paper

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
{[email protected], [email protected], [email protected]}
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 MIB 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 MIB 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
banco de
dados
browser
web
server
PHP
(PTSL, Java,
Perl, Tcl)
Target
MIB
scripts
(PHP)
trap
notifier
agente
SNMP
Notif.
MIB
Script
MIB
monitor PTSL
repositório
scripts
(PTSL)
RMON2
MIB
agente
SNMP
scripts
(Java, Perl, Tcl)
agente
SNMP
Script
MIB
interpretador
Java, Perl, Tcl
interpretador
Java, Perl, Tcl
Script
MIB
Agente de Ação
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 MIB 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” Version: 1.0
Description:Acesso a serviço não disponível.
TCP SYN
Key: TCP, varredura de portas
Port:
Owner: Edgar Meneghetti
2
idle
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” Version: 1.0
Description: Acesso a telnet com payload não
vazio.
Key: TCP, telnet, anomalia
TCP SYN &&
idle
TCP PORTA=23 && Port:
Owner: Edgar Meneghetti
TCP *
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
2
idle
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 MIB [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 MIB 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
MIB similar à RMON2 [14]. Uma das diferenças da MIB 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 MIB 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.1
172.16.108.32
172.16.108.254
172.16.108.2
172.16.108.2
Acesso inválido a serviço TCP
Comportamento anômalo TCP
Comando rpcinfo
20
4
8
3.204
4.350
7.300
A desvantagem em usar a MIB 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 MIB [15]. A tabela 4.2 apresenta o tipo de informações armazenadas pela
MIB. 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 MIB 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 – MIB com informações sobre desempenho
Client
Server
Protocol
Successful Unsuccessful
172.16.108.1
172.16.108.254
Three-way handshake
12700
2320
Responsiveness
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 MIB 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 MIB. 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