Next: Conclusão Up: Um Sistema de Testes Previous: Implementação Sumário
Como mostrado no capítulo anterior, foi desenvolvida uma biblioteca de testes e uma aplicação para a detecção remota de sniffers. Neste capítulo relatamos os resultados de tais testes, assim como suas limitações, confiabilidade e fatores que podem influenciar novos experimentos.
Os experimentos aqui relatados foram realizados em ambiente doméstico. A variedade de equipamentos e softwares utilizados é pequena, porém dado que a aplicação é de livre distribuição, espera-se que esta seja amplamente testada e aperfeiçoada por usuários e interessados após o seu lançamento público.
Entre os fatores que mais podem influenciar nos resultados dos testes, podemos citar o sistema operacional utilizado e as configurações deste, o driver da interface e a capacidade da rede, assim como todos os equipamentos e software envolvidos na captura e geração de tráfego na rede.
Os equipamentos empregados nos experimentos estão listados abaixo:
Em termos de software, foram utilizados três sistemas operacionais para os testes: Linux (kernel 2.2 e 2.4), FreeBSD 4.2 e Microsoft Windows 98SE. Dado o pouco domínio sobre estes dois últimos sistemas por parte dos autores, os resultados neles obtidos são menos conclusivos que os obtidos no sistema Linux, extensivamente utilizado para o desenvolvimento do projeto.
A lista de softwares utilizados nos experimentos encontra-se abaixo:
Os sniffers utilizados são bastante flexíveis, oferecendo opções para filtragem de pacotes, visualização de conteúdo em tempo real, resolução reversa de nomes, várias opções para gravação dos dados, etc. Sendo assim, foi possível reproduzir o comportamento de sniffers reais a partir dessas opções de configuração sem grandes dificuldades.
Devido a característica de flexibilidade do projeto, permitindo a alteração dos parâmetros utilizados sem a necessidade de recompilação, conseguiu-se uma quantidade significativa de informações na realização dos testes, porém, demasiadamente grande para serem descritas por completo neste documento.
Nas seções a seguir apresentamos exemplos de execução e particularidades relevantes a cada um dos testes implementados.
O teste de requisições ICMP com endereço de hardware falso é bastante simples. Como o objetivo é descobrir se determinada interface de rede da máquina alvo está operando em modo promíscuo, o sniffer utilizado não é relevante. Na verdade, qualquer ferramenta que configure a interface para trabalhar em modo promíscuo pode ser utilizada.
Em relação aos parâmetros do teste, foram utilizados os seguintes valores:
Todos esses valores são configuráveis pela aplicação de testes, e podem ser alterados conforme as características das máquinas e da rede envolvidas.
A utilização de valores de endereço de hardware iniciados em 0xff se mostrou necessária para que este teste funcionasse, conforme justificativa dada em 3.3.1.
Em todas as execuções desse teste, resultados positivos foram retornados logo após o envio dos primeiros pacotes, frequentemente nos primeiros 2 segundos após a ativação do teste de detecção. A carga da rede não tem influência nos testes. Testes em máquinas com interfaces em modo normal não reportaram falso positivo, retornando sempre após o tempo máximo configurado para o teste.
É importante ressaltar que esse teste não se mostrou efetivo na detecção de interfaces em modo promíscuo no ambiente Windows por nós testado. Acredita-se que o driver da interface em questão tenha algum tipo de filtro embutido, não repassando os pacotes para as camadas superiores da pilha TCP/IP.
Abaixo temos uma pequena lista de execuções:
O teste de requisições ARP com endereço de hardware falso também é bastante simples e assim como o teste ICMP, apenas detecta se a interface da máquina alvo está em modo promíscuo. Foram utilizados os seguintes valores para o teste de requisição ARP:
Todos esses valores são configuráveis pela aplicação de testes, e podem ser alterados para se adequar a particularidades da rede e do ambiente de execução.
Assim como no teste ICMP, foi necessária a utilização de um endereço de hardware iniciado em 0xff para que esse teste se mostrasse efetivo.
Em todas as execuções do teste, resultados positivos eram retornados logo após o envio das primeiras requisições, também frequentemente nos primeiros 2 segundos após a ativação do teste de detecção. Esse teste se mostrou efetivo na detecção de interfaces em modo promíscuo nos três sistemas operacionais testados, porém falsos positivos podem ser reportados caso haja tráfego de rede legítimo entre as duas máquinas, uma vez que não é possível diferenciar uma resposta ARP legítima de uma gerada pela requisição falsa.
Abaixo temos uma pequena lista de execuções:
Para que esse teste seja efetivo, o sniffer deve ter a resolução reversa de nomes ativada. Essa opção é ligada por padrão no Ethereal e em algumas versões do tcpdump. Em ambos a opção pode ser habilitada a partir da linha de comando ou da interface gráfica.
Os pacotes utilizados nas conexões falsas são do protocolo TCP e tem vários dos seus campos de opção preenchidos com valores configuráveis. Em nossos experimentos utilizamos as seguintes opções:
Todos os valores foram escolhidos de maneira arbitrária. A alteração destes se mostra útil em casos particulares, como quando da necessidade de evitar a caracterização do teste ou adequá-lo a um determinado ambiente, mas não é necessária na maioria dos casos.
Comportamento dos Sistemas Operacionais testados:
Como o teste de latência não é determinístico, a análise dos resultados deve levar em consideração várias características do ambiente testado. Uma vez que o objetivo do teste é estressar a máquina alvo, um conhecimento da arquitetura e funcionamento interno do sistema operacional e do sniffer destino se mostra extremamente útil na escolha dos valores utilizados nesse teste e a quem está a interpretar os resultados.
Encontrar a combinação ótima de parâmetros e tráfego a ser utilizado por esse teste requer um estudo que foge do escopo deste trabalho. Com a ferramenta disponibilizada, novos experimentos podem ser realizados e aperfeiçoados num futuro próximo.
Em nossos experimentos, utilizamo-nos de uma sequência de pacotes
TCP com a flag SYN ativada e com a porção de dados vazia ou de tamanho
bastante reduzido![[*]](footnote.png)
. O objetivo da utilização de pacotes com
essas característica foi forçar o sniffer a
processar um grande número de cabeçalhos de pacotes. Essa abordagem
funcionou bem no sistema operacional Linux, mas não gerou resultados
conclusivos nos outros dois sistemas testados (MS Windows 98 e FreeBSD
4.2).
Os valores para o endereço de hardware (MAC) e endereço IP foram escolhidos arbitrariamente, e, se necessário, podem ser alterados para se adequar às características da rede e dos sniffers testados.
Teste 1
Máquina executando o teste:
Máquina alvo do teste:
Parâmetros utilizados:
Pacote utilizado para a inundação:
Os resultados obtidos com tal teste podem ser vistos abaixo:
Interface alvo em modo normal
Interface alvo em modo promíscuo
Como pode ser visto acima, a máquina alvo quando com um sniffer em execução em modo promíscuo não foi capaz de responder todas as requisições ICMP (obtivemos variações entre 30 e 50% de responsividade), e quando o fez, foi com uma demora considerável em relação ao mesmo teste com a interface em modo normal. Esse teste foi repetido várias vezes e os resultados levaram às mesmas conclusões, mesmo sob condições ligeiramente diferentes (tráfego na rede, utilização da máquina para outros fins, etc).
Como nossa implementação insere uma grande quantidade de pacotes ``estranhos'' no barramento da rede, alguns equipamentos reagiram de maneira inesperada à execução de alguns testes:
Modem ADSL: A cada execução do teste de latência, o modem ADSL, que estava no mesmo barramento da rede, perdia a conexão externa com a Internet. O fabricante foi contactado a respeito desse comportamento, mas até o presente momento não obtivemos resposta. Além disso, a interface do modem conectada à rede interna parece estar em modo promíscuo, uma vez que responde positivamente aos testes ICMP e ARP.
Switch: O switch utilizado é bastante simples e apresenta pouca robustez. Durante a inundação de pacotes do teste de latência, este diversas vezes passou a se comportar como um HUB, retransmitindo todos os pacotes para todas as máquinas a ele conectadas.
Máquinas pertencentes ao barramento da rede testado não apresentaram comportamento inesperado durante a execução dos testes ICMP, DNS e ARP. Já na execução do teste de latência, máquinas com interfaces em modo promíscuo tiveram sua responsividade diminuida, uma vez que nesses casos o número de pacotes processados pela pilha de rede do sistema operacional era grande.
Ademar de Souza Reis Jr. 2003-03-11