Firewall do Windows com Segurança Avançada - vazamento de DHCP?

Question

Quando eu inicio o programa dhcptest.exe (no Win7), recebo um aviso de firewall. O bloqueio cria duas novas regras de entrada, bloqueando o TCP e o UDP. (sem regras de saída). Quando eu executo o teste, ele envia uma solicitação DHCP (sem surpresa) e recebe uma resposta DHCP (WTF?). A resposta do DHCP chega claramente ao executável, que o reporta.

Existe, é claro, uma regra de entrada DHCP que permite ao cliente DHCP receber respostas DHCP, mas o cliente não está aceitando as novas ofertas DHCP - e não importa de qualquer maneira, quando eu desabilito essa regra, o dhcptest.exe programa ainda está relatando a oferta DHCP.

Como, por quê? As ofertas DHCP são um protocolo de transmissão sem conexão, portanto, não é como se ele estivesse entrando em uma conexão criada pela solicitação de saída.

O que estou perdendo?

    

Answer 1

O programa primeiro começa a escutar na porta 68. Isso dispara a mensagem do firewall. As mensagens que o Windows mostra são apenas sobre "servidores". Conexões de saída não são afetadas.

Então, quando você seleciona para enviar uma solicitação DHCP, é criada uma associação. Esta associação permite que as respostas cheguem ao programa.

O Windows percebe que o programa está enviando para o endereço de broadcast e, como tal, permite que as respostas cheguem. Caso contrário, um programa nunca poderia realizar a descoberta de serviços na rede local.

O UDP é de fato sem conexão. No entanto, o rastreamento de “conexão” ainda é necessário em muitos casos, como firewalls com informações de estado ou NAT. Quando um pacote é enviado, uma associação temporária é criada. Ela expira depois de algum tempo sem tráfego.

Do artigo “Como funciona o Firewall do Windows” ( ênfase minha):

Because UDP is a connectionless protocol and has no sequence numbers or flags, it has no mechanism for terminating and closing a connection. Therefore, the timeout for UDP connections is much shorter than that for TCP connections. The timeout for established but inactive UDP connections is 60 seconds. In other words, if an established UDP connection is inactive for 60 seconds, the state table entry for that connection is removed from the NAT Mapping Table. This behavior applies to UDP connections on all ports.

There are some exceptions to the 60-second timeout for UDP connections. When a computer sends a multicast or broadcast message, Windows Firewall waits for up to 3 seconds for a unicast response. In essence, the state table entry for multicast or broadcast connections is maintained for up to 3 seconds; if the multicast or broadcast connection is inactive for 3 seconds (that is, there is no response), then the state table entry is deleted from the NAT Mapping Table. Dynamic Host Configuration Protocol (DHCP) multicast messages are a special case and are exempt from the 3-second timeout.