iptables Anfänger Fragen

[debianx]

Hallo,

ich bringe mir gerade iptables etwas näher und nach etwas testen sind mir drei Fragen aufgekommen.

1. Bei einigen Beispielen in Netz findet man innerhalb einer Zeile hintereinander : "-m udp -p udp". Ich verstehe nicht wofür das "-m udp" sein soll? Man hat doch schon die implizite Match-Erweiterung mit "-p udp" also wofür die explizite Match-Erweiterung "-m udp". Gibt es überhaupt udp als explizite Match-Erweiterung und wenn ja warum sollte man beides nutzen oder reicht nicht einfach die implizite Match-Erweiterung "-p udp"?

2. Wenn man (ohne benutzerdefinierte Ketten) bei Auftreten von Bedingungen diese Bedingungen per -j LOG loggen will ist dann der normale Weg zuerst zu loggen und dann die entsprechende Aktion auszuführen? Also eine Aktion die auch geloggt wird besteht die immer aus zwei identischen Zeilen die sich nur unterscheiden, dass die erste -j LOG als Aktion hat und die zweite dann die eigentliche Anwendung zB -j DROP ? Ist das korrekt?

3. Wenn man zu Beginn als Reset per -F und -X die Regeln+Ketten löscht, dann nat und mangle in den folgenden Regeln keine Rolle spielen, macht es sicherheitshalber trotzdem Sinn immer die Regeln+Ketten auch für nat und mangle zu löschen?

Grüße

[debianx]

Entweder die Fragen waren zu blöd und leicht oder zu schwer
Ich beantworte mal selber in der Hoffnung ungefähr richtig zu liegen:
1. ich behaupte mal die explizite Match-Erweiterung "-m udp" macht kein Sinn wenn die implizite Match-Erweiterung mit "-p udp" existiert.
2. Ja. LOG macht nichts mit dem Paket, daher sollte es vor Dingen die wirklich was mit dem Paket machen, wie DROP ACCEPT etc, angeordnet sein. Ich ich behaupte mal sobald DROP ACCEPT etc in Aktion kommt sind die folgenden Bedingungen zu dem Paket obsolet.
3. ich würde schätzen Reset für nat und mangle ist nicht nötig wenn dahingehend auch nichts verarbeitet/konfiguriert wird.

kann man das in etwa so stehen lassen?

[TomL]

Entweder die Fragen waren zu blöd und leicht oder zu schwer

Nö, nicht blöd, aber schon sehr anspruchsvoll und immer mit der Gefahr verbunden, sich unnütz aufs Glatteis zu bewegen.

kann man das in etwa so stehen lassen?

Ja, das denke ich....

[eggy]

zu 1: Die manpage von iptables-extensions sagt dazu

MATCH EXTENSIONS
iptables can use extended packet matching modules with the -m or --match options, followed by the matching module name; after these, various extra command line options become available, depending on the specific module. You can specify multiple extended match modules in one line, and you can use the -h or --help options after the module has been specified to receive help specific to that module. The extended match modules are evaluated in the order they are specified in the rule.
If the -p or --protocol was specified and if and only if an unknown option is encountered, iptables will try load a match module of the same name as the protocol, to try making the option available.

zu 3: Die zusätzliche Zeit die Regeln mit in nen Script zu schreiben und auch auszuführen kostet so gut wie nichts, sich später wundern, warum es nicht so läuft wie erwartet, hingegen viel Zeit.

[Gunman1982]

Übrigens setzt das kommende Buster als Standard auf nftables. Vielleicht eher das anschauen?

[debianx]

Ich hatte sogar zuerst mit nftables gestartet weil es wie bekannt iptables ablösen soll, allerdings gibt es dazu derart wenig verständliche Beispiele (zumindest für mich Einsteiger) und ich kam nicht weiter. Bei iptables gibt es extrem viel Stoff und Erklärungen zum lernen, dass ich damit viel schneller ans Ziel gekommen bin. Ich denke in ein paar Jahren starte ich nochmal der Versuch mit nftables wenn es dazu mehr Stoff gibt, ich habe aber den Eindruck, selbst die Profis nutzen immer noch zum Großteil iptables.

[TomL]

Übrigens setzt das kommende Buster als Standard auf nftables. Vielleicht eher das anschauen?

Ich würde auch unbedingt nftables empfehlen.... das ist deutlich eingängiger. Wobei ich festgestellt habe, dass es in Testing (also noch nicht Buster, und auch nicht mit dem Vor-Release-Installer) noch nicht der Standard ist. Da wars noch iptables. Mal abwarten, wie's im Release dann wirklich aussieht.

Ich hatte sogar zuerst mit nftables gestartet weil es wie bekannt iptables ablösen soll, allerdings gibt es dazu derart wenig verständliche Beispiele (zumindest für mich Einsteiger) und ich kam nicht weiter.

Ich denke, das ist so wie immer.... das bessere wird sich erst langsam behaupten. Ich halte nftables definitiv für eine Verbesserung. Ich schick Dir mal nen Link per PM.... vielleicht hilft Dir das für den Anfang weiter.

[debianx]

danke!

[wanne]

Zu 2.: Ja.
Zu 1:
Was da -m macht haben hier offensichtlich einige nicht verstanden.
-p tcp filtert auf tcp Pakete. Das ist relativ einfach. Aber es gibt so Varianten wie --sport. Das ist keine echte iptables-Regel sondern eine aus dem Modul tcp. Es gibt möglicherweise gleich heißende filter in anderen Modulen.
Um die tcp Option --sport nutzen zu können muss man -m tcp angeben.
Nun ist iptables aber intelligent: Ist -p tcp schon angegeben und folgt darauf ein --sport fügt er automaitsch ein -m tcp ein. (Man sieht das dann in iptables-save, dass das trotzdem drin ist.) Entsprechend unnötig ist meistens das -m. (Ich und viele andere nutzuen es defakto trotzdem aus Gewohnheit immer: Wenn da ein --sport o.ä. kommt kommt ein -m tcp davor.)
Es gibt aber Ausnahmefälle wo es doch Sinn macht: Wäre jetzt schon ein anderes Modul geladen worden, dass eine --sport Option hat, könnte man mit einem Vorangestellten -m erzwingen, dass der tcp und nicht der andere Filter genutzt wird.

[TomL]

Was da -m macht haben hier offensichtlich einige nicht verstanden.
::::
Es gibt aber Ausnahmefälle wo es doch Sinn macht: Wäre jetzt schon ein anderes Modul geladen worden, dass eine --sport Option hat, könnte man mit einem Vorangestellten -m erzwingen, dass der tcp und nicht der andere Filter genutzt wird.

Das müsstest Du aber mal genauer erkären... damit wir nicht ahnungslos bleiben. Bei der Frage des TEs ging es nämlich nicht um eine allgemeine Match-Option, sondern konkret um eine Match-Option fürs gleiche Protokoll, also -p und -m mit gleichem Parameter. Bei Deinem Beispiel könnte ich mir als theoretisches Problem vorstellen, dass ich 2 Regeln für den gleichen --sport habe und wenn beispielsweise in der ersten Regel -m udp matcht, wird die Regel ausgeführt, ansonsten wird die zweite Regel ausgeführt, weil -m udp nicht gematcht hat. Soweit sogut... nur funktioniert genau das nicht. Deswegen habe ich mal ein bisschen rumgespielt:

Funktioniert:

Code: Alles auswählen

# iptables -I INPUT -p udp  --sport 64998 -j ACCEPT

Funktioniert erwartungsgemäß nicht:

Code: Alles auswählen

# iptables -I INPUT -m udp --sport 64999 -j ACCEPT
iptables v1.8.2 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain INPUT

# iptables -I INPUT -p tcp -m udp --sport 64999 -j ACCEPT
iptables v1.8.2 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain INPUT

Funktioniert natürlich:

Code: Alles auswählen

# iptables -I INPUT -p udp -m udp --sport 64999 -j ACCEPT

Ergebnis:

Code: Alles auswählen

# iptables -L -nv
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:64998
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:64999

# iptables-save > /tmp/rules.v4

# cat /tmp/rules.v4
    # Generated by xtables-save v1.8.2 on Sat Jun 22 23:06:31 2019
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -p udp -m udp --sport 64998 -j ACCEPT
    -A INPUT -p udp -m udp --sport 64999 -j ACCEPT
    COMMIT
    # Completed on Sat Jun 22 23:06:31 2019
    # Table `tfilter' is incompatible, use 'nft' tool.

Wie man sieht, funktioniert es nur dann, wenn der Protokoll-Parameter -p mit dem via -m übergebenen Parameter übereinstimmt.... also wenn der Match-Parameter sich explizit auch auf das Protokoll beziehen soll. Mit anderen Worten, man kann das übergeben, wie du das tust, aus ästhetischen Gründen oder warum auch immer, aber speziell -m mit Bezugnahme aufs gleiche Protokoll ist Quatsch, weils der Netfilter sowieso automatisch tut. Genau zu dem Schluss ist der TE selber gekommen. Was ist daran jetzt nicht verstanden?

Völlig anders siehts natürlich aus, wenn ich mehrere Regeln für den gleichen --sport und keine Protokollangabe habe... dann kann ich natürlich mit -m und erlaubten Matchings differenzieren, um die passende Regeln auszuwählen... in dem Fall darf ich eben nur nicht das Protokoll verwenden... s.o.... aber genau darauf hat sich ja dummerweise die Frage bezogen.

[debianx]

Danke für die spannende Diskussion , ok zB: ein "-p tcp --dport 433" wird intern immer zu einem ""-p tcp -m tcp --dport 433" (sichtbar per "iptables -S")
Insofern ist beides möglich zu schreiben, ohne -m ist es nur kürzer.
Aber das ist dann natürlich die Erklärung, denn intern ist -m also nötig (das war für mich neu) und weil intern sowieso das -m erzeugt wird, schreiben es viele wohl einfach gleich mit ins Skript. Das Skript entspricht dann eher der internen Darstellung daher kann ich das Vorgehen schon nachvollziehen. Fazit dann wohl: beides möglich

Die -p Kombi mit -m ist es tatsächlich oft zu finden daher kam auch erst die Frage auf zB:
https://docs.oracle.com/cd/E26996_01/E1 ... GHECD.html
https://wiki.zimbra.com/wiki/Firewall_Configuration
http://wiki.amule.org/wiki/Firewall
https://blog.slucas.fr/projects/debian/iptables/
https://helpful.knobs-dials.com/index.p ... cket_stuff

[eggy]

haben hier offensichtlich einige nicht verstanden.

@Wanne: Was soll sowas?

Die Manpage ist gut verständlich. Ich bin davon ausgegangen, dass der Fragende diesen Abschnitt einfach nicht gesehen hat. Dass die Infos in mehreren Manpages verstreut sind, ist der Informationsfindung nicht grade zuträglich. Es hätte auch sein können, dass der Fragende seine Infos aus älteren Tutorials bezog, mir wurde vor langer Zeit mal beigebracht, dass man Module explizit laden muss, falls sie nicht bereits beim Boot initialisiert worden sind. Dass der Automatismus (überwiegend) verlässlich funktioniert war nicht immer so.

[wanne]

Funktioniert erwartungsgemäß nicht:

Ja. Weil du in einem tcp Paket nicht nach einem UDP-Port suchen kannst. Macht wenig Sinn.
Ein tcp-Paket hat keinen UDP-Port. Entsprechend widerspricht sich -m udp und -p tcp.
Problematisch wäre wenn iptables mptcp-support haben würde: Dann könntest du sowohl auf den MPTCP-port wie auch auf den fake TCP-Port filtern.
Eine reale Sache ist die Option --set. Die ist sowohl in connlabel wie auch in recent drin und auch die widersprechen sich nicht.

[TomL]

Funktioniert erwartungsgemäß nicht:

Ja. Weil du in einem tcp Paket nicht nach einem UDP-Port suchen kannst. Macht wenig Sinn. Ein tcp-Paket hat keinen UDP-Port. Entsprechend widerspricht sich -m udp und -p tcp.

Ja, das weiss ich doch... ... ich wollte doch bloß einen schwachsinnigen Test dokumentieren, um eine Fehlermeldung zu generieren . Eigentlich wollte ich -nach Deinem Posting- nur eine Erklärung dafür, und zwar ganz speziell, wann man z.B. -m udp benötigt. Deine Ausssage behauptet, ich habs nicht verstanden.... was ich natürlich nicht wiederlegen kann. Also erklärs mir bitte... wann braucht man die ausdrückliche Verwendung von -m udp?

[TomL]

Aber das ist dann natürlich die Erklärung, denn intern ist -m also nötig (das war für mich neu) und weil intern sowieso das -m erzeugt wird, schreiben es viele wohl einfach gleich mit ins Skript.

Nein, diese Aussage ist so nicht richtig. Das bezieht sich nur darauf, wenn ausdrücklich der Protokoll-Typ gematcht wird. Der Parameter "--match" erlaubt aber noch deutlich mehr Prüfungen, wie auf ICMP-Types, Conntrack-States, Limits, TCP-Flags, usw.

Das ist vielleicht hilfreich:
http://manpages.ubuntu.com/manpages/xen ... ons.8.html

[wanne]

Deine Ausssage behauptet, ich habs nicht verstanden....

Nein. Wer man Pages zitiert hat es verstanden, was ein Programm macht. Ich finde aber, dass die Manpage da zwar über details aufklärt aber für einen Außenstehenden nicht so wirklich verständlich erklärt, wozu die Option grundsätzlich gut ist.
Praktisch alle antworten haben (wie du jetzt gefordert hast) irgend welche Edge-Cases beschrieben, wann man -m (nicht) brauch. Für jemand der grundsätzlich nicht verstanden hat um was es geht ist das wenig hilfreich.
Deswegen mein Hinweis, dass einige nicht verstanden haben was -m überhaupt macht.

wann man z.B. -m udp benötigt

Ich habe ultimativ auch ein Besipiel für -m udp gefunden (obwohl der echt eher schwierig ist, weil das wenig mögliche Optionen hat.):
Du willst auf solche Pakete filtern auf Anwendung auf Port xy filtern:
https://tools.ietf.org/html/rfc6951
(Ich hoffe Linux kommt damit zurecht. Habe das nie genutzt.)
Du machst also zuerst einen Filter auf einen sctp-Port (-m sctp --dport xy). Damit würdest du aber auch nicht encapsulatedte Pakete erwichen. Also hängst du hinten Dran ein -p udp und den Port auf den dein sctp-Stack hört. Die Regel würde nicht matchen weil sie zwei Filter auf sctp ports hat. Du brauchst also noch ein -m udp damit du auf den udp-Port filterst.

[TomL]

Ich finde aber, dass die Manpage da zwar über details aufklärt aber für einen Außenstehenden nicht so wirklich verständlich erklärt, wozu die Option grundsätzlich gut ist.

Das betrifft aber sehr sehr viele Man-Pages... ich kann die alle lesen, ich verstehe, was da steht... nur ganz am Ende kann ich es dann oft doch nicht auf eine konkrete praxisbezogene Situation und die mit dem bestimmten Parameter verbundenen Effekte projizieren.

Da liegts dann tatsächlich an der Man-Page. Aber ich weiss selber -nachdem ich mich selber auch an Anleitungen versucht habe- wie wahnsinnig schwer das ist. Deswegen gehe ich meist einen anderen Weg, ich beschreibe zuerst das Problem, eben um genau ein Verständnis für eine bestimmte Situation in der Praxis zu bilden... und erst dann befasse ich mich mit der Lösung. Aber bei dem Vorgehen fehlt natürlich wieder die allgemeine Perspektive, weils eben immer einen konkreten Kontext gibt. Aber ich denke/hoffe, wer's erst mal grundsätzlich kapiert hat, wird die Erkenntnis vielleicht adaptiv auf andere Probleme übertragen können.

Nur ist mir natürlich jetzt klar, dass eine solche Man-Page-Herangehensweise für so ein Mammut-Teil wie beim Paketfilter absolut unmöglich ist. Man muss also mit dem klarkommen, wie es in der Kürze der Man-Page eben vorhanden ist. Ich greife dann meistens auf die Text-Interpretationen anderer Anwender irgendwo im Web zurück... und aus mehreren fremden Interpretationen kann ich dann meistens eine eigene brauchbare entwickeln.

Für jemand der grundsätzlich nicht verstanden hat um was es geht ist das wenig hilfreich.

Wobei ich an diesem speziellen Punkt denke, dass dieses mir fehlende Wissensextrem für mich als Mitglied der unkundigen Masse nicht wirklich bedeutsam ist. Es schadet mir imho nicht, so etwas nicht zu wissen. Ich denke, dass ist allenfalls für Leute mit wirklich hoher IT-Verantwortung relevant, z.B. für Security verantwortliche Leute in RZ's. Ganz ausdrücklich auf die Frage des TE bezogen, finde ich definitiv in meiner kleinen privaten IT-Welt keine Situation, die ich damit lösen könnte. Das hilft also auch nicht beim Verstehen weils für mich nur irgendwas ungreifbares in der Therorie bleibt.

Trotzdem danke für die Hinweise... und ich gestehe, dass das wirklich jenseits meines Horizontes ist.

[debianx]

#-------------------------------
Ich habe noch eine interessante Frage zu Policys in Verbindung mit loopback:
Wenn alle Policys auf DROP definiert werden, nach welchen Regeln verhält sich dann eigentlich lo ?

Mir ist aufgefallen, wenn die Policys komplett DROP stehen, dass es sich dann bei verschiedenen Programmen nicht einheitlich verhält. ZB bei einem Programm wenn: Policys DROP ohne zusätzliche "lo" Erlaubnis funktioniert die Verbindung. Aber bei einem anderen Programm funktioniert es nicht bzw funktioniert es nur wenn "lo" extra akzeptiert wird ("-A INPUT -i lo -j ACCEPT" und "-A INPUT -o lo -j ACCEPT").

Jetzt frage ich mich, wenn das Betriebsystem bei "Policys DROP" ohne extra Zusätze normal funktioniert dann gehe ich davon aus, dass loopback erlaubt ist, ich denke sonst würde das Betriebsystem nicht gehen/hochfahren. Oder liege ich da falsch?
Zum Anderen wundert mich wieso es dennoch unterschiedliches Verhalten gibt, so als wäre bei "Policys DROP" das loopback zwar für das OS erlaubt aber irgendwie für manche Programme wohl nicht.
Kann mir jemand auf die Sprünge helfen oder hat eine Erklärung nach welchen Regeln bei den "Policys DROP" lo zugelassen wird oder eben nicht?
Ich würde bei "Policys DROP" nur gerne wissen wieso bei einem Programm der Zusatz "-A INPUT -i lo -j ACCEPT" und "-A INPUT -o lo -j ACCEPT" zur korrekten Funktion/Verbindung nötig ist und bei einem anderen Programm aber nicht.

LG

[eggy]

Wären die Namen der geheimnisvollen Programme bekannt, könnte man ja mal genauer nachsehn.
Allgemein: es gibt nicht nur die Kommunikation über den Netzwerkstack, viele Programme benutzen Unixsockets als Alternative oder brauchen einfach garkein Netz.

[TomL]

Ich habe noch eine interessante Frage zu Policys in Verbindung mit loopback:
Wenn alle Policys auf DROP definiert werden, nach welchen Regeln verhält sich dann eigentlich lo ?

Der PC wird an vielen Stellen nicht mehr funktionieren... und das hat nicht viel damit zu tun, dass irgendwelche Anwendungsprogramme im User-Space funktionieren oder vielleicht auch nicht. Über das Loop-Device kommuniziert der Rechner mit sich selber. Loop-Devices werden u.a. immer dann verwendet, wenn es *dafür* kein physisches Device gibt, z.B. auch beim Mounten von Blockgeräten, oder Crypt-Containern, oder Image-Files, oder Snaps.... weiß nicht wo noch alles....

Wenn die Policies auf "drop" stehen, muss das Loop-Device unbedingt "accept" werden. Ausdrücklich damit ist imho auch kein Sicherheitsrisiko verbunden... zumindest habe ich davon noch nichts gehört... weil ein Loop-Device ja auch niemals nach draußen lauscht, sondern immer nur Rechnerintern.

Jetzt frage ich mich, wenn das Betriebsystem bei "Policys DROP" ohne extra Zusätze normal funktioniert

Genau das ist eben nicht der Fall... und genau da wird es über kurz oder lang zu Störungen kommen. Wenn es jetzt bei Dir scheinbar funktioniert hat, hast Du lediglich noch nicht die Stelle gefunden, wo es halt nicht funktioniert... und das liegt vermutlich daran, dass diese Stelle in Deinen normal-Benutzungs-Gewohnheiten zufällig (!) einfach noch nicht relevant war.

[debianx]

Ok vielen Dank verstehe jetzt, dann sind die Unixsockets, an die ich gar nicht gedacht hatte, wohl der Grund warum das OS zumindest im Groben trotzdem funktioniert. IPC ist wohl "faster and lighter than IP sockets" (https://serverfault.com/questions/12451 ... -ip-socket) daher wird vermutlich vieles vom OS damit gemacht und es fällt nicht unbedingt direkt auf wenn man "lo" sperrt.

Wenn die Policies auf "drop" stehen, muss das Loop-Device unbedingt "accept" werden. Ausdrücklich damit ist imho auch kein Sicherheitsrisiko verbunden... zumindest habe ich davon noch nichts gehört... weil ein Loop-Device ja auch niemals nach draußen lauscht, sondern immer nur Rechnerintern.

Alles klar, dann werd ich auf "accept" gehen sobald die Policies auf "drop"stehen sonst bekomme ich noch irgendwann eine böse Überraschung