O iptables pode ser usado para monitorar tempos limite / redefinições de TCP em todo o sistema?

Question

Estou tentando determinar se a conexão de um aplicativo a um banco de dados é interna ao aplicativo ou devido a um evento de rede. Isso parece algo em que o netfilter teria visibilidade em todo o sistema. Para esse fim, eu queria usar -j LOG com iptables para registrar todas as redefinições e tempos limite do TCP que ocorrem no sistema. Eu não sei o que usar para os critérios correspondentes, no entanto.

Sinto que a resposta envolveria o módulo conntrack em algum momento, mas consegui localizar quase nada nele. O servidor de banco de dados é MS-SQL e o aplicativo J2EE está em execução em uma VM do RHEL 5.10. A última é a máquina que estou tentando executar o login.

EDITAR:

Encontrei esta postagem do blog que mostra como registrar O TCP é redefinido (entre outras coisas) com a opção --tcp-flags para iptables . Portanto, a questão pendente é descobrir como registrar conexões sem RST explícito, mas estão fechadas devido à conexão ser vista como obsoleto / tempo limite.

    

Answer 1

Depois de perguntar no IRC um pouco, parece que a expectativa geral é que se um nó achar que uma conexão terminou anormalmente por qualquer razão (incluindo atingir um tempo limite derivado internamente) espera-se que envie o remoto nó um pacote RST antes de fechar a conexão em seu lado. Portanto, as duas perguntas são respondidas com a mesma solução: log TCP redefine via --tcp-flags .

O comando básico para fazer isso no meu sistema RHEL 5.10 (deve funcionar nas distribuições baseadas no Debian também) é:

root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags RST RST -j LOG
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags FIN FIN -j LOG

Sem critérios de correspondência, provavelmente acabaria correspondendo a alguns poucos pacotes, por isso criei uma nova regra voltada especificamente para o sistema que estou buscando:

root@xxxxxxvlt01 ~ $ iptables -A OUTPUT  -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags RST RST -j LOG
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT  -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags FIN FIN -j LOG
root@xxxxxxvlt01 ~ $ iptables -nvL
Chain INPUT (policy ACCEPT 767K packets, 108M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 448K packets, 68M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            xxx.xxx.64.248       tcp flags:0x04/0x04 LOG flags 0 level 4
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            xxx.xxx.64.248       tcp flags:0x01/0x01 LOG flags 0 level 4
root@xxxxxxvlt01 ~ $

Qual é muito melhor. Uma vez que a minha confirmação para o material RST-upon-timeout é de alguém no IRC, deixarei este aberto / sem resposta caso alguém possa provar que estou errado. Depois de uma semana, aceitarei minha própria resposta, a menos que seja contradita.