iptables misterioso DROP --sport 80 [ACK FIN]

Question

Recentemente, decidi pacotes DROP que querem sair pela porta 80. Parece que minha configuração tem um problema, porque alguns pacotes indesejados são descartados.

Trecho da minha configuração:

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -s [PUBLIC IP OF MY SERVER] --sport 80 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Pergunta 1: não é a segunda regra inútil, uma vez que eu já disse no primeiro que aceito todos os pacotes com o estado "ESTABLISHED"?

Pergunta 2: Por que essas duas regras não são suficientes para aceitar os seguintes pacotes eliminados:

Jul 14 18:47:18 [HOSTNAME] kernel: iptables output: IN= OUT=eth0 SRC=[PUBLIC IP OF MY SERVER] DST=[A WWW CLIENT PUBLIC IP] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8408 DF PROTO=TCP SPT=80 DPT=50085 WINDOW=123 RES=0x00 ACK FIN URGP=0 
Jul 14 18:47:53 [HOSTNAME] kernel: iptables output: IN= OUT=eth0 SRC=[PUBLIC IP OF MY SERVER] DST=[A WWW CLIENT PUBLIC IP] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8409 DF PROTO=TCP SPT=80 DPT=50085 WINDOW=123 RES=0x00 ACK FIN URGP=0 
Jul 14 18:48:08 [HOSTNAME] kernel: iptables output: IN= OUT=eth0 SRC=[PUBLIC IP OF MY SERVER] DST=[A WWW CLIENT PUBLIC IP] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=54091 DF PROTO=TCP SPT=80 DPT=25780 WINDOW=16616 RES=0x00 ACK FIN URGP=0

N.B:

• Não há regra acima da cadeia que descarta pacotes.
• A política padrão é DROP.

EDITAR Eu olhei para este post , e também habilitado o registro de pacotes INVALID pelo kernel:

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

Agora parece que tenho vários tipos de erros:

Jul 14 22:00:40 [HOSTNAME] kernel: nf_ct_tcp: invalid RST IN= OUT= SRC=[ONE_CLIENT_IP] DST=[SERVER_IP] LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=47149 PROTO=TCP SPT=993 DPT=51364 SEQ=1043042446 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
Jul 14 21:57:11 [HOSTNAME] kernel: nf_ct_tcp: invalid packet ignored in state ESTABLISHED IN= OUT= SRC=[SERVER_IP] DST=[ONE_CLIENT_IP] LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=3782 SEQ=474588492 ACK=2243291425 WINDOW=14600 RES=0x00 ACK SYN URGP=0 OPT (020405B401010402)
Jul 14 21:57:25 [HOSTNAME] kernel: nf_ct_tcp: invalid packet ignored in state LAST_ACK IN= OUT= SRC=[SERVER_IP] DST=[ONE_CLIENT_IP] LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=3782 SEQ=474588492 ACK=2243291425 WINDOW=14600 RES=0x00 ACK SYN URGP=0 OPT (020405B401010402) 
Jul 14 21:57:41 [HOSTNAME] kernel: nf_ct_tcp: invalid packet ignored in state TIME_WAIT IN= OUT= SRC=[SERVER_IP] DST=[ONE_CLIENT_IP] LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=3782 SEQ=474588492 ACK=2243291425 WINDOW=14600 RES=0x00 ACK SYN URGP=0 OPT (020405B401010402)
Jul 14 21:58:52 [HOSTNAME] kernel: nf_ct_tcp: invalid packet ignored in state SYN_RECV IN= OUT= SRC=[SERVER_IP] DST=[ONE_CLIENT_IP] LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=50488 SEQ=3804975135 ACK=229029122 WINDOW=14600 RES=0x00 ACK SYN URGP=0 OPT (020405B401010402) 

    

Answer 1

(na verdade eu fiz essa resposta em outro lugar, achei que fosse o mesmo site)

de acordo com estes:

link

link (não atualizado)

Pode ser possível que o cliente (talvez móvel) fechou primeiro, não esperou o FIN / ACK final e nunca enviou seu ACK final, ou talvez o servidor tenha respondido muito tarde e o cliente em si tenha um firewall ou qualquer outro caso de resposta lenta ... Assim, o servidor tenta novamente, além de um temporizador ( sysctl net.netfilter.nf_conntrack_tcp_timeout_last_ack ), mas o netfilter caiu o estado antes que a pilha tcp real o derrube.

você deve pegar traços e ver se tem pacotes duplicados, por exemplo.

A segunda regra é um subconjunto da primeira regra, por isso é inútil. Tente aumentar os valores de várias configurações de tcp_timeout ( sysctl -w net.netfilter.... ou echo XX > /proc/sys/net/netfilter/... ) e veja se esses logs desaparecem. Eu configurei isso por razões semelhantes no passado e "resolvi" alguns logs misteriosos do netfilter. Isso pode aumentar o uso de memória do conntrack.

    

Answer 2

1) O segundo parece ser inútil se você tiver um primeiro.

2) Agora. Por que você teria DROP por padrão em OUTPUT? Você não confia em si mesmo? Eu deixaria ACEITAR por padrão. Basta ter suas regras aplicadas à cadeia INPUT com DROP por padrão. Com regras adequadas na cadeia INPUT e DROP, por padrão, o iptables fará um ótimo trabalho na segurança do seu servidor. Criar essas políticas para o OUTPUT parece ser demais se você não estiver fazendo uma configuração de segurança muito especial.

    

Answer 3

Antes que o handshake TCP de três vias seja concluído, a conexão ainda não será "estabelecida". O handshake requer que o cliente envie um pacote SYN , retorne um pacote SYN+ACK e o cliente retorne um pacote ACK . No entanto, você irá bloquear o pacote de saída SYN+ACK .

Uma coisa melhor a fazer seria permitir que todos os pacotes em OUTPUT correspondam a -p tcp --sport 80 --dport 1024:65535 . Você também pode limitar ainda mais o limite inferior; A IANA recomenda que as portas 41952 e posteriores sejam usadas para portas de origem aleatórias, mas, como você pode perceber, muitos clientes não são compatíveis. Uma regra como essa permitirá qualquer tráfego que seja uma resposta a uma conexão de porta 80, em que a porta no cliente não seja uma porta privilegiada (e impedirá que o malware chame a casa em 80 ou 443).

Se você preferir usar estados de conexão para suas regras, também poderá permitir pacotes de saída na porta de origem 80 com estados ESTABLISHED,RELATED,SYN_RECV (em sua configuração, você pode usar apenas SYN_RECV porque a primeira regra cuidará disso ). Isso permitirá que o SYN+ACK de saída configure a conexão de saída.

Os pacotes inválidos parecem estar relacionados ao fato de serem SYN+ACK pacotes, mas a conexão não está esperando para ser estabelecida. Provavelmente este é um artefato não relacionado ao problema e nada para se preocupar.