VoIP: Segurança da Informação em Telefonia Baseada em SIP
Este tutorial apresenta uma revisão bibliográfica sucinta acerca dos principais protocolos empregados na
telefonia VoIP e sobre questões de segurança relevantes para o serviço. São abordadas ameaças legadas das
redes IP (que já existiam antes mesmo da tecnologia de voz sobre IP), bem como ameaças específicas à
arquitetura SIP.
André de Almeida Lima
Tecnólogo em Redes de Computadores pelo Instituto Federal de Educação, Ciência e Tecnologia do Espírito
Santo (IFES, 2008) e Especialista em Engenharia de Redes e Sistemas de Telecomunicações pelo Instituto
Nacional de Telecomunicações (Inatel, 2011).
Atualmente trabalha como Trainee Expert na operadora de Telecomunicações Oi, atuando no tratamento de
falhas de banda larga e vídeo.
Email: [email protected]
Guilherme Rezende dos Santos
Bacharel em Sistemas de Informação pela Faculdade de Administração e Informática (2008) e Especialista
em Segurança da Informação pela Faculdade Impacta Tecnologia (2010).
Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX.
Atualmente trabalha com Analista de Segurança da Informação na empresa Cipher Security S/A, e também
é professor da disciplina Segurança em Redes de Telecomunicações do curso de Pós-graduação em
Engenharia de Redes e Sistemas de Telecomunicações do Inatel.
1
Categoria: VoIP
Nível: Introdutório
Enfoque: Técnico
Duração: 20 minutos
Publicado em: 21/05/2012
2
VoIP: Introdução
A telefonia VoIP promete, eventualmente, por fim a mais de um século de rede pública de telefonia
comutada (RPTC), transferindo a inteligência do sistema para as bordas da rede, seguindo a tradição da
Internet.
Como aplicações IP são mais facilmente criadas e distribuídas, tem-se visto um proeminente crescimento do
número de soluções VoIP, vindas de múltiplos fornecedores, sendo apresentadas ao mercado. Neste modelo,
os próprios usuários terão um importante papel na definição, implementação e controle dos serviços de
telefonia ( SICKER e LOOKBAUGH, 2004).
Aliada a isto, a flexibilidade do SIP (Session Initiation Protocol), atualmente o protocolo mais usado para o
estabelecimento de sessões VoIP, torna esta tecnologia cada vez mais viável e atrativa economicamente
quando comparada com o serviço oferecido pela RPTC (SIÉCOLA, 2010).
Em contrapartida, toda esta flexibilidade e disseminação também atrai a atenção dos hackers. O fato da
tecnologia se proliferar não quer dizer que as infraestruturas para comunicação VoIP apresentadas pelos
fornecedores tem se preocupado em blindar as ameaças que são inerentes ao SIP, tampouco as conhecidas
brechas de segurança que flagelam as redes IP e praticamente qualquer serviço oferecido sobre elas.
Diante disto, este tutorial se propõe a examinar quais sãos os principais protocolos que oferecem suporte à
telefonia VoIP e enumera algumas das ameaças que devem ser levadas em consideração quando se pretende
levantar uma infraestrutura baseada em SIP para esta tecnologia, preocupando-se inclusive com as ameaças
legadas das já existentes redes IP.
3
VoIP: Protocolos da Telefonia VoIP
Basicamente, dois tipos de protocolos são utilizados para viabilizar a comunicação VoIP: um protocolo para
sinalização (com objetivo de estabelecer e gerenciar a chamada – sessão) e outro para o transporte da voz
por uma rede IP (SIÉCOLA, 2010).
Diversos protocolos de sinalização foram concebidos por instituições padronizadoras, contudo a maior parte
das aplicações utiliza o SIP (Session Initiation Protocol), descrito no RFC 3261, visto que este protocolo
apresenta flexibilidade quanto à adição de novas features, além de facilidade de implementação e solução
de problemas (DALGIC e FANG, 2011), por isto este trabalho aborda as situações onde este protocolo é
utilizado para o estabelecimento de chamadas VoIP.
O SIP é um protocolo textual baseado em requisições e respostas, bastante similar ao HTTP, que possui
campos de cabeçalho e um corpo. No corpo de uma mensagem SIP é encapsulado algum protocolo de
descrição de sessão responsável pela negociação dos tipos e formatos de mídias que serão trocadas entre as
partes comunicantes, chamadas de User Agents (UA). O RFC 3261 não determina qual protocolo de
descrição de sessão deve ser usado, portanto implementações SIP podem oferecer suporte a múltiplos
protocolos de descrição de sessão. Entretanto, é mandatório o suporte ao SDP (Session Description
Protocol), descrito no RFC 2327, o que faz deste o mais utilizado para negociação de mídias numa sessão
SIP (JOHNSTON, 2009).
Em se tratando do transporte da voz digitalizada por uma rede IP, o protocolo que ganhou o mercado foi o
RTP (Real-time Transport Protocol), definido pelo RFC 3550, que não depende do tipo de protocolo de
sinalização e descrição sendo utilizados. Também no mesmo RFC é definido o RTCP, um protocolo
associado ao RTP que permite a troca de relatórios estatísticos entre os participantes de uma sessão a
respeito da recepção de mídia.
A seguir, é apresentado um tratamento de caráter introdutório sobre os protocolos SIP, SDP, RTP e RTCP.
SIP – Session Initiation Protocol
O SIP é um protocolo da camada de sessão do modelo OSI (camada de aplicação do modelo TCP/IP) que
pode estabelecer, modificar e terminar sessões multimídias - onde sessão é considerada uma troca de dados
entre uma associação de UAs - como uma chamada telefônica pela Internet (ROSENBERG,
SCHULZRINNE e CAMARILLO et al, 2011).
Nesta sessão serão introduzidas as funções básicas do protocolo SIP que tem participação fundamental na
viabilização de VoIP: localização de um sistema final, sinalização da intensão de se comunicar, negociação
dos parâmetros e estabelecimento de uma sessão e término de uma sessão previamente estabelecida
(ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
A Figura1 exibe uma típica troca de mensagens SIP entre dois usuários que desejam se comunicar, André e
Guilherme. Para referência no texto, cada mensagem foi identificada com uma letra “M” e um número entre
parênteses.
O processo começa com o usuário André, no domínio “lima.com” desejando realizar uma chamada ao
usuário Guilherme, no domínio “santos.com”. Os usuários são identificados fora de seu domínio pela sua
identidade SIP, um tipo de URI (Uniform Resource Identifier) similar a um endereço de email. Para o caso
presente, as identidades SIP poderiam ser: sip:[email protected] e sip:[email protected]. Portanto, o
usuário André constrói uma solicitação SIP INVITE (a mensagem M1) conforme a seguir:
4
INVITE sip:[email protected] SIP/2.0
Via:SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>
From: André Lima <sip:[email protected]>;tag=76341
Call-ID: jlaks984309k
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 158
(Conteúdo SDP não exibido)
Figura 1: Estabelecimento de uma sessão SIP
O cabeçalho da mensagem SIP vai da primeira linha até o campo Content-Length. A primeira linha da
mensagem de solicitação exibe o método (INVITE), a identidade SIP do destino
(sip:[email protected]) e a versão do protocolo (SIP/2.0).
A seguir vem o campo Via, que exibe o endereço e a porta para o qual o usuário André espera receber a
resposta de sua solicitação. Neste caso, “pc145.lima.com” é um nome que pode ser traduzido por DNS para
o endereço IP 100.101.102.103 e a porta 5060 é a porta padrão do SIP.
Ainda no campo Via, há o parâmetro branch que serve como um identificador de transação. Desta forma,
respostas referentes a esta transação podem ser identificadas, pois deverão possuir o mesmo valor no
parâmetro branch.
O campo Max-Forwards exibe a quantidade máxima de dispositivos SIP que a mensagem pode atravessar. A
cada salto o campo é decrementado e quando chega a zero é descartado pelo dispositivo SIP que receber a
mensagem.
5
O campo To carrega um nome de exibição (opcional) e a URI SIP que identifica o destinatário.
O campo From carrega um nome de exibição (opcional) e a URI SIP que identifica o chamador. Observa-se
também a presença do parâmetro tag, que é uma sequência de caracteres gerada aleatoriamente pela fonte.
O próximo campo é o Call-ID, outra sequência de caracteres aleatória gerada pela fonte com o objetivo de
identificar uma sessão SIP e, portanto, deve ser única no dispositivo SIP de origem. Na verdade, os User
Agents de origem e destino, também chamados de User Agent Client (UAC) e User Agent Server (UAS),
respectivamente, contribuem com a identificação da chamada cada um com mais uma sequência de
caracteres aleatória, que são os parâmetros tag nos campos To e From. Esses três valores (Call-ID, tag do
campo To e tag do campo From) identificarão completamente um diálogo aberto entre origem e destino. Na
mensagem anterior não há parâmetro tag no campo To porque ele será adicionado quando o destinatário
responder a solicitação INVITE.
O campo seguinte é o CSeq (Command Sequence), que traz um valor inteiro e o nome do método. A cada
nova solicitação enviada dentro de um diálogo o valor inteiro deve ser incrementado. No exemplo acima, o
valor do campo foi iniciado com um (1), mas poderia ser qualquer inteiro maior que zero.
É oportuno dizer que os campos Via, Max-Forwards, To, From, Call-ID e CSeq compõem o menor conjunto
de campos obrigatórios no cabeçalho de qualquer solicitação SIP (JOHNSTON, 2009).
O próximo campo na mensagem INVITE é o Contact, que contém o SIP URI do originador da chamada para
o qual o User Agent de destino poderá encaminhar as transações seguintes diretamente (sem passar por
dispositivos SIP intermediários).
Os dois campos seguintes, Content-Type e Content-Length, informam o tipo de mensagem que está sendo
carregada no corpo do protocolo SIP e qual o tamanho desta mensagem, respectivamente.
Importa dizer que a mensagem INVITE aqui exibida não contém todos os campos possíveis para o método
em questão. Uma lista completa dos campos possíveis numa mensagem INVITE, bem como em qualquer
outra mensagem, está disponível em (JOHNSTON, 2009) e (ROSENBERG, SCHULZRINNE e
CAMARILLO et al, 2011).
Apesar de conhecer a identidade SIP do destinatário, o usuário André não conhece o seu endereço IP atual.
Portanto, de alguma forma, a mensagem SIP deve ser roteada até o dispositivo onde está o UA de destino.
Para isso, o UAC confia num servidor SIP chamado proxy. Servidores SIP serão abordados posteriormente,
por hora importa que um SIP proxy é capaz de receber uma mensagem SIP em seu domínio local, determinar
para qual domínio ela está endereçada, encaminhar essa mensagem para o SIP proxy no domínio de destino
para que este, finalmente, o entregue ao UAS.
Assim, como pode ser observado na Figura 1, a M1 é encaminhada ao servidor proxy do domínio
“lima.com”. Através de uma pesquisa DNS SRV, o servidor proxy do domínio local obterá o endereço do
servidor proxy do domínio remoto, “santos.com”. Contudo, antes de encaminhar uma mensagem SIP, um
dispositivo SIP adiciona um campo Via com seu próprio endereço, adiciona um parâmetro received (que tem
como valor o endereço IP do UAC) ao campo Via original da mensagem e decrementa o valor no campo
Max-Forwards. Desta forma, M2 será:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78
6
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103
Max-Forwards: 69
(O resto não se altera)
Adicionalmente, o servidor proxy do domínio “lima.com” também opta por retornar uma mensagem “100
Trying” (M3) para o UAC, informando que recebeu a solicitação INVITE e tomou providências acerca dela.
Isto impede que o UAC faça retransmissões da solicitação INVITE (ROSENBERG, SCHULZRINNE e
CAMARILLO et al, 2011). Vale destacar que essa não é uma mensagem obrigatória.
Ao receber M2, o servidor proxy do domínio “santos.com” adiciona mais um campo Via com seu endereço,
adiciona um parâmetro received ao campo Via inserido pelo servidor proxy anterior, decrementa o valor no
campo Max-Forwards e encaminha a mensagem ao UAS, Guilherme. Desta forma, M4 será:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf
Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103
Max-Forwards: 68
(O resto não se altera)
Como anteriormente, o proxy do domínio “santos.com” envia uma mensagem “100 Trying” para o proxy do
domínio “lima.com” informando que está trabalhando na solicitação que lhe foi encaminhada. Contudo, essa
mensagem não é repassada pelo proxy do domínio “lima.com” para o UAC, pois mensagens “100 Trying”
são do tipo hop-to-hop, isto é: nunca são repassadas.
Ao receber a M4, o UAS opta por gerar uma mensagem “180 Ringing”, M6, para informar que já recebeu a
solicitação INVITE e está aguardando ação do usuário (por exemplo, atender ou rejeitar a ligação).
Mensagens “180 Ringing” também são opcionais, mas, ao contrário da “100 Trying”, devem ser repassadas
até retornar ao UAC.
Como M4 chegou ao destinatário final com três campos Via, o User Agent sabe que a solicitação passou por
dois dispositivos SIP intermediários e a rota de retorno para todas as mensagens dentro do contexto da
transação INVITE devem passar pelos mesmos dispositivos SIP. Desta forma, M6 é encaminhada ao proxy
do domínio “santos.com” conforme mostrado a seguir:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf;
received=200.201.202.203.204
Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>;tag=762920
From: André Lima <sip:[email protected]>;tag=76341
Call-ID: jlaks984309k
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
Essa mensagem simplesmente copia os campos Via, To, From, Call-ID e CSeq da mensagem de requisição
INVITE original, mas como agora não há corpo na mensagem, o campo Content-Type não existe e o valor de
7
Content-Length é zero. Além disto, o parâmetro tag foi adicionado ao campo To.
É importante atentar para o fato que, ainda que esta mensagem tenha como origem o usuário Guilherme e
destino o usuário André, os campos To e From não se alteram. Isto acontece porque estes campos
identificam a direção da requisição e não a direção de uma mensagem específica (ROSENBERG,
SCHULZRINNE e CAMARILLO et al, 2011).
Deve-se notar ainda que o campo Contact agora contém o endereço para o qual o usuário André poderá
enviar as próximas transações diretamente para o usuário Guilherme sem auxílio dos servidores proxy, a
saber: “sip:[email protected]”, um nome que pode ser traduzido por DNS para o endereço IP
200.201.202.203.
Ao receber M6, o proxy do domínio “santos.com” checa que o primeiro campo Via contém seu próprio
endereço, então ele o remove e encaminha a mensagem para o endereço e porta informados no segundo
campo Via (proxy.lima.com, 5060).
Similarmente, o proxy do domínio “lima.com”, ao receber M7 observa que o endereço no primeiro campo
Via é o seu próprio endereço. Logo, ele o remove e, finalmente, encaminha a mensagem ao originador, o
UAC. Assim, M8 é:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103
Max-Forwards: 68
To: Guilherme Santos <sip:[email protected]>;tag=762920
From: André Lima <sip:[email protected]>;tag=76341
Call-ID: jlaks984309k
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
No exemplo presente o usuário Guilherme decide atender a ligação, portanto uma mensagem “200 OK” é
enviada. Essa resposta é construída da mesma forma que a “180 Ringing”, contendo o mesmo parâmetro tag
no campo To e o mesmo endereço de contato direto no campo Contact. Uma resposta “200 OK” também
indica que os tipos e formatos de mídias negociadas pelo SDP foram aceitos, por isso no corpo da mensagem
SIP é levada uma mensagem SDP carregando essa informação.
Como a mensagem “200 OK” ainda faz parte da transação INVITE, o caminho de retorno deve passar pelos
mesmos dispositivos SIP como aconteceu com a mensagem “180 Ringing”. Desta forma, M9 é:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf;
received=200.201.202.203.204
Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>;tag=762920
From: André Lima <sip:[email protected]>;tag=76341
Call-ID: jlaks984309k
CSeq: 1 INVITE
Contact: <sip:[email protected]>
8
Content-Type: application/sdp
Content-Length: 158
(Conteúdo SDP não exibido)
Como anteriormente, os servidores proxy no caminho verificam seus endereços no primeiro campo Via da
mensagem que recebem, removem este campo, decrementam o valor no campo Max-Forwards e repassam a
mensagem para o próximo endereço e porta do campo Via abaixo.
Neste ponto, é interessante destacar que respostas à requisições SIP são sempre compostas por um número
de três dígitos seguido por uma frase informativa, como em: “100 Trying”, “180 Ringing”, “200 OK”. Estas
respostas são classificadas de acordo com o primeiro dígito de seu número. Os dois dígitos seguintes servem
como um subtipo. A Tabela I, extraída de (SIÉCOLA, 2010), mostra as respostas SIP com suas
classificações.
Tabela 1: Classes de respostas SIP
RESPOSTA
CLASSE
1xx
Informativas
2xx
Sucesso
3xx
Redirecionamento
4xx
Falha na Requisição
5xx
Falha no Servidor
6xx
Falha Global
O último passo para estabelecer a sessão é o UAC confirmar o recebimento da resposta “200 OK”,
permitindo então o início do tráfego de mídia usando outro protocolo (o RTP, por exemplo). Essa
confirmação é feita com uma requisição ACK, que é a mensagem M12:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKf992uij
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>;tag=762920
From: André Lima <sip:[email protected]>;tag=76341
Call-ID: jlaks984309k
CSeq: 2 ACK
Content-Length: 0
Inicialmente deve-se observar que a primeira linha da requisição agora conta com o endereço que o UAS
previamente informou como sendo seu endereço de contato direto. Desta forma, o usuário André pode
enviar o ACK diretamente para o usuário Guilherme sem intervenção dos servidores proxy. O campo
Contact também foi removido, uma vez que o UAS já foi informado do endereço de contato direto do UAC.
Nota-se ainda que o parâmetro branch do campo Via é diferente dos anteriores, uma vez que esta mensagem
ACK é considerada uma transação diferente da INVITE. Por outro lado, os parâmetros tag dos campos To e
From, bem como o Call-ID não se alteraram porque esta mensagem ainda faz parte do mesmo diálogo que
as mensagens anteriores. Agora, a troca de informações da mídia negociada pode então finalmente
9
acontecer.
Após o tráfego de mídia, o usuário Guilherme deseja encerrar a sessão e para isso envia uma Requisição
BYE para o usuário André, a mensagem M13:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hG4bK098jUkj
Max-Forwards: 70
To: André Lima <sip:[email protected]>;tag=76341
From: Guilherme Santos <sip:[email protected]>;tag=762920
Call-ID: jlaks984309k
CSeq: 3 BYE
Content-Length: 0
Novamente, o parâmetro branch é diferente daquele nas requisições INVITE e ACK porque o BYE é uma
transação diferente, contudo os parâmetros tag e o Call-ID permanecem os mesmos já que ainda trata-se do
mesmo diálogo. Contudo, como agora esta é uma requisição direcionada ao usuário André, os campos To e
From estão trocados em relação às mensagens anteriores. Portanto, neste momento o usuário Guilherme age
como um UAC e o usuário André como um UAS.
Isto posto, infere-se que toda implementação SIP deve contar com um módulo cliente e um módulo servidor,
visto que estes papéis são dinâmicos dentro de um mesmo diálogo.
Para finalizar a sessão, o UAS (usuário André) agora responde a solicitação BYE com uma mensagem “200
OK”, M14:
SIP/2.0 200 OK
Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hG4bKfw19b;
received=200.201.202.203
Max-Forwards: 70
To: André Lima <sip:[email protected]>;tag=76341
From: Guilherme Santos<sip:[email protected]>;tag=762920
Call-ID: jlaks984309k
CSeq: 2893 BYE
Content-Length: 0
Com isso, completa-se o ciclo SIP de localização de usuário, sinalização, estabelecimento e encerramento de
um diálogo. Contudo, não discutido aqui é como os servidores proxy são capazes de localizar um usuário. Na
verdade há diferentes mecanismos para cumprir com esta finalidade, seja usando o protocolo SIP ou outros
protocolos.
Servidores SIP
Servidores SIP são aplicações que recebem solicitações SIP, executam alguma operação com ela e devolvem
uma resposta ao dispositivo que a solicitou.
Há três tipos de servidores SIP: servidor de proxy, servidor de redirecionamento e servidor de registro.
Como são entidades lógicas, mais de um servidor SIP pode estar hospedado num mesmo dispositivo físico
(YOSHIOKA, 2003).
10
Servidor Proxy
A sessão 2.1 introduziu o servidor proxy como um facilitador de troca de mensagens SIP, sendo o elemento
responsável pela localização do User Agent alvo da requisição.
É importante esclarecer que um proxy diferencia-se de um User Agent em três pontos chave
(ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011):
Não formula requisições SIP, apenas responde e trabalha em solicitações de User Agents (os métodos
CANCEL e ACK são exceções);
Não é multimídia, isto é, não produz fluxos de mídia (exceto o próprio texto contido nas mensagens
SIP);
Não analisa o corpo de uma mensagem SIP, trabalhando exclusivamente nos campos de cabeçalho.
Na configuração exibida na Figura 1, conhecida como Trapezoide SIP, cada User Agent é configurado
previamente para saber qual é o proxy padrão no seu domínio. Toda mensagem SIP será encaminhada para
este servidor quando o UAC não souber qual endereço de contato direto do UAS com quem pretende
estabelecer uma sessão.
Quando recebe uma requisição SIP, o proxy analisa para qual domínio a mensagem está destinada e obtém o
endereço do servidor de proxy do domínio de destino, tipicamente através de uma pesquisa DNS SRV.
Alternativamente, por motivos que estão fora do escopo da presente discussão, um proxy também pode
rejeitar uma solicitação. Neste caso é retornada uma mensagem “406 Not Acceptable” ao UA.
Dentro do seu domínio, um servidor proxy tem acesso a uma abstração chamada de serviço de localização,
tipicamente um banco de dados populado pelo servidor de registros (Registrar – tratado posteriormente) que
armazena a relação entre identidades SIP externas e o endereço atual do dispositivo onde o UA está sendo
executado. É desta forma que os servidores proxy resolvem o problema de localização do alvo de uma
requisição SIP.
Ademais, um servidor proxy pode operar com estado (stateful)ou sem estado (stateless). No modo stateful,
o proxy mantém um contador de tempo e registros para todas as requisições e respostas que recebe e repassa
e usa essas informações no processamento futuro de mensagens pertencentes a um mesmo diálogo. No modo
stateless não há contadores de tempo nem registros das requisições e respostas repassadas anteriormente,
desta forma não há retransmissões de mensagens perdidas e nenhum tipo de processamento para mensagens
futuras pertencentes a um mesmo diálogo (YOSHIOKA, 2003).
Servidor de Redirecionamento
Tal como um servidor proxy, um servidor de redirecionamento também auxilia no processo de localização do
destinatário de uma requisição SIP, mas não encaminha requisições SIP. Em vez disto, apenas responde ao
UA de origem qual é o endereço de contato para atingir o UA de destino, ou um endereço de próximo salto
para um servidor proxy ou outro servidor de redirecionamento mais próximo, sem se envolver de fato na
comunicação (YOSHIOKA, 2003).
Detalhamentos sobre as mensagens trocadas entre um UA e um servidor de redirecionamento podem ser
obtidos em (JOHNSTON, 2009).
Servidor de Registro
11
Um servidor de registro, também chamado Registrar, aceita requisições SIP REGISTER. Qualquer outra
solicitação recebe como resposta um “501 Not Implemented” (ROSENBERG, SCHULZRINNE e
CAMARILLO et al, 2011).
A Figura 2 mostra uma situação em que o usuário Guilherme solicita ao servidor de registro em seu domínio
que crie um vínculo entre sua identidade SIP externa (também chamada de Address-of-Record, ou
simplesmente AOR) e seu endereço atual.
Figura 2: Exemplo de Registro SIP
A solicitação REGISTER é:
REGISTER sip:reg.santos.com SIP/2.0
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK019jesd
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>
From: Guilherme Santos <sip:[email protected]>;tag=456098
Call-ID: 3487654
CSeq: 1 REGISTER
Contact: sip:[email protected]
Content-Length: 0
O campo To traz o AOR que para o qual o UA deseja registrar o seu endereço de contato atual. O campo
Contact traz o endereço de contato atual que deve ser associado ao AOR. Os campos To e From usualmente
trazem o mesmo endereço, exceto quando há um terceiro dispositivo que faz o registro em nome de outro
UA (JOHNSTON, 2009).
Ao receber a requisição REGISTER, o servidor de registro atualiza o banco de dados usado pelos servidores
proxy e de redirecionamento para localização de usuário e responde com uma mensagem “200 OK”
informando que o registro foi feito com sucesso da seguinte forma:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK019jesd
Max-Forwards: 70
To: Guilherme Santos <sip:[email protected]>;tag=374060164
From: Guilherme Santos <sip:[email protected]>;tag=456098
Call-ID: 3487654
CSeq: 1 REGISTER
12
Contact: sip:[email protected];expires=3600
Content-Length: 0
O campo Contact confirma o endereço de contato que foi registrado para o AOR e traz um parâmetro
expires que informa a quantidade de tempo em segundos para a qual o registro permanecerá válido. Se o UA
desejar que o seu registro continue válido por mais tempo, basta enviar outra requisição REGISTER ao
servidor de registro antes que o tempo expire.
Analogamente a um sistema de telefonia celular, o registro tipicamente é feito enquanto o dispositivo SIP
está iniciando. A forma como o UA toma conhecimento do endereço do servidor de registro está descrita na
seção 10.2.6 de (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
SDP – Session Description Protocol
Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro
protocolo, comumente o SDP.
O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito
original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e,
portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas
atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY,
JACOBSON e PERKINS, 2011), para garantir a compatibilidade.
De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a
sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente “RTP/AVP”),
número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto
e etc.) e esquema de codificação de mídia.
Similarmente ao SIP, o SDP é um protocolo textual cujas mensagens são compostas por campos. Cada linha
da mensagem é um campo e começa com uma letra minúscula. Nem todos os campos são obrigatórios, mas,
se presentes, devem aparecer na ordem especificada na Tabela II, retirada de (SIÉCOLA, 2010).
Tabela 2: Campos SDP
CAMPO
NOME
OBRIGATÓRIO
v=
Versão do protocolo
Sim
o=
Criador e identificador
da sessão (origem)
Sim
s=
Nome da sessão
Sim
i=
Informação
sessão
u=
Uniforme
Resource
Identifier – URI
Não
e=
Endereço de email
Não
p=
Número de telefone
Não
sobre
a
Não
13
c=
Informação
conexão
sobre
b=
Informação
sobre
largura de banda
Não
t=
Tempo para início e
término da sessão
Sim
r=
Número de repetições
Não
z=
Correções
horário
Não
k=
Chave de criptografia
(não utilizado mais)
Não
a=
Linha de atributos da
sessão
Não
m=
Informações sobre a
mídia
Não
a=
Atributos da mídia
Não
de
a
fuso
Sim
Como detalhado em (ROSENBERG e SCHULZRINE, 2011) e amplamente exemplificado em (JOHNSTON
e SPARKS, 2011), o SDP é baseado no modelo de oferta e resposta (Offer/Answer Model). Resumidamente,
neste modelo um participante da sessão (o UAC) gera uma mensagem SDP (a oferta) informando quais
mídias (e seus respectivos esquemas de codificação) gostaria de trocar, bem como seu endereço IP e porta
onde gostaria de receber o fluxo de mídia. O outro participante (UAS) responde com uma mensagem SDP (a
resposta) que tem um fluxo de mídia correspondente para cada fluxo de mídia descrito na oferta (isto é, para
cada campo “m =” na oferta, deve haver um campo “m =” correspondente na resposta) indicando se o fluxo
é aceitável ou não. Na resposta, também são informados o endereço IP e porta onde o UAS gostaria de
receber o fluxo de mídia sendo negociado.
Para exemplificar, abaixo segue a oferta SDP carregada em M1 da Figura 1:
v=0
o = André 2890844526 2890844526 IN IP4 pc145.lima.com
s=c = IN IP4 100.101.102.103
t=00
m = audio 46000 RTP/AVP 0 6 8
a = rtpmap : 0 PCMU/8000
a = rtpmap : 6 DVI4/16000
a = rtpmap : 8 PCMA/8000
A primeira linha traz o campo versão. A versão atual e única do protocolo SDP é a zero (0). Portanto, uma
mensagem SDP válida sempre começa com “v = 0”.
O campo seguinte contém informações sobre o originador da mensagem. Esse campo identifica
exclusivamente a sessão no contexto do SDP. O primeiro valor depois do “=” é o parâmetro username, que
14
tipicamente contém o nome de login ou host do originador, ou simplesmente “-”. A seguir estão os
parâmetros session-id e version. Em (HANDLEY e JACOBSON, 2011) e (HANDLEY, JACOBSON e
PERKINS, 2011) recomenda-se que estes parâmetros sejam um timestamp NTP (Network Time Protocol)
ou um número aleatório qualquer. Logo após, está o parâmetro network-type que é sempre “IN” para
Internet, seguido pelos parâmetros address-type (“IP4” ou “IP6”, para IPv4 e IPv6 respectivamente) e
address, que informa o endereço IP do originador ou nome DNS do host.
O campo seguinte é o nome de sessão. Este campo não tem utilidade para o estabelecimento de uma sessão
unicast com o SIP, contudo trata-se de um campo obrigatório e como tal não pode deixar de ser incluído.
Assim, (ROSENBERG e SCHULZRINE, 2011) recomenda que o campo seja preenchido com um espaço em
branco ou com um traço (“-”).
A linha seguinte traz informações sobre a conexão. Os parâmetros neste campo são network-type,
address-type e address, que são preenchidos conforme já explicado no campo “o =”, exceto que aqui o
parâmetro address deve conter o endereço IP do participante.
A próxima linha indica o tempo para início e término da sessão. Contudo, conforme (ROSENBERG e
SCHULZRINE, 2011), sessões unicast devem ser criadas e terminadas através de um protocolo de
sinalização, como o SIP. Então os parâmetros start-time e stop-time neste campo devem ser preenchidos
com “0”.
A mensagem SDP segue com o campo “m =”, que especifica qual o tipo de mídia deseja-se trocar. O
primeiro parâmetro é media que, de acordo com (HANDLEY e JACOBSON, 2011) pode ser “áudio”,
“vídeo”, “text”, “application”, “message”, “image”, ou “control”. Seguindo, há os parâmetros port, que
identifica em qual porta o participante gostaria de receber o fluxo de mídia, e o transport que exibe o
protocolo de camada de transporte ou o perfil RTP que será usado. O último parâmetro é o format-list que
traz os esquemas de codificação para a mídia sendo negociada que estão disponíveis.
As três linhas seguintes são atributos, campos opcionais e que podem ser usados para trazer mais
informações sobre a mídia listada no campo “m =”. Neste caso, apenas trazem explicitamente informações
sobre os esquemas de codificação listados no parâmetro format-list.
Como determina o modelo Offer/Answer, o UAS agora deve construir uma resposta que aceite ou rejeite a
oferta. No caso de rejeição, basta que o UAS formule uma mensagem SDP que tenha “0” (zero) no
parâmetro port do campo “m =”. Esta é a forma que o SDP usa para comunicar ao outro participante que
não tem interesse em trocar uma mídia oferecida (ROSENBERG e SCHULZRINE, 2011).
No exemplo da Figura 1, o usuário Guilherme aceita a oferta. Neste caso, a resposta deve conter uma
especificação de mídia coincidente com a oferta. Portanto, a mensagem SDP carregada em M9 pode ser:
v=0
o = Guilherme 2890844570 2890844570 IN IP4 soft667.santos.com
s=c = IN IP4 200.201.202.203
t=00
m = audio 50000 RTP/AVP 8
a = rtpmap : 8 PCMA/8000
Deve-se notar que o UAS selecionou apenas um dos três esquemas de codificação oferecidos, indicando que
este deve ser o codec usado.
15
Os exemplos de mensagens SDP abordados aqui exploraram apenas os campos obrigatórios. Em
(JOHNSTON, 2009) e (HANDLEY, JACOBSON e PERKINS, 2011) são oferecido detalhamentos sobre
cada campo da Tabela II. Em (JOHNSTON e SPARKS, 2011) há numerosos exemplos de trocas de
mensagens oferta/resposta.
RTP – Real-time Transport Protocol
O RTP (Real-Time Transport Protocol), definido em (SCHULZRINNE, CASNER e FREDERICK, 2011),
foi desenvolvido para tornar possível o transporte de pacotes contendo voz, vídeo ou outro tipo de mídia
(informação) sobre uma rede IP.
O protocolo permite a detecção de pacotes perdidos, variações no atraso (jitter) e chegada fora de ordem,
contudonão garante qualidade de serviço para a mídia sendo transportada, isto é: pacotes RTP são tratados
da mesma forma como qualquer outro pacote numa rede IP. Assim sendo, o que ocorre é um trabalho em
conjunto com o RTCP (Real-time Transport Control Protocol), que é usado para monitorar estatísticas
referentes às trocas de pacotes RTP (SCHULZRINNE, 2011).
Sendo usado por aplicações cuja natureza é de tempo real, o transporte de pacotes RTP requer uma latência
fim-a-fim tão baixa quanto possível através da Internet. Para isto, as aplicações tipicamente utilizam o
protocolo UDP na camada de transporte, uma vez que não há tempo para detectar, sinalizar e retransmitir
um pacote perdido.
Diferentemente do SIP e do SDP, o RTP é um protocolo orientado a bit e possui um formato predefinido de
cabeçalho composto por 12 bytes fixos, podendo ser estendido. O cabeçalho RTP é mostrado na Figura 3.
Figura 3: Cabeçalho RTP
O empacotamento da mídia codificada se dá simplesmente pela adição de um cabeçalho RTP a pequenas
amostras do fluxo de bits codificado pelo codec negociado anteriormente com o SDP, formando então um
pacote RTP.
Na recepção, os pacotes RTP são tratados de acordo com seu cabeçalho, podendo até ser descartado caso
seja um pacote contendo um fragmento de mídia que esteja atrasado demais para ser reproduzido, por
exemplo.
O cabeçalho RTP contém, de acordo com (JOHNSTON, 2009):
Version (V): Traz a versão do protocolo sendo usado. A versão atual em uso do RTP é a 2.
Padding (P): Se este bit estiver setado (igual a 1), significa que há bytes de preenchimento no final do
pacote RTP para garantir que este tenha um tamanho fixo. O uso deste campo é mais comumente
observado quando a mídia está criptografada.
Extension (X): Se este bit estiver setado, há uma extensão ao final do cabeçalho.
CSRC Count (CC): Contém o número de campos CSRC identifiers que há no cabeçalho. Este campo
16
é usado apenas quando mixers unem diferentes fluxos RTP formando um fluxo só.
Marker (M): Esse bit é usado no nível de aplicação. Quando setado, significa que os dados deste
pacote têm alguma relevância especial para aplicação em questão. Por exemplo, pode indicar o fim de
um quadro completo em um vídeo, ou o início de um surto de fala numa conversa com supressão por
silêncio.
Payload Type (PT): O RTP foi desenvolvido para ser um protocolo de transporte de mídia genérico,
isto é, permitir o transporte de mídias codificadas de diversas formas (com codecs distintos). Assim
sendo, este campo é necessário para identificar com um número inteiro o codec previamente
negociado com o SDP (e agora em uso na sessão). Em (SCHULZRINNE e CASNER, 2011) é
detalhado o perfil “RTP/AVP” e pode ser encontradas tabelas que especificam os valores possíveis
para o campo TP.
Sequence Number: O valor nesse campo é incrementado a cada pacote RTP enviado e é usado para
detectar pacotes perdidos ou que chegaram foram de ordem. Importa notar que apesar de detectar
estes problemas o RTP não os trata, deixando essa função para o algoritmo do codec sendo utilizado.
Timestamp: Este campo indica quando o primeiro byte do payload deste pacote foi amostrado,
possibilitando ao receptor reproduzir a amostra no tempo adequado, pela introdução de atrasos para
remoção de jitter, por exemplo.
SSRC identifiers: O valor neste campo identifica a fonte (Synchronization Source) do pacote RTP.
Para iniciar uma sessão, cada participante escolhe de forma aleatória um identificador, caso este seja
igual ao de alguma outra fonte participando da sessão, o processo de escolha se repete até que todos
os participantes tenham um identificador exclusivo. Esse campo introduz uma camada de segurança
na comunicação RTP contra um ataque do tipo media spamming, onde uma terceira parte tenta
invadir uma sessão de mídia já estabelecida. A menos que o atacante possa determinar o SSRC de
uma das partes, qualquer pacote por ele enviado será descartado.
CSRC identifiers: Pode haver nenhum ou até quinze campos deste num pacote RTP (haja visto que o
tamanho do campo CC é de 4 bits). Só existirá se o pacote RTP estiver sendo enviado por um mixer,
que junta pacotes RTP vindos de diferentes fontes.
RTCP – Real-time Transport Control Protocol
Para que os participantes de uma sessão RTP tenham subsídios para medir a qualidade da comunicação,
(SCHULZRINNE e CASNER, 2011) também define o RTCP (Real-Time Transport Control Protocol), que
se baseia na transmissão periódica de pacotes de controle para todos os participantes da sessão.
O RTCP desempenha, dentre outros, dois papéis que importa destacar. Primeiro, e principalmente, ele deve
reunir informações estatísticas sobre aspectos de qualidade a respeito do recebimento da mídia e enviar tais
informações à fonte (ou fontes, se na sessão houver vários participantes – sessão multicast). Esses dados
podem ser usados para realizar codificação adaptativa da mídia, por exemplo, além de detecção de falhas na
transmissão.
Em segundo lugar, o RTCP provê um identificador exclusivo para os sistemas finais da sessão RTP
conhecido como CNAME. Essa é também a função do SSRC visto anteriormente, contudo o SSRC de um
participante pode ser alterado caso seja detectado um conflito ou caso a aplicação comunicante reinicie.
Nestes casos, o CNAME permite correlacionar um participante ao seu novo SSRC, evitando que todo o
processo de estabelecimento da sessão seja executado novamente.
A taxa com a qual um participante envia pacotes RTCP para os demais deve ser controlada, caso contrário a
comunicação de mídia, que é a principal razão do RTP, ficaria comprometida. Sendo assim, o protocolo
também provê mecanismos para que seja calculado um intervalo de envio entre pacotes RTCP, de tal forma
17
que a banda ocupada por eles seja suficientemente baixa. Contudo, a forma como isto é realizado está além
do escopo deste trabalho e está detalhada na sessão 6.2 de (SCHULZRINNE e CASNER, 2011).
São definidos cinco tipos de pacotes RTCP no RFC 3551, (SCHULZRINNE e CASNER, 2011):
Sender report (SR): São os relatórios enviados por um participante ativo a todos os outros
participantes ativos da sessão com estatísticas sobre a recepção e transmissão dos pacotes RTP no
intervalo decorrido.
Receiver report (RR): São relatórios para participantes “ouvintes”, isto é, que não enviam pacotes
RTP.
Source description (SDES): Usado para enviar o CNAME de um participante. Também pode conter
informações adicionais como nome, email, telefone, entre outras.
End of participation (BYE): Enviado por um participante quando deseja deixar a sessão.
Application specific (APP): Este tipo de pacote foi inserido na definição do protocolo para permitir
extensões, isto é: um pacote APP levará informações específicas para a aplicação, para realizar uma
ação não definida em (SCHULZRINNE e CASNER, 2011).
Para diminuir o overhead de controle na comunicação, múltiplos pacotes RTCP são concatenados e
enviados num único datagrama UDP. Cada pacote RTCP neste datagrama poderia ser processado
individualmente sem que nenhuma restrição quanto a sua ordem ou combinação fosse imposta, contudo para
que as funcionalidades do protocolo sejam garantidas, cada datagrama enviado deve conter no mínimo dois
pacotes RTCP diferentes: um pacote de relatório (isto é um SR ou um RR) e um SDES com o CNAME para
garantir que participantes recém chegados obtenham o CNAME dos demais participantes tão logo quanto
possível.
18
VoIP: Segurança da Informação
A informação já se tornou o ativo mais valioso das corporações e como tal, independente da forma como
existe e é manipulada (em papel ou eletronicamente), sua proteção passou a ser mandatória.
A norma ABNT NBR ISO/IEC 27002 define segurança da informação como a proteção da informação
contra os diferentes tipos de ameaças a fim de minimizar o risco ao negócio, garantir sua continuidade e
maximizar o retorno sobre os investimentos e as oportunidades de negócio.
Existem três aspectos chave da segurança da informação comumente referidos como CIA Triad, ou Tríade
CID: Confidencialidade, Integridade e Disponibilidade.
A seguir estão expostos estes conceitos de maneira breve e posteriormente apresentam-se definições para
alguns dos termos mais usados em se tratando de segurança da informação.
Confidencialidade, Integridade e Disponibilidade
A confidencialidade significa, conforme (BRAUMANN, CAVIN e SCHMID, 2011), que nenhum acesso à
informação deverá ser garantido a sujeitos ou sistemas não autorizados, isto é, apenas aqueles com os
direitos e privilégios necessários serão capazes de acessar a informação, esteja ela armazenada, em
processamento ou em trânsito.
A violação da confidencialidade pode ocorrer por modo intencional através de ataques, captura de tráfego,
engenharia social, entre outros, bem como de forma não deliberada por imperícia ou negligência.
No caso específico do VoIP, a confidencialidade preocupa-se com a não intercepção de uma conversa por
uma terceira parte não autorizada, como nos ataques do tipo man-in-the-middle (MITM).
A integridade é o aspecto que se preocupa com a confiança que pode ser depositada sobre uma informação
obtida. Além disto, uma informação é dita íntegra se não sofreu nenhuma alteração entre os momentos de
transmissão e recepção.
Desta forma, em (BRAUMANN, CAVIN e SCHMID, 2011) são definidas duas categorias de integridade:
integridade de fonte e integridade de dados. A integridade de fonte garante que uma informação realmente
vem do remetente correto. A integridade dados se refere à confiabilidade da informação em si, isto é se a
informação não foi comprometida (manipulada) em algum momento anterior à leitura pelo destinatário
pretendido.
Adicionalmente, (STEWART, TITTEL e CHAPPLE, 2008) atribui à integridade três objetivos:
Impedir que sujeitos não autorizados realizem modificações na informação;
Impedir que sujeitos autorizados realizem modificações não autorizadas; e
Garantir a legitimidade, verificabilidade e consistência da informação, esteja ela armazenada, em
trânsito ou em processamento.
Em se tratando de VoIP, a integridade deve garantir que os pacotes de mídia cheguem ao destinatário sem
sofrerem manipulações maliciosas.
A disponibilidade é o aspecto da segurança da informação que diz que esta deve estar disponível para ser
19
acessada quando solicitada por um sujeito ou sistema legítimo (BRAUMANN, CAVIN e SCHMID, 2011).
Isto requer que toda estrutura que permite acesso e transporte da informação deve ser protegida para que
não seja degradada ou se torne indisponível.
Com relação à disponibilidade, os tipos de ataque que representam maior ameaça são DoS (Denial of
Service) e DDoS (Distributed Denial of Service) , que visam danificar ou sobrecarregar sistemas.
Especificamente para o VoIP, disponibilidade significa garantir que o serviço estará operante para os
usuários, evitando qualquer efeito adverso resultante de um ataque do tipo negação de serviço, cujas
consequências podem ser perda total ou parcial da comunicação (BRAUMANN, CAVIN e SCHMID, 2011).
Definições
Nesta sessão definem-se termos importantes mais comumente usados quando se discute sobre segurança da
informação. De acordo com (STEWART, TITTEL e CHAPPLE, 2008), tem-se:
Vulnerabilidade: Diz respeito às fraquezas de um sistema que podem ser exploradas
maliciosamente. Podem estar relacionadas à software, hardware ou processos que apresentam
falhas passíveis de serem exploradas de tal forma que comprometa o funcionamento de um
sistema ou serviço.
Ameaça: A forma como uma vulnerabilidade pode ser explorada determina uma ameaça. É
chamada de agente de ameaça a entidade que tira proveito da vulnerabilidade, que pode ser
uma pessoa (hacker), um processo ou um evento natural.
Risco: É a probabilidade de um agente de ameaça se aproveitar de uma vulnerabilidade.
Proteção: É um mecanismo usado para diminuir o risco, podendo ser em nível de software,
hardware ou processo. Exemplos de proteção são: firewalls, isolamento de tráfego (VLAN),
antivírus, entre outros.
Incidente: Quando um agente de ameaça consegue explorar uma vulnerabilidade com sucesso,
diz-se que houve um incidente de segurança. Neste caso, um ou mais princípios da tríada CID
foram violados.
20
VoIP: Ameaças em VoIP
Tipicamente, um atacante (agente de ameaça) inicia seus esforços com um trabalho de
reconhecimento, onde busca reunir o máximo possível de informações sobre as vulnerabilidades
latentes dos dispositivos, sistemas e identidades dos alvos. De posse desse conhecimento, um ou mais
ataques são, então, disparados e se bem sucedidos violarão um ou mais princípios da tríade CID.
Contudo, as técnicas usadas para descoberta, escaneamento e identificação de dispositivos, bem como
a enumeração de serviços e usuários não serão tratadas neste trabalho.
O objetivo desta sessão é expor algumas das principais ameaças de segurança à tecnologia VoIP,
primeiro abordando as ameaças inerentes a qualquer rede IP e em seguida as que são particulares aos
dispositivos VoIP baseados em SIP.
Ameaças Legadas
Fundamentalmente, um telefone SIP é um dispositivo IP e como tal também padece com os mesmos
problemas de segurança inerentes as redes IP. Ademais, telefones e servidores SIP tipicamente contam
com implementações de um série de serviços de rede, incluindo HTTP, telnet, SNMP, TFTP, entre
outros (ENDLER e COLLIER, 2007).
Portanto, muitas das ameaças atuais ao VoIP já existiam antes mesmo desta tecnologia surgir. Esta
sessão apresenta algumas delas.
UDP Flood
Ataques Flooding são do tipo Negação de Serviço, cujo objetivo é consumir recursos de rede e de
sistemas a fim de causar indisponibilidade total ou parcial de um ou vários serviços (ENDLER e
COLLIER, 2007).
O UDP Flood consiste no envio de centenas de milhares de datagramas UDP direcionados para uma
porta específica, causando uma “inundação” de pacotes. O efeito é que o alvo terá que alocar
recursos de sistema valiosos (processamento e memória) para tratar os muitos pacotes que chegam,
deixando de atender a outras solicitações legítimas naquela e em outras portas.
Dependendo da intensidade do ataque e principalmente se este for realizado distribuidamente, o
excesso de tráfego pode causar congestionamento na rede, aumentando a cadeia de efeitos colaterais.
Por exemplo, um ataque UDP Flood que pode inviabilizar completamente a comunicação VoIP (e
praticamente a comunicação de qualquer aplicação numa rede IP) é aquele direcionando à porta 53 de
host funcionando como servidor DNS. Neste caso, o ataque é conhecido também como DNS Flood.
Como visto anteriormente, o DNS é um serviço crítico para realização de chamadas SIP, portanto seu
comprometimento significa a inviabilização de toda comunicação VoIP baseada em SIP dentro do
domínio.
O UDP Flood é particularmente eficiente neste caso, visto que este é o protocolo de camada de
transporte utilizado pelo DNS e porque há firewalls não conseguem distinguir entre um ataque DoS e
uma solicitação/resposta DNS válida(ENDLER e COLLIER, 2007).
Vale ressaltar que praticamente todos os ataques do tipo DoS e DDoS são especialmente nocivos à
21
comunicação VoIP, uma vez que esta é uma aplicação de tempo real e, portanto, qualquer degradação
do serviço ou congestionamento causados por esta classe de ataques causa impacto significativo ao
serviço (THERMOS e TAKANEN, 2007).
Exaustão de DHCP
Comumente, sempre que iniciam, telefones VoIP são configurados por padrão para solicitarem um
endereço IP dinamicamente através de uma mensagem DHCPREQUEST. Se um servidor DHCP
(Dynamic Host Control Protocol) não estiver disponível, ou se o número máximo de endereços IP já
houver sido distribuído, então o telefone não poderá ser usado na rede (ENDLER e COLLIER, 2007).
Um ataque de exaustão de DHCP consiste no envio de um número suficientemente alto de requisições
ao servidor DHCP com endereços MAC falsos, de tal forma que ocorra o esgotamento do espaço de
endereços IP disponível. Assim, quando um cliente da rede, por exemplo um telefone VoIP, solicitar
um endereço, não haverá nenhum.
O efeito do ataque dura enquanto o “contrato” dos endereços IP não expirar.
Envenenamento de Cache DNS
O objetivo deste ataque é fazer com que uma solicitação específica feita para um nome seja
redirecionada a um host falso, isto é, um host que verdadeiramente não corresponde ao destino
legítimo.
Isso se dá pela introdução de um registro falso no servidor de nome de domínios usado pela rede alvo
da seguinte forma, de acordo com (ROHR, 2011):
Primeiro o atacante faz uma solicitação ao servidor DNS alvo para o nome que deseja inserir
um endereço IP falso;
Ao receber essa solicitação, o servidor DNS por sua vez faz outra consulta ao servidor de nomes
do domínio de destino e fica esperando uma resposta;
Como mensagens DNS utilizam o UDP na camada de transporte, o servidor DNS alvo não
estabeleceu uma conexão com o servidor de nomes do domínio de destino, então basta que o
atacante formule uma resposta falsa (passando-se pelo servidor de nomes do domínio de
destino) respondendo à requisição feita pelo servidor DNS alvo, informando um endereço IP
falso, conforme seu interesse.
Como o resultado de consultas DNS são armazenadas em cache, o servidor alvo não efetuará
consultas para o mesmo nome por algum tempo, encaminhando todas as solicitações para o
nome para um endereço ilegítimo.
Novamente, o DNS é um serviço crítico na sinalização SIP, portanto esta constitui uma ameaça
particularmente perigosa, visto que um atacante pode usá-la tanto como uma forma de negação de
serviço (causando redirecionamento da sinalização SIP para hosts aleatórios) ou, em um ataque mais
elaborado, como uma forma de se passar por um ou vários usuários (redirecionando a sinalização para
um proxy maliciosamente configurado), ou ainda realizar um ataque do tipo man-in-the-middle.
(ENDLER e COLLIER, 2007).
Envenenamento ARP
O envenenamento ARP é baseado na vulnerabilidade de alguns sistemas operacionais que incluem ou
substituem uma entrada em seu cache ARP se receberem uma resposta ARP com uma nova
22
correlação, mesmo que não tenha sido feita nenhuma solicitação previamente (ENDLER e COLLIER,
2007).
O ataque consiste em:
Determinar os endereços IP e MAC de dois hosts de interesse (por exemplo, o de um telefone
SIP e o de um SIP proxy). Sejam eles o host A e host B;
Enviar uma mensagem ARP reply para o host A informando a associação entre o endereço IP
do host B e o endereço MAC da estação onde está o atacante;
Enviar uma mensagem ARP reply para o host B informando a associação entre o endereço IP
do host A e o endereço MAC da estação onde está o atacante;
Realizar o roteamento do tráfego entre os hosts, para que não se perceba a interceptação da
comunicação.
Assim sendo, o envenenamento ARP consiste em uma das formas mais simples de se executar um
ataque MITM, mas é necessário que o atacante esteja na mesma rede local que o alvo.
Manipulação da Sinalização e de Mídia
SIP INVITE Flood
O servidor proxy é um elemento chave na comunicação VoIP de dispositivos SIP, sendo o responsável
pelo processamento de todas as chamadas entre sistemas finais, incluindo telefones SIP, gateways de
mídia e outros proxies. Assim sendo, se o serviço prestado pelo servidor proxy for parcial ou
completamente comprometido, toda comunicação VoIP pode ser afetada (ENDLER e COLLIER,
2007).
Uma ameaça com este potencial consiste no envio de uma imensa quantidade de mensagens SIP
INVITE para um servidor proxy. A requisição INVITE tem um aspecto computacional importante
porque ela é o gatilho que dispara uma maior carga de processamento e reserva de recursos num
dispositivo SIP. Assim, se um servidor proxy puder ser inundado com requisições INVITE, uma
interrupção parcial ou total do serviço pode ocorrer (ENDLER e COLLIER, 2007).
Como demostrado em (ENDLER e COLLIER, 2007), há uma vasta quantidade de cenários possíveis
para ataques com inundação de mensagens INVITE, contudo um dos mais nocivos é o ataque à um
proxy de um domínio solicitando o contato com um UA (que pode ou não existir) em outro domínio.
Desta forma, o efeito é o comprometimento do serviço em dois domínios simultaneamente.
Em (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011), é aberta a possibilidade de se
exigir autenticação para a requisição INVITE. Se este for o caso, o efeito do ataque é ainda mais
rápido, visto que serão alocados ainda mais recursos para manter registros e contadores das
solicitações de autenticação que o servidor proxy fará (ENDLER e COLLIER, 2007).
Remoção de Registro
Como visto anteriormente, num ambiente SIP típico os telefones registram-se junto ao servidor
registrar para que as ligações possam ser adequadamente encaminhadas ao UA. Portanto, se um
registro for removido do servidor de registros, o servidor proxy será incapaz de encaminhar as ligações
para o telefone SIP (ENDLER e COLLIER, 2007).
Um ataque de remoção de registro é bastante trivial, sendo necessário apenas enviar uma mensagem
23
SIP tal qual a exibida na Figura 2, porém com “*” como valor do campo Contact e, a seguir, inserindo
uma linha “Expires= 0”. Desta forma, todos os registros para o AOR informado no campo To serão
removidos do servidor registrar.
Adição Registro
Os registros de endereços SIP são gerenciados de tal forma que mais de um dispositivo pode
registrar-se para o mesmo AOR, permitindo que usuários registrem-se de diversos locais, como de seu
escritório, de uma sala de reuniões e etc. Quando múltiplos telefones SIP registrados sob o mesmo
AOR tocam, o primeiro a responder a ligação a deterá (ENDLER e COLLIER, 2007).
Essa flexibilidade cria a oportunidade para vários tipos de ataques. Por exemplo, um atacante pode
adicionar diversos registros para um mesmo AOR, fazendo com que diversos telefones toquem
quando é realizada uma ligação para aquele endereço, irritando e confundindo os usuários.
O ataque é igualmente trivial ao anterior, bastando enviar uma mensagem (ou várias) SIP REGISTER
para o servidor de registros vinculando o AOR a um dispositivo do interesse do atacante.
Sequestro de Registro
Usando os dois ataques anteriores, neste ataque o agente de ameaça substitui um registro legítimo por
um falso, fazendo com que ligações sejam encaminhadas para um dispositivo SIP ilegítimo, ou até
mesmo inexistente (ENDLER e COLLIER, 2007).
Mais difícil, porém realizável, é executar um ataque do tipo MITM em nível de aplicação. Para isto o
atacante redireciona a ligação para sua estação, onde captura os pacotes e os roteia para o destino
correto, permanecendo despercebido (ENDLER e COLLIER, 2007).
Redirecionamento
Em (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011), é determinado que um servidor
proxy ou um UA pode responder a uma solicitação INVITE com uma mensagem “301 Moved
Permanently” ou “302 Moved Temporarily”, informando ao chamador que o UA que deseja alcançar
não se encontra mais no endereço solicitado e o novo endereço para contato (no campo Contact da
resposta). O chamador, então, usa o novo endereço informado na resposta para entrar em contato com
o UA pretendido.
Valendo-se dessa flexibilidade do protocolo SIP, um atacante, se capaz de monitorar solicitações
INVITE, poderá responder com uma mensagem de redirecionamento, sendo possível causar uma
negação do serviço ao encaminhar a chamada para um UA inexistente, ou, pior ainda, encaminhar a
ligação para um UA ilegítimo que pode tentar se passar pelo UA que se pretendia alcançar (ENDLER
e COLLIER, 2007).
Interrupção de Sessão
O protocolo SIP usa a solicitação BYE para anunciar o término de uma sessão. Se um agente de
ameaça for capaz de monitorar uma ligação por tempo suficiente para coletar o Call-ID, o tag do
campo From e o tag do campo To, então poderá montar uma mensagem BYE (com os demais campos
pertinentes) e enviar para uma das partes, fazendo com que a ligação seja interrompida, conforme
demostrado em (ENDLER e COLLIER, 2007).
24
Inserção e Mixagem RTP
Pelo fato de aplicações VoIP serem de tempo real, os pacotes RTP sempre são carregados pelo UDP
na camada de transporte, portanto, ataques contra o RTP são simples e aplicáveis a praticamente todo
sistema de comunicação VoIP.
Assumindo então que um atacante já esteja em uma posição de “homem do meio”, isto é, que já tenha
executado com sucesso um ataque MITM, é possível que ele insira ou mixe novo áudio no fluxo RTP.
A inserção de áudio sobrescreve a informação de áudio existente, enquanto a mixagem faz com que o
novo áudio seja misturado ao existente (ENDLER e COLLIER, 2007). A ideia é introduzir ruído na
ligação ou provocar um efeito parecido com o de “linha cruzada”.
Em (ENDLER e COLLIER, 2007) o ataque é demonstrado explorando uma ferramenta especifica
desenvolvida para realizá-lo.
25
VoIP: Contra Medidas
Nesta sessão são examinadas de forma não exaustiva apenas algumas das abordagens que visam
diminuir a probabilidade de um atacante executar uma ameaça com êxito. Várias outras contra
medidas podem ser encontradas em (STEWART, TITTEL e CHAPPLE, 2008), (HARRIS, 2008),
(ENDLER e COLLIER, 2007), (THERMOS e TAKANEN, 2007) e (PORTER e GOUGH, 2007).
Virtual Local Area Network
Uma VLAN (padrão IEEE 802.1Q) promove a separação lógica do tráfego de dispositivos conectados
a uma mesma LAN, criando domínios de brodcast distintos com base nas portas de um switch ou
endereços físicos de interfaces. Desta forma, é possível fazer um isolamento entre os tráfegos de
dados e voz e, com isso, atividades maliciosas oriundas da rede de dados (que é o cenário mais
comum) não afetarão a comunicação VoIP. A segregação do tráfego também traz o benefício de
menor congestionamento enfrentado pelos pacotes de voz, melhorando a qualidade do serviço VoIP
(PORTER e GOUGH, 2007).
Contudo, uma questão que deve ser levada em consideração é com relação ao uso de softwares do
tipo Softphone, que são aplicações VoIP instaladas em computadores de uso pessoal. Se a estação
onde estiver instalado um Softphone não contar com mais de uma interface, então não será possível o
uso de VLAN para separação de tráfego. Neste cenário, para viabilizar o uso de VLAN, deve-se ter
uma interface de rede separada para o tráfego VoIP (ENDLER e COLLIER, 2007).
Firewall, IDS e IPS
Há equipamentos que podem ser inseridos na infraestrutura de rede com o objetivo de adicionar
segurança de uma forma geral, isto é, não especificamente para o serviço VoIP.
Um deles é o firewall, onde são implementadas regras responsáveis por bloquear todo tráfego (de
entrada ou saída) que não é aderente à política de segurança da rede. Basicamente, o firewall analisa
o conteúdo dos pacotes IP que o atravessa, como portas e endereços de origem e destino e, com base
nessas informações, autoriza ou nega o fluxo (PORTER e GOUGH, 2007).
Firewalls podem ser do tipo stateless ou stateful. Um firewall stateless não guarda em memória o
estado das conexões estabelecidas. O firewall stateful mantém em memória uma tabela que guarda o
estado das conexões em andamento, o que permite identificar pacotes que estão iniciando uma nova
conexão e pacotes pertencentes a uma conexão já estabelecida e, portanto, este é o tipo de firewall
mais eficiente para detectar uma tentativa de ataque (PORTER e GOUGH, 2007).
Apesar de importante, o firewall não é a defesa definitiva para uma rede de computadores. O IDS
(Intrusion Detection System) e o IPS (Intrusion Prevention System) são dispositivos de segurança que
podem ser posicionados estrategicamente dentro da rede para detectar tráfego malicioso que por
ventura tenha passado pelas regras do firewall.
De acordo com (HARRIS, 2008), a diferença entre eles é que o IDS, ao detectar um tráfego malicioso,
unicamente gerará alarmes e logs. Qualquer ação de combate deverá ser tomada pelo administrador
da rede. Já o IPS é embarcado com inteligência reativa a um fluxo identificado como malicioso.
IPSec
26
O IPSecou IP Security é um protocolo que opera na camada de rede da pilha TCP/IP e, como tal,
trabalha com qualquer protocolo da camada de transporte. Ademais, protocolos como o SIP e o RTP
funcionam sobre o IPSec sem alterações. Uma sessão IPSec é comumente chamada de VPN
(JOHNSTON, 2009).
O gerenciamento de chaves no IPSec pode ser significativamente difícil, uma vez que é necessário
chaves simétricas em ambos os lados comunicantes, mas o fato de que um túnel VPN pode proteger
tanto a sinalização SIP como o tráfego de mídia é um ponto forte do protocolo. Contudo, para
aplicações distribuídas, como áudio conferências, o IPSec não é escalável, já que estabelecer túneis
VPN para todos os hosts antes da sinalização SIP e do fluxo RTP é difícil (JOHNSTON, 2009).
TLS – Tranport Layer Security
É um protocolo de segurança desenvolvido para oferecer suporte ao transporte confiável de pacotes
através de protocolos como o TCP ou SCTP. Além disto, o TLS oferece autenticação e proteção a
confidencialidade e integridade (STEWART, TITTEL e CHAPPLE, 2008).
O TLS vale-se de dois protocolos. Um é o TLS Handshake Protocol, responsável por estabelecer a
conexão e negociar os parâmetros da comunicação segura que serão usados como: métodos de
compressão, tamanho do hash, algoritmos de criptografia (DES, RC4, entre outros) e de integridade
(MD5, SHA, entre outros). O outro é o TLS Record Protocol, responsável pela aplicação dos
parâmetros de segurança negociados, isto é: faz a fragmentação, compactação, criptografia e aplica
função de integridade antes do envio das mensagens vindas das camadas superiores (HARRIS, 2008).
Contudo, por não ter sido desenvolvido para oferecer suporte ao UDP, o TLS pode ser usado para
tornar segura a sinalização SIP (prevenindo ataques de manipulação de sinalização), mas não o fluxo
de mídia RTP.
Outra questão que deve ser considerada no uso do TLS é que as sessões estabelecidas são hop by hop,
isto é, para cada salto entre dispositivos SIP um túnel TLS deve ser criado, o que aumenta a latência
durante a sinalização (JOHNSTON, 2009).
Vale a pena destacar o SIPS (Secure SIP), que é um esquema URI que requer o uso do TLS para cada
salto entre dispositivos SIP. Sendo assim, com o SIPS em uso, quando um servidor proxy recebe uma
mensagem ele deverá processá-la e estabelecer um conexão TLS com o próximo dispositivo SIP para
então encaminhá-la ou, caso não ofereça suporte ao TLS, retornar uma mensagem de erro ao UA.
Infelizmente este aditivo de segurança à comunicação SIP não ganhou o mercado graças a confusões
e ambiguidades na especificação, bem como a falta de suporte ao TLS oferecida pela maior parte das
aplicações SIP (JOHNSTON, 2009).
DTLS – Datagram Transport Layer Security
De acordo com (RESCORLA e MODADUGU, 2011), a filosofia básica do DTLS é construir “TLS
sobre datagrama”. O motivo pelo qual o TLS não pode ser usado sobre datagramas é simplesmente
porque pacotes podem se perder ou ser reordenados, isto é, a camada de criptografia do TLS não
permite decriptografar registros isoladamente (se o registro N não for recebido, o registro N+1 não
poderá ser desencriptar) e a camada de handshake assume que as mensagens são entregues em ordem
e caso não sejam, ela falha.
27
Para suprir as deficiências que impedem o TLS ser usado sobre UDP, o DTLS utiliza um sistema de
retransmissão baseada em contadores, o que significa que uma mensagem será automaticamente
retransmitida se não houver retorno na comunicação. Com relação ao problema de reordenamento, o
DTLS insere uma sequencia numérica específica em cada mensagem de handshake. Quando um
sistema final recebe uma mensagem de handshake ele pode determinar se é a próxima mensagem que
espera ou se é uma mensagem diferente. Se for a mensagem esperada, esta será processada. Caso
contrário, será armazenada para processamento posterior, quando já tiverem sido recebidas todas as
mensagens anteriores a esta (RESCORLA e MODADUGU, 2011).
Autenticação SIP
A autenticação SIP busca adição de segurança no processo de registro de usuários SIP, bem como
início e término de sessões, isto é: para mensagens REGISTER, INVITE e BYE. A figura 4, extraída
de (THERMOS e TAKANEN, 2007), ilustra o fluxo para tais mensagens.
Figura 4: Exemplos de autenticação SIP
Ao receber uma mensagem REGISTER, o servidor registrar verifica se nela há credenciais digest. Se
não houver, será retornado ao UA uma “401 Unauthorized” onde um desafio MD5 digest é inserido.
Quando o UA recebe o desafio, ele confirma o recebimento com um ACK e calcula a resposta
adequada para enviar novamente uma mensagem REGISTER, dessa vez incluindo a resposta MD5
digest calculada. O servidor verifica se a resposta ao desafio está correta e processa a solicitação, caso
positivo (JOHNSTON, 2009).
Para mensagens BYE e INVITE, o procedimento é o mesmo, contudo servidores proxy encaminham o
desafio ao UA numa mensagem “407Proxy Unauthorized Request”. De uma forma geral, se a
solicitação é feita ao dispositivo SIP final (como no caso de uma mensagem de registro), o desafio é
retornado numa mensagem 401, caso contrário o desafio é retornado numa mensagem 407
(ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
Muito mais sobre autenticação SIP pode ser encontrado em (JOHNSTON, 2009) e (ROSENBERG,
28
SCHULZRINNE e CAMARILLO et al, 2011).
SRTP e SRTCP
O SRTP é um perfil seguro do RTP, definido no RFC 3711, (BAUGHER, 2011), que oferece
autenticação, confidencialidade e integridade do fluxo de mídia. Em seu projeto, questões de
relacionadas ao consumo de banda, processamento e latência da comunicação foram levadas em
consideração para garantir a eficiência do protocolo.
O protocolo usa um esquema de chaves simétricas que devem ser negociadas pelo modelo
offer/answer com o SIP. Para a criptografia o algoritmo usado é o AES-CTR (Advanced Encryption
Standard – Counter Mode) com 128 ou 256 bits, que executa uma operação XOR (Exclusive-OR)
sobre o fluxo de mídia. Isso permite que a criptografia seja executada em paralelo com a codificação,
diminuindo a latência introduzida pelo processamento (JOHNSTON, 2009).
O pacote SRTP é idêntico ao pacote RTP em sua estrutura, contudo o payload é criptografado e é
adicionado um campo Authentication tag. Opcionalmente, um campo MKI (Master Key Index)
(BAUGHER, 2011).
Como o fluxo do RTCP é totalmente separado do fluxo RTP (os protocolos usam portas diferentes
para comunicação), há também a necessidade de que aquele seja protegido para que se previnam
ataques que degradem ou interrompam a troca de mensagens RTCP e, consequentemente, a qualidade
do fluxo de mídia.
Para isso, em (BAUGHER, 2011) também é definido o SRTCP (Secure Real-time Transport Control
Protocol). O mesmos campos adicionados no SRTP também são usados no pacote SRTCP, mas outros
dois cabeçalhos também são incorporados: SRTCP Index, cuja função é identificar os pacotes RTCP
evitando ataque por repetição e o Encrypt-flag, um campo de 1 bit que indica que o corpo do RTCP
foi criptografado (THERMOS e TAKANEN, 2007).
29
VoIP: Considerações Finais
Este tutorial procurou apresentar uma revisão bibliográfica sucinta acerca dos principais protocolos
empregados na telefonia VoIP e das questões de segurança relevantes para o serviço. Foram
abordadas ameaças legadas das redes IP (que já existiam antes mesmo da tecnologia de voz sobre IP),
bem como ameaças específicas à arquitetura SIP.
Referências
SICKER, D. C.; LOOKBAUGH, T. VoIP Security – Not Na Afterthought. ACM Queue, New York,
set. 2004. Disponível em:
http://dl.acm.org/citation.cfm?id=1028898
SIÉCOLA, P. C. VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de
telefonia IP. Dissertação (Mestrado em Ciência da Computação) - São Paulo: Universidade de São
Paulo, 2010.
DALGIC, Ismael, FANG, H. Comparison of H.323 as SIP for IP Telephony Signaling. Disponível em:
http://www.cs.columbia.edu/~hgs/papers/others/1999/Dalg9909_Comparison.pdf
Acesso em: 10 de jul. 2011.
JOHNSTON, A. B. SIP: Understanding the Session Initiation Protocol. 3. ed. Norwood: Artech
House, 2009.
ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., et al. SIP: Session Initiation Protocol.
Disponível em:
http://tools.ietf.org/html/rfc3261
Acesso em: 6 de jun. 2011.
YOSHIOKA, S. Protocolos para Telefonia IP. Dissertação (Mestrado em Ciência da Computação) –
Campinas: Universidade Estadual de Campinas, 2003.
HANDLEY, M., JACOBSON, V. SDP: Session Initiation Protocol. Disponível em:
http://tools.ietf.org/html/rfc2327
Acesso em: 8 de jun. 2011.
HANDLEY, M., JACOBSON, V., PERKINS, C. SDP: Session Description Protocol. Disponível em:
http://tools.ietf.org/html/rfc4566
Acesso em: 8 de jun. 2011.
ROSENBERG, J., SCHULZRINNE, H. An Offer/Answer Model with the Session Description
Protocol (SDP). Disponível em:
http://tools.ietf.org/html/rfc3264
Acesso em 7 de jun. 2011.
JOHNSTON, A., SPARKS, R. Session Description Protocol (SDP) Offer/Answer Examples.
Disponível em:
http://tools.ietf.org/html/rfc4317
30
Acesso em: 15 de jun. 2011.
SCHULZRINNE, H., CASNER, S., FREDERICK, R., et al. RTP: A Transport Protocol for Real-Time
Applications. Disponível em:
http://tools.ietf.org/html/rfc3550
Acesso em: 13 de jun. 2011.
SCHULZRINNE, H. Some Frequently Asked Questions About RTP. Disponível em:
http://www.cs.columbia.edu/~hgs/rtp/faq.html
Acesso em: 1 de jul. 2011.
REAL-time Transport Protocol, Wikipèdia. Disponível em:
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
Acesso em: 19 jul. 2011.
SCHULZRINNE, H., CASNER, S. RTP for Audio and Video Conferences with Minimal Control.
Disponível em:
http://tools.ietf.org/html/rfc3551
Acesso em: 3 jul. 2011.
BRAUMANN, R., CAVIN, S., SCHMID, S. Voice Over IP – Security and SPIT. Disponível em:
http://scholar.googleusercontent.com/scholar?q=cache:uYD9e_DMEZsJ:scholar.google.com
/+VoIP+Security+Threats&hl=pt-BR&as_sdt=0
Acesso em: 6 jul. 2011.
STEWART, J. M., TITTEL, E., CHAPPLE, M. CISSP: Certified Information Systems Security
Professional Study Guide.4. ed. [S.I]: Wiley Publishing, 2008.
HARRIS, S. CISSP: All-in-One Exam Guide. 4. ed. [S.I]: McGraw-Hill, 2008.
ENDLER, D., COLLIER, M. Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions.
[S.I]: McGraw-Hill, 2007.
THERMOS, P., TAKANEN, A. Securing VoIP Networks: Threats, Vulnerabilities, Countermeasures.
Boston: Pearson Education, 2007.
ROHR, A. Envenenamento do Cache DNS. Disponível em:
http://www.linhadefensiva.org/2005/04/envenenamento-cache-dns
Acesso em: 2 de ago. 2011
PORTER, T., GOUGH, M. How to Cheat at VoIP Secutity. Rockland: Syngress Publishing, 2007.
RESCORLA, E., MODADUGU, N. Datagram Transport Layer Security. Disponível em:
http://tools.ietf.org/html/rfc4347
Acesso em: 5 de ago. 2011.
BAUGHER, M., et al. The Secure Real-time Transport Protocol (SRTP). Disponível em:
http://www.rfc-editor.org/rfc/rfc3711.txt
Acesso em: 6 de ago. 2011.
31
VoIP: Teste seu entendimento
1. Qual é a finalidade do protocolo SIP (Session Initiation Protocol) na comunicação VoIP?
Sinalização
Transporte de Voz
Segurança
Controle do Transporte de Voz.
2. Qual das alternativas abaixo representa uma das ameaças legadas das Redes IP para a
comunicação VoIP?
UDP Flood.
Exaustão de DHCP.
Envenenamento de Cache DNS.
Envenenamento ARP.
Todas as anteriores.
3. Qual das alternativas abaixo não representa uma das abordagens apresentadas que visam
diminuir a probabilidade de um atacante executar uma ameaça com êxito numa comunicação
VoIP?
Virtual Local Area Network, Firewall, IDS e IPS.
Sinalização ISUP/SS7.
Protocolos IPSec, SRTP e SRTCP.
TLS – Tranport Layer Security e DTLS – Datagram Transport Layer Security.
Autenticação SIP.
32