UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
ANÁLISE DAS VULNERABILIDADES E ATAQUES AO
PROTOCOLO SIP
ANDERSON RODRIGUES SOUZA REZENDE
UBERLÂNDIA - MG
2006
ANDERSON RODRIGUES SOUZA REZENDE
ANÁLISE DAS VULNERABILIDADES E ATAQUES AO
PROTOCOLO SIP
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
Orientador: Prof. Esp Flamaryon Guerin
Gomes Borges
UBERLÂNDIA - MG
2006
ANDERSON RODRIGUES SOUZA REZENDE
ANÁLISE DAS VULNERABILIDADES E ATAQUES AO
PROTOCOLO SIP
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
Orientador: Prof. Esp Flamaryon Guerin
Gomes Borges
Banca Examinadora: sobre
Uberlândia, 16 de setembro de 2006.
Prof. Esp Flamaryon Guerin Gomes Borges (Orientador)
Prof. Esp. Carlos Henrique Barros
Prof. Dr. Mauro Hemerly Gazzani
UBERLÂNDIA - MG
2006
Pela emoção de me vêem crescer, por acreditarem em mim, pelo grande amor que
me destinam, por sempre ensinarem aos seus filhos a verdadeira importância da
honestidade e da ética. É para meus pais, Paulo e Maria, que dedico este
trabalho, àqueles de especial significado pra mim, aos quais devo toda formação
que tenho e todo futuro que me fora entregue.
AGRADECIMENTOS
Ao professor e orientador Flamaryon Guerin Gomes Borges, que com
seu apoio e conhecimento, tornou possível a elaboração deste trabalho.
Muito
obrigado por confiar à mim este tema.
À professora Kátia Lopes Silva, por sua dedicação constante,
buscando sempre extrair todo nosso potencial. Com sua inteligência e carisma
inigualáveis, esteve sempre ao lado do aluno, ajudando em nossas dificuldades, e
partilhando das nossas superações.
Aos grandes amigos, Arnaldo e Fernando, “companheiros de estrada”,
pessoas que aprendi a respeitar e confiar. Àqueles que considero como irmãos,
sempre presentes em minha vida acadêmica, tanto nos momentos felizes, quanto
nas dificuldades. E juntos conquistamos mais uma etapa importante em nossas
vidas. Agradeço a vocês pela grande amizade, amizade esta, que prezo para que
seja por minha parte, retribuída à altura.
A namorada Lívia, uma pessoa muito importante e especial em minha
vida. Uma mulher que é maravilhosa acima de tudo. Que pode com um sorriso
provocar amor e felicidade. Uma pessoa que me encantou, e me encanta em todos
os seus gestos, e que compartilha comigo grandes realizações. Meu grande amor.
À Instituição UNIMINAS, e seus docentes, por sua excelente estrutura,
onde fora possível a conquista desta vitória.
RESUMO
No cenário atual, não há como ficar indiferente ao assunto de VoIP.
Discussões em torno do tráfego de voz sobre o protocolo da Internet não dão sinais
de cessar, por isso companhias apostam nesta tendência, que segundo pesquisas,
promete confirmar-se numa grande explosão de consumo. Nesta evolução das
comunicações, destaca-se o protocolo SIP (Session Initiation Protocol), um
protocolo capaz de iniciar, alterar e finalizar sessões multimídia, garantindo a
convergência em definitivo, da telefonia tradicional para telefonia IP. Porém apesar
das grandes vantagens trazidas pela convergência, esta trouxe também uma nova
preocupação: a segurança das informações, requisito que pode confirmar a
maturidade da tecnologia. Implementações do protocolo SIP, são vulneráveis a
ataques comuns baseados em redes IP, bem como a ataques que são únicos ao
SIP. Este fato coloca em risco as Informações das empresas que utilizam sistemas
de telefonia IP. Ataques que fazem uso das vulnerabilidades do protocolo SIP,
podem resultar na interrupção de aplicações fundamentais ao negócio de
corporações sustentadas em uma rede VoIP. Tal fato, dentro do contexto de
concorrência global, tornará uma grande economia em sérios prejuízos. A proposta
da pesquisa é demonstrar as vulnerabilidades e os possíveis ataques que fazem
uso das brechas em implementações do Session Initiation Protocol, criando um
documento com tais informações destinado a interessados e envolvidos com
sistemas de comunicação baseados no protocolo SIP.
Palavras-chave: SIP, vulnerabilidades, ataques, VoIP.
ABSTRACT
In the current scene, it does not have as to be indifferent to the subject
of VoIP. Quarrels around the traffic of voice on the protocol of the Internet do not
give signals to cease, therefore company bets in this trend, that according to
research, promises to confirm in a great consumption explosion. In this evolution of
the communications, protocol SIP (Session Initiation Protocol) is distinguished, a
protocol capable to initiate, to modify and to finish sessions multimedia, promising
the convergence in definitive, of the traditional telephony for telephony IP. However
although the great advantages brought for the convergence, this also brought a new
concern: the security of the information, requirement that can confirm the maturity of
the technology. Implementations of protocol SIP, are vulnerable the based common
attacks in nets IP, as well as the attacks that are only to the SIP. This fact at risk
places the Information of the companies who use systems of telephony IP. Attacks
that make use of the vulnerabilities of protocol SIP, can result in the interruption of
basic applications to the business of corporations supported in a VoIP net. Such
fact, inside of the context of global competition, will become a great economy in
serious damages. The proposal of the research is to demonstrate to the
vulnerabilities and the possible attacks that make use of the breaches in
implementations of the Session Initiation Protocol, creating a document with such
information destined the involved interested parties and with based systems of
communication in protocol SIP.
Key-words: SIP, vulnerabilities, attacks, VoIP.
LISTA DE FIGURAS
FIGURA 1 -
ARQUITETURA CLIENTE/SERVIDOR...................................................................... 21
FIGURA 2 -
ARQUITETURA DE PROTOCOLOS MULTIMÍDIA INTERNET ................................ 22
FIGURA 3 -
ARQUITETURA SIP ................................................................................................... 23
FIGURA 4 -
EXEMPLOS DE UA’S................................................................................................ 24
FIGURA 5 -
FUNCIONAMENTO DO REDIRECT SERVER........................................................... 26
FIGURA 6 -
REGISTRO DA LOCALIZAÇÃO EM UM REGISTRAR SERVER............................. 27
FIGURA 7 -
GATEWAY SIP/PSTN E GATEWAY SIP/H323 ......................................................... 28
FIGURA 8 -
ESTABELECIMENTO DE UMA SESSÃO SIP SIMPLES ......................................... 29
FIGURA 9 -
CAMPOS DA MENSAGEM INVITE ........................................................................... 29
FIGURA 10 -
CÁLCULO DO CAMPO CONTENT-LENGTH ........................................................... 31
FIGURA 11 -
DESCRIÇÃO DOS CAMPOS SDP............................................................................. 32
FIGURA 12 -
MÉTODOS DE REQUISIÇÕES SIP ........................................................................... 32
FIGURA 13 -
MÉTODOS DE REQUISIÇÕES ESTENDIDAS DO SIP ............................................ 33
FIGURA 14 -
CLASSES DE RESPOSTA SIP.................................................................................. 33
FIGURA 15 -
ESTRUTURA DA MENSAGEM 180 RINGING .......................................................... 34
FIGURA 16 -
ESTRUTURA DA MENSAGEM 200 OK .................................................................... 35
FIGURA 17 -
ESTRUTURA DO ACK ............................................................................................... 36
FIGURA 18 -
ESTRUTURA DO BYE ............................................................................................... 37
FIGURA 19 -
200 OK CONFIRMAÇÃO DO BYE............................................................................. 37
FIGURA 20 -
CHAMADA SIP COM PROXY SERVER .................................................................... 38
FIGURA 21 -
INVITE REPASSADO AO PROXY............................................................................. 39
FIGURA 22 -
INVITE REPASSADO PELO PROXY AO DESTINO................................................. 40
FIGURA 23 -
MENSAGEM 180 RINGING ENVIADA AO PROXY .................................................. 40
FIGURA 24 -
MENSAGEM DE RESPOSTA ENVIADA DO PROXY AO ORIGINADOR................ 41
FIGURA 25 -
CONFIRMAÇÃO 200 OK REPASSADA DO PROXY AO ORIGINADOR................. 41
FIGURA 26 -
REGISTER ENVIADO DIRETAMENTE PARA O SERVIDOR DE REGISTRO ........ 43
FIGURA 27 -
REGISTRO DE UM AGENTE EM UM SERVIDOR DE REGISTRO VIA PROXY ..... 43
FIGURA 28 -
MENSAGEM INVITE ENVIADA PARA O REDIRECT SERVER............................... 44
FIGURA 29 -
REPOSTA ENVIADA PELO REDIRECT SERVER ................................................... 45
FIGURA 30 -
REDIRECIONAMENTO VIA SERVIDOR PROXY ..................................................... 46
FIGURA 31 -
SIP X 323 .................................................................................................................... 48
FIGURA 32 -
SINALIZAÇÕES SIP X H323...................................................................................... 48
FIGURA 33 -
DIFERENÇAS NO STREAMMING SIP X H323 ......................................................... 49
FIGURA 34 -
SIP INVITE PASSÍVEL DE SNIFFING E SPOOFFING ............................................. 51
FIGURA 35 -
MENSAGEM DE REGISTRO VÁLIDA....................................................................... 56
FIGURA 36 -
VERSÃO MODIFICADA DO REGISTRO................................................................... 57
FIGURA 37 -
SPOOFING DO REGISTRO UTILIZANDO O SIVUS ................................................ 58
FIGURA 38 -
ATAQUE DE REGISTRATION HIJACKING .............................................................. 59
FIGURA 39 -
ATAQUE DE PROXY IMPERSONATION .................................................................. 61
FIGURA 40 -
PASSOS PARA CAPTURAR A MÍDIA VOIP COM O ETHEREAL........................... 62
FIGURA 41 -
ATAQUE DE ARP SPOOFING .................................................................................. 63
FIGURA 42 -
A FERRAMENTA CAIN REALIZANDO O ATAQUE DE HOMEM-DO-MEIO........... 64
FIGURA 43 -
ATAQUE DE MESSAGE TAMPERING ..................................................................... 64
FIGURA 44 -
ATAQUE DE SESSION TEAR DOWN....................................................................... 65
FIGURA 45 -
REMOÇÃO DO REGISTRO DO USUÁRIO PELO ATACANTE ............................... 67
FIGURA 46 -
FLUXO DO ATAQUE DE RE-INVITE......................................................................... 68
FIGURA 47 -
ATAQUE DE BYE....................................................................................................... 69
FIGURA 48 -
FLUXO DO ATAQUE DE UPDADE ........................................................................... 70
FIGURA 49 -
MENSAGEM SIP INVITE BEM FORMADA ............................................................... 72
FIGURA 50 -
MENSAGEM SIP INVITE MAL FORMADA ............................................................... 73
FIGURA 51 -
DESCOBRINDO AS CAPACIDADES COM A REQUISIÇÃO OPTIONS ................. 75
FIGURA 52 -
FLUXO NORMAL DE REGISTRO ............................................................................. 76
FIGURA 53 -
ATAQUE CONTRA UM REGISTRAR SERVER ........................................................ 77
FIGURA 54 -
ATAQUE DE CANCEL ............................................................................................... 78
FIGURA 55 -
CÓDIGOS DE ERROS COMUNS .............................................................................. 79
FIGURA 56 -
FLOODING DE INVITE............................................................................................... 82
FIGURA 57 -
PRINCIPAIS MECANISMOS DE SEGURANÇA PARA O SIP.................................. 84
FIGURA 58 -
CONFIRMAÇÃO DO INVITE PELO PROXY ............................................................. 85
FIGURA 59 -
INVITE ORIGINAL COM A CONFIRMAÇÃO............................................................. 85
FIGURA 60 -
TIPOS DE CONTEÚDO S/MIME ................................................................................ 86
FIGURA 61 -
NEGOCIAÇÃO COM SERVIDOR TLS ...................................................................... 88
FIGURA 62 -
SOLUÇÃO PARA SEGURANÇA REAL-TIME MEDIA STREAMS........................... 90
LISTA DE ABREVIATURAS E SÍMBOLOS
ACK
- Acknowledgment
AES
- Advanced Encryption Standard
AH
- Authentication Header
AOR
- address of record
ARP
- Address Resolution Protocol
ASCII
- American Standard Code for Information Interchange
CCP
- Connection Control Protocol
CR
- Carrier Return
DDoS
- Distributed Denial of Service
DES
- Data Encryption Standard
DHCP
- Dynamic Host Configuration Protocol
DNS
- Domain Name Service
DoS
- Denial of Service
ESP
- Encapsulating Security Payload
FTP
- File Transfer Protocol
HTML
- Hyper Text Transfer Protocol
HTTP
- Hyper Text Transfer Protocol
IETF
- Internet Engineering Task Force
IKE
- Hyper Text Markup Language
IP
- Internet Protocol
IPSEC
- Internet Protocol Security
IVS
- INRIA Videoconferencing System
LF
- Line Feed
MD5
- Message Digest Algoritm
MIME
- Multi-purpose Internet Mail Extension
MITL
- man-in-the-middle
MMCC
- Multimídia Conference Control
NGN
- Next Generations Network
OSI
- Open System Interconnection
PC
- Pesonal Computer
PCM
- Pulse-code modulation
PDA
- Personal Digital Assistant
PGP
- Pretty Good Privacy
PKI
- Public key infraestructure
PSK
- Pre-shared keys
PSTN
- Public Switched Telephone Network
QoS
- Quality of Service
RAS
- Registration Admission Status
RFC
- Request For Comments
RTCP
- Real-Time Control Protocol
RTP
- Real Time Protocol
S/MIME - Security/Multi-purpose Internet Mail Extension
SCIP
- Simple Conference Invitation Protocol
SDP
- Session Description Protocol
SHA
- Secure Hash Algorithm
SIP
- Session Initiation Protocol
SMTP
- Send Mail Transfer Protocol
SPIT
- Spam over Internet Telephony
SRTP
- Secure Real Time Protocol
SYN
- Synchronous
TCP
- Transmission Control Protocol
TCP/IP
-
TLS
- Transport Layer Security
UA
- User Agent
UAC
- User Agent Client
UAS
- User Agent Server
UDP
- User Datagram Protocol
URL
- Uniform Resource Locators
VoIP
- Voice over Internet Protocol
Transmission Control Protocol/Internet Protocol
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................15
1.1
1.2
1.3
1.4
1.5
CENÁRIO ATUAL ............................................................................................15
OBJETIVOS ...................................................................................................17
IDENTIFICAÇÃO DO PROBLEMA ........................................................................17
JUSTIFICATIVA ...............................................................................................18
ORGANIZAÇÃO DO TRABALHO .........................................................................18
2 FUNDAMENTOS DO PROTOCOLO SIP .............................................................19
2.1
SURGIMENTO DO SIP.....................................................................................19
2.2
INTRODUÇÃO .................................................................................................20
2.3
COMPONENTES DO SIP..................................................................................23
2.4
SINALIZAÇÃO SIP ..........................................................................................28
2.5
SINALIZAÇÃO SIP COM SERVIDOR PROXY........................................................37
2.6
REGISTRO SIP ..............................................................................................42
2.7
REDIRECIONAMENTO......................................................................................44
2.8
SIP X H.323.................................................................................................47
2.8.1 Diferenças na Sinalização .......................................................................48
2.8.2 Diferenças no Streaming .........................................................................49
3 VULNERABILIDADES DOS SISTEMAS VOIP BASEADOS EM SIP ..................50
3.1
INTRODUÇÃO .................................................................................................50
3.2
AMEAÇAS E ATAQUES AO SIP.........................................................................55
3.2.1 Registration Hijacking..............................................................................55
3.2.2 Proxy Impersonation................................................................................60
3.2.3 Eavesdropping (Espionando) ..................................................................62
3.2.4 Message Tampering................................................................................64
3.2.5 Session Tear Down .................................................................................65
3.2.6 Denial of Service .....................................................................................66
3.3
ATAQUES UTILIZANDO DE MENSAGENS SIP......................................................66
3.3.1 Ataques a sistemas sem a autenticação aplicada ...................................66
3.3.1.1 Ataque de DoS utilizando mensagens de REGISTER SIP ..............66
3.3.1.2 Ataque de “Re-INVITE” ....................................................................67
3.3.1.3 Ataque de “BYE” ..............................................................................68
3.3.1.4 Ataque de “UPDATE” .......................................................................69
3.3.2 Ataques a sistemas com a autenticação aplicada (antes da autenticação)
70
3.3.2.1 Ataques de “Parser” .........................................................................71
3.3.2.2 Ataques de “REGISTER” .................................................................75
3.3.2.3 Ataques de “CANCEL” .....................................................................77
3.3.2.4 Fraudes em Respostas SIP..............................................................78
3.3.3 Ataques a sistemas com a autenticação aplicada (após a autenticação)79
3.3.3.1 Ataque de Força Bruta .....................................................................80
3.3.3.2 Unusable Destinations (Destinos Inúteis).........................................81
3.3.3.3 Ataques de “INVITE” ........................................................................81
4 MECANISMOS DE SEGURANÇA........................................................................83
4.1
HTTP BASIC AUTHENTICATION .......................................................................83
4.2
HTTP DIGEST AUTHENTICATION .....................................................................84
4.3
PRETTY GOOD PRIVACY (PGP)......................................................................86
4.4
SECURE MIME (S/MIME)..............................................................................86
4.5
SIPS URI (TLS) ...........................................................................................88
4.6
IP SECURITY (IPSEC).....................................................................................89
4.7
SEGURANÇA SOBRE PROTOCOLOS DE TRANSPORTE EM TEMPO REAL .................89
4.7.1 Secure RTP (SRTP) ................................................................................90
4.7.2 IP Security (IPsec)...................................................................................90
5 CONCLUSÕES .....................................................................................................91
5.1
5.2
CONSIDERAÇÕES FINAIS ................................................................................91
PROPOSTAS PARA TRABALHOS FUTUROS ........................................................92
6 REFRÊNCIAS BIBLIOGRÁFICAS .......................................................................94
15
1 INTRODUÇÃO
1.1 Cenário Atual
O envio de sinais de voz em pacotes digitais, conhecido como VoIP
(Voice over IP – Voz sobre Protocolo de Internet), manifesta diversas vantagens em
relação as redes telefônicas tradicionais. Muitas dessas vantagens deve-se ao fato
de consolidar a transmissão de voz e dados sobre uma mesma infra-estrutura, e de
distribuir a inteligência do sistema entre diversos elementos, deixando de concentrála apenas nas centrais telefônicas. Como resultado, tem-se não só a redução
drástica dos custos como também a possibilidade de criação de sistemas globais de
comunicação. Com o amadurecimento da Internet e de seus protocolos de
comunicação, a convergência de múltiplas mídias como voz, vídeo, dados e
serviços como chat, Instant Messages, e Web, deixou de ser apenas uma
curiosidade, para tornar-se uma grande oportunidade. Neste contexto é que surge a
telefonia IP (Internet Protocol). Telefonia IP é uma modalidade de VoIP onde o
serviço fornecido apresenta qualidade e funcionalidades no mínimo equivalentes
aos serviços telefônicos convencionais. O usuário utiliza um telefone IP que é um
telefone mais inteligente, ou um adaptador IP para um telefone convencional e uma
conexão IP de banda larga para conectar-se a rede de telefonia IP. Adicionalmente
pode-se acessar o serviço utilizando um computador com um programa especial
para esse fim. Nesta evolução das comunicações, destaca-se o SIP (Session
Initiation Protocol – Protocolo de iniciação de sessão), um protocolo desenvolvido
pelo IETF (Internet Engineering Task Force), que atua no nível de aplicação, capaz
de estabelecer, gerenciar e terminar chamadas entre dois ou mais pontos de
comunicação. O SIP é caracterizado por sua estrutura simples, fazendo uso dos
serviços de outros protocolos para implementar sua arquitetura multimídia e desse
modo deve ser o protocolo padrão nas comunicações mundiais. o SIP visa trazer
algo semelhante ao que o IP trouxe para Internet no mundo, prometendo a
convergência em definitivo, da telefonia tradicional para telefonia IP. Segundo
Lazarini (2006), a Telefonia IP associada a outras aplicações como colaboração,
presença, e-mail, voice mail, fax, e outras limitadas somente pela nossa capacidade
16
de criação, serão a base da comunicação do futuro e mudará a maneira como
fazemos negócios.
Existem,
porém,
aspectos
importantes
a
serem
revistos
nas
implementações SIP, a mais crítica refere-se a segurança. De acordo com Collier
(2005), o sistema SIP é vulnerável aos ataques comuns baseados em redes IP,
bem como a ataques que são únicos ao SIP. A disponibilidade do serviço de VoIP
está ligada diretamente a disponibilidade da infra-estrutura IP, qualquer tipo de
ataque, pode acarretar um sério impacto nas comunicações. Por ser um protocolo
baseado nos protocolos da pilha TCP/IP (Transmission Control Protocol/ Internet
Protocol), o SIP herdou destes suas tão exploradas vulnerabilidades.
Hoje em dia o requisito mais importante para a VoIP é a segurança, e
isso pode construir-se com componentes fiáveis e bom planeamento
durante a colocação. As telecomunicações sempre tiveram requisitos
altos de fiabilidade, mas devido ás redes de telecomunicações terem
estado sempre fechadas, a segurança nunca foi um requisito. As
coisas são diferentes para o VoIP. A prevenção da fraude é um dos
tópicos
principais
quando
se
coloca
a
VoIP.
A conectividade aberta é também frequentemente exigida, e isso cria
um recreio para os hackers, expondo a rede de telecomunicações a
ataques como vermes e vírus. A colocação inteligente requer um
conhecimento das ameaças, vulnerabilidades e ataques. O
desenvolvimento de produtos e sistemas de VoIP seguros é possível
com testes à robustez, concentrando-se na eliminação das
vulnerabilidades em cada parte do conjunto. Conhecendo os
requisitos, e minimizando os riscos, permite-lhe construir um sistema
de VoIP seguro, fiável e robusto. (TAKANEN,2006, tradução nossa).
VoIP é um assunto de grande importância na evolução dos serviços de
telecomunicações; é necessário rever algumas questões fundamentais como a
segurança das comunicações e a harmonização sobre a regulamentação aplicada;
o Session Initiation Protocol é a base para o seu desenvolvimento e disseminação
no mercado. Sendo assim, a segurança em sistemas baseados no protocolo SIP,
torna-se um ponto importante a ser pesquisado, já que o mesmo promete ser o
protocolo universal que integrará a rede de voz e dados definitivamente.
[...]Ao fazer ligações telefônicas pela internet, as empresas estão
economizando milhões. Mas estão expondo seus sistemas de voz a
todas as pragas que hoje atacam as redes de dados, como worms,
vírus, spam sobre telefonia internet (SPIT), ataques DoS e fraudes.
Além disso, abrem mais portas para que outras áreas da rede
também sejam atacadas, afetando a infra-estrutura das empresas e
17
seus sistemas.[...] (CIO REVISTA, 2004).
[...] Na sua forma básica, o SIP trafega em texto puro, significando
que ele é vulnerável aos softwares espiões. Segundo os
especialistas é fácil interceptar as chamadas VoIP não criptografadas
usando um iPod.[...](CIO REVISTA, 2004).
1.2 Objetivos
Este trabalho tem por objetivo demonstrar o funcionamento do
protocolo SIP, expondo suas vulnerabilidades e evidenciando ataques à sua
arquitetura, bem como alguns métodos de defesa à tais ofensivas maliciosas. Com
isto, pretende-se fornecer subsídios de informações referentes à segurança no uso
de sistemas de comunicação baseados no protocolo SIP, oferecendo condições aos
ingressantes, de evoluir nesta área. Não é foco deste trabalho, aprofundar em
métodos de defesa, nem em outros protocolos de sinalização, tais como o H323.
Deve-se notar que o mesmo não trata de QoS – Quality of Service (Qualidade de
Serviço) VoIP.
1.3 Identificação do problema
Devido ao grande interesse na redução de gastos, convergência e na
criação de novos serviços de comunicação, a padronização de um protocolo capaz
de gerir uma sessão multimídia torna-se inevitável. O fato de ser um protocolo de
arquitetura simples e aberta faz do SIP um protocolo com grandes possibilidades de
se tornar o padrão das comunicações sobre as redes IP.
[...] Desenvolvedores de produtos VoIP, grandes e pequenos, estão
adotando o SIP. A Microsoft introduziu o protocolo SIP em seu
sistema operacional Windows XP, e baseou seu programa de
mensagens instantâneas neste protocolo. A IBM reconheceu o SIP
como o futuro para todos os produtos de comunicação que utilizam
voz e vídeo[...]. (CHECK POINT SOFTWARE TECNOLOGIES LTD,
CA, 2004, p. 4, tradução nossa).
18
Contudo Implementações do SIP, sem as devidas preocupações com
a segurança podem acarretar em sérios prejuízos ao negócio. Documentar e tornar
pública as vulnerabilidades do SIP facilita a correção de problemas, servindo como
apoio tanto profissionais experientes em segurança da informação, quanto
interessados em ingressar na nova tendência da comunicação multimídia sobre
redes IP.
1.4 Justificativa
A justificativa para elaboração de um documento de referência sobre
as vulnerabilidades do protocolo SIP, explica-se pelo fato de ser um assunto pouco
divulgado. Sabe-se da grande capacidade do SIP nas comunicações globais, porém
suas falhas ainda são pouco conhecidas. O trabalho torna-se interessante à medida
que detalha os ataques que exploram as vulnerabilidades deste protocolo,
demonstrando como tais falhas podem abrir portas permitindo que pessoas mal
intencionadas estejam aptas a explorá-las, e como conseqüência, gerar prejuízos
ao sistema de comunicação.
1.5 Organização do trabalho
No Capítulo 2, será apresentado o protocolo SIP, enfatizando além da
sua arquitetura, componentes e estrutura, o seu funcionamento. Este capítulo ainda
apresenta uma breve comparação do SIP com o H323, outro protocolo de
sinalização, que está sendo substituído pelo Session Initiation Protocol. O Capítulo
3 trata das vulnerabilidades do sistema de comunicação que fazem uso do SIP,
enfatizando os ataques e suas conseqüências. No Capítulo 4, serão analisadas
algumas medidas de proteção, contudo, sem aprofundar nestas soluções, apenas
expondo alguns procedimentos mais utilizados. E finalmente, o Capitulo 5, relatando
tanto as conclusões obtidas pela pesquisa, quanto as dificuldades e limitações no
estudo do tema.
19
2 FUNDAMENTOS DO PROTOCOLO SIP
2.1 Surgimento do SIP
Segundo, Camarillo (2001), embora a primeira transmissão de voz
sobre redes comutadoras de pacotes datam por volta de 1974, O primeiro sistema
de conferência multimídia surgiu no inicio de 1990 desenvolvido por Terry Turletti.
Nomeado de INRIA Videoconferencing System (IVS). Tratava-se de um sistema de
transmissão de áudio e vídeo sobre a Internet. Mais tarde, Eve Schooler
desenvolveu o Multimídia Conference Control (MMCC), um software capaz de
prover teleconferências ponto-a-ponto e multiponto, com áudio e vídeo. Para
conectar vários usuários, o MMCC fazia uso do Connection Control Protocol (CCP),
um protocolo de controle orientado a transação. Uma transação consiste em um
podido de um usuário, e a resposta de outro usuário remoto. Para o transporte dos
pacotes o CCP utilizava o protocolo User Datagram Protocol (UDP), implementando
o time-out, e a retransmissão para garantia da entrega dos pacotes. Estes dois
primeiros
sistemas
de
conferência
multimídia
abriram
caminho
para
o
desenvolvimento do Session Initiation Protocol (SIP). A primeira versão do SIP, o
SIPv1, criada por Mark Handley e Eve Schooler, foi avaliada pelo IETF, como um
modelo para Internet em vinte e dois de fevereiro de 1996. O SIPv1 era um
protocolo baseado em texto, e fazia uso do Session Description Protocol (SDP) para
descrever as sessões multimídia, e do UDP, para o transporte dos pacotes. O
SIPv1 apresentou o conceito de registro de endereço em servidores de conferência
multimídia, promovendo certo nível de mobilidade ao usuário, pois uma vez que
este registre sua localização, um servidor de endereços é capaz de endereçar
convites ao próprio usuário. Sendo assim, se um usuário estivesse distante de sua
estação de trabalho, poderia escolher registrar-se em uma estação de trabalho
temporária e continuar recebendo convites multimídia. Neste primeiro momento, o
SIPv1 controlava apenas o estabelecimento e a finalização da sessão. Também em
vinte e dois de fevereiro de 1996, Henning Schulzrinne, submeteu ao IETF um
modelo de protocolo para Internet, capaz de convidar usuários para conferências
ponto-a-ponto ou multicast chamado de Simple Conference Invitation Protocol
20
(SCIP). Este protocolo era baseado no HTTP, e utilizava o Transmission Control
Protocol (TCP) para transporte dos pacotes. O SCIP fazia uso de endereços de email para identificar os usuários, e era capaz de alterar parâmetros da sessão após
seu estabelecimento. Então no 35th IETF meeting, foram apresentados os
protocolos SIP e o SCIP. E durante este encontro, e se estendendo ao seguinte o
36th IETF meeting, Schooler e Schulzrinne decidiram então unir as funcionalidades
dos dois protocolos, mantendo o nome SIP criando então o SIPv2. Em dezembro de
1996, surgiu o novo SIP, baseado em HTTP, é fazendo uso tanto do TCP, quanto
do UDP para transporte dos pacotes. A partir deste momento o SIP, adquiriu sua
verdadeira importância pelo IETF, que despende esforços para o desenvolvimento
da maturidade deste protocolo que gradativamente esta se tornando o padrão para
o estabelecimento, modificação e finalização de sessões multimídia.
2.2 Introdução
Segundo as especificações contidas no Request For Comment 3261
(RFC 3261), algumas aplicações que utilizam a Internet necessitam do
estabelecimento e gerenciamento de sessões. O fato dos usuários moverem-se
entre terminais, estarem acessíveis por diferentes nomes, comunicarem-se
utilizando diferentes mídias e às vezes simultaneamente, dificulta a implementação
destas aplicações. Neste cenário destaca-se o protocolo SIP. Definido e
implementado pelo Internet Engineering Task Force (IETF), trata-se de um
protocolo de controle referente à camada de aplicação do Modelo de Referência
OSI (Open System Interconnection), capaz de iniciar, modificar e terminar
comunicações multimídia ou chamadas entre usuários, definindo como os
equipamentos (computadores, telefones fixos, celulares, etc.) trocarão informações
entre si. As aplicações atuais do SIP estão direcionadas para as sessões interativas
de multimídia, tais como chamadas telefônicas ou conferências multimídia, mas o
SIP pode ser utilizado em sistemas de mensagens instantâneas, notificação de
acontecimentos, ou na gestão de outros tipos de sessão como, por exemplo, jogos
distribuídos. Em meio as suas funcionalidades tem-se o estabelecimento de
chamadas, a localização de usuários, suporte a unicast e multicast, administração
na participação de chamadas, negociação de recursos entre as partes e a
21
possibilidade de interoperabilidade com o protocolo H323, através de um gateway.
O SIP basea-se no modelo cliente/servidor, como demonstrado na figura 1, o cliente
faz a requisição e o servidor retorna as respostas referentes ao pedido.
Figura 1 - Arquitetura cliente/servidor
A sintaxe e semântica do SIP assemelham-se ao HTML com campos
explicitamente descritos, e herda do Hyper Text Transfer Protocol (HTTP) várias
propriedades, uma delas: o suporte ao transporte de qualquer tipo de carga. E
assim como o HTTP propiciou um grande impacto na Internet, o SIP promete o
mesmo no que se refere à comunicação em tempo real: com celulares, ou telefones
comuns,
via
mensagens
instantâneas,
ou
utilizando
qualquer
dispositivo
fundamentado em IP (Internet Protocol). De fato o potencial do SIP extrapola sua
simplicidade e flexibilidade. Com uma estrutura textual, o SIP possibilita a inclusão
de novas características de forma fácil e compatível com versões anteriores, o que
é fundamental para um protocolo que pretende ter vida longa. Os endereços SIP
são URLs (Unifomr Resource Locators), possibilitando a implementação de
diferentes recursos, como permitir realizar uma chamada, apenas com o clique em
22
um link em uma página web. O protocolo SIP faz parte de uma arquitetura de
protocolos de Conferência Multimídia da Internet, em desenvolvimento no IETF. A
figura 2 apresenta a pilha de protocolos correspondente a esta arquitetura.
Figura 2 - Arquitetura de protocolos multimídia Internet
De acordo com a RFC 2543, que descreve as operações do SIP, este
define algumas funcionalidades básicas, tais como:
• Estabelecimento, modificação e termino de sessões multimídia
O protocolo SIP, estabelece, modifica e termina sessões multimídia,
independente do tipo de sessão, seja ela uma vídeo conferência, uma chamada
telefônica na Internet, um chat, ou até sessões de jogos entre participantes. O SIP
determina as capacidades do meio de transmissão entre os usuários e estabelece o
nível mínimo de comunicação possível entre dois pontos. Além disso, permite que
os usuários determinem o tipo de informação que será trocada e seus respectivos
parâmetros. Possibilita a alteração dinâmica das configurações estabelecidas no
momento da conexão, por exemplo, a entrada de outros intervenientes na
conferência, ou alterações nas características em uma sessão já iniciada. O SIP
também detecta a transferência de chamadas, estabelecendo uma conexão entre o
transmissor e o novo receptor, encerrando a conexão original. Se uma chamada
não pode ser estabelecida porque o destinatário esta indisponível, o SIP e capaz de
determinar o estado do mesmo, se este já está com outra chamada em curso, ou se
não atende num determinado tempo.
• Mobilidade
O SIP não pode iniciar uma sessão com um potencial participante até
23
que este seja localizado. É comum que um usuário se desloque entre estações de
trabalho, podendo ser localizado em vários lugares. O SIP determina a localização
do destino da chamada através da resolução de endereços, mapeamento de nomes
e redirecionamento de chamadas. Para que os usuários possam ser localizados,
estes registram-se em um servidor de localização, isto torna-se necessário para
que um determinado usuário que possui um nome qualquer, possa ser localizado
em algum momento da ligação. Os usuários em um ambiente SIP, são identificados
através do SIP Uniform Resource Locators, (URL), cuja sintaxe assemelha-se aos
endereços de correio eletrônico, geralmente constituído por um nome de usuário e a
descrição do domínio, por exemplo: SIP:[email protected].
2.3 Componentes do SIP
O IETF define um conjunto de componentes na arquitetura do SIP,
operando em uma rede IP. Este conjunto de componentes é definido como Rede
SIP, e é apresentado na figura 3.
Figura 3 - Arquitetura SIP
24
• SIP User Agent (UA)
É o cliente da arquitetura, ou ponto final da comunicação multimídia,
que provê a interface de interação com o usuário. O User Agent possui dois
componentes: um User Agent Client (UAC), que é responsável por iniciar as
chamadas enviando as requisições, e um User Agent Server (UAS) responsável por
responder as requisições do UAC. Um UA tem a capacidade de atuar como UAC e
UAS, porém de um modo a cada transação, dependendo de quem inicia o pedido.
Os SIP UA’s são implementados em diversos tipos de sistemas. Estes podem, por
exemplo, operarem em um computador, através de uma aplicação, ou podem ser
implementados em dispositivos dedicados como um SIP phone. A figura 4, ilustra
alguns exemplos de UA’s:
Figura 4 - Exemplos de UA’s
• SIP Proxy Server
São intermediários em uma comunicação multimídia, é um servidor de
redirecionamento de requisições e respostas. O SIP Proxy Server, recebe uma
requisição e atua como sinalizador da chamada, redirecionando-a para o próximo
servidor SIP da rede, como se fosse o requisitante. Assim que recebe a resposta,
encaminha ao real chamador. O SIP Proxy Server também disponibiliza serviços
25
como: autenticação, autorização, controle de acessos, roteamento, retransmissões
de pedidos e segurança. Tipicamente, o Proxy Server, acessa uma base ou um
serviço de localização para determinar o próximo hop (nó da rede). Esta interface
entre proxy e serviço de localização não é definida pelo SIP. As bases acessadas
pelo proxy, para determinar a localização, pode conter: informações de presença,
registros SIP, ou qualquer outro tipo de informação que auxilie na localização do
usuário.
• SIP Redirect Server
Responsável por receber as requisições e Informar aos clientes o
caminho que a chamada deve tomar, de forma que o cliente entre diretamente em
contato com os próximos UAs. A função primária do Redirect Server é o roteamento
de chamadas, ou seja, a determinação do conjunto de servidores que será utilizado
como rota para a comunicação. Para que sejam determinadas as rotas, tanto o SIP
Proxy Server quanto o SIP Redirect Server, podem utilizar meios tais como executar
programas de consulta a banco de dados. Além disto, um servidor proxy também
pode duplicar a requisição, enviando copias destas para os próximos servidores.
Isto proporciona que uma requisição de inicio de chamada tente diferentes rotas, e
a primeira localização que responder é conectada com o cliente chamador. Em
resumo, o Redirect Server, faz o roteamento das requisições e respostas enviando
uma mensagem aos clientes com o endereço SIP procurado, e não fazendo o papel
de continuar a chamada. A Figura 5 ilustra o funcionamento do Redirect Server.
Nesta figura, Lívia pretende iniciar uma chamada para Rodrigo, utilizando uma
aplicação SIP em seu computador. Ao enviar o convite, o UA de Livia primeiramente
tenta localizar Rodrigo pelo seu endereço público, porém, no domínio empresa.com,
existe um SIP Redirect Server controlando os convites para inicio de sessão, que se
destinam a este domínio. O Redirect Server sabe que Rodrigo pode ser encontrado
tanto no endereço: SIP:[email protected], quanto no endereço: SIP:
[email protected], então o Redirect Server informa Livia para que tente
localizar Rodrigo, nos endereços conhecidos. Além disso, o servidor de
redirecionamento é capaz de priorizar e informar para o UA de Livia que Rodrigo
será localizado provavelmente no domínio empresa.com. Nota-se que neste
exemplo, o Redirect Server meramente retorna uma lista de possíveis localidades
do destinatário.
26
Figura 5 - Funcionamento do Redirect Server
A arquitetura SIP pode ainda apresentar os seguintes componentes:
• SIP Registrars
São responsáveis por processar os pedidos dos UAC, registrando sua
localização, que é armazenada em algum dos servidores de localização da
arquitetura. O Registrar ou Register Server pode ser incluído em um servidor proxy
ou em um Redirect Server. A figura 6 mostra Rodrigo registrando sua localização
em um SIP Registrar:
27
Figura 6 - Registro da localização em um Registrar Server
• Servidor de Localização
Sua função é armazenar e consultar registros de localização de
usuários.
• Gateway SIP
O Gateway e responsável pela interoperabilidade entre redes SIP e
outras que utilizam diferentes protocolos de sinalização, SIP – H323 ou SIP – PSTN
(Public Switched Telephone Network). A figura 7 ilustra esta interoperabilidade.
28
Figura 7 - Gateway SIP/PSTN e gateway SIP/H323
2.4 Sinalização SIP
Na figura 8, vê-se um exemplo do estabelecimento de uma sessão SIP
simples, entre dois dispositivos SIP. Estes dispositivos podem ser telefones SIP,
hand-helds, palmtops, telefones celulares, softwares para chamadas SIP, entre
outros. No exemplo ilustrado por Jonhston (2001), assume-se que ambos
dispositivos estão conectados em uma rede IP e cada um conhece o endereço IP
do outro.
29
Figura 8 - Estabelecimento de uma sessão SIP simples
Neste exemplo, o chamador Anderson inicia a troca de mensagens
enviando uma mensagem SIP INVITE para Livia. A mensagem de INVITE, contem
os detalhes do tipo de sessão que será estabelecida. Esta sessão pode ser tanto
uma chamada com voz, uma conferência com vídeo, ou até uma sessão para uma
partida de um jogo. Os campos da mensagem de INVITE são demonstrados na
figura 9.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: Livia <sip:[email protected]>
From: Anderson <sip:[email protected]>;tag=76341
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: Preciso de sua ajuda...
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 158
v=0
o=Anderson 2890844526 2890844526 IN IP4 laboratorio.faculdade.com.br
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 9 - Campos da mensagem INVITE
30
A linha de início do INVITE SIP contém o tipo de pedido enviado pelo
cliente SIP, o endereço SIP do usuário destino e a versão SIP utilizada. De acordo
com Hersent (2001), o cabeçalho geral, comum tanto nos pedidos como nas
respostas, contém os seguintes campos:
• Via:
Traz a versão SIP, o protocolo da camada de rede, o endereço IP do
usuário que faz a chamada e a porta utilizada.
• Call-ID:
A primeira parte deste campo deve ser um padrão único dentro de
cada agente, e a última parte, o nome de domínio ou endereço IP. Um novo “CallID” deve ser gerado para cada chamada.
• From:
Este campo contém um nome que pode ser mostrado opcionalmente e
o endereço do originador da chamada. Deve estar presente tanto nas requisições
quanto nas respostas SIP. Nas respostas, o campo From simplesmente é copiado a
partir do pedido e, portanto, não designa ser o originador da chamada.
• To:
Este campo indica o destino da chamada, sendo obrigatório em todas
as requisições e respostas SIP.
• Cseq:
Este campo guarda um número escolhido aleatoriamente sem sinal,
que é incrementado a cada novo pedido (com exceção dos pedidos do tipo ACK e
CANCEL, onde o número é o mesmo da resposta recebida para o ACK; e o mesmo
do pedido cancelado para o CANCEL) juntamente com nome do método, ou seja,
que identifica o tipo de pedido que está sendo enviado. No caso de mensagens do
tipo resposta, o servidor deve copiar o valor Cseq do pedido para as respostas
correspondentes. Em ambos os tipos de mensagens (requisições e respostas), o
campo Qseq é obrigatório. Além dos campos de cabeçalho geral (utilizado por
requisições e respostas), uma requisição pode transportar campos com informações
31
específicas dos pedidos no cabeçalho, tais como: o campo Accept que transporta
os tipos de mídias aceitáveis na resposta, o campo Subject para transportar
informações sobre a natureza da chamada. Os campos que terminam com CR
(Carrier Return) e LF (Line Feed) são utilizados para determinar o uso de uma linha
em branco entre os campos. O cabeçalho da entidade é formado por campos de
que se aplicam diretamente ao corpo da mensagem, são eles:
• Content-Type:
Informa o tipo de conteúdo da mensagem.
• Content-Length:
Contém o número de octetos do corpo da mensagem.
Os campos Content-Type e Content-Length, indicam que o corpo da
mensagem, vista na figura 9, é SDP (Session Description Protocol), contendo 169
octetos de dados. A demonstração da contagem dos octetos é ilustrada na figura
10. Uma linha em branco separa o corpo da mensagem dos campos de cabeçalho,
que termina com o campo Content-Length.
No exemplo da figura 9, pode-se observar sete linhas de informações
SDP, que descrevem o tipo de mídia que o chamador Anderson prefere estabelecer
com Livia. A informação de mídia descrita é necessária, pois o SIP não faz
suposição da mídia utilizada, então o originador deve especificar exatamente seu
tipo. Os nomes dos campos SDP são listados na figura 11.
Linha
v=0©®
o=Anderson 2890844526 2890844526 IN IP4 laboratotio.faculdade.com.br©®
s=Phone Call©®
c=IN IP4 100.101.102.103©®
t=0 0©®
m=audio 49170 RTP/AVP 0©®
a=rtpmap:0 PCMU/8000©®
Total
05
70
14
26
07
25
22
169
Figura 10 - Cálculo do campo Content-Length
32
Parâmetros SDP
v=0
o=Anderson 2890844526 2890844526 IN IP4
laboratorio.faculdade.com.br
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 11 - Descrição dos campos SDP
Descrição
Numero da versão
Nome do originador
Assunto
Conexão
Tempo
Mídia
Atributos
A figura 11 inclui:
O endereço de conexão IP – 100.101.102.103.
O formato da Mídia – áudio.
O numero da porta utilizada – 49170.
O protocolo de transporte de Mídia – RTP (Real Time Protocol).
Codificação da Mídia - PCM u Law.
Taxa de amostragem – 8000Hz.
O INVITE SIP, é apenas um exemplo de requisição SIP. Segundo
especificações na RFC 3261, existem ainda cinco outros tipos ou métodos de
requisições SIP, e mais alguns em extensões desta RFC. As tabelas 12 e 13
apresentam os seis métodos de requisições SIP e os métodos estendidos
respectivamente.
Método
INVITE
ACK
BYE
CANCEL
REGISTER
OPTIONS
Funcionalidade
Convida pessoas para participar de uma sessão
Confirma o recebimento de uma resposta final para um INVITE
Solicita o término de uma sessão
Solicita que uma sessão prévia seja cancelada, diferente do BYE
Registra a informação de contato de um indivíduo
Consulta servidores com respeito a suas capacidades
Figura 12 - Métodos de requisições SIP
33
Método
INFO
MESSAGE
NOTIFY
PRACK
RFC
2976
3428
3265
3262
PUBLISH
REFER
SUBSCRIBE
UPDATE
Funcionalidade
Carrega informações de controle geradas durante a sessão
Permite a transferência de mensagens instantâneas
Permite a notificação de eventos específicos
Confirma a recepção de uma mensagem de resposta
informativa
3903
Publica o estado de um evento
3515
Solicita que o receptor faça contato com um terceiro
participante
3265
Permite se subscrever para um estado particular de um
recurso
3311
Permite a atualização dos parâmetros de uma sessão
Figura 13 - Métodos de requisições estendidas do SIP
A próxima mensagem vista no fluxo da figura 8 é a 180 Ringing,
enviada em resposta ao INVITE. Esta mensagem indica que a outra parte, no caso
Lívia recebeu o INVITE, e esta sendo alertada de que alguém quer contatá-la. O
alerta pode ser o toque do telefone, uma mensagem piscando no display, alerta
vibratório, ou qualquer outra forma que indique a intenção da chamada. O 180
Ringing é um tipo de mensagem SIP de resposta. As mensagens de resposta são
numéricas e classificadas pelo primeiro dígito da seqüência. O 180 Ringing é
qualificado como classe de informação, identificado pelo primeiro digito, o número 1.
Existem seis classes de respostas SIP, as primeiras cinco, foram herdadas do
HTTP versão 1.1, a sexta e ultima foi criada especificamente para o SIP. A figura 14
define cada classe de resposta SIP:
Classe
1xx
2xx
3xx
4xx
5xx
6xx
Descrição
Informativo
Ação
Indica o status da chamada antes que esta se
complete
Sucesso
A requisição foi recebida com sucesso
Redirecionamento
O servidor retornou possíveis localidades. O cliente
deve reenviar a requisição para outros servidores
Erro no Cliente
A requisição falhou devido a um erro no cliente
Falha no Servidor
A requisição falhou devido a um erro no servidor
Falha Global
A requisição falhou. A requisição não deve ser
enviada a este ou outros servidores
Figura 14 - Classes de resposta SIP
34
A figura 15 demonstra a estrutura da mensagem 180 Ringing.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bKfw19b
;received=100.101.102.103
To: Livia <sip:[email protected]>;tag=a53e42
From: Anderson <sip:[email protected]>;tag=76341
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
Figura 15 - Estrutura da mensagem 180 Ringing
Esta mensagem é composta pela cópia de alguns campos da
mensagem INVITE, como: Via, To, From, Call-ID e QSeq. Então uma linha de inicio
é adicionada a mensagem contendo a versão do SIP, o código de resposta e a
frase que indica a razão: Ringing (tocando). O parâmetro received é adicionado ao
campo Via, que contem o endereço IP de quem o origina a chamada, que
tipicamente é o mesmo endereço URI no campo Via, resolvido por um DNS
(laboratorio.faculdade.com.br). Nota-se que os campos To e From não se
inverteram, o que poderia se esperar, já que a mensagem partiu de Livia, porém o
SIP indica a direção da requisição, e não a direção da mensagem. Agora o campo
To, possui uma tag gerada por Lívia. Desde então, todas as requisições e respostas
da sessão terão as tags geradas por ambos. A resposta também contém o campo
Contact, que descreve o endereço pelo qual Livia pode ser contatada diretamente
uma vez que a sessão tenha sido estabelecida. Quando a parte chamada aceita a
sessão, atendendo ao telefone, por exemplo, uma resposta de 200 OK é enviada ao
originador da chamada, que também significa que o tipo de mídia proposta foi
aceito. A figura 16 ilustra a estrutura da mensagem 200 OK, enviada por Lívia.
35
SIP/2.0 200 OK
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bKfw19b
;received=100.101.102.103
To: Livia <sip:[email protected]>;tag=a53e42
From: Anderson <sip:[email protected]>;tag=76341
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 155
v=0
o=Livia 2890844528 2890844528 IN IP4 torre.empresa.com.br
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 60000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 16 - Estrutura da mensagem 200 OK
A mensagem 200 OK é estruturada da mesma forma que a 180
Ringing, contendo o mesmo tag do campo To, e o URI do contato. As capacidades
da mídia devem ser explicitadas no corpo da mensagem SDP adicionada na
resposta. No caso da figura 16, o corpo SDP contém:
Endereço do ponto final da comunicação – 200.201.202.203.
Formato da mídia – áudio.
Número da porta 60000.
Protocolo de transporte de mídia – RTP.
Codificação da mídia – PCM u Law.
Taxa de amostragem – 8000Hz.
A etapa final para confirmação e inicio da sessão, é feita por uma
requisição de reconhecimento (acknowledgment). Este reconhecimento indica que o
originador da chamada, no caso Anderson, recebeu com sucesso, do destino, Livia,
uma resposta. Esta troca de informações de mídia permite que a sessão seja
estabelecida usando outro protocolo, o RTP, por exemplo. A figura 17 mostra a
estrutura do acknowledgment (ACK).
36
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bK321g
Max-Forwards: 70
To: Livia <sip:[email protected]>;tag=a53e42
From: Anderson <sip:[email protected]>;tag=76341
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
Figura 17 - Estrutura do ACK
O campo CSeq, tem o mesmo número do INVITE que originou a
sessão, porém o método agora é o ACK. Neste momento a sessão de mídia é
iniciada, utilizando os parâmetros estabelecidos na troca de mensagens SIP. A
comunicação acontece utilizando outro protocolo, tipicamente o RTP. O parâmetro
branch contido no campo Via guarda um novo identificador da transação, isso
ocorre após o reconhecimento de uma das partes da comunicação através do 200
OK, considerando uma nova transação. Estas mensagens trocadas, mostram que o
Session Initiation Protocol é um protocolo de sinalização fim-a-fim, ou seja, uma
rede SIP ou um Servidor SIP, não é requerido para que o protocolo seja usado.
Dois end-points, utilizando a pilha de protocolo SIP e conhecendo o endereço IP um
do outro, podem fazer uso do SIP para configurar uma sessão entre eles. Quando o
chamador, Anderson, origina um INVITE, esta agindo como cliente, e quando Livia,
responde a esta requisição, esta agindo como servidor. Depois de estabelecida a
conexão, Livia envia uma requisição de BYE, agindo então como um cliente, e
Anderson agora age como o servidor, quando responde a requisição. Este é o
motivo pelo qual um ponto final da comunicação deve implementar tanto o software
cliente quanto o servidor. Jonhston (2001) ressalta ainda, que esta é a diferença do
SIP em relação a outro protocolo cliente\servidor como o HTTP ou FTP. No HTTP,
por exemplo, o browser (navegador) age sempre como o cliente, e o Web Server
age sempre como o servidor, similar ao FTP. A figura 18 demonstra a requisição de
BYE, que indica que uma das partes, no caso Livia, deseja encerrar a sessão:
37
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hG4bK392kf
Max-Forwards: 70
To: Anderson <sip:[email protected]>;tag=76341
From: Livia <sip:[email protected]>;tag=a53e42
Call-ID: [email protected]
CSeq: 1 BYE
Content-Length: 0
Figura 18 - Estrutura do BYE
Pode-se observar na figura 18 que o campo Via do BYE possui o
endereço do host de Livia, e também um novo identificador de transação. Isso
ocorre pois o BYE é considerado como uma nova transação, independente do
INVITE e do ACK. Os campos From e To mostram que a mensagem agora parte
de Livia. Assim Anderson consegue identificar a sessão pelo campo Call-ID, que é o
mesmo do INVITE, e então finalizar a sessão correta. A confirmação da resposta do
BYE é o 200 OK, visto na figura 19, nota se que a resposta mantém o valor CSeq
da requisição de BYE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hG4bK392kf
;received=200.201.202.203
To: Anderson <sip:[email protected]>;tag=76341
From: Livia <sip:[email protected]>;tag=a53e42
Call-ID: [email protected]
CSeq: 1 BYE
Content-Length: 0
Figura 19 - 200 OK confirmação do BYE
2.5 Sinalização SIP com Servidor Proxy
Jonhston (2001), explica ainda, que no exemplo ilustrado na figura 8, o
originador da chamada, Anderson, conhecia o endereço IP do destinatário do
convite, possibilitando que a requisição de INVITE pudesse ser diretamente enviada
ao destino, o que não acontece em geral. Um endereço IP não pode ser utilizado
como um número de telefone, isto porque os endereços IPs são geralmente
dinâmicos, obtidos pelo host quando este se conecta a um servidor DHCP, por
exemplo. Este endereço IP mantém-se fixo durante o tempo em que o host
38
permanece conectado, porém o endereço será diferente a cada conexão com o
servidor. Com isto conclui-se que o endereço IP, não identifica unicamente um
usuário, e sim um host em uma rede particular. Contudo, existe um protocolo que
identifica o usuário através de um endereço, independente de onde este esteja, este
protocolo é o SMTP (Send Mail Transfer Protocol). O SMTP entrega as mensagens
pelo endereço de e-mail, permitindo que o destinatário seja alcançado,
independente de qual seja seu endereço IP, ou onde este esteja localizado. Sendo
a comunicação usuário-a-usuário e não dispositivo-a-dispositivo, o SIP utiliza um
esquema de endereçamento semelhante ao de e-mail. Este endereçamento é parte
da família de endereços da Internet conhecidos como URI (Universal Resource
Identifier). O SIP URI é um nome, que é resolvido em endereço IP utilizando-se um
SIP Proxy Server e consultas a um DNS (Domain Name Server), no momento da
chamada, como visto na figura 20. Nesta figura, observa-se uma típica chamada
SIP utilizando-se um Proxy Server.
Figura 20 - Chamada SIP com Proxy Server
39
O SIP Proxy Server, não configura ou termina a sessão, este age
apenas como intermediário, situando-se entre as trocas de mensagens, apenas
recebendo as requisições e repassando-as. Na figura 20 vê-se apenas um servidor
proxy, porém podem existir múltiplos servidores no caminho da sinalização. O SIP
possui duas categorias de URIs: a primeira corresponde ao usuário, e a segunda
corresponde ao dispositivo ou ponto final da comunicação. As URI de usuário ou
user URI são conhecidas como address of record (AOR). Requisições destinadas a
AORs necessitam de buscas em bancos de dados de localização, podendo resultar
no envio da requisição para um ou vários dispositivos, já o URI de dispositivo,
conhecido como contato, não necessita de busca a banco de dados. O address of
record é geralmente usado nos campos de cabeçalho: To e From, enquanto um URI
de dispositivo é usado no campo de cabeçalho Contact. O método que relaciona as
URIs de dispositivo com um address of record é denominado REGISTER. Este
método é detalhado na sessão 2.6. Na demonstração da figura 20, Anderson
desconhece a localização de Rodrigo, então o SIP Proxy Server é usado para
repassar o INVITE. Primeiramente ocorre uma busca do URI SIP do domínio de
Rodrigo, que retorna o endereço IP do SIP Proxy Server deste domínio, então o
INVITE é repassado a este endereço. A figura 21 mostra a estrutura do INVITE.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
Max-Forwards: 70
To: Rodrigo <sip: [email protected] >
From: Anderson <sip:[email protected]>;tag=42
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: Onde você está exatamente?
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 159
v=0
o=Anderson 2890844526 2890844526 IN IP4 100.101.102.103
s=Phone Call
t=0 0
c=IN IP4 100.101.102.103
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 21 - INVITE repassado ao Proxy
40
Após receber o INVITE, o proxy examina o SIP URI requisitado, no
caso da figura 21: sip:[email protected], localizando então Rodrigo. O
proxy repassa o INVITE ao endereço IP do destinatário, com a adição de um
segundo campo Via, como visto na figura 22, contendo o endereço do proxy. Pela
presença de dois campos Via, pode-se concluir que o INVITE passou por um Proxy
Server. Após receber o INVITE, uma mensagem 180 Ringing é enviada de Rodrigo
ao proxy. Esta mensagem é detalhada na figura 23. Nota-se que o campo To, agora
possui uma tag, para identificar o dialogo em particular, além disso, o campo
Contact, contém o URI do dispositivo de Rodrigo.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP proxy.escritorio.com.br:5060;branch=z9hG4bK83842.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
Max-Forwards: 69
To: Rodrigo <sip:[email protected]>
From: Anderson <sip:[email protected]>;tag=42
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 159
v=0
o=Anderson 2890844526 2890844526 IN IP4 100.101.102.103
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 22 - INVITE repassado pelo proxy ao destino
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.escritorio.com.br:5060;branch=z9hG4bK83842.1
;received=100.101.102.105
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
To: Rodrigo <sip:[email protected]>;tag=314159
From: Anderson <sip:[email protected]>;tag=42
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
Figura 23 - Mensagem 180 Ringing enviada ao proxy
41
O proxy recebe o 180 Ringing, e verifica que o primeiro campo Via
contém seu próprio endereço, então o proxy remove o campo e repassa a resposta
ao endereço contido no próximo campo Via: 100.101.102.103, porta 5060. A
estrutura da resposta enviada a Anderson é detalhada na figura 24.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
To: Rodrigo <sip:[email protected]>;tag=314159
From: Anderson <sip:[email protected]>;tag=42
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
Figura 24 - Mensagem de resposta enviada do proxy ao originador
Vê-se que o campo Via, reduz a complexidade no encaminhamento da
mensagem, pois não requer buscas em banco de dados para localização da rota, e
além disso, a mensagem pode retornar pelos mesmos proxyes que a requisição. A
chamada é aceita por Rodrigo que envia uma resposta 200 OK que é repassada
pelo proxy a Anderson. A estrutura do 200 OK é detalhada na figura 25.
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.escritorio.com.br:5060;branch=z9hG4bK83842.1
;received=100.101.102.105
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
To: Rodrigo <sip:[email protected]>;tag=314159
From: Anderson <sip:[email protected]>;tag=42
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 159
v=0
o=Rodrigo 2890844526 2890844526 IN IP4 200.201.202.203
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 25 - Confirmação 200 OK repassada do proxy ao originador
Na figura 25, nota-se a presença do campo Contact, permitindo que a
mensagem de ACK seja encaminhada diretamente do originador ao destinatário.
42
Por fim o BYE é enviado diretamente ao ponto final da comunicação, que sinaliza
com um ACK, encerrando a sessão.
2.6 Registro SIP
Colcher (2005) explica que o primeiro passo para que um agente
possa ser conectado a um sistema de telefonia baseado no SIP, é registrar-se em
um servidor de registro. Deste modo, as mensagens entrantes no sistema
destinadas a este usuário, podem ser encaminhadas corretamente para sua
localização. Este processo pode ser feito diretamente entre o usuário e o servidor
de registro SIP, porém geralmente o registro é feito através de um servidor proxy,
que utiliza algum processo de autenticação do usuário antes de encaminhar a
solicitação ao SIP Rregister Server. O registro do agente é feito através de uma
requisição REGISTER, e alguns campos-chave no cabeçalho da mensagem. O
Campo From indica o endereço do indivíduo que inicia o registro, e o campo To traz
o endereço de registro, ou seja, o endereço a ser associado ao usuário sendo
registrado. Caso o registro seja feito pelo próprio usuário, diretamente no servidor,
os campos To e From terão os mesmos valores. Entretanto, se o registro ocorrer de
forma indireta, ou seja, via servidor proxy, estes valores serão diferentes, indicando
que um individuo, no caso o proxy, esta realizando o registro em benefício de outro,
o usuário. A mensagem de requisição de registro contém ainda o campo Contact,
que fornece a identificação do usuário e a localização do seu agente, para onde
serão encaminhadas as futuras mensagens. Outro campo importante na requisição
de registro é o campo Expire. Este campo contém um valor que indica o tempo
solicitado para o registro manter-se ativo no servidor de registro. Este tempo,
normalmente e indicado em segundos, e não pode ultrapassar o tempo limite
configurado no servidor, caso ocorra, é adotado o tempo estabelecido no SIP
Register Server. Tal situação é informada ao usuário na resposta enviada pelo
servidor, que indicará o tempo para expiração do registro no campo Expire do
cabeçalho da mensagem. O usuário precisa renovar o registro antes da expiração.
A figura 26, apresenta o conteúdo da mensagem REGISTER, enviada diretamente
de um agente localizado em m34.rio.com.br para o servidor de registro
registrar.rio.com.br.
43
REGISTER sip:registrar.rio.com.br SIP/2.0
Via: SIP/2.0/UDP m34.rio.com.br
From: <sip:[email protected]>
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]>
Expire:3600
Content-Length: 0
Figura 26 - REGISTER enviado diretamente para o servidor de registro
O registro pode ser feito pelo usuário em mais de um agente, em
localizações diferentes, e com o mesmo endereço de registro. Assim se uma
mensagem for destinada a este usuário, será replicada em série ou em paralelo
para os diversos agentes registrados para o individuo. O usuário pode remover seu
registro, enviando uma nova requisição REGISTER, indicando no campo To, o
endereço de registro, no campo Contact sua localização e identificação, e o valor
zero no campo Expire. Caso queira remover todos os registros, basta utilizar o
caractere * (asterisco) como valor no campo Contact. A figura 27, apresenta o fluxo
de registro de um agente em um servidor de registro passando por um proxy.
Figura 27 - Registro de um agente em um servidor de registro via proxy
A seqüência do registro é realizada da seguinte forma:
1 – O usuário inicia o agente e uma requisição REGISTER é enviada
ao proxy.
44
2 – O servidor proxy recebe a mensagem REGISTER e envia a
resposta 100 Trying para o agente, indicando que a requisição fora recebida, não
sendo necessária a retransmissão.
3 – Como o esquema de autenticação neste caso é simplificado, o
servidor proxy encaminha a requisição REGISTER para o servidor de registro.
4 – O servidor de registro então envia uma resposta 200 OK para o
proxy. A operação de registro não utiliza a mensagem ACK.
5 – O proxy encaminha a mensagem ao agente, notificando o registro
no sistema.
2.7 Redirecionamento
Em um sistema de telefonia baseado em SIP, pode ser necessária a
localização de seus participantes, afirma Colcher (2005). Este processo é realizado
utilizando-se as funcionalidades do servidor de redirecionamento. Para que seja
solicitado o serviço de redirecionamento, uma mensagem INVITE deve ser
encaminhada para o servidor de redirecionamento, ou Redirect Server. O campo
From desta mensagem indica o endereço do usuário que solicita o mapeamento, e
no campo To o endereço do indivíduo a ser localizado. A figura 28 apresenta o
conteúdo de uma mensagem INVITE, enviada por Anderson ([email protected])
para o servidor de redirecionamento (redirect.rio.com.br) solicitando a localização
do usuário Rodrigo ([email protected]).
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP m34.rio.com.br
From: Anderson <sip:[email protected]>
To: Rodrigo <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: Proposta de Venda de Produto
Content-Length:256
Content-Type: application/sdp
Figura 28 - Mensagem INVITE enviada para o Redirect Server
Para realizar a localização de participantes o Redirect Server age
como um cliente de um serviço de localização, este representado por um serviço de
45
banco de dados que mantém o mapeamento entre uma única URI e um conjunto
de localizações possíveis para o elemento referenciado na URI. A lista de uma ou
mais localizações possíveis são registradas no campo Contact da mensagem de
resposta de classe 3xx enviada pelo Redirect Server. A figura 29 apresenta o
conteúdo da mensagem de resposta 302 Moved Temporarily, enviada pelo Redirect
Server para o usuário Anderson, em resposta a mensagem da figura 28.
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP m34.rio.com.br
From: Anderson <sip:[email protected]>
To: Rodrigo <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Expire: 3600
Content-Length:0
Figura 29 - Reposta enviada pelo Redirect Server
Ao receber a mensagem de redirecionamento o originador da
chamada envia uma requisição ACK para o Redirect Server, e em seguida envia
uma nova requisição com base na URI ou URIs recebidas do Servidor de
redirecionamento. Estas URIs, não necessariamente são limitadas a URIs SIP,
podendo ser URIs de telefones, fax, irc, ou até de “mailto:”. A figura 30, apresenta o
processo de redirecionamento para efetivar a comunicação entre dois agentes
registrados através de servidores proxy.
46
Figura 30 - Redirecionamento via servidor proxy
O fluxo de mensagens é realizado da seguinte forma:
1 – O agente A envia uma requisição INVITE para que o proxy A
encaminhe ao agente B.
2 – O proxy A recebe o INVITE e notifica o Agente A com a resposta
100 Trying.
3 – Sendo o esquema de autenticação simplificado, o proxy não troca
demais mensagens com o agente A. E simplesmente encaminha o INVITE ao
servidor de redirecionamento.
4- O servidor de redirecionamento envia a resposta 302 Moved
47
Temporarily, com o mapeamento obtido através do serviço de localização.
5
–
O
proxy
A
encaminha
um
ACK para
o
servidor
de
redirecionamento completando o three-way-handshake (aperto de mão em três
vias).
6 – O proxy A utiliza a informação de mapeamento e gera um novo
INVITE, enviado ao proxy B.
2.8 SIP X H.323
O SIP e H.323 foram desenvolvidos para endereçar e sinalizar
sessões multimídia em arquiteturas distribuídas de controle de chamadas. Ambos
permitem comunicações com dois ou mais participantes, utilizando computadores
ou telefones como pontos terminais, admitem negociações de parâmetros,
criptografia e utilizam os protocolos RTP e RTCP para transporte e controle,
respectivamente. O protocolo H.323 é constituído por múltiplos protocolos incluindo,
Q.931 para a sinalização, H.245 para a negociação e o RAS (Registration
Admission Status) para controle de sessões. Este protocolo é considerado por
muitos, um protocolo grande, pesado, complexo e rígido, típico das empresas de
telecomunicações, difícil de adaptar a soluções futuras. Ao contrário, o SIP é um
protocolo típico da Internet e funciona trocando mensagens simples de texto ASCII.
O SIP é um protocolo com boa inter-operação com os outros protocolos da Internet,
mas não muito bom com os protocolos de sinalização do sistema telefônico
existente. Por ser um protocolo altamente modular e flexível, (modelo VoIP IETF),
pode ser facilmente adaptado a novas aplicações. Prometendo ser o centro no
controle das NGN (Next Generation Network). Segundo David (2005) o H.323
significa o “Mundo Antigo” das redes telefônicas PSTN, por ser complexo,
determinístico e vertical. Ao ser focalizado em aplicações multimídia, preocupa-se
em especificar todos os parâmetros da comunicação, centralizando a complexidade
no servidor. Ao contrário, o SIP significa o “Novo Mundo” das telecomunicações
sobre redes IP, tratando-se de um protocolo da família dos protocolos Internet,
simples, aberto e horizontal. O SIP é um protocolo de transação genérico que
delega a complexidade nos clientes. A figura 31 resume algumas diferenças entre
48
estes protocolos. Conclui-se nesta figura que o SIP é mais simples e mais orientado
para a Internet, suportando inclusive funcionalidades como instant messaging.
Aspectos
Negociação
H.245
SDP
Codecs
Todos
Todos
Comunicação
RTP/RTCP
RTP/RTCP
Codificação das
Mensagens
Binário
ASCII
Transporte
UDP e maioritariamente
TCP
-
TCP e maioritariamente
UDP
RFC 3428
Instant Messaging
H.323
SIP
Figura 31 - SIP X 323
2.8.1 Diferenças na Sinalização
As mensagens de sinalização e de controle podem ser trocadas
diretamente entre os terminais ou através de um servidor. A sinalização SIP é mais
simples, permitindo adicionar funcionalidades e serviços sem se perder a
compatibilidade com os terminais antigos, algo que não é possível no H.323. A
figura 32, compara as sinalizações SIP e H323.
H.323
SIP
Usa o H245 como protocolo de controle
para comunicações multimídia.
Sinalização em binário ASN.1.
Sinalização textual muito semelhante ao
HTTP ou SMTP;
Atrasos mínimos devido a sinalização
simplificada.
Possíveis atrasos.
Utiliza funções RAS (Registration,
Admission and Status) para o registro
dos terminais e resolução de endereços.
Figura 32 - Sinalizações SIP X H323
49
2.8.2 Diferenças no Streaming
O streaming é o envio da informação entre os terminais. A forma como
é feito é diferente dependendo dos protocolos. Embora tanto o H323, quanto o SIP
utilizem pacotes RTP/RTCP, o interior dos pacotes é muito diferente. A figura 33
demonstra as diferenças no streamming.
H.323
O H.245 é usado para negociar a
capacidade dos terminais e criar canais
de mídia
Usa RTSP que é um protocolo para
controle de sistemas de streamming.
SIP
Usa o controle de chamadas SDP que é
um descritor de mídia baseado em texto.
O SDP pode ser transportado nas
mensagens SIP.
Os URIs são semelhantes ao e-mail.
O RTSP tem mídia unidirecional.
Geralmente inicia sessões bidirecionais.
Figura 33 - Diferenças no streamming SIP X H323
50
3 VULNERABILIDADES DOS SISTEMAS VOIP BASEADOS EM SIP
3.1 Introdução
Está claro que a tecnologia VoIP é a grande tendência emergente no
panorama das telecomunicações, porém, apesar de todas as oportunidades
apresentadas, o serviço de voz sobre redes IP introduziu novos riscos referentes a
segurança da informação. A conversão para o sistema de telefonia IP sem os
devidos cuidados com a segurança, pode acarretar sérios danos ao negócio,
transformando a solução em problemas. Se por um lado as empresas economizam
ao fazerem ligações telefônicas pela internet, por outro, estão expondo seus
sistemas de voz a todas as pragas que hoje atacam as redes de dados, como
worms, vírus, spam sobre telefonia Internet (SPIT), ataques DoS, DDoS e fraudes,
comprometendo toda infra-estrutura VoIP. A utilização de redes privadas de
operadoras, não elimina os riscos de segurança. Ameaças de origem interna, como
ataques e fraudes continuam existindo. Segurança em ambientes VoIP são
exigidas, embora promove-la na Internet seja mais complexo do que em redes
PSTN. Mensagens SIP trocadas para o estabelecimento de sessões, podem conter
informações privadas, que o usuário ou o servidor queiram manter em sigilo. Um
exemplo são os cabeçalhos SIP, estes podem revelar informações sobre a
comunicação entre as partes. O mesmo ocorre com o corpo das mensagens, que
podem conter dados que não devem ser expostos, como: endereços, números de
telefone, etc. A natureza aberta dos protocolos VoIP em conjunto com o grande
número de sub-sistemas existentes na telefonia sobre a Internet, torna o desafio de
estabelecer-se uma comunicação segura, muito mais complexo. O acesso fácil ao
canal de comunicação é a ameaça mais ativa em um sistema VoIP. A captura e
analise do trafego da internet, facilitada pela estrutura textual do SIP, faz com que
seja simples a tarefa de espionagem. Assim, o protocolo SIP, oferece oportunidades
para ataques do tipo spoofing (falsificação), hijacking (seqüestro), e message
tampering (adulteração de mensagens). A figura 34 ilustra uma mensagem SIP
INVITE, assinalando alguns campos passiveis de falsificação.
51
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: Livia <sip:[email protected]>
From: Anderson <sip:[email protected]>;tag=76341
Call-ID: [email protected]
CSeq: 1 INVITE
Subject: Preciso de sua ajuda...
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 158
v=0
o=Anderson 2890844526 2890844526 IN IP4 laboratorio.faculdade.com.br
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP /AVP 0
a=rtpmap:0 PCMU/8000
Figura 34 - SIP INVITE passível de sniffing e spooffing
A utilização de mensagens SIP maliciosas pode causar desde o
acesso não autorizado ao sistema, até o estado crítico de negação de serviço
(Denial of Service - DoS). Ataques de DoS são um grande problema para o SIP. Um
atacante pode, por exemplo, inserir um código malicioso em uma requisição
REGISTER, induzindo a modificação do banco de dados de registro, fazendo com
que toda requisição de INVITE destinada a um usuário seja distribuída para vários
agentes pelo proxy, amplificando o tráfego, ou ainda enviada a um único agente,
tornando este indisponível. Por utilizar os protocolos TCP e UDP para o transporte,
e sendo estes protocolos vulneráveis a ataques como SYN flood, session hijacking,
o SIP também será vulnerável a ataques similares. Além disso, a interoperabilidade
do SIP permite a interconexão com redes PSTN, introduzindo novos pontos de
falha, como os gateways, que são susceptíveis a ataques de DoS e message
tampering. Os bugs (falhas) de software são outras fontes para problemas de
segurança do protocolo SIP, podendo causar o acesso não autorizado ou o DoS,
quando implementados em telefones. Por outro lado, se implementados em Smart
Phones, são vulneráveis a pragas como vírus.
52
“...Stevens assinalou ainda que com os sistemas de voz sobre IP o
problema tende a piorar. Um exemplo pode ser o da operadora - que
não teve o nome revelado - e que perdeu cerca de 76 mil dólares em
um único dia com a invasão de seu sistema de VoIP. Recentemente,
a Telecom New Zealand, principal operadora de telefonia fixa e
móvel da Nova Zelândia, enfrentou uma vulnerabilidade que permitiu
que hackers acessassem correios de voz de seus clientes. Utilizando
um software que permitia fazer ligações de voz sobre IP, um
adolescente acessou correios de voz de várias personalidades do
país, até mesmo do prefeito de Auckland, a maior cidade do país”. (
STEVENS , 2005)
Aspectos como vulnerabilidades em equipamentos que utilizam
protocolos para telefonia IP, são ressalvas importantes a serem consideradas, a fim
de impedir o comprometimento da rede e da utilização fraudulenta do serviço. Os
protocolos da pilha TCP/IP, atentam-se a funcionalidade e portabilidade não tendo a
segurança como prioridade.
TCP/IP e a maioria dos seus protocolos não foram desenvolvidos
com a segurança como prioridade. Eles foram projetados para
funcionalidade e portabilidade. (WILLIAN, 2003 apud YOSHIOKA,
2003, tradução nossa).
A maioria dos desenvolvimentos em SIP são focados em
interoperabilidade, com pouca atenção para segurança. Um sistema
SIP é vulnerável aos ataques IP e VoIP, bem como a ataques que
são únicos ao SIP. É fundamental que tal fato seja entendido e que
sejam tomadas as medidas apropriadas de segurança (COLLIER,
2005 , tradução nossa).
Segundo Yoshioka (2003), existem alguns desafios a serem
considerados em relação a segurança em telefonia IP:
a) Confidencialidade: As informações armazenadas e transmitidas
são acessíveis somente aos autorizados.
b) Autenticidade: Assegurar a correta identificação da origem
mensagem.
c) Integridade: Garantir que as mensagens não sejam apagadas ou
alteradas de forma não autorizada.
53
d) Disponibilidade: As informações e serviços devem estar
disponíveis 99,999%(five nines) para os autorizados.
e) Não Repúdio: Garantir que originador e o receptor da mensagem
não possam negar a autoria e recebimento respectivamente.
f) Controle de Acesso: O acesso às informações e recursos devem
ser controlados por autorizados.
Como visto as redes VoIP estão propensas aos mais diversos tipos de
ameaças. Um atacante pode invadir servidores ganhando o acesso à informação
vital de uma organização, ou ainda empregar de forma maliciosa os serviços de
voz, através do acesso não autorizado, beneficiando-se das vulnerabilidades do
sistema. Segundo Dhamankar (2004), falhas existentes nestes sistemas são
definidas da seguinte forma:
a) Vulnerabilidades dos Sistemas Operacionais implementados
nos dispositivos VoIP: Os dispositivos VoIP, tais como: IP
Phones, Call Manager, Gateways, e Proxy Servers, herdam as
mesmas vulnerabilidades dos Sistemas Operacionais ou firmware,
implementados nos mesmos. Estes dispositivos são tipicamente
desenvolvidos com os Sistemas Windows ou Linux, estes com
diversas vulnerabilidades já exploradas. Portanto, não importa o
quão uma aplicação VoIP seja ser segura, se o Sistema
operacional estiver comprometido, seu serviço de telefonia IP
estará em risco.
b) Configuração inadequada dos dispositivos VoIP: Em sua
configuração padrão, muitos dispositivos de VoIP, expõem
diversas portas UDP e TCP. Estas portas podem ser vulneráveis
a ataques do tipo DoS, Buffer overflow,
senhas fracas sejam facilmente capturadas.
e ainda permitir que
54
c) Vulnerabilidades da infra-estrutura IP: O serviço de VoIP
depende diretamente da disponibilidade da infra-estrutura IP em
que este esteja implementado. Utilizando-se dos protocolos UDP
e TCP, como meio de transporte, o serviço de VoIP, está
suscetível as diversas ameaças tais como ataques de DDoS, SYN
flood, que podem gerar indisponibilidade do serviço, ou ainda,
ataques de hijaking no caso do TCP, e a fragmentação maliciosa,
como o ping-da-morte (ping-of-death), no caso do UDP.
d) Vulnerabilidades em implementações de protocolos para
VoIP: Os protocolos escritos para VoIP não tem como prioridade
a segurança, e sim a interoperabilidade. Muitas vulnerabilidades
encontradas em implementações destes protocolos, como o SIP,
são resultado de pesquisas de grupos especializados que
geralmente disponibilizam suas ferramentas para teste das
vulnerabilidades nas implementações dos protocolos.
e) Vulnerabilidades na camada de aplicação VoIP: Nesta camada
existem uma variedade de ataques específicos ao VoIP. Incluído:
•
•
•
•
•
•
Denial of Service (DoS)
Call Hijacking
Resource Exhaustion
Evearsdropping
Message Integrity
Toll Fraud
O protocolo SIP possui os as mesmas vulnerabilidades do protocolo IP
e da camada de aplicação, este fato é explicado por alguns fatores:
Maturidade: as Implementações SIP são relativamente novas.
Codificação: o SIP utiliza mensagens de texto nas suas sinalizações,
que são fáceis de serem lidas, utilizando um sniffer.
55
Extensível: O SIP suporta extensões, que são novas e geralmente
frágeis do ponto de vista da segurança.
O SIP, oferece uma segurança embutida limitada, de acordo com a
RFC 3261, alguns itens classificados como “recomendado”, estão faltando em
algumas implementações. Além disto, o SIP promete interoperabilidade, permitindo
a aquisição de componentes de diversos fornecedores, isto tornar-se um problema,
pois todos os componentes devem suportar os mesmos padrões, caso contrário,
apenas as capacidades comuns serão utilizadas, fato grave do ponto de vista da
segurança. O SIP utiliza o protocolo UDP, para o transporte das mensagens, que é
protocolo não orientado à conexão, e não confiável. Nele não ocorre a
retransmissão dos pacotes, nem a ordenação dos mesmos, facilitando os ataques
de spoofing.
Softwares SIP de alguns fabricantes podem deixar os dispositivos
SIP como: IP Phones, PBX, e clientes instat messaging, vulneráveis
a ataques de DoS. (CERT CORDINATION CENTER 2003 Apud
HOCHMUTH, 2003, tradução nossa).
3.2 Ameaças e Ataques ao SIP
Esta sessão descreve possíveis falhas de segurança em sistemas
baseados no protocolo SIP, bem como ataques que fazem uso destas brechas,
colocando em risco a disponibilidade do serviço.
3.2.1 Registration Hijacking
O ataque de hijacking ou seqüestro é uma forma de se obter o controle
de uma conexão iniciada por um UA legítimo, impedindo o mesmo de fazer uso do
sistema e tomando seu lugar. O registration Hijacking (Seqüestro do Registro)
ocorre quando um atacante falsifica um UA válido para um SIP Register, alterando a
56
inscrição legítima para seu próprio endereço. Assim todas as chamadas são
enviadas para o UA registrado pelo atacante. A figura 35 ilustra uma mensagem de
registro válida, que como explicado anteriormente, é usada para anunciar o ponto
de contato de um usuário. O registro do usuário indica que este está apto a receber
chamadas.
Figura 35 - Mensagem de registro válida
A requisição de REGISTER, possui o cabeçalho Contact:, que indica o
endereço IP do dispositivo do usuário (tanto para um software VoIP, quanto para
um telefone IP). Quando o proxy recebe a requisição de INVITE, ele fará uma busca
para identificar onde o usuário ao qual se destina a chamada se encontra. No caso
da Figura 35, o usuário com o numero 201-853-0102 pode ser encontrado no
endereço IP 192.168.94.70. O proxy irá repassar a requisição de invite para aquele
endereço IP. O cabeçalho da mensagem informa que a porta a ser utilizada é 5061.
57
A Figura 36 mostra uma versão modificada do REGISTER, que pode ser lançada
por um atacante.
Figura 36 - Versão modificada do registro
Nesta requisição, todos os cabeçalhos e os parâmetros mantêm-se
inalterados, exceto os parâmetros no cabeçalho Contact. Este, alterado para o
endereço: 192.168.1.3, apontando para o dispositivo do atacante, por exemplo.
Utilizando ferramentas como o SiVuS, é muito fácil gerar mensagens forjadas, como
demonstrado na figura 37.
58
Figura 37 - Spoofing do registro utilizando o SiVuS
O ataque de Registration Hijacking pode seguir os seguintes passos:
1. Desabilitar o registro legitimo da vitima, que pode ser feito das
seguintes maneiras:
•
Executando um ataque de DoS no dispositivo do alvo.
•
Executando um ataque no Registrar Server, removendo o
registro da vitima.
•
Gerando “disputa” de mensagens de registro, onde o atacante
envia repetidamente mensagens de REGISTER num período
curto de tempo, com isso o atacante tenta sobrescrever o
registro do usuário legítimo.
59
2. Enviar a requisição de REGISTER alterando o endereço IP de
localização do usuário legítimo, para o dispositivo do atacante. A
figura 38 demonstra o fluxo do ataque.
Figura 38 - Ataque de Registration Hijacking
O registro normalmente é feito com a utilização do protocolo UDP,
tornando fácil o spoofing das requisições. Frequentemente a autenticação não é
60
requerida, e se presente, na maioria das vezes é fraca, exigindo apenas um usuário
e uma senha. De acordo com a RFC 3261, os dispositivos de registro SIP, são
recomendados a comprovar a autenticidade das solicitações. Muitos destes
dispositivos ou não fazem, ou simplesmente exigem um nome do usuário e uma
senha, que podem facilmente serem descobertos através de um ataque de
dicionário, onde o atacante possui um dos nomes de usuário e tenta descobrir a
senha através de uma lista de possibilidades baseadas no conhecimento da
corporação. Um atacante externo pode também criar um diretório de usuários,
através de um scanning dos endereços dos UAs. Algumas empresas utilizam
senhas compartilhadas, fracas, ou geradas mecanicamente. Neste caso, um
atacante que aprende uma das senhas, estará apto a aprender todas as outras.
Tentativas falhas de registro, não são armazenadas em arquivos de log, e o proxy
SIP, normalmente, não detecta tentativas de scanning e registration hijacking. O
ataque de registration hijacking, resulta na perda de chamadas ao UA legítimo, que
pode ser um usuário, telefone ou recurso crítico. Além disto, o atacante é capaz de
coletar a autenticação ou outra informação sobre a chave de sinalização, podendo
também realizar o ataque de man-in-the-middle (MITL), onde este posiciona-se de
forma transparente entre o UA chamandor e o UA chamado, possibilitando a coleta
e a modificação tanto da sinalização quanto da mídia. O Registration Hijacking
pode ser lançado tanto contra empresas quanto contra usuários domésticos. Uma
rede doméstica, por exemplo, que utiliza uma rede wireless mal configurada pode
ser comprometida por um atacante, que pode interceptar e encaminhar requisições
de registro. No caso de sucesso no registro, o atacante pode executar diversos
ataques, como chamadas fraudulentas, ou redirecionamento da comunicação, que
podem ser executados também em empresas.
3.2.2 Proxy Impersonation
O ataque de proxy Impersonation ou personificação de proxy, ocorre
quando um atacante engana um dos SIP UAs ou proxy do sistema de comunicação
com um falso proxy. Se o atacante obtiver sucesso no ataque, este terá acesso à
todas as mensagens SIP, e também ao controle total da chamada. A figura 39
ilustra o ataque de proxy impersonation.
61
Figura 39 - Ataque de proxy Impersonation
Os Uas e proxy, normalmente se comunicam utilizando o UDP, sendo
assim, um falso proxy pode, portanto, inserir-se no sistema de sinalização através
de diversos meios, incluindo DNS (Domain Name Service) spoofing, ARP (Address
Resolution Protocol) cache spoofing, ou simplesmente mudando o endereço proxy
para um telefone SIP. Um proxy disfarçado tem o controle total das chamadas e
pode executar os mesmos tipos de ataques descritos no ataque de registration
hijacking. Se o DNS spoofing for usado para redirecionar chamadas de saída para
um domínio particular, todo o curso da comunicação para aquele destino pode ser
interceptado, manipulado, bloqueado, assistido, ou gravado. O ARP cache spoofing
é um ataque contra um switch de rede, que pode enganar um UA comunicando-se
com o falso proxy na rede interna. Se bem sucedido, este ataque faz com que todas
as chamadas originadas do UA, possam ser interceptadas, manipuladas,
bloqueadas, assistidas e gravadas.
62
3.2.3 Eavesdropping (Espionando)
A espionagem em VoIP difere-se da espionagem das redes
tradicionais de dados, porém o conceito segue a mesma linha. O Eavesdropping em
redes VoIP requer a interceptação da sinalização e do respectivo fluxo de mídia da
conversação. As mensagens de sinalização utilizam protocolos como UDP e TCP e
o fluxo da mídia tipicamente são transportadas sobre UDP utilizando o protocolo
RTP. Com o uso de ferramentas como o Ethereal ou Cain & Abel, que são, entre
outras, ferramentas de sniffing de rede, é possível capturar a mídia transportada,
como demonstrado na figura 40.
Figura 40 - Passos para capturar a mídia VoIP com o Ethereal
O ataque de Eavesdropping pode seguir os seguintes passos:
1. Capturar e decodificar os pacotes RTP utilizando um sniffer.
2. Analisar a sessão, extraído a mídia a ser remontada.
63
3. Extrair o arquivo contendo o áudio da conversação capturado.
A utilização de switches que restringem o tráfego de broadcast não
impossibilitam o ataque, pois o ARP Spoofing pode ser utilizado para lançar um
ataque de homem-do-meio permitindo a espionagem. A figura 41 resume o ataque
de ARP Spoofing.
Figura 41 - Ataque de ARP Spoofing
A Figura 42 demonstra a utilização da ferramenta Cain, promovendo a
habilidade de realizar o ataque de homem-do-meio, capturando o tráfego VoIP.
64
Figura 42 - A ferramenta Cain realizando o ataque de homem-do-meio
3.2.4 Message Tampering
O ataque de Message Tampering ou adulteração de mensagens
ocorre quando o atacante intercepta e modifica pacotes trocados entre
componentes SIP. Este ataque pode acontecer através de Registration Hijacking,
Proxy Impersonation, ou ataque a um componente SIP com direitos de processar
mensagens, tais como proxy, media gateway, ou firewall. A figura 43 ilustra o
message tampering.
Figura 43 - Ataque de Message Tampering
As mensagens SIP não têm nenhum meio embutido para assegurar a
integridade. Manipulando estas mensagens, um atacante pode executar os mesmos
tipos de ataques descritos para Registration Hijacking e Proxy Impersonation.
65
3.2.5 Session Tear Down
Session tear down ocorre quando o atacante observa a sinalização da
chamada, e então envia um falso SIP BYE ou um re-INVITE para os UAs
participantes. A maioria dos UAs, não requerem uma forma de autenticação forte, o
que permite ao atacante enviar o SIP “BYE” para encerrar a chamada, ou um reINVITE para altera-la. A figura 44 ilustra o Session Tear Down.
Figura 44 - Ataque de session tear down
Se um UA não confere a validade do pacote, o atacante nem mesmo
necessita de observar a sinalização da chamada. Se o atacante conhece o
endereço de um UA continuamente ativo, como o Media Gateway, ele pode fazer
com que estes UAs ativos enviem as mensagens de do tipo “BYE” causando a
finalização das chamadas. Um outro exemplo de tear down, é praticar um ataque de
flooding no firewall, inundando este com mensagens SIP “BYE”, fazendo com que
sejam derrubadas as portas UDP abertas por chamadas legítimas. O DoS é o efeito
primário do session tear down. O SIP re-INVITE, utilizado para modificar a mídia, se
direcionados a endereços de broadcast pode também causar o DoS.
66
3.2.6 Denial of Service
Denial of Service (DoS), ou Negação de serviço, pode ocorrer por
quaisquer meios descritos nos outros ataques, ou por um ataque de DoS especifico.
Por ser raramente usada uma autenticação forte, componentes SIP podem
processar mensagens de atacantes. Pesquisas demonstraram que muitas
implementações do SIP são altamente vulneráveis a este tipo de ataque. O DoS
pode ser especialmente prejudicial se o alvo for um recurso chave do sistema como
o Media Gateway, podendo, por exemplo gerar um enorme número de chamadas
para serviços de informação, polícia, bombeiros, etc, ou ainda utilizar de uma rede
para lançar ataques a outra empresa.
3.3 Ataques utilizando de Mensagens SIP
Certos ataques à arquitetura SIP podem ser evitados utilizando-se um
esquema de autenticação apropriado. Porém mesmo com a autenticação aplicada,
alguns ataques ainda são possíveis. Nesta sessão serão apresentados ataques a
arquitetura, utilizando mensagens SIP, tanto em ambientes sem autenticação
aplicada, quanto em ambientes que fazem uso da autenticação.
3.3.1 Ataques a sistemas sem a autenticação aplicada
3.3.1.1
Ataque de DoS utilizando mensagens de REGISTER SIP
Dagiuklas (2005) explica que um atacante pode remover o registro de
todos os contatos existentes para uma URI, e registrar-se no lugar dos contatos
válidos, fazendo com que todas as mensagens destinadas a estes usuários sejam
direcionadas ao seu dispositivo. Além disso, é possível lançar um ataque de DoS
67
modificando uma requisição de registro que contenha mais de um endereço de
contato e que utilize valores “q” para classificar a prioridade correspondente a estes
endereços. Se este campo for alterado para o valor 0 (zero), é possível que o
usuário não receba mensagens de SIP INVITE. O mesmo ocorre para o valor do
campo Expire, ilustrado na figura 45, a modificação maliciosa deste valor para 0
(zero), indica a remoção do registro do usuário. Além disso, o atacante pode não
somente modificar os valores “q”, mas também adicionar seu endereço, fazendo
com que este receba todas as mensagens entrantes no sistema.
Figura 45 - Remoção do registro do usuário pelo atacante
3.3.1.2
Ataque de “Re-INVITE”
Uma vez iniciada uma sessão por uma mensagem inicial, mensagens
subseqüentes de requisições podem ser enviadas com o propósito de alterar o
status da sessão. Entretanto, modificações não-autorizadas da sessão através de
re-INVITE forjados por um potencial atacante, podem causar o DoS. A figura 46
ilustra o fluxo do ataque.
68
Figura 46 - Fluxo do Ataque de re-INVITE
3.3.1.3
Ataque de “BYE”
O objetivo do ataque de BYE é encerrar uma sessão já estabelecida.
Para que seja possível a execução deste ataque é necessário que o atacante
conheça os parâmetros da sessão tais como: Session-ID, RTP Port, etc. Para isto, o
atacante realiza um sniffing da rede, ou realiza um ataque de man-in-the-midlle. O
sucesso deste ataque depende da falta de mecanismos de autenticação
apropriados, e é claro, da capacidade do atacante de descobrir os parâmetros da
sessão. A figura 47 ilustra o fluxo do ataque de BYE.
69
Figura 47 - Ataque de BYE
3.3.1.4
Ataque de “UPDATE”
O método de UPDATE SIP proporciona aos usuários finais as diversas
capacidades da sessão, como por exemplo, a identificação dos parâmetros de QoS
e a negociação para outros atributos da sessão. A diferença entre o re-INVITE e o
UPDATE no que diz respeito à negociação da sessão, e que o re-INVITE só pode
ser utilizado após o estabelecimento da sessão, enquanto que o método UPDATE
pode ser lançado antes da resposta para o convite inicial. Utilizando-se destas
funcionalidades, um atacante pode enviar mensagens de UPDATE forjadas para
modificar os parâmetros iniciais da sessão com o intuito de degradar a qualidade do
serviço, impedindo a comunicação entre participantes. A figura 48 ilustra o fluxo do
70
ataque de UPDATE.
Figura 48 - Fluxo do ataque de UPDADE
3.3.2 Ataques a sistemas com a autenticação aplicada (antes da autenticação)
Mesmo com a aplicação de serviços de autenticação, ameaças a
arquitetura não deixam de existir. Ataques como o de parsing, são lançados mesmo
antes da autenticação. Esta sessão descreve alguns ataques deste tipo.
71
3.3.2.1
•
Ataques de “Parser”
Complexidade da análise gramatical SIP
Uma mensagem SIP pode ser tanto uma requisição quanto um
reconhecimento a esta requisição, constituída de campos de cabeçalho e corpo,
baseadas em texto com um grande grau de “liberdade”. Sendo assim, uma analise
gramatical eficiente da mensagem é requerida para avaliar a estrutura da mesma
considerando apenas a informação necessária. Esta análise gramatical é conhecida
como parse. Entretanto, mesmo mensagens SIP válidas podem ser construídas
para impedir sua análise gramatical (parsing). De acordo com Dagiuklas (2005), um
atacante pode criar mensagens longas, com múltiplos cabeçalhos e com um
extenso corpo, pois todas as mensagens permitem a adição do corpo, mesmo que
este não seja necessário. Com isso, além de aumentar o processamento do agente,
as mensagens longas aumentam o tráfego da rede. Outro problema é a inclusão do
mesmo campo de cabeçalho, múltiplas vezes na mesma mensagem, onde estes
estão distribuídos, tornando complexa a análise gramatical. Além disso, alguns
campos de cabeçalho SIP permitem outros tipos de URIs, tal fato também prejudica
o processo de parsing. Mesmo que um analisador gramatical bem aprimorado
pudesse impedir o ataque de parsing, o processamento necessário para tal, poderia
dificultar a execução de outras tarefas, prejudicando o desempenho.
•
Mensagens SIP Mal-Formadas
Por sua codificação ASCII, o SIP torna-se mais atrativo para atacantes
do que seu “concorrente” da ITU o protocolo H.323, este com uma codificação mais
complexa. Atacantes podem fazer uso de qualquer método SIP, incluído suas
extensões para lançar um ataque utilizando mensagens mal formadas. A figura 49
apresenta uma mensagem SIP INVITE bem formada, conforme especificação na
RFC 3261. Porém, devido a erros de implementação, em certos casos, levando em
consideração a complexidade do analisador gramatical SIP, mesmo mensagens
bem formadas podem gerar falhas em servidores. Além de erros de implementação,
72
o atacante tentará diversas combinações de mensagens SIP mal formadas a fim de
descobrir possíveis falhas no sistema SIP da vitima. A figura 50 é uma mensagem
inválida, e não pode ser gerada pelo padrão de sintaxe do protocolo SIP.
Figura 49 - Mensagem SIP INVITE bem formada
73
Figura 50 - Mensagem SIP INVITE mal formada
Na figura 50, falta o REQUEST-URI, que deve seguir o método
INVITE. Segundo Dagiuklas (2005), quaisquer mensagens não conforme com as
especificações do protocolo SIP, podem causar falhas em sistemas que utilizam o
Session Initiation Protocol. E, além disso, é altamente complexa a distinção entre
mensagens legais e ilegais.
•
Montando o Ataque de Mensagens Mal Formadas
Dagiuklas (2005) diz que um atacante não possui um método padrão
para atacar, e de certo modo o procedimento para realizar este ataque é
imprevisível. Isto também, torna-se verdade para os ataques SIP utilizando
mensagens mal formadas. O atacante pode, por exemplo, utilizar o método de
força-bruta
e
tentar
exaustivamente
combinações
de
mensagens
SIP.
Alternativamente este atacante pode seguir procedimentos gerais, executando
passos algorítmicos repetidamente como:
74
1 – Descobrir as capacidades do alvo
2 – Construir a mensagem mal-formada
3 – Testar as possíveis combinações contra o alvo
A vantagem de tal tentativa, é que esta não pode ser facilmente
identificada nas suas primeiras fases, pois normalmente, mecanismos de defesa
não estão preparados para tal.
•
Descobrindo as capacidades do alvo
Antes de lançar o ataque, torna-se necessário descobrir as
capacidades de um sistema SIP particular. Mensagens de REGISTER e respostas
OPTIONS, são capazes de fornecer informações sobre qualquer capacidade de um
User Agent. Esta informação é incluída no cabeçalho Contact do REGISTER e no
cabeçalho Alow das respostas às requisições OPTIONS. Em todo caso, estas
mensagens podem ser utilizadas pelo atacante de duas diferentes formas.Na
primeira, o atacante pode simplesmente realizar um sniffing das requisições de
REGISTER no momento da sua realização. A outra forma, demonstrada no fluxo da
figura 51, é simplesmente utilizar a Mensagem de OPTIONS, enviando-a para
vitima, que em resposta, revela ao atacante as capacidades dos métodos e
mensagens implementadas em seu agente. Estas capacidades reveladas podem
ser, entre outras coisas, o fabricante e a versão implementada no produto da vítima,
expondo as vulnerabilidades existentes.
75
Figura 51 - Descobrindo as capacidades com a requisição OPTIONS
•
Construindo a Mensagem Mal Formada
O próximo passo é a construção da mensagem mal formada, a figura
50 ilustra um exemplo deste tipo de mensagem. A existência de aplicativos para
testes em sistemas SIP como o PROTOS, que é capaz de gerar diferentes tipos de
mensagens mal formadas, torna fácil esta tarefa. Além disso é provável que o
atacante envie mensagens não implementadas (invalidas ou fora do padrão) para
dispositivo da vitima, provocando uma eventual falha crítica. Mensagens de
REGISTER, BYE, CANCEL e outras, também podem ser empregadas no ataque.
3.3.2.2
Ataques de “REGISTER”
Conforme especificação na RFC 3261, a requisição de REGISTER,
pode adicionar ou remover registros de localizações, ou ainda criar associações
entre address-of-record e um ou mais endereços de contato. A figura 52 ilustra um
processo de registro onde o Register Server exige a autenticação para todas as
requisições de registro entrantes. Nesta figura, o usuário primeiramente tenta o
76
registro sem as credenciais, e não é autorizado pelo Register Server. O Servidor
envia ao User Agent uma resposta contendo a mensagem de não autorizado e um
número aleatório, que deve ser usado pelo UA para gerar a credencial.
Posteriormente o User Agent refaz a requisição de REGISTER, porém, com as
devidas credenciais, obtendo sucesso na sua ação.
Figura 52 - Fluxo normal de registro
Dagiuklas (2005), afirma que um atacante que pretende lançar um
ataque a um servidor Registrar, utilizando mensagens de REGISTER, possui uma
ou mais das seguintes metas:
1 – Descobrir a senha de um usuário legitimo.
2 – Causar um DoS no servidor.
3 – Remover o registro de um usuário legitimo.
A figura 53 ilustra o ataque contra um Registrar Server, onde o
atacante tenta adivinhar a senha do usuário legitimo, ou causar o DoS. Igualmente
o atacante pode tentar remover o registro do usuário, para isto basta fixar o valor do
campo Expires para zero. A execução distribuída deste ataque também é possível,
77
onde múltiplos atacantes tentam descobrir a senha do usuário legitimo.
Figura 53 - Ataque contra um Registrar Server
3.3.2.3
Ataques de “CANCEL”
A Requisição de CANCEL, é utilizada para encerrar o processamento
de um pedido prévio enviado por um cliente. Um atacante pode utilizar a mensagem
de CANCEL para interromper o processamento de um pedido INVITE, encaminhado
por um usuário legitimo, como demonstrado na figura 54. O CANCEL encerra
apenas requisições de INVITE, gerando uma mensagem apropriada de erro se for
enviada para o cancelamento de outro tipo de requisição. Além disso, pedidos de
78
cancelamento não são processados caso o INVITE inicial tenha obtido uma
resposta final.
Figura 54 - Ataque de CANCEL
3.3.2.4
Fraudes em Respostas SIP
Diversos tipos de ataque de DoS podem ser lançados se o atacante
utilizar as mensagens de resposta SIP. O atacante pode por exemplo, utilizar estas
mensagens
agindo
como
homem-no-meio
(man-in-the-middle),
ou
ainda
personificar um proxy, causando a negação de serviço às requisições SIP dos user
agents. A figura 55, resume algumas mensagens de erro utilizadas para lançar o
ataque de DoS.
79
Código Descrição
3xx
A resposta pode conter um ou mais campos Contact com endereços
onde o destinatário pode ser encontrado
300
Multiple Choices
301
Moved Permanently
302
Moved Temporarily
4xx
Respostas de falha do servidor
400
Bad Request
401
Unauthorized
403
Forbidden
405
Method Not Allowed
406
Not Acceptable
408
Request Timeout
413
Request Entity Too Large
414
Request-URI Too Long
415
Unsupported Media Type
420
Bad Extension
480
Temporarily Unavailable
404
Not Found
5xx
Falha no Servidor
503
Service Unavailable
504
Server Time-out
505
Version Not Supported
6xx
Falhas Globais
600
Busy Everywhere
606
Not Acceptable
Figura 55 - Códigos de erros comuns
3.3.3 Ataques a sistemas com a autenticação aplicada (após a autenticação)
A infra-estrutura VoIP, baseada no protocolo SIP, provê serviços
similares ao e-mail. Assim, muitos provedores de serviço, podem permitir o livre
registro, sem a checagem de credenciais. Isso facilita a ação dos atacantes, pois
estes podem registrar-se como usuários regulares, permitindo que os ataques
80
possam ser originados de “dentro” do sistema. Outra possibilidade para atacante
inserir-se na base de usuários regulares para realizar ataques, é assumir um SIP
Registrar, ou configurar um ou mais novos servidores, com usuários utilizados
apenas para ataques. A primeira possibilidade torna-se complicada se o Servidor
possuir mecanismos de segurança adicionais, a segunda opção é menos complexa.
Porém, a provedora do serviço, pode bloquear qualquer tipo de origem
desconhecida, assim estas possibilidades seriam descartadas. Mesmo existindo
grandes barreiras para o atacante conseguir uma base de usuários registrada e
lançar o ataque de dentro da rede, este ainda é possível. Estando dentro da rede, o
atacante tem grandes possibilidades de obter sucesso com o ataque.
3.3.3.1
Ataque de Força Bruta
Dentro da estrutura SIP, ataques de Bruta podem ser lançados através
de mensagens com o conteúdo não reconhecido, requisitando uma extensão
exótica ou contendo tipos desconhecidos no corpo da mensagem. A entidade SIP
tem que processar estas mensagens e responder com mensagens de erro,
consumindo os recursos de processamento. O atacante pode também modificar o
valor do campo Route que identifica o host alvo, e então enviar a mensagem forjada
para vários elementos da SIP da rede, na intenção de gerar um DoS flood traffic, ou
negação de serviço por inundação de tráfego. Outro exemplo é o ataque de Relay,
que pode ser lançado criando-se falsos pedidos, onde o IP de origem e o Valor do
campo Via são falsificados, identificando o alvo como real originador da requisição.
E então esta requisição, é enviada para um grande número de elementos da rede
como telefones SIP.
81
3.3.3.2
Unusable Destinations (Destinos Inúteis)
A adição maliciosa de endereços insolúveis ou não correspondentes
em mensagens SIP, forçam o proxy a repassar esta mensagem a um endereço que
não pode ser resolvido. Administradores dos servidores SIP, devem estar atentos
ao impacto das operações do servidor de DNS. As tentativas pelos UACs de
resolverem um grande fluxo de endereços insolúveis podem degradar o
desempenho do servidor, resultando no DoS. O proxy gera requisições continuas ao
DNS, na tentativa de resolver o nome inexistente. Normalmente o atacante produz
grandes quantidades de nomes insolúveis ou falsos INVITES. O objetivo do
atacante é sobrecarregar a rede com mensagens do DNS, provocando sérios
problemas ao serviço VoIP.
3.3.3.3
Ataques de “INVITE”
Dagiuklas (2005) explica que um elemento SIP torna-se mais
vulnerável se este necessitar de manter seu estado por certo período, como é o
caso do processo de INVITE. Um exemplo é quando um UAC precisa retransmitir
um INVITE, caso este não obtenha resposta até no máximo em 32s. Durante este
período, o UAC mantém seu estado de INVITE, necessitando manter este estado
para outros 32s após o encaminhamento das respostas de 3xx e 6xx. A figura 56
demonstra o fluxo de um ataque usando mensagens de INVITE, onde o atacante
constrói as mensagens sem receber nenhuma resposta, realizando um flooding de
INVITE. Como resultado final desta inundação de requisições tem-se o DoS.
82
Figura 56 - flooding de INVITE
83
4 MECANISMOS DE SEGURANÇA
Como a troca das mensagens SIP herdou o modelo de requisição e
resposta do HTTP, todos os mecanismos de segurança disponíveis para o HTTP
podem ser aplicados às sessões SIP. Por outro lado, a utilização de container MIME
dentro das mensagens SIP, sugere o potencial uso de mecanismos de segurança
de e-mail, como PGP ou S/MIME. E é claro, similar ao https: URI, o correspondente
sips: URI tentará construir um túnel seguro na camada de transporte usando TLS. E
não menos importante o IP Security (IPsec), que pode ser usado como mecanismo
de encriptação de toda comunicação baseada em IP na camada de rede. Os
principais mecanismos de segurança destinados ao SIP estão relacionados na
figura 57. Estes mecanismos coincidem com lista de recomendações de segurança
da versão 1 do SIP. Enquanto isto, dois dos métodos: HTTP basic Authentication, e
PGP foram descartados pela versão 2 do Session Initialization Protocol. Segundo a
RFC 3329, é definida uma nova funcionalidade de negociação para mecanismos de
segurança entre um agente usuário SIP e o próximo hop SIP. Esta funcionalidade
complementa outras já existentes para o SIP. São criados 3 novos campos de
cabeçalho SIP: Security-Client, Security-Server e Security Verify; e também definida
uma lista de mecanismos de segurança suportados:
“tls” para TLS
“digest” para http Digest
“ipsec-ike” para IPsec com IKE
“ipsec-man” para IPsec sem IKE.
4.1 HTTP Basic Authentication
HTTP basic authentication requer a transmissão do nome de usuário e
a senha embutida no cabeçalho do pedido HTTP. Incluído nos pedidos SIP, este
nome de usuário pode ser usado por um SIP proxy Server ou um User Agent para
autenticar um cliente SIP ou um "SIP hop", na cadeia de proxy. Sendo a senha um
84
texto puro, que pode ser facilmente capturada por um sniffer, torna-se um risco a
segurança, por isso o uso do HTTP basic authentication foi descartado na versão 2
PKI – Public key infraestructure
(infra-estrutura de chave pública)
Autenticação
PSK – Pre-shared keys
(chaves pre-definidas)
Confidencialidade
Métodos de autenticação:
Integridade dos dados
do SIP (SIPv2).
HTTP 1.0 Basic Authentication
PSK
-
-
HTTP 1.1 Digest Authentication
PSK
٧
٧
Pretty Good Privacy (PGP)
PKI
٧
٧
Secure MIME (S/MIME)
PKI
٧
٧
SIPS URI (TLS)
PKI
٧
٧
IP Security (IPsec)
PKI
٧
٧
Descrição
Desaconselhado
pelo
SIPv2 - insegurança na
transmissão da senha.
Hash da senha baseado
em no método MD5.
Desaconselhado
pelo
SIPv2.
Para encriptação a chave
pública do UA deve ser
conhecida.
Aplicações SIP e proxy
devem usar TLS.
Integração
com
a
aplicação SIP não é
requerida, mas proxies
devem ser confiáveis.
Figura 57 - Principais mecanismos de segurança para o SIP
4.2 HTTP Digest Authentication
O HTTP Digest Authentication corrige as deficiências do HTTP Basic
Authentication, transmitindo um hash MD5 ou SHA-1 da senha secreta e de uma
string aleatória, no lugar onde iria apenas a senha vulnerável. Apesar de este
método garantir a identidade do usuário sem a necessidade da transmissão da
senha pura, o procedimento ainda pode ser vulnerável a ataques de dicionário,
baseados em valores hash interceptados, sendo facilitado se as senhas utilizadas
forem fracas. Outra grande desvantagem, e a falta de um mecanismo para prover a
confidencialidade, e alem disso, esta técnica não garante a integridade das
mensagens SIP. As figuras 58 e 59 mostram como uma requisição SIP INVITE
85
originada do usuário “Alice” é autenticada pelo proxy usando o HTTP Digest
Authentication.
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:[email protected]>;tag=3b6c2a3f
From: Alice <sip:[email protected]>;tag=daa21162
Call-ID: [email protected]
CSeq: 1 INVITE
Proxy-Authenticate: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch"
Content-Length: 0
Figura 58 - Confirmação do INVITE pelo proxy
O primeiro proxy recebe o SIP INVITE de Alice e imediatamente
responde com uma confirmação, mostrada na figura 58. A confirmação contém um
nonce aleatório e define o algoritimo hash a ser utilizado, (geralmente MD5 ou SHA1), bem como o domínio o qual o usuário deve fornecer a autenticação. Assim que
recebe a confirmação, Alice reenvia o INVITE original, porém insere no cabeçalho
da resposta a confirmação, como mostrado na figura 59.
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=daa21162
Call-ID: [email protected]
CSeq: 2 INVITE
Proxy-Authorization: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch",
response="142311a910a4d57ba49afdbe5646768c",
uri="sip:[email protected]",
username="alice"
Max-Forwards: 70
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 239
Figura 59 - INVITE original com a confirmação
O valor da resposta consiste na compilação MD5 do nome do usuário,
da senha secreta, do valor contido no nonce, do método SIP e do URI requisitado.
Assim a senha clara não é transmitida, mas deve ser conhecida pelo servidor proxy
afim de poder verificar a autenticação.
86
4.3 Pretty Good Privacy (PGP)
O
PGP
pode
ser
potencialmente
usado
para
autenticar
e
opcionalmente, encriptar MIME payloads, contidos nas mensagens SIP. Porém a
versão 2 do SIP desaprova o uso do PGP em favor do S/MIME.
4.4 Secure MIME (S/MIME)
Mensagens SIP carregam estruturas MIME, e padrões MIME incluem
mecanismos para segurança de seu conteúdo, assegurando tanto a integridade
quanto a confidencialidade. O objetivo do S/MIME é a interoperabilidade de
mensagens seguras, obtida pela criptografia e assinatura digital. A segurança é
fornecida apenas no cliente S/MIME, os servidores não precisam ser modificados. O
S/MIME é o resultado da integração de três padrões já estabelecidos:
• MIME - Multi-purpose Internet Mail Extension, especificado na RFC 1521;
• Criptographic Message Syntax Standard (PKCS#7);
• Certification Request Syntax Standard (PKCS#10).
O S/MIME aceita os tipos de conteúdo PKCS#7 listados na Figura 60.
Nota: Todas as funções de criptografia exigem que o cliente/servidor tenham, pelo
menos, um certificado válido.
Tipo de Conteúdo
Dados
Descrição
Conteúdo trabalhado com algum tipo de segurança
Uma mensagem MIME assinada digitalmente, um
Dados Assinados
certificado ou uma informação de revogação (CRL)
Mensagem MIME assinada e criptografada. Requer
Dados Assinados e
acesso a chave pública da entidade de origem
Envelopados
Mensagem MIME criptografada. Requer acesso a
Dados Envelopados
chave pública da entidade de origem
Figura 60 - Tipos de Conteúdo S/MIME
O S/MIME aceita os seguintes algoritmos de criptografia, modos e
tamanhos de chave:
• Triple DES, modo CBC com chave de 168 bits;
• RC2, modo CBC com chave de 128 bits;
87
• DES, modo CBC com chave de 56 bits;
• RC2, modo CBC com chave de 64 bits;
• RC2, modo CBC com chave de 40 bits.
O S/MIME também é compatível com os seguintes algoritmos de hash:
• MD5
• SHA-1
Os retardos introduzidos pelos processos de segurança não são
significativos. Uma mensagem assinada requer apenas que a entidade de origem
tenha um certificado válido. A entidade de destino recebe o certificado da origem
como parte da mensagem e, se implementar o S/MIME, utiliza a chave pública para
reconhecer a assinatura. O certificado é armazenado no receptor para possibilitar a
privacidade (criptografia) das próximas mensagens. O processo de privacidade e
integridade de mensagens obedece aos seguintes passos na entidade de origem:
1. Calcular uma amostra (hash) do conteúdo da mensagem
2. Criptografar o hash com a sua chave privada para criar uma
assinatura digital
3. Criptografar o conteúdo da mensagem e a assinatura digital com uma
chave simétrica randômica
4. Criptografar a chave simétrica com a chave pública da entidade de
destino
5. Remeter o resultado dos passos 3 e 4 usando um meio de transporte
A entidade receptora deve executar os seguintes procedimentos:
1. Receber a mensagem utilizando um meio de transporte tradicional.
2. Decriptar, com a chave simétrica, o conteúdo da mensagem e a
assinatura digital
3. Decriptar o hash recebido usando a chave pública do remetente
4. Validar a assinatura digital calculando o hash da mensagem e
comparando com recebido
88
5. Validar o certificado do remetente
Se a entidade de origem utilizou um certificado incorreto, a mensagem
não pode ser recuperada pelo destino.
4.5 SIPS URI (TLS)
O TLS (Transport Layer Security), definido pela RFC 2246, prove uma
camada de transporte seguro sobre TCP. O uso de URI SIP sobre a forma de
sips:bob.biloxy.com em uma mensagem de INVITE, requer o uso de TLS em todo o
caminho ate o destino. Desde que cada hop possa adicionar informações de rota ao
cabeçalho da mensagem SIP, a proteção TLS deve ser realizada hop-by-hop (em
cada salto) do caminho. O uso do TLS requer o TCP como o protocolo de transporte
(TCP/SIP) e necessita de uma infra-estrutura de chave pública. A figura 61 ilustra a
negociação com um servidor TLS.
Figura 61 - Negociação com servidor TLS
89
4.6 IP Security (IPsec)
O IPsec é um mecanismo de propósito geral que pode ser usado para
proteger mensagens SIP na camada de rede. Devido à exigência de que cada
servidor proxy deve ter acesso de leitura e escrita ao cabeçalho SIP, IPsec ESP
(Encapsulating Security Payload) ou AH (Authentication Header) no modo de
transporte, deve ser aplicado hop-by-hop (em cada salto). O protocolo Internet Key
Exchange (IKE), suporta tanto autenticações baseadas em Pre-Shared Key (PSK)
quanto Public Key (PKI). Pelo fato dos endereços IPs dos SIP UAs serem
principalmente dinâmicos, e levando-se em conta de que o modo principal IKE
neste caso não trabalha com chaves Pre-Shared e o modo agressivo IKE possui
problemas de segurança que possibilitam a ataques como: man-in-the-middle e offline dictionary sobre PSK, a autenticação baseada em chave pública deve ser o
método utilizado, isto significa que o estabelecimento da confiança global no
certificado X.509 torna-se problemático.
4.7 Segurança sobre protocolos de transporte em tempo real
O Fluxo de pacotes multimídia é transportado utilizando o protocolo de
transporte em tempo real RTP (Real Time Transport Protocol) baseado em UDP.
Para que possa haver alguma avaliação em relação à qualidade do fluxo de pacote
recebido, periodicamente é enviado de volta um relatório usando o RTCP (RealTime Control Protocol). Sendo a conexão de áudio e o vídeo em tempo real muito
sensível a atrasos e variações deste atraso (jitter), qualquer algoritmo de
encriptação e autenticação não devem influenciar significativamente estes
parâmetros. Devido a tais restrições, o pré-requisito fundado para transmissões em
tempo real é que esta seja sobre UDP. Apenas dois mecanismos de segurança,
listados na figura 62, estão atualmente disponíveis.
PKI – Public key infraestructure
(infra-estrutura de chave pública)
Autenticação
PSK – Pre-shared keys
(chaves pre-definidas)
Confidencialidade
Métodos de autenticação:
Integridade dos dados
90
Descrição
As
chaves
de
usuários devem ser
Secure RTP (SRTP)
PSK
٧
٧ distribuídas
por
outros meios.
Integração com o SIP
não é requerida, mas
IP Security (IPsec)
PKI
٧
٧ o peer deve ser
confiável.
Figura 62 - Solução para segurança Real-Time Media Streams
4.7.1 Secure RTP (SRTP)
O SRTP (Secure Real-time Transport Protocol), é uma extensão do
RTP, e disponibiliza confidencialidade, autenticação da mensagem e proteção
contra replay de tráfego RTP e RTCP. O uso da criptografia AES cipher, sendo
executada em modo de cifra de fluxo (stream cipher mode), garante uma forte
segurança e não incrementa o tamanho do pacote encriptado. A tag de
autenticação, adiciona 10 bytes para cada pacote RTP/RTCP, mas pode ser
reduzido para 4 bytes, se a banda utilizada para comunicação for estreita.
4.7.2 IP Security (IPsec)
Como uma alternativa, os real-time payloads, podem ser protegidos na
camada de rede pelo IPsec, usando a mesma associação de segurança já
negociada para proteger as mensagens SIP entre os UAs. Uma grande
desvantagem desta técnica é o grande overhead introduzido pela encapsulação
ESP, podendo chegar a 37bytes por pacote IPsec para a encriptação 3DES,
aumentando para 53 bytes se a encriptação for a AES.
91
5 CONCLUSÕES
Este capítulo trata das conclusões obtidas a partir da pesquisa
realizada, e finalmente oferece propostas e sugestões de trabalhos futuros que
transpareceram-se no decorrer do desenvolvimento deste documento.
5.1 Considerações Finais
A pesquisa realizada demonstrou a importância do protocolo SIP no
cenário atual das comunicações mundiais, em especial a sua utilização no serviço
de VoIP, bem como os desafios a serem superados no que diz respeito a segurança
em sistemas que fazem uso do protocolo SIP. Neste trabalho faz-se uma
abordagem
das
vulnerabilidades
existentes
em
implementações
do
SIP,
vulnerabilidades estas, que coloca em risco os sistemas de comunicação baseados
neste protocolo.
Foi demonstrado o funcionamento do SIP, enfatizando o fluxo de
mensagens da sua sinalização, detalhando com exemplos, seus vários métodos de
requisições e respectivas respostas. Alem disso, demonstrou-se a arquitetura SIP, e
o papel desempenhado por cada componente dentro desta arquitetura.
Abordou-se, também, algumas diferenças entre o SIP e o H.323, um
outro protocolo utilizado para sinalização, que aos poucos cede espaço para o
Session Initiation Protocol.
O Capitulo 3 detalha as vulnerabilidades do SIP, falhas que
comprometem a continuidade do negócio, afetando os pilares da segurança. Neste
capítulo é exemplificado alguns dos possíveis ataques a componentes da
arquitetura, e seus resultados.
Por fim, são mencionados alguns métodos utilizados para promover a
segurança no protocolo SIP.
Estima-se um grande investimento e crescimento na convergência
92
para a tecnologia de VoIP, devido as suas grandes vantagens, a principal no que
diz respeito a economia. Porém mais do que a significativa redução dos custos é
interessante discutir a questão da segurança da informação, e assim confirmar a
grande tendência: a maturidade da Voz sobre IP.
Em geral a opção pelo serviço de VoIP, são focadas em fatores
ligados a economia e eficiência, como disponibilidade, latência e QoS,
negligenciando a proteção do sistema.
No centro desta convergência encontra se o protocolo SIP,
responsável por gerir as sessões multimídias, como a de VoIP.O SIP, um protocolo
emergente, de arquitetura simples, aberta, e que aos poucos torna-se maduro o
suficiente para atrair as atenções e afirmar-se como o protocolo padrão das
comunicações mundiais. Porem, por basear-se em redes IP, o SIP herda destas
suas já exploradas vulnerabilidades e também, expõem novas específicas de sua
arquitetura. A divulgação, documentação e estudo destas vulnerabilidades torna-se
importante para evolução dos métodos de segurança aplicados a esta nova
tendência das comunicações.
Enfim, toda nova aplicação exige uma fase cuidadosa de análise de
riscos, qualquer tecnologia adicionada, traz novas vulnerabilidades além dos
benefícios. É essencial tornar a segurança um dos pré-requisitos para as adoção
de qualquer tecnologia, e não fazer da segurança, um empecilho para evolução de
tais avanços.
5.2 Propostas para Trabalhos Futuros
• Implementação e teste de uma tecnologia ou metodologia para garantir a
segurança ou reduzir os riscos de ataques a sistemas que utilizam
sinalizações do protocolo SIP.
• Criação de um documento de implementação de um PBX IP baseado no
software livre ASTERISK.
93
• Implementação de segurança em PBX IP ASTERISK.
• Continuidade do documento produzido, demonstrando novas vulnerabilidades
ataques a arquitetura SIP.
94
6 REFRÊNCIAS BIBLIOGRÁFICAS
CAMARILLO, Gonzalo. SIP Demytified. Finlândia: McGraw-Hill Inc, 2001. 320 p.
CHECK POINT SOFTWARE AND TECHNOLOGIES. Security IP Telephony For The
Enterprise, 2004, 17 p.
CIO REVISTA. Disque VoIP para Vulnerabilidades, 2004. Disponível em:
http://ciomagazine.uol.com.br/revista/2006/01/30/idgnoticia.2006-0130.1195711369/IDGNoticia_view. Acesso em: 23 abr. 2006.
COLCHER, Sergio. et al. VOIP: Voz Sobre IP. 1.ed. Rio de Janeiro: Campus, 2005.
300p.
COOLIER, Mark. Basic Vulnerabilities Issues for SIP Security. San Antonio, Texas,
Secure Logix Corporation, 2005. 9 p. Apostila.
DAGIUKLAS, Tasos. et al. Low Cost Tools for Secure and Highly Available VoIP
Communication Services. SNOCER (2005) 74p.
DAVID, João P.; PEREIRA, Silva G. Voz Sobre IP. Lisboa, Universidade de Lisboa,
2005, 136p.
DHAMANKAR, Rohit. Intrusion Prevention: The Future of VoIP Security. Tipping
Point Technologies (2004), 12p.
HERSENT, Oliver; GURLE, David; PETIT, Jean-Pierre. Telefonia IP:
Comunicação,multimídia baseada em pacotes. São Paulo: Makron Books, 2001. 451
p.
HOCHMUTH, Phil. SIP weakness could expose VoIP gear to attacks, 2003,
Disponível em: http://www.networkworld.com/news/2003/0224sip.html?page=1.
Acesso em: 31 jul. 2006.
JOHNSTON, Alan B. SIP: Understanding the Session Initiation Protocol. 2.ed. s.l.:
Artech House, 2003, 283p.
LAZARINI, Otávio. (2006) SIP Ganhando Força. In ALICE RAMOS.COM, 2006,
Disponível em: http://www.aliceramos.com/view.asp?materia=995. Acesso em: 23
abr. 2006.
STEVENS, David. Ataque hacker de telefonia cresce na Austrália, 2005, Disponível
em:
http://worldtelecom.uol.com.br/AdPortalv5/adCmsDocumentShow.aspx?GUID=EC5A
D31B-1038-4FAC-A356-260F4844F2A3&ChannelID=4. Acesso em:31 jul. 2006.
TAKAKEN, Ari. Ameaças, Vulnerabilidades e Ataques na Voice over IP. In: IP VOICE
MEETING, 2006, Lisboa. : IP VOICE MEETING 2006: Disponível em:
http://www.ipvoice2006.com/. Acesso em: 15 abr. 2006.
95
YOSHIOKA, Sergio. Aspectos de Segurança para Telefonia IP utilizando o Protocolo
SIP. Campinas: UNICAMP, 2003, 75p.