Cisco NGFW: do PIX ao Firewall Threat Defense

Caio H Santos · ‎05-03-2024

Saudações
Cisco e Sourcefire - Como tudo começou
Cisco e Sourcefire - O inicio da Integração
O nascimento do Firepower Threat Defense (FTD)
Secure Firewall Threat Defense
Conclusão
Referências

Saudações

Fala pessoal, espero que todos estejam bem!

Meu intuito com esta e futuras publicações é compartilhar com todos vocês da comunidade da Cisco os aprendizados e experiências profissionais que tenho adquirido na área de Redes e Segurança da informação. Para começar, decidi criar uma série de artigos nos quais abordarei a solução de Next-Generation Firewall (NGFW) da Cisco, o Secure Firewall Threat Defense (FTD), conhecido por muito tempo como Firepower.

Começarei esta série apresentando um breve histórico sobre o surgimento do FTD e sua evolução aos longo dos anos. Nos demais artigos abordarei conceitos técnicos sobre seus recursos e funcionalidades, bem como demonstrações de configuração em laboratório.

Boa leitura!

Cisco e Sourcefire - Como tudo começou

A Cisco foi uma das pioneiras na oferta de produtos de segurança para a proteção de redes corporativas. Ingressou neste segmento com a comercialização do Firewall PIX (Private Internet Exchange) logo após adquirir a Network Translation em 1995, a empresa desenvolvedora da solução. O PIX era um stateful firewall com capacidade para filtrar tráfego nas camadas 3 e 4, possuía recursos de VPN e suporte para realização de NAT (Network Address Translation), uma de suas principais especialidades.

The History of the PIX

Nos anos seguintes, a Cisco expandiu seu portfólio de segurança adicionando os dispositivos IPS 4200 que realizavam operações básicas de detecção e prevenção de intrusão, e os concentradores VPN 3000, equipamento dedicado para o provisionamento de redes virtuais privadas (VPN).

Anos depois, as funcionalidades oferecidas por essas soluções foram consolidadas em um único equipamento, lançado em 2005 sob o nome de Adaptive Security Appliance (ASA). O ASA utilizou inicialmente o mesmo código do PIX, contudo, migrou para um sistema operacional baseado em linux e ganhou o apelido de LINA (LInux NAtively).

O ASA é um stateful firewall equipado com diversos recursos de segurança e conectividade. Foi por muito tempo a principal solução da Cisco neste segmento, com ampla adoção em redes pequenas/médias e de missão crítica. No decorrer dos anos, sua arquitetura foi aprimorada de forma consistente e atualmente é utilizado com mais frequência na sua versão com "esteróides" e "anabolizantes", o Firewall Threat Defense, tema deste artigo.

O QUE É UM STATEFUL FIREWALL? 

É uma categoria de firewall que monitora e mantém o registro das comunicações que passam por suas interfaces. Ele identifica os endereços IP, portas, protocolos de transporte e, no caso do TCP, analisa as flags citadas no cabeçalho, as quais são responsáveis por determinar o estado de uma conexão (Listen, Established, Closed, etc.).

Estas informações são denominadas de "contexto", e o stateful firewall, por ser mais sofisticado é capaz de tomar decisões de filtragem com base no contexto.

Para exemplificar, quando um segmento TCP aleatório com apenas a flag ACK ativada for recebido na interface do firewall, este irá descartar o pacote, pois, de acordo com o contexto, ou seja, de acordo com as informações armazenadas em sua tabela de conexões, aquele segmento isolado não corresponde a nenhuma comunicação previamente estabelecida.

Nos projetos de redes e segurança, o ASA era um componente geralmente posicionado no perímetro da rede, e suas funcionalidades eram suficientes para lidar com atividades maliciosas que se originavam na internet ou em outras redes externas. Contudo, esse cenário mudou rapidamente devido ao expressivo aumento na variedade, volume e sofisticação dos ataques cibernéticos ao longo do anos.

Neste mundo hostil tornou-se fundamental a adoção de soluções de firewall capazes não apenas de filtrar o tráfego nas camadas 2 a 4, mas também equipados com recursos para fornecer visibilidade e controle de aplicações, realizar inspeção profunda de pacotes, prevenir tentativas de intrusão, proteger contra malwares, descriptografar tráfego criptografado, detectar anomalias em protocolos e correlacionar eventos de segurança usando diversos dados contextuais. Essas funcionalidades definem o que constitui um Next-Generation Firewall.

Para atender estas necessidades, a Cisco introduziu entre 2010 e 2012 novos modelos de hardware ASA, pertencentes a família 5500-X. Estas plataformas possuíam melhor desempenho em comparação com sua antecessora, a 5500 (sem o X) e suportavam o Context Aware (CX), uma solução de NGFW que fornecia serviços de segurança avançados como IPS, URL Filtering, Application Visibility and Control e Web Security. O CX poderia ser implementado por meio de software em um SSD ou em um módulo de hardware, e a interação com o sistema operacional do ASA em termos de processamento de pacotes era realizada através de uma política de MPF, ou seja, o administrador deveria especificar quais fluxos de comunicação seriam direcionado ao CX para inspeções mais sofisticadas

O CX foi comercializado e suportado por algum tempo, porém, foi descontinuado quando a Cisco visando aprimorar sua oferta no segmento de NGFW, anunciou em meados de 2013 a aquisição da Sourcefire, uma renomada empresa no mercado de cibersegurança, fundada em 2001 por Martin Roesch, o criador do Snort.

A Sourcefire possuía em seu portfólio o Sourcefire 3D System, um produto que oferecia um amplo conjunto de recursos de segurança voltados para a proteção de ambientes corporativos.

Segue abaixo um link sobre a aquisição da Sourcefire na época:

[Notícia: Cisco adquire Sourcefire]

O 3D System era composto por um Next-Generation Intrusion Detection and Prevention System (NGIDS/NGIPS) baseado no código do Snort, denominado de 3D Sensor nas versões 4.x e de FirePOWER appliance nas versões 5.x.

Além das funções de IPS/IDS, o FirePOWER estava equipado com funcionalidades de segurança adicionais, como o Advanced Malware Protection (AMP), o anti-virus ClamAV, Security Intelligence, URL Filtering, recursos de Application Visibility and Control (AVC) e mecanismos para fornecer visibilidade em tempo real sobre hosts, usuários e aplicações presentes no ambiente. Estas soluções, conhecidas como Real-time Network Awareness (RNA) e Real-time User Awareness (RUA), faziam parte do recurso de Network Discovery do FirePOWER.

O QUE É O SNORT

É a principal solução de Intrusion Detection e Prevention System (IDS/IPS) de código aberto do mundo. Criado em 1998 por Martin Roecsh, inicialmente foi projetado para realizar detecções de intrusão e o monitoramento passivo do tráfego de rede.

Com o tempo, sua arquitetura foi aprimorada e recebeu funcionalidades que o habilitaram para operar em modo "inline", ou seja, como um Intrusion Prevention System (IPS), capaz de registrar em tempo real as comunicações em trânsito por suas interfaces, detectar anomalias em protocolos, identificar os tipos de conteúdos transportados no Payload das PDUs, detectar/bloquear ataques com base em assinaturas e detectar/bloquear tentativas de enumeração, dentre outros.

Em 2001, Martin Roesch fundou a Sourcefire e apresentou ao mercado corporativo uma solução baseada no código do Snort chamada de Sourcefire 3D System. O 3D System era composto por uma solução de gerenciamento centralizado denominada de Defense Center e por um NGIPS batizado de FirePOWER. Em 2013, a Cisco adquiriu a Sourcefire e integrou o FirePOWER com seu pricipal produto de Firewall na época, o ASA, resultando no lançamento do Firepower Threat Defense em 2015, renomeado para Secure Firewall Threat Defense em 2020. 

Em 2021, a Cisco lançou o Snort 3, uma versão com novos recursos de segurança e com otimizações em suas capacidades de detecção e prevenção de intrusão.

O Sourcefire 3D System incluía também o Defense Center (DC), uma solução capaz de gerenciar múltiplos appliances FirePOWER de forma centralizada e que vinha equipada com recursos que forneciam ao administrador visibilidade completa da rede.

O DC possuía uma interface web que permitia visualizar e categorizar eventos de conexão e segurança, criar dashboards personalizados, gerar relatórios de incidentes e agendar atualizações. Além disso, servia como ponto central para a criação e a implementação de políticas de segurança nos dispositivos gerenciados (FirePOWER), também conhecidos como sensores.

A figura a seguir apresenta a tela de login do Defense Center:

A título de curiosidade, o termo "3D" presente no nome da solução da Sourcefire representava as etapas fundamentais de Discover (Descoberta), Determine (Determinação) e Defend (Defesa) realizadas pelo 3D System, conforme ilustrado a seguir:

Para aqueles interessados em conhecer um pouco mais sobre o finado Sourcefire 3D System segue uma playlist no youtube criada pelo time da Sourcefire:

SourceFire 3D System Playlist

Cisco e Sourcefire - O inicio da Integração

Logo após a aquisição, a Cisco iniciou o processo de integração do FirePOWER versão 5.3+ com o ASA nas versões 9.2.2+ e introduziu no mercado o ASA com os serviços do FirePOWER (ASA with FirePOWER Services), uma nova solução de NGFW desenvolvida para operar nas famílias de hardware 5500-X.

Nesta arquitetura, as funções realizadas pelo FirePOWER rodavam em um espaço separado do sistema operacional do ASA. Nas plataformas 5585-X o FirePOWER residia em um módulo de hardware e nas demais versões era necessário realizar a instalação de um SSD adicional para receber a imagem do NGIPS.

Haviam duas opções para administrar essa solução: você poderia usar o ASDM para gerenciar as políticas tanto do ASA quanto do FirePOWER, ou poderia optar por manter o ASDM e demais softwares de gerenciamento (CSM e CLI) para o ASA e adotar o Cisco FireSIGHT Management Center (FMC), anteriormente conhecido como Defense Center para administrar as políticas relacionadas ao FirePOWER. A segunda opção era a mais recomendada devido aos beneficios de visibilidade e gerenciamento centralizado oferecidos pelo FMC.

A figura a seguir apresenta a tela de login do antigo fireSIGHT:

A topologia a seguir apresenta uma visão geral sobre a arquitetura do ASA com os serviços do FirePOWER e um breve resumo sobre o fluxo de pacotes dentro da caixa:

O cliente produz uma requisição com destino ao servidor e encaminha os pacotes para o ASA, que os recebe em sua interface inside;
A aquisição e controle do tráfego é realizado pelo Lina, código do ASA e os pacotes são submetidos a um pipeline de processamento que inclui etapas como a decodificação das PDUs L2-L4 (frames, pacotes e segmentos), registro de novos fluxos TCP/UDP na tabela de conexões, identificação de conexões existentes, realização de UN-NAT, determinação da interface de saída e a correspondência do fluxo de comunicação nas ACLs configuradas, as quais são baseadas em critérios de camada 3 e 4 apenas.
Os pacotes são direcionados para o motor do Snort através da implementação de uma política de MPF (Modular Policy Framework) no ASA. Isso envolve a configuração de uma ACL, uma class-map e uma policy-map. Esses itens em cojunto são responsáveis por efetivamente identificar e encaminhar o tráfego para o módulo de inspeção. Dentro do Snort, os pacotes são submetidos a análises de segurança mais sofisticadas, que incluem filtros por URL, Aplicações, Security Intelligence, Advanced Malware Protection e inspeções no IPS.
Após o processamento, o Snort envia os pacotes de volta para o Lina junto com um veredito (Liberar ou Bloquear). Caso o veredito seja bloquear, os pacotes são descartados pelo Lina e caso seja uma liberação, o Lina executa os demais procedimentos como NAT, route lookup, rescrita dos cabeçalhos de camada 2 e por fim envia o pacote pela interface de saída até o servidor de destino.

O nascimento do Firepower Threat Defense (FTD)

At the current time, the Cisco ASA FirePOWER product consists of two different products tightly integrated with each other: the ASA Firewall and the FirePOWER Next-Generation Intrusion Prevention System (NGIPS). Whereas critical data sharing between the two has been accomplished, a unified management platform is still in development. - Release Notes Version 5.4.0.12 and Version 5.4.1.11 FireSIGHT System

A Cisco aprimorou consistentemente o FirePOWER no decorrer dos anos, culminando no lançamento do Firepower Threat Defense (FTD) em 2015, uma solução mais sofisticada e equipada com novos recursos e funcionalidades de segurança. O FTD foi apresentado na versão 6.0 e ainda operava de forma independente do ASA. No entanto, em 2016, a Cisco lançou a versão 6.0.1 com melhorias a nível de arquitetura. A partir dessa versão a separação física entre o ASA e o Firepower foi eliminada e as funções realizadas por seus respectivos processos (Lina e Snort) foram unificadas em uma mesma imagem de software.

No Firepower, não é necessário implementar uma política de MPF para direcionar os fluxos de comunicação para o motor do Snort, este procedimento é realizado automaticamente através da interação entre os processos que compõem o sistema operacional da solução. Abordarei como ocorre o fluxo de pacotes dentro do Firepower na parte 2 deste artigo

A imagem abaixo apresenta uma visão geral do Firepower System:

É importante destacar que algumas funcionalidades do ASA como EIRGP, Multicast, VPN (site-to-site e remote access) e device clustering, não eram suportadas nas versões iniciais do Firepower. Contudo, esses e outros recursos de segurança/conectividade foram gradualmente adicionados e otimizados nas demais versões 6.x e 7.x lançadas no decorrer dos anos.

Este tópico, que explora os novos recursos e diferenças entre os softwares é bastante extenso e por isso não entrarei em detalhes neste artigo. Contudo, deixo abaixo um link para o release notes oficial da Cisco e outros links que discutem sobre o tema.

https://www.cisco.com/c/en/us/support/security/defense-center/products-release-notes-list.html

https://networkequipmentcisco.blogspot.com/2018/04/cisco-asa-with-firepower-services-vs-ftd.html

https://community.cisco.com/t5/network-security/firewalls-current-status-of-asa-features-vs-ftd/td-p/3750966

https://dependencyhell.net/2021/firepower-7-0-release-highlights

As imagens a seguir foram retiradas de apresentações no Cisco Live e do guia oficial para a certificação CCNP Security. Elas apresentam um breve resumo sobre a evolução do Firepower ao longo do anos:

Cisco Live TECSEC-3004

Cisco Live TECSEC-3782CCNP Security Cisco Secure Firewall and Intrusion Prevention System Official Cert Guide

O lançamento do FTD foi marcado também por uma mudança na nomenclatura da solução. Anteriormente, o produto desenvolvido pela Sourcefire utilizava o termo "FirePOWER" (POWER escrito em maiúsculo) para referir-se ao componente na arquitetura responsável pelas funções de AVC, URL Filtering, Security Intelligence, IPS/IDS, e para denominar as plataformas de hardware que hospedavam o NGIPS, os modelos FirePOWER 7000 e 8000 . A Cisco manteve essa nomenclatura após a aquisição da Sourcefire até o lançamento do FTD, quando adotou o termo "Firepower" (power escrito em minúsculo) para designar o novo NGFW.

A tabela a seguir apresenta a evolução das nomenclaturas ao longo do tempo:

PRÉ-AQUISIÇÃO

Versão	Nome da Solução	NGIPS	Plataforma de gerenciamento
4.x	Sourcefire 3D System	3D Sensor	Defense Center
5.x	Sourcefire 3D System	FirePOWER	Defense Center

PÓS-AQUISIÇÃO

Versão	Nome da Solução	NGFW	Plataforma de gerenciamento
5.x	FireSIGHT System	ASA with FirePOWER Services	FireSIGHT Management Center
6.x	Firepower System	Firepower Threat Defense	Firepower Management Center
7.x	Secure Firewall	Firewall Threat Defense	Firewall Management Center

Como o Firepower pode ser gerenciado?

O gerenciamento do FTD é realizado exclusivamente através do Firepower Device Manager (FDM), uma aplicação web para gerenciamento local do Firewall, ou através do Firepower Management Center (FMC), a versão aprimorada do FireSIGHT Managemente Center.

Em uma implatação de Firepower, os sensores enviam regularmente para o gerenciador (FDM/FMC) informações sobre os eventos de conexão e segurança que estão ocorrendo no ambiente. Esses dados são processados e correlacionados com outros dados contextuais, proporcionando ao administrador visibilidade completa da rede.

As imagens a seguir apresentam, respectivamente, a tela de login do FMC até a versão 6.4 e o novo dashboard a partir da versão 6.5. A tela de login do FDM permaneceu a mesma até a versão 7.1.

Tela de login do FMC até a versão 6.4

Tela de login do FMC a partir da versão 6.5

Tela de login do FDM atá versão 7.1

Quais plataformas de Hardware/Virtuais suportam o Firepower?

Para acomodar o FTD e também as versões de ASA tradicionais, a Cisco introduziu no mercado as famílias de hardware Firepower 9300 e 4100 em 2015 e 2016 respectivamente, seguidas posteriormente pelas linhas 2100 e 1000 em 2017 e 2019, respectivamente. Essas plataformas são mais sofisticadas que sua antecessora, a 5500-X e estão equipadas com a tecnologia Firepower eXtensible Operating System (FXOS), bem como recursos de clustering e multi-instance, os quais serão abordados na parte 2 deste artigo.

Ainda é possível instalar o FTD nas famílias de hardware ASA 5500-X, exceto na série 5585-X . No entanto, é importante observar que essas soluções serão descontinuadas em breve. Inclusive, a Cisco já anunciou que o FTD na versão 6.6 foi o último lançamento de software para a maioria das plataformas 5500-X existentes, com exceção das séries 5508-X e 5516-X, que suportam até a versão 7.0.

O Firepower também pode ser implantado em ambientes virtualizados que utilizam tecnologias de nuvem privada, como VMware, KVM, Hyperflex, Nutanix e OpenStack, assim como em nuvens públicas, como AWS, Azure, GCP e OCI.

A utilização do FTD em ambientes que utilizam Hyperflex, Nutanix ou OpenStack é viável somente a partir da versão 7.0.

A figura abaixo apresenta as famílias de hardware Firepower:

Cisco Live BRKSEC 2020

Secure Firewall Threat Defense

Em 2020, a Cisco unificou os nomes de seus produtos de segurança sob a marca Cisco Secure. Essa medida foi tomada para simplificar as nomenclaturas das soluções e alinhá-las melhor com seu uso e propósito. Como parte dessa transição, o Firepower Threat Defense foi renomeado para Secure Firewall Threat Defense e o Firepower Management Center para Secure Firewall Management Center.

No ano seguinte, em 2021, a Cisco lançou no mercado a versão 7.x do FTD, trazendo otimizações e novos recursos de segurança/conectividade. Um destaque deste lançamento foi a adoção do Snort 3 como motor padrão para uso em conjunto com o FMC. O Snort 3 possui uma arquitetura mais sofisticada, com diversas melhorias em suas capacidades de detecção e prevenção de intrusões. Foi introduzido na versão 6.7 do Firepower e até então estava disponível apenas via FDM.

Em seguida, nos anos 2022 e 2023, foram apresentadas ao mercado as novas plataformas de hardware: Secure Firewall 3100 e Secure Firewall 4200. A imagem abaixo apresenta o portfólio de hardware da Cisco para o FTD:

Cisco Live BRKSEC-2828

As figuras a seguir apresentam a tela de login do novo FMC/FDM. É importante mencionar que a mudança de nome das plataformas de gerenciamento ocorreu efetivamente a partir da versão 7.2, até a versão 7.1 a tela de login ainda utilizava o nome Firepower Management Center.

A figura abaixo apresenta uma visão geral sobre o Secure Firewall:

Conclusão

No momento em que escrevo este artigo, o Secure Firewall já está na versão 7.4, e a versão de software sugerida pela Cisco para uso em produção, devido à sua qualidade, estabilidade e longevidade, é a 7.2.5, lançada em 2023. Desse modo, os laboratórios práticos que apresentarei em artigos futuros serão elaborados com base nessa versão ou na próxima versão recomendada caso já tenha mudado.

Obrigado por ter chegado até aqui! Espero sinceramente que este conteúdo tenha lhe ajudado a compreender melhor sobre o surgimento e a evolução do NGFW da Cisco até o presente momento. Nos vemos nos próximos artigos. Até breve!