Sinalização Segura

Sinalização Segura
102
VoIP e QoS
Segurança
Tripé
– Autenticação
• Quem está do outro lado da linha de fato
– Integridade
• A conversa não foi alterada no caminho
– Privacidade
• O que se fala não pode ser escutado ou entendido por outros
• Outros não sabem com quem se fala ou estabeleceu chamadas
Atenção: justiça pode autorizar grampo legal
– Communications Assistance for Law Enforcement Act (CALEA) é uma lei
americana aprovada em 1994 que requer que grampo autorizado seja viável em
comunicação pública
103
MSI
VoIP e QoS
103
Protocolos envolvidos
Três protocolos estão de fato envolvidos no tráfego VoIP
– Na sinalização: SIP e Session Description Protocol (SDP)
– Na mídia: RTP
Requisições e respostas SIP não podem ser cifradas fim a fim porque os
campos Request-URI, Via e Route precisam ser visíveis aos proxies
intermediários para que as mensagens sejam roteadas corretamente
A segurança das mensagens de sinalização terá que ser garantida hop a
hop
A criptografia da mídia pode ser fim a fim em geral
– Atenção: proxies de mídia podem ser usados para garantir aderência a CALEA
(permitir grampo)
104
MSI
VoIP e QoS
104
Sinalização segura usando
TCP
SIP and SDP são transmitidos em texto claro na porta 5060, usualmente
usando UDP por questão de eficiência e rapidez
Se a sinalização operar sobre TCP, ela pode ser protegida com uso de TLS
(Transport Layer Security)
– TLS sobre TCP (RFC 2246, RFC 3546)
Se a sinalização operar sobre UDP, ela pode ser protegida com uso de
DTLS (Datagram Transport Layer Security)
– RFC 4347, abril 2006, especifica a versão 1.0
Uso de TLS a cada hop entre origem e destino é indicado por SIPS na URI
– <sips:fulano@domain>
– Similar a https e usa a porta 5061 como default
105
MSI
VoIP e QoS
105
TLS
Protocolo mais utilizado para comunicação segura em redes,
amplamente utilizado para proteger o tráfego Web e para
protocolos de correio como IMAP e POP
– A vantagem primária do TLS é prover um canal orientado a conexão de
forma transparente, tornando fácil proteger um protocolo de aplicação
inserindo TLS entre a camada de aplicação e a camada de transporte
– TLS deve rodar sobre um transporte confiável, tipicamente TCP, que
garante a ordenação dos pacotes e falha quando operando sobre
transporte não confiável como UDP
SIP recomenda o uso de TLS para proxies, servidores de
redirecionamento e registro, e também para os clientes
106
MSI
VoIP e QoS
106
Transport Layer Security
TLS 1.1, versão atual
– TLS sobre TCP V1.1 (RFC 4346, abril/2006)
– Transport Layer Security Extensions (RFC 4366, abril/2006)
TLS 1.2 próxima versão
– Internet draft <draft-ietf-tls-rfc4346-bis-04.txt>
Jan/2008)
(jan/2007, expires
História
– The TLS Protocol Version 1.0 (RFC 2246, jan/1999)
– TLS é uma evolução de SSL 3.0 (1996), originalmente desenvolvido
pela Netscape
107
VoIP e QoS
107
TLS
Envolve três fases
– Negociação entre os pares
• Cliente conecta a um servidor com suporte a TLS e apresenta lista de funções
criptográficas e funções de hash suportadas
– Chave pública: RSA, Diffie-Helmann, DSA
– Cifradores simétricos: RC2, RC4, IDEA, DES, 3DES, AES ou Camellia
– Funções de hash: MD2, MD4, MD5 ou SHA
• Servidor escolhe funções e comunica ao cliente sua decisão
– Troca de chaves públicas e autenticação baseada em certificado
• Servidor envia seu certificado digital assinado por autoridade certificadora (CA) e sua
chave pública
• Cliente checa autenticidade e validade do certificado e da chave pública
• Normalmente apenas o servidor é autenticado, mas cliente também poderia
– PKI
– TLS-PSK ou TLS-SRP para autenticação mútua na ausência de PKI
• Para criar uma chave simétrica para a sessão, cliente codifica um número aleatório
com a chave pública do servidor e envia ao servidor
• Termina a fase de negociação e estabelecimento de chave simétrica
– Troca de mensagens criptografadas com chave simétrica
VoIP e QoS
108
108
Mercado de certificados digitais
Pesquisa da Security Space
–
http://www.securityspace.com/s_survey/data/man.200707/casurvey.html
July 2007
Count
July 2007
%
June 2007
Count
June 2007
%
Growth
%
Verisign total
202,097
58.06
200,100
58.44
-1.00
Verisign
80,096
23.01
79,888
23.33
-1.37
Equifax (Geotrust)
75,822
21.78
74,526
21.77
0.08
Thawte
46,179
13.27
45,686
13.34
-0.57
Comodo Limited
29,524
8.48
29,070
8.49
-0.09
Starfield Technologies, Inc.
14,037
4.03
14,410
4.21
-4.18
DigiCert
9,104
2.62
8,670
2.53
3.30
Unknown
8,528
2.45
8,277
2.42
1.35
GoDaddy.com, Inc.
6,914
1.99
6,047
1.77
12.48
Network Solutions L.L.C.
4,442
1.28
4,206
1.23
3.89
Entrust.net
4,023
1.16
3,991
1.17
-0.84
CA
109
VoIP e QoS
109
Alternativas
Alguns telefones IP e PBX IP suportam TLS
Se produtos não suportam nativamente TLS, podem ser
usadas soluções encapsuladoras de TLS independentes
– Stunnel
– Funciona?
110
MSI
VoIP e QoS
110
DTLS v1.0
(RFC 4347, abril 2006)
TLS falha sobre transporte não confiável
– A camada de codificação do TLS não permite a decodificação
independente de registros: se o registro N não é recebido, então o
registro N+1 não pode ser decodificado
– A camada de negociação do TLS (handshake) assume que as
mensagens de negociação são trocadas de forma confiável e falha se
mensagens são perdidas
DTLS é baseado em TLS e acrescenta mecanismos para
resolver os problemas citados
DTLS roda no ambiente de aplicação e não no kernel
DTLS preserva a semântica do transporte, não compensando
por perda ou reordenação de datagramas
111
MSI
VoIP e QoS
111
Como DTLS ataca os
problemas
Perda de mensagens
– Contexto criptográfico em TLS encadeado entre registros
• DTLS acrescenta estado CBC em cada registro (isso é provido também
no TLS 1.1)
– Proteção contra reordenação de mensagens e ataques de repetição é
alcançada com números de seqüência que estão implícitos nos registros
• DTLS usa números de seqüência explícitos
112
MSI
VoIP e QoS
112
Como DTLS ataca os
problemas
Fase de negociação
– Mensagens de negociação TLS são enviadas e recebidas em um ordem
definida, além de serem potencialmente grandes para um datagrama
• DTLS usa temporizadores para proteção contra perdas
• DTLS enfileira mensagens fora de ordem para posterior processamento
• DTLS acrescenta acrescenta offset e tamanho de fragmento para permitir
recompor uma mensagem fragmentada
– DTLS opcionalmente suporta a deteção de ataque de repetição usando
a mesma técnica de IPsec AH/EP
• Manter uma janela de registros recebidos. Registros muito velhos e registros
recebidos em duplicata são descartados silenciosamente
• A detecção de repetição é opcional, pois a duplicação de pacotes pode
ocorrer devido a erros de roteamento
113
MSI
VoIP e QoS
113
DTLS: DoS ataques
Dois ataques mais prováveis
– Um ataque pode consumir recursos excessivos de um servidor pela transmissão de
mensagens de inicialização de negociação, forçando o servidor a alocar estado e realizar
operações criptográficas excessivas consumindo processamento
– Um ataque pode usar o servidor como um amplificador enviando mensagens de
inicialização com uma identidade forjada. O servidor então envia sua próxima mensagem
(em DTLS, uma mensagem de certificado, que pode ser bastante grande) para a máquina
da vítima.
DTLS usa a técnica de cookie para combater estes ataques
– Quando o cliente envia mensagem ClientHello ao servidor, o servidor pode responder com
uma mensagem HelloVerifyRequest contendo um stateless cookie (gerado usando a
técnica de ICMP seguro)
• Cookie = HMAC(Secret, Client-IP, Client-Parameters)
– O cliente então deve retransmitir o ClientHello acrescentando o cookie
– O servidor verifica validade do cookie para continuar negociação
– Este mecanismo força o atacante/cliente a receber o cookie, que torna o ataque de DoS
com IP forjado mais difícil
– O mecanismo não protege contra ataques vindos de IP válidos
114
MSI
VoIP e QoS
114
S/MIME
SIP pode usar S/MIME para permitir mecanismos como
distribuição de chave pública, autenticação e proteção da
integridade ou confidencialidade na sinalização SIP
– S/MIME permite que SIP UAs cifrem MIME dentro de SIP, fornecendo
confidencialidade e integridade fim-a-fim para as mensagens bem
como autenticação mútua sem afetar o cabeçalho
Também é possível usar S/MIME para fornecer uma forma de
integridade e confidencialidade para os campos do cabeçalho
SIP com tunelamento da mensagem SIP, mas isso pode gerar
um overhead adicional
– Quando S/MIME for usado para tunelamento da mensagem SIP, o uso
de TCP é recomendado pelo SIP para evitar problemas com
fragmentação UDP
115
MSI
VoIP e QoS
115
S/MIME em Mensagem
Instântanea
Definido um Commom Profile for Instant Mensaging (CPIM)
pelo grupo de trabalho do IETF IMPP (Instant Mensaging and
Presence Protocol) (em andamento)
– Protocolos populares que usam o CPIM
• XMPP (eXtensible Messaging and Presence Protocol) usado pelo cliente
Jabber IM
• SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)
O formato de uma mensagem/CPIM é um formato multiparte
MIME que encapsula
– Metadados relativos ao conteúdo e à mensagem
– A mensagem em qualquer conteúdo MIME
– Opcionalmente, uma assinatura eletrônica de acordo com S/MIME, RFC
2633.
116
VoIP e QoS
Formato CPIM
117
VoIP e QoS
CPIM com assinatura
118
VoIP e QoS
Mídia Segura
119
VoIP e QoS
Mídia segura
Opção pela criptografia da mídia pode ser sinalizada pelo parâmetro k do
SDP (RFC 2327), nos seguintes formatos
– k = clear : <chave de criptografia>
• k = clear:DES-CBC/aZ25rYg7/12eR5t6y
• Opções de algoritmos: ver RFC 1423 (DES-CBC, DES-ECB, 3DES, …)
– k = base64 :<chave de criptografia codificada>
– k = prompt
• Solicita chave. DES-CBC default.
Em todos estes casos a chave acaba passando em claro na rede, se a
sinalização não estiver protegida
Para proteger a chave de criptografia da mídia a sinalização SIP deve ser
criptografada
Duas estratégias
– Hop a hop com uso de IPSec
– Fim a fim com uso de chave compartilhada ou mecanismo de chave pública
120
MSI
VoIP e QoS
120
Mídia segura
A privacidade da mídia pode ser alcançada criptografando o
campo de informação (payload) do RTP
O RTP (RFC 3550, seção 9 Security) define um mecanismo
básico para criptografia da mídia (pacotes RTP e RTCP) com
uso de DES-CBC, sem entrar em detalhes de distribuição de
chaves e certificados
121
MSI
VoIP e QoS
121
Segurança no RTP/RTCP
Todos os bytes que serão encapsulados para transmissão em
um único pacote são criptografados como uma unidade
– Algoritmo padrão: DES-CBC (Data Encryption Standard – Cypher Block
Chaining)
Para permitir o uso de CBC, uma seqüência aleatória de 32
bits é prefixada a pacotes RTCP e pacotes RTP têm campos
de seqüência e de sincronização (timestamp) inicializados de
forma aleatória, servindo como inicialização independente
Todavia, recomenda-se o uso de algoritmos mais fortes como
3DES
122
MSI
VoIP e QoS
122
Segurança no RTP/RTCP
A presença de criptografia e o uso da chave correta são confirmados pelo
receptor através de checagem de validade do cabeçalho e carga
– RTP version deve ser igual a 2, o tipo de carga deve ser conhecido e não deve
ser igual a SR ou RR, etc
– Outras verificações podem envolver o tipo de carga, tamanho dos pacotes,
incremento esperado do timestamp, etc
Quando se recebe pacotes RTP de uma fonte pela primeira vez, um certo
número mínimo de pacotes (dois típico) com número de seqüência
crescente deve ser recebido antes da fonte ser considerada válida
Validação pode ocasionar atrasos inaceitáveis
Como DES é uma criptografia vulnerável, outras iniciativas são
recomendadas como SRTP
123
MSI
VoIP e QoS
123
Mídia segura
Duas iniciativas com criptografia mais forte que RTP
– SRTP (Secure RTP) (RFC 3711, 03/2004)
• Usa AES (160 bits) e contempla um mecanismo com canal separado (out-band) para
gerência e troca de chaves
• Não cifra o cabeçalho do RTP, permitindo que mecanismos de compressão de
cabeçalho ao nível de enlace ainda funcionem
– ZRTP (internet draft, RTPSEC, draft-zimmermann-avt-zrtp-o4 , 9/07/2007)
• É um acordo para negociação de chave para a mídia
• Utiliza um mecanismo de troca de chaves dentro do próprio canal (in-band) durante o
estabelecimento da chamada
• ZRTP é transparente para o usuário ou aplicação!
Contudo, nenhuma destas proposições tem tido aceitação maior no
mercado, de modo que ainda são poucas as implementações suportando
um destes padrões
124
MSI
VoIP e QoS
124
SRTP
O SRTP é um perfil do RTP oferecendo não somente
confidencialidade, mas também autenticação da mensagem e
proteção para o tráfego RTP bem como RTCP
SRTP pode conseguir alto desempenho usando AES como
algoritmo padrão e chave de 160 bits
Aumento na segurança
– Confidencialidade e intergridade para RTP/RTCP criptografando os
respectivos campos de carga
– Possibilidade de atualização das chaves de sessão periodicamente
– Uma estrutura que permite atualizações com novos algoritmos de
criptografia
– Segurança para aplicações unicast e multcast
125
MSI
VoIP e QoS
125
ZRTP
Usa esquema efêmero Diffie-Helman para a geração de chaves
– Destrói chaves ao final da sessão
Permite a deteção de ataque de homem no meio (Man in the Middle MITM) pela apresentação de uma pequena seqüência de autenticação (no
display) para o usuário ler e comparar pelo telefone
– Faz cache de informação parcial e combina com a próxima chave gerando uma
continuidade entre chaves semelhante a SSH e prevenindo adicionalmente
ataques MITM
Não usa PKI, certificação de chaves, modelos de confiança, autoridades de
certificação, etc., que trazem complexidade
Negocia as chaves sendo usar servidores, mas num acordo P2P
diretamente no fluxo RTP
Autenticação pode ser conseguida se houver um meio para um cliente obter
a chave de assinatura do outro e autenticar a seqüência de autorização
126
MSI
VoIP e QoS
126
ZRTP
ZRTP pode ser usado e descoberto sem ser declarado ou
indicado na sinalização
– Uso transparente e minimiza interdependência entre sinalização e mídia
Ser ZRTP for indicado na sinalização e houver sinalização
segura fim a fim, a pequena seqüência de autenticação pode
ser automaticamente comparada pelo cliente ZRTP
– Um identificador ZRTP único enviado na sinalização pode fazer a
associação entre a mídia e a sinalização
127
MSI
VoIP e QoS
127
Acordo de segurança para SIP
RFC 3329. Security Mechanism Agreement for the Session Initiation
Protocol (SIP).
Passo1: informa mecanismos suportados pelo cliente
Passo2: desafio e mecanismos suportados pelo servidor
Passo3: cliente seleciona mecanismo e habilita segurança
Passo4: lista original do servidor enviada com resposta ao desafio
Passo5: servidor verifica integridade
128
MSI
VoIP e QoS
128
Ataques
129
VoIP e QoS
Aspectos gerais
Com a convergência de voz e dados, um ataque a VoIP pode
comprometer toda a segurança da infra-estrutura de
comunicações
Por outro lado, sendo VoIP uma aplicação, ela depende da
segurança que a infra-estrutura implementar
Segurança na infra-estrutura de VoIP requer planejamento,
análise e conhecimento detalhado de sua implementação
130
MSI
VoIP e QoS
130
Tipos de ataques
DoS
– Intuito de causar indisponibilidade
Quebra de confidencialidade
– Captura e análise de tráfego IP transmitido sem criptografia ou proteção
Repetição
– Parte de uma chamada é capturada e retransmitida
Man-in-the-middle (MITM)
– Ofensor se coloca entre usuário legítimo e o serviço, fazendo se passar
pelo usuário
131
MSI
VoIP e QoS
131
Níveis de vulnerabilidade
Vulnerabilidade
Descrição
Vulnerabilidades em sistemas relacionados com
VoIP podem comprometer toda a infraestrutura VoIP
Dispositivos VoIP herdam as mesmas
vulnerabilidades que os sistemas
operacionais ou firmware que rodam (em
geral Windows ou Unix)
Infra-estrutura IP
Sistema operacional subjacente
Na maioria dos dispositivos VoIP a configuração
default vem com serviços e portas abertos,
tornando-se vulnerável a ataques DoS,
buffer overflows ou autenticações fracas
Configuração
Tecnologias imaturas podem sofrer ataques
para destruir o serviço ou para manipular;
aplicação legada tem problemas conhecidos
Nível de Aplicação
132
MSI
VoIP e QoS
132
Common Vulnerabilities and
Exposures
Common Vulnerabilities and Exposures (CVE®) is a dictionary of common
names (i.e., CVE Identifiers) for publicly known information security
vulnerabilities, while its Common Configuration Enumeration (CCE™)
provides identifiers for security configuration issues and exposures.
http://nvd.nist.gov/nvd.cfm?advancedsearch
– Busca com openser
– CVE-2006-6876
– Summary: Buffer overflow in the fetchsms function in the SMS handling module
(libsms_getsms.c) in OpenSER 1.2.0 and earlier allows remote attackers to
cause a denial of service (crash) via a crafted SMS message, triggering memory
corruption when the "beginning" buffer is copied to the third (pdu) argument.
– Published: 12/31/2006
– CVSS Severity: 7.5 (High)
133
MSI
VoIP e QoS
133
Common Vulnerabilities and
Exposures
http://nvd.nist.gov/nvd.cfm?advancedsearch
– Busca com openser
– CVE-2007-5469
• Summary: ** DISPUTED ** OpenSER 1.2.2 does not verify the Digest
authentication header URI against the Request URI in SIP messages, which
allows remote attackers to use sniffed Digest authentication credentials to
call arbitrary telephone numbers or spoof caller ID (aka "toll fraud and
authentication forward attack"). NOTE: Debian disputes this issue, stating
that "having the two URIs mismatch is allowed by the standard and happens
in some setups for valid reasons."
• Published: 10/16/2007
• CVSS Severity: 5.0 (MEDIUM)
– CVE-2006-6875
• Summary: Buffer overflow in the validateospheader function in the Open
Settlement Protocol (OSP) module in OpenSER 1.1.0 and earlier allows
remote attackers to execute arbitrary code via a crafted OSP header.
• Published: 12/31/2006
• CVSS Severity: 7.5 (HIGH)
MSI
VoIP e QoS
134
134
Ameaças ao VoIP
DoS
Interceptação de chamada e grampo
Roubo de registro
Inserção de servidor TFTP
Vulnerabilidade da senha default
Interface de servidor Web
136
MSI
VoIP e QoS
136
Ameaça: ataque DoS
Se a infra-estrutura IP sofrer um ataque de DoS não específico
ao VoIP, os retardos ou perdas de pacotes incorridos ainda
podem causar perda significativa de qualidade na voz
DoS dirigido ao VoIP
– Tentativas de registro nos servidores
– Tentativas de abertura de chamadas (envio de invites)
– Envio de pacotes UDP maiores que 65534 bytes na porta 5060 podem
causar falha em telefones IP
– Vírus e worms podem causar DoS devido ao aumento de tráfego
Prevenção
–
–
–
–
IDS, Firewalls com ALG e Session Border Gateways
Configuração e atualização de software
Segregação lógica da rede para tentar confinar ataque
Paliativo nos servidores: limitar número de registros por minuto
137
MSI
VoIP e QoS
137
Ameaça: ataque DoS
Telefones IP usando SO como WinCE, PalmOS, SymbianOS e
POSIX podem ficar vulneráveis pois em geral não rodam
software antivírus e o SO é menos robusto
Programas maliciosos instalados por um ataque podem
capturar a entrada do usuário, capturar tráfego e repassar
informação por um back channel ao atacante
Para uma lista completa de possibilidades de ataques DoS
veja www.syngress.com
138
MSI
VoIP e QoS
138
Exemplos de DoS em VoIP
Reset de conexão TLS
–
Ataque pelo reenvio de pacote VoIP
–
DHCP, DNS, etc
Inundação de pacotes de controle
Mensagens de interrupção
–
Inserir atraso ou ruído, além de forjar participantes em conferências
Ataques a servidores de apoio
–
Alterar tag 802.1Q VLAN ou campo TOS de pacote IP para prejudicar a voz
Injeção de pacotes VoIP
–
Sinais de modem podem ser trafegados como informação de cabeçalho burlando política
Modificação de QoS
–
Captura e reenvio de pacotes fora de seqüência pode gerar atraso e degradar qualidade da voz
Tunelamento de informação
–
Envio do pacote forjado certo pode interrromper a sinalização entre o servidor e telefone IP
Válidas mas falsas causando condição ocupado ou desconexão da chamada
Pacotes inválidos que causam interrupção
–
Relatados em CVEs
139
VoIP e QoS
Ameaça: interceptação e
grampo
Descrição
– No grampo, a chamada é monitorada sem alteração de conteúdo
– Na interceptação, pode haver alteração dos dados
Ataques efetivos apenas na ausência de criptografia
Prevenção:
– Autenticação do usuário sempre
– Uso de criptografia na mídia para preservar a integridade e
confidencialidade
– Uso de criptografia na sinalização
140
MSI
VoIP e QoS
140
Exemplo de grampo
Ferramenta Wireshark (www.wireshark.org)
141
MSI
VoIP e QoS
141
Prevenção contra grampo
Evitar que o tráfego chegue ao ofensor usando switches na rede local e/ou VLAN
ARP spoofing pode ser utilizado em MITM
B
A
A
142
MSI
VoIP e QoS
142
Ameaça: roubo de registro
Ferramenta SiVuS (The VoIP Vulnerability Scanner v1.0.9 Beta)
– Captura e gera mensagens editadas
143
MSI
VoIP e QoS
143
Ameaça: roubo de registro
SiVuS
144
MSI
VoIP e QoS
144
Ameaça: roubo de registro
SiVuS
145
MSI
VoIP e QoS
145
Ameaça: roubo de registro
Desabilitar o registro legítimo do usuário. Como?
– Executar um ataque de DoS contra o equipamento do usuário
• Desregistrar o usuário
• Enviar requisições REGISTER repetidamente (a cada 15s, p.ex.) para
sobrescrever pedido legítimo do usuário
– Enviar um REGISTER falseado com o IP do ofensor para registro
146
MSI
VoIP e QoS
146
Ameaça: roubo de registro
147
MSI
VoIP e QoS
147
Ameaça: roubo de registro
Só funciona se sinalização não for criptografada
– Autenticação no registro apenas não é suficiente pois mensagens
passam em claro
Prevenção: SIPS (SIP over TLS) e autenticação das
mensagens SIP (garantindo integridade também)
148
MSI
VoIP e QoS
148
Ameaça: inserção de servidor
TFTP
Equipamentos IP costumam usar TFTP para atualizar firmware
ou baixar configurações
A inserção falsa de um servidor TFTP permite que um ataque
mude a configuração de um telefone IP
Semelhante a ataque de inserção de DHCP
O uso de IDS (Intrusion Detection System) pode filtrar os
pacotes maliciosos
149
MSI
VoIP e QoS
149
Ameaça: senha default
Comum deixar em equipamentos a senha padrão:
admin/admin ou root/root
Brechas de segurança
– Equipamentos podem operar com configuração default em caso de falta
intermitente de energia
150
MSI
VoIP e QoS
150
Ameaça: interfaces Web
Interfaces Web podem ser usadas para configuração de
telefones IP e equipamentos
Se usar http, contas e senhas podem passar em claro
Prevenção: uso de https (http sobre TLS ou SSL)
151
MSI
VoIP e QoS
151
NAT, IPSec
152
VoIP e QoS
NAT Simétrico
Apenas o
IP/porta de
destino podem
acessar o
IP/porta
internos;
associação
mantida no NAT
O mais
restritivo
Não admite
renegociação
de chamada
153
VoIP e QoS
Full Cone NAT
Qualquer um
pode falar com
endereço
IP/porta
anunciado no
NAT
Menos
restritivo dos
NATs
154
VoIP e QoS
Restricted Cone NAT
Filtro feito com IP
destino apenas,
podendo receber
comunicação de
qualquer porta do
destino
155
VoIP e QoS
Port Restricted Cone NAT
Filtro feito pela
porta
156
VoIP e QoS
Hairpin
Máquina interna com
endereço público
anunciado no NAT pode
ser acessada de dentro,
usando o endereço
público
Associação disponível
para os dois lados do
NAT
157
VoIP e QoS
Atravessando NAT
Problema: chamadas VoIP com clientes atrás de 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 muda para cada conexão (NAT simétrico),
temos o pior cenário
Básico: para operar com NAT é preciso que cliente atrás do NAT inicie a
comunicação
Soluções
– ALG, SBG
– Uso de RTP/RTCP simétrico
– Session Traversal Utilities for NAT (STUN) (out/2008)
158
MSI
VoIP e QoS
158
STUN (RFC 3489), Simple
traversal of UDP through NAT
(obsoleto)
Solução completa e falha
Cliente descobria se estava atrás de um NAT, determina o seu tipo,
descobria 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 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 alternativa no
caso de falha
– O algoritmo de STUN para classificação de NATs era 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
159
VoIP e QoS
Usos de STUN
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
– 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
160
VoIP e QoS
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
161
VoIP e QoS
Convivência com NAT
RTP/RTCP simétricos
– Quando numa comunicação bidirecional a mesma porta é usada nos dois
sentidos da comunicação
Essencial empregar RTP/RTCP simétrico em ambientes com NATs que
não têm a funcionalidade de Application Layer Gateway (ALG)
– Requerem que os clientes usem portas UDP simétricas
– 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
Session Border Controllers (SBCs) e outras formas de repasse RTP/RTCP
(mídia proxy)
O uso de RTP/RTCP simétricos pode facilitar depuração e deteção de
falhas, todavia pode facilitar ataque
162
MSI
VoIP e QoS
162
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
163
MSI
VoIP e QoS
163
IKE
164
VoIP e QoS
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
165
VoIP e QoS
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
166
VoIP e QoS
Recomendações de Segurança
167
VoIP e QoS
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
168
MSI
VoIP e QoS
168
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
169
MSI
VoIP e QoS
169
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
170
MSI
VoIP e QoS
170
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 EAPPEAP ou EAP-TTLS para os outros.
171
MSI
VoIP e QoS
171
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
172
MSI
VoIP e QoS
172
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
173
MSI
VoIP e QoS
173
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
174
MSI
VoIP e QoS
174
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
175
MSI
VoIP e QoS
175
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/
http://archives.neohapsis.com/archives/bugtraq/2006-06/0139.html
http://archives.neohapsis.com/archives/fulldisclosure/2006-08/0617.html
http://archives.neohapsis.com/archives/bugtraq/2006-10/0311.html
• Cisco Unified Call Manager Vulnerabilities
http://www.cisco.com/en/US/products/products_security_advisory09186a00805e8a55.shtml
• 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/products/sw/voicesw/ps556/products_implementation_design
_guide_chapter09186a008063742b.html
176
MSI
VoIP e QoS
176