Iptables - Interface ausgeben

Internet Internet Sicherheit
#1

Hi allerseits,

ich will meinen Linux-PC auch als NAT-Router für ein kleines LAN verwenden und möchte dies über iptables realisieren.
Dazu habe ich ein paar Regeln angelegt, die als Kriterium unter anderem auch das Interface (Option ‚-i‘) verwenden, an dem das Paket empfangen wurde.

Wenn ich nun die erstellten Tabellen über

iptables -L

anzeigen lasse, erscheint dieses Kriterium nicht, was etwas verwirrend ist.

Gibt es eine Möglichkeit, dies zu tun? In der manpage habe ich leider nichts dazu gefunden.

Danke und LG
Stuffi

#2

ich will meinen Linux-PC auch als NAT-Router für ein kleines
LAN verwenden und möchte dies über iptables realisieren.
Dazu habe ich ein paar Regeln angelegt, die als Kriterium
unter anderem auch das Interface (Option ‚-i‘) verwenden, an
dem das Paket empfangen wurde.

Wenn ich nun die erstellten Tabellen über

iptables
-L

anzeigen lasse, erscheint dieses Kriterium nicht, was
etwas verwirrend ist.

Wenn du die Regeln nur auf die Standardketten FORWARD, INPUT und OUTPUT anlegst, siehst du in der Tat nicht, für welches Interface die Regel gültig ist. Daher ist es sinnvoll, für alle wesentlichen eigenen Regeln eigene Ketten anzulegen. Dann wird dir das iface zwar auch nicht angezeigt, wenn du den Ketten aber interpretierbare sprechende Namen (eth02ppp0 oder lan2net…) gibst, erkennst anhand des Namens der Kette, auf welches iface die Regel lautet.

So sinnvoll es auch ist, auf der Ebene von iptables einmal eigene Regelwerke anzulegen und so die Grundlagen und Logik verstehen zu lernen, würde ich zumindest für komplexere Aufgaben ein Framework wie z. B. die Shorewall http://www.shorewall.net/ verwenden, wo du mit relativ geringem Aufwand - quasi selbstdokumentierend - ein Regelwerk erstellen kannst, welches dann in die doch etwas aufwändigere Syntax von iptables übersetzt wird.

HTH
Schorsch

#3

Hi allerseits,

Moin,

man iptables

Dort wirst du fündig werden.

Schau mal unter Other Options nach. BTW -n ist auch immer recht hilfreich.

cu polarix

#4

Achtung Falsch

Wenn du die Regeln nur auf die Standardketten FORWARD, INPUT
und OUTPUT anlegst, siehst du in der Tat nicht, für welches
Interface die Regel gültig ist. Daher ist es sinnvoll, für
alle wesentlichen eigenen Regeln eigene Ketten anzulegen. Dann
wird dir das iface zwar auch nicht angezeigt, wenn du den
Ketten aber interpretierbare sprechende Namen (eth02ppp0 oder
lan2net…) gibst, erkennst anhand des Namens der Kette, auf
welches iface die Regel lautet.

Diese Aussage ist Falsch.

So sinnvoll es auch ist, auf der Ebene von iptables einmal
eigene Regelwerke anzulegen und so die Grundlagen und Logik
verstehen zu lernen, würde ich zumindest für komplexere
Aufgaben ein Framework wie z. B. die Shorewall
http://www.shorewall.net/ verwenden, wo du mit relativ
geringem Aufwand - quasi selbstdokumentierend - ein Regelwerk
erstellen kannst, welches dann in die doch etwas aufwändigere
Syntax von iptables übersetzt wird.

Hmmm…
Zusammen gefasst verstehe ich dich so.
Du verwendest shorewall o.ä. bei komplexen Dingen, da iptables eine aufwändigere sprich komplexere Syntax hat.

  • iptables ist komplex, da es komplexe Dinge ermöglicht.

  • Komplexes so zu abstrahieren das es einfach ist, keine Einschränkungen hat und funktioniert ist IMHO fast unmöglich.

Meistens haben solche Lösungen Einschränkungen.
Wenn einem die Einschränkungen nicht stören und man es einfacher haben möchte, ist es durch aus adäquat solch eine Lösung zu wählen.

Ich könnte jetzt hier stunden Pros und Contras aufführen.
Das würde aber dem Rahmen sprengen…

cu

polarix

–
„Wenn etwas einfach ist und funktioniert dann ist es nicht einfach.“ Die Pragmatischen Programmierer

#5

Achtung Falsch

Wenn du die Regeln nur auf die Standardketten FORWARD, INPUT
und OUTPUT anlegst, siehst du in der Tat nicht, für welches
Interface die Regel gültig ist. Daher ist es sinnvoll, für
alle wesentlichen eigenen Regeln eigene Ketten anzulegen. Dann
wird dir das iface zwar auch nicht angezeigt, wenn du den
Ketten aber interpretierbare sprechende Namen (eth02ppp0 oder
lan2net…) gibst, erkennst anhand des Namens der Kette, auf
welches iface die Regel lautet.

Diese Aussage ist Falsch.

Welcher Teil bzw. welche der Aussagen?

  • Komplexes so zu abstrahieren das es einfach ist, keine
    Einschränkungen hat und funktioniert ist IMHO fast unmöglich.

Nun, du könntest mittels iptables z. B. eine Regel schreiben die ein OUTPUT im Status NEW, ESTABLISHED erlaubt, ein INPUT im Status ESTABLISHED aber verbietet. Das geht m. W. mit der shorewall native, ohne wieder auf iptables zurückzugreifen, nicht.

Eine sinnvolle und notwendige Regel aber, die mit iptables möglich, mit der shorewall jedoch nicht möglich wäre, fällt mir so auf Anhieb nicht ein.

So viel „einfacher“ ist die shorewall übrigens nicht, die shorewall-Konfigurationsdateien sind zunächst nur wesentlich übersichtlicher und ermöglichen so u. a. ein weitaus besseres Qualitätsmanagement.

Du kannst auch mit C++ die gleichen Konstrukte komnpilieren wie mit C und in C kannst du auch Assemblercode einfliessen lassen. Ist C++ deswegen abzulehnen, weil der C+±Programmierer sich mit Assembler nicht befassen will? Ich denke nicht, auch wenn der Assembler-Code möglicherweise erheblich performanter ist.

Gruss
Schorsch

#6

Diese Aussage ist Falsch.

Welcher Teil bzw. welche der Aussagen?

Wenn es nur ein Teil gewesen wäre, hätte ich das erwähnt. In diesem Fall meinte ich alles.

  • Komplexes so zu abstrahieren das es einfach ist, keine
    Einschränkungen hat und funktioniert ist IMHO fast unmöglich.

Eine sinnvolle und notwendige Regel aber, die mit iptables
möglich, mit der shorewall jedoch nicht möglich wäre, fällt
mir so auf Anhieb nicht ein.

So viel „einfacher“ ist die shorewall übrigens nicht, die
shorewall-Konfigurationsdateien sind zunächst nur wesentlich
übersichtlicher und ermöglichen so u. a. ein weitaus besseres
Qualitätsmanagement.

Ich habe mich noch nie mit shorewall auseinander gesetzt.
Deswegen kann ich zu shorewall im speziellen nichts sagen.

Ich habe jedoch die Erfahrung gemacht, das solche Tools meistens Einschränkungen beinhalten. Anyway die aus deiner Sicht bessere Übersicht ist ja ein Argument die Software zu nutzen. Ich gab nur zu bedenken das es auch andere Sichtweisen geben kann.

Du kannst auch mit C++ die gleichen Konstrukte komnpilieren
wie mit C und in C kannst du auch Assemblercode einfliessen
lassen. Ist C++ deswegen abzulehnen, weil der
C+±Programmierer sich mit Assembler nicht befassen will? Ich
denke nicht, auch wenn der Assembler-Code möglicherweise
erheblich performanter ist.

Jeder Vergleich hinkt, dieser passt aber meiner Meinung nach überhaupt nicht.

Aber es geht mir gar nicht darum eine Diskussion über dieses Thema anzufangen. Es würde letztendlich in einer Endlos Schleife enden.

bis dann

polarix

Gruss
Schorsch

#7

Diese Aussage ist Falsch.

Welcher Teil bzw. welche der Aussagen?

Wenn es nur ein Teil gewesen wäre, hätte ich das erwähnt. In
diesem Fall meinte ich alles.

Man lernt ja gern, aber wenn auf die Frage, was man denn falsch gemacht habe, vom Lehrer nur die Antwort komnmt, man habe es eben nicht richtig gemacht, ist dies wenig hilfreich.

Man iptables (um nur auf eine meiner drei von dir bemängelten Aussagen einzugehen) zumindest hat mir genauso viel gebracht, wie Stuffi (habe aber auch nicht so intensiv gelesen). Auch mit den Parametern -nv bekomme ich nicht angezeigt, für welches Interface eine Regel gilt.

Gruss
Schorsch

#8

[iptables] Auch mit den Parametern -nv bekomme ich nicht
angezeigt, für welches Interface eine Regel gilt.

Dann verwendest Du ein anderes iptables als ich. Du solltest es ersetzen. Im Zweifelsfall liefert iptables-save den _vollstaendigen_ Regelsatz, da sich mit dem ja alle Regeln auch wieder herstellen lassen. Und da gibt es dann auch Interfaces.

Gruss vom Frank.

#9

Nun, du könntest mittels iptables z. B. eine Regel schreiben
die ein OUTPUT im Status NEW, ESTABLISHED erlaubt, ein INPUT
im Status ESTABLISHED aber verbietet.

Ich weiss ja nicht, was an diesen zwei Regeln jetzt so verwerflich sein soll… voellig unabhaengig davon: hat shorewall einen ‚suicide mode‘, der solche Regeln dann wenigstens doch erlaubt? Ich mag so ungern bevormundet werden. (Man merkt es vielleicht, ich habe mir shorwall immer noch nicht angesehen. Mea culpa.)

Gruss vom Frank.

#10

Nun, du könntest mittels iptables z. B. eine Regel schreiben

Ich weiss ja nicht, was an diesen zwei Regeln jetzt so
verwerflich sein soll…

Verwerflich ist da da grad garnichts. Aber das ist das schöne am Dadaismus, er verwirrt so nett.

shorewall einen ‚suicide mode‘, der solche Regeln dann
wenigstens doch erlaubt? Ich mag so ungern bevormundet
werden. (Man merkt es vielleicht, ich habe mir shorwall immer
noch nicht angesehen. Mea culpa.)

Shorewall hat den ‚Schuss ins eigene Knie‘-Mode. Den Suizid-Modus kann ich nicht versprechen, ich denke dass es ihn gibt; hätte ich ihn bislang je gebraucht könnte ich deine Frage aus irgendwelchen Gründen nicht mehr beantworten.

Tora Tora Tora
Schorsch

#11

Im Zweifelsfall liefert iptables-save den
_vollstaendigen_ Regelsatz, da sich mit dem ja alle Regeln
auch wieder herstellen lassen. Und da gibt es dann auch
Interfaces.

Ich habe gerade keinen Rechner ohne Shorewall zur Hand, wenn du recht hast, greift die Shorewall wesentlich tiefer ins System ein, als mir recht ist. Ich sehe kein Interface, nur die von mir benannten Ketten (willkürlicher Ausschnitt):

-A net2fw -s 192.168.0.99 -p tcp -m tcp --dport 22 -j ACCEPT
-A net2fw -s 192.168.0.1 -p udp -m udp --dport 123 -j LOG --log-prefix "Shorewall:net2fw:ACCEPT:" --log-level 6
-A net2fw -s 192.168.0.1 -p udp -m udp --dport 123 -j ACCEPT

Könntest du mir ein Gegenbeispiel zur Verfügung stellen?

Gruss
Schorsch

#12

Ich habe gerade keinen Rechner ohne Shorewall zur Hand,

Und ich keinen mit.

wenn du recht hast, greift die Shorewall wesentlich tiefer ins
System ein, als mir recht ist.

Das kann es gar nicht: dazu muesste es Kernel-Module mitbringen. Tut es das?

Ich sehe kein Interface, nur die von mir benannten Ketten:

> -A net2fw -s 192.168.0.99 -p tcp -m tcp --dport 22 -j ACCEPT  
> -A net2fw -s 192.168.0.1 -p udp -m udp --dport 123 -j LOG --log-prefix "Shorewall:net2fw:ACCEPT:" --log-level 6  
> -A net2fw -s 192.168.0.1 -p udp -m udp --dport 123 -j ACCEPT

Entweder unterscheidet er ‚drinnen‘ und ‚draussen‘ nur anhand der IP# (was ziemlich bloed und ein echter Grund _gegen_ shorewall waere) oder er macht das woanders: dort wo er nach net2fw springt. Pack doch die Ausgabe eines iptables-save mal bitte in eine Mail an mich (falls es nicht gegen die Security-Policy verstoesst).

Könntest du mir ein Gegenbeispiel zur Verfügung stellen?

In Massen:

hydra:~# iptables -nvL INPUT |grep eth
 1964 118K ACCEPT tcp -- eth0 \* 192.168.0.0/24 192.168.0.7 tcp spts:1024:65535 dpt:8080 state NEW 
 9 3048 ACCEPT udp -- eth2 \* 10.0.0.0/24 10.0.0.7 state NEW udp spts:1024:65535 dpt:5000 
 3 360 ACCEPT udp -- eth2 \* 10.0.0.0/24 10.0.0.7 state NEW udp spts:1024:65535 dpt:4999 
 3 156 ACCEPT tcp -- eth2 \* 10.0.0.0/24 10.0.0.7 tcp spts:1024:65535 dpt:22 state NEW 
 0 0 ACCEPT tcp -- eth2 \* 10.0.0.0/24 10.0.0.7 tcp spts:1024:65535 dpt:500 state NEW 
 0 0 ACCEPT udp -- eth2 \* 10.0.0.0/24 10.0.0.7 state NEW udp spt:500 dpt:500 
 4 204 ACCEPT tcp -- eth2 \* 10.0.0.0/24 10.0.0.7 tcp spts:1024:65535 dpt:5001 state NEW 
 0 0 ACCEPT esp -- eth2 \* 0.0.0.0/0 0.0.0.0/0 
 0 0 ACCEPT ah -- eth2 \* 0.0.0.0/0 0.0.0.0/0 
 4148 249K ACCEPT tcp -- eth1 \* 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:22 state NEW 
 3303 466K ACCEPT all -- eth0 \* 0.0.0.0/0 0.0.0.0/0 state NEW 
 8478 1118K LOG all -- eth2 \* 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
hydra:~#

Gruss vom Frank.

#13

net2fw springt. Pack doch die Ausgabe eines iptables-save mal
bitte in eine Mail an mich (falls es nicht gegen die
Security-Policy verstoesst).

Jetzt hast du gelitten. Konntest du vorher noch hoffen, dass meine strengen Security by obscurity-Policies es mir verbieten, derartige Daten rauszuschicken, habe ich mittlerweile auf meinen privaten PC gewechselt, auf dem die Shorewall nicht mehr als ein Spielzeug im Wechsel der Gezeiten ist.

Aber als ich die Mail zusammengestellt habe, habe ich gesehen, dass die Ausgabe von iptables-save doch mehr beinhaltet, als in der History der Shell zunächst zu sehen war.

Scheinen Querbezüge drin zu sein, muss ich mich mal durchkämpfen.

Gruss
Schorsch

#14

Hallo,

Man lernt ja gern, aber wenn auf die Frage, was man denn
falsch gemacht habe, vom Lehrer nur die Antwort komnmt, man
habe es eben nicht richtig gemacht, ist dies wenig hilfreich.

Hmmm…
Du weißt doch was du geschrieben hast und ich schrieb das es falsch wäre.

Aussage: Wenn du die Regeln nur auf die Standardketten FORWARD, INPUT und OUTPUT anlegst, siehst du in der Tat nicht, für welches Interface die Regel gültig ist

Diese Aussage stimmt nicht, weil man sich das Interface mit aussgeben lassen kann. Siehe dazu man iptables. Wenn du dann noch verständnis fragen hast. Kannst du mich gerne Fragen.

Aussage: Daher ist es sinnvoll, für alle wesentlichen eigenen Regeln eigene Ketten anzulegen.

Diese Aussage stimmt nicht im besagten Kontext.

Aussage: Dann wird dir das iface zwar auch nicht angezeig

Diese Aussage stimmt nicht, siehe deine erste Aussage.

Aussaage: wenn du den Ketten aber interpretierbare sprechende Namen (eth02ppp0 oder lan2net…) gibst, erkennst anhand des Namens der Kette, auf welches iface die Regel lautet.

Diese Aussagte stimmt zwar. Aber sie ist unnötig, da sie ein workaround für die anderen (falsch) Aussagen ist.

Natürlich kann ich das so auseinander nehmen. Letztendlich ist es aber unnötige Wiederholung.

Man iptables (um nur auf eine meiner drei von dir bemängelten
Aussagen einzugehen) zumindest hat mir genauso viel gebracht,

Wo genau war dein Verständnis Problem ?

wie Stuffi (habe aber auch nicht so intensiv gelesen). Auch
mit den Parametern -nv bekomme ich nicht angezeigt, für
welches Interface eine Regel gilt.

Hmmm…

ich schon. Wenn du natürlich dein oben beschriebenes vorgehen wählts und dann in den subchains nachschauts wirst du die Interfaces nicht angezeigt bekommen. Wenn doch solltest du dein Regel Design überdenken.

Bis dann

polarix