Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX.

Transcrição

1 VoIP: Segurança da Informação em Telefonia Baseada em SIP Este tutorial apresenta uma revisão bibliográfica sucinta acerca dos principais protocolos empregados na telefonia VoIP e sobre questões de segurança relevantes para o serviço. São abordadas ameaças legadas das redes IP (que já existiam antes mesmo da tecnologia de voz sobre IP), bem como ameaças específicas à arquitetura SIP. André de Almeida Lima Tecnólogo em Redes de Computadores pelo Instituto Federal de Educação, Ciência e Tecnologia do Espírito Santo (IFES, 2008) e Especialista em Engenharia de Redes e Sistemas de Telecomunicações pelo Instituto Nacional de Telecomunicações (Inatel, 2011). Atualmente trabalha como Trainee Expert na operadora de Telecomunicações Oi, atuando no tratamento de falhas de banda larga e vídeo. andrealmeida_lima@yahoo.com.br Guilherme Rezende dos Santos Bacharel em Sistemas de Informação pela Faculdade de Administração e Informática (2008) e Especialista em Segurança da Informação pela Faculdade Impacta Tecnologia (2010). Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX. Atualmente trabalha com Analista de Segurança da Informação na empresa Cipher Security S/A, e também é professor da disciplina Segurança em Redes de Telecomunicações do curso de Pós-graduação em Engenharia de Redes e Sistemas de Telecomunicações do Inatel. 1

2 Categoria: VoIP Nível: Introdutório Enfoque: Técnico Duração: 20 minutos Publicado em: 21/05/2012 2

3 VoIP: Introdução A telefonia VoIP promete, eventualmente, por fim a mais de um século de rede pública de telefonia comutada (RPTC), transferindo a inteligência do sistema para as bordas da rede, seguindo a tradição da Internet. Como aplicações IP são mais facilmente criadas e distribuídas, tem-se visto um proeminente crescimento do número de soluções VoIP, vindas de múltiplos fornecedores, sendo apresentadas ao mercado. Neste modelo, os próprios usuários terão um importante papel na definição, implementação e controle dos serviços de telefonia ( SICKER e LOOKBAUGH, 2004). Aliada a isto, a flexibilidade do SIP (Session Initiation Protocol), atualmente o protocolo mais usado para o estabelecimento de sessões VoIP, torna esta tecnologia cada vez mais viável e atrativa economicamente quando comparada com o serviço oferecido pela RPTC (SIÉCOLA, 2010). Em contrapartida, toda esta flexibilidade e disseminação também atrai a atenção dos hackers. O fato da tecnologia se proliferar não quer dizer que as infraestruturas para comunicação VoIP apresentadas pelos fornecedores tem se preocupado em blindar as ameaças que são inerentes ao SIP, tampouco as conhecidas brechas de segurança que flagelam as redes IP e praticamente qualquer serviço oferecido sobre elas. Diante disto, este tutorial se propõe a examinar quais sãos os principais protocolos que oferecem suporte à telefonia VoIP e enumera algumas das ameaças que devem ser levadas em consideração quando se pretende levantar uma infraestrutura baseada em SIP para esta tecnologia, preocupando-se inclusive com as ameaças legadas das já existentes redes IP. 3

4 VoIP: Protocolos da Telefonia VoIP Basicamente, dois tipos de protocolos são utilizados para viabilizar a comunicação VoIP: um protocolo para sinalização (com objetivo de estabelecer e gerenciar a chamada sessão) e outro para o transporte da voz por uma rede IP (SIÉCOLA, 2010). Diversos protocolos de sinalização foram concebidos por instituições padronizadoras, contudo a maior parte das aplicações utiliza o SIP (Session Initiation Protocol), descrito no RFC 3261, visto que este protocolo apresenta flexibilidade quanto à adição de novas features, além de facilidade de implementação e solução de problemas (DALGIC e FANG, 2011), por isto este trabalho aborda as situações onde este protocolo é utilizado para o estabelecimento de chamadas VoIP. O SIP é um protocolo textual baseado em requisições e respostas, bastante similar ao HTTP, que possui campos de cabeçalho e um corpo. No corpo de uma mensagem SIP é encapsulado algum protocolo de descrição de sessão responsável pela negociação dos tipos e formatos de mídias que serão trocadas entre as partes comunicantes, chamadas de User Agents (UA). O RFC 3261 não determina qual protocolo de descrição de sessão deve ser usado, portanto implementações SIP podem oferecer suporte a múltiplos protocolos de descrição de sessão. Entretanto, é mandatório o suporte ao SDP (Session Description Protocol), descrito no RFC 2327, o que faz deste o mais utilizado para negociação de mídias numa sessão SIP (JOHNSTON, 2009). Em se tratando do transporte da voz digitalizada por uma rede IP, o protocolo que ganhou o mercado foi o RTP (Real-time Transport Protocol), definido pelo RFC 3550, que não depende do tipo de protocolo de sinalização e descrição sendo utilizados. Também no mesmo RFC é definido o RTCP, um protocolo associado ao RTP que permite a troca de relatórios estatísticos entre os participantes de uma sessão a respeito da recepção de mídia. A seguir, é apresentado um tratamento de caráter introdutório sobre os protocolos SIP, SDP, RTP e RTCP. SIP Session Initiation Protocol O SIP é um protocolo da camada de sessão do modelo OSI (camada de aplicação do modelo TCP/IP) que pode estabelecer, modificar e terminar sessões multimídias - onde sessão é considerada uma troca de dados entre uma associação de UAs - como uma chamada telefônica pela Internet (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Nesta sessão serão introduzidas as funções básicas do protocolo SIP que tem participação fundamental na viabilização de VoIP: localização de um sistema final, sinalização da intensão de se comunicar, negociação dos parâmetros e estabelecimento de uma sessão e término de uma sessão previamente estabelecida (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). A Figura1 exibe uma típica troca de mensagens SIP entre dois usuários que desejam se comunicar, André e Guilherme. Para referência no texto, cada mensagem foi identificada com uma letra M e um número entre parênteses. O processo começa com o usuário André, no domínio lima.com desejando realizar uma chamada ao usuário Guilherme, no domínio santos.com. Os usuários são identificados fora de seu domínio pela sua identidade SIP, um tipo de URI (Uniform Resource Identifier) similar a um endereço de . Para o caso presente, as identidades SIP poderiam ser: sip:andre@lima.com e sip:guilherme@santos.com. Portanto, o usuário André constrói uma solicitação SIP INVITE (a mensagem M1) conforme a seguir: 4

5 INVITE SIP/2.0 Via:SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b Max-Forwards: 70 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:andre@pc145.lima.com> Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido) Figura 1: Estabelecimento de uma sessão SIP O cabeçalho da mensagem SIP vai da primeira linha até o campo Content-Length. A primeira linha da mensagem de solicitação exibe o método (INVITE), a identidade SIP do destino (sip:guilherme@santos.com) e a versão do protocolo (SIP/2.0). A seguir vem o campo Via, que exibe o endereço e a porta para o qual o usuário André espera receber a resposta de sua solicitação. Neste caso, pc145.lima.com é um nome que pode ser traduzido por DNS para o endereço IP e a porta 5060 é a porta padrão do SIP. Ainda no campo Via, há o parâmetro branch que serve como um identificador de transação. Desta forma, respostas referentes a esta transação podem ser identificadas, pois deverão possuir o mesmo valor no parâmetro branch. O campo Max-Forwards exibe a quantidade máxima de dispositivos SIP que a mensagem pode atravessar. A cada salto o campo é decrementado e quando chega a zero é descartado pelo dispositivo SIP que receber a mensagem. 5

6 O campo To carrega um nome de exibição (opcional) e a URI SIP que identifica o destinatário. O campo From carrega um nome de exibição (opcional) e a URI SIP que identifica o chamador. Observa-se também a presença do parâmetro tag, que é uma sequência de caracteres gerada aleatoriamente pela fonte. O próximo campo é o Call-ID, outra sequência de caracteres aleatória gerada pela fonte com o objetivo de identificar uma sessão SIP e, portanto, deve ser única no dispositivo SIP de origem. Na verdade, os User Agents de origem e destino, também chamados de User Agent Client (UAC) e User Agent Server (UAS), respectivamente, contribuem com a identificação da chamada cada um com mais uma sequência de caracteres aleatória, que são os parâmetros tag nos campos To e From. Esses três valores (Call-ID, tag do campo To e tag do campo From) identificarão completamente um diálogo aberto entre origem e destino. Na mensagem anterior não há parâmetro tag no campo To porque ele será adicionado quando o destinatário responder a solicitação INVITE. O campo seguinte é o CSeq (Command Sequence), que traz um valor inteiro e o nome do método. A cada nova solicitação enviada dentro de um diálogo o valor inteiro deve ser incrementado. No exemplo acima, o valor do campo foi iniciado com um (1), mas poderia ser qualquer inteiro maior que zero. É oportuno dizer que os campos Via, Max-Forwards, To, From, Call-ID e CSeq compõem o menor conjunto de campos obrigatórios no cabeçalho de qualquer solicitação SIP (JOHNSTON, 2009). O próximo campo na mensagem INVITE é o Contact, que contém o SIP URI do originador da chamada para o qual o User Agent de destino poderá encaminhar as transações seguintes diretamente (sem passar por dispositivos SIP intermediários). Os dois campos seguintes, Content-Type e Content-Length, informam o tipo de mensagem que está sendo carregada no corpo do protocolo SIP e qual o tamanho desta mensagem, respectivamente. Importa dizer que a mensagem INVITE aqui exibida não contém todos os campos possíveis para o método em questão. Uma lista completa dos campos possíveis numa mensagem INVITE, bem como em qualquer outra mensagem, está disponível em (JOHNSTON, 2009) e (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Apesar de conhecer a identidade SIP do destinatário, o usuário André não conhece o seu endereço IP atual. Portanto, de alguma forma, a mensagem SIP deve ser roteada até o dispositivo onde está o UA de destino. Para isso, o UAC confia num servidor SIP chamado proxy. Servidores SIP serão abordados posteriormente, por hora importa que um SIP proxy é capaz de receber uma mensagem SIP em seu domínio local, determinar para qual domínio ela está endereçada, encaminhar essa mensagem para o SIP proxy no domínio de destino para que este, finalmente, o entregue ao UAS. Assim, como pode ser observado na Figura 1, a M1 é encaminhada ao servidor proxy do domínio lima.com. Através de uma pesquisa DNS SRV, o servidor proxy do domínio local obterá o endereço do servidor proxy do domínio remoto, santos.com. Contudo, antes de encaminhar uma mensagem SIP, um dispositivo SIP adiciona um campo Via com seu próprio endereço, adiciona um parâmetro received (que tem como valor o endereço IP do UAC) ao campo Via original da mensagem e decrementa o valor no campo Max-Forwards. Desta forma, M2 será: INVITE sip:guilherme@santos.com SIP/2.0 Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk

7 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 69 (O resto não se altera) Adicionalmente, o servidor proxy do domínio lima.com também opta por retornar uma mensagem 100 Trying (M3) para o UAC, informando que recebeu a solicitação INVITE e tomou providências acerca dela. Isto impede que o UAC faça retransmissões da solicitação INVITE (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Vale destacar que essa não é uma mensagem obrigatória. Ao receber M2, o servidor proxy do domínio santos.com adiciona mais um campo Via com seu endereço, adiciona um parâmetro received ao campo Via inserido pelo servidor proxy anterior, decrementa o valor no campo Max-Forwards e encaminha a mensagem ao UAS, Guilherme. Desta forma, M4 será: INVITE sip:guilherme@santos.com SIP/2.0 Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 68 (O resto não se altera) Como anteriormente, o proxy do domínio santos.com envia uma mensagem 100 Trying para o proxy do domínio lima.com informando que está trabalhando na solicitação que lhe foi encaminhada. Contudo, essa mensagem não é repassada pelo proxy do domínio lima.com para o UAC, pois mensagens 100 Trying são do tipo hop-to-hop, isto é: nunca são repassadas. Ao receber a M4, o UAS opta por gerar uma mensagem 180 Ringing, M6, para informar que já recebeu a solicitação INVITE e está aguardando ação do usuário (por exemplo, atender ou rejeitar a ligação). Mensagens 180 Ringing também são opcionais, mas, ao contrário da 100 Trying, devem ser repassadas até retornar ao UAC. Como M4 chegou ao destinatário final com três campos Via, o User Agent sabe que a solicitação passou por dois dispositivos SIP intermediários e a rota de retorno para todas as mensagens dentro do contexto da transação INVITE devem passar pelos mesmos dispositivos SIP. Desta forma, M6 é encaminhada ao proxy do domínio santos.com conforme mostrado a seguir: SIP/ Ringing Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf; received= Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag= From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> Content-Length: 0 Essa mensagem simplesmente copia os campos Via, To, From, Call-ID e CSeq da mensagem de requisição INVITE original, mas como agora não há corpo na mensagem, o campo Content-Type não existe e o valor de 7

8 Content-Length é zero. Além disto, o parâmetro tag foi adicionado ao campo To. É importante atentar para o fato que, ainda que esta mensagem tenha como origem o usuário Guilherme e destino o usuário André, os campos To e From não se alteram. Isto acontece porque estes campos identificam a direção da requisição e não a direção de uma mensagem específica (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Deve-se notar ainda que o campo Contact agora contém o endereço para o qual o usuário André poderá enviar as próximas transações diretamente para o usuário Guilherme sem auxílio dos servidores proxy, a saber: sip:guilherme@soft667.santos.com, um nome que pode ser traduzido por DNS para o endereço IP Ao receber M6, o proxy do domínio santos.com checa que o primeiro campo Via contém seu próprio endereço, então ele o remove e encaminha a mensagem para o endereço e porta informados no segundo campo Via (proxy.lima.com, 5060). Similarmente, o proxy do domínio lima.com, ao receber M7 observa que o endereço no primeiro campo Via é o seu próprio endereço. Logo, ele o remove e, finalmente, encaminha a mensagem ao originador, o UAC. Assim, M8 é: SIP/ Ringing Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 68 To: Guilherme Santos <sip:guilherme@santos.com>;tag= From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> Content-Length: 0 No exemplo presente o usuário Guilherme decide atender a ligação, portanto uma mensagem 200 OK é enviada. Essa resposta é construída da mesma forma que a 180 Ringing, contendo o mesmo parâmetro tag no campo To e o mesmo endereço de contato direto no campo Contact. Uma resposta 200 OK também indica que os tipos e formatos de mídias negociadas pelo SDP foram aceitos, por isso no corpo da mensagem SIP é levada uma mensagem SDP carregando essa informação. Como a mensagem 200 OK ainda faz parte da transação INVITE, o caminho de retorno deve passar pelos mesmos dispositivos SIP como aconteceu com a mensagem 180 Ringing. Desta forma, M9 é: SIP/ OK Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf; received= Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag= From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> 8

9 Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido) Como anteriormente, os servidores proxy no caminho verificam seus endereços no primeiro campo Via da mensagem que recebem, removem este campo, decrementam o valor no campo Max-Forwards e repassam a mensagem para o próximo endereço e porta do campo Via abaixo. Neste ponto, é interessante destacar que respostas à requisições SIP são sempre compostas por um número de três dígitos seguido por uma frase informativa, como em: 100 Trying, 180 Ringing, 200 OK. Estas respostas são classificadas de acordo com o primeiro dígito de seu número. Os dois dígitos seguintes servem como um subtipo. A Tabela I, extraída de (SIÉCOLA, 2010), mostra as respostas SIP com suas classificações. Tabela 1: Classes de respostas SIP RESPOSTA CLASSE 1xx 2xx 3xx 4xx 5xx 6xx Informativas Sucesso Redirecionamento Falha na Requisição Falha no Servidor Falha Global O último passo para estabelecer a sessão é o UAC confirmar o recebimento da resposta 200 OK, permitindo então o início do tráfego de mídia usando outro protocolo (o RTP, por exemplo). Essa confirmação é feita com uma requisição ACK, que é a mensagem M12: ACK sip:guilherme@soft667.santos.com SIP/2.0 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkf992uij Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag= From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 2 ACK Content-Length: 0 Inicialmente deve-se observar que a primeira linha da requisição agora conta com o endereço que o UAS previamente informou como sendo seu endereço de contato direto. Desta forma, o usuário André pode enviar o ACK diretamente para o usuário Guilherme sem intervenção dos servidores proxy. O campo Contact também foi removido, uma vez que o UAS já foi informado do endereço de contato direto do UAC. Nota-se ainda que o parâmetro branch do campo Via é diferente dos anteriores, uma vez que esta mensagem ACK é considerada uma transação diferente da INVITE. Por outro lado, os parâmetros tag dos campos To e From, bem como o Call-ID não se alteraram porque esta mensagem ainda faz parte do mesmo diálogo que as mensagens anteriores. Agora, a troca de informações da mídia negociada pode então finalmente 9

10 acontecer. Após o tráfego de mídia, o usuário Guilherme deseja encerrar a sessão e para isso envia uma Requisição BYE para o usuário André, a mensagem M13: BYE sip:andre@pc145.lima.com SIP/2.0 Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hg4bk098jukj Max-Forwards: 70 To: André Lima <sip:andre@lima.com>;tag=76341 From: Guilherme Santos <sip:guilherme@santos.com>;tag= Call-ID: jlaks984309k CSeq: 3 BYE Content-Length: 0 Novamente, o parâmetro branch é diferente daquele nas requisições INVITE e ACK porque o BYE é uma transação diferente, contudo os parâmetros tag e o Call-ID permanecem os mesmos já que ainda trata-se do mesmo diálogo. Contudo, como agora esta é uma requisição direcionada ao usuário André, os campos To e From estão trocados em relação às mensagens anteriores. Portanto, neste momento o usuário Guilherme age como um UAC e o usuário André como um UAS. Isto posto, infere-se que toda implementação SIP deve contar com um módulo cliente e um módulo servidor, visto que estes papéis são dinâmicos dentro de um mesmo diálogo. Para finalizar a sessão, o UAS (usuário André) agora responde a solicitação BYE com uma mensagem 200 OK, M14: SIP/ OK Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hg4bkfw19b; received= Max-Forwards: 70 To: André Lima <sip:andre@lima.com>;tag=76341 From: Guilherme Santos<sip:guilherme@santos.com>;tag= Call-ID: jlaks984309k CSeq: 2893 BYE Content-Length: 0 Com isso, completa-se o ciclo SIP de localização de usuário, sinalização, estabelecimento e encerramento de um diálogo. Contudo, não discutido aqui é como os servidores proxy são capazes de localizar um usuário. Na verdade há diferentes mecanismos para cumprir com esta finalidade, seja usando o protocolo SIP ou outros protocolos. Servidores SIP Servidores SIP são aplicações que recebem solicitações SIP, executam alguma operação com ela e devolvem uma resposta ao dispositivo que a solicitou. Há três tipos de servidores SIP: servidor de proxy, servidor de redirecionamento e servidor de registro. Como são entidades lógicas, mais de um servidor SIP pode estar hospedado num mesmo dispositivo físico (YOSHIOKA, 2003). 10

11 Servidor Proxy A sessão 2.1 introduziu o servidor proxy como um facilitador de troca de mensagens SIP, sendo o elemento responsável pela localização do User Agent alvo da requisição. É importante esclarecer que um proxy diferencia-se de um User Agent em três pontos chave (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011): Não formula requisições SIP, apenas responde e trabalha em solicitações de User Agents (os métodos CANCEL e ACK são exceções); Não é multimídia, isto é, não produz fluxos de mídia (exceto o próprio texto contido nas mensagens SIP); Não analisa o corpo de uma mensagem SIP, trabalhando exclusivamente nos campos de cabeçalho. Na configuração exibida na Figura 1, conhecida como Trapezoide SIP, cada User Agent é configurado previamente para saber qual é o proxy padrão no seu domínio. Toda mensagem SIP será encaminhada para este servidor quando o UAC não souber qual endereço de contato direto do UAS com quem pretende estabelecer uma sessão. Quando recebe uma requisição SIP, o proxy analisa para qual domínio a mensagem está destinada e obtém o endereço do servidor de proxy do domínio de destino, tipicamente através de uma pesquisa DNS SRV. Alternativamente, por motivos que estão fora do escopo da presente discussão, um proxy também pode rejeitar uma solicitação. Neste caso é retornada uma mensagem 406 Not Acceptable ao UA. Dentro do seu domínio, um servidor proxy tem acesso a uma abstração chamada de serviço de localização, tipicamente um banco de dados populado pelo servidor de registros (Registrar tratado posteriormente) que armazena a relação entre identidades SIP externas e o endereço atual do dispositivo onde o UA está sendo executado. É desta forma que os servidores proxy resolvem o problema de localização do alvo de uma requisição SIP. Ademais, um servidor proxy pode operar com estado (stateful)ou sem estado (stateless). No modo stateful, o proxy mantém um contador de tempo e registros para todas as requisições e respostas que recebe e repassa e usa essas informações no processamento futuro de mensagens pertencentes a um mesmo diálogo. No modo stateless não há contadores de tempo nem registros das requisições e respostas repassadas anteriormente, desta forma não há retransmissões de mensagens perdidas e nenhum tipo de processamento para mensagens futuras pertencentes a um mesmo diálogo (YOSHIOKA, 2003). Servidor de Redirecionamento Tal como um servidor proxy, um servidor de redirecionamento também auxilia no processo de localização do destinatário de uma requisição SIP, mas não encaminha requisições SIP. Em vez disto, apenas responde ao UA de origem qual é o endereço de contato para atingir o UA de destino, ou um endereço de próximo salto para um servidor proxy ou outro servidor de redirecionamento mais próximo, sem se envolver de fato na comunicação (YOSHIOKA, 2003). Detalhamentos sobre as mensagens trocadas entre um UA e um servidor de redirecionamento podem ser obtidos em (JOHNSTON, 2009). Servidor de Registro 11

12 Um servidor de registro, também chamado Registrar, aceita requisições SIP REGISTER. Qualquer outra solicitação recebe como resposta um 501 Not Implemented (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). A Figura 2 mostra uma situação em que o usuário Guilherme solicita ao servidor de registro em seu domínio que crie um vínculo entre sua identidade SIP externa (também chamada de Address-of-Record, ou simplesmente AOR) e seu endereço atual. A solicitação REGISTER é: Figura 2: Exemplo de Registro SIP REGISTER sip:reg.santos.com SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com> From: Guilherme Santos <sip:guilherme@santos.com>;tag= Call-ID: CSeq: 1 REGISTER Contact: sip:guilherme@ Content-Length: 0 O campo To traz o AOR que para o qual o UA deseja registrar o seu endereço de contato atual. O campo Contact traz o endereço de contato atual que deve ser associado ao AOR. Os campos To e From usualmente trazem o mesmo endereço, exceto quando há um terceiro dispositivo que faz o registro em nome de outro UA (JOHNSTON, 2009). Ao receber a requisição REGISTER, o servidor de registro atualiza o banco de dados usado pelos servidores proxy e de redirecionamento para localização de usuário e responde com uma mensagem 200 OK informando que o registro foi feito com sucesso da seguinte forma: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag= From: Guilherme Santos <sip:guilherme@santos.com>;tag= Call-ID: CSeq: 1 REGISTER 12

13 Contact: Content-Length: 0 O campo Contact confirma o endereço de contato que foi registrado para o AOR e traz um parâmetro expires que informa a quantidade de tempo em segundos para a qual o registro permanecerá válido. Se o UA desejar que o seu registro continue válido por mais tempo, basta enviar outra requisição REGISTER ao servidor de registro antes que o tempo expire. Analogamente a um sistema de telefonia celular, o registro tipicamente é feito enquanto o dispositivo SIP está iniciando. A forma como o UA toma conhecimento do endereço do servidor de registro está descrita na seção de (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). SDP Session Description Protocol Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP. O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade. De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente RTP/AVP ), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia. Similarmente ao SIP, o SDP é um protocolo textual cujas mensagens são compostas por campos. Cada linha da mensagem é um campo e começa com uma letra minúscula. Nem todos os campos são obrigatórios, mas, se presentes, devem aparecer na ordem especificada na Tabela II, retirada de (SIÉCOLA, 2010). Tabela 2: Campos SDP CAMPO NOME OBRIGATÓRIO v = Versão do protocolo Sim o = Criador e identificador da sessão (origem) Sim s = Nome da sessão Sim i = u = Informação sobre a sessão Uniforme Resource Identifier URI Não Não e = Endereço de Não p = Número de telefone Não 13

14 c = b = t = Informação sobre a conexão Informação sobre largura de banda Tempo para início e término da sessão Sim Não Sim r = Número de repetições Não z = k = a = m = Correções de fuso horário Chave de criptografia (não utilizado mais) Linha de atributos da sessão Informações sobre a mídia Não Não Não Não a = Atributos da mídia Não Como detalhado em (ROSENBERG e SCHULZRINE, 2011) e amplamente exemplificado em (JOHNSTON e SPARKS, 2011), o SDP é baseado no modelo de oferta e resposta (Offer/Answer Model). Resumidamente, neste modelo um participante da sessão (o UAC) gera uma mensagem SDP (a oferta) informando quais mídias (e seus respectivos esquemas de codificação) gostaria de trocar, bem como seu endereço IP e porta onde gostaria de receber o fluxo de mídia. O outro participante (UAS) responde com uma mensagem SDP (a resposta) que tem um fluxo de mídia correspondente para cada fluxo de mídia descrito na oferta (isto é, para cada campo m = na oferta, deve haver um campo m = correspondente na resposta) indicando se o fluxo é aceitável ou não. Na resposta, também são informados o endereço IP e porta onde o UAS gostaria de receber o fluxo de mídia sendo negociado. Para exemplificar, abaixo segue a oferta SDP carregada em M1 da Figura 1: v = 0 o = André IN IP4 pc145.lima.com s = - c = IN IP t = 0 0 m = audio RTP/AVP a = rtpmap : 0 PCMU/8000 a = rtpmap : 6 DVI4/16000 a = rtpmap : 8 PCMA/8000 A primeira linha traz o campo versão. A versão atual e única do protocolo SDP é a zero (0). Portanto, uma mensagem SDP válida sempre começa com v = 0. O campo seguinte contém informações sobre o originador da mensagem. Esse campo identifica exclusivamente a sessão no contexto do SDP. O primeiro valor depois do = é o parâmetro username, que 14

15 tipicamente contém o nome de login ou host do originador, ou simplesmente -. A seguir estão os parâmetros session-id e version. Em (HANDLEY e JACOBSON, 2011) e (HANDLEY, JACOBSON e PERKINS, 2011) recomenda-se que estes parâmetros sejam um timestamp NTP (Network Time Protocol) ou um número aleatório qualquer. Logo após, está o parâmetro network-type que é sempre IN para Internet, seguido pelos parâmetros address-type ( IP4 ou IP6, para IPv4 e IPv6 respectivamente) e address, que informa o endereço IP do originador ou nome DNS do host. O campo seguinte é o nome de sessão. Este campo não tem utilidade para o estabelecimento de uma sessão unicast com o SIP, contudo trata-se de um campo obrigatório e como tal não pode deixar de ser incluído. Assim, (ROSENBERG e SCHULZRINE, 2011) recomenda que o campo seja preenchido com um espaço em branco ou com um traço ( - ). A linha seguinte traz informações sobre a conexão. Os parâmetros neste campo são network-type, address-type e address, que são preenchidos conforme já explicado no campo o =, exceto que aqui o parâmetro address deve conter o endereço IP do participante. A próxima linha indica o tempo para início e término da sessão. Contudo, conforme (ROSENBERG e SCHULZRINE, 2011), sessões unicast devem ser criadas e terminadas através de um protocolo de sinalização, como o SIP. Então os parâmetros start-time e stop-time neste campo devem ser preenchidos com 0. A mensagem SDP segue com o campo m =, que especifica qual o tipo de mídia deseja-se trocar. O primeiro parâmetro é media que, de acordo com (HANDLEY e JACOBSON, 2011) pode ser áudio, vídeo, text, application, message, image, ou control. Seguindo, há os parâmetros port, que identifica em qual porta o participante gostaria de receber o fluxo de mídia, e o transport que exibe o protocolo de camada de transporte ou o perfil RTP que será usado. O último parâmetro é o format-list que traz os esquemas de codificação para a mídia sendo negociada que estão disponíveis. As três linhas seguintes são atributos, campos opcionais e que podem ser usados para trazer mais informações sobre a mídia listada no campo m =. Neste caso, apenas trazem explicitamente informações sobre os esquemas de codificação listados no parâmetro format-list. Como determina o modelo Offer/Answer, o UAS agora deve construir uma resposta que aceite ou rejeite a oferta. No caso de rejeição, basta que o UAS formule uma mensagem SDP que tenha 0 (zero) no parâmetro port do campo m =. Esta é a forma que o SDP usa para comunicar ao outro participante que não tem interesse em trocar uma mídia oferecida (ROSENBERG e SCHULZRINE, 2011). No exemplo da Figura 1, o usuário Guilherme aceita a oferta. Neste caso, a resposta deve conter uma especificação de mídia coincidente com a oferta. Portanto, a mensagem SDP carregada em M9 pode ser: v = 0 o = Guilherme IN IP4 soft667.santos.com s = - c = IN IP t = 0 0 m = audio RTP/AVP 8 a = rtpmap : 8 PCMA/8000 Deve-se notar que o UAS selecionou apenas um dos três esquemas de codificação oferecidos, indicando que este deve ser o codec usado. 15

16 Os exemplos de mensagens SDP abordados aqui exploraram apenas os campos obrigatórios. Em (JOHNSTON, 2009) e (HANDLEY, JACOBSON e PERKINS, 2011) são oferecido detalhamentos sobre cada campo da Tabela II. Em (JOHNSTON e SPARKS, 2011) há numerosos exemplos de trocas de mensagens oferta/resposta. RTP Real-time Transport Protocol O RTP (Real-Time Transport Protocol), definido em (SCHULZRINNE, CASNER e FREDERICK, 2011), foi desenvolvido para tornar possível o transporte de pacotes contendo voz, vídeo ou outro tipo de mídia (informação) sobre uma rede IP. O protocolo permite a detecção de pacotes perdidos, variações no atraso (jitter) e chegada fora de ordem, contudonão garante qualidade de serviço para a mídia sendo transportada, isto é: pacotes RTP são tratados da mesma forma como qualquer outro pacote numa rede IP. Assim sendo, o que ocorre é um trabalho em conjunto com o RTCP (Real-time Transport Control Protocol), que é usado para monitorar estatísticas referentes às trocas de pacotes RTP (SCHULZRINNE, 2011). Sendo usado por aplicações cuja natureza é de tempo real, o transporte de pacotes RTP requer uma latência fim-a-fim tão baixa quanto possível através da Internet. Para isto, as aplicações tipicamente utilizam o protocolo UDP na camada de transporte, uma vez que não há tempo para detectar, sinalizar e retransmitir um pacote perdido. Diferentemente do SIP e do SDP, o RTP é um protocolo orientado a bit e possui um formato predefinido de cabeçalho composto por 12 bytes fixos, podendo ser estendido. O cabeçalho RTP é mostrado na Figura 3. Figura 3: Cabeçalho RTP O empacotamento da mídia codificada se dá simplesmente pela adição de um cabeçalho RTP a pequenas amostras do fluxo de bits codificado pelo codec negociado anteriormente com o SDP, formando então um pacote RTP. Na recepção, os pacotes RTP são tratados de acordo com seu cabeçalho, podendo até ser descartado caso seja um pacote contendo um fragmento de mídia que esteja atrasado demais para ser reproduzido, por exemplo. O cabeçalho RTP contém, de acordo com (JOHNSTON, 2009): Version (V): Traz a versão do protocolo sendo usado. A versão atual em uso do RTP é a 2. Padding (P): Se este bit estiver setado (igual a 1), significa que há bytes de preenchimento no final do pacote RTP para garantir que este tenha um tamanho fixo. O uso deste campo é mais comumente observado quando a mídia está criptografada. Extension (X): Se este bit estiver setado, há uma extensão ao final do cabeçalho. CSRC Count (CC): Contém o número de campos CSRC identifiers que há no cabeçalho. Este campo 16

17 é usado apenas quando mixers unem diferentes fluxos RTP formando um fluxo só. Marker (M): Esse bit é usado no nível de aplicação. Quando setado, significa que os dados deste pacote têm alguma relevância especial para aplicação em questão. Por exemplo, pode indicar o fim de um quadro completo em um vídeo, ou o início de um surto de fala numa conversa com supressão por silêncio. Payload Type (PT): O RTP foi desenvolvido para ser um protocolo de transporte de mídia genérico, isto é, permitir o transporte de mídias codificadas de diversas formas (com codecs distintos). Assim sendo, este campo é necessário para identificar com um número inteiro o codec previamente negociado com o SDP (e agora em uso na sessão). Em (SCHULZRINNE e CASNER, 2011) é detalhado o perfil RTP/AVP e pode ser encontradas tabelas que especificam os valores possíveis para o campo TP. Sequence Number: O valor nesse campo é incrementado a cada pacote RTP enviado e é usado para detectar pacotes perdidos ou que chegaram foram de ordem. Importa notar que apesar de detectar estes problemas o RTP não os trata, deixando essa função para o algoritmo do codec sendo utilizado. Timestamp: Este campo indica quando o primeiro byte do payload deste pacote foi amostrado, possibilitando ao receptor reproduzir a amostra no tempo adequado, pela introdução de atrasos para remoção de jitter, por exemplo. SSRC identifiers: O valor neste campo identifica a fonte (Synchronization Source) do pacote RTP. Para iniciar uma sessão, cada participante escolhe de forma aleatória um identificador, caso este seja igual ao de alguma outra fonte participando da sessão, o processo de escolha se repete até que todos os participantes tenham um identificador exclusivo. Esse campo introduz uma camada de segurança na comunicação RTP contra um ataque do tipo media spamming, onde uma terceira parte tenta invadir uma sessão de mídia já estabelecida. A menos que o atacante possa determinar o SSRC de uma das partes, qualquer pacote por ele enviado será descartado. CSRC identifiers: Pode haver nenhum ou até quinze campos deste num pacote RTP (haja visto que o tamanho do campo CC é de 4 bits). Só existirá se o pacote RTP estiver sendo enviado por um mixer, que junta pacotes RTP vindos de diferentes fontes. RTCP Real-time Transport Control Protocol Para que os participantes de uma sessão RTP tenham subsídios para medir a qualidade da comunicação, (SCHULZRINNE e CASNER, 2011) também define o RTCP (Real-Time Transport Control Protocol), que se baseia na transmissão periódica de pacotes de controle para todos os participantes da sessão. O RTCP desempenha, dentre outros, dois papéis que importa destacar. Primeiro, e principalmente, ele deve reunir informações estatísticas sobre aspectos de qualidade a respeito do recebimento da mídia e enviar tais informações à fonte (ou fontes, se na sessão houver vários participantes sessão multicast). Esses dados podem ser usados para realizar codificação adaptativa da mídia, por exemplo, além de detecção de falhas na transmissão. Em segundo lugar, o RTCP provê um identificador exclusivo para os sistemas finais da sessão RTP conhecido como CNAME. Essa é também a função do SSRC visto anteriormente, contudo o SSRC de um participante pode ser alterado caso seja detectado um conflito ou caso a aplicação comunicante reinicie. Nestes casos, o CNAME permite correlacionar um participante ao seu novo SSRC, evitando que todo o processo de estabelecimento da sessão seja executado novamente. A taxa com a qual um participante envia pacotes RTCP para os demais deve ser controlada, caso contrário a comunicação de mídia, que é a principal razão do RTP, ficaria comprometida. Sendo assim, o protocolo também provê mecanismos para que seja calculado um intervalo de envio entre pacotes RTCP, de tal forma 17

18 que a banda ocupada por eles seja suficientemente baixa. Contudo, a forma como isto é realizado está além do escopo deste trabalho e está detalhada na sessão 6.2 de (SCHULZRINNE e CASNER, 2011). São definidos cinco tipos de pacotes RTCP no RFC 3551, (SCHULZRINNE e CASNER, 2011): Sender report (SR): São os relatórios enviados por um participante ativo a todos os outros participantes ativos da sessão com estatísticas sobre a recepção e transmissão dos pacotes RTP no intervalo decorrido. Receiver report (RR): São relatórios para participantes ouvintes, isto é, que não enviam pacotes RTP. Source description (SDES): Usado para enviar o CNAME de um participante. Também pode conter informações adicionais como nome, , telefone, entre outras. End of participation (BYE): Enviado por um participante quando deseja deixar a sessão. Application specific (APP): Este tipo de pacote foi inserido na definição do protocolo para permitir extensões, isto é: um pacote APP levará informações específicas para a aplicação, para realizar uma ação não definida em (SCHULZRINNE e CASNER, 2011). Para diminuir o overhead de controle na comunicação, múltiplos pacotes RTCP são concatenados e enviados num único datagrama UDP. Cada pacote RTCP neste datagrama poderia ser processado individualmente sem que nenhuma restrição quanto a sua ordem ou combinação fosse imposta, contudo para que as funcionalidades do protocolo sejam garantidas, cada datagrama enviado deve conter no mínimo dois pacotes RTCP diferentes: um pacote de relatório (isto é um SR ou um RR) e um SDES com o CNAME para garantir que participantes recém chegados obtenham o CNAME dos demais participantes tão logo quanto possível. 18

19 VoIP: Segurança da Informação A informação já se tornou o ativo mais valioso das corporações e como tal, independente da forma como existe e é manipulada (em papel ou eletronicamente), sua proteção passou a ser mandatória. A norma ABNT NBR ISO/IEC define segurança da informação como a proteção da informação contra os diferentes tipos de ameaças a fim de minimizar o risco ao negócio, garantir sua continuidade e maximizar o retorno sobre os investimentos e as oportunidades de negócio. Existem três aspectos chave da segurança da informação comumente referidos como CIA Triad, ou Tríade CID: Confidencialidade, Integridade e Disponibilidade. A seguir estão expostos estes conceitos de maneira breve e posteriormente apresentam-se definições para alguns dos termos mais usados em se tratando de segurança da informação. Confidencialidade, Integridade e Disponibilidade A confidencialidade significa, conforme (BRAUMANN, CAVIN e SCHMID, 2011), que nenhum acesso à informação deverá ser garantido a sujeitos ou sistemas não autorizados, isto é, apenas aqueles com os direitos e privilégios necessários serão capazes de acessar a informação, esteja ela armazenada, em processamento ou em trânsito. A violação da confidencialidade pode ocorrer por modo intencional através de ataques, captura de tráfego, engenharia social, entre outros, bem como de forma não deliberada por imperícia ou negligência. No caso específico do VoIP, a confidencialidade preocupa-se com a não intercepção de uma conversa por uma terceira parte não autorizada, como nos ataques do tipo man-in-the-middle (MITM). A integridade é o aspecto que se preocupa com a confiança que pode ser depositada sobre uma informação obtida. Além disto, uma informação é dita íntegra se não sofreu nenhuma alteração entre os momentos de transmissão e recepção. Desta forma, em (BRAUMANN, CAVIN e SCHMID, 2011) são definidas duas categorias de integridade: integridade de fonte e integridade de dados. A integridade de fonte garante que uma informação realmente vem do remetente correto. A integridade dados se refere à confiabilidade da informação em si, isto é se a informação não foi comprometida (manipulada) em algum momento anterior à leitura pelo destinatário pretendido. Adicionalmente, (STEWART, TITTEL e CHAPPLE, 2008) atribui à integridade três objetivos: Impedir que sujeitos não autorizados realizem modificações na informação; Impedir que sujeitos autorizados realizem modificações não autorizadas; e Garantir a legitimidade, verificabilidade e consistência da informação, esteja ela armazenada, em trânsito ou em processamento. Em se tratando de VoIP, a integridade deve garantir que os pacotes de mídia cheguem ao destinatário sem sofrerem manipulações maliciosas. A disponibilidade é o aspecto da segurança da informação que diz que esta deve estar disponível para ser 19

20 acessada quando solicitada por um sujeito ou sistema legítimo (BRAUMANN, CAVIN e SCHMID, 2011). Isto requer que toda estrutura que permite acesso e transporte da informação deve ser protegida para que não seja degradada ou se torne indisponível. Com relação à disponibilidade, os tipos de ataque que representam maior ameaça são DoS (Denial of Service) e DDoS (Distributed Denial of Service), que visam danificar ou sobrecarregar sistemas. Especificamente para o VoIP, disponibilidade significa garantir que o serviço estará operante para os usuários, evitando qualquer efeito adverso resultante de um ataque do tipo negação de serviço, cujas consequências podem ser perda total ou parcial da comunicação (BRAUMANN, CAVIN e SCHMID, 2011). Definições Nesta sessão definem-se termos importantes mais comumente usados quando se discute sobre segurança da informação. De acordo com (STEWART, TITTEL e CHAPPLE, 2008), tem-se: Vulnerabilidade: Diz respeito às fraquezas de um sistema que podem ser exploradas maliciosamente. Podem estar relacionadas à software, hardware ou processos que apresentam falhas passíveis de serem exploradas de tal forma que comprometa o funcionamento de um sistema ou serviço. Ameaça: A forma como uma vulnerabilidade pode ser explorada determina uma ameaça. É chamada de agente de ameaça a entidade que tira proveito da vulnerabilidade, que pode ser uma pessoa (hacker), um processo ou um evento natural. Risco: É a probabilidade de um agente de ameaça se aproveitar de uma vulnerabilidade. Proteção: É um mecanismo usado para diminuir o risco, podendo ser em nível de software, hardware ou processo. Exemplos de proteção são: firewalls, isolamento de tráfego (VLAN), antivírus, entre outros. Incidente: Quando um agente de ameaça consegue explorar uma vulnerabilidade com sucesso, diz-se que houve um incidente de segurança. Neste caso, um ou mais princípios da tríada CID foram violados. 20