Iptables NEW, ESTABLISHED und RELATED verstehen

[SirNibo]

Hallo,

kann mir jemand die Schlüsselwörter NEW, ESTABLISHED und RELATED erklären.
Irgendwie werde ich im Internet nicht schlau daraus.
Established kriege ich noch hin. Aber das Schlüsselwort NEW bei conntrack verstehe ich überhaupt nicht
Wann macht es Sinn das zu benutzen?

Danke

[eggy]

https://www.netfilter.org/documentation ... WTO-7.html

NEW: Verbindung ist neu, Paket gehört zu keiner bekannten Verbindung
ESTABLISHED: Verbindung gibts schon, Paket gehört zu anderen Paketen aus der selben Verbindung
RELATED: Ist zwar nicht die selbe Verbindung, gehört aber trotzdem irgendwie dazu, nen Fall von FTP ist da das Standardbeispiel, gibt auch andere, in der Regel: Kontrollverbindung und Nutzdaten laufen parallel über unterschiedliche Ports

Man könnte z.B. sagen, immer wenn was "NEW" ist und nicht vorher von anderen Regeln verworfen wurde, dann soll ein Eintrag ins Log. Reicht oft ja schon pro aufgebauter Verbindung einmal zu loggen, statt bei jedem Paket.

Oder NEW soll durch chain A, wohingegen ESTABLISHED durch chain B geht. Manchmal macht's Sinn, bestimmte Fälle auf die Überholspur zu schicken und sich nur wenige andere Pakete in Ruhe anzusehen.

[TomL]

Speziell 'established' ist dabei eine ziemlich komplizierte Kiste. Das bedeutet, falsch angewandt kann damit in Einzelfällen das ganze Regelwerk außer Kraft gesetzt werden. Eine Verbindung gilt dann als 'established', wenn sie das erste Mal völlig unbehelligt die Postrouting-Chain (oder den entsprechenden nft-Hook) verlassen hat. Das heißt, das Paket kommt jetzt beim lauschenden Service an, wird aber -weil hacking, illegal oder sonst was- vom Service verworfen. Das bedeutet aber auch, dass alle folgenden illegalen Versuche des gleichen Hackers auch beim Service ankommen, eben weil die Verbindung jetzt 'established' ist.

Dieser Umstand macht dann den Einsatz von z.B. Fail2ban notwendig, damit dieses Programm eben durch das Gejammere des Services in seinem Log über die Vorfälle stolpert. Der Paketfilter ist also an der Stelle wegen 'established' raus aus dem Rennen.

Fazit: 'Established' ganz oben in der Regelliste kann unter bestimmten Voraussetzungen also ziemlich kontraproduktiv sein... und zweitens, besser nicht die Logs eines Services deaktivieren....

[wanne]

Speziell 'established' ist dabei eine ziemlich komplizierte Kiste. Das bedeutet, falsch angewandt kann damit in Einzelfällen das ganze Regelwerk außer Kraft gesetzt werden. Eine Verbindung gilt dann als 'established', wenn sie das erste Mal völlig unbehelligt die Postrouting-Chain (oder den entsprechenden nft-Hook) verlassen hat. Das heißt, das Paket kommt jetzt beim lauschenden Service an, wird aber -weil hacking, illegal oder sonst was- vom Service verworfen. Das bedeutet aber auch, dass alle folgenden illegalen Versuche des gleichen Hackers auch beim Service ankommen, eben weil die Verbindung jetzt 'established' ist.

Dieser Umstand macht dann den Einsatz von z.B. Fail2ban notwendig, damit dieses Programm eben durch das Gejammere des Services in seinem Log über die Vorfälle stolpert. Der Paketfilter ist also an der Stelle wegen 'established' raus aus dem Rennen.

Das macht jetzt nicht wirklich viel Sinn.

[TomL]

Das macht jetzt nicht wirklich viel Sinn.

Korrekt, das ist eben genau die Falle, in die man reinfallen kann, wenn man das nicht weiß. Es gibt Umstände, da kann man das eliminieren, es gibt andere Umstände, da kann man das nicht.

BTW, das ist nicht meine Interpretation der Funktionsweise dessen, was zu "established" führt, sondern aus einem Vortag über das Conntrack-Modul von Florian Westphal. Damit sind die möglichen Auswirkungen eben genau so, wie ich das beschrieben habe.

[wanne]

Korrekt, das ist eben genau die Falle, in die man reinfallen kann, wenn man das nicht weiß.

Ich weiß glaube ich ziemlich gut wie contrak funktioniert. – Zumindest wenn es sich um eine tcp-Verbindung handelt. (Ich habe mir das mal für ICMP angeguckt das ist ziemlich strange und man kann wirklich komische Effekte verursachen.) Ich verwende es praktisch nie. Die aller meisten benutzen ESTABLISHED um sich die zweite Regel für den in die entgegen gesetzte Richtung zu ersparen:

Code: Alles auswählen

-A OUTPUT -d debianforum.de -p tcp -m tcp --dports 443,80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dports 443,80 -j REJECT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A INPUT -j REJECT

Statt

Code: Alles auswählen

-A OUTPUT -d debianforum.de -p tcp -m tcp --dports 443,80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dports 443,80 -j REJECT
-A INPUT -s debianforum.de -p tcp -m tcp --sports 443,80 -j ACCEPT
-A INPUT -p tcp -m tcp --sports 443,80 -j REJECT

Das ist zwar nicht die effizienteste Methode aber legitim. Damit du in OUTPUT nach ESTABLISHED rein rutschst, musst du zuerst durch die INPUT-Chain durch. Und die filtert korrekt.

Man kann damit ganz nett Lastenverteilung mit machen. Aber da bin ich bequem genug, dass ich nen xinetd oder haproxy für nehme.

Viel schlimmer ist, dass ich weiß, wie fil2ban funktioniert. Und deswegen lasse ich da ganz sicher die Finger von. Bekomm ein mal ne DDOS und du verstehst warum. Die Last durch Fail2ban steigt quadratisch mit der Anzahl der fehlgeschlagenen versuche und ist auch noch ineffizient in Python und mit einzelnen Regeln geschrieben. Was besseres kann dir als Auslaster nicht passieren. Und bringen tut es defakto nichts. Wer gestohlene Passwörter hat gibt die für gewöhnlich korrekt ein. Wer durchprobiert nutzt für jeden Versuch ne neue IP. Die einzigen Leute, die fail2ban aussperrt, sind die User, die nach dem dritten mal immer noch nicht gemerkt haben, dass sie Capslock drin haben.

[TomL]

Die aller meisten benutzen ESTABLISHED um sich die zweite Regel für den in die entgegen gesetzte Richtung zu ersparen:

Yes Sir, so isses... aber ich empfinde das nicht zwingend als kritisch.... zumal ich da sowieso eine eher unorthodoxe Vorgehensweise eingeschlagen habe. Ich reguliere primär hinter dem DSL-Router, wer was nach draußen senden darf.

Das ist zwar nicht die effizienteste Methode aber legitim. Damit du in OUTPUT nach ESTABLISHED rein rutschst, musst du zuerst durch die INPUT-Chain durch. Und die filtert korrekt.

Nicht ganz... richtig, INPUT filtert korrekt, aber das isses nicht allein. Das Paket muss auch quasi "unbehelligt" POSTROUTING passieren, denn da könnte es immer noch getötet werden. Das bedeutet nach meinem Verständnis, erst nach POSTROUTING (und nach dem L4-Tracker) erfolgt syn-ack, und erst dann ist es ESTABLISHED.

Viel schlimmer ist, dass ich weiß, wie fil2ban funktioniert. Und deswegen lasse ich da ganz sicher die Finger von. Bekomm ein mal ne DDOS und du verstehst warum.

Yes Sir, ich lass da auch aus ähnlichen Beweggründen die Finger von ... *lol* ... aber das gilt nur für mich, ich maße mir da kein allgemeines Urteil an.

Die einzigen Leute, die fail2ban aussperrt, sind die User, die nach dem dritten mal immer noch nicht gemerkt haben, dass sie Capslock drin haben.

[wanne]

Das Paket muss auch quasi "unbehelligt" POSTROUTING passieren, denn da könnte es immer noch getötet werden.

INPUT muss nicht durch POSTROUTING nur PREROUTING und dann bist du established. Die Antwort geht natürlich doch durch POSTROUTING. Du kannst dir natürlich immer durch eine Beliebige vorhergehende Regel alles kaputt schießen. Dazu musst du gar nicht auf die POSTROUTING-Chain sondern kannst einfach ein -I INPUT 1 -j DROP davor hängen. Dann ist Schluss

Edit Satz richtig gestellt.

[TomL]

Das Paket muss auch quasi "unbehelligt" POSTROUTING passieren, denn da könnte es immer noch getötet werden.

INPUT muss nicht durch POSTROUTING und dann bist du established. Die Antwort geht natürlich doch durch POSTROUTING nur PREROUTING. Du kannst dir natürlich immer durch eine Beliebige vorhergehende Regel alles kaputt schießen. Dazu musst du gar nicht auf die POSTROUTING-Chain sondern kannst einfach ein -I INPUT 1 -j DROP davor hängen. Dann ist Schluss

Nein, nicht INPUT muss irgendwo durch, ich spreche von TCP-Paketen. Alle Pakete passieren prerouting -> forward || input -> postrouting. Auf dem gesamten Weg liegt noch mehr, das ist aber hierbei irrelevant. Meine vorherige Aussage war dennoch missverständlich. Richtig wäre: Ein TCP-Paket muss unbehelligt die existierenden Regeln passieren (wozu selbstverständlich am Ende auch Postrouting gehört), und erst danach kann es im L4-Tracker established werden. Das gilt für TCP-Pakete, nicht für UDP.... UDP ist stateless und Conntrack für UDP ist mir derzeit nicht bekannt.

Ein Drop -völlig egal, an welcher Stelle- macht genau das, was ich gesagt habe, es verhindert, dass ein TCP-Paket das bestehende Regelwerk (einschl. POSTROUTING) unbehelligt passiert. Es wird verworfen, bevor es den L4-Tracker erreicht, und damit kann es nie den Status 'ESTABLISHED' erhalten.

[wanne]

Nein, nicht INPUT muss irgendwo durch, ich spreche von TCP-Paketen. Alle Pakete passieren prerouting -> forward || input -> postrouting.

Nein. Einkommende Pakete gehen PREROUTING -> INPUT [-> L4-Processing -> Prozess] fertig! Dann ist es established. Lediglich weitergeleitete Paketete gehen den Weg PREROUTING -> FORWARD -> POSTROUTING

[TomL]

Ja, Du hast natürlich Recht... weil Du von "ESTABLISHED bei ankommenden TCP-Paketen (INPUT) sprichst. Aber das ist nur die eine Seite der Medaille, ich betrachte beide.

Ich sagte ja schon, ich reguliere hinter dem DSL-Router primär auch, wer nach draußen telefonieren darf. Und auch dabei ist ESTABLISHED ein Status. POSTROUTING betrifft hierbei beide Chains, FORWARD und OUTPUT, im Grunde genommen also alle das Interface verlassenden TCP-Pakete. Wenn wir nur über input reden, ist ESTABLISHED gesetzt, sobald das Paket die INPUT-Chain unbehelligt verlassen hat. Reden wir aber auch von output, passiert das erst nach POSTROUTING.

Damit gibt es kein outgoing-established mehr:

Code: Alles auswählen

chain postrouting {
	type nat hook postrouting priority 100; policy accept;
	drop
}