Dead Packets

11/07/2012

TCP RST enviado pelo firewall

Filed under: cisco,troubleshooting — drak @ 7:00 PM

Caso: Capture no Cisco ASA (caixa grande, 5550) indicava intermitência na comunicação de certos tráfegos, ora estabelecia conexão ora a mesma recebia um TCP Reset. Foi inicialmente verificado as métricas de performance do equipamento: CPU e memória normais, tráfego na interface também normal.

Foi verificado o detalhe do tráfego ponto a ponto, originava de um determinado host da rede interna, chegava no firewall e era enviada para um VIP (Load Balancer F5 BigIP). Foi montada um tcpdump no BigIP para determinar qual dos servidores da farm estava enviando o TCP Reset e qual não foi a surpresa quando na captura do BigIP não foi encontrado nenhum pacote RST sendo enviado.

Tráfego passando normalmente

Tráfego sendo rejeitado com TCP RST

Surgiu a questão, porque o firewall estava enviando os resets (já que não havia outros elementos que poderiam fazer isso na topologia) ?

Foi feito nova revisão do firewall, verificou-se a configuração da ACL, existência de service policy (não havia) e outros parâmetros de segurança que poderiam limitar conexões como threath-detection, nada relevante foi encontrado.

Foi passado a informação de que uma nova aplicação relacionada ao SAP havia entrado em produção há pouco tempo, o que poderia ter causado algum impacto de performance no firewall, porém parâmetros como CPU e memória já haviam sido analisados e não estavam nem perto de 100%, foi quando analisando o número de conexões estabelecidas (sh conn count) notamos que o número era estranhamente “redondo”, 650001. Imediatamente suspeitamos que o número máximo de sessões do equipamento havia sido atingido, ao validar o número de sessões simultâneas que o equipamento suporta no datasheet do fabricante finalmente validamos a suspeita, entendendo que o comportamento observado ocorria justamente por esse limite ter sido alcançado.

Comunicamos ao time da aplicação o problema encontrado, fizemos uma análise de sessões (inserir link) para determinar os IPs mais ofensivos (do ponto de vista de número de sessões criadas) e passamos essa informação a eles, durante essa análise notamos que o maior tráfego era de servidores de backup fazendo consultas DNS, descobrimos que as máquinas de backup estavam rodando o software Data Protector que em sua configuração padrão realiza uma consulta no DNS reverso do IP do servidor que está sendo feito o backup, o motivo do número excessivo de sessões foi que a zona de DNS reversa não estava configurada e portanto o Data Protector ficava continuamente tentando efetuar essa consulta ao DNS, que nunca era resolvida com sucesso, causando um efeito similar a o de uma ataque DoS e estourando o número de sessões utilizadas no firewall.

Referências
Cisco ASA 5500 Series Adaptive Security Appliances

Anúncios

1 Comentário »

  1. passei coisa parecida com um 5585 estourando 1 milhão de sessões só que a causa eram rotas assimétricas

    Comentário por gabriel big pennis — 15/02/2013 @ 10:05 AM | Responder


RSS feed for comments on this post. TrackBack URI

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Crie um website ou blog gratuito no WordPress.com.

%d blogueiros gostam disto: