Projeto Sniffdet - Deteco Remota de Sniffers

O texto desta pgina parte do artigo Um Sistema para a Deteco Remota de Sniffers em Redes TCP/IP, apresentado como trabalho de graduao do curso de Bacharelado em Cincia da Computao da Universidade Federal do Paran. Uma verses em PDFest disponvel no link acima. A implementao do projeto est disponvel em http://sniffdet.sourceforge.net/. Copyright (C) 2002-2003 Ademar de Souza Reis Jr. Copyright (C) 2002-2003 Milton Soares Filho

Agradecimentos Resumo Abstract Introduo Sniffers Redes de Difuso (Meio Compartilhado) Redes Comutadas Modos de Operao da Interface de Rede Utilizao em Ataques Ataque Inicial Anatomia de Ataques com o Uso de Sniffers Ataques a Redes de Difuso Ataques a Redes Comutadas Casos Particulares Evitando o uso Efetivo de Sniffers Limitao da Visibilidade do Trfego Utilizao de Interfaces que No Suportem Modo Promscuo Utilizao de Criptografia Deteco

Deteco de sniffers Detectores de Intruso Deteco Local Deteco Remota Requisio ICMP com Falso Endereo Fsico Requisio ARP com Falso Endereo Fsico DNS Reverso Latncia Armadilha (Honey Pot) Deteco de Inundao de Respostas ARP

Confiabilidade dos Testes

Implementao Preocupaes do Projeto Documentao Licena e Distribuio Ambientao Biblioteca Arquitetura Geral Funcionamento Responsividade Resultado dos Testes de Deteco Teste ICMP Teste ARP Teste DNS Teste de Latncia Aplicao Interface texto Plugins de Relatrios de Resultados Arquivo de Configurao Segurana Consideraes Ps-desenvolvimento

Experimentos e Resultados Ambientao Descrio dos Resultados Teste ICMP Teste ARP Teste DNS Teste de Latncia Comportamentos Inesperados

Concluso Trabalhos Futuros

Pginas de Manual ("Unix Manpages") libsniffdet (3)

sniffdet (1) sniffdet.conf (2)

Referncias Bibliogrficas

Agradecimentos
Nossos sinceros agradecimentos a nosso orientador, professor Dr. Roberto Andr Hexsel, que foi nosso paciente guia durante toda a confecco deste texto. Agradecimentos tambm aos professores Dr. Elias Procpio Duarte Jr. e Armando Luiz Nicolini Delgado e a Andreas Hasenack por suas revises, dicas e sugestes. Estendemos nossos agradecimentos ainda a toda a comunidade de software livre, que nos propiciou excelentes ferramentas e bibliotecas para o desenvolvimento e testes de nosso projeto.

Resumo
Sniffers so ferramentas utilizadas para capturar e opcionalmente analisar trfego de rede. Este trabalho faz uma anlise do funcionamento dessas ferramentas, o potencial perigo de seu uso do ponto de vista da segurana de uma rede e tcnicas de defesa e deteco. Tambm descreve a implementao aberta e de livre distribuio de uma biblioteca e de uma aplicao para a deteco remota de sniffers em redes Ethernet, assim como os resultados obtidos com seus testes.

Abstract
Sniffers are tools used to capture and optionally analyze network traffic. This work discusses their behaviour, potential security risks when used by malicious users in a network and available defense and detection techniques. It also describes the implementation of an open source library and an application for remote sniffer detection in Ethernet networks, and the results of the experiments performed.

Introduo
O assunto ``segurana computacional'' tem sido muito discutido nos ltimos tempos. Como parte importante deste tpico temos as medidas de conteno, cujo objetivo evitar que invases ocorram, e

as medidas de deteco, que procuram por indcios de invases considerando uma possvel falha nas barreiras levantadas pelas medidas de conteno. Nesta ltima categoria entram os conhecidos detectores de intruso e a perspiccia dos administradores de sistemas. Uma das ferramentas mais utilizadas por atacantes o sniffer, um software usado para capturar e analisar trfego de rede. Em ataques simples ou sofisticados, o uso de um sniffer parte importante de sua concepo e efetivao. Com a ainda ampla utilizao de protocolos no criptografados, a utilizao de um sniffer pode revelar dados consideravelmente sensitivos e importantes para os atacantes. importante conhecer a arquitetura e topologia das redes onde um sniffer pode atuar. Porm, independentemente das caractersticas desta, a utilizao de um sniffer por um atacante no deixa de ser um grande risco sua segurana. Neste trabalho so estudadas diversas arquiteturas e topologias, assim como os riscos e potenciais vulnerabilidades destas, em especial quando se tem um sniffer como ferramenta de ataque a ser utilizada. Devido a sua operao inerentemente passiva e o potencial comprometimento prvio da mquina utilizada, tanto a deteco local como a remota de um sniffer tornam-se tarefas difceis. Atravs da compreenso de seu funcionamento e do estudo aprofundado das caractersticas das diferentes implementaes da pilha TCP/IP possvel planejar tcnicas que apontem sua utilizao no autorizada no ambiente de rede testado, mesmo que de forma no determinstica. Este trabalho contm uma anlise das diferentes tcnicas de deteco existentes, mostrando seus pontos fracos e fortes. A falta de uma ferramenta flexvel, de cdigo fonte aberto e de livre distribuio motivou a implementao dos testes discutidos. Os resultados do trabalho aqui exposto so uma biblioteca de testes e uma ferramenta que visa suprir as expectativas de administradores de redes, profissionais de segurana e estudantes da rea de redes. Tal implementao voltada para redes que seguem o padro Ethernet, o mais utilizado entre os padres para redes locais. No captulo 2, discorremos sobre os sniffers, suas origens, utilizao e implicaes prticas na segurana das redes em que so executados. No captulo 3, so mostradas e comentadas diversas tcnicas para a deteco desniffers. O captulo 4 descreve a implementao de uma biblioteca de testes de deteco e uma aplicao que a utiliza. Por fim,

temos os resultados dos testes realizados com a utilizao de tal sistema no captulo 5 e as concluses do trabalho no captulo 6.

Sniffers
Sniffers so ferramentas utilizadas para capturar e opcionalmente analizar trfego de rede. Estes so to antigos quanto as redes de computadores e sua funo originalmente foi a de ajudar desenvolvedores de protocolos e administradores de rede a solucionarem problemas, diagnosticar falhas e levantar dados estatsticos. Um sniffer pode ser utilizado de diversas maneiras e com diversos propsitos, mas seu princpio de funcionamento continua sendo o mesmo: capturar e anlizar trfego de rede sem interferir no funcionamento desta. A arquitetura de um sniffer pode ser vista na figura 2.1. As mais variadas ferramentas se encaixam no conceito de sniffers. Entre elas, existem as benficas, como analisadores de trfego, utilizados para estudo e depurao de protocolos (como por exemplo o Ethereal [16] e o tcpdump [38]), detectores de intruso, que procuram por assinaturas de ataques no trfego da rede (como o Snort [37]) e as que geralmente so utilizados por atacantes ou usurios mal intencionados com o objetivo de capturar senhas e informaes relevantes a partir do trfego da rede.

A topologia da rede, a interface de comunicao e sua operao, os protocolos utilizados e o comportamento dos usurios so fatores importantes ao analisar-se o potencial de uso de um sniffer, principalmente quando o objetivo a captura de informaes alheias. Esses fatores so discutidos no decorrer deste captulo.

Redes de Difuso (Meio Compartilhado)

Redes de difuso so caracterizadas pelo compartilhamento do meio de transmisso de dados, que a camada enlace da rede. Seu uso comum em configuraes de pequeno porte, como redes domsticas e de pequenos laboratrios e escritrios, j que seu custo de implementao baixo. Um caso particular de rede de difuso o das redes sem fio, comumente chamadas de ``wireless''. Nestas, o

compartilhamento do meio - espao fsico - aberto e de difcil limitao. Topologias como ``estrela'' e ``barramento'' so exemplos tpicos de redes de difuso. Em redes que seguem o padro Ethernet, extremamente popular e presente em grande parte das instalaes de redes locais, so utilizadoshubs ou cabos coaxiais para a implementao de redes de difuso.

Redes Comutadas
Redes comutadas por sua vez fazem uso de um enlace dedicado para cada mquina ligada rede. O trfego distribudo com base no endereo de destino dos pacotes atravs de um comutador (um ``switch'' no caso de redes Ethernet). Seu desempenho superior quando comparado s redes de difuso mas seu custo de implementao mais alto, dada a necessidade de hardware especializado.

Modos de Operao da Interface de Rede

No modo de operao normal, uma interface de rede deve descartar o trfego de rede que no a ela direcionado. possvel alterar o modo como uma interface de rede trabalha e fazer com que todo o trfego que passe pelo meio de transmisso seja capturado, no importando a quem ele destinado. Tal modo chamado de ``modo promscuo''. Nas interfaces de comunicao que seguem o padro Ethernet, sua implementao faz parte da especificao e geralmente pode ser habilitado atravs de comandos de software. Uma mquina deve capturar apenas o trfego a ela endereado, descartando os pacotes alheios. Essa seleo de pacotes geralmente feita em nvel de hardware ou firmware, evitando assim que as camadas superiores da pilha de rede, implementadas em software, tenham que se preocupar com tal seleo. Um sniffer pode ser utilizado com a interface de rede em qualquer modo de operao. Sua eficincia em recolher dados porm maior quando a interface est em modo promscuo. Uma mquina com a interface de rede em modo promscuo conectada a uma rede de difuso consiste no cenrio timo para um sniffer, na qual todo o trfego na rede pode ser capturado e analisado.

Utilizao em Ataques

Como ferramenta poderosa que , no demorou para que usurios mal intencionados comeassem a utilizarsniffers para a coleta de dados privilegiados, transformando-os numa das principais ferramentas utilizadas em ataques a redes de computadores. Um sniffer tem o potencial de revelar dados crticos de uma organizao tais como senhas, nmeros de cartes de crdito, correspondncias, documentos, enfim, toda e qualquer informao que trafegue de forma desprotegida pela rede. Ataque Inicial Normalmente, o processo de invaso de uma rede alheia comea quando o atacante obtm algum tipo de privilgio de administrador em uma mquina dessa rede. Isso pode ser conseguido de diversas maneiras, como com a explorao de vulnerabilidades remotas em software da rede, uso de vrus, acesso fsico irrestrito mquinas da rede ou ao meio transmissor de dados e, muito comumente, atravs da utilizao de tcnicas de ``engenharia social'' [32,43], nas quais o atacante obtm acesso ou informaes relevantes sobre o sistema atravs de contato pessoal, muitas vezes fazendo-se passar por outra pessoa. Tm sido relatados os mais inesperados casos de ataques de engenharia social, como por exemplo atacantes que se passam por funcionrios da empresa (mesmo que um inocente faxineiro), analistas de suporte, fiscais de segurana, professores, etc. Truques telefnicos e conversas atravs de meios eletrnicos em geral so fontes comuns de ataques de engenharia social [7]. Estatsticas mostram que agentes j familiarizados com o ambiente da rede, como os prprios funcionrios de uma empresa ou pessoas com acesso fsico irrestrito so as principais portas de entrada no ataque a uma rede. Em pesquisa feita entre empresas brasileiras no primeiro semestre de 2001, 53% dos entrevistados apontaram funcionrios insatisfeitos como a maior ameaa segurana da informao, enquanto que, dos ataques registrados, cerca de 34% se originam de funcionrios, fornecedores ou prestadores de servio [33]. Uma vez que um atacante tenha privilgios de administrador em uma mquina conectada rede, a instalao de um sniffer e outras ferramentas de ataque (como os chamados rootkits ) muito simples e o comprometimento das informaes passa a ser uma mera questo de tempo.

Anatomia de Ataques com o Uso de Sniffers Existem diversos cenrios e topologias nas quais sniffers podem ser utilizados para a captura de informaes alheias. Tcnicas de proteo e evaso desses ataques so discutidas na prxima seo.
Ataques a Redes de Difuso

Redes de difuso apresentam o cenrio timo para um sniffer cujo objetivo seja a captura de trfego alheio. Uma vez que este trfego difundido por todo o barramento, um sniffer localizado em qualquer ponto da rede capaz de captur-lo por completo simplesmente utilizando-se de uma interface de rede em modo promscuo. Tal cenrio exemplificado na figura 2.2.

Ataques a Redes Comutadas

Uma vez que em redes comutadas o meio no compartilhado entre todas as mquinas, a localizao do sniffertorna-se um fator muito importante. A instalao de um sniffer em um servidor ou roteador consite no cenrio ideal, pois este pode capturar o trfego ali canalizado, como exemplificado na figura 2.3, onde o sniffer est no mesmo enlace que uma mquina importante.

Nessas redes, atravs da utilizao de tcnicas que visam ``enganar'' diversos protocolos, possvel a um atacante capturar at todo o trfego da rede mesmo tendo acesso apenas a uma mquina. Neste cenrio, o atacante tenta enganar as mquinas da rede de forma que o trfego seja redirecionado para um local onde possa ser capturado. Agindo como um proxy, o atacante mantm o fluxo normal da rede, evitando que os usurios percebam sua presena. Uma anlise e exemplos deste tipo de ataque podem ser vistos em [40]. A figura 2.4 exemplifica o caso em que uma mquina enganada, tendo seu trfego roteado atravs da mquina de um atacante.

Casos Particulares

Dispositivos no convencionais A utilizao de dispositivos no convencionais vem se tornando popular entre os atacantes. Pela aparncia inofensiva que tm, consoles de videogames (que ultimamente saem de fbrica equipados com suporte rede) vm sendo utilizados em ataques a redes corporativas . Alm disso, nada impede que um atacante crie seu prprio dispositivo eletrnico capaz de capturar trfego da rede, precisando ento apenas ter acesso direto ao meio fsico para sua instalao.

Redes sem fio Em redes sem fio, utilizar um sniffer muito simples, pois basta ao atacante conseguir uma certa proximidade de seu alvo e utilizar-se de um equipamento que opere na mesma frequncia da rede em questo. Tem sido comum encontrar atacantes utilizando-se de potentes antenas caseiras (que podem feitas com latas de batata frita) para capturar trfego de redes sem fio em grandes centros comerciais .

Anlise tica Como se no bastasse a captura do trfego atravs do meio de transmisso, um recente estudo mostra que possvel a captura do trfego de uma rede atravs da anlise de luzes de switchs e hubs a distncias de at 30 metros [22].

Evitando o uso Efetivo de Sniffers

Existem vrias maneiras de se evitar o uso efetivo de um sniffer por parte de um atacante. Embora no exista uma ``frmula mgica'' ou mtodo totalmente eficaz, existem vrias tcnicas que podem ser utilizadas na luta contra os atacantes. O uso de canais de comunicao criptografados, embora no evite o uso de sniffers, a tcnica mais eficaz para a proteo de informaes na rede, pois torna o trfego incompreensvel a quem no conhea a chave para descriptografia. O uso de hardware especializado, tcnicas de deteco (remota e local) e intenso trabalho de administrao mostram-se efetivos para vrios casos, mas nem sempre so confiveis.

Abaixo fazemos uma anlise de vrias dessas tcnicas, apontando seus prs e contras. Limitao da Visibilidade do Trfego Limitar a visibilidade do trfego evitando que dados no pertinentes a determinada mquina estejam visveis a outras uma maneira simples e eficaz para diminuir a eficincia de um sniffer. O modo mais comum de implementar tal tcnica atravs da utilizao de hardware especializado (como switches), configuraes de redes onde haja separao entre as partes no relacionadas e utilizao de rotas bem implementadas. A tarefa de limitar a visibilidade do trfego exige planejamento, hardware especializado e intenso trabalho de administrao. Utilizao de Interfaces que No Suportem Modo Promscuo Como j foi visto, a utilizao de interfaces em modo promscuo aumenta em muito o potencial de captao de umsniffer. Frente a isso, a utilizao de interfaces que no operem nesse modo consiste numa boa maneira de limitar a utilidade de potenciais sniffers na rede, a no ser que sejam utilizados em roteadores, por exemplo, onde a utilizao do modo promscuo no necessria. Embora paream de grande utilidade, interfaces com essa caracterstica no alcanaram sucesso quando colocadas no mercado. A principal razo para tal insucesso o fato de que, alm de fugir da especificao dos padres do mercado h uma consequente perda de funcionalidade . Existem contudo interfaces cujo driver problemtico e no funciona em modo promscuo. Esse fator de pouca relevncia uma vez que nada impede que um atacante crie e utilize seu prprio driver aps conseguir privilgios de administrador em uma mquina, mas pode ser levado em conta em casos muito particulares, como a implementao de kernels monolticos ou com camadas extras de segurana . Utilizao de Criptografia A soluo mais eficiente para o problema de acesso indevido a dados torn-los ilegveis ou invlidos para o atacante que os consiga capturar. Tal objetivo pode ser alcanado atravs da utilizao de protocolos e canais criptografados - como tneis e VPNs [19] - e outras tcnicas de criptografia, como extensamente discutido em [35].

 importante lembrar que embora seja um meio eficiente de garantir o sigilo das informaes trafegadas, mesmo protocolos considerados seguros, se no bem implementados, podem ser quebrados com pouco ou nenhum esforo [1,24]. Protocolos como SSL (Secure Socket Layer) [8,12] e SSH (Secure SHell) [3] permitem o tunelamento de canais de comunicaes de modo que todo o trfego seja criptografado, e consistem em boas solues para a implementao de redes seguras. A utilizao de protocolos no criptografados ainda prtica comum. Embora existam alternativas e solues j h muito tempo disponveis, o custo de implementao e manuteno adicional que estes acarretam os tornam proibitivos para aplicaes em redes simples ou que tenham grande demanda de trfego. Como mostrado em [2], implementar a utilizao de canais criptografados utilizando SSL, pode exigir at o dobro de capacidade de processamento de um servidor ou cliente. Uma breve lista de protocolos e suas principais caractersticas relacionadas segurana do trfego de informaes, assim como as alternativas existentes mostrada abaixo. Os detalhes sobre o funcionamento e arquitetura de cada protocolo no esto no escopo deste trabalho. Para isso recomendamos a consulta da documentao dos projetos que implementem tais protocolos ou seus respectivos RFCs .

POP (Post Office Protocol) [26] e IMAP (Internet Message Access Protocol) [9] Protocolo para trfego de correio eletrnico. amplamente utilizado e tanto autenticao como dados so transmitidos em claro. Alternativas: Tunelamento sob SSL e utilizao de mensagens criptografadas.

SMTP (Simple Mail Transfer Protocol) [31] Protocolo de envio de correio eletrnico. Todo o trfego transmitdo em claro. Alternativa: Tunelamento sob SSL.

Telnet [29]

Um dos primeiros protocolos a ser criado para logins remotos, o telnet ainda hoje utilizado e apresenta um grande risco uma vez que todo o trfego (o que inclui nome de usurios e senhas) trafega em claro. Alternativa: SSH.

NIS (Network Information Service) [41] Prov um conjunto de informaes para o gerenciamento de usurios, mquinas e servios de uma rede. Permite o livre acesso a nomes de usurios, senhas criptografadas e servios disponveis. uma grande fonte de informao para atacantes e passvel de ataques de dicionrio (fora bruta). Alternativas: Kerberos, LDAP.

HTTP (Hyper Text Transfer Protocol) [15] Dada sua popularidade, amplamente utilizado, servindo como camada intermediria na implementao de inmeros servios a usurios. Nenhum tipo de criptografia fornecido pelo protocolo, o que expe todo o trfego. Alternativa: HTTPS (HTTP + SSL)

FTP (File Transfer Protocol) [30] Protocolo para transferncia de arquivos. Inclui autenticao que, assim como todo o trfego, transmitida em claro. Alternativa: SSH

Kerberos [21] Protocolo de autenticao que permite a reutilizao de credenciais de login ("Single Sign On"). A autenticao e a troca de chaves feita de forma criptografada. Se no cuidadosamente implementado, passvel de ataques de sincronia e de dicionrio (fora bruta), como mostrado em [4].

CVS (Concurrent Versions System) [10] Sistema de controle de verses amplamente utilizado para o gerenciamento de cdigo fonte e documentao de projetos. Seu protocolo de comunicao nativo (pserver) no criptografado, e o mtodo de autenticao extremamente simples. Alternativa: Tunelamento sob SSH

IRC (Internet Relay Chat) [27] Protocolo para conversas via rede. Implementado sem grandes preocupaes com segurana, transmite todo o trfego em claro, e utilizado como grande fonte de senhas e informaes relevantes para atacantes, como alertado em [7]. Este protocolo deve ter sua utilizao evitada quando houver a necessidade de transmisso de dados sensitivos.

O uso de canais de comunicao criptografados definitivamente se mostra como a melhor soluo para o problema da visibilidade dos dados, j que os torna incompreensveis a terceiros. Com o uso de criptografia, consegue-se anular boa parte da utilidade de um sniffer que esteja procura de trfego relevante. Porm a substituio de sistemas funcionais, a necessidade de maior capacidade de processamento e, de um modo geral, a configurao adicional associada utilizao de tcnicas de criptografia - como a gerao de certificados e chaves por parte do administrador - tm impedido sua ampla utilizao. Deteco Mesmo em redes nas quais protocolos criptografados sejam utilizados e o trfego seja bem delimitado, ainda grande a quantidade de informaes que um atacante munido de um sniffer consegue capturar. A topologia da rede, a verso dos softwares em execuo, a carga e o nmero de usurios, alm de diversos outros dados tm um valor substancial na formulao de ataques sofisticados. A simples existncia de um sniffer no autorizado em qualquer ponto da rede um forte indcio de que esta est sob a mira de atacantes ou usurios mal intencionados, independentemente da qualidade e quantidade dos dados que estes possam capturar. Sendo assim, v-se a necessidade da utilizao de mtodos que detectem a presena de sniffers e a ocorrncia de incidentes em geral que sejam suspeitos. Tais mtodos so discutidos no prximo captulo.

Deteco de sniffers
Sniffers so em geral agentes passivos. Em outras palavras, eles iraramente interferem no funcionamento da rede. Um sniffer ideal (no sentido de ser invisvel aos usurios da rede) no injeta pacotes na

rede, no responde a qualquer tipo de requisio e no precisa sequer ter um endereo da rede. Um exemplo de tal sniffer seria um dispositivo eletrnico qualquer capaz de capturar o trfego diretamente do meio de transmisso 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 so muito raros e, na prtica, a principal caracterstica visvel de um sniffer uma interface em modo promscuo sem o aval do administrador da rede. essa a caracterstica geralmente procurada por um detector de sniffers. Entre as diversas tcnicas e ferramentas existentes para o cumprimento de tal tarefa, podemos destacar as relacionadas abaixo.

Detectores de Intruso
Os detectores de intruso (Intrusion Detection Systems - IDS), tanto os destinados redes (Network Intrusion Detection Systems NIDS) como os destinados a uma nica mquina (Host Based Intrusion Detection Systems)so caracterizados pela anlise de trfego e informaes que evidenciem tentativas ou ocorrncias de ataques, atuando como espcies de alarmes. IDSs so itens indispensveis a redes nas quais haja um srio comprometimento com a questo da segurana. Um detector de sniffers pode ser considerado uma espcie de NIDS (ou uma extenso destes), embora seu funcionamento e implementao, de um modo geral, sejam bastante diferentes.

Deteco Local
Na deteco local, o administrador do sistema precisa procurar por caractersticas de sniffers diretamente em cada mquina conectada rede, sendo a principal delas a configurao da interface em modo promscuo e certos processos em execuo. Uma alternativa verificao manual um servio que fique em execuo em cada mquina disparando um alarme quando alguma interface entrar em modo promscuo ou trfego de rede no endereado mquina em questo for recebido pelas camadas superiores da pilha de rede. Apesar de ser um mtodo determinstico, a deteco local tem srias desvantagens: Difcil implantao:

 necessria a interveno pessoal do administrador, ou de um software. A utilizao de mtodos de deteco local torna-se difcil em redes de grande extenso ou heterogneas. Alm disso, mquinas que no faam oficialmente parte da rede no seriam verificadas. No confiabilidade: o principal fator que reduz a confiabilidade de testes locais o possvel comprometimento da segurana da mquina invadida. Uma vez que tenha obtido privilgios de administrador na mquina, o atacante pode utilizar-se de vrios artifcios para camuflar as respostas do sistema. Exemplos de tais artifcios so a substituio de utilitrios do sistema, mdulos e drivers do sistema operacional.

Deteco Remota
A deteco remota consiste na anlise do trfego da rede procura de ``assinaturas'' tpicas de sniffers ou de interfaces em modo promscuo. Tais assinaturas possuem caractersticas decorrentes de peculiaridades do sistema operacional, do software em execuo ou mesmo do hardware. Cabe a um detector o papel de explorar essas peculiaridades, muitas vezes enviando trfego que dispare um determinado comportamento na mquina remota. Dentre essas caractersticas, uma possvel classificao dos testes remotos a de ativos e passivos, no sentido de alterarem ou no o estado da rede atravs da injeo de pacotes. Dado que sniffers so geralmente programas executados a partir de mquinas de uso geral e assumindo que tais mquinas tm uma implementao de uma pilha TCP/IP e outros protocolos e servios disponveis rede, pode-se desenvolver testes remotos que explorem suas caractersticas. Como a definio do comportamento de uma pilha TCP/IP bastante flexvel e no aborda todas as combinaes possveis de pacotes e opes (flags), ela implementada de inmeras maneiras diferentes. possvel, por exemplo, a deteco da verso do sistema operacional e diversas outras caractersticas de uma mquina atravs de uma tcnica conhecida como ``TCP/IP Fingerprinting'' , atravs da qual so analisadas respostas a determinados tipos de requisies e reaes a comportamentos inesperados [18]. A maioria dos testes remotos baseiam-se na explorao de caractersticas de determinadas implementaes da pilha TCP/IP e do

prprio driver de rede, especialmente as mais comuns em sistemas operacionais atuais. As prximas subsees contm uma explicao detalhada dos mtodos conhecidos [20] para a deteco remota de sniffers ou de interfaces trabalhando em modo promscuo. Requisio ICMP com Falso Endereo Fsico Um dos testes de deteco remota mais conhecidos consiste no envio de um pacote do tipo ICMP ECHO REQUEST utilizando um endereo destino de hardware adulterado de modo a no ser normalmente aceito pela mquina suspeita, a no ser que esta se encontre em modo promscuo. Uma resposta a esse tipo de requisio indica que a mquina testada est recebendo trfego atravs de uma interface de rede em modo promscuo. Excluindo-se o endereo de broadcast e os endereos de multicast [11] configurados para serem aceitos, uma interface de rede trabalhando em modo normal s deveria aceitar quadros enviados com seu prprio endereo de hardware no campo de destino. Uma interface trabalhando em modo promscuo passa todo quadro recebido s camadas superiores da pilha de rede. Por questes de modularidade e eficincia, tais camadas fazem poucas verificaes nos endereos de hardware dos quadros repassados. enviando pacotes com endereos de hardware vlidos dentro destas verificaes, porm fora do conjunto de endereos normalmente aceitos pela interface (broadcast, multicast e o prprio endereo da interface) que se faz possvel a realizao deste teste. Tomando como exemplo uma implementao do mdulo de rede do kernel Linux verso 2.4, quando um endereo de hardware no coincide com o endereo da prpria interface, seu primeiro octeto testado contra o valor 0xff. Caso este teste seja verdadeiro, assumese que foi recebido um quadro do tipo broadcast ou multicast. No sendo do tipo broadcast , este mesmo octeto testado novamente; se for mpar, assume-se que o quadro do tipo multicast, caso contrrio ele sumariamente descartado. Tal comportamento pode ser evidenciado nas funes ip_rcv(), eth_type_trans() e ether_setup() da camada de rede do kernel Linux nas verses 2.2, 2.4 e 2.5.

Este teste tambm pode funcionar em algumas redes comutadas, uma vez que existem switches que ao receberem pela primeira vez um pacote com endereo desconhecido o repassam a todos os segmentos da rede. Embora comumente se utilizem pacotes do protocolo ICMP para a realizao deste teste, este tambm pode ser implementado utilizando-se outros protocolos, como HTTP ou FTP. No restante deste trabalho referimo-nos ao teste de requisies de ICMP com falso endereo fsico simplesmente como teste ICMP. Requisio ARP com Falso Endereo Fsico De forma similar ao teste visto anteriormente, este teste utiliza-se de requisies do protocolo ARP (Address Resolution Protocol) [28], que o protocolo utilizado para converter endereos IP para endereos fsicos em redes Ethernet. Neste teste, feita uma requisio com endereo fsico de destino invlido e aguarda-se uma resposta por parte da mquina suspeita. Explorando a pouca variao nas implementaes do sistema de resoluo de endereos de determinados sistemas operacionais - at mesmo devida simplicidade deste protocolo -, este teste mostra-se com um escopo bastante amplo, funcionando, por exemplo, na deteco de mquinas com ambientes Windows, Linux e BSD. Mquinas geralmente possuem cache de ARP, tornando possvel usar uma variao deste teste enviando anncios ARP com endereo de hardware invlido no intuito de que mquinas com interfaces em modo promscuo guardem no cache a tupla <IP, endereo fsico> recebida atravs desses anncios invlidos. Nesse cenrio feita uma requisio qualquer em modo broadcast na rede (como uma requisio de ECHO ICMP) e aguarda-se que alguma mquina (ou mquinas) responda a tal requisio sem fazer uma consulta ARP, o que indicaria a presena de uma interface atuando em modo promscuo. Um cuidado deve ser tomado com a ocorrncia de falsos positivos, uma vez que se houver trfego legtimo entre as duas mquinas, estas eventualmente precisaro trocar requisies e respostas ARP. Como no possvel identificar a partir de qual requisio veio uma determinada resposta, o teste pode erroneamente reportar que a mquina est em modo promscuo.

No restante deste trabalho referimo-nos ao teste de requisies de ARP com falso endereo fsico simplesmente como teste ARP. DNS Reverso Para um atacante ou at mesmo um administrador, muito mais fcil verificar os dados coletados por um sniffer analisando nomes de host ao invs de confusos endereos IP. principalmente por causa desta razo que muitos sniffers optam por trocar os endereos IP coletados por nomes de host utilizando a funcionalidade de resoluo reversa de nomes do DNS. Tendo acesso fsico ao caminho de rede entre uma mquina suspeita e o servidor de nomes utilizado por ela, possvel arquitetar um teste de deteco remota que descubra um sniffer atravs da verificao da utilizao desta funcionalidade (resoluo reversa) por parte do sniffer. Para isso, simulada uma conexo entre uma mquina interna e outra externa rede testada, com o detalhe de que o endereo IP da mquina externa escolhido de forma absurda, ou seja, ou ele simplesmente no existe alocado a algum domnio ou um endereo cuja probabilidade de utilizao pelas mquinas da rede testada seja quase nula. A partir disto, espera-se que alguma mquina pertencente ao segmento de rede em que a conexo foi simulada tente acessar o servidor DNS em busca de informaes sobre este endereo falso. O endereo IP utilizado deve ser escolhido com cautela. Este no deve ser comum rede testada, uma vez que requisies de resoluo legtimas geradas pelas mquinas testadas poderiam criar falsos positivos. Alm disso, o trfego 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 aps um determinado nmero de execues. Isso se d devido ao fato de que o sniffer pode "desistir" de tentar resolver o endereo IP aps um determinado nmero de tentativas . Uma vez que o sniffer pode ficar em execuo por um longo perodo de tempo, recomenda-se que o teste seja feito com endereos IPs diferentes entre execues consecutivas. No restante deste trabalho referimo-nos ao teste de requisies de DNS reverso simplesmente como teste DNS. Latncia

Um sniffer pode consumir recursos computacionais considerveis de uma mquina para fazer coleta e anlise de trfego. Se a interface estiver em modo promscuo e a quantidade de trfego for substancialmente grande, a responsividade da mquina pode diminuir de forma perceptvel. Uma maneira no determinstica mas eficiente de detectar-se a presena de sniffers atravs da medida de variao de tal responsividade. O objetivo do teste de latncia gerar uma condio de negao de servio (Denial of Service - DoS) na mquina alvo atravs da utilizao de algum tipo de trfego que sobrecarregue apenas mquinas que estejam com umsniffer em execuo. A escolha de tal trfego deve levar em conta inmeras variveis do sistema operacional, do equipamento utilizado e do sniffer em execuo. Esse teste pode ser feito atravs da medida do tempo de resposta e do nmero de requisies respondidas com a utilizao de requisies ECHO do protocolo ICMP ou atravs da mensurao da responsividade de qualquer servio em execuo na mquina suspeita. Como insere uma grande quantidade de trfego na rede, ele deve ser utilizado com muito cuidado, pois pode interferir no desempenho e funcionamento de servios daquela. Essa caracterstica faz com que sua utilizao seja mais adequada quando j existe a suspeita da execuo de um sniffer em alguma mquina. Esse teste deve ser ajustado para a rede em questo e seus resultados analisados com cautela, uma vez que so subjetivos e no determinsticos. A implementao do servio usado para medio, a situao da rede no momento e vrios 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 gerao da inundao:

Pacotes de protocolos complexos Alguns sniffers analisam os campos internos de pacotes de determinados protocolos para a captura de informaes especficas. Entre esses protocolos, podemos citar os que podem conter informaes sensitivas como senhas e nomes de usurios e os que tm estrutura complexa, como os pacotes utilizados pelo protocolo de resoluo de nomes (DNS). Tais protocolos precisam ser do interesse do atacante para no serem descartados inicialmente no filtro de pacotes do sniffer.

Pacotes pequenos Como o sniffer precisa fazer anlise do trfego baseado em pacotes, os cabealhos de todos estes precisam ser abertos. Sendo assim, utilizar um grande nmero de pacotes pequenos em geral vantajoso em relao utilizao de poucos pacotes grandes.

Truques com o protocolo TCP A utilizao de algumas opes de pacotes TCP e a explorao de algumas caractersticas deste protocolo podem esgotar os recursos de um mquina, como descrito em [36,25].

Inundao distribuda Tcnicas de negao de servio distribuda (Distributed Denial of Service - DDoS) podem ser utilizadas para fazer com que a mquina alvo do teste tenha sua performance (processamento) seriamente comprometida. Nesse cenrio, diversas mquinas so utilizadas com o intuito de sobrecarregar a mquina alvo [39]. No caso da deteco de sniffers, conexes com falsos endereos de hardware podem ser utilizadas, sobrecarregando a mquina apenas se esta estiver em modo promscuo.

Capacidade de processamento importante levar em conta a capacidade de processamento tanto da mquina alvo como da mquina geradora da inundao. Enquanto que a tarefa de gerao de pacotes pode consumir uma substancial quantidade de recursos da mquina, se o alvo tiver grande capaciade de processamento a inundao pode no ter o efeito esperado para este teste. Alm disso, a capacidade da rede deve ser levada em considerao, pois se esta no for capaz de suportar a quantidade de trfego necessria, a inundao no ter o efeito desejado.

Outros estudos sobre ataques de negao de servio, assim como tcnicas para sua conteno podem ser encontrados em [6,34,23]. Como no teste de requisies DNS, possvel implementar esse teste de maneira a testar a existncia de sniffersem todas as mquinas da rede ao mesmo tempo, uma vez que a inundao de pacotes visvel a todas elas. Armadilha (Honey Pot)

O uso de armadilhas uma tcnica amplamente usada na deteco e estudo de ataques de diversos tipos. Uma armadilha, comumente chamada de ``Honey Pot'', consiste na utilizao de ``iscas'' geralmente mquinas em ambientes bem controlados - para serem invadidas e exploradas por atacantes [13]. A partir das informaes coletadas em tais ambientes possvel conhecer melhor o atacante, suas tcnicas e em muitos casos chegar sua identificao. No caso da deteco de sniffers, pode-se fornecer falsas senhas e informaes atravs de conexes forjadas e ento 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 autenticao seja feita em texto claro. Uma possvel implementao pode agir como um sniffer procurando pelo uso dos dados falsos ou expandir a armadilha a outros nveis, criando falsos ambientes tambm para os servios cujas informaes falsas foram disponibilizadas. A utilizao deste tipo de tcnica bastante eficiente pois pode conseguir detectar at mesmo um sniffertotalmente passivo, alm de se mostrar muito til no estudo de hbitos do atacante. Seu grande problema que a resposta para o teste pode demorar consideravelmente e sua implantao pode exigir alteraes nos servios da rede. Alguns exemplos destas alteraes podem ser a implantao de servios de rede que sejam passivos atuao dos atacantes e a simulao de ambientes corporativos que atraiam a ateno e previnam a desconfiana por parte dos atacantes. Deteco de Inundao de Respostas ARP sniffers em redes comutadas geralmente se fazem passar por outra mquina para receber o trfego e fazer seu roteamento (veja seo 2.4.2). Para isso, uma das tcnicas freqentemente empregadas consiste no envio de anncios ARP em excesso para enganar outras mquinas da rede. Tal excesso, comumente chamado de inundao (flooding), constitui uma evidncia de um sniffer ou atacante em atuao. Para a implementao de tal teste de maneira confivel, necessria a definio de um limiar a partir do qual o nmero de anncios considerado excessivo. Este deve ser ajustado conforme as caractersticas da rede e dossniffers em questo.

Confiabilidade dos Testes

O principal problema com os mtodos de deteco remotos que eles, em sua maioria, podem ser evadidos porsniffers ou atacantes que conheam a metodologia utilizada. Um atacante pode alterar o comportamento do SO ou implementar ``tcnicas de deteco das tcnicas de deteco'', criando sniffers que reajam aos testes de maneira a no serem detectados. importante notar que tal evaso no trivial e no se tem notcia de sniffers que tenham implementado tais tcnicas at o momento. Alm disso, a grande variedade nas implementaes da pilha TCP/IP se mostra um desafio para a implementao de testes portveis, que venham a detectar sniffers ou interfaces em modo promscuo em uma ampla variedade de arquiteturas e sistemas operacionais. Devido caracterstica inerentemente passiva dos sniffers e a pressuposio de que uma mquina invadida no confivel, a tarefa de deteco complexa. A melhor maneira de proteger os dados em trnsito ainda o uso da criptografia juntamente com a limitao na disponibilizao do trfego. A utilizao de tcnicas de deteco porm consiste numa das muitas armas disponveis aos administradores de redes na luta pela segurana dos dados e, na guerra contra os atacantes, todas as armas tm sua utilizao valorizada nas vrias frentes de batalha.

Implementao
A escassez de programas para deteco de sniffers em redes, principalmente gratuitos e de qualidade, alm do interesse pela rea de segurana computacional motivou a implementao de um aplicativo para deteco remota de sniffers. O projeto, batizado de sniffdet, foi dividido em duas partes, a saber, uma biblioteca contendo os testes de deteco implementados, chamada libsniffdet, e uma aplicao para utilizar e testar esta biblioteca. A vantagem desta diviso est no fato de que uma vez definida a API da biblioteca, ambas as partes poderiam ser desenvolvidas simultaneamente at o estgio de depurao, otimizando o tempo usado para implementao. O restante deste captulo mostra os princpios, as qualidades, orientaes e preocupaes relevados durante o processo de desenvolvimento do projeto sniffdet.

Preocupaes do Projeto
O projeto comea com a definio da interface de seu componente mais importante, a biblioteca libsniffdet. Sabe-se, a princpio, que preocupaes comuns em desenvolvimento de software tais como eficincia, eficcia, modularidade e manutenibilidade devem ser somadas a outros itens especficos de acordo com sua aplicao e utilizao. Alguns destes itens apresentam-se ressaltados abaixo. Segurana como se trata de um aplicativo que lida com softwares e dados potencialmente maliciosos, a segurana dentro do ambiente de execuo primordial, sendo levada em considerao durante todo o processo de desenvolvimento. Extensibilidade dada a dinamicidade da rea de deteco de sniffers, esperado que novos testes e variaes dos j existentes sejam criados com o passar do tempo, devendo ser incorporados biblioteca. Flexibilidade Sniffers podem alterar seu comportamento de modo a evitar sua deteco, principalmente se os testes de deteco possurem algum tipo de comportamento que os denuncie, ou seja, algum tipo de ``assinatura'' que os caracterize. Pensando nisso, a utilizao de valores constantes evitada e so disponibilizados vrios artifcios para se configurar os atributos dos testes de deteco. Usabilidade Pouco vale um sistema para auxiliar administradores de rede se somente uns poucos forem capazes de utiliz-lo. O software acompanhado de extenso material explicando seu funcionamento e sua utilizao e adotada a utilizao de valores padro para alguns dos parmetros omitidos pelo usurio, tornando seu uso mais prtico. Responsividade importante fornecer um mecanismo de comunicao entre a biblioteca e a aplicao que funcione durante a execuo dos testes, permitindo uma melhor interao entre os dois. Este mecanismo evita

a impresso de ``congelamento'', principalmente naqueles testes que exigem bastante tempo para realizarem medies mais precisas.

Documentao
A preocupao com a utilizao do sistema fomentou a criao de vrios documentos que descrevem a utilizao da libsniffdet e sua aplicao, bem como seu funcionamento interno, convenes de suas APIs e preocupaes na utilizao. Alm destes textos especficos, existem pginas de manual (manpages), compilaes de perguntas mais freqentes (faqs) e a pgina oficial do projeto, disponvel em http://sniffdet.sourceforge.net. Como um projeto concebido para ser utilizado e receber contribuies da comunidade mundial de desenvolvimento de software livre, existem verses da documentao em portugus e ingls.

Licena e Distribuio
Todo o cdigo fonte e documentao deste projeto esto sob a licena GPL (General Public License) verso 2 da GNU [17]. A GPL uma licena de software que garante a livre distribuio e alterao deste contanto que os direitos autorais sejam mantidos e a licena no revogada. O projeto sniffdet est sendo distribudo pela Internet e conta com toda a infra-estrutura necessria para receber contribuies da comunidade do software livre como novas funcionalidades, indicaes de erros, sugestes, correes e discusses em geral a respeito do projeto. O material produzido pode ser obtido atravs da pgina do projeto ou da utilizao de um cliente CVS. A pgina do projeto est localizada em http://sniffdet.sourceforge.net. Para se obter o material diretamente do repositrio de desenvolvimento (cdigos fonte e documentao) basta usar um cliente CVS com:pserver:anonymous@abrigo.dyndns.org:/sniffdetcomo raiz. O projeto est dividido em trs mdulos no repositrio, a saber:

docs: documentao gerada durante a execuo do projeto; sndet: cdigo fonte da libsniffdet e aplicao; web: estrutura e documentos da pgina do projeto.

Na pgina web so encontradas as ltimas verses oficiais, correes para problemas srios e pacotes binrios em formato RPM.

Ambientao
Tanto a biblioteca quanto a aplicao foram implementados usando linguagem C a partir de uma plataforma operacional Linux. Dada a popularidade e disponibilidades das redes padro Ethernet, este foi escolhido para a implementao e testes do projeto. Foram utilizadas diversas ferramentas e bibliotecas auxiliares para o desenvolvimento do mesmo, sendo que as mais relevantes so:

libpthread Biblioteca POSIX de gerenciamento de threads.

glibc 2.2 Biblioteca GNU padro C.

gcc (GNU C Compiler) Compilador GNU C.

autoconf Utilitrio para automao de configurao do sistema.

libnet Biblioteca para criao de pacotes de rede.

libpcap Biblioteca para captura de pacotes de rede.

CVS (Concurrent Versions System) Sistema de gerenciamento para acesso concorrente a repositrios de cdigo centralizados.

GNU make Utilitrio de construo automtica de projetos.

ElectricFence

Wrapper da biblioteca padro de alocao de memria. til para a fase de depurao, pois ajuda a encontrar vazamentos de memria e acessos a endereos invlidos.

gdb (GNU Debugger) Depurador de processos GNU.

Ethereal Sniffer com recursos de visualizao de pacotes capturados, inclusive descrio dos protocolos utilizados e verificao de payload. Essencial para verificar a adequao dos pacotes gerados pela libsniffdet e a captura correta dos mesmos nas mquinas testadas.

tcpdump Sniffer bastante flexvel que funciona em interface texto.

Todos os itens acima so gratuitos, de livre distribuio e disponibilizados em vrias plataformas operacionais diferentes. Juntando este fato preocupao com a documentao, a adoo do padro ANSI para linguagem C e a utilizao de vrias bibliotecas padro POSIX, espera-se que o porte deste projeto para outras plataformas torne-se uma tarefa bem simplificada. Atualmente, ele j compila e executado num sistema FreeBSD, sendo necessrias apenas algumas adaptaes no processo de compilao.

Biblioteca
Bibliotecas so componentes de sistemas que agrupam funes e definies de propsito comum em objetos disponibilizados de maneira centralizada. Sua finalidade agregar funcionalidades a programas em tempo de execuo de acordo com a demanda, num processo chamado de ligao dinmica. A vantagem est no fato de que o cdigo existente na biblioteca no precisa ser replicado em cada processo com interesse em utiliz-lo, economizando memria e o tempo de processamento levado para carreg-la. Outra facilidade na utilizao de bibliotecas que as mesmas podem ser modificadas de forma transparente aos usurios, permitindo sua expanso e correo sem exigir a recompilao dos aplicativos que as usam. Para que este procedimento possa ocorrer sem problemas,

deve-se seguir algumas regras como, por exemplo, as citadas em [42] e mencionadas abaixo. 1. No trocar o comportamento de funes entre verses; 2. No modificar o layout ou atributos de dados exportados que no so alocados somente internamente na biblioteca; 3. No remover funes exportadas; 4. No modificar a interface de uma funo exportada; 5. Evitar inserir novos membros em estruturas em uma posio diferente da ltima; O procedimento de ligao dinmica trata, basicamente, da exportao de smbolos e as restries acima garantem a compatibilidade entre diferentes verses de uma biblioteca, ou melhor dizendo, a compatibilidade binria das mesmas. Todos estas qualidades juntas da possibilidade de insero de novos testes de deteco de sniffers num futuro prximo justificam a escolha de uma biblioteca como residncia dos testes implementados. Arquitetura Geral A arquitetura geral da biblioteca est representada pela figura 4.1. Como pode ser visto, a biblioteca est dividida em mdulos, um para cada teste de deteco implementado. Os testes de deteco existentes na verso atual so o ICMP, ARP, DNS e de Latncia. Existe um mdulo especial, o mdulo helpers, que agrega vrias funes de propsito geral tais como tradutores de nomes e geradores de nmeros aleatrios, podendo ser utilizado tanto pelos outros mdulos quanto pela aplicao. A comunicao da biblioteca com a aplicao feita atravs da ativao com passagem de parmetros e do uso de funes de callback. O fluxo comum de utilizao de suas funes segue abaixo. 1. Inicializar a estrutura de controle da interface de rede; 2. Chamar a funo de teste requerida, passando todos os argumentos obrigatrios e, na medida do interesse, os opcionais; 3. Tratar, opcionalmente, os dados enviados pela callback; 4. Interpretar os resultados; 5. Desalocar a estrutura de controle da interface de rede. Dentre estes passos, o nico que precisa ocorrer com privilgios de administrador o primeiro, pois a interface precisa ser inicializada sem restries de utilizao. Portanto, a aplicao tem a opo de efetuar

a restrio de privilgios - trocar sua identificao de usurio para outro diferente do administrador - aps este passo inicial, contribuindo para uma execuo mais segura dos testes.

Pensando na praticidade de sua utilizao, a biblioteca incorpora o conceito de classificao de argumentos, dividindo-os em 2 tipos: obrigatrios e opcionais. Os argumentos minimamente necessrios para a correta execuo de um teste so ditos obrigatrios e sua omisso gera um aviso em tempo de execuo e a pronta parada do teste. A omisso dos argumentos opcionais faz com que a biblioteca substitua seus valores internamente por padres que se mostrem adequados. Os valores escolhidos para esta substituio so discutidos logo a seguir. Funcionamento Todos os testes de deteco at agora implementados funcionam com a utilizao de mltiplas threads. Os testes so do tipo de deteco remota ativa, que injetam pacotes na rede e coletam pacotes ou impresses (no caso do teste de latncia). Podemos generalizar seu modelo de acordo com a figura 4.2. So trs as threads responsveis pelos testes. Uma delas - main - responsvel pelo controle das

outras duas threads, incluindo a criao, destruio, inicializao, desalocao de suas estruturas de controle e monitorao do tempo mximo de execuo, representado pela barra de timeout. As outras duas threads so responsveis, respectivamente, pelo envio de estmulos rede (sender) e pela percepo de respostas que caracterizem a utilizao de sniffers na rede testada (catcher), sendo estas as caractersticas inerentes aos testes de deteco ativos.

Responsividade Alguns testes de deteco podem precisar de vrios minutos de funcionamento para realizar uma verificao significativa do ambiente a ser testado. Durante este tempo, importante que haja algum indcio do que o programa est fazendo atualmente a fim de se evitar a impresso de ``congelamento'' por parte do usurio. Por outro lado, pode ocorrer a necessidade de se cancelar um teste em execuo ao invs de esperar pelo seu trmino. Estas caractersticas so ainda mais necessrias em ambientes com interfaces grficas. A preocupao com a responsividade do sistema foi satisfeita atravs da implementao de um mecanismo de comunicao entre a biblioteca e a aplicao. A partir da implementao e freqente ativao de uma funo compatvel com o prottipo abaixo, possvel obter notificaes sobre o andamento da execuo dos testes de deteco ao mesmo tempo em que a aplicao pode requisitar o cancelamento de um procedimento em andamento. Este tipo de funo tambm chamada de funo de callback.
int (*user_callback)(struct test_status *status, int msg_type, char *msg);

O primeiro argumento simplesmente mostra dados estatsticos, como a porcentagem de execuo do teste ativado e a quantidade de bytes recebidos e enviados. O segundo argumento identifica o tipo da mensagem. O terceiro traz uma mensagem a respeito do evento que ativou a chamada desta callback quando necessria e o valor de retorno indica a requisio de cancelamento do teste em execuo. So seis os tipos de mensagens passadas aplicao pela biblioteca:

RUNNING: serve para indicar o correto funcionamento do teste de deteco ativado e afastar a impresso de ``congelamento''; NOTIFICATION: vem acompanhado de informaes corriqueiras sobre o funcionamento do teste, como seu instante de incio ou trmino; ERROR: indica uma condio crtica e iminente cancelamento do teste em execuo, tal como erros em chamadas de sistema ou falta de permisso para manipular a interface; WARNING: mostra alertas relevantes, porm, que no levam ao cancelamento do teste; DETECTION: indica a deteco de um sniffer; ENDING: avisa sobre o fim da execuo do teste;

Outro fator importante sobre a utilizao de callbacks que como sua implementao ocorre no espao de cdigo da aplicao, cada programa usurio pode desenvolv-la de acordo com sua necessidade, podendo criar mecanismos diferenciados de registro de acordo com o tipo de mensagem recebida, assim como ativar sistemas externos a partir dela. Um exemplo disso seria o envio de email ao administrador da rede testada quando da deteco de um sniffer na mesma. Resultado dos Testes de Deteco Algumas aplicaes podem implementar o conceito de bateria de testes. Portanto, para facilitar a classificao e posterior visualizao dos resultados, foi criada uma estrutura comum de retorno dos testes que identifica o teste realizado atravs de seu cdigo (enumerao), nome, descrio, tempo de incio e fim de sua execuo, alm de uma indicao sobre sua validade (correta execuo) e algumas informaes estatsticas. Esta estrutura mostrada abaixo:
struct test_info { enum test_code code; int valid; char *test_name; char *test_short_desc;

time_t time_start; time_t time_fini; unsigned int b_sent; unsigned int b_recvd; unsigned int pkts_sent; unsigned int pkts_recvd; union { struct icmptest_result icmp; struct arptest_result arp; struct dnstest_result dns; struct latencytest_result latency; } test; };

Cada teste possui uma estrutura de retorno especfica de acordo com suas caractersticas. Cada uma delas ser explicada nas subsees seguir, junto das implicaes prticas de utilizao de cada teste. Teste ICMP O teste de deteco usando mensagens ICMP apresenta o seguinte prottipo.
int sndet_icmptest(char *host, struct sndet_device *device, unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *result, char *fakehwaddr );

Os argumentos obrigatrios so a estrutura de controle da interface de rede (device) e o endereo da mquina a ser testada (host). A flexibilidade e a descaracterizao de assinaturas necessrias para se evitar a contra-atuao por parte desniffers mais avanados so garantidas pela variao do valor dos argumentos de intervalo de envio de pacotes (send interval) e endereo MAC utilizado como destino (fakehwaddr). A omisso destes valores faz com que sejam internamente substitudos por um segundo de intervalo de envio de pacotes - valor comum para aplicativos de diagnstico de rede, tais como o ping - e pelo endereo 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, conforme sugesto explicada em 3.3.1. Seu funcionamento dentro do modelo genrico apresentado consiste na utilizao de uma thread para enviar as requisies ICMP falsas e outra thread para capturar respostas enviadas pela mquina alvo.

Devido natureza determinstica deste teste, sua parte especfica da estrutura de retorno contm somente uma argumento que diz se o alvo testado foi flagrado ou no com um sniffer em execuo. Teste ARP O teste ARP apresenta o seguinte prottipo e tem um comportamento similar ao do teste ICMP:
int sndet_arptest(char *host, struct sndet_device *device, unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *result, char *fakehwaddr );

De acordo com sua semelhana com o teste ICMP, tem os mesmos argumentos obrigatrios, assim como valores padro, funcionamento geral e estrutura de retorno. Teste DNS O teste DNS apresenta o seguinte prottipo:
int sndet_dnstest(char *host, struct sndet_device *device, unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *info, char *fake_ipaddr, char *fake_hwaddr, ushort dport, ushort sport, char *payload, short int payload_len );

Tem os mesmos argumentos obrigatrios dos testes anteriores, porm, a flexibilidade e descaracterizao de assinaturas mais elaborada. So usados os argumentos de tempo de envio de pacotes (send interval) e outros mais para simular um pacote de comunicao comum, atravs da parametrizao dos endereos IP de destino e origem, das portas de destino e origem e de um payload opcional. Os seguintes valores so usados quando da omisso dos argumentos opcionais:

Um segundo como intervalo de envio de pacotes; Porta de origem 23 (Telnet) e destino 1150 (nenhum servio especial); Endereo MAC destino 0x44, 0x44, 0x44, 0x44, 0x11, 0xff; Endereo IP destino 10.0.0.21.

Tanto o endereo MAC quando o IP so endereos invlidos na rede testada O funcionamento da thread de leitura tem um cuidado especial no que diz respeito leitura do pacote de consulta DNS. Como o prprio dado contido na requisio DNS orienta sobre a formao dos nomes representados no pacote, um sniffer pode construir um pacote malformado com o intuito de causar uma falha no teste de deteco atravs do acesso memria indevido. Este problema contornado respeitando sempre o tamanho total do pacote capturado. A estrutura de resposta deste teste semelhante a do ICMP e ARP, com somente uma indicao da localizao ou no do sniffer na mquina testada. Teste de Latncia O teste de latncia apresenta o seguinte prottipo:
int sndet_latencytest_pktflood(char *host, struct sndet_device *device, unsigned int tmout, unsigned int probe_interval, user_callback callback, struct test_info *info, struct custom_info *bogus_pkt );

Os argumentos obrigatrios so o nome da mquina alvo (host) e a estrutura de controle da interface de rede (device). Para a descaracterizao de assinaturas, tm-se a parametrizao do intervalo de verificao de latncia e a estrutura de construo de pacote (bogus pkt), apresentada logo abaixo.
struct custom_info { int values_set; // ETH u_char dmac[6]; u_char smac[6]; // IP uint id;

uint timestamp; u_char ttl; ulong dest_ip; ulong source_ip; // TCP/UDP short protocol; // udp/tcp/icmp int flags; // header flags uint seq; uint ack; ushort winsize; short dport; short sport; u_char *payload; short payload_len; // mandatory if payload is used };

Com todos estes parmetros, possvel criar vrios tipos de pacotes diferentes para a inundao da rede. Como discutido no captulo anterior, o importante fazer com que o sniffer gaste o mximo de tempo com o processamento destes pacotes. A omisso do argumento bogus_pkt faz com que a biblioteca o susbstitua internamente por um pacote telnet com o flag SYN ligado, simulando um incio de conexo. Devido natureza no-determinstica deste teste, a estrutura de retorno restringe-se a disponibilizar os dados colhidos durante o estgio de trfego normal e de inundao da rede para que, atravs da comparao e de uma certa subjetividade, o usurio decida sobre a possibilidade de existncia do sniffer. Os dados disponibilizados so o tempo mdio de resposta na rede com trfego normal e os tempos mnimo, mdio e mximo e o nmero de pacotes enviados e perdidos na rede sobrecarregada. Em futuras verses deste teste, pretende-se aprimorar o clculo do tempo mdio de resposta atravs do uso de desvio padro ou outras tcnicas estatsticas. A utilizao de vrios tipos de pacotes para inundao tambm requerida, pois quanto mais se explorar a pilha da mquina alvo, maior ser o tempo gasto por ela para processar os pacotes enviados, fornecendo uma medida melhor da latncia incorrida em mquinas que rodam com sua interface em modo promscuo.

Aplicao
O principal objetivo da aplicao fornecer um modo simples e flexvel para se testar a biblioteca. Alm de cumprir esta tarefa, a

aplicao propiciou uma melhor viso sobre a utilizao dos testes de deteco. Durante sua codificao e testes, houve um amadurecimento da biblioteca, que teve uma melhor definio de que valores utilizar por padro e como se comunicar com a aplicao atravs do uso da funo de callback. A arquitetura geral da aplicao pode ser vista na figura 4.3.

Nesta figura, percebe-se a segmentao dos procedimentos em trs fases. Na primeira fase ocorre a carga dos dados do arquivo de configurao, o qual contm os parmetros utilizados na execuo de cada um dos testes. Na segunda fase ocorre a ativao dos testes pedidos usando os parmetros lidos e a execuo dos mesmos prossegue at seu trmino ou cancelamento atravs da callback. Na ltima fase, os resultados obtidos so passados aos plugins de sada, cujo funcionamento ser melhor explicado na seo correspondente. Interface texto A aplicao tm uma interface texto simples mas poderosa. Atravs de parmetros passados na linha de comando, possvel escolher as

funcionalidades presentes. Abaixo temos a tela de ajuda da aplicao, onde as opes existentes so listadas:
sniffdet 0.7 A Remote sniffer Detection Tool Copyright (C) 2002 Ademar de Souza Reis Jr. <myself /at/ ademar.org> Milton Soares Filho <eu_mil /at/ yahoo.com> Usage: ./sniffdet [options] TARGET Where: TARGET is a canonical hostname or a dotted decimal IPv4 address -i tests -c -l -f --iface=DEVICE Use network DEVICE interface for Use FILE as configuration file Use FILE for tests log Use FILE for tests target Search for plugins in DIR Use FILE plugin Run program with UID (after Run program with GID (after

--configfile=FILE --log=FILE --targetsfile=FILE --pluginsdir=DIR -p --plugin=FILE -u --uid=UID dropping root) -g --gid=GID dropping root) -t

--test=[testname] Perform specific test Where [testname] is a list composed by: dns DNS test arp ARP response test icmp ICMP ping response test latency ICMP ping latency test Run in verbose mode Show this help screen and exit Show version info and exit

-v --verbose -h, --help --version

Defaults: Interface: "eth0" Log file: "sniffdet.log" Config file: "/etc/sniffdet.conf" Plugins Directory: "/usr/lib/sniffdet/plugins" Plugin: "stdout.so" You have to inform at least one test to perform

O apndice A traz a pgina manual relativa utilizao da aplicao sniffdet. Plugins de Relatrios de Resultados Cada administrador tem uma predileo quanto maneira de se armazenar ou visualizar os resultados obtidos pelos testes de deteco. Bases de dados, registros de sistema, arquivos XML ou simplesmente arquivos em formato texto so alguns exemplos de

locais onde tais resultados podem ser guardados. Para facilitar o atendimento a todos estes diferentes gostos, a aplicao d suporte ao conceito de plugins, que so objetos executveis que contm uma interface padronizada de ativao. Cada plugin oferecido pode ser relacionado a um destes diferentes mtodos de armazenamento, sendo que novos podem ser adicionados sem que haja a necessidade de recompilao de qualquer parte do sistema. Atualmente, um plugin de visualizao em modo texto e outro com sada em XML so disponibilizados. Um exemplo de visualizao de resultado atravs de um plugin em modo texto pode ser visto abaixo.
-----------------------------------------------------------Sniffdet Report Generated on: Mon Oct 14 19:54:35 2002 -----------------------------------------------------------Tests Results for target 192.168.1.1 -----------------------------------------------------------Test: ARP Test Check if target replies a bogus ARP request (with wrong MAC) Validation: OK Started on: Mon Oct 14 19:54:34 2002 Finished on: Mon Oct 14 19:54:35 2002 Bytes Sent: 84 Bytes Received: 60 Packets Sent: 2 Packets Received: 1 -----------------------------------------------------------RESULT: POSITIVE ----------------------------------------------------------------------------------------------------------------------Number of tests with positive result: #1 ------------------------------------------------------------

O contedo do arquivo gerado pelo plugin de sada em XML pode ser visto abaixo.
<?xml version="1.0"?> <SNIFFDET-SESSION> <info> <name>Latency test</name> <description>Ping response with custom packet flood</description> <validation>VALID</validation> <start-time>Wed Oct 30 01:16:37 2002</start-time> <finish-time>Wed Oct 30 01:17:02 2002</finish-time> <bytes-sent>337629680</bytes-sent> <bytes-received>0</bytes-received> <pkts-sent>3246439</pkts-sent> <pkts-received>13</pkts-received> <results unit="msecs">

<normal>0.6</normal> <minimal>9.1</minimal> <maximal>548.9</maximal> <mean>168.4</mean> </results> </info> </SNIFFDET-SESSION>

Arquivo de Configurao Uma das caractersticas mais importantes da biblioteca sua flexibilidade. Pensando em aproveitar este poder e facilitar a utilizao do sistema, a aplicao permite sua configurao atravs da utilizao de um arquivo externo, no qual todos os parmetros utilizados podem ser facilmente editados e adaptados de acordo com a necessidade do usurio. Alm de toda a flexibilidade do arquivo de configurao, possvel ativar diversas opes atravs de parmetros passados atravs da linha de comando. Um exemplo de arquivo de configurao, assim como sua documentao esto disponveis no apndice A. Segurana Quanto segurana, importante frisar que a aplicao, apesar de poder ser executada somente por um usurio com privilgios de administrador, abdica de tais privilgios aps a inicializao da interface, diminuindo o impacto da explorao de potenciais vulnerabilidades existentes no cdigo.

Consideraes Ps-desenvolvimento
Foi grande o desafio de se implementar um projeto que, alm de funcionar em um ambiente de rede de computadores, toca em tantos subsistemas do ncleo do sistema operacional (rede, sistema de arquivos, timers,threads e outros). claro que tal desafio seria muito mais complicado se no houvessem tantas ferramentas livres para auxiliar no desenvolvimento, em especial, ferramentas de diagnstico de rede e de depurao de cdigo. Apesar da dificuldade, o produto final consegue agrupar vrias qualidades necessrias para, ao menos, interessar pela sua utilizao e estudo. Dentre o pblico que pode ser tocado pela existncia deste software, pode-se destacar os administradores de rede, profissionais da rea de segurana e estudantes cursando disciplinas intermedirias sobre redes de computadores.

At o momento, o sniffdet a nica ferramenta que agrupa as seguintes qualidades: Licena GPL Este tipo de licena encoraja o estudo e utilizao por tornar o sistema gratuito e permitir modificaes em cdigo. Outro fator importante que este tipo de software tende a evoluir rapidamente, pois conta com a crtica e sugesto constante de seu pblico usurio. Flexibilidade A preocupao com a descaracterizao de assinaturas, liberdade de configurao e poder de ajuste aos usurios atravs do uso de arquivos de configurao e parmetros passados pela linha de comando garantem uma vida til maior ao sistema. Tambm neste tpico se destaca a possibilidade de insero de novos plugins de relatrios de resultados, tornando o sistema ainda mais adaptado necessidade de seu usurio. Segurana Alm de ser mantida em mente a todo instante ainda pode ser testada atravs da auditoria do cdigo, por ser aberto. Simplicidade na Utilizao A interface em modo texto foi desenvolvida de maneira a ser simples e intuitiva. Um fator preocupante para a implementao a possvel heterogeneidade de sistemas e plataformas que trabalham numa rede. Estas diferentes configuraes, tanto de software quanto de hardware, dificultam a generalizao e adaptao dos parmetros dos testes de deteco. Somente atravs de sucessivos testes utilizando vrias configuraes diferentes possvel chegar a um ajuste prximo do ideal. Por causa disso, a preparao do prximo captulo levou nossa ateno de volta ao estgio de implementao, tornando-se parte do processo evolutivo do sistema.

Experimentos e Resultados
Como mostrado no captulo anterior, foi desenvolvida uma biblioteca de testes e uma aplicao para a deteco remota de sniffers. Neste

captulo relatamos os resultados de tais testes, assim como suas limitaes, confiabilidade e fatores que podem influenciar novos experimentos.

Ambientao
Os experimentos aqui relatados foram realizados em ambiente domstico. A variedade de equipamentos e softwares utilizados pequena, porm dado que a aplicao de livre distribuio, esperase que esta seja amplamente testada e aperfeioada por usurios e interessados aps o seu lanamento pblico. Entre os fatores que mais podem influenciar nos resultados dos testes, podemos citar o sistema operacional utilizado e as configuraes deste, o driver da interface e a capacidade da rede, assim como todos os equipamentos e software envolvidos na captura e gerao de trfego na rede. Os equipamentos empregados nos experimentos esto listados abaixo:

Microcomputador AMD Duron 1GHz, 256MB RAM Microcomputador Intel Pentium 200MHz, 64MB RAM Interfaces de rede PCI 100Mbps, chipset RTL8139 Interfaces de rede PCI 10Mbps, chipset RTL8129 Modem ADSL US Robotics USR8550 Switch Encore ENH908-NWY+ HUB 10Mbps genrico Cabos de rede coaxiais e cabos padro RJ45

Em termos de software, foram utilizados trs sistemas operacionais para os testes: Linux (kernel 2.2 e 2.4), FreeBSD 4.2 e Microsoft Windows 98SE. Dado o pouco domnio sobre estes dois ltimos sistemas por parte dos autores, os resultados neles obtidos so 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:

Sistemas Operacionais: GNU/Linux (kernels 2.4.18 e 2.2.19), FreeBSD 4.2 e Microsoft Windows 98se. sniffers: Ethereal 0.9.6 e tcpdump 3.7.1

Os sniffers utilizados so bastante flexveis, oferecendo opes para filtragem de pacotes, visualizao de contedo em tempo real,

resoluo reversa de nomes, vrias opes para gravao dos dados, etc. Sendo assim, foi possvel reproduzir o comportamento de sniffers reais a partir dessas opes de configurao sem grandes dificuldades.

Descrio dos Resultados

Devido a caracterstica de flexibilidade do projeto, permitindo a alterao dos parmetros utilizados sem a necessidade de recompilao, conseguiu-se uma quantidade significativa de informaes na realizao dos testes, porm, demasiadamente grande para serem descritas por completo neste documento. Nas sees a seguir apresentamos exemplos de execuo e particularidades relevantes a cada um dos testes implementados. Teste ICMP O teste de requisies ICMP com endereo de hardware falso bastante simples. Como o objetivo descobrir se determinada interface de rede da mquina alvo est operando em modo promscuo, o sniffer utilizado no relevante. Na verdade, qualquer ferramenta que configure a interface para trabalhar em modo promscuo pode ser utilizada. Em relao aos parmetros do teste, foram utilizados os seguintes valores:

Tempo limite de execuo: 20 segundos. Nmero mximo de requisies enviadas: 10. Intervalo entre requisies: 1 segundo. Falso endereo de hardware (Ethernet MAC): 0xff, 0x00, 0x00, 0x00, 0x00, 0x00. Pacote ICMP: Requisio ICMP simples, idntica utilizada pelo utilitrio ping, disponvel em diversos sistemas operacionais.

Todos esses valores so configurveis pela aplicao de testes, e podem ser alterados conforme as caractersticas das mquinas e da rede envolvidas. A utilizao de valores de endereo de hardware iniciados em 0xff se mostrou necessria para que este teste funcionasse, conforme justificativa dada em 3.3.1.

Em todas as execues desse teste, resultados positivos foram retornados logo aps o envio dos primeiros pacotes, frequentemente nos primeiros 2 segundos aps a ativao do teste de deteco. A carga da rede no tem influncia nos testes. Testes em mquinas com interfaces em modo normal no reportaram falso positivo, retornando sempre aps o tempo mximo configurado para o teste. importante ressaltar que esse teste no se mostrou efetivo na deteco de interfaces em modo promscuo no ambiente Windows por ns testado. Acredita-se que o driver da interface em questo tenha algum tipo de filtro embutido, no repassando os pacotes para as camadas superiores da pilha TCP/IP. Abaixo temos uma pequena lista de execues:

Linux 2.4: Execuo e deteco ocorreram sem problemas, utilizando qualquer endereo de hardware como destino. FreeBSD 4.2: Execuo e deteco ocorreram sem problemas, utilizando qualquer endereo de hardware como destino. Microsoft Windows 98: No houve deteco, resultados no conclusivos.

Teste ARP O teste de requisies ARP com endereo de hardware falso tambm bastante simples e assim como o teste ICMP, apenas detecta se a interface da mquina alvo est em modo promscuo. Foram utilizados os seguintes valores para o teste de requisio ARP:

Tempo limite de execuo: 20 segundos. Nmero mximo de requisies enviadas: 10. Intervalo entre requisies: 1 segundo. Falso endereo de hardware (Ethernet MAC): 0xff, 0x00, 0x00, 0x00, 0x00, 0x00. Requisio ARP comum, idntica s geradas pelo sistema operacional Linux 2.4 na rede observada.

Todos esses valores so configurveis pela aplicao de testes, e podem ser alterados para se adequar a particularidades da rede e do ambiente de execuo. Assim como no teste ICMP, foi necessria a utilizao de um endereo de hardware iniciado em 0xff para que esse teste se mostrasse efetivo.

Em todas as execues do teste, resultados positivos eram retornados logo aps o envio das primeiras requisies, tambm frequentemente nos primeiros 2 segundos aps a ativao do teste de deteco. Esse teste se mostrou efetivo na deteco de interfaces em modo promscuo nos trs sistemas operacionais testados, porm falsos positivos podem ser reportados caso haja trfego de rede legtimo entre as duas mquinas, uma vez que no possvel diferenciar uma resposta ARP legtima de uma gerada pela requisio falsa. Abaixo temos uma pequena lista de execues:

Linux 2.4: Execuo e deteco ocorreram sem problemas. FreeBSD 4.2: Execuo e deteco ocorreram sem problemas. Microsoft Windows 98: Deteco sem problemas.

Teste DNS Para que esse teste seja efetivo, o sniffer deve ter a resoluo reversa de nomes ativada. Essa opo ligada por padro no Ethereal e em algumas verses do tcpdump. Em ambos a opo pode ser habilitada a partir da linha de comando ou da interface grfica. Os pacotes utilizados nas conexes falsas so do protocolo TCP e tem vrios dos seus campos de opo preenchidos com valores configurveis. Em nossos experimentos utilizamos as seguintes opes:

Tempo limite de execuo: 20 segundos. Nmero de pacotes enviados: 10. Intervalo entre o envio: 1 segundo. Falso endereo de hardware (Ethernet MAC): arbitrrio. Falso endereo IP: 10.0.0.21 Porta de conexo (destino): 23 (telnet) Porta de conexo (origem): 23 Poro de dados do pacote (payload): VAZIO

Todos os valores foram escolhidos de maneira arbitrria. A alterao destes se mostra til em casos particulares, como quando da necessidade de evitar a caracterizao do teste ou adequ-lo a um determinado ambiente, mas no necessria na maioria dos casos. Comportamento dos Sistemas Operacionais testados:

Linux 2.4: Execuo e deteco ocorreram sem problemas. FreeBSD 4.2: Execuo e deteco ocorreram sem problemas.

Microsoft Windows 98: Deteco sem problemas.

Teste de Latncia Como o teste de latncia no determinstico, a anlise dos resultados deve levar em considerao vrias caractersticas do ambiente testado. Uma vez que o objetivo do teste estressar a mquina 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 combinao tima de parmetros e trfego 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 aperfeioados num futuro prximo. Em nossos experimentos, utilizamo-nos de uma sequncia de pacotes TCP com a flag SYN ativada e com a poro de dados vazia ou de tamanho bastante reduzido . O objetivo da utilizao de pacotes com essas caracterstica foi forar o sniffer a processar um grande nmero de cabealhos de pacotes. Essa abordagem funcionou bem no sistema operacional Linux, mas no gerou resultados conclusivos nos outros dois sistemas testados (MS Windows 98 e FreeBSD 4.2). Os valores para o endereo de hardware (MAC) e endereo IP foram escolhidos arbitrariamente, e, se necessrio, podem ser alterados para se adequar s caractersticas da rede e dos sniffers testados.

Teste 1
Mquina executando o teste:

Processador AMD Duron 1GHz, 256MB RAM Interface de rede 100Mbps Sistema Operacional: Linux (kernel 2.4.18)

Mquina alvo do teste:

Intel Pentium 200Mhz, 64MB RAM Interface de rede 100Mbps Sistema Operacional: Linux (kernel 2.4.18) sniffer em execuo: tcpdump 3.7.1 (opes padro)

Parmetros utilizados:

Tempo de execuo do teste: 180 segundos Intervalo entre as requisies ICMP: 1 segundo

Pacote utilizado para a inundao:

Falso endereo de hardware de origem: 0x00,

0x11, 0xff

0x55, 0x34, 0x21, 0x44, 0x34, 0x2A,

Falso endereo de hardware de destino: 0x00,

0x0B, 0xff

Falso endereo IP de origem: 10.0.0.21 Falso endereo IP de destino: 10.0.0.30 Porta de conexo (destino): 23 (telnet) Porta de conexo (origem): 23 Poro de dados do pacote (payload): 2 bytes, contedo arbitrrio Pico do trfego alcanado na rede: 20Mbps Responsividade da mquina executora do teste: aceitvel; processamento normal Responsividade da mquina alvo do teste: muito baixa; processamento lento; dificuldade at mesmo para trocar de um terminal (tty) para outro

Os resultados obtidos com tal teste podem ser vistos abaixo: Interface alvo em modo normal

Requisies enviadas: 122 Requisies respondidas: 122 (100%) Tempo de resposta normal: 0.2ms Tempo de resposta durante inundao (min/med/max): 0.2/0.2/1.3 (ms)

Interface alvo em modo promscuo

Requisies enviadas: 122 Requisies respondidas: 44 (36%) Tempo de resposta normal: 0.2ms Tempo de resposta durante inundao (min/med/max): 1.0/1.5/6.3 (ms)

Como pode ser visto acima, a mquina alvo quando com um sniffer em execuo em modo promscuo no foi capaz de responder todas as requisies ICMP (obtivemos variaes entre 30 e 50% de responsividade), e quando o fez, foi com uma demora considervel em relao ao mesmo teste com a interface em modo normal. Esse teste foi repetido vrias vezes e os resultados levaram

s mesmas concluses, mesmo sob condies ligeiramente diferentes (trfego na rede, utilizao da mquina para outros fins, etc). Comportamentos Inesperados Como nossa implementao insere uma grande quantidade de pacotes ``estranhos'' no barramento da rede, alguns equipamentos reagiram de maneira inesperada execuo de alguns testes: Modem ADSL: A cada execuo do teste de latncia, o modem ADSL, que estava no mesmo barramento da rede, perdia a conexo externa com a Internet. O fabricante foi contactado a respeito desse comportamento, mas at o presente momento no obtivemos resposta. Alm disso, a interface do modem conectada rede interna parece estar em modo promscuo, uma vez que responde positivamente aos testes ICMP e ARP. Switch: O switch utilizado bastante simples e apresenta pouca robustez. Durante a inundao de pacotes do teste de latncia, este diversas vezes passou a se comportar como um HUB, retransmitindo todos os pacotes para todas as mquinas a ele conectadas. Mquinas pertencentes ao barramento da rede testado no apresentaram comportamento inesperado durante a execuo dos testes ICMP, DNS e ARP. J na execuo do teste de latncia, mquinas com interfaces em modo promscuo tiveram sua responsividade diminuida, uma vez que nesses casos o nmero de pacotes processados pela pilha de rede do sistema operacional era grande.

Concluso
sniffers so geralmente executados a partir de mquinas comprometidas por atacantes e injetam o mnimo de pacotes na rede em que esto sendo executados. Esse modus operandi faz com que sistemas de deteco locais percam sua confiabilidade, pois o atacante pode facilmente camuflar a existncia de seu sniffer ao manipular os sistemas que indicam sua utilizao, inclusive modificando o funcionamento de mdulos internos do ncleo do sistema operacional. J sistemas de deteco remota devem levar isto em considerao e esforar-se ao mximo em termos de flexibilidade para que sniffers mais avanados no venham a reconhecer um padro na sua utilizao e desenvolver uma tcnica de evaso.

Apesar da criptografia e da limitao de trfego imposta pelo cuidado na escolha da configurao da rede restringir bastante a eficncia de um sniffer, ainda h muita informao importante que pode ser angariada, o que no permite que somente tais tcnicas sejam adotadas em substituio utilizao de sistemas de deteco remota de sniffers. Tanto a bibloteca como a aplicao implementadas so abertas e tm seu cdigo fonte disponvel na Internet. Aliadas essa caracterstica esto flexibilidade, simplicidade e segurana, o que fazem de nossa implementao um bom exemplo para ser utilizado por administradores de rede e profissionais da rea de segurana, alm de servir como interessante ferramenta de estudo para alunos de cursos de redes de computadores. A implementao de um sistema de deteco remota de sniffers complexa pois sua eficcia sensvel a fatores externos, tais como o funcionamento das implementaes dos protocolos da pilha TCP/IP e dos equipamentos usados na rede que podem ser muitos variados e diferenciados. A indisponibilidade de um laboratrio para testes fez com que, infelizmente, os resultados obtidos com a flexibilidade da aplicao tenham sido mais toricos do que prticos. A segurana de um sistema depende de um conjunto considervel de fatores. No existe soluo tima que aborde todos os pontos vulnerveis, assim como no existe detector perfeito que possa detectar todo e qualquer tipo de sniffer. O cenrio parece-se com o de uma competio entre os atacantes e responsveis por segurana, e o objetivo destes ltimos sempre estar frente, dificultando o mximo possvel o caminho dos que pretendem comprometer a estrutura ou apoderar-se de dados importantes.
Trabalhos Futuros

Ainda h muito o que ser estudado e desenvolvido na rea de deteco de sniffers. Como toda rea em evoluo, novos ambientes, topologias e arquiteturas de rede esto sempre surgindo e os atacantes frequentemente utilizando sua infinita criatividade para contornar as barreiras a eles impostas. Tanto a aplicao como a biblioteca desenvolvida ainda esto em estgio inicial e, alm de muitos testes e ajustes finos, tm vrias funcionalidades a serem adicionadas. Aumentar o nmero de testes disponveis, assim como incluir diversas variaes dos existentes e fazer estudos qualitativos sobre seu funcionamento em diversas

plataformas seriam os principais focos de extenso deste trabalho. Por parte da aplicao, interessante desenvolver novos plugins de sada, assim como desenvolver uma interface grfica e sistemas de reao e resposta aos resultados obtidos. O lanamento pblico do cdigo fonte de toda a implementao, assim como a extensa documentao disponvel, devem permitir que o desenvolvimento e testes do projeto sejam acelerados num futuro prximo.

Pginas de Manual ("Unix Manpages")

Este apndice contm as pginas de manual do programa sniffdet e da biblioteca libsniffdet verso 0.7. Como o software tem um alcance mundial ( de livre distribuio), seu desenvolvimento e documentao foram feitos primariamente em ingls, e esse o idioma na qual as pginas de manual a seguir esto escritas.

libsniffdet (3)
LIBSNIFFDET(3) LIBSNIFFDET(3) Remote Sniffer Detection Library

NAME libsniffdet - Sniffer detection library DESCRIPTION This library is useful for remote sniffer detection or to discover machines which are running in promiscuous mode. You can see the full documentation at http://sniffdet.sourceforge.net SYNOPSIS #include <sniffdet.h> GENERAL DEFINITIONS CALLBACK The callback functions used by the detection tests for activity report and interactivity issues must have the following prototype, providing that its return value is used to cancel the current execution of the detection test. int (*user_callback)(struct test_status *status, int msg_type, char *msg);

The first argument is a structure of the type below, containing information about the state of execution (in percent) and the quantity of incoming and outcoming packets of the current test. struct test_status { unsigned short int percent; // 0% to 100% unsigned int bytes_sent; unsigned int bytes_recvd; }; The second argument is one of the following enumerations. RUNNING - used just for resposivity purposes NOTIFICATION - general messages ERROR - critical conditions (abort cases) WARNING - critical conditions (do not abort the execution) DETECTION - detection performed ENDING - indicates the end of the detction test DEVICE The following functions should be used to initialize/finish the network device. struct sndet_device * sndet_init_device( char *device, int promisc, char *errbuf); int sndet_finish_device( struct sndet_device *device, char *errbuf); Where struct sndet_device has the following layout: struct sndet_device { char *device; int datalink; int pkt_offset; struct libnet_link_int *ln_int; pcap_t *pktdesc; bpf_u_int32 network; bpf_u_int32 netmask; int rawsock; }; // // // // datalink type device name sync bytes raw socket id

RESULTS All the detection tests return their results in the following structure.

struct test_info { enum test_code code; int valid; char *test_name; char *test_short_desc; time_t time_start; time_t time_fini; unsigned int b_sent; unsigned int b_recvd; unsigned int pkts_sent; unsigned int pkts_recvd; union { struct icmptest_result icmp; struct arptest_result arp; struct dnstest_result dns; struct latencytest_result latency; } test; }; // // // // // // // // // // // detection test enumeration - see libsniffdet.h wether it was valid or not name of the test test short description start time stop time bytes sent bytes received packets sent packets received specifics results

GENERAL USE FUNCTIONS There are many functions built to provide basic network and general purpose functions. u_long sndet_resolve(char *hostname); Resolve hostname, returns binary representation in network-ordered representation. Hostname is an ASCII string representing an IPv4 address (canonical hostname or doted decimal representation). int sndet_random(void); Returns a pseudo random integer int sndet_ping_host( Common ping function. Provided are the target name (host), a pointer to the interface structure (device), the timeout in seconds, the interval between target probes (send_interval)and the amount of packets sent on each probe (burst_size). The last two args are used to return the results and to write the error

message in case an internal error occurs. It returns non-zero if any error occurs. u_long sndet_get_iface_ip_addr( Returns interface IP address in binary notation (host-ordered) for the given interface structure (sndet). If any error occurs, an error message will be writen in errbuf. struct ether_addr * sndet_get_iface_mac_addr( Returns interface MAC address unsigned char *sndet_gen_tcp_pkt( Generates a TCP packet based on information supplied in custom_pkt information void sndet_sleep(long sec, long usec); Independent and portable way for sleeping DETECTION TESTS The folowing are the detection test implemented by the library. They always have as obrigatory arguments the name of the target host and the device structure. The rest of theirs parameters will be replaced for internal values if not specified (passing NULL or zero, depending of the data type). As a general rule, all the tests return non-zero if an error occurs. For more specific information about the error, one should verify the message returned by the callback functions. ICMP TEST int sndet_icmptest( char *host, struct sndet_device *device, unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *result, char *fakehwaddr ); // // // // // suspicious host timeout in seconds max number of tries interval between packets sent (in msec) fake MAC hardware address sent to the host

ARP TEST int sndet_arptest( char *host, struct sndet_device *device,

unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *result, char *fakehwaddr ); // // // // // suspicious host timeout in seconds max number of tries interval between packets sent (in msec) fake MAC hardware address sent to the host

DNS TEST int sndet_dnstest( char *host, struct sndet_device *device, unsigned int tmout, unsigned int tries, unsigned int send_interval, user_callback callback, struct test_info *info, // bogus pkt information, optional char *fake_ipaddr, char *fake_hwaddr, ushort dport, ushort sport, char *payload, short int payload_len ); // // // // // pkt source pkt destination destination/source port payload data payload length

LATENCY TEST int sndet_latencytest_pktflood( char *host, struct sndet_device *device, unsigned int tmout, unsigned int probe_interval, user_callback callback, struct test_info *info, struct custom_info *bogus_pkt ); // // // // as tenths of second and RTT = Round Trip Time). struct latencytest_result { // time is expressed in msec/10 u_int normal_time; u_int min_time; suspicious host timeout in seconds interval between probes (x10 msec) info about the fake packet desired

As the result, there's the structure below (time measured

u_int max_time; u_int mean_time; }; EXAMPLES See the documentation included with the library and the source distribution, which you can found at http://sniffdet.sourceforge.net BUGS This library is in beta stage and is not widely tested. Your support is appreciated. :-) Please report bugs at http://sniffdet.sourceforge.net or to sniffdet-devel@lists.sourceforge.net Also take a look in our TODO file. COPYRIGHT Copyright (C) 2002 Ademar de Souza Reis Jr. <myself /at/ ademar.org> Milton Soares Filho <eu_mil /at/ yahoo.com> SEE ALSO sniffdet(1) libnet(3) pcap(3) http://sniffdet.sourceforge.net sniffdet manpage LIBSNIFFDET(3) 2002-11-28

sniffdet (1)
SNIFFDET(1) SNIFFDET(1) Remote Sniffer Detection Tool

NAME sniffdet 0.7 - Remote sniffer detection tool SYNOPSIS sniffdet [options] TARGET DESCRIPTION Sniffdet is an OpenSource implementation of a set of tests for remote sniffers detection in TCP/IP network environments. It is useful for remote sniffer detection or to just discover machines which are running in promiscuous mode. Sniffdet is very flexible and allows you to configure many of its options by using the config file /etc/sniffdet.conf. It also has

plugins support for the result of its tests (currently, XML and stdout output are created). You can see the full documentation at http://sniffdet.sourceforge.net OPTIONS TARGET is a canonical hostname or a dotted decimal IPv4 address -i --iface=DEVICE Use network DEVICE interface for tests. Default is eth0 in linux systems. -l --log=FILE Use FILE for tests log. Default is none -c --configfile=FILE Use FILE as configuration file for application. Default is /etc/sniffdet.conf -f --hostsfile=FILE Use FILE as input for tests target. The file must be in ascii with one hostname, IP or net address per line. Comments start with '#' -u --uid=UID Run program with UID (after dropping root). Default is UID 280 (from config file) -g --gid=GID Run program with GID (after dropping root) Default is GID 280 (from config file) -t --test=[testname] Perform a specific test(s) Where [testname] is a list composed by at least one of: dns arp icmp latency DNS test ARP response test ICMP ping response test ICMP ping latency test

See the full documentation included with the library for information about all tests --pluginsdir=[directory] Select a directory where sniffdet will load plugins from -p --plugin=[plugin_name] Select a plugin to load (xml, stdout, etc). -f --targetsfile=[file] Scan all targets present in a file with a test. -v --verbose Run in verbose mode (extra output messages).

Default is no. -s --silent Run in silent mode (no output messages). Default is no. -h --help Show a help screen and exit --version Show version information and exit EXAMPLES # sniffdet -i eth1 -t dns,arp,icmp foo.localdomain Test the host foo.localdomain with dns, arp and icmp tests using the interface eth1 # sniffdet -i eth0 -t latency foo.localdomain -plugin=xml Test the machine foo.localdomain using the latency test through the interface eth0. Output results using the xml plugin. BUGS This program is in beta stage and is not widely tested. Your support is appreciated. :-) Please report bugs at http://sniffdet.sourceforge.net or to sniffdet-devel@lists.sourceforge.net Also see our TODO file. COPYRIGHT Copyright (C) 2002 Ademar de Souza Reis Jr. <myself /at/ ademar.org> Milton Soares Filho <eu_mil /at/ yahoo.com> SEE ALSO sniffdet.conf(5) libsniffdet(3) http://sniffdet.sourceforge.net sniffdet manpage SNIFFDET(1) 2002-11-25

sniffdet.conf (2)
SNIFFDET(1) SNIFFDET(1) Remote Sniffer Detection Tool

NAME sniffdet.conf - sniffdet configuration file DESCRIPTION

sniffdet.conf allows you to configure the way sniffdet performs its tests. It's located in /etc by default and has various sections, all described below. SYNTAX The syntax is very simple. Each section has a name and is delimited by brackets "{}". Inside the section, simple attributions are made to variables. Comments are started with "#" and can be located anywhere in the file. Everything after a "#" is ignored by the parser until a line break. Blank lines are ignored. EXAMPLE An example of a configuration file follows (it's filled with some default values from the current implementation of libsniffdet, but should not be used in production enviroments. We strongly recommend that you create your own config file to avoid identification of the tests by the sniffers. # snifdet example configuration file # http://sniffdet.sourceforge.net # # see sniffdet.conf (5) manpage # global configuration global { verbose = 0; # this is one or a combination of FILE, STDOUT, STDERR, SYSLOG logtype = FILE; # want a log by default? logfile = "sniffdet.log"; #plugins_dir = "/usr/lib/sniffdet/plugins"; plugin = "stdout.so"; # UID to use after dropping root privileges UID = 280; # GID to use after dropping root privileges GID = 280; iface = "eth0"; fake_hwaddr = {0xff, 0x00, 0x00, 0x00, 0x00, 0x00}; fake_ipaddr = "192.168.1.100"; } # icmp test variables icmptest { # interface per test not supported yet #iface = "eth0"; timeout = 20; # secs tries = 10;

interval = 1000 # msecs fake_hwaddr = {0xff, 0x00, 0x00, 0x00, 0x00, 0x00}; } # arp test variables arptest { # interface per test not supported yet #iface = "eth0"; timeout = 20; # secs tries = 10; interval = 1000 # msecs fake_hwaddr = {0xff, 0x00, 0x00, 0x00, 0x00, 0x00}; } # dns test variables dnstest { # interface per test not supported yet #iface = "eth0"; timeout = 20; # secs tries = 10; interval = 1000 # msecs fake_ipaddr = "10.0.0.10" fake_hwaddr = {0x46, 0x0f, 0xA4, 0x33, 0x11, 0xD1}; sport = 22; dport = 22; # payload support not implemented in parser yet... #payload = "login: foobar"; } # latency test variables latencytest { # interface per test not supported yet #iface = "eth0"; timeout = 300; # secs interval = 1500; # msecs # tcpflags support not implemented in parser yet... #tcpflags = SYN; # payload support not implemented in parser yet... #payload = ""; } # EOF COPYRIGHT Copyright (C) 2002 Ademar de Souza Reis Jr. <myself /at/ ademar.org> Milton Soares Filho <eu_mil /at/ yahoo.com> BUGS - payload and tcpflags parser not implemented yet - multi-line support not implemented SEE ALSO sniffdet(1) libsniffdet(3) http://sniffdet.sourceforge.net sniffdet manpage SNIFFDET(1) 2002-11-28

Referncias Bibliogrficas 1 Anderson e Needham. Robustness Principles for Public Key Protocols. CRYPTO: Proceedings of Crypto, 1995. Disponvel em http://citeseer.nj.nec.com/anderson95robustness.html. 2 Apostolopoulos, Peris, e Saha. Transport Layer Security: How Much Does it Really Cost? INFOCOM: The Conference on Computer Communications, joint conference of the IEEE Computer and Communications Societies, 1999. Disponvel em http://citeseer.nj.nec.com/apostolopoulos99transport.html. 3 Daniel J. Barrett e Richard E. Silverman. SSH: The Secure Shell: The Definitive Guide. O'Reilly & Associates, Inc., 2001. 4 Steven M. Bellovin e Michael Merritt. Limitations of the Kerberos Authentication System. USENIX Conference Proceedings, pginas 253-267, Dallas, TX, 1991. USENIX. Disponvel emhttp://citeseer.nj.nec.com/article/bellovin91limitations.html. 5 Peter Breuer. Linux Bridge+Firewall Mini-HOWTO, dezembro de 1997. Disponvel emhttp://www.tldp.org/HOWTO/mini/Bridge+Firewall.html. 6 Computer Emergency Response Team CERT. Trends in Denial of Service Attack Technology, outubro de 2001. Disponvel emhttp://www.cert.org/archive/pdf/DoS_trends.pdf. 7 Computer Emergency Response Team CERT. Social Engineering Attacks via IRC and Instant Messaging, maro de 2002. Disponvel emhttp://www.cert.org/incident_notes/IN-2002-03.html. 8 Netscape Comunications. The SSL Protocol Version 3.0, novembro de 1996. Disponvel emhttp://wp.netscape.com/eng/ssl3/draft302.txt. 9 M. Crispin. Internet Message Access Protocol - Version 4rev1. ARPA RFC -

2060, dezembro de 1996. Disponvel emftp://ftp.rfceditor.org/in-notes/rfc2060.txt. 10 CVS Project. Concurrent version system - cvs home, 2002. Disponvel em http://www.cvshome.org. 11 Steve Deering. Host Extensions for IP Multicasting. ARPA RFC - 1112, agosto de 1989. Disponvel em ftp://ftp.rfc-editor.org/innotes/rfc1112.txt. 12 T. Dierks e C. Allen. The TLS Protocol. ARPA RFC - 2246, janeiro de 1999. Disponvel em ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt. 13 The Honeynet Project (Editor). Know Your Enemy: Revealing the Security Tools, Tactics, and Motives of the Blackhat Community. Addison-Wesley Pub Co, 1st edition, 2001. 14 J. Case et al. A Simple Network Management Protocol (SNMP). ARPA RFC 1157, maio de 1990. Disponvel emftp://ftp.rfc-editor.org/innotes/rfc1157.txt. 15 R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. ARPA RFC - 2616, junho de 1999. Disponvel em ftp://ftp.rfc-editor.org/innotes/rfc2616.txt. 16 Ethereal Project. Ethereal network analyser, version 0.9.7, 2002. Disponvel em http://www.ethereal.com. 17 Free Software Foundation. GNU General Public License Version 2, junho de 1991. Disponvel em http://www.gnu.org/copyleft/gpl.html. 18 Thomas Glaser. TCP/IP Stack Fingerprinting Principles, outubro de 2000. Disponvel emhttp://www.sans.org/newlook/resources/IDFAQ/TCP_fingerprintin g.htm.

19 B. Gleeson, A. Lin, J. Heinanen, e G. Armitage. A framework for IP based virtual private networks. ARPA RFC 2764, agosto de 1998. Disponvel emhttp://citeseer.nj.nec.com/gleeson00framework.html. 20 Robert Graham. Sniffing (network wiretap, sniffer) FAQ, setembro de 2000. Disponvel emhttp://www.robertgraham.com/pubs/sniffingfaq.html. 21 J. Kohl e C. Neuman. The Kerberos Network Authentication Service (V5). ARPA RFC 1510, setembro de 1995. Disponvel emftp://ftp.rfceditor.org/in-notes/rfc1510.txt. 22 Joe Loughry e David A. Umphress. Information Leakage from Optical Emanations. ACM Transactions on Information and Systems Security, 5(3), agosto de 2002. Disponvel emhttp://citeseer.nj.nec.com/528578.html. 23 Meadows. A Formal Framework and Evaluation Method for Network Denial of Service. PCSFW: Proceedings of The 12th Computer Security Foundations Workshop. IEEE Computer Society Press, 1999. Disponvel em http://citeseer.nj.nec.com/meadows99formal.html. 24 J. Moore. Protocol Failures in Cryptosystems. Proceedings of the IEEE, 5(76):594-602, agosto de 1988. 25 Pars Mutaf. Defending against a Denial-of-Service Attack on TCP. Recent Advances in Intrusion Detection, 1999. Disponvel emhttp://citeseer.nj.nec.com/mutaf99defending.html. 26 J. Myers e M. Rose. Post Office Protocol - Version 3. ARPA RFC - 1939, maio de 1996. Disponvel em ftp://ftp.rfc-editor.org/innotes/rfc1939.txt. 27

J. Oikarinen e D. Reed. Internet Relay Chat Protocol. ARPA RFC - 1459, maio de 1993. Disponvel em ftp://ftp.rfc-editor.org/in-notes/rfc1459.txt. 28 David C. Plummer. An Ethernet Address Resolution Protocol. ARPA RFC - 826, novembro de 1982. Disponvel em ftp://ftp.rfc-editor.org/innotes/rfc826.txt. 29 J. Postel e J. Reynolds. Telnet Protocol Specification. ARPA RFC - 854, maio de 1983. Disponvel em ftp://ftp.rfc-editor.org/in-notes/rfc854.txt. 30 J. Postel e J. Reynolds. File Transfer Protocol (FTP). ARPA RFC - 959, outubro de 1985. Disponvel em ftp://ftp.rfc-editor.org/in-notes/rfc959.txt. 31 Jonathan B. Postel. Simple Mail Transfer Protocol. ARPA RFC - 821, agosto de 1982. Disponvel em ftp://ftp.rfc-editor.org/innotes/rfc821.txt. 32 Jonathan J. Rusch. The 'Social Engineering' of Internet Fraud. 9th Annual Conference of the Internet Society, 1999. Disponvel emhttp://www.isoc.org/isoc/conferences/inet/99/proceedings/3g/3 g_2.htm. 33 Modulo Security Solutions S.A. 7^a Pesquisa Nacional de Segurana da Informao, julho de 2001. Disponvel emhttp://www.modulo.com.br/pdf/pesq_seg_01.zip. 34 Stefan Savage, Neal Cardwell, David Wetherall, e Tom Anderson. TCP Congestion Control with a Misbehaving Receiver. Computer Communication Review, 29(5), 1999. Disponvel em http://citeseer.nj.nec.com/savage99tcp.html. 35 Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley & Sons, 2nd edition, 1996. 36

Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, e Diego Zamboni. Analysis of a Denial of Service Attack on TCP. Proceedings of the 1997 IEEE Symposium on Security and Privacy, pginas 208-223. IEEE Computer Society Press, maio de 1997. Disponvel em https://www.cerias.purdue.edu/techreports-ssl/public/9706.ps. 37 Snort Project. Snort network intrusion detection system, version 1.9.0, 2002. Disponvel em http://www.snort.org. 38 Tcpdump Project. tcpdump sniffer, version 0.6.2, 2002. Disponvel em http://www.tcpdump.org. 39 Bennett Todd. Distributed Denial of Service Attacks, fevereiro de 2000. Disponvel emhttp://www.opensourcefirewall.com/ddos_whitepaper_copy.html. 40 Yuri Volobuev. Playing redir games with ARP and ICMP, setembro de 1997. Disponvel em http://bugtraq.inet-one.com/dir.199709/msg00057.html. 41 P. Weiss. Yellow Pages Protocol Specification, Sun Microsystems, Inc. Technical Report, 1985. 42 David A. Wheeler. Program Library HOWTO, agosto de 2002. Disponvel em http://www.dwheeler.com/program-library/Program-LibraryHOWTO/index.html. 43 Ira S. Winkler e Brian Deal. Information Security Technology? Don't Rely on It. A Case Study in Social Engineering. 5TH USENIX UNIX Security Symposium, 1995. Disponvel emhttp://www.usenix.org/publications/library/proceedings/securi ty95/winkler.html.

Notas de Rodap

...Sniffers O termo ``sniffer'', que em ingls significa ``farejador'' uma marca registrada da empresa Network Associates, referindo-se ao produto ``Sniffer Network Analyser''. Atualmente o termo utilizado ampla e genericamente em referncia a qualquer dispositivo ou software cuja funo seja capturar trfego de redes. ...rootkits Um rootkit consiste-se de um conjunto de ferramentas que auxiliam o atacante a manter-se em sigilo e dominar a mquina por completo. Podem ser facilmente encontrados na Internet e geralmente incluem mdulos de kernel, backdoors, sniffers e demais ferramentas teis a um atacante. ... corporativas Hackers j usam consoles em invases http://www2.uol.com.br/info/aberto/infonews/082002/0208200210.shl. Attack Of The Dreamcasts http://slashdot.org/article.pl?sid=02/08/01/1535234&mode=nested& tid=172.

... comerciais Tambm conhecidos como wardrivings, que consistem na procura por redes sem fio atravs do uso de algum meio de locomoo. ... funcionalidade Interfaces em modo promscuo tem grande utilidade, como a criao de bridges [5] e a depurao de problemas na rede. ... segurana Um exemplo o projeto Linux Intrusion Detection/Defense System (LIDS), onde criado um modelo de controle de acesso para o prprio kernel. Pgina do projeto: http://www.lids.org. ... RFCs RFCs, ou "Requests for Comments", so documentos criados com o intuido de criar padres para a Internet. As transcries podem ser encontradas em http://www.rfc-editor.org. ... execuo Uma possibilidade a utilizao do protocolo SNMP [14]. ... Fingerprinting'' A conhecida ferramenta ``nmap'' em sua verso 3.0 capaz de detectar mais de 700 diferentes implementaes utilizando tal tcnica. http://www.insecure.org/. ...broadcast O valor para broadcast Ethernet 0xff, 0xff, 0xff, 0xff, 0xff, 0xff. ... Linux

Os fontes do kernel Linux normalmente podem ser encontrados nos diretrios abaixo de /usr/src/linux em distribuies Linux padronizadas, ou diretamente de http://www.kernel.org. ... tentativas Alguns sistemas operacionais podem implementar um sistema de cache para as informaes obtidas atravs de requisies DNS. ... reduzido No faz sentido um pacote que tenha a flag SYN ativada carregar dados, mas durante os testes no estamos necessariamente preocupados em gerar trfego vlido. Ademar de Souza Reis Jr. 2003-03-11