Ich verwende Ubuntu 16.04. Ich habe ufw installiert und aktiviert. Ich habe auch isc-dhcp-server installiert. Ich habe UDP-Port 67 nicht geöffnet, aber DHCP-Clients scheinen trotzdem DHCP-Leases vom Server erhalten zu können. Warum ist das so? Ich habe die von ufw erstellten IPTABLES überprüft und es hat UDP-Port 68 für einen DHCP-Client geöffnet, aber nicht UDP-Port 67 (soweit ich weiß). Es sieht für mich auch nicht so aus, als ob ufw IPTABLES so konfiguriert hätte, dass Broadcast-Verkehr akzeptiert wird. Soll ufw Broadcast-Verkehr zulassen oder blockieren?
Verfügt IPTABLES über eine Art Sonderausnahme für den Datenverkehr über UDP-Port 67?
Greift ein DHCP-Client auf Broadcasting auf UDP-Port 68 zurück, wenn er nicht zuerst eine Antwort vom Broadcasting auf UDP-Port 67 erhält? Wenn ja, könnte es Sinn ergeben, dass die DHCP-Anfragen ihren Weg zum Server finden, denn dann würde die UFW-Regel zum Zulassen ausgehender DHCP-Client-Anfragen auch eingehende DHCP-Client-Anfragen zulassen.
Der Status von ufw status verboseist
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
Antwort1
Ich war zu dumm, die richtigen Ports meiner Firewall zu öffnen, bevor ich mit dem Testen meines nagelneuen DHCP-Servers begann, und es dauerte einen Moment, bis mir klar wurde, dass es noch nicht funktionieren sollte. Ich habe Port 67 der Firewall meines Servers nie geöffnet.
...
Die einfache Antwort ist, dass DHCP tatsächlich etwas Besonderes ist. Um zu zitieren, was ein Fremder zitierte:
Laut Mark Andrews von isc.org:
„DHCP verwendet Paketfilter und diese greifen in den IP-Stapel vor der Firewall ein.“
--https://www.centos.org/forums/viewtopic.php?t=8728
Es wird oft behauptet, dass dies daran liegt, dass der DHCP-Server Raw Sockets verwendet. Ich finde diese Formulierung ziemlich verwirrend. Einige offizielle ISC-Dokumente für ihren DHCP-Server verwenden „Raw Sockets“ als weit gefassten Begriff, da er auf einer Reihe verschiedener Plattformen ausgeführt werden kann und dort eine Reihe verschiedener Schnittstellen verwenden muss. Unter Linux gibt es mehr als einen Typ, den Sie möglicherweise als Raw Sockets bezeichnet hören. Einige sind von Linux iptables betroffen, andere nicht.
Ich bin überzeugt, dass der TCP/IP-Stack von Linux beim Senden von Paketen mit PF_INET+SOCK_RAW einige Einschränkungen mit sich bringt. Ich erinnere mich vage, dass DHCP unter Linux nicht unbedingt mit diesem Socket-Typ funktioniert und stattdessen möglicherweise „Paket-Sockets“ verwendet werden müssen. Paket-Sockets arbeiten auf einer niedrigeren Ebene. Ich bin überzeugt, dass Paket-Sockets von iptables nicht betroffen sind.
PF_PACKET-Sockets umgehen den TCP/IP-Stapel.
PF_INET/SOCK_RAW-Sockets durchlaufen weiterhin den TCP/IP-Stapel.
--https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html
Dieses Zitat wurde im Zusammenhang mit dem Empfangen von Paketen geschrieben. Es gibt, wie zu erwarten, auch Hinweise darauf, dass dies für das Senden von Paketen gilt.
Es scheint, dass iptables eine der Einschränkungen ist, die für den TCP/IP-Stapel gelten, einschließlich des Sendens mit PF_INET+SOCK_RAW.
Wenn ich ein IP-Datagramm im Benutzerbereich habe und es über einen mit socket(PF_INET, SOCK_RAW, IPPROTO_RAW) erstellten Raw-Socket unter Verwendung des Systemaufrufs send() sende, durchläuft dieses Paket dann die Netfilter-Ketten?
...
sieht nach guten Neuigkeiten aus:
ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_tcpmss_target: bad length (10 bytes)Ihre Pakete durchlaufen also iptables.
https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html
Und der Beweis für die Empfangsrichtung:
Es stellt sich heraus, dass ich durch die Verwendung von Raw Sockets die Pakete nach NAT erhalte, sodass die IP-Adressen wieder im privaten Bereich liegen (in meinem Beispiel 10.xxx). Vielleicht ist das allgemein bekannt, aber ich hatte Mühe, es dokumentiert zu finden. Wenn ich libpcap/tcpdump verwende, erhalte ich Pakete vor NAT
[NAT wird von iptables durchgeführt]
--https://lists.gt.net/iptables/user/62529#62529
Bonus-Meckern: IchdenkenDer Begriff „Paketfilter“ in meinem ersten Zitat ist ein offener Missbrauch, wenn auch ein seit langem bestehender. Berkeley Packet Filter ist ein Mechanismus, mit dem ein Filter auf einem Raw Socket installiert wird, z. B. so, dass er nur Pakete über den DHCP-Port empfängt. Ich glaube, ISC spricht manchmal von „Linux Packet Filter“, als wäre es selbst eine Art Raw Socket. Das ist es nicht, und Sie können BPF tatsächlich auf normalen UDP- oder TCP-Sockets verwenden.