Fase 8 do Troubleshooting do trajeto de dados de FirePOWER: Política da análise de rede

Introdução

Este artigo é parte de uma série de artigos que explicam como pesquisar defeitos sistematicamente o trajeto de dados em sistemas de FirePOWER para determinar se os componentes de FirePOWER podem afetar o tráfego. Refira por favor o artigo da vista geral para obter informações sobre da arquitetura de Plataformas e de links de FirePOWER aos outros artigos do Troubleshooting do trajeto de dados.

Este artigo cobre a oitava fase do Troubleshooting do trajeto de dados de FirePOWER, os recursos de política da análise de rede.

Pré-requisitos

• Este artigo é aplicável a todas as Plataformas de FirePOWER
  
  • A característica do traço está somente disponível na versão de software 6.2.0 e acima para a plataforma da defesa da ameaça de FirePOWER (FTD) somente.
• O conhecimento do Snort da aberta é útil, embora não exigido
  • Para obter informações sobre do Snort da aberta, visite por favor https://www.snort.org/

Pesquisando defeitos os recursos de política da análise de rede

A política da análise de rede (SESTA) contém os ajustes do preprocessor do snort que executam inspeçãos no tráfego, com base no aplicativo identificado. Os preprocessors têm a capacidade para deixar cair o tráfego, com base na configuração. Endereços deste artigo como verificar a configuração da SESTA e verificá-la para ver se há gotas de preprocessor.

Nota: As regras do Preprocessor têm um gerador ID (GID) a não ser o '1' ou o '3' (isto é 129, 119, 124). Mais informação sobre o GID aos mapeamentos do preprocessor pode ser encontrada no FMC ConfigurationGuides.

Usando a ferramenta do “traço” para encontrar as gotas do Preprocessor (FTD somente)

A ferramenta do traço do suporte de sistema pode ser usada para detectar as gotas executadas a nível do preprocessor.

No exemplo abaixo, o preprocessor da normalização TCP detectou uma anomalia. Em consequência, o tráfego é deixado cair pela regra 129:14, que procura timestamps faltantes dentro de um córrego TCP.

Nota: Embora o PRE-processador da configuração do córrego TCP deixe cair o tráfego, pode fazer assim porque o preprocessor Inline da normalização é permitido igualmente. Para mais na normalização Inline, você pode ler este artigo.

Verifique a configuração da SESTA

No centro de gerenciamento de FirePOWER (FMC) UI, a SESTA pode ser vista sob políticas > controle de acesso > intrusão. Então, clique sobre a opção da política da análise de rede no direita superior, depois do qual você pode ver as sestas, criar novos e editar o existências.

Como visto na ilustração acima, as sestas contêm “uma característica do modo Inline”, que seja o equivalente da “gota quando Inline” opção na política da intrusão. Uma etapa rápida da mitigação para impedir a SESTA do tráfego deixando cair seria desmarcar o modo Inline. Os eventos da intrusão gerados pela SESTA não indicam qualquer coisa na aba Inline do resultado com modo Inline desabilitada.

Ajustes da SESTA da vista

Dentro da SESTA, você pode ver as configurações atual. Isto inclui os preprocessors permitidos totais, seguidos pelo

preprocessors permitidos com configurações diferente da padrão (umas que tweaked manualmente) e umas que são permitidas com configurações padrão, como visto na ilustração abaixo.

Ajustes da SESTA que podem causar gotas silenciosas

No exemplo mencionado na seção do traço, a regra 129:14 da configuração do córrego da regra TCP está deixando cair o tráfego. Isto é determinado olhando as saídas de rastreamento do suporte de sistema. Contudo, se a regra dita não é permitida dentro da política respectiva da intrusão, nenhum evento da intrusão é enviado ao FMC.

A razão pela qual esta acontece é devido a um ajuste dentro do preprocessor Inline da normalização chamado anomalias Unresolvable do cabeçalho de TCP do bloco. Esta opção permite basicamente que o Snort execute uma ação do bloco quando determinadas regras GID 129 detectam anomalias no córrego TCP.

Se as anomalias Unresolvable do cabeçalho de TCP do bloco são permitidas, recomenda-se girar sobre as regras GID 129 pela ilustração abaixo.

Girando sobre o GID 129 ordena os eventos da intrusão das causas a ser enviados ao FMC quando tomam a ação no tráfego. Contudo, enquanto as anomalias Unresolvable do cabeçalho de TCP do bloco são permitidas, pode ainda deixar cair o tráfego mesmo se o estado da regra na política da intrusão é ajustado para gerar somente eventos. Este comportamento é explicado nos manuais de configuração FMC.

A documentação acima pode ser encontrada neste artigo (para a versão 6.4, que é a maioria de versão recente na altura desta postagem do artigo).

Verifique a configuração backend

Uma outra camada de complexidade é adicionada ao comportamento do preprocessor que determinados ajustes podem ser permitidos na parte posterior, sem ser refletido no FMC. Estas são algumas razões possíveis.

• Outras características permitidas têm a capacidade para forçar permitem os ajustes do preprocessor (principal que é a política do arquivo)
• Algumas regras da política da intrusão exigem determinadas opções do preprocessor a fim executar a detecção
• Um defeito pode causar o comportamento
  • Nós vimos um exemplo deste: CSCuz50295 - do “a política arquivo com bloco do malware permite a normalização TCP com bandeira do bloco”

Antes de olhar a configuração backend, note que as palavras-chaves do Snort, que são usadas nos arquivos de configuração backend do Snort, podem ser consideradas pairando sobre um ajuste específico dentro da SESTA. Refira por favor a ilustração abaixo.

A opção Unresolvable das anomalias do cabeçalho de TCP do bloco na aba da SESTA traduz à palavra-chave do bloco na parte posterior. Com essa informação na mente, a configuração backend pode ser verificada do shell perito.

 Criando uma SESTA visada

Se determinados anfitriões estão provocando eventos do preprocessor, uma SESTA feita sob encomenda pode ser usada para inspecionar o tráfego a ou dos anfitriões ditos. Dentro da SESTA feita sob encomenda, os ajustes que estão causando edições podem ser desabilitados.

Estas são as etapas para executar uma SESTA visada.

1. Crie a SESTA pelas instruções mencionadas dentro verificam a seção de configuração da SESTA deste artigo.
2. No guia avançada da política do controle de acesso, navegue à seção das políticas da análise de rede e da intrusão. O clique adiciona a regra e cria uma regra, usando os anfitriões visados e escolhe a SESTA recém-criado na seção de política da análise de rede.

Análise do falso positivo

Verificar para ver se há falsos positivos em eventos da intrusão para regras do preprocessor é bastante diferente do que aquela das regras do Snort usadas para a avaliação da regra (que contêm um GID de 1 e de 3).

A fim executar uma análise do falso positivo para eventos da regra do preprocessor, uma captação da sessão completa é necessária para procurar anomalias dentro do córrego TCP.

No exemplo abaixo, a análise do falso positivo está sendo executada na regra 129:14, que é mostrada deixar cair o tráfego nos exemplos acima. Desde que 129:14 estão procurando o TCP flui no que timestamps faltam, você pode claramente ver porque a regra foi provocada pela análise da captura de pacote de informação ilustrada abaixo.

Etapas da mitigação

Para abrandar rapidamente possíveis problemas com a SESTA, as seguintes etapas podem ser executadas.

• Se uma SESTA feita sob encomenda está sendo usada e você não é certo se um ajuste da SESTA está deixando cair o tráfego mas você suspeita que pôde ser, você pode tentar substitui-lo com “Segurança e Conectividade” ou “Conectividade equilibrada sobre uma política da Segurança”.

• Se alguma “regulamentação aduaneira” está sendo usada, certifique-se ajustar a SESTA a um dos padrões mencionados acima
• Se alguma regra do controle de acesso usa uma política do arquivo, você pode precisar de tentar temporariamente removê-la enquanto uma política do arquivo pode permitir os ajustes do PRE-processador na parte posterior que não devem ser refletidos no FMC, e este acontece a nível “global”, significando que todas as sestas estão alteradas.

Cada protocolo tem um preprocessor diferente e pesquisá-los defeitos pode ser muito específica ao preprocessor. Este artigo não cobre todos os ajustes e métodos de Troubleshooting do preprocessor para cada um.

Você pode verificar a documentação para ver se há cada preprocessor para obter uma ideia melhor do que cada opção faz, que é útil ao pesquisar defeitos um preprocessor específico.

Dados a fornecer ao TAC

Dados	Instruções
Pesquise defeitos o arquivo do dispositivo de FirePOWER	http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html
Captação completa do pacote de sessão do dispositivo de FirePOWER	http://www.cisco.com/c/en/us/support/docs/security/sourcefire-firepower-8000-series-appliances/117778-technote-sourcefire-00.html