Paulo Aguiar SIP Complemento (parte 3)

SIP Complemento (parte 3)
Telefonia IP
MAB – 618
Paulo Aguiar
Tel. (0xx21) 2598-3165
e-mail: [email protected]
Departamento de Computação /IM da UFRJ
Recomendações de Segurança
MAB618
2
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
MAB618
3
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
MAB618
4
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
MAB618
5
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.
MAB618
6
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
MAB618
7
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
MAB618
8
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
MAB618
9
Serviços e portas mais comuns em VoIP
Serviços
Portas
Skinny
TCP 2000-2002
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
16384-32767
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 11000-11999
H.323 Gatekeeper Discovery
TCP 1718
SIP
TCP 5060
SIP/TLS
TCP 5061
MAB618
10
Fontes para consulta complementar
• SANS (SysAdmin, Audit, Network, Security) Institute
• SANS-Top-20 Internet Security Attack Targets
• http://www.sans.org/top20/#n1
• N1.4 References
• Asterisk Vulnerabilities
http://www.asterisk.org/
• Cisco Unified Call Manager Vulnerabilities
http://www.cisco.com/en/US/products/hw/vpndevc/index.html
• General VoIP Security Information VoIPSA Organization
http://www.voipsa.org/Resources/tools.php
• NIST Security Considerations for VoIP Systems
http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf
• Voice security, Chapter 19, Cisco Unified Communications SRND
• http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/uc6_
1.html
MAB618
MSI
11
NAT
MAB618
12
Esquema de funcionamento do NAT
MAB618
13
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
MAB618
14
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
MAB618
15
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
MAB618
16
Cone Restrito por Porta
(Port Restricted Cone NAT)
•
Filtro feito
apenas pela
porta
MAB618
17
Cone Completo (Full Cone NAT)
•
Qualquer
um pode
falar com
endereço
IP/porta
anunciado
no NAT
•
Menos
restritivo
dos NATs
MAB618
18
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
MAB618
19
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
MAB618
20
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
MAB618
21
Exemplo de registro atrás de NAT
•
REGISTER enviado via UDP com campo CONTACT com endereço privado
MAB618
22
Resposta OK
• Observe “received=146.164.11.67” e “rport=10722” inseridos pelo
servidor REGISTRAR no campo VIA da resposta
• Campo CONTACT foi alterado para 146.164.11.67:10722, que
representa a porta SIP de sinalização do cliente (após o NAT)
• NAT manteve a porta de sinalização escolhida
MAB618
23
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!
MAB618
24
INVITE após o registro
•
•
Observe “Contact: 146.164.11.67:10722” (end/porta públicos)
Todavia, SDP indica 192.168.195.159:38704 para a recepção da mídia
Este endereç
endereço de mí
mídia não vai funcionar fora de rede privada!
MAB618
25
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)
MAB618
26
Exemplo envolvendo NAT e proxy de mídia
•
MAB618
Portas de sinalização
identificadas na figura
27
INVITE enviado pelo VAIO via PROXY
•
SDP do VAIO anuncia 192.168.193.89:45286
para receber mídia
MAB618
28
INVITE recebido pelo HP após passar pelo
PROXY
•
SDP indica 146.164.247.240:50528 para envio de mídia ao chamador,
forçando a mídia a passar pelo PROXY (que age como proxy de RTP)
MAB618
29
Resposta OK enviada pelo HP
•
•
SDP indica 192.168.99.231:51692 para a recepção de mídia
Campo CONTACT indica que a sinalização pública do HP é 146.164.11.67:49181
MAB618
30
Resposta OK recebida pelo VAIO
•
SDP indica 146.164.247:240:50528 para o envio de mídia ao chamado
MAB618
31
MAB618
32
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
MAB618
33
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
MAB618
34
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
MAB618
35
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
MAB618
36
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-turn15, 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
MAB618
37
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
MAB618
38
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 2007.
• 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)
MAB618
39
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
MAB618
40
IKE
MAB618
41
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
MAB618
42