O dispositivo de segurança adaptável da Cisco está descartando pacotes em que o sinalizador SYN não está definido

Question

Temos uma instância do apache dentro da nossa DMZ, que é configurada para fazer proxy de solicitações para uma instância do tomcat interno da NAT dentro de nossa rede. Ele funciona bem, mas, de repente, solicitações do apache para a instância do tomcat param de passar com o seguinte nos logs do apache:

[error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header

Investigar no visualizador de log da Cisco revela o seguinte:

Error Message %ASA-6-106015: Deny TCP (no connection) from IP_address/port to IP_address/port flags tcp_flags on interface interface_name. Explanation The adaptive security appliance discarded a TCP packet that has no associated connection in the adaptive security appliance connection table. The adaptive security appliance looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is not an existing connection, the adaptive security appliance discards the packet.

Recommended Action None required unless the adaptive security appliance receives a large volume of these invalid TCP packets. If this is the case, trace the packets to the source and determine the reason these packets were sent.

Todas as máquinas são virtualizadas usando o VMware e, por padrão, as máquinas vêm usando a NIC emulada do Intel E1000. Nosso administrador de rede mudou isso para um driver VMXNET3 em uma tentativa de corrigir o problema, apenas temos que esperar e ver se o problema persistir, pois é um problema intermitente.

Existe algo mais que possa estar causando esse problema? Este não é o primeiro serviço em que tivemos problemas semelhantes.

Nosso host apache está executando o Ubuntu 11.10 com uma versão do kernel do 3.0.0-17-server. Nós também tivemos esse problema no RHEL5 (5.8) executando o kernel 2.6.18-308.16.1.el5, esta máquina também possui a NIC E1000.

OBSERVAÇÃO : não sou um administrador de rede e sou um arquiteto de software e programador de analistas responsável por esses sistemas.

    

Answer 1

O problema foi encontrado para ser o ASA fechando conexões persistentes após um período de tempo, quando ele fecha as conexões, ele também foi configurado para não enviar RST mensagens quando uma chamada é feita novamente.

Para entender por que isso causa um problema, posso ilustrá-lo aqui.

1. O Apache cria a primeira conexão que é bem-sucedida.
2. Após um atraso maior que o tempo de reinicialização do ASA, o ASA fecha a conexão.
3. A solicitação é feita e o Apache tenta enviar o que acha que é uma conexão aberta e atinge o tempo limite após TimeOut - padrão 300 segundos
4. O Apache envia um erro ao cliente

O problema aqui é amplificado se houver várias conexões em pool ainda abertas. Por exemplo, se o Apache começou com 5 conexões agrupadas, e após o fechado acima, ele ainda exibirá esse comportamento mais 4 vezes antes que um cliente receba uma solicitação bem-sucedida.

Existem várias maneiras de superar isso.

1. Permitir que o ASA envie mensagens de RST para os clientes nos quais confia.
2. Defina a configuração de mod_proxy:ProxyPass - keepalive para On
3. Defina a configuração para mod_proxy:ProxyPass - ttl para algo menor que o tempo de redefinição do firewall.

Não tente configurar mod_proxy:ProxyPass - timeout e mod_proxy:ProxyPass - connectiontimeout muito baixo, como se você tivesse operações de longa execução existentes em sua instância tomcat, por exemplo, qualquer serviço da Web ou ponto de extremidade ReST, então elas podem começar a falhar se demorarem mais do que desta vez.

Nossa solução é fazer as duas primeiras opções.