iptables-Regeln

[mat6937]

Gehen wir mal davon aus, Du meinst den Resolver, welcher hier mal via UDP beim DNS-Server anfragt.
2. hier ist dann der Fehler: Bei UDP ist nichts etabliert. UDP ist ein sogenanntes "verbindungsloses Protokoll".

Ja es ist richtig, dass UDP (im Verglich zu TCP) ein "verbindungsloses Protokoll" ist. D. h. aber nicht, dass iptables nicht den Zustand einer UDP-Verbindung erkennen kann. Z. B.:

Code: Alles auswählen

iptables -I INPUT 1 -i eth0 -p udp --sport 53 -m state --state ESTABLISHED -j DROP

Code: Alles auswählen

:~# host heise.de 4.2.2.1
;; connection timed out; no servers could be reached

danach:

Code: Alles auswählen

iptables -D INPUT 1

Code: Alles auswählen

:~# host heise.de 4.2.2.1
Using domain server:
Name: 4.2.2.1
Address: 4.2.2.1#53
Aliases: 
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de.

[mat6937]

Also wenn in der INPUT-chain kein RELATED-/ESTABLISHED grundsätzlich erlaubt ist, wird dieser Traffic - auch wenn das keine eingehende Verbindung ist - von iptables herausgefiltert - spricht: Es wird diesem Rück-Traffic nicht erlaubt das Ziel (Dienst/Programm auf dem RasPi) zu erreichen.
Hab ich das jetzt richtig verstanden?

BTW: Wenn es um die INPUT chain (auch Rück-Traffic) geht, ist es immer eine _eingehende_ Verbindung.

[eggy]

Zu 1.: Naja egal ob ich ein nslookup mache, oder z.B. apt den/die Debian-Server anfragt.

Ja und Nein. So einfach ist das nicht.
Es gibt mehrere Arten Namensauflösung zu machen, eine davon ist ne DNS Anfrage. Und wie die gemacht wird, gibt unterschiedliche Methoden. Ohne Dich jetzt mit Details zuwerfen zu wollen, entweder man greift auf nen externes Programm/Bibliothek (unspezifisch als "Resolver" bezeichnet) zurück oder macht die Anfrage im Programm selbst. Dann gibt's Unterschiede darin, welche Anfrage (Query) gestellt wird, und dann gibt's noch unterschiedliche Arten, wie man die Anfrage stellen kann, rekursiv/iterativ z.B., von Spezialzeug wie DNSSec mal ganz abgesehn. Bestimmte Queries (bzw deren Länge) bedeuten einfach, dass TCP sinnvoller ist, historisch war es UDP, heute je nach Anwendungsfalls und/oder System mal so mal so. Und um die Verwirrung zu perfektionieren gibts auch noch die nsswitch.conf.

Zu 2.: Stimmt, aber auch der Traffic wird doch in der default-Policy berücksichtigt, oder?

Für iptables ohne Erweitung gibt es nicht "den Traffic". Es gibt Pakete. Einzelne. Erstmal alles ohne Logik.
Das was-gehört-wozu kommt erst später (unter anderem durch die connection tracking Module).
Iptables arbeitet sein Regelwerk von oben nach unten ab, grundsätzlich gilt erstmal "erster Treffer zählt".
Wenn irgendwo beim Abarbeiten des Regelwerks nen "-j ACCEPT" kommt, darf das Paket passieren, kommt nen "-j DROP" eben nicht. Und die Policy sagt nur "was mach ich mit den Paketen, wenn ich unten angekommen bin und für die ich bis dahin noch nichts entschieden habe".

Zu 3. & nachfolgendem Text: Ich denke jetzt kommen wir der Sache etwas näher ^^ ...

Also, so wie ich das jetzt verstehe, läuft das so ab:
1. Ein Programm/Dienst macht eine ausgehende Verbindung ins Internet auf (z.B. DNS) - jetzt steht eine Leitung.

Nö. Unterschied TCP/UDP lies Dich da mal ein.

Auf dieser Leitung werden die angefragten Daten auf der selben Leitung zum betr. Dienst/Programm "rücktransportiert", ABER auch auf diesem "Rücktransport" greift die INPUT-chain ... richtig?

Nein, loopback (127.x.x.x) hat ne besondere Bedeutung und ist nicht das Lan lokale Interface. Dein Rechner hat noch ne weiteres "Netzwerkinterface" zumindest in der Logik der Paketvermittlung und damit bei iptables, das Rechner lokale, Pakete die der Rechner nur an sich selbst sendet, ohne dass sie physikalisch auf die Kabel kommen. Der Unterschied spielt ne wichtig Rolle. Und Dein Script erweckt den Eindruck, dass Dir der Unterschied noch nicht bewusst ist. Deswegen: Lokale IP (192.168.x.x zB ) ist nicht loopback (127.x.x.x)!
Lies nochmal dazu nochmal nach.

[worker777]

Also wenn in der INPUT-chain kein RELATED-/ESTABLISHED grundsätzlich erlaubt ist, wird dieser Traffic - auch wenn das keine eingehende Verbindung ist - von iptables herausgefiltert - spricht: Es wird diesem Rück-Traffic nicht erlaubt das Ziel (Dienst/Programm auf dem RasPi) zu erreichen.
Hab ich das jetzt richtig verstanden?

BTW: Wenn es um die INPUT chain (auch Rück-Traffic) geht, ist es immer eine _eingehende_ Verbindung.

Alles klar, danke

[worker777]

Zu 1.: Naja egal ob ich ein nslookup mache, oder z.B. apt den/die Debian-Server anfragt.

Ja und Nein. So einfach ist das nicht.
Es gibt mehrere Arten Namensauflösung zu machen, eine davon ist ne DNS Anfrage. Und wie die gemacht wird, gibt unterschiedliche Methoden. Ohne Dich jetzt mit Details zuwerfen zu wollen, entweder man greift auf nen externes Programm/Bibliothek (unspezifisch als "Resolver" bezeichnet) zurück oder macht die Anfrage im Programm selbst. Dann gibt's Unterschiede darin, welche Anfrage (Query) gestellt wird, und dann gibt's noch unterschiedliche Arten, wie man die Anfrage stellen kann, rekursiv/iterativ z.B., von Spezialzeug wie DNSSec mal ganz abgesehn. Bestimmte Queries (bzw deren Länge) bedeuten einfach, dass TCP sinnvoller ist, historisch war es UDP, heute je nach Anwendungsfalls und/oder System mal so mal so. Und um die Verwirrung zu perfektionieren gibts auch noch die nsswitch.conf.

Ja, die Verwirrung ist komplett ...

Zu 2.: Stimmt, aber auch der Traffic wird doch in der default-Policy berücksichtigt, oder?

Für iptables ohne Erweitung gibt es nicht "den Traffic". Es gibt Pakete. Einzelne. Erstmal alles ohne Logik.
Das was-gehört-wozu kommt erst später (unter anderem durch die connection tracking Module).
Iptables arbeitet sein Regelwerk von oben nach unten ab, grundsätzlich gilt erstmal "erster Treffer zählt".
Wenn irgendwo beim Abarbeiten des Regelwerks nen "-j ACCEPT" kommt, darf das Paket passieren, kommt nen "-j DROP" eben nicht. Und die Policy sagt nur "was mach ich mit den Paketen, wenn ich unten angekommen bin und für die ich bis dahin noch nichts entschieden habe".

Ja, das weiss ich. Ich bin es vereinfacht angegangen ("Traffic"), da ich die "tiefere" Funktionsweise der Paket-Verarbeitung (die einzelnen Layer-Schichten, etc. bis hin zum physikalischen Geschehen) nicht kenne, bzw. mir denke, dass ich das ganze Networking nicht ins Detail studiert haben muss, um zu wissen, welche Regel wann anzuwenden ist, damit ein Dienst, etc. ins Netz offen sein kann.
Klar, die Positionen für die Reglen sind wichtig und - wie ich jetzt weiss - ist es auch wichtig, dass der (für meine Begriffe) "Rück-Traffic" auch zurück kommt und nicht geblockt wird.

Zu 3. & nachfolgendem Text: Ich denke jetzt kommen wir der Sache etwas näher ^^ ...

Also, so wie ich das jetzt verstehe, läuft das so ab:
1. Ein Programm/Dienst macht eine ausgehende Verbindung ins Internet auf (z.B. DNS) - jetzt steht eine Leitung.

Nö. Unterschied TCP/UDP lies Dich da mal ein.

Da verwirrst du mich aber nochmals. Ich bin hier von einer TCP-Verbindung ausgegangen, um erstmal das grundsätzliche Verständnis für meine Problematik zu bekommen. UDP ist dann wohl anders, da ja verbindungslos...

Auf dieser Leitung werden die angefragten Daten auf der selben Leitung zum betr. Dienst/Programm "rücktransportiert", ABER auch auf diesem "Rücktransport" greift die INPUT-chain ... richtig?

Nein, loopback (127.x.x.x) hat ne besondere Bedeutung und ist nicht das Lan lokale Interface. Dein Rechner hat noch ne weiteres "Netzwerkinterface" zumindest in der Logik der Paketvermittlung und damit bei iptables, das Rechner lokale, Pakete die der Rechner nur an sich selbst sendet, ohne dass sie physikalisch auf die Kabel kommen. Der Unterschied spielt ne wichtig Rolle. Und Dein Script erweckt den Eindruck, dass Dir der Unterschied noch nicht bewusst ist. Deswegen: Lokale IP (192.168.x.x zB ) ist nicht loopback (127.x.x.x)!
Lies nochmal dazu nochmal nach.

Warum bringst du hier das Loopback ins Spiel?
Das Loopback kenne ich und auch dessen Bedeutung ist mir bekannt, nur warum du das jetzt hier erwähnst verstehe ich nicht...

[mat6937]

Ich bin hier von einer TCP-Verbindung ausgegangen, um erstmal das grundsätzliche Verständnis für meine Problematik zu bekommen. UDP ist dann wohl anders, da ja verbindungslos...

D. h. aber nicht, dass Du bei UDP mit iptables, die Verbindung (bzw. den Datenverkehr) _zum_ Server und _vom_ Server genau so "regeln" kannst wie bei TCP.
Es gibt tools mit denen Du das anschauen kannst. Z. B.:

Code: Alles auswählen

tcpdump -c 100 -vvveni eth0 src port 53

Code: Alles auswählen

host -t a -T heise.de 1.1.1.1

und (mit UDP statt TCP)

Code: Alles auswählen

host -t a heise.de 9.9.9.9

Wenn Du mit dnssec testen willst, kannst Du z. B. dig benutzen:

Code: Alles auswählen

dig +dnssec bund.de @9.9.9.9

Bei DNS over TLS (DoT) wird vom Server der TCP-Port 853 benutzt und bei DNS over HTTPS (DoH) wird der Server auf seinem lauschenden TCP-Port 443 erreicht. Es gibt auch Tools zum testen von DoT bzw. DoH:

Code: Alles auswählen

:~ $ doh berlin.de                
[berlin.de]
TTL: 76835 seconds
A: 109.68.230.145
AAAA: 2a00:13c8:00f5:0000:0000:0393:8a4d:0002

Code: Alles auswählen

:~ $ doh hamburg.de https://dns.quad9.net/dns-query
[hamburg.de]
TTL: 300 seconds
A: 212.1.41.12
AAAA: 2a02:0ad0:0005:0001:0000:0000:0000:0012

[worker777]

D. h. aber nicht, dass Du bei UDP mit iptables, die Verbindung (bzw. den Datenverkehr) _zum_ Server und _vom_ Server genau so "regeln" kannst wie bei TCP.
Es gibt tools mit denen Du das anschauen kannst. Z. B.:

Code: Alles auswählen

tcpdump -c 100 -vvveni eth0 src port 53

Was es mit UDP und TCP genau auf sich hat, da muss ich mich noch einlesen. Die Ausgabe von tcpdump (wenn ich dann z.B. ein 'nslookup' mache) verstehe ich auch nicht. Das ist mir dann zu tief in der Tiefe ^^ ...
Leider habe ich im Moment nicht die nötige Zeit dafür, aber irgendwann möchte ich schon noch den genauen Unterschied zwischen UDP und TCP (insbes. in Verbindung mit Paketfiltern) verstehen.

Jedenfalls danke für die Hilfe!

[mat6937]

..., aber irgendwann möchte ich schon noch den genauen Unterschied zwischen UDP und TCP (insbes. in Verbindung mit Paketfiltern) verstehen.

Ein wesentlicher Unterschied ist, dass man für TCP-Verbindungen, im Paketfilter tcp-flags benutzen kann und bei UDP gibt es das nicht. Z. B.:

Code: Alles auswählen

iptables -I INPUT 1 -t security -i <input-Interface> -p tcp --tcp-flags SYN,ACK SYN,ACK -s <source-IP-Adresse> -m ecn ! --ecn-tcp-ece -j DROP

Siehe auch:

Code: Alles auswählen

man iptables-extensions | grep -i tcp-flags

[eggy]

@mat6937: man braucht nicht mal bis doh zu gehen, +tcp bzw +notcp (ist default) reicht bei dig schon aus.
UDP: zwei Zeilen; TCP: fast nen halber Bildschirm voll

@worker777: ohne grundlegendes Verständnis der Protokolle, wird Deine Selbstbau-Firewall vermutlich löchrig wie nen schweizer Käse.
Du kannst gerne mal im Jabber vorbei schauen, im "Gespräch" lässt sich vielleicht einfacher rausfinden, wo Deine Verwirrung herkommt und wie man sie loswird.
Falls Du nen Buch zu der Materie suchst: "Kurose: Computernetworks - A Top-Down-Approach.", gibts auch auf Deutsch, Titel so ähnlich, liest sich bequem weg.

[worker777]

@mat6937:
Alles klar, danke dir.

@eggy:
Ja, mit dem Schweizerkäse haste absolut recht - ich krieg das nicht gebacken, vor allem das IPv6. Hab den RasPi jetzt wieder hinter die Router-FW "gestellt" und die Ports wieder freigeschaltet, da ich im Moment einfach leider keine Zeit dafür habe .... ärgerlich(!).
Danke auch für's Jabber Angebot, aber wie gesagt, im Moment geht das zeitlich einfach nicht. Und für sowas brauch ich reichlich Zeit und Ruhe, sonst wird das nix ^^ ...

Ich habe mir einiges hier rauskopiert und wenn ich dann wieder Zeit dafür habe, werde ich es hervorholen - Eure Zeit/Mühe ist also nicht vergebens gewesen
Vielen Dank, auch für die Geduld!

[mat6937]

@mat6937: man braucht nicht mal bis doh zu gehen, +tcp bzw +notcp (ist default) reicht bei dig schon aus.
UDP: zwei Zeilen; TCP: fast nen halber Bildschirm voll

Man braucht auch nicht bis dig zu gehen. Siehe mein Beispiel oben, mit host:

Code: Alles auswählen

host -t a -T heise.de 1.1.1.1

By default, host uses UDP when making queries. The -T option makes it use a TCP connection when querying the
name server.

BTW: Ich habe DoT und DoH nicht wegen TCP erwähnt, eher wegen dem Port.