O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este artigo faz parte de uma série de artigos que explicam como solucionar problemas sistematicamente no caminho de dados em sistemas Firepower para determinar se os componentes do Firepower podem estar afetando o tráfego. Consulte o artigo Visão geral para obter informações sobre a arquitetura das plataformas Firepower e links para outros artigos de solução de problemas de caminho de dados.
Este artigo aborda o sexto estágio da solução de problemas de caminho de dados do Firepower, o recurso de autenticação ativa.
Ao tentar determinar se um problema é causado pela identidade, é importante entender qual tráfego esse recurso pode afetar. Os únicos recursos na própria identidade que podem causar interrupções de tráfego são os relacionados à autenticação ativa. A autenticação passiva não pode fazer com que o tráfego seja descartado inesperadamente. É importante entender que somente o tráfego HTTP(S) é afetado pela autenticação ativa. Se outro tráfego for afetado porque a identidade não está funcionando, isso é mais provável porque a política usa usuários/grupos para permitir/bloquear o tráfego, então quando o recurso de identidade não pode identificar usuários, coisas inesperadas podem ocorrer, mas depende da política de controle de acesso e da política de identidade do dispositivo. A solução de problemas nesta seção apresenta problemas relacionados apenas à autenticação ativa.
Os recursos de autenticação ativa envolvem o dispositivo Firepower executando um servidor HTTP. Quando o tráfego corresponde a uma regra de política de identidade que contém uma ação de autenticação ativa, o Firepower envia um pacote 307 (redirecionamento temporário) para a sessão, para redirecionar os clientes para seu servidor de portal cativo.
Existem atualmente cinco tipos diferentes de autenticação ativa. Dois redirecionamentos para um nome de host que consiste no nome de host do sensor e no domínio primário do Ative Diretory vinculado ao território, e três redirecionamentos para o endereço IP da interface no dispositivo Firepower que está executando o redirecionamento do portal cativo.
Se algo der errado no processo de redirecionamento, a sessão pode ser interrompida porque o site não está disponível. É por isso que é importante entender como o redirecionamento está operando na configuração em execução. O gráfico abaixo ajuda a entender esse aspecto de configuração.
Se a autenticação ativa estiver sendo redirecionada para o nome do host, ela redirecionará os clientes para ciscoasa.my-ad.domain:<port_used_for_cativo_portal>
A coleta de capturas de pacotes é a parte mais importante da solução de problemas de autenticação ativa. As capturas de pacotes ocorrem em duas interfaces:
As duas capturas são iniciadas, o tráfego interessante é executado pelo dispositivo Firepower e as capturas são interrompidas.
Observe que o arquivo de captura de pacote da interface interna, "ins_ntlm", é copiado para o diretório /mnt/disk0. Em seguida, ele pode ser copiado para o diretório /var/common para ser baixado do dispositivo (/ngfw/var/common em todas as plataformas FTD):
> expert
# copy /mnt/disk0/<pcap_file> /var/common/
Os arquivos de captura de pacote podem ser copiados do dispositivo Firepower do prompt > usando as instruções neste artigo.
Como alternativa, não há uma opção no Firepower Management Center (FMC) no Firepower versão 6.2.0 e posterior. Para acessar esse utilitário no FMC, navegue para Dispositivos > Gerenciamento de dispositivos. Em seguida, clique no botão ao lado do dispositivo em questão, seguido por Advanced Troubleshooting > File Download. Em seguida, você pode digitar o nome de um arquivo em questão e clicar em Download.
A análise de PCAP no Wireshark pode ser realizada para ajudar a identificar o problema nas operações de autenticação ativas. Como uma porta fora do padrão é usada na configuração do portal cativo (885 por padrão), o Wireshark precisa ser configurado para decodificar o tráfego como SSL.
A captura da interface interna e a captura da interface do túnel devem ser comparadas. A melhor maneira de identificar a sessão em questão em ambos os arquivos PCAP é localizar a porta de origem exclusiva, já que os endereços IP são diferentes.
No exemplo acima, observe que o pacote de saudação do servidor está ausente da captura da interface interna. Isso significa que nunca voltou para o cliente. É possível que o pacote tenha sido descartado pelo snort, ou possivelmente devido a um defeito ou erro de configuração.
Note: O Snort inspeciona seu próprio tráfego de portal cativo para evitar qualquer exploração HTTP.
Se o problema não estiver na pilha SSL, pode ser útil descriptografar os dados no arquivo PCAP para ver o fluxo HTTP. Existem dois métodos para isso.
Caution: Se o método 2 for usado, não forneça ao Cisco Technical Assistance Center (TAC) sua chave privada. Entretanto, um certificado de teste temporário e uma chave podem ser usados. Um usuário de teste também deve ser usado em testes.
No exemplo abaixo, um arquivo PCAP foi descriptografado. Ele mostra que o NTLM está sendo usado como o método de autenticação ativa.
Após a autorização de NTLM, o cliente é redirecionado de volta para a sessão original, para que possa alcançar seu destino pretendido, que é http://www.cisco.com.
Quando usada em uma política de identidade, a autenticação ativa tem a capacidade de descartar tráfego permitido (somente HTTP(s)), se algo der errado no processo de redirecionamento. Uma etapa de mitigação rápida é desativar qualquer regra na Política de identidade com a ação da Autenticação ativa.
Além disso, certifique-se de que todas as regras com 'Autenticação passiva' como ação não tenham a opção 'Usar autenticação ativa se a autenticação passiva não puder identificar o usuário' marcada.
Dados | Instruções |
Solucionar problemas do Firepower Management Center (FMC) | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Solucionar problemas do dispositivo Firepower que inspeciona o tráfego | https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
Capturas de pacote de sessão completa | Consulte este artigo para obter instruções |
Se for determinado que o componente Autenticação ativa não é a causa do problema, a próxima etapa será solucionar o problema do recurso de Política de intrusão.
Clique aqui para prosseguir para o próximo artigo.