The Evolution of Identity Services on Firewalls

The IP address is a basic attribute related to computer systems that rely on the TCP/IP protocol stack to establish network connectivity. As a result, the vast majority of access control rules deployed on Stateful Firewalls are based upon parameters present, for instance, in the IP,TCP,UDP and HTTP headers. Although this protocol-based approach has demonstrated to be powerful, the need for networks that are flexible enough to accommodate multiple classes of users (employees, contractors, guests) along with the increasing need for network mobility, has motivated the search for alternative ways of implementing access control. 

This article briefly examines the creation of firewall rules that include some sort of Identity-based information for the users initiating connection requests. As we will see later, in some scenarios identity information may also be associated with the servers.

The first generation is centered on the captive portal paradigm, mainly relying on downloadable ACLs to differentiate among users that are connecting through the firewall. The second, normally referred to as the ID Firewall, allows the creation of permissions based on MS AD user/group domain information. The third generation, known as the SGT Firewall, represents a true evolution because it provides integration not only between the firewall with the edge devices (such as wireless APs and LAN switches), which are the main source of user information, but also between the firewall with the switches that reside on the server side (as shown in the figure below).

To read the complete article, follow the link to the Cisco Support Community.

https://supportforums.cisco.com/docs/DOC-36198

** Additional Reading

1. A more detailed description of the first generation (https://alexandremspmoraes.wordpress.com/2012/01/27/cisco-firewalls-and-user-based-access-control/)
2. Illustrating the use of RADIUS Authorization Profiles on Cisco IOS  (https://alexandremspmoraes.wordpress.com/2012/02/02/cisco-ios-authentication-proxy-and-radius-authorization-profiles/)

 

Autenticação, Autorização e Accounting: Conceitos Fundamentais

O presente artigo é o primeiro de uma série que discute a utilização do conceito de identidade para a criação de regras de controle de acesso. Por ser um texto introdutório, começaremos justamente pelos conceitos mais básicos. Por exemplo:  – o que é identidade ?

Identidade pode ser definida como “um conjunto de características próprias e exclusivas de um sujeito”. (Vale registrar que, no universo de Redes e Segurança, o sujeito mais comum ainda é o username). Mas para que os processos de diferenciação entre os usuários possam ser iniciados, é necessário primeiramente validar a identidade apresentada. E, para entender como isso acontece, é fundamental conhecer a terminologia a seguir:

• Autenticação: processo de verificação de uma identidade alegada, por meio de comparação das credenciais apresentadas pelo sujeito com outras pré-definidas. A combinação username/password é muito comum mas vários outros métodos estão disponíveis (certificados digitais, biometria, etc).
• Autorização: processo que ocorre após a autenticação e que tem a função de diferenciar os privilégios atribuídos ao sujeito autenticado. Os atributos de autorização normalmente são definidos em grupos mantidos em um base de dados centralizada. (Cada sujeito herda as características do grupo a que pertence…)
• Accounting: processo por meio do qual um equipamento de Rede que implementa uma política de acesso (accounting client), coleta informações sobre a atividade do elemento autenticado e as envia ao servidor de autenticação.

A arquitetura AAA (Autenticação, Autorização e Accounting) define uma forma estruturada para integração dessas três funcionalidades.  Talvez seja mais fácil visualizar o papel de cada um dos componentes se os associarmos às questões que eles foram projetados para responder:

• Autenticação: trata de responder a questão “quem é o usuário ?”
• Autorização: tem a função de definir “o que um usuário (já autenticado) tem permissão de fazer” ?
• Accounting: está relacionada com a questão “o que o usuário fez?”. Através desse processo o cliente de autenticação (equipamento de rede), coleta os dados de atividade do usuário e os envia ao servidor de accounting (o qual, normalmente, contempla todos os elementos AAA).

Listamos abaixo alguns cenários de uso dos conceitos AAA para controle de acesso a serviços de Rede.

• Controle de acesso em ambientes LAN: permite habilitar o acesso (Layer 2) à porta física (no caso de switches) ou ao segmento áereo (no caso Wi-fi). Para viabilizar tal validação, foi criado o padrão IEEE 802.1X, disponível em Wireless APs e switches LAN modernos. Um cuidado a se tomar é que a expressão “suportar 802.1X” significa basicamente controlar o status “up/down” da porta após autenticação, o que é muito pouco diante das possibilidades da solução. Para ter os benefícios é vital especificar detalhadamente todas as funções AAA desejadas.
• Controle de acesso em ambientes VPN de acesso remoto (client-to-site): verifica-se inicialmente o direito de montar o túnel e, a seguir, são validadas as credenciais daquele usuário (extended authentication).
• Controle de acesso através de firewalls: podem ser citados como exemplo as funcionalidades Authentication Proxy (Cisco IOS) e Cut-through Proxy (Cisco ASA). Nesses casos, o firewall intercepta as requisições e aplica regras dinâmicas conforme permissões informadas pelo servidor AAA.
• Controle de Acesso avançado através de Firewalls: especificamente para a família ASA, existem as possibilidades de criação de políticas de acesso baseadas em usuários/grupos da estrutura de diretório corporativo bem como o uso do atributo avançado “Security Group Tag”. (Mas esse tema certamente merece outro post).
• Controle de acesso à Internet num ambiente corporativo, definindo políticas aceitáveis de uso conforme o grupo ao que o usuário pertença (por exemplo: funcionários regulares, sub-contratados e visitantes).

Outra aplicação importante da arquitetura AAA está relacionada ao controle de acesso administrativo aos equipamentos de Rede, tarefa essa para o qual o protocol o TACACS+ é otimizado. Recomando fortemente a leitura do texto “RADIUS e TACACS+: dois protocolos complementares“, para saber mais detalhes sobre o tema.

Bem, esse foi apenas um texto inicial. Em breve teremos outros posts tratando de usos específicos dos conceitos aqui discutidos.

** Notas:

• Apesar de no mundo de TI o sujeito clássico ser um username, tem se tornado cada vez mais freqüente a utilização do termo identidade para definir elementos tais como: dispositivo (ou tipo de dispositivo) de onde partiu o acesso, localidade em que o usuário se encontra (rede corporativa, VPN, ou rede externa) ou aplicação solicitando acesso a um determinado recurso ou processo.
• Dentre as opções existentes para obtenção do username, podemos citar o uso de um prompt apresentado por alguma aplicação ou a extração direta da algum atributo de um certificado digital.

** Artigos Relacionados:

Alguns cenários práticos de uso do conceito de Identidade: https://alexandremspmoraes.wordpress.com/tag/identity/

Para entender sobre a evolução do controle de acesso baseado em Identidade nos Firewalls, veja o seguinte artigo:

http://wp.me/p1loe7-l2

 

** Agradecimentos:

Registro aqui os agradecimentos ao meu grande amigo Andrey Lee por gentilmente ter produzido (e cedido) a ilustração usada nesse post (espero que se lembrem do filme 1 de “O Senhor dos Anéis”…)

Funcionalidade de Stateful Firewall em Roteadores Cisco: yes, we can !!

Na primeira vez que ouvem sobre a possibilidade de implementar soluções de stateful firewall em roteadores, muitos administradores de Segurança demonstram imediata desconfiança…

Por um lado acho compreensível, visto que os roteadores são, por excelência, elementos provedores de conectividade, não impondo restrições para encaminhamento de pacotes (basta que conheçam a rota para o destino de interesse). Vale ainda lembrar que a operação padrão de roteamento tem natureza stateless, já que os pacotes são roteados como entidades individualizadas ( e não como parte de uma conexão).

Entendo ainda que em pontos específicos da rede, tais como Data Center e borda Internet, não é uma prática recomendável apostar todas as fichas em um elemento só.

Mas o que pensar sobre implementar a funcionalidade de stateful firewall em roteadores que atendem localidades remotas e que, tipicamente, não apresentam requisitos elevados de desempenho ? Seria possível ter um firewall de verdade em um tal roteador ? (- Sem dúvida… Caso contrário, nã0 me atreveria a escrever este post… 😉 )

Começo a responder tais perguntas, afirmando que a funcionalidade integrada de stateful firewall não é novidade nos roteadores Cisco. O modelo Context Based Access Control (CBAC), também conhecido como Classic IOS Firewall está disponível há mais de dez anos e o seu sucessor, Zone-based Policy Firewall (ZFW), ilustrado na Figura 1,  há pelo menos seis…

Figura 1: Visão Geral do conceito de “Security Zone”

Neste ponto da discussão você pode estar se perguntando:

– Se já existia o CBAC, por que criar o Zone-based Firewall ? O CBAC não era suficiente ?

Bem, vamos à análise:

• A abordagem CBAC já provia um firewall stateful mas as regras de inspeção eram criadas entre pares de interfaces, não havendo um conceito de “domínio de segurança” (Security Zone, utilizando a nomenclatura do ZFW). Tal característica dificultava a visualização lógica das relações de confiança entre os elementos da topologia e também trazia desafios em termos de expansibilidade. Imagine, por exemplo, criar regras entre dez interfaces distintas ou estabelecer uma política que controle o acesso entre as interfaces Giga 1/1.200  e Giga 1/2.25… (É fácil perceber que uma política INISIDE>OUTSIDE é algo bem mais intuitivo…)
•  A linha de raciocínio de construção de políticas adotada pelo ZFW é muito similar à que se usa para configurar Qualidade de Serviço (class-map para classificar pacotes e policy-map para definir as ações a serem tomadas para o tráfego classificado) e, portanto, para os que já estão acostumados com QoS, assimilar os conceitos do ZFW será mais simples. (A estrutura de configuração é mostrada na Figura 2).
• O modelo proposto pelo Zone-based Policy Firewall permite que o roteador seja configurado de modo a bloquear por default, fato este que o aproxima em comportamento dos appliances de segurança dedicados. Após este passo inicial de “fechar” o roteador, você pode definir os critérios para que os pacotes sejam encaminhados entre duas dadas interfaces (que agora são membros de Security Zones). E teríamos, assim, uma espécie de encaminhamento condicional: além de dispor da rota para o destino, a criação daquela conexão específica deve estar prevista na política de firewall em vigor.

Figura 2: Estrutura de uma política de acesso do Zone-based Firewall

Alguns fatos adicionais merecem especial menção:

1. O ZFW é a abordagem que vem recebendo todos os investimentos no que concerne a evolução funcional. Só convém usar o CBAC em roteadores muito antigos cujo IOS não suporte o novo modelo.
2. O ZFW está disponível nas imagens Security do Cisco IOS, juntamente com as funcionalidades de VPN. Desta forma, se você comprou tal imagem por precisar da conectividade segura materializada pelas soluções de VPN,  a boa notícia é que ganhou um stateful firewall de brinde ! 🙂 ( E reciprocamente…)
3. Os roteadores ISR (Integrated Services Routers), os quais já provêem uma miríade de opções de conectividade e serviços (switching, WLAN, Multicast, Telefonia IP/VoIP, backup via GSM/CDMA/DSL, etc) podem agora ser configurados como gateways condicionais (tanto em modo roteado como modo transparente), o que os torna ainda mais completos e flexíveis.
4. Nunca é demais enfatizar que as listas de controle de acesso (ACLs) empregadas numa política ZFW são de natureza stateful e, portanto, vão muito além de meros filtros de pacotes.

Termino este breve post, propondo que você estude mais a respeito do Cisco Zone-based Policy Firewall para que possa contar com tal recurso em seus projetos que envolvem os roteadores Cisco ISR. Para facilitar o acesso a informações sobre o tema, produzi uma série de artigos e, naturalmente, espero que o material seja útil. (É importante observar, no entanto, que a página do blog mostra os posts mais recentes primeiro… Vale a pena começar pelos “older posts“…)

• https://alexandremspmoraes.wordpress.com/tag/zone-firewall/

*** Nota:

Também é relevante se informar sobre a facilidade de se montar INTRANETS seguras com a tecnologia GET VPN:

• http://wp.me/p1loe7-27

*** Leitura Adicional:

• PCI Compliance for Branch Offices: Using Router-Based Security to Protect Cardholder Data (http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps6538/ps6540/white_paper_c11-542889_ns625_Networking_Solutions_White_Paper.html)

Segurança para Comunicações Unificadas: o que esperar do seu Firewall ?

Em um artigo anterior, apresentamos os conceitos básicos de VoIP, Telefonia IP e Colaboração (http://wp.me/p1loe7-c2) e caracterizamos o papel das redes convergentes como plataforma de negócios. Não é necessária uma longa reflexão para concluir que um tal apelo negocial vem acompanhado da necessidade de se prover segurança para o transporte integrado de vídeo, voz e dados.

Seguindo o clássico raciocínio de que é recomendável criar “camadas de segurança”, resumimos a seguir algumas iniciativas relevantes no que concerne à Segurança de Telefonia IP:

• Separação das VLANs de voz e dados nas portas de acesso dos switches LAN (usando o conceito de “Voice VLAN“)
• Prover proteção contra as técnicas que podem induzir um redirecionamento de tráfego em ambientes de switches LAN (mesmo sem necessidade de configuração explícita de espelhamento de portas). Exemplos de ataques em um tal categoria são ARP Cache Poisoning (combatido com Dynamic ARP Inspection) e emulação do servidor DHCP (combatido com DHCP Snooping).
• Controle de acesso entre subredes associadas a voz e dados.
• Criptografia da voz para evitar a remontagem das conversações eventualmente capturadas
• Proteção dos servidores que implementam as soluções de colaboração usando firewalls
• Proteção das entidades de sinalização (Call Managers, gateways, gatekeepers, etc) por meio de firewalls.

A discussão de todas as técnicas que acabamos de elencar exigiria muitos artigos e, portanto, concentraremos nossa atenção na última delas. E uma das motivações para uma tal escolha é precisamente esclarecer o significado da expressão “inspeção avançada dos protocolos de telefonia“, sempre presente nos descritivos técnicos dos firewalls disponíveis no mercado (mas quase nunca detalhados).

A esta altura, alguém que já conheça os princípios básicos de segurança de redes pode estar se perguntando: ” – Se voz e vídeo são apenas novas aplicações que usam o transporte convergente, por que precisariam de um tratamento especial ao atravessar um firewall…? A resposta está relacionada à forma com que os protocolos de sinalização de Telefonia IP (que podem usar transporte TCP ou UDP) negociam as portas UDP destinadas aos canais de mídia (RTP/RTCP):

• Se os firewalls inseridos entre os elementos de sinalização não entenderem perfeitamente a natureza do protocolo em uso (SCCP, SIP, H.323 ou MGCP), não serão capazes de criar corretamente as conexões RTP/RTCP. E, bem sabemos, deixar um intervalo de portas UDP previamente aberto não é uma boa idéia se você tem intenção de implementar uma política de firewall que tenha alguma dignidade… 🙂
• Apesar de sempre mencionarmos a criação das conexões, também é vital (tanto sob a ótica de segurança como de liberação de recursos) que elas sejam terminadas dinamicamente. Para materializar tal possibilidade é importante que o firewall suporte timeouts diferenciados para as sessões de controle e mídia.
• Os protocolos de sinalização de voz tipicamente incluem o endereço IP em seu payload (camada de aplicação). Desta forma, caso as comunicações se estabeleçam em ambientes com NAT ou PAT, é fundamental que o firewall tenha consciência de tais características para que possa efetuar as traduções de endereços IP nas camadas 3 e 7 simultaneamente.
• Um dos atrativos de Telefonia IP é a capacidade de prover confidencialidade para a voz transportada, usando, por exemplo, sinalização sobre TLS (Transport Layer Security) para então derivar os canais Secure RTP (SRTP) para mídia (vide figura 3). O desafio em uma tal situação é que muitos firewalls não conseguem entender a sinalização cifrada e teriam, portanto, que deixar um grande número de portas UDP (associadas ao SRTP) abertas. Isso, em termos práticos, significa abrir mão da criptografia de voz ou do stateful firewall.

Para auxiliar na compreensão dos principais conceitos da integração de firewalls a projetos de UC , passaremos agora à análise de alguns modelos de topologia: um primeiro, contendo apenas telefones IP, e um mais abrangente, prevendo a existência de gateways de voz e comunicação com a rede pública de telefonia (PSTN). Por último (Figura 3), examinaremos a situação de agregar criptografia a fluxos de voz que atravessam o firewall.

A Figura 1 ilustra um cenário simples em que dois IP Phones SCCP (Skinny), que residem em  redes diferentes, precisam se comunicar em uma topologia protegida por um Cisco ASA. A figura caracteriza a situação inicial (apenas sinalização) e um momento seguinte, com uma ligação estabelecida. (Note que o firewall identifica claramente as portas associadas a áudio). Para fins práticos, vale citar que, além da permissão para registro dos telefones e execução de chamadas (porta de serviço TCP/2000 na direção do telefone ao CUCM ), você precisará criar regras que permitam o uso dos serviços auxiliares:

• TFTP (dos telefones para o CUCM): neste caso, as atribuições principais do servidor TFP são a transferência de arquivos de firmware e configuração para os telefones.
• Resolução DNS do nome do CUCM ( e eventuais serviços complementares).
• DHCP é a escolha tradicional para endereçamento dos IP phones. A opção DHCP 150 informa os telefones sobre o endereço IP do servidor TFTP. Tal funcionalidade pode ser habilitada por interface no próprio Cisco ASA.

Figura 1: Cenário simples usando sinalização SCCP (Skinny)

Há ambientes com complexidade bem superior ao que foi mostrado na Figura 1, exigindo alta capacidade de coordenação por parte do firewall. Isso costuma ocorrer porque, mesmo depois de ter migrado toda a sua rede para telefonia IP, você ainda precisará integrá-la com as redes tradicionais de telefonia, fato este que exige a inclusão dos gateways de voz . Se você estiver usando o conjunto de padrões H.323, por exemplo, a primeira tarefa adicional é decidir se os gateways se comunicarão diretamente com o CUCM ou se haverá o uso de um gatekeeper.

Dentre os protocolos definidos no framework H.323, alguns são de particular relevância para redes VoIP/IPT:

• H.225: responsável por criação e finalização de chamadas em ambientes H.323. As mensagens H.225 usam a porta TCP/1720.
• H.245: responsável por flow control, negociação de funcionalidades e alocação dos canais de mídia, dentre outras atividades. A porta TCP usada para o H.245 é derivada da inspeção H.225.
• H.225 RAS: As mensagens de Registration, Admission and Status (RAS) são usadas nos ambientes em que o roteamento de chamadas de voz é executado de forma centralizada por um gatekeeper H.323. A porta UDP/1719 é reservada para o RAS.

Os dois modelos H.323 brevemente descritos são ilustrados na Figura 2. A principal razão para incluir tal exemplo está relacionada com a tentativa de enfatizar que o firewall deve ser capaz de analisar as várias etapas de sinalização e manter o processo de chamadas o mais transparente possível para os usuários finais.  Note que há várias entidades de sinalização envolvidas (CUCM, gateways, gatekeeper), as quais normalmente estão situadas em diferentes interfaces do firewall. Além disso, o objetivo final (após inspecionar as várias mensagens de controle) é estabelecer a chamada entre os telefones (os quais também podem estar localizados em interfaces diferentes).

Cumpre ainda ressaltar que o Cisco Unified Communications Manager (CUCM) pode operar simultaneamente como controlador de chamadas que usem qualquer dos protocolos mencionados (SCCP, SIP, H.323 e MGCP), o que permite seu uso como elemento de interworking entre tais tecnologias. Mais interessante ainda é o fato de o Cisco ASA poder ser incorporado a um tal cenário sem qualquer perda de funcionalidade.

Figura 2: Inserção do firewall em ambientes com H.323

A Figura 3 traz um cenário que envolve troca de sinalização sobre TLS (TCP 2443 para SCCP/TLS ou TCP/5061 para SIP/TLS) e posterior estabelecimento do canal SRTP através do firewall. Basicamente, o firewall se apresenta como CUCM para os telefones (usando os certificados apropriados) e simula ser um telefone para o CUCM. Após criação de tais relações de confiança, os telefones podem se registrar de forma segura e criar as sessões SRTP pertinentes.

Lembrando que as chaves para criptografia de voz são geradas durante o processo de sinalização, usar mensagens de controle em clear text não é uma abordagem conveniente. (Daí o fato de se recorrer ao transporte sobre TLS).

Figura 3: Criptografia de voz (SRTP) em ambientes com stateful firewalls

Para sintetizar o que foi exposto até aqui, achei interessante criar uma espécie de resumo sobre o que não pode faltar no seu firewall para telefonia, usando como exemplo o protocolo SIP (pois sua tendência de adoção é crescente):

• A partir da análise da sinalização SIP entre o controlador de chamadas IP (Call Manager)  e os telefones IP,  devem ser criadas dinamicamente as permissões pertinentes para o tráfego de mídia (RTP/RTCP) entre os telefones envolvidos.
• Deve ser possível configurar timeouts distintos para a conexão de sinalização SIP e para as conexões de mídia dinamicamente negociadas (RTP/RTCP).
•  A inspeção stateful da sinalização SIP deve estar igualmente disponível para TCP e UDP.
• O firewall deve ser capaz de analisar os pacotes de manutenção do canal de controle (keepalives) de modo a garantir que a conexão de sinalização não necessite ser restabelecida a cada chamada.
• Deve ser possível especificar os métodos SIP (SIP Methods) aceitáveis e bloquear requisições de conexão que utilizem métodos indesejáveis.
• Deve ser possível analisar conexões de sinalização criprografadas (SIP over TLS), de modo que sejam criadas dinamicamente as permissões adequadas para o tráfego de mídia cifrado (Secure RTP) entre os telefones IP envolvidos.

Para ir um pouco além do que foi tratado no presente post, sugiro a leitura do texto Firewalls and UC Security (artigo que escrevi para a Cisco Support Community): https://supportforums.cisco.com/docs/DOC-24159

** Leitura Adicional:

• Para obter mais detalhes sobre o tema (incluindo inúmeros exemplos reais de cenários de aplicação), veja o capítulo 13 do livro Cisco Firewalls: http://www.ciscopress.com/bookstore/product.asp?isbn=1587141094

Múltiplas camadas de defesa: A complementaridade do Firewall e do IPS

Não há muita discussão no que diz respeito à possibilidade de um Sistema de Prevenção de Intrusão (IPS) complementar o trabalho realizado por um firewall stateful. No entanto, é bem comum que se presenciem discussões de cunho quase filosófico sobre o posicionamento relativo de tais elementos em uma topologia de rede. O propósito do presente artigo é discutir as duas opções clássicas e caracterizar porque uma delas se mostra a mais natural. (Não que você precise concordar comigo… :-))

As duas disposições tradicionais são representadas na Figura 1, na qual os conceitos de “antes” e “depois” estão relacionados com o sentido de criação da conexão de uma máquina cliente para um servidor que se deseja proteger.

• No primeiro arranjo, apenas o tráfego permitido pelo firewall é passado ao IPS, o qual, por sua vez, tem função de promover uma inspeção mais detalhada. Imagine, por exemplo, que se tente fazer um telnet, a partir de uma máquina externa, a um servidor web localizado na DMZ. O firewall poderia bloquear tal acesso sem necessidade de uso de qualquer funcionalidade mais elaborada do IPS.
• Já no segundo modelo, todos os pacotes passariam inicialmente pelo IPS antes de chegarem à interface outside do firewall. Em algumas situações cheguei a ouvir que a razão de se ter o IPS na rede outside era permitir que ele “protegesse” o firewall ou que limitasse as novas conexões para tal dispositivo…

Figura 1: Posicionamento Relativo de Firewall e IPS

Refletindo por um instante sobre a atuação dos equipamentos de rede no contexto do modelo de camadas TCP/IP, podemos perceber que a complexidade de operação ( e conseqüente impacto em recursos tais como CPU) aumenta na seguinte ordem: Switch LAN (L2) < Roteador < Firewall < IPS.

Os sistemas IPS concentram seus recursos de análise nas camadas de rede, transporte e aplicação. Além disso mantém informação de estado (stateful pattern matching), realizam detecção de anomalias e, após tais tarefas, ainda precisam encaminhar os pacotes permitidos (na camada de enlace). Tantas atribuições acabam significando que a mais alta performance atingida por um IPS (num dado momento) é aproximadamente 4 ordens de grandeza menor que a do maior switch ou roteador da época e cerca de 1/10 da performance do maior firewall disponível. A última comparação é ainda mais favorável ao firewall se as métricas de conexões por segundo (CPS) e pacotes por segundo (pps) forem levadas em conta, conforme já discutido no artigo “Considerações sobre desempenho de Firewalls” (http://wp.me/p1loe7-15).

Uma outra forma de avaliar o cenário é pensar que se fosse possível construir um IPS com a mesma performance do maior roteador disponível, o custo por Gbps protegido pelo IPS seria certamente muito maior do que o custo por Gbps encaminhado pelo roteador. (Não há mágica aqui… Toda a capacidade de análise de padrões e contexto de um IPS exige módulos de hardware e software complexos, o que naturalmente acarreta custos extras).

Mas de onde vem a (eventual) percepção de que um IPS teria maior desempenho que o Firewall ? (– Seria natural ter o IPS antes do Firewall ?) Enxergo duas possíveis explicações:

• Em um grande número de empresas a solução de IPS foi comprada (ou implementada) bem depois que o firewall já estava em uso. Essa diferença de fase entre os projetos de Firewall e IPS pode ter contribuído para que o IPS fosse selecionado entre as ofertas mais modernas do mercado ao passo que o firewall era um pouco antigo (no que diz respeito a desempenho).
• Os parâmetros utilizados para análise provavelmente foram restritos a throughput (Gbps), de modo que foi negligenciado o fato de que um IPS tem natureza stateful. ( Conforme já mencionado, CPS é um atributo chave na avaliação de qualquer elemento stateful).

Uma opção que pode ser interessante para prover visibilidade adicional é representada na Figura 2. O IPS está localizado depois do firewall e um IDS (Intrusion Detection System) foi acrescentado à rede externa (em modo passivo, sem bloqueio de conexões). Desta forma pode-se obter informação sobre tentativas de ataque (inclusive direcionados a alvos entre o roteador e o firewall). O desafio é justamente ter uma equipe (tipicamente um Grupo de Resposta a Incidentes) que possa tirar proveito dos dados coletados.

Figura 2: Combinando Firewall, IPS e IDS

Se você ainda não está convencido sobre qual seria a opção mais natural, imagine a alegoria proposta na Figura 3. Considerando que o controle de passaporte (ou mesmo o check-in) corresponde ao firewall e que o sistema de raio-X represente o IPS, apenas quem teve acesso concedido ao portão de embarque será submetido à inspeção avançada. Lembre-se de sua experiência em aeroportos e considere a inversão dos processos: todos que chegam ao terminal passam inicialmente pelo raio-X, independentemente de terem viagem marcada…

Figura 3: Ilustrando a relação entre Firewall e IPS

O modelo que emprega o Sistema de Prevenção de Intrusão após o firewall é adequado tanto em projetos em que os equipamentos são distintos quanto naqueles em que o IPS consiste em um módulo do firewall. Na segunda opção é ainda comum que o firewall selecione os tipos de tráfego que serão direcionados ao IPS (em vez de se fazer o espelhamento completo), ação esta que também contribui para um melhor uso dos recursos de IPS.

** Artigos Relacionados:

• Posts em Português: https://alexandremspmoraes.wordpress.com/category/portugues/
• Segurança para Comunicações Unificadas: o que esperar do seu Firewall ? (http://wp.me/s1loe7-1064)
• Revisiting Firewall Performance Parameters: https://supportforums.cisco.com/docs/DOC-16954

** Recursos Adicionais:

• Gravação webex (slides/áudio) sobre Cisco ASA (contemplando IPS): https://cisco.webex.com/ciscosales-pt/lsr.php?AT=pb&SP=EC&rID=61682667&rKey=a32c95c9e790dbc6
• Informação sobre IPS na família Cisco ASA: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/data_sheet_c78_459036.pdf

FLEX VPN: Sample LAN-to-LAN configuration with Dynamic Routing

As a follow on to our FLEX VPN Overview  (http://wp.me/p1loe7-fJ) and to the first post presenting a sample configuration  (http://wp.me/p1loe7-hX), we will now examine a site-to-site scenario that relies on Cisco EIGRP to forward packets over the VPN tunnel. The only modification in our reference environment was the replacement of static routes by a dynamic routing protocol on the participant ISR G2 routers. Some new commands (not explored in the first article) will be used here in an attempt to help you build a tool set that might be handy on your monitoring and troubleshooting tasks.

Figures 1 and 2, respectively summarize the main settings on the HUB and on the SPOKE. Using a routing protocol not only brings scalability to your deployment but also simplies maintenance.

Figure 1: Main settings on HUB1

As depicted in the topologies, the EIGRP adjacency is built over the GRE Tunnel interface (whose subnet is 10.190.1.0/24). After the routers become neighbors, the LAN subnets that need IPSec protection services (10.200.101.0/24 on the HUB and 10.200.201.0/24 on the SPOKE) are advertised to the remote peer. Detailed reachability information for our sample network is provided in Figure 5.

Figure 2: Main settings on SPOKE1

Figure 3 registers the type of information unveiled by the show crypto ikev2 session detail command.

Figure 3: Detailed information about the IKEv2 Session

Figure 4 brings a partial output of the show crypto ipsec sa command and characterizes that the tunnel in place, which is secured by the profile IPSEC-PROFILE1, uses the GRE protocol (notice the permit 47 statement on the IPSEC FLOW).

Figure 4: Information about the IPSec SA and Tunnel interface

Figure 5 reveals connectivity details from the HUB perspective. The show ip route command clearly demonstrates that the EIGRP updates flow trough the GRE tunnel, whereas the show ip cef commands are insightful with respect to forwarding activities. Notice that the show ip cef exact-route even displays the underlying interface used to reach the tunnel destination (172.20.1.1, associated with Loopback 2000 on the SPOKE).

Figure 5: Routing and Forwarding information

It would be instructive at this point to compare the current scenario with that one covering static routes (http://wp.me/p1loe7-hX), document the commands already analyzed and make sure you understand the overall structure (and building blocks) of a FLEX VPN policy.

** Related Posts:

• FLEX VPN series: https://alexandremspmoraes.wordpress.com/tag/flex-vpn/

** Additional Reading:

• FLEX VPN      configuration guide: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book.pdf
• FLEX VPN      authentication options: http://www.cisco.com/en/US/docs/ios-xml/ios/security/a1/sec-cr-a3.html#GUID-D1894BF4-475E-4513-BF9A-9F3FE5276021

Hello World: Simple LAN-to-LAN Flex VPN configuration

Having discussed the motivations behind FLEX VPN (http://wp.me/p1loe7-fJ) and presented information about positioning of Cisco IOS VPN solutions (http://wp.me/p1loe7-gy), it’s now time to jump to some practical scenarios.

Our site-to-site topology consists of two ISR G2 routers connected by a GRE interface, as depicted in Figures 1. The Integrated Services Routers rely on static routes to direct traffic to the tunnel and reach the protected networks (10.200.101.0/24 on the HUB1 site and 10.200.201.0/24 on SPOKE1 site). Authentication is performed by Pre-shared Keys (PSK) defined within a crypto ikev2 keyring. The main settings for this  environment are summarized for HUB1 and SPOKE1 on Figures 1 and 2, respectively.

This sample configuration is also useful to illustrate the overall structure of a FLEX VPN policy. The main building blocks are:

• IKEv2 profile: basically defining how authentication is handled and what identities to consider. Settings such as the keyring (for PSK) and crypto trustpoint (for rsa-sig) are established here. The complete set of parameters contained in the IKEv2 profile are displayed with the show crypto ikev2 profile command.
• IPSec Profile: determines the transform-set for IKE phase 2 (IPSec SA) and points to the IKEv2 profile. This type of profile is tied to the interface (similar to what we did for a crypto-map) by means of the tunnel protection ipsec profile command.

Other important entities (not shown in the configuration) are:

• IKEv2 proposal: specifies the algorithms used to secure the IKE phase 1 SA. Take a look at Figure 3 and use the show crypto ikev2 proposal command to obtain more information about this policy component.
• IKEv2 policy:  selects the IKEv2 proposal and VRFs where to place the VPN packets. Figure 4 registers the settings for the default IKEv2 policy.

Figure 1: Main Configs on router HUB1

It’s interesting to observe that FLEX provides extra flexibility with regards to the authentication process (that can even be asymmetric). Some possibilities are listed below:

• The HUB can use a pre-shared key with all the spokes (which is not the ideal) but still have an individual key to authenticate each of the remotes. In previous models if the HUB had to share a key with all the spokes, that key would be known to all the routers involved. (And therefore it would be easy for spokes to spoof one another).
• Digital certificates (rsa-sig method) can be used to authenticate both sides.
• You can use digital certificates to authenticate the hub and PSK for the spokes.
• There is also support for the Elliptic Curve Digital Signature Algorithm (ecdsa-sig) and for the Extensible Authentication Protocol (EAP).
• Although you can configure only one local authentication method, multiple remote authentication methods are allowed, so that you can cope with different types of peers connecting to a certain router (normally the central element in your topology).

Figure 2: Main configs on router SPOKE1

Figure 3 provides visibility about the IKEv2 and IPSec SAs corresponding to our configuration. Notice that the show crypto session detail command is particularly useful to obtain summarized information about the Security Associations in place, interfaces in use for protected traffic and even encrypted/decrypted packets. The command also characterizes that the IPSec flow is protecting GRE packets (protocol 47) between HUB1 (172.20.20.11) and SPOKE1 (172.20.20.1).

Figure 3: Information about the IKEv2 and IPSec Security Associations

Figure 4 allows us to gain additional insight about this basic deployment. For instance, it reveals:

• The default IKEv2 policy and how it binds to the default proposal (not shown in the configuration)
• Some characteristics of the tunnel interface (source/destination, GRE-based, MTU and attached IPSec profile).
• Another quick way of displaying encrypted and decrypted packets.

Figure 4: IKEv2 Policy, Tunnel Interface and Encrypted Packets

This is the very first article covering sample configurations… So stay tuned for more !

** Related Posts:

• FLEX VPN series: https://alexandremspmoraes.wordpress.com/tag/flex-vpn/

** Additional Reading:

• FLEX VPN configuration guide: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book.pdf
• FLEX VPN authentication options: http://www.cisco.com/en/US/docs/ios-xml/ios/security/a1/sec-cr-a3.html#GUID-D1894BF4-475E-4513-BF9A-9F3FE5276021

Zone-based Firewall and Cisco Security Manager – basic concepts

The initial articles in the Zone-based Policy Firewall (ZFW) series concentrated on basic ZFW behavior and capabilities. The current post shift gears a little bit, by quickly discussing how the Cisco Security Manager (CSM) software can facilitate the operation and maintenance of a network protected by the Zone Firewall.

As depicted in Figure 1, if you are already acquainted with graphical configuration of firewall policies (for ASA and even other vendors’ products), you will notice that the philosophy is basically the same. The traditional logic for rule construction (involving sources, destinations and services) is still there… Yes, that’s it: benefit from the abstraction provided by CSM to build the logical rules and the software will take care of translating them to the CLI commands that materialize the ZFW functionality.

Figure 1 also illustrates another interesting possibility: you can create a ZFW policy on CSM and assign it to multiple devices. This is really relevant when you need, for instance, to deploy multiple branches that have similar rules.

Figure 1: Zone-based Firewall rule table on CSM

Figure 2 shows that you can import the active settings on a live Cisco IOS device and share it on CSM. It’s important to highlight that you can select the types of settings to be imported for later use (ZFW rules, AAA configuration, general platform information and much more).

Figure 2: Sharing device policies through CSMth

Figure 3 displays the CSM Configuration Archive feature, which allows you to keep track of configuration versions (a kind of information that is certainly useful for auditing and meeting compliance requirements). By selecting a saved configuration you can see the configuration commands delivered to the device (Transcript Viewer).

Figure 3: Configuration Archive and CLI Transcript

This was just a quick review of the CSM capabilities regarding the Zone Firewall. It’s naturally recommended that you review the previous ZFW posts and, if possible, that you navigate through the CSM GUI.

** Related Articles:

• Zone-based Firewall series: https://alexandremspmoraes.wordpress.com/tag/zone-firewall/

** Further Reading:

• General Information about Cisco Security Manager: http://www.cisco.com/go/csmanager
• ZFW configuration via CSM: http://www.cisco.com/en/US/docs/security/security_management/cisco_security_manager/security_manager/4.2/user/guide/fwzbf.html

Firewalls and UC Security

Convergent networks that convey  data, voice and video in an integrated manner are spread all around. And this is not just because people consider convergence something fashionable but, rather, because organizations have realized how the concept of Collaboration can contribute to business efficiency and productivity. Of course this convergence promise sounds appealing but along with business relevance comes the responsibility of providing adequate security…

Network Security principles are well mapped and you might be asking what is so special about integrating voice and video.

I will start by saying that the new service possibilities associated with Collaboration are materialized by a set of application protocols that have specific characteristics and networking requirements and, as such, bring new challenges. As usual, from the perspective of network security professionals, the first step is precisely to understand the protocols involved.

And, please, never forget that there is no magic black box approach… Although firewalls constitute one indispensable protection element of an UC Security solution, there are many other resources that need to be taken into account for any practical implementation. For instance, LAN switch, router and IP Phone security features.

Read the complete article on the Cisco Support Community page…

https://supportforums.cisco.com/docs/DOC-24159

GET VPN or Flex VPN…? Do I need both ?

– How Flex is GET ? – What do you get from FLEX ?

On two recent posts we summarized the concepts and motivations pertaining to Flex VPN and GET VPN, two important IPSec-based solutions offered by Cisco. But the availability of these two VPN paradigms may eventually generate some confusion: – Which way to go ? – Do I need both… ?

The figure below provides the backdrop for our current discussion. The two technologies are actually complementary:

• GET VPN is designed for use within environments that do not have the public/private addressing issue and is well suited for materializing what I frequently name the Secure Intranet Service. FLEX is more flexible in that sense because it allows you to deal with either Intranet or Internet-related scenarios.
• GET VPN is tunnel-less in nature and aims at scenarios in which the trust level is shared by VPN participants. An attractive by-product of not using tunnels: GET is very adequate to encrypt multicast, because the same distribution tree built in the WAN to forward the clear text multicast packets is equally available for ciphered ones. (Remember the IP Header Preservation inherent to GET…)
• FLEX is tunnel-based and is able to handle environments involving dynamic (on demand) tunnel setup between spokes, EasyVPN style deployments (when the remote behaves as a hardware client) and many more.
• GET VPN employs group-based Security Associations (SAs), as opposed to the point-to-point SAs that appear on tunnel-based VPNs (including the FLEX VPN framework). Again, this is possible as a result of the trust level parity that characterizes remote sites on INTRANET-only deployments. This is not a limitation of FLEX, which was conceived to cover a broader spectrum of VPN styles ( for which you cannot assume the same trust level for every site).
• GET VPN is used for site-to-site only, whereas FLEX VPN is able to work with site-to-site and Remote Access (RA VPN) deployments at once.
• GET VPN was designed to take advantage of the inherent full-mesh capabilities of MPLS networks. Of course FLEX can be employed on any-to-any clouds but, given that it is tunnel-based, its logical configuration possibilities will be hub-and-spoke and spoke-to-spoke.
• FLEX VPN requires IKEv2 while GET VPN currently supports only IKEv1. (Of course there are plans to add IKEv2 to the GET VPN side of life at some point in time… :-)) The key information to remember: immediate IKEv2 support is less critical for GET (which presupposes private transport) than for FLEX VPN, a technology aimed at tunnel-based scenarios that involve Internet-based transport.

Flex VPN or GET VPN: quick comparison

The good news: if you have a security license on your Cisco ISR G2, the two options are available simultaneously allowing you to select the option that better fits the needs of your specific environment (eventually you will end up employing both). Some general guidelines are presented below:

• For INTRANET-only site-to-site scenarios, GET may prove very appealing. Policy distribution and key management tasks are centralized and the Group SA concept is really convenient. The other key differentiator (associated with its tunnel-less nature) is encrypted multicast.
• On the other hand, for any environment that includes external connections (INTERNET, EXTRANETS and the like), go FLEX. It provides an unified and structured approach for VPN creation and can handle so many connectivity options. And, remember, it relies on IKEv2 for SA negotiation (much more secure than its v1 counterpart).
• If you want to stick to a single way of dealing with all VPNs (site-to-site and Remote Access), FLEX is the answer. Although not offering the Group SA, it covers everything. As discussed in the FLEX article, you can end up with a single block of configuration at the hub and be prepared to terminate any VPN connection.
• If necessary, you can still leverage both technologies at the same router (GET for INTRANET site-to-site interconnection) and FLEX for all the rest.

** Notes:

• For more information on GET VPN, visit: http://www.cisco.com/go/getvpn
• On recent releases, IOS added support for GET VPN IPv6 data plane. IPv4 is still necessary for the control plane: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_getvpn/configuration/15-2mt/sec-get-vpn.html#GUID-8E920B11-BD30-400B-95A5-151588D76B01
• FLEX VPN configuration guide: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book.pdf

** Related Posts:

• VPN Series: https://alexandremspmoraes.wordpress.com/tag/vpn/