iptables bloqueando parte do tráfego nas portas 80 e 443 quando não deveria?

Question

Um servidor web que estou administrando mostra negações de iptables estranhas de endereços IPv4 na porta de destino 443, apesar do tráfego HTTPS ser explicitamente permitido. A porta 80 também é permitida na mesma regra, mas o site é somente HTTPS e 80 é imediatamente redirecionado para 443 pelo nginx.

A coisa é: navegar no site funciona . Você pode carregar todas as páginas, todos os recursos vêm bem etc. Mas algo está claramente errado aqui, e isso pode estar prejudicando o desempenho do carregamento da página.

Aqui estão alguns exemplos de erros registrados em /var/log/iptables_deny.log para as portas 443 e 80, respectivamente. Estes podem vir individualmente ou em rajadas, a julgar pelo meu tail -f no arquivo de log. A grande maioria é para a porta 443:

iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0

Um quick grepping diz que os tipos de pacotes nas negações podem ser pelo menos ACK, ACK FIN, ACK RST, ACK PSH e RST. Talvez outros, mas eles não me chamaram a atenção.

Abaixo, a saída do iptables -nvL. O padrão básico (permitir que todos os relacionados e estabelecidos primeiro, depois permitir todo o novo tráfego em 80 e 443) deve ser sólido com base em tudo que eu li. O LOG & As regras DROP são as últimas na cadeia INPUT, como deveriam ser.

Chain INPUT (policy ACCEPT 1 packets, 391 bytes)
 pkts bytes target     prot opt in     out     source          destination   
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0       0.0.0.0/0     
 8893  770K ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0       0.0.0.0/0      icmptype 8
   63  3840 ACCEPT     tcp  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate NEW multiport dports 80,443
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:137
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:138
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:139
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:445
    1    40 LOG        all  --  *      *       0.0.0.0/0       0.0.0.0/0      limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    1    40 DROP       all  --  *      *       0.0.0.0/0       0.0.0.0/0     

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source          destination   
    0     0 DROP       all  --  *      *       0.0.0.0/0       0.0.0.0/0     

Chain OUTPUT (policy ACCEPT 1 packets, 65 bytes)
 pkts bytes target     prot opt in     out     source          destination   
 7311   19M ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0

As regras relevantes reais, se forem de alguma utilidade após essa saída:

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT

O que é claro é que este não é um tráfego malicioso, em geral. Eu naveguei no site a partir de um par de diferentes endereços IP, e enquanto o site carregado aparentemente bem, o meu IP também apareceu no log de negação, sem qualquer padrão que eu poderia discernir, e sem quaisquer condições de erro visível pelo usuário no navegador. >

Alguma idéia do que poderia estar por trás disso?

    

Answer 1

RST e ACK, os pacotes FIN fazem parte do extremo final de uma conexão TCP.

Meu entendimento é que o mecanismo de controle de conexão iptables adota uma abordagem bastante robusta para excluir entradas da tabela de estado, por motivos de segurança: assim que ele vê uma extremidade de uma conexão tentando fechá-la, tal solicitação sinaliza o fim de uma conexão, porque uma extremidade dela agora acha a conexão inativa) remove as entradas da tabela de estado que permitiram o tráfego dessa conexão.

Seria indiscutivelmente inseguro esperar mais tempo para fazer isso, caso algum outro firewall semelhante também estivesse no caminho, bloqueando o restante dos pacotes que os RFCs especificam; atrasar a obtenção da entrada da tabela de estado até que ela seja vista pode arriscar deixar entradas inválidas na tabela por algum período de tempo e isso representaria uma possível vulnerabilidade.

Mas os RFCs especificam um pouco mais de arrumação a ser feita, e são esses pacotes que você vê sendo recusados. Sim, isso significa que os pontos de extremidade na conexão usarão mais memória, aguardando que as conexões fiquem obsoletas em vez de ver o fechamento total e poder liberar memória de conexão muito mais rapidamente; mas o aumento da segurança geralmente requer recursos, e esse é um desses trade-offs.

Não há nenhum dano nesses pacotes que nunca passam, então você pode ignorar com segurança as entradas de log.

Editar : se você não quiser vê-los nos registros, lide com eles antes da linha de registro, por exemplo

iptables -I INPUT 13 -p tcp -m conntrack --ctstate INVALID --tcp-flags ACK,FIN ACK,FIN -j DROP