SIP Complemento (parte 3) Telefonia IP MAB 618. Paulo Aguiar Tel. (0xx21) Departamento de Computação /IM da UFRJ

Transcrição

1 SIP Complemento (parte 3) Telefonia IP MAB 618 Paulo Aguiar Tel. (0xx21) Departamento de Computação /IM da UFRJ

2 Recomendações de Segurança 2

3 Recomendações de segurança para VoIP Segurança física Segregação de endereços lógicos Usar subrede IP separada para VoIP Implementar VLAN separada para VoIP Facilita QoS e aumenta segurança Usar telefones IP ou ATAS Diminui possibilidades de ataques de vírus entre outros Aumentar a robustez e segurança do SIP Tentar usar SIPS e/ou SRTP Implementar controle dinâmico em firewalls Evitar configurações estáticas, preferindo o uso de ALGs ou semelhantes Usar firewalls em conjunto com roteadores e switches 3

4 Recomendações de segurança para VoIP Planejar cuidadosamente os serviços VoIP Garantir redundância, balanceamento de carga, dispersão geográfica Gerência remota somente com acesso seguro Uma possibilidade é usar uma rede separada para gerência Troca de tráfego apenas com pares confiáveis Usar SBG nos pontos de troca para esconder topologia interna e políticas de ingresso e egresso de tráfego multimídia Usar VPN Usar VPN em acesso remoto para VoIP Reforçar segurança de sistemas de correio de voz Filtrar tráfego que entra e que sai Usar VoIP apenas em redes em fio seguras 4

5 Outras recomendações Assegurar que todos os ativos estão seguros e com as últimas atualizações disponíveis Listar todas as portas usadas pelo VoIP e monitorar uso indevido Usar FTP ou HTTP seguros ao invés de TFTP para baixar atualizações de firmware Usar DNS seguro ou DNS privado se necessário Usar entradas SRV e/ou NAPTR no DNS para garantir redundância, aumento de confiabilidade e balanceamento de carga nos servidores Usar 802.1x na autenticação de usuários e dispositivos 5

6 Autenticação 802.1x 802.1x força o cliente a se autenticar em um servidor de autenticação, tipicamente um servidor RADIUS, antes que a porta do switch esteja disponível e o cliente possa acessar a rede A recomendação é que 802.1x seja utilizado para autenticação em dispositivos e usuários EAP-TLS deve ser usado se uma PKI existir; senão, a recomendação é EAP-PEAP para os ambientes baseados em clientes Windows, e EAP-PEAP ou EAP-TTLS para os outros. 6

7 Outras recomendações Usar NIDS (network IDS) em pontos de troca de tráfego Usar HIDS (host IDS) em todos os serviços críticos do VoIP: DNS, DHCP, RADIUS, NTP, servidores, etc 7

8 Testes de invasão e vulnerabilidade Estes testes são conduzidos por uma equipe que emula e analisa um ataque real em sistemas para descobrir maneiras de burlar a segurança implementada obtendo acesso a serviços não autorizados, descobrir informações sensíveis e/ou simular danos aos sistemas negando serviços Os testes podem ser feitos por pessoas internas ou por empresas especializadas Os testes mantém a equipe sempre atualizada sobre vulnerabilidades e os últimos tipos de ataques lançados na Internet 8

9 QoS Em redes VoIP é preciso usar QoS para não afetar a qualidade, mas algumas medidas de segurança em VoIP podem prejudicar o desempenho de uma conexão afetando a qualidade do serviço. A maior parte dos atrasos causados pela segurança implementada vem da autenticação na troca de chaves 9

10 Serviços e portas mais comuns em VoIP Serviços Portas Skinny TCP TFTP UDP 69 MGCP UDP 2427 Backhaul (MGCP) TCP 2428 Tapi/Jtapi TCP 2748 HTTP TCP 8080/80 SSL TCP 443 SCCP TCP 3224 Transport traffic SNMP UDP 161 SNMPTrap UDP 162 DNS UDP 53 NTP UDP 123 LDAP TCP 389 H.323RAS TCP 1719 H.323 H.225 TCP 1720 H.323 H.245 TCP H.323 Gatekeeper Discovery TCP 1718 SIP TCP 5060 SIP/TLS TCP

11 Fontes para consulta complementar SANS (SysAdmin, Audit, Network, Security) Institute SANS-Top-20 Internet Security Attack Targets N1.4 References Asterisk Vulnerabilities Cisco Unified Call Manager Vulnerabilities General VoIP Security Information VoIPSA Organization NIST Security Considerations for VoIP Systems Voice security, Chapter 19, Cisco Unified Communications SRND 1.html MSI 11

12 NAT 12

13 Esquema de funcionamento do NAT 13

14 Funcionamento do NAT NAT exerce dois controles: mapeamento e filtro Equipamento atrás de NAT só entra na tabela de mapeamento quando ele envia pacotes para fora do NAT (endereço IP destino externo ao NAT) Filtro controla que pode acessar o mapeamento existente Tipos de NAT RFC 3489 STUN Simple traversal of UDP through NAT simétrico, cone restrito, cone restrito por porta, cone completo Mas, comportamento do NAT pode ser dinâmico e se alterar com o tempo 14

15 NAT Simétrico (Symmetric NAT) Filtro sobre o IP e a porta de destino, sendo a comunicação externa restrita a pacotes vindos desta porta do host externo O mais restritivo 15

16 Cone Restrito (Restricted Cone NAT) Filtro feito com IP destino apenas, podendo receber comunicação externa vinda de qualquer porta do host externo, mas apenas dele 16

17 Cone Restrito por Porta (Port Restricted Cone NAT) Filtro feito apenas pela porta 17

18 Cone Completo (Full Cone NAT) Qualquer um pode falar com endereço IP/porta anunciado no NAT Menos restritivo dos NATs 18

19 Convivência com NAT SIP usa informações do cabeçalho, campos CONTACT e VIA para encaminhar requisições e respostas corretamente Se um cliente soubesse como o seu NAT opera, talvez ele pudesse gerar estes campos com a informação presumidamente correta Proxies e clientes podem ser configurados para detetar NAT e corrigir/alterar campos pertinentes 19

20 Convivência com NAT Cabeçalho VIA Parâmetros RECEIVED e RPORT Cabeçalho CONTACT Alterado pelo REGISTRAR Transmissão RTP Via proxy de mídia 20

21 Cabeçalhos VIA Se deteção de NAT estiver habilitada, o servidor ou cliente compara o endereço/porta origem recebidos no pacote IP com a informação presente no campo VIA Note que o último campo VIA presente indica quem repassou a mensagem Se houver diferença, o endereço IP origem e porta origem recebidos no pacote IP são adicionados como os parâmetros received= e rport= ao cabeçalho VIA correspondente 21

22 Exemplo de registro atrás de NAT REGISTER enviado via UDP com campo CONTACT com endereço privado 22

23 Resposta OK Observe received= e rport=10722 inseridos pelo servidor REGISTRAR no campo VIA da resposta Campo CONTACT foi alterado para :10722, que representa a porta SIP de sinalização do cliente (após o NAT) NAT manteve a porta de sinalização escolhida 23

24 Cabeçalho Contact CONTACT é utilizado por mensagens que ocorrem depois da requisição original (como BYE ou um re-invite) Mas o NAT mantém os registros de conexões ativas somente por um período limitado de tempo Solução Reenvio de REGISTER para manter mapeamento do NAT ativo Configurar cliente dependendo do tempo de cache do NAT É normal observar mensagens REGISTER de um mesmo cliente! Cuidado para não interpretar como um ataque ao servidor! 24

25 INVITE após o registro Observe Contact: :10722 (end/porta públicos) Todavia, SDP indica :38704 para a recepção da mídia Este endereço de mídia não vai funcionar fora de rede privada! 25

26 Transmissão RTP Problema As mensagens SDP, usadas para a negociação de portas, codecs e etc, estão confinadas no corpo da mensagem e que por isso não são processadas pelo Proxy SIP, pois o padrão IETF prevê apenas a manipulação do cabeçalho Conterão informações válidas somente dentro da rede interna Solução Utilizar um Proxy RTP (proxy de mídia), o que quebrará a chamada em duas instâncias separadas O proxy de mídia altera no SDP os campos connection information (c) e media description (m) Se o cliente e o servidor usarem uma mesma porta para a troca de mídia nos dois sentidos entre si, temos RTP simétrico RTP simétrico é interessante para manter o mapeamento no NAT (imaginando que há tráfego nos dois sentidos) e permitir o recebimento de mídia mesmo no caso de NAT simétrico (mais restritivo) 26

27 Exemplo envolvendo NAT e proxy de mídia Portas de sinalização identificadas na figura 27

28 INVITE enviado pelo VAIO via PROXY SDP do VAIO anuncia :45286 para receber mídia 28

29 INVITE recebido pelo HP após passar pelo PROXY SDP indica :50528 para envio de mídia ao chamador, forçando a mídia a passar pelo PROXY (que age como proxy de RTP) 29

30 Resposta OK enviada pelo HP SDP indica :51692 para a recepção de mídia Campo CONTACT indica que a sinalização pública do HP é :

31 Resposta OK recebida pelo VAIO SDP indica :240:50528 para o envio de mídia ao chamado 31

32 32

33 RTP Simétrico Cliente envia e recebe pela mesma porta UDP Viabiliza a mídia atravessar o NAT (mesmo sendo NAT simétrico) Desvantagem: se intruso monitora o envio de mídia, ele pode atacar a conversa enviando pacotes RTP para a porta em uso 33

34 Atravessando o NAT Procedimento mais usual é ignorar a informação dentro das mensagens e confiar nos cabeçalhos IP recebidos Tentar descobrir que tipo de NAT trocando mensagens com servidores conhecidos (STUN) Em geral, quando mapeamento do NAT muda para cada conexão (NAT simétrico), temos o pior cenário Para operar com NAT é preciso que cliente atrás do NAT inicie a comunicação Soluções STUN, TURN, ICE, VPN, ALG, SBG RTP/RTCP simétrico 34

35 STUN (RFC 3489), Simple traversal of UDP through NAT (obsoleto) STUN original era uma solução completa, mas falha Cliente descobre se está atrás de um NAT, determina o seu tipo, descobre seu endereço IP e porta do lado público do NAT mais externo e então utiliza este endereço e porta dentro do corpo de protocolos como SIP Todavia, a experiência mostrou que STUN não é uma boa solução prática O endereço e a porta aprendidos pelo STUN clássico são algumas vezes usados para comunicação e algumas vezes não STUN clássico não consegue garantir a operação perfeita e nem estabelece alternativa no caso de falha O algoritmo de STUN para classificação de NATs é falho e muitos NATS não se encaixam na classificação STUN deve ser usado como parte de uma solução para atravessar NAT e não como a solução em si 35

36 Comportamento não determinístico Primário Mantém o mesmo mapeamento se não houver conflito de porta com outra estação Secundário Em caso de conflito com associação existente, muda-se o mapeamento Terciário Ao se adicionar uma terceira associação ao NAT Conseqüência Resultado dos testes pode depender do instante em que os testes são realizados Mapeamento pode ser alterado por tráfego subseqüente 36

37 STUN, ICE e TURN (atualizar) Em alguns casos, a utilização requer extensões ao STUN na forma de métodos, atributos ou códigos de erro em respostas Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols draft-ietf-mmusic-ice-19, expirou em maio, 2008 (atualizar) ICE [MMUSIC-ICE] é uma solução completa para atravessar NAT para protocolos baseados no modelo de oferta/resposta [RFC3264] como SIP Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn- 15, junho 2009 (em progresso) Difere de outros protocolos com relays por permitir que um cliente se comunique com múltiplos parceiros usando um único endereço de relay TURN foi projetado para ser parte de ICE mas pode ser usado independente 37

38 Usos de STUN Managing Client Initiated Connections in the Session Initiation Protocol (SIP) draft-ietf-sip-outbound-20, Junho, 2009 Permite que proxies possam iniciar conexões TCP ou enviar datagramas UDP para agentes de usuário (UA) Firewalls, NATs ou o uso de certificados de servidores com TLS impede a comunicação do proxy com clientes A especificação define o comportamento de UAs, servidores de registro e proxy para permitir o encaminhamento de requisições em conexões previamente estabelecidas pelo usuário Define ainda comportamentos para manter os mapeamentos de NAT e especificar o uso de múltiplas conexões do UA para o servidor de registro 38

39 Convivência com NAT Essencial empregar RTP/RTCP simétrico em ambientes com NATs que não têm a funcionalidade de Application Layer Gateway (ALG) Abrange todos os NATs descritos na seção 4 da RFC4787 [RFC4787]"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January ALGs são definidos na seção 4.4 da RFC3022 Uso de Session Border Controllers (SBCs) e outras formas de repasse RTP/RTCP (mídia proxy) 39

40 IPSec Geralmente usado em um cenário de VPN ou entre domínios SIP Recomendado o uso de IKE (Internet Key Exchange) para a gerência e troca de chaves 40

41 IKE 41

42 IKE Internet Key Exchange Negocia as associações de segurança IPSec Sistemas IPSec autenticam primeiro entre si e estabelecem as chaves compartilhadas ISAKMP Na fase 1, o canal seguro entre as entidades IKE é criado, com Diffie-Helmann sempre sendo executado nesta fase Na fase 2, IKE negocias as associações IPSec e gera o material necessário para a criptografia O transmissor e o receptor concordam no uso de um conjunto de transformadas e algoritmos para a sessão Um novo acordo Diffie-Helman pode ser feito na fase 2 ou chaves podem ser derivadas da chave secreta da fase 1 42