Análise e Verificação 50

Para que o processo de análise/teste tenham a mesma quantidade de tráfego, pelo menos no que diz respeito aos dados RTP, será usado um ficheiro .pcap (packet capture) com um som já gravado (ver Figura 3.10), com a duração de 18,98 segundos.

Figura 3.10. Som existente no ficheiro pcap.

Este ficheiro é composto por 949 pacotes UDP que possuem o som a transmitir (ver Figura 3.11).

....

Depois de todo o processo de estabelecimento da chamada, e segundo a configuração do XML, este som será enviado através do Protocolo RTP (ver Figura 3.12). Trata-se do mesmo conteúdo, mas com protocolo de transporte diferente.

Figura 3.12. Transição para pacotes RTP.

3.4 Resumo

Neste capítulo propôs-se uma arquitetura para um sistema de avaliação do desempenho de sistemas VoIP seguros. Foi também identificada a metodologia de preparação dos diferentes cenários de teste, e as métricas a serem usadas na avaliação.

4. Implementação

Nesta secção será apresentada uma concretização do sistema de avaliação de desempenho de sistemas VoIP seguros, explicitando para cada componente da arquitetura quais as ferramentas escolhidas, bem como a forma como foram usadas e instaladas, no cenário de teste laboratorial adotado.

4.1 Introdução

Para o cenário de teste inicial e básico, foram usados três computadores, um com o softphone Yate [34], outro com o softphone SFLphone [35] e o terceiro com o software AsteriskNOW [36] instalado. Mais informações sobre as máquinas podem ser consultadas na Tabela 4.1.

Figura 4.1. Cenário experimental.

Sugestão: Nos Sistemas Operativos (SO) Linux e CentOS as informações do SO podem ser obtidas através do comando “lsb_release -a”, já no SO Mac OS X podem ser obtidas através do comando “system_profiler SPSoftwareDataType”.

Tabela 4.1. Características das máquinas envolventes.

Identificador Ferramenta Sistema Operativo Especificações do sistema

Cliente 1002 _4.2.0 Yate Versão 10.7.5 Mac OS X 64 bits

Processador: 2,4GHz Intel Core i5 Memória RAM: 4GB 1333 MHz DDR3 Disco rígido: 750GB

Cliente 1003 SFLphone _1.3.0 Linux Mint 16 Petra Edição: Cinnamon 32 bits

Processador: 1.66GHz Intel Atom N280 Memória RAM: 1 GB

Disco rígido: 250 GB Servidor Asterisk AsteriskNOW _3.0.1 CentOS 6.5 _{32 bits}

Processador: 3.10GHz Intel Core i3- 2100

Memória RAM: 2 GB Disco rígido: 40 GB

Esta experiência terá como objetivo inicial o de auxiliar a interpretação de quais as mensagens necessárias para a realização de uma chamada. A ordem e os dados contidos nas mensagens serão um auxílio para a criação do XML.

Depois de efetuado o teste entre os dois softphones e com o auxilio da ferramenta Wireshark [37], capturou-se uma chamada no lado do recetor (ver Figura 4.2) e outra do lado de emissor (ver Figura 4.3), e posteriormente aplicou-se um filtro, em cada um, para obter pacotes correspondentes a cada chamada. De notar, que por questões de simplicidade de leitura, as imagens apenas apresentam dois dos 949 pacotes RTP.

Figura 4.3. Pacotes existentes na chamada selecionada do cliente 1003.

Após alguns testes, foi possível visualizar que na configuração do Asterisk existem mais mensagens a serem trocadas do que esperado na secção 3.3, pois constatou-se que um cliente antes de efetuar ou receber qualquer chamada, tem de estar registado na base de dados do Servidor Asterisk e antes de efetuar um pedido de chamada, tem de se a autenticar.

Depois de uma análise cuidada, foi possível deduzir o diagrama de sequência apresentado na Figura 4.4, onde se pode observar a sequência de mensagens necessárias para uma chamada VoIP bem sucedida.

Figura 4.4. Mensagens necessárias numa chamada.

O registo inicial, de cada cliente, é feito através da mensagem “Register”, que indica a intenção de registo. O Servidor Asterisk envia uma mensagem “Unauthorized”, ao cliente em questão, indicando que não foi autorizado a registar-se e lança-lhe um desafio. O cliente envia outra mensagem de “Register”, mas agora com autenticação. Se tudo correr bem o Servidor envia uma mensagem “OK”.

Para se proceder ao estabelecimento de uma chamada existe um conjunto de mensagens que são necessárias, tais como a mensagem “Invite”. Esta mensagem indica intenção de realização de chamada. O Servidor responderá com a mensagem “Unauthorized”, mencionando que não foi autorizando a realizar a chamada e volta a lançar um desafio ao cliente. O cliente envia uma mensagem de “ACK” e logo a seguir uma mensagem de “Invite”, onde contém a autenticação e informação SDP (Session Description Protocol). A informação SDP serve para negociar parâmetros de sessão, tais como descrição da sessão (versão do protocolo SDP, criador e identificador de sessão, etc), descrição do tempo de sessão, descrição media e quais os codecs disponíveis (ver o secção 2.1.4). Assim que o Servidor receba a mensagem “Invite”, este

enviará uma mensagem de “Trying”, indicando que está a tentar estabelecer a chamada, e outra de “Ringing”, indicando que o telefone está a tocar, estas duas mensagens são enviadas ao Servidor e deste para cliente que iniciou todo o processo. Numa fase quase final das mensagens de sinalização, o cliente contactado envia uma mensagem de “OK”, com informações SDP, ao Servidor e o Servidor ao cliente 1002. Se tudo estiver correto o Cliente 1002 envia uma mensagem “ACK” ao Servidor e este ao cliente 1003. Finalmente os clientes passam a trocar pacotes RTP entre si, ou seja, a chamada é estabelecida e os cliente iniciam um diálogo.

Quando um dos clientes pretender finalizar a chamada, será enviada uma mensagem “BYE” ao servidor e este enviará um “OK”, indicando que a chamada foi finalizada. O Servidor por sua vez contacta o outro cliente com a mensagem “BYE” e este responde com “OK”.

4.2 Rede

O cenário de rede adotado para a realização dos testes, é semelhante ao cenário apresentado anteriormente. As máquinas que se fazem passar por clientes, neste cenário, contêm um emulador de tráfego, o SIPp. Este emulador irá permitir, com a ajuda do ficheiro XML, simular um estabelecimento de uma, ou várias, chamada(s) VoIP.

Adicionou-se uma máquina com o software CACTI, que é uma ferramenta para monitorização da rede, que será abordado na secção 4.4.1.2.

Todas as características de cada componente, do cenário descrito na Figura 4.5, poderão ser encontradas na Tabela 4.2.

Tabela 4.2. Características dos componentes envolventes.

Identificador Descrição Sistema Operativo Especificações do sistema

1

(193.136.9.112) Cliente 1002

Mac OS X Versão 10.7.5

64 bits

Processador: 2,4GHz Intel Core i5 Memória RAM: 4GB 1333 MHz DDR3 Disco rígido: 750GB

2

(193.136.9.111) Cliente 1003

Linux Mint 16 Petra Edição: Cinnamon

32 bits

Processador: 1.66GHz Intel Atom N280

Memória RAM: 1 GB Disco rígido: 250 GB 3

(193.136.9.113) CACTI

Linux Mint 16 Petra Edição: Cinnamon

32 bits

Processador: 2.80GHz Intel Celeron Memória RAM: 1 GB

Disco rígido: 73 GB 4

(193.136.9.110) Servidor Asterisk CentOS 6.5 32 bits

Processador: 3.10GHz Intel Core i3- 2100

Memória RAM: 2 GB Disco rígido: 40 GB

5 Switch _{(com 48 portas de 100Mbps e 2 portas de 1Gbps)} Cisco Catalyst 2950

Quanto à capacidade da rede, e segundo a ferramenta iperf, o cenário apresentado na Figura 4.5 possui uma capacidade de 94,1Mbits/s (ver Figura 4.6).

O iperf [38] é uma ferramenta de código aberto, desenvolvida em C++, que funciona sobre os Sistemas Operativos Linux e Windows e tem como objetivo medir o desempenho da rede, nomeadamente a largura de banda, o jitter e o packet loss. Possui funcionalidade de cliente/servidor, assim como faz as medições de forma unidirecional ou bidirecional (exemplo no servidor: #iperf –s; no cliente: #iperf –c 193.136.9.110).

4.3 Configurações de segurança

Neste tópico serão apresentadas todas as configurações de segurança usadas para o TLS e para o IPSec.