IPTables et questions DHCP?

Sur mon autre fil, je parlais de choses intéressantes sur la politique et les états d'iptables , maintenant j'aimerais mieux comprendre comment fonctionne DHCP et comment iptables le comprend.

ETH0 est connecté à mon commutateur principal qui reçoit l'IP dynamique de mon routeur pour accéder non seulement à Internet mais aussi à mon réseau externe.

ETH1 est la carte interne qui est connectée à un commutateur interne où les clients X reçoivent leur IPS de ce serveur

Le réseau ETH1 est 192.168.1.0/255.255.255.0 où l'adresse IP du serveur est 192.168.1.254.

D'après ce que j'ai compris, dhcp est un protocole bootp, donc même si vous avez vos politiques de pare-feu pour tout supprimer, votre réseau recevrait toujours le DHCP, ce qui, dans les tests que j'ai faits, semblait être vrai.

Depuis tcpdump:

root@test:~# tcpdump -i eth1 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:34:03.943928 IP 192.168.1.2.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:03.957647 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300
11:34:06.492153 IP 192.168.1.2.bootpc > 192.168.1.254.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:06.506593 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300

J'ai créé une règle de journal simple pour voir ce que fait iptables:

root@test:~# tail -f /var/log/syslog
Oct 15 11:30:58 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9527 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:31:43 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9529 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:33:32 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9531 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:34:03 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9533 PROTO=UDP SPT=68 DPT=67 LEN=311

Voici mes règles iptables au momment:

# deny all traffic
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

# Use stateful inspection feature to only allow incoming connections
# related to connections I have already established myself
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow all traffic on lo interface
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

Donc, même avec la POLITIQUE par défaut pour supprimer tout, j'obtiens toujours le DHCP sur mon réseau alors qu'il faut beaucoup plus de temps pour renouveler une IP et autres.

Si j'ajoute la règle de suivi à mon pare-feu:

$IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

Il faudra beaucoup moins de temps pour mettre à jour n'importe quel DHCP client.

Compte tenu de ce qui précède:

1. pourquoi faut-il en effet plus de temps pour le mettre à jour alors qu'il n'était pas bloqué?
2. est-il possible de supprimer le serveur DHCP du tout sans l'éteindre?
3. est-il possible d'accepter le serveur dhcp dans iptables avec le BOOTP? comment cela se fait-il?

Si vous connaissez de bons liens, cela ne me dérangerait pas d'en prendre beaucoup :)

Je répondrai # 2: Non.

Lors de l'obtention d'une adresse IP, le démon dhcp crée un socket brut pour l'interface réseau et gère le protocole UDP lui-même. Ainsi, les paquets UDP ne passent jamais par iptables.

La raison pour laquelle le démon dhcp doit implémenter UDP est que le noyau ne peut gérer UDP (en fait la totalité de la suite TCP / IP) que lorsque l'interface a une adresse IP. Auparavant, les démons dhcp donnaient d'abord à une interface l'adresse IP de 0.0.0.0 mais cela ne fonctionnait plus.

Ajouter

$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

doit rendre la mise à jour DHCPD plus rapide :) Il doit fonctionner à la fois côté entrée et sortie. Vous pouvez DROP dhcpd avec ebtables, pas avec iptables. DHCPD écoute à 0.0.0.0, pas dans IP

Ma récente observation, sur OpenWRT Kamikaze 7.09 = 2.4.34 et udhcpc de busybox 1.4.2:

J'ai une politique "ACCEPT" dans la chaîne OUTPUT, et dans le sens INPUT, à l'origine je me suis appuyé sur cette règle fourre-tout classique:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

pour autoriser les réponses DHCP dans (à mon udhcpc) ​​sur l'interface WAN. C'est-à-dire que c'est là que le serveur DHCP en amont de mon FAI m'attribue une adresse IP.

Faites attention à la différence entre un échange DHCP initial (découverte, offre, demande, accusé de réception) et un renouvellement de bail DHCP (demande, accusé de réception).

Après le démarrage, udhcpc démarre par l'échange initial complet. Cet échange allait réussir. Et un autre renouvellement ou deux réussirait aussi - juste une demande et un accusé de réception. Le serveur DHCP de mon FAI demande généralement un temps de renouvellement d'environ une heure à 1,5 heure, donc mon client DHCP demande un renouvellement toutes les 30 à 45 minutes (ce comportement est basé sur le RFC).

Mais, vers le troisième ou le quatrième renouvellement, cela commencerait à devenir intéressant. TCPdump afficherait environ trois tentatives de renouvellement, suivies d'un échange initial complet - dans un laps de temps de quelques minutes, voire quelques secondes. Comme si udhcpc n'aimait pas ce qu'il a récupéré :-( et serait finalement satisfait de l'échange complet. Après cela, un autre renouvellement dans une demi-heure réussirait ... et l'histoire se répéterait à nouveau.

J'ai compris que c'est peut-être le suivi des connexions dans le noyau qui a quelque chose de mal. Comme si l'entrée conntrack expirait au bout de deux heures environ, et que les renouvellements DHCP ultérieurs échouaient parce que l'ACK du serveur ne parvient pas réellement à écouter udhcpc sur le socket. Notez que tcpdump (libpcap) écoute sur l'interface brute et peut voir tous les paquets entrant, avant d'être soumis à iptables. Une fois que udhcpc abandonne les renouvellements et, désespéré, essaie de recommencer à zéro en utilisant un échange complet (en commençant par DISCOVER), le noyau établit une nouvelle entrée conntrack et peut comprendre les paquets associés pendant un certain temps ...

Effectivement, une fois que j'ai ajouté quelque chose comme:

iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT

les renouvellements semblent fonctionner pour toujours.

Les arguments de la cmdline tcpdump peuvent être utiles:

tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68

Remarque: le -vvdemande la sortie du dissecteur détaillé. eth0.1est mon port WAN (également une interface "NAT en dehors").

Un attribut intéressant dans les paquets ACK est le champ LT: = durée de bail suggérée / maximale accordée en secondes. Les demandes DHCP sont envoyées du port 68 au port 67. Les réponses proviennent du port 67 au port 68.