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

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

Estou executando o Ubuntu 16.04. Eu tenho o ufw instalado e habilitado. Eu também tenho o servidor isc-dhcp instalado. 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 revisei os 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 posso entender). Também não me parece que o ufw tenha configurado o IPTABLES para aceitar tráfego de transmissão. O ufw deveria permitir ou bloquear o tráfego de transmissão?

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 não obtiver primeiro uma resposta da transmissão na porta UDP 67? Nesse caso, pode fazer sentido que as solicitações DHCP estejam indo para o servidor, porque então a regra UFW para permitir solicitações de clientes DHCP de saída permitiria solicitações de clientes DHCP de entrada.

O estado 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                  

Responder1

Eu estava muito cansado para abrir as portas adequadas em meu firewall antes de começar a testar meu servidor DHCP novinho em folha, e demorei um pouco para perceber que ele ainda não deveria funcionar. Nunca abri a porta 67 no firewall do meu servidor.

...

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

Por Mark Andrews do isc.org:

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

http://thr3ads.net/netfilter-buglog/2011/07/1961358-Bug-730-New-DHCP-request-and-other-traffic-bypasses-iptables-netfilter

--https://www.centos.org/forums/viewtopic.php?t=8728


Costuma-se afirmar que isso ocorre porque o servidor DHCP usa soquetes brutos. Acho que essa frase é bastante confusa. Alguns documentos oficiais do ISC para seu servidor DHCP usam "soquetes brutos" como um termo amplo, porque ele pode ser executado em diversas plataformas diferentes, onde deve usar diversas interfaces diferentes. No Linux, há mais de um tipo que você pode chamar de soquetes brutos. Alguns são afetados pelo Linux iptables 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 era que o DHCP no Linux não funciona necessariamente com esse tipo de soquete e pode ser necessário usar "soquetes de pacotes". Os soquetes de pacotes funcionam em um nível inferior. Estou confiante de que os soquetes de pacotes não são afetados pelo iptables.

Os soquetes PF_PACKET ignoram a pilha TCP/IP.

Os soquetes PF_INET/SOCK_RAW ainda atravessam a pilha TCP/IP.

--https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html

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 seria de esperar.


Parece que iptables é uma das restrições que se aplica à pilha TCP/IP, inclusive ao envio com PF_INET+SOCK_RAW.

Se eu tiver um datagrama IP no espaço do usuário e enviá-lo através de um soquete bruto criado com socket(PF_INET, SOCK_RAW, IPPROTO_RAW) usando a chamada de sistema send(), este pacote atravessará as cadeias do netfilter?

...

parece uma boa notícia:

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

Portanto, seus pacotes atravessarão o iptables.

https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html

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

Acontece que o uso de soquetes brutos me fornece os pacotes pós-NAT, de modo que os endereços IP voltam ao intervalo privado (10.xxx no meu exemplo). Talvez isso seja de conhecimento comum, mas tenho me esforçado para encontrá-lo documentado. Se eu usar libpcap/tcpdump, recebo pacotes pré-NAT

[NAT é realizado por iptables]

--https://lists.gt.net/iptables/user/62529#62529


Reclamação bônus: eupensaro termo "filtro de pacotes" na minha citação inicial é um abuso direto, embora de longa data. Berkeley Packet Filter é um mecanismo usado para instalar um filtro em um soquete bruto, por exemplo, para que ele receba apenas pacotes na porta DHCP. Acho que o ISC às vezes se refere ao "Filtro de Pacotes Linux" como se fosse um tipo de soquete bruto. Não é, e você pode usar o BPF em soquetes UDP ou TCP normais.

informação relacionada