INPE-9625-TDI/845

ANLISE DE ESTADO DE TRFEGO DE REDES TCP/IP PARA APLICAO EM DETECO DE INTRUSO

Marcelo Henrique Peixoto Caetano Chaves

Dissertao de Mestrado em Computao Aplicada, orientada pelo Prof. Dr. Antonio Montes Filho, aprovada em 23/09/2002.

INPE So Jos dos Campos 2003

681.3.24 CHAVES, M. H. P. C. Anlise de estado de trfego de redes TCP/IP para aplicao em deteco de intruso / M. H. P. C. Chaves.So Jos dos Campos: INPE, 2002. 172p. (INPE-9625-TDI/845). 1.Redes TCP/IP. 2.Segurana de Rede. 3.Sistemas de deteco de intruso. I.Ttulo.

Se voc e e respons avel pela seguran ca de uma organiza c ao, mas n ao tem autoridade para estabelecer regras ou punir infratores, seu papel e levar a culpa quando algo grande der errado.

EUGEN E SPAF FORD

Aos meus pais, por tudo.

AGRADECIMENTOS Agrade co a DEUS, por estar sempre presente e por ter iluminado o meu caminho. Aos meus pais Carlos e Terezinha, pelo amor incondicional, por todo o carinho, dedica c ao, apoio e pelo maior presente, a vida. ` minha eterna e amada Jana A na, por todo o seu amor, lealdade, companheirismo, carinho, dedica c ao, por estar ao meu lado, mesmo em tempos de chuva, e por todo o apoio na fase mais cr tica deste trabalho. Ao meu irm ao Carlos, por estar sempre ao meu lado e pela amizade cada vez mais forte. Ao meu orientador Prof. Dr. Antonio Montes, pelos ensinamentos e experi encias compartilhadas, pela orienta c ao e apoio e, principalmente, pelo imensur avel aux lio no momento mais cr tico. Aos amigos da Rep ublica Her ois da Resist encia, Gilberto, Claudio, Bruno e Glauco, por todo o companheirismo e pela grande amizade, pelas experi encias adquiridas e discuss oes innd aveis mas proveitosas, pelos bons momentos e tamb em pelos momentos dif ceis, e aos tr es primeiros pelo grande aux lio durante todo o desenvolvimento deste trabalho. Ao grande amigo Ivan, por seu companheirismo, lealdade e amizade incondicional, mesmo nos momentos em que estive mais distante. Aos insepar aveis amigos Reinaldo e Adriano, que apesar de ` as vezes distantes, sempre participaram de momentos importantes da minha vida. ` amiga Alessandra, por todo o aux A lio enquanto trabalhava na biblioteca do INPE. Aos amigos Klaus e Cristine, pelos ensinamentos, experi encias compartilhadas e, principalmente, pelos bons conselhos e contribui c oes dadas a este trabalho. Ao amigo Am andio, por toda a compreens ao e apoio nos momentos mais dif ceis. Aos novos amigos L ucio e Gustavo, pelas contribui c oes dadas a este trabalho.
A Ao Bruno, pelo estilo do L TEX, desenvolvido segundo as normas de publica c ao do INPE.

Ao Instituto Nacional de Pesquisas Espaciais (INPE) e, em especial, ao Laborat orio de Matem atica e Computa c ao Aplicada (LAC), pela oportunidade de estudo, trabalho e utiliza c ao de suas instala c oes, e aos professores e colegas do INPE, pelos ensinamentos e conhecimento compartilhado. ` Funda A c ao de Aperfei coamento de Pessoal de N vel Superior (CAPES), pelo aux lio nanceiro em quase dois anos de bolsa de mestrado. E nalmente, a todas as pessoas que de alguma forma contribu ram para o cumprimento de mais esta etapa da minha vida.

RESUMO Este trabalho apresenta o desenvolvimento de uma metodologia de reconstru c ao de sess oes para o tr afego de redes TCP/IP. Esta metodologia baseia-se em um modelo, gerado a partir de dados extra dos do tr afego de rede, que permite reconstruir e rastrear o estado das sess oes, utilizando apenas o cabe calho dos pacotes. Atrav es da extrapola c ao do conceito de sess ao, esta modelagem permite n ao s o reconstruir e rastrear o estado das sess oes TCP, mas tamb em reconstruir sess oes ICMP e UDP. O modelo e, ent ao, utilizado como base para o desenvolvimento do Sistema de Reconstru c ao de Sess oes TCP/IP - RECON - para ser usado em atividades associadas ` a detec c ao de intrus ao. Esta abordagem possibilita a redu c ao do n umero de falso-positivos e falso-negativos, visto que o estado e todo o hist orico de pacotes que comp oem uma sess ao podem ser utilizados na tomada de decis oes, em contrapartida ` aquelas que tomam decis oes avaliando pacote a pacote, isoladamente. Ela tamb em permite correlacionar informa c oes de um conjunto de sess oes na identica c ao de atividades hostis, que n ao podem ser observadas em uma u nica sess ao. O sistema faz uso de um sensor, posicionado adequadamente para coleta de pacotes do tr afego, que armazena os dados em arquivos periodicamente. Estes arquivos s ao transferidos para uma esta c ao de an alise, onde o RECON e executado. Uma caracter stica desta metodologia e que ela permite tratar uma quantidade relativamente grande de informac oes, pois utiliza um n umero reduzido de dados por pacote, correspondentes apenas aos seus cabe calhos. O sistema desenvolvido pode tamb em funcionar como uma ferramenta de suporte, aplicado n ao s o em atividades de detec c ao de intrus oes, mas tamb em a outras atividades, tais como o gerenciamento, monitoramento e estudo do comportamento do tr afego de redes TCP/IP. Finalmente, s ao relatados os resultados obtidos com o sistema desenvolvido, mostrando a eci encia, capacidade e possibilidades de sua aplica c ao.

STATEFUL ANALYSIS OF TCP/IP NETWORK TRAFFIC FOR INTRUSION DETECTION APPLICATION

ABSTRACT In this work, the development of a session reconstruction methodology for TCP/IP network trac is presented. The methodology is model-based and uses netwok trac extracted data for the reconstruction and tracking of sessions state using only packet headers. By extrapolating the concept of session this modeling allows not just the reconstruction and tracking of TCP sessions states, but also the reconstruction of ICMP and UDP sessions. The model has been designed to support the development of the TCP/IP Sessions Reconstruction System - RECON - for use in intrusion detection. Since the state and packets history associated with a session can be used to decide if the trac is part of an attack, dierently from other methods that based decisions on a packet by packet exam, the use of this methodology can reduce the number of false-positives and false-negatives. It also possible to correlate informations from a set of sessions for the identication of hostile activities that can not be observed in an isolated session. The system makes use of a sensor that is appropriatedly located to capture packets from network trac and to store captured data in les regularly. This les are transfered to an analysis station, where RECON runs. One feature of this methodology is the ability to treat large amount of trac, due to the use of a reduced amount of data associated with the packet headers. The developed system can also operate as a support tool, applied not just to intrusion detection but also to the management, monitoring and testing of TCP/IP network trac. Finally, the results obtained with the developed system are reported and showing the eciency, capability and possible applications.

 SUMARIO P ag.

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTA DE SIGLAS E ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAP ITULO 1 INTRODUC AO ` REDE MUNDIAL E A ` REDE BR . . . 1.1 RISCOS RELACIONADOS A . . . . . . . . . . . 1.2 SEGURANCA DE SISTEMAS DE INFORMAC AO DOS SISTEMAS DE DETECC DE INTRUSAO 1.3 A EVOLUC AO AO . . . . . . . . . . . . .

17 19 21 23 23 26 28 29 31 31 32 33 35 36 37 37 38 40 41 47 47 49 50 53 53 55 56 59 61

1.4 PROPOSITOS, MOTIVAC OES E ESBOCO GERAL DESTE TRABALHO CAP ITULO 2 TECNOLOGIA TCP/IP . . . . . . . . . . . . . . . . . . 2.1 PILHA DE PROTOCOLOS TCP/IP . . . . . . . . . . . . . . . . . . . . . . 2.2 PROTOCOLOS ARP e RARP . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 PROTOCOLO IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 PROTOCOLO ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Mensagens ICMP de Erro . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Mensagens ICMP de Informa ca o . . . . . . . . . . . . . . . . . . . . . . . 2.5 PROTOCOLO UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 PROTOCOLO TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Estabelecimento e T ermino de uma Conex ao TCP . . . . . . . . . . . . . 2.7 APLICAC OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAP ITULO 3 CAPTURA DE PACOTES EM REDES . . . . . . . . . 3.1 ARQUITETURA PARA A CAPTURA DE PACOTES . . . . . . . . . . . . 3.2 BIBLIOTECA LIBPCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 TCPDUMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DE INTRUSAO CAP ITULO 4 DETECC AO . . . . . . . . . . . . . . . 4.1 CONCEITOS DE SEGURANCA DE SISTEMAS . . . . . . . . . . . . . . . DE INTRUSAO . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 DETECC AO 4.2.1 Detec ca o de Intrus ao por Anomalia . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Detec ca o de Intrus ao por Abuso . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Sistemas H bridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.4 Classica ca o dos Sistemas de Detec ca o por Tipo de An alise . . . . . . . . 4.2.5 O Estado da Arte em Sistemas de Detec ca o de Intrus oes . . . . . . . . . . 4.2.6 Sistemas de Detec ca o de Intrus ao Baseados em Rede . . . . . . . . . . . . AO DE SESSOES CAP ITULO 5 O SISTEMA DE RECONSTRUC TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 CONSIDERAC OES GERAIS SOBRE O DESENVOLVIMENTO DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Estrat egias de Captura de Pacotes . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Metodologia Adotada para Captura e An alise de Dados . . . . . . . . . . . 5.2 MODELAGEM DAS SESSOES TCP/IP . . . . . . . . . . . . . . . . . . . . 5.2.1 Representa ca o utilizando Grafos . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Solu ca o para o Problema de Localiza ca o de V ertices . . . . . . . . . . . .

61 62 64

75 75 75 76 77 79 81

5.2.3 Vis ao Geral do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.3 A IMPLEMENTAC AO DO SISTEMA DE RECONSTRUC AO DE SESSOES 86 5.3.1 Recursos Utilizados no Desenvolvimento do Sistema . . . . . . . . . . . . . 5.3.2 Vis ao Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 A Inicializa ca o dos Contadores Globais . . . . . . . . . . . . . . . . . . . . 5.3.4 O Parser do Arquivo de Congura c ao . . . . . . . . . . . . . . . . . . . . 5.3.5 O Vericador de Argumentos e Par ametros Obtidos do Arquivo de Congura ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.6 O Leitor do Tr afego de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.7 O Processador de Pacote . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.8 O Processador IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.9 O Desfragmentador IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.10 O Processador ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.11 O Processador UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.12 O Processador TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.13 O Gerador de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . CAP ITULO 6 RESULTADOS OBTIDOS . . . . . . . . . . . . DOS DADOS UTILIZADOS NA ANALISE 6.1 OBTENC AO . . . . . DE RECURSOS . . . . . . . . . . 6.2 DESEMPENHO E ALOCAC AO 6.3 ESTAT ISTICAS SUMARIZADAS . . . . . . . . . . . . . . . . . . 87 87 89 89 91 92 93 94 98 103 108 112 120

. . . . . 121 . . . . . . . . . . . . . . . 121 122 124 125 125 127 128 130

DAS SESSOES 6.4 RECONSTRUC AO ICMP . . . . . . . . . . . . . . . . . . . 6.4.1 Pacotes ICMP de Erro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Sess oes ICMP de Informa ca o . . . . . . . . . . . . . . . . . . . . . . . . . IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 DESFRAGMENTAC AO DAS SESSOES 6.6 RECONSTRUC AO UDP . . . . . . . . . . . . . . . . . . .

 DAS SESSOES 6.7 RECONSTRUC AO TCP . . . . . . . . . . . . . . . . . . ` DE INTRUSAO 6.8 ATIVIDADES RELACIONADAS A DETECC AO . . . 6.8.1 A Arvore de Logs TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8.2 Alertas da Arvore de Desfragmenta ca o . . . . . . . . . . . . . . . . . .

. . . . . . . .

133 137 137 139 140 147 149

6.8.3 Detec ca o de Host Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8.4 Investiga ca o do Uso de ICMP/Echo . . . . . . . . . . . . . . . . . . . . . . 6.8.5 Detec ca o de Ferramentas Automatizadas para a Cria c ao de Backdoors . .

. . . . . . . . . . . . . . . . . . . . . . . . 153 CAP ITULO 7 CONCLUSOES 7.1 SUGESTOES PARA TRABALHOS FUTUROS . . . . . . . . . . . . . . . . 154 7.1.1 Estruturas de Armazenamento do Tr afego de Rede . . . . . . . . . . . . . 7.1.2 M odulos Utilizados na Reconstru ca o de Sess oes . . . . . . . . . . . . . . . 7.1.3 Rotinas para a Aplica ca o em Detec ca o de Intrus ao . . . . . . . . . . . . . 7.2 CONSIDERAC OES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 155 156 156

REFERENCIAS BIBLIOGRAFICAS . . . . . . . . . . . . . . . . . . . . . 159 APENDICE A MENSAGENS ICMP: TIPOS E CODIGOS . . . . . . . 167 DO SISTEMA APENDICE B DETALHES DE IMPLEMENTAC AO RECON . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 B.1 OS CONTADORES GLOBAIS DO SISTEMA . . . . . . . . . . . . . . . . . 169 B.2 EXEMPLO DE UM ARQUIVO DE CONFIGURAC AO . . . . . . . . . . . 171 B.3 LISTAGEM DESCRITIVA DOS ARGUMENTOS DO RECON . . . . . . . 172

LISTA DE FIGURAS P ag.

1.1 2.1

Sostica c ao dos ataques verso conhecimento t ecnico dos intrusos. . . . . . . Os 4 n veis conceituais da tecnologia TCP/IP e os objetos que trafegam entre n veis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

31 33 34 35 36 37 38 39

2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

V arios protocolos nas diferentes camadas da tecnologia TCP/IP. . . . . . . . Datagrama IP, mostrando os campos no cabe calho IP. . . . . . . . . . . . . Formato da mensagem ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . Formato da mensagem ICMP de erro. . . . . . . . . . . . . . . . . . . . . . . Formato da mensagem ICMP de informa c ao. . . . . . . . . . . . . . . . . . . Formato da mensagem UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . Formato da mensagem TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . (A) Estabelecimento de uma conex ao TCP. (B) Encerramento de uma conex ao TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40 48 51 57 59 60 76 81

3.1 3.2 4.1 4.2 4.3 5.1 5.2

Esquema da arquitetura BPF (BSD Packet Filtering).

. . . . . . . . . . . .

Etapas de processamento de um pacote TCP/IP realizadas pelo tcpdump. . . Sistema de Detec c ao de Intrus ao por Anomalia (esquema b asico). . . . . . . Sistema de Detec c ao de Intrus ao por Abuso (esquema b asico). . . . . . . . . Representa c ao de Eventos com Diagrama de Transi c ao de Estados. . . . . . Posicionamento do sensor de rede. . . . . . . . . . . . . . . . . . . . . . . . . Grafo G representando o tr afego de rede e sua listas de adjac encias. . . . . .

 5.3 Arvore bin aria balanceada associada a lista de adjac encia. . . . . . . . . . . 5.4 5.5 5.6 5.7 5.8 5.9 Vis ao geral do modelo para a reconstru c ao de sess oes. . . . . . . . . . . . . . Sess oes TCP/IP associadas a cada par de IPs interconectados. . . . . . . . . Vis ao geral da implementa c ao do RECON. . . . . . . . . . . . . . . . . . . . Linha gerada na execu c ao do RECON sem argumentos. . . . . . . . . . . . . Estrutura adicionada pela biblioteca libpcap a cada pacote. . . . . . . . . . . Estruturas de armazenamento da arvore bin aria de IPs, lista de adjac encias e bloco de sess oes TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 Estrutura de armazenamento dos dados obtidos do datagrama IP. . . . . . . 5.11 Esquema de armazenamento dos fragmentos IP. . . . . . . . . . . . . . . . . 5.12 Estruturas de armazenamento dos fragmentos IP. . . . . . . . . . . . . . . . 5.13 Estruturas de armazenamento das sess oes ICMP de informa c ao. . . . . . . . 5.14 Estruturas de armazenamento das sess oes ICMP de erro. . . . . . . . . . . . 5.15 Estruturas de armazenamento das sess oes UDP. . . . . . . . . . . . . . . . . 5.16 Diagrama de transi c ao de estados para as sess oes TCP. . . . . . . . . . . . . 5.17 Estruturas de armazenamento das sess oes TCP. . . . . . . . . . . . . . . . . 5.18 Estruturas de armazenamento da arvore de logs TCP. . . . . . . . . . . . . .

82 83 86 88 91 94

96 98 99 100 104 107 111 116 118 119

LISTA DE TABELAS P ag.

2.1 5.1 5.2 5.3 6.1 6.2 6.3

Alguns servi cos/aplica c oes de rede . . . . . . . . . . . . . . . . . . . . . . . Codica c ao da dire c ao do pacote . . . . . . . . . . . . . . . . . . . . . . . . Identica c ao do tipo do pacote NTP . . . . . . . . . . . . . . . . . . . . . . Atividades stealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M edias hor arias calculadas sobre o tr afego do per odo. . . . . . . . . . . . . M edia dos tempos por pacote nas etapas de execu c ao. . . . . . . . . . . . . . M edia de area de armazenamento alocada por pacote. . . . . . . . . . . . . .

42 97 110 115 122 123 123 167 169

A.1 Tipos e c odigos das mensagens ICMP . . . . . . . . . . . . . . . . . . . . . . B.1 Contadores globais do RECON . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE SIGLAS E ABREVIATURAS

API ARP BPF BSD CVE CERT CERT/CC DNS FTP HTTP IANA IDS IDSs ICMP IMAP IP I/O NFS NTP POP RARP RFC RPC SDI SDIs SDIR SDIRs SMTP SNMP SSH TCP TCP/IP UDP

Application Programming Interface Address Resolution Protocol BSD Packet Filtering Berkeley Systems Development Common Vulnerabilities and Exposures Computer Emergency Response Team Computer Emergency Response Team/Coordinate Center Domain Name System File Transfer Protocol Hypertext Transfer Protocol Internet Assigned Numbers Authority Intrusion Detection System Intrusion Detection Systems Internet Control Message Protocol Internet Message Access Protocol Internet Protocol Input/Output Network File System Network Time Protocol Post Oce Protocol Reverse Address Resolution Protocol Request for Comments Remote Procedure Call Sistema de Detec c ao de Intrus ao Sistemas de Detec c ao de Intrus ao Sistema de Detec c ao de Intrus ao de Rede Sistemas de Detec c ao de Intrus ao de Rede Simple Mail Transfer Protocol Simple Network Management Protocol Secure Shell Transmission Control Protocol Transmission Control Protocol/Internet Protocol User Datagram Protocol

CAP ITULO 1 INTRODUC AO Este cap tulo apresenta uma breve discuss ao sobre os riscos associados ` as redes de computadores, com rela c ao ` a seguran ca, e sobre algumas caracter sticas associadas ` a sistemas de informa c oes seguros. Uma breve discuss ao sobre a evolu c ao dos sistemas de detec c ao de intrus ao e apresentada e, ao nal, s ao abordados os prop ositos e motiva c oes para a realiza c ao desta pesquisa. 1.1 ` REDE MUNDIAL E A ` REDE BR RISCOS RELACIONADOS A

O alto n vel de conectividade das redes de computadores que comp oem a Internet e o avan co no desenvolvimento de tecnologias relacionadas a redes de computadores, v em proporcionando a sensa c ao de que acessar um computador do outro lado do mundo n ao e mais dif cil do que acessar um computador na sala ao lado. Com isso, as organiza c oes passaram a conar e utilizar tecnologias de Internet como meio de comunica c ao de dados e para o com ercio eletr onico, o que despertou a preocupa c ao com a seguran ca de seus sistemas de informa c ao. Pessoas mal intencionadas poderiam estar utilizando a grande rede para desferir ataques contra os computadores e sistemas destas organiza c oes. Estes ataques poderiam causar grandes danos ` as organiza c oes, portanto algumas destas passaram a investigar a possibilidade de estarem sendo atacadas e quais vulnerabilidades estavam sendo utilizadas para este prop osito. Tem-se observado a crescente preocupa c ao destas organiza c oes para com as quest oes relacionadas ` a seguran ca de seus sistemas, de modo que estas t em dispendido grandes esfor cos na constru c ao e implanta c ao de sistemas de monitoramento e an alise, na busca de uma melhor capacita c ao para reagir a poss veis incidentes de seguran ca. A quest ao e que o aperfei coamento da seguran ca dos sistemas de informa c ao de uma organiza c ao, normalmente, e uma tarefa ardua e requer comprometimento e responsabilidade por parte dos prossionais respons aveis. Al em da constante e crescente preocupa c ao com amea cas externas, administradores de sistemas e analistas de seguran ca est ao saturados com uma s erie de problemas relacionados ` as redes e sistemas internos ` a organiza c ao. Estes problemas envolvem o constante esfor co para o cumprimento da pol tica de seguran ca da organiza c ao, quando esta existe, usu arios utilizando senhas fracas e disponibilizando suas senhas para pessoas n ao-autorizadas, abusos de privil egios e acesso n ao-autorizado a redes e sistemas da organiza c ao, e invas oes partindo da rede interna. Este u ltimo impacta diretamente em um dos principais preju zos sofridos por uma organiza c ao: as perdas nanceiras.

23

Mesmo quando nenhum destes problemas est a ocorrendo, administradores dispendem horas ou dias de trabalho atualizando sistemas operacionais e aplica c oes associadas a servi cos de rede disponibilizados na organiza c ao. Apesar dos desenvolvedores terem conhecimento dos problemas gerados por falhas na implementa c ao de sistemas computacionais, cuidados para evitar estes tipos de problemas ainda n ao foram incorporados nos processos de desenvolvimento de software. Em grande parte dos casos, estas falhas s ao diretamente respons aveis e correspondem a vulnerabilidades de seguran ca. Em 1999, o MITRE Corporation1 iniciou o desenvolvimento do CVE2 ( Common Vulnerabilities and Exposures ), um dicion ario ou lista padronizada de nomes para todas as vulnerabilidades de seguran ca publicamente conhecidas. A grande maioria das entradas desta lista refere-se a falhas na implementa c ao de aplica c oes de rede e sistemas operacionais, que podem, em muitos casos, ser utilizadas no comprometimento de sistemas tanto a partir da rede local quanto a partir de uma rede externa ou remota. Em sua u ltima vers ao, do dia 25/06/2002, estavam catalogadas 2223 vulnerabilidades ociais e 2613 vulnerabilidades candidatas. No ano 2000, o Computer Security Institute (CSI3 ) anunciou os resultados do quinto levantamento anual de crimes de computadores e seguran ca. Este levantamento e conduzido pelo CSI, em conjunto com o San Francisco Federal Bureau of Investigations (FBI) Computer Intrusion Squad. O principal objetivo e elevar o n vel de preocupa c ao com seguran ca, e determinar caracter sticas dos crimes de computadores nos Estados Unidos. Dentre os resultados, foram apontadas as seguintes quest oes: 90% dos que participaram do levantamento, tais como grandes corpora c oes e ag encias governamentais, detectaram viola c oes de seguran ca dentro dos u ltimos 12 meses; 70% relataram uma variedade de viola c oes de seguran ca mais s erias, como roubo de informa c oes propriet arias, fraudes nanceiras, intrus ao de sistemas (partindo de uma rede externa), ataques de nega c ao de servi co (denial-of-service) e sabotagem de dados ou redes; 74% noticaram perdas nanceiras, devido a viola c oes de seguran ca, e 42% (723 inspecionados) estavam aptos a quanticar suas perdas nanceiras, que giraram em torno de US$265,589,940 (a m edia anual total dos tr es anos anteriores foi US$120,240,180). Outros resultados mostraram que amea cas de crimes de computadores, visando grandes corpora c oes e ag encias governamentais v em tanto de dentro quanto de fora dos sistemas, conrmando as tend encias apontadas em anos anteriores. Em 2002, o AusCERT, juntamente ao Deloitte Touche e a NSW Police realizaram o pri1

P agina Web em: http://www.mitre.org. P agina Web em: http://cve.mitre.org 3 P agina Web em: http://www.gocsi.com.
2

24

meiro levantamento anual de crimes de computadores e seguran ca da Austr alia. Dentre os resultados, os seguintes apontamentos foram realizados: 67% das organiza c oes que participaram do levantamento sofreram um incidente de seguran ca em 2002 e 35% destas vivenciaram 6 ou mais incidentes; pela primeira vez na Austr alia a amea ca crescente de ataques externos superou a de ataques internos; 89% das organiza c oes australianas que sofreram incidentes de seguran ca foram atacadas remotamente, enquanto que menos de 65% foram atacadas internamente; 75 organiza c oes puderam identicar perdas nanceiras, mas apenas 60 puderam quantic a-las, sendo que estas giraram em torno de US$5,781,300. O ALLDAS.org4 , site que mant em uma base de dados de p aginas Web que tiveram seu conte udo alterado (defacement) como consequ encia de uma invas ao, j a mant em em seus arquivos 35390 ocorr encias, sendo que 10430 correspondem a p aginas de organiza c oes comerciais (.com). Um outro aspecto que deve ser levando em conta e o desenvolvimento de ferramentas, utilizadas para desferir ataques contra estas organiza c oes. Inicialmente, o processo envolvido com a execu c ao de um ataque necessitava de um alto n vel de conhecimento t ecnico, por parte do intruso, e os recursos dispon veis para o desenvolvimento deste processo eram bem limitados. Mas com o passar do tempo, os ataques v em se tornando mais sosticados, e exigem um n vel de conhecimento t ecnico cada vez menor, por parte do intrusos. O grande respons avel por esta quest ao e o pr oprio advento da Internet. As informa c oes est ao dispon veis, e desta forma, ferramentas desenvolvidas para a realiza c ao de ataques s ao difundidas pela rede muito rapidamente. O maior trabalho de um intruso e encontrar o reposit orio, contendo a ferramenta certa, que realiza o ataque desejado. A Figura (1.1) apresenta um gr aco, que relaciona o n vel de conhecimento t ecnico dos intrusos, com a sostica c ao dos ataques, no decorrer dos anos. No ano de 2000, 21.756 incidentes de seguran ca foram reportados ao Carnegie Mellon University CERT/CC5 (Computer Emergency Response Team/Coordination Center). Este n umero cresceu mais de duas vezes no ano de 2001, totalizando 52.658 incidentes. E at e o presente momento, no ano de 2002, este n umero j a alcan ca 43.136 incidentes reportados. De 1988 a 2002, o n umero de incidentes totaliza 143.505 ocorr encias. e a orO Brazilian CERT, tamb em conhecido como NIC BR Security Oce (NBSO6 ), ganiza c ao respons avel por receber, analisar e responder a incidentes de seguran ca em
4 5

P agina Web em: http://www.alldas.org. P agina Web e estat sticas relacionadas encontradas em: http://www.cert.org. 6 P agina Web e estat sticas relacionadas encontradas em: http://www.nbso.nic.br.

25

computadores envolvendo redes conectadas a Internet brasileira. No ano de 1999, 3.107 ataques foram reportados ao NBSO, e este n umero cresceu para 5.997 ocorr encias em 2000. No primeiro trimestre de 2001, 3138 ataques foram reportados, onde: 0,22% constitu ram tentativas de obter/atualizar mapas de DNS; 15,42% ataques ao usu ario nal (direcionados a m aquinas pessoais); 0.83% nega c ao de servi cos (denial-of-service); 1.72% invas oes; 3,7% ataques a servidores Web; 77,66% varreduras, e 0,45% fraudes. Os totais relacionados a cada ano mostram uma tend encia crescente no n umero de ataques, de ano para ano.

High

Stealth/advanced scanning techniques Denial of Service Packet spoofing Sniffers

Tools

Distributed attack tools WWW attacks

Back doors Disabling audits Password guessing

Sweepers

Automated probes/scans GUI Network Management Diagnostics

Hijacking sessions Burglaries Exploiting known vulnerabilities Password cracking Selfreplicating code

Low 1980 1985 Intruder Knowledge 1990 1995 Attack sophistication 2000

FIGURA 1.1 Sostica c ao dos ataques verso conhecimento t ecnico dos intrusos. FONTE: adaptada de McHugh et al. (2000, p. 43). A inten c ao aqui e ressaltar que as organiza c oes est ao expostas a estes riscos. E tamb em mostrar a import ancia da seguran ca de sistemas de informa c oes, e mais especicamente, a import ancia do uso de sistemas que possam detectar viola c oes de seguran ca. 1.2 SEGURANCA DE SISTEMAS DE INFORMAC AO

De forma generalizada, a literatura especializada na area diz que a seguran ca de um sistema de informa c ao e das redes que o comp oem n ao pode ser garantida por um u nico mecanismo de defesa. Muitos acreditam que a utiliza c ao de um Firewall e suciente para proteger uma rede contra quaisquer tipos de amea cas. Mas o n vel de seguran ca de uma rede est a na verdade associado ` a maneira com que mecanismos de seguran ca s ao empregados. N ao existe um sistema gen erico e que concentre todas as solu c oes para os problemas da area e, portanto, seguran ca deve ser implementada em camadas e n ao concentrada em um u nico ponto, supostamente infal vel.

26

Esta abordagem, utilizada para garantir um bom n vel de seguran ca, est a relacionada primeiramente ao estabelecimento de uma pol tica de seguran ca, onde s ao denidos comportamentos que s ao permitidos ou proibidos, ferramentas e procedimentos necess arios a organiza c ao, e que disseminem o consenso entre gerentes e administradores. Uma boa pol tica de seguran ca, atrelada a deni c ao de uma pol tica de senhas para os usu arios do sistema, a preocupa c ao com a seguran ca de hosts, a utiliza c ao de Firewall, dividindo e controlando o acesso entre rede interna e externa, e a utiliza c ao de SDIs (Sistemas de Detec c ao de Intrus ao) constituem um bom exemplo de seguran ca em camadas, e que asseguram um bom n vel de seguran ca para a organiza c ao. Dentro desta abordagem, o Firewall constitui uma das ferramentas mais utilizadas atualmente, sendo que o tipo mais empregado e conhecido como ltro de pacotes. Basicamente, esses sistemas de ltragem examinam pacotes entrando ou saindo da rede, atrav es do uso de um conjunto de regras xas, que determinam se os pacotes ser ao ou n ao aceitos. Inicialmente, os sistemas de ltragem de pacotes tomavam decis oes, apenas analisando informa c oes, tais como endere cos IP de origem e destino, protocolo e portas, pacote por pacote, no momento em que entravam ou saiam do Firewall. Mesmo dispositivos um pouco mais sosticados baseavam-se em informa c oes est aticas. Desta forma, a natureza destes sistemas de ltragem possibilitou que ferramentas fossem desenvolvidas para subverter este mecanismo de defesa. Para solucionar este problema, foram desenvolvidos ltros de pacotes din amicos (stateful), que mant em o estado das informa c oes entrando e saindo da rede. Desta forma, estes ltros podem checar se um pacote pertence a uma sess ao v alida, previamente estabelecida. A grande vantagem dos ltros de pacote din amicos e que o tr afego de retorno n ao precisa ser explicitamente especicado, simplicando assim, o conjunto de regras mantidas pelo Firewall. Hartmeier (2002) e Rooij (2002) apresentam boas refer encias sobre ltragem din amica de pacotes. Sabe-se, entretanto, que Firewalls do tipo ltro de pacotes n ao fornecem uma solu c ao completa para o problema de seguran ca. Uma de suas limita c oes consiste no fato de que este n ao pode bloquear uma tentativa de intrus ao ou abuso, que se aproveite de vulnerabilidades de servi cos habilitados, para os quais o tr afego e permitido. Da surge a necessidade de utiliza c ao de mecanismos que permitam detectar falhas de seguran ca, ou seja, detectar intrus oes ou tentativas de intrus oes. Estes mecanismos s ao conhecidos como SDIs - Sistemas de Detec c ao de Intrus ao - e desempenham a fun c ao de mais uma camada de defesa em um sistema de informa c ao.

27

1.3

DOS SISTEMAS DE DETECC DE INTRUSAO A EVOLUC AO AO

Em 1987, Denning (1987) desenvolveu o primeiro modelo gen erico de detec c ao de intrus ao que se tem conhecimento, independente de qualquer sistema em particular, vulnerabilidade de sistema ou tipo de intrus ao. Este utilizava dados estat sticos, gerados ` a partir de registros de auditoria, e baseava-se na hip otese de que viola c oes de seguran ca poderiam ser detectadas atrav es do monitoramento desses registros, relacionados a padr oes anormais de uso do sistema. A partir da , m etodos de detec c ao de intrus ao foram desenvolvidos e dividiram-se, basicamente, em duas categorias: detec c ao por anomalia e a detec c ao por abuso. A primeira baseia-se na id eia de que todo evento intrusivo e necessariamente an omalo, sendo um subconjunto da atividade an omala, e normalmente est a associada a t ecnicas estat sticas. J a a segunda baseia-se na id eia de que ataques podem ser representados na forma de padr oes ou assinaturas (sequ encia de eventos e condi c oes que levam a uma intrus ao). Sistemas de detec c ao de intrus ao foram desenvolvidos (Allen et al., 2000) (Bace e Mell, 2000) baseados nestes dois m etodos, e alguns at e utilizam os dois m etodos simultaneamente. Estes u ltimos caram conhecidos como sistemas h bridos. Estes sistemas ser ao discutidos em detalhes no Cap tulo 4. Os primeiros SDIs baseavam-se apenas em informa c oes obtidas de um determinado host, e em sua linha de evolu c ao, foram rapidamente adaptados para utilizar como base informac oes coletadas do tr afego de rede. Estes sistemas s ao conhecidos como SDIs network-based. Nesta nova abordagem, que e amplamente utilizada na atualidade, os SDIs de maior destaque utilizam detec c ao por reconhecimento de padr oes, onde ataques s ao codicados em assinaturas (padr oes), de forma que estas possam ser identicadas pelo mecanismo de detec c ao. At e h a algum tempo, estes sistemas, da mesma forma que os ltros de pacotes est aticos, baseavam-se na an alise de informa c oes avaliadas pacote por pacote, ` a medida que estes eram processados. Caso as informa c oes utilizadas no reconhecimento de uma assinatura de ataque estivessem divididas em mais de um pacote, muitas vezes o SDI falhava na detec c ao. A natureza est atica destes SDIs permitiu o desenvolvimento de ferramentas, tais como o stick (Giovanni, 2002) e o fragrouter7 (Ptacek e Newsham, 1998), cujo principal objetivo era subverter os mecanismos de detec c ao de intrus ao. A base de regras do pr oprio SDI, contendo as assinaturas de ataques, era utilizada para gerar o tr afego de rede com os padr oes intrusivos. Ent ao, o SDI gerava uma innidade de alarmes que, muitas vezes,
7

man page: http://www.gnusec.com/resource/security-stuff/IDS/fragrouter.html

28

caracterizavam um ataque de nega c ao de servi cos (denial-of-service) para o pr oprio SDI. Al em disso, um ataque real poderia ser inserido neste tr afego, de modo que este n ao seria detectado, em meio a tantos alarmes. Atualmente, desenvolvedores de sistemas de detec c ao de intrus ao t em se preocupado com estas quest oes e alguns SDIs, na maioria comerciais, j a implementam funcionalidades relacionadas a reconstru c ao e a avalia c ao do estado das sess oes. Estes s ao conhecidos como SDIs stateful. Outros sistemas, um pouco mais sosticados, j a fazem a an alise de protocolos de aplica c ao, mas utilizam como base as funcionalidades mencionadas anteriormente. O grande problema e que estas solu c oes s ao propriet arias, tendo seu c odigo fechado e um alto custo atrelado. Outra quest ao est a relacionada a quantidade de recursos necess arios a implementa c ao destas solu c oes. A maioria destes sistemas realizam a detec c ao de intrus oes em tempo real e utilizam o conte udo dos pacotes nesta tarefa. Portanto, a quantidade de dados a ser avaliada e mantida e normalmente muito grande. Isso acaba tendo uma forte implica c ao no desempenho dos sistemas de detec c ao modernos, considerando em particular o grande aumento de banda dispon vel nas redes atuais (Mueller e Shipley, 2001). Outro aspecto que solu c oes propriet arias endere cam e o da captura de pacotes em redes de alta velocidade. V em sendo desenvolvidos drivers propriet arios para interfaces de rede que operam com alta eci encia, evitando, dessa maneira, as limita c oes das bibliotecas de captura publicamente dispon veis (libpcap), que come cam a perder pacotes para taxas de transmiss ao acima de algumas dezenas de megabits por segundo. 1.4 PROPOSITOS, MOTIVAC OES E ESBOCO GERAL DESTE TRABALHO

O que se pretende com este trabalho e propor, desenvolver e testar uma metodologia de reconstru c ao de sess oes para o tr afego de redes TCP/IP. Esta metodologia baseia-se em um modelo, gerado ` a partir de dados extra dos do tr afego de rede, que permite reconstruir e rastrear o estado das sess oes, utilizando apenas o cabe calho dos pacotes. Este modelo e, ent ao, utilizado como base para o desenvolvimento do RECON - Sistema de Reconstru c ao de Sess oes TCP/IP - a ser utilizado em aplica c oes associadas ` a detec c ao de intrus ao, e at e mesmo em tarefas de monitoramento e estudo do comportamento do tr afego de redes. A principal motiva c ao deste trabalho foi o desenvolvimento de recursos para a supera c ao de algumas das fragilidades dos atuais sistemas de detec c ao de intrus ao. Assim, buscou-se fazer uso de uma metodologia de reconstru c ao de sess oes, que possibilita a redu c ao do n umero de falso-positivos e falso-negativos, visto que o estado e todo o hist orico de pacotes

29

que comp oem uma sess ao podem ser utilizados na tomada de decis oes, em contrapartida aquelas que tomam decis ` oes avaliando pacote a pacote. Al em disso, a abordagem onde apenas os cabe calhos dos pacotes s ao analisados permite uma consider avel redu c ao na quantidade de dados do uxo de rede a ser capturada e avaliada. Desta forma, espera-se um melhor desempenho e eci encia de aplica c oes baseadas nestas caracter sticas. Deve-se considerar tamb em que esta metodologia permite a correla c ao de sess oes, que isoladamente n ao representariam uma atividade hostil, como por exemplo a utiliza c ao de uma m aquina intermedi aria para o lan camento de ataques ou a abertura de uma porta dos fundos em sistemas comprometidos. E por m, o sistema desenvolvido pode funcionar como uma ferramenta de suporte, de modo que este poder a ser aplicado n ao s o` a detec c ao de intrus oes, mas tamb em a outras atividades, tais como o monitoramento e a gera c ao de estat sticas relacionadas ao tr afego de redes. O restante desta disserta c ao est a organizado em seis cap tulos. O Cap tulo 2 faz uma breve revis ao te orica sobre a tecnologia TCP/IP, onde e apresentada a pilha de protocolos TCP/IP, com uma descri c ao de cada camada, seus respectivos protocolos, e algumas aplica c oes. O Cap tulo 3 apresenta uma revis ao sobre captura de pacotes, baseada em apresentada tamb uma arquitetura espec ca. E em a biblioteca que implementa esta arquitetura, bem como uma aplica c ao que faz uso dessa biblioteca. O Cap tulo 4 discute conceitos e princ pios relacionados a seguran ca de sistemas de informa c ao e detec c ao de intrus ao. Nele s ao abordadas as principais categorias e m etodos de detec c ao de intrus ao, al em de apresentar alguns exemplos de sistemas de detec c ao de intrus ao projetados e implementados. O Cap tulo 5 prop oe um modelo para a reconstru c ao de sess oes TCP/IP e apresenta de forma detalhada a implementa c ao do RECON, sistema de reconstru c ao de Sess oes TCP/IP baseado na modelagem proposta. O Cap tulo 6 apresenta e discute os resultados obtidos com o sistema desenvolvido. E por u ltimo, o Cap tulo 7 apresenta as conclus oes e algumas propostas para a continua c ao desta pesquisa.

30

CAP ITULO 2 TECNOLOGIA TCP/IP Este cap tulo mostra uma breve revis ao te orica sobre a tecnologia TCP/IP, assunto fundamental para o entendimento do funcionamento de sistemas de detec c ao de intrus ao, atualmente dispon veis e utilizados nas redes de computadores conectadas ` a Internet. E apresentada a pilha de protocolos TCP/IP, com uma breve descri c ao de cada camada e de seus respectivos protocolos, bem como algumas aplica c oes dentre as v arias que merecem aten c ao com rela c ao a seguran ca de redes de computadores. 2.1 PILHA DE PROTOCOLOS TCP/IP

A pilha de protocolos TCP/IP e organizada em quatro n veis ou camadas conceituais, constru das sobre uma quinta camada (Comer, 2000), correspondente ao n vel f sico ou de hardware, como mostra a Figura (2.1).

Nvel Conceitual Aplicao

Objetos que Trafegam entre Nveis

Mensagens ou Cadeias Transporte Pacotes do Protocolo de Transporte Rede Datagramas IP Enlace de Dados Frames Especficos da Rede Fsico

FIGURA 2.1 Os 4 n veis conceituais da tecnologia TCP/IP e os objetos que trafegam entre n veis. FONTE: adaptada de Comer (2000, p. 184). As fun c oes das camada da pilha de protocolos s ao apresentadas como se segue. Camada de Aplica c ao: corresponde ao n vel mais alto, onde usu arios executam aplica c oes, atrav es da utiliza c ao de servi cos dispon veis em uma rede TCP/IP. Uma aplica c ao interage com os protocolos da camada de transporte para enviar ou receber dados. Cada aplica c ao escolhe o tipo de transporte, que pode ser uma sequ encia de mensagens individuais ou uma cadeia cont nua de bytes. Camada de Transporte: a nalidade da camada de transporte e prover comunica c ao entre aplica c oes, comumente denominada comunica c ao m-a-m. Essa camada e respons avel pelo estabelecimento e controle do uxo de dados entre dois hosts. Al em disso, pode

31

prover transporte con avel, de modo a garantir que as informa c oes sejam entregues sem erros e na sequ encia correta. A cadeia de dados sendo transmitida e dividida em pacotes, que s ao passados para camada seguinte (rede). Camada de Rede: a camada de rede trata da comunica c ao entre hosts. Esta aceita uma requisi c ao de envio de pacote vinda da camada de transporte, com a identica c ao do host para onde o pacote deve ser transmitido. Encapsula o pacote em um datagrama IP e preenche o cabe calho do datagrama com os endere cos l ogicos de origem e destino, dentre outros dados. Tamb em utiliza um algoritmo de roteamento para determinar se o datagrama deve ser entregue diretamente, ou enviado para um gateway. Finalmente, o datagrama e passado para a interface de rede apropriada, para que este possa ser transmitido. Camada de Enlace de Dados: e a camada de n vel mais baixo na pilha de camadas da respons tecnologia TCP/IP. E avel por aceitar os datagramas IP, encapsul a-los em frames, preencher o cabe calho de cada frame com os endere cos f sicos de origem e destino, dentre outros dados, e transmit -los para uma rede espec ca. Na camada de enlace de dados est a o device-driver da interface de rede, por onde e feita a comunica c ao com a camada f sica. Camada F sica: esta camada corresponde ao n vel de hardware, ou meio f sico, que trata dos sinais eletr onicos. Esta recebe os frames da camada de enlace, convertidos em sinais eletr onicos compat veis com o meio f sico, e os conduz at e a pr oxima interface de rede, que pode ser a do host destino ou a do gateway da rede, caso esta n ao perten ca a rede local. Stevens (Stevens, 1994) apresenta essas camadas subdivididas em v arios protocolos, ilustrados na Figura (2.2). As descri co es dos principais protocolos mostrados nesta gura s ao apresentadas nas sess oes seguintes. 2.2 PROTOCOLOS ARP e RARP

O protocolo ARP (Address Resolution Protocol) (Plummer, 2002) foi originalmente projetado para interfaces do tipo 10 Mbit Ethernet, mas foi generalizado para outros tipos de hardware. O m odulo de resolu c ao de endere cos, normalmente parte do driver do dispositivo de hardware, recebe um par <tipo-de-protocolo, endere co-destino> e tenta encontr a-lo em uma tabela. Se o par for encontrado, e retornado o endere co do hardware (f sico) correspondente, para que o pacote possa ser transmitido. Caso contr ario, e normalmente informado que o pacote ser a descartado. Um exemplo comum na Internet e a utiliza c ao do ARP para converter endere cos IP, de 32 bits, em endere cos Ethernet, de 48 bits.

32

A fun c ao do protocolo RARP (Reverse Address Resolution Protocol) (Finlayson et al., 2002) e inversa ao ARP, ou seja, converte um endere co de hardware (f sico) em um usado principalmente por n endere co Internet. E os de rede do tipo diskless, ou seja, que n ao possuem um endere co Internet armazenado localmente. No momento da inicializa c ao, o RARP e usado para encontrar o endere co Internet correspondente ao endere co de hardware do n o, que e conhecido.

Processo de usurio

Processo de usurio

Processo de usurio

Processo de usurio

Aplicao

TCP

UDP

Transporte

ICMP

IP

IGMP

Rede

ARP

Interface de hardware Fsico

RARP

Enlace de dados

FIGURA 2.2 V arios protocolos nas diferentes camadas da tecnologia TCP/IP. FONTE: adaptada de Stevens (1994, p. 6). 2.3 PROTOCOLO IP

O protocolo IP (Internet Protocol) (Postel, 2002b) e a base ou suporte para os outros protocolos da pilha TCP/IP, tais como ICMP, UDP e TCP, que s ao transmitidos em datagramas IP, como mostrado na Figura (2.2). Datagramas IP podem ser denidos como blocos de dados transmitidos de uma determinada origem para um destino, de forma que origens e destinos s ao hosts identicados por endere cos l ogicos de tamanho xo. Uma caracter stica deste protocolo e a possibilidade de fragmentar e remontar datagramas, de modo que estes possam ser transmitidos entre redes que suportem diferentes especicamente projetado para prover as fun tamanhos por bloco de dados. E c oes necess arias para entregar pacotes de bits (datagramas IP) de uma origem para um destino determinado, em redes interconectadas.

33

Este e comumente denominado por servi co de entrega de datagramas n ao orientado ` a conex ao, pois n ao existem mecanismos para aumentar a conabilidade de dados ma-m, controle de uxo, sequenciamento, ou outros servi cos que normalmente s ao de responsabilidade dos protocolos de n veis mais altos. O protocolo IP tamb em incorpora a fun c ao de roteamento, isto e, determina se o datagrama deve ser entregue diretamente a seu destino, caso origem e destino perten cam ` a mesma rede, ou entregue ao gateway da rede contendo a origem, para o caso contr ario. Se o mecanismo de roteamento decide que o datagrama deve ser enviado ao gateway, ent ao este passa a ser respons avel por enviar o datagrama para o seu destino. O IP baseia-se na id eia de entrega de datagramas sem garantias, portanto inclui um conjunto de regras que dizem como hosts e gateways devem processar os datagramas, quando e como uma mensagem de erro deve ser gerada e as condi c oes nas quais datagramas devem ser descartados (Comer, 2000). A Figura (2.3) mostra o cabe calho de um datagrama IP, e uma breve descri c ao, baseada em (Postel, 2002b) e (Stevens, 1994), de alguns de seus campos e apresentada como se segue.

Bit 0

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Type of Servise (TOS) (8bits)

1 2

IP Version (4 bits)
0

Hdr Length (4 bits)

Total Length (16 bits)

3

4
4

Identification (Fragment ID) (16 bits)

5

R D M F F
6

Fragment Offset (13 bits)

7

8 Bytes

TimetoLive (TTL) (8bits)

8

Protocol (8bits)
9 10

Header Checksum (16 bits)

11

16
12 13

Source IP Address (32 bits)

14 15

12
16 17

Destination IP Address (32 bits)

18 19

20

Options (if any, variable length, padded with 0s, 40 bytes max length Data

FIGURA 2.3 Datagrama IP, mostrando os campos no cabe calho IP. FONTE: adaptada de Stevens (1994, p. 34). O campo version indica o formato do datagrama, que para este caso corresponde ao IP vers ao 4 (tamb em conhecido como IPv4). Hdr length cont em o tamanho do cabe calho IP, incluindo op c oes, caso estas ocorram. Type of Service prov e uma indica c ao de par ametros, relacionados a qualidade de servi co desejada, embora a maioria das implementa c oes TCP/IP n ao suportem esta caracter stica. Total Length cont em o tamanho total do datagrama, incluindo o cabe calho IP e os dados propriamente ditos. Identication e utilizado 34

20 Bytes

para identicar univocamente cada datagrama enviado por um host. O campo ags e dividido em tr es partes: R, DF e MF, sendo R o bit reservado e que normalmente tem o valor 0, DF o bit respons avel por dizer que o datagrama n ao deve ser fragmentado, e MF o bit respons avel por informar que o datagrama est a fragmentado e existem mais fragmentos. Oset indica o posicionamento do fragmento em um dado datagrama a ser remontado. Time to Live cont em um contador que indica o m aximo de roteadores pelos quais um datagrama pode passar. O campo Protocol diz qual e o protocolo utilizado pelo pr oximo n vel, ou seja, pelo n vel ou camada de transporte. E nalmente, os campos Source IP Address e Destination IP address cont em os endere cos l ogicos dos hosts de origem e destino, respectivamente. O tamanho do cabe calho IP e vari avel, de modo que um datagrama IP sem op c oes tem 20 bytes. Caso op c oes estejam presentes no datagrama, este pode ter at e 60 bytes. Detalhes sobre o campo options podem ser vistos em Postel (2002b). 2.4 PROTOCOLO ICMP

O protocolo ICMP (Internet Control Message Protocol) (Postel, 2002a) tem como nalidade relatar erros no processamento de datagramas IP, bem como prover mecanismos de investiga c ao na determina c ao de caracter sticas gerais de redes TCP/IP. Algumas das situa c oes em que mensagens ICMP s ao utilizadas: datagrama n ao pode alcan car seu destino, o buer de um gateway est a cheio e este n ao pode transmitir o datagrama, o tr afego deve ser direcionado para uma rota mais curta, vericar se um determinado host est a ativo, dentre outras. As mensagens ICMP s ao enviadas em datagramas IP. Embora o ICMP pare ca fazer parte do conjunto de protocolos de n vel mais alto, este e parte da implementa c ao do protocolo IP. O formato do cabe calho de uma mensagem ICMP e apresentado na Figura (2.4).

Bit

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Code (8bits)
1 2

Type (8bits)
0

Checksum (16 bits)

3

Data

FIGURA 2.4 Formato da mensagem ICMP. FONTE: adaptada de Stevens (1994, p. 70). Mensagens ICMP s ao identicadas pelo campo type, sendo que algumas destas utilizam valores diferentes para o campo code. Isto permite que um tipo de mensagem possa especicar diferentes condi c oes, como mostra a tabela A.1. 35

O ICMP utiliza duas formas de opera c ao, portanto pode ser dividido em duas categorias: mensagens de erro e mensagens de requisi c ao, sendo que a u ltima tamb em e referenciada neste trabalho como mensagens de informa c ao. 2.4.1 Mensagens ICMP de Erro

Mensagens ICMP de erro s ao utilizadas para relatar problemas referentes a n ao entrega de um datagrama IP (Arkin, 2002). O formato gen erico do cabe calho de uma mensagem ICMP de erro e apresentado na Figura (2.5).

Bit

6 7

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Code (8bits)
1 2

Type (8bits)
0

Checksum (16 bits)

3

Depends on the Error Message Type

0 4 0 5 0 6 0 7

IP Header + 64 bits of original data of the datagram

FIGURA 2.5 Formato da mensagem ICMP de erro. FONTE: adaptada de Arkin (2002, p. 17). Os 4 bytes, especicados na Figura (2.5) por Depends on the Error Message Type, s ao dependentes do tipo de mensagem utilizada. Para cada mensagem de erro, esta area do cabe calho poder a ser dividida em um ou mais campos. Toda mensagem ICMP de erro inclui o cabe calho IP e pelo menos os primeiros 8 bytes de dados do datagrama que ocasionou o erro. Como o tamanho do cabe calho IP pode variar entre 20 e 60 bytes, o tamanho de uma mensagem ICMP de erro deve estar entre 36 e 72 bytes. Arkin (2002) apresenta algumas regras de uso do protocolo ICMP para mensagens de erro, onde s ao enumeradas algumas situa c oes em que estas mensagens n ao devem ser enviadas. Sendo assim, mensagens ICMP de erro n ao s ao enviadas: em resposta a outra mensagem de erro, para evitar ciclos intermin aveis; em resposta a datagramas destinados a endere cos de broadcast ou multicast; em resposta a broadcasts da camada de enlace; em resposta a datagramas, cujo endere co de origem n ao represente um u nico host.

36

2.4.2

Mensagens ICMP de Informa c ao

Segundo Arkin (2002), mensagens ICMP de informa c ao (ou requisi c ao) s ao utilizadas na obten c ao de informa c oes gerais de redes TCP/IP, atrav es de requisi c oes e respostas. Estas informa c oes podem variar desde a disponibilidade de um host (m aquina est a ativa e conectada ` a rede), at e a lat encia da rede. Neste ponto, entende-se por lat encia de rede o tempo observado, desde a sa da da mensagem de requisi c ao partindo do host na rede origem, at e a chegada da mensagem de resposta, enviada pelo host na rede destino. O formato gen erico do cabe calho de uma mensagem ICMP de informa c ao e apresentado na Figura (2.6).

Bit

6 7

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Code (8bits)
1 2

Type (8bits)
0

Checksum (16 bits)

3

Identifier
0 4 0 5 0 6

Sequence Number
0 7

Depends on the Query Message Type

FIGURA 2.6 Formato da mensagem ICMP de informa c ao. FONTE: adaptada de Arkin (2002, p. 25). O campo identier tem como fun c ao diferenciar mensagens ICMP enviadas para hosts distintos. J a o campo sequence number e utilizado para diferenciar mensagens ICMP enviadas para um mesmo host. O tamanho de uma mensagem ICMP de informa c ao varia de acordo com o tipo da mensagem, sendo que seu cabe calho sempre ocupar a 8 bytes. Por exemplo, no caso de mensagens do tipo Timestamp Request e Timestamp Reply - vide Tabela (A.1) - al em dos 8 bytes, que s ao xos para mensagens de informa c ao, tem-se mais 12 bytes, referentes aos campos Originate Timestamp, Receive Timestamp e Transmit Timestamp, que fazem parte do conte udo da mensagem e s ao intr nsecos a este tipo (Arkin, 2002). 2.5 PROTOCOLO UDP

O protocolo UDP (User Datagram Protocol) (Postel, 2002e) prov e um mecanismo n ao orientado a conex ao1 e sem garantias, que atrav es da utiliza c ao do protocolo IP, envia e recebe datagramas de uma aplica c ao para a outra. S ao utilizados n umeros de portas para distinguir entre v arias aplica co es em um mesmo host, ou seja, cada mensagem UDP cont em uma porta de origem e uma porta de destino.
1

O termo orientado ` a conex ao e melhor denido na se c ao 2.6.

37

Al em disso, uma aplica c ao baseada no protocolo UDP e inteiramente respons avel por problemas de conabilidade (perda e duplica c ao de pacotes, pacotes entregues fora de ordem, dentre outros) e problemas relacionados ` a conex ao. Programadores, ao desenvolverem aplica c oes baseadas em UDP, s ao respons aveis por implementar estas caracter sticas. Como isto normalmente n ao ocorre, este protocolo tem grande funcionalidade em ambientes locais e em aplica c oes que n ao requerem alta conabilidade (Comer, 2000). A mensagem UDP e chamada de user datagram e seu cabe calho segue o formato apresentado na Figura 2.7.

Bit 0 Bytes

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Destination Port Number

1 2 3

Source Port Number (16 bits)

0

4
4

UDP Length (16 bits)

5 6

UDP Checksum (16 bits)

7

Data

FIGURA 2.7 Formato da mensagem UDP. FONTE: adaptada de Stevens (1994, p. 144). Os campos Source Port Number e Destination Port Number s ao utilizados na identica c ao dos processos de envio e recebimento de dados, respectivamente. O campo UDP Length cont em o tamanho do cabe calho UDP mais o tamanho dos dados propriamente ditos. Deve-se observar que o menor valor para este campo e igual a 8 bytes, correspondente ao tamanho do cabe calho UDP, caso nenhum dado esteja sendo transmitido (Stevens, 1994). 2.6 PROTOCOLO TCP

O TCP (Transmission Control Protocol) (Postel, 2002d) e um protocolo de comunica c ao que prov e conex oes (circuitos virtuais) entre m aquinas, de forma con avel, ou seja, e um protocolo orientado ` a conex ao. Segundo Stevens (1994), o termo orientado ` a conex ao signica que duas aplica c oes, usando um protocolo que det em esta caracter stica, devem estabelecer uma conex ao bidirecional, antes de efetuar troca de dados. O protocolo e con avel porque quando um host envia dados a outro, o primeiro requer o reconhecimento relativo ` a chegada dos dados. Al em disso, os dados s ao sequenciados, de forma que um n umero de sequ encia e associado a todo pacote transmitido. Isto permite que dados sejam reordenados caso sejam recebidos fora de ordem, e descartados caso sejam duplica c oes de dados j a recebidos. Outra caracter stica e o controle de uxo, onde em uma conex ao, um host sempre informa ao outro quantos bytes poder ao ser aceitos,

38

8 Bytes

(16 bits)

evitando assim a ocorr encia de sobrecargas do buer do host que estiver recebendo dados (Stevens, 1998). O formato do cabe calho de uma mensagem TCP e apresentado na Figura 2.8 e cont em um grande n umero de campos, utilizados no controle da comunica c ao e transmiss ao de dados entre hosts. Uma breve descri c ao, baseada em (Postel, 2002d) e (Stevens, 1994), de alguns de seus campos e apresentada como se segue.

Bit 0

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Destination Port Number (16 bits)

1 2 3

Source Port Number (16 bits)

0

4
4 5

Sequence Number (32 bits)

6 7

8 Bytes
8 9

Acknowledgement Number (32 bits)

10 11

URG

ACK

SYN

PSH

RST

16

Hdr Length (4 bits)

12

Reserved (6 bits) TCP Checksum (16 bits)

16

FIN

Window Size (16 bits)

14 15

13

12

Urgent Pointer (16 bits)

17 18 19

20

Options (if any, variable length, padded with 0s, 40 bytes max length Data

FIGURA 2.8 Formato da mensagem TCP. FONTE: adaptada de Stevens (1994, p. 225). Os campos Source Port Number e Destination Port Number s ao utilizados na identica c ao das aplica c oes de envio e recebimento de dados, respectivamente. Quando combinados aos campos Source IP Address e Destination IP address do cabe calho IP (se c ao 2.3), identicam univocamente cada conex ao. Sequence Number informa o n umero de sequ encia do segmento, associado ao primeiro byte da cadeia de dados sendo transmitida. Para o segmento que representa o in cio de uma conex ao TCP, este campo recebe um valor atribu do pelo sistema operacional, conhecido como Initial Sequence Number (ISN). Para cada segmento subsequente, este valor e incrementado do n umero de bytes transmitidos pelo segmento anterior. Acknowledgement Number cont em o pr oximo n umero de sequ encia (ou sequence number) esperado. O campo Hdr Length informa o tamanho do cabe calho da mensagem TCP, que varia de 20 a 60 bytes. Se o cabe calho tem 20 bytes, ent ao n ao h a ocorr encia de op c oes2 . Window Size e respons avel por prover o controle de uxo implementado no protocolo TCP. Este informa qual e o n umero m aximo de bytes que podem ser recebidos por um host. O campo Urgent Pointer cont em um valor positivo a ser adicionado ao n umero de sequ encia do segmento, informando que os dados a partir do byte por este apontado tem maior prioridade.
2

Detalhes sobre o campo Options podem ser encontrados em Postel (2002d).

39

20 Bytes

Al em dos campos anteriormente descritos, o cabe calho TCP dene seis bits, conhecidos como ags, e suas fun co es s ao apresentadas como se segue. URG indica que o campo Urgent Pointer e v alido; ACK indica que o campo Acknowledgement Number e v alido; PSH indica que o host recebendo os dados deve repass a-los ` a aplica c ao assim que poss vel; RST indica o m abrupto da conex ao; SYN indica que os n umeros de sequ encia est ao sendo sincronizados para o in cio da conex ao; FIN indica que o host terminou o envio de dados e pretende encerrar a conex ao. Conex oes TCP s ao tamb em conhecidas como full-duplex, isto e, uma aplica c ao pode enviar e receber dados, em ambas as dire c oes, a qualquer momento. A id eia e que uma conex ao ocorre entre uma aplica c ao cliente e uma servidora, onde a cliente estabelece a conex ao, dados s ao transmitidos entre cliente/servidora e a conex ao e terminada. A subse c ao 2.6.1 descreve mais detalhadamente os precedimentos de in cio e t ermino de uma conex ao TCP. 2.6.1 Estabelecimento e T ermino de uma Conex ao TCP

A Figura 2.9 ilustra a troca de mensagens entre dois hosts, para o estabelecimento (A) e o t ermino (B) de uma conex ao TCP.

Eventos no Site 1

Mensagens na rede

Eventos no Site 2

Eventos no Site 1

Mensagens na rede

Eventos no Site 2

Envia SYN seq=x Recebe segmento SYN Envia SYN seq=y, ACK x+1 Recebe SYN + ACK Envia ACK y+1 Recebe segmento ACK (A)

Envia FIN seq=x Recebe segmento FIN Envia ACK x+1 Recebe segmento ACK Envia FIN seq=y Recebe segmento FIN Envia ACK y+1 Recebe segmento ACK (B)

FIGURA 2.9 (A) Estabelecimento de uma conex ao TCP. (B) Encerramento de uma conex ao TCP. FONTE: adaptada de Comer (2000, p. 238,240). 40

O estabelecimento de uma conex ao bidirecional TCP utiliza um processo conhecido como three-way handshake, que normalmente utiliza tr es mensagens. Algumas varia c oes para o seu estabelecimento podem ser encontradas em Postel (2002d).O cliente envia um segmento SYN (synchronize), passando ao servidor o n umero de sequ encia inicial para os dados que ser ao enviados. A aplica c ao servidora deve reconhecer o SYN enviado pelo cliente e, em seguida, enviar um SYN contendo seu n umero de sequ encia inicial e um ACK, normalmente contido no mesmo segmento. Ent ao, a cliente envia um ACK reconhecendo o SYN enviado pelo servidor. J a para o t ermino de uma conex ao TCP, normalmente s ao utilizados quatro mensagens, pois cada host envolvido e respons avel por fechar sua conex ao, j a que esta e bidirecional. Quando um host n ao possui mais dados a enviar, este solicita o encerramento da conex ao atrav es do envio de um segmento FIN, que deve ser reconhecido pelo outro host atrav es do envio de um segmento ACK para o solicitante. Com isto, estabelece-se que um lado da conex ao est a fechado. O lado da conex ao, que ainda est a aberto, pode continuar enviando dados, mesmo depois do recebimento de um FIN. O mesmo procedimento, solicitando o t ermino da conex ao, deve ocorrer no sentido oposto. Al em da forma normal de t ermino de uma conex ao TCP, como descrita anteriormente, caracterizada existe um outra maneira de naliza c ao, conhecida como t ermino abrupto. E pelo envio de uma mensagem TCP, com o ag RST ativo, ao inv es do FIN. O host que enviou a mensagem contendo o RST naliza o seu lado da conex ao, e o host que recebeu faz com que a conex ao do seu lado seja interrompida. Mensagens de reconhecimento (ACK) n ao s ao enviadas quando do recebimento uma mensagem de t ermino abrupto de conex ao. 2.7 APLICAC OES

As aplica c oes, muitas vezes chamadas de servi cos, constituem um novo conjunto de protocolos, correspondendo ao mais alto n vel na pilha de protocolos TCP/IP. Estas aplica c oes/servi cos est ao associadas a uma s erie de par ametros (n umero do protocolo, n umero da porta, identicadores, dentre outros), que s ao nomeados por um coordenador central, conhecido como Internet Assigned Numbers Authority (IANA, 2002), sendo este respons avel por atribuir valores u nicos a estes par ametros e manter um registro atualizado dos valores catalogados. Os n umeros das portas (um dos par ametros identicadores das aplica c oes) s ao, normalmente, divididos em tr es categorias (Stevens, 1998): portas privilegiadas (0-1023): s ao atribu das pela IANA e na maioria dos sis41

temas s o podem ser utilizadas por processos do sistema, ou por aplica c oes executadas por usu arios privilegiados; portas registradas (1024-49151): s ao listadas e catalogadas pela IANA e podem ser usadas, na maioria dos sistemas, por processos de usu arios n ao privilegiados, ou por aplica c oes executadas por usu arios n ao privilegiados; portas din amicas e/ou privadas (49152-65535): tamb em chamadas de portas ef emeras, n ao sofrem qualquer controle da IANA. A Tabela (2.1), gerada ` a partir de dados coletados em IANA (2002), apresenta algumas das aplica c oes/servi cos comumente utilizados na Internet, bem como os n umeros das portas e protocolos associados. TABELA 2.1: Alguns servi cos/aplica c oes de Rede Aplica c ao/Servi co FTP (le transfer) [data] FTP (le transfer) [control] SSH (secure shell) TELNET (remote login) SMTP (eletronic mail) DNS (domain name system) FINGER (user information) HTTP (the World Wide Web) POP3 (post oce protocol - version 3) Sun RPC (remote procedure Call) NTP (network time protocol) IMAP (Internet message access protocol) SNMP (simple network management protocol) NFS (network le system) Porta 20/tcp 21/tcp 22/tcp 23/tcp 25/tcp 53/udp 79/tcp 80/tcp 110/tcp 111/tcp 123/udp 143/tcp 161/udp 2049/udp

Breves descri c oes de algumas destas aplica c oes s ao apresentadas como se segue. FTP (File Transfer Protocol): esta aplica c ao tem como objetivos promover o compartilhamento de arquivos, proteger o usu ario de varia c oes nos sistemas de armazenamento de arquivos entre hosts e transferir dados de forma con avel. Diferente da maioria das aplica c oes, o FTP usa duas conex oes de rede separadas, onde a maioria de suas implementa c oes cont em dois modos de opera c ao: o ativo e o passivo. Ao iniciar um conex ao 42

FTP com um servidor remoto operando em modo ativo, o cliente abre, a partir de uma porta acima de 1023/tcp, um canal de controle na porta 21/tcp do servidor. Para transferir arquivos ou outras informa c oes, o servidor remoto abre um canal de dados a partir da porta 20/tcp para uma porta acima de 1023/tcp no cliente. A conex ao do canal de dados opera ao contr ario da maioria dos protocolos, que abrem conex oes do cliente para o servidor. J a no modo passivo, tanto a conex ao de controle, quanto a conex ao para a transfer encia de dados s ao iniciadas do cliente para o servidor (Postel e Reynolds, 2002a). SSH (Secure Shell ): O SSH e um protocolo da camada de aplica c ao, que prov e um conjunto de mecanismos de comunica c ao, em forma de canais, multiplexados em um u nico t unel criptografado. Estes mecanismos s ao: sess oes interativas de login; execu c ao remota de comandos; tunelamento de conex oes TCP/IP, e transfer encia de dados (Ylonen et al., 2002). SMTP (Simple Mail Transfer Protocol ): o objetivo desta aplica c ao e realizar o servi co de correio eletr onico (transferir mail) de forma eciente, atrav es da especica c ao da forma como as mensagens ser ao transferidas de um host para a outro. Este e independente de um sistema particular de transmiss ao e requer apenas um canal con avel para enviar/receber dados ordenados. O SMTP tamb em permite que se efetue mail relay atrav es de ambientes que forne cam servi cos de transporte de dados (Postel, 2002c) (Crocker, 2002). TELNET: esta aplica c ao tem como nalidade prover uma facilidade de comunica c ao bidirecional, onde o principal objetivo e proporcionar um m etodo padronizado para o uso de uma interface de dispositivos de terminais e/ou processos orientados a terminal. O protocolo que dene esta aplica c ao utiliza conex oes do tipo TCP e e constru do sobre tr es id eias principais: o conceito de Terminal Virtual de Rede; o princ pio de negocia c ao de op c oes; e uma visualiza c ao sim etrica dos terminais e processos. O estabelecimento de uma conex ao depende de uma valida c ao, que combina nome e senha do usu ario (ou cliente) da aplica c ao (Postel e Reynolds, 2002b). DNS (Domain Name System ): o DNS e um sistema de gerenciamento hier arquico e distribu do de nomes. Este cont em a especica c ao da sintaxe dos nomes usados na Internet, regras para delega c ao de autoridade na deni c ao de nomes, banco de dados distribu do para associar nomes a atributos (por exemplo, endere co IP), al em de um algoritmo distribu do que mapeia nomes em endere cos (Mockapetris, 2002a) (Mockapetris, 2002b). FINGER (Finger User Information Protocol ): esta aplica c ao prov e a troca de informa c oes de usu ario, efetuada atrav es de uma interface para um programa de infor43

ma c oes de usu arios remotos (RUIP - Remote User Information Program) (Zimmerman, 2002). HTTP (Hypertext Transfer Protocol ): o HTTP e um protocolo da camada de aplica c ao, utilizado em sistemas de informa c oes hiperm dia distribu dos e colaborativos. Tamb em conhecido como WWW (World-Wide Web), e utilizado como um protocolo gen erico, proporcionando a realiza c ao de v arias tarefas al em da convencional (transfer encia de hipertexto), tais como servidores de nomes e sistemas de gerenciamento de objetos distribu dos, atrav es da extens ao de seus m etodos de requisi c ao, c odigos de erro e cabe calhos. Uma das caracter sticas do HTTP e a representa c ao do tipo e negocia c ao de dados, de forma a permitir que sistemas sejam constru dos independentemente dos dados a serem transferidos (Fielding et al., 2002). POP (Post Oce Protocol ): esta aplica c ao tem com fun c ao permitir que um cliente acesse e obtenha mensagens de correio eletr onico, armazenadas em um dado servidor. Esta n ao prov e mecanismos extensivos de manipula c ao de mensagens, de modo que, normalmente, mensagens s ao obtidas pelo cliente e ent ao apagadas do servidor (Myers e Rose, 2002). Sun RPC (Remote Procedure Call ): o servi co RPC foi criado para facilitar o desenvolvimento de aplica c oes distribu das, baseadas no paradigma cliente/servidor. Este e um protocolo de mensagens, especicado por uma linguagem, conhecida como XDR (eXternal Data Representation), e e baseado no modelo de chamada de procedimentos remotos, que e similar ao modelo de chamada de procedimentos locais. O processo cliente envia uma mensagem de chamada para o processo servidor, contendo par ametros de procedimentos, e espera pela mensagem de resposta. O processo servidor, que estava em estado de espera, extrai os par ametros da mensagem de chamada, computa os resultados e envia uma mensagem de resposta, contendo os resultados da execu c ao do procedimento. Uma vez que a mensagem de resposta e recebida, os resultados s ao extra dos e o processo cliente e terminado (Sun, 2002b). NTP (Network Time Protocol ): o NTP e um protocolo da camada de aplica c ao que prov e um mecanismo para a sincroniza c ao e distribui c ao coordenada de tempo numa rede grande e heterog enea, com taxas de transmiss ao variando do corriqueiro at e alt ssimas. Ele usa uma arquitetura na qual servidores de tempo distribu dos numa subrede, operando com uma congura c ao tipo cliente-servidor hier arquico auto-organiz avel, sincronizam rel ogios l ogicos dentro da subrede e com padr oes de tempo nacionais. Os servidores podem distribuir refer encias de tempo por meio de algoritmos de roteamento local ou processos espec cos de difus ao pela rede (Mills, 2002a) (Mills, 2002b) (Mills, 2002c).

44

IMAP (Internet Message Access Protocol ): o objetivo deste protocolo da camada de aplica c ao e permitir que um cliente acesse e manipule mensagens de correio eletr onico em um dado servidor. Diferente do protocolo de aplica c ao POP3, prov e mecanismos que permitem v arias formas de manipula c ao de mensagens no servidor. Destacam-se os seguintes mecanismos: manipula c ao remota de pastas (mailboxes) contendo mensagens; opera c oes de cria c ao, exclus ao e troca de nomes para as mailboxes; remo c ao permanente de mensagens, dentre outros (Crispin, 2002). SNMP (Simple Network Management Protocol ): o SNMP e um protocolo da camada de aplica c ao, utilizado no gerenciamento de redes TCP/IP. Seus processos, que atuam como gerentes ou agentes, coletam de objetos gerenciados informa c oes u teis para o gerenciamento da rede. Estes objetos representam recursos, tais como sistema (esta c ao de trabalho), gateway, ou equipamentos de transmiss ao (modem, bridge, concentrador). Cada objeto gerenciado e mapeado como uma cole c ao de vari aveis, cujos valores podem ser lidos e alterados. O gerente processa as informa c oes recolhidas pelos agentes, com o objetivo de detectar a presen ca de falhas no funcionamento dos componentes da rede (hosts, gateways, processos executando protocolos de comunica c ao, dentre outros), de forma que provid encias possam ser tomadas para contornar os problemas gerados pelas falhas (Case et al., 2002). NFS (Network File System ): o servi co de NFS foi projetado para prover acesso transparente a arquivos/diret orios compartilhados atrav es da rede, e para ser port avel entre diferentes hosts, sistemas operacionais, arquiteturas de rede e protocolos de transporte. Esta portabilidade e alcan cada atrav es do uso de RPCs, constru das sobre a linguagem XDR. Do ponto de vista de programa c ao, este sistema n ao acrescenta nenhum procedimento espec co para o acesso a arquivos remotos. Quando o NFS e instalado em um host, o acesso a arquivos remotos e efetuado com as mesmas chamadas de procedimentos utilizadas para acessar arquivos locais (Sun, 2002a).

45

46

CAP ITULO 3 CAPTURA DE PACOTES EM REDES apresentada a arquiEste cap tulo mostra uma breve revis ao sobre captura de pacotes. E tetura utilizada para a captura, a biblioteca que implementa esta arquitetura, bem como uma aplica c ao que utiliza esta biblioteca para visualizar pacotes coletados. 3.1 ARQUITETURA PARA A CAPTURA DE PACOTES

Na administra c ao de sistemas de informa c ao, uma t ecnica que vem sendo amplamente utilizada e a captura de pacotes. Esta veio possibilitar a monitora c ao de redes, atrav es de aplica c oes que realizam esta tarefa. Como esses monitores de rede s ao executados na forma de processos de usu ario, pacotes precisam ser copiados do n ucleo do sistema operacional (kernel) para o espa co do usu ario, antes de serem avaliados. Uma forma de minimizar as opera c oes de c opia de pacotes consistiu no desenvolvimento de um agente de kernel, conhecido como packet lter (ou ltro de pacotes), cuja func ao e descartar pacotes desnecess arios o mais r apido poss vel. Os packet lters iniciais foram desenvolvidos sobre uma arquitetura baseada em pilhas, e apresentaram um baixo desempenho quando executados nos processadores RISC daquela epoca. McCanne e Jacobson (1993) apresentaram uma nova arquitetura para a captura de pacotes, conhecida como BPF - BSD Packet Filtering. Esta nova abordagem, baseada no uso de registradores, mostrou-se 20 vezes mais r apida, quando comparada a abordagem inicialmente proposta. A arquitetura BPF, apresentada na Figura (3.1), e constitu da por dois componentes principais: a sonda de rede e o ltro de pacotes. A sonda de rede coleta c opias de pacotes nos device-drivers de rede e os entrega para as aplica c oes de monitoramento de rede. J ao ltro de pacotes decide se um pacote deve ou n ao ser coletado, e quantos bytes do mesmo devem ser copiados para a aplica c ao. Quando o BPF est a sendo executado em um sistema e um pacote chega na interface de rede, antes do device-driver da interface decidir o que vai ser feito com este pacote, o BPF realiza as seguintes a c oes: envia uma c opia do pacote para cada processo de ltragem; estes ltros decidem se o pacote deve ou n ao ser aceito; cada ltro que aceita o pacote, copia a quantidade de dados requisitada para 47

o buer associado ao ltro. O controle e ent ao devolvido ao device-driver da interface de rede, que envia o pacote para a pilha de protocolos do sistema, caso esteja endere cado para o pr oprio host.

network monitor

network monitor user kernel protocol stack

buffer filter

buffer filter

BPF

linklevel driver

linklevel driver kernel network

FIGURA 3.1 Esquema da arquitetura BPF (BSD Packet Filtering). FONTE: adaptada de McCanne e Jacobson (1993, p. 260). Uma caracter stica fundamental para o bom desempenho desta arquitetura e a capacidade de coletar e armazenar v arios pacotes entre uma chamada de leitura do sistema e outra. Seria invi avel realizar uma chamada de leitura do sistema para cada pacote coletado, pois o intervalo entre pacotes pode ser de alguns microsegundos. Portanto, o BPF realiza a coleta e o armazenamento de v arios pacotes, de modo que estes s ao repassados quando da ocorr encia de uma chamada de leitura do sistema realizada pelo processo de monitoramento de rede. Al em disso, o BPF encapsula os dados capturados para cada pacote com um cabe calho pr oprio, que cont em o hor ario de captura, tamanho e deslocamento para o alinhamento dos dados. A se c ao 3.2 descreve a biblioteca libpcap, implementa c ao atual da arquitetura BPF, proposta por McCanne e Jacobson (1993).

48

3.2

BIBLIOTECA LIBPCAP

McCanne e Jacobson puderam apresentar as vantagens da arquitetura BPF, atrav es da implementa c ao de uma biblioteca de captura de pacotes, conhecida como libpcap1 . Atualmente, o grupo tcpdump.org2 e respons avel por dar continuidade ao desenvolvimento dessa biblioteca. Esta e composta por um conjunto de rotinas, cujas principais fun c oes s ao descritas como se segue: especicar dispositivo de rede onde a coleta deve ser efetuada; criar uma sess ao de captura e associ a-la a um descritor da biblioteca; compilar uma express ao de ltragem para o formato que pode ser entendido pela biblioteca; aplicar a express ao de ltragem, j a compilada, ` a sess ao de captura previamente criada; iniciar o processo de obten c ao de pacotes da rede; A rotina de especica c ao do dispositivo de rede pode ser suprimida. Neste caso, a biblioteca se encarrega de identicar quais dispositivos est ao ativos e, portanto a coleta de pacotes e realizada em todas as interfaces v alidas. A sess ao de captura e associada a um descritor, pois este ser a utilizado como identicador para posterior aplica c ao de ltros e in cio do processo de coleta. A libpcap tem uma sintaxe pr opria para as express oes de ltragem, grande respons avel pelo melhor desempenho da biblioteca. Por isso, e necess ario compilar os ltros antes de aplic a-los ` a sess ao de coleta de pacotes. O processo de captura pode ser feito para um n umero determinado de pacotes ou indenidamente. Para o segundo caso, a coleta e terminada quando da ocorr encia de uma interrup c ao de sistema gerada para este m. Al em das fun c oes anteriormente descritas, a biblioteca permite que os pacotes coletados sejam armazenados em arquivo e disponibiliza rotinas para recuperar os pacotes previamente armazenados. Para este caso, n ao h a a necessidade de especica c ao de um dispositivo de rede e a sess ao de captura e associada a um arquivo de dados. Filtros podem ser aplicados a este tipo de sess ao e o processo de obten c ao de pacotes ocorre de forma semelhante.
1 2

Dispon vel em ftp://ftp.ee.lbl.gov/libpcap.tar.Z. P agina Web em http://www.tcpdump.org.

49

As rotinas de obten c ao de pacotes, seja da rede ou de um arquivo de dados, t em como argumento uma fun c ao de retorno, conhecida como callback function, denida pela aplica c ao que est a utilizando a biblioteca. Esta fun c ao recebe a sequ encia de bytes capturados para cada pacote e e respons avel por manipular estes dados. Portanto, a libpcap n ao implementa qualquer tipo de tratamento para a sequ encia de bytes capturados, sendo que esta tarefa e de total responsabilidade da aplica c ao. Descri c oes mais detalhadas das fun c oes de maior relev ancia para este trabalho, bem como seus argumentos s ao apresentadas na se c ao 5.3.6. A se c ao 3.3 descreve a primeira aplica c ao baseada na biblioteca libpcap, desenvolvida para o monitoramento de redes. 3.3 TCPDUMP

A ferramenta de monitoramento de rede tcpdump3 foi originalmente implementada por McCanne e Jacobson (1993), e da mesma forma que a biblioteca libpcap, a continuidade de seu desenvolvimento e de responsabilidade do grupo tcpdump.org4 . Esta tem como nalidade processar pacotes sendo coletados em uma rede ou lidos de um arquivo previamente armazenado. Disp oe de par ametros que permitem gerar diferentes formas de apresenta c ao dos pacotes sendo impressos e que especicam como as rotinas da libpcap devem ser executadas. A Figura (3.2) apresenta as etapas de processamento de um pacote, realizadas pela func ao de retorno (callback function) denida na implementa c ao do tcpdump. Esta fun c ao e passada para a biblioteca libpcap e e respons avel pelo tratamento de cada pacote coletado. Por quest oes de simplica c ao e entendimento, o exemplo mostrado na Figura (3.2) apresenta o processamento de um pacote TCP/IP, onde o protocolo da camada de enlace de dados e o Ethernet. A descri c ao de cada uma das etapas e apresentada como se segue. Na etapa A a libpcap passa para a fun c ao de retorno o cabe calho PCAP, denido por uma estrutura contendo o hor ario da captura do pacote (timestamp), a quantidade de bytes capturados (caplen) e o deslocamento para o alinhamento dos dados (oset), como descrito na se c ao 3.1. Al em disso, recebe um apontador, do tipo unsigned char (ucp), que aponta para o in cio da sequ encia de bytes capturados para o pacote. Na etapa B inicializam-se dois apontadores: um para o in cio da sequ encia de bytes (pktp) e outro para o m (snapend). O segundo e calculado pela soma do apontador de in cio
3 4

Dispon vel em ftp://ftp.ee.lbl.gov/tcpdump.tar.Z. Idem 2.

50

com a quantidade de bytes coletados (caplen). Inicializa-se, ent ao, o apontador ep, que referencia a estrutura contendo o formato do cabe calho Ethernet (struct ether header). Isto e poss vel atrav es da utiliza c ao de uma caracter stica da linguagem C (Kernighan e Ritchie, 1990), utilizada no desenvolvimento do tcpdump e da libpcap, que permite fazer convers ao (casting) de tipos. Por cast (ou casting) entende-se converter um determinado tipo para outro, respeitando os limites (ou tamanhos) denidos para cada tipo envolvido. Os dados referentes ao cabe calho Ethernet s ao ent ao processados.

ucp Cabealho PCAP ucp ep = ( struct ether_header * ) ucp pktp = ucp B) pktp Cabealho Ethernet ucp ip = ( struct ip * ) ucp Cabealho IP tcp udp = icmp Dados encapsulados no datagrama ( struct tcphdr * ) ( struct udphdr * ) ( struct icmp * ) Dados encapsulados no frame snapend

A)

Cadeia de bytes do pacote capturado snapend = ucp + caplen

C)

pktp

ucp

ucp

snapend

D) pktp

Cabealho TCP/UDP/ICMP ucp

Dados encapsulados na mensagem snapend

E)

Dados

FIGURA 3.2 Etapas de processamento de um pacote TCP/IP realizadas pelo tcpdump. Na etapa C o apontador ucp e incrementado do tamanho da estrutura ether header. Ent ao e inicializado o apontador ip, que referencia a estrutura contendo o formato do cabe calho IP (struct ip). Os dados referentes ao cabe calho IP s ao processados. Neste ponto e feita a verica c ao do protocolo da camada de transporte utilizado no pacote. Na etapa D o apontador ucp e novamente incrementado, mas agora do tamanho da estrutura ip. Ent ao e inicializado o apontador tcp ou udp ou icmp, de acordo com o protocolo identicado na etapa anterior. Este apontador referencia a estrutura contendo o formato do cabe calho TCP (struct tcphdr), ou cabe calho UDP (struct udphdr), ou o cabe calho ICMP (struct icmp). Os dados referentes ao cabe calho em quest ao s ao ent ao processados.

51

Na etapa E o apontador ucp e incrementado do tamanho da estrutura referente ao cabe calho da camada de transporte. Ent ao, rotinas de processamento de protocolos da camada de aplica c ao s ao executadas. Para os casos onde o cabe calho tem tamanho vari avel, como no IP e TCP, quando da ocorr encia de op c oes, o apontador ucp e reajustado, de modo que o processamento a ser executado na pr oxima etapa aconte ca de forma correta. No decorrer do processamento do pacote, informa c oes de cada cabe calho s ao impressas, de acordo com argumentos passados para o tcpdump no momento em que este e executado. A descri c ao detalhada de cada um destes argumentos pode ser encontrada nos manuais (man pages) disponibilizados juntamente com a aplica c ao. Uma vez aplicados os ltros e processado o pacote, o resultado e armazenado num arquivo ou impresso na tela de um terminal. Um exemplo da s ntese de um comando tcpdump e a sa da5 correspondente s ao mostrados a seguir:
argumentos filtro /------------\ /-------------\ # tcpdump -nSr dump_file tcp and port 22 14:38:04.080644 eth0 > xxx.xxx.xxx.xxx.2754 > yyy.yyy.yyy.yyy.22: S 1145744603:1145744603(0) win 32120 \ <mss 1460,sackOK,timestamp 155682026 0,nop,wscale 0> (DF) 14:38:04.081408 eth0 < yyy.yyy.yyy.yyy.22 > xxx.xxx.xxx.xxx.2754: S 4038512504:4038512504(0) \ ack 1145744604 win 10136 <nop,nop,timestamp 371616198 155682026, nop,...,mss 1460> (DF) 14:38:04.081529 eth0 > xxx.xxx.xxx.xxx.2754 > yyy.yyy.yyy.yyy.22: . 1145744604:1145744604(0) \ ack 4038512505 win 32120 <nop,nop,timestamp 155682026 371616198> (DF) 14:38:04.099287 eth0 < yyy.yyy.yyy.yyy.22 > xxx.xxx.xxx.xxx.2754: P 4038512505:4038512554(49) \ ack 1145744604 win 10136 <nop,nop,timestamp 371616200 155682026> (DF) 14:38:04.099396 eth0 > xxx.xxx.xxx.xxx.2754 > yyy.yyy.yyy.yyy.22: . 1145744604:1145744604(0) \ ack 4038512554 win 32120 <nop,nop,timestamp 155682027 371616200> (DF) 14:38:04.108752 eth0 > xxx.xxx.xxx.xxx.2754 > yyy.yyy.yyy.yyy.22: P 1145744604:1145744653(49) \ ack 4038512554 win 32120 <nop,nop,timestamp 155682028 371616200> (DF) ...

5 As linhas da sa da tcpdump foram editadas e quebradas, por quest oes de legibilidade, e os endere cos IP foram substitu dos.

52

CAP ITULO 4 DE INTRUSAO DETECC AO Este cap tulo apresenta alguns conceitos e princ pios relacionados a seguran ca de sistemas de informa c ao, bem como a detec c ao de intrus ao. S ao tamb em abordadas as principais categorias e m etodos de detec c ao relacionados aos sistemas de detec c ao de intrus oes. Ao nal, s ao apresentados alguns dos principais sistemas de detec c ao de intrus oes projetados e implementados, em ordem cronol ogica. A arquitetura, funcionamento, principais vantagens e desvantagens destes sistemas tamb em s ao discutidos neste cap tulo. 4.1 CONCEITOS DE SEGURANCA DE SISTEMAS

Entende-se por sistemas de informa c ao os computadores, as redes que os interligam, bem como as informa c oes que estes manipulam. Um sistema de informa c ao seguro est a relacionado ` a condencialidade, integridade e disponibilidade dos recursos que o comp oe. A condencialidade diz que a informa c ao s o est a dispon vel para aqueles devidamente autorizados; a integridade diz que a informa c ao n ao e destru da ou corrompida e o sistema tem um desempenho correto, e a disponibilidade diz que os servi cos/recursos do sistema est ao dispon veis sempre que forem necess arios. Outra deni c ao de seguran ca de sistemas de informa c ao e apresentada por Garnkel e Spaord (1996), onde um sistema de informa c ao e seguro se este se comporta da forma esperada. Al em da condencialidade, integridade e disponibilidade, h a outros requisitos que podem determinar o n vel de seguran ca de um sistema de informa c ao. A consist encia diz respeito ` a certeza de que o sistema se comporta como o esperado pelos usu arios autorizados; o controle diz que o acesso ao sistema e restrito, e a auditoria diz respeito ` a preocupa c ao quanto as atividades realizadas pelos usu arios autorizados do sistema. Apesar de cada um dos requisitos/aspectos de seguran ca apresentados terem grande import ancia, diferentes organiza c oes ter ao diferentes necessidades e, portanto, alguns aspectos/requisitos ter ao maior import ancia do que outros. Em um sistema banc ario a integridade e a auditoria s ao, normalmente, os que recebem maior aten c ao. J a em um instituto ou universidade a integridade e disponibilidade devem ser os requisitos de maior import ancia. Um fator determinante e crucial para a seguran ca de um sistema de informa c ao e o estabelecimento de pol ticas, que apontem as propriedades de seguran ca que o sistema deve ter. Estas pol ticas de seguran ca s ao estabelecidas pelas necessidades e particularidades da organiza c ao. S ao denidas atrav es de uma an alise de riscos e amea cas aos sistemas de

53

informa c ao, estabelecendo contra o que a organiza c ao deve se defender e de que forma. Anderson (1980) apresentou alguns conceitos relacionados aos riscos e amea cas que afetam a seguran ca dos sistemas de informa c ao. Estes s ao descritos como se segue e ser ao utilizados nas se c oes seguintes. Amea ca: possibilidade de ocorr encia de uma tentativa deliberada e n ao autorizada para: acessar informa c oes; manipular informa c ao, ou tornar um sistema n ao con avel ou indispon vel; Risco: exposi c ao acidental e imprevista de informa c oes, ou viola c ao da integridade das opera c oes, relacionadas ao mal funcionamento do hardware ou projeto incorreto/incompleto de software. Vulnerabilidade: Uma suspeita de falha ou uma falha conhecida no projeto do hardware ou software, ou opera c ao de um sistema que exp oe informa c oes; Ataque: formula c ao espec ca ou execu c ao de um plano que explora uma amea ca. Intrus ao: ataque bem sucedido, habilidade de obter acesso n ao autorizado (e muitas vezes n ao detect avel) a arquivos e programas, ou controle de um sistema de informa c ao. Outra deni c ao importante diz respeito ao indiv duo que realiza um ataque/intrus ao. S ao conhecidos como executores/atacantes/intrusos e, normalmente, s ao usu arios leg timos ou n ao, que exploram ou tentam explorar vulnerabilidades do sistema para: comprometer recursos, fraudar, roubar ou sabotar informa c oes, ou mesmo obter acesso a informa c oes de forma n ao autorizada. Todas estas a c oes, que s ao consideradas viola c oes, resultam na transgress ao da pol tica de seguran ca do sistema de informa c oes. Os atacantes internos representam a amea ca mais s eria, pois suas a c oes podem resultar em danos onerosos e desastrosos para a organiza c ao. Os atacantes externos s ao normalmente motivados pelos grandes desaos t ecnicos. Frequentemente passam a atuar por ganhos nanceiros. Sabe-se que a seguran ca de um sistema de informa c ao e obtida, de acordo com a conveni encia e facilidades de uso de recursos que o comp oem. Este fato e cr tico e complicador na defesa de um sistema, pois sabe-se que quanto mais facilidades e recursos um sistema disponibilizar, mais suscet vel estar a a falhas e a ocorr encia de vulnerabilidade. Da vem a necessidade de utiliza c ao de mecanismos que permitam detectar a explora c ao de falhas de seguran ca, ou seja, detectar intrus oes. Estes mecanismos s ao conhecidos como SDIs 54

Sistemas de Detec c ao de Intrus oes, e desempenham a fun c ao mais uma linha de defesa dentro de um sistema de informa c ao. 4.2 DE INTRUSAO DETECC AO

Anderson (1980), ao introduzir o conceito de detec c ao de intrus ao, deniu uma tentativa de intrus ao ou amea ca como sendo a possibilidade de ocorr encia de uma tentativa deliberada e n ao autorizada para: acessar informa c oes; manipular informa c ao; tornar um sistema n ao con avel ou indispon vel. De modo geral, intrus oes podem ser divididas em 6 tipos principais (Smaha, 1988): Tentativa de invas ao (Attempted Break-in): detectado atrav es de pers de comportamento at pico ou viola c oes de restri c oes de seguran ca; Ataque (Masquerade Attack): tamb em detectado atrav es de pers de comportamento at pico ou viola c oes de restri c oes de seguran ca; Penetra c ao (Penetration of the Security Control System): detectado atrav es do monitoramento de padr oes espec cos de atividade; Vazamento (Leakage): detectado pelo uso at pico dos recursos do sistema; Nega c ao de servi cos (Denial of Service): tamb em detectado pelo uso at pico dos recursos do sistema; Uso mal intencionado (Malicious Use): detectado atrav es de pers de comportamento at picos, viola c oes de restri c oes de seguran ca, ou uso de privil egios especiais. Dentre as v arias deni c oes para detec c ao de intrus ao, Amoroso (1999) diz que: Detec c ao de Intrus ao e o processo de identicar e responder a atividades mal intencionadas, direcionadas para recursos computacionais e de rede. relevante para este trabalho analisar alguns dos termos utilizadas na deni E c ao apresentada acima (Amoroso, 1999): Processo: detec c ao de intrus ao deve ser vista primeiramente como processo envolvendo tecnologia, pessoas e ferramentas; 55

 Identicar: identica c ao de intrus ao pode ocorrer antes, durante ou depois da execu c ao da atividade mal intencionada. Isto e fundamental para determinar o tipo de detec c ao e a c oes a serem tomadas; Responder: est a diretamente relacionada e depende da identica c ao da intrus ao. A resposta pode ser a naliza c ao de um servi co, a identica c ao do intruso, entre outras. Atividades mal intencionadas: quaisquer atividades que atentem contra a seguran ca de um sistema de informa c ao. As t ecnicas de detec c ao de intrus ao s ao divididas em duas categorias principais: detec c ao de intrus ao por anomalia e detec c ao de intrus ao por abuso. A discuss ao apresentada a seguir baseou-se nos trabalhos de Kumar (1994), (Allen et al., 2000), (Bace e Mell, 2000) e Sundaram (2000). 4.2.1 Detec c ao de Intrus ao por Anomalia

A detec c ao de intrus ao por anomalia e baseada na id eia de que todo evento intrusivo e necessariamente an omalo, sendo um subconjunto da atividade an omala. Esta id eia parece bem razo avel, uma vez que um intruso, ao invadir um sistema, n ao conhece o padr ao de uso dos recursos, gerando assim, um comportamento an omalo. Normalmente, atividades intrusivas podem ser vistas como um conjunto de atividades individuais, sendo que estas muitas vezes n ao caracterizam atividades an omalas. Portanto, teoricamente, bastaria encontrar as atividades an omalas para encontrar todas as atividades intrusivas. Mas isto nem sempre acontece, gerando assim os seguintes casos: Intrusivo e n ao an omalo: conhecido como falso-negativo, caracteriza falha na detec c ao, pois a atividade e intrusiva apesar de n ao ser an omala; N ao intrusivo e an omalo: conhecido como falso-positivo, caracteriza falha na detec c ao, pois a atividade n ao e intrusiva, mas por ser an omala, e apontada como tal; N ao intrusivo e n ao an omalo: caracteriza uma atividade normal; Intrusivo e an omalo: caracteriza uma intrus ao, pois a atividade e intrusiva por ser tamb em an omala. Os sistemas de detec c ao de intrus ao por anomalia s ao, normalmente, baseados em pers do sistema. Portanto, seu maior problema consiste na mudan ca dos pers esperados, que tendem a gerar um grande n umero de falso-positivos. Outra quest ao est a relacionada ao 56

custo destes sistemas. Por utilizarem estes pers e tendo que mant e-los atualizados e sob vigil ancia constante, estes sistemas normalmente t em o custo bastante elevado. A Figura (4.1) mostra a representa c ao b asica de um sistema de detec c ao baseado neste m etodo.

Atualizar perfil Estatisticamente divergente? Estado de Ataque

Dados de Auditoria

Perfil do Sistema

Gerar novos perfis dinamicamente

FIGURA 4.1 Sistema de Detec c ao de Intrus ao por Anomalia (esquema b asico). FONTE: adaptada de Sundaram (2000, p. 3). Os sistemas que utilizam o m etodo de detec c ao por anomalia s ao desenvolvidos segundo algumas abordagens, descritas nas subse c oes seguintes. 4.2.1.1 Abordagem estat stica

Nesta abordagem, o detector de anomalias monitora as atividades dos usu arios e processos do sistema e gera pers de comportamento destes. Estes pers s ao atualizados regularmente, sendo que os dados antigos s ao ajustados de forma apropriada. Logo que os registros de auditoria s ao processados, e gerado periodicamente um valor indicativo de anormalidade, sendo que este valor e fun c ao de medidas de anormalidade individuais, associadas ao perl do usu ario. Existem v arios tipos de medidas de atividades, relacionadas a um perl, tais como tempo de uso da CPU, n umero de conex oes na rede em um certo per odo, acesso a arquivos, utiliza c ao de processos envolvendo I/O (entrada/sa da), frequ encia de logins a partir de uma determinada localidade, utiliza c ao do servidor de mail, compiladores, shells, editores do sistema, etc. O comportamento do usu ario e armazenado em um perl corrente. Em intervalos de tempo regulares o perl corrente e comparado com o perl armazenado, para determinar se h a ocorr encia de comportamento an omalo. Alguns destes sistemas concatenam, em intervalos determinados, o perl corrente do usu ario com o seu perl correspondente armazenado. Outros sistemas s ao est aticos, e n ao alteram o perl armazenado uma vez que este foi determinado. A grande vantagem desta abordagem e que esta aprende, de forma adaptativa, o comportamento dos usu arios do sistema. Mas, existem alguns problemas relacionados a esta abordagem. Os SDIs baseados no m etodo estat stico podem ser gradativamente treinados por intrusos, de forma que eventos intrusivos passem a ser considerados normais; a congura c ao do limiar (indica se uma anomalia deve ser considerada intrusiva) muito alto ou muito baixo pode gerar um n umero consider avel de falso positivos e falso negativos, e

57

o relacionamento entre eventos pode n ao ser considerado, pois as medidas estat sticas de anormalidade n ao levam em considera c ao a ordem de ocorr encia dos eventos. 4.2.1.2 Gera c ao de progn osticos de padr oes

Esta abordagem tenta prever eventos futuros, baseando-se em eventos que j a ocorreram. A id eia e que sequ encias de eventos n ao s ao aleat orias, mas seguem um padr ao previs vel. Uma abordagem desenvolvida por Teng et al. (1990) utiliza regras temporais geradas por indu c ao para caracterizar padr oes de comportamento normais dos usu arios. As regras s ao modicadas dinamicamente durante a fase de aprendizado, de forma que somente regras con aveis permanecem no sistema. Seja o seguinte exemplo: E1 E2 E3 (E4 = 70%, E5 = 25%, E6 = 5%). Isto signica que dadas as ocorr encias dos eventos E1 , E2 e E3 , nesta ordem, existe uma probabilidade de 70% para o evento E4 , ou 25% para o evento E5 , ou 5% para o evento E6 ocorrer em sequ encia. Um conjunto de regras geradas por indu c ao, atrav es da observa c ao do comportamento do usu ario, ent ao compreende o perl do usu ario. Uma anomalia e detectada se a sequ encia de eventos observada confere com o lado esquerdo de uma regra, mas os eventos seguintes diferem estatisticamente, e de forma consider avel, daqueles previstos pela regra. Uma desvantagem desta abordagem consiste na exist encia de padr oes de comportamento desconhecidos, que n ao podem ser identicados como an omalos, apesar de n ao coincidirem com as regras estabelecidas para o sistema. Algumas das vantagens s ao: maior facilidade em casos onde usu arios possuem comportamentos bem variados, mas que apresentam padr oes sequenciais bem signicativos, foco em uma quantidade menor de eventos de seguran ca realmente relevantes, comparado com a an alise de todo andamento de uma sess ao considerada suspeita, e maior precis ao na detec c ao de viola c oes, ou seja, atacantes tentando treinar o sistema na fase de aprendizado s ao mais facilmente detectados, devido as caracter ` sticas sem anticas das regras. 4.2.1.3 Utiliza c ao de redes neurais

Uma outra abordagem, que segue a mesma linha da abordagem de gera c ao de progn osticos de padr oes, utiliza redes neurais. A rede e treinada sobre um conjunto de informa c oes (comandos), de forma que esta possa prever a pr oxima a c ao ou comando de um usu ario. Estes comandos ou a c oes n ao s ao necessariamente os registros de auditoria, mas podem estar em um n vel de abstra c ao mais elevado. A rede neural toma como entrada o comando atual e os n comandos anteriores, onde n e o tamanho da janela que constitui os

58

comandos anteriores, tomados pela rede, para efetuar a previs ao do pr oximo comando. Ap os a fase de treinamento, a rede constr oi os pers dos usu arios sobre sequ encias de comandos relevantes. Qualquer previs ao de eventos incorreta e sinalizada como um desvio, em rela c ao ao perl do usu ario previamente estabelecido. Esta abordagem apresenta algumas vantagens, tais como: tolerante a ru dos no conjunto de informa c oes, o sucesso desta abordagem n ao depende de hip oteses estat sticas ` a respeito da natureza dos dados, e e de f acil modica c ao para novos grupos de usu arios. As desvantagens s ao: uma janela de comandos pequena pode gerar falso positivos, enquanto que janela de comandos grande ir a gerar dados irrelevantes e poder a ocasionar em falso negativos, intrusos podem treinar a rede durante a fase de aprendizado, padr oes n ao podem ser induzidos a partir de amostras, e a topologia da rede neural s o e determinada depois de v arios testes e erros. 4.2.2 Detec c ao de Intrus ao por Abuso

A detec c ao de intrus ao por abuso baseia-se na id eia que ataques podem ser representados na forma de padr oes ou assinaturas (sequ encia de eventos e condi c oes que levam a uma intrus ao). Um fato importante e que existe um componente de detec c ao por abuso na maioria dos sistemas de detec c ao de intrus ao, devido a fato de que t ecnicas estat sticas isoladas s ao limitadas na detec c ao de todos os eventos de seguran ca, como visto anteriormente. A Figura (4.2) mostra a representa c ao b asica de um sistema de detec c ao de intrus ao por abuso.

Modificar regras existentes Regra confere? Estado de Ataque

Dados de Auditoria

Perfil do Sistema

Adicionar novas regras

FIGURA 4.2 Sistema de Detec c ao de Intrus ao por Abuso (esquema b asico). FONTE: adaptada de Sundaram (2000, p. 4). A grande limita c ao deste m etodo consiste no fato de que este busca por vulnerabilidades conhecidas, sendo que novas vulnerabilidades n ao s ao reconhecidas como intrus oes. O principal aspecto relacionado aos sistemas de detec c ao de intrus ao que utilizam o m etodo por abuso, e como preparar uma assinatura, de modo que esta englobe todas as poss veis varia c oes de um ataque determinado. E, al em disso, prepar a-la de forma que esta n ao se encaixe em uma atividade n ao intrusiva. Os sistemas que utilizam m etodos de detec c ao de intrus ao por abuso s ao desenvolvidos segundo algumas abordagens, descritas nas subse c oes seguintes.

59

4.2.2.1

Utiliza c ao de sistemas especialistas

Sistemas especialistas s ao capazes de representar e inferir sobre algum dom nio do conhecimento, visando solucionar problemas. Estes s ao modelados, de forma que haja uma separa c ao entre o centro de infer encia e a formula c ao da solu c ao do problema (base de conhecimento representada por regras e fatos). Quando utilizados na detec c ao de intrus oes, estes sistemas codicam o conhecimento sobre ataques, atrav es da declara c ao e associac ao de fatos extra dos de eventos nos processos auditores. Estas codica c oes geram regras contendo condi c oes e a c oes a serem realizadas. Quando um conjunto de condi c oes descritas em uma regra e satisfeito, um conjunto de a c oes e executado. Algumas vantagens deste m etodo s ao: dedu ca o simb olica da ocorr encia de uma intrus ao baseada nos dados recebidos e par ametros podem ser combinados para gerar um quadro coeso acerca de uma intrus ao. Algumas desvantagens s ao: pode apenas detectar vulnerabilidades conhecidas, e o conhecimento relacionado ao sistema especialista depende do prossional que efetua a modelagem deste conhecimento em um conjunto de regras. 4.2.2.2 Detec c ao por reconhecimento de padr oes

Esta abordagem de detec c ao de intrus ao por abuso codica assinaturas de intrus oes conhecidas como padr oes, que s ao ent ao reconhecidos nos dados de auditoria (Kumar, 1995). Este modelo tenta reconhecer os eventos como padr oes representando situa c oes de intrus ao. A implementa c ao utiliza diagramas de transi c ao de estados, para representar os padr oes, sendo que uma transi c ao corresponde ` a ocorr encia de um determinado evento. A Figura (4.3) apresenta um exemplo de codica c ao, utilizando diagrama de transi c ao de estados.
touch

1. cp /bin/sh /usr/spool/mail/root 2. chmod 4755 /usr/spool/mail/root 3. touch msg 4. mail root < msg 5. /usr/spool/mail/root * T1

S4
T3 T2

S5

(*) estado inicial

T4

S1
cp

S2
chmod

S3
mail

S6

FIGURA 4.3 Representa c ao de Eventos com Diagrama de Transi c ao de Estados. FONTE: adaptada de Kumar (1994, p. 19). Cada transi c ao e rotulada, ou seja, recebe um nome que caracteriza o evento associado (label). Uma transi c ao entre estados e disparada ap os o evento correspondente a esta ocorrer. Al em disso, express oes opcionais podem ser associadas a cada transi c ao. Estas express oes, conhecidas como guards, s ao booleanas (assumem valores do tipo true ou false), e s ao avaliadas no contexto do evento a que est ao associadas. Por exemplo, na Figura (4.3), um guard na transi c ao T4 s o permite que esta seja disparada, se os estados 60

S3 e S5 foram alcan cados e um evento mail ocorrer. Quando ocorre um evento reconhecido como um label (transi c ao) no diagrama, este dispara a transi c ao e a verica c ao do padr ao passa para um novo estado. Quando um determinado estado e alcan cado, e sinalizado um evento de seguran ca. Algumas vantagens desta abordagem s ao: utiliza especica c ao declarativa, ou seja, precisa apenas especicar que padr oes devem ser reconhecidos, e n ao como reconhec e-los, cadeias de eventos podem ser processadas de forma independente, sendo que seus resultados podem ser analisados em conjunto para evidenciar uma atividade intrusiva, e tem como caracter stica a portabilidade, ou seja, desde que assinaturas de intrus oes s ao escritas em uma linguagem independente de sistema, estas n ao precisam ser reescritas para processos de auditoria diferentes. Algumas desvantagens s ao: pode apenas detectar ataques baseados em vulnerabilidades conhecidas, e n ao eu til na representa c ao de padr oes pobremente denidos, visto que a tradu c ao de situa c oes de ataques conhecidas em padr oes que possam ser utilizados pelo modelo, n ao e uma tarefa simples. 4.2.3 Sistemas H bridos

Basicamente, existem as duas t ecnicas de detec c ao de intrus oes apresentadas anteriormente: detec c ao por anomalia e detec c ao por abuso. V arios sistemas s ao baseados na detec c ao por abuso ou na detec c ao por anomalia, mas ainda existem sistemas que combinam ambas, com o intuito de resolver ou atenuar os deci encias apresentadas por cada uma das t ecnicas. Um fator importante e que a modelagem destes sistemas, normalmente, e muito complexa, contendo v arias considera c oes, restri c oes, ou mesmo limita c oes relacionadas a sua implanta c ao. Geralmente, estes sistemas s ao implementados de forma parcial, e apresentam bons resultados. 4.2.4 Classica c ao dos Sistemas de Detec c ao por Tipo de An alise

Al em da duas t ecnicas principais de detec c ao de intrus ao apresentadas anteriormente, os sistemas de detec c ao de intrus ao podem ser divididos em duas categorias principais: host-based - sistemas baseados em hosts, e network-based - sistemas baseados em rede (Mukherjee e Levitt, 1994). Os sistemas de detec ca o de intrus ao host-based utilizam os registros de auditoria como principal conjunto de informa c oes na detec c ao de intrus oes. Aqui, as informa c oes relevantes s ao tempo de uso da CPU, n umero de acessos ao sistema via terminal remoto, tentativas de login, utiliza c ao de recursos do sistema, etc. Os sistemas de detec c ao de intrus ao network-based utilizam as informa c oes da rede como principal fonte de detec c ao de intrus oes. Utilizam informa c oes como tr afego, acesso, uxo de dados, cabe calho e conte udo de pacotes, al em de poderem utilizar os registros de

61

auditoria das m aquinas que comp oem a rede, para complementar informa c oes ou eliminar casos duvidosos. 4.2.5 O Estado da Arte em Sistemas de Detec c ao de Intrus oes

Denning (1987) desenvolveu um modelo gen erico de detec c ao de intrus ao, independente de qualquer sistema em particular, ambiente de aplica c oes, vulnerabilidade de sistema ou tipo de intrus ao. O modelo e baseado na hip otese de que viola c oes de seguran ca podem ser detectadas atrav es do monitoramento dos registros de auditoria, relacionados a padr oes anormais de uso do sistema. A id eia b asica do modelo e manter um conjunto de pers para os subjects (sujeitos), que s ao os iniciadores de atividades no sistema (normalmente usu arios). Quando um registro de auditoria e gerado, o modelo o associaria a um determinado perl e, ent ao, toma decis oes a respeito da atualiza c ao do perl, da checagem de comportamento anormal e do relato de anomalias detectadas. Para isto, logins, comandos, execu c ao de programas, acesso a arquivos e dispositivos s ao monitorados em busca de desvios no uso. O modelo n ao tem conhecimentos espec cos, relacionados ` as vulnerabilidades do sistema. O prot otipo de sistema de detec c ao de intrus oes IDES (Intrusion-Detection Expert System) baseou-se neste modelo. Desenvolvido pelo SRI Internationals Computer Science Laboratory (CSL), no nal da d ecada de 80, era capaz de prover detec c ao de viola c oes de seguran ca, em tempo real, para um u nico host. Este sistema foi um marco no desenvolvimento da tecnologia de detec c ao de intrus ao h brida (an alise de assinaturas e detec c ao por anomalias), em tempo real (SRI, 2002). O prot otipo consiste de dois componentes principais. O detector estat stico de anomalias (IDES/STAT) utiliza um processo de dedu c ao baseado em estat sticas para determinar se o comportamento, como relatado nos registros de auditoria, e normal em rela c ao a um comportamento aceit avel, baseado no perl hist orico de atividades do usu ario. Estes pers hist oricos s ao continuamente atualizados, utilizando os dados extra dos dos registros de auditoria, para aprender sobre o comportamento esperado dos usu arios de um sistema. Desta forma, prov e mecanismos para relatar e concluir sobre viola c oes de seguran ca, bem como detectar intrus oes que n ao podem ser detectadas pelos controles de acesso do sistema a ser monitorado. O sistema especialista (PBEST), outro componente do prot otipo, cont em regras que descrevem comportamentos suspeitos, baseadas no conhecimento de intrus oes passadas, vulnerabilidades conhecidas do sistema, ou pol ticas de seguran ca espec cas do dom nio. Os registros de auditoria do sistema monitorado s ao associados a estas regras, para determinar se o comportamento e suspeito. Entretanto, n ao e razo avel esperar que todas as situa c oes de intrus ao possam ser codicadas no formato de regras.

62

Os dois componentes (estat stico e baseado em regras) s ao independentes, e a combina c ao destes teria um poder de detec c ao bem superior ao caso isolado (Lunt et al., 1992). Em meados dos anos 90, a SRI International iniciou trabalhos para aperfei coar, otimizar e realizar reengenharia no prot otipo IDES, com o intuito de desenvolver um sistema de detec c ao de intrus ao de qualidade, chamado de Next-Generation Intrusion Detection Expert System (NIDES). O NIDES introduziu um componente de fus ao de resultados, chamado de Resolver, para integrar sua l ogica de respostas aos resultados produzidos pelo componente estat stico de detec c ao de anomalias e a ferramenta de an alise de assinaturas, baseada em regras (SRI, 2002). Algumas das mudan cas realizadas para o projeto do NIDES inclu ram a facilidade de personalizar a an alise, de modo que o componente estat stico podia ser ajustado e par ametros espec cos podiam ser habilitados ou desabilitados; a base de regras podia ser personalizada, habilitando ou desabilitando regras, al em de permitir a introdu c ao de novas regras no sistema em execu c ao. Um m odulo de testes foi adicionado, onde congura c oes candidatas do NIDES eram executadas fora do software NIDES rodando em tempo real. Recursos de arquivamento foram adicionados, suportando a armazenagem e recupera c ao de registros de auditoria, bem como dados de resultados (Anderson et al., 1995). Os projetos IDES/NIDES marcaram o campo da detec c ao de intrus ao, e tentaram resolver problemas relacionados com uma abordagem gen erica e ex vel, sem restri c oes impostas pelos sistemas, tipos de registros de auditoria a serem analisados, ou t ecnicas a serem utilizadas. Estes projetos estavam focados na necessidade de monitoramento e cria c ao de pers espec cos dos usu arios. Estes esfor cos, entretanto, apresentaram algumas limita c oes relacionadas a escalabilidade, aplicabilidade em ambientes baseados em rede, por estarem voltados para usu arios como alvos de an alise, bem como falhas no suporte ` a interoperabilidade. Outra linha de pesquisas em detec c ao de intrus ao vem sendo desenvolvida pela Purdue University, onde foi proposta uma arquitetura para detec c ao de intrus ao, usando agentes aut omonos. Diferente de outros SDIs, que s ao normalmente grandes, este e um sistema de detec c ao distribu do, baseado em v arias entidades independentes, trabalhando em conjunto. Estas entidades s ao conhecidas como agentes aut onomos, e s ao softwares que realizam fun c oes de monitoramento de seguran ca em um host. O sistema e conhecido como Autonomous Agents For Intrusion Detection (AAFID) e cont em tr es componentes principais: agents (ou agentes), transceivers e monitors. Este pode ser distribu do sobre qualquer n umero de hosts em uma rede. Cada host cont em um certo n umero de agents monitorando a ocorr encia de eventos de interesse. Todos os agents em um determinado host

63

enviam relat orios para um u nico transceiver. Os transceivers s ao entidades relacionadas a um conjunto de hosts, que supervisionam a opera c ao de todos os agents a estes relacionados. Eles exercem controle sobre os agentes, podendo inici a-los, par a-los ou congur a-los. Estas entidades enviam relat orios para um ou mais monitors. Os monitors t em acesso aos dados na rede e, portanto, est ao aptos a correlacionar e detectar intrus oes envolvendo v arios hosts. Monitors podem ser organizados hierarquicamente, de modo que um envie relat orios a outro de n vel mais alto (Balasubramaniyan et al., 1998). Esta abordagem apresenta vantagens relacionadas ` a eci encia, toler ancia a falhas, exibilidade quanto ` a degrada c ao e escalabilidade. Alguns dos problemas s ao: monitors s ao pontos cr ticos de falhas, e caso algum falhe, todos os transceivers controlados por ele param de transferir informa c oes; se monitors s ao duplicados para prover redund ancia, deve haver um esfor co para manter os dados de ambos consistentes, e atrasos na detec c ao de intrus oes podem ocorrer, devido ao cascateamento (dividido em n veis) do modelo. V arios sistemas de detec c ao de intrus ao foram implementados e testados. Alguns destes baseados em detec c ao por anomalia, outros baseados em detec c ao por abuso, e ainda outros que combinam as duas t ecnicas (sistemas h bridos). Estes ainda s ao classicados de acordo com o tipo de an alise que realizam, ou seja, host-based ou network-based. Em COAST (2002) h a uma lista de SDIs, contendo uma breve descri c ao, t ecnica utilizada, tipo de an alise, dentre outras informa co es. 4.2.6 Sistemas de Detec c ao de Intrus ao Baseados em Rede

Os modelos de sistemas de detec c ao de intrus oes anteriores foram projetados para operar em host. Entretanto, os sistemas de detec c ao de intrus ao atuais, al em de utilizarem as t ecnicas de detec c ao por anomalia e por abuso, utilizam-nas para efetuar a monitora c ao de um ambiente de rede, utilizando os dados da rede no processo de detec c ao. Alguns dos sistemas que incorporam estas caracter sticas s ao descritos pr oximas se c oes. 4.2.6.1 Network Security Monitor

Desenvolvido pela Universidade da Calif ornia, o Netwok Security Monitor (NSM) analisa o tr afego em uma rede local para detectar comportamentos intrusivos (Mukherjee e Levitt, 1994). Este modela a rede e os hosts sendo monitorados em uma estrutura hier arquica, conhecida como Interconnected Computing Environment Model (ICEM), composta por seis camadas. A camada mais baixa e conhecida como camada de pacote, e recebe como entrada um uxo de bits vindos de uma rede broadcast, por exemplo Ethernet. O uxo de bits e dividido em pacotes Ethernet completos e um timestamp e adicionado ao pacote. A pr o-

64

xima camada, chamada de thread layer, recebe o pacote da camada anterior e, ent ao, efetua a correla c ao entre pacotes para um uxo de dados unidirecional. Cada uxo consiste dos dados transferidos de um host para o outro, atrav es de um protocolo particular (TCP ou UDP), utilizando um conjunto u nico de portas. Este uxo de dados, chamado de thread, e mapeado para um vetor, conhecido como thread vector. A terceira camada (connection layer) recebe os vetores da camada anterior. Cada thread vector e combinado com outro para representar um uxo bidirecional de dados. Estes pares de vetores s ao representados por um vetor de conex ao (connection vector). Cada connection vector e analisado e reduzido. A quarta camada (host layer) recebe os vetores reduzidos gerados pela camada anterior. Estes vetores s ao utilizados na constru c ao de vetores de hosts (host vectors). Cada host vector representa as atividades de rede de um host. A pr oxima camada (connected-network layer) recebe os host vectors e os transforma em um grafo G. Se G(host1, host2, serv1) n ao e vazio, h a uma conex ao do host1 para o host2 pelo servi co serv1. O valor para a posi c ao G(host1, host2, serv1) e n ao vazia se o host vector para o host1 possui (host2, serv1) em seu caminho de conex ao. A u ltima camada (system layer) utiliza os connected-network vectors para construir um u nico vetor, representando o comportamento do sistema como um todo. O tr afego na rede e analisado por um sistema especialista simplicado, que trata de alguns tipos de entradas. O primeiro tipo corresponde aos vetores do modelo ICEM. Nesta implementa c ao apenas os connection vectors e os host vectors s ao usados. O segundo tipo consiste dos pers de comportamento esperado do tr afego. A combina c ao dos pers com o tr afego atual permite que o NSM detecte comportamento an omalo na rede. O terceiro tipo representa o conhecimento sobre as capacidades oferecidas por cada servi co de rede disponibilizado. O quarto tipo consiste do n vel de autentica c ao requerido por cada servi co. O quinto tipo corresponde ao n vel de seguran ca de cada uma das m aquinas e o sexto tipo corresponde ` as assinaturas de ataques passados. Os dados destas fontes s ao usados para identicar se uma conex ao em particular representa um comportamento intrusivo, ou se um host foi comprometido. A avalia c ao da seguran ca de um host, relacionado a uma conex ao em particular e fun c ao de quatro fatores: anormalidade da conex ao, n vel de seguran ca do servi co usado, n vel de sensibilidade em rela c ao ` a dire c ao da conex ao e as assinaturas de ataques reconhecidas no uxo de dados daquela conex ao (Mukherjee e Levitt, 1994). Algumas vantagens deste sistema s ao: o NSM pode monitorar um conjunto heterog eneo de m aquinas e sistemas operacionais, por utilizar protocolos de rede padronizados, como UDP e TCP; o processo de detec c ao e agil, devido ` a natureza das redes locais broadcast, que permitem acesso aos dados assim que transmitidos pela rede, e o sistema monitora

65

passivamente a rede e est a logicamente protegido, pois e invis vel e seus dados n ao podem ser modicados. Algumas desvantagens s ao: implementa c ao de todo o modelo e complexa; a especica c ao de limiares de detec c ao deve ser feito com muita cautela, e s o e poss vel detectar as assinaturas de ataques codicadas. 4.2.6.2 Distributed Intrusion Detection System

Outro marco na pesquisa em detec c ao de intrus ao foi o sistema conhecido como Distributed Intrusion Detection System (DIDS). Este sistema e um aprimoramento do NSM e foi desenvolvido por Snapp et al. (2000) para suprir as falhas apresentadas naquele sistema. A arquitetura do DIDS combina monitoramento distribu do e redu c ao de dados, sendo que a an alise dos dados e centralizada. Os componentes do sistema s ao DIDS director, host monitor (por host) e LAN monitor (por cada segmento da rede local, na rede monitorada). Os componentes host monitor e LAN monitor s ao respons aveis pela coleta de evid encias relacionadas ` a atividades suspeitas ou n ao autorizadas. Por outro lado, o DIDS director e respons avel pela avalia c ao dos dados coletados. O host monitor coleta e analisa registros de auditoria do host, que representam eventos de interesse. Estes eventos s ao, ent ao, enviados para o DIDS director, para an alise posterior. O LAN monitor observa todo o tr afego em seu segmento da rede local, para monitorar conex oes do tipo host-a-host, servi cos usados e volume do tr afego. Ele relata atividades de rede, como rlogin e telnet, o uso de servi cos relacionados a seguran ca e mudan cas nos padr oes do tr afego da rede. O DIDS director obt em os dados de cada host e dos LAN monitors e os envia para o sistema especialista. O sistema especialista e respons avel por avaliar e relatar o estado de seguran ca do sistema monitorado. Ele recebe relat orios dos hosts e LAN monitors e, baseado nestes, faz infer encias sobre a seguran ca de cada host, bem como do sistema como um todo. O sistema especialista e baseado em regras, sendo que estas regras s ao derivadas de um modelo de detec c ao de intrus ao, denominado Intrusion Detection Model - IDM (Smaha, 1988). A interface do DIDS director permite que o System Security Ocer (SSO), ou analista de seguran ca, tenha acesso interativo a todo o sistema. 4.2.6.3 Event Monitoring Disturbances Enabling Responses to Anomalous Live

Sucessor do NIDES, o Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD) e uma ferramenta distribu da e escal avel, para rastrear atividades mal intencionadas em redes de grande porte. Sua arquitetura utiliza monitores de vig lia e resposta altamente distribu dos, ajust aveis de forma independente, que s ao empregados em v arias camadas abstratas na rede. E composta por um conjunto de uni66

dades interoper aveis de an alise e resposta (monitores), que prov eem prote c ao localizada de ativos chaves em uma rede. Os monitores s ao computacionalmente independentes, provendo assim um grau de paralelismo na cobertura de an alise, enquanto ajuda na distribui c ao da carga computacional e utiliza c ao de espa co em disco. Atrav es do emprego de monitores locais aos alvos de an alise, o EMERALD ajuda a reduzir poss veis atrasos na an alise e resposta, que podem ocorrer ao longo da rede. Tamb em introduz um esquema de an alise hier arquica, onde an alises locais s ao compartilhadas e correlacionadas em camadas de abstra c ao mais altas. O esquema de an alise e iniciado a partir da camada de interface de rede, de dom nios administrativos individuais. Os monitores s ao empregados por todo o dom nio e em cada um dos dom nios, para analisar a opera c ao dos servi cos de rede e outros componentes externamente acess veis. Cada monitor cont em um conjunto espec co de manipuladores de respostas, que s ao invocadas ao detectar um poss vel abuso. Estes monitores da camada de servi co (service-layer) tamb em disseminam suas an alises para outros monitores do EMERALD, que realizam a correla c ao para o dom nio. Os monitores de dom nio prov eem uma perspectiva mais global, em rela c ao a gera c ao de pers e modelagem de vulnerabilidades, que podem ocorrer de interdepend encias entre servi cos da rede e outros ativos dentro do dom nio. Finalmente, o EMERALD implementa uma an alise para correlacionar os relat orios de atividades produzidos atrav es do conjunto de dom nios monitorados. Os monitores da camada Enterprise-layer est ao focados em amea cas a rede, tais como Internet worms, ataques repetidos contra servi cos de redes comuns atrav es dos dom nios, ou ataques coordenados a partir de v arios dom nios contra um u nico dom nio. Atrav es da correla c ao e compartilhamento de resultados de an alise, relat orios de problemas encontrados por um monitor podem propagar para outros monitores e para toda a rede. O monitor foi projetado para ocupar pouco espa co, ser bem r apido e gen erico o bastante para ser empregado em qualquer camada no esquema hier arquico de an alise do EMERALD. O monitor opera como um detector de intrus ao descentralizado, que combina an alise por assinatura com a gera c ao de pers estat sticos, provendo prote c ao localizada, em tempo real, da infraestrutura e dos servi cos da rede. O monitor incorpora uma API (application program interface) que melhora a capacidade de interoperabilidade com o alvo de an alise e com outras ferramentas de detec c ao de intrus ao. O EMERALD representa um grande avan co, em rela c ao ` as pesquisas anteriores e o desenvolvimento de detec c ao por abuso e anomalia, para acomodar o monitoramento de grandes sistemas distribu dos e redes. Devido ao fato de an alise em tempo real poder

67

ser distribu da e aplicada onde for mais efetiva, em diferentes camadas de abstra c ao, o EMERALD apresenta vantagens signicantes sobre abordagens mais centralizadas, em termos de capacidade de detec c ao e resposta a eventos. Este pretende detectar n ao apenas ataque locais, mas tamb em ataques coordenados como denial-of-service distribu do ou padr oes de ataque repetidos contra v arios dom nios (Porras e Neumann, 2002). 4.2.6.4 Advanced Counter-Measures Environment

(Cansian, 1997) desenvolveu um sistema adaptativo de detec c ao de intrus ao (SADI), que foi a primeira refer encia para a aplica c ao do m etodo de detec c ao de intrus ao por abuso, utilizando reconhecimento de padr oes associado ` a redes neurais. O Advanced CounterMeasures Environment (ACME!)1 constitui a continua c ao deste trabalho. Este SDI baseia-se em um modelo de detec c ao, composto por um sistema de captura e tratamento de pacotes, um sistema de rede neural, e um gerenciador de comunica c oes e interface com o usu ario. O sistema de captura e tratamento de pacotes e modularizado, de forma que seu m odulo de mais baixo n vel apenas captura o uxo de dados no tr afego de rede e envia os pacotes ordenados para o m odulo de conex ao, que por sua vez, est a sob controle do m odulo de pr e-sele c ao e sistema especialista. O m odulo de pr e-sele c ao e sistema especialista (PSSE) decide se uma conex ao e considerada suspeita. Neste caso, um conjunto procedimentos e executado simultaneamente. Este e respons avel por mais um n vel de ltragem, pois o m odulo de conex ao s o inicia o registro das atividades de hosts ou dom nios considerados suspeitos, quando indicado pelo m odulo de pr e-sele c ao e sistema especialista. O m odulo de conex ao (CON) e respons avel pela cria c ao e manuten c ao de vetores de conex ao, que constituem a representa c ao contendo a reconstru c ao do uxo de dados. Um vetor de conex ao armazena os dados que trafegam em uma dada conex ao, a partir do momento em que ela foi considerada suspeita. Este e composto por informa c oes de controle, tais como portas, endere cos, tipos de frame, at e os dados efetivamente transportados. Esse m odulo e acionado pelo m odulo de pr e-sele c ao e sistema especialista, que transmite os dados necess arios para a cria c ao do vetor de conex ao. Ap os a constru c ao do vetor de conex ao, e criado o vetor de est mulo, que corresponde ` a codica c ao bin aria do vetor de conex ao. Este vetor de est mulo e, ent ao, enviado para o m odulo de rede neural. A interface da rede neural recebe o conjunto de bits que comp oe
1

P agina Web em: http://www.acme-ids.org/acme-ids/.

68

o vetor de est mulo e, baseado no treinamento ao qual a rede foi submetida, retorna um valor num erico, que indica o grau de suspeita da sess ao. A cada atualiza c ao de dados para uma conex ao, o sistema efetua uma nova an alise do estado alcan cado pelo vetor de est mulo, fornecendo um coeciente de n vel de intrus ao, atrav es do m odulo de rede neural. Este novo valor substitui o antigo coeciente no arquivo de sa da de dados. Este e utilizado pela interface do usu ario e cont em a rela c ao de todas as conex oes monitoradas e suas respectivas informa c oes. A seguir, verica-se se o coeciente relacionado a cada conex ao ultrapassou o limiar de intrus ao permitido. Caso positivo, o sistema executa um m odulo para a realiza c ao de a c oes, que podem ser pr e-programadas pelo administrador do sistema. 4.2.6.5 SANS Heuristic Analysis system for Defensive Online Warfare

O System Administration Networking and Security (SANS2 ) Institute anunciou, em julho de 1998, uma ferramenta de monitoramento de rede, de dom nio p ublico: o SANS Heuristic Analysis system for Defensive Online Warfare (SHADOW). Parte do projeto, intitulado Cooperative Intrusion Detection Evalution and Response (CIDER), e um sistema de detec c ao de intrus ao, que pode ser constru do atrav es da utiliza c ao de softwares de dom nio p ublico dispon veis e hardware existente ou de baixo custo. A discuss ao a seguir baseia-se em Northcutt (1999) e Stocksdale (2002). A id eia b asica do sistema SHADOW e que existe uma hist oria a ser contada pelos pacotes trafegando nas redes. Dentro do uxo de dados esperado, podem ocorrer pacotes mal intencionados, contendo algumas formas de ataques. Sem um sistema de detec c ao de intrus ao, seria provavelmente imposs vel detectar estas atividades, para determinar sua origem, observar padr oes, ou congurar alarmes quando eventos semelhantes fossem detectados. O sistema e, ent ao, projetado para ter componentes em localiza c oes estrat egicas (dentro ou fora de um Firewall), coletando dados associados ao tr afego da rede. Estes dados s ao posteriormente movidos para um m odulo de an alise, para avalia c ao. A arquitetura do SHADOW e composta por dois sistemas: uma m aquina de coleta de dados, conhecida como sensor, e uma esta c ao de an alise. O sensor e situado na rede de interesse (alvo) e captura parte ou todo o tr afego. Os dados brutos (raw) s ao movidos, atrav es de um canal seguro, para a esta c ao de an alise. A implementa c ao e baseada na utiliza c ao de duas ferramentas originalmente desenvolvidas pelo Lawrence Berkeley Laboratory (LBL3 ): libpcap (vista na se c ao 3.2) e o tcpdump (visto na se c ao 3.3).

2 3

P agina Web em http://www.sans.org. P agina Web em http://www.lbl.gov.

69

Basicamente, o SHADOW e constitu do por um conjunto de scripts na linguagem de programa c ao PERL (Wall et al., 1996), que realizam as seguintes tarefas: Criam arquivos para onde ser ao copiados os dados coletados; Iniciam e terminam processos tcpdump, relacionados ` a coleta do tr afego da rede; Transferem, utilizando um processo seguro, os dados coletados para an alise; Ordenam e agrupam os dados e os disponibilizam em p aginas Web; Realizam an alises diferenciadas sobre os dados coletados. O sistema sensor e constitu do pelos scripts que coletam os dados na rede, descritos como se segue: sensor driver.pl : este script e executado periodicamente na m aquina que funciona como sensor. Ele recebe um argumento, apontando para um arquivo de congura c oes. Este arquivo cont em informa c oes, como localiza c ao do aplicativo tcpdump e seus par ametros, localiza c ao da aplica c ao utilizada na compacta c ao dos dados coletados (gzip), entre outras. Al em disso, utiliza um arquivo contendo os ltros (express oes booleanas) a serem aplicados pelo processo de coleta de dados. O script faz chamadas para outros dois scripts. Um inicia e o outro termina o processo tcpdump. Como o sensor driver.pl e peri odico, ao ser chamado novamente, p ara o processo tcpdump anterior e inicia um novo processo; start logger.pl : este script tem como par ametros os arquivos de congura c ao e de ltros, utilizados pelo script sensor driver.pl. Ele cria o nome do arquivo para onde ser ao enviados os dados brutos, coletados da rede, baseado na data e hora atuais. Ent ao, inicia o processo tcpdump, passando como par ametro o arquivo de ltros, a interface de rede, um arquivo de log (para mensagens de status e erros), e direcionando sua sa da para o arquivo com nome no formato data-hora. Enquanto este processo e executado, o arquivo de sa da e comprimido, visando a redu c ao do espa co ocupado; stop logger.pl : este script interrompe o processo tcpdump e, ent ao, fecha o arquivo contendo os dados brutos coletados. Como o sistema sensor, o analisador e constitu do por um conjunto de scripts, mas que realizam atividades diferentes. Deve-se observar que o analisador precisa habilitar um 70

servidor Web (como o Apache4 ), pois seus resultados s ao disponibilizados em formato hipertexto, e precisam estar atualizados. Al em de uma p agina que d a acesso as p aginas de resultado, o analisador do SHADOW disp oem de outras facilidades, acess veis tamb em no formato hipertexto, que auxiliam o System Security Ocer no rastreamento de um determinado dom nio, no relato de um incidente de seguran ca, dentre outras. Os scripts s ao: fetchem.pl : este script e executado periodicamente e realiza um sequ encia de atividades. Ele copia o u ltimo arquivo compactado de dados brutos gerado no sensor, utilizando um canal seguro. Este canal seguro e provido pelo Secure Shell - SSH5 . O arquivo e, ent ao, descompactado e inicia-se o processo tcpdump para a leitura dos dados brutos. Este processo utiliza arquivos, contendo ltros ou padr oes, a serem reconhecidos nos dados brutos. O resultado desta ltragem e enviado para um arquivo texto tempor ario. O pr oximo passo e ordenar e agrupar os dados, de acordo com o endere co de origem, que pode ser obtido do cabe calho dos pacotes. Al em disso, neste mesmo passo, tenta-se resolver os endere cos IP dos pacotes em nomes. Deve-se observar que este processo e demorado e pode ser exclu do. Finalmente, o resultado e armazenado em uma p agina, no formato hipertexto, e disponibilizada pelo servidor Web; cleanup.pl : este script acessa o sistema sensor atrav es de um canal seguro e remove os arquivos de dados brutos armazenados a mais de n dias, sendo que n pode ser congurado. Esta medida procura evitar que o sensor que sem espa co de armazenamento. Para contornar o problema de detec c ao de ataques pequenos e lentos, como determinados tipos de varreduras de rede, foi desenvolvido um conjunto de scripts para este tipo de an alise, descritos a seguir: one day pat.pl : procura por um padr ao (no formato tcpdump) espec co, nos arquivos correspondentes a um dia, utilizando a linha de comandos; one day script.pl : procura por padr oes nos arquivos correspondentes a um dia, utilizando um ltro pr e-denido, no diret orio que cont em os arquivos de ltragem (especicam as express oes booleanas no formato tcpdump); pat match.pl : procura em um arquivo de dados brutos espec co, por um padr ao especicado na linha de comandos.
4 5

P agina Web em http://www.apache.org. P agina Web em http://www.openssh.org.

71

O sistema de detec c ao de intrus ao SHADOW reconhece padr oes no tr afego de rede, baseado em ltros constru dos por um analista, para identicar atividades an omalas, tais como Land attacks, Ping of Death, dentre outros. Os analistas devem modicar e adicionar novos ltros que correspondam ` as necessidades de seu dom nio. Finalizando, analistas com conhecimento no desenvolvimento dos ltros s ao a chave das implementa c oes bem sucedidas deste sistema de detec c ao de intrus ao. 4.2.6.6 Snort

O Snort, desenvolvido por (Roesch, 1999), e um sistema de detec c ao de intrus ao de dom nio p ublico, originalmente projetado para ambientes de rede com tr afego moderado. Ele se baseia na biblioteca libpcap para realizar a captura de pacotes de rede e disp oe de um conjunto de regras, utilizado no reconhecimento de padr oes no conte udo dos pacotes capturados. As regras dispon veis permitem a detec c ao de uma grande variedade de ataques, varreduras e atividades relacionadas ` a explora c ao de vulnerabilidades de aplica c oes, al em de ser capaz de gerar alertas em tempo real. A arquitetura do Snort e dividida em tr es componentes principais: o decodicador de pacotes, o mecanismo de detec c ao e o sistema de registro de eventos (logging) e gera c ao de alertas. O decodicador de pacotes e composto por um conjunto de subrotinas, que atuam sobre os dados capturados para cada pacote. Cada subrotina corresponde a uma camada da pilha de protocolos TCP/IP e cuida da decodica c ao da parte relacionada do pacote. A principal fun c ao do decodicador e, ent ao, estabelecer apontadores para segmentos do pacote, de modo que estes segmentos possam ser posteriormente analisados pelo mecanismo de detec c ao. O Snort mant em as regras de detec c ao em listas encadeadas, conhecidas como Chain Headers e Chain Options. Cada elemento da Chain Headers e constitu do por atributos comuns a um constitu do por regras, e mant em uma lista do tipo Chain Options, onde cada elemento, por sua vez, e constitu do por op c oes de detec c ao diferenciadas para cada regra do conjunto correspondente. Esta modelagem tem como nalidade melhorar o desempenho do processo de detec c ao. As listas encadeadas s ao, ent ao, checadas recursivamente para cada pacote, de modo que a primeira regra que confere com um pacote decodicado no mecanismo de detec c ao dispara uma a c ao especicada na deni c ao da regra. O sistema de registro de eventos e gera c ao de alertas permite que logs e alertas sejam gerados em diferentes formatos, que s ao selecionados no momento em que o Snort e

72

inicializado, atrav es de argumentos da linha de comandos. Pacotes podem ser registrados em seu formato decodicado e leg vel, e armazenados em uma estrutura de diret orios baseada em endere cos IP, no formato bin ario do tcpdump em um u nico arquivo, ou at e em uma base de dados. O primeiro formato de armazenamento permite uma an alise mais r apida dos dados coletados pelo sistema, ao passo que o segundo apresenta um melhor desempenho no processo de armazenagem em disco e, portanto, e indicado em situa c oes onde alta performance e necess aria. J a os alertas podem ser enviados para o processo syslog, para arquivo-texto em diferentes formatos, ou para a tela, atrav es de janelas de di alogo. A arquitetura modularizada do Snort permite que outros m odulos (plugins) sejam desenvolvidos e acoplados ao sistema, no intuito de adicionar funcionalidades de detec c ao ou personaliz a-lo para realiza c ao de tarefas espec cas. Quando um m odulo e caracterizado como um preprocessador, este atua entre o decodicador de pacotes e o mecanismo de detec c ao. Desta forma, uma de suas principais fun c oes e preparar um ou mais pacotes decodicados para serem analisados pelo mecanismo de detec c ao. Dentre os preprocessadores atualmente dispon veis destacam-se o Frag2 e o Stream4. O primeiro permite remontar datagramas IP fragmentados. J a o segundo prov e a capacidade de remontagem de uxo de dados (stream reassembly) e de rastreio e an alise de estados para o TCP (Roesch e Green, 2002).

73

74

CAP ITULO 5 DE SESSOES O SISTEMA DE RECONSTRUC AO TCP/IP Este cap tulo apresenta o sistema de reconstru c ao de sess oes TCP/IP, conhecido como RECON. S ao apresentadas algumas considera c oes, relacionadas ao seu desenvolvimento, e e apresentada e discutida a modelagem criada para representar as sess oes TCP/IP, baseada em Chaves e Montes (2001). Tamb em e apresentada e discutida a implementa c ao detalhada de todo o sistema. 5.1 CONSIDERAC OES GERAIS SOBRE O DESENVOLVIMENTO DO SISTEMA

O desenvolvimento deste sistema parte de algumas considera c oes, referentes ` a obten c ao dos pacotes de rede. As pr oximas se c oes apresentam uma discuss ao sobre estrat egias de captura de pacotes e suas implica c oes, bem como a metodologia adotada para a an alise dos dados obtidos do tr afego de redes TCP/IP. 5.1.1 Estrat egias de Captura de Pacotes

A captura de dados para um sistema de monitoramento de redes, ou mesmo para sistemas de detec c ao de intrus ao, e realizada por um elemento de rede normalmente conhecido como sensor. Existem v arias possibilidades para o posicionamento deste dispositivo na rede sendo monitorada e que inuenciam diretamente na eci encia e utilidade dos resultados sendo gerados pelo monitor de rede ou detector de intrus oes, a partir da an alise dos dados coletados. A Figura (5.1) apresenta as formas mais utilizadas no posicionamento de sensores de rede. Na primeira forma de posicionamento, apresentada na ilustra c ao (a) da Figura (5.1), o sensor e colocado fora dos limites de prote c ao do Firewall, de modo que todo o tr afego destinado ` a rede monitorada e selecionado para a coleta de pacotes. Esta congura c ao permite a observa c ao de ataques direcionados ao Firewall e a recursos protegidos por este. Em contrapartida, a quantidade de dados a serem tratados e consideravelmente maior. Na ilustra c ao (b), o sensor, posicionado dentro dos limites de prote c ao do Firewall, observa apenas o tr afego permitido e destinado ` a rede monitorada, eliminando assim a coleta de todos os pacotes bloqueados. Desta forma, a quantidade de dados a serem tratados reduz razoavelmente.

75

E nalmente, na ilustra c ao (c) s ao colocados dois sensores: um dentro dos limites de prote c ao do Firewall e outro fora. Al em das caracter sticas apresentadas para as ilustra c oes anteriores, esta abordagem permite, atrav es da compara c ao do tr afego coletado pelos sensores em ambos os lados do Firewall, validar as regras de controle deste dispositivo (McHugh et al., 2000). A quantidade de dados a serem tratados para este caso e semelhante ao (a).

INTERNET SENSOR

INTERNET INTERNET barramento FIREWALL FIREWALL barramento barramento SENSOR

SENSOR

barramento

FIREWALL

REDE MONITORADA

REDE MONITORADA REDE MONITORADA

SENSOR

(a)

(b)

(c)

FIGURA 5.1 Posicionamento do sensor de rede. Deve-se observar que para todas a ilustra c oes apresentadas, o sensor de rede est a conectado a um barramento, o que viabiliza a observa c ao de todo o tr afego passando pelo ponto de monitoramento em quest ao. Outra observa ca o importante refere-se ao sentido unidirecional da seta, que representa o tr afego indo para o sensor. Isto quer dizer que o sensor e passivo e n ao interage com outros dispositivos, a n ao ser para eventuais transfer encias de dados coletados. 5.1.2 Metodologia Adotada para Captura e An alise de Dados

Algumas considera c oes e procedimentos foram adotados no desenvolvimento do sistema de reconstru c ao de sess oes RECON, e dizem respeito a forma de captura dos pacotes no tr afego de rede e de sua posterior an alise. O RECON foi projetado para analisar apenas os cabe calhos dos pacotes da pilha de protocolos TCP/IP, onde s ao considerados:

76

 da camada de enlace de dados, o protocolo Ethernet; da camada de rede, os protocolos IP e ICMP; e da camada de transporte, os protocolos UDP e TCP. Desta forma, o componente sensor do sistema de detec c ao de intrus ao SHADOW, descrito na se c ao 4.2.6.5, foi utilizado como dispositivo de captura de pacotes, pois este coleta apenas 68 bytes por pacote do tr afego de rede. Este padr ao para a quantidade de dados sendo capturados normalmente engloba todos os cabe calhos descritos anteriormente. Foi adotada, ent ao, a metodologia de an alise oine (ou pos-mortem) dos dados. O tr afego de rede e coletado pelo sensor e armazenado em arquivos periodicamente. Estes arquivos s ao transferidos para uma esta c ao de an alise, onde o RECON e executado, analisando assim os pacotes TCP/IP obtidos dos arquivos em quest ao. Sabe-se que a an alise de dados em tempo real e amplamente utilizada na detec c ao de padr oes de ataques conhecidos. Em contrapartida, a an alise oine permite identicar novas tend encias, por meio da detec c ao de anomalias, e avaliar como os ataques est ao se comportando e evoluindo, pois pode-se englobar na an alise intervalos de tempo consideravelmente maiores, fazendo uso de pacotes previamente coletados e armazenados. Estas caracter sticas reduzem a preocupa c ao com problemas relacionados ` a exaust ao de recursos do sistema. Algumas extens oes da metodologia adotada para a captura de pacotes de rede s ao propostas no Cap tulo 7. 5.2 MODELAGEM DAS SESSOES TCP/IP

Um modelo pode ser visto como a representa c ao de algo que se quer reproduzir ou imitar. Especicamente, um modelo de dados pode ser visto como a representa c ao de um conjunto de informa c oes de forma estruturada, em um sistema computacional, baseado em um conjunto de premissas. Estas premissas, bem como a forma de representa c ao do modelo criado para representar as sess oes TCP/IP, s ao descritas a seguir. Faz-se necess ario estabelecer uma deni c ao concisa para sess ao TCP/IP, j a que o o objetivo do sistema RECON e obter informa c oes dos cabe calhos dos pacotes e a partir destas informa c oes, reconstruir e inferir sobre o estado das sess oes TCP/IP contidas no tr afego de rede sendo analisado. Uma sess ao TCP/IP e denida por qualquer sequ encia de pacotes, que caracterize a troca de informa c oes entre dois endere cos IP, e que tenha in cio, meio e m (mesmo que 77

toda a comunica c ao esteja contida em um u nico pacote). Na literatura, e comum encontrar refer encias onde e feita a analogia entre o conceito de sess ao e conex ao utilizando o protocolo TCP, por ser este um protocolo orientado ` a conex ao. Esta analogia e natural, pois no protocolo TCP o in cio, meio e m de uma conex ao s ao bem denidos e facilmente identic aveis. J a para protocolos n ao orientados ` conex a ao, como o UDP e o ICMP, faz-se necess ario extrapolar o conceito normalmente utilizado para a deni c ao de sess ao. Portanto, nessa modelagem o conceito de sess ao foi dividido em tr es categorias: Sess ao TCP corresponde a conex ao TCP (se c ao 2.6). Cada sess ao TCP e identicada pelo seguinte conjunto de informa c oes: endere co IP de origem e porta de origem, endere co IP de destino e porta de destino. Como podem haver recorr encias deste conjunto de informa c oes no tr afego de rede, os pacotes que caracterizam o in cio e o t ermino de uma conex ao TCP (se c ao 2.6.1) s ao utilizados para delimitar as sess oes. Sess ao ICMP existem dois formatos de mensagens ICMP: mensagens de informa c ao e mensagens de erro. A comunica c ao utilizando mensagens ICMP de informa c ao ocorre atrav es de requisi c oes e suas respectivas respostas. Portanto, uma sess ao ICMP de informa c ao e denida pelo conjunto de pacotes de requisi c ao e de respostas, caracterizadas pelas seguintes informa c oes: endere co IP de origem, endere co IP de destino e o campoidentierdo cabe calho da mensagem ICMP de informa c ao. J a as mensagens ICMP de erro normalmente est ao associadas a alguma falha ou problema na comunica c ao entre hosts ou dispositivos da rede. Como visto na se c ao 2.4.1, uma mensagem ICMP de erro n ao deve ser gerada como resposta a outra mensagem de erro, portanto n ao e denido uma sess ao para este formato de mensagem. Cada mensagem ICMP de erro e apenas associada ao pacote gerador do erro, que pode ser um pacote TCP, UDP ou ICMP de informa c ao. Sess ao UDP corresponde ao conjunto de pacotes, identicados pelo seguinte conjunto de informa c oes: endere co IP de origem e porta de origem, endere co IP de destino e porta de destino. Apesar de haver uma correspond encia com as informa c oes utilizadas na caracteriza c ao da sess ao TCP, n ao existe uma forma de delimitar as sess oes. O cabe calho UDP n ao fornece informa c oes sucientes para identicar o in cio e o t ermino de uma comunica c ao. Normalmente estas informa c oes s o podem ser encontradas no conte udo dos pacotes. Portanto, todos os pacotes no tr afego de rede, caracterizados pelo conjunto de informa c oes inicialmente descrito, s ao associados a uma mesma sess ao UDP. 78

Para denir a metodologia adotada na representa c ao do modelo de reconstru c ao de sess oes, e preciso inicialmente especicar uma forma de representa c ao para o tr afego de rede. Esta representa c ao e apresentada na pr oxima se c ao (5.2.1). 5.2.1 Representa c ao utilizando Grafos

O tr afego de rede constitui a mat eria-prima, ou seja, os dados lidos e modelados (ou representados) na forma de sess oes TCP/IP. Este pode ser visto como um conjunto de endere cos IP (representando os hosts ou dispositivos conectados ` a rede)1 e a comunica c ao (ou transfer encia de dados) entre cada par de endere cos deste conjunto. Da vem a facilidade em estabelecer uma rela c ao entre os elementos que constituem o tr afego de rede e o conceito de grafos. Segundo Gibbons (1985), um grafo consiste de um conjunto de v ertices interconectados por um conjunto de arestas. Para um grafo G, denota-se o conjunto de v ertices por V e o conjunto de arestas por E , sendo G = (V, E ). Uma aresta no grafo G pode ser especicada por dois v ertices que esta conecta. Se a aresta e conecta os v ertices vi e vj , ent ao denota-se e = (vi , vj ) ou e = (vj , vi ). Al em disso, se (vi , vj ) E , ent ao vi e adjacente a vj e vj e adjacente a vi . Portanto, o tr afego de redes e representado pelo grafo G = (V, E ), onde o conjunto de v ertices V e constitu do por todos os endere cos IP do tr afego de rede, e cada aresta do conjunto de arestas E representa a comunica c ao entre dois endere cos IP (v ertices) do conjunto V , justicando assim a utiliza c ao de grafos para a modelagem inicial dos dados. Cada v ertice vi V e associado a um u nico IP do tr afego de rede, sendo que o n umero inteiro que representa o IP em quest ao, obtido do cabe calho do datagrama IP, e utilizado como identicador para o v ertice. Uma aresta e = (vi , vj ) e inserida no conjunto de arestas E , no momento em que ocorre a primeira transfer encia de dados (envio de um pacote) entre os IPs representados pelos v ertices vi e vj . Quaisquer transfer encias subsequentes referem-se ` a mesma aresta. Dadas as deni c oes citadas anteriormente, os seguintes termos ser ao utilizados com signicados equivalentes, no decorrer desta disserta c ao: v ertice - IP - endere co IP - n umero inteiro representando o IP - host - dispositivo conectado ` a rede; aresta - transfer encia de dados entre dois IPs - comunica c ao entre dois IPs 1 Parte-se do princ pio que um host ou dispositivo conectado ` a rede e representado por um endere co IP, a n ao ser para casos explicitamente especicados.

79

envio de pacote de um IP para outro. No processo de gera c ao do grafo G, inicialmente os conjuntos V (v ertices) e E (arestas) ` medida que cada pacote s ao vazios (V = e E = ). A e lido do tr afego de rede e utilizado para alimentar o processo de gera c ao do grafo, tr es casos podem ocorrer. Para apresentar os casos, seja vi um dos IPs do pacote, vj o outro IP e e = (vi , vj ) a comunica c ao entre estes IPs (representada pelos dados contidos no pacote). Caso 1 Os v ertices vi e vj n ao existem no conjunto V do grafo G = (V, E ). Ocorre na leitura do primeiro pacote entre dois IPs, onde ambos ainda n ao apareceram nos dados coletados. S ao adicionados ao conjunto V os v ertices vi e vj [V V vi e V V vj ] e e adicionada ao conjunto E a aresta e = (vi , vj ) [E E e ou E E (vi , vj )]. Caso 2 O v ertice vi n ao existe no conjunto V do grafo G = (V, E ). Ocorre na leitura do primeiro pacote entre dois IPs, onde um dos IPs ainda n ao apareceu nos adicionado ao conjunto V o v dados coletados. E ertice vi (V V vi ) e e adicionada ao conjunto E a aresta e = (vi , vj ) [E E e ou E E (vi , vj )]. Caso 3 Os v ertices vi e vj existem no conjunto V , mas a aresta e = (vi , vj ) n ao existe no conjunto E do grafo G = (V, E ). Ocorre na leitura do primeiro pacote entre dois IPs, onde ambos j a apareceram nos dados coletados, mas ainda n ao adicionada ao conjunto E a aresta e = (vi , vj ) houve comunica c ao entre eles. E [E E e ou E E (vi , vj )]). A gera c ao do grafo G consiste na cria c ao de uma lista de adjac encia (Gibbons, 1985), onde cada v ertice tem uma lista associada de v ertices adjacentes. A Figura 5.2 apresenta o exemplo de um grafo G, gerado para um tr afego de rede hipot etico, e sua respectiva lista de adjac encia. Para cada v ertice contido nas listas de adjac encia dos v ertices A, B , C , D e E , podese observar a ocorr encia do s mbolo . Este e utilizado para denotar que o elemento representante do v ertice e um apontador. Por exemplo, a lista de adjac encia do v ertice A cont em um apontador para o v ertice B e outro para o v ertice C , signicando que o IP A se comunicou como o IP B e com o IP C . Isto evita que identicadores de IPs sejam replicados, reduzindo assim o espa co ocupado no armazenamento do grafo. O grande problema de uma representa c ao baseada em grafos e a determina c ao de um m etodo para a localiza c ao de v ertices. A metodologia empregada para solucionar este problema e apresentada na pr oxima se c ao (5.2.2).

80

A A B D E G B C C D E

B A A E D

Lista de adjacncia

FIGURA 5.2 Grafo G representando o tr afego de rede e sua listas de adjac encias. 5.2.2 Solu c ao para o Problema de Localiza c ao de V ertices

A maioria das implementa c oes de grafos necessitam de um m etodo sistem atico para localiza c ao de v ertices. Foram vistos tr es casos na se c ao 5.2.1, que envolvem a identica c ao de v ertices, de forma que a c oes s ao tomadas de acordo com a exist encia ou n ao de um determinado v ertice no conjunto V . Normalmente, m etodos de identica c ao (localiza c ao) de v ertices em um grafo, como em complexidade linear - O(max(n, |E |)) - onde depth-rst search (Gibbons, 1985), t n e o n umero de v ertices e |E | e o n umero de arestas. Neste caso a complexidade est a associada ao tempo de execu c ao do m etodo ou ao n umero de compara c oes realizadas para encontrar o v ertice. Para minimizar o n umero de compara c oes feitas na busca de um determinado v ertice, foi analisado um outro m etodo baseado na utiliza c ao de uma arvore bin aria balanceada (Gonnet e Baeza-Yates, 1991). Neste novo m etodo, os v ertices do grafo G correspondem aos n os da arvore. A localiza c ao (ou identica c ao) de um n o em uma arvore bin aria balanceada tem complexidade logar tmica - O(log2 n) - onde n e o n umero de n os (equivalente ao n umero de v ertices no grafo G). Portanto, esta nova abordagem melhora o desempenho na localiza c ao em pelo menos uma ordem de magnitude. A Figura 5.3 apresenta a arvore bin aria balanceada, j a associada ` as listas de adjac encias, para o grafo G da Figura 5.2. S ao utilizados os n umeros inteiros representando os endere cos IP, como chaves (ou identicadores) para os n os da arvore. Para o exemplo da Figura 5.3 tem-se A < B < C < D < ` medida que v E. A ertices s ao inseridos no conjunto de v ertices V do grafo G = (V, E ), os apontadores para os n os da arvore s ao atualizados, mantendo-a balanceada. Depois de especicada a representa c ao b asica para o tr afego de rede, onde n umeros IP s ao inseridos em uma arvore bin aria balanceada, e a comunica c ao entre cada par de IPs

81

constitui um elemento da lista de adjac encias de cada n o da arvore, faz-se necess ario apresentar a vis ao geral do modelo criado para a reconstru c ao de sess oes TCP/IP, como descrita na pr oxima sess ao (5.2.3).

root B C B A A C A D E E D

FIGURA 5.3 Arvore bin aria balanceada associada a lista de adjac encia. 5.2.3 Vis ao Geral do Modelo

Atualmente, a grande maioria dos fabricantes de sistemas de detec c ao de intrus ao de rede (SDIRs) diz que uma das caracter sticas fundamentais de seus produtos e a remontagem. Apesar deste termo ser amplamente utilizado, sua real nalidade n ao e bem especicada. Ranum (2001) enumera algumas caracter sticas, relacionadas ao termo remontagem, que um SDIR deve ter: Desfragmenta c ao (defragmenting) processo de combinar datagramas IP fragmentados em um u nico pacote, de modo que este possa ser checado em busca de ataques. Reordena c ao (reordering) processo de reordenar datagramas IP fragmentados ou mensagens TCP, de forma que estejam na sequ encia correta. Remontagem do uxo de dados (stream reassembly) processo de combinar mensagens TCP, de modo que estas representem uma cadeia de dados ordenados da forma como o host de destino est a interpretando. Rastreio do estado das sess oes (state tracking) processo de rastrear os n umeros de sequ encia TCP e o estado das sess oes, de forma que o SDIR possa entender quais dados o host destino trata como v alidos. Para metodologia de desenvolvimento do sistema de reconstru c ao de sess oes TCP/IP, algumas destas caracter sticas foram adaptadas para melhor se adequar ` a modelagem de suporte do sistema, e s ao descritas como se segue: Desfragmenta c ao constitui o processo de combinar datagramas IP fragmentados em um u nico pacote, de modo que este possa ser inserido, de forma correta, em sua sess ao correspondente; 82

 Reordena c ao constitui o processo de reordenar apenas datagramas IP fragmentados, de forma que estejam na sequ encia correta; Remontagem do uxo de dados n ao e tratada nesta modelagem, pois esta baseia-se apenas no cabe calho dos pacotes TCP/IP; Rastreio do estado das sess oes constitui o processo de rastrear e inferir sobre o estado das sess oes TCP/IP, diferenciadas por protocolo da camada de transporte (TCP, UDP ou ICMP). O modelo criado para representar os dados, uxo de execu c ao e as fun c oes do sistema de reconstru c ao de sess oes RECON, foi subdividido em m odulos, como mostra a Figura (5.4).

Sistema de leitura de pacotes Gerente da rvore de IPs Sistema de tratamento do pacote Gerente da lista de IPs interconectados Gerente das Sesses ICMP Mdulo Ethernet Gerente da rvore de logs TCP Mdulo IP fluxo normal de tratamento do pacote Gerente da rvore desfragmentao Gerente do Bloco de Sesses TCP/IP Gerente das Sesses UDP Gerente das Sesses TCP

tramento de erros ou situaes especiais

FIGURA 5.4 Vis ao geral do modelo para a reconstru c ao de sess oes. O primeiro m odulo a ser descrito e o sistema de leitura de pacotes. Este utiliza a biblioteca de captura de pacotes para obter de um arquivo, contendo o tr afego de rede a ser analisado, cada pacote e o envia para o sistema de tratamento do pacote. Este, por sua vez, e respons avel por vericar se o frame, contido no pacote, e do tipo Ethernet. Caso positivo, envia o frame para o m odulo Ethernet. Caso contr ario, devolve o controle para o sistema de leitura de pacotes. O m odulo Ethernet checa se o cabe calho Ethernet est a completo e, caso positivo, verica se os dados contidos no frame constituem um datagrama IP. Caso contr ario, devolve o controle para o sistema de leitura de pacotes. Se o frame contiver um datagrama IP, este e enviado para o m odulo IP. O m odulo IP verica se o cabe calho do datagrama est a completo e, caso contr ario, devolve 83

o controle para o sistema de leitura de pacotes. Se o datagrama est a correto, ent ao existem duas possibilidades: ele e um datagrama normal ou e um fragmento. Para o datagrama normal, verica-se qual protocolo da camada de transporte2 est a sendo usado (TCP ou UDP ou ICMP). Ent ao, de acordo com o protocolo, e feita a verica c ao do cabe calho da camada de transporte em quest ao. Caso este esteja completo, o datagrama IP e enviado para os m odulos gerente da arvore de IPs, gerente da lista de IPs interconectados e gerente do bloco de sess oes TCP/IP. Se o datagrama e um fragmento, este e enviado para o gerente da arvore de desfragmenta c ao. Este m odulo e respons avel por receber cada fragmento IP e realizar as seguintes opera c oes: verica se existe um n o da arvore de desfragmenta c ao associado ao fragmento; cria o n o se este n ao existir, ou atualiza as informa c oes associadas a este n o, que dizem se o fragmento ainda est a sendo remontado, se o tempo de remontagem expirou, ou se o datagrama j a foi completamente desfragmentado. Caso este tenha sido desfragmentado, e tratado da mesma forma que um datagrama normal, como descrito anteriormente. O gerente da arvore de IPs e o gerente da lista de IPs interconectados s ao respons aveis por gerar e atualizar o grafo, que representa o tr afego de rede, como descrito nas se c oes 5.2.1 e 5.2.2. O gerente da arvore de IPs obt em os IPs de origem e destino do datagrama e os insere na arvore de IPs, caso estes n ao fa cam parte dessa. E o gerente da lista de IPs interconectados cria a rela c ao entre o par de IPs do datagrama, atrav es da atualiza c ao das listas de adjac encia de cada um dos IPs em quest ao. J a o gerente do bloco de sess oes TCP/IP cria um bloco de acesso ` as sess oes associadas a esse par de IPs (caso este ainda n ao tenha sido criado). Depois de checar o cabe calho da camada de transporte e atualizar a arvore de IPs, as listas de adjac encias e o bloco de sess oes TCP/IP, e extra da do datagrama IP a mensagem, correspondente ao protocolo da camada de transporte, sendo utilizada pelo pacote. Esta e, ent ao, enviada ao gerente das sess oes ICMP ou ao gerente das Sess oes UDP ou gerente das Sess oes TCP, de acordo com o protocolo de transporte. O gerente das sess oes ICMP divide-se em duas partes: o gerente das sess oes ICMP de informa c ao e o gerente dos pacotes ICMP de erro. Caso a mensagem ICMP seja de informa c ao, verica-se se o pacote faz parte de uma sess ao previamente criada, de acordo com o tipo da mensagem ICMP e com seu campo identier. Caso positivo, o pacote e adicionado ` a sua respectiva sess ao. Caso contr ario, uma nova sess ao e criada e adicionada a lista de sess oes ICMP de informa c ao, e o pacote e associado a esta. J a para a mensagem
2

Para facilitar o entendimento, assume-se que o ICMP e um protocolo da camada de transporte.

84

ICMP de erro, o pacote que a cont em e adicionado a lista de pacotes ICMP de erro, e e associado ao pacote gerador do erro, caso seja poss vel. Na Figura (5.4), as setas tracejadas, saindo do gerente das Sess oes ICMP para o gerente das Sess oes UDP e para o gerente das Sess oes TCP, indicam a associa c ao de pacotes ICMP de erro com pacotes que fazem parte das sess oes UDP ou TCP, e que geraram cada pacote de erro. E a seta para o gerente da arvore de desfragmenta c ao indica a ocorr encia do pacote ICMP de erro time exceeded in fragmentation reassembly - tipo 11, c odigo 1 - cuja fun c ao e relatar que o tempo estipulado pelo host recebendo os fragmentos expirou e o pacote n ao foi remontado. Quando da ocorr encia deste tipo de pacote de erro, o gerente das sess oes ICMP interage com o gerente da arvore de desfragmenta c ao, para localizar o pacote sendo remontado. Caso este seja localizado, e associado ao pacote um atributo dizendo que o tempo de remontagem expirou. O gerente das Sess oes UDP verica se o pacote faz parte de uma sess ao previamente criada, de acordo com as portas de origem e destino, contidas na mensagem UDP. Caso positivo, o pacote e adicionado ` a sua respectiva sess ao. Caso contr ario, uma nova sess ao e criada e adicionada a lista de sess oes UDP, e o pacote e associado a esta. O gerente das Sess oes TCP verica se o pacote faz parte de uma sess ao previamente criada. Esta verica c ao ocorre atrav es da checagem das portas de origem e destino contidas na mensagem TCP e do estado atual da sess ao. Mesmo que o pacote contenha portas de origem e destino que casem com uma sess ao TCP j a criada, o estado desta e vericado, pois esta sess ao j a pode ter sido terminada. Se este pacote pertencer a uma sess ao TCP, cujo estado permita sua associa c ao, este e adicionado ` a respectiva sess ao e o estado desta e atualizado. Caso n ao perten ca a uma sess ao previamente criada, uma nova sess ao TCP e adicionada a lista de sess oes TCP, o pacote e associado a esta nova sess ao e seu estado e atualizado. Existem situa c oes em que pacotes TCP podem caracterizar algum comportamento estranho ou n ao esperado, ou mesmo n ao estar associados a alguma sess ao. Para tratar estas situa c oes foi criado o gerente da arvore de logs das sess oes TCP, que por sua vez, e controlado pelo gerente das Sess oes TCP. Algumas destas situa c oes s ao: pacotes TCP n ao esperados durante o processo de in cio de uma conex ao TCP (three-way handshake), ou pacotes com uma combina c ao de ags n ao esperada, muitas vezes utilizados por sistemas de varredura de redes (scanners). Quando o gerente das sess oes TCP identica um pacote deste g enero, ele aciona o gerente da arvore de logs TCP. Este ent ao atualiza a sua arvore de logs, adicionando o pacote TCP ao n o, identicado pelos IPs de origem e destino obtidos do pacote. Caso este n o n ao exista, ele e criado e o pacote e ent ao adicionado.

85

O resultado da execu c ao de todo o processo descrito anteriormente, para a modelagem das sess oes TCP/IP, e apresentado na Figura (5.5).

prim_sessao_tcp

ult_sessao_tcp

Sesso TCP 1

Sesso TCP 2

Sesso TCP n

prim_sessao_udp

ult_sessao_udp

Bloco de Sesses

IPx IPz

IPz IPx

Sesso UDP 1

Sesso UDP 2

Sesso UDP m

prim_sessao_icmpI Sesso ICMP de info. 1 Sesso ICMP de info. 2

ult_sessao_icmpI

Sesso ICMP de info. k ult_pct_icmpE

prim_pct_icmpE Pacote ICMP de erro 1 Pacote ICMP de erro 2

Pacote ICMP de erro w

FIGURA 5.5 Sess oes TCP/IP associadas a cada par de IPs interconectados. Depois de processado todo o arquivo de dados capturados, tem-se uma arvore bin aria balanceada com todos os IPs do tr afego de rede, onde para cada par de IPs interconectados, seus respectivos n os na arvore ter ao em suas listas de adjac encias um elemento que referencia o outro IP em quest ao. Estes elementos, pertencentes ` as listas de adjac encias dos dois IPs, referenciam um bloco de sess oes TCP/IP comum. Este bloco mant em refer encias para a primeira e para a u ltima sess ao TCP, UDP e ICMP de informa c ao e para o primeiro e u ltimo pacote ICMP de erro, de modo que estas sess oes e pacotes s ao elementos de listas duplamente encadeadas. Justica-se a utiliza c ao de listas duplamente encadeadas na representa c ao das sess oes e pacotes, por facilitar a localiza c ao de elementos que a comp oem, pois neste tipo de estrutura e permitido caminhar tanto para frente quanto para tr as, de acordo com a necessidade. A pr oxima se c ao (5.3) apresenta, de forma detalhada, a implementa c ao do RECON Sistema de Reconstru c ao de Sess oes TCP/IP, baseado na modelagem aqui descrita. 5.3 DO SISTEMA DE RECONSTRUC DE SESA IMPLEMENTAC AO AO SOES

Nesta se c ao s ao descritos os recursos utilizados no desenvolvimento do RECON - Sistema de Reconstru c ao de Sess oes TCP/IP, e apresentada a vis ao geral do sistema e s ao descritos, de forma detalhada, os m odulos funcionais que o comp oem. 86

5.3.1

Recursos Utilizados no Desenvolvimento do Sistema

O desenvolvimento das rotinas do RECON - Sistema de Reconstru c ao de sess oes TCP/IP foi realizado em linguagem C ANSI (Kernighan e Ritchie, 1990) e estas foram compiladas com o compilador GNU C (gcc)3 . O sistema foi compilado e executado nos sistemas operacionais Linux, FreeBSD e OpenBSD, para a plataforma UNIX. O equipamento utilizado para a implanta c ao do RECON trata-se de um PC, com processador Pentium III de 550MHz, 256Mb de mem oria RAM, aproximadamente 40Gb de capacidade em disco r gido, e interface de rede Ethernet 100/10 Mbits/s. O sistema FreeBSD foi utilizado neste equipamento, onde algumas medidas de seguran ca foram tomadas com o intuito de minimizar a possibilidade de ataques. O kernel do sistema operacional foi recompilado, de modo que funcionalidades desnecess arias foram removidas. Servi cos potencialmente inseguros ou desnecess arios tamb em foram exclu dos. Al em disso, um Firewall (ltro de pacotes) foi instalado neste equipamento, permitindo apenas o acesso explicitamente autorizado. Este equipamento trabalha como esta c ao de an alise de dados e recebe, periodicamente, arquivos contendo o tr afego de rede, coletados pelo componente sensor do sistema de detec c ao de intrus oes SHADOW. Estes arquivos s ao armazenados em disco e s ao posteriormente utilizados como entrada de dados para o RECON. 5.3.2 Vis ao Geral do Sistema

O RECON foi subdividido em m odulos funcionais, que executam uma s erie de procedimentos, cujo objetivo e reconstruir as sess oes TCP/IP contidas em um tr afego de rede. A Figura (5.6) apresenta a vis ao geral da implementa c ao do sistema, e uma breve descri c ao dos procedimentos executados por cada um de seus m odulos e apresentada posteriormente. No momento em que o RECON e executado, os seguintes procedimentos s ao realizados: a) S ao inicializados os contadores e as vari aveis globais do sistema. Estes contadores s ao utilizados posteriormente, na apresenta c ao de estat sticas relacionadas ao tr afego de rede analisado; b) Obt em-se o arquivo de congura c ao do RECON, que e ent ao passado para o parser. Este tem como fun c ao extrair valores do arquivo e armazen a-los em vari aveis que ser ao utilizadas no decorrer da execu c ao do sistema.
3

P agina Web em http://www.gnu.org/software/gcc/gcc.html.

87

c) O sistema permite a utiliza c ao de v arios argumentos. Dentre eles, um argumento indispens avel e o arquivo contendo o tr afego de rede a ser analisado. Nesta etapa, o sistema verica a consist encia destes argumentos, al em de vericar algumas informa co es obtidas do arquivo de congura c ao. d) Nesta etapa, o arquivo contendo o tr afego de rede, armazenado em formato tcpdump, e passado para rotina da biblioteca libpcap, que e respons avel pela extra c ao dos pacotes. Esta rotina, que constitui o leitor do tr afego de rede, executa um la co (loop), passando para o processador de pacote cada pacote do arquivo de dados. Os outros processadores s ao acionados de acordo com o tratamento e caracter sticas de cada pacote lido. Este conjunto de rotinas constitui o n ucleo do sistema de reconstru c ao de sess oes TCP/IP, e e a implementa c ao da modelagem apresentada na se c ao (5.2). e) E nalmente, o gerador de resultados, de acordo com os argumentos passados na execu c ao do RECON e com os par ametros obtidos do arquivo de congura c ao, l e e formata as informa c oes geradas e estruturadas na etapa anterior, e as apresenta para o usu ario.

ENTRADA

Dispositivo de Armazenamento

Arquivo contendo o trfego de rede

RECON
Ncleo do Sistema Inicializao dos contadores globais Arquivo de configurao do RECON Leitor do trfego de rede Processador de pacote Processador IP Desfragmentador IP Gerador de Processador ICMP Verificador de argumentos da linha de comandos e parmetros obtidos do arquivo de configurao Processador TCP Processador UDP Resultados

Parser do arquivo de configurao

SADA

FIGURA 5.6 Vis ao geral da implementa c ao do RECON. 88

Pode-se observar na Figura (5.6) que os m odulos respons aveis pela reconstru c ao das sess oes TCP/IP est ao contidos no sistema RECON. A se c ao 7.1 prop oe uma modica c ao, onde esses m odulos passam a constituir uma biblioteca independente. Esta nova biblioteca poder a ser, ent ao, utilizada por aplica c oes envolvendo detec c ao de intrus oes, ou mesmo aplica c oes de monitoramento de rede. As pr oximas se c oes apresentam, de forma mais aprofundada, a implementa c ao de cada um dos m odulos que comp oem o RECON. 5.3.3 A Inicializa c ao dos Contadores Globais

Este m odulo e respons avel por inicializar as vari aveis globais, que t em como nalidade armazenar a contagem e a ocorr encia de certas caracter sticas dos pacotes que comp oem o tr afego de rede analisado. Todos os contadores globais, denidos no sistema RECON, bem como suas descri c oes, s ao apresentados na Tabela (B.1). Alguns dos principais contadores s ao: total de pacotes lidos; endere cos IP distintos; conex oes distintas entre pares de endere cos IP; datagramas IP com o conte udo truncado; datagramas IP cujos cabe calhos cont em op c oes; datagramas IP fragmentados; Mensagens ICMP desconhecidas ou reservadas; Mensagens ICMP do tipo fragment reassembly time exceeded; Mensagens ICMP, UDP e TCP inseridas nas estruturas de reconstru c ao de sess oes; Mensagens ICMP de informa c ao, do tipo request e do tipo reply, inseridas nas estruturas de reconstru c ao de sess oes; Mensagens ICMP de erro inseridas nas estruturas de reconstru c ao de sess oes; Mensagens TCP com o cabe calho corrompido; Mensagens TCP cujos cabe calhos cont em op c oes, e Mensagens TCP inseridas na arvore de logs TCP. Al em dos contadores, este m odulo inicializa tamb em vari aveis, que s ao apontadores (ou ponteiros) para as arvores bin arias balanceadas de IPs, de desfragmenta ca o e de logs TCP. Estas vari aveis apontam, inicialmente, para NULL e s ao atualizadas posteriormente pelos m odulos processadores e desfragmentador. 5.3.4 O Parser do Arquivo de Congura c ao

O m odulo respons avel por realizar o parsing do arquivo de congura c ao do RECON e implementado pela fun c ao parse congle, e tem o seguinte formato: int parse congle(char le name) le name e um apontador para um buer, que cont em o caminho e o nome do arquivo de congura c ao. Este arquivo pode ser especicado atrav es de um argumento do execut avel do sistema RECON. Caso n ao seja especicado, o sistema adota o arquivo

89

/etc/local/recon.conf como padr ao. Inicialmente, a rotina parse congle checa se o arquivo de congura c ao existe, e caso n ao exista, termina a execu c ao do sistema, retornando o respectivo erro. Caso exista, este arquivo e aberto no modo leitura e o processo de parsing e iniciado. A se c ao B.2 apresenta um exemplo deste arquivo, contendo uma s erie de par ametros de congura c ao. A grande maioria dos par ametros apresentados s ao utilizados na sele c ao, formata c ao e apresenta c ao dos resultados gerados pelo sistema, e ser ao discutidos posteriormente. Alguns destes par ametros s ao apresentados e descritos como se segue: DATA DIR: especica o diret orio, onde os arquivos contendo o tr afego de rede est ao armazenados; TEMP DIR: especica o diret orio a ser utilizado pelo RECON como area de armazenamento tempor ario; OUTPUT DIR: especica o diret orio onde os resultados gerados ser ao armazenados (depende de um argumento na linha de comandos); NETWORK: especica o endere co de rede, correspondente ` a rede monitorada; NETMASK: especica a m ascara de rede, correspondente ` a rede monitorada. Depois de abrir o arquivo, o parser realiza um conjunto de procedimentos. Inicia-se um la co (loop), que l e cada linha do arquivo de congura c ao. Um n umero xo de bytes (atualmente 1024 bytes) da linha e copiado para um buer. Portanto, os bytes de uma linha que exceda este valor s ao descartados. Se a linha for um coment ario (iniciada pelo caracter #), esta e descartada. Caso contr ario, espa cos e coment arios que n ao iniciam a linha s ao removidos. Ent ao, o parser busca pelo separador =. Este e utilizado para separar cada par ametro, no arquivo de congura c ao, de seu respectivo valor. Uma vez estabelecida a separa c ao, o par ametro e copiado para um buer e o valor para outro, sendo que estes buers tamb em t em tamanho limitado. O parser verica, ent ao, se o par ametro no buer confere com algum na lista de par ametros conhecidos. Caso positivo, o buer contendo o valor e checado. Cada par ametro conhecido pelo parser tem um valor m aximo permitido. Se o valor obtido do arquivo exceder o valor permitido, um erro e retornado. Caso o valor esteja dentro dos limites pr e-estabelecidos, este e armazenado em uma vari avel do sistema, para posterior utiliza c ao. 90

5.3.5

O Vericador de Argumentos e Par ametros Obtidos do Arquivo de Congura c ao

Este m odulo, respons avel por vericar os argumentos da linha de comandos do RECON e o valor dos par ametros obtidos do arquivo de congura c ao, e implementado pela fun c ao check cong and arg values, e tem o seguinte formato: int check cong and arg values(void) O retorno da fun c ao igual a 0 (zero) indica que algum erro ocorreu. Ent ao, todos os erros identicados s ao mostrados e a execu c ao do RECON e terminada. A verica c ao inicia-se com a checagem do conte udo das vari aveis atualizadas pelo m odulo de parsing (se c ao 5.3.4). Apesar de checar o tamanho e os valores a serem armazenados nas vari aveis, o parser n ao trata de sua consist encia. Alguns conte udos de vari aveis, checados para o arquivo de congura c ao, s ao: exist encia do diret orio, onde est ao os arquivos contendo o tr afego de rede; exist encia do diret orio, onde est ao armazenados os resultados; exist encia do diret orio tempor ario; formato dos endere cos de rede e m ascara de rede. Al em disso, esta rotina verica os argumentos passados na linha de comandos, quando da execu c ao do RECON. Existem argumentos que s ao exclusivos, ou seja, n ao devem ocorrer simultaneamente. Outros dependem de valores e outros s ao obrigat orios. A execu c ao do RECON sem argumentos, gera uma linha, como a apresentada na Figura (5.7)4 abaixo, que apresenta todos os argumentos v alidos. Aqueles delimitados pelos caracteres < e > s ao obrigat orios, os delimitados por [ e ] s ao opcionais, e argumentos divididos por | s ao exclusivos.

Usage: recon [AaFfhIiLlOSTtUuv] [c config_file] [C pkts] <r dump_file | d yyyymmddhh:yyyymmddhh> [ R filter_file | expression ]

FIGURA 5.7 Linha gerada na execu c ao do RECON sem argumentos. As fun c oes de alguns dos argumentos da linha de comandos s ao: mostrar todas as sess oes reconstru das; mostrar as sess oes TCP ou UDP ou ICMP; mostrar pacotes ICMP de erro;
4

A linha foi quebrada para facilitar a legibilidade.

91

apresentar o logs TCP; ler n pacotes do arquivo contendo o tr afego de rede; ltrar o arquivo contendo o tr afego de rede, atrav es de uma express ao ou arquivo de ltragem; apresentar a tabela de desfragmenta c ao; ativar o modo verbose, dentre outras. Uma listagem descritiva dos argumentos, como ilustrada na se c ao B.3, e apresentada quando o RECON e executado com o argumento -h. 5.3.6 O Leitor do Tr afego de Rede

O leitor do tr afego de rede utiliza algumas rotinas implementadas pela biblioteca libpcap (se c ao 3.2), que permitem ler de um arquivo de dados previamente armazenado, as informa c oes de cada pacote capturado. Al em disso, permitem ltrar o arquivo, de modo que apenas o tr afego desejado seja lido. As descri c oes das fun c oes utilizadas foram obtidas das p aginas de manual (man pages) da biblioteca e de Carstens (2002). pcap t pcap open oine(char fname, char ebuf ) Esta fun c ao e utilizada para abrir um arquivo previamente armazenado, que contenha o tr afego de rede capturado, no modo de leitura. fname especica o nome do arquivo a ser aberto. Caso o nome - seja utilizado, especica que os dados ser ao obtidos da entrada padr ao (stdin). ebuf e usado para retornar um texto de erro, caso a fun c ao falhe e retorne NULL. int pcap compile(pcap t p, struct bpf program fp, char str, int optimize, bpf u int32 netmask) Esta fun c ao e utilizada para compilar a string str em um c odigo de ltragem, que pode ser entendido pela biblioteca. p e o ponteiro para o descritor da sess ao de leitura dos dados. program e o ponteiro para uma estrutura do tipo bpf program, que e preenchida pela pr opria fun c ao com a vers ao compilada do ltro. optimize informa para a fun c ao se a otimiza c ao do c odigo de ltragem deve ser realizada. netmask especica a m ascara da rede local. int pcap setlter(pcap t p, struct bpf program fp) Esta fun c ao e utilizada para aplicar um c odigo de ltragem a uma sess ao de leitura de dados. p e o ponteiro para o descritor da sess ao de leitura dos dados. fp e o ponteiro para a estrutura do tipo bpf program, que cont em a vers ao compilada do c odigo de ltragem, e e resultado da chamada para a fun c ao pcap compile. int pcap loop(pcap t p, int cnt, pcap handler callback, u char user) Esta fun c ao e utilizada para, efetivamente, ler os pacotes capturados. p e o ponteiro para o descritor da sess ao de leitura dos dados. cnt especica o 92

n umero de pacotes a serem lidos. Caso cnt seja negativo, todos os pacotes s ao lidos, exceto se um erro ocorrer. callback especica a fun c ao de retorno, que ser a respons avel pelo tratamento de cada pacote lido. user e utilizada para passar argumentos adicionais para a fun c ao de retorno callback. void pcap close(pcap t p) Esta fun c ao e respons avel por fechar os arquivos associados ao descritor da sess ao de leitura dos dados p e liberar os recursos alocados. As estruturas pcap t, pcap handler e bpf program s ao internas ` a biblioteca libpcap e n ao ser ao discutidas neste trabalho. O valor 0 (zero) e atribu do ao argumento netmask da fun c ao pcap compile, pois o RECON utiliza, como entrada de dados, arquivos contendo o tr afego de rede previamente coletado. Este argumento deve conter o valor real da m ascara da rede monitorada, apenas no momento em que os dados est ao sendo capturados. A deni c ao da fun c ao de retorno (callback function), utilizada como par ametro da rotina pcap loop e que e respons avel pelo tratamento de cada pacote, possui alguns argumentos que devem ser respeitados, pois a biblioteca libpcap preenche estes argumentos com informa c oes referentes a cada pacote sendo lido. A descri c ao desta fun c ao, aqui intitulada Processador de Pacote, e apresentada na pr oxima se c ao (5.3.7). 5.3.7 O Processador de Pacote

A rotina packet proc corresponde ` a fun ca o de retorno, passada como argumento para a fun c ao de leitura de pacotes da biblioteca libpcap, descrita na se c ao anterior. Esta ea implementa c ao do processador de pacote e seu formato e apresentado como se segue: void packet proc(u char user, const struct pcap pkthdr h, const u char p) user e o ponteiro para uma string contendo argumentos adicionais, que podem ser passados da rotina de obten c ao de pacotes para a fun c ao de retorno. Neste trabalho, este ponteiro e desconsiderado. h e o ponteiro para a estrutura do tipo pcap pkthdr. Esta estrutura e adicionada pela biblioteca de captura de pacotes ` a sequ encia de bytes capturados para cada pacote. p e o ponteiro para o in cio da cadeia de bytes que representa o pacote. A Figura (5.8) apresenta a estrutura pcap pkthdr, que e constitu da pelos seguintes campos: timestamp, que cont em o hor ario de captura do pacote; caplen, que cont em a quantidade de bytes capturados para o pacote, e len, que cont em o tamanho efetivo do pacote. A fun c ao packet proc mant em dois apontadores, um para o in cio e outro para o nal 93

da sequ encia de bytes do pacote. O primeiro, packetp, e igual ao ponteiro p, par ametro da pr opria fun c ao. E o segundo, snapend, e igual ao ponteiro p somado com caplen.

struct pcap_pkthdr { struct timeval ts; bpf_u_int32 caplen; bpf_u_int32 len; };

FIGURA 5.8 Estrutura adicionada pela biblioteca libpcap a cada pacote. Os seguintes procedimentos s ao, ent ao, executados: declarado o ponteiro ep, como apontador para estrutura ether header. Esta a) E estrutura e denida pelo sistema operacional, e cont em os campos do cabe calho Ethernet; b) S ao armazenados em tr es vari aveis, cur pkt tv, caplen e length, o hor ario de captura, a quantidade de bytes capturados e o tamanho efetivo do pacote, obtidos da estrutura pcap pkthdr; c) A quantidade de bytes capturados para o pacote e comparada com o tamanho do cabe calho Ethernet. Se a quantidade for menor que o cabe calho, a fun c ao termina e retorna o controle para o leitor do tr afego de rede; d) Se n ao for, as vari aveis caplen e length s ao decrementadas do tamanho do cabe calho Ethernet; e) O ponteiro ep e inicializado, atribuindo-se p a ep, atrav es de um casting de tipos. Isto permite acessar os campos do cabe calho Ethernet; f) O ponteiro p e incrementado do tamanho da estrutura ether header, passando a apontar para o in cio do datagrama contido no frame Ethernet; g) O cabe calho Ethernet possui um campo que informa qual e o tipo de datagrama que ele est a encapsulando. Este campo e checado e, se o datagrama for IP, a rotina que implementa o processador IP e executada, recebendo como par ametros as vari aveis p, length e caplen. Caso contr ario, a fun c ao termina e retorna o controle para o leitor do tr afego de rede. 5.3.8 O Processador IP

A fun c ao ip proc corresponde ` a implementa c ao do processador IP, e seu formato e apresentado como se segue: 94

void ip proc(const u char bp, const u int length, u int cap len) A rotina de processamento do pacote, discutida na se c ao anterior, preenche os par ametros da fun c ao ip proc, de modo que bp aponta para o in cio do datagrama IP, length cont em o tamanho efetivo do pacote e cap len cont em a quantidade de bytes capturados para o pacote, decrementada do tamanho do cabe calho Ethernet. S ao declarados quatro ponteiros - ip, icmp, udp e tcp - que apontam para as estruturas ip, icmp, udphdr e tcphdr, respectivamente. Estas estruturas s ao denidas pelo sistema operacional. Ent ao, o apontador ip e inicializado, atribuindo-se bp (argumento da fun c ao es de um casting de tipos. Isto permite acessar os campos do cabe calho ip proc ) a ip, atrav IP. Inicia-se uma s erie de checagens acerca do tamanho do datagrama IP. Caso a quantidade de bytes, informada pelo par ametro cap len, seja menor que o tamanho do cabe calho IP, a fun c ao termina e retorna o controle para o leitor do tr afego de rede. O ponteiro cp, do tipo u char, e declarado e inicializado, atribuindo-se ip a cp, atrav es de um casting de tipos. Este novo ponteiro e incrementado do tamanho do cabe calho IP. Para isto, e utilizado o campo header length da estrutura apontada por ip. As vari aveis cap len, que e decrementada do tamanho do cabe calho IP, e snapend, que aponta para o m da sequ encia de bytes capturados para o pacote, ser ao utilizadas nas pr oximas verica c oes. Checa-se, ent ao, se o campo oset, obtido da estrutura apontada por ip, e igual a 0 (zero). Esta caracter stica indica que o cabe calho da camada de transporte (ICMP, UDP ou TCP) deve estar presente no datagrama. Caso positivo, verica-se o campo protocol. Se este apresenta um protocolo diferente do ICMP, UDP ou TCP, a fun c ao termina e retorna o controle para o leitor do tr afego de rede. Para as outras possibilidades o seguinte teste e realizado: caso cp + 1 for maior que snapend, ou, de acordo com o campo protocol, cap len for menor que o tamanho do cabe calho ICMP ou UDP ou TCP, a fun c ao termina e retorna o controle para o leitor do tr afego de rede. O pr oximo passo e vericar se o datagrama IP e um fragmento. Para isto, s ao utilizados o bit MF (more fragments) e o campo oset da estrutura apontada por ip. Caso o datagrama seja um fragmento, dois casos podem ocorrer: o bit MF est a ativo; ou o bit MF est a desativado, mas o campo oset e diferente de 0 (zero). Ent ao, e chamada a rotina implementada pelo desfragmentador IP, passando para esta

95

os devidos par ametros. Os detalhes de sua implementa c ao s ao apresentados na pr oxima se c ao (5.3.9). Quando a execu c ao desta rotina termina, verica-se se o datagrama est a no estado REMONTADO. Caso positivo, os ponteiros cp e ip s ao atualizados, atrav es do n o ` contendo o pacote remontado na arvore de desfragmenta c ao. A partir da , o tratamento e semelhante para um datagrama normal ou remontado. Obt em-se os endere cos IP de origem e destino, contidos na estrutura apontada por ip, de modo que estes dois endere cos s ao inseridos na arvore de IPs, caso ainda n ao existam. A Figura (5.9a) apresenta a estrutura de cada n o desta arvore. ip addr armazena o endere co IP. f adjl elem e l adjl elem s ao apontadores para o in cio e m da lista de adjac encias do n o. adjl elem count armazena o n umero de elementos na lista de adjac encias. left e right apontam para as sub- arvores esquerda e direita. E balance e utilizado no balanceamento da arvore bin aria de IPs. Para o n o que cont em o endere co IP de origem, verica-se se sua lista de adjac encias cont em o elemento correspondente ao endere co IP de destino. Caso n ao exista, este elemento e inserido. O mesmo e feito para o n o que cont em o endere co IP de destino. A Figura (5.9b) apresenta a estrutura de cada elemento da lista de adjac encias. t node aponta para o n o relacionado na arvore bin aria de IPs. session aponta para o bloco de sess oes TCP/IP associado. E next aponta para o pr oximo elemento da lista de adjac encias. importante ressaltar que o par <n E o, elemento da lista de adjac encias do n o> identica a comunica c ao entre dois IPs e a estes dois est a associado um bloco de sess oes TCP/IP. O bloco e criado e o ponteiro session, dos elementos nas listas de adjac encias em quest ao, passam a apontar para este. A Figura (5.9c) apresenta a estrutura do bloco de sess oes TCP/IP.

struct avlnode { u_int32_t ip_addr; struct adj_list_elem *f_adjl_elem; struct adj_list_elem *l_adjl_elem; u_int32_t adjl_elem_count; struct avlnode *left; struct avlnode *right; char balance; }; a

struct adj_list_elem { struct avlnode *t_node; struct tcpip_session *session; struct adj_list_elem *next; };

struct tcpip_session { struct tcp_sessions *f_tcp_session; struct tcp_sessions *l_tcp_session; struct udp_sessions *f_udp_session; struct udp_sessions *l_udp_session; struct icmp_Isessions *f_icmp_Isession; struct icmp_Isessions *l_icmp_Isession; struct icmp_Epkt *f_icmp_Epkt; struct icmp_Epkt *l_icmp_Epkt; u_int8_t clear; }; c

FIGURA 5.9 Estruturas de armazenamento da arvore bin aria de IPs, lista de adjac encias e bloco de sess oes TCP/IP. Os campos desta estrutura s ao apontadores para o in cio e m das sess oes TCP, UDP, 96

ICMP de informa c ao e para o in cio e m dos pacotes ICMP de erro. clear e utilizado apenas no momento em que esta estrutura e desalocada. O pr oximo passo na execu c ao processador IP e estipular um c odigo para a dire c ao do pacote. Esta informa c ao e de suma import ancia, pois toda a implementa c ao RECON baseia-se na utiliza c ao de arvores bin arias e, apesar dos IPs estarem relacionados por listas de adjac encias, n ao h a informa c ao sobre a dire c ao da comunica c ao. Como cada endere co IP e representado univocamente por um n umero inteiro de 4 bytes, a seguinte codica c ao e apresentada na Tabela (5.1). TABELA 5.1: Codica c ao da dire c ao do pacote Compara c ao Endere co IP de origem < Endere co IP de destino Endere co IP de origem > Endere co IP de destino C odigo da Dire c ao 0 1

Depois de estipulado o c odigo para a dire c ao do pacote, o pr oximo passo e acionar o processador da mensagem na camada de transporte, de acordo com o conte udo do campo protocol, obtido da estrutura apontada por ip. Tr es casos podem ocorrer, de modo que os seguintes procedimentos s ao realizados, de acordo com identica c ao do protocolo, contida neste campo: ICMP: inicializa-se o ponteiro icmp, atribuindo cp a icmp. Se o campo type, obtido da estrutura apontada por icmp, indicar que a mensagem e de informac ao, a rotina que implementa o Processador ICMP para sess oes de informa c ao e executada com os devidos par ametros. O mesmo acontece caso type indique que a mensagem e de erro, s o que, nesse caso, a rotina que implementa o Processador ICMP para pacotes de erro e executada; UDP: inicializa-se o ponteiro udp, atribuindo cp a udp. A rotina que implementa o processador UDP e executada com os devidos par ametros; TCP: inicializa-se o ponteiro tcp, atribuindo cp a tcp. A rotina que implementa o processador TCP e executada com os devidos par ametros. Apesar de n ao ser manipulada pela fun c ao ip proc, faz-se necess ario apresentar a estrutura de armazenamento dos dados obtidos do datagrama IP, pois esta ser a utilizada pelos processadores ICMP, UDP e TCP, descritos nas pr oximas se c oes. Esta estrutura e ilustrada na Figura (5.10). 97

struct mod_ip { u_int8_t dir:1; u_int8_t status:3; u_int8_t hdr_len:4; u_int16_t len; u_int16_t id; u_int8_t ttl; };

Possveis valores para o campo status PACKET_STATUS_OK PACKET_STATUS_RETRANSMISSION PACKET_STATUS_UNREACHABLE PACKET_STATUS_MISSED

FIGURA 5.10 Estrutura de armazenamento dos dados obtidos do datagrama IP. Os campos hdr len, len, id e ttl s ao an alogos aos campos no cabe calho IP, como visto na se c ao 2.3. dir armazena o c odigo da dire c ao do pacote, como descrito anteriormente. O campo status pode assumir os valores apresentados na Figura (5.10). No momento em que esta estrutura e criada e os dados do datagrama s ao armazenados, o campo status recebe o valor PACKET STATUS OK. Os demais valores ser ao discutidos posteriormente. 5.3.9 O Desfragmentador IP

A fun c ao frag avl insert corresponde ` a implementa c ao do desfragmentador IP, e seu formato e apresentado como se segue: char frag avl insert(struct frag node node, struct frag node ret node, struct frag elem ret f elem, struct ip ip, u int32 t ip src, u int32 t ip dst, u char message, u int caplen) Quando a rotina de processamento do datagrama IP, discutida na se c ao anterior, verica que o datagrama e um fragmento, esta faz a chamada para a fun c ao frag avl insert, preenchendo seus par ametros. node e a refer encia do apontador para o n o raiz da arvore de desfragmenta c ao. ret node armazena a refer encia do apontador do n o atual. ret f elem armazena a refer encia para o apontador do elemento atual, na lista encadeada de elementos de fragmenta c ao do n o. ip e o apontador para a estrutura contendo o cabe calho IP. ip src e ip dst s ao os endere cos IP de origem e destino do pacote. message e o apontador para a sequ encia de bytes do pacote ` a partir do cabe calho IP. E caplen cont em o tamanho da sequ encia de bytes do pacote, decrementado do tamanho do cabe calho Ethernet e do cabe calho IP. As informa c oes do datagrama fragmentado, obtidas da estrutura apontada por ip, s ao inseridas na arvore de desfragmenta c ao e divididas nas estruturas que a comp oem. Os endere cos IP de origem e destino s ao utilizados como identicadores do n o. Cada n o na arvore cont em uma lista encadeada de elementos de fragmenta c ao. Os campos identication

98

e protocol s ao utilizados como identicadores de cada elemento. E cada elemento da lista de desfragmenta c ao cont em uma lista encadeada de fragmentos contendo oset e length de cada fragmento. Suponha que o IP X envie um pacote ICMP para o IP Y, e que este pacote tenha o campo identication do cabe calho IP igual a 1000. Suponha tamb em que este pacote tenha sido dividido em tr es fragmentos. Sabe-se que os tr es fragmentos ter ao, em seus cabe calhos IP, os campos identication e protocol semelhantes. Ent ao, o desfragmentador IP, ao processar estes fragmentos, realizar a os seguintes procedimentos: criar a um n o na arvore de desfragmenta c ao, identicado pelo par de IPs <X,Y>; este n o ter a, em sua lista de elementos de desfragmenta c ao, um elemento identicado pelo par <1000,ICMP>, correspondente aos campos identication e protocol do cabe calho IP; e este elemento ter a uma outra lista, contendo tr es elementos, onde cada um destes ter a o oset e o length de um fragmento. A Figura (5.11) apresenta, de forma simplicada, o esquema de armazenamento de datagramas IP fragmentados na arvore de desfragmenta c ao.

frag_root

Fa
Src IP Dst IP

first_f_elem frag_elem 1 frag_elem 2 frag_elem x

last_f_elem

frag_elem n

Fb Fd Fe Ff

Fc Fg

frag_elem. x struct frag_elem last_frag

first_frag frag_offlen 1 frag_offlen 2

frag_offlen m

FIGURA 5.11 Esquema de armazenamento dos fragmentos IP. Esta abordagem permite que os dados dos fragmentos sejam armazenados, sem que informa c oes comuns dos fragmentos de um dado pacote sejam replicadas, reduzindo assim a quantidade de recursos alocados para seu armazenamento. A Figura (5.12) apresenta, de forma completa, as estruturas correspondentes ao n o da arvore de desfragmenta c ao (a), ao elemento de desfragmenta c ao (b) e ao elemento contendo o oset e length de um fragmento (c).

99

struct frag_node { u_int32_t ip_src, ip_dst; struct frag_elem *first_f_elem; struct frag_elem *last_f_elem; struct frag_node *left; struct frag_node *right; char balance; };

struct frag_elem { struct timeval ftv; u_int8_t mode:1; u_int8_t first_rcvd:1; u_int8_t last_rcvd:1; u_int8_t state:2; u_int8_t attributes:3; u_int16_t frag_count; int32_t hole_count; u_int8_t ip_proto; u_int16_t ip_id; u_int32_t ip_length; struct ip *ips; u_char *m_data; u_int8_t m_data_len; void *session; void *packet; struct frag_off_len *first_frag; struct frag_off_len *last_frag; struct frag_elem *next; struct frag_elem *prev; }; b

struct frag_off_len { u_int16_t offset; u_int16_t len; struct frag_off_len *next; struct frag_off_len *prev; };

FIGURA 5.12 Estruturas de armazenamento dos fragmentos IP. Na estrutura frag node, correspondente a cada n o da arvore de desfragmenta c ao, os campos ip src e ip dst armazenam os endere cos IP de origem e destino do pacote fragmentado, e s ao utilizados na identica c ao do n o. rst f elem e last f elem s ao apontadores para o in cio e m da lista encadeada de elementos de fragmenta c ao. left e right s ao apontadores para as sub- arvores esquerda e direta do n o. E balance e utilizado no balanceamento da arvore bin aria de desfragmenta c ao. c ao de Na estrutura frag elem, correspondente a cada elemento da lista de desfragmenta um dado n o da arvore, ftv cont em o hor ario de captura do primeiro fragmento. mode n ao e utilizado e est a reservado para futuras extens oes. rst rcvd e last rcvd indicam se o primeiro e u ltimo fragmentos j a foram recebidos. state cont em o estado do pacote sendo desfragmentado. attributes cont em os atributos do pacote sendo desfragmentado. frag count armazena o n umero de fragmentos recebidos. hole count conta o n umero de espa cos entre fragmentos. ip proto armazena o protocolo encapsulado no datagrama fragmentado. ip id armazena o campo identication do cabe calho IP. ip length cont em o tamanho total do datagrama IP desfragmentado. ips e um ponteiro para o cabe calho IP do primeiro fragmento. m data aponta para sequ encia de bytes capturados para o primeiro fragmento, a partir do cabe ` calho IP. m data len armazena a quantidade de bytes na area apontada por m data. session e o apontador para a sess ao onde o datagrama remontado foi inserido. packet e o apontador para o pacote remontado, j a inserido em uma sess ao. rst frag e last frag s ao apontadores para o in cio e m da lista encadeada de osets e lengths de cada fragmento. E next e prev s ao apontadores para o pr oximo elemento de fragmenta c ao e para o anterior. Na estrutura frag o len, correspondente a cada fragmento da lista de fragmentos de um

100

dado elemento de desfragmenta c ao, oset armazena o campo oset do cabe calho IP do fragmento. len armazena o tamanho total do fragmento IP, decrementado do tamanho do cabe calho IP. E prev e next s ao apontadores para o pr oximo elemento da lista encadeada de osets e lengths e para o anterior. Existem tr es poss veis estados para um pacote fragmentado, quando seus fragmentos est ao sendo inseridos na arvore de desfragmenta c ao. Estes estados est ao associados a valores que atualizam o campo state da estrutura correspondente ao elemento de desfragmenta c ao do pacote, e s ao descritos como se segue: FRAG REASSEMBLING: este estado e associado ao elemento de desfragmenta c ao, quando da ocorr encia do primeiro fragmento. Neste momento, o elemento de desfragmenta c ao e criado e permanece neste estado enquanto o pacote n ao for completamente remontado; FRAG REASSEMBLED: este estado e associado ao elemento de desfragmenta c ao, quando todos os fragmentos j a foram recebidos e o pacote foi remontado. Indica que mais fragmentos n ao podem ser associados a este elemento de desfragmenta c ao; FRAG TIME EXCEEDED: este estado e associado ao elemento de desfragmenta c ao, quando da ocorr encia de um pacote ICMP do tipo time exceeded in fragmentation reassembly, correspondente ao elemento de desfragmenta c ao. Diz que o tempo de remontagem do pacote expirou e indica que mais fragmentos n ao podem ser associados a este elemento de desfragmenta c ao. Para determinar se um pacote foi totalmente remontado, tr es campos da estrutura correspondente ao elemento de desfragmenta c ao s ao utilizados: rst rcvd, last rcvd e hole count. rst rcvd recebe o valor 1, quando o cabe calho IP de um fragmento cont em oset igual a 0 e o bit MF ativado. last rcvd recebe o valor 1, quando o cabe calho IP de um fragmento cont em oset diferente de 0 e o bit MF desativado. Quando estes dois campos t em valor 1, signica que o primeiro e o u ltimo fragmento j a foram processados. Ent ao basta determinar se os fragmentos intermedi arios tamb em foram. Para isto, e utilizado o campo hole count. Quando o elemento de desfragmenta ca o e criado, o campo hole count recebe o valor -1 e quando o primeiro fragmento, independente de seu oset, e inserido na lista de fragmentos, ` medida que os fragmentos v este campo recebe o valor 0. A ao sendo inseridos na lista de fragmentos, e estes s ao inseridos de forma ordenada, os campos oset e len do fragmento atual s ao checados, de modo que o valor de hole count e atualizado da seguinte forma: 101

 Decremento do campo hole count: oset do fragmento atual e igual ou menor que oset + len do fragmento anterior; ou oset + len do fragmento atual e igual ou maior que oset do pr oximo fragmento; Incremento do campo hole count: oset do fragmento atual e maior que oset + len do fragmento anterior; ou oset + len do fragmento atual e menor que oset do pr oximo fragmento; Para o pacote fragmentado estar completamente remontado, os campos rst rcvd e last rcvd devem ter o valor 1 e o campo hole count deve ter o valor 0, indicando que o primeiro e o u ltimo fragmento foram processados e n ao h a espa cos entre eles. Ent ao, o campo state do elemento de desfragmenta c ao do pacote remontado recebe o valor FRAG REASEMBLED. Quando um pacote remontado e inserido em uma sess ao, seja ela ICMP, UDP, ou TCP, os campos session e packet, da estrutura correspondente ao elemento de desfragmenta c ao do pacote, passam a apontar para a sess ao onde o pacote foi inserido e para o pacote propriamente dito. Estes apontadores ser ao utilizados pelas fun c oes de ajustes de sess oes, implementadas no processador ICMP, a ser visto na pr oxima se c ao (5.3.10). Existem, ainda, alguns atributos que podem ser associados ao campo attributes da estrutura correspondente a um elemento de desfragmenta c ao, para um pacote sendo remontado. Estes atributos indicam a poss vel inten c ao de explorar vulnerabilidades ou fraquezas na implementa c ao da pilha de protocolos TCP/IP, e s ao descritos como se segue: FRAG OVERLAP: indica a sobreposi c ao de fragmentos, ou seja, oset + len de um fragmento e maior que o oset do fragmento consecutivo. Esta t ecnica e muito utilizada na tentativa de iludir sistemas de detec c ao de intrus ao (Ptacek e Newsham, 1998); FRAG TEARDROP: indica que o tamanho do fragmento remontado excedeu o m aximo permitido, que e igual 65535 bytes. Esta t ecnica foi muito utilizada na tentativa de indisponibilizar servi cos e at e mesmo hosts conectados ` a Internet (Northcutt e Novak, 2001) (Northcutt et al., 2001). FRAG MULTI: indica que o tamanho de algum fragmento, com exce c ao do u ltimo, n ao e m ultiplo de 8. Esta t ecnica tamb em foi muito utilizada na tentativa de indisponibilizar servi cos e at e mesmo hosts conectados ` a Internet (Northcutt e Novak, 2001) (Northcutt et al., 2001). A implementa c ao das rotinas que comp oem o desfragmentador IP foram baseadas em Clark (2002), Ziemba et al. (2002) e Miller (2002). 102

5.3.10

O Processador ICMP

O processador ICMP e dividido em duas partes: o processador ICMP de informa c ao e o processador ICMP de erro. As se c oes 5.3.10.1 e 5.3.10.2 discutem as implementa c oes destas partes. 5.3.10.1 Processador ICMP de Informa c ao

A fun c ao icmp Isession proc corresponde ` a implementa c ao do processador ICMP de informa c ao, e seu formato e apresentado como se segue: void icmp Isession proc(struct icmp Isessions f icmp Isession, struct icmp Isessions l icmp Isession, struct ip ip, struct icmp icmp, u int8 t icmp categ, u int8 t pkt dir, u int length) Quando o processador IP verica que o pacote sendo processado cont em uma mensagem ICMP de informa c ao, este executa a chamada da fun c ao icmp Isession proc, preenchendo devidamente seus par ametros. f icmp Isession e l icmp Isession s ao apontadores para o in cio e para o m da lista encadeada de sess oes ICMP de informa c ao, associada aos dois IPs contidos no pacote. ip e o apontador para a estrutura contendo o cabe calho IP do pacote. icmp e o apontador para a estrutura contendo o cabe calho ICMP do pacote. icmp categ cont em a categoria da mensagem ICMP de informa c ao, que pode ser request ou reply. pkt dir cont em o c odigo da dire c ao do pacote, como visto na se c ao 5.3.8. E length cont em o tamanho da mensagem ICMP, calculada pela diferen ca dos campos ip len, que e o tamanho total do datagrama IP, e ip hl, que e o tamanho do cabe calho IP do pacote. As sess oes ICMP de informa c ao t em como identicador o campo identication do cabealho ICMP. Quando ocorre uma mensagem ICMP, onde seu campo identier c e diferente das sess oes ICMP de informa c ao associadas aos dois IPs no pacote em quest ao, ou a lista de sess oes ICMP est a vazia, uma nova sess ao ICMP e criada, e todos os pacotes ICMP de informa c ao com o campo identication semelhante e da mesma categoria s ao inseridos nesta sess ao, compondo assim sua lista encadeada de pacotes. A Figura (5.13) apresenta as estruturas correspondentes a: cada sess ao ICMP de informa c ao (a); cada pacote ICMP, que comp oe a lista encadeada de pacotes para uma dada sess ao (b); e os dados armazenados de cada mensagem ICMP (c).

103

struct icmp_Isessions { u_int8_t type:4; u_int8_t attributes:4; u_int16_t id; int32_t match_reply; struct icmp_Ipkt *first_icmp_Ipkt; struct icmp_Ipkt *last_icmp_Ipkt; struct icmp_Isessions *next; struct icmp_Isessions *prev; }; a

struct icmp_Ipkt { struct timeval ptv; struct mod_ip data_ip; struct mod_Iicmp data_icmp; struct icmp_Ipkt *next; struct icmp_Ipkt *prev; };

struct mod_Iicmp { u_int8_t type; u_int8_t code; u_int16_t seq; };

FIGURA 5.13 Estruturas de armazenamento das sess oes ICMP de informa c ao. Na estrutura icmp Isession, correspondente a cada sess ao ICMP, o campo type armazena o tipo da sess ao, ou seja, se esta e do tipo echo, timestamp, address mask ou information. attributes cont em os atributos associados a ` sess ao. id armazena o campo identication, obtido do cabe calho da mensagem ICMP, e que e utilizado como identicador da sess ao. match reply e o contador da diferen ca no n umero de pacotes de requisi c ao e de resposta, inseridos na sess ao. rst icmp Ipkt e last icmp Ipkt s ao apontadores para o primeiro e para o u ltimo pacote da sess ao. E next e prev s ao apontadores para a pr oxima sess ao e para a anterior. Na estrutura icmp Ipkt, correspondente a cada pacote inserido em uma determinada sess ao ICMP de informa c ao, o campo ptv armazena o hor ario de captura do pacote. data ip e uma estrutura que armazena os dados obtidos do cabe calho IP do pacote, como visto na se c ao 5.3.8. data icmp e uma estrutura que armazena os dados obtidos do cabe calho ICMP. E next e prev s ao apontadores para o pr oximo pacote na sess ao e para o anterior. Na estrutura mod Iicmp, correspondente aos dados da mensagem ICMP de informa c ao armazenados para cada pacote, o campo type cont em o tipo da mensagem ICMP e o campo code cont em o c odigo. O campo seq cont em o sequence number associado ao pacote ICMP de informa c ao. Quando um pacote ICMP de informa c ao constitui uma requisi c ao (request) e este e inserido em uma sess ao, o campo match reply da estrutura correspondente a esta e incrementado de 1. E quando um pacote constitui uma resposta (reply), o campo match reply e decrementado de 1. Ao nal do processamento de todos os pacotes do arquivo contendo o tr afego de rede, tr es situa c oes devem ser consideradas para as sess oes ICMP de informa c ao reconstru das, e dizem respeito ao valor armazenado pelo campo match reply destas sess oes. Na primeira, match reply e igual a 0 (zero). Isto indica que, para todos os pacotes de requisi c ao, houve um pacote de resposta correspondente. Na segunda, match reply e maior que 0. Indica que

104

o n umero de requisi c oes foi maior que o n umero de respostas. E nalmente, na terceira situa c ao, match reply e menor que 0. Indica que o n umero de respostas foi maior que o n umero de requisi c oes. Algumas considera c oes devem ser feitas acerca da u ltima situa c ao apresentada. Se match reply for igual a -1, uma possibilidade e que, na captura do tr afego de rede, um pacote de requisi c ao tenha sido perdido. Mas se este n umero for bem menor que -1, deve-se considerar a possibilidade de ocorr encia de algum comportamento an omalo, que deve ser melhor avaliado. Al em do campo match reply, que apresenta algumas informa c oes sobre o que ocorreu com uma dada sess ao ICMP de informa c ao, existem atributos que podem ser associados a uma sess ao e s ao descritos como se segue: ICMP INFO REPLY FIRST: ocorre em uma sess ao, quando o primeiro pacote ICMP de informa c ao inserido e um pacote de resposta; ICMP INFO NOMATCH REPLY: ocorre quando o processador ICMP n ao consegue associar um pacote de resposta ao respectivo pacote de requisi c ao, dentro de uma mesma sess ao. Para realizar esta associa c ao, o campo sequence number do pacote de resposta deve ser igual ao mesmo campo de algum dos pacotes de requisi c ao na sess ao. 5.3.10.2 Processador ICMP de Erro

A fun c ao icmp Epkt proc corresponde ` a implementa c ao do processador ICMP de erro, e seu formato e apresentado como se segue: void icmp Epkt proc(struct icmp Epkt f icmp Epkt, struct icmp Epkt l icmp Epkt, struct ip ip, struct icmp icmp, u int8 t pkt dir) Quando o processador IP verica que o pacote sendo processado cont em uma mensagem ICMP de erro, este executa a chamada da fun c ao icmp Epkt proc, preenchendo devidamente seus par ametros. f icmp Epkt e l icmp Epkt s ao apontadores para o in cio e m dos pacotes ICMP de erro, associados aos dois IPs contidos no pacote. ip e o apontador para a estrutura que cont em o cabe calho IP do pacote. icmp e o apontador para a estrutura que cont em o cabe calho ICMP do pacote. E pkt dir armazena o c odigo da dire c ao do pacote, como visto na se c ao 5.3.8. Os pacotes ICMP de erro cont em, al em do cabe calho ICMP propriamente dito, o cabe105

calho IP do datagrama que ocasionou o erro, como visto na se c ao 2.4.1. Ent ao, os dados obtidos do cabe calho IP do pacote gerador do erro s ao utilizados em duas situa c oes distintas, de acordo com o tipo da mensagem de erro gerada. Na primeira situa c ao, o pacote ICMP de erro n ao e do tipotime exceeded in fragmentation reassembly. Ent ao, os seguintes procedimentos s ao realizados: a) Insere-se o pacote na lista encadeada de pacotes ICMP de erro, associada aos dois IPs, obtidos do pacote de erro. b) Os campos correspondentes aos endere cos IP de origem e destino do cabe calho IP gerador do erro s ao utilizados para encontrar os n os correspondentes na a rvore bin aria de IPs. Caso algum destes n os n ao seja encontrado, o atributo ICMP ERROR NOMATCH e associado ao pacote de erro e a fun c ao termina. c) Verica-se o campo protocol do cabe calho IP gerador do erro. De acordo com o valor deste campo, a busca do pacote gerador do erro e direcionada para as sess oes ICMP, UDP ou TCP, relacionadas aos n os localizados na arvore bin aria de IPs. d) A busca e iniciada na u ltima sess ao da lista encadeada de sess oes, e e realizada at e a primeira sess ao, atendendo a algumas condi c oes de parada. Estas condi c oes s ao apresentadas nos procedimentos seguintes. e) Para cada sess ao, a lista de pacotes nela inseridos e vericada, partindo do u ltimo pacote. Caso os campos ip hl, ip len e ip id, do cabe calho IP gerador do erro, sejam iguais aos respectivos campos na estrutura que armazena os dados do cabe calho IP do pacote atual, os hor arios de captura s ao checados. f) Se o hor ario do pacote ICMP de erro for menor que o hor ario do pacote atual, a fun c ao termina e o atributo ICMP ERROR NOMATCH e associado ao pacote de erro. Caso contr ario, signica que o pacote gerador do erro foi encontrado. Ent ao, o pacote ICMP de erro, inserido na lista encadeada, e associado ao atributo ICMP ERROR MATCHED, ` a sess ao onde o pacote gerador do erro est a, e ao pacote gerador do erro propriamente dito. Quando um pacote ICMP de erro e associado ao pacote gerador do erro, o campo status, na estrutura que cont em os dados do cabe calho IP do pacote gerador do erro (visto na se c ao 5.3.8), e atualizado. Se o pacote ICMP de erro for do tipo destination unreachable, o campo status recebe o valor PACKET STATUS UNREACHABLE. Caso contr ario, recebe o valor PACKET STATUS MISSED. 106

J a na outra situa c ao, onde o pacote ICMP de erro e do tipo time exceeded in fragmentation reassembly , os seguintes procedimentos s ao realizados: a) Insere-se o pacote na lista encadeada de pacotes ICMP de erro, associada aos dois IPs, obtidos do pacote de erro. Os pr oximos procedimentos interagem com a arvore de desfragmenta c ao, vista na se c ao 5.3.9. b) Busca, na arvore bin aria de desfragmenta c ao, o n o que cont em os endere cos IP de origem e destino iguais aos do cabe calho IP do pacote gerador do erro, contido no pacote ICMP de erro. Caso encontre, busca pelo elemento de desfragmenta c ao correspondente. Caso n ao encontre o n o ou o elemento de desfragmenta c ao, a fun ca o termina. c) Se o elemento de desfragmenta c ao estiver no estado FRAG REASSEMBLING, este e atualizado para FRAG TIME EXCEEDED e a fun c ao termina. d) Se o elemento de desfragmenta c ao estiver no estado FRAG REASSEMBLED, signica que o pacote foi remontado e faz parte de alguma sess ao. Portanto, alguns ajustes devem ser feitos. Para isto, s ao utilizados os apontadores session e packet da estrutura que representa o elemento de desfragmenta c ao. O pacote remontado e, ent ao, removido da sess ao correspondente. O estado e os atributos desta sess ao s ao atualizados quando necess ario e, at e mesmo a sess ao e removida, se for o caso. Finalmente, o estado do elemento de desfragmenta c ao e atualizado para FRAG TIME EXCEEDED. A Figura (5.14) apresenta a estrutura correspondente a cada pacote ICMP de erro (a) e aos dados armazenados para cada um destes pacotes (b).

struct icmp_Epkt { struct timeval ptv; u_int8_t attributes; struct mod_ip data_ip; struct mod_Eicmp data_icmp; struct icmp_Epkt *next; struct icmp_Epkt *prev; }; a

struct mod_Eicmp { u_int8_t type; u_int8_t code; struct avlnode *src_node; struct avlnode *dst_node; u_int8_t proto; void *session; void *packet; }; b

FIGURA 5.14 Estruturas de armazenamento das sess oes ICMP de erro. Na estrutura icmp Epkt, correspondente a cada pacote inserido na lista encadeada de pacotes ICMP de erro, o campo ptv armazena o hor ario de captura do pacote. attributes 107

cont em os atributos associados ao pacote de erro. data ip e uma estrutura que armazena os dados obtidos do cabe calho IP do pacote, como visto na se c ao 5.3.8. data icmp e uma estrutura que armazena os dados obtidos do cabe calho ICMP e refer encias para o pacote gerador do erro. E next e prev s ao apontadores para o pr oximo pacote na lista de pacotes de erro e para o anterior. Na estrutura mod Eicmp, correspondente aos dados da mensagem ICMP de erro armazenados para cada pacote, o campo type cont em o tipo da mensagem ICMP e o campo code cont em o c odigo. src node e dst node s ao apontadores para os n os da arvore bin aria de IPs, correspondentes aos IPs de origem e destino do pacote gerador do erro. proto cont em o protocolo utilizado pelo pacote gerador do erro, e pode ser ICMP, UDP ou TCP. session e o apontador para a sess ao onde o pacote gerador do erro foi inserido. E packet e o apontador para o pacote gerador do erro propriamente dito. 5.3.11 O Processador UDP

A fun c ao udp session proc corresponde ` a implementa c ao do processador UDP, e seu formato e apresentado como se segue: void udp session proc(struct udp sessions f udp session, struct udp sessions l udp session, u char up, struct ip ip, struct udphdr udp, u int8 t pkt dir, u int caplen, u int length) Quando o processador IP verica que o pacote sendo processado cont em uma mensagem UDP, este executa a chamada da fun c ao udp session proc, preenchendo devidamente seus par ametros. f udp session e l udp session apontam, respectivamente, para o in cio e m das sess oes UDP, associadas aos dois IPs contidos no pacote sendo processado. up aponta para o byte de in cio do cabe calho UDP, na sequ encia de bytes capturados para o pacote. ip eo apontador para a estrutura contendo o cabe calho IP. udp e o apontador para a estrutura contendo o cabe calho UDP. pkt dir cont em o c odigo da dire c ao do pacote. caplen cont em a quantidade de bytes do pacote, a partir do in cio do cabe calho UDP. E length cont em o tamanho total do datagrama IP, que cont em a mensagem UDP, decrementado do tamanho do cabe calho IP. Uma sess ao UDP tem como identicadores as duas portas contidas nas mensagens UDP dos pacotes que a comp oem. Utiliza-se o par <portA,portB> para identicar a sess ao, onde a primeira est a associada ao menor endere co IP dos pacotes, e a segunda est a associada ao maior endere co IP. Observe que n ao h a a preocupa c ao com a id eia de porta

108

de origem e destino, pois existe a codica c ao da dire c ao do pacote, como visto na se c ao 5.3.8. Quando um pacote UDP e processado, a lista encadeada de sess oes UDP, associada aos dois endere cos IP do pacote, e vericada. Caso exista uma sess ao, identicada pelo mesmo par de portas contido no pacote sendo processado, este pacote e inserido na lista encadeada de pacotes desta sess ao. Caso contr ario, uma nova sess ao e criada e o pacote e ent ao inserido em sua lista de pacotes. O processador UDP prop oe e implementa duas extens oes para o tratamento das aplica c oes de DNS (Mockapetris, 2002b) e NTP (Mills, 2002c) (Mills, 2002b) (Mills, 2002c). Sabe-se que estas aplica c oes baseiam-se em requisi c oes e respostas, mas para identicar se um pacote DNS ou NTP e uma requisi c ao ou uma resposta, e preciso avaliar o conte udo da mensagem UDP. Para o DNS, o primeiro byte do conte udo da mensagem UDP cont em o identicador da requisi c ao/resposta, e o primeiro bit do segundo byte diz se o pacote e uma requisi c ao ou uma resposta. J a para o NTP, o primeiro byte do conte udo informa a vers ao do protocolo NTP sendo utilizado e o modo de opera c ao do pacote, informando assim se este est a operando como uma requisi c ao ou como uma resposta. Sabe-se que o arquivo que cont em o tr afego de rede armazena, no m aximo, 68 bytes por pacote. Portanto, pode-se considerar a seguinte divis ao para os pacotes UDP: 14 bytes do cabe calho Ethernet, 20 bytes do cabe calho IP sem op c oes e 8 bytes do cabe calho UDP. Ent ao, restam 26 bytes para armazenar o conte udo da mensagem UDP, que permitem a obten c ao dos bytes iniciais para as aplica c oes de DNS e NTP. Existem dois crit erios, utilizados para denir se um pacote DNS e uma requisi c ao ou uma aplicada uma m resposta. E ascara de bits ao segundo byte do conte udo do pacote, para obter apenas o valor do bit desejado. Se este bit for igual a 0, ent ao o pacote e uma requisi c ao. Se for 1, ent ao este e uma resposta. J a para os pacotes NTP, outros crit erios s ao utilizados para denir se um pacote NTP e uma requisi c ao ou uma resposta. Primeiro e aplicada uma m ascara de bits ao primeiro byte do conte udo do pacote, para obter a vers ao do protocolo NTP sendo utilizado. E segundo, e aplicada outra m ascara de bits sobre o mesmo byte, para identicar o modo de opera c ao do pacote. A Tabela (5.2) apresenta estes crit erios:

109

TABELA 5.2: Identica c ao do tipo do pacote NTP Vers ao igual a 1 Modo de Opera c ao 0 (unspecied) Verica c ao porta de destino igual a 123 porta de origem igual a 123 Tipo do pacote requisi c ao (request) resposta (reply) requisi c ao (request) resposta (reply) requisi c ao (request) resposta (reply)

maior que 1

1 2 3 4

(symmetric active) (symmetric passive) (client) (server)

Para as sess oes UDP, associadas ` as aplica c oes de DNS e NTP, e feita a aloca c ao de um inteiro de 4 bytes, para armazenar a contagem da diferen ca no n umero de pacotes de requisi c ao e de resposta. Este contador tem a mesma funcionalidade do campo match reply, associado ` as sess oes ICMP de informa c ao, vista na se c ao 5.3.10.1, e e associado a cada sess ao UDP deste g enero. Portanto, para cada pacote UDP, onde e caracterizada a utiliza c ao das aplica c oes de DNS e NTP, juntamente com os dados obtidos da mensagem UDP contida no pacote, s ao armazenados os seguintes campos: para o DNS, o campo id de um byte, que cont em a identica c ao do pacote DNS e e utilizado no casamento das respostas com as respectivas requisi c oes, e o campo ags tamb em de um byte, que cont em o bit que informa se o pacote e uma requisi c ao ou resposta; e para o NTP, o campo status de um byte, que cont em a vers ao e o modo de opera c ao do pacote. Existem, ainda, alguns atributos associados ` as sess oes deste g enero, e s ao apresentados como se segue: DNS REPLY FIRST e NTP REPLY FIRST: associados ` a sess ao UDP de DNS e NTP, respectivamente, quando o primeiro pacote inserido e uma resposta; DNS REPLY NOMATCH e NTP REPLY NOMATCH: associados ` a sess ao UDP de DNS e NTP, respectivamente, quando n ao e encontrado o pacote de requisi c ao relacionado ao pacote de resposta sendo processado; DNS TRUNC DATA e NTP TRUNC DATA: associados ` a sess ao UDP de DNS e NTP, respectivamente, quando o processador UDP n ao consegue obter os bytes de conte udo, necess arios para identicar as requisi c oes e respostas; 110

 DNS EXCEEDED PAYLOAD: associado a sess ao UDP de DNS, quando o tamanho do conte udo da mensagem UDP excede o m aximo permitido. Segundo Mockapetris (2002b), o tamanho m aximo de um pacote DNS, utilizando o protocolo UDP, e de 512 bytes. A Figura (5.15) apresenta as estruturas utilizadas no armazenamento: de cada sess ao na lista encadeada de sess oes UDP (a); de cada pacote na lista encadeada de pacotes UDP de uma sess ao (b); dos dados obtidos da mensagem UDP contida no pacote (c); dos dados espec cos, no caso da aplica c ao DNS (d); e dos dados espec cos, no caso da aplica c ao NTP (e).

struct udp_sessions { u_int8_t attributes; u_int16_t portA; u_int16_t portB; void *spec; struct udp_pkt *first_udp_pkt; struct udp_pkt *last_udp_pkt; struct udp_sessions *next; struct udp_sessions *prev; };

struct udp_pkt { struct timeval ptv; struct mod_ip data_ip; struct mod_udp data_udp; struct udp_pkt *next; struct udp_pkt *prev; };

struct mod_udp { u_int16_t len; void *app_data; }; c struct dns_data { u_int16_t id; u_int8_t flags; }; d struct ntp_data { u_int8_t status; }; e

FIGURA 5.15 Estruturas de armazenamento das sess oes UDP. Na estrutura udp sessions, correspondente a cada sess ao da lista encadeada de sess oes UDP, attributes cont em os atributos da sess ao. portA e portB cont em as portas associadas ` sess a ao UDP, onde estas referem-se ao maior e menor endere co IP, respectivamente. spec e um apontador para informa c oes espec cas, associadas ` a aplica c ao utilizando o protocolo UDP, no caso de aplica c oes tratadas pelo processador UDP. rst udp pkt e last udp pkt s ao apontadores para o primeiro e para o u ltimo pacote, na lista encadeada de pacotes UDP da sess ao. E next e prev s ao apontadores para a pr oxima sess ao UDP e para a anterior. Na estrutura udp pkt, correspondente a cada pacote da lista encadeada de pacotes UDP de uma sess ao, ptv cont em o hor ario de captura do pacote UDP. data ip e a estrutura que cont em os dados obtidos do cabe calho IP do pacote, como visto na se c ao 5.3.8. data udp e a estrutura que cont em os dados obtidos do cabe calho UDP do pacote. E next e prev s ao apontadores para o pr oximo pacote e para o anterior. Na estrutura mod udp, correspondente ao dados armazenados do cabe calho UDP de cada 111

pacote, len cont em o tamanho da mensagem UDP, obtido da estrutura apontada por udp. E app data e o apontador para dados espec cos da aplica c ao utilizando o protocolo UDP, no caso de aplica c oes tratadas pelo processador UDP. Na estrutura dns data, correspondente aos dados espec cos armazenados para a aplica c ao DNS, id cont em a identica c ao da requisi c ao ou resposta DNS. E ags cont em os bits necess arios para identicar se o pacote e uma requisi c ao ou uma resposta DNS. Na estrutura ntp data, correspondente aos dados espec cos armazenados para a aplica c ao NTP, status cont em os bits necess arios para identicar se o pacote e uma requisi c ao ou uma resposta NTP. Para o caso das sess oes UDP de DNS e NTP, o apontador spec, da estrutura udp sessions, referencia o contador da diferen ca no n umero de requisi c oes e respostas. E o apontador app data, da estrutura udp pkt, referencia a estrutura dns data ou ntp data, de acordo com a aplica c ao. Para os demais casos, estes apontadores s ao iguais a NULL. 5.3.12 O Processador TCP

A fun c ao tcp session proc corresponde ` a implementa c ao do processador TCP, e seu formato e apresentado como se segue: void tcp session proc(struct tcp sessions f tcp session, struct tcp sessions l tcp session, struct ip ip, struct tcphdr tcp, u int8 t pkt dir, u int caplen, u int length) Quando o processador IP verica que o pacote sendo processado cont em uma mensagem TCP, este executa a chamada da fun c ao tcp session proc, preenchendo devidamente seus par ametros. f tcp session e l tcp session s ao apontadores para o in cio e m das sess oes TCP, associadas aos dois IPs contidos no pacote sendo processado. ip e o apontador para a estrutura contendo o cabe calho IP. tcp e o apontador para a estrutura contendo o cabe calho TCP. pkt dir cont em o c odigo da dire c ao do pacote. caplen cont em a quantidade de bytes capturados para o pacote, a partir do in cio do cabe calho TCP. E length cont em o tamanho total do datagrama IP, que cont em a mensagem TCP, decrementado do tamanho do cabe calho IP. Uma sess ao TCP tem como identicadores as duas portas contidas nas mensagens TCP dos pacotes que a comp oem. Seguindo o mesmo esquema de implementa c ao do processador UDP, utiliza-se o par <portA,portB> para identicar a sess ao, onde a primeira

112

est a associada ao menor endere co IP dos pacotes, e a segunda est a associada ao maior endere co IP. Observe que tamb em n ao h a a preocupa c ao com a id eia de porta de origem e destino, pois existe a codica c ao da dire c ao do pacote, como visto na se c ao 5.3.8. Outra informa c ao, que determina se um pacote pertence ou n ao a uma sess ao TCP, eo seu estado. Quando um pacote cont em um par de portas, que casa com uma sess ao TCP previamente criada, se o estado desta sess ao informar que ela j a foi terminada, uma nova sess ao TCP dever a ser criada, e este pacote TCP dever a ser inclu do na lista encadeada de pacotes desta nova sess ao. O primeiro passo, realizado pela fun c ao tcp session proc, e vericar que a c ao deve ser tomada para o pacote TCP sendo processado. Para isto e utilizada uma subrotina, que verica o campo ags da estrutura apontada por tcp, correspondente ao cabe calho TCP do pacote, e que leva em considera c ao o estado das sess oes TCP. Existem dois casos, tratados por esta subrotina. No Caso 1, n ao existem sess oes TCP, associadas ao par de endere cos IP contido no pacote. Ent ao, a subrotina faz as devidas checagens, observando que n ao existe um estado associado, pois ainda n ao existe uma sess ao TCP, onde o pacote deva ser inserido. E no caso 2, existem sess oes TCP associadas. Ent ao, antes de executar a subrotina, e iniciada uma busca por uma sess ao, identicada pelo mesmo par de portas do pacote TCP sendo processado. Se esta sess ao existir, o seu estado e checado, e se este n ao informar que a sess ao foi terminada, e utilizado para direcionar as checagens realizadas pela subrotina. De outra forma, a execu c ao ocorre de maneira semelhante ao caso 1. Ao terminar as checagens dos ags, contidos no cabe calho TCP do pacote, a subrotina retorna um c odigo, referente a a c ao que deve ser tomada para o pacote sendo processado. O c odigo PROCEED informa que os ags s ao v alidos e que deve-se proceder com o processamento do pacote, sendo que este pode ou n ao estar associado a uma sess ao TCP previamente criada. C odigos DROP STH ACT {FXT,SAPU,FIN,NULL,NXT,VECNA,UNKNOWN}5 indicam que o pacote deve ser descartado e inserido na arvore de logs TCP (a ser vista na se c ao 5.3.12.1), pois uma combina c ao de ags indesejada foi observada. O pacote n ao e associado a uma sess ao TCP, e a fun c ao termina. O c odigo DROP RESET indica que o pacote deve ser descartado e inserido na arvore
As chaves ({ }) indicam que s ao sete c odigos diferentes, onde o prexo do nome dado ao c odigo e semelhante, e a a c ao a ser tomada e a mesma.
5

113

de logs TCP, pois o ag RST est a ativo e o pacote n ao foi associado a uma sess ao TCP. Este c odigo faz com que a fun c ao termine. C odigos LOG TWH STH ACT {FXT,SAPU,FIN,NULL,NXT,VECNA,UNKNOWN}5 indicam que deve-se proceder com o processamento do pacote, mas este deve ser inserido na arvore de logs TCP, pois cont em uma combina c ao de ags que caracterizam uma atividade stealth. Atividades stealth s ao aquelas que tentam iludir um mecanismo de defesa, por exemplo, um Firewall. O pacote e associado ` a sess ao TCP, e est a contido em seu three-way handshake. O c odigo LOG TWH WEIRD BEHAVIOR indica que deve-se proceder com o processamento do pacote, mas este deve ser inserido na arvore de logs TCP, pois caracteriza uma atividade n ao esperada, durante o three-way handshake de uma sess ao TCP. O pacote e associado ` a sess ao correspondente. C odigos LOG STH ACT {FXT,SAPU,FIN,NULL,NXT,VECNA,UNKNOWN}5 indicam que deve-se proceder com o processamento do pacote, mas este deve ser inserido na arvore de logs TCP, pois cont em uma combina c ao de ags que caracterizam uma atividade stealth. O pacote e associado ` a sess ao TCP, e est a contido em seu uxo de dados. Os c odigos LOG DATA SEQN GT FIN1 e LOG DATA SEQN GT FIN2 indicam que deve-se proceder com o processamento do pacote, mas este deve ser inserido na arvore de logs TCP, pois caracteriza o envio de dados, onde a mensagem TCP tem o sequence number maior que o sequence number do pacote FIN, no mesmo sentido. O pacote e associado ` a sess ao TCP correspondente. E nalmente, LOG ACK GT FIN1 SEQNplus1 e LOG ACK GT FIN2 SEQNplus1 s ao c odigos que indicam que deve-se proceder com o processamento do pacote, mas este deve ser inserido na arvore de logs TCP, pois caracteriza o envio de um ACK, onde a mensagem TCP tem o acknowledgement number maior que o sequence number + 1 do pacote FIN, no sentido oposto. O pacote e associado ` a sess ao TCP correspondente. A Tabela (5.3) apresenta as combina c oes de ags, para os c odigos de retorno da subrotina, relacionados ` as atividades stealth. Convenciona-se que a ocorr encia do ag URG e representada por U, ACK por A, PSH por P, RST por R, SYN por S e FIN por F.

114

TABELA 5.3: Atividades stealth Suxo no c odigo da a c ao STH ACT FXT STH ACT SAPU STH ACT FIN STH ACT NULL STH ACT NXT STH ACT VECNA STH ACT UNKNOWN Flags UAPRSF SAPU F aus encia de ags FPU U, PF, UP, P ags n ao esperados Nome da atividade full xmas tree sapu n null nmap6 xmas tree vecna atividade desconhecida (unknown)

Caso o c odigo de retorno da subrotina, que determina a a c ao a ser tomada, permita a continuidade do processamento do pacote, uma outra subrotina e executada, e tem como nalidade atualizar o estado da sess ao TCP associada. Para o caso onde uma nova sess ao e criada, estabelece o estado inicial para esta. Essa subrotina implementa um diagrama de transi c ao de estados, que e uma variante do diagrama proposto na RFC de especica c ao do protocolo TCP (Postel, 2002d). O diagrama implementado considera o uxo bidirecional de informa c oes na conex ao, diferente do diagrama tradicional, onde estados distintos s ao criados nos dois extremos da conex ao. A Figura (5.16) apresenta o diagrama proposto e implementado na subrotina de atualizac ao do estado de uma sess ao TCP. Combina c oes de ags foram suprimidas do diagrama, para facilitar seu entendimento. Pode-se observar que um pacote contendo a combina c ao de ags SYN/FIN ocasiona a transi c ao do estado de partida No State para o estado inicial SYN . Esta condic ao foi considerada, pois v arios sistemas operacionais, baseados na plataforma UNIX, tais como Linux, FreeBSD, OpenBSD e Solaris, e o sistema operacional Windows, responderam com um pacote SYN/ACK, nesta situa c ao. Para realizar estes testes a ferramenta hping7 foi utilizada. Algumas observa c oes s ao feitas em rela c ao ao diagrama da Figura 5.16 e s ao apresentadas como se segue: a) Os estados, cujos nomes cont em FIN1 e FIN2, indicam a ocorr encia do
6 Caracteriza a poss vel utiliza c ao da conhecida ferramenta de varredura (scanner) nmap. P agina Web em http://www.insecure.org/nmap. 7 P agina Web em: http://www.hping.org.

115

primeiro e do segundo pacote FIN, relacionados ao t ermino da sess ao TCP, respectivamente; b) Os estados, que correspondem ao t ermino normal de uma sess ao, identicados por FIN{1,2}-A, indicam que o pacote FIN foi enviado pelo menor endere co IP associado ` a sess ao. E os identicados por FIN{1,2}-B indicam que este foi enviado pelo maior endere co IP. J a para os estados identicados por ACK/FIN{1,2}-A e ACK/FIN{1,2}-B, indicam que o pacote ACK/FIN foi recebido pelo menor endere co IP e pelo maior, respectivamente; c) Os estados que cont em a palavra Closed , indicam que a sess ao foi terminada; d) Os estados, que correspondem ao t ermino normal de uma sess ao, e identicados pela palavra Sim., indicam o fechamento simult aneo da sess ao.

Legenda: S = SYN S/A = SYN/ACK A = ACK S/F = SYN/FIN F/A = FIN/ACK R/A = RST/ACK F/A Estado de partida

NO State S S/F S/A SYN S/A A HALF OPEN A OPEN F/A F/A FIN1A A Sim. FIN2B ACK/FIN1A A Sim. ACK/FIN2B A Sim. ACK/FIN1A Closed F/A FIN2B A ACK/FIN2B Closed F/A FIN1B A ACK/FIN1B F/A FIN2A A ACK/FIN2A Closed A Sim. ACK/FIN2A A Sim. ACK/FIN1B Closed Sim. FIN2A A Sim. ACK/FIN1B A Sim. ACK/FIN2A Closed F/A F/A R/A RESET Closed

Estados iniciais

A Sim. ACK/FIN1A A Sim. ACK/FIN2B Closed

FIGURA 5.16 Diagrama de transi c ao de estados para as sess oes TCP. A cada sess ao TCP, e associado o campo server, onde procura-se identicar qual par <endere co IP, porta> e o servidor na sess ao. Para isto, a sess ao deve ter passado pelo estado SYN, ou pelo menos pelo HALF-OPEN. No primeiro caso, o par que recebeu o pacote SYN e identicado como servidor. J a no segundo caso, o par que enviou o pacote SYN/ACK e identicado como servidor. Caso o servidor esteja relacionado ao menor IP da sess ao, o valor 1 e associado ao campo server. Caso esteja relacionado ao maior IP, 116

o valor 2 e associado. Se n ao houver possibilidade de realizar esta associa c ao, o campo recebe o valor 0. Para vericar e efetivar o t ermino normal de uma sess ao TCP, os sequence numbers dos pacotes FIN, enviados pelos dois endere cos IP associados ` a sess ao, s ao armazenados. Estes s ao utilizados para checar se os pacotes posteriores aos pacotes FIN t em sequence numbers e acknowledgement numbers v alidos. Quando o processador TCP observa um pacote RST, este procura associ a-lo a uma sess ao TCP. Caso a associa c ao seja bem sucedida, o sequence number e/ou acknowledgement number do pacote s ao checados em rela c ao ` a sess ao associada. Se estes forem v alidos, o estado da sess ao e atualizado para RESET Closed , e indica o t ermino abrupto da sess ao. Caso a associa c ao com uma sess ao TCP n ao seja poss vel, a arvore de logs e checada. Se o pacote de RST for associado a algum log, o pacote de log em quest ao recebe um marcador, dizendo que um RST foi associado a ele. Ent ao, para sumarizar o funcionamento do processador TCP, depois de avaliar que a c ao deve ser tomada para o pacote sendo processado, se for permitido dar continuidade ao processamento do pacote, e vericado se este deve ser associado a uma sess ao TCP. Caso positivo, o estado da sess ao e atualizado, e o pacote e inserido na lista encadeada de pacotes TCP, associada a ` sess ao. Ainda existem alguns atributos que podem ser associados a uma sess ao TCP, e s ao descritos como se segue: COLD START: indica que a sess ao n ao teve um in cio esperado. Normalmente, est a relacionado ` a perda de pacotes no processo de coleta do tr afego de rede e, principalmente, de parte ou todo o three-way handshake. Est a associado aos estados iniciais HALF-OPEN, OPEN, FIN1-A, FIN1-B ; RES1 SET ON SYN e RES2 SET ON SYN: indicam a presen ca dos ags RES1 e RES2 no pacote SYN, respectivamente; DATA ON SYN: indica que dados foram enviados no pacote SYN; RES1 SET ON SYN FIN e RES2 SET ON SYN FIN: indicam a presen ca dos ags RES1 e RES2 no pacote SYN/FIN,respectivamente; STEALTH ACTIVITY SYN FIN: quando ocorre um pacote SYN/FIN, a sess ao recebe este atributo; RES1 SET ON SYN ACK e RES2 SET ON SYN ACK: indicam a presen ca dos ags RES1 e RES2 no pacote SYN/ACK, respectivamente; 117

 SYN RESET: indica que a sess ao estava no estado SYN e foi terminada abruptamente; HALF OPEN RESET: indica que a sess ao estava no estado HALF-OPEN e foi terminada abruptamente; A Figura (5.17) apresenta as estruturas utilizadas no armazenamento: de cada sess ao na lista encadeada de sess oes TCP (a); de cada pacote na lista encadeada de pacotes TCP de uma sess ao (b); dos dados obtidos da mensagem TCP contida no pacote (c); e dos n umeros de sequ encia dos pacotes TCP utilizados na solicita c ao do t ermino de conex ao (d).

struct tcp_sessions { u_int8_t state:5; u_int8_t server:3; u_int16_t attributes; u_int16_t portA; u_int16_t portB; struct mod_tcp_finseq *finseq; struct tcp_pkt *first_tcp_pkt; struct tcp_pkt *last_tcp_pkt; struct tcp_sessions *next; struct tcp_sessions *prev; }; a

struct tcp_pkt { struct timeval ptv; struct mod_ip data_ip; struct mod_tcp data_tcp; struct tcp_pkt *next; struct tcp_pkt *prev; };

struct mod_tcp { u_int32_t seq; u_int32_t ack; u_int8_t hdr_len:4; u_int8_t reserved:4; u_int8_t flags; u_int16_t win; }; c struct mod_tcp_finseq { u_int32_t seqA; u_int32_t seqB; }; d

FIGURA 5.17 Estruturas de armazenamento das sess oes TCP. Na estrutura tcp sessions, correspondente a cada sess ao TCP, o campo state armazena o estado atual da sess ao. server cont em o c odigo, que diz qual par <endere co IP, porta> e o servidor, caso seja poss vel determinar. attributes cont em os atributos associados ` a sess ao. portA e portB cont em as portas associadas ` a sess ao TCP, onde estas referem-se ao maior e menor endere co IP, respectivamente. nseq e um apontador para a estrutura, que cont em os n umeros de sequ encia dos pacotes FIN, enviados por cada endere co IP associado ` a sess ao. rst tcp pkt e last tcp pkt s ao apontadores para o in cio e m da lista encadeada de pacotes TCP, associados ` a sess ao. E next e prev s ao apontadores para a pr oxima sess ao e para a anterior. Na estrutura tcp pkt, correspondente a cada pacote da lista encadeada de pacotes TCP de uma sess ao, ptv cont em o hor ario de captura do pacote TCP. data ip e a estrutura que cont em os dados obtidos do cabe calho IP do pacote, como visto na se c ao 5.3.8. data tcp e a estrutura que cont em os dados obtidos do cabe calho TCP do pacote. E next e prev s ao apontadores para o pr oximo pacote e para o anterior. Na estrutura mod tcp, correspondente aos dados armazenados para o cabe calho TCP de 118

cada pacote, seq cont em o sequence number, ack o acknowledgement number, hdr len o tamanho do cabe calho TCP, reserved os bytes do campo reserved, ags os ags, e win o window size. Todos estes dados s ao obtidos da estrutura apontada por tcp, correspondente ao cabe calho da mensagem TCP. em o sequence number do pacote FIN, enviado Na estrutura mod tcp nseq, seqA cont pelo menor endere co IP. E seqB cont em o sequence number do pacote FIN, enviado pelo maior endere co IP. 5.3.12.1 A Arvore de Logs TCP

A arvore bin aria de logs TCP armazena os pacotes, correspondentes aos logs gerados pelo processador TCP. Cada n o da arvore e identicado pelo par <endere co IP de origem, endere co IP de destino>, e constitui uma lista encadeada de pacotes de logs TCP, com o mesmo par de endere cos do n o da arvore. A Figura (5.18) apresenta as estruturas correspondentes a: cada n o da arvore (a), e cada pacote de log TCP, associado ao n o (b).

struct tcp_log_node { u_int32_t ip_A; u_int32_t ip_B; struct tcp_log_data struct tcp_log_data struct tcp_log_node struct tcp_log_node char balance; };

*first_log; *last_log; *left; *right;

struct tcp_log_data { u_int8_t log_type:7; u_int8_t ass_reset:1; struct timeval ptv; struct mod_ip data_ip; u_int16_t portA; u_int16_t portB; struct mod_tcp data_tcp; struct tcp_log_data *next; struct tcp_log_data *prev; }; b

FIGURA 5.18 Estruturas de armazenamento da arvore de logs TCP. Na estrutura tcp log node, correspondente a cada n o da arvore, os campos ip A e ip B cont em os endere cos IP de origem e destino, identicadores do n o. rst log e last log s ao apontadores para o in cio e para o m da lista encadeada de pacotes de log associados ao n o. left e right apontam para as sub- arvores esquerda e direita. E balance e utilizado no balanceamento da arvore bin aria de logs. Na estrutura tcp log data, correspondente a cada pacote de log associado a um n o, o campo log type armazena o tipo do pacote de log, atribu do pelo processador TCP. ass reset diz se um pacote RST foi associado ao pacote de log. ptv cont em o hor ario de captura do pacote. data ip e a estrutura que cont em os dados obtidos do cabe calho IP do pacote, 119

como visto na se c ao 5.3.8. portA e portB cont em as portas associadas ao pacote, onde estas referem-se ao maior e menor endere co IP, respectivamente. data tcp e a estrutura que cont em os dados obtidos do cabe calho TCP do pacote. E next e prev s ao apontadores para o pr oximo pacote de log e para o anterior. 5.3.13 O Gerador de Resultados

O gerador de resultados e respons avel por apresentar as informa c oes contidas nas estruturas de armazenamento das sess oes TCP/IP reconstru das, bem como da arvore de desfragmenta c ao e da arvore de logs TCP. E implementado atrav es de um conjunto de rotinas destinadas a estas opera c oes. De acordo com os argumentos obtidos da linha de comandos (como visto na se c ao 5.3.5) e com os par ametros obtidos do arquivo de congura c oes (visto na se c ao 5.3.4), direciona a gera c ao dos resultados, para que sejam apresentados apenas os desejados pelo usu ario. Por exemplo, se na execu c ao do RECON, os argumentos -T e -vv forem especicados, todas as sess oes TCP ser ao apresentadas, onde para cada sess ao, todos os seus pacotes ser ao mostrados. Al em disso, os resultados ser ao apresentados no n vel verbose 2, o que signica que estes ter ao o maior n vel de detalhamento. Se o argumento -f for especicado, a arvore de desfragmenta c ao deve ser vericada, e as informa c oes dos elementos de desfragmenta c ao de cada n o, associadas a alguma situa c ao de alarme, como por exemplo, a sobreposi c ao de fragmentos (overlaping), devem compor os resultados gerados. E se o argumento -l for especicado, todos os pacotes da arvore de logs TCP devem ser apresentados, mas de forma colapsada. Isto signica que pacotes que tiverem caracter sticas muito semelhantes devem ser suprimidos, e apenas um deve ser apresentado, mas com a contagem do n umero de vezes que se repetiu. O gerador de resultados disp oe de um mecanismo, que faz o caminhamento pr e-ordem (Gonnet e Baeza-Yates, 1991) das arvores bin arias balanceadas, de modo que os resultados apresentados sejam ordenados do menor endere co IP para o maior endere co. Com isto, ca f acil localizar um determinado endere co, dentre todos os resultados gerados. Al em disso, os n os das arvores bin arias, cujas informa c oes j a foram apresentadas, s ao marcados, evitando assim que resultados sejam duplicados.

120

CAP ITULO 6 RESULTADOS OBTIDOS Este cap tulo apresenta os resultados obtidos pelo RECON, na reconstru c ao de sess oes TCP/IP e em algumas aplica c oes relacionadas ` a detec c ao de intrus ao. E apresentada a forma de obten c ao dos dados utilizados na an alise dos resultados, bem como uma breve discuss ao sobre o desempenho da ferramenta desenvolvida. 6.1 DOS DADOS UTILIZADOS NA ANALISE OBTENC AO

A an alise dos resultados gerados pelo RECON, relacionados ` as atividades de reconstruc ao de sess oes TCP/IP, e sua aplica c ao em algumas atividades relacionadas ` a detec c ao de intrus ao, fez uso do tr afego direcionado ` as redes do Instituto Nacional de Pesquisas Espaciais e no tr afego de rede gerado em ambiente de laborat orio experimental. Para a coleta do tr afego de rede do Instituto, foi usado o componente sensor do sistema de detec c ao de intrus ao SHADOW, posicionado estrategicamente de modo a coletar pacotes entrando e saindo de sua rede de comunica c ao de dados. Foram capturados apenas 68 bytes por pacote e estes foram armazenados em arquivos, de hora em hora. Cada arquivo gerado foi, ent ao, transferido para uma esta c ao de an alise, instalada na rede interna do Instituto. O RECON foi executado nesta esta c ao e, a cada hora, realizou-se a an alise dos pacotes contidos no arquivo transferido. Al em disso, pacotes gerados em ambiente de laborat orio foram utilizados no estudo. A principal fun c ao deste tr afego de rede experimental foi apresentar alguns casos que n ao puderam ser observados no tr afego de rede do Instituto. Algumas considera c oes foram feitas na apresenta c ao dos resultados, onde s ao analisadas a reconstru c ao de sess oes e algumas aplica c oes relacionadas ` a detec c ao de intrus ao. Estas considera c oes s ao apresentadas como se segue: Algumas linhas foram quebradas e, em alguns casos, informa c oes nelas contidas foram suprimidas por quest oes de legibilidade. Os IPs reais foram substitu dos por nomes ct cios que, em algumas situa c oes, est ao associados ao servi co utilizado na troca de informa c oes; Com exce c ao de algumas situa c oes espec cas, n ao e feita a distin c ao entre o tr afego experimental e o tr afego real coletado pelo sensor, por quest oes de sigilo das informa c oes observadas. Como a quantidade de dados analisados e consideravelmente grande, os resul121

tados apresentados foram divididos em se c oes, onde parte do tr afego de rede contido em diferentes arquivos foram selecionados, para ilustrar a funcionalidade da ferramenta desenvolvida. 6.2 DE RECURSOS DESEMPENHO E ALOCAC AO

Os arquivos contendo o tr afego de rede, coletados entre os dias 12/07/2002 e 06/08/2002, foram selecionados para a realiza c ao de uma breve an alise do desempenho do RECON, bem como da utiliza c ao de recursos na esta c ao de an alise onde este e executado. No per odo selecionado foram coletados 806.325.074 pacotes, representando uma m edia di aria de 31.012.503 pacotes e, consequentemente, 1.292.188 pacotes por hora. Foi, ent ao, aplicado um ltro sobre os arquivos contendo estes pacotes, de modo que todo o tr afego HTTP relacionado ` a porta 80/tcp foi exclu do da an alise. Ap os a ltragem restaram 536.100.574 pacotes, representando 66,49% do total coletado, com uma m edia di aria de 20.619.253 pacotes e, consequentemente, 859.136 pacotes por hora. A Tabela (6.1) apresenta as m edias hor arias de mem oria alocada na execu c ao do RECON e do tempo gasto em sua execu c ao. Tamb em s ao apresentados os tempos gastos na cria c ao de todo o modelo de reconstru c ao de sess oes e na apresenta c ao dos resultados. A soma destes dois tempos e igual ao tempo total de execu c ao. TABELA 6.1: M edias hor arias calculadas sobre o tr afego do per odo. M edia hor aria aloca c ao de mem oria tempo gasto na execu c ao tempo gasto na gera c ao do modelo tempo gasto na impress ao dos resultados Contagem 31,96 Mbytes 75,091 segundos 29,697 segundos 45,393 segundos

Atualmente, o hardware dispon vel possui uma quantidade de mem oria bem superior a taxa de aloca c ao observada na execu c ao do RECON. Outro aspecto a ser considerado e que a esta c ao de an alise de dados utilizada n ao estava exclusivamente dedicada ` as tarefas de an alise, alocando assim apenas parte dos recursos dispon veis. Em vista disto, a aloca c ao de recursos da esta c ao, relacionada ` a utiliza c ao de mem oria, foi considerada satisfat oria. O tempo gasto na apresenta c ao dos resultados e razoavelmente maior que o tempo gasto 122

na gera c ao do modelo, visto que o primeiro envolve opera c oes de I/O (entrada/sa da), onde o resultados s ao enviados para arquivo ou mesmo apresentados na tela, enquanto o segundo envolve apenas opera c oes em mem oria. A Tabela (6.2) apresenta as m edias de tempos gastos no processamento de cada pacote, divididas entre gera c ao do modelo e apresenta c ao dos resultados. O c alculo consiste na divis ao dos tempos observados na Tabela (6.1) pelo total de pacotes analisados. TABELA 6.2: M edia dos tempos por pacote nas etapas de execu c ao. M edia sobre o tempo gasto na execu c ao gasto na gera c ao do modelo gasto na impress ao dos resultados C alculo 75,091 / 859136 29,697 / 859136 45,393 / 859136 Tempo/Pacote (s/pkt) 87,403 34,566 52,836

Apesar dos n umeros associados aos tempos gastos no processamento de cada pacote serem relativamente pequenos, em particular o tempo gasto na gera c ao do modelo, alguns aperfei coamentos na implementa c ao do RECON s ao propostos no cap tulo 7, com o intuito de melhorar o seu desempenho. E nalmente, a Tabela (6.3) apresenta a m edia de a rea de armazenamento alocada por pacote analisado. O c alculo consiste na divis ao da mem oria alocada, observada na Tabela (6.1), pelo n umero total de pacotes analisados. TABELA 6.3: M edia de area de armazenamento alocada por pacote. M edia sobre mem oria alocada C alculo (31,96*1024*1024) / 859136 Bytes/Pacote (b/pkt) 39,01

Este n umero e justicado pela quantidade consideravelmente maior de pacotes TCP, observados no tr afego de rede analisado. Isto se deve ao fato de que os pacotes TCP cont em mais informa c oes a serem armazenadas, quando comparados aos pacotes ICMP e UDP. A pr oxima se c ao ilustra esta observa c ao.

123

6.3

ESTAT ISTICAS SUMARIZADAS

O RECON adiciona, ao nal dos resultados gerados, um conjunto de informa c oes estat sticas, obtidas dos contadores globais do sistema. Estes contadores, apresentados no ap endice B.1, s ao atualizados durante o processamento dos pacotes contidos em um arquivo, para uma determinada hora. Ent ao, estes valores acumulados s ao agrupados e apresentados, como mostra o exemplo a seguir.
================================================================== | Graph Numbers | +---------------+ Num. IPs (vertex) 7528 Num. connections (arests) 15037 ================================================================== | Packet Numbers | +----------------+ Total packets 2985410 Non TCP/IP packets 0 Non IP packets 0 ================================================================== | Ethernet Numbers | +------------------+ Ethernet packets with truncated header 0 ================================================================== | IP Numbers | +------------+ IP datagrams with truncated header 0 IP datagrams with truncated content 14297 IP datagrams with options 0 IP fragmented datagrams 0 IP datagrams with protocols different from TCP/UDP/ICMP or Multicast 0 Multicast messages (IP in IP) 0 ================================================================== | TCP Numbers | +-------------+ TCP messages with truncated header 0 ------------TCP packets inserted in the model 2906587 TCP packets with bad header length 1 TCP packets with options 510796 TCP log packets 6381 TCP reset packets (nomatch) 759 ================================================================== | UDP Numbers | +-------------+ UDP messages with truncated header 0 ------------UDP packets inserted in the model 75049 ================================================================== continua...

124

================================================================== | ICMP Numbers | +--------------+ ICMP messages with truncated header 0 ICMP messages with unknown or reserved type 0 ICMP messages - router solicitation 0 ICMP messages - router advertisement 7 ICMP messages - time exceeded in frag. 0 ------------ICMP packets inserted in the model 3767 - Info messages Requisition ICMP info packets 1433 Reply ICMP info packets 924 - Error messages ICMP error packets 1410 Alarm ICMP error packets (no match) 142 ICMP time exceeded in frag. (no match) 0 ==================================================================

O primeiro grupo de informa c oes apresenta a quantidade de endere cos IP distintos observados no tr afego da hora em quest ao, e o n umero de interliga c oes realizadas entre pares de IPs. Ent ao, o n umero total de pacotes processados e mostrado e informa c oes sobre o processamento de cada protocolo, desde a camada de enlace at e a camada de transporte, s ao apresentadas. Pode-se observar que o n umero de pacotes TCP processados e efetivamente inseridos no modelo e consideravelmente maior do que os pacotes dos outros protocolos e, apesar deste exemplo representar apenas os dados analisados para uma hora, esta caracter stica foi uma constante no per odo considerado. Outra observa c ao interessante diz respeito ao n umero de pacotes TCP com o ag RST ativo, e que n ao foram associados a alguma sess ao. Este n umero expressivo fornece um indicativo de que endere cos IP da rede monitorada est ao, provavelmente, sendo forjados (spoong) por terceiros para a realiza c ao de ataques ou varreduras de m aquinas externas. 6.4 DAS SESSOES RECONSTRUC AO ICMP

A reconstru c ao das sess oes ICMP e dividida em duas partes: a associa c ao dos pacotes ICMP de erro aos respectivos pacotes geradores dos erros, e a reconstru c ao das sess oes ICMP de informa c ao. Estas partes s ao apresentadas nas subse c oes seguintes. 6.4.1 Pacotes ICMP de Erro

A sa da tcpdump abaixo apresenta pacotes ICMP de erro, do tipo host unreachable, enviadas de um roteador interno para um roteador externo. 125

12:00:12.366670 12:00:12.367009 12:00:22.369117 ... 12:45:48.941137 12:45:48.941439 12:45:48.941738

int_router > ext_router: icmp: host int_host_90 unreachable int_router > ext_router: icmp: host int_host_90 unreachable int_router > ext_router: icmp: host int_host_90 unreachable int_router > ext_router: icmp: host int_host_90 unreachable int_router > ext_router: icmp: host int_host_90 unreachable int_router > ext_router: icmp: host int_host_90 unreachable

Ap os a execu c ao do RECON com a op c ao -E, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado.
[ ext_router (o) <=> int_router (i) ] ICMP Error packets pkt 1 (<-) 12:00:12.366670 unreachable - host (match icmp) [len 56 id 38786 ttl 64] pkt 2 (<-) 12:00:12.367009 unreachable - host (match icmp) [len 56 id 38787 ttl 64] pkt 3 (<-) 12:00:22.368789 unreachable - host (match icmp) [len 56 id 38788 ttl 64] ... pkt 164 (<-) 12:45:48.941137 unreachable - host (match icmp) [len 56 id 43759 ttl 64] pkt 165 (<-) 12:45:48.941439 unreachable - host (match icmp) [len 56 id 43760 ttl 64] pkt 166 (<-) 12:45:48.941738 unreachable - host (match icmp) [len 56 id 43761 ttl 64] ------------------duration ............: 12:00:12.366670 - 12:45:48.941738 - diff = 45m 36s 575068ms , 166 packets. unreachable .........: type 3 - 166 packets, 0 nomatch

A op c ao -E faz com que o RECON apresente uma sa da detalhada para os pacotes de erro. Os identicadores (o) e (i), que aparecem logo ap os os nomes1 associados aos endere cos IP, mostram que o primeiro e externo e o segundo e interno ` a rede monitorada. Esta identica c ao e realizada atrav es do uso do endere co e m ascara de rede, informados no arquivo de congura c ao do RECON (exemplo no ap endice B.2). S ao apresentados os pacotes de erro associados aos dois IPs em quest ao, onde e identicado o tipo (unreachable ) e o c odigo (host ) da mensagem ICMP de erro. O identicador match icmp indica que o pacote de erro foi associado ao pacote gerador do erro, que no caso e ICMP. Ao nal, e apresentado um resumo com a dura c ao desde o recebimento do primeiro pacote at eou ltimo, e com a totaliza c ao dos pacotes para o tipo de mensagem de erro. O valor 0 associado ao identicador nomatch diz que todos os pacotes de erro foram associados aos pacotes geradores do erro. J a para o pr oximo exemplo, as mensagens ICMP de erro associadas ao dois IPs em quest ao n ao puderam ser associadas aos pacotes geradores dos erros. Este exemplo ilustra tamb em a ocorr encia de outro tipo de mensagem ICMP de erro: time exceeded.

1`

A partir daqui estes nomes ser ao chamados de endere cos IP.

126

[ ext_host (o) <=> int_router (i) ] ICMP Error packets pkt 1 (<-) 04:20:08.192937 time exceeded - time exceeded in-transit (no match udp) \ [len 56 id 33050 ttl 64] pkt 2 (<-) 04:20:12.830695 time exceeded - time exceeded in-transit (no match udp) \ [len 56 id 33052 ttl 64] pkt 3 (<-) 04:20:13.124671 time exceeded - time exceeded in-transit (no match udp) \ [len 56 id 33053 ttl 64] pkt 4 (<-) 04:20:20.201846 unreachable - host (no match udp) [len 56 id 33054 ttl 64] pkt 5 (<-) 04:20:20.202369 unreachable - host (no match udp) [len 56 id 33055 ttl 64] pkt 6 (<-) 04:20:27.203321 unreachable - host (no match udp) [len 56 id 33092 ttl 64] pkt 7 (<-) 04:20:27.203839 unreachable - host (no match udp) [len 56 id 33093 ttl 64] pkt 8 (<-) 04:20:34.204790 unreachable - host (no match udp) [len 56 id 33094 ttl 64] pkt 9 (<-) 04:20:34.205316 unreachable - host (no match udp) [len 56 id 33095 ttl 64] ------------------duration ............: 04:20:08.192937 - 04:20:34.205316 - diff = 26s 012379ms , 9 packets. unreachable .........: type 3 - 6 packets, 6 nomatch time exceeded .......: type 11 - 3 packets, 3 nomatch

6.4.2

Sess oes ICMP de Informa c ao

A sa da tcpdump abaixo apresenta pacotes ICMP de informa c ao do tipo echo, trocados entre um host interno e um host externo.
04:41:54.737443 04:41:54.739418 04:41:54.884732 04:41:54.885131 04:41:55.030296 04:41:55.030752 ext_host int_host ext_host int_host ext_host int_host > > > > > > int_host: ext_host: int_host: ext_host: int_host: ext_host: icmp: icmp: icmp: icmp: icmp: icmp: echo echo echo echo echo echo request seq 0 (ttl 50, id 44206, len 64) reply seq 0 (ttl 253, id 28110, len 64) request seq 256 (ttl 50, id 44212, len 64) reply seq 256 (ttl 253, id 28111, len 64) request seq 512 (ttl 50, id 44219, len 64) reply seq 512 (ttl 253, id 28112, len 64)

Ap os a execu c ao do RECON com a op c ao -I, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado.
[ ext_host (o) <=> int_host (i) ] ICMP Info sessions session 1 [ echo ] id 31346 (->) 04:41:54.737443 request seq 0 [len 64 id 44206 ttl 50] (<-) 04:41:54.739418 reply seq 0 [len 64 id 28110 ttl 253] (->) 04:41:54.884732 request seq 256 [len 64 id 44212 ttl 50] (<-) 04:41:54.885131 reply seq 256 [len 64 id 28111 ttl 253] (->) 04:41:55.030296 request seq 512 [len 64 id 44219 ttl 50] (<-) 04:41:55.030752 reply seq 512 [len 64 id 28112 ttl 253] ---------------duration ......: 04:41:54.737443 - 04:41:55.030752 - diff = 293309ms attributes ....: none match_reply ...: 0 payload rcvd ..: (ext_host) 120 bytes , (int_host) 120 bytes , biggest packet (36) , 6 packets.

O exemplo mostra que a primeira sess ao ICMP de informa c ao, associada aos dois IPs em quest ao, e do tipo echo e foi identicada pelo id 31346, observado nos pacotes ICMP 127

associados. Os pacotes s ao apresentados e diferenciados entre requisi c oes e respostas. Ao nal, e apresentado um resumo com a dura c ao da sess ao, atributos associados, diferen ca entre requisi c oes e respostas (match reply ) e totaliza c ao dos pacotes e dados trocados entre os dois IPs. J a o pr oximo exemplo apresenta uma sess ao ICMP de informa c ao, onde as respostas para os pacotes de requisi c ao n ao foram observadas. No m das linhas que apresentam as informa c oes dos pacotes, foram adicionados os identicadores missed e unreachable, que informam que pacotes ICMP de erro foram associados aos pacotes originais. No resumo da sess ao e apresentado o n umero total de pacotes associados a pacotes ICMP de erro.
[ ext_host (o) <=> int_host (i) ] ICMP Info sessions session 1 [ echo ] id 3909 (->) 04:44:27.475093 request seq 20562 [len 40 id (->) 04:44:31.604885 request seq 14425 [len 40 id (->) 04:44:35.549194 request seq 38495 [len 40 id (->) 04:44:41.603269 request seq 41576 [len 40 id ---------------duration ......: 04:44:27.475093 - 04:44:41.603269 attributes ....: none match_reply ...: 4 icmp error ....: 4 pkts payload rcvd ..: (ext_host) 0 bytes , (int_host) 0

48919 22399 55774 36198

ttl ttl ttl ttl

1] 2] 3] 3]

(missed) (missed) (unreach) (unreach)

- diff = 14s 128176ms

bytes , biggest packet (12) , 4 packets.

6.5

IP DESFRAGMENTAC AO

A sa da tcpdump abaixo apresenta uma sequ encia de pacotes ICMP fragmentados, que constituem uma comunica c ao entre dois hosts. Pode-se observar que o u ltimo pacote apresentado e um ICMP de erro, do tipo ip reassembly time exceeded, informando que ou ltimo datagrama IP n ao p ode ser remontado.
16:52:20.920219 16:52:20.920345 16:52:20.920464 16:52:24.248155 16:52:24.249390 16:52:24.249469 16:52:31.290616 16:52:31.290741 16:52:31.290839 16:52:35.827423 16:52:35.828658 16:52:35.828731 16:52:39.679566 16:52:39.679691 16:52:39.679796 16:53:41.372333 < < < < < < < < < < < < < < < < host-a host-a host-a host-b host-b host-b host-a host-a host-a host-b host-b host-b host-a host-a host-a host-b > > > > > > > > > > > > > > > > host-b: host-b: host-b: host-a: host-a: host-a: host-b: host-b: host-b: host-a: host-a: host-a: host-b: host-b: host-b: host-a: (frag (frag icmp: icmp: (frag (frag (frag (frag icmp: icmp: (frag (frag (frag (frag icmp: icmp: 9383:48@2960) 9383:1480@1480+) echo request (frag 9383:1480@0+) echo reply (frag 25558:1480@0+) 25558:1480@1480+) 25558:48@2960) 9384:48@2960) 9384:1480@1480+) echo request (frag 9384:1480@0+) echo reply (frag 25942:1480@0+) 25942:1480@1480+) 25942:48@2960) 9385:48@2960) 9385:1480@1480+) echo request (frag 9385:1480@0+) ip reassembly time exceeded

128

Quando o RECON e executado com a op c ao -F, e apresentada a tabela de fragmentos, a partir da arvore bin aria de desfragmenta c ao implementada pela ferramenta, gerando assim o seguinte resultado:
================================================================== | Fragment Table | +----------------+ [ host-a > host-b ] defrag. 1 - 16:52:20.920219 - frags 3 holes 0 ICMP id 9383 len 3028 state ( reassembled ) frag. 1 -> [offset = 0] [len = 1480] frag. 2 -> [offset = 1480] [len = 1480] frag. 3 -> [offset = 2960] [len = 48] defrag. 2 - 16:52:31.290616 - frags 3 holes 0 ICMP id 9384 len 3028 state ( reassembled ) frag. 1 -> [offset = 0] [len = 1480] frag. 2 -> [offset = 1480] [len = 1480] frag. 3 -> [offset = 2960] [len = 48] defrag. 3 - 16:52:39.679566 - frags 3 holes 0 ICMP id 9385 len 3028 state ( time_exceeded ) frag. 1 -> [offset = 0] [len = 1480] frag. 2 -> [offset = 1480] [len = 1480] frag. 3 -> [offset = 2960] [len = 48] [ host-b > host-a ] defrag. 1 - 16:52:24.248155 - frags 3 holes 0 ICMP id 25558 len 3028 state ( reassembled ) frag. 1 -> [offset = 0] [len = 1480] frag. 2 -> [offset = 1480] [len = 1480] frag. 3 -> [offset = 2960] [len = 48] defrag. 2 - 16:52:35.827423 - frags 3 holes 0 ICMP id 25942 len 3028 state ( reassembled ) frag. 1 -> [offset = 0] [len = 1480] frag. 2 -> [offset = 1480] [len = 1480] frag. 3 -> [offset = 2960] [len = 48]

Os fragmentos foram agrupados de acordo com a dire c ao em que foram enviados. Ent ao, tem-se um conjunto de fragmentos que v ao do host-a para o host-b, e outro do hostb para o host-a. Dentro de cada um destes grupos, os fragmentos s ao organizados em elementos de desfragmenta c ao, identicados pelo id, que e comum a cada conjunto de fragmentos relacionados. Ent ao, para cada elemento de desfragmenta c ao e informado o hor ario do primeiro fragmento observado, o n umero de fragmentos, se h a espa cos entre os fragmentos, o protocolo utilizado, o tamanho total do datagrama e o estado da desfragmenta c ao. Nos casos onde o estado e reassembled, o fragmento foi completamente remontado e foi inserido em uma sess ao v alida. No caso em que o estado da desfragmenta c ao e time exceeded, uma situa c ao interessante ocorreu. Os tr es fragmentos que comp oem o elemento de desfragmenta c ao em quest ao ocorreram antes da mensagem de erro associada, como observado na sa da tcpdump. Portanto, antes da mensagem de erro ser processada, o datagrama IP foi dado como remontado e inserido em uma sess ao v alida. Ap os a an alise da mensagem de erro, realizada pelo processador ICMP de erro, o estado do elemento de desfragmenta c ao foi atualizado para time exceeded, o pacote remontado foi removido da sess ao onde foi inserido, e ajustes necess arios na sess ao em quest ao foram realizados. 129

O resultado destas opera c oes e ilustrado nas estat sticas apresentadas abaixo, geradas na an alise do tr afego em quest ao.
================================================================== | ICMP Numbers | +--------------+ ... ICMP messages - time exceeded in frag. 1 ------------ICMP packets inserted in the model 4 - Info messages Requisition ICMP info packets 2 Reply ICMP info packets 2 - Error messages ... ICMP time exceeded in frag. (no match) 0 ==================================================================

Um problema conhecido do processo de desfragmenta c ao IP est a associado ` a fragmenta c ao do cabe calho da camada de transporte. O processador IP, ao observar um pacote desta natureza, ir a descart a-lo, eliminando assim a possibilidade deste ser remontado. Apesar de algumas implementa co es da pilha TCP/IP n ao permitirem este tipo de pacote, isto n ao e regra e, portanto, aperfei coamentos na implementa c ao do RECON ser ao necess arios. Esta proposta e apresentada no cap tulo 7. 6.6 DAS SESSOES RECONSTRUC AO UDP

A sa da tcpdump abaixo apresenta uma sequ encia de pacotes UDP, associados ao servio SNMP (se c c ao 2.7), trocados entre um host interno e um roteador externo. Pode-se observar que os pacotes s ao identicados como requisi c oes ou respostas.
04:00:04.246473 int_snmp_mon.56682 > border_router.161: { SNMPv1 [|snmp]} 04:00:04.363584 border_router.161 > int_snmp_mon.56682: { SNMPv1 [|snmp]} ... 04:55:04.657942 int_snmp_mon.60154 > border_router.161: { SNMPv1 [|snmp]} 04:55:04.747432 border_router.161 > int_snmp_mon.60154: { SNMPv1 [|snmp]} { } { } { } { } GetRequest(11) R=1850734177 \ (DF) (ttl 251, id 40245, len 133) GetResponse(9) R=1850734177 \ (ttl 252, id 15830, len 173) GetRequest(11) R=95081423 \ (DF) (ttl 251, id 63825, len 133) GetResponse(9) R=95081423 \ (ttl 252, id 15841, len 173)

Ap os a execu c ao do RECON com a op c ao -U, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado:

130

[ border_router (o) <=> int_snmp_mon (i) ] UDP sessions session 1 [ 161 <=> 56682 ] (<-) 04:00:04.246473 udp 113 (105) [ip - hd_len 20 len 133 id 40245 ttl 251] (->) 04:00:04.363584 udp 153 (145) [ip - hd_len 20 len 173 id 15830 ttl 252] --------------duration .....: 04:00:04.246473 - 04:00:04.363584 - diff = 117111ms payload rcvd .: (border_router) 105 bytes, (int_snmp_mon) 145 bytes, biggest packet (145), 2 packets. ... session 12 [ 161 <=> 60154 ] (<-) 04:55:04.657942 udp 113 (105) [ip - hd_len 20 len 133 id 63825 ttl 251] (->) 04:55:04.747432 udp 153 (145) [ip - hd_len 20 len 173 id 15841 ttl 252] --------------duration .....: 04:55:04.657942 - 04:55:04.747432 - diff = 089490ms payload rcvd .: (border_router) 105 bytes, (int_snmp_mon) 145 bytes, biggest packet (145), 2 packets.

Os pacotes associados aos dois IPs em quest ao foram agrupados em sess oes, identicadas pelo par de portas comum a cada pacote UDP. Para cada pacote e informado o tamanho total da mensagem UDP, incluindo seu cabe calho e, entre par enteses, a quantidade de bytes que comp oe seu conte udo. Ao nal de cada sess ao e apresentado um resumo com a dura c ao da sess ao e a totaliza c ao dos pacotes e dados trocados entre os dois IPs. Deve-se observar que n ao e feita distin c ao entre pacotes de requisi c ao e resposta. Estas informa c oes s ao encontradas no conte udo da mensagem UDP e, com exce c ao das aplica c oes de DNS e NTP, n ao s ao tratadas pela ferramenta. Todas as sess oes UDP associadas a outras portas de servi ` cos, mas an alogas ` a apresentada anteriormente, s ao processadas da mesma forma. J a as sess oes UDP, associadas aos servi cos de DNS e NTP, recebem um tratamento diferenciado. A sa da tcpdump abaixo apresenta uma sequ encia de pacotes trocados entre um host interno e um servidor de DNS externo.
12:10:37.263680 12:10:37.263709 12:10:37.330077 12:10:37.338636 int_host.1365 > int_host.1365 > ext_dns_serv.53 ext_dns_serv.53 ext_dns_serv.53: ext_dns_serv.53: > int_host.1365: > int_host.1365: 37416 [1au][|domain] 58597 [1au][|domain] 37416-[|domain] (ttl 58597-[|domain] (ttl (ttl 63, id 21374, len 74) (ttl 63, id 21375, len 76) 55, id 36215, len 149) 55, id 36216, len 155)

Ap os a execu c ao do RECON, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado:

131

[ int_host (i) <=> ext_dns_serv (o) ] UDP sessions session 1 [ 1365 <=> 53 ] (->) 12:10:37.263680 udp 54 (46) [dns request - id 37416] [ip - hd_len 20 len 74 id 21374 ttl 63] (->) 12:10:37.263709 udp 56 (48) [dns request - id 58597] [ip - hd_len 20 len 76 id 21375 ttl 63] (<-) 12:10:37.330077 udp 129 (121) [dns reply - id 37416] [ip - hd_len 20 len 149 id 36215 ttl 55] (<-) 12:10:37.338636 udp 135 (127) [dns reply - id 58597] [ip - hd_len 20 len 155 id 36216 ttl 55] --------------duration .....: 12:10:37.263680 - 12:10:37.338636 - diff = 074956ms attributes ...: none match_reply ..: 0 payload rcvd .: (int_host) 248 bytes , (ext_dns_serv) 94 bytes , biggest packet (127) , 4 packets.

Os pacotes UDP associados aos dois IPs foram agrupados em uma sess ao, identicada pelo par de portas comum a cada pacote. A diferen ca aqui vem do conhecimento espec co, associado ` a forma de comunica c ao da aplica c ao de DNS. Sabe-se que os dois primeiros bytes do conte udo do pacote s ao utilizados para diferenciar entre requisi c ao e resposta e para identicar e associar cada requisi c ao a sua respectiva resposta. Portanto, cada pacote da sess ao apresenta o id da mensagem UDP de DNS e informa se esta e uma requisi c ao ou resposta. Ao nal, e apresentado um resumo da sess ao, com sua dura c ao, atributos associados, diferen ca entre pacotes de requisi c ao e resposta (match reply ) e a totaliza c ao dos pacotes e dados trocados entre os dois IPs. Para o caso das sess oes UDP associadas ao servi co de NTP, o tratamento e an alogo. A sa da tcpdump abaixo apresenta uma sequ encia de pacotes trocados entre dois hosts, utilizando o servi co em quest ao.
01:10:02.421237 01:10:02.421532 ... 01:16:07.810014 01:16:07.815641 ... < int_ntp_p1.123 > int_ntp_p2.123: v4 client strat 4 (ttl 64, id 22803) < int_ntp_p2.123 > int_ntp_p1.123: v4 server strat 3 (ttl 64, id 3484) < int_ntp_p2.123 > int_ntp_p1.123: v3 sym_act strat 3 (ttl 64, id 19352) < int_ntp_p1.123 > int_ntp_p2.123: v3 sym_pas strat 4 (ttl 64, id 33990)

Ap os a execu c ao do RECON, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado:

132

[ int_ntp_p1 (i) <=> int_ntp_p2 (i) ] UDP sessions session 1 [ 123 <=> 123 ] (->) 01:10:02.421237 udp 56 (48) [ntp - v4 client] [ip - hd_len 20 len 76 id 22803 ttl 64] (<-) 01:10:02.421532 udp 56 (48) [ntp - v4 server] [ip - hd_len 20 len 76 id 3484 ttl 64] (<-) 01:16:07.810014 udp 56 (48) [ntp - v3 symmetric active] [ip - hd_len 20 len 76 id 19352 ttl 64] (->) 01:16:07.815641 udp 56 (48) [ntp - v3 symmetric passive] [ip - hd_len 20 len 76 id 33990 ttl 64] ... --------------duration .....: 01:10:02.421237 - 14:55:19.817520 - diff = 13h 45m 17s 396283ms attributes ...: none match_reply ..: 0 payload rcvd .: (int_ntp_p1) 4704 bytes, (int_ntp_p2) 4704 bytes, biggest packet (48), 196 packets.

Os pacotes UDP associados aos dois IPs foram agrupados em uma sess ao, identicada pelo par de portas comum a cada pacote. Sabe-se que o primeiro byte do conte udo do pacote e utilizado para identicar o modo de opera c ao do pacote e para diferenciar entre requisi c ao e resposta. Portanto, cada pacote da sess ao apresenta o modo de opera c ao da mensagem UDP de NTP. Os modos client e symmetric active est ao associados ` a requisi c oes, e os modos server e symmetric passive ` a respostas. Ao nal, e apresentado um resumo da sess ao, com sua dura c ao, atributos associados, diferen ca entre pacotes de requisi c ao e resposta (match reply ) e a totaliza c ao dos pacotes e dados trocados entre os dois IPs. 6.7 DAS SESSOES RECONSTRUC AO TCP

A sa da tcpdump abaixo apresenta uma sequ encia de pacotes t pica em uma conex ao bidirecional TCP, trocados entre um host externo e um servidor interno.
04:28:00.942144 ext_host.61183 > int_smtp_serv.25: S 365735391:365735391(0) win 24820 \ (DF) (ttl 48, id 52574, len 48) 04:28:00.943500 int_smtp_serv.25 > ext_host.61183: S 1881033246:1881033246(0) ack 365735392 win 16560 (DF) (ttl 62, id 4311, len 44) 04:28:01.135432 ext_host.61183 > int_smtp_serv.25: . ack 1881033247 win 24840 \ (DF) (ttl 48, id 52575, len 40) 04:28:01.489202 int_smtp_serv.25 > ext_host.61183: P 1881033247:1881033278(31) ack 365735392 win 16560 \ (DF) (ttl 62, id 12319, len 71) 04:28:01.680527 ext_host.61183 > int_smtp_serv.25: . ack 1881033278 win 24840 \ (DF) (ttl 48, id 52578, len 40) ... 04:28:02.624829 int_smtp_serv.25 > ext_host.61183: P 1881033415:1881033453(38) ack 365742172 win 16560 \ (DF) (ttl 62, id 12673, len 78) 04:28:02.625069 int_smtp_serv.25 > ext_host.61183: F 1881033453:1881033453(0) ack 365742172 win 16560 \ (DF) (ttl 62, id 17737, len 40) 04:28:02.817370 ext_host.61183 > int_smtp_serv.25: . 1881033454 win 24840 \ (DF) (ttl 48, id 52601, len 40) 04:28:02.817399 ext_host.61183 > int_smtp_serv.25: F 365742172:365742172(0) ack 1881033453 win 24840 \ (DF) (ttl 48, id 52600, len 40) 04:28:02.818360 int_smtp_serv.25 > ext_host.61183: . ack 365742173 win 16560 \ (DF) (ttl 62, id 23176, len 40)

133

Ap os a execu c ao do RECON com a op c ao -T, sobre o tr afego que cont em os pacotes apresentados, o seguinte resultado foi gerado:
[ ext_host (o) <=> int_smtp_server (i) ] TCP sessions session 1 [ 61183 (c) <=> 25 (s) ] (->) 04:28:00.942144 S 365735391:365735391(0) ack 0 win 24820 [len 48 id 52574 ttl 48] (<-) 04:28:00.943500 SA 1881033246:1881033246(0) ack 365735392 win 16560 [len 44 id 4311 ttl 62] (->) 04:28:01.135432 A 365735392:365735392(0) ack 1881033247 win 24840 [len 40 id 52575 ttl 48] (<-) 04:28:01.489202 AP 1881033247:1881033278(31) ack 365735392 win 16560 [len 71 id 12319 ttl 62] (->) 04:28:01.680527 A 365735392:365735392(0) ack 1881033278 win 24840 [len 40 id 52578 ttl 48] ... (<-) 04:28:02.624829 AP 1881033415:1881033453(38) ack 365742172 win 16560 [len 78 id 12673 ttl 62] (<-) 04:28:02.625069 AF 1881033453:1881033453(0) ack 365742172 win 16560 [len 40 id 17737 ttl 62] (->) 04:28:02.817370 A 365742173:365742173(0) ack 1881033454 win 24840 [len 40 id 52601 ttl 48] (->) 04:28:02.817399 AF 365742172:365742172(0) ack 1881033453 win 24840 [len 40 id 52600 ttl 48] (<-) 04:28:02.818360 A 1881033454:1881033454(0) ack 365742173 win 16560 [len 40 id 23176 ttl 62] ---------------state .........: Fin2 Closed Ok duration ......: 04:28:00.942144 - 04:28:02.818360 - diff = 01s 876216ms attributes ....: none payload rcvd ..: (ext_host) 206 bytes, (int_smtp_server) 6780 bytes , \ biggest packet (1380) , 24 packets.

Os pacotes TCP associados aos dois IPs foram agrupados em uma sess ao, identicada pelo par de portas comum a cada pacote. Os identicadores (c) e (s), que aparecem logo ap os as portas, mostram que primeiro par <IP,porta> e o cliente na sess ao, e que o segundo par corresponde ao servidor. Foi poss vel realizar esta identica c ao, pois o threeway handshake est a presente no in cio da sess ao. S ao apresentados, para cada pacote associado ` a sess ao, os ags ativos, sequence number, acknowledge number e o window size. Ao nal, e apresentado um resumo da sess ao, seu estado nal, dura c ao, atributos associados e a totaliza c ao dos pacotes e dados trocados entre os dois IPs. Para este exemplo, o estado nal da sess ao indica o t ermino normal da sess ao, caracterizado pela sequ encia de pacotes FIN1, ACK, FIN2, ACK. Deve-se observar que a retransmiss ao dos pacotes FIN n ao inuenciou no estado nal determinado. Os pr oximos exemplos caracterizam outras situa c oes relevantes, e apresentam sess oes com diferentes estados terminais. O quadro abaixo apresenta uma sess ao TCP, onde seu estado nal determina o t ermino simult aneo da sess ao, caracterizado pela sequ encia de pacotes FIN1, FIN2, ACK, ACK. O nome Simultaneous Fin1 dado ao estado deve-se ao fato do u ltimo ACK da sess ao estar associado ao primeiro FIN.

134

[ ext_host (o) <=> int_smtp_serv (i) ] TCP sessions session 1 [ 14323 (c) <=> 25 (s) ] (->) 04:42:16.196996 S 1687056646:1687056646(0) ack 0 win 16384 [len 60 id 29103 ttl 47] (<-) 04:42:16.198029 SA 4294966272:4294966272(0) ack 1687056647 win 33580 [len 48 id 36793 ttl 58] (->) 04:42:16.384472 A 1687056647:1687056647(0) ack 4294966273 win 17520 [len 40 id 29813 ttl 47] (<-) 04:42:22.214794 AP 4294966273:4294966357(84) ack 1687056647 win 33580 [len 124 id 36810 ...] (->) 04:42:22.401051 A 1687056647:1687056647(0) ack 4294966357 win 17436 [len 40 id 48594 ttl 47] ... (<-) 04:42:28.928780 AP 4294966771:4294966813(42) ack 1687068518 win 33580 [len 82 id 36826 ...] (<-) 04:42:28.929985 AF 4294966813:4294966813(0) ack 1687068518 win 33580 [len 40 id 36827 ttl 58] (->) 04:42:29.114862 A 1687068518:1687068518(0) ack 4294966813 win 17478 [len 40 id 3502 ttl 47] (->) 04:42:29.116175 AF 1687068518:1687068518(0) ack 4294966813 win 17520 [len 40 id 3507 ttl 47] (->) 04:42:29.116305 AF 1687068518:1687068518(0) ack 4294966814 win 17520 [len 40 id 3510 ttl 47] (<-) 04:42:29.116901 AF 4294966813:4294966813(0) ack 1687068519 win 33580 [len 40 id 36828 ttl 58] (<-) 04:42:29.117162 A 4294966814:4294966814(0) ack 1687068519 win 33580 [len 40 id 36829 ttl 58] (->) 04:42:29.302867 A 1687068519:1687068519(0) ack 4294966814 win 17520 [len 40 id 4156 ttl 47] ---------------state .........: Simultaneous Fin1 Closed Ok duration ......: 04:42:16.196996 - 04:42:29.302867 - diff = 13s 105871ms attributes ....: none payload rcvd ..: (ext_host) 540 bytes, (int_smtp_serv) 11871 bytes , \ biggest packet (1460) , 39 packets.

No quadro seguinte, o estado nal determina tamb em o t ermino simult aneo da sess ao TCP, mas o nome Simultaneous Fin2 dado ao estado deve-se ao fato do u ltimo ACK da sess ao estar associado ao segundo FIN. Uma caracter stica desta sess ao e que o ACK para o primeiro FIN faz parte do pacote que cont em o segundo FIN. E, portanto, n ao inuenciou no estado nal da sess ao. Tamb em pode-se observar a ocorr encia do atributo Cold Start e a n ao determina c ao do cliente e servidor da sess ao, devido a aus encia de todo o three-way handshake. Esta situa c ao ocorre quando o sistema de captura falha na coleta de pacotes ou mesmo quando estes est ao contidos no arquivo da hora anterior.
[ ext_ftp_serv (o) <=> int_host (i) ] TCP sessions session 1 [ 21 <=> 42582 ] (<-) 04:00:03.112594 A 235869536:235869536(0) ack 234991991 win 5840 [len 52 id 55350 ttl 62] (<-) 04:00:03.225639 AP 235869536:235869555(19) ack 234991991 win 5840 [len 71 id 55351 ttl 62] (->) 04:00:03.374717 AP 234991991:234992066(75) ack 235869555 win 32120 [len 127 id 20899 ttl 48] ... (->) 04:00:32.444908 AP 234992090:234992104(14) ack 235869561 win 32120 [len 66 id 26418 ttl 48] (->) 04:00:32.445378 AF 234992104:234992104(0) ack 235869561 win 32120 [len 52 id 26419 ttl 48] (<-) 04:00:32.446454 A 235869561:235869561(0) ack 234992104 win 5840 [len 52 id 55355 ttl 62] (<-) 04:00:32.446516 AF 235869561:235869561(0) ack 234992105 win 5840 [len 52 id 55356 ttl 62] (->) 04:00:32.663171 A 234992105:234992105(0) ack 235869562 win 32120 [len 52 id 26422 ttl 48] ---------------state .........: Simultaneous Fin2 Closed Ok duration ......: 04:00:03.112594 - 04:00:32.663171 - diff = 29s 550577ms attributes ....: Cold_Start payload rcvd ..: (ext_ftp_serv) 25 bytes, (int_host) 113 bytes , biggest packet (75) , 12 packets.

135

Na sa da mostrada abaixo, a sess ao TCP foi terminada normalmente, mas o atributo Cold Start est a presente. O cliente e o servidor da sess ao puderam ser determinados pois, apesar do primeiro pacote do three-way handshake ter sido perdido, o pacote SYN/ACK (SA) p ode ser observado.
[ int_host (i) <=> ext_web_serv (o) ] TCP sessions session 1 [ 3369 (c) <=> 8080 (s) ] (<-) 12:00:05.134030 SA 13545257:13545257(0) ack 3455609422 win 1460 [len 48 id 47002 ttl 117] (->) 12:00:05.136451 A 3455609422:3455609422(0) ack 13545258 win 17520 [len 40 id 44737 ttl 127] (->) 12:00:05.137337 AP 3455609422:3455609725(303) ack 13545258 win 17520 [len 343 id 44738 ...] (<-) 12:00:05.352495 AP 13545258:13545378(120) ack 3455609725 win 8457 [len 160 id 47770 ttl 117] (<-) 12:00:05.352605 AF 13545378:13545378(0) ack 3455609725 win 8457 [len 40 id 48026 ttl 117] (->) 12:00:05.353264 A 3455609725:3455609725(0) ack 13545379 win 17400 [len 40 id 44739 ttl 127] (->) 12:00:05.355022 AF 3455609725:3455609725(0) ack 13545379 win 17400 [len 40 id 44740 ttl 127] (<-) 12:00:05.582214 A 13545379:13545379(0) ack 3455609726 win 8457 [len 40 id 48282 ttl 117] ---------------state .........: Fin2 Closed Ok duration ......: 12:00:05.134030 - 12:00:05.582214 - diff = 448184ms attributes ....: Cold_Start payload rcvd ..: (int_host) 120 bytes, (ext_web_serv) 303 bytes , biggest packet (303) , 8 packets.

J a para a situa c ao ilustrada abaixo, o estado nal determina o t ermino abrupto da sess ao, caracterizado pela ocorr encia do pacote RST. Deve-se observar que a retransmiss ao do pacote RST foi associada a esta mesma sess ao.
[ ext_ftp_serv (o) <=> int_host (i) ] TCP sessions session 1 [ 21 <=> 1178 ] (<-) 12:00:30.067065 AF 970217047:970217047(0) ack 2811158358 win 15372 [len 40 id 4601 ttl 127] (->) 12:00:30.527401 A 2811158358:2811158358(0) ack 970217048 win 24840 [len 40 id 29242 ttl 46] (->) 12:00:30.527424 AP 2811158358:2811158395(37) ack 970217048 win 24840 [len 77 id 29243 ttl 46] (->) 12:00:30.527453 AF 2811158395:2811158395(0) ack 970217048 win 24840 [len 40 id 29244 ttl 46] (<-) 12:00:30.542158 R 970217048:970217048(0) ack 4100948994 win 0 [len 40 id 4603 ttl 127] (<-) 12:00:30.542225 R 970217048:970217048(0) ack 970217048 win 0 [len 40 id 4604 ttl 127] ---------------state .........: Reset Closed Ok duration ......: 12:00:30.067065 - 12:00:30.542225 - diff = 475160ms attributes ....: Cold_Start payload rcvd ..: (ext_ftp_serv) 0 bytes, (int_host) 37 bytes , biggest packet (37) , 6 packets.

E nalmente, no quadro abaixo, o estado nal da sess ao mostra que esta n ao foi terminada, provavelmente porque os pacotes relativos a seu t ermino foram armazenados em algum arquivo subsequente.

136

[ ext_ftp_serv (o) <=> int_host (i) ] TCP sessions session 1 [ 21 (s) <=> 1651 (c) ] (<-) 12:45:43.451144 S 3663629258:3663629258(0) ack 0 win 16384 [len 48 id 10124 ttl 125] (->) 12:45:43.602494 SA 2585636504:2585636504(0) ack 3663629259 win 5840 [len 48 id 0 ttl 46] (<-) 12:45:43.603723 A 3663629259:3663629259(0) ack 2585636505 win 17520 [len 40 id 10125 ttl 125] (->) 12:45:43.752914 AP 2585636505:2585636547(42) ack 3663629259 win 5840 [len 82 id 37372 ttl 46] (<-) 12:45:43.757569 AP 3663629259:3663629274(15) ack 2585636547 win 17478 [len 55 id 10126 ...] ... (->) 12:57:02.805034 AP 2585641646:2585641662(16) ack 3663631084 win 5840 [len 56 id 37584 ttl 46] (<-) 12:57:02.805914 A 3663631084:3663631084(0) ack 2585641662 win 16785 [len 40 id 12390 ttl 125] ---------------state .........: Open duration ......: 12:45:43.451144 - 12:57:02.805914 - diff = 11m 19s 354770ms attributes ....: none payload rcvd ..: (ext_ftp_serv) 1825 bytes, (int_host) 5157 bytes , \ biggest packet (87) , 374 packets.

6.8

` DETECC DE INTRUSAO ATIVIDADES RELACIONADAS A AO

Esta se c ao apresenta os resultados obtidos, atrav es da execu c ao do RECON, na sua aplica c ao para a detec c ao de intrus ao. Foram utilizadas informa c oes geradas pelas arvores bin arias de logs TCP e de desfragmenta c ao, e por algumas rotinas implementadas e integradas ao RECON. 6.8.1 A Arvore de Logs TCP

A arvore de logs TCP tem como nalidade armazenar pacotes TCP em duas situa c oes: os que n ao foram associados a alguma sess ao e os associados a alguma sess ao, mas que apresentaram um comportamento n ao esperado. Nesta u ltima situa c ao, onde o pacote de log faz parte de uma sess ao, s ao observados os ags e o momento em que o pacote em quest ao foi associado a uma determinada sess ao. Por exemplo, um pacote com os ags PSH e ACK ativos, contendo dados e associado a uma sess ao onde o three-way handshake ainda n ao tenha sido conclu do. E na primeira situa c ao, s ao observados os pacotes que apresentam uma combina c ao ou aus encia de ags, de modo que n ao devem ser respons aveis pela cria c ao de uma nova sess ao. Este tipo de pacote normalmente est a associado a varreduras (scans), consideradas pela comunidade de seguran ca como precursoras de ataques ou intrus oes. Como visto na se c ao 5.3.12, as ocorr encias relacionadas ao uso destes pacotes s ao conhecidas como atividades stealth. Atualmente, existe uma grande variedade de ferramentas que geram tais pacotes. Os intrusos normalmente fazem uso destas ferramentas para investigar se um determinado 137

servi co est a ativo em um ou mais hosts, e at e mesmo para descobrir que sistemas operacionais est ao sendo executados nos hosts investigados (Fyodor, 2002b). Um bom exemplo e a ferramenta de varredura de rede nmap (network mapper) desenvolvida por Fyodor (2002a). A grande maioria dos pacotes TCP, analisados pelo RECON durante todo o per odo em que o tr afego de rede foi examinado e que foram associados ` a arvore de logs TCP, se enquadraram na primeira situa c ao. O RECON foi executado com a op c ao -l, para apresentar os logs de forma colapsada, mas devido ao grande n umero de ocorr encias deste tipo, alguns resultados foram compilados em uma u nica sa da, apresentada abaixo, de modo a exemplicar a maioria dos casos observados no per odo em quest ao.
[ host-a - host-k ] 09:04:59.554629 (73 -> 1438) : P 5242941:5242953(12) ack 4032219641 win 20496 - \ vecna sth act (no session). [ host-b - host-n ] 09:18:23.197408 (21 -> 1078) : SAPRUF 36306988:36306992(4) ack 2193322316 win 20496 - \ fxmas tree sth act (no session). 09:22:01.512284 (234 -> 1116) : 1PU 5242930:5242942(12) ack 1549244900 win 20484 - \ unknown sth act (no session). [ host-c - host-p ] 10:16:22.750380 (52558 -> 53) : PUF 1150218965:1150218965(0) ack 0 win 3072 - \ nmap xmas tree sth act (no session). (repeated 3 times) [ host-d - host-x ] 13:14:56.050751 (0 -> 2901) : F 5243167:5243175(8) ack 1733885952 win 20496 - \ fin sth act (no session). [ host-e - host-y ] 13:52:10.857162 (0 -> 2142) : SAPU 5243017:5243057(40) ack 1768544445 win 20496 - \ sin/ack/push/urg sth act (no session). [ host-a - host-w ] 15:17:52.517083 (4 -> 1375) : 12SPUF 5242907:5242911(4) ack 1104258650 win 20496 - \ unknown sth act (no session). [ host-c - host-z ] 16:02:36.896668 (50832 -> 7) : SPUF 2300745433:2300745433(0) ack 0 win 4096 - \ unknown sth act (no session). 16:02:36.896908 (50836 -> 1) : PUF 2300745433:2300745433(0) ack 0 win 4096 - \ nmap xmas tree sth act (no session). {rst} 16:02:38.895885 (50831 -> 7) : . 2300745433:2300745433(0) ack 0 win 4096 - \ nxmas tree sth act (no session). (repeated 2 times)

No quadro acima, o pacote enviado do host-a para o host-k apresenta apenas o ag PSH ativo. Este pacote gerou o log que caracteriza a atividade stealth intitulada vecna. Pacotes com apenas os ags URG ou PSH/FIN ou URG/PSH s ao caracterizados da mesma forma. No primeiro pacote do host-b para o host-n todos os ags est ao ativos. Este gerou o log que caracteriza a atividade stealth intitulada full christmas tree. No pacote enviado do host-c para o host-p os ags PSH/URG/FIN est ao ativos. Este 138

gerou o log que caracteriza a atividade stealth intitulada nmap christmas tree e indica o prov avel uso da ferramenta nmap. Tamb em ilustra a apresenta c ao colapsada de pacotes associados a um mesmo tipo de log, onde repeated 3 times diz que mais tr es pacotes com as mesmas caracter sticas foram enviados. No pacote enviado do host-d para o host-x apenas o ag FIN est a ativo. Este gerou o log que caracteriza a atividade stealth intitulada n. No pacote enviado do host-e para o host-y os ags SYN/ACK/PSH/URG est ao ativos. Este gerou o log que caracteriza a atividade stealth intitulada sapu. No segundo pacote do host-c para o host-z, o {rst} no nal da linha diz que um pacote de RST foi enviado como resposta ao pacote que gerou o log em quest ao. E na u ltima linha, o pacote n ao cont em ags ativos, o que caracteriza a atividade stealth intitulada null christmas tree. E nalmente, os pacotes que geraram logs de eventos que caracterizam atividades stealth do tipo unknown, est ao associados a combina c oes de ags n ao conhecidas pelo processador de pacotes TCP. 6.8.2 Alertas da Arvore de Desfragmenta c ao

A execu c ao do RECON com a op c ao -f faz com que as entradas na arvore de desfragmenta c ao, associadas a algum alerta, sejam apresentadas nos resultados gerados para o tr afego de rede analisado, caso ocorram. O resultado apresentado abaixo ilustra uma situa c ao, onde uma sequ encia de fragmentos, ao serem remontados, disparou um alerta indicando a ocorr encia de uma sobreposi c ao. Este alerta e gerado atrav es da verica c ao dos atributos associados ` a entrada na arvore de desfragmenta c ao e que, para este caso, indica o alerta OVERLAP.
================================================================== | Fragment Table | +----------------+ [ host-a > host-b ] defrag. 1 - 17:49:12.283209 - frags 9 holes 0 ICMP id 42949 len 84 state ( reassembled ) attributes ( OVERLAP ) ==================================================================

Ao executar o RECON com a op c ao -F, sobre o mesmo tr afego de rede, esta entrada na arvore de desfragmenta c ao e apresentada de forma mais detalhada, onde pode-se observar a sobreposi c ao do fragmento de oset igual a 48.

139

================================================================== | Fragment Table | +----------------+ [ host-a > host-b ] defrag. 1 - 17:49:12.283209 - frags 9 holes 0 ICMP id 42949 len 84 state ( reassembled ) attributes ( OVERLAP ) frag. 1 -> [offset = 0] [len = 8] frag. 2 -> [offset = 8] [len = 8] frag. 3 -> [offset = 16] [len = 8] frag. 4 -> [offset = 24] [len = 8] frag. 5 -> [offset = 32] [len = 8] frag. 6 -> [offset = 40] [len = 8] frag. 7 -> [offset = 48] [len = 8] frag. 8 -> [offset = 48] [len = 8] frag. 9 -> [offset = 56] [len = 8] ==================================================================

A sa da tcpdump associada a este caso e apresentada abaixo.

17:49:12.283209 17:49:12.335185 17:49:12.336641 17:49:12.337812 17:49:12.338090 17:49:12.338295 17:49:12.338506 17:49:12.338708 17:49:12.338894 host-a host-a host-a host-a host-a host-a host-a host-a host-a > > > > > > > > > host-b: host-b: host-b: host-b: host-b: host-b: host-b: host-b: host-b: icmp: (frag (frag (frag (frag (frag (frag (frag (frag echo request (frag 42949:8@0+) 42949:8@8+) 42949:8@16+) 42949:8@24+) 42949:8@32+) 42949:8@40+) 42949:8@48+) 42949:8@48+) 42949:8@56)

Segundo Ptacek e Newsham (1998), esta t ecnica de ataque pode ser utilizada para tentar iludir um sistema de detec c ao de intrus ao, pois este pode remontar o datagrama de uma forma completamente diferente da adotada pelo sistema nal, para onde os fragmentos foram direcionados. O fato e que a fragmenta c ao de um datagrama com sobreposi c ao (overlaping) de osets constitui uma atividade maliciosa, que n ao ocorre na utiliza c ao normal de um sistema e, portanto, foi detectada e registrada pelo RECON. 6.8.3 Detec c ao de Host Scans

Normalmente, intrusos realizam varreduras (scans) para identicar hosts ativos em um ou mais dom nios, ou mesmo para identicar se um determinado servi co est a sendo oferecido nos hosts investigados. Estas atividades fazem parte do processo malicioso de obten c ao de informa c oes, e t em como principal nalidade direcionar os ataques a serem realizados pelos intrusos. Apesar dos resultados gerados a partir da arvore de logs TCP, vistos na se c ao 6.8.1, indicarem na maioria dos casos atividades relacionadas a varreduras, estes n ao est ao 140

associados a sess oes estabelecidas. Portanto, faz-se necess ario vericar tais atividades nas sess oes reconstru das pelo RECON. Baseado nestas id eias, uma rotina foi implementada e integrada ao RECON, no intuito de detectar estas atividades maliciosas e, normalmente, precursoras de ataques. A rotina utiliza a arvore bin aria de IPs e as listas de adjac encias associadas, geradas ap os o processamento do tr afego de rede. Para cada endere co IP da arvore e vericado o n umero de elementos na sua lista de adjac encias. Caso este n umero seja igual ou maior que um limiar, as pr oximas verica c oes s ao realizadas. Para facilitar o entendimento, seja IP1 o endere co IP identicado pelo n o da arvore, e IPn (n = 1) os endere cos IP referenciados na lista de adjac encias de IP1 . Verica-se se o mesmo tipo de sess ao ICMP de informa c ao ocorreu entre cada par [IP1 , IPn ] levando em considera c ao a dire c ao. Neste caso, as requisi c oes devem partir do IP1 para cada IPn . Se a contagem destas ocorr encias exceder o limiar pr e-estabelecido, uma linha e acrescentada aos resultados, contendo o IP1 , origem do scan, o n umero de destinos acessados e o recurso utilizado, por exemplo, echo/icmp. Tamb em verica-se se sess oes TCP ocorreram entre cada par [IP1 , IPn ] levando em considera c ao a dire c ao. Neste caso, as sess oes devem ter sido iniciadas pelo IP1 e a porta de destino deve ser igual para cada IPn . Se a contagem destas ocorr encias for igual ou maior que o limiar, uma linha e acrescentada aos resultados, contendo o IP1 , origem do scan, o n umero de destinos acessados e o recurso utilizado, no formato porta/tcp. S ao utilizados os seguintes par ametros, que devem estar presentes no arquivo de congura c ao do RECON (ver ap endice B.2): FIND HOST SCAN: este par ametro diz para o RECON que a busca por varreduras de hosts deve ser realizada; IN HOST SCAN THRESHOLD e OUT HOST SCAN THRESHOLD: estes dois par ametros informam limiares a serem vericados, e que reduzem as buscas sobre a arvore bin aria de IPs. Est ao relacionados ao acesso de um host interno para a rede externa, e ao acesso de um host externo para a rede monitorada, respectivamente. Estes limiares foram congurados para alertar ocorr encias, onde um host acessou pelo menos 10 destinos diferentes. Alguns dos resultados mais relevantes, obtidos da execu c ao do RECON sobre o tr afego de rede para todo o per odo em que este foi testado, s ao apresentados. Em cada linha onde e informada a dire c ao (direction) dos acessos, isto e, se 141

estes partiram de dentro da rede monitorada para fora, ou de fora para dentro, a dire c ao observada foi editada e removida.
================================================================== | Host Scan Logs | +----------------+ direction source IP num. dests resource ----------------------------------------------********* host-a 20 00113 / tcp ********* host-b 31 00113 / tcp ********* host-c 268 00025 / tcp ********* host-d 14 00113 / tcp ********* host-e 11 00025 / tcp ********* host-f 20 00025 / tcp ********* host-g 12 00113 / tcp ********* host-h 20 00113 / tcp ********* host-i 10 00025 / tcp ********* host-j 25 00025 / tcp ********* host-k 14 00113 / tcp ********* host-l 21 00025 / tcp ********* host-m 18 00025 / tcp ********* host-n 3964 echo / icmp ==================================================================

Au ltima linha do resultado apresentado indica que o host-n acessou 3964 hosts distintos, no intervalo de uma hora, atrav es da utiliza c ao de mensagens ICMP do tipo echo. Esta ocorr encia caracteriza a utiliza c ao de uma das t ecnicas de varredura mais triviais, onde o objetivo e descobrir quais hosts est ao ativos em um ou mais dom nios. A linha de maior relev ancia corresponde aos acessos do host-c a 286 hosts distintos, na porta 25/tcp. Esta porta e normalmente utilizada por servidores de SMTP, no envio e recebimento de mensagens de correio eletr onico. Esta atividade ocorreu durante 40 horas consecutivas, com picos de 586, 665, 702 e 807 acessos a hosts distintos, em horas e dias diferentes. As sess oes correspondentes aos acessos observados foram reconstru das, atrav es da execu c ao do RECON com a op c ao -t, de modo que uma sa da resumida fosse apresentada. Parte da comunica c ao entre o host-c e um dos hosts acessados e mostrado logo abaixo.
[ smtp-serv-n <=> host-c ] TCP sessions session 1 [ 25 (s) <=> 4876 (c) ] -> duration ( 12:00:19.243924 attributes ( none ), \ payload rcvd ( smtp-serv-n session 2 [ 25 (s) <=> 4916 (c) ] -> duration ( 12:01:56.290414 attributes ( Syn_RST ), \ payload rcvd ( smtp-serv-n ...

state ( Fin2_Closed ), \ - 12:00:20.736278 - diff = 01s 492354ms ), - 133 b , host-c - 336 b , biggest packet 100 , 20 packets ). state ( Rst_Closed ), \ - 12:01:56.469436 - diff = 179022ms ), \ - 0 b , host-c - 0 b , biggest packet 0 , 2 packets ). continua...

142

... session 10 [ 25 (s) <=> 1155 (c) ] -> state ( Rst_Closed ), \ duration ( 12:06:46.154101 - 12:06:46.333630 - diff = 179529ms ), \ attributes ( Syn_RST ), \ payload rcvd ( smtp-serv-n - 0 b , host-c - 0 b , biggest packet 0 , 2 packets ). ...

O host-c inicia uma sess ao com o smtp-serv-n na porta 25/tcp. Dados s ao enviados e recebidos e a sess ao e terminada. Em um curto intervalo de tempo uma tentativa de abertura de sess ao e realizada, mas a porta 25/tcp encontra-se indispon vel. Este comportamento e repetido por v arias vezes. Pode-se observar que h a uma lacuna entre o n umero da porta utilizada pelo host-c na primeira sess ao e na tentativa de abertura da segunda sess ao. Isto ocorreu porque v arias outras sess oes estavam sendo abertas com os outros hosts. Ent ao, foi caracterizado que os hosts n ao estavam suportando o grande n umero de tentativas de abertura de sess oes. N ao havia uma grande varia c ao nos hosts acessados em diferentes horas, e as sess oes apresentavam as mesmas caracter sticas. Houve, ent ao, o forte ind cio de que o host-c estava realizando uma varredura, mas sendo utilizado para enviar mensagens de correio eletr onico com propagandas comerciais, conhecidas como SPAM. O administrador da rede onde estava localizado o host-c foi contactado, e p ode-se comprovar que este disponibilizava um servi co HTTP com uma funcionalidade mal congurada, e que permitia o envio indiscriminado de mensagens de correio eletr onico. Este servi co estava sendo explorado e utilizado em tais atividades. As outras ocorr encias mostradas no quadro com o host scan anterior estavam associadas ao envio normal de mensagens de correio eletr onico de um servidor SMTP para outros na porta 25/tcp, e a identica c ao de usu ario normalmente realizada em aplica c oes de FTP, atrav es da utiliza c ao da porta 113/tcp. Uma possibilidade para retirar estas ocorr encias dos resultados e a cria ca o de uma lista de servidores conhecidos, associados ` a portas conhecidas, com limiares espec cos. Estes limiares podem ser estabelecidos atrav es da pr opria an alise dos resultados gerados pelo RECON, caracterizando assim um perl de comportamento esperado para estes servidores. Outro resultado relevante observado durante o per odo em que o RECON foi testado e apresentado a seguir:

143

================================================================= | Host Scan Logs | +----------------+ direction source IP num. dests resource ----------------------------------------------********* host-p 391 01214 / tcp ********* host-q 81 04662 / tcp ********* host-r 201 01214 / tcp ==================================================================

As portas 1214/tcp (catalogada em IANA (2002)) e 4662/tcp s ao relacionadas ` a aplica c oes p2p, normalmente, associadas ao compartilhamento de arquivos mp3 atrav es da rede. A natureza destas aplica c oes justica o grande n umero de acessos observados no resultado anterior, sendo que estes ocorreram de forma an aloga durante todo o per odo em que o RECON analisou o tr afego de rede. A quest ao e que a utiliza c ao destes tipos de servi co pode n ao estar em conformidade com a pol tica de uso adequado das redes e sistemas de informa c ao de uma organiza c ao, e s ao conhecidos por consumirem uma grande quantidade de recursos da rede onde est ao sendo disponibilizados. Apesar de n ao indicarem uma varredura, estes resultados fornecem boas fontes de informa c ao relacionadas a utiliza c ao da rede em quest ao. Atualmente, ferramentas para a realiza c ao de varreduras espec cas v em sendo amplamente utilizadas, onde estas procuram identicar a vers ao do servi co (aplica c ao) executado em uma determinada porta TCP. Existem v arios servi cos que enviam no primeiro pacote contendo dados, ap os o estabelecimento da conex ao, informa c oes que indicam seu nome e sua vers ao (banner). Um intruso, de posse destas informa c oes, pode utilizar em um ataque a ferramenta certa, desenvolvida para explorar uma vulnerabilidade conhecida e relacionada a uma vers ao espec ca do servi co. Este tipo de varredura e conhecido como banner scan. Baseado nestas id eias, foi acrescentado ` a implementa c ao da rotina de detec c ao de varreduras de hosts do RECON um conjunto de verica c oes adicionais para dois servi cos espec cos: o FTP e o SSH. A implementa c ao deste conjunto de verica c oes baseou-se em duas ferramentas: o ftpscan2 e o scanssh3 . Estas duas ferramentas estabelecem uma conex ao com a porta 21/tcp e 22/tcp, respectivamente, e ap os receberem as informa c oes de nome e vers ao do servi co, abortam a conex ao, enviando um pacote de RST, ou fazem um encerramento normal. Portanto, para detectar estas varreduras o limiar especicado anteriormente continua sendo utilizado, mas para acessos destinados ` as portas 21/tcp e 22/tcp o n umero de pacotes enviados do
2 3

Pode ser encontrado em: http://www.secureaustin.com/nlog/nlog-1.6.0/tools/. Pode ser encontrado em: http://http://monkey.org/~provos/scanssh/.

144

servidor para o host em quest ao e avaliado. Retransmiss oes s ao checadas e descartadas da contagem, caso ocorram. S ao utilizados os seguintes par ametros, que devem estar presentes no arquivo de congura c ao do RECON (ver ap endice B.2): FIND HOST SCAN WITH BANNER: este par ametro diz para o RECON que a busca por varreduras de hosts deve ser realizada, mas com a checagem adicional em busca de banner scans para as portas 21/tcp e 22/tcp; FTP BANNER PKTS FROM SERVER: este par ametro indica qual e o n umero de pacotes contendo o banner, enviados do servidor FTP para o host; SSH BANNER PKTS FROM SERVER: este par ametro indica qual e o n umero de pacotes contendo o banner, enviados do servidor SSH para o host; O par ametro que indica o n umero de pacote enviados pelo servidor e congurado para 2 no caso do FTP e para 1 no caso do SSH. Estes valores foram determinados, atrav es da avalia c ao do tr afego gerado na utiliza c ao das ferramentas ftpscan e scanssh, tomadas como base para o desenvolvimento das verica c oes adicionais. O sa da abaixo, gerada pelo RECON, ilustra uma das situa c oes onde foi realizada uma varredura do tipo banner scan para o servi co de FTP, detectada pela rotina implementada.
================================================================== | Host Scan Logs | +----------------+ direction source IP num. dests resource banner grab. sessions ------------------------------------------------------------------********* scanner-host 156 00021 / tcp 82 ==================================================================

O resultado apresentado diz que scanner-host acessou 156 hosts distintos na porta 21/tcp no intervalo de uma hora e, destes 156 acessos, 82 foram caracterizados como sess oes de varredura para obten c ao de banner. As sess oes TCP, relacionadas scanner-host e ` a porta 21/tcp foram reconstru das, atrav es da execu c ao do RECON com a op c ao -t, gerando assim uma sa da resumida. Parte desta sa da e apresentada a seguir:

145

[ host-x <=> scanner-host ] TCP sessions session 1 [ 21 (s) <=> 1760 (c) ] -> state ( Rst_Closed ), \ duration ( 01:16:16.424417 - 01:16:16.584467 - diff = 160050ms ), \ attributes ( Syn_RST ), \ payload rcvd ( host-x - 0 b , scanner-host - 0 b , biggest packet 0 , 2 packets ). session 2 [ 21 (s) <=> 1760 (c) ] -> state ( Rst_Closed ), \ duration ( 01:16:17.305382 - 01:16:17.464738 - diff = 159356ms ), \ attributes ( Syn_RST ), \ payload rcvd ( host-x - 0 b , scanner-host - 0 b , biggest packet 0 , 2 packets ). ... ... [ ftp-serv-w <=> scanner-host ] TCP sessions session 1 [ 21 (s) <=> 1245 (c) ] -> state ( Rst_Closed ), \ duration ( 01:13:47.307012 - 01:13:51.093051 - diff = 03s 786039ms ), \ attributes ( none ), \ payload rcvd ( ftp-serv-w - 0 b , scanner-host - 79 b , biggest packet 42 , 9 packets ). ... ...

As sess oes 1 e 2 entre o scanner-host e host-x mostram que a porta 21/tcp do hostx n ao estava aberta. O atributo Syn RST indica que um pacote RST foi enviado em resposta ao pacote SYN do scanner-host. E a sess ao 1 entre o scanner-host e ftp-serv-w mostra que a porta 21/tcp do ftpserv-w estava aberta, a sess ao foi criada e 79 bytes foram recebidos pelo scanner-host. A sa da mais detalhada, gerada pela execu c ao do RECON com a op c ao -T para esta u ltima sess ao e apresentada abaixo.
[ ftp-serv-w <=> scanner-host ] TCP sessions session 1 [ 21 (s) <=> 1245 (c) ] (<-) 01:13:47.307012 S 50527054:50527054(0) ack 0 win 8192 [ip - hd_len 20 len 48 ...] (->) 01:13:47.613496 SA 914461385:914461385(0) ack 50527055 win 5840 [ip - hd_len 20 len 48 ...] (<-) 01:13:48.109228 A 50527055:50527055(0) ack 914461386 win 8576 [ip - hd_len 20 len 40 ...] (<-) 01:13:48.121909 AF 50527055:50527055(0) ack 914461386 win 8576 [ip - hd_len 20 len 40 ...] (->) 01:13:48.426781 A 914461386:914461386(0) ack 50527056 win 5840 [ip - hd_len 20 len 40 ...] (->) 01:13:50.695368 AP 914461386:914461428(42) ack 50527056 win 5840 [ip - hd_len 20 len 82 ...] (->) 01:13:50.695428 APF 914461428:914461465(37) ack 50527056 win 5840 [ip - hd_len 20 len 77 ...] (<-) 01:13:51.080727 R 50527056:50527056(0) ack 3762913726 win 0 [ip - hd_len 20 len 40 ...] (<-) 01:13:51.093051 R 50527056:50527056(0) ack 50527056 win 0 [ip - hd_len 20 len 40 ...] ---------------state .........: Reset Closed Ok duration ......: 01:13:47.307012 - 01:13:51.093051 - diff = 03s 786039ms attributes ....: none payload rcvd ..: (ftp-serv-w) 0 bytes, (scanner-host) 79 bytes , biggest packet (42) , 9 packets.

Pode-se observar que os 79 bytes recebidos pelo scanner-host prov eem de 2 pacotes enviados pelo ftp-serv-w. Em seguida a sess ao e abortada pelo scanner-host. 146

Um exemplo de outro caso observado nos resultados gerados pelo RECON, onde foi detectada uma varredura do tipo banner scan para o servi co de SSH, e apresentado logo abaixo.
================================================================== | Host Scan Logs | +----------------+ direction source IP num. dests resource banner grab. sessions ------------------------------------------------------------------********* scanner-host 19 00022 / tcp 2 ==================================================================

O resultado apresentado diz que scanner-host acessou 19 hosts distintos na porta 22/tcp no intervalo de uma hora e, destes 19 acessos, 2 foram caracterizados como sess oes de varredura para obten c ao de banner. A sa da mais detalhada, gerada pela execu c ao do RECON com a op c ao -T para uma das sess oes que caracterizou o banner scan, e apresentada abaixo.
[ ssh-serv-y <=> scanner-host ] TCP sessions session 1 [ 22 (s) <=> 1552 (c) ] (<-) 16:56:38.345818 S 1720751383:1720751383(0) ack 0 win 32120 [ip - hd_len 20 len 60 ...] (->) 16:56:38.346875 SA 2097474906:2097474906(0) ack 1720751384 win 5792 [ip - hd_len 20 len 60 ..] (<-) 16:56:38.347000 A 1720751384:1720751384(0) ack 2097474907 win 32120 [ip - hd_len 20 len 52 ..] (->) 16:56:38.357915 AP 2097474907:2097474930(23) ack 1720751384 win 5792 [ip - hd_len 20 len 75 .] (<-) 16:56:38.358061 A 1720751384:1720751384(0) ack 2097474930 win 32120 [ip - hd_len 20 len 52 ..] (<-) 16:56:38.358556 AP 1720751384:1720751412(28) ack 2097474930 win 32120 [ip - hd_len 20 len 80.] (<-) 16:56:38.358666 AF 1720751412:1720751412(0) ack 2097474930 win 32120 [ip - hd_len 20 len 52 .] (->) 16:56:38.359660 A 2097474930:2097474930(0) ack 1720751412 win 5792 [ip - hd_len 20 len 52 ...] (->) 16:56:38.362873 AF 2097474930:2097474930(0) ack 1720751413 win 5792 [ip - hd_len 20 len 52 ..] (<-) 16:56:38.363052 A 1720751413:1720751413(0) ack 2097474931 win 32120 [ip - hd_len 20 len 52 ..] ---------------state .........: Simultaneous Fin2 Closed Ok duration ......: 16:56:38.345818 - 16:56:38.363052 - diff = 017234ms attributes ....: none payload rcvd ..: (ssh-serv-y) 28 bytes, (scanner-host) 23 bytes , biggest packet (28) , 10 packets.

Pode-se observar que os 23 bytes recebidos pelo scanner-host prov eem de 1 u nico pacote enviado pelo ssh-serv-y. Em seguida, a sess ao e terminada pelo scanner-host. O pacote enviado do scanner-host para o ssh-serv-y n ao inuencia na detec c ao. 6.8.4 Investiga c ao do Uso de ICMP/Echo

Sabe-se que o tr afego ICMP, do tipo echo, e intensivamente utilizado em redes, baseadas na pilha de protocolos TCP/IP, para gerenciamento, testes e an alise de desempenho destas redes. Normalmente, e encapsulado no pacote ICMP de requisi c ao uma sequ encia de bytes aleat oria, e esta mesma sequ encia e retornada no pacote de resposta. Portanto, 147

os pacotes t em conte udos semelhantes. A quest ao e que estes conte udos e mesmo seus tamanhos normalmente n ao s ao checados. Uma ferramenta desenvolvida para explorar esta lacuna (LOKI), utiliza pacotes deste tipo, para enviar e receber informa c oes arbitr arias, caracterizando assim o uso de um t unel, ou covert channel. Assim, comandos do sistema podem ser enviados em pacotes ICMP de requisi c ao, de modo que o resultado da execu c ao destes comandos e retornado em mensagens ICMP de resposta. Baseado nestas id eias, uma rotina foi implementada e integrada ao RECON, no intuito de detectar este uso indevido, que na maioria dos casos, indica a invas ao e o comprometimento de um sistema. A rotina busca por diferen cas no tamanho dos conte udos enviados nos pacotes de requisi c ao e recebidos nos pacotes de resposta, para as sess oes ICMP reconstru das ` a partir do tr afego de rede analisado. Seu desenvolvimento foi baseado na ferramenta LOKI4 (daemon9, 1996) (daemon9, 1997). S ao utilizados os seguintes par ametros, que devem estar presentes no arquivo de congura c ao do RECON (ver ap endice B.2): DETECT COVERT CHANNELS: este par ametro diz para o RECON que as sess oes ICMP do tipo echo devem ser checadas, em busca da utiliza c ao de t uneis. COVERT CHANNELS REQ REPLY DIFF: este par ametro e utilizado para reduzir as buscas nas sess oes ICMP reconstru das. Por exemplo, se o valor a ele associado for igual a 1, nenhuma sess ao ICMP com o n umero de pacotes de requisi c ao igual ao n umero de pacotes de resposta ser a checada. Para os casos onde a diferen ca entre respostas e requisi c oes for pelo menos igual a 1, a checagem e realizada. O resultado gerado pelo RECON, e apresentado abaixo, ilustra uma detec c ao deste g enero.
================================================================== | ICMP/Echo Investigation | +-------------------------+ IPs: host-a <=> host-b - init 18:55:36.251989 , end 18:55:37.249949 resource [ ICMP/Echo ] , id [ 15726 ] , excd. replies [ 2 ] , attributes [ none ] WARNING: different payload lenghts for icmp packets. ==================================================================

Implementa c ao pode ser encontrada em: http://www.phrack.org.

148

Para avaliar mais detalhadamente a sess ao associada ` a detec c ao apresentada, o RECON foi executado com a op c ao -I, sobre o mesmo tr afego. O resultado e apresentado logo abaixo.
[ host-a <=> host-b ] ICMP Info sessions session 1 [ echo ] id 15726 (<-) 18:55:36.251989 request seq 0 [ip - hd_len 20 len 84 id 52337 ttl 64] [icmp - type 8 code 0] (->) 18:55:36.253330 reply seq 0 [ip - hd_len 20 len 84 id 64434 ttl 255] [icmp - type 0 code 0] (->) 18:55:37.249121 reply seq 0 [ip - hd_len 20 len 100 id 52339 ttl 64] [icmp - type 0 code 0] (->) 18:55:37.249949 reply seq 0 [ip - hd_len 20 len 86 id 64435 ttl 255] [icmp - type 0 code 0] ---------------duration ......: 18:55:36.251989 - 18:55:37.249949 - diff = 997960ms attributes ....: none match_reply ...: -2 payload rcvd ..: (hoat-a) 128 bytes , (host-b) 114 bytes , \ biggest packet (72) , 4 packets.

Pode-se observar que o primeiro pacote de resposta cont em o mesmo tamanho do pacote de requisi c ao, mas os pacotes de resposta subsequentes, apesar de terem o mesmo id e n umero de sequ encia (seq) do pacote de requisi c ao, apresentam tamanhos diferentes. Apesar desta rotina detectar o uso indevido das mensagens ICMP do tipo echo, n ao h a impedimentos para o uso de outros tipos de mensagens ICMP de informa c ao, portanto a rotina de detec c ao deve ser extendida para abranger outros casos. 6.8.5 Detec c ao de Ferramentas Automatizadas para a Cria c ao de Backdoors

Para concretizar o comprometimento de um sistema e necess aria a realiza c ao de um conjunto de opera c oes. Estas opera c oes, normalmente, iniciam com a varredura de um dom nio ou sistema, em busca de uma vulnerabilidade conhecida, a escolha de um ou mais hosts-alvo, e a realiza c ao do ataque para este(s) host(s). Caso o ataque seja bem sucedido, o intruso normalmente habilita uma porta no sistema comprometido, onde e executado um servi co que permite a sua volta, sem que o ataque tenha que ser realizado novamente. Esta porta habilitada pelo intruso e conhecida como backdoor. Atualmente, estes ataques est ao se tornando mais sosticados, de modo que existem ferramentas que realizam todas essas opera c oes de forma automatizada. Algumas destas ferramentas apresentam o seguinte comportamento: testam se a porta onde o backdoor ser a instalado est a habilitada; caso n ao esteja, realizam o ataque na porta onde o servi co vulner avel est a sendo executado; habilitam a backdoor, e realizam uma conex ao na backdoor, onde uma s erie de atividades s ao executadas no host rec em-comprometido. Uma caracter stica marcante das atividades realizadas por estas ferramentas e que todas as opera c oes descritas no par agrafo acima s ao realizadas em curto intervalo de tempo, na 149

maioria dos casos dentro de um mesmo segundo. Baseado nestas id eias, uma rotina foi implementada e integrada ao RECON, no intuito de detectar o uso destas ferramentas. Esta rotina busca por duas sess oes TCP, abertas concomitantemente ou em um curto intervalo de tempo, e checa se uma tentativa de conex ao com a segunda porta foi realizada antes do in cio das sess oes. Esta checagem e realizada para cada par de endere cos IP, onde existam sess oes TCP associadas. S ao utilizados os seguintes par ametros, que devem estar presentes no arquivo de congura c ao do RECON (ver ap endice B.2): DETECT BACKDOORS: este par ametro diz para o RECON que as sess oes TCP reconstru das devem ser checadas, em busca da detec c ao de backdoors; BACKDOOR TIME TOLERANCE: este par ametro e utilizado para indicar o intervalo de tempo a ser checado, em segundos, entre a primeira conex ao e a segunda, caso a primeira tenha sido terminada antes do in cio da segunda. O sa da gerada pelo RECON, e apresentada abaixo, ilustra algumas situa c oes deste g enero, detectadas pela rotina implementada. Cada linha onde e informada a dire c ao (direction ) dos acessos, isto e, se estes partiram de dentro da rede monitorada para fora, ou de fora para dentro, foi editada e a dire c ao observada foi removida.
================================================================== | TCP Backdoor Detection for Automated Tools | +--------------------------------------------+ direction: ****** PROBE : host-a (34230) -> host-d [10007] - state (Reset Closed Ok) - attr. ( Syn_RST ) \ - init 14:02:46.095267 , end 14:02:55.890798 access : host-a (34277) -> host-d (10002) - state (Fin2 Closed Ok) - attr. ( none ) \ - init 14:02:59.147389 , end 14:02:59.452274 backdoor : host-a (34281) -> host-d [10007] - state (Reset Closed Ok) - attr. ( none ) \ - init 14:02:59.584230 , end 14:02:59.931630 ================================================================== ================================================================== | TCP Backdoor Detection for Automated Tools | +--------------------------------------------+ direction: ****** PROBE : host-a (53889) -> host-d [08888] - state (Reset Closed Ok) - attr. ( Syn_RST ) \ - init 15:01:35.799028 , end 15:01:44.288762 access : host-a (53902) -> host-d (00443) - state (Fin2 Closed Ok) - attr. ( none ) \ - init 15:01:47.872501 , end 15:03:13.874060 backdoor : host-a (53973) -> host-d [08888] - state (Fin2 Closed Ok) - attr. ( none ) \ - init 15:03:10.301851 , end 15:03:14.570973 ================================================================== continua...

150

================================================================== | TCP Backdoor Detection for Automated Tools | +--------------------------------------------+ direction: ****** PROBE : host-b (01590) -> host-c [05443] - state (Reset Closed Ok) - attr. ( Syn_RST ) \ - init 15:42:43.926817 , end 15:42:43.931631 access : host-b (01667) -> host-c (00443) - state (Fin2 Closed Ok) - attr. ( none ) \ - init 15:55:43.612203 , end 15:55:52.817577 backdoor : host-b (01668) -> host-c [05443] - state (Fin2 Closed Ok) - attr. ( none ) \ - init 15:55:49.818310 , end 15:55:53.825410 ==================================================================

O RECON foi, ent ao, utilizado para avaliar as sess oes TCP correspondentes ` as detec c oes apresentadas e ap os uma an alise aprofundada destas sess oes, p ode-se observar que os hosts para onde os acessos foram direcionados executavam aplica c oes HTTP nas portas que foram acessadas. Estas aplica c oes apresentaram um comportamento semelhante ao das ferramentas de ataque para as quais a rotina foi desenvolvida. Isto caracteriza um falso-positivo gerado pela rotina. Detec c oes de eventos realmente associados a invas oes n ao puderam ser observados durante todo o per odo em que o RECON foi executado. Este fato indica que a rotina apresenta um alto ndice de falso-positivos. Al em disso, o fato da rotina estar baseada apenas no per odo de ocorr encia dos acessos ` as portas n ao e suciente para concluir, detectar e alertar que o tipo de ferramenta de ataque, objetivo de seu desenvolvimento, foi utilizada para realizar tais acessos. H a, ent ao, a necessidade de realizar um estudo mais aprofundado destas ferramentas e do tipo de tr afego de rede que elas geram, para que outros par ametros possam ser associados a rotina de detec ` c ao, e os falso-positivos sejam reduzidos ou at e eliminados.

151

152

CAP ITULO 7 CONCLUSOES Este trabalho apresentou um sistema baseado em um modelo de reconstru c ao de sess oes TCP/IP, que faz uso dos cabe calhos de pacotes extra dos do tr afego de redes. Os resultados obtidos a partir do RECON indicam que e vi avel utilizar um n umero reduzido de informa c oes por pacote obtido do tr afego de redes TCP/IP, e a partir da associ a-las de modo que estas representem, na forma de sess oes, o uxo de dados observado. Mostrou tamb em possibilidades de aplica c oes desta metodologia em atividades relacionadas a detec ` c ao de intrus ao, onde a tomada de decis oes e realizada atrav es da an alise de um conjunto de informa c oes. Esta caracter stica fornece ao RECON a capacidade de detectar atividades hostis subversivas, que tentam iludir os sistemas de detec c ao. O RECON mostrou ser um sistema capaz de tratar uma quantidade consider avel de dados obtidos do tr afego de rede, visto que este utiliza um n umero reduzido de informa c oes obtidas de cada pacote. Al em disso, poucos recursos s ao exigidos de um equipamento executando o RECON, de modo que este tem um baixo custo atrelado. De maneira oposta, os sistemas de detec c ao de intrus ao comerciais atualmente dispon veis apresentam grandes exig encias relacionadas ` a aloca c ao de recursos, tratamento de dados e causam um grande impacto sobre a performance dos equipamentos envolvidos. Com rela c ao ` a extrapola c ao do conceito relacionado ` a sess ao, n ao houve grandes diculdades em sua aplica c ao para o protocolo ICMP, visto que seu cabe calho disp oe de campos bem denidos, com n umeros de identica c ao e sequ encia, que permitem distinguir os pacotes de diferentes sess oes. A maior diculdade ocorreu na identica c ao e distin c ao entre diferentes sess oes para o protocolo UDP. As informa c oes que comp oem os pacotes UDP e que s ao utilizadas na associa c ao de um conjunto de pacotes a uma mesma sess ao, fazem parte do conte udo da mensagem. Portanto, esta associa c ao depende de detalhes de implementa c ao dos protocolos da camada de aplica c ao. A diculdade, ent ao, est a na an alise dos v arios protocolos de aplica c ao dispon veis, onde faz-se necess ario identicar se o protocolo disponibiliza alguma informa c ao que possibilite esta associa c ao e se esta informa c ao est a contida na sequ encia de bytes capturados por pacote. Ao contr ario do que se pensava, para o protocolo TCP, que est a diretamente associado ao conceito de sess ao, algumas diculdades tamb em foram encontradas. Ap os exaustiva an alise do tr afego de redes TCP/IP, p ode-se observar uma grande varia c ao na combina c ao de ags dos pacotes, que s ao de fundamental import ancia para a distin c ao entre sess oes.

153

Desta forma, um grande n umero de possibilidades foi adicionado ao desenvolvimento do RECON, mas altera c oes ou inclus oes de novos casos ou casos n ao observados devem ser considerados. O desenvolvimento deste sistema resultou em uma ferramenta que pode ser aplicada n ao s o` a detec c ao de intrus oes, mas tamb em no gerenciamento, monitoramento e estudo do comportamento de redes de computadores. As pr oximas se c oes apresentam algumas sugest oes e propostas para a continua c ao destes estudos, bem como as considera c oes nais e contribui c oes deste trabalho. 7.1 SUGESTOES PARA TRABALHOS FUTUROS

Uma primeira sugest ao seria a de criar uma biblioteca de rotinas. O modelo para reconstru c ao de sess oes TCP/IP desenvolvido est a integrado a todos os outros m odulos que comp oem o RECON e constitui o n ucleo deste sistema. Portanto, a primeira necessidade para tornar este modelo independente de uma aplica c ao espec ca e transform a-lo em um biblioteca. A id eia e, ent ao, modicar as principais fun c oes respons aveis pela reconstru c ao das sess oes e criar uma API (Application Programming Interface), ou seja, uma interface para a programa c ao de aplica c oes que permita o desenvolvimento de diversas ferramentas, n ao s o para a detec c ao de intrus ao, mas tamb em para o monitoramento e estudo do comportamento de redes. Em seguida, s ao discutidas algumas propostas para o aperfei coamento de alguns dos m odulos de reconstru c ao de sess oes e rotinas aplicadas ` a detec c ao de atividades maliciosas, bem como para a expans ao do sistema desenvolvido. 7.1.1 Estruturas de Armazenamento do Tr afego de Rede

Os m odulos do RECON utilizam, al em das arvores bin arias, listas encadeadas para armazenar informa c oes. Pode-se considerar que a utiliza c ao destas listas e essencial em alguns casos, pois mant em a sequ encia associada ` a ocorr encia de eventos. Este e o caso da lista encadeada de pacotes, associada a cada sess ao reconstru da. Mas para os outros casos, tais como a lista de adjac encias dos n os da arvore de IPs, a lista de elementos de desfragmenta c ao e as listas de sess oes, pode-se substitu -las por arvores bin arias balanceadas. Esta altera c ao impacta diretamente no desempenho do sistema, pois sabe-se que as opera c oes de busca em uma arvore t em complexidade logar tmica, ao passo que as mesmas opera c oes em uma lista t em complexidade linear. Isto representa um ganho de tr es ordens de magnitude, em rela c ao a tais opera c oes.

154

7.1.2

M odulos Utilizados na Reconstru c ao de Sess oes

Apesar do RECON tratar uma grande quantidade de situa c oes que inuenciam na cria c ao e atualiza c ao dos dados de sess oes TCP/IP, ainda existem lacunas a serem preenchidas. Portanto, s ao feitas algumas sugest oes e propostas para seu aperfei coamento, de acordo com os m odulos respons aveis pela reconstru c ao das sess oes. O m odulo de processamento de pacotes, respons avel por tratar o cabe calho do protocolo da camada de enlace de dados, considera apenas pacotes utilizando o protocolo Ethernet. Prop oe-se, ent ao, a extens ao deste m odulo para o tratamento de outros protocolos desta camada. O m odulo de desfragmenta c ao, respons avel por remontar datagramas IP fragmentados, n ao trata o caso onde os dados do cabe calho da camada de transporte foram divididos. Logo, h a uma proposta para que este m odulo seja aperfei coado, de modo que permita remontar n ao s o o datagrama, mas tamb em o cabe calho da camada de transporte, caso seja poss vel e que possa alertar sobre tais ocorr encias. O m odulo respons avel pelo processamento das mensagens UDP realiza um tratamento diferenciado para os protocolos DNS e NTP da camada de aplica c ao. Nestes dois casos, s ao extra das do in cio do conte udo da mensagem UDP informa c oes que permitem vericar se o pacote e uma requisi c ao ou uma resposta. Existem outros protocolos da camada de aplica c ao que t em este mesmo comportamento e possibilitam o mesmo tipo de an alise. Portanto, sugere-se que rotinas para o tratamento de outros protocolos da camada de aplica c ao sejam agregadas ao RECON. E por m, o m odulo respons avel pelo processamento das mensagens TCP n ao checa o sequence number e o acknowledgement number de todo e qualquer pacote TCP. No sistema desenvolvido, estas verica c oes s ao realizadas a partir do momento em que e observado um pacote solicitando o t ermino de conex ao, ou para associar pacotes RST recorrentes ` as suas respectivas sess oes. O fato e que existem t ecnicas relacionadas ` a atividades hostis, para a subvers ao de sistemas de detec c ao de intrus ao, que manipulam os n umeros de sequ encia de pacotes TCP, e t em como nalidade realizar a sobreposi c ao de dados (Ptacek e Newsham, 1998). Desta forma, sugere-se que sejam armazenados em cada sess ao TCP os pr oximos sequence numbers esperados e os u ltimos acknowledgement numbers recebidos, associados aos dois IPs da sess ao. Estes n umeros poderiam ser checados e atualizados, ` a medida que pacotes TCP forem sendo processados, de modo que tais atividades hostis possam ser alertadas.

155

7.1.3

Rotinas para a Aplica c ao em Detec c ao de Intrus ao

Algumas rotinas para a aplica c ao em detec c ao de intrus ao foram desenvolvidas e integradas ao RECON, mas como observado, aperfei coamentos podem ser realizados e outros crit erios podem ser agregados ` a estas rotinas, no intuito de obter resultados mais apurados. A rotina respons avel pela detec c ao de host scans realiza as verica c oes nas sess oes TCP e ICMP reconstru das. Para o caso das sess oes TCP, n ao e feita a correla c ao com informac oes da arvore de logs TCP. Portanto, h a uma sugest ao para que estas sejam analisadas em conjunto, de modo a complementar os resultados gerados por esta rotina. Al em disso, h a a necessidade de cria c ao de uma lista de servidores internos ` a rede monitorada, associados a limiares espec cos, de forma que checagens diferenciadas sejam realizadas, reduzindo assim a ocorr encia de falso-positivos. E ainda h a a sugest ao de extens ao desta rotina para a checagem das sess oes UDP. Outra sugest ao refere-se ` a rotina de investiga c ao da utiliza c ao de mensagens ICMP do tipo echo. Atrav es do estudo dos outros tipos de mensagens ICMP de informa c ao, podese vericar a viabilidade de se extender as checagens realizadas pela rotina para abranger os outros tipos. Em rela c ao ` a rotina desenvolvida para a detec c ao de backdoors criados por ferramentas automatizadas, h a uma proposta para a realiza c ao de um estudo aprofundado acerca do funcionamento destas. Atrav es deste estudo, pode-se aperfei coar os crit erios utilizados na gera c ao de um alerta, de modo que os falso-positivos observados sejam reduzidos. E por m, sugere-se a cria c ao de uma rotina para checar as listas de pacotes ICMP de erro. Os resultados gerados por esta rotina podem fornecer uma rela c ao de endere cos IP da rede interna que possivelmente est ao sendo forjados (spoong). 7.2 CONSIDERAC OES FINAIS

De forma geral, entende-se que esta pesquisa forneceu uma contribui c ao para o desenvolvimento de aplica c oes em detec c ao de intrus ao, baseadas em uma abordagem alternativa e utilizando um n umero reduzido de recursos. Atrav es da aplica c ao de metodologias relativamente simples, tais como a associa c ao do conceito de grafos ao tr afego de redes, a utiliza c ao de arvores bin arias balanceadas, para melhorar o desempenho, e a extrapola c ao do conceito associado ` a sess ao, foi poss vel especicar, implementar e testar um novo modelo para fornecer meios de tratar um problema comum em muitas aplica c oes associadas ` a detec c ao de intrus ao, que e a tomada de decis oes baseadas em informa c oes

156

isoladas. Uma poss vel aplica c ao do sistema desenvolvido consiste em seu uso como uma ferramenta de an alise pos-mortem que atuaria de forma complementar com um sistema de detec c ao de intrus ao por padr ao intrusivo de tempo real, visto que permitiria detectar alguns tipos de ataques que, normalmente, n ao s ao observados pelo u ltimo. Isto seria feito por meio da correla c ao de pacotes e sess oes, algo que o Snort, por exemplo, n ao faz. Por este assunto ser extremamente abrangente, houve tamb em a preocupa c ao de que o desenvolvimento da pesquisa apresentada possa servir como refer encia para novos estudos nesta area. Com rela c ao ` as vantagens da modelagem e do sistema desenvolvido pode-se considerar que possibilita a redu c ao de falso-positivos e falso-negativos em aplica c oes de detec c ao de intrus ao, pois decis oes podem ser tomadas atrav es da an alise de um conjunto de eventos relacionados a uma ou mais sess oes, em contrapartida a eventos isolados. Desta forma, permite correlacionar informa c oes de um conjunto de sess oes na identica c ao de atividades hostis, que n ao podem ser observadas em uma u nica sess ao. Al em disso, o sistema trata uma quantidade relativamente grande de informa c oes, pois utiliza um n umero reduzido de dados por pacote. Tamb em pode ser utilizado no monitoramento e estudo do comportamento de redes TCP/IP e n ao necessita da aloca c ao de muitos recursos computacionais, portanto tem custo reduzido. Com rela c ao ` as desvantagens pode-se considerar que o sistema utiliza arquivos contendo o tr afego de rede e, portanto, n ao realiza a reconstru c ao e an alise das informa c oes em tempo real. Tamb em n ao realiza an alises sobre o conte udo dos pacotes, exceto para uma pequena por c ao dos dados nas mensagens do protocolo UDP. E para os exemplos de aplica c oes em detec c ao de intrus ao j a desenvolvidas, depende de pessoal especializado, pois a determina c ao de limiares a partir dos quais um alerta e gerado e de fundamental import ancia na redu c ao de falsos-positivos. Para nalizar, e importante ressaltar que a seguran ca de um sistema de informa c ao deve ser implementada em camadas, ou seja, atrav es de um conjunto de t ecnicas, procedimentos e mecanismos, envolvendo uma pol tica de seguran ca bem determinada e estabelecida para a organiza c ao, o treinamento adequado dos administradores, o uso e congura c ao apropriados dos sistemas computacionais, o comprometimento e conscientiza c ao dos usu arios, e mais...

157

158

 REFERENCIAS BIBLIOGRAFICAS Allen, J.; Christie, A.; Fithen, W.; McHugh, J.; Pickel, J.; Stoner, E. State of the practice of intrusion detection technologies. Pittsburgh: Carnegie Mellon University, 2000. 220 p. (CMU/SEI-99-TR-028). 28, 56 Amoroso, E. G. Intrusion detection: an introduction to internet surveillance, correlation, traps, trace-back, and response. New Jersey: Intrusion.Net Books, 1999. 218 p. 55 Anderson, D.; Frivold, T.; Valdes, A. Next-generation intrusion detection expert system (NIDES): a summary. Menlo Park: SRI International, 1995. 47 p. (SRI-CSL-95-07). 63 Anderson, J. P. Computer security threat monitoring and surveillance. Fort Washington: James P. Anderson Co., 1980. 53 p. (79F296400). 54, 55 Arkin, O. ICMP usage in scanning: the complete know-how. The Sys-Security Group [online]. <http://www.sys-security.com/archive/papers/ICMP_Scanning_v3.0.pdf>. July 2002. 36, 37 Bace, R.; Mell, P. Intrusion detection systems. Gaithersburg: National Institute of Standards and Technology, 2000. 51 p. (NIST-SP-800-31). 28, 56 Balasubramaniyan, J. S.; Garcia-Fernandez, J. O.; Isaco, D.; Spaord, E.; Zamboni, D. An architecture for intrusion detection using autonomous agents. West Lafayette: Purdue University, 1998. 19 p. (COAST-TR-98-05). 64 Cansian, A. M. Desenvolvimento de um sistema adaptativo de detec c ao de intrusos em redes de computadores. S ao Carlos. 154 p. Disserta c ao (Doutorado em F sica Aplicada) Universidade de S ao Paulo, 1997. 68 Carstens, T. Programming with pcap. [online]. <http://www.tcpdump.org/pcap.htm>. July 2002. 92 Case, J.; Fedor, M.; Schostall, M.; Davin, J. A simple network management protocol (SNMP). Request for Comments RFC 1157. [online]. <http://www.rfc-editor.org/rfc/rfc1157.txt>. July 2002. 45 Chaves, M. H. P. C.; Montes, A. Modelo de dados para sistema de detec c ao de intrus ao visando a reconstru c ao de sess oes. In: Simp osio sobre Seguran ca e Inform atica. Anais. S ao Jos e dos Campos: CTA/ITA, 2001. v. 3, p. 141150. 75 159

Clark, D. D. IP datagram reassembly algorithms. Request for Comments RFC 815. [online]. <http://www.rfc-editor.org/rfc/rfc815.txt>. July 2002. 102 COAST. Intrusion detection systems. [online]. <http://www.cerias.purdue.edu/coast/intrusion-detection/ids.html>. July 2002. 64 Comer, D. E. Internetworking with TCP/IP. 4. ed. New Jersey: Prentice Hall, 2000. v. 1: principles, protocols, and architectures. 750 p. 31, 34, 38, 40 Crispin, M. Internet message access protocol - version 4rev1. Request for Comments RFC 2060. [online]. <http://www.rfc-editor.org/rfc/rfc2060.txt>. July 2002. 45 Crocker, D. Standard for the format of ARPA Internet text messages. Request for Comments RFC 822. [online]. <http://www.rfc-editor.org/rfc/rfc822.txt>. July 2002. 43 daemon9. Project Loki. Phrack. [online], v. 5, n. 49, Feb. 1996. <http://www.phrack.org/show.php?p=49&a=6>. 148 . LOKI2 (the implementation). Phrack. [online], v. 7, n. 51, Sep. 1997. <http://www.phrack.org/show.php?p=51&a=6>. 148 Denning, D. E. An intrusion-detection model. IEEE Transactions on Software Engineering, v. SE-13, n. 2, p. 222232, Feb. 1987. 28, 62 Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. Standard for the format of ARPA Internet text messages. Request for Comments RFC 822. [online]. <http://www.rfc-editor.org/rfc/rfc822.txt>. July 2002. 44 Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. Hypertext transfer protocol - HTTP/1.1. Request for Comments RFC 2616. [online]. <http://www.rfc-editor.org/rfc/rfc2616.txt>. July 2002. 44 Finlayson, R.; Mann, T.; Mogul, J.; Theimer, M. A Reverse address resolution protocol. Request for Comments RFC 903. [online]. <http://www.rfc-editor.org/rfc/rfc903.txt>. July 2002. 33 Fyodor. Nmap - network mapper. [online]. <http://www.insecure.org/nmap>. July 2002a. 138 160

. Remote OS detection via TCP/IP stack ngerprinting. [online]. <http://www.insecure.org/nmap/nmap-fingerprinting-article.html>. July 2002b. 138 Garnkel, S.; Spaord, G. Pratical UNIX and Internet secutity. 2. ed. Sebastopol: OReilly & Associates, 1996. 917 p. 53 Gibbons, A. Algorithmic graph theory. Cambridge: Cambridge University Press, 1985. 259 p. 79, 80, 81 Giovanni, C. Fun with packets: designing a stick. [online]. <http://www.eurocompton.net/stick/papers/Peopledos.pdf>. July 2002. 28 Gonnet, G. H.; Baeza-Yates, R. Handbook of algorithms and data structures: in Pascal and C. 2. ed. Boston: Addison-Wesley, 1991. 424 p. 81, 120 Hartmeier, D. Design and performance of the openbsd stateful packet lter (pf). In: USENIX Annual Technical Conference, Monterey, 2002. Proceedings. Monterey: USENIX, 2002. FREENIX Track. 27 IANA. Protocol numbers and assignment services. [online]. <http://www.iana.org/numbers.htm>. July 2002. 41, 42, 144 Kernighan, B. W.; Ritchie, D. M. C, a linguagem de programa c ao: padr ao ANSI. Rio de Janeiro: Campus, 1990. 289 p. 51, 87 Kumar, S.; Spaord, E. H. An application of pattern matching in intrusion detection. West Lafayette: Purdue University, 1994. 55 p. (CSD-TR-94-013). 56, 60 Kumar, S. Classication and detection of computer intrusions. West Lafayette. 165 p. Thesis (Doctor of Philosophy in Computer Sciences) Purdue University, 1995. 60 Lunt, T. L.; Tamaru, A.; Gilham, F.; Jagannathan, R.; Jalali, C.; Neumann, P. G.; S., J. H.; Valdes, A.; Garvey, T. D. A real-time intrusion-detection expert system (IDES). Washington DC: SRI International, 1992. 166 p. (SRI Project 6784). 63 McCanne, S.; Jacobson, V. The BSD packet lter: a new arquitecture for user-level packet capture. In: Winter USENIX Technical Conference, San Diego, 1993. Proceedings. San Diego: USENIX, 1993. p. 259269. 47, 48, 50 McHugh, J.; Christie, A.; Allen, J. Defending yourself: the hole of intrusion detection systems. IEEE Software, v. 17, n. 5, p. 4251, Set.-Out. 2000. 26, 76 161

Miller, I. Protection against a variant of the tiny fragment attack. Request for Comments RFC 3128. [online]. <http://www.rfc-editor.org/rfc/rfc3128.txt>. July 2002. 102 Mills, D. L. Network time protocol (version 1): specication and implementation. Request for Comments RFC 1059. [online]. <http://www.rfc-editor.org/rfc/rfc1059.txt>. July 2002a. 44 . Network time protocol (version 2): specication and implementation. Request for Comments RFC 1119. [online]. <http://www.rfc-editor.org/rfc/rfc1119.txt>. July 2002b. 44, 109 . Network time protocol (version 3): specication and implementation. Request for Comments RFC 1305. [online]. <http://www.rfc-editor.org/rfc/rfc1305.txt>. July 2002c. 44, 109 Mockapetris, P. Domain names: concepts and facilities. Request for Comments RFC 1034. [online]. <http://www.rfc-editor.org/rfc/rfc1034.txt>. July 2002a. 43 . Domain names: implementation and specication. Request for Comments RFC 1035. [online]. <http://www.rfc-editor.org/rfc/rfc1035.txt>. July 2002b. 43, 109, 111 Mueller, P.; Shipley, G. DRAGON claws its way to the top. Network Computing, p. 4567, Aug. 20 2001. 29 Mukherjee, B.; Heberlein, L. T.; Levitt, K. N. Network intrusion detection. IEEE Network, v. 8, n. 3, p. 2641, May-June 1994. 61, 64, 65 Myers, J.; Rose, M. Post oce protocol - version 3. Request for Comments RFC 1939. [online]. <http://www.rfc-editor.org/rfc/rfc1939.txt>. July 2002. 44 Northcutt, S. Network intrusion detection: an analysts handbook. Indianapolis: New Riders, 1999. 267 p. 69 Northcutt, S.; Cooper, M.; Fearnow, M.; Frederick, K. Intrusion signatures and analysis. Indianapolis: New Riders, 2001. 408 p. 102 Northcutt, S.; Novak, J. Network intrusion detection: an analysts handbook. 2. ed. Indianapolis: New Riders, 2001. 450 p. 102 Plummer, D. C. An ethernet address resolution protocol. Request for Comments RFC 826. [online]. <http://www.rfc-editor.org/rfc/rfc826.txt>. July 2002. 32 162

Porras, P. A.; Neumann, P. G. EMERALD: event monitoring enabling responses to anomalous live disturbances. [online]. <http://www.sdl.sri.com/emerald/emerald-niss97.html>. July 2002. 68 Postel, J. Internet control message protocol: DARPA Internet program, protocol specication. Request for Comments RFC 792. [online]. <http://www.rfc-editor.org/rfc/rfc792.txt>. July 2002a. 35 . Internet protocol: DARPA Internet program, protocol specication. Request for Comments RFC 791. [online]. <http://www.rfc-editor.org/rfc/rfc791.txt>. July 2002b. 33, 34, 35 . Simple mail transfer protocol. Request for Comments RFC 821. [online]. <http://www.rfc-editor.org/rfc/rfc821.txt>. July 2002c. 43 . Transmission control protocol: DARPA Internet program, protocol specication. Request for Comments RFC 793. [online]. <http://www.rfc-editor.org/rfc/rfc793.txt>. July 2002d. 38, 39, 41, 115 . User datagram protocol. Request for Comments RFC 768. [online]. <http://www.rfc-editor.org/rfc/rfc768.txt>. July 2002e. 37 Postel, J.; Reynolds, J. File transfer protocol (FTP). Request for Comments RFC 959. [online]. <http://www.rfc-editor.org/rfc/rfc959.txt>. July 2002a. 43 . TELNET protocol specication. Request for Comments RFC 854. [online]. <http://www.rfc-editor.org/rfc/rfc854.txt>. July 2002b. 43 Ptacek, T. H.; Newsham, T. N. Insertion, evasion, and denial of service: eluding network intrusion detection. [online]. <http://www.silicondefense. com/research/itrex/archive/tracing-papers/ptacek98insertion.pdf>. July 2002. 28, 102, 140, 155 Ranum, M. J. Experiences benchmarking intrusion detection systems. Rockville: NFR Security, Inc., 2001. 10 p. 82 Roesch, M. SNORT - lightweigth intrusion detection for networks. In: Systems Administration Conference, 13., Seattle, 1999. Proceedings. Seattle: USENIX, 1999. p. 229238. LISA99. 72 Roesch, M.; Green, M. Snort users manual. Release 1.9.X. [online]. <http://www.snort.org/docs/SnortUsersManual.pdf>. July 2002. 73 163

Rooij, G. Real stateful TCP packet ltering in IP lter. [online]. <http://home.iae.nl/users/guido/papers/tcp_filtering.ps.gz>. July 2002. 27 Smaha, E. S. Haystack: an intrusion detection system. In: AeroSpace Computer Security Applications Conference, 4., Austin, 1988. Proceedings. Austin: IEEE, 1988. p. 3744. 55, 66 Snapp, S. R.; Brentano, J.; Dias, G. V.; Goan, T. L.; Heberlein, L. T.; Ho, C.; Levitt, K. N.; Mukherjee, B.; Smaha, S. E.; Grance, T.; Teal, D. M.; Mansur, D. DIDS (distributed intrusion detection system): motivation, arquitecture, and an early prototype. [online]. <http://olympus.cs.ucdavis.edu/papers/DIDS.ncsc91.pdf>. May 2000. 66 SRI. History of intrusion detection at SRI/CSL. [online]. <http://www.sdl.sri.com/programs/intrusion/history.html>. July 2002. 62, 63 Stevens, W. R. TCP/IP illustrated: the protocols. Boston: Addisson-Wesley, 1994. v. 1. 576 p. 32, 33, 34, 35, 38, 39 . UNIX network programming. 2. ed. Upper Saddle River: Prentice Hall, 1998. v. 1, Cap. 2: the transport layer: UDP and TCP, p. 2953. 39, 41 Stocksdale, G. CIDER documents. [online]. <http://www.nswc.navy.mil/ISSEC/CID>. July 2002. 69 Sun. NFS: network le system protocol specication. Request for Comments RFC 1094. [online]. <http://www.rfc-editor.org/rfc/rfc1094.txt>. July 2002a. 45 . RPC: remote procedure call protocol specication version 2. Request for Comments RFC 1057. [online]. <http://www.rfc-editor.org/rfc/rfc1057.txt>. July 2002b. 44 Sundaram, A. An introduction to intrusion detection. [online]. <http://coast.cs.purdue.edu/pub/doc/intrusion_detection>. July 2000. 56, 57, 59 Teng, H. S.; Chen, K.; Lu, S. C. Security audit trail analysis using inductively generated predictive rules. In: Conference on Articial Intelligence Applications, 6., Santa Barbara, 1990. Proceedings. Los Alamitos: IEEE, 1990. p. 2429. 58 Wall, L.; Christiansen, T.; Randal, L. S. Programming perl. 2. ed. Sebastopol: OReilly & Associates, 1996. 547 p. 70 164

Ylonen, T.; Kivinen, T.; Saarinen, M.; Rinne, T.; Lehtinen, S. SSH connection protocol. Internet Draft. [online]. <http: //search.ietf.org/internet-drafts/draft-ietf-secsh-connect-15.txt>. July 2002. 43 Ziemba, G.; Reed, D.; Traina, P. Security considarations for IP fragment ltering. Request for Comments RFC 1858. [online]. <http://www.rfc-editor.org/rfc/rfc1858.txt>. July 2002. 102 Zimmerman, D. The nger user information protocol. Request for Comments RFC 1288. [online]. <http://www.rfc-editor.org/rfc/rfc1288.txt>. July 2002. 44

165

 APENDICE A MENSAGENS ICMP: TIPOS E CODIGOS TABELA A.1: Tipos e c odigos das mensagens ICMP Tipo 0 3 C odigo 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 4 5 0 0 1 2 3 0 0 0 0 Descri c ao Echo reply Destination unreachable Net unreachable Host unreachable Port unreachable Protocol unreachable Fragment needed but DF was set Source route failed Destination network unknown Destination host unknown Source host isolated Communication with destination network is administratively prohibited Communication with destination host is administratively prohibited Destination network unreachable for type of service Destination host unreachable for type of service Communication administratively prohibited Host precedence violation Precedence cuttof in eect Source quench Redirect Redirect Redirect Redirect Redirect datagram datagram datagram datagram for for for for the network the host type of service and network type of service and host

8 9 10 11

Echo request Router advertisement Router solicitation Time exceeded Time to live exceeded in transit
continua na pr oxima p agina

167

TABELA A.1: (continua c ao) Tipo 12 C odigo 1 0 1 2 0 0 0 0 0 0 Descri c ao Fragment reassembly time exceeded Parameter problem Pointer indicates the error Missing a required option Bad length Timestamp request Timestamp reply Information request Information reply Address mask request Address mask reply

13 14 15 16 17 18

168

 APENDICE B DO SISTEMA RECON DETALHES DE IMPLEMENTAC AO B.1 OS CONTADORES GLOBAIS DO SISTEMA TABELA B.1: Contadores globais do RECON Contador packet count ip count connection count trunc ether hdr packets non tcpip packets non ip packets multicast tunnel packets non tcp udp icmp packets trunc ip hdr packets trunc ip content packets ip opts packets ip frag packets trunc icmp hdr packets icmp routeradvert packets icmp routersolicit packets icmp res or unknown packets icmp timxceed frag icmp not matched timxceed icmp proc packets Descri c ao n umero total de pacotes lidos n umero de endere cos IP distintos n umero de conex oes distintas entre pares de endere cos IP frames Ethernet com tamanho menor que a estrutura do cabe calho Ethernet protocolo encapsulado no frame Ethernet n ao e um protocolo TCP/IP protocolo utilizado n ao e o IP datagrama IP encapsulando datagrama IP (multicast tunnel) datagramas IP contendo mensagens diferentes de TCP/UDP/ICMP ou Multicast datagramas IP com tamanho menor que a estrutura do cabe calho IP datagramas IP com o conte udo truncado datagramas IP cujos cabe calhos cont em op c oes datagramas IP fragmentados Mensagens ICMP com tamanho menor que a estrutura do cabe calho ICMP Mensagens ICMP do tipo router advertisement Mensagens ICMP do tipo router solicitation Mensagens ICMP desconhecidas ou reservadas Mensagens ICMP do tipo fragment reassembly time exceeded Mensagens ICMP do tipo anterior que n ao foram encontradas na arvore de desfragmenta c ao Mensagens ICMP realmente inseridas nas estruturas de reconstru c ao de sess oes
continua na pr oxima p agina

169

TABELA B.1: (continua c ao) Contador icmp proc packets req icmp proc packets rep icmp proc packets error icmp proc packets error nomatch trunc udp hdr packets udp proc packets trunc tcp hdr packets tcp proc packets tcp bad hdr len tcp packets with options tcp log packets tcp packets nomatch reset mem amount icmp Isession mem amount icmp Ipkt mem amount icmp Epkt mem amount udp session mem amount udp pkt mem amount tcp session mem amount tcp pkt mem amount Descri c ao Mensagens ICMP de informa c ao, do tipo request inseridas Mensagens ICMP de informa c ao, do tipo reply inseridas Mensagens ICMP de erro inseridas Mensagens ICMP de erro n ao associadas ao pacote gerador do erro Mensagens UDP com tamanho menor que a estrutura do cabe calho UDP Mensagens UDP realmente inseridas nas estruturas de reconstru c ao de sess oes Mensagens TCP com tamanho menor que a estrutura do cabe calho TCP Mensagens TCP realmente inseridas nas estruturas de reconstru c ao de sess oes Mensagens TCP com o cabe calho corrompido Mensagens TCP cujos cabe calhos cont em op c oes Mensagens TCP inseridas na arvore de logs TCP Mensagens TCP com o ag RST ativo, n ao associadas a alguma sess ao total de mem oria alocada pelo sistema total de mem oria alocada no armazenamento das sess oes ICMP de informa c ao total de mem oria alocada no armazenamento dos pacotes ICMP de informa c ao total de mem oria alocada no armazenamento dos pacotes ICMP de erro total de mem oria alocada no armazenamento das sess oes UDP total de mem oria alocada no armazenamento dos pacotes UDP total de mem oria alocada no armazenamento das sess oes TCP total de mem oria alocada no armazenamento dos
continua na pr oxima p agina

170

TABELA B.1: (continua c ao) Contador tcp log node mem amount tcp log pkt mem amount Descri c ao pacotes TCP total de mem oria alocada no armazenamento dos n os da arvore de logs TCP total de mem oria alocada no armazenamento dos pacotes de logs TCP

B.2

EXEMPLO DE UM ARQUIVO DE CONFIGURAC AO

A moldura abaixo apresenta um exemplo do arquivo de congura c ao do RECON.

#### INICIO DO ARQUIVO #### # # RECON.CONF v.1 c 2002/06/17 # # Paths to DATA_DIR = TEMP_DIR = OUTPUT_DIR Data, Temp and Output Directories /path_to_my_raw_data_directory /tmp = /path_to_my_output_directory

# Organization Network and Mask Addresses NETWORK = xxx.xxx.xxx.xxx NETMASK = xxx.xxx.xxx.xxx # Determines if Scan Checks will be made #FIND_HOST_SCAN = YES FIND_HOST_SCAN_WITH_BANNER = YES # Scan Threshholds IN_HOST_SCAN_THRESHOLD = 10 OUT_HOST_SCAN_THRESHOLD = 10 FTP_BANNER_PKTS_FROM_SERVER = 2 SSH_BANNER_PKTS_FROM_SERVER = 1 # ICMP/Echo Investigation DETECT_COVERT_CHANNELS = YES COVERT_CHANNEL_REQ_REPLY_DIFF = 1 # TCP Backdoor Detection DETECT_BACKDOORS = YES BACKDOOR_TIME_TOLERANCE = 1 # end. #### FIM DO ARQUIVO ####

171

B.3

LISTAGEM DESCRITIVA DOS ARGUMENTOS DO RECON

A moldura abaixo apresenta os argumentos, a serem passados para o RECON, no momento de sua execu c ao. Esta sa da foi obtida atrav es da execu c ao do RECON com o argumento -h.
Usage: recon [-AaEeFfhIiLlOSTtUuv] [-c config_file] [-C #] <-r dump_file | -d yyyymmddhh:yyyymmddhh> [ -R filter_file | expression ] -A: -a: -C: -c: -d: print all sessions, including packets print all sessions stop reading after receiving # packets specifies an alternative configuration file selectt dump_files for reading, according to date of capture (comming soon) -E: print ICMP error packets -e: print ICMP error packets summary -F: print fragment table -f: print just fragment table alerts -h: show this help information -I: print ICMP sessions, including packets -i: print ICMP sessions -L: print TCP log packets -l: print collapsed TCP log packets -O: dont run packet-matching code optimizer -R: use filter_file as input for filter expression -r: read packets from dump_file -S: dont print final statistics -T: print TCP sessions, including packets -t: print TCP sessions -U: print UDP sessions, including packets -u: print UDP sessions -v: be verbose (level 1) -vv: be even more verbose (level 2)

172