VII SRST SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES INSTITUTO NACIONAL DE TELECOMUNICAÇÕES INATEL ISSN 2358-1913 SETEMBRO DE 2017 Abordagem de segurança em VoIP - SIP Márcio de Salles Paiva Junior 1, Mário Ferreira Silva Júnior 2 Abstract This article contains an introduction to VoIP technology and its different implementations in terms of employed protocols, of which SIP (Session Initiation Protocol), SDP (Session Description Protocol) and RTP (Real-time Transport Protocol) are overviewed due to their high usage rate. Security and privacy approaches for VoIP are also presented with some possible security measures. Index Terms SIP authentication, SIPS, SRTP, VoIP security. Resumo Este artigo faz uma introdução à tecnologia VoIP e suas diferentes implantações possíveis em termos de protocolos, entre os quais SIP (Session Initiation Protocol), SDP (Session Description Protocol) e RTP (Real-time Transport Protocol) são destacados devido a maior utilização dos mesmos. É apresentada uma abordagem de segurança e privacidade nessas redes, listando algumas ameaças e medidas de segurança. Palavras chave Autenticação SIP, Segurança VoIP, SIPS, SRTP. I. INTRODUÇÃO A tecnologia VoIP (Voice Over Internet Protocol ou Voz sobre Internet Protocol) consiste na comunicação de voz através de redes baseadas em protocolo IP ou redes heterogêneas de comutação de pacotes como a Internet. O VoIP foi e vem sendo cada vez mais adotado nas organizações em detrimento à telefonia tradicional principalmente devido ao fato da convergência das redes de dados e voz possibilitarem a diminuição de despesas operacionais e em bens de capitais, já que uma infraestrutura comum de rede pode ser utilizada para serviços de voz, dados e vídeo [1]. A Telefonia IP, termo utilizado para a transmissão de voz em tempo real utilizando rede de pacotes, baseia-se nos mesmos princípios utilizados na telefonia convencional, onde protocolos de controle e sinalização são empregados para estabelecimento e controle de chamadas [2]. Para que seja possível a transmissão de voz através da rede IP, é necessário o uso de técnicas de codificação para conversão analógicadigital do sinal de voz e sua posterior segmentação em pacotes. Entre os principais protocolos padronizados para controle e sinalização em VoIP podemos destacar os protocolos da recomendação H.323 (Packet-based multimídia Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações. Orientador: Prof. Mário Ferreira Silva Júnior. Trabalho aprovado em 09/2017. communication system), o protocolo SIP (Session Initiation Protocol) e o IAX (Inter-Asterisk-Exchange Protocol) [1] [3]. A recomendação H.323 é um padrão definido pela União Internacional das Telecomunicações (ITU International Telecommunication Union), inicialmente estabelecida em 1996, a princípio foi amplamente difundida nas redes de telefonia IP [1] [3]. Os sistemas baseados em H.323 proveem suporte a sistemas audiovisuais e multimídia utilizando protocolos de transporte em tempo real como o RTP (Real Time Transport Protocol) e RTCP (Real Time Control Protocol), além da autenticação do usuário e controle de tarifação [1]. Embora reconhecido por características como confiabilidade e robustez, o H.323 também foi considerado complexo e de difícil entendimento e implantação, já que a composição de sua estrutura envolve uma cadeia de outros protocolos [1]. Esse foi um dos motivadores da busca por novas soluções que resultou no desenvolvimento do protocolo SIP, que vem sendo adotado em substituição ao H.323 em muitos casos. O SIP foi a proposta do IETF (Internet Engineering Task Force) [1] como alternativa ao H.323, desenvolvida pela visão de um órgão formado por pessoas físicas, universidades e corporações que contribuem voluntariamente para o desenvolvimento de protocolos que são utilizados Internet. É um protocolo da camada de aplicação do TCP/IP (Transmission Control Protocol / Internet Protocol), ou sessão do modelo OSI (Open System Interconnection), e assim como o H.323 proporciona mecanismos de gerenciamento e controle de sessões de mídia, sendo estas compostas por áudio, vídeo e dados [1] [4]. Para que essa mídia seja transportada, é necessário o uso de protocolos de camada de transporte como o UDP (User Datagram Protocol), ou TCP [1] [2] [5]. Ainda na camada de aplicação, esta mídia utiliza de serviços dos protocolos RTP e RTCP [2]. O IAX é um protocolo desenvolvido pela empresa Digium, que tem como proposta ligar dois ou mais servidores que utilizem o software de código aberto de telefonia IP Asterisk ou outros projetos com código aberto, além de uso em telefones VoIP [3]. Ele tem muitas semelhanças com o SIP, porém, utiliza uma única porta (4569) para sinalização e fluxo de mídia, tornando-o vantajoso em cenários de firewall e NAT (Network Address Translation) [3]. Atualmente o SIP é o protocolo mais implantado nas redes VoIP entre os três citados, por isso, será o protocolo explorado nesse artigo em termos de segurança e privacidade [4].
O restante deste artigo está organizado da seguinte forma: a Seção II apresenta os protocolos da arquitetura VoIP utilizados em conjunto com o SIP; a Seção III aborda ameaças e possíveis soluções de segurança e a Seção IV apresenta as conclusões desse trabalho. II. PROTOCOLOS VOIP UTILIZADOS COM O SIP A. SIP Session Initiation Protocol Já brevemente abordado, o protocolo SIP é utilizado para início, término e controle de sessões de mídia, não importando o tipo de mídia que trafegará durante a mesma, isto é, funciona como um mecanismo de propósito geral para iniciar qualquer tipo de sessão, como por exemplo VoIP, sessões multimídia, mensagem instantânea, jogos, comunicação máquina para máquina, e outros. Pode-se definir sessão como o processo realizado entre duas ou mais partes com o objetivo de acordar previamente as regras e parâmetros que serão utilizadas durante a troca de informações entre as mesmas. A sessão será finalizada após a conclusão da troca de informações entre as partes. O protocolo SIP é baseado em texto, com funcionamento semelhante ao HTTP (Hyper Text Protocol), tornando relativamente simples a análise de sua estrutura [5]. Ele define através de URIs (Uniform Resource Identifiers) os números ou identidades para a realização de chamadas, como por exemplo sip: usuário@operadora.com.br. As mensagens são compostas por um cabeçalho e podem ou não apresentar um ou mais corpos de mensagem. Está localizado na camada de sessão do modelo OSI ou camada de aplicação do TCP/IP, permitindo com que diferentes protocolos sejam utilizados para transportá-lo nas camadas de Transporte, Rede e Enlace. O suporte a UDP e TCP é mandatório em qualquer terminal que suporte SIP, outros protocolos de transporte são opcionais. A Figura 1 ilustra uma pilha de protocolos, incluindo aqueles que podem ser utilizados com SIP [2]. Fig. 1. Pilha de Protocolos Multimídia. SIP é um protocolo modular extensível. Seu comportamento básico é definido pela RFC 3261 [3] [6] [7] mas diferentes extensões podem ser aplicadas, as quais estão documentadas em outras RFCs e podem definir métodos adicionais, cabeçalhos, procedimentos, entre outros. A arquitetura do protocolo é do tipo orientada a cliente-servidor onde um cliente envia solicitações para um servidor que responde com uma ou mais respostas [1]. Cinco funcionalidades básicas são oferecidas por SIP, e elas habilitam outros sistemas a fornecer diferentes tipos de serviço. As funcionalidades são: - Localização de usuário; - Verificação da disponibilidade de usuário; - Descoberta das capacidades ou recursos de um usuário; - Estabelecimento de parâmetros de uma sessão; - Gerenciamento de uma sessão. As principais entidades lógicas ou componentes SIP são descritas a seguir [1] [2] [3]. - Agente de Usuário ou User Agent (UA): Um endpoint que pode ser um UAC (User Agent Client), agente que envia as solicitações e recebe respostas, ou um UAS (User Agent Server) que recebe as solicitações e envia respostas. Quando um agente realiza ambas as funções, pode-se referir ao mesmo apenas como UA ou um Back to Back User Agent (B2BUA). - SIP Registrar: Um tipo especial de UAS que aceita apenas solicitações de registro (método REGISTER) e mantém um banco de dados com associações entre o nome do usuário (URI) ou endereço de registro (AOR Address of Register) e seu endereço (ex. IP). Essas associações são chamadas de bindings e podem existir mais de uma para um mesmo usuário. Realiza também a autenticação do usuário através de credenciais para evitar registros indevidos. - Proxy Server: Entidade intermediária responsável por receber as requisições SIP, funcionando como um proxy e encaminhando ao elemento de destino, atuando como UAC e UAS. Esse tipo de servidor nunca irá formular as mensagens de requisição ou solicitação, com exceção de mensagens que utilizem método CANCEL. Trafega apenas mensagens de controle, não trafega mídia, e pode incorporar outras funções como tarifação e autenticação. - Redirect Server: Um UAS que recebe solicitações e as redireciona para outros servidores através de respostas de classe SIP 3xx. Este tipo de resposta ocorrerá para informar ao chamador quando um usuário chamado não se encontra mais localizado no mesmo domínio do usuário de origem. Esta função pode ser implementada para que o próprio proxy encaminhe as requisições a um proxy onde se localiza o usuário de destino. Com relação as suas mensagens, SIP trabalha com conceito de Requisições (também conhecida por Métodos ou Requests) e Respostas (Responses). Essas mensagens normalmente contêm em seu corpo descrições da sessão, comandos ou sinalização. Elas possuem campos de cabeçalho obrigatórios e opcionais, os quais podem ser suplementados ou estendidos para atender e atualizar as novas demandas e tecnologias. Seis métodos básicos são previstos na RFC 3261 [1] [2] [3] [5]: INVITE: Solicita início de sessão. ACK: Confirmações de recebimento de respostas definitivas recebidas em resposta a um INVITE. OPTIONS: Consulta de recursos ou capacidades.
REGISTER: Informações de localização, associando um SIP URI a um endereço (binding). CANCEL: Cancelamento de solicitações pendentes. BYE: Abandono ou encerramento de sessão. Métodos de extensão adicionais foram criados para suportar serviços presentes em redes de telefonia fixa ou móvel, como os exemplos a seguir [3]. PRACK: Previsto na RFC 3262, confirma respostas provisórias, ou seja, as não definitivas. INFO: Previsto na RFC 6086, permite transporte de sinalização outband durante a sessão (interface com redes de telefonia tradicionais). SUBSCRIBE: Prevista na RFC 3265, realiza inscrição em algum evento de notificações. NOTIFY: Realiza notificação de eventos ao cliente após o mesmo se inscrever através do SUBSCRIBE. Também previsto na RFC 3265. UPDATE: Altera parâmetros de uma sessão já estabelecida (RFC 3311). MESSAGE: Envio de mensagens instantâneas (RFC 3428). REFER: Permite transferência de chamadas (RFC 3515). PUBLISH: Permite que um agente informe o estado de um evento a um elemento específico (RFC 3903). No que diz respeito às respostas SIP, existem seis classes de respostas possíveis, as quais podem ser classificadas como definitivas ou provisórias, sendo que as definitivas podem ser dividas em sucesso, falha ou redirecionamento [3]. 100-199: Respostas informativas (provisória). 200-299: Respostas de sucesso (definitivas ou finais). 300-399: Respostas de redirecionamento (definitiva). 400-499: Respostas de falha na requisição do cliente (definitiva). 500-599: Respostas de falha de servidor (definitiva). 600-699: Respostas de falha global (definitiva). A Figura 2 apresenta algumas respostas SIP e suas classes [2]. Fig. 2. Respostas SIP e suas classes. Algumas respostas pertencentes a estas classes são detalhadas a seguir [2]. - 100 Trying: Enviada pelo proxy, indica que a requisição foi recebida e está em processamento. - 180 Ringing: Gerada pelo elemento de destino ao receber uma solicitação INVITE, indicando que o usuário está sendo notificado. - 181 Call is being forwarded: Mensagem opcional, indica que a chamada está sendo redirecionada para outro agente (UA) de destino. - 182 Queued: Mensagem opcional, indica que o destino está em outra sessão e a solicitação de chamada está na fila. - 183 Session Progress: Mensagem opcional, utilizada para enviar informação de mídia do usuário de destino sem que a sessão tenha sido estabelecida. - 200 OK: Indica que a solicitação foi processada e bemsucedida. - 300 Multiple Choices: Lista múltiplos URIs onde o usuário de destino pode ser encontrado. - 301 Moved Permanently: Envia a nova URI do usuário de destino que deverá ser utilizada de forma permanente pelo chamador. - 302 Moved Temporarily: Indica ao usuário chamador uma nova URI do usuário de destino, que deverá ser usado de forma temporária, mantendo a URI original para futuras chamadas. - 305 Use Proxy: Lista um endereço de Proxy de destino que deverá ser utilizado no envio da nova solicitação. - 400 Bad Request: A requisição não pode ser processada por falha na sintaxe da mensagem. - 401 Unauthorized: A requisição não foi autorizada, pois requer autenticação prévia. - 403 Forbidden: Servidor recebeu a requisição, mas ela foi recusada, por exemplo, por problema de autenticação. - 404 Not Found: Usuário de destino não existe no domínio. - 407 Proxy Authentication required: O usuário de origem deve se autenticar no Proxy para poder realizar essa requisição. - 415 Unsupported Media Type: O corpo da mensagem de requisição contém informações de mídia que não são suportadas pelo destino. - 480 Temporarily Unavailable: O UA de destino foi encontrado, mas não deseja participar de sessões no momento. - 486 Busy Here: O UA de destino está em outra sessão e não suporta serviço de chamada em espera. - 487 Request Terminated: A requisição foi encerrada por uma ação de usuário ou aplicação, por exemplo, por uma solicitação CANCEL. A Figura 3 ilustra um exemplo de estabelecimento de uma sessão SIP. André (UAC) quer iniciar uma sessão com Guilherme (UAS). Embora conheça a identidade do destinatário (por ex: sip:guilherme@santos.com), André não necessariamente conhece seu endereço IP. Desta forma, é necessário a existência de um servidor SIP Proxy em seu domínio, responsável por determinar para qual domínio sua requisição está endereçada, encaminhando-a ao SIP proxy no domínio de destino que finalmente a entrega ao UAS. Guilherme responde a solicitação e inicia a sessão. A troca de mídia ocorre normalmente (através de protocolo RTP) até que
uma das partes decida encerrar a sessão, nesse caso diretamente, sem passar pelo proxy (embora seja mais comum que o proxy acompanhe a chamada até o final) [7]. Fig. 3. Estabelecimento de sessão SIP. B. SDP Session Description Protocol Descrito na RFC 2327, SDP é um dos protocolos que pode ser encapsulado pelo protocolo SIP em seu corpo, sendo comumente utilizado ao iniciar sessões. O SIP mandatoriamente deve suportar o SDP, ainda que possa encapsular outros protocolos no corpo de suas mensagens [3] [4]. A função deste é transmitir informações sobre os parâmetros que um determinado usuário deseja utilizar em uma sessão que está sendo negociada ou estabelecida. O campo de cabeçalho SIP Content-Type: application/sdp irá indicar a existência de conteúdo SDP no corpo da mensagem SIP. Os parâmetros informados são pertinentes a todo fluxo de mídia daquela sessão, tais como [2]: - Codificadores de áudio e vídeo listados por ordem de prioridade; - Endereços IP de mídia; - Portas UDP/TCP de mídia; - Largura de banda necessária; - Parâmetros de Qualidade de Serviço (QoS Quality of Service); - Duração da sessão. A Figura 4 mostra um exemplo de oferta SDP encontrada em uma mensagem SIP INVITE capturada e exibida utilizando o software Wireshark. As mensagens SDP são divididas em níveis de descrição de tempo, descrição de sessão e descrição de mídia. A seguir alguns parâmetros são dados como exemplo. Os campos marcados com asterisco são opcionais [2] [3]. Fig. 4. Exemplo de uma oferta SDP encapsulada em um SIP INVITE. Descrição de sessão: v= (versão do protocolo) o= (criador e identificador da sessão, descrevendo usuário, id da sessão, versão do protocolo IP, tipo de rede e endereço). s= (nome da sessão) i=* (informação da sessão) u=* (URI da descrição da sessão) e=* (endereço de e-mail do responsável pela sessão) p=* (número de telefone do responsável pela sessão) c=* (informações de conexão incluindo tipo de rede, tipo de endereço e endereço para conexão desnecessário se for incluído em todas as mídias). Descrição de mídia [2]: m= (nome da mídia e endereço de transporte) i=* (título da mídia) c=* (informações de conexão, opcional se incluído no nível de sessão) b=* (informação de largura de faixa) k=* (chave de criptografia) a=* (descritivos de atributos de mídia) Descrição de tempo [2]: t= (período em que a sessão estará ativa) r=* (zero ou mais vezes para repetição)
C. RTP Real-time Transport Protocol e RTCP- Realtime Transport Control Protocol Conforme sugere seu nome, o RTP foi desenvolvido para transporte de informações em tempo real, impulsionado pela popularização do uso de multimídia em tempo real através da internet, sendo adequado para transporte de áudio e vídeo (rádio, telefonia IP, vídeo conferência e outros) [1] - [5]. Pode ser definido como um protocolo de transporte de mídia implementado na camada de aplicação. Embora possa ser transportado sobre TCP ou UDP, nas aplicações em tempo real sempre será utilizado o protocolo UDP, já que recursos implantados pelo TCP, tais como retransmissão, controle de fluxo e segmentação, não fazem sentido em aplicações em tempo real [2]. O RTP oferece mecanismos que permitem que o receptor identifique as informações por ele recebidas, determinando a sequência correta de pacotes, pacotes perdidos e a variação de atraso (jitter) proporcionada pela rede [1]. Para que isso seja possível, o RTP faz uso de três tipos de informações contidas em seu cabeçalho, que são a identificação do tipo de mídia encapsulada, as timestamps e os números de sequência. O protocolo RTP é orientado a byte e seu cabeçalho é composto por 12 bytes fixos, podendo ser estendido [2]. O encapsulamento da mídia codificada é feito apenas adicionando um cabeçalho RTP às amostras codificadas pelo codec conforme previamente negociado via SDP. Os pacotes serão tratados na recepção de acordo com seus cabeçalhos, podendo inclusive ser descartados caso um fragmento de mídia esteja atrasado demais para ser reproduzido. A Figura 5 mostra a estrutura de um cabeçalho RTP [2]. Fig. 5. Cabeçalho de pacotes RTP Os significados dos campos são mostrados a seguir [2]. Version (V): Traz a versão do protocolo que está sendo usado. A versão atual em uso do RTP é a 2. Padding (P): Se o bit estiver setado (igual a 1), significa que há bytes de preenchimento no final do pacote RTP a fim de garantir que este tenha um tamanho fixo. É mais comumente observado quando a mídia está criptografada. Extension (X): Indica a presença de extensões ao final do cabeçalho RTP. CSRC Count (CC): Contém o número de fontes de contribuição CSRC (Contributing source) presentes no cabeçalho RTP. Marker (M): Quando setado, significa que os dados deste pacote têm alguma relevância especial para aplicação em questão. Por exemplo, pode indicar o fim de um quadro completo em um vídeo, ou o início de uma rajada numa conversa com supressão de silêncio. Payload Type (PT): Indica o codificador usado na transmissão (definido pela RFC 1890). Sequence Number: O valor inicial nesse campo é aleatório, sendo incrementado a cada pacote RTP enviado. É usado para detectar perda de pacotes ou pacotes fora de ordem. Timestamp: Indica quando o primeiro byte do payload deste pacote foi amostrado, para que o receptor possa reproduzir a amostra no tempo adequado. No primeiro pacote possui um valor aleatório, sendo incrementado nos pacotes seguintes em número de ticks de clock. Permite estimar o atraso sofrido pelo pacote na rede (jitter), ajudando o receptor a determinar um tempo de retenção no dejitter buffer para compensar a variação dos atrasos. SSRC identifiers: Identifica a fonte (SSRC - Synchronization Source) do pacote RTP. Para iniciar uma sessão, cada participante escolhe de forma aleatória um identificador, caso este seja igual ao de alguma outra fonte participando da sessão, o processo de escolha se repete até que todos os participantes tenham um identificador exclusivo. Esse campo introduz uma camada de segurança na comunicação RTP contra um ataque do tipo media spamming, onde uma terceira parte tenta invadir uma sessão de mídia já estabelecida. A menos que o atacante possa determinar o SSRC de uma das partes, qualquer pacote enviado por ele será descartado. CSRC identifiers: Pode haver de zero a quinze campos deste num pacote RTP (refletindo o tamanho do campo CC de 4 bits). Só existirá se o pacote RTP estiver sendo enviado por um mixer, que junta pacotes RTP vindos de diferentes fontes. O protocolo RTCP foi desenvolvido para controle dos fluxos RTP e se baseia na transmissão periódica de pacotes de controle para todos os participantes de uma sessão RTP [5]. A taxa de envio desses pacotes é controlada pelo protocolo de modo a manter baixa ocupação de banda e não prejudicar o transporte da mídia. Os pacotes RTCP transportam informações sobre os participantes da comunicação, tais como identificação e localização na rede, e outras informações de controle. As informações permitem o monitoramento da qualidade de rede, possibilitando, por exemplo, que codificadores adaptativos alterem suas características dependendo do estado atual da rede, e monitoração de atividade dos participantes de uma conferência. A RFC 3551 define cinco tipos de pacotes RTCP. A função básica de cada um é listada a seguir [6]. Sender Report (SR): São informações enviadas por um participante ativo (fonte de fluxo RTP) no momento a todos os outros participantes da sessão com estatísticas
sobre recepção e transmissão de pacotes RTP em um intervalo. Receiver Report (RR): São informações enviadas por participantes ouvintes da sessão que não estão enviando fluxo RTP em um certo espaço de tempo. Source Description (SDES): Usado para enviar informações de identificação de participantes da sessão. End of Participation (BYE): Enviado por um participante quando deseja deixar a sessão. Application Specific (APP): Pacote inserido na definição do protocolo para permitir extensões, permitindo que uma aplicação leve informações específicas para que alguma ação seja tomada. III. SEGURANÇA EM REDES VOIP Assim como qualquer rede de computadores, redes que utilizam tecnologia VoIP podem sofrer diferentes tipos de ameaças vindas de diversos tipos de fontes. Com a crescente utilização dessa tecnologia, é cada vez mais relevante a adoção de métodos que possam garantir a segurança da informação seguindo os pilares da tríade CID Confidencialidade, Integridade e Disponibilidade de serviço. A VOIPSA (Voice Over IP Security Alliance) é uma organização que se destaca nesse sentido, visando contribuir com a tecnologia VoIP no que diz respeito à segurança, promovendo a pesquisa e a conscientização do uso de metodologias e ferramentas que possam melhorar esses aspectos [5]. Além das ameaças legadas, que são problemas de segurança que já apareciam em redes IP antes do surgimento de VoIP, houve o surgimento de novas ameaças inerentes a uma rede usando SIP que podem afetar a manipulação da sinalização e da mídia. A seguir algumas delas são listadas [8]. Inundação SIP INVITE: É um ataque do tipo negação de serviço. Esse tipo de ameaça consiste no envio de grandes quantidades de mensagens SIP INVITE ao destino de maneira a degradar o desempenho dos servidores SIP proxy, levando a uma interrupção parcial ou total do serviço. O servidor SIP proxy é o responsável pelo processamento de todas as chamadas entre sistemas finais e a mensagem INVITE é aquela que requer a maior carga de processamento e reserva de recursos computacionais em dispositivos SIP, o que explica a proporção que um ataque desse tipo pode atingir. Remoção de registro: Esse ataque baseia-se no envio de mensagem REGISTER ao servidor de registro SIP Registrar com um parâmetro Expires=0 após o campo Contact especificado com *. Desse modo todos os registros para uma identidade ou AOR informada em um campo To serão removidos do servidor SIP Registrar, causando indisponibilidade do serviço aos elementos registrados naquele domínio. Adição de registro: No SIP, é permitido que um usuário efetue registro a partir de diferentes locais e dispositivos para uma mesma identidade ou AOR, como por exemplo em sua casa e seu trabalho. Dentre os registros sob uma mesma identidade, ao receber uma chamada o primeiro dispositivo a atendê-la será o que efetivamente participará desta. Este ataque baseia-se no envio de mensagens SIP REGISTER a um servidor de registro vinculando uma identidade ou AOR a um novo dispositivo, com o intuito de confundir os usuários ou até mesmo deter a chamada para um elemento diferente do original. Sequestro de registro: Se baseia no uso dos ataques de remoção e adição, substituindo um registro verdadeiro por um falso. Esse tipo de ataque permite ainda a atuação de Man in the Middle, no qual uma ligação é encaminhada para um dispositivo ilícito e pode ser redirecionada para o destino real após captura de pacotes, auxiliando o atacante a permanecer despercebido. Redirecionamento: Baseia-se na interceptação de mensagens INVITE respondendo-as com as mensagens de redirecionamento SIP 301 Moved Permanently ou 302 Moved Temporarily, permitindo uma negação de serviço ao encaminhar a chamada para um usuário inexistente ou uma fraude encaminhando-a para um usuário ilegítimo. Interrupção de sessão: Baseia-se no envio de mensagens SIP BYE para terminar uma sessão, contanto que uma chamada possa ser monitorada por tempo suficiente para obter os parâmetros necessários ao BYE. Escuta RTP: Se um invasor puder capturar o tráfego RTP de uma chamada relativa a um canal de voz, é possível a remontagem do fluxo RTP podendo levar ao acesso à conversa sendo conduzida pelo uso de codecs padronizados utilizados para codificação de voz. Inserção de pacotes RTP e mixagem: Uma vez que um atacante esteja em uma posição de man in the middle, é possível a alteração do fluxo RTP, inserindo novo áudio ou adicionando áudio ao conteúdo original do fluxo. As subseções seguintes apresentam alguns métodos de segurança para ajudar na prevenção de ataques. A. Autenticação SIP Antes de um usuário efetuar ou receber chamadas em uma rede baseada em SIP, é necessário que o mesmo efetue o registro no servidor REGISTRAR. Este servidor passará a armazenar no seu banco de dados informações referentes a este usuário que permitirão, por exemplo, informar corretamente o endereço IP do UA a um servidor SIP Proxy caso o mesmo receba uma chamada. A autenticação SIP propõe um aumento da segurança no processo de registro de usuários SIP, também podendo ser implementada para início e término de sessões. Nesse caso, a implementação dos servidores e agentes envolvidos deverá suportar essa autenticação O processo consiste de desafios que deverão ser respondidos em novas mensagens REGISTER, INVITE ou BYE para que o terminal e as mensagens sejam devidamente autenticados. Os desafios são os esquemas de autenticação e parâmetros que o usuário deverá utilizar para se autenticar, sendo enviados em respostas 401 Unauthorized para uma solicitação REGISTER. Para mensagens INVITE e
BYE as respostas 407 Proxy Authentication Required são usadas para solicitações feitas ao proxy, além da 401 Unauthorized para solicitação feita diretamente ao dispositivo final [1]. A Figura 6 mostra um exemplo de um desafio a um método REGISTER enviado em uma resposta 401 Unauthorized, informando no campo WWW-Authenticate os esquemas de autenticação que o usuário deverá utilizar para se autenticar, nesse caso especificando uma função criptográfica MD5 [2]. Fig. 6. Desafio enviado em uma resposta SIP 401. A Figura 7 ilustra possíveis cenários de autenticação para os três tipos de mensagens citados [1]. Fig. 7. Cenário de autenticação para SIP REGISTER, INVITE e BYE. B. Transport Layer Security (TLS) e Datagram TLS (DTLS) O TLS é um método de segurança que provê suporte ao transporte confiável de pacotes através de protocolos como o TCP, oferecendo autenticação e proteção da confidencialidade e integridade. Dois protocolos são utilizados em um método TLS, sendo o TLS Handshake Protocol responsável pelo estabelecimento da conexão e negociação dos parâmetros da sessão segura, e o TLS Record Protocol responsável pela aplicação dos parâmetros negociados às mensagens [1]. Uma sessão SIP assegurada com o uso de TLS é também chamada de SIPS ou Secure SIP [1] [5]. Para o estabelecimento de uma conexão segura SIP, o protocolo faz uso do TLS pela porta 5061 e define SIPS URIs (Uniform Resource Identifiers), funcionando de forma similar a um HTTPS sendo utilizado para uma conexão HTTP segura. Neste caso, o campo do cabeçalho sip:url é substituído pelo sips:url. Uma das desvantagens dessa técnica é que as sessões TLS são estabelecidas salto a salto, sendo necessária a criação de um túnel TLS em cada salto dos dispositivos SIP envolvidos a fim de garantir a conexão segura fim a fim, gerando aumento de latência da troca de sinalização. O TLS não é apropriado para segurança de sessões SIP que usam o UDP como protocolo de transporte, bem como o fluxo de mídia. Para atender a essas limitações, desenvolveu-se o DTLS, similar em muitos aspectos ao TLS, mas implementando tratamento de perda de pacotes e reordenação que permitem a decodificação correta dos pacotes criptografados, ao custo de um atraso ainda maior no processamento dos pacotes [1]. C. Secure Real-time Trasnport Protocol (SRTP) e SRTCP Definido na RFC 3711 [9], o SRTP é o perfil seguro do RTP que provê confidencialidade, autenticação e integridade ao fluxo de mídia RTP, além de proteção contra retransmissão fraudulenta (replays) [4]. Para o fluxo de controle RTCP, é definido o perfil seguro SRTCP. Estes recursos são opcionais e independentes entre si, sendo mandatória somente a proteção de integridade nos pacotes RTCP uma vez que alterações maliciosas nesse tipo de pacote podem interromper todo o fluxo RTP. A implementação de SRTP pode prevenir ataques como escuta do RTP [4], inserções e outras manipulações possíveis envolvendo este protocolo. Foi desenvolvido considerando altas taxas de transmissão, inserindo um aumento relativamente pequeno no tamanho dos pacotes, a fim de garantir a eficiência em termos de latência, banda e processamento computacional. O SRTP usa um esquema de chaves simétricas que devem ser negociadas através do protocolo SIP. Esta técnica define um conjunto de padrões de criptografia e prevê o desenvolvimento futuro de novas técnicas [1]. Elas consistem na captura da carga útil (payload) e transformação da mesma por criptografia de modo a garantir a privacidade e integridade dos dados do usuário. No caso de transformações padrão prédefinidas, a cifra ou algoritmo padrão utilizado é o AES (Advanced Encryption Standard) e a parte criptografada do payload SRTP é do mesmo tamanho do payload original do pacote RTP, pois não há preenchimento de bits (padding) para elas [1]. Isso ajuda a garantir um baixo custo computacional para as transformações padrão. Uma cifra nula também é possível, e nesse caso não há criptografia e nem confidencialidade aos pacotes RTP/RTCP.
Com relação às chaves, o SRTP possui um recurso para auxiliar no gerenciamento das mesmas permitindo, por exemplo, uma configuração para que a derivação de chaves de sessão seja atualizada periodicamente, limitando a quantidade de dados transmitidos por uma única chave, conferindo maior segurança. Além disso, SRTP faz uso de função HASH para autenticação e integridade das mensagens [4]. Pode-se descrever o SRTP como uma implementação que se situa entre a aplicação RTP e a camada de transporte (UDP). Do ponto de vista do remetente, há o processamento dos pacotes RTP e o posterior envio dos pacotes SRTP para a camada de transporte. No receptor, os pacotes SRTP são recebidos, processados para extração da informação do RTP equivalente e enviados então para a camada superior. Os pacotes SRTP tem a mesma estrutura de um pacote RTP, com o diferencial do payload ser criptografado e da presença de um campo recomendado de autenticação Authentication Tag e opcionalmente um campo Master Key Identifier ou MKI [1] [4]. A Figura 8 mostra o formato de um pacote SRTP [4] [5]. configurar o isolamento de tráfego de dados e de voz (VoIP), permitindo um menor congestionamento dos pacotes de voz e uma melhor proteção contra atividades maliciosas, já que normalmente a maioria das ameaças tem origem na rede de dados. Um eventual impeditivo para utilização de VLANs ocorre quando o serviço VoIP é utilizado em aplicativos softphone, executados diretamente no computador do usuário [1]. Como tanto o serviço de dados quanto o de voz trafegarão pela mesma interface física do dispositivo, a mesma deverá suportar o recurso de tagueamento de quadros, de forma a diferenciar os diferentes fluxos. E. Protocolo IPSec (IP Security) O protocolo IPsec é muito utilizado no estabelecimento de VPNs (Virtual Private Network) em comunicações fim a fim de redes IP, provendo confiabilidade, autenticidade e integridade dos dados. É um mecanismo de segurança genérico que opera na camada de rede da pilha TCP/IP, podendo trabalhar com qualquer protocolo na camada de transporte. Portanto, protocolos como o SIP e o RTP funcionam sobre o IPSec de maneira direta, sem necessidade de alteração [1]. Para utilização do IPSec é necessário o estabelecimento de um túnel a partir de chaves simétricas em ambos os lados, podendo proteger VoIP em nível de sinalização SIP e tráfego de mídia RTP [1]. Este túnel, ativo permanentemente nas máquinas e dispositivos que compõe a rede SIP, se torna uma boa opção de segurança em VoIP. Entretanto, para aplicações distribuídas onde se faz necessário o estabelecimento de túneis VPN entre os hosts (ou seja, IPSec ativado quando necessário), o seu uso não é recomendado uma vez que é complexo estabelecer túneis entre todos os hosts envolvidos antes do envio de sinalização e mídia. Fig. 8. Formato de um pacote SRTP. O Authentication Tag é utilizado para armazenar os dados de autenticação das mensagens gerados a partir do cabeçalho RTP e payload associado [4]. O campo MKI é utilizado para informar a chave mestra a partir da qual se irá obter as chaves de sessão para criptografia e autenticação [4]. Nos pacotes SRTCP, três campos adicionais aos pacotes RTCP são definidos. Além dos campos de MKI e Authentication tag, também se faz necessário um campo Encryption Flag contendo o índice SRTCP [4]. O primeiro indica se o pacote está cifrado ou não, enquanto o índice SRTCP é incrementado a cada pacote SRTP enviado com o objetivo de evitar ataques de replay. D. Virtual Local Area Network (VLAN) Definidas pelo padrão IEEE 802.1Q, as VLANs promovem separação lógica do tráfego para dispositivos conectados a uma mesma LAN, definindo domínios de broadcast distintos entre eles baseados em parâmetros como portas de um switch ou endereços físicos de uma interface [1]. É possível então IV. CONCLUSÃO A grande variedade de ameaças presentes em diferentes tipos de rede também são uma realidade em todos os elementos de infraestrutura que compõem a arquitetura VoIP. Esses elementos possuem vulnerabilidades que podem ser exploradas se as devidas proteções não forem utilizadas. Além disso, novos métodos maliciosos surgem com frequência e é extremamente importante fazer o uso de soluções de implementação de segurança nas redes VoIP a fim de evitar que elas possam sofrer incidentes que prejudiquem parcial ou totalmente o serviço. Normalmente espera-se implementar em VoIP soluções de segurança complementares a outras já implementadas nas redes IP. A escolha dessas soluções para arquitetura VoIP deve levar em conta alguns fatores, como o aumento de complexidade da tecnologia e o fato de os dispositivos e equipamentos envolvidos oferecerem ou não o suporte aos métodos. Dentre as diversas soluções propostas na literatura, optou-se por abordar neste artigo algumas soluções que dizem respeito à segurança na sinalização SIP, no fluxo da mídia e na arquitetura da rede.
Propõe-se sempre que possível a implementação de VLAN para segmentação da rede, separando fluxos de dados e voz (em conjunto com a sinalização), a fim de aumentar a proteção contra ataques que visam comprometer a disponibilidade do serviço VoIP (tais como técnicas de negação de serviço) e também outros ataques baseados em violação de acesso. As VLANs atuam na camada de enlace do modelo OSI (ou na camada de acesso à rede no modelo TCP/IP), e além de proporcionarem uma melhor proteção ao serviço, proporcionam também uma melhor distribuição do tráfego, o que é sempre desejável. A autenticação SIP e as técnicas de criptografia TLS, DTLS, SRTP, SRTCP e IPSec, são empregadas como soluções de segurança que visam preservar a integridade e confiabilidade das informações, principalmente no fluxo de sinalização e transporte de mídia fim a fim. A autenticação SIP provê segurança no processo de requisição de sessão SIP, atuando na camada de sessão do modelo OSI (aplicação do TCP/IP). As técnicas de criptografia TLS e DTLS proveem segurança na comunicação fim a fim em redes TCP/IP, atuando na camada de apresentação do modelo OSI ou camada de aplicação do modelo TCP/IP. Técnicas SRTP e SRTCP fornecem confidencialidade, autenticação e integridade ao fluxo de mídia RTP, e são empregadas na camada de aplicação do modelo OSI e TCP/IP. Por último, o protocolo IPSec atua na camada de rede do modelo OSI e TCP/IP, sendo muito aplicado em comunicações fim a fim de redes IP. É importante ressaltar que não há um padrão claramente definido no que se refere aos mecanismos de criptografia que podem ser utilizados em VoIP, como o TLS, DTLS, IPSec, SRTP e SRTCP. As técnicas escolhidas deverão ser avaliadas em termos de interoperabilidade entre equipamentos, desempenho na rede VoIP e complexidade de implementação. É certo que não existem sistemas seguros em sua totalidade, mas pode-se aumentar a segurança dos mesmos por meio do emprego de algumas técnicas combinadas, diminuindo a relevância das ameaças conhecidas. É importante que a política de segurança seja baseada em camadas para evitar qualquer brecha para ataques, e deve estar em constante atualização de modo a fornecer proteção contra as ameaças mais recentes. [5] A. Lima e H. Duarte, "Segurança em VoIP," ISEL - Redes e Serviços de Comunicação Multimédia, Lisboa, Jan. 2009. [6] Session Initiation Protocol (SIP) Parameters. [Online]. Available: https://www.iana.org/assignments/sip-parameters/sipparameters.xhtml. [7] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., et al. SIP: Session Initiation Protocol. Available: http://tools.ietf.org/html/rfc3261 [8] ENDLER, D., COLLIER, M. Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions. [S.I]: McGraw-Hill, 2007 [9] D. A. McGrew and K. Norrman, RFC 3711 - The Secure Real-time Transport Protocol (SRTP). [Online]. Available: https://tools.ietf.org/html/rfc3711. Márcio de Salles Paiva Junior nasceu em Mococa-SP, em 14 de janeiro de 1983. Possui os títulos: Engenheiro Eletricista com ênfase em Telecomunicações (Inatel, 2005), Técnico em Eletrônica (ETE FMC, 2001). Atuou em Projetos de fontes chaveadas em 2001. De 2003 a 2005 foi monitor do laboratório de Automação Industrial do Inatel, lecionando em aulas práticas. Em 2005, atuou no CPqD Centro de Pesquisa e Desenvolvimento em P&D envolvendo equipamentos de Power Line Communications para internet via rede elétrica. Desde 2006 é especialista do Inatel Competence Center onde, por mais de dez anos, vem trabalhando em diversos projetos principalmente envolvendo centrais móveis e fixas em parceria com a Ericsson Telecomunicações S.A. Mário Ferreira Silva Júnior é engenheiro, formado em julho de 2008 como Engenheiro Eletricista na modalidade Eletrônica com Ênfase em Telecomunicações pelo Instituto Nacional de Telecomunicações e em 2012 recebeu o título de Especialista em Engenharia de Redes e Sistemas de Telecomunicações pelo mesmo instituto. Atualmente é Gerente de Educação Continuada do Inatel Competence Center, sendo responsável por cursos de Extensão Presencial, Ensino a Distância, Capacitação Corporativa, Consultoria e Preparatórios para Certificações. É professor do curso de Pós- Graduação em Engenharia de Redes e Sistemas de Telecomunicações do Inatel e especialista em Redes de Dados, TCP/IP, NGN, Voz e Vídeo sobre IP, Redes de Acesso, Redes convergente e Cidades Digitais. REFERÊNCIAS [1] A. S. Antoniazzi, Segurança em VoIP : ameaças, vulnerabilidade e as melhores práticas de segurança, VoIP security: threats, vulnerabilities and security best practices, 2008. [2] M. Ferreira, "Voz sobre IP Protocolos e Aplicações," Instituto Nacional de Telecomunicações - Inatel, Santa Rita do Sapucaí, MG, 2017. (Apostila). [3] R. C. Borges, "Um estudo para o provimento de segurança nas transmissões de Voz sobre redes IP," Monografia, Instituto Federal de Santa Catarina, São José, SC, Mar. 2009. [4] L. A. L Hércules, "Impacto no Desempenho em Aplicações de Tempo Real Utilizando Criptografia," Monografia, Universidade Federal do Rio Grande do Sul Instituto de Informática, Porto Alegre, SC, 2014.