Um servidor da Web que estou administrando mostra negações estranhas de iptables 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 a 80 é imediatamente redirecionada para 443 pelo nginx.
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 nas /var/log/iptables_deny.logportas 443 e 80, respectivamente. Estes podem vir individualmente ou em rajadas, a julgar pelo meu tail -farquivo 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 grep rápido 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 não me chamaram a atenção.
Abaixo, a saída de iptables -nvL. O padrão básico (permitir 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 li. As regras LOG & 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 está claro é que, em geral, não se trata de tráfego malicioso. Eu naveguei no site a partir de alguns endereços IP diferentes e, embora o site tenha carregado aparentemente bem, meu IP também apareceu no log de negação sem nenhum padrão que eu pudesse discernir e sem nenhuma condição de erro visível pelo usuário no navegador.
Alguma ideia do que poderia estar por trás disso?
Os pacotes RST e ACK, FIN fazem parte do final de uma conexão TCP.
Meu entendimento é que
iptableso mecanismo de rastreamento de conexão adota uma abordagem bastante robusta para excluir entradas da tabela de estado, por motivos de segurança: assim que vê uma extremidade de uma conexão tentando fechá-la, então (sabendo que tal solicitação sinaliza o fim de uma conexão, porque uma extremidade dela agora pensa que a conexão está inativa) ele 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 de limpeza que os RFCs especificam; atrasar a coleta da entrada da tabela de estado até que essas sejam vistas pode correr o risco de deixar entradas inválidas na tabela por algum período de tempo e isso apresentaria uma vulnerabilidade potencial.
Mas os RFCs especificam mais alguns ajustes a serem feitos, e são esses pacotes que você vê sendo recusados. Sim, isso significa que os endpoints na conexão usarão mais memória, esperando que as conexões envelheçam em vez de ver o fechamento completo e ser capaz de liberar memória de conexão muito mais rápido; 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 logs, lide com eles antes de sua linha de log, por exemplo