No meu outro tópico, eu estava falando sobre algumas coisas interessantes sobre o iptables política e estados , agora eu gostaria de entender mais sobre como o DHCP funciona e como o iptables entende isso.
O ETH0 está conectado ao meu switch principal que recebe o ip dinâmico do meu roteador para obter não apenas acesso à Internet, mas também acesso à minha rede externa.
ETH1 é a placa interna que está conectada a um comutador interno no qual os clientes X recebem seu IPS deste servidor
A rede ETH1 é 192.168.1.0/255.255.255.0, onde o ip do servidor é 192.168.1.254.
Pelo que entendi, o dhcp é um protocolo bootp, portanto, mesmo que você tenha suas políticas de firewall para DROP tudo, sua rede ainda receberia o DHCP, que nos testes que fiz parecia ser verdadeiro.
Do 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
Eu fiz uma regra de log simples para ver o que o iptables faz:
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
Aqui estão minhas regras do iptables no 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
Portanto, mesmo com a POLÍTICA padrão para descartar tudo, eu ainda recebo o DHCP na minha rede, embora demore muito mais para renovar um IP e tal.
Se eu adicionar a regra de acompanhamento ao meu firewall:
$IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
Demora muito menos tempo para atualizar qualquer dhcp de cliente.
Considerando o acima:
Se você conhece bons links eu não me importaria de levar muito:)
Eu respondo # 2: Não.
Ao obter um endereço IP, o daemon dhcp cria um soquete bruto para a interface de rede e manipula o próprio protocolo UDP. Assim, os pacotes UDP nunca passam pelo iptables.
A razão pela qual o daemon dhcp tem que implementar o UDP é que o kernel só pode manipular o UDP (na verdade, todo o conjunto TCP / IP) quando a interface tiver um endereço IP. Anteriormente, os daemons dhcp primeiro dariam a uma interface o endereço IP de 0.0.0.0, mas isso não funciona mais.
Adicionando
$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT
fará atualização do DHCPD mais rápido :) Deverá funcionar tanto no lado INPUT quanto no OUTPUT. Você pode DROP dhcpd com ebtables, não com iptables. DHCPD escutando em 0.0.0.0, não dentro do IP
Minha recente observação, no OpenWRT Kamikaze 7.09 = 2.4.34 e no udhcpc do busybox 1.4.2:
Eu tenho uma política "ACCEPT" na cadeia OUTPUT, e na direção do INPUT, originalmente eu confiei nessa regra clássica de pega-tudo:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
para permitir as respostas do DHCP em (para meu udhcpc) na interface da WAN. Ou seja, é aqui que o servidor DHCP a montante do meu ISP atribui um endereço IP para mim.
Observe a diferença entre uma troca inicial de DHCP (descobrir, oferecer, solicitar, ack) e uma renovação de concessão de DHCP (request, ack).
Após a inicialização, o udhcpc é iniciado pela troca inicial completa. Essa troca teria sucesso. E outra renovação ou duas teria sucesso também - apenas um pedido e reconhecimento. O servidor DHCP do meu ISP normalmente pede um tempo de renovação de cerca de uma hora a 1,5 horas, assim meu cliente DHCP pede uma renovação a cada 30 a 45 minutos (esse comportamento é baseado no RFC).
Mas, sobre a terceira ou quarta renovação, ela começa a ficar interessante. O TCPdump mostraria cerca de três ou mais tentativas de renovação, seguidas de uma troca inicial completa - que duraria apenas alguns minutos ou mesmo segundos. Como se o udhcpc não gostasse do que ele voltou :-( e ficaria satisfeito com a troca completa. Depois disso, outra renovação em meia hora teria sucesso ... e a história se repetiria novamente.
Eu descobri que talvez seja o rastreamento de conexão no kernel que tem algo errado. Como se a entrada conntrack expirasse após duas horas ou mais, e as renovações posteriores do DHCP falharem, porque o ACK do servidor não chega ao udhcpc escutando no soquete. Note que o tcpdump (libpcap) escuta na interface bruta e pode ver todos os pacotes chegando, antes que eles estejam sujeitos ao iptables. Uma vez que o udhcpc desiste de renovações e, em desespero, tenta recomeçar do zero usando uma troca completa (começando com DISCOVER), o kernel estabelece uma nova entrada conntrack e pode entender pacotes relacionados por mais algum tempo ...
De fato, uma vez adicionei algo como:
iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT
as renovações parecem funcionar para sempre.
Você pode encontrar os seguintes argumentos do cmdline tcpdump úteis:
tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68
Nota: o -vv pede a saída detalhada do dissector. eth0.1 é minha porta WAN (também uma interface "NAT externa").
Um atributo interessante nos pacotes ACK é o tempo de concessão LT: campo = sugerido / máximo concedido em segundos. As solicitações DHCP são enviadas da porta 68 para a porta 67. As respostas vêm da porta 67 para a porta 68.