domingo, 2 de setembro de 2012

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:

Nenhum comentário:

Postar um comentário