Iptables - Grundsätzliche Eigenschaften???

[TomL]

Moin@all

Nachdem ich zuerst geglaubt habe, dass Wanne's Vorschlag perfekt läuft, habe ich nun bei genauerem Hinsehen festgestellt, dass es leider doch nicht mit meinen Anpassungen läuft. Aber irgendwie ist mir das Verhalten nicht verständlich und nicht nachvollziehbar. Vielleicht kann mir das jemand erklären.

Primär gehts um diesen am Anfang meiner Regeln stehenden Block, welcher letztendlich zur Folge hat, dass das System völlig "abgeschlossen" ist:

Code: Alles auswählen

 /sbin/iptables -P INPUT DROP
 /sbin/iptables -P OUTPUT DROP
 /sbin/iptables -P FORWARD DROP

Das heisst, KEINE einzige meiner im Script danach folgenden ACCEPT-Regeln findet Anwendung oder hat eine Auswirkung, obwohl beim Drüberschauen mit "iptables -L -nv" wirklich alles gut und fehlerfrei aussieht und genau so dargestellt wird, wie ich das eingetragen habe. Aber meine ACCEPTS werden schlichtweg überhaupt nicht gematch't. Kommentiere ich jedoch diesen Block, geht alles... oder mit anderen Worten, es ist gar nichts geblockt, wirklich alles ist offen.

Wenn ich die Man-Page richtig verstanden habe, werden die vorhandenen Regeln nacheinander in der Reihenfolge ihres "Setzens" abgearbeitet und sofern am Ende keine explizite Regel gematch't wurde, greifen die mit -P gesetzen Standard- oder Default-Regeln. Und jetzt kommt das, was ich nicht nachvollziehen kann:
Wenn ich diesen Block ans Ende setze, also HINTER meine ACCEPTS, dann funktionert es korrekt. Und weil diese faktische Feststellung im Widerspruch zu Wannes Vorschlag steht, denke ich mir... lieber mal nachfragen.

Ich teste meine Regeln mit folgenden Befehlen:

Code: Alles auswählen

echo quit | timeout 3 openssl s_client -connect smtp.strato.de:587 -starttls smtp | grep depth;\
echo quit | timeout 3 openssl s_client -connect smtp.gmail.com:587 -starttls smtp | grep depth;\
echo quit | timeout 3 openssl s_client -connect mail.gmx.net:587 -starttls smtp | grep depth

wget -c http://212.117.163.148/jd.sh;\
wget -c "http://download.osmand.net/download.php?standard=yes&file=Germany_bremen_europe_2.obf.zip"

echo -e "Subject: Test Mail\r\n\r\nTest-Mail vom:  $(date)" | msmtp --debug -t toml@xxx.de --file=/home/thomas/.msmtprc --account=tls --timeout=5

echo -e "Subject: Test Mail\r\n\r\nTest-Mail vom:  $(date)" | msmtp --debug -t toml@xxx.de --file=/home/thomas/.msmtprc --account=gmx --timeout=5

wobei immer nur 1 Ziel erlaubt ist, die anderen müssen fehlschlagen.

Ist das wirkich so richtig, dass auch die Position der -P Regeln von Bedeutung sind? Auf meinem Test-Raspberry PI ist das anscheinend so. Es wird tatsächlich unterschiedlich behandelt, wenn dieser Block am Anfang oder am Ende steht, obwohl beide Ausgaben mit -L -nv absolut identisch sind. Aber wenn das so ist, wofür benötigt man denn dann überhaupt dieses Paket mit den P-Regeln...?... weil diese folgende Alternative am Ende meiner ACCEPT-Regeln das gleiche macht. Aber hier als reguläre Regel, die nachvollziehbar genau an der Stelle match't, wo sie positioniert ist:

Code: Alles auswählen

/sbin/iptables -A INPUT -j REJECT --reject-with icmp-net-unreachable  
/sbin/iptables -A OUTPUT -j REJECT --reject-with icmp-net-unreachable 
/sbin/iptables -A FORWARD -j REJECT --reject-with icmp-net-unreachable

Wäre diese Alternative dann nicht sogar die bessere Lösung?

Was ist das richtige Verhalten der iptables und was kann man beim Formulieren seiner eigenen Regeln als gegeben voraussetzen? Ich sag schon mal Danke für ein bisschen Unterstützung.

[DeletedUserReAsG]

-P ist die Policy. Die kommt zum Tragen, wenn keine der für die Kette vorhandenen Regeln zu dem betreffenden Paket gepasst hat. Wenn du also DROP da stehen hast, und ein durchlaufendes Paket wird von keiner der für die Kette mit -A oder -I angelegten Regeln abgedeckt, wird das Paket verworfen werden. An welcher Stelle du die Policy in deinem Script festlegst, ist hingegen egal. Sie steht letztlich immer am Ende deiner Kette. Es gibt da im Netz hübsche Diagramme, wie iptables funktioniert. Einfach mal anschauen ….

[TomL]

Exakt das, was Du erklärst, hatte ich genau so als Voraussetzung verstanden. Und genau mit diesem Gedanken habe ich gestern abend ein paar Stunden versucht zu verstehen, warum meine Regeln nicht funktionieren, und heute nachmittag wieder, mehrere Stunden. Und das ist das, was ich nicht begreife: werden diese 3 Zeilen am Ende ausgeführt, nach meinen ACCEPTS, funktioniert alles wie es soll. Was verboten sein soll, ist verboten, was erlaubt sein soll, ist auch erlaubt.

Packe ich diese 3 genannten Zeilen jedoch an den Anfang des Script, wo sie meiner Meinung nach aus ästhetisch-logischer Sicht eigentlich hingehören, weil es ja die "Defaults" sind, funktioniert gar nix. Es funktioniert dann noch nicht mal mehr die Namensauflösung dieser zwei Zeilen, die ich von Wanne adaptiert habe und die nach den 3 default-DROPs eigentlich die ersten beiden meiner ACCEPT-Regeln sind:

Code: Alles auswählen

 /sbin/iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW -d mirrordirector.raspbian.org -j ACCEPT
 /sbin/iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW -d archive.raspberrypi.org -j ACCEPT

Ich kriege sofort ne Fehlermeldung wie "Netz nicht gefunden oder Name kann nicht aufgelöst werden".... irgendwie so ähnlich.... kann mich nicht genau daran erinnern.

Kopiere ich die 3 Zeilen nach unten, ans Ende, funktionieren die 'erlaubten' wieder... der DROP-Byte-Counter wird bei den 'verbotenen' hochgezählt. Möglicherweise habe ich hier ein spezielles RPi-Problem gefunden, was vielleicht nicht dem Soll-Verhalten der iptables entspricht. Deswegen ja hier mal meine Problemschilderung.

[DeletedUserReAsG]

Dann würde ich mir mal die Regeln nach dem Anwenden des jeweiligen Scriptes ausgeben lassen und vergleichen.

[TomL]

Hatte ich schon oben im ersten Posting beschrieben:

... obwohl beide Ausgaben mit -L -nv absolut identisch sind.

Ich habe meiner Meinung nach wirklich alles abgesucht und untersucht und mich sogar noch mal durch die ManPages gewühlt. Und auch die haben bestätigt, was Du erklärt hast. Und dennoch habe ich reproduzierbar diesen Effekt. Kopiere ich es hoch, geht nix, kopiere ich es ans Ende, funktioniert es wie gewünscht.

Ich vermute fast, dass man das nur ergründen kann, wenn man sich duchs Programm steppt, aber das wäre mir zuviel... oder einfach die Kröte schlucken und nicht weiter drauf rumkauen. "Am Ende" positioniert geht ja alle wie gewollt.

[DeletedUserReAsG]

Dann würde ich mir die Regeln mal mit z.B. iptables-save ausgeben lassen und vergleichen.

[TomL]

Ich habs jetzt gerade noch mal ausdrücklich verglichen. Wenn die -P-DROPS am Anfang stehen, kriege ich diese Meldung:

Code: Alles auswählen

set-iptables
iptables v1.4.21: host/network `mirrordirector.raspbian.org' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `archive.raspberrypi.org' not found
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.21: host/network `smtp.strato.de' not found
Try `iptables -h' or 'iptables --help' for more information.
Chain INPUT (policy DROP 0 packets, 0 bytes)

Alle anderen meiner gesetzten ACCEPTs sind identisch, lediglich die obigen über DNS kommenden fehlen. Packe ich die Default-DROPS ans Ende, habe ich keine Fehlermeldungen und die Outgoing-ACCEPTs sind um die IPs ergänzt.... also ist alles gut.
Wenn ich nun meine Test-Commands (s.o.) absende, geht z.B. das Strato-Postfach, GMAIL und GMX geht nicht... genau so soll es sein. Aber es ist abhängig davon, wo diese Default-DROPS stehen.... es klappt eben nur, wenn sie am Ende stehen.

iptables-save kannte ich noch nicht. Das probiere ich morgen und berichte anschließend.

[DeletedUserReAsG]

Sieht so aus, als würden die Policies gesetzt, bevor es selbst die Namen auflösen kann. Insofern erscheint mir das Verhalten logisch – ich würde in dem Fall dafür sorgen, dass DNS-Abfragen nicht geblockt werden, das würde sonst früher oder später sowieso zu Problemen führen – auch wenn die Policies am Ende des Scriptes gesetzt werden.

[TomL]

Oh mann... ... wer soll denn darauf kommen...?... na klar, das ist es... das muss es sein. Es ist ja nicht so, dass erstmal alle Regeln geschrieben werden und dann am Ende "gestartet" werden, sondern jede Regel ist in dem Moment aktiv, wenn sie gesetzt ist. Jetzt ergibt dieses Verhalten auch einen Sinn. Und jetzt kann ich damit umgehen. Das werde ich morgen bestätigen... da bin ich mir jetzt sicher. Genau so sicher wie ich mir bin, das ich niemals selber darauf gekommen wäre.

Danke!

[letzter3]

TomL,
ich mag die Art, wie du Probleme angehst und hier im Forum postest.
Weiter so! Es gibt genug andere negative Beispiele!

[BenutzerGa4gooPh]

Mojn Thomas, du könntest doch auch temporaer - nur zum schnelleren Verständnis - eine "Erklaerbaer-GUI" (Frontend) für iptables/netfilter installieren und die rohen Ergebnisse damit vergleichen.
https://wiki.archlinux.org/index.php/firewalls
http://mobile.serverwatch.com/server-tu ... linux.html
Schönen Sonntag dir und allen Lesern!

[TomL]

Moin @ all

Thomas du könntest doch auch temporaer - nur zum schnelleren Verständnis - eine "Erklaerbaer-GUI" für iptables/netfilter installieren und die rohen Ergebnisse damit vergleichen. shorewall und ufw fallen mir so ein, gibt sicher noch mehr. Das sind doch nur Oberflächen für netfilter, keine eigenständigen Desktop-FWs.

Ja, das wäre sicher auch ne Möglichkeit. Aber ich bin da so ein bisschen wie Guennid ... ... mir reicht es nicht, dass es läuft, ich will auch wissen, warum es läuft. Und ich will zumindest glauben dürfen, dass ich die Kontrolle habe. Also ist es eher mein Ding Man-Pages mühsam zu lesen, Web-Suche und -sofern möglich- eigene Kontrollmechanismen zum Gegenprüfen finden/entwickeln. Und Dank 'niemands' Hilfe konnte ich es heute morgen lösen. Und tatsächlich, es war der DNS-Lookup. Herrschaftszeiten .... da wär ich nie drauf gekommen... so logisch und folgerichtig das jetzt im Nachhinein betrachtet auch ist.

Mein Script hat jetzt diesen Initial-Teil, und damit funktioniert es so wie beabsichtigt:

Code: Alles auswählen

modprobe ip_conntrack

/sbin/iptables -P INPUT DROP                                                                
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP

/sbin/iptables -A INPUT -i lo -j ACCEPT                                                     
/sbin/iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP                                      

/sbin/iptables -A INPUT -m conntrack --ctstate INVALID -j DROP                              

/sbin/iptables -A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
/sbin/iptables -A OUTPUT -p tcp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT  -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT  -p tcp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT 

Die Lösung war letztendlich ganz einfach, und zwar einfach nur den DNS-Lookup über Port 53 zu erlauben. Mein Script gibt direkt nach dem Setzen der Regeln mit

Code: Alles auswählen

iptables -L -nv

die aktiven Regeln aus. Hier ein Auszug, an dem ersichtlich ist, dass das allererste, was festgestellt wird (jeweils 3 Pakete), der DNS-Lookup ist:

Code: Alles auswählen

# set-iptables
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   347 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53 ctstate ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:53 ctstate ESTABLISHED

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   202 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 ctstate NEW,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 ctstate NEW,ESTABLISHED

@niemand

[TomL]

Moin @ all

Gestern abend ist mir auf einmal ein 'Folgeproblem' in den Sinn gekommen.... angestoßen durch einen anderen Umstand. Im Moment habe ich zwar mit dem Dual-Stack auch IPv6, aber dennoch trennt mich der ISP immer noch einmal täglich. Und da ich durch viel Lesen mittlerweile zum dem Schluss gekommen bin, dass in meinem kleinen Netz ULA's mehr schaden als nutzen, habe ich die ULA's aus dem RA rausgenommen - und somit werden sie gar nicht erst generiert.

Bewusst geworden ist mir das Problem mit dem von Wanne erwähnten "Holepunching". Auch wenn das möglicherweise momentan eine eher mehr theoretische als praktische Gefährdung bedeutet, hätte mich das Wissen darum gestört. Wenn da 'ne Tür ist, will ich sie nicht auch noch offen haben. Und ich denke, dass ich 2 Netze auf den gleichen Maschinen eigentlich nicht mehr kontrollieren kann.... irgendwo ist immer irgendwas geöffnet.

Nun ist das Problem ganz einfach... wenn ich beispielsweise das Drucken via Cups/631 nur aus dem LAN erlauben möchte, so benötigt die entsprechende iptables-Regel als match die Angabe des lokalen Netzes... resp. und in meinem Fall also den ISP-Prefix/64 für die GUA's. Das Problem dabei ist, der ISP-Prefix und somit die Site-ID ändert sich momentan wg. der Zwangstrennung noch täglich....was bedeutet, dass ich auch täglich die iptables-regeln anpassen muss, damit das klappt. Als Hinweis am Rande... hier gehts jetzt nur um meinen Server, den ich wg. IPv6 etwas mehr wasserdicht machen möchte.

Die Lösung wäre für mich jetzt täglich (mit irgendeinem Zyklus) via Cron-Job den IPS-Prefix zu ermittlen, mit dem vorherigen zu vergleichen und dann ggf. die betroffenen Regeln zu flushen und neu zu setzen:

Code: Alles auswählen

gua_ip=$(ip -f inet6 -o addr show eth0 | grep mngtmpaddr | grep -v deprecated | awk -F 'inet6 ' '{ print $2 }' | cut -d' ' -f1)
isp_prefix=$(echo $gua_ip | cut -d':' -f1-4)

Und bei diesen Überlegungen ist mir in den Sinn gekommen, dass die zwei folgenden Regeln vom Anfang dieses Threads eigentlich ja auch nur statisch sind.

Code: Alles auswählen

/sbin/iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW -d mirrordirector.raspbian.org -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW -d archive.raspberrypi.org -j ACCEPT

Beim Erstellen der Regel wird zwar der Hostname verwendet, aber in der Regel selber steht dann die IP drin. Das heisst, würde sich da mal was ändern, würde ich das gar nicht mitkriegen. Bedeutet das nicht aber, dass ich diese 2 Regeln auch mindestens einmal am Tag löschen und neu generieren muss, damit sie immer aktuell sind?