IPTables e domande DHCP?

Sull'altra mia discussione stavo parlando di alcune cose interessanti sulla politica e gli stati di iptables , ora vorrei capire di più su come funziona il DHCP e su come iptables lo capisce.

ETH0 è collegato al mio switch principale che riceve l'ip dinamico dal mio router per ottenere non solo l'accesso a Internet ma anche l'accesso alla mia rete esterna.

ETH1 è la scheda interna collegata a uno switch interno in cui X client ricevono il proprio IPS da questo server

La rete ETH1 è 192.168.1.0/255.255.255.0 dove l'ip del server è 192.168.1.254.

Da quello che ho capito, dhcp è un protocollo di bootp, quindi anche se si hanno i criteri del firewall per DROP tutto, la rete riceverebbe comunque il DHCP, che nei test che ho fatto sembrava essere vero.

Da 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

Ho creato una semplice regola di registro per vedere cosa fa 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

Ecco le mie regole iptables al momento:

# 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

Quindi, anche con la POLITICA predefinita per eliminare tutto, ottengo ancora il DHCP sulla mia rete mentre ci vuole molto più tempo per rinnovare un IP e simili.

Se aggiungo la seguente regola al mio firewall:

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

Occorrerà molto meno tempo per aggiornare qualsiasi client dhcp.

Considerando quanto sopra:

1. perché ci vuole davvero più tempo per aggiornarlo anche se non viene bloccato?
2. è possibile DROP il server dhcp senza spegnerlo?
3. è possibile ACCETTARE il server dhcp all'interno di iptables con BOOTP? come è fatto?

Se conosci buoni collegamenti non mi dispiacerebbe prenderne molto :)

Risponderò # 2: No.

Quando si ottiene un indirizzo IP, il demone dhcp crea un socket raw per l'interfaccia di rete e gestisce il protocollo UDP stesso. Pertanto i pacchetti UDP non passano mai attraverso iptables.

Il motivo per cui il daemon dhcp deve implementare UDP è che il kernel può gestire UDP (in effetti tutta la suite TCP / IP) quando l'interfaccia ha un indirizzo IP. In precedenza i demoni dhcp dapprima davano a un'interfaccia l'indirizzo IP di 0.0.0.0 ma questo non funziona più.

Aggiunta

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

deve velocizzare l'aggiornamento di DHCPD :) Funziona sia in ingresso che in uscita. È possibile DROP dhcpd con ebtables, non con iptables. Ascolto DHCPD a 0.0.0.0, non in IP

La mia recente osservazione, su OpenWRT Kamikaze 7.09 = 2.4.34 e udhcpc da busybox 1.4.2:

Ho una politica "ACCETTA" nella catena OUTPUT, e nella direzione INPUT, inizialmente mi basavo su questa classica regola generale:

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

per consentire le risposte DHCP in (al mio udhcpc) ​​nell'interfaccia WAN. Cioè, è qui che il server DHCP upstream del mio ISP mi assegna un indirizzo IP.

Ricorda la differenza tra uno scambio DHCP iniziale (scopri, offri, richiedi, conferma) e un rinnovo del contratto di locazione DHCP (richiedi, conferma).

Dopo l'avvio, udhcpc inizia con lo scambio iniziale completo. Quello scambio avrebbe avuto successo. E anche un altro rinnovo o due avrebbe successo: solo una richiesta e un riconoscimento. Il server DHCP del mio ISP richiede in genere un tempo di rinnovo da circa un'ora a 1,5 ore, quindi il mio client DHCP richiede un rinnovo ogni 30 a 45 minuti (questo comportamento si basa sulla RFC).

Ma, circa il terzo o il quarto rinnovo, inizierebbe a diventare interessante. TCPdump mostrerebbe circa tre tentativi di rinnovo, seguiti da uno scambio iniziale completo, che entro un periodo di pochi minuti o addirittura secondi. Come se a udhcpc non piacesse quello che è tornato :-( e alla fine si accontenterebbe dell'intero scambio. Dopo di che, un altro rinnovo in mezz'ora avrebbe successo ... e la storia si ripeterebbe di nuovo.

Ho capito che forse è il tracking della connessione nel kernel che ha qualcosa che non va. Come se la voce conntrack scade dopo circa due ore e i successivi rinnovi DHCP non riescono perché l'ACK dal server non riesce effettivamente ad ascoltare ascolto sul socket udhcpc. Nota che tcpdump (libpcap) è in ascolto sull'interfaccia non elaborata e può vedere tutti i pacchetti in arrivo, prima che siano soggetti a iptables. Una volta che udhcpc ha rinunciato ai rinnovi e, nella disperazione, cerca di ricominciare da capo usando uno scambio completo (a partire da SCOPRI), il kernel stabilisce una nuova voce conntrack e può capire i pacchetti correlati per qualche altro tempo ...

Abbastanza sicuro, una volta che ho aggiunto qualcosa di simile:

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

i rinnovi sembrano funzionare per sempre.

Potresti trovare utili i seguenti argomenti di cmdline di tcpdump:

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

Nota: -vvchiede l'output dettagliato del dissettore. eth0.1è la mia porta WAN (anche un'interfaccia "NAT outside").

Un attributo interessante nei pacchetti ACK è il LT: campo = tempo di leasing suggerito / massimo concesso in secondi. Le richieste DHCP vengono inviate dalla porta 68 alla porta 67. Le risposte arrivano dalla porta 67 alla porta 68.