SNORTFACE: Um Modelo de Interface para Ferramentas IDS
321
SNORTFACE – Um Modelo de Interface para
Ferramentas IDS
Kurt Schneider (URI-FW)
[email protected]
Frederico Henrique Goldschmidt Neto (URI-FW)
[email protected]
Resumo. A procura por uma forma eficiente para monitorar o tráfego das informações
em redes de computadores, tornou-se uma das maiores preocupações dos
administradores de rede. O crescimento em larga escala da utilização de computadores
de pequeno porte, a distribuição das aplicações que antes rodavam somente em
mainframes e o uso das facilidades da Internet e Intranet tornaram um desafio a
segurança da rede e o funcionamento correto dos equipamentos. O modelo
SNORTFACE é uma proposta de interface Web para configuração, distribuição em rede
e coleta de dados das ferramentas de Detecção de Intrusão (IDS – Intrusion Detection
System), para auxiliar o administrador na análise de tráfego das informações na rede e
diagnóstico de problemas. Este modelo será mostrado através do uso de uma aplicação
em rede, desenvolvida em linguagem estruturada, objetivando chamadas remotas para
busca das informações que alimentam a base de dados sobre as tentativas de ataque.
Palavras Chave: Segurança, IDS, Interface Web
1. Introdução
Sistemas de monitoramento têm adquirido importância fundamental na
análise das informações de possíveis ameaças de invasão em redes de
computadores. As ferramentas de detecção de intrusão, ao analisar os pacotes de
dados que trafegam pelas redes, geram arquivos de log contendo alertas de
tentativas de ataque. A adoção de um modelo que permita de forma centralizada
monitorar e visualizar estas informações, automatiza o processo de filtragem e
análise para o administrador de rede, agilizando o acompanhamento e resposta a
problemas.
2. Motivação
A segurança das redes de computadores tem enfrentado um momento crítico,
isto pode ser comprovado pelo crescimento dos serviços eletrônicos (E-cash, B2B,
B2C, E-Commerce), os constantes atos de vandalismo no meio eletrônico e a falta
de ferramentas adequadas para análise e acompanhamento de tentativas de
intrusão, gerando sobrecarga aos administradores de rede.
A necessidade de analisar o tráfego em redes comutadas representa um
grande desafio na atualidade, pois as ferramentas IDS (Intrusion Detection
322
XI SEMINCO - Seminário de computação - 2002
System) estão instaladas em pontos geograficamente distribuídos, podendo
apresentar distâncias consideráveis, onerando valioso tempo quando se necessita de
uma analise constante de todos os arquivos de alertas gerados.
Outro agravante desse processo é o de que muitas empresas não apresentam
uma política de segurança eficiente e implantada, quando a tem, abrindo brechas
enormes para a prática de vandalismo inclusive dentro da empresa. Com o
aperfeiçoamento das técnicas de ataque, diariamente surgem novas
vulnerabilidades que podem, facilmente, ser utilizadas por qualquer pessoa,
tornando o trabalho de um gerente de rede complexo e perigoso.
Neste contexto surgiram em 1998 as técnicas de IDS (Intrusion Detection
System), que segundo Martin Roesch [1] tem como principal objetivo detectar se
alguém está tentando entrar no sistema ou se algum usuário está tentando fazer
mau uso do mesmo.
Esta técnica define um sensor que é composto por um conjunto de
componentes, dentre eles: sub-sensor estático, sub-sensor inteligente e aprendiz.
Um sub-sensor estático deve inicialmente ser configurado de acordo com a política
de segurança além de possuir as assinaturas dos ataques conhecidos, já o subsensor inteligente inicialmente passa por um período de adaptação e aprendizagem,
fase em que o sensor aprende o padrão de funcionamento da rede, este período
pode ser variável dependendo do volume de tráfego. Após estas fases os subsensores estariam em condições de reconhecer padrões que fogem da normalidade
da rede e tomarem ações.
De acordo com campo de ação os sensores podem ainda ser classificados em
dois tipos:
Sensores de rede: deve estar localizado em segmentos estratégicos,
observando o tráfego da rede e os formatos de pacotes.
Sensores de host: ficam dentro dos servidores críticos, observando as ações
realizadas no sistema operacional, as ações dos servidores e o comportamento da
pilha TCP/IP (Transfer Comunication Protocol / Internet Protocol).[2].
Os sensores devem interagir entre si a fim de construírem uma matriz de
eventos que tem por objetivo a qualificação do padrão de ataque, minimizando
desta forma a ocorrência de alertas falsos.
Outras características fundamentais dos sensores são: o gerenciamento
centralizado, a possibilidade do sensor interagir com outros elementos de rede, tais
como: firewall, roteadores e consoles de gerência, possibilitando a construção de
uma base de conhecimento centralizada de forma a permitir uma visão ampla do
nível de segurança da rede.
2.1
Características de uma ferramenta IDS
Uma ferramenta IDS, segundo Martin Roesch [1], deve possuir algumas
características, entre elas:
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
323
•
Deve executar continuamente sem interação humana e deve ser segura o
suficiente de forma a permitir sua operação em background;
•
Ser tolerante a falhas de forma a não ser afetada por uma queda no
sistema, ou seja, sua base de conhecimento não deve ser perdida quando
o sistema for inicializado;
•
Resistir a tentativas de mudança (subversão) de sua base, ou seja, deve
monitorar a si próprio de forma a garantir sua segurança;
•
Ter o mínimo de impacto no funcionamento do sistema;
•
Poder detectar mudanças no funcionamento normal;
•
Ser fácil de configurar. Cada sistema possui padrões diferentes e a
ferramenta deve adaptar-se de forma fácil a cada um;
•
Cobrir as mudanças do sistema durante o tempo, como no caso de uma
nova aplicação que seja integrada ao sistema.
É importante referenciar os prováveis erros que podem acontecer ao sistema.
Estes, podem ser classificados como falso positivo, falso negativo ou erros de
subversão. A saber:
§
Falso positivo: quando a ferramenta classifica uma ação como possível
intrusão, tratando-se na verdade de uma ação legítima.
§
Falso negativo: ocorre quando uma intrusão real acontece, mas a
ferramenta permite que ela passe como se fosse uma ação legítima.
§
Subversão: ocorre quando o intruso modifica a operação da ferramenta
IDS para forçar a ocorrência de falso negativo.
2.2 Modelo conceitual de uma ferramenta IDS
Devido a uma grande variedade
de IDS, foi proposto um modelo
denominado CIDF (Common Intrusion Detection Framework )[3], que agrupa um
conjunto de componentes que caracterizam uma ferramenta de IDS. São eles:
§
Gerador de Eventos (E-box);
§
Analisador de Eventos (A-box);
§
Base de Dados de Eventos (D-box)
§
Unidade de Resposta (R-box);
Algumas características desejáveis destes componentes são:
§
Reutilização em um contexto diferente do qual foram originalmente
desenvolvidos, ou seja, devem ser configuráveis de forma a adaptarem-se
a ambientes distintos;
§
Elaboração em módulos com funções distintas;
§
Compartilhamento e troca de informações entre si via rede para uma
melhor precisão na identificação de ataques;
324
XI SEMINCO - Seminário de computação - 2002
§
Integração automática entre componentes novos e em uso;
§
Atuação mútua de componentes, dando a impressão de ser um único.
Também na padronização CIDF existe um modelo de linguagem para troca de
informações entre os componentes, o CISL (Common Intrusion Specification
Language) – este formato é referenciado como GIDO (Generalized Intrusion
Detection Objects).
2.2.1 Funções dos componentes
Gerador de eventos (E-box): A função deste componente é obter os eventos a
partir do meio externo ao CIDF, ou seja, ele “produz” os eventos mas não os
processa, isso fica a cargo do componente especializado na função de
processamento.
Analisador de eventos (A-box): Este componente basicamente recebe as
informações de outros componentes, analisa-as e envia-as de forma resumida para
outros componentes, ou seja, recebe os dados de forma bruta, faz um refinamento e
envia para outros.
Base de dados de eventos (D-box): A função deste componente é armazenar
os eventos e/ou resultados para uma necessidade futura.
Unidade de resposta (R-box): Este componente é responsável pelas ações, ou
seja, matar o processo, reinicializar a conexão, alterar a permissão de arquivos,
notificar as estações de gerência, etc...
2.2.2 A Comunicação entre componentes
A comunicação entre componentes é descrita em [3], por uma arquitetura de
macro camadas assim declaradas:
Nível Gido (Gido Layer): nesta camada mensagens recebidas e geradas no
meio externo ao CIDF podem ser trocadas por componentes condizentes com a
CIDF, provendo características como, por exemplo, a comprovação de origem de
uma mensagem ou mensagens com prioridade.
Nível de Mensagem (Message Layer): esta camada foi desenvolvida para
resolver problemas de sincronização, tipos de dados diferentes oriundos de
diversos sistemas operacionais ou o problema de grupos distintos de
programadores usarem linguagem de programação diferentes.
Nível de Transporte (Negotiated Transport Layer): A utilização normal dos
métodos de transporte de mensagens do CIDF sobre o UDP (User Datagram
Protocol –Serviço sem conexão não confiável, usando protocolo IP para
transportar mensagens entre duas máquinas) são eficientes. Porém quando
combina-se o Nível de Mensagem do CIDF com as propriedades do Nível de
Transportes gera-se uma linha de comunicação/transporte negociado que pode ser
usada para suportar requesições de diferentes aplicações.
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
325
Esta arquitetura garante a comunicação entre os elementos, bem como
sistema de criptografia e autenticação. Estes mecanismos estão definidos no Co mm
(Communication in the Common Intrusion Detection Framework).
A primeira ferramenta desenvolvida usando este novo paradigma foi o IDS
SNORT, criada por Martin Roesch em 1998, definido em [4] é um sistema de
detecção de intrusos em redes de peso leve, capaz de desempenhar em tempo real
análise de tráfego de pacotes em redes TCP/IP (Transfer Control Protocol/Internet
Protocol). Uma grande facilidade oferecida por esta ferramenta é a de ser
configurado de acordo com os critérios estabelecidos na política de segurança, uma
vez que, a ferramenta possui uma linguagem de definição de regras que permite a
criação de novos filtros a cada segmento de rede abordado.
Um dos problemas, enfrentado neste tipo de ferramenta é o seu arquivo de
logs das atividades monitoradas. Quando a ferramenta está totalmente configurada
são gerados muitos logs e armazenados em um arquivo no formato texto.
Para um gerente de rede que precisa agilidade na hora de verificar o que está
acontecendo em sua rede, o processo de filtrar estes logs é demasiado demorado e
impreciso, visto que o mesmo ainda precisa tratar estas informações caso queira
representar graficamente uma estatística.
O objetivo principal do SNORTFACE é desenvolver uma interface para
configurar, distribuir em rede e coletar informações do IDS SNORT.
2.3 Modelo do SNORTFACE
O objetivo do modelo proposto é atender de forma eficiente as necessidade de
monitoramento do tráfego das redes de computadores, fornecendo uma interface
única para análise das informações coletadas e configuração de novas regras,
objetivando uma visão centralizada da análise efetuada sobre os pacotes de dados
que trafegam na rede em múltiplos segmentos. Baseado nestas informações o
administrador poderá tomar atitudes orientadas ao segmento ou máquina que está
enviando ou recebendo algum tipo de ataque.
A partir da especificação do modelo acima referido foi desenvolvida uma
ferramenta que automatiza este processo levando em consideração algumas
características como:
Uso de SGBD (Sistema Gerenciador de Banco de Dados) para
Armazenamento de Dados: todos os dados do sistema serão armazenados em uma
base de dados objetivando uma maior agilidade na busca de informações ao
administrador para o gerenciamento de seu tráfego de rede.
Interface de Configuração/Consultas via Web: todas as consultas e inserção
de novas regras de ataques serão feitas através de páginas PHP[5] e HTML,
permitindo independência de local, podendo o acesso ser feito de qualquer rede,
local ou do mundo, caso a página esteja em um servidor Web com endereço IP
válido.
326
XI SEMINCO - Seminário de computação - 2002
Configuração dos filtros/assinaturas de ataque centralizada: quando da
inserção de uma nova regra de ataque ou um filtro para análise de pacotes TCP/IP,
o mesmo é atualizado em todos os servidores, facilitando a tarefa do administrador,
evitando o acesso a máquina no ambiente para a configuração.
Uso de Programação Estruturada: no desenvolvimento será utilizado
desenvolvimento estruturado buscando fornecer uma codificação simplificada e de
fácil portabilidade para outras linguagens como Java.
2.3.1 Definição dos módulos
Com base nas características citadas anteriormente, o modelo foi projetado
em três módulo:
Comunicação: responsável pelos processos de atualização das regras do
servidor para o agente, atualização do banco de dados do servidor com novos
alertas informados pela ferramenta Snort, através do agente, e execução de rotinas
de verificação do correto funcionamento do banco de dados. É composta pelas
aplicações IDSAgent e IDSServer.
Base de Dados: armazena as informações sobre novas regras criadas, agentes
que possuem a ferramenta Snort e a aplicação IDSAgent instalada, erros de
conexão com as aplicações agente e os alertas recolhidos pelo módulo
comunicação. A base de dados é denominada IDSBase.
Interface Web: módulo que possibilita ao usuário efetuar operações de
inserção, deleção, alteração e consulta sobre as informações armazenadas no banco
de dados de forma rápida e intuitiva.
Na Figura 1 é fornecida uma visão geral da ferramenta. Os agentes ficarão
instalados em servidores de rede ou segmentos de rede onde o IDS Snort poderá
monitorar todo o tráfego de informações
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
A g e n te 3
A g e n te 2
A gent e 1
S n ort
S nort
I DS A ge nt
ID S A g ent
S nor t
ID S A ge nt
M en sag em 1 - A tu ali zar re gras no Ag ent e
M en sag em 2 - A tu ali za a lert a s no S ervi dor
M en sag em 3 - E ncer ra co ne xão
S e r v i d o r C en tr a l
S nort
327
I DS A ge nt
I D S S e rve r
ID S B as e
A t ua li za a b ase de da dos
1 - E nv ia i nst ruçã o S Q L ao S er vid or
2 - Re ceb e re sul t ados em H TM L
3 - Re ali za op era ções sob re r egi st ro s
I nt er fa ce W e b
Figura 1: Visão Geral da Ferramenta
O servidor fará o processo de conexão com os agentes que informam sobre a
existência de novos alertas ou recebem novas regras. Quando a informação estiver
armazenada na base de dados poderá ser consultado pelo administrador através da
interface Web.
Na Figura 2 é apresentado o fluxograma do IDSAgent. Este, ao ser
inicializado ativa uma porta padrão para conexão e fica aguardando para que o
servidor o conecte. Quando conectado, trata a informação recebida identificando o
tipo de protocolo enviado.
Se a mensagem for a de solicitar novos alertas, o mesmo abre o arquivo de
alertas do IDS Snort, verifica a existência de novos registros, se existindo, envia-os
para o servidor, caso contrário envia uma mensagem encerrando a conexão.
Caso a mensagem for a de receber regras, fica recebendo informações
enquanto for regra e as insere no arquivo de regras do IDS Snort, quando termina,
encerra a conexão e volta ao estado inicial, aguardando nova conexão do servidor.
328
XI SEMINCO - Seminário de computação - 2002
ID S A g en t
S T AR T
A TIV A R
PO R T A
E N VI A
M E N S A GE M
( FIM C O N E X Ã O)
A G UA R DA R
CO NE X Ã O
R E C E BE
CO NE X Ã O
F E CHA A RQ
R E GR A S
A N AL IS A
P R O TO C
M EN SAG E M
1
A BR E A R Q
R E GR A S
NÃ O
RE CE B E
DA DO S
É
RE G RA ?
MEN S AG EM
2
S IM
A B R E A RQ
A LE RT A S
NO V O S
A L E R TA S ?
GR A V A R E G .
A RQ R E G RA S
NÃ O
NÃ O
S IM
E N V IA
A LE RT A S
F IM
A RQ ?
S IM
FE C H A A R Q
A L E R TA
A T U A L IZA
A RQ T A M
Figura 2: Fluxograma do IDSAgent
A Figura 3 apresenta o fluxograma do IDSServer, que baseado em um
temporizador fará inicialmente uma conexão com a base de dados, se obtiver
sucesso, selecionará as máquinas agentes e iniciará a conexão com as mesmas. Se a
base não estiver ativa grava em um arquivo de log, e tenta inicializar a base.
Se a conexão com o agente for bem sucedida, solicita novos alertas, enviando
a mensagem de serviço para o agente. Este responde com alertas ou informa se
não existirem, se existem o servidor recebe a informação e armazena no banco de
dados. Em seguida avisa ao agente da existência de novas regras e as envia.
Terminado este processo, verifica se existem mais agentes a serem conectados e
reinicia o processo para o próximo agente. Se não consegue conectar com
determinado agente, grava um erro no banco de dados e retorna selecionando a
próxima máquina a ser conectada.
O IDSServer será executado por tempo indeterminado, toda vez que um ciclo
de conexões é terminado o temporizador é inicializado.
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
329
ID S S erve r
2
ST AR T
1
NÃ O
NÃ O
S LE E P
( TIM E )
S IM
SI M
C O N E C T OU
B . D A D OS
3
ABR E T AB
MÁ Q AG EN T E
SI M
4
E N V IA
R E GR A
A RQ
TE R M I N O U
SI M
E XIST E
R E G R A?
NÃ O
NÃ O
S IM
FI M
R E GR A S ?
MEN SAG EM
1
C O N E C T OU
A G E NT E ?
N ÃO
NÃ O
S IM
M E NS A G E M
2
G RA V A L O G
A R Q E RRO
A T U A L I ZA TA B
M Á Q RE G RA
RE CE B E
D A D OS
1
INICIALIZA
TEMPORIZADOR
2
GRAVA ERRO
ARQ. LOG
4
ENCERA
CONEXAODB
É
A L E RT A ?
COMANDO INICIALIZA
BANCO DE DADOS
1
3
S IM
GR A V A
A LE RT A S
B . D A DO S
N ÃO
F IN A L IZ A
C O NE X Ã O
A T U A L IZ A T A B
M Á Q A G E NT E
Figura 3: Fluxograma do IDSServer
Para evitar ataques do tipo “Deny of Service” na porta utilizada para
comunicação entre agente e servidor é necessário a utilização de um terceiro
elemento, pois o pacote necessita ser bloqueado antes de chegar ao destino.
Portanto uma das formas de evitar este tipo de ataque seria utilizando filtros de
pacotes em roteadores, ou switches que suportem nível 3.
3 Testes
Para comprovar a eficácia da ferramenta desenvolvida foi necessário um
cenário para a realização do teste. Foi utilizado a rede da Universidade Regional
Integrada do Alto Uruguai e das Missões, campi de Frederico Westphalen. A
Figura 5.1 apresentada demonstra os principais componentes da estrutura da rede.
330
XI SEMINCO - Seminário de computação - 2002
Figura 4: Estrutura da rede da URI-FW
Foi definida a máquina Scutun, representada na Figura 4 com dois círculos,
como servidor central. Nesta máquina estão sendo executados o sistema
operacional Conectiva Linux versão 6.0, servidor de páginas Apache HTTP Server
versão 1.3, interpretador de comandos PHP versão 3.0.16, banco de dados MySQL
versão 3.23.25, ferramenta Snort versão 1.16, IDSServer e o IDSAgent.
As máquinas Pluton e Lab234 foram definidas com agentes. São executados
o sistema operacional Conectiva Linux 6.0, Snort versão 1.6 e o IDSAgent. Em
seguida a ferramenta Snort foi colocada em execução nestas máquinas, começando
a analisar os pacotes de dados e gerar alertas. O IDSAgent foi iniciado, aguardando
a conexão com o IDSServer.
Os agentes foram cadastrados pela página de manutenção de agentes. O
IDSServer foi colocado em operação e iniciou o processo de conexão com os
agentes atualizando as regras e recebendo os alertas.
A eficácia foi comprovada, pois os alertas gerados pela ferramenta Snort,
instalada nos agentes e no servidor, foram inseridos na base de dados do servidor e
posteriormente consultados pela interface Web. Desta forma, foi possível a analise
de informações oriundas, por exemplo, de um agente localizado em um segmento
de rede que possui dois switches.
A Figura 5 apresenta uma das telas da interface, onde pode ser verificado
que existem dois agentes. A cor verde representa agente em atividade, já a cor
vermelha, agente desativado.
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
331
Figura 5: Interface para Operações com Agentes
Pode-se também observar a situação dos agentes em relação a alertas, como
mostra o ícone mostrado no lado direito da interface, conforme a Figura 6.
Existência de alertas a serem analisados para o agente
Todos alertas analisados para o agente.
Figura 6: Ícones para página Agente
Se o usuário tivesse que consultar a todo o momento as máquinas agentes
buscando as novas informações, teria um gasto adicional de deslocamento e
identificação dos novos alertas. Um fato importante é que ambas as aplicações
IDSAgent e IDSServer, para serem executadas, necessitam de permissões do
usuário administrador do sistema.
4 Conclusões
Algumas ferramentas são especializadas apenas em analise de logs, outras
em gerar logs, desta forma torna-se onerosa a tarefa do administrador de redes, que
necessita juntar fragmentos de analises realizadas pelos diferentes programas
existentes. O modelo SNORTFACE propõe a facilidade da consulta a diversos
agentes que estão distribuídos pela rede, analisando os logs de forma centralizada
332
XI SEMINCO - Seminário de computação - 2002
usando uma interface gráfica fornecida pelo browser do usuário através de páginas
HTML criadas dinamicamente por consultas efetuadas em uma base de dados,
permitindo também a inserção de novas regras de ataques. O administrador não
terá a necessidade de acessar individualmente cada uma das máquinas monitoradas
pela ferramenta IDS, pois este processo é feito de forma centralizada e
transparente.
A possibilidade de armazenamento de logs das atividades monitoradas nos
servidores que estão instalados em outros segmentos de rede separados por
switches, é outro grande diferencial, pois desta forma o administrador consegue em
uma visão centralizada analisar toda a rede, evitando a necessidade de várias bases
de dados, uma para cada segmento de rede.
O desenvolvimento da ferramenta foi efetuado com a utilização de uma
aplicação em rede usando Socket [6] escrita no paradigma estruturado, objetivando
no futuro, adaptações sem grandes traumas aos demais módulos e agilizando o
reaproveitamento de código. As páginas HTML foram criadas utilizando PHP, que
permitirá um conteúdo dinâmico, refletindo os dados armazenados no banco de
dados. O armazenamento em banco de dados das informações analisadas foi
solucionado com o uso de MySQL.[7]
Durante o desenvolvimento do modelo conceitual da ferramenta, foram
realizadas várias analises, buscando a otimização na forma de armazenar os dados
e na execução das aplicações cliente e servidor. Estas analises permitiram a
criação de uma base de dados enxuta e de fácil manipulação, evitando demoradas
instruções SQL repletas de condições e necessitando unir várias tabelas.
As aplicações agente e servidor tiveram atenção especial. Seu
desenvolvimento foi feito objetivando a criação de um código simples, utilizando
comandos básicos da linguagem C, de fácil entendimento. A transparência das
operações para o usuário é fundamental, pois a aplicação fica sendo executada sem
que o usuário tenha conhecimento efetivo de sua existência.
As páginas Web necessitaram de um tempo maior para serem
desenvolvidas. A visualização dos resultados, a criação das instruções conforme a
seleção de critérios e o processo de ajuste foram onerosos. O resultado é uma
página útil, de fácil operação, permitindo ao usuário a realização de operações de
inserção, alteração, consulta e exclusão sobre os registros armazenados na base de
dados. As operações são disparadas pelo cliente, executadas no servidor e apenas a
página com os resultados é apresentada.
Os testes realizados com a ferramenta SNORTFACE mostraram que, a
atualização dos alertas no banco de dados, a atualização das regras nos arquivos da
ferramenta Snort e a visualização centralizada destas informações, permite sua
utilização em ambientes geograficamente distribuídos, pois novos agentes podem
ser acrescentados em tempo real. Esta característica e ponto fundamental quando
observa-se a distância entre os pontos na Internet, ou mesmo a necessidade de uso
de ferramentas IDS em ambientes comutados.
SNORTFACE: Um Modelo de Interface para Ferramentas IDS
333
Atualmente, a eficiência da administração de segurança da rede é expressa
na velocidade com que são diagnosticadas e analisadas tentativas de invasão. A
ferramenta SNORFACE apresenta uma forma rápida, eficaz e útil de auxiliar nesta
tarefa, o que o torna um sistema viável e atual.
Referências bibliográficas
[1] ROESCH, Martin. The Open Source Network Intrusion Detection for
Networks. Disponível em: http://www.snort.org. Acesso em:26 de junho de 2001.
[2]
RFC.
Request
for
Comment
(0791
/
0793).
Disponível
em:http://www.ietf.org/rfc.html. Acesso em: 26 de junho de 2001.
[3] CIDF Site.Common Intrusion Detection Framework. Disponível em:
http://www.isi.edu/gost/cidf/. Acesso em: 25 junho de 2001.
[4] BAKER, Andrew R. SNORT Documentation . Disponível em
http://www.dpo.uab.edu/~andrewb /snort/snortdocs/snort.html. Acesso em 26 de
junho de 2001.
[5] PHP: Personal Home Page. Disponível em: http://www.php.net. Acesso em:
25 de junho de 2001.
[6] STEVENS, W. Richard. UNIX Network Programming – Networking APIs:
Sockets and XTI, Volume 1, Second Edition, Prentice Hall PTR, 1997.
[7] MYSQL PAGE. Disponível em: http://www.mysql.com/. Acesso em: 26 junho
de 2001.
334
XI SEMINCO - Seminário de computação - 2002