Next: Implementação Up: Um Sistema de Testes Previous: Sniffers Sumário
Sniffers são em geral agentes passivos. Em outras palavras, eles raramente interferem no funcionamento da rede. Um sniffer ideal (no sentido de ser invisível aos usuários da rede) não injeta pacotes na rede, não responde a qualquer tipo de requisição e não precisa sequer ter um endereço da rede. Um exemplo de tal sniffer seria um dispositivo eletrônico qualquer capaz de capturar o tráfego diretamente do meio de transmissão sem a necessidade de pertencer formalmente à rede, trabalhando de maneira totalmente passiva. Detectar tal dispositivo seria uma tarefa de extrema dificuldade.
Felizmente, sniffers ideais como o citado acima são muito raros e, na prática, a principal característica visível de um sniffer é uma interface em modo promíscuo sem o aval do administrador da rede. É essa a característica geralmente procurada por um detector de sniffers.
Entre as diversas técnicas e ferramentas existentes para o cumprimento de tal tarefa, podemos destacar as relacionadas abaixo.
Os detectores de intrusão (Intrusion Detection Systems - IDS), tanto os destinados à redes (Network Intrusion Detection Systems - NIDS) como os destinados a uma única máquina (Host Based Intrusion Detection Systems) são caracterizados pela análise de tráfego e informações que evidenciem tentativas ou ocorrências de ataques, atuando como espécies de alarmes. IDSs são itens indispensáveis a redes nas quais haja um sério comprometimento com a questão da segurança.
Um detector de sniffers pode ser considerado uma espécie de NIDS (ou uma extensão destes), embora seu funcionamento e implementação, de um modo geral, sejam bastante diferentes.
Na detecção local, o administrador do sistema precisa procurar por
características de sniffers diretamente em
cada máquina conectada à rede, sendo a principal delas a configuração
da interface em modo promíscuo e certos processos em execução. Uma
alternativa à verificação manual é um serviço que fique em execução![[*]](footnote.png)
em cada máquina
disparando um alarme quando alguma interface entrar em modo promíscuo
ou tráfego de rede não endereçado à máquina em questão for recebido
pelas camadas superiores da pilha de rede.
Apesar de ser um método determinístico, a detecção local tem sérias desvantagens:
A detecção remota consiste na análise do tráfego da rede à procura de ``assinaturas'' típicas de sniffers ou de interfaces em modo promíscuo. Tais assinaturas possuem características decorrentes de peculiaridades do sistema operacional, do software em execução ou mesmo do hardware. Cabe a um detector o papel de explorar essas peculiaridades, muitas vezes enviando tráfego que dispare um determinado comportamento na máquina remota. Dentre essas características, uma possível classificação dos testes remotos é a de ativos e passivos, no sentido de alterarem ou não o estado da rede através da injeção de pacotes.
Dado que sniffers são geralmente programas executados a partir de máquinas de uso geral e assumindo que tais máquinas têm uma implementação de uma pilha TCP/IP e outros protocolos e serviços disponíveis à rede, pode-se desenvolver testes remotos que explorem suas características.
Como a definição do comportamento de uma pilha TCP/IP é bastante
flexível e não aborda todas as combinações possíveis de pacotes e
opções (flags), ela é implementada de
inúmeras maneiras diferentes. É possível, por exemplo, a detecção da
versão do sistema operacional e diversas outras características de uma
máquina através de uma técnica conhecida como ``TCP/IP
Fingerprinting'', através da qual são analisadas respostas
a determinados tipos de requisições e reações a comportamentos
inesperados [18].
A maioria dos testes remotos baseiam-se na exploração de características de determinadas implementações da pilha TCP/IP e do próprio driver de rede, especialmente as mais comuns em sistemas operacionais atuais.
As próximas subseções contêm uma explicação detalhada dos métodos conhecidos [20] para a detecção remota de sniffers ou de interfaces trabalhando em modo promíscuo.
Um dos testes de detecção remota mais conhecidos consiste no envio de um pacote do tipo ICMP ECHO REQUEST utilizando um endereço destino de hardware adulterado de modo a não ser normalmente aceito pela máquina suspeita, a não ser que esta se encontre em modo promíscuo. Uma resposta a esse tipo de requisição indica que a máquina testada está recebendo tráfego através de uma interface de rede em modo promíscuo.
Excluindo-se o endereço de broadcast e os endereços de multicast [11] configurados para serem aceitos, uma interface de rede trabalhando em modo normal só deveria aceitar quadros enviados com seu próprio endereço de hardware no campo de destino.
Uma interface trabalhando em modo promíscuo passa todo quadro recebido às camadas superiores da pilha de rede. Por questões de modularidade e eficiência, tais camadas fazem poucas verificações nos endereços de hardware dos quadros repassados. É enviando pacotes com endereços de hardware válidos dentro destas verificações, porém fora do conjunto de endereços normalmente aceitos pela interface (broadcast, multicast e o próprio endereço da interface) que se faz possível a realização deste teste.
Tomando como exemplo uma implementação do módulo de rede do kernel
Linux versão 2.4, quando um endereço de hardware não coincide com o
endereço da própria interface, seu primeiro octeto é testado contra o
valor 0xff. Caso este teste seja
verdadeiro, assume-se que foi recebido um quadro do tipo broadcast ou multicast. Não
sendo do tipo broadcast, este mesmo octeto é testado
novamente; se for ímpar, assume-se que o quadro é do tipo multicast, caso contrário ele é sumariamente
descartado. Tal comportamento pode ser evidenciado nas funções ip_rcv(), eth_type_trans() e ether_setup() da camada de rede do kernel Linux nas versões 2.2, 2.4
e 2.5.
Este teste também pode funcionar em algumas redes comutadas, uma vez que existem switches que ao receberem pela primeira vez um pacote com endereço desconhecido o repassam a todos os segmentos da rede.
Embora comumente se utilizem pacotes do protocolo ICMP para a realização deste teste, este também pode ser implementado utilizando-se outros protocolos, como HTTP ou FTP.
No restante deste trabalho referimo-nos ao teste de requisições de ICMP com falso endereço físico simplesmente como teste ICMP.
De forma similar ao teste visto anteriormente, este teste utiliza-se de requisições do protocolo ARP (Address Resolution Protocol) [28], que é o protocolo utilizado para converter endereços IP para endereços físicos em redes Ethernet. Neste teste, é feita uma requisição com endereço físico de destino inválido e aguarda-se uma resposta por parte da máquina suspeita.
Explorando a pouca variação nas implementações do sistema de resolução de endereços de determinados sistemas operacionais - até mesmo devida à simplicidade deste protocolo -, este teste mostra-se com um escopo bastante amplo, funcionando, por exemplo, na detecção de máquinas com ambientes Windows, Linux e BSD.
Máquinas geralmente possuem cache de ARP, tornando possível usar uma variação deste teste enviando anúncios ARP com endereço de hardware inválido no intuito de que máquinas com interfaces em modo promíscuo guardem no cache a tupla <IP, endereço físico> recebida através desses anúncios inválidos. Nesse cenário é feita uma requisição qualquer em modo broadcast na rede (como uma requisição de ECHO ICMP) e aguarda-se que alguma máquina (ou máquinas) responda a tal requisição sem fazer uma consulta ARP, o que indicaria a presença de uma interface atuando em modo promíscuo.
Um cuidado deve ser tomado com a ocorrência de falsos positivos, uma vez que se houver tráfego legítimo entre as duas máquinas, estas eventualmente precisarão trocar requisições e respostas ARP. Como não é possível identificar a partir de qual requisição veio uma determinada resposta, o teste pode erroneamente reportar que a máquina está em modo promíscuo.
No restante deste trabalho referimo-nos ao teste de requisições de ARP com falso endereço físico simplesmente como teste ARP.
Para um atacante ou até mesmo um administrador, é muito mais fácil verificar os dados coletados por um sniffer analisando nomes de host ao invés de confusos endereços IP. É principalmente por causa desta razão que muitos sniffers optam por trocar os endereços IP coletados por nomes de host utilizando a funcionalidade de resolução reversa de nomes do DNS.
Tendo acesso físico ao caminho de rede entre uma máquina suspeita e o servidor de nomes utilizado por ela, é possível arquitetar um teste de detecção remota que descubra um sniffer através da verificação da utilização desta funcionalidade (resolução reversa) por parte do sniffer. Para isso, é simulada uma conexão entre uma máquina interna e outra externa à rede testada, com o detalhe de que o endereço IP da máquina externa é escolhido de forma absurda, ou seja, ou ele simplesmente não existe alocado a algum domínio ou é um endereço cuja probabilidade de utilização pelas máquinas da rede testada seja quase nula. A partir disto, espera-se que alguma máquina pertencente ao segmento de rede em que a conexão foi simulada tente acessar o servidor DNS em busca de informações sobre este endereço falso.
O endereço IP utilizado deve ser escolhido com cautela. Este não deve ser comum à rede testada, uma vez que requisições de resolução legítimas geradas pelas máquinas testadas poderiam criar falsos positivos. Além disso, o tráfego simulado deve utilizar um protocolo que seja interessante ao sniffer procurado, evitando ser descartado por um filtro.
Um detalhe a ser considerado nesse teste é que ele pode deixar de
detectar sniffers após um determinado
número de execuções. Isso se dá devido ao fato de que o sniffer pode "desistir" de tentar resolver o endereço
IP após um determinado número de tentativas. Uma vez que o sniffer pode ficar em execução por um longo período de
tempo, recomenda-se que o teste seja feito com endereços IPs diferentes
entre execuções consecutivas.
No restante deste trabalho referimo-nos ao teste de requisições de DNS reverso simplesmente como teste DNS.
Um sniffer pode consumir recursos computacionais consideráveis de uma máquina para fazer coleta e análise de tráfego. Se a interface estiver em modo promíscuo e a quantidade de tráfego for substancialmente grande, a responsividade da máquina pode diminuir de forma perceptível. Uma maneira não determinística mas eficiente de detectar-se a presença de sniffers é através da medida de variação de tal responsividade.
O objetivo do teste de latência é gerar uma condição de negação de serviço (Denial of Service - DoS) na máquina alvo através da utilização de algum tipo de tráfego que sobrecarregue apenas máquinas que estejam com um sniffer em execução. A escolha de tal tráfego deve levar em conta inúmeras variáveis do sistema operacional, do equipamento utilizado e do sniffer em execução.
Esse teste pode ser feito através da medida do tempo de resposta e do número de requisições respondidas com a utilização de requisições ECHO do protocolo ICMP ou através da mensuração da responsividade de qualquer serviço em execução na máquina suspeita.
Como insere uma grande quantidade de tráfego na rede, ele deve ser utilizado com muito cuidado, pois pode interferir no desempenho e funcionamento de serviços daquela. Essa característica faz com que sua utilização seja mais adequada quando já existe a suspeita da execução de um sniffer em alguma máquina. Esse teste deve ser ajustado para a rede em questão e seus resultados analisados com cautela, uma vez que são subjetivos e não determinísticos. A implementação do serviço usado para medição, a situação da rede no momento e vários outros fatores podem afetar o tempo de resposta mensurado.
Abaixo temos uma lista com alguns dos mais importantes fatores que devem ser levados em conta na geração da inundação:
Alguns sniffers analisam os campos internos de pacotes de determinados protocolos para a captura de informações específicas. Entre esses protocolos, podemos citar os que podem conter informações sensitivas como senhas e nomes de usuários e os que têm estrutura complexa, como os pacotes utilizados pelo protocolo de resolução de nomes (DNS). Tais protocolos precisam ser do interesse do atacante para não serem descartados inicialmente no filtro de pacotes do sniffer.
Como o sniffer precisa fazer análise do tráfego baseado em pacotes, os cabeçalhos de todos estes precisam ser abertos. Sendo assim, utilizar um grande número de pacotes pequenos em geral é vantajoso em relação à utilização de poucos pacotes grandes.
A utilização de algumas opções de pacotes TCP e a exploração de algumas características deste protocolo podem esgotar os recursos de um máquina, como descrito em [36,25].
Técnicas de negação de serviço distribuída (Distributed Denial of Service - DDoS) podem ser utilizadas para fazer com que a máquina alvo do teste tenha sua performance (processamento) seriamente comprometida. Nesse cenário, diversas máquinas são utilizadas com o intuito de sobrecarregar a máquina alvo [39]. No caso da detecção de sniffers, conexões com falsos endereços de hardware podem ser utilizadas, sobrecarregando a máquina apenas se esta estiver em modo promíscuo.
É importante levar em conta a capacidade de processamento tanto da máquina alvo como da máquina geradora da inundação. Enquanto que a tarefa de geração de pacotes pode consumir uma substancial quantidade de recursos da máquina, se o alvo tiver grande capaciade de processamento a inundação pode não ter o efeito esperado para este teste. Além disso, a capacidade da rede deve ser levada em consideração, pois se esta não for capaz de suportar a quantidade de tráfego necessária, a inundação não terá o efeito desejado.
Outros estudos sobre ataques de negação de serviço, assim como técnicas para sua contenção podem ser encontrados em [6,34,23].
Como no teste de requisições DNS, é possível implementar esse teste de maneira a testar a existência de sniffers em todas as máquinas da rede ao mesmo tempo, uma vez que a inundação de pacotes é visível a todas elas.
O uso de armadilhas é uma técnica amplamente usada na detecção e estudo de ataques de diversos tipos. Uma armadilha, comumente chamada de ``Honey Pot'', consiste na utilização de ``iscas'' - geralmente máquinas em ambientes bem controlados - para serem invadidas e exploradas por atacantes [13]. A partir das informações coletadas em tais ambientes é possível conhecer melhor o atacante, suas técnicas e em muitos casos chegar à sua identificação.
No caso da detecção de sniffers, pode-se fornecer falsas senhas e informações através de conexões forjadas e então monitorar seu uso na rede, podendo ser utilizados quaisquer protocolos que venham causar interesse a um atacante. O exemplo mais comum é o uso de contas de e-mail (POP/IMAP) cuja autenticação seja feita em texto claro.
Uma possível implementação pode agir como um sniffer procurando pelo uso dos dados falsos ou expandir a armadilha a outros níveis, criando falsos ambientes também para os serviços cujas informações falsas foram disponibilizadas.
A utilização deste tipo de técnica é bastante eficiente pois pode conseguir detectar até mesmo um sniffer totalmente passivo, além de se mostrar muito útil no estudo de hábitos do atacante. Seu grande problema é que a resposta para o teste pode demorar consideravelmente e sua implantação pode exigir alterações nos serviços da rede. Alguns exemplos destas alterações podem ser a implantação de serviços de rede que sejam passivos à atuação dos atacantes e a simulação de ambientes corporativos que atraiam a atenção e previnam a desconfiança por parte dos atacantes.
sniffers em redes comutadas geralmente se fazem passar por outra máquina para receber o tráfego e fazer seu roteamento (veja seção 2.4.2). Para isso, uma das técnicas freqüentemente empregadas consiste no envio de anúncios ARP em excesso para enganar outras máquinas da rede. Tal excesso, comumente chamado de inundação (flooding), constitui uma evidência de um sniffer ou atacante em atuação.
Para a implementação de tal teste de maneira confiável, é necessária a definição de um limiar a partir do qual o número de anúncios é considerado excessivo. Este deve ser ajustado conforme as características da rede e dos sniffers em questão.
O principal problema com os métodos de detecção remotos é que eles, em sua maioria, podem ser evadidos por sniffers ou atacantes que conheçam a metodologia utilizada. Um atacante pode alterar o comportamento do SO ou implementar ``técnicas de detecção das técnicas de detecção'', criando sniffers que reajam aos testes de maneira a não serem detectados. É importante notar que tal evasão não é trivial e não se tem notícia de sniffers que tenham implementado tais técnicas até o momento.
Além disso, a grande variedade nas implementações da pilha TCP/IP se mostra um desafio para a implementação de testes portáveis, que venham a detectar sniffers ou interfaces em modo promíscuo em uma ampla variedade de arquiteturas e sistemas operacionais.
Devido à característica inerentemente passiva dos sniffers e a pressuposição de que uma máquina invadida não é confiável, a tarefa de detecção é complexa. A melhor maneira de proteger os dados em trânsito ainda é o uso da criptografia juntamente com a limitação na disponibilização do tráfego. A utilização de técnicas de detecção porém consiste numa das muitas armas disponíveis aos administradores de redes na luta pela segurança dos dados e, na guerra contra os atacantes, todas as armas têm sua utilização valorizada nas várias frentes de batalha.
Ademar de Souza Reis Jr. 2003-03-11