Seção: Banda Larga
|
|
||
Nesta sessão são examinadas de forma não exaustiva apenas algumas das abordagens que visam diminuir a probabilidade de um atacante executar uma ameaça com êxito. Várias outras contra medidas podem ser encontradas em (STEWART, TITTEL e CHAPPLE, 2008), (HARRIS, 2008), (ENDLER e COLLIER, 2007), (THERMOS e TAKANEN, 2007) e (PORTER e GOUGH, 2007).
Virtual Local Area Network
Uma VLAN (padrão IEEE 802.1Q) promove a separação lógica do tráfego de dispositivos conectados a uma mesma LAN, criando domínios de brodcast distintos com base nas portas de um switch ou endereços físicos de interfaces. Desta forma, é possível fazer um isolamento entre os tráfegos de dados e voz e, com isso, atividades maliciosas oriundas da rede de dados (que é o cenário mais comum) não afetarão a comunicação VoIP. A segregação do tráfego também traz o benefício de menor congestionamento enfrentado pelos pacotes de voz, melhorando a qualidade do serviço VoIP (PORTER e GOUGH, 2007).
Contudo, uma questão que deve ser levada em consideração é com relação ao uso de softwares do tipo Softphone, que são aplicações VoIP instaladas em computadores de uso pessoal. Se a estação onde estiver instalado um Softphone não contar com mais de uma interface, então não será possível o uso de VLAN para separação de tráfego. Neste cenário, para viabilizar o uso de VLAN, deve-se ter uma interface de rede separada para o tráfego VoIP (ENDLER e COLLIER, 2007).
Firewall, IDS e IPS
Há equipamentos que podem ser inseridos na infraestrutura de rede com o objetivo de adicionar segurança de uma forma geral, isto é, não especificamente para o serviço VoIP.
Um deles é o firewall, onde são implementadas regras responsáveis por bloquear todo tráfego (de entrada ou saída) que não é aderente à política de segurança da rede. Basicamente, o firewall analisa o conteúdo dos pacotes IP que o atravessa, como portas e endereços de origem e destino e, com base nessas informações, autoriza ou nega o fluxo (PORTER e GOUGH, 2007). Firewalls podem ser do tipo stateless ou stateful. Um firewall stateless não guarda em memória o estado das conexões estabelecidas. O firewall stateful mantém em memória uma tabela que guarda o estado das conexões em andamento, o que permite identificar pacotes que estão iniciando uma nova conexão e pacotes pertencentes a uma conexão já estabelecida e, portanto, este é o tipo de firewall mais eficiente para detectar uma tentativa de ataque (PORTER e GOUGH, 2007).
Apesar de importante, o firewall não é a defesa definitiva para uma rede de computadores. O IDS (Intrusion Detection System) e o IPS (Intrusion Prevention System) são dispositivos de segurança que podem ser posicionados estrategicamente dentro da rede para detectar tráfego malicioso que por ventura tenha passado pelas regras do firewall.
De acordo com (HARRIS, 2008), a diferença entre eles é que o IDS, ao detectar um tráfego malicioso, unicamente gerará alarmes e logs. Qualquer ação de combate deverá ser tomada pelo administrador da rede. Já o IPS é embarcado com inteligência reativa a um fluxo identificado como malicioso.
IPSec
O IPSecou IP Security é um protocolo que opera na camada de rede da pilha TCP/IP e, como tal, trabalha com qualquer protocolo da camada de transporte. Ademais, protocolos como o SIP e o RTP funcionam sobre o IPSec sem alterações. Uma sessão IPSec é comumente chamada de VPN (JOHNSTON, 2009).
O gerenciamento de chaves no IPSec pode ser significativamente difícil, uma vez que é necessário chaves simétricas em ambos os lados comunicantes, mas o fato de que um túnel VPN pode proteger tanto a sinalização SIP como o tráfego de mídia é um ponto forte do protocolo. Contudo, para aplicações distribuídas, como áudio conferências, o IPSec não é escalável, já que estabelecer túneis VPN para todos os hosts antes da sinalização SIP e do fluxo RTP é difícil (JOHNSTON, 2009).
TLS – Tranport Layer Security
É um protocolo de segurança desenvolvido para oferecer suporte ao transporte confiável de pacotes através de protocolos como o TCP ou SCTP. Além disto, o TLS oferece autenticação e proteção a confidencialidade e integridade (STEWART, TITTEL e CHAPPLE, 2008).
O TLS vale-se de dois protocolos. Um é o TLS Handshake Protocol, responsável por estabelecer a conexão e negociar os parâmetros da comunicação segura que serão usados como: métodos de compressão, tamanho do hash, algoritmos de criptografia (DES, RC4, entre outros) e de integridade (MD5, SHA, entre outros). O outro é o TLS Record Protocol, responsável pela aplicação dos parâmetros de segurança negociados, isto é: faz a fragmentação, compactação, criptografia e aplica função de integridade antes do envio das mensagens vindas das camadas superiores (HARRIS, 2008).
Contudo, por não ter sido desenvolvido para oferecer suporte ao UDP, o TLS pode ser usado para tornar segura a sinalização SIP (prevenindo ataques de manipulação de sinalização), mas não o fluxo de mídia RTP.
Outra questão que deve ser considerada no uso do TLS é que as sessões estabelecidas são hop by hop, isto é, para cada salto entre dispositivos SIP um túnel TLS deve ser criado, o que aumenta a latência durante a sinalização (JOHNSTON, 2009).
Vale a pena destacar o SIPS (Secure SIP), que é um esquema URI que requer o uso do TLS para cada salto entre dispositivos SIP. Sendo assim, com o SIPS em uso, quando um servidor proxy recebe uma mensagem ele deverá processá-la e estabelecer um conexão TLS com o próximo dispositivo SIP para então encaminhá-la ou, caso não ofereça suporte ao TLS, retornar uma mensagem de erro ao UA. Infelizmente este aditivo de segurança à comunicação SIP não ganhou o mercado graças a confusões e ambiguidades na especificação, bem como a falta de suporte ao TLS oferecida pela maior parte das aplicações SIP (JOHNSTON, 2009).
DTLS – Datagram Transport Layer Security
De acordo com (RESCORLA e MODADUGU, 2011), a filosofia básica do DTLS é construir “TLS sobre datagrama”. O motivo pelo qual o TLS não pode ser usado sobre datagramas é simplesmente porque pacotes podem se perder ou ser reordenados, isto é, a camada de criptografia do TLS não permite decriptografar registros isoladamente (se o registro N não for recebido, o registro N+1 não poderá ser desencriptar) e a camada de handshake assume que as mensagens são entregues em ordem e caso não sejam, ela falha.
Para suprir as deficiências que impedem o TLS ser usado sobre UDP, o DTLS utiliza um sistema de retransmissão baseada em contadores, o que significa que uma mensagem será automaticamente retransmitida se não houver retorno na comunicação. Com relação ao problema de reordenamento, o DTLS insere uma sequencia numérica específica em cada mensagem de handshake. Quando um sistema final recebe uma mensagem de handshake ele pode determinar se é a próxima mensagem que espera ou se é uma mensagem diferente. Se for a mensagem esperada, esta será processada. Caso contrário, será armazenada para processamento posterior, quando já tiverem sido recebidas todas as mensagens anteriores a esta (RESCORLA e MODADUGU, 2011).
Autenticação SIP
A autenticação SIP busca adição de segurança no processo de registro de usuários SIP, bem como início e término de sessões, isto é: para mensagens REGISTER, INVITE e BYE. A figura 4, extraída de (THERMOS e TAKANEN, 2007), ilustra o fluxo para tais mensagens.
Figura 4: Exemplos de autenticação SIP
Ao receber uma mensagem REGISTER, o servidor registrar verifica se nela há credenciais digest. Se não houver, será retornado ao UA uma “401 Unauthorized” onde um desafio MD5 digest é inserido. Quando o UA recebe o desafio, ele confirma o recebimento com um ACK e calcula a resposta adequada para enviar novamente uma mensagem REGISTER, dessa vez incluindo a resposta MD5 digest calculada. O servidor verifica se a resposta ao desafio está correta e processa a solicitação, caso positivo (JOHNSTON, 2009).
Para mensagens BYE e INVITE, o procedimento é o mesmo, contudo servidores proxy encaminham o desafio ao UA numa mensagem “407Proxy Unauthorized Request”. De uma forma geral, se a solicitação é feita ao dispositivo SIP final (como no caso de uma mensagem de registro), o desafio é retornado numa mensagem 401, caso contrário o desafio é retornado numa mensagem 407 (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
Muito mais sobre autenticação SIP pode ser encontrado em (JOHNSTON, 2009) e (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
SRTP e SRTCP
O SRTP é um perfil seguro do RTP, definido no RFC 3711, (BAUGHER, 2011), que oferece autenticação, confidencialidade e integridade do fluxo de mídia. Em seu projeto, questões de relacionadas ao consumo de banda, processamento e latência da comunicação foram levadas em consideração para garantir a eficiência do protocolo.
O protocolo usa um esquema de chaves simétricas que devem ser negociadas pelo modelo offer/answer com o SIP. Para a criptografia o algoritmo usado é o AES-CTR (Advanced Encryption Standard – Counter Mode) com 128 ou 256 bits, que executa uma operação XOR (Exclusive-OR) sobre o fluxo de mídia. Isso permite que a criptografia seja executada em paralelo com a codificação, diminuindo a latência introduzida pelo processamento (JOHNSTON, 2009).
O pacote SRTP é idêntico ao pacote RTP em sua estrutura, contudo o payload é criptografado e é adicionado um campo Authentication tag. Opcionalmente, um campo MKI (Master Key Index) (BAUGHER, 2011).
Como o fluxo do RTCP é totalmente separado do fluxo RTP (os protocolos usam portas diferentes para comunicação), há também a necessidade de que aquele seja protegido para que se previnam ataques que degradem ou interrompam a troca de mensagens RTCP e, consequentemente, a qualidade do fluxo de mídia.
Para isso, em (BAUGHER, 2011) também é definido o SRTCP (Secure Real-time Transport Control Protocol). O mesmos campos adicionados no SRTP também são usados no pacote SRTCP, mas outros dois cabeçalhos também são incorporados: SRTCP Index, cuja função é identificar os pacotes RTCP evitando ataque por repetição e o Encrypt-flag, um campo de 1 bit que indica que o corpo do RTCP foi criptografado (THERMOS e TAKANEN, 2007).
|