preocupado com o conteúdo de ip_conntrack

Question

Resumo

• Server OS: Debian Squeeze
• Servidor da Web: Apache2
• Script de tabelas de IP ': arno-iptables-firewall

Existem 170 entradas em /proc/net/ip_conntrack no servidor. Atualmente, 134 deles se referem a um endereço IP que é resolvido como cl59.justhost.com (sugiro que você não navegue até ele, apenas no caso). Eu não entendo as entradas do conntrack, e estou preocupado que elas possam indicar uma violação de segurança.

Detalhes

As 134 entradas em /proc/net/ip_conntrack são todas assim (meu servidor IP foi substituído por 192.168.0.1),

tcp      6 282883 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33053 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33053 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282877 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33064 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33064 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60963 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60963 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60950 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60950 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283131 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33221 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33221 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 283080 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33253 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33253 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2
tcp      6 282879 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33208 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33208 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2

Não estou vendo nenhuma conexão ativa em netstat ,

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:842             0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.1:22          xx.xx.xx.xx:54586       ESTABLISHED
tcp6       0      0 :::25                   :::*                    LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 192.168.0.1:80          xxx.xx.196.80:30010     TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xx.13.54:60767       TIME_WAIT
tcp6       0      0 192.168.0.1:80          xxx.xx.196.11:33402     TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xxx.142.192:58280    TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xxx.142.192:58281    TIME_WAIT
tcp6       0      0 192.168.0.1:80          xx.xx.13.54:62025       TIME_WAIT
udp        0      0 192.168.0.1:123         0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*

O servidor roda o Apache2, PHP5 e possui vários blogs wordpress e um único fórum phpBB3 (além de outros pequenos bits aleatórios aqui e ali).

Alguém pode lançar alguma luz sobre uma possível fonte para essas conexões. Eles falharam / protelaram conexões para o meu servidor de 69.175.58.106 e, portanto, não há muito com o que se preocupar, ou são conexões de saída do meu servidor para 69.175.58.106, o que pode indicar algo sinistro acontecendo?

Se eles não são em si mesmos uma preocupação, existe uma razão pela qual eles não parecem estar indo embora?

Atualização:

Então, fizemos mais algumas pesquisas e o terceiro campo na entrada é a hora em que a entrada permanecerá ativa. Então, por alguma razão, todas essas entradas têm um tempo de vida muito grande. Isso explica por que eles não foram embora, mas ainda não foram a causa original e, agora, como foram criados com durações tão grandes.

Atualização 2:

Então, mais escavações me sugerem que as entradas devem ser lidas como, meu servidor (192.168.0.1) enviou um pacote para 69.175.58.106, que até agora não respondeu. Isso me leva a suspeitar que 69.175.58.106 originalmente solicitou dados do servidor, e então desconectou, e o iptables decidiu manter a entrada por algum tempo.

Eu ainda estaria interessado em saber se essa avaliação está correta ou se há algo mais acontecendo.

    

Answer 1

Certo, cavando ainda mais e tenho a minha resposta.

1. os TTLs longos nas conexões são o padrão para o kernel e o Debian Squeeze que eu tenho, são cerca de 5 dias para conexões estabelecidas, e são configurados em /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

2. Lendo as entradas do conntrack, agora interpreto-as como 69.175.58.106 conectadas ao servidor web na porta 80, e o servidor web respondeu com alguns dados, mas antes que a conexão pudesse ser fechada, era simplesmente caiu por qualquer coisa entre o meu servidor e 69.175.58.106, ou pelo próprio 69.175.58.106. Conexões fechadas têm um TTL muito mais curto.

3. Não é possível dizer se 69.175.58.106 conectou muitas vezes e depois simplesmente parou de se comunicar, ou se houve um problema de rede entre meu servidor e 69.175.58.106, mas a julgar pelo fato de que o 69.175.58.106 O endereço IP aponta para outro servidor e não para uma conexão de usuário, estou inclinado a pensar que algo estranho estava acontecendo, mas que, no final, não causou nenhum problema no final.

4. iptstate parece ser uma boa ferramenta baseada em palavrões para ver a conntrack dados.