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

Segue uma matéria muito boa escrita no Blog de nosso amigo Alexandre Moraes.

Em um artigo no blog do Alexandre Moraes, foi apresentado 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

NBAR - Dedo duro das Aplicações !

Ola  Pessoal,

Estou de volta estudando para CCNP SWITCH !

Nesse primeiro ponto irei falar sobre NBAR ( Dedo duro )

Vamos direto ao assunto...!

NBAR (Network Based Application Recognition) é um mecanismo criado pela Cisco pra, nada mais nada menos, que descobrir o tipo de tráfego (baseado nas portas layer 4) passando por uma interface especificada. E não somente portas conhecidas (<1024), como portas altas, por exemplo de programas P2P!

O objetivo é verificar o tipo de tráfego passando para depois serem aplicadas regras de QoS a fim de priorizar o tráfego que necessita mais prioridade, e limitando o tráfego "não interessante".

E tem mais, é bem simples de habilitar:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface FastEthernet 0/0
Router(config-if)#ip nbar protocol-discovery
Router(config-if)#

Pronto!

Agora para verificar:

show ip nbar resources -> podemos verificar o quanto de memória o NBAR está utilizando.
show ip nbar -> todo o tráfego passando pela interface.
show ip nbar protocol-discovery top-n -> verificar somente o tráfego das top "N" aplicações que estão utilizando os recursos (memória, cpu, etc) do roteador/MLS(Multi-Layer Switch).

A imagem abaixo nos mostra um exemplo do nbar habilitado em um roteador:



Pronto! Agora é só configurar o QoS :)

Abraços!!

Referência: http://slaptijack.com/networking/using-cisco-nbar-to-monitor-traffic-protocols-on-your-network/

Considerações sobre desempenho de Firewalls

Achei valido as informações de nosso amigo Alexandre M. S. P. Morais que trabalha na Cisco Brasil desde 1998 em projetos que envolvem Segurança e VPN, Design de Protocolos de Roteamento, Design de grandes redes LAN e Design de Redes MPLS. 

Certificações

• CCSP (Cisco Certified Security Professional)
• CISSP (Certified Information Systems Security Professional)
• CCIE #6063 (Routing & Switching, Security, Service Provider)

Autor do Livro

• Cisco Firewalls (Concepts, design and deployment for Cisco Stateful Firewall solutions) –  [Cisco Press, 2011]

Muitas das análises  se limitam a olhar o valor nominal de “throughput” (Gbps) e simplesmente ignoram aspectos vitais para o bom funcionamento de um Stateful Firewall . O presente texto é uma tentativa de revisitar tais parâmetros.

1. Novas conexões por segundo (Connections per second) – Há várias soluções no mercado que, apesar de apresentarem um número grande de throughput (Gbps), têm valor muito baixo para o parâmetro connections per second (CPS ). Para entender a importância deste parâmetro, basta lembrar que há várias verificações efetuadas pelo Firewall antes que o tráfego possa passar através do “backplane” dele.  Dentre elas, algumas merecem especial destaque:

• Análise de Fluxo:  o pacote que chegou `a interface de entrada é parte de um fluxo (conexão) existente ou é justamente o primeiro pacote e, portanto, uma nova conexão precisará ser criada ? Isto é particularmente importante para protocolos de aplicação que usam o TCP como transporte. (Basta lembrar das tarefas associadas ao “Three-way Handshake”…)
• O pacote que chegou é permitido pela ACL de entrada ?
• Existe regra de NAT que permita a passagem do tráfego ? (É sempre interessante questionar se os números de desempenho alegados por um fabricante levam em conta o uso de tal funcionalidade).
• Existe rota para encaminhar o pacote ?
• Existe regra de inspeção avançada (inspeção das instruções dentro do protocolo de aplicação)  para este fluxo  ?

Só após estas verificações o tráfego poderá usar o “backplane”.  A limitação do valor de CPS geralmente impede que o elemento chegue a usar o throughput (Gbps).

*Note que a atuação do Firewall é bem diferente de L2 Switching ( a análise deste é feita apenas buscando o MAC de destino numa tabela que associa o endereço L2 à uma porta física…)

** Muitos testes são feitos com pacotes UDP. O mais realista, no entanto, seria usar TCP, não só pelo fato de haver muito mais aplicações práticas que usam tal transporte mas também pelos aspectos de criação e manutenção de conexões (TCP é o transporte eminentemente Stateful, pois possui uma máquina de estados da qual constam Flags, números de seqüência e ACK, etc).

*** O atributo CPS ajuda a lidar com situações de acréscimo brusco de conexões (“flash flood”). Negar conexões por falta de CPS gera retransmissões e mais tráfego agregado de rede.

2. Pacotes por Segundo (pps) – Esta é a principal métrica para Roteadores e, considerando que os Stateful Firewalls (na maioria dos casos) se inserem na topologia como elementos L3, este parâmetro também não pode ser desprezado.

• Na visão de um Firewall Stateful, uma mesma conexão pode envolver muitos pacotes trafegados. (Pense, por exemplo, em uma transferência de um grande arquivo via FTP).
• O desempenho de algumas plataformas quando implementadas em ambientes com “pacotes pequenos”. Às vezes havia a impressão que os Firewalls em uso possuíam algum tipo de limitação no tratamento de tais pacotes. Na realidade, o que acontecia era o seguinte:  – os números de “Marketing” eram calculados com Jumbo Frames (~9000 bytes) e o resultado expresso em Gbps. Os números do ambiente real seguiam um perfil IMIX (~450 bytes). Como a expectativa de desempenho estava associada a Gbps, a decepção era grande… (desempenho 20 vezes menor do que o que constava no data sheet).

3. Conexões Simultâneas ( memória específica para manutenção da tabela de estados): corresponde ao número instantâneo máximo de entradas na tabela de conexões.

• A entrada é removida da tabela de estados após um tempo de inatividade (“idle timeout”).
• Este atributo está de certa forma relacionado com o número de CPS. Por quanto tempo o Firewall consegue absorver novas conexões (sem descartá-las) até o limite de conexões simultâneas ?

4. Throughput (Gigabits/segundo), um parâmetro associado à capacidade de encaminhamento.

Apesar de ser uma métrica muito importante para encaminhamento L2, no caso dos Stateful Firewalls este parâmetro acaba se tornando secundário. Diante do que já foi exposto, o valor de Gbps deveria ser uma conseqüência do número de Pacotes por Segundo (pps) suportado pelo equipamento e do conhecimento das características de tamanho de pacote do ambiente em que o Firewall será instalado.

Um artigo mais detalhado sobre o tema está disponível no seguinte link:

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