Introdução
Este documento descreve os motivos e as etapas de mitigação para o FirePOWER Management Center (FMC) exibir eventos de conexão TCP na direção inversa, onde o IP do iniciador é o IP do servidor da conexão TCP e o IP do respondente é o IP do cliente da conexão TCP.
Observação: há vários motivos para a ocorrência de tais eventos. Este documento explica a causa mais comum desse sintoma.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Tecnologia FirePOWER
- Conhecimento básico do Adaptive Security Appliance (ASA)
- Compreensão do mecanismo de temporização do Transmission Control Protocol (TCP)
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- ASA Firepower Threat Defense (5506X/5506H-X/5506W-X, ASA 5508-X, ASA 5516-X ) com software versão 6.0.1 e posterior
- ASA Firepower Threat Defense (5512-X,5515-X, ASA 5525-X, ASA 5545-X, ASA 5555-X,FP9300,FP4100) com software versão 6.0.1 e posterior
- ASA com módulos Firepower (5506X/5506H-X/5506W-X, ASA 5508-X, ASA 5516-X,5515-X, ASA 5525-X, ASA 5545-X, ASA 5555-X, ASA 5585-X) que executa as versões de software 6.0.0 e posteriores
- Firepower Management Center (FMC) versão 6.0.0 e posterior
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste documento começaram com uma configuração clara (padrão). Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Background
Em uma conexão TCP, cliente se refere ao IP que envia o pacote inicial. O FirePOWER Management Center gera um evento de conexão quando o dispositivo gerenciado (sensor ou FTD) vê o pacote TCP inicial de uma conexão.
Os dispositivos que rastreiam o estado de uma conexão TCP têm um timeout de ociosidade definido para garantir que as conexões que não são fechadas erroneamente por endpoints não consomem a memória disponível por longos períodos de tempo. O tempo limite ocioso padrão para conexões TCP estabelecidas no FirePOWER é de três minutos. Uma conexão TCP que permaneceu ociosa por três minutos ou mais não é rastreada pelo sensor IPS FirePOWER.
O pacote subsequente após o tempo limite é tratado como um novo fluxo TCP e a decisão de encaminhamento é tomada de acordo com a regra que corresponde a esse pacote. Quando o pacote é do servidor, o IP do servidor é registrado como o iniciador desse novo fluxo. Quando o registro estiver ativado para a regra, um evento de conexão será gerado no FirePOWER Management Center.
Observação: de acordo com as políticas configuradas, a decisão de encaminhamento para o pacote que vem após o timeout é diferente da decisão para o pacote TCP inicial. Se a ação padrão configurada for "Bloquear", o pacote será descartado.
Um exemplo desse sintoma é mostrado na captura de tela abaixo:
Solução
Esse problema é atenuado pelo aumento do tempo limite das conexões TCP. Para alterar o tempo limite,
- Navegue até Policies > Access Control > Intrusion.
- Navegue até o canto superior direito e selecione Network Access Policy.
- Selecione Create Policy, escolha um nome e clique em Create and Edit Policy. Não modifique a política base.
- Expanda a opção Settings e escolha TCP Stream Configuration.
- Navegue até a seção de configuração e altere o valor de Timeout conforme desejado.
- Navegue até Policies > Access Control > Access Control.
- Selecione a opção Edit para editar a política aplicada ao dispositivo gerenciado relevante ou criar uma nova política.
- Selecione a guia Advanced na política de acesso.
- Localize a seção Análise de rede e políticas de intrusão e clique no ícone Editar.
- No menu suspenso de Default Network Analysis Policy, escolha a política criada na etapa 2.
- Clique em OK e Salvar as alterações.
- Clique na opção Deploy para implantar as políticas em dispositivos gerenciados relevantes.
Cuidado: espera-se que o aumento do tempo limite cause uma maior utilização da memória. O FirePOWER precisa rastrear os fluxos que não são fechados por endpoints por mais tempo. O aumento real na utilização da memória é diferente para cada rede exclusiva, pois depende de quanto tempo os aplicativos de rede mantêm as conexões TCP ociosas.
Conclusão
O benchmark de cada rede para o timeout de ociosidade das conexões TCP é diferente. Depende completamente dos aplicativos que estão em uso. Um valor ideal deve ser estabelecido observando-se por quanto tempo os aplicativos de rede mantêm as conexões TCP ociosas. Para problemas relacionados ao módulo de serviço FirePOWER em um Cisco ASA, quando um valor ideal não puder ser deduzido, o tempo limite pode ser ajustado aumentando-o em etapas até o valor de tempo limite do ASA.
Informações Relacionadas