Um Framework Seguro para Aplicações Multimídia em Redes

Um Framework Seguro para Aplicações Multimídia em
Redes Convergentes
Gustavo Passos Tourinho, Roberto Costa Filho, Alexandre Vieira, Jorge Guedes
Silveira, Ricardo Balbinot
PPGEE – FENG – PUCRS - Laboratório GPARC-TI - Avenida Ipiranga, 6681 – Porto
Alegre – RS – Brasil.
{gtourinho, rcosta, atvieira, jguedes, rbalbinot}@gparc.org
Abstract: This paper shows us convergent networks problems when used
together with Firewall / NAT security devices. It also proposes a solution to
this problem with the introduction of new elements on network environment.
Those elements work as a module, so it can be used without configuration’s
need on devices already configured.
Resumo: Este artigo descreve os problemas encontrados nas redes
convergentes com os dispositivos de segurança Firewall / NAT. Também é
proposta uma solução para tal com a introdução de elementos terceiros no
ambiente de rede. Tais elementos são agregados à rede na forma de um único
módulo, não ocasionando necessidade de uma nova configuração nos
dispositivos existentes.
1. Introdução
Com a introdução do conceito de Redes Convergentes [1] nas redes de
computadores atuais, alguns dispositivos necessitaram de alterações no seu modo
funcionamento, devido ao conflito destes com o modo de operação dos aplicativos de
voz e vídeo agregados a este novo conceito. Os dispositivos em questão são, justamente,
os responsáveis pela segurança da rede capaz de assegurar que nenhuma pessoa não
autorizada terá acesso às informações confidenciais. Iremos focar o trabalho em dois
principais, o Firewall e o NAT.
Através da utilização e um módulo seguro, composto por diversas entidades de
rede, é possível resolver o problema das redes convergentes. Aqui será apresentada uma
possível solução para o problema da utilização dos dispositivos de segurança em
harmonia com aplicativos que agregam o conceito de redes convergentes.
2. Trabalhos relacionados acerca da solução
Paulsamy e Chatterjee [2] apresentam três soluções para este problema. A
primeira solução é a utilização de um Proxy para controlar o Firewall / NAT. Nela é
apresentado que a inteligência da aplicação ficará externa aos dispositivos de borda,
sendo encontrada no Proxy, o qual será responsável pelo controle das ações realizadas
pelo Firewall / NAT. Entretanto, é necessário um protocolo capaz de efetuar a
comunicação entre o Proxy e o Firewall / NAT. Esta solução não é descrita.
A segunda solução descrita por [2] seria realizar uma nova configuração no
Firewall / NAT de forma que a sinalização SIP fosse controlada por [3]. O Firewall
deverá possuir três interfaces de rede sendo uma conectada aos agentes SIP, outra
conectada a rede pública (Internet) e a última interface conectada ao Proxy RTP e SIP,
em uma zona desmilitarizada [4]. Esta solução, por sua vez, não permite uma
atualização automática dos dispositivos, de modo que a cada nova versão de software do
Firewall / NAT, uma nova versão do controlador SIP [3] deverá ser desenvolvida.
Uma terceira solução é descrita por [2], que utiliza a TSL [5]. Para iniciar uma
sessão é realizado primeiro uma conexão TSL e então utilizar sempre essa conexão para
transmitir pacotes SIP e até mesmo o tráfego RTP, desta forma o fluxo de dados será
transportado em um túnel passando através do Firewall / NAT.
Reynolds e Ghosal [6] propõem o STEM (Secure Telephony Enabled
Middlebox) como forma de solução para o problema das redes convergentes. Esta idéia
tem como base a utilização de um elemento que controla as ações executadas pelo
Firewall / NAT. O Security Manager [6] é encarregado desta função, sendo auxiliado
pelo Protocol Parser [6] que realiza a inspeção dos pacotes com destino a porta 5060
(SIP). Esta arquitetura utiliza o protocolo TCP, implicando que, além de ser uma
solução proprietária, ainda é dependente do protocolo de transporte.
Kuthan [7] sugere uma maneira similar à [6] de resolver o problema do tráfego
multimídia em redes convergentes. Com a utilização de um Firewall decomposto e um
protocolo de controle, FCP (Firewall Control Protocol), o cliente é capaz de realizar as
ações necessárias para o estabelecimento da comunicação. Todavia, este protocolo não é
padronizado por nenhum órgão.
3. Problemas atuais de tráfego multimídia em Redes Convergentes
Antes de existir uma comunicação multimídia propriamente dita, acontece a fase
de sinalização. Para exemplificar iremos utilizar o protocolo SIP [8] (Session Initiation
Protocol) de forma a estabelecermos uma conexão multimídia.
O SIP utiliza o SDP [9] (Session Description Protocol) no intuito de descrever o
anúncio das sessões multimídias, convite de sessões e outras formas de inicialização
para sessões multimídia. O SDP contém as informações necessárias para o
estabelecimento da conexão, como, IP e porta de origem, tipo de protocolo utilizado,
nome da sessão, entre outras tantas informações. Sendo este protocolo, utilizado para
estabelecer uma conexão, e utilizando o SDP, logo o pacote, além de conter as
informações no cabeçalho, também terá informações extremamente necessárias para a
conexão dentro do conteúdo do pacote, área também conhecida como Payload [10].
Desta forma, se um usuário que está em uma rede privada, dita atrás do NAT,
tentar iniciar uma chamada de voz. O pacote da sinalização SIP, após transpor o
dispositivo NAT, terá somente as informações do cabeçalho alteradas, para ser um
pacote válido na rede pública (Internet). Quando este pacote chegar ao destino, a
aplicação encarregada irá analisar as informações contidas nele. Ao analisar os dados do
SIP ela irá então responder para a origem com base nessas informações. Conforme a
figura 1, o destino irá responder para a máquina com endereço IP 200.17.45.19, valor
adquirido do campo received do pacote e porta 7890, informação adquirida da mesma
forma. Entretanto, o mapeamento feito pelo NAT para a máquina que originou o pacote
(192.168.0.1) é para a porta 8000, informação alterada no cabeçalho do pacote que irá
transpor o dispositivo de rede. Logo, a resposta ao chegar ao NAT será descartada, pois
é esperada uma resposta na porta 8000 e não em uma porta desconhecida, ou não
mapeada, pelo NAT, no caso a 7890, causando assim a falha na sinalização SIP.
Abaixo, a figura 1 ilustra melhor o problema do NAT.
Figura 1. O Problema do NAT
O segundo problema encontrado pelos aplicativos multimídia em redes
convergentes diz respeito ao funcionamento do Middlebox Firewall.
A configuração de um Middlebox Firewall parte do princípio de que todos os
serviços devem ser negados, em outras palavras, que todos os pacotes que chegarem à
rede devem ser descartados. Após isso, é definido um conjunto de políticas de regras
que possibilitam a transposição dos pacotes endereçados às portas de serviços bem
conhecidas, como, a porta 80 para servidor Web, porta 21 para servidor de transferência
de arquivos FTP, entre outras tantas.
O problema em relação ao tráfego multimídia é justamente na definição das
regras para os pacotes que chegam à rede. O RTP (Real-Time Protocol) e RTCP (RealTime Control Protocol) [11] utilizam uma faixa aleatória de portas para a comunicação,
e a permissão para transposição de tal faixa, nas regras do Middlebox Firewall, iria
comprometer seriamente a segurança da rede.
Em outras palavras, supondo que um usuário externo A deseja iniciar uma
comunicação de voz com um usuário B, localizado em uma rede privada. Supondo
também que a fase de sinalização tenha sido completada sem problemas. Ao iniciar o
tráfego multimídia, partindo do usuário A, em direção ao usuário B, estes dados
passarão por um dispositivo que filtrará os pacotes e irá compará-los com sua tabela de
políticas regras.
O tráfego multimídia irá usar uma porta escolhida aleatoriamente e o Middlebox
Firewall possui em sua tabela de regras, somente, a descrição das portas dos serviços
bem conhecidos. Logo, o Middlebox ao analisar a porta destino do pacote que chega à
rede e compará-la a sua tabela irá descartar o pacote, pois a faixa aleatória de portas não
deverá estar explicitada nas regras, causando assim falha na comunicação.
4. A Proposta para o Módulo Seguro
A proposta que incentivou o desenvolvimento desde módulo seguro foi devido à
necessidade de solução para o problema de Firewall/NAT em redes convergentes. O
objetivo principal deste trabalho é a implementação de um protótipo capaz de solucionar
os problemas mostrados anteriormente.
O objetivo secundário deste trabalho visa suprir a carência de soluções baseadas
em software livre. A necessidade de sistemas abertos para o problema das redes
convergentes levou o trabalho a ser baseado nesta filosofia.
É possível destacar também a necessidade do laboratório GPARC-TI, que
realiza pesquisa voltada para este tipo de rede emergente. Desta forma, os
conhecimentos adquiridos no estudo do Framework, serão utilizados em propósitos
próprios.
A proposta apresentada neste trabalho utiliza entidades externas para controlar
os dispositivos Firewall / NAT. Entretanto, além dessas entidades, também existirão
outras que irão fazer a comunicação entre as máquinas que executam a aplicação e as
entidades que controlam o Firewall / NAT.
O Framework, então, é composta por três tipos de entidades, os agentes, a
entidade encarregada das operações ALG e a entidade lógica PDP. Além destes tipos,
ainda existe o protocolo de comunicação utilizada.
A utilização de agentes MIDCOM permite que a inteligência necessária para
executar as operações nos dispositivos Firewall/NAT, fique externa. Desta forma, esses
elementos não precisam alocar seus recursos computacionais para tais tarefas,
realizando somente o que é desejado que eles façam, como por exemplo, filtrar pacotes
e realizar a tradução dos endereços. Os agentes geralmente são combinados com os
ALGs, de forma a realizar as operações necessárias para a transposição do fluxo
multimídia pelo Middlebox.
A entidade ALG fica responsável por toda a comunicação referente à
transposição do tráfego pelo Middlebox. Por exemplo, um usuário necessita que o
Firewall permita o fluxo de dados na porta X. A função do ALG é inserir as regras
necessárias para essa operação, permitindo assim, um pinhole [12] no Firewall. O
pinhole é a operação de definir, dinamicamente, nas regras do Firewall que um
determinado fluxo irá transpor o Middlebox em uma porta específica, no exemplo a
porta X.
A última entidade é a PDP. Essa entidade será responsável pelo gerenciamento
de acesso ao Middlebox. Sua presença no módulo é necessária para que seja possível
definir níveis de acesso ao elemento, assim como, definir quais agentes tem permissão
de conectar no Firewall / NAT. Além disso, o PDP também desempenha uma função de
segurança para o Middlebox, pois ele é responsável pela autenticação da conexão entre
o dispositivo e o agente MIDCOM.
Cada novo agente que for incorporado ao módulo deve realizar o registro no
PDP, para que desta forma possa conectar-se ao Middlebox.
Por fim, é necessário o desenvolvimento de um protocolo para realizar a
comunicação entre todas essas entidades. O protocolo MIDOM permite que se
exteriorizem as entidades do Middlebox, possibilitando assim, que o módulo seguro
proposto seja acoplado a um ambiente de rede e funcione sem a necessidade de
configurações extras.
5. Funcionamento do Módulo
A comunicação feita entre as entidades que compõem o módulo é feita com o
protocolo MIDCOM, como dito anteriormente, a utilização deste permite que o
processamento das informações seja feito externo ao Middlebox.
As entidades ALGs são as responsáveis no auxílio ao Middlebox. No caso de
um NAT, a entidade ALG irá tratar o pacote de forma que este possa transpor o
dispositivo sem problemas.
No desenvolvimento dessas entidades serão utilizadas as bibliotecas libpcap [13]
e libnet [14]. Essas bibliotecas são utilizadas para a manipulação das informações
contidas nos pacotes.
A alteração das informações dos pacotes é uma solução necessária para o
problema referente ao NAT, logo, iremos utilizar as bibliotecas de forma a capturar os
pacotes que estão passando pelo ALG, examinar o conteúdo, realizar alguma
comunicação com o Middlebox, se necessário, para receber informações, alterar os
campos devidos e injetar o pacote na rede de modo a ser encaminhado até o destino.
Para solucionar o problema relativo ao Firewall, o ALG irá proceder de forma
similar. O pacote é capturado e, então, analisado. Após obter as informações necessárias
para a comunicação multimídia, o ALG realização as alterações devidas nas regras de
filtragem do Firewall, permitindo assim que os dados multimídia possam transpor o
Middlebox sem problemas.
Quando uma conexão for finalizada, o processo reverso deve ser feito no
Middlebox. Para o caso do Firewall, o pinhole feito anteriormente deve ser fechado, de
forma que a segurança da rede volte ao estado inicial.
Os agentes MIDCOM são os responsáveis pela comunicação entre dois pontos
que compõem o Framework. Ou seja, a comunicação é feita entre eles no auxílio ao
Middlebox, para permitir a transposição do tráfego. Os agentes possuem o
conhecimento necessário para realizar essa tarefa e, auxiliado pelo ALG, efetua as
operações necessárias no Middlebox para que a solução do problema de tráfego
multimídia seja possível.
Cada fez que um agente inicia uma conexão com o Middlebox, o PDP realiza
sua função de gerenciador. Quando o PDP detecta esse inicio de conexão, ele verifica
em seu repositório de políticas se o agente em questão tem permissão de conectar no
Middlebox. Caso exista essa condição, o PDP executa a validação para a tarefa que o
agente deseja executadar no Middlebox. Tendo permissão, o Firewall / NAT executa a
função especificada pelo agente, caso contrário, o PDP pode informar à ele que termine
a conexão com o agente em questão.
A figura 2 ilustra o framework composto por estas entidades e suas
comunicações descritas acima.
Figura 2. Comunicação entre entidades
Para garantir um nível ainda maior de segurança, a utilização do conceito de
DMZ em conjunto com o módulo é uma alternativa sólida devido aos benefícios que
esse conceito traz. A figura 3 ilustra as ações realizadas para que uma comunicação
multimídia possa transpor os mecanismos de segurança de uma rede que utiliza DMZ.
Figura 3. Framework em funcionamento
1 - Um usuário externo A deseja realizar uma chamada de voz para um usuário
B que está localizado dentro de uma rede privada. Ele envia um pacote INVITE. Este
pacote possui a porta de destino 5060 (SIP). Ao chegar no Middlebox, este deve estar
devidamente configurado para aceitar pacotes com porta de destino 5060, será
encaminhado para o Proxy SIP-ALG que irá retornar 100Trying para a origem,
usuário A.
2 – O Proxy informa ao Middlebox que necessita de um mapeamento para a
porta 5060 e recebe uma resposta informando a notificação. Então o Proxy pergunta ao
Middlebox sobre informações que descrevem o fluxo da sessão e recebe a resposta. O
Proxy identifica o endereço IP privado do destino e identifica também as portas UDP do
destino usadas para a transmissão RTP e RTCP (RTP1, RTCP1) no sentido rede privada
rede pública. O Proxy informa ao Middlebox para criar as sessões RTP1 e RTCP2,
associando esta ao fluxo SIP e recebe confirmação. Agora o Proxy informa que o
Middlebox deve realizar o pinhole para permitir que o tráfego com destino a RTP1 e
RTCP1 possa sair da rede, nomeados Eport1 e Eport1+1. Após realizar a operação, o
Middlebox responde ao Proxy que a operação foi concluída. O Proxy transmite um
INVITE ao Middlebox.
3 – O Middlebox redireciona o INVITE até o destino.
4 – O destino envia 180Ringing para origem (Proxy) que por sua vez reenvia
para o usuário externo A.
4 – O destino atende a chamada, enviando 200OK.
5 – Proxy identifica as portas UDP usadas pelo usuário interno para o tráfego
RTP2, RTCP2. Então indica ao Middlebox para criar mapeamento destas portas para o
usuário privado, Pport2 e Pport2+1. Após receber a confirmação do Middlebox, o Proxy
indica que ele deve realizar agora a operação para criar as sessões do tráfego RTP2 e
RTCP2 e associar ao fluxo SIP. Recebe a confirmação do Middlebox e modifica os
parâmetros SDP, na resposta “200 OK”, com as informações indicadas pelo
Middlebox para o tráfego RTP2. Por fim, notifica ao Middlebox a necessidade do
pinhole para permitir que o tráfego com destino a RTP2 e RTCP2 possa entrar na rede.
Proxy recebe confirmação do Middlebox.
6 – Proxy envia 200OK ao usuário A indicando que a fase de sinalização foi
concluída. Usuário externo A envia ACK para o Proxy que redireciona ao usuário
privado B.
7 – É estabelecida a conexão RTP/RTCP ponto a ponto entre os usuários A e B.
Quando um dos participantes desejarem terminar a conexão, o processo reverso
é feito. Os pinholes são fechados e os mapeamentos, realizados pelo NAT, desfeitos.
Mantendo assim a estabilidade e segurança da rede no estado inicial.
6. Validação do Framework
De forma a validar o protótipo do Framework, foram utilizadas diversas
ferramentas para captura de tráfego, permitindo a avaliação do comportamento de cada
pacote.
Com a utilização do ethereal [11], foi possível analisar os dados dos pacotes.
Desta forma, assegurou-se que as entidades que compõem o Framework estavam
modificando, de forma correta, as informações no payload do pacote, bem como foi
possível verificarmos se essas informações estavam criptografadas. Garantindo assim,
que mesmo o pacote sendo capturado por pessoas não autorizadas, estas não terão
acesso às informações. Assegurou-se então, que os dados não serão obtidos de forma
legível, senão pela entidade de destino.
Para validar as operações realizadas pelo Firewall, foi necessário um
monitoramento constante do estado de suas regras, para os pacotes que chegam e saem
da rede, para tal, utilizou-se um software de monitoramento de tráfego chamado
etherape [12].
7. Conclusões
É possível concluir que o estudo realizado permite benefícios para ambos os
meios, acadêmico e comercial, pois esta é uma solução desejada para redes
convergentes, não interessando o ambiente onde este novo conceito se aplica.
Da mesma forma, é possível identificar que os pontos de falha para a segurança
continuam os mesmo, muito embora exista a adição de novos elementos na rede que
compõem o módulo. Para este problema existem os métodos tradicionais de segurança
de redes, como por exemplo, a utilização de IDS (Intrusion Detection System),
HoneyPots, entre outros tantos mecanismos amplamente conhecidos.
A proposta de um módulo dito seguro é justamente de adicionar novos
elementos na rede, que funcionem de forma a solucionar um determinado problema e
não possibilite brechas no sistema previamente implantado.
8. Bibliografia
[1]
DE SERRES, Y. and HEGARTY, L. (2001). "Value-added services in the
converged network", in: Communications Magazine, IEEE
[2]
PAULSAMY, V. and CHATTERJEE, S. (2002) “Network Convergence and the
NAT/Firewall Problems”, in: Proceedings of the 36th Hawaii International Conference
on System Sciences (HICSS’03), IEEE.
[3]
FREDRIK T., BERTIL E. (2000) "SIP Firewall Solution," Internet Draft,
Internet Engineering Task Force, Work in progress. Julho
[4]
SHIMONSKI, R. (2003) “Building DMZs for Enterprise Networks”, in:
Syngress Publishing, Inc., Rockland.
[5]
BLAKE-WILSON, S. (2003) “Transport Layer Security (TLS) Extensions”,
http://www.ietf.org/rfc/rfc3546.txt?number=3546, Abril.
[6]
REYNOLDS, B. e GHOSAL, D. (2002). "STEM: Secure Telephony Enabled
Middlebox", in: Communications Magazine, IEEE
[7]
KUTHAN, J. (2001). "Internet Telephony Traversal across Decomposed
Firewalls and NATs", in: Internet Telephony Workshop 2001 Technical Program
[8]
HANDLEY,
M.
(1999)
“SIP:
Session
http://www.ietf.org/rfc/rfc2543.txt?number=2543, Janeiro.
Initiation
Protocol”,
[9]
HANDLEY,
M.
(1998)
“SDP:
Session
http://www.ietf.org/rfc/rfc2327.txt?number=2327, Janeiro.
Description
Protocol”,
[10] TANENBAUM, A. S. (1997) “Redes de computadores”, in: Rio de Janeiro:
Campus.
[11] SCHULZRINNE, H. (2003) “RTP: A Transport Protocol for Real-Time
Applications”, http://www.ietf.org/rfc/rfc3550.txt?number=3550, Fevereiro.
[13] FUKUYAMA, N. (2003) “Firewall-Friendly VoIP Secure Gateway and VoIP
Se2urity Issues”, http://www.fujitsu.com/downloads/MAG/vol39-2/paper05.pdf, Junho.
[13]
TCPDUMP. (2004) “TCPDump / Libpcap”, http://www.tcpdump.org/, Junho.
[14]
LIBNET. (2004) “Libnet”, http://libnet.sourceforge.net/, Junho.
http://www.ietf.org/rfc/rfc3304.txt?number=3304, Janeiro.