Uma Ferramenta de Monitoração Programável Voltada à Detecção de Intrusão

Uma Ferramenta de Monitoração Programável Voltada à Detecção de Intrusão Edgar Meneghetti, Luciano Gaspary, Liane Tarouco Universidade Federal do Rio Grande do Sul, Instituto de Informática Av. Bento Gonçalves, 9500 - Agronomia - CEP 91591-970 - Porto Alegre, Brasil {edgar@cesup.ufrgs.br, paschoal@inf.ufrgs.br, liane@penta.ufrgs.br} ABSTRACT This paper proposes the use of Trace architecture proposed in [1, 2, 3] as an Intrusion Detection System. The architecture provides the network manager with mechanisms for distributed management of high layer protocols and network services. Using the graphical/textual language called PTSL (Protocol Trace Specification Language), which is one of the elements of the architecture, the network manager can specify protocol traces and delegate them to monitoring agents, which monitor and count their occurrence on the network segment where they are attached to. The paper presents how PTSL may be used to model attack signatures and proposes the implementation of the programmable monitoring tool (monitoring agent), which is another key element of the architecture. Keywords: intrusion detection, network management, monitoring, Internet. RESUMO Este artigo propõe a utilização da arquitetura Trace proposta em [1, 2, 3] como um Sistema para Detecção de Intrusão. A arquitetura oferece ao gerente de rede mecanismos para o gerenciamento distribuído de protocolos de alto nível e serviços de rede. Usando a linguagem gráfica/textual PTSL (Protocol Trace Specification Language), que é um dos elementos da arquitetura, o gerente de rede pode especificar traços de protocolos e delegá-los a agentes de monitoração, que monitoram e contabilizam sua ocorrência no segmento de rede onde estão ligados. O artigo apresenta como PTSL pode ser usada para modelar assinaturas de ataque e propõe a implementação da ferramenta de monitoração programável (agente de monitoração), outro elemento-chave da arquitetura. Palavras-chave: detecção de intrusão, gerenciamento de redes de computadores, monitoração, Internet.

1. INTRODUÇÃO Com o grande crescimento das redes de dados, evidenciado principalmente pela Internet, cresce também a preocupação com a segurança das informações armazenadas nos computadores conectados a elas e dos próprios dados que circulam por essas redes. Além disso, uma quantidade cada vez maior de atividades essenciais é realizada por intermédio das redes (principalmente através da Internet), e seu funcionamento correto e confiável torna-se cada vez mais fundamental. Em paralelo, tentativas de intrusão, ações de pirataria e invasões consumadas são reportadas diariamente, e envolvem um número cada vez maior de máquinas. O uso de mecanismos específicos de segurança é cada vez mais indispensável nos sistemas computacionais modernos. Sistemas para Detecção de Intrusão baseados em rede como o SHADOW [4], o SNORT [5] e o NFR (Network Flight Recorder) [6] têm sido propostos, mas limitam a análise apenas aos protocolos das camadas mais baixas (TCP e IP) e dificilmente suportam a detecção de ataques mais elaborados, tais como os realizados explorando vulnerabilidades presentes em protocolos da camada de aplicação. A ferramenta SHADOW apresenta essa limitação. Embora a detecção de intrusão não seja feita em tempo real, a ferramenta é capaz de detectar muitos cenários de ataques através da análise dos cabeçalhos IP ou TCP, de forma eficiente e robusta. Outra deficiência do SHADOW é a incapacidade de monitorar o payload do pacote, inviabilizando a detecção de ataques simples, como os efetuados contra CGIs de servidores web. A ferramenta SNORT aparece como o sistema mais utilizado atualmente para detecção de intrusão, possuindo um desempenho muito bom e uma linguagem procedural flexível para descrição de ataques. O processo de detecção de intrusão do SNORT baseia-se na aplicação de regras de filtragem em cada pacote, a fim de procurar assinaturas de ataques conhecidos. Uma limitação dessa ferramenta se refere ao fato de apenas procurar assinaturas de ataques em cada pacote, ou em um fluxo, sem conseguir detectar ataques que necessitem de pacotes de protocolos diversos para serem caracterizados. O sistema para detecção de intrusão NFR apresenta um mecanismo mais elaborado para o processo de detecção de intrusão, fornecendo uma linguagem procedural bastante extensa e de difícil aprendizado (N-code) e a possibilidade de se medir o grau de anormalidade de um determinado pacote. O grau de anormalidade é medido através da ocorrência freqüente ou não dos pares endereço IP e porta do serviço em um intervalo de tempo. Mais uma vez, esta solução não contempla os casos relativos à camada de aplicação, além de não apresentar uma linguagem de fácil assimilação, que é importante do ponto de vista do administrador no momento em que um novo ataque precisa ser descrito. O presente trabalho explora a arquitetura Trace com o propósito de realizar detecção de intrusão e apresenta a arquitetura de uma ferramenta de monitoração programável, capaz de receber especificações de traços de protocolos e passar a observar sua ocorrência na rede. A arquitetura para gerenciamento distribuído de protocolos de alto nível, proposta por Gaspary em [1, 2, 3], é apresentada na seção 2. A seção 3 apresenta a modelagem de alguns cenários de ataques utilizando a notação gráfica e textual da linguagem PTSL, assim como uma breve descrição da linguagem. O agente de monitoração é apresentado na seção 4. Na seção 5 são apresentadas as considerações finais. 2. ARQUITETURA TRACE A arquitetura Trace é uma extensão da infra-estrutura centralizada de gerenciamento SNMP, para, através de um modelo em três camadas, suportar o gerenciamento distribuído de protocolos de alto nível e serviços de rede. A figura 1 ilustra um esquema da arquitetura. A principal contribuição da mesma é a presença de agentes de monitoração extensíveis ou programáveis, capazes de receber dinamicamente descrições de traços de protocolos (especificações PTSL) e passar a monitorar a sua ocorrência na rede. As estatísticas coletadas são armazenadas em uma similar à RMON2. A programação do agente de monitoração é realizada pelo gerente intermediário através de um script. Este mesmo script faz a monitoração dos dados armazenados na pelo agente e, dependendo das condições observadas, instancia e dispara um script em um agente de ação. O agente de ação reside na estação onde o serviço monitorado se encontra. Os scripts disparados por esse agente realizam, por exemplo, o reinício do serviço ou a reconfiguração do mesmo. A arquitetura apresenta ainda mecanismos de notificação (traps) para que os agentes façam notificação de eventos ao gerente intermediário e para que este possa reportar eventos mais significativos à estação de gerenciamento. 2

Estação de Gerenciamento repositório (PTSL, Java, Perl, Tcl) banco de dados Target Notif. browser web server PHP scripts (PHP) trap notifier agente SNMP Script monitor PTSL scripts (PTSL) agente SNMP RMON2 Agente de Ação Script interpretador Java, Perl, Tcl scripts (Java, Perl, Tcl) agente SNMP Script interpretador Java, Perl, Tcl scripts (Java, Perl, Tcl) Gerente Intermediário FIGURA 1- Arquitetura Trace A arquitetura foi projetada com o objetivo de atender aos requisitos das cinco áreas funcionais de gerenciamento FCAPS (Fault, Configuration, Accounting, Performance e Security). Ao observá-la com o foco voltado ao gerenciamento de segurança, a arquitetura seria classificada como um sistema de detecção de intrusão baseado em rede, já que os dados são coletados diretamente da rede, sem a necessidade de haver algum agente sendo executado nos hosts monitorados. Se a classificação for pelo método empregado, pode-se classificar como um sistema de detecção de intrusão baseado em assinatura e em anomalia, uma vez que se pode empregar assinaturas conhecidas para reconhecimento de invasões, bem como criar traços que representem situações anormais (anômalas). O próprio gerente intermediário pode realizar a detecção por anomalia, como, por exemplo, a ocorrência de um determinado traço em um horário não usual. 3. MODELAGEM DE ATAQUES USANDO A LINGUAGEM PTSL Uma série de ataques conhecidos [7, 8, 9, 10,11] foi modelada utilizando as notações gráfica e textual da linguagem PTSL, parte integrante da arquitetura Trace. As figuras a seguir ilustram alguns destes ataques. A notação gráfica corresponde a uma máquina de estados, onde as transições em linha cheia representam mensagens do cliente para o servidor e as linhas pontilhadas representam mensagens do servidor para o cliente. A varredura de portas é um método de avaliação de quais são os possíveis serviços TCP e UDP disponíveis em um equipamento alvo. Existe uma série de técnicas [8] para realizar esta varredura, sendo a mais simples o envio de pacotes para todas as portas de uma estação. No caso do TCP, ao enviar um pacote com o bit SYN ligado, a resposta esperada é um pacote com SYN e ACK ligados, caso aquela porta possua um serviço associado. Caso não haja nenhum serviço nesta porta, a resposta será um pacote TCP com o bit RST ligado. O traço, descrito com a notação gráfica, está ilustrado na figura 2. O gerente intermediário programa o agente de monitoração para que passe a observar a ocorrência do traço. Além disso, ele consulta periodicamente a RMON2 estendida onde os resultados da monitoração são armazenados (vide tabela 1). Se em um intervalo de consulta o número de ocorrências superar um determinado valor, definido pelo gerente na especificação da tarefa de gerenciamento, o script gera uma notificação à estação central de gerenciamento. Outras técnicas de varredura de portas são facilmente implementadas através de PTSL. A técnica na qual é enviado um pacote TCP com os bits SYN e ACK ligado e espera-se um pacote de resposta com o bit RST ligado caso a porta não esteja associada a algum serviço pode ser especificada de forma similar. Esta técnica também é conhecida por mapeamento reverso, visto que as respostas obtidas do alvo correspondem às portas que não possuem serviços, mas 3

pode-se deduzir que as demais portas possuem. As demais técnicas que utilizam mapeamento reverso (também conhecidas por stealth scan) também podem ser implementadas de forma análoga. Trace Acesso inválido a serviço TCP TCP SYN idle 2 Version: 1.0 Description:Acesso a serviço não disponível. Key: TCP, varredura de portas Port: Owner: Edgar Meneghetti Last Update: Tue, 16 Aug 2000 15:30:58 GMT TCP RST FIGURA 2 Traço para detectar varredura de portas Os artifícios para encobrir a varredura de portas, tais como, varredura de portas usando uma seqüência aleatória, ou com intervalos de tempo grandes, são problemas tratados pontualmente pelas ferramentas para detecção de intrusão. No caso do traço modelado acima, este problema não se aplica. A seqüência de números de portas não é importante para a ocorrência do traço, assim como o intervalo entre uma conexão e outra. Este último problema deverá ser endereçado pelo gerente intermediário, no sentido de definir quais são os limites aceitáveis de ocorrência deste traço em um período de tempo. A especificação do mesmo traço utilizando a notação textual está mostrada na figura 3. Os itens principais da linguagem serão descritos a seguir. A especificação de um traço inicia com a palavra-chave Trace e termina com EndTrace (linhas 1 e 27). O nome do traço (linha 1) deve ser especificado pelo gerente intermediário, sendo os demais itens do cabeçalho opcionais (linhas 2 a 7). Em seguida, a especificação é dividida em três seções: MessagesSection (linhas 8 a 17), GroupsSection (não utilizada no exemplo) e StatesSection (linhas 18 a 26). Em MessagesSection são definidas as mensagens que causarão a evolução do traço. Quando duas ou mais mensagens causam a transição de um mesmo estado para outro, é possível agrupá-las em uma única mensagem, tornando a especificação mais clara. Esses agrupamentos são definidos na seção GroupsSection. Por fim, na seção StatesSection é definida a máquina de estados que representa o traço. A evolução da máquina de estados ocorre quando um pacote com campos idênticos aos especificados em uma client ou server message é observado na rede. No exemplo apresentado na figura 2, a máquina de estados evolui do estado idle para o estado 2 ao observar uma mensagem TCP-SYN. Na linguagem PTSL, as transições de estado são representadas por um sistema posicional. A diferença entre os protocolos requer a utilização de duas abordagens distintas para a identificação de campos. São elas: FieldCounter:usada em protocolos baseados em caracter, esta abordagem trata uma mensagem como um conjunto de primitivas separadas por espaços em branco; a identificação de um campo, nesse caso, ocorre pela posição do mesmo na mensagem (não usado no exemplo); BitCounter:usada em protocolos binários; a identificação de um campo é determinada por um offset em bits a partir do início do cabeçalho do protocolo em questão até o início do campo desejado; além da posição inicial do campo é preciso indicar ainda o número de bits que o campo ocupa (linhas 11 e 15). 4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Trace Acesso inválido a serviço TCP Version: 1.0 Description: Acesso a serviço não disponível. Key: TCP, varredura de portas Port: Owner: Luciano Paschoal Gaspary Last Update: Tue, 16 Aug 2000 15:30:58 GMT MessagesSection Message TCP SYN MessageType: client BitCounter Ethernet/IP 110 1 1 Campo SYN 1 significa TCP Connect EndMessage Message TCP RST MessageType: server BitCounter Ethernet/IP 109 1 1 Campo RST EndMessage EndMessagesSection StatesSection FinalState idle State idle TCP SYN GotoState 2 EndState State 2 TCP RST GotoState idle EndState EndStatesSection EndTrace FIGURA 3 Especificação textual do traço para detectar varredura de portas As informações associadas a um campo BitCounter são as seguintes: Encapsulamento: identifica onde o campo deve ser buscado; no exemplo, o encapsulamento definido para ambos os campos é Ethernet/IP, indicando que o protocolo a ser monitorado será encontrado no campo de dados do protocolo IP; Posição inicial: indica o offset em bits a partir do início do cabeçalho do protocolo em questão até o início do campo desejado; o primeiro bit é o 0; Comprimento do campo: indica o tamanho em bits do campo; String de comparação: string usada na comparação com o campo selecionado no pacote; Descrição: breve comentário a respeito do campo. A seção StatesSection permite especificar, de forma textual, a máquina de estados que representa o traço. O estado final é identificado logo após o início da seção StatesSection (linha 19). Os estados idle e 2 são definidos, respectivamente, nas linhas 20 a 22 e 23 a 25. A especificação de um estado se resume a listar os eventos (mensagens e agrupamentos) que podem provocar uma transição e indicar, para cada um deles, o próximo estado (linhas 21 e 24). Além das abordagens BitCounter e FieldCounter, a linguagem ainda proporciona a abordagem NoOffSet, que permite a localização de seqüência de caracteres (strings) na área de dados do protocolo especificado. Agrupamento de mensagens também é possível através da declaração GroupsSection, o que equivale a uma operação lógica ou entre as mensagens especificadas na seção MessagesSection. Mais informações sobre a linguagem podem ser obtidas em [1, 2, 3]. A figura 4 ilustra um caso de comportamento anômalo, onde o pacote de início da conexão TCP (SYN) carrega dados [12]. Este recurso é utilizado para enganar algum sistema de segurança que procura pela ocorrência de determinadas palavras-chave no payload do TCP, mas que em geral não fazem esta verificação no handshake. Estes dados serão adicionados ao restante dos dados que vierem após o handshake. 5

Trace Comportamento anômalo TCP idle TCP SYN && TCP PORTA=23 && TCP * Version: 1.0 Description: Acesso a telnet com payload não vazio. Key: TCP, telnet, anomalia Port: Owner: Edgar Meneghetti Last Update: Tue, 16 Aug 2000 15:30:58 GMT FIGURA 4 - Comportamento anômalo Um cenário de ataque no nível de aplicação pode ser descrito pela utilização freqüente do comando rpcinfo, disponível em implementações Unix. Este comando retorna uma relação de servidores que aceitam requisições do tipo RPC (Remote Procedure Call) e pode ser uma informação valiosa do ponto de vista do atacante. O comando baseia-se no envio de uma mensagem ao servidor de conversão de número de programas RPC para portas TCP/UDP (portmapper daemon), solicitando que seja enviado um dump de todos os servidores RPC disponíveis nesta máquina. Como resposta, o portmapper envia uma mensagem contendo uma relação destes servidores e as respectivas portas e números de programa RPC. A modelagem deste traço está ilustrada na figura 5. Trace comando rpcinfo RPC msg type=0 && TCP port dst=111 idle 2 Version: 1.0 Description:Utilização do comando rpcinfo. Key: RPC, rpcinfo Port: Owner: Edgar Meneghetti Last Update: Tue, 16 Aug 2000 15:30:58 GMT RPC msg type=1 Figura 5 - Traço de ocorrência do comando rpcinfo É importante salientar que este traço irá capturar tráfego legítimo também, ou seja, a ocorrência deste traço, analisado de forma estanque, não tem um significado conclusivo. O sistema NFS (Network File System) faz uso de rotinas que envolvem um processo idêntico ao descrito no traço. Porém, este traço só será observado durante a negociação para a montagem de sistemas de arquivos externos e não mais durante o resto do período em que este sistema de arquivos estiver montado. Desta forma, a ocorrência deste traço em horários não usuais ou em grande quantidade (varredura de hosts que possuam portmapper sendo executado, por exemplo), pode ser interpretada pelo gerente intermediário como um indicativo de ataque, ou de futuro ataque. 4. O AGENTE DE MONITORAÇÃO Os agentes de monitoração contabilizam a ocorrência de traços no segmento onde se encontram. São denominados programáveis porque os traços a serem monitorados podem ser configurados dinamicamente, sem a necessidade de recompilar esses agentes. Esta flexibilidade é obtida através da linguagem PTSL, apresentada no capítulo 3. Na prática, os agentes realizam a leitura de arquivos PTSL, organizam algumas estruturas em memória e iniciam o processo de monitoração. A determinação de que traços devam ser monitorados em um dado momento é realizada pelo gerente intermediário. A interface de comunicação entre o gerente intermediário e o agente de monitoração é a Script [13]. No script executado pelo gerente intermediário, descrito em [1, 2, 3], é possível observar como é feita a programação de um agente de monitoração. Um dos parâmetros informados no script executado no gerente intermediário é o endereço URL 6

do script (especificação PTSL) a ser executado. Ao receber do gerente intermediário a solicitação de execução de um determinado script, esse é recuperado do repositório via HTTP e executado. Na realidade, uma especificação PTSL não é executável. A semântica associada à solicitação de execução de uma especificação é fazer com que o agente de monitoração passe a monitorar o novo traço. De forma análoga, a interrupção de um script na Script significa programar o agente de monitoração para que ele cesse a monitoração do traço definido por esse script. Toda vez que a ocorrência do traço é observada entre qualquer par de estações, informações são armazenadas em uma similar à RMON2 [14]. Uma das diferenças da usada com relação à RMON2 é que o grupo protocoldir, que indica os protocolos que o agente é capaz de monitorar, deixa de ser um grupo de leitura e passa a ser configurável. Além disso, a granularidade da monitoração torna-se maior. Ao invés de armazenar estatísticas globais sobre o tráfego gerado por um determinado protocolo, as estatísticas são geradas de acordo com a ocorrência de traços especificados. O grupo almatrix, da RMON2, armazena estatísticas sobre o traço, quando observado entre cada par de estações. A tabela 4.1 ilustra o conteúdo da tabela almatrixsd. Ela contabiliza o número de pacotes e octetos entre cada par de máquinas (cliente/servidor). No caso, três traços foram observados. TABELA 1 Informações obtidas com consulta à tabela almatrixsd SourceAddress DestAddress Protocol Pkts Octets 125.120.10.100 172.16.108.254 Acesso inválido a serviço TCP 20 3.204 172.16.108.1 172.16.108.2 Comportamento anômalo TCP 4 4.350 172.16.108.32 172.16.108.2 Comando rpcinfo 8 7.300 A desvantagem em usar a RMON2 é que ela não possui objetos capazes de armazenar informações relacionadas a desempenho. Por essa razão, está sendo avaliada atualmente a possibilidade de utilizar adicionalmente uma extensão da RMON2, como a Application Performance [15]. A tabela 4.2 apresenta o tipo de informações armazenadas pela. A primeira linha indica que o traço Three-way handshake foi observado 12.700 vezes entre as máquinas 172.16.108.1 e 172.16.108.254. O número de traços que não completaram com sucesso foi de 2320. Além disso, o tempo médio de ocorrência deste traço foi de 1 segundo. Desta pode-se retirar informações valiosas do ponto de vista de segurança, como por exemplo, de que a quantidade de falhas no início da conexão está muito alta, significando que provavelmente alguma anomalia está ocorrendo neste ponto. As técnicas de varredura de portas poderiam ser detectadas desta forma também. TABELA 2 com informações sobre desempenho Client Server Protocol Successful Unsuccessful Responsiveness 172.16.108.1 172.16.108.254 Three-way handshake 12700 2320 1 sec. A implementação do agente de monitoração está sendo realizada segundo o esquema da figura 6. O módulo de captura de pacotes está sendo implementado através da libpcap, uma biblioteca específica para esta função e disponibilizada pelo grupo de pesquisa em redes do laboratório Lawrence Berkeley [16]. A libpcap tem aparecido como uma biblioteca padrão para captura de pacotes em sistemas que a suportem. Embora a biblioteca suporte a especificação de filtros utilizando a notação BPF (Berkeley Packet Filter), este recurso não está sendo utilizado pelo agente. A utilização deste mecanismo poderia aumentar bastante o desempenho do agente, sendo este um trabalho futuro a ser desenvolvido. O módulo verificador de ocorrência de traços é responsável por analisar os pacotes fornecidos pela biblioteca de captura de pacotes e procurar pela ocorrência de traços nestes. Uma máquina de estados é implementada através de listas encadeadas, executando em uma thread distinta da thread de captura de pacotes. Se houver a ocorrência de um traço, então é desencadeado um processo de inclusão ou alteração de informação no banco de dados mysql. Este banco de dados servirá como base de leitura para o agente SNMP buscar dados da RMON2 estendida. A escolha do banco 7

de dados mysql se deu principalmente pelo alto desempenho apresentado por ele tanto para consultas como para inclusões. FIGURA 6 - Agente de monitoração O agente de monitoração está sendo implementado através da linguagem C, com o auxílio de threads, e o sistema operacional utilizado é Linux, principalmente pela facilidade em integrar os diferentes componentes da arquitetura. Em uma primeira avaliação, o agente de monitoração foi capaz de detectar 1000 traços/segundo, sem que se notasse grande impacto no desempenho do equipamento. Uma maior avaliação quanto a desempenho ainda precisa ser feita. 6. CONCLUSÕES Este artigo apresentou a arquitetura Trace e procurou demonstrar como ela pode ser utilizada para fins de implementação de uma ferramenta para detecção de intrusão baseada em rede. Alguns cenários de ataques foram descritos e pôde-se verificar a facilidade com que se modela traços representativos de ataques através da especificação dos mesmos em PTSL. A linguagem PTSL mostra-se bastante adequada para a especificação de cenários de ataques, seja pela sua simplicidade quanto pela facilidade e rapidez em descrever um traço. Como deficiência da linguagem, fica a impossibilidade de se recompor fluxos de dados. Em uma sessão de telnet, por exemplo, a monitoração de senhas fracas não seria possível, devido à impossibilidade de agregar todos os dados encapsulados no protocolo TCP para fazer esta análise. Uma maior validação do agente de monitoração ainda precisa ser feita e pretende-se integrá-lo aos demais componentes da arquitetura. Como trabalhos futuros está o estudo da utilização do mecanismo de filtragem da biblioteca libpcap como forma de melhorar o desempenho, além do próprio estudo de algoritmos mais eficazes para tratamento dos pacotes capturados da rede. 8

REFERÊNCIAS [1] GASPARY, L. P.; BALBINOT, L. F.; STORCH, R.; WENDT, F.; TAROUCO, L. R. Uma Arquitetura para Gerenciamento Distribuído e Flexível de Protocolos de Alto Nível e Serviços de Rede. Anais do XIX Simpósio Brasileiro de Redes de Computadores, Florianópolis, Maio de 2001. [2] GASPARY, L. P.; BALBINOT, L. F.; STORCH, R.; WENDT, F.; TAROUCO, L. R. Towards a Programmable Agent-based Architecture for Enterprise Application and Service Management. Proc. First IEEE/IEC Enterprise Networking Applications and Services Conference, Atlanta, June 2001. [3] GASPARY, L. P.; BALBINOT, L. F.; STORCH, R.; WENDT, F.; TAROUCO, L. R. Distributed Management of High-layer Protocols and Network Services Through a Programmable Agent-based Architecture. Proc. IEEE International Conference on Networking, Colmar, France, July 2001. [4] NAVAL Surface Warfare Center, Dalgren. SHADOW Indications Technical Analysis--Coordinated Attacks and Probes. 1998. Disponível em http://www.nswc.navy.mil/issec/cid/co-ordinated_analysis.txt. [5] ROESCH, M. Snort - Lightweight Intrusion Detection for Networks, Proc. LISA 99, 1999. [6] Network Flight Recorder, Inc., Network Flight Recorder, Disponível em http://www.nfr.com. [7] BELLOVIN, STEVEN M. Security Problems in the TCP/IP Protocol Suite, Computer Communications Review, Vol. 19, No. 2, pp. 32-48, April 1989. [8] FYODOR, "The Art and Detection of Port Scanning," Sys Admin. Mag., Nov. issue, 1998. [9] NORTHCUTT, S; Novak, J; McLachlan, D. Segurança e Prevenção em Redes. São Paulo, Brasil: Editora Berkeley, 2001. [10] OTEL, Florian-Daniel. Survey of existing TCP/IP attacks. Disponível em http://www.ce.chalmers.se/~otel/papersmine/lecture-on-tcpip-attacks-25012000/slides.ps. [11] YANG, GUANG. Introduction to TCP/IP Network Attacks. Disponível em http://seclab.cs.sunysb.edu/sekar/papers/netattacks.pdf. [12] IRWIN, Vicki; Northcutt, Stephen; & Ralph, Bill. (Naval Surface Warfare Center). Building a Network Monitoring and Analysis Capability--Step by Step. 1998. Disponível em http://www.nswc.navy.mil/issec/cid/step.htm. [13] LEVI, D.; SCHÖNWÄLDER, J. Definitions of Managed Objects for the Delegation of Management Scripts. Internet Draft, Nortel Networks, TU Braunschweig, July 2000. [14] WALDBUSSER, S. Remote Network Monitoring Management Information Base Version 2 using SMIv2. Request for Comments 2021, January 1997. [15] WALDBUSSER, S. Application Performance Measurement. Internet Draft, May 2000. [16] FLOYD, Sally, et al. Lawrence Berkeley National Laboratory - LBNL's Network Research Group. 1998. Disponível em http://ftp.ee.lbl.gov/. [17] 9