Was macht wie DNS in Debian?

[noobadix]

Hallo!
Die folgenden Frage ist von grundsätzlicher Natur:
Welche Komponente in Linux/Debian führt DNS-lookups durch und wie wird von wem entschieden welche Ports dafür benutzt werden? Wo ist das dokumentiert?
Oder anders: Was passiert, nachdem ich z.B. "ping debianforum.de" aufgerufen habe? Gibt es ein Programm, mit dem man dessen Aktivitäten untersuchen kann, sowas wie ein Traceback des Programms machen ähnlich wie bash -x nur lower level? Wie komme ich eigentlich an den Source Code von z.B. "host" in https://sources.debian.org/ ? D.h. woher weiß ich, welcher Source Code zu diesem Binary gehört? Gibt es zu den Source Codes auch Dokumentationen?

DNS arbeitet ja auf der Anwendungsschicht des OSI-Modells und von daher nehme ich an, dass die Anfragen nicht vom Kernel ausgeführt werden, sondern dessen Sockets eben von dem gesuchten Dienst benutzt werden.

Hintergrund:
Gerade richte ich eine Firewall ein, setze die INPUT Policy auf Drop und möchte z.B. DNS erlauben, weiß aber nicht welche Ports dafür benutzt werden. Zunächst hatte ich Port 53 probiert, aber nur damit konnten keine URLs aufgelöst werden. Dann habe ich IPTABLES loggen lassen und gesehen, dass DNS-Anfragen vom SRC-Port 53 auf diverse andere Zielports gehen, da ging meine Verwirrung los. Recherchen zeigten, dass es sowas wie UPD Port Randomization gibt und das müsste ja wenn dann auch in Debian implementiert werden. Aber wo, in welchem Dienst/Programm? Googlen zeigte mir nur immer und immer wieder die /etc/resolv.conf an, die kenne ich nun schon, aber welcher Dienst liest die für DNS-Abfragen?

Herzlichen Dank vorab und lieben Gruß!

[Bullet64]

Sehr interessante Frage. Kann leider nichts zum Thema beitragen, aber sicher hier noch was lernen.

[mat6937]

Hintergrund:
Gerade richte ich eine Firewall ein, setze die INPUT Policy auf Drop und möchte z.B. DNS erlauben, weiß aber nicht welche Ports dafür benutzt werden. Zunächst hatte ich Port 53 probiert, aber nur damit konnten keine URLs aufgelöst werden. Dann habe ich IPTABLES loggen lassen und gesehen, dass DNS-Anfragen vom SRC-Port 53 auf diverse andere Zielports gehen, da ging meine Verwirrung los. Recherchen zeigten, dass es sowas wie UPD Port Randomization gibt und das müsste ja wenn dann auch in Debian implementiert werden. Aber wo, in welchem Dienst/Programm? Googlen zeigte mir nur immer und immer wieder die /etc/resolv.conf an, die kenne ich nun schon, aber welcher Dienst liest die für DNS-Abfragen?

Wenn Du die default policy der INPUT chain auf DROP gesetzt hast, kannst Du als 1. Regel in dieser chain, ESTABLISHED- und RELATED-Verbindungen erlauben. Wenn Du das nicht willst kannst Du auch NEW- und INVALID-Verbindungen (oder alle input-Verbindungen) aus dem Internet, mit dem Port 53 als source-Port, erlauben.
BTW: DNS kann auch über TCP gemacht werden:

Code: Alles auswählen

host -t A -T heise.de 1.1.1.1

[TomL]

Gerade richte ich eine Firewall ein, setze die INPUT Policy auf Drop und möchte z.B. DNS erlauben, weiß aber nicht welche Ports dafür benutzt werden.

Da stellt sich die Frage, wo richtest du die Firewall ein....?... zwischen LAN und WWW oder als Desktop-FW? Und die zweite und wichtigster Frage ist, ob das System, wo die FW eingerichtet ist, auch wirklich der DNS ist....?... wenn nicht, kommen da m.M.n. nämlich nie Pakete auf Port 53 in der Input-Chain an. Und wenn er selber Dns-Anfragen stellen muss, muss Port 53 in der Output-Chain erlaubt sein.

Btw, zum jetzigen Zeitpunkt, also wenn das alles noch Neuland ist, empfehle ich nftables statt iptables zu verwenden.

Was den Quellcode angeht, kann der ganz normal wie auch normale Programmpakete auf dem Repo geladen werden.

[MSfree]

Oder anders: Was passiert, nachdem ich z.B. "ping debianforum.de" aufgerufen habe?

Programme, die einen Hostnamen in eine IP-Adresse auflösen müssen oder umgekehrt, ip nach Hostname, verwenden die libresolv. Egal ob ping, curl, wget, ftp, Firefox ..., das wird alles von libresolv abgehandelt.

Gerade richte ich eine Firewall ein, setze die INPUT Policy auf Drop und möchte z.B. DNS erlauben, weiß aber nicht welche Ports dafür benutzt werden.

TCP/53 und UDP/53.

Dann habe ich IPTABLES loggen lassen und gesehen, dass DNS-Anfragen vom SRC-Port 53 auf diverse andere Zielports gehen

Nein, umgekehrt, Die Clients verwenden den Zielport 53, die Antwort kommt dann unter Umständen über einen anderen Port.

Googlen zeigte mir nur immer und immer wieder die /etc/resolv.conf an, die kenne ich nun schon, aber welcher Dienst liest die für DNS-Abfragen?

Die libresolv greift auf die resolv.conf zurück, um die IP-Adresse der Nameservers zu erfragen, der die Auflösung durchführen soll. Ferner steht in der resolv.conf noch die Defaultdomain, die jedem Hostnamen angehängt wird, wenn dieser keinen Punkt enthält. Das dient aber nur zur Abkürzung im lokalen Netz.

Zu guter Letzt sei aber noch erwähnt, daß es inzwischen leider Bestrebungen gibt, DNS über HTTP (DOH) abzuhandeln. Vor allem Webbrowser kommen inzwischen damit, was den Werbetreibenden das Tracking erleichtern soll.

[eggy]

Welche Komponente in Linux/Debian führt DNS-lookups durch und wie wird von wem entschieden welche Ports dafür benutzt werden? Wo ist das dokumentiert?

kommt drauf an. Gewöhlicherweise der sogenannte "Resolver", das kann ein einzelnes Programm sein, das ist in der Regel eine Bibliothek, das kann aber auch was selbstgeschriebenes innerhalb eines beliebigen Anwendungsprogramms sein. Einfach sagen "nur xyz darf raus" klappt also nicht, falls das die Idee dahinter war.

Oder anders: Was passiert, nachdem ich z.B. "ping debianforum.de" aufgerufen habe?

kommt drauf an. wenn du nen "normales" ping meinst (von denen es allein als /bin/ping schon mindestens zwei Versionen in Debian gibt (inetutils-ping/iputils-ping) dann je nach mitgelieferten Optionen (was das sein kann: siehe man ping), klassiches ping via icmp? Dazu gibts mehrere gute Webseiten die das auf unterschiedlichstem Niveau erklären, einfach mal $suchmaschine bemühen. Leseempfehlung TCP-Illustrated Vol. 1 und Kurose Computernetworks the Top-Down-Approach, beides auch in deutsch erhältlich. Das erste alt aber sehr gut, das zweite moderner und weitergefasst.

Gibt es ein Programm, mit dem man dessen Aktivitäten untersuchen kann, sowas wie ein Traceback des Programms machen ähnlich wie bash -x nur lower level?

ja, mehrere. strace zeigt die librarycalls, Harald König hat dazu nen paar nette Vorträge auf diversen Linuxkonferenz gehalten, einfach mal selbst suchen. Was du eher sehen willst: was geht übers Netzwerk: tcpdump bzw grafisch wireshark. Auch dazu gibts mehr als genug gute Anleitungen, bitte selbst suchen.

Wie komme ich eigentlich an den Source Code von z.B. "host" in https://sources.debian.org/ ? D.h. woher weiß ich, welcher Source Code zu diesem Binary gehört? Gibt es zu den Source Codes auch Dokumentationen?

apt-get source namenvompaket
also z.B. apt-get source bind9-host
ob das dokumentiert ist, oder nicht, hängt unter anderem von der Motivation des Coders ab, manchmal sehr gut, manchmal garnicht, meist irgendwo dazwischen.
Die Protokolle an sich sind in sogenannten RFCs zu finden, da steht (fast) alles drin was man wissen muss.

DNS arbeitet ja auf der Anwendungsschicht des OSI-Modells und von daher nehme ich an, dass die Anfragen nicht vom Kernel ausgeführt werden, sondern dessen Sockets eben von dem gesuchten Dienst benutzt werden.

Kommt drauf an, was man als "vom Kernel ausgeführt" betrachtet, jede Speicheranforderung, jedes Öffnen eines Sockets, alles braucht Mitarbeit des Kernels. Beschäftige Dich mit strace, syscalls und co, dann wird das klarer. Und bei der Gelegenheit verabschiede Dich auch schonmal vom OSI Modell als Maß aller Dinge. Es ist, wie es schon heißt, nur ein Modell. Mit der Realität hat das, wenn man wirklich auf Paketebene runtergeht, nicht so viel zu tun. Fürs oberflächliche Einsortieren gut, für mehr nicht.

[noobadix]

Hi,

habt herzlichen dank für die schnellen, erhellenden und ermutigenden Antworten!

Der Reihe nach:

Wenn Du die default policy der INPUT chain auf DROP gesetzt hast, kannst Du als 1. Regel in dieser chain, ESTABLISHED- und RELATED-Verbindungen erlauben. Wenn Du das nicht willst kannst Du auch NEW- und INVALID-Verbindungen (oder alle input-Verbindungen) aus dem Internet, mit dem Port 53 als source-Port, erlauben. [...]

Ja, damit können tatsächlich auch wieder DNS-Lookups durchgeführt werden. Ein Verständnis dieser Policy bin ich noch schuldig, aber da gibt's bestimmt viel im Google.

Da stellt sich die Frage, wo richtest du die Firewall ein....?... zwischen LAN und WWW oder als Desktop-FW? Und die zweite und wichtigster Frage ist, ob das System, wo die FW eingerichtet ist, auch wirklich der DNS ist....?... wenn nicht, kommen da m.M.n. nämlich nie Pakete auf Port 53 in der Input-Chain an. Und wenn er selber Dns-Anfragen stellen muss, muss Port 53 in der Output-Chain erlaubt sein.

Btw, zum jetzigen Zeitpunkt, also wenn das alles noch Neuland ist, empfehle ich nftables statt iptables zu verwenden.

Was den Quellcode angeht, kann der ganz normal wie auch normale Programmpakete auf dem Repo geladen werden.

Die Firwall läuft auf einem Webserver, also steht (afaik) direkt im WWW, bzw. weil es ein vServer ist hat der noch ein Gateway. Betreiben will ich keinen DNS-Server, aber der Webserver soll z.B. wenigstens updates über apt beziehen können, dafür braucht er DNS-Lookups.
Ja, NFTABLES ist der Nachfolger, aber an IPTABLES bin ich aus anderen Gründen mehr oder minder gebunden (Schule).

Tatsächlich hat mir apt source bind9-host etwas geliefert, das ich nun erstmal inspizieren muss.

[...]
Programme, die einen Hostnamen in eine IP-Adresse auflösen müssen oder umgekehrt, ip nach Hostname, verwenden die libresolv. Egal ob ping, curl, wget, ftp, Firefox ..., das wird alles von libresolv abgehandelt.
[...]
Die libresolv greift auf die resolv.conf zurück, um die IP-Adresse der Nameservers zu erfragen, der die Auflösung durchführen soll. Ferner steht in der resolv.conf noch die Defaultdomain, die jedem Hostnamen angehängt wird, wenn dieser keinen Punkt enthält. Das dient aber nur zur Abkürzung im lokalen Netz.

Aha! Super, das ist wieder eine Spur. Wie hätte ich darauf kommen können, welche Manual habe ich nicht gelesen? Ich würde ja gerne etwas selbständiger werden

Gerade richte ich eine Firewall ein, setze die INPUT Policy auf Drop und möchte z.B. DNS erlauben, weiß aber nicht welche Ports dafür benutzt werden.

TCP/53 und UDP/53.

Das gilt dann wohl für DNS-Server, aber wo ich ja keiner bin, brauche ich nur DNS-Lookups.

Dann habe ich IPTABLES loggen lassen und gesehen, dass DNS-Anfragen vom SRC-Port 53 auf diverse andere Zielports gehen

Nein, umgekehrt, Die Clients verwenden den Zielport 53, die Antwort kommt dann unter Umständen über einen anderen Port.

Dann bleibt die Frage, welcher Quellport für meine DNS-Lookups verwendet wird. Und der letzte Halbsatz ist für meine Firwall natürlich ganz wichtig: Ist das wirklich so unvorhersagbar, wenn ja warum und kann ich damit gezielter als mit einer "-m state --state RELATED,ESTABLISHED"-Regel umgehen?

Zu guter Letzt sei aber noch erwähnt, daß es inzwischen leider Bestrebungen gibt, DNS über HTTP (DOH) abzuhandeln. Vor allem Webbrowser kommen inzwischen damit, was den Werbetreibenden das Tracking erleichtern soll.

Was ist nur aus dem ARPANET geworden...

Welche Komponente in Linux/Debian führt DNS-lookups durch und wie wird von wem entschieden welche Ports dafür benutzt werden? Wo ist das dokumentiert?

kommt drauf an. Gewöhlicherweise der sogenannte "Resolver", das kann ein einzelnes Programm sein, das ist in der Regel eine Bibliothek, das kann aber auch was selbstgeschriebenes innerhalb eines beliebigen Anwendungsprogramms sein. Einfach sagen "nur xyz darf raus" klappt also nicht, falls das die Idee dahinter war.

kommt drauf an. wenn du nen "normales" ping meinst (von denen es allein als /bin/ping schon mindestens zwei Versionen in Debian gibt (inetutils-ping/iputils-ping) dann je nach mitgelieferten Optionen (was das sein kann: siehe man ping), klassiches ping via icmp? Dazu gibts mehrere gute Webseiten die das auf unterschiedlichstem Niveau erklären, einfach mal $suchmaschine bemühen. Leseempfehlung TCP-Illustrated Vol. 1 und Kurose Computernetworks the Top-Down-Approach, beides auch in deutsch erhältlich. Das erste alt aber sehr gut, das zweite moderner und weitergefasst.

Gibt es ein Programm, mit dem man dessen Aktivitäten untersuchen kann, sowas wie ein Traceback des Programms machen ähnlich wie bash -x nur lower level?

ja, mehrere. strace zeigt die librarycalls, Harald König hat dazu nen paar nette Vorträge auf diversen Linuxkonferenz gehalten, einfach mal selbst suchen. Was du eher sehen willst: was geht übers Netzwerk: tcpdump bzw grafisch wireshark. Auch dazu gibts mehr als genug gute Anleitungen, bitte selbst suchen.

Wie komme ich eigentlich an den Source Code von z.B. "host" in https://sources.debian.org/ ? D.h. woher weiß ich, welcher Source Code zu diesem Binary gehört? Gibt es zu den Source Codes auch Dokumentationen?

apt-get source namenvompaket
also z.B. apt-get source bind9-host
ob das dokumentiert ist, oder nicht, hängt unter anderem von der Motivation des Coders ab, manchmal sehr gut, manchmal garnicht, meist irgendwo dazwischen.
Die Protokolle an sich sind in sogenannten RFCs zu finden, da steht (fast) alles drin was man wissen muss.

DNS arbeitet ja auf der Anwendungsschicht des OSI-Modells und von daher nehme ich an, dass die Anfragen nicht vom Kernel ausgeführt werden, sondern dessen Sockets eben von dem gesuchten Dienst benutzt werden.

Kommt drauf an, was man als "vom Kernel ausgeführt" betrachtet, jede Speicheranforderung, jedes Öffnen eines Sockets, alles braucht Mitarbeit des Kernels. Beschäftige Dich mit strace, syscalls und co, dann wird das klarer. Und bei der Gelegenheit verabschiede Dich auch schonmal vom OSI Modell als Maß aller Dinge. Es ist, wie es schon heißt, nur ein Modell. Mit der Realität hat das, wenn man wirklich auf Paketebene runtergeht, nicht so viel zu tun. Fürs oberflächliche Einsortieren gut, für mehr nicht.

Danke!
Die Ausgabe von Strace gilt es erstmal zu verstehen, aber die libcalls konnte ich glaube ich schon ausfindig machen. Die Literatur klingt spannend, ich schaue mal. RFCs sind gewiss ein guter Tipp, helfen mir hier aber nicht weiter, weil ich ja nach einer bestimmten Implementierung von DNS-Lookup-Mechanismus suche. Im letzten DNS-RFC kommt das Wort "Port" nicht ein einziges Mal vor, habe es geprüft! Mit dem OSI-Modell muss ich erstmal noch gehen, weil das in der Schule gefordert wird.
Und tcpdump/ss muss ich tatsächlich mal Herr werden. Mit Wireshark habe ich schon so viel interessantes herausgefunden.

[TomL]

Dann bleibt die Frage, welcher Quellport für meine DNS-Lookups verwendet wird.

Immer noch dport 53 TCP und UDP... allerdings Outgoing-Chain.

Und der letzte Halbsatz ist für meine Firwall natürlich ganz wichtig: Ist das wirklich so unvorhersagbar, wenn ja warum und kann ich damit gezielter als mit einer "-m state --state RELATED,ESTABLISHED"-Regel umgehen?

Der ausgehende Port ist irrelevant, weil Du im Paketfilter nicht den ausgehenden Port freigibst, sondern den Zielport 53.... weil das nämlich der Port ist, auf den der woanders stehende DSN lauscht. Welcher ausgehende Port für diese Anfrage verwendet wird, ist unwichtig und muss auch nicht beachtet werden, der wechselt bei jedem lookup. Und natürlich kommt auf diesem ausgehenden 5-stelligen Port auch die Antwort wieder rein... aber die Verbindung ist ja dann established, weil Du ja zuvor den dport 53 erlaubt hast.

[mat6937]

Dann bleibt die Frage, welcher Quellport für meine DNS-Lookups verwendet wird.

Da gibt es schon Möglichkeiten immer nur einen bestimmten UDP-Port als source-Port für die DNS-Anfragen zu benutzen. Z. B. beim dnsmasq (oder gleichwertig!) mit dem query-port:

-Q, --query-port=<query_port>
Send outbound DNS queries from, and listen for their replies on, the specific UDP port <query_port> instead of using random ports. NOTE that using this option will make dnsmasq less secure against DNS spoofing attacks but it may be faster and use less resources. Setting this option to zero makes dnsmasq use a single port allocated to it by the OS: this was the default behaviour in versions prior to 2.43.

[reox]

Zunächst hatte ich Port 53 probiert, aber nur damit konnten keine URLs aufgelöst werden. Dann habe ich IPTABLES loggen lassen und gesehen, dass DNS-Anfragen vom SRC-Port 53 auf diverse andere Zielports gehen, da ging meine Verwirrung los. Recherchen zeigten, dass es sowas wie UPD Port Randomization gibt und das müsste ja wenn dann auch in Debian implementiert werden.

Ganz unabhängig vom Rest: Der Grund dafür ist eigentlich sehr einfach. Ein Rechner auf dem vielleicht auch ein DNS Server läuft, möchte ja selber auch DNS abfragen starten. Daher wäre es ungeschickt, wenn er selber für die Antwort auf Port 53 lauschen müsste - der wäre in dem Fall ja schon durch den Server belegt.
Zudem gibt es eine Separierung zwischen priviligierten Ports und normalen. Alle Ports unter 1024 können nur von root gestartet werden. Daher kommen die Antworten oft auf Ports in der 10er range rein.
dH Userland prozesse können ohne weiteres gar nicht Ports <1024 aufmachen.

Wenn du dir das genauer anschauen willst, empfehle ich mal ein kleines Programm mit der socket API zu schreiben.
Dazu mehr unter

Code: Alles auswählen

man 2 socket

[TomL]

Ganz unabhängig vom Rest: Der Grund dafür ist eigentlich sehr einfach. Ein Rechner auf dem vielleicht auch ein DNS Server läuft, möchte ja selber auch DNS abfragen starten. Daher wäre es ungeschickt, wenn er selber für die Antwort auf Port 53 lauschen müsste - der wäre in dem Fall ja schon durch den Server belegt.

Nee, das ist irrelevant. Ein DNS-Server (z.B. Pihole) empfängt Anfragen auf dem belauschten Port 53, hier input-chain, von irgendeinem beliebigen sport eines anderen Gerätes.Die Antwort geht nicht an 53 zurück, sondern an den verwendeten beliebigen sport, der für die Antwort zum dport wird. Er selber sendet Anfragen ebenfalls via port 53, hier output-chain, aber eben dport.... und ebenfalls von einem beliebigen sport. Die Magie liegt auf der jeweiligen individuellen Perspektive, wann etwas sport ist und wann dport... in Abhängigkeit davon, ob es rein kommt oder raus geht und was gerade mit dem Paket von wem beabsichtigt ist.

sport = source port
dport = destination port

weil es ein vServer ist hat der noch ein Gateway.

Das wird vermutlich der Grund dafür sein, dass Du keinen Einfluss auf ausgehende Source-Ports hast bzw. dass das nur systeminterne Auswirkung hat.... weil da möglicherweise ein Port-NAT dazwischen funkt. Ich würde darüber auch nicht mal nachdenken, weil das meiner Meinung nach vor diesem Hintergrund Zeitverschwendung ist.

[reox]

Ganz unabhängig vom Rest: Der Grund dafür ist eigentlich sehr einfach. Ein Rechner auf dem vielleicht auch ein DNS Server läuft, möchte ja selber auch DNS abfragen starten. Daher wäre es ungeschickt, wenn er selber für die Antwort auf Port 53 lauschen müsste - der wäre in dem Fall ja schon durch den Server belegt.

Nee, das ist irrelevant. Ein DNS-Server (z.B. Pihole) empfängt Anfragen auf dem belauschten Port 53, hier input-chain, von irgendeinem beliebigen sport eines anderen Gerätes. Er selber sendet Anfragen ebenfalls via port 53, hier output-chain, aber eben dport.... und ebenfalls von einem beliebigen sport. Die Magie liegt auf der jeweiligen individuellen Perspektive, wann etwas sport ist und wann dport... in Abhängigkeit davon, ob es rein kommt oder raus geht und was gerade mit dem Paket von wem beabsichtigt ist.

Ich glaube das sind schon zwei paar Schuhe: Was ich meine ist du hast einen DNS Server Prozess mit PID x und hast einen DNS Client mit PID y. Dann kann y gar nicht auf dem Socket von x senden (außer durch IPC). Aber wenn der Server eine Anfrage beantwortet, kann er natürlich den bidirektionalen Socket verwenden, der schon auf ist.
Nur was ich gelernt habe ist, dass man als Server trotzdem den Socket wechseln sollte, weil der Socket ja sonst belegt ist. dH du empfängst die initiale Antwort auf Port 53, gehst dann aber woanders hin.
Aber es geht ja primär hier um Clients, also ein Program was eine Verbindung zu einem Server aufbaut, um etwa DNS abzufragen. Ich glaube kaum, dass es irgendeinen Client gibt der auf Port 53 die Abfragen sendet.

[TomL]

Ich glaube das sind schon zwei paar Schuhe: Was ich meine ist du hast einen DNS Server Prozess mit PID x und hast einen DNS Client mit PID y. Dann kann y gar nicht auf dem Socket von x senden (außer durch IPC). Aber wenn der Server eine Anfrage beantwortet, kann er natürlich den bidirektionalen Socket verwenden, der schon auf ist.

Genau hier liegt der Fehler. Für die ausgehenden DNS-Anfragen des 'suchenden' Systems braucht es keinen Socket, für den ist das ein normales UDP/TCP-Paket an den dport 53 des DNS. Der Socket läuft NUR auf dem DNS, und der ist nicht birektional, sondern NUR lauschend.... eben deshalb, weil der sport des 'suchenden' was beliebiges ist. Das heisst, auch für die Anworten des DNS auf die Frage des 'suchenden' braucht es ebenfalls keinen Socket für 53, weil der ursprüngliche sport des 'suchenden' ein völlig beliebiger war und weil genau dahin die Antwort geht. Definitiv gibt es auf keinem einzigen meiner Clients Sockets für Port 53... einen geöffneten Port 53 gibt es nur ein einziges Mal, und zwar in der PiHole-VM.

Du kannst das einfach kontrollieren.... schau dir die offenen Ports an... zuerst auf einem DNS und dann auf einem reinen Client-System:

Code: Alles auswählen

ss -tulpen

und vergleiche die PIDs in den offenen Sockets (ggf. an IPv6 denken):

Code: Alles auswählen

# cat /proc/net/tcp
# cat /proc/net/udp

Das ist identisch. Wenn da jedoch tatsächlich Port 53 auf einem reinen Client-System gelistet wird, obwohl das System keine DNS-Funktionalität hat, ist das System imho falsch konfiguriert.... hinsichtlich der m.M.n. vernünftigen Direktive "keine unnützen Services mit offenen Ports laufen zu lassen".

[reox]

Ich glaube das sind schon zwei paar Schuhe: Was ich meine ist du hast einen DNS Server Prozess mit PID x und hast einen DNS Client mit PID y. Dann kann y gar nicht auf dem Socket von x senden (außer durch IPC). Aber wenn der Server eine Anfrage beantwortet, kann er natürlich den bidirektionalen Socket verwenden, der schon auf ist.

Genau hier liegt der Fehler. Für die ausgehenden DNS-Anfragen des 'suchenden' Systems braucht es keinen Socket, für den ist das ein normales UDP/TCP-Paket an den dport 53 des DNS. Der Socket läuft NUR auf dem DNS, und der ist nicht birektional, sondern NUR lauschend.... eben deshalb, weil der sport des 'suchenden' was beliebiges ist. Das heisst, auch für die Anworten des DNS auf die Frage des 'suchenden' braucht es ebenfalls keinen Socket für 53, weil der ursprüngliche sport des 'suchenden' ein völlig beliebiger war und weil genau dahin die Antwort geht. Definitiv gibt es auf keinem einzigen meiner Clients Sockets für Port 53... einen geöffneten Port 53 gibt es nur ein einziges Mal, und zwar in der PiHole-VM.

Ich glaube wir reden aneinander vorbei. Das was du beschreibst ist vollkommen richtig. Du hast einen Server der lauscht auf einem Port, zB 53. Es kommt eine Anfrage von einem Client rein, die Antwort kommt mit sport 53 zum Client zurück. Alles klar, das hab ich ja auch nie in Frage gestellt.

Was ich meine ist folgender Fall. Du hast einen DNS Server lokal laufen. Der lauscht weiterhin auf 53. Aber jetzt möchte der Firefox eine Domain auflösen, in /etc/resolvctl.conf steht 8.8.8.8 drin. Der DNS Client wird jetzt sicherlich nicht als srcport 53 angeben - a) dort lauscht schon ein Dienst und b) kann er gar nicht auf 53 einen socket öffnen, da priviligiert. Natürlich wird der resolver auf dstport 53 senden und bekommt seine Antwort mit srcport 53 zurück.
zB auf meinem System kommt eine DNS Abfrage zu meinem DNS Server von srcport 36467 und geht an dstport 53 am Router. Zurück kommt die Antwort von 53 an 36467.

Der TO wollte ja eine Firewall regel setzen mit der DNS Abfragen erlaubt werden und war verwirrt, dass diese nicht srcport 53 haben. Meine Erklärung war, warum ein Client eben nicht 53 als srcport nimmt sondern irgendwas anderes und DNS von einem Client nur über den dstport erkennbar ist (oder meinetwegen durch traffic inspection)

Was ich glaube ich verwirrend geschrieben habe ist, dass ein neuer Socket aufgemacht wird. Ich glaube ich hab das falsch in Erinnerung oder es hat sich da in den letzten 16 Jahren was geändert. Jedenfalls hatte ich das damals so in der Schule gelernt...Die manpage zu accept meint, dass die letzte Verbindung aus der Queue der Verbindungen akzeptiert wird und ein Filedescriptor zurück kommt. Ich hatte das eher so in Erinnerung, dass der Socket, solange ein Client dort drin hängt, blockiert ist. Aber offenbar reicht es aus, die Verbindung zu akzeptieren und das read in einem Thread zu machen. Also ich nehm das zurück - offenbar kann man über den selben Socket kommunizieren. Macht auch irgendwie mehr Sinn, sonst würden Firewalls ja gar nicht funktionieren. Wir haben damals in der Schule einen Multithread Client/Server schreiben sollen und dort war genau die Aufgabe auf dem initialen Server socket eine neue Verbindung auszuhandeln, damit der socket nicht blockiert ist. War wohl unnötig so ^_^

[mat6937]

Was ich meine ist folgender Fall. Du hast einen DNS Server lokal laufen. Der lauscht weiterhin auf 53. Aber jetzt möchte der Firefox eine Domain auflösen, in /etc/resolvctl.conf steht 8.8.8.8 drin. Der DNS Client wird jetzt sicherlich nicht als srcport 53 angeben - a) dort lauscht schon ein Dienst und b) kann er gar nicht auf 53 einen socket öffnen, da priviligiert. Natürlich wird der resolver auf dstport 53 senden und bekommt seine Antwort mit srcport 53 zurück.
zB auf meinem System kommt eine DNS Abfrage zu meinem DNS Server von srcport 36467 und geht an dstport 53 am Router. Zurück kommt die Antwort von 53 an 36467.

Meinst Du die /etc/resolv.conf mit 8.8.8.8? Wenn ja, warum soll der Firefox den auf Port 53 lokal lauschenden DNS-Resolver/Server (DNS-forwarder) benutzen, wenn in der resolv.conf die 8.8.8.8 eingetragen ist? Oder ist dein Firefox so konfiguriert, dass er die resolv.conf ignoriert bzw. die 127.0.0.1 benutzt?

[TomL]

Der TO wollte ja eine Firewall regel setzen mit der DNS Abfragen erlaubt werden und war verwirrt, dass diese nicht srcport 53 haben.

Ist das System Client, muss er für Anfragen an einen DNS outgoing dport 53 erlauben. Ist das System DNS, muss er incoming dport 53 erlauben und natürlich einen dort lauschenden Prozess (den DNS) gestartet haben. Ist das System sowohl Client als auch DNS, muss er beide Regeln setzen und den resolver für Anfragen (z.B. durch Firefox) auf localhost setzen, weil eben diese Anfragen der lokale DNS beantwortet.... bei dieser Interprozesskommunikation ist natürlich auch wieder outgoing->localhost->dport 53 das Ziel... es sei denn, der FF soll einen anderen, fremden DNS verwenden.

Der Socket auf diesen Port wird m.M.n. aber nur zum Lauschen auf eben diesen Port für ankommende Pakete verwendet.... damit eben der lauschende Service tatsächlich auch der Empfänger der Pakete ist.... denn die Kommunikation braucht immer einen Anfang, einen Startpunkt. Theoretisch könnten die Prozesse auf beiden Seiten nach dem Verbindungsaufbau kurzerhand auch auf related Ports wechseln, die gar nix mehr mit 53 zu tun haben.... was aber hier aufgrund des geringen Kommunikationsumfangs 'eine Frage, eine Anwort' imho wenig Sinn macht.

[reox]

Was ich meine ist folgender Fall. Du hast einen DNS Server lokal laufen. Der lauscht weiterhin auf 53. Aber jetzt möchte der Firefox eine Domain auflösen, in /etc/resolvctl.conf steht 8.8.8.8 drin. Der DNS Client wird jetzt sicherlich nicht als srcport 53 angeben - a) dort lauscht schon ein Dienst und b) kann er gar nicht auf 53 einen socket öffnen, da priviligiert. Natürlich wird der resolver auf dstport 53 senden und bekommt seine Antwort mit srcport 53 zurück.
zB auf meinem System kommt eine DNS Abfrage zu meinem DNS Server von srcport 36467 und geht an dstport 53 am Router. Zurück kommt die Antwort von 53 an 36467.

Meinst Du die /etc/resolv.conf mit 8.8.8.8? Wenn ja, warum soll der Firefox den auf Port 53 lokal lauschenden DNS-Resolver/Server (DNS-forwarder) benutzen, wenn in der resolv.conf die 8.8.8.8 eingetragen ist? Oder ist dein Firefox so konfiguriert, dass er die resolv.conf ignoriert bzw. die 127.0.0.1 benutzt?

ah hoppala, ja ich meinte die resolv.conf
Ich glaub das Beispiel ist zu kompliziert... streich einfach mal DNS komplett weg und wir nehmen ein anderes Beispiel. Auf deinem Rechner rennt ein http server auf port 80. Jetzt willst du ein apt update machen. Dann kann die Anfrage ja nicht von port 80 ausgehen, weil da ja dein service rennt. Deswegen nimmt sich ein Client der einen socket aufmacht eben nicht den dstport als srcport sondern einen anderen, zB 36234.

Ist das System Client, muss er für Anfragen an einen DNS outgoing dport 53 erlauben. Ist das System DNS, muss er incoming dport 53 erlauben und natürlich einen dort lauschenden Prozess (den DNS) gestartet haben.

Ja, mehr hab ich ja auch nicht gesagt.

Ist das System sowohl Client als auch DNS, muss er beide Regeln setzen und den resolver für Anfragen (z.B. durch Firefox) auf localhost setzen, weil eben diese Anfragen der lokale DNS beantwortet

Wie gesagt, ich glaube das Beispiel war zu kompliziert. Mir ging es nicht darum zu sagen, dass man einen lokalen resolver laufen hat. Sondern schlicht ergreifend darum, dass Anfragen die raus gehen, als source port nicht den Port des Dienstes nehmen.
Der TO hatte ja offenbar dies bemerkt, nachdem er sagt, dass DNS Antworten an seinem Rechner andere dstports als 53 haben. Er setzte INPUT auf Drop und erlaubte nur dstport (?) 53, was aber nicht funktionierte, da die ankommenden Antworten ja natürlich nicht auf dstport 53 reinkommen.

Egal, ich glaube das führt hier nur alles OT.

[mat6937]

Ich glaub das Beispiel ist zu kompliziert... streich einfach mal DNS komplett weg und wir nehmen ein anderes Beispiel. Auf deinem Rechner rennt ein http server auf port 80. Jetzt willst du ein apt update machen. Dann kann die Anfrage ja nicht von port 80 ausgehen, weil da ja dein service rennt. Deswegen nimmt sich ein Client der einen socket aufmacht eben nicht den dstport als srcport sondern einen anderen, zB 36234.

Das ist schon richtig, aber der Client wird auch wenn auf meinem Rechner _kein_ HTTP-Server auf Port 80 lauscht, den Port 80 _nicht_ als source-Port benutzen.

[reox]

Ich glaub das Beispiel ist zu kompliziert... streich einfach mal DNS komplett weg und wir nehmen ein anderes Beispiel. Auf deinem Rechner rennt ein http server auf port 80. Jetzt willst du ein apt update machen. Dann kann die Anfrage ja nicht von port 80 ausgehen, weil da ja dein service rennt. Deswegen nimmt sich ein Client der einen socket aufmacht eben nicht den dstport als srcport sondern einen anderen, zB 36234.

Das ist schon richtig, aber der Client wird auch wenn auf meinem Rechner _kein_ HTTP-Server auf Port 80 lauscht, den Port 80 _nicht_ als source-Port benutzen.

jo eh, nichts anderes sag ich ja die ganze zeit! Ich wollte nur einen der zwei Gründe aufzeigen, warum es keine gute Idee wäre, Sockets so zu verwenden.

[noobadix]

Wow, dann habe ich das all die Jahre falsch verstanden?! Und es war nie ein Problem, weil ich noch nie mit Firewalls gearbeitet habe. Unglaublich...

Um es nochmal kristallklar zu sagen: Die Ports 53, 80, 443 sind für eingehende Anfragen vom System reserviert/belegt, ausgehende Anfragen müssen von Ports >1024 durchgeführt werden. Mit unserem (wir hier im Thread) Kenntnisstand können wir nicht vorhersagen welche Ports genau da benutzt werden und so bleibt als Firwall Policy lediglich ein allgemeines Erlauben von selbst initiierten Verbindungen, vielleicht noch mit Begrenzung auf Zielports wie 53,80,443.

Hm, das hätte ich dennoch gerne irgendwo schriftlich, bzw. ich wüsste gerne wo ich das hätte selbst herausfinden können. Ich habe schon von so "Papers" gehört, wo solche Situationen erläutert werden (z.B. ein Artikel von Cisco mit Abwägungen und Empfehlungen zu zentralem/dezentralem DHCP-Server), vielleicht findet sich da auch was in Debian, ich erlaube mir mal die Entwickler anzuschreiben.

Euch erstmal nochmals herzlichen Dank fürs Aufdröseln!!!

[MSfree]

Wow, dann habe ich das all die Jahre falsch verstanden?!

Du verstehst es immer noch falsch.

Um es nochmal kristallklar zu sagen: Die Ports 53, 80, 443 sind für eingehende Anfragen vom System reserviert/belegt, ausgehende Anfragen müssen von Ports >1024 durchgeführt werden.

Nein, das mit ausgehend und reinkommend hast du hier kristallklar verwechselt.

[eggy]

Um es nochmal kristallklar zu sagen: Die Ports 53, 80, 443 sind für eingehende Anfragen vom System reserviert/belegt, ausgehende Anfragen müssen von Ports >1024 durchgeführt werden. Mit unserem (wir hier im Thread) Kenntnisstand können wir nicht vorhersagen welche Ports genau da benutzt werden und so bleibt als Firwall Policy lediglich ein allgemeines Erlauben von selbst initiierten Verbindungen, vielleicht noch mit Begrenzung auf Zielports wie 53,80,443.

Nein, die "well kown ports" ( <1024) sind fürs System reserviert, Du brauchst root-Rechte um die aufzumachen. In der Regel laufen da ein paar der älteren Serverdienste. Du kannst Server aber auch weiter oben starten, viele neuere machen das auch, schau einfach mal was bei Dir so läuft und wo, nen Blick in /etc/services bringt da Erkenntnisgewinn. Und dann gibt's noch die Clients, die für den Verbindungsaufbau zu den Servern in der Regel mehr oder weniger zufällige temporäre Ports aus dem "flüchtigen" Bereich anfordern. Genaueres siehe Literatur. Wikipedia gibt ne Übersicht: https://en.wikipedia.org/wiki/Registered_port

Hm, das hätte ich dennoch gerne irgendwo schriftlich, bzw. ich wüsste gerne wo ich das hätte selbst herausfinden können.

In den oben genannten Büchern und so ziemlich jedem anderen halbwegs guten Buch über IP/TCP/UDP.
In den Protokollspezifikationen (RFCs) und Manpages zur Implementierung (man 7 udp, man 7 tcp, man connect, man 2 bind und diverse andere)
Und wenn Du Wireshark aufmachst und ne beliebige Netzwerkaktion ausführst, siehst Du auch welche Absenderports z.B. von Deinem Webbrowser genutzt werden.

[noobadix]

Wow, dann habe ich das all die Jahre falsch verstanden?!

Du verstehst es immer noch falsch.

Um es nochmal kristallklar zu sagen: Die Ports 53, 80, 443 sind für eingehende Anfragen vom System reserviert/belegt, ausgehende Anfragen müssen von Ports >1024 durchgeführt werden.

Nein, das mit ausgehend und reinkommend hast du hier kristallklar verwechselt.

Aber wie kann es dann sein, dass mein Apache Webserver, auf dem ich als INPUT ausschließlich die Ports 80 und 443 erlaube, http-Verbindungen von Clients beantwortet, die explizit auf Port 80 gehen, etwa mit "curl http://ichsagmeineurlhiermalnicht.aq:80"?

[eggy]

Ein Port hat grundsätzlich keine Richtung. Dass Server nen bestimmten Port eingehend und andere Ports ausgehend benutzen ist Konvention. Niemand hält dich davon ab, deinen Apache auf Port 4223 zu setzen. Versuchs einfach mal, in der apache config gibts den "listen" Parameter, änder den einfach mal auf was anderes, apache neustarten und im Browser http://serverIP:4223/ aufrufen.