depuração spiking netstat “tentativas de conexão com falha” com iptables

Question

link

Este gráfico é munin coletando netstat -s output.

Eu quero determinar de onde as conexões estão vindo. Não há nada óbvio em despejos wireshark.

Já passou algum tempo desde que eu fiz algo extravagante com o iptables. Como eu posso fazer o log desses?

Obrigado

-s

    

Answer 1

Para determinar de onde as conexões estão vindo ... Aqui está um exemplo para registrar o tráfego SSH. O formato ficará assim no seu registro de kernels

MONTH DAY TIME SERVERNAME kernel: [IPTABLES] : IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=REMOTEIP DST=SERVERIP LEN=00 TOS=0x00 PREC=0x00 TTL=# ID=# DF PROTO=TCP SPT=# DPT=22 WINDOW=# RES=0x00 SYN URGP=0 OPT (#)

Aqui criamos uma nova cadeia chamada MyLOG

# iptables -N MyLOG

Limpe a nova corrente apenas no caso de

# iptables -F MyLOG

crie o recurso de registro na porta tcp 22, defina os logs para alertar e uma seqüência fácil de ver "[IPTABLES]" para o início da linha de registro.

# iptables -A MyLOG -i eth0 -p tcp --dport 22 -j LOG --log-level alert --log-tcp-options --log-ip-options --log-prefix '[IPTABLES] : '

Anexe a cadeia MyLOG à cadeia de entrada

# iptables -A INPUT -i eth0 -j MyLOG

Isso deve enviar os logs para o log do kernel (embora alguns tipos de linux possam variar os resultados). Você pode testar o log seguindo o log do kernel.

# tail -f /var/log/kern.log

Se você estiver no console e notar a quantidade de dados espalhados pela sua tela, você pode tentar configurar a saída do registro do console com

dmesg -n 1

Se você deseja obter "estatísticas", pode executar

# iptables -nvxL

a saída mostrará a quantidade de pacotes e bytes enviados a partir do momento em que a cadeia foi criada.

Chain MyLOG (1 references)
    pkts      bytes target     prot opt in     out     source               destination
      61     4416 LOG        tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0

Eu tenho um script aqui link que usei para registrar determinada atividade de porta e coletar dados para serverstats serverstats (para download no berlios), configuração de NAT, redirecionamento de portas, tentativas de quebra de varreduras de portas e uso de tcp-rejects em vez de descarte.

Serverstats pode ser difícil de descobrir. É um conjunto de scripts PHP que usa o RRDTool. Ele usa um script de shell para acionar a saída do iptables. Minhas notas ilegíveis me dizem que você precisa modificar o array de configuração com algo assim para fazê-lo rodar

'ssh-traffic' => array(
        'used' => true,
        'chains' => array('MyLOG'),
        'graphs' => array(
            'combined_bps' => array('used' => true, 'title' => 'Combined (bps)'),
            'single_bps' => array('used' => true, 'title' => '%s (bps)'),
            'combined_count' => array('used' => true, 'title' => 'Combined (count)'),
            'single_count' => array('used' => true, 'title' => '%s (count)')
        )
    ),

    

Answer 2

Obrigado pelas respostas caras.

Meu objetivo aqui é entender por que os picos no gráfico são regulares e cíclicos e, em seguida, fazê-los parar. Estes estão chegando em um gotejamento lento (5 ou mais de cada vez). Eu entendo que as conexões tcp falham por uma razão ou outra, mas obviamente há algo em andamento devido à sua regularidade. Eu suspeito que um cron job em algum lugar, um erro de configuração do balanceador de carga ou um dispositivo de monitoramento como o culpado.

Eu decidi adotar a abordagem UTSL e aqui é onde eu estou até agora:

netstat -s obtém suas estatísticas em / proc / net / snmp.

Ótimo. Portanto, o kernel atualiza um contador SNMP toda vez que há uma tentativa de conexão com falha.

O que eu gostaria de realizar, é sempre que há uma falha na conexão, não apenas atualiza este contador, mas também registra "falha na tentativa de conexão do IP $ foo no $ timestamp"

Então ... o que se qualifica como tentativa de conexão com falha?

transfere a fonte do kernel circula conclui que o contador que estou procurando é TCP_MIB_ATTEMPTFAILS

percorrendo a árvore fonte 2.6.18, encontrei dois lugares onde isso é referenciado:

./ net / ipv4 / tcp_minisocks.c:

453 struct sock *tcp_check_req(struct sock *sk,struct sk_buff *skb,
454                            struct request_sock *req,
455                            struct request_sock **prev)
456 {

592                 if (flg & (TCP_FLAG_RST|TCP_FLAG_SYN)) {
593                         TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
594                         goto embryonic_reset;
595                 }

640 }

... e inclua / net / tcp.h

915 static inline void tcp_done(struct sock *sk)
916 {
917         if(sk->sk_state == TCP_SYN_SENT || sk->sk_state == TCP_SYN_RECV)
918                 TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
919 
920         tcp_set_state(sk, TCP_CLOSE);
921         tcp_clear_xmit_timers(sk);
922 
923         sk->sk_shutdown = SHUTDOWN_MASK;
924 
925         if (!sock_flag(sk, SOCK_DEAD))
926                 sk->sk_state_change(sk);
927         else
928                 inet_csk_destroy_sock(sk);
929 } 

Estou um pouco surpreso que estas sejam as únicas duas condições que geram uma contra-atualização, mas seja o que for.

O primeiro bloco parece bastante óbvio. "Se você vir um pacote TCP com os sinalizadores RST e SYN definidos, atualize o contador TCP_MIB_ATTEMPTFAILS e redefina a conexão".

Na tentativa de pegá-los, coloco as seguintes regras do iptables

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG
iptables -A OUTPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG

aguarda … .. nada. = (

O segundo bloco é um pouco mais misterioso, mas eu vou adivinhar e assumir que isso significa "atualizar o contador TCP_MIB_ATTEMPTFAILS se o socket estiver em um certo estado ao rasgá-lo"

Isso, não tenho idéia de como testar isso.

Minhas perguntas agora são: 1) Estou interpretando mal este gráfico de alguma forma? 2) Estou no caminho certo? 3) Falta de escrever um módulo do kernel (que eu não sou tão habilidoso o suficiente para fazer), como posso realizar meu objetivo de registro?

Obrigado

-s

    

Answer 3

Eu não tenho certeza se o iptables é o que você quer, pode haver uma ferramenta que permanece ativa e consulta os mesmos syscalls que o netstat usa, ou você pode escrever um.

iptables reage aos pacotes, para processá-los. o que você está vendo é basicamente uma tabela de alocação para todos os sockets ativos.

Agora, dependendo do que realmente é, você pode pegar pacotes nessas conexões.

Se você tem muitos soquetes em um estado que não é muito impressionante, por um longo tempo, crescendo continuamente para números cada vez mais altos, eu estaria mais preocupado com a saída do netstat -anp, iirc, que informa o programa. Talvez alguém esteja vazando soquetes.

Isso é altamente presunçoso de mim. Como elaborar o que você deseja ver, altere esse gráfico.

Eu comentei sobre mim mesmo, mas ele não apareceu, então vou apenas editar - o outro post é absolutamente uma instrução clara de como registrar, com o iptables, o tráfego que você deve poder ver com o wireshark. Soa como se você estivesse perguntando sobre soquetes, não pacotes. Os soquetes que são difíceis de rastrear não estão recebendo / enviando pacotes, normalmente, e algumas vezes isso indica desperdício de recursos.