iptables descarta alguns pacotes na porta 80 e não sei a causa

Question

Estamos executando um firewall com o iptables em nosso sistema Debian Lenny. Eu mostro apenas as entradas relevantes do nosso firewall.

Chain INPUT (policy DROP 0 packets, 0 bytes)
target  prot opt in out  source     destination         
ACCEPT  all  --  lo *    0.0.0.0/0  0.0.0.0/0
ACCEPT  all  --  *  *    0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
ACCEPT  tcp  --  *  *    0.0.0.0/0  0.0.0.0/0  tcp dpt:80 state NEW

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
target  prot opt in out  source     destination
ACCEPT  all  --  *  lo   0.0.0.0/0  0.0.0.0/0           
ACCEPT  all  --  *  *    0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED 
LOGDROP all  --  *  *    0.0.0.0/0  0.0.0.0/0

Alguns pacotes são descartados a cada dia com mensagens de log como esta:

Feb 5 15:11:02 host1 kernel: [104332.409003] dropped IN= OUT=eth0 SRC=<OWN_IP> DST=<REMOTE_IP> LEN=1420 TOS=0x00 PREC=0x00 TTL=64 ID=18576 DF PROTO=TCP SPT=80 DPT=59327 WINDOW=54 RES=0x00 ACK URGP=0

Por questões de privacidade, substituí os endereços IP por < OWN_IP > e < REMOTE_IP >

Isso não é motivo para qualquer preocupação, mas eu só quero entender o que está acontecendo. O servidor da Web tenta enviar um pacote para o cliente, mas o firewall de alguma forma chegou à conclusão de que esse pacote é "NÃO RELACIONADO" para qualquer tráfego anterior.

Eu configurei um parâmetro do kernel ip_conntrack_ma para um valor alto o suficiente para ter certeza de obter todas as conexões controladas pelo módulo de estado iptables:

sysctl -w net.ipv4.netfilter.ip_conntrack_max=524288

O que é engraçado é que eu consigo uma conexão a cada 20 minutos:

06:34:54
06:52:10 
07:10:48 
07:30:55 
07:51:29 
08:10:47 
08:31:00 
08:50:52
09:10:50
09:30:52 
09:50:49 
10:11:00 
10:30:50 
10:50:56 
11:10:53 
11:31:00 
11:50:49 
12:10:49 
12:30:50 
12:50:51 
13:10:49 
13:30:57 
13:51:01 
14:11:12
14:31:32 
14:50:59 
15:11:02 

Isso é a partir de hoje, mas em outros dias parece que isso também (às vezes a taxa varia).

Qual pode ser o motivo?

Qualquer ajuda é muito apreciada. Atenciosamente Janning

    

Answer 1

Eu tenho visto um problema muito semelhante em meus próprios sistemas e posso ter uma resposta sobre o que está acontecendo.

Aparentemente, o TCP permite que o cliente envie um pacote FIN, e você ACK o pacote FIN, mas ainda mantém sua extremidade da conexão aberta e envia mais dados através dele, enviando seu próprio pacote FIN em algum momento no futuro . Lembro-me de ler que isso foi implementado em algum ponto no Kernel 2.6, embora minha memória sobre este ponto possa ser imprecisa / irrelevante.

Muitos firewalls, incluindo IPTables, não parecem ter implementado isso ainda ou implementado incorretamente e consideram a conexão fechada assim que eles vêem um FIN seguido por um ACK. O resultado disso é que, de vez em quando, meu servidor envia um pacote para um cliente que o firewall acha que não faz parte de uma conexão estabelecida e não é novo e, portanto, descarta isso.

Na prática, eu não vi nenhum dado importante nos pacotes finais que estão sendo descartados, então o efeito são alguns pacotes de reset extra sendo jogados ao redor e algumas conexões extras deixadas no estado FIN_WAIT, mas não quebradas ou páginas carregadas.

Eu não sei sobre o tempo de 20 minutos que você está vendo, mas eu acho que é um tipo de cliente que funciona regularmente a cada 20 minutos e faz um pedido que faz com que seu servidor execute a sequência FIN ACK PSH FIN RST .

Esta postagem pode oferecer mais informações sobre o motivo pelo qual o IPTables descarta esses pacotes: link

De acordo com Chris Brenton, é uma incompatibilidade entre os tempos limite do cliente, o servidor e o firewall para os pacotes no estado fechado de um lado.

    

Answer 2

O IP de origem / origem é exibido nessa saída de log? Se sim, esse IP mostra alguma requisição válida nos registros http? Talvez um sistema de monitoramento de algum tipo esteja verificando o http no seu servidor, já que você disse que ele estava em intervalos consistentes. Apenas jogando coisas lá fora.

    

Answer 3

Se alguém tentar verificar você enviando pacotes ACK e seu firewall solicitar um STATE (uma conexão estabelecida), ele será descartado.

Os firewalls sem monitoramento de estado descartam apenas os pacotes SYN recebidos e permitem que o ACK entre. Isso significa que você pode digitalizar por trás do firewall, mesmo que a porta esteja bloqueada. Como? Como o ACK não é reconhecido, o sistema será reproduzido e enviará um pacote RST (RESET) informando que não temos uma conexão. Agora você sabe que algo está escutando nessa porta.

E, olhando para as informações que você forneceu, é de fato um pacote ACK sendo descartado.

Você pode confirmar isso usando o nmap (de um sistema externo):
nmap -sA -p80 your_ip

    

Answer 4

Nunca tentei fazer isso sozinho, mas talvez usando estas instruções para registrar o pacote inteiro no pcap pode ajudá-lo a encontrar sua resposta.

    

Answer 5

O que eu não entendo é: como as mensagens de log do iptables mostram pacotes que são descartados enquanto são enviados , enquanto o último log mostra pacotes descartados ingoing ?

Eu suspeito que você tenha dois problemas separados aqui. Talvez alguém esteja tentando falsificar seu endereço, portanto, uma resposta não relacionada a (o endereço falsificado) é capturada pelo iptables e descartada. Isso cobriria as quedas de saída.

Em relação às quedas recebidas, o intervalo de tempo de 20 minutos é suspeito .. talvez ARP? Alguma autenticação DHCP ..? 20 minutos é de 1200 segundos; talvez haja 3 cadeias separadas, cada uma adicionando até 3600 (tempo de concessão padrão do DHCP), mas você só vê os pacotes únicos. Apenas uma sugestão.