[gelöst] Angeblicher Ladefehler iptable rules beim Start

[Piepnase]

Das sind nun die Regeln auf dem Server, auf den ich per SSH zugreifen möchte und mit denen der SSH-Zugriff auch funktioniert:

Code: Alles auswählen

Chain INPUT (policy DROP 13 packets, 6970 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        8   624 ACCEPT     all  --  lo     any     anywhere             anywhere            
2       60  6441 ACCEPT     udp  --  eth0   any     anywhere             anywhere             udp spt:domain
3      300 23991 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED
4        0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 501 packets, 30060 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        8   624 ACCEPT     all  --  any    lo      anywhere             anywhere            
2       60  4062 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp dpt:domain
3      170 20167 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
4        0     0 ACCEPT     tcp  --  any    eth0    anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED

Hier die Regeln auf meinem Client, mit denen der Zugriff aber nur dann funktioniert, wenn ich die INPUT und OUTPUT Policies beide auf ACCEPT habe, was natürlich nicht okay ist:

Code: Alles auswählen

Chain INPUT (policy ACCEPT 20 packets, 3319 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     3992  300K ACCEPT     all  --  lo     any     anywhere             anywhere            
2       55  6745 ACCEPT     udp  --  wlan0  any     anywhere             anywhere             udp spt:domain
3        0     0 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             tcp dpt:ssh ctstate NEW,ESTABLISHED
4      435  289K ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             multiport sports http,https ctstate RELATED,ESTABLISHED
5        0     0 ACCEPT     tcp  --  wlan0  any     anywhere             anywhere             tcp dpt:76543 ctstate NEW,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 25 packets, 4523 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     3992  300K ACCEPT     all  --  any    lo      anywhere             anywhere            
2       55  3382 ACCEPT     udp  --  any    wlan0   anywhere             anywhere             udp dpt:domain
3        0     0 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             tcp spt:76543 ctstate RELATED,ESTABLISHED
4      451 47900 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             multiport dports http,https ctstate NEW,ESTABLISHED
5        0     0 ACCEPT     tcp  --  any    wlan0   anywhere             anywhere             tcp spt:ssh ctstate RELATED,ESTABLISHED

@dufty, an allen möglichen Stellen wird empfohlen, dass man den SSH-Standardport durch einen beliebigen Port ersetzt. Daher die Regel mit dem Port 76543. In den SSH-Config-Dateien habe ich auf dem Client und dem Server den abweichenden Port eingestellt. Da müsste dann doch die entsprechende iptables-Regel funktionieren. Wenn das bei Nutzung von iptables nicht geht, dann sind doch all die Empfehlungen, vom Standardport 22 abzuweichen eigentlich für die Katz, oder?
Unabhängig davon brauche ich immer noch eine Lösung für den Client, damit ich dort die Policies für IN- und OUTPUT auf DROP stellen kann.

Hier ist übrigens meine /etc/network/interfaces. Sehr übersichtlich:

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

[dufty2]

Du hast einen
* Client, der soll auf den Server per ssh auf port xy zugreifen können. Auf den Client soll sich aber niemand/von nirgendwo per ssh (von mir aus Port xy) zugegriffen werden können.
* Server, auf dem von Deinem Client aus per ssh auf Port xy zugegriffen werden darf. Der Server selbst soll sich nirgendwo hin per ssh connektieren können.

=> Dann sind die Regeln für Deinen client nicht korrekt, denn dieser braucht dann in der
_OUTPUT_-chain
die Regel
tcp dpt:22 ctstate NEW,ESTABLISHED
und für INPUT
tcp spt:22 ctstate ESTABLISHED
weil er ein Client ist und die ssh-Verbindung initiiert sprich aufbaut:
Client-IP:>1023 => Server-IP:22 (xyz)

Die Regeln für Server sind ok.

Unabhängig davon, wenn der Networkmanager für eth0 und wlan zur gleichen Zeit die gleiche IP vergibt (und dies kein Art Loadbalancing werden soll), ist das Netzwerk nicht in Ordnung und dann helfen auch die besten iptables nix mehr

[Piepnase]

@dufty,
vielen Dank!
Man soll eben nicht gleichzeitig an 3 Rechnern herumtesten, dann geht sowas schon mal völlig in die Hose.
Ich habe nämlich 2 Testrechner und als ich iptables noch nicht eingestellt hatte, standen die Policies ja standardmäßig allesamt auf ACCEPT, so dass das mit den --sport und --dport gar nicht aufgefallen ist. Es durfte ja alles in beide Richtungen passieren.
Jetzt funktioniert es aber.

Gibt es eine Möglichkeit, das "Kraut und Rüben-Gewurschtel" bzgl. Networkmanager zu beheben?
Mein Testrechner ist ein Laptop und bei der Installation von Debian per Netinstall-CD fehlen mir wlan-Treiber. Daher habe ich die Netzwerkkonfiguration bei der Installation über LAN (eth0) gemacht, mir dann die fehlenden WLAN-Treiber besorgt und im Nachhinein WLAN eingerichtet, denn mit dem Laptop möchte ich ortsungebunden sein.