Descartou pacotes ACK FIN, ACK RST, RST no servidor da web com iptables

Question

Eu rodei um servidor web (Apache) em uma máquina Debian 7, com o iptables na mesma máquina. Regras iptables são geradas pelo script ConfigServer Firewall (CSF). Os sites hospedados são bons, mas estou vendo muito tráfego de entrada na porta 80 .

Aqui está uma extração dos logs (IP do servidor web: 11.22.33.44):

Jan 27 15:21:36 [hostname] kernel: [1229124.817624] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3144 DF PROTO=TCP SPT=36879 DPT=80 WINDOW=510 RES=0x00 ACK FIN URGP=0
Jan 27 15:21:36 [hostname] kernel: [1229124.872795] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3183 DF PROTO=TCP SPT=36684 DPT=80 WINDOW=513 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:36 [hostname] kernel: [1231642.223513] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=19101 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:41 [hostname] kernel: [1231647.015463] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=26215 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK RST URGP=0
Jan 27 16:03:51 [hostname] kernel: [1231656.677627] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=10630 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911962] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3513 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911976] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3514 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

Centenas de linhas dessas coisas. Nenhum padrão de tempo específico e a queda ocorre para clientes aleatórios.

Mas esses pacotes descartados são sempre marcados com ACK FIN, RST, ACK RST e com muito menos frequência com SYN. Eu entendo que estes são pacotes de "transferência de reconhecimento e conexão final".

Regras relevantes do iptables:

Chain INPUT (policy DROP)
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:80
LOGDROPIN  all  --  anywhere             anywhere

Chain LOGDROPIN (1 references)
LOG        tcp  --  anywhere             anywhere             limit: avg 30/min burst 5 LOG level warning prefix "Firewall: *TCP_IN Blocked* "
DROP       all  --  anywhere             anywhere

Então, pelo que parece, esses pacotes estão sendo descartados porque a conexão correspondente não está mais aberta, ou seja, RELACIONADA ou ESTABELECIDA. O que significa que a transferência é bem-sucedida e que o servidor está fechando a conexão antes que o cliente tenha tempo de reconhecer os dados recebidos, deixando a conexão (e talvez a solicitação HTTP?) Pendurada no lado do cliente.

Estou muito curioso para saber o que poderia estar causando isso. E também se perguntando se os clientes estão sendo afetados, pois não consigo replicar o problema. Eu espero que vocês possam me ajudar a entender!

Obrigado pela leitura =)

EDIT : OK, eu fui pescar e fiz um rastreamento de pacotes para um desses casos onde os pacotes [ACK, FIN] são descartados (seguindo o método descrito no meu comentário abaixo). Os três últimos pacotes são os que foram descartados pelo firewall:

Source                Destination           Protocol Length Info                                                                            Time
[CLIENT COMP]         [WEBSERVER]           TCP      68     55478 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1400 WS=4 SACK_PERM=1               2014-01-29 20:44:36.044009
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:36.044052
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:37.243948
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=1 Ack=1 Win=16800 Len=0                                  2014-01-29 20:44:37.421123
[CLIENT COMP]         [WEBSERVER]           HTTP     464    GET /sites/default/files/js/js_R9UbiVw2xuTUI0GZoaqMDOdX0lrZt....js HTTP/1.1     2014-01-29 20:44:37.432097
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [ACK] Seq=1 Ack=409 Win=15872 Len=0                                2014-01-29 20:44:37.432122
[WEBSERVER]           [CLIENT COMP]         HTTP     963    HTTP/1.1 200 OK  (text/javascript)                                              2014-01-29 20:44:37.432703
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=908 Win=15892 Len=0                              2014-01-29 20:44:37.769928
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [FIN, ACK] Seq=908 Ack=409 Win=15872 Len=0                         2014-01-29 20:44:42.437129
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=909 Win=15892 Len=0                              2014-01-29 20:44:42.580378
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:44.668730
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:49.194316
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:58.869659

De acordo com isto:

1. O servidor envia sua resposta HTTP 200 OK
2. Deseja fechar a conexão. Ele envia um pacote [FIN, ACK] para o cliente, como estou supondo que esteja tentando fechar uma conexão simultânea.
3. O cliente responde com um [ACK] para o servidor [FIN, ACK] (os números Seq / Ack estão na ordem correta), mas não [FIN], que de acordo com a especificação significa que a conexão é apenas metade fechado.
4. Mas depois, 5 minutos depois , o cliente envia um [FIN, ACK], o que é incomum porque já enviou um ACK para o "fim de conexão" do servidor. forma de tempo limite TCP está envolvida, e que o cliente está apenas tentando fechar uma conexão que foi deixada em aberto.

Portanto, o handshake de término de conexão não está ocorrendo na sequência correta. E parece que o problema está no lado do cliente, que não fecha a conexão até o tempo limite de 5 minutos.

Eu notei três coisas:

• Este cliente em particular estava executando um navegador moderno, portanto, o navegador não é o problema.
• Ele estava enviando / recebendo muitas retransmissões TCP, sugerindo uma conexão com perdas. Acontece que esse cara está conectado a partir do Marrocos em 3G, então isso se soma ^^.
• Finalmente, os logs do Apache mostram que ele obteve a resposta HTTP correta, portanto, o tráfego do site não é afetado pelo "problema".

Coisas interessantes. Se você tem alguma coisa, atire!

    

Answer 1

De acordo com uma cadeia de e-mails no netfilter, parece ser uma função normal de iptables. Se você não quiser obter essas mensagens no log, poderá tentar adicionar INVALID à lista de estados a serem aceitos na porta 80 e verificar se esse problema desaparece.

Caso contrário, além de ser irritante e preenchimento de log, é um tráfego inofensivo e seus clientes não teriam problemas.