UDP-Filtering IPTABLES

[Misterzde]

Hallo zusammen,

habe eine Verständnisfrage:

DHCP-Anfragen via UDP Port 68 (dhclient) sollen mit iptables gefiltert werden, dazu werden folgende Rules gesetzt:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p udp --dport 67 -j DROP
iptables -A INPUT -p udp --dport 68 -j DROP
iptables -A OUTPUT -p udp --dport 67 -j DROP
iptables -A OUTPUT -p udp --dport 68 -j DROP

Leider funktioniert das nicht wirklich über eth1, der dhclient bekommt weiterhin eine neue DHCP-Adresse vom DHCP-Server (in diesem Fall der Router).

Bei einem uralt Windows 2000 kann ich hingegen die UDP-Ports über den IP-Filter von Windows blockieren - Windows bekommt dann keine IP mehr vom DHCP-Server.

Was mache ich falsch mit IPTABLES? Sollte doch eigentlich funktionieren? Oder bleibt der Port 68 aus Kompatibilitätsgründen absichtlich offen?

Danke für einen Tipp!

[Dimejo]

DHCP-Anfragen via UDP Port 68 (dhclient) sollen mit iptables gefiltert werden, dazu werden folgende Rules gesetzt:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p udp --dport 67 -j DROP
iptables -A INPUT -p udp --dport 68 -j DROP
iptables -A OUTPUT -p udp --dport 67 -j DROP
iptables -A OUTPUT -p udp --dport 68 -j DROP

Leider funktioniert das nicht wirklich über eth1, der dhclient bekommt weiterhin eine neue DHCP-Adresse vom DHCP-Server (in diesem Fall der Router).

DHCP benutzt zur Kommunikation normalerweise raw sockets (also weder UDP noch TCP), womit iptables "übergangen" wird.

[dufty2]

DHCP benutzt zur Kommunikation normalerweise raw sockets (also weder UDP noch TCP), womit iptables "übergangen" wird.

Nun, der superdolle DHCP Server von ISC benutzt raw sockets.
dhclient (auch von ISC) ist noch gemeiner, denn jenes nimmt PACKET sockets,
die sind so gemein, die kann netstat nicht mal anzeigen
Nimm

Code: Alles auswählen

# ss -f link -n -l -p

[Misterzde]

DHCP benutzt zur Kommunikation normalerweise raw sockets (also weder UDP noch TCP), womit iptables "übergangen" wird.

Nun, der superdolle DHCP Server von ISC benutzt raw sockets.
dhclient (auch von ISC) ist noch gemeiner, denn jenes nimmt PACKET sockets,
die sind so gemein, die kann netstat nicht mal anzeigen
Nimm

Code: Alles auswählen

# ss -f link -n -l -p

Hmm, was macht das für einen Sinn? Damit wird ja der normale TCP/IP-Stack übergangen:

"Während Stream Sockets und Datagram Sockets den TCP- bzw. UDP-Header eines Datenpakets normalerweise verbergen und automatisch setzen, lassen Raw Sockets (Raw: roh) das Erstellen eigener TCP- und UDP-Header zu. Raw Sockets werden am ehesten in netzwerknahen Applikationen verwendet, z. B. für Router, Packet-Sniffer oder bei Packet-Injection."

Ein DHCP-Client ist ja eigentlich eine relativ einfache Standardapplikation, die normalerweise mit UDP arbeiten sollte (gemäss RFC 2131). Warum wird das nicht mit "Datagram-Sockets" gearbeitet? Dürfte doch ggf. auch einfacher auf andere Plattformen zu portieren sein, wenn auf einem Layer weiter oben angesetzt wird.

Es ist ja auch streng genommen so nicht konforum zu RFC 2131....

Kann Ich den Datenverkehr von Raw-Sockets im Linux-Kernel irgendwie kontrollieren?

[Misterzde]

https://deepthought.isc.org/article/AA- ... ckets.html

Question:

How does DHCP use raw sockets? Is it possible not to use them?
Answer:
The DHCP protocol has some odd requirements to really work properly. Being able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP.

In order to both reliably receive and transmit these packets in a way that conforms with RFC 2131, we have to use platform-flavor specific raw sockets. For example on SUSE that's what we call "LPF" - the Linux' version of the BPF device. You should see LPF/interface/MAC lines logged when dhcpd starts, these are the raw sockets initializing.

When operating in this mode, dhcpd opens the raw sockets, and a backup BSD/UDP socket (called the "fallback interface"), which you will be seeing in netstat.

This mode of operation is the default at compile time, because it is the most compatible and general.

The raw socket:

Receives all DHCP packets - so the DHCP packet sent to the server must come in on the interface the socket is opened on.
Transmits directed unicasts (w/out ARP), and special RFC 2131 complying all-ones limited broadcasts (rather than the subnet broadcast address you may get from the BSD/UDP interface). These are needed in clients' initial configuration stage (when the client does not yet have an address configured).

The BSD/UDP socket:

Is read from to empty it and free up buffers, but all packets read from this socket are immediately discarded. The reason for this is that in the expected operating mode, these packets are all duplicates of packets received via the raw socket.
Is used to transmit routed unicasts, so we don't have to implement IP routing in 'dhcpd'. This is used to reply to any relay agent, or to reply to clients apparently in the RENEWING state.

You can compile raw socket behaviour out, and it may sometimes be advisable for performance and simplicity reasons, but administrators should understand the limitation that the DHCP server will no longer be able to send unicast replies to clients on the same broadcast domain as the DHCP server. Any clients for who this would be a problem must instead be situated where they are reached via relay agents. It may be hard to maintain this limitation in an installed system across administrators, as networks grow and ebb. Raw sockets do not negatively impact most users' performance in a meaningful way, so it is not recommended to disable it.

Disabling raw sockets in DHCP

From 4.1-ESV-R3 and 4.2.2 onwards, you can use experimental configure option --enable-use-sockets. Note that this feature is Operating System-dependent - it will not work in all environments. Also note however that it is specifically intended and recommended for users of Solaris 11: Building ISC DHCP on Solaris 11

Prior to the introduction of the --enable-use-sockets option you could disable raw socket behaviour by defining USE_SOCKETS in site.h.

[dufty2]

Das ist ja alles ganz nett, aber hauptsächlich geht's in dem Artikel um den DHCP Server (dhcpd) von ISC.
Den dhclient haben sie nach dem Server gebastelt, um möglichst viel Code uebernehmen zu können.

Aber niemand hindert Dich daran, einen anderen DHCP client zu benutzen in Debian, z. B. den "udhcpc".
Der lauscht ueberhaupt nicht, so weit ich das sehen konnte:
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK und fertisch.

[Misterzde]

Hmm, dann werde ich den "udhcpc" mal testen demnächst.

Ich sehe aber noch ein ganz anderes Problem:

Der isc-dhcp-client lauscht ja offensichtlich über Raw-Sockets (sonst würde ich beim Filter über iptables keine IP-Adresse bekommen, ist ja auch so dokumentiert.

Der Befehl ss -w listet bei mir mit laufendem dhclient aber keinerlei aktive "Raw-Sockets". Es ist also anscheinend möglich dem Linux-Kernel Programme unterzuschieben, die unbemerkt auf Raw-Sockets lauschen und dort beliebige Daten empfangen und senden können. Viren, Trojaner, etc.

[DeletedUserReAsG]

Aber niemand hindert Dich daran, einen anderen DHCP client zu benutzen […]

Infame Unterstellungen!

[NAB]

Der Befehl ss -w listet bei mir mit laufendem dhclient aber keinerlei aktive "Raw-Sockets".

Vielleicht wäre ss -w -a zielführender.

Es ist also anscheinend möglich dem Linux-Kernel Programme unterzuschieben, die unbemerkt auf Raw-Sockets lauschen und dort beliebige Daten empfangen und senden können. Viren, Trojaner, etc.

Ja, natürlich ist das möglich. Es gibt sogar Viren, die docken direkt an der Netzwerkkarte an und bringen ihren kompletten eigenen Netzwerkstack mit, um dem Betriebssystem bloß nicht aufzufallen. Du wirst es nicht hören wollen, aber die meisten davon laufen unter Windows.

Das wäre jetzt der richtige Augenblick, um Zweifel an deinem Konzept einer Personal Firewall zu kriegen ... aber ich glaube, dazu ist es noch zu früh.

[dufty2]

Der Befehl ss -w listet bei mir mit laufendem dhclient aber keinerlei aktive "Raw-Sockets". Es ist also anscheinend möglich dem Linux-Kernel Programme unterzuschieben, die unbemerkt auf Raw-Sockets lauschen und dort beliebige Daten empfangen und senden können. Viren, Trojaner, etc.

Nein, wie ich oben schon versucht habe zu erklären, gibt es zwei Arten von raw-sockets,
einmal die normalen ("AF_INET,SOCK_RAW"), die auch schon "netstat" anzeigen würde und einmal die packet sockets ("PF_PACKET,SOCK_RAW" bzw. "PF_PACKET,SOCK_DGRAM") [1].
Und dafür brauchst Du "ss", genauer "ss -f link".

Desweiteren ist Öffnen von raw/packet sockets nur root erlaubt und ergo hättest Du dann im Fall eines "Viren/Trojaner-Befalls" eh schon "verloren", da sich jene Schädlinge bereits zu root emporgeschwungen hätten.
Dann könnten sie aber auch gleich die iptables ausschalten

[1] http://yusufonlinux.blogspot.de/2010/11 ... -copy.html

[whiizy]

Alles sehr interessant, ich hätte gar nicht gedacht, was sich hinter einem gewöhnlichen dhcp-client so alles verbirgt. Der gängige dhclient (von isc.org) lauscht also neben UDP Port 68 auch noch auf einem Socket, der wie folgt zu erkennen ist, richtig?

Code: Alles auswählen

# ss -f link -nlp
Netid State      Recv-Q Send-Q    Local Address:Port      Peer Address:Port 
p_dgr UNCONN     0      0                     *:eth0                  *      users:(("dhclient",pid=928,fd=5))

Das war es dann aber auch, oder?

[Misterzde]

Hmm, jetzt wird es aber spannend:

dhclient läuft:

root@debian6:~# netstat -anp |grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2017/dhclient
unix 2 [ ] DGRAM 6473 2017/dhclient

iptables sind gesetzt:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

(auch wenn ich explizit noch die UDP-Ports 67 und 68 sperre bleibt es gleich)

Linux bekommt weiterhin DHCP-Adresse vom Router und trotzdem zeigt das ss-utility nichts an:

root@debian6:~# ss -f link -nlp
Netid Recv-Q Send-Q Local Address:Port Peer Address:Port
root@debian6:~#

Wie kann das sein?

root@debian6:~# uname -a
Linux debian6 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC 2014 x86_64 GNU/Linux
root@debian6:~#

Ich bin verwirrt ?!?

[whiizy]

Wie kann das sein?

Meines Erachtens bleibt dann nur noch dein unix 2 Socket für die Kommunikation übrig:

root@debian6:~# netstat -anp |grep dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 2017/dhclient
unix 2 [ ] DGRAM 6473 2017/dhclient

Vielleicht arbeitet das ss-Kommando auf einem 2.6x-Kernel auch anders, als auf (m)einem 3.x-Jessie-Kernel. Das ist aber wohlgemerkt nur Spekulation von mir und verwirrt bin ich nun auch

[Misterzde]

Hmm, werde das bei Gelegenheit noch einmal mit Debian 7 testen, das ist dann der 3er-Kernel....

[whiizy]

Nicht zu vergessen auch die unterschiedlichen Versionen des dhclient, hier bspw.
ii isc-dhcp-client 4.3.1-6 amd64

[dufty2]

Mmh, kann ich Dir jetzt auch nicht sagen, warum es bei Dir nicht geht,
unter Debian 8 (jessie) geht es jedenfalls:

Code: Alles auswählen

# ss -f inet -nlp | grep dhcl
p_dgr  UNCONN     0      0                      *:wlan0                  *      users:(("dhclient",pid=1209,fd=5))
u_dgr  UNCONN     0      0                      * 16819                 * 8089  users:(("dhclient",pid=1209,fd=3))
udp    UNCONN     0      0                      *:59330                 *:*      users:(("dhclient",pid=1209,fd=20))
udp    UNCONN     0      0                      *:68                    *:*      users:(("dhclient",pid=1209,fd=6))

Mit der "inet"-Family werden neben den beiden UDP-Sockets auch das unix-socket und das packet-socket gelistet.

Vergleiche mal mit

Code: Alles auswählen

# udhcpc -i wlan0 -f
<snip>

# ss -f inet -nlp | grep udh
#

Eine Möglichkeit wäre noch "lsof" mit der Prozessnummer (pid), also bei mir 1209:

Code: Alles auswählen

# lsof -p 1209 -n
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME
<snip>
dhclient 1209 root    0r   CHR                1,3      0t0     1037 /dev/null
dhclient 1209 root    1w   CHR                1,3      0t0     1037 /dev/null
dhclient 1209 root    2w   CHR                1,3      0t0     1037 /dev/null
dhclient 1209 root    3u  unix 0xffff88003af324c0      0t0    16819 socket
dhclient 1209 root    4w   REG              254,1     1527 14221320 /var/lib/NetworkManager/blahblub
dhclient 1209 root    5u  pack              17693      0t0      ALL type=SOCK_PACKET
dhclient 1209 root    6u  IPv4              17695      0t0      UDP *:bootpc 
dhclient 1209 root   20u  IPv4              16820      0t0      UDP *:59330

Da taucht es wieder auf, das "SOCK_PACKET"; unter Debian 8 jedenfalls.

[Misterzde]

Mit lsof zeigt er den PACKET_SOCKET auch unter Debian 6 an:

root@debian6:~# lsof |grep 1938
dhclient 1938 root cwd DIR 8,17 4096 2 /
dhclient 1938 root rtd DIR 8,17 4096 2 /
dhclient 1938 root txt REG 8,17 487728 15067286 /sbin/dhclient
dhclient 1938 root mem REG 8,17 51728 6930434 /lib/libnss_files-2.11.3.so
dhclient 1938 root mem REG 8,17 1437064 6930443 /lib/libc-2.11.3.so
dhclient 1938 root mem REG 8,17 128744 6930439 /lib/ld-2.11.3.so
dhclient 1938 root 0u CHR 1,3 0t0 580 /dev/null
dhclient 1938 root 1u CHR 1,3 0t0 580 /dev/null
dhclient 1938 root 2u CHR 1,3 0t0 580 /dev/null
dhclient 1938 root 3u unix 0xffff88042c3a1800 0t0 6279 socket
dhclient 1938 root 4r REG 8,17 1038 3599166 /var/lib/dhcp/dhclient-ad9c6947-1e96-4839-a90c-354c319481e9-eth1.lease
dhclient 1938 root 5w pack 6289 0t0 ALL type=SOCK_PACKET
dhclient 1938 root 6u IPv4 6291 0t0 UDP *:bootpc

Da bin ich aber beruhigt, dass das nicht am Kernel liegt. Habe mal den russischen Entwickler eine Mail bezüglich des Bugs geschrieben.

P.S.

Das "Device" 6289 taucht auch im Proc-Filesystem unter /proc/net/packet auf, handelt sich also wohl wirklich nicht um einen Fehler im Linux-Kernel.

root@debian6:/proc/net# more packet
sk RefCnt Type Proto Iface R Rmem User Inode
ffff88042c325000 3 10 0003 2 1 0 0 6289
root@debian6:/proc/net#

[whiizy]

Hmm, werde das bei Gelegenheit noch einmal mit Debian 7 testen, das ist dann der 3er-Kernel....

Debian 7 (Wheezy) scheint das "evolutionäre Bindglied" zu sein, es verhält sich nochmal anders als Vor- und Nachfahre. Von beiden hat es etwas:

Der Befehl ss zeigt schon den packet socket in der link-Familie, aber unterschlägt den dhclient noch in der inet-family:

Code: Alles auswählen

# ss -f link -nlp | grep dhclient
p_dgr  UNCONN     0      0                      *:eth0                   *      users:(("dhclient",3016,5))

# ss -f inet -nlp | grep dhcl
#

PS: Dieser wheezy kernel ist allerdings ein rt-kernel, nur zur Erwähnung.

[Misterzde]

So, habe nun udhcpc getestet und gleich dauerhaft aktiviert.

Habe den Network-Manager weiterhin am laufen, allerdings auf feste IP-Adresse konfiguriert.

Diese feste IP wird das von udhcpc in rc.local "überschrieben"

udhcpc -i eth1 -q

Durch die Option "-q" läuft er auch nicht im Hintergrund sondern beendet sich sofort wieder.

[Misterzde]

So, noch ein kurzes Update zum Thema SS-Utility:

Ich hatte den Fehler sowohl an den Entwickler aus Russland als auch an Debian gemeldet.

Die Russen wollten leider keinen Fehler erkennen und bei Debian verwies man mich darauf, dass bei Debian 6 nur Security-Fixes gemacht würden (das wäre meiner Meinung nach einer )
"Backport" gäbe es nur noch für Debian 7, bla, bla bla

So viel zum Support bei Linux und Debian....

Das Problem lässt sich aber einfach lösen.

1. Download aktuellste Version von https://www.kernel.org/pub/linux/utils/net/iproute2/
2, Archiv in temporäres Verzeichnis laden, in dieses Verzeichnis wechseln
3. make
4. in Verzeichnis "misc" wechseln, dort ist das neue "ss".

Output alt:

ss utility, iproute2-ss100519

root@debian6:/home/felix/SS/iproute2-3.19.0/misc# ss -0
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
root@debian6:/home/felix/SS/iproute2-3.19.0/misc#


Output neu:

root@debian6:/home/felix/SS/iproute2-3.19.0/misc# ./ss -0
Netid Recv-Q Send-Q Local Address:Port Peer Address:Port
RTNETLINK answers: Invalid argument
p_dgr 0 0 *:eth1 *
root@debian6:/home/felix/SS/iproute2-3.19.0/misc#

Wie wird man eigentlich zum Supporter bei Debian?