iptables: ist mit folgenden Zeilen die Kiste dicht?

[Fats]

Mojn allerseits!

Mal ne Frage an die Experten: Ist mit folgenden Zeilen alles ok und mein Rechner wirklich dicht? (Also dicht bis auf SSH )

#Konstante definieren
EXT_INTERFACE="eth0"
IP="1.2.1.4"
UPRV_PORTS="1024:65535"
SSH_SERVER_PORT="22"

# Löschen und Policy setzen
iptables -F
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

# Loopback erlauben
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# SSH raus erlauben
iptables -A OUTPUT -o $EXT_INTERFACE -p tcp -s $IP --sport $UPRV_PORTS --dport $SSH_SERVER_PORT -j ACCEPT
iptables -A INPUT -i $EXT_INTERFACE -p tcp ! --syn --sport $SSH_SERVER_PORT -d $IP --dport $UPRV_PORTS -j ACCEPT

# SSH rein erlauben
iptables -A INPUT -i $EXT_INTERFACE -p tcp --sport $UPRV_PORTS -d $IP --dport $SSH_SERVER_PORT -j ACCEPT
iptables -A OUTPUT -o $EXT_INTERFACE -p tcp ! --syn -s $IP --sport $SSH_SERVER_PORT --dport $UPRV_PORTS -j ACCEPT

Was sagt ihr dazu?

Viele Grüße
Fats

 

[jengelh]

Mal ne Frage an die Experten: Ist mit folgenden Zeilen alles ok und mein Rechner wirklich dicht? (Also dicht bis auf SSH )

Das ist etwas zweideutig...

iptables --policy INPUT DROP

Kannst du in -P INPUT DROP abkürzen.

# SSH raus erlauben
iptables -A OUTPUT -o $EXT_INTERFACE -p tcp -s $IP --sport $UPRV_PORTS --dport $SSH_SERVER_PORT -j ACCEPT

Wieso auf "-s $IP" beschränken? Bist du ein Router?

iptables -A INPUT -i $EXT_INTERFACE -p tcp ! --syn --sport $SSH_SERVER_PORT -d $IP --dport $UPRV_PORTS -j ACCEPT

Wieso so schwer? Mit "-m conntrack --ctstate ESTABLISHED" einfach alle aufgebauten Verbindungen erlauben.

# SSH rein erlauben
iptables -A INPUT -i $EXT_INTERFACE -p tcp --sport $UPRV_PORTS -d $IP --dport $SSH_SERVER_PORT -j ACCEPT

Wieso auf $UPRV_PORTS beschränken?

iptables -A OUTPUT -o $EXT_INTERFACE -p tcp ! --syn -s $IP --sport $SSH_SERVER_PORT --dport $UPRV_PORTS -j ACCEPT

siehe conntrack/ESTABLISHED.

 

[Fats]

[...]

# SSH raus erlauben
iptables -A OUTPUT -o $EXT_INTERFACE -p tcp -s $IP --sport $UPRV_PORTS --dport $SSH_SERVER_PORT -j ACCEPT

Wieso auf "-s $IP" beschränken? Bist du ein Router?

Ist sicherheitshalber dafür, falls sich irgendein Böse-Buben-Programm mit anderer IP ausgibt ...

Wieso so schwer? Mit "-m conntrack --ctstate ESTABLISHED" einfach alle aufgebauten Verbindungen erlauben.

Mit -m aktiviere ich die Zustandsüberwachung der einzelnen Verbindungen. Die kosten ggf. etwas mehr RAM - da muß ich sparen --> vmware user
By the way: warum ist "-m conntrackt" leichter?

# SSH rein erlauben
iptables -A INPUT -i $EXT_INTERFACE -p tcp --sport $UPRV_PORTS -d $IP --dport $SSH_SERVER_PORT -j ACCEPT

Wieso auf $UPRV_PORTS beschränken?

Weil Anfragen VON einem SSH Client immer auf einem höheren Port kommen müssen, oder?

Viele Grüße
Fats

 

[Fats]

.... nur nochmal kurz nachgehakt: Prinzipiell ist mit dem Script oben - von einigen kleineren Optimierungen abgesehen - ein Rechner so "dicht" zu bekommen, daß SSH die einzige Schwachstelle ist, oder?

Gruß
Fats

 

[jengelh]

Ist sicherheitshalber dafür, falls sich irgendein Böse-Buben-Programm mit anderer IP ausgibt ...

Und wer sollte das sein? Mehr als eine Netzwerkkarte drin? (VMware Bridge zählt nicht.)

Mit -m aktiviere ich die Zustandsüberwachung der einzelnen Verbindungen. Die kosten ggf. etwas mehr RAM - da muß ich sparen --> vmware user
By the way: warum ist "-m conntrackt" leichter?

Weil du dir die Regeln für den Rücktransport sparen kannst, also aus "allow A allow A', allow B, allow B', else drop" kannst du "allow A, allow B, allow *', else drop" machen, so in etwa als Pseudoantwort.

Weil Anfragen VON einem SSH Client immer auf einem höheren Port kommen müssen, oder?

Nein. Überhaupt nicht. Der Sourceport kann alles sein, erst recht wird der Attacker wohl root auf seiner Kiste haben und das bewerkstelligen können.

 

[Fats]

Ist sicherheitshalber dafür, falls sich irgendein Böse-Buben-Programm mit anderer IP ausgibt ...

Und wer sollte das sein? Mehr als eine Netzwerkkarte drin? (VMware Bridge zählt nicht.)

Wenn ein Angreifer root-Rechte erlangt ist eh alles hin - klar! Aber solange er nur user-Rechte bekommt, würden gefälschte Pakete abgefangen wreden ... D.h. meine Maschine kann selbst nur bedingt nach außen attackieren.

[...]
By the way: warum ist "-m conntrackt" leichter?

Weil du dir die Regeln für den Rücktransport sparen kannst, also aus "allow A allow A', allow B, allow B', else drop" kannst du "allow A, allow B, allow *', else drop" machen, so in etwa als Pseudoantwort.

OK, wenn ich das recht verstehe, dann werden die Regelkonstrukte übersichtlicher, damit auch weniger und in der Ausführung schneller. Stimmt der Gedankengang?

Weil Anfragen VON einem SSH Client immer auf einem höheren Port kommen müssen, oder?

Nein. Überhaupt nicht. Der Sourceport kann alles sein, erst recht wird der Attacker wohl root auf seiner Kiste haben und das bewerkstelligen können.

OK, aber im Normalfall - bei Einhaltung der Kommunikationsprotokolle - müssen die Anfragen des Clients doch von einem Upper-Port kommen. Wenn dem nicht so ist, dann kann man sie gleich raus werfen, da sie dann mit Sicherheit manipuliert wurden.

Gruß
Fats

 

[jengelh]

Wenn ein Angreifer root-Rechte erlangt ist eh alles hin - klar! Aber solange er nur user-Rechte bekommt, würden gefälschte Pakete abgefangen wreden ... D.h. meine Maschine kann selbst nur bedingt nach außen attackieren.

Und du meinst nicht, dass ein normaler User einfach so gespoofte Pakete erzeugen kann? Denk' nochmal nach...

OK, wenn ich das recht verstehe, dann werden die Regelkonstrukte übersichtlicher, damit auch weniger und in der Ausführung schneller. Stimmt der Gedankengang?

Ja, abzüglich des genannten RAMs sollte sich aber in Grenzen halten. Selbst eine lahme Linuxkiste schafft heutzutage mehr gleichzeitige Verbindungen als "billige" Router-Lösungen wie z.B. Toshiba Magna20. (Oder die conntrack-Größe eines vom ISP bereitgestellten Routers in ******* ist bescheuert klein eingestellt - weniger als 1000.)

OK, aber im Normalfall - bei Einhaltung der Kommunikationsprotokolle - müssen die Anfragen des Clients doch von einem Upper-Port kommen. Wenn dem nicht so ist, dann kann man sie gleich raus werfen, da sie dann mit Sicherheit manipuliert wurden.

(1) Das steht in keinem RFC, dass es ein Highport sein muss (und wenn doch, zeige mir die Zeile)
(2) Recht hat du
(3) In welchem Fall aber ein Angreifersystem sowieso einen Highport nimmt - und damit die Beschränkung, SSH nur von Highports zu erlauben, sinnlos ist.

 

[Fats]

Und du meinst nicht, dass ein normaler User einfach so gespoofte Pakete erzeugen kann? Denk' nochmal nach...

Hmm ... Du meinst, man müsste root sein, um IP-Pakete überhaupt fälschen zu können? In diesem Fall kann man die Regel wirklich vereinfachen und das "-s $IP" weglassen. Stimmt!
Wenn nur unter dem root-Account gespooft werden kann, dann ist der Rechner eh nicht mehr zu halten und mit den lächerlichen iptables-Scripten schon gar nicht ;-) Dann ist es egal, da die Kiste sowieso nicht mehr kontrollierbar ist.

Ja, abzüglich des genannten RAMs sollte sich aber in Grenzen halten. Selbst eine lahme Linuxkiste schafft heutzutage mehr gleichzeitige Verbindungen als "billige" Router-Lösungen [...]

Wie ist Dein Bauchgefühl: Ein Host und 3 bis 4 VMs und alle mit einer FW mit Zustandsüberwachung. Gesamt RAM 1GB und die VMs so mit 64MB bis 350MB. Passt das oder wäre hier besser ohne?

By the way: Was ist eigentlich -m conntrack im Vergleich zu -m state?

(1) Das steht in keinem RFC, dass es ein Highport sein muss (und wenn doch, zeige mir die Zeile)

Keine Ahnung - hatte das bisher immer so gelesen und gehört:
Client sendet auf HighPort an Server auf LowPort
Server sendet auf LowPort an Client auf HighPort
Dachte, das wäre so als Protokoll festgelegt?! Wenn ich mal Luft hab schnökere ich mal in den RFCs

(3) In welchem Fall aber ein Angreifersystem sowieso einen Highport nimmt - und damit die Beschränkung, SSH nur von Highports zu erlauben, sinnlos ist.

Klar, wenn ich nur die HighPorts zulasse und ein Angreifer sich diese aussucht, dann hab ich natürlich keine Chance. Ich fange halt nur ab, wenn der Angreifer fälschlicherweise einen LowPort nutzt. Aber was würde er eher nehmen: einen HighPort oder einen LowPort? Die Frage ist vermutlich ähnlich wie, ob es an Weihnachten regnet oder nicht

Viele Grüße
Fats