Por que alguns pacotes de redefinição de TCP aparecem no meu log do iptables?

Question

Eu comecei a adicionar algumas regras básicas do iptables no meu servidor Debian Jessie. Meu objetivo é filtrar e registrar o tráfego de rede (para fins de segurança e aprendizado). Desconsiderando os pacotes ICMP, estas são as regras que estou usando:

# INPUT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset

# OUTPUT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

A política está definida para ACCEPT para INPUT e OUTPUT.

Agora, o log freqüentemente lista os pacotes de saída RST , geralmente para a porta 80. O IP do SRC aqui pertence ao meu servidor, o IP de destino é parcialmente editado para não divulgar outras atividades de pessoas.

Aug 14 11:48:37 reynholm kernel: [81795.100496] UNKNOWN_OUTGOING: IN= OUT=ifext SRC=89.238.65.123 DST=108.162.[edited] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3594 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

Não entendo o que está causando isso, não há aplicativos sendo executados além do SSH e de um MTA. É por causa da minha regra de entrada REJECT ? Mas esses pacotes não deveriam ser manipulados pela regra de saída estado ?

Abaixo está uma captura de um desses pacotes junto com a tentativa de conexão que aparentemente o acionou. Nenhum pacote foi enviado entre meu servidor e 108.162.[edited] antes disso.

11:48:37.860337 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    108.162.[edited].80 > 89.238.65.123.3594: Flags [S.], cksum 0x79bb (correct), seq 79911989, ack 235561828, win 29200, options [mss 1460], length 0
        0x0000:  4500 002c 0000 4000 3c06 7342 6ca2 0000  E..,..@.<.sBl...
        0x0010:  59ee 417b 0050 0e0a 04c3 5c35 0e0a 6364  Y.A{.P......cd
        0x0020:  6012 7210 79bb 0000 0204 05b4 0000       '.r.y.........
11:48:37.860408 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    89.238.65.123.3594 > 108.162.[edited].80: Flags [R], cksum 0x648e (correct), seq 235561828, win 0, length 0
        0x0000:  4500 0028 0000 4000 4006 6f46 59ee 417b  E..(..@[email protected]{
        0x0010:  6ca2 0000 0e0a 0050 0e0a 6364 0000 0000  l......P..cd....
        0x0020:  5004 0000 648e 0000                      P...d...

    

Answer 1

A criação do pacote TCP RST é da sua regra

-A INPUT -p tcp -j REJECT --reject-with tcp-reset

A política padrão (ACCEPT no seu caso) aplica-se apenas aos pacotes que não correspondem a nenhuma das regras da sua cadeia. Se um pacote corresponder à regra acima com o alvo REJECT, ele não estará sujeito à política padrão e será REJEITADO (e gerará um TCP RST) em vez de ACEITO.

Este TCP RST não corresponde à sua regra:

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

porque não está RELACIONADO a outra conexão estabelecida e não faz parte de uma conexão ESTABLISHED. Ele continuará através de suas regras e corresponderá

-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

e termine no seu log. Se você não deseja registrar esses pacotes RST, ajuste essa regra para não combiná-los ou insira uma regra anterior para corresponder aos pacotes RST e, assim, algo com eles antes que eles cheguem aqui.

Outra coisa que estou notando é que o primeiro pacote que você está registrando é um pacote SYN / ACK de um servidor remoto, que se parece com um pacote de resposta do servidor remoto para um pacote SYN que você teria enviado anteriormente para iniciar o conexão com o host remoto na porta 80. Se você não enviou um SYN inicial, eu não acho que a conexão seria igual a 'ESTABLISHED', mas se você enviou um SYN então eu acho que a conexão deve ser 'ESTABLISHED'. Isso pode estar mexendo com qual regra seu RST acaba combinando.

    

Answer 2

Estendendo a grande resposta por @casey: A causa disso é que o pacote do remote tem as flags SYN e ACK definidas. Isso é INVALID para um primeiro pacote. O iptables não considera o pacote de reset como RELATED para o pacote inicial, já que claramente não faz sentido.

O efeito pode ser reproduzido usando uma ferramenta como hping3 : Um pacote SYN / ACK é enviado com hping3 -c 1 --syn --ack 89.238.65.123 . A resposta do servidor a este pacote não terá o sinalizador ACK definido e não corresponderá à regra estado (ou seja, não está relacionada ao ping de envio). Uma entrada de log é acionada como resultado.

Nenhum efeito desse tipo ocorrerá se o sinalizador ACK não estiver definido na solicitação inicial.

Eu me livrei das mensagens de log filtrando e descartando os pacotes tcp INVALID.

-I INPUT 3 -m state --state INVALID -j DROP

    

Answer 3

Isso parece ser parte de uma varredura de porta iniciada de tcp / 80 no host remoto. O host remoto investiga seu serviço tcp / 3594 e seu sistema diz corretamente "Não. Agora vai embora (RST)". Infelizmente, coisas relativamente normais para sistemas de conexão à Internet.

Você pode querer instalar o fail2ban , que pode ser muito bom em bloquear hosts que tentam se conectar ao seu sistema de maneira inaceitável. Um aviso, porém: configurá-lo além dos exemplos incluídos não é trivial.