IPTables Default Policies

[Anonymous]

Wenn ich

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

mache, und dann noch mit

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

SSH zulasse, bekomme ich nach ausführen des scriptes keinen zugriff per putty mehr, trotz der SSH-regel oben, weiss einer warum??
iptables version ist 1.2.11 glaube ich, auf jeden fall die neueste DEBIAN version...

 

[Martin Breidenbach]

Wie wär's wenn Du auch ausgehende Antwortpakete zuläßt ?

 

[Anonymous]

hab mal ne OUTPUT regel dazugeklatscht.. immernoch am blocken die feuerwand
oder wie genau hast du das gemeint?

 

[oc2pus]

hab mal ne OUTPUT regel dazugeklatscht.. immernoch am blocken die feuerwand

und wie sieht die aus ?
du denkst dran das die "zugehörige ausgehende Verbindung" des ssh nicht zwingend auf Port 22 liegt ?

 

[oc2pus]

hab mal ne OUTPUT regel dazugeklatscht.. immernoch am blocken die feuerwand

und wie sieht die aus ?
du denkst dran das die ausgehende Verbindung des ssh nicht zwingend auf Port 22 liegt ?

 

[Anonymous]

ich habe
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
und
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
probiert, beides ein fehlschlag, es kommt:

iptables v1.2.11: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

 

[Martin Breidenbach]

Erlaube erstmal testweise alles was rausgeht. Dann müßte es klappen. Wenn nicht sollte die Fehlerquelle woanders liegen.

Dann kannst Du ja eine Regel machen die ESTABLISHED und RELATED zuläßt. Damit werden alle Antwortpakete zu bestehenden Verbindungen durchgelassen.

 

[Anonymous]

Erlaube erstmal testweise alles was rausgeht.

hab ich, dann gehts auch

Dann kannst Du ja eine Regel machen die ESTABLISHED und RELATED zuläßt. Damit werden alle Antwortpakete zu bestehenden Verbindungen durchgelassen.

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

richtig so, oder? geht aber auch nicht. Wo kann der Fehler noch liegen?

 

[Martin Breidenbach]

Äh nee das wäre dann für output. Soll ja Antwortpakete raus- und nicht reinlassen.

 

[Anonymous]

also das script sieht mittlerweile so aus:

iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

--> immernoch nix, könnt ihr euch nochmal erbarmen?

 

[Anonymous]

kann mir niemand helfen?????

 

[Anonymous]

hi,
sieh dir mal die sshd_config an, was den aktiviert ist und dann eventuell `cat /etc/services|grep ssh`.
Kann ja sein das dir die freigabe vom "SSH X11 forwarding offset" port was hilft wenn du mit x arbeitest !?

Mƒg ®êïñï
ein mitschnitt per tcpdump kann auch nicht schaden ;-)

 

[Anonymous]

also die config scheint mir ganz in ordnung zu sein, er läuft auf port 22, was dein befehl auch bestätigt, jedoch sehe ich port22 auf TCP + UDP. X11 Forwarding benötige ich nicht, da RootServer.
es muss irgendwie mit dem ports zusammenhängen, ich vermute mal dass der Anbieter des Server Port 22 auf Port XY routet oder so, wie müsste ich tcpdump genau verwenden, damit ich sehen kann welche ports bei einem ssh login genau genutzt werden? Ich hab sogar schon versucht, mittels dem iptables-target LOG etwas herauszubekommen, aber leider ist in dem kernel kein ip_conntrack eingebacken, und auch kein loadable module support

 

[Martin Breidenbach]

Falls Du ethereal installiert hast dann kannst Du statt tcpdump besser ethereal verwenden - der ist einfach mit seiner grafischen Oberfläche leichter zu bedienen.

 

[Anonymous]

X11 Forwarding benötigte ich nicht, da Rootserver

--> Rootserver haben in dem meissten Fällen kein KDE, aber trotzdem danke...

 

[warpi]

HI rm -rf /
Kannst du nicht temporär nen xclient & ethereal auf dem server installieren. Dann mit ssh von einem anderen Linuxrechner ethereal aufrufen und mitsniffen?
Wenns keine andere Consolenlösung gibt, um die Ports herauszufinden.

 

[ThomasF]

Hmm,

schau Dir doch erstmal während eines Verbindungsaufbaus die /var/log/messages an ...

Dort siehst Du genau welche Pakete geblockt werden ...

Falls nicht bau doch eine Logregel ein ..

So long

ThomasF

 

[oc2pus]

also das script sieht mittlerweile so aus:

iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

also die OUTPUT-Regel für Port 22 brauchst du nur wenn DU von deinem Server eine ssh Verbindung nach draussen aufbauen willst.

wenn du von extern auf deinen Server via SSH zugreifst, kommst du über port 22 rein, aber dein SSH daemon antwortet auf einem anderen Port, der steht im /var/log/messages:

sshd[18094]: Accepted keyboard-interactive/pam for oc2pus from ::ffff:<ip-nummer> port 59300 ssh2

Und d.h. wenn deine OUTPUT Policy DROP ist, kann das nicht gehen ... aber Achtung: der Port variiert! du kannst aber einen Port-range in deinem sshd konfigurieren