iptables Anfänger Fragen

[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