UFW / IPTABLES não está bloqueando a porta UDP do DHCP 67?

Question

Estou executando o Ubuntu 16.04. Eu tenho ufw instalado e habilitado. Eu também tenho o isc-dhcp-server instalado. Eu não abri a porta UDP 67, mas os clientes DHCP ainda parecem conseguir obter concessões de DHCP do servidor. Por que é isso? Eu revi o IPTABLES que o ufw cria, e ele tem a porta UDP 68 aberta para um cliente DHCP, mas não a porta UDP 67 (até onde eu entendo). Também não me parece que o ufw configurou o IPTABLES para aceitar o tráfego de broadcast. O ufw deve permitir ou bloquear o tráfego de broadcast?

O IPTABLES tem algum tipo de exceção especial para o tráfego da porta UDP 67?

Um cliente DHCP volta a transmitir na porta UDP 68 se primeiro não recebe uma resposta da transmissão na porta UDP 67? Em caso afirmativo, isso pode fazer sentido de que as solicitações DHCP estejam chegando ao servidor, porque a regra UFW para permitir solicitações de cliente DHCP de saída permitiria solicitações de clientes DHCP de entrada.

O status de ufw status verbose é

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  

    

Answer 1

I was too dump to open up the proper ports on my firewall before I started testing out my shiny new DHCP server, and it took a moment to dawn on me that it shouldn't work yet. I never opened port 67 on my server's firewall.

     

...

     

A resposta simples é que o DHCP é realmente especial. Para citar o que um estranho citou,

     

Per Mark Andrews, do isc.org:

     

"O DHCP usa filtros de pacotes e estes conectam-se à pilha de IP antes do firewall."

     

link

- link

Muitas vezes é dito que isso acontece porque o servidor DHCP usa soquetes brutos. Eu acho que esse fraseado é bastante confuso. Alguns documentos oficiais do ISC para seu servidor DHCP usam "raw sockets" como um termo amplo, porque ele pode ser executado em diversas plataformas diferentes, nas quais ele deve usar várias interfaces diferentes. No Linux, há mais de um tipo que você pode ouvir chamado de soquetes não processados. Alguns são afetados pelo iptables do Linux, e alguns não são afetados pelo Linux iptables .

Estou confiante de que a pilha TCP / IP do Linux impõe algumas restrições ao enviar pacotes com PF_INET + SOCK_RAW. Minha vaga lembrança é que o DHCP no Linux não funciona necessariamente com esse tipo de soquete e talvez precise usar "soquetes de pacotes". Os soquetes de pacote funcionam em um nível inferior. Estou confiante de que os soquetes de pacotes não são afetados pelo iptables.

PF_PACKET sockets bypass the TCP/IP stack.

PF_INET/SOCK_RAW sockets still travers the TCP/IP stack.

- link

Esta citação foi escrita no contexto do recebimento de pacotes. Também há evidências de que isso se aplica ao envio de pacotes, como você poderia esperar.

Parece que o iptables é uma das restrições que se aplicam à pilha TCP / IP, incluindo o envio com PF_INET + SOCK_RAW.

If I have a an IP datagram in userspace and I send it via a raw socket created with socket(PF_INET, SOCK_RAW, IPPROTO_RAW) using the send() system call, will this packet traverse the netfilter chains?

     

...

     

parece uma boa notícia:

ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_tcpmss_target: bad length (10 bytes)

     

Para que seus pacotes percorram o iptables.

link

E a evidência para a direção de recebimento:

It turns out that using raw sockets gives me the packets post-NAT so the IP addresses are back in the private range (10.x.x.x in my example). Maybe this is common knowledge but I've struggled to find it documented. If I use libpcap/tcpdump I get packets pre-NAT

[NAT é executado pelo iptables]

- link

Barulho de bônus: Eu penso que o termo "filtro de pacotes" na minha citação inicial é um abuso direto, ainda que de longa data. O Berkeley Packet Filter é um mecanismo usado para instalar um filtro em uma tomada bruta, por ex. de modo que receba apenas pacotes na porta DHCP. Eu acho que o ISC às vezes se refere ao "Linux Packet Filter" como se fosse um tipo de socket bruto. Não é, e você pode realmente usar BPF em soquetes UDP ou TCP normais.