Hebelt dhclient nftables aus?

[str]

Hallo Gemeinde,

ich versuche gerade, einen Router (Banana Pi-R2) mit Debian Buster "from scratch" aufzusetzen.
Nach der Aktivierung der Firewall (nftables) hatte ich erwartet, dass ohne eine entsprechende Regel keine DHCP Verhandlungen mehr stattfinden können.
Dann hätte ich einen Haken in meiner Checkliste gemacht und die entsprechenden Regeln eingesetzt.
Offenbar kümmert es den dhclient aber überhaupt nicht, dass er nicht freigegeben ist. Meine Interfaces senden fein ihr REQUEST und bekommen jedes Mal ihr ACK.
Warum? Habe ich einen "Kurzschluss" in meiner Konfiguration oder gibt es irgendwo einen geheimen Nebeneingang?

Code: Alles auswählen

nft list ruleset

table inet filter {
	chain lan-in {
		icmp type { destination-unreachable, source-quench, time-exceeded, parameter-problem } accept
		ip6 nexthdr ipv6-icmp icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
		ip saddr { 192.168.1.1, 192.168.1.7 } tcp dport ssh accept
	}

	chain lan-out {
		ip daddr 192.168.1.1 udp dport { domain, ntp } accept
		ip daddr { 192.168.1.1, 192.168.1.7 } tcp dport ssh accept
	}

	chain wan-out {
	}

	chain input {
		type filter hook input priority 0; policy drop;
		iifname "lo" accept
		ct state established,related accept
		udp dport { netbios-ns, netbios-dgm } drop
		iifname "lan0" jump lan-in
		counter packets 0 bytes 0 log prefix "netfilter INPUT: "
	}

	chain forward {
		type filter hook forward priority 0; policy drop;
		ct state established,related accept
		counter packets 0 bytes 0 log prefix "netfilter FORWARD: "
	}

	chain output {
		type filter hook output priority 0; policy drop;
		oifname "lo" accept
		ct state established,related accept
		oifname "wan" jump wan-out
		oifname "lan0" jump lan-out
		counter packets 32 bytes 1992 log prefix "netfilter OUTPUT: "
	}
}

Bin für jeden Hinweis dankbar. SuFu brachte hier im Forum und weltweit keinen Hinweis.

Gruß
Stephan

[mat6937]

Nach der Aktivierung der Firewall (nftables) hatte ich erwartet, dass ohne eine entsprechende Regel keine DHCP Verhandlungen mehr stattfinden können.
...

Bin für jeden Hinweis dankbar. SuFu brachte hier im Forum und weltweit keinen Hinweis.

Hast Du den Traffic für die udp-Port-range 67-68 und für den host 255.255.255.255 (... wenn es um IPv4 geht) blockiert?

[wanne]

Ja. Ich bin mir nicht sicher aber ich glaube wenn dhclient als root läuft umgeht er für IPv4 passende filter. (Siehe auch: raw sockets)

[str]

Hast Du den Traffic für die udp-Port-range 67-68 und für den host 255.255.255.255 (... wenn es um IPv4 geht) blockiert?

Sollte mit policy drop erledigt sein.

wenn dhclient als root läuft umgeht er für IPv4 passende filter

So etwas hatte ich befürchtet.
Kann ich irgendwie herausfinden, wer noch alles meine Firewall umgehen kann?
Eigentlich war die Grundidee beim Router selbst aufsetzen ja, die volle Kontrolle über das Regelwerk zu haben.
Wenn das nicht so ist, wäre es wenigstens schön, über die Hintertüren Bescheid zu wissen.

[mat6937]

Hast Du den Traffic für die udp-Port-range 67-68 und für den host 255.255.255.255 (... wenn es um IPv4 geht) blockiert?

Sollte mit policy drop erledigt sein.

OK, aber ab wann beim booten ist diese "policy drop" wirksam? Denn Du hast in deinem 1. Beitrag u. a. geschrieben:

Meine Interfaces senden fein ihr REQUEST und bekommen jedes Mal ihr ACK.

Hast Du REQUEST und ACK irgendwie gesnifft und wenn ja, wann bzw. wie oder hast Du das nur abgeleitet bzw. angenommen?
Für die raw.sockets siehe:

Code: Alles auswählen

ss -w -a -n

[str]

OK, aber ab wann beim booten ist diese "policy drop" wirksam?

Danke für den Hinweis, genau daran dachte ich auch zuerst. Ergebnis:
REQUEST und ACK (und das ganze drumherum) sehe ich im system log des Servers.
Das zuerst netfilter und danach erst dhclient startet sehe ich system log des aufzusetzenden Routers.
Ich habe mir jetzt mal gespart, 2 komplette journalctl Listings hier hochzuladen.

[wanne]

Kann ich irgendwie herausfinden, wer noch alles meine Firewall umgehen kann?

Nein. root kann ja auch firewallregeln ändern (und zurück ändern) und logs löschen. Wer root ist darf halt alles. Ist noch nicht so, wie bei Windows, dass es da einen System-User gibt, der mehr als der root user darf. Kommt aber leider.

Eigentlich war die Grundidee beim Router selbst aufsetzen ja, die volle Kontrolle über das Regelwerk zu haben.

Gerade weil du die Kontrolle hast, kann sowas passieren. Indem du als root dhclient sagst, sagst du halt implizit: Umgehe die Frewall. Wie gesagt: Unter Windows ist das anders. Da gibt es noch ein System das über deinen Befehlen steht und eventuell Sachen unterbindest. Aber unter Linux ist root halt allmächtig. Und wenn du als root irgend was machst dann kann das eben potentiell alle Konsequenzen haben.

[wanne]

Kann ich irgendwie herausfinden, wer noch alles meine Firewall umgehen kann?

Die Antwort ist einfach: root darf das. PUNKT. (Oder User die die cap_raw bekommen haben. Das ist eher unüblich.) root kann auch firewallregeln ändern (und zurück ändern) und logs löschen. Wer root ist darf halt alles. Ist noch nicht so, wie bei Windows, dass es da einen System-User gibt, der mehr als der admin user darf und eventuell einschränkt, was root darf. Kommt aber leider.

Eigentlich war die Grundidee beim Router selbst aufsetzen ja, die volle Kontrolle über das Regelwerk zu haben.

Gerade weil du die Kontrolle hast, kann sowas passieren. Indem du als root dhclient sagst, sagst du halt implizit: Umgehe die Frewall. Als root darfst du beliebig "dumme" Programme schreiben oder kopieren. Wie gesagt: Unter iOS oder so ist das anders. Da gibt es noch ein System das über deinen Befehlen steht und gewisse Programme unterbindet. Aber unter Linux ist root halt allmächtig. Und wenn du als root irgend was machst dann kann das eben potentiell alle Konsequenzen haben.
Deswegen willst du ungern Programme als root laufen lassen. Nutzer unterschätzen die Bedeutung immer wieder und fordern dass das einschränkbar ist. Aber das resultat wäre dann halt dass es dann einen Superroot geben müsste, wenn alles wie zuvor möglich sein sollte. Und die Programme die jetzt als root laufen wollen würden dann halt verlangen als Superroot zu laufen. Zum einschränken könnte man dann einen Superallesroot erfinden...

[TRex]

Alles, was mit root läuft, kann das. Sollten nun alle verstanden haben. Die Frage ist aber: tut dhclient das auch?

Indem du als root dhclient sagst, sagst du halt implizit: Umgehe die Frewall

Hab ich nicht gesagt und nicht erwartet. Ob das impliziert wird (d.h. in dhclient einprogrammiert ist), interessiert nun zumindest mich.

In den Quellen von isc-dhcp-client finde ich 0 Zeilen mit nftables, iptables und firewall nur als Erwähnung in der Readme (dass man seine firewall entsprechend konfigurieren muss). I call bullshit

[MSfree]

Es gibt kein Programm, das nftables umgehen kann. Auch nicht solche, die mit raw Sockets arbeiten. nftable und auch iptables werden vom Kernel immer als erstes abgehandelt, bevor irgendein Programm im Userpsace an das Paket rankommt. Wenn nftables DHCP-Pakete blockiert, dann funktioniert weder der dhclient noch der dhcp-Server.

Die einzige Hintertür ist, daß Programme, die mit root-Rechten laufen, auch die nftables-Regeln neu einstellen können, und somit Regeln ausser Kraft setzen können.

[mat6937]

Ob das impliziert wird (d.h. in dhclient einprogrammiert ist), interessiert nun zumindest mich.

Z. B. in FreeBSD ist der dhclient-Hauptprozess (hier PID 17238) in einer Sandbox und es wird ein zusätzlicher dhclient_Prozess unter dem user "_dhcp" gestartet:

Code: Alles auswählen

:~ # sockstat -c | grep -i dhclient
_dhcp    dhclient   17241 4  stream -> ??
root     dhclient   17238 4  stream -> ??

[mat6937]

Auch nicht solche, die mit raw Sockets arbeiten.

Manche sagen das Gegenteil. Z. B.:

None of those times though did I realize that dhclient uses raw sockets and that iptables is unable to block those connections.

Quelle: https://diablohorn.com/2013/11/28/qp-ra ... -iptables/

[str]

Danke mat6937, dieser Link war genau die Info, nach der ich gesucht hatte und sie mit meinen Suchworten nicht gefunden habe.

Womit ich jetzt aber wieder zu der Frage komme, ob es noch mehr Kandidaten gibt, die an meinem Ruleset vorbei arbeiten (können).
Die will ich ja nicht gleich verurteilen, dhclient z. B. hätte ich die Rechte natürlich sowieso erteilt.
Aber ich möchte wenigstens davon wissen um eventuelle "zweifelhafte Kandidaten" bei Bedarf anders in ihre Schranken zu weisen.

[wanne]

Die Frage ist aber: tut dhclient das auch?

nein. Aber er benutzt raw sockets.
Passende Man Page.

Normally a DHCPv4 client will open a raw UDP socket to receive and send most DHCPv4 packets. It also opens a fallback UDP socket for use in sending unicast packets.

Ich glaube der.

Es gibt kein Programm, das nftables umgehen kann.

Bullshit.

Auch nicht solche, die mit raw Sockets arbeiten.

Bullshit.

nftable und auch iptables werden vom Kernel immer als erstes abgehandelt, bevor irgendein Programm im Userpsace an das Paket rankommt.

Bullshit. Guck dir wireshark oder ariodump an. Guck dir ettercap oder arireplay an. Guck dir traceroute an. Guck dir dir arp an. Guck dir die libpcap an.

Wenn nftables DHCP-Pakete blockiert, dann funktioniert weder der dhclient noch der dhcp-Server.

Quatsch.

Die einzige Hintertür ist, daß Programme, die mit root-Rechten laufen, auch die nftables-Regeln neu einstellen können, und somit Regeln außer Kraft setzen können.

Nein. Wie gesagt raw sockets sind ne Hintertür. Zusätzliche Interfaces ne 2. Manipulieren des kernelspaces die 3. direktes ansprechen ansprechen der Kartentreiber ne 4. Und ich wette es gibt nochmal 20 Möglichkeiten, die mir gerade nicht einfallen.

[mat6937]

Womit ich jetzt aber wieder zu der Frage komme, ob es noch mehr Kandidaten gibt, die an meinem Ruleset vorbei arbeiten (können).
Die will ich ja nicht gleich verurteilen, ...

Schau mal mit:

Code: Alles auswählen

netstat -p -a --raw -n4

nach, ob der dhclient und mehr, angezeigt wird bzw. werden.
Bei mir habe ich den aktiven dnsspoof (mit raw auf dem Port 255) entdeckt:

Code: Alles auswählen

:~ # netstat -p -aw -n4
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
raw        0      0 0.0.0.0:255             0.0.0.0:*               7           1088/dnsspoof   
raw        0      0 0.0.0.0:255             0.0.0.0:*               7           744/dnsspoof    
raw        0      0 0.0.0.0:255             0.0.0.0:*               7           745/dnsspoof    

[str]

netstat -p -a --raw -n4

...liefert bei mir keine Ausgabe.

Werde ich nochmal abfragen, wenn alle benötigten Dienste installiert und konfiguriert sind.
Danke für den Tip!

[habakug]

Hallo,

@Wanne hatte schon die Doku von ISC-DHCP erwähnt [1]:

DHCP with firewalls and packet filters
dhcpd's raw sockets receive packets before the point at which most OS packet filters and firewalls operate, which means that if you want to reliably intercept packets before they reach the DHCP server, it is better to do this externally to the server itself.

Das Interface z.B. in "netstat" ist nur das "fallback interface" [2].
Das alles ist notwendig um auf einer Broadcast-Adresse (255.255.255.255 oder "all-ones") in der lokalen Broadcastdomäne zu senden und zu empfangen und vor allem Unicast ohne ARP zu machen.

Gruss, habakug

[1] https://kb.isc.org/docs/aa-00378
[2] https://kb.isc.org/docs/aa-00379