Refinando análises do Snort através de correlação com o estado ativo da rede

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

101 
REFINANDO ANÁLISES DO SNORT ATRAVÉS DE CORRELAÇÃO 
DE EVENTOS COM O ESTADO ATIVO DA REDE 
 
Cleiton Soares Martins 
Centro de Informática - Universidade Federal de Pernambuco 
Caixa Postal 7851, CEP 50732-970 - Recife - PE – Brasil 
csm@cin.ufpe.br 
André Luis Medeiros Santos
 
 
Centro de Informática - Universidade Federal de Pernambuco 
Caixa Postal 7851, CEP 50732-970 - Recife - PE – Brasil
 
alms@cin.ufpe.br 
 
Cristiano Lincoln Mattos 
Tempest Security Technologies / UFPE 
Rua do Apolo, 181, Bairro do Recife, CEP 50030-220 
Recife - PE – Brasil 
lincoln@tempest.com.br
 
 
Evandro Curvelo Hora
 
Tempest Security Technologies / UFPE / UFS 
Rua do Apolo, 181, Bairro do Recife, CEP 50030-220 
Recife - PE – Brasil 
evandro@tempest.com.br
 
 
 
RESUMO 
 
O snort é um sistema de detecção de intrusão de redes, baseado em assinaturas amplamente utilizado. A criação e 
manutenção de bases de assinaturas que capturem os eventos mais intrusivos e ao mesmo tempo evitem falsos positivos e 
falsos negativos é uma tarefa não trivial que consome muito tempo e altamente dependente da experiência e da paciênia 
do administrator de segurança. Esse documento propõe uma metodologia para refinar a análise de eventos gerados pelo 
snort através da correlação desses eventos com uma representação do estado ativo da rede protegida. Agentes 
distribuídos são utilizados para coletar e manter o estado da rede. Os eventos são processados por um analizador central 
que usa um sistema de produção para agrupar esses eventos e classificá-los quanto ao risco por eles oferecidos. 
Argumentamos que o uso de bases de assinaturas genéricas e a posterior priorização dos eventos usando a metodologia 
proposta pode aumentar significativamente a qualidade da análise e reduzir consideravlemente o esforço e tempo 
necessários para implantar o snort na maioria das redes. 
 
ABSTRACT 
 
Snort is a widely used freeware, signature based, network intrusion detection system. The task of creating a signature 
ruleset that catches most intrusive events avoiding false positives and false negatives is very difficult, can be very time-
consuming and greatly depends on security managers’ expertise and patience.In this paper we propose a methodology to 
improve the analysis of snort-generated events by correlating them with a live representation of the the state of the 
protected network. Distributed Agents are used to gather and mantain current network state. Events are processed by a 
central analyzer that uses a java embedded production system to group these events together and classify them according 
to the risk they offer to the protected network. We argue that by using a standard snort ruleset and by classifying events 
generated by snort with the proposed methodology we can significantly increase the quality of the analysis and greatly 
reduce the effort and time needed to deploy snort on most networks. 
 
 
 
102 
1. INTRODUÇÃO 
1.1. Segurança e Detecção de Intrusão 
O interesse no desenvolvimento de sistemas 
para aumentar o nível de segurança de redes de 
computadores tem crescido bastante nos últimos 
anos. Abordagens variam desde a instalação de 
firewalls de rede, passando pela reconfiguração 
segura (hardening) dos servidores até o 
desenvolvimento de aplicações mais seguras 
baseadas em rígidas metodologias formais e de 
testes. O conjunto de várias dessas medidas pode 
garantir um nível aceitável de segurança, porém 
esse nível deve ser mantido através de contínua 
monitoração. 
Neste contexto surgiram as ferramentas de 
detecção de intrusão e anomalias, que procuram 
antecipar possíveis tentativas de invasão através 
de detecção na rede de padrões de ataques 
conhecidos ou detectar ocorrência bem sucedida 
de invasões através de mudanças significativas 
sofridas nos sistemas. 
Historicamente esses sistemas, conhecidos 
como Sistemas de Detecção de Intrusão (IDS), 
têm sido classificados quanto ao tipo de dados 
analisados e quanto ao método de análise: 
 
• Quanto ao tipo de dado analisado 
De rede: Coletam os pacotes que trafegam na rede 
monitorada. Normalmente capturam dados nos 
pontos de estrangulamento da rede (roteadores ou 
firewalls), seja rodando diretamente nesses 
elementos ou através de cópia de dados utilizando 
dispositivos de rede como hubs e switches. 
De host: Utilizam informações coletadas nos 
sistemas operacionais tais como registros de 
auditoria (logs), saída de programas de 
monitoração e informações de estado do S.O. 
 
• Quanto ao método de análise 
Por Assinatura: Utilizam características comuns 
de ataques bem-conhecidos para classificar os 
dados coletados em normais ou maliciosos. 
Por Anomalias: Constroem padrões de uso 
normal dos sistemas e detectam desvios 
significativos desses padrões como indicativo de 
possíveis atividades maliciosas. 
A manutenção de muitos analisadores 
independentes pode ser difícil. Normalmente a 
reconfiguração desses detectores exige a alteração 
de arquivos de propriedades, adição de novos 
módulos e a reinicialização do serviço. A ausência 
de correlação entre dados capturados em diversos 
pontos de análise pode impedir a detecção de 
determinados tipos de ataque. Por exemplo, 
algumas poucas tentativas de logon mal-sucedidas 
em um único serviço podem ser consideradas 
normais e toleradas, porém a repetição dessas 
falhas em vários servidores da rede pode indicar 
uma tentativa de invasão. 
A qualidade das análises realizadas por esses 
detectores geralmente depende demasiadamente 
na habilidade do administrador em ajustar (e 
manter ajustados) os parâmetros desses sistemas 
para refletir as necessidades da rede monitorada. 
A tarefa de ajustar esses parâmetros costuma ser 
árdua e dificilmente se consegue chegar a um 
balanço ideal entre o número de alertas falsos 
gerados, também conhecidos como falsos 
positivos, e a ausência de alertas em situações de 
perigo real, os falsos negativos. 
A ausência de correlacionamento com o estado 
atual das redes monitoradas é uma grande 
deficiência, principalmente nos sensores de rede 
baseados em assinaturas. A natureza genérica de 
suas regras e a velocidade das mudanças do estado 
da rede dificultam o “ajuste fino” desses sistemas. 
Não são raras as situações em que o número de 
alarmes gerados representando situações com 
pouca ou nenhuma relevância para a segurança da 
rede acaba por mascarar os alertas realmente 
perigosos. 
1.2. Snort – The Open Source Network 
Intrusion Detection System 
O Snort [1] é uma ferramenta de detecção de 
intrusão de rede baseado em assinaturas, que 
funciona em várias plataformas e pode ser usado 
para monitorar redes TCP/IP de pequeno e médio 
portes e detectar uma grande variedade de tráfego 
de rede suspeito e ataques explícitos. Ele pode 
prover aos administradores dados suficientes para 
tomar decisões sobre a atitude a ser tomada em 
face a atividades suspeitas. 
A grande vantagem do snort em relação a 
muitos produtos comerciais é a velocidade com 
que assinaturas para novos ataques são lançadas. 
Por contar com uma grande quantidade de 
usuários em todo o mundo, muitos dos quais 
capazes de desenvolver rapidamente assinaturas, o 
snort consegue se manter atualizado em relação 
aos problemas de segurança, enquanto os 
vendedores de produtos comerciais tendem a 
retardar a publicação de suas atualizações. 
O funcionamento interno do snort é baseado 
na libpcap, uma biblioteca de captura de pacotes 
amplamente utilizada, desenvolvida inicialmente 
para ser usada no programa tcpdump. Sua 
principal característica é a utiliação de regras para 
103 
o casamento de padrões no conteúdo dos pacotes 
com o objetivo de detectar uma grande variedade 
de ataques, tais como buffer overflows, ataques a 
CGIs, varreduras,
entre outros. O engenho de 
detecção é programado utilizando uma linguagem 
(regras) que descreve testes e ações a serem 
realizados para cada pacote capturado. 
A principal fraqueza do snort é grande 
quantidade de alarmes falsos tipicamente emitidos 
ao utilizar bases de assinaturas genéricas. Quanto 
mais refinada e adequada à rede monitorada for a 
base de regras, menor o número de falsos 
positivos gerados, porém mais complexa se torna 
sua manutenção. Novas regras são 
disponibilizadas com grande freqüência e sua 
inserção em bases de assinaturas altamente 
customizadas constitui uma tarefa não trivial. 
1.3. IDSs com Agentes Distribuídos 
Muitas das limitações dos sistemas 
tradicionais podem ser minimizadas pela 
utilização de características presentes em sistemas 
distribuídos: 
• Tolerância a Falhas: o sistema deve ser 
capaz de continuar funcionando caso alguma 
parte dele apresente falhas, sejam elas 
causadas por acidente ou por eventuais 
ataques ao sistema. 
• Escalabilidade: novas partes do sistema 
devem ser facilmente adicionadas sem haver 
a necessidade de se reconfigurar e reiniciar 
todo o sistema. Alterações em partes 
específicas do sistema podem ser realizadas 
de forma localizada sem afetar as outras 
partes. 
• Distribuição de carga: como parte do 
processamento é realizado em cada um dos 
servidores da rede monitorada pode-se evitar 
a sobrecarga característica de detectores 
centralizados. 
• Correlação de dados: a troca de mensagens 
entre as diversas partes do sistema possibilita 
a análise global dos eventos ocorridos na rede 
monitorada. 
A maior parte dos sistemas de detecção de 
intrusão tradicionais é restrita na análise dos 
dados coletados. A estratégia mais comum é a de 
coletar informações, fazer um casamento de 
padrões com regras pré-estabelecidas pelos 
administradores ou desenvolvedores do sistema e 
gerar alertas e relatórios quando acontecerem 
eventos previstos por essas regras. A quantidade 
de alertas falsos e o volume de informações 
irrelevantes gerados por esses sistemas sugerem a 
necessidade de um processamento mais efetivo 
das informações antes da geração dos alarmes e 
relatórios. 
A utilização de agentes inteligentes tem sido 
considerada como estratégia para otimizar a 
análise realizada pelo sistema [2,3,4,5]. A 
utilização de técnicas de mineração de dados 
ajuda a identificar partes relevantes da grande 
massa de dados possivelmente coletadas de 
diversas fontes, tais como logs, processos de 
monitoramento e analisadores de tráfego. 
Agentes que possuam a capacidade de 
aprendizagem podem ajudar na detecção de 
ataques realizados de formas não previstas ou que 
não tenham sido estudadas e documentadas 
previamente. A utilização de redes neurais 
treinadas com a utilização de ferramentas de 
ataque bem conhecidas é uma área incipiente de 
pesquisa. 
1.4. Sistemas Especialistas em IDS 
Sistemas Especialistas são programas de 
computadores que utilizam conhecimento 
explicitamente representado e técnicas de 
inferência computacional para reproduzir ou 
imitar o comportamento de especialistas humanos 
em um domínio específico. Uma abordagem 
comum é utilizar regras de produção que utilizam 
fatos da base de conhecimento para inferir novos 
fatos e tomar decisões ou gerar soluções para os 
problemas propostos. 
O papel do especialista humano no processo 
de detecção de intrusão pode ser, de forma 
bastante simplificada, resumido como: observar o 
comportamento suspeito, deduzir o risco 
associado a esse comportamento e quando 
necessário efetuar contra-medidas para reduzir ou 
anular esse risco. 
 Alguns IDS baseados em sistemas 
especialistas já foram desenvolvidos e obtiveram 
relativo sucesso. Como exemplo pode-se citar o 
NIDES[6] e o EMERALD[7]. A grande 
dificuldade desses sistemas é a de se manterem 
atualizados frente as constantes mudanças nas 
metodologias e ferramentas de ataque. Por 
agregarem numa só ferramenta os mecanismos de 
detecção e análise esses sistemas perdem 
flexibilidade e por não possuirem uma grande 
base de usuários e colaboradores sua evolução 
tende a tornar-se lenta e não atender as 
necessidades do mercado. 
 
104 
2. COMPONENTES DO SISTEMA 
 
A metodologia proposta nesse documento 
difere dos sistemas existentes em grande parte 
pela sua simplicidade. Ao invés de tentar 
(re)desenvolver todo um sistema de detecção de 
intrusão, com todas as suas complexidades de 
captura de pacotes, casamento de padrão, 
desenvolvimento de linguagem para criação de 
assinaturas e análise de eventos, propõe-se 
quebrar a tarefa em duas grandes partes: a geração 
de eventos e a sua análise. A primeira tarefa já é 
muito bem realizada de forma madura e eficiente 
por IDSs de código aberto como o snort e por 
isso essa função é delegada à ele. 
O esforço de desenvolvimento do sistema 
concentra-se então em extrair os alertas gerados 
pelo IDS, convertê-los para um formato padrão, 
enviá-los para um processador central e aí sim 
realizar toda a análise, apresentando para o 
usuário final um resultado bem mais refinado do 
que aquele oferecido apenas pelo snort. 
Nessa seção serão descritos os principais 
componentes do sistema e de que forma eles 
interagem durante todo o processo de coleta e 
análise. 
2.1. Sensores 
Coletam informações relevantes em diversos 
pontos da rede. Tipicamente constituídos por 
sistemas já existentes com adaptadores 
desenvolvidos para transformação dos dados 
coletados para formatos intermediários próprios, 
cujo processamento será realizado por outros 
componentes do sistema. 
O sensor formado pelo snort e pelo seu 
adaptador (atualmente chamado de snortAdmin) 
gera alertas baseados no mecanismo de 
reconhecimento de assinaturas de ataques descrito 
na seção 1.2. Esses alertas são enfileirados e, de 
acordo com critérios como número de alertas e/ou 
intervalo entre transmissões, são enviados para o 
módulo de análise. Esses critérios são definidos 
pelo usuário na inicialização do snortAdmin e 
devem poder ser alterados sempre que necessário. 
O adaptador snortAdmin também permite efetuar 
operações administrativas no snort, tais como 
mudanças de configuração, inserção e remoção de 
assinaturas e re-inicializações. 
Um outro sensor utiliza os eventos disparados 
pelo arpwatch [8] para identificar novas máquinas 
na rede. Sabendo da existência dessas máquinas 
um ou mais coletores remotos podem ser 
disparados para fazer o levantamento do maior 
número de informações possíveis sobre essas 
máquinas. 
2.2. Coletores 
O processo de análise é altamente baseado 
numa base de conhecimentos que visa representar 
o estado ativo da rede monitorada. Idealmente 
essa base deve conter informações sobre todos os 
elementos da rede, assim como os serviços por 
eles oferecidos e eventuais vulnerabilidades 
conhecidas desses serviços. 
Para criar e manter essa base de 
conhecimentos são utilizados agentes distribuídos 
pela rede que coletam as informações necessárias 
e as enviam para a central de análise de forma a 
serem armazenadas na base. 
Duas etapas distintas são utilizadas para a 
montagem do estado da rede: levantamento inicial 
e manutenção contínua. Ao implantar o sistema na 
rede, vários agentes são disparados para descobrir 
e montar o estado inicial. Ao longo das análises 
poderá ser necessário fazer atualizações e novas 
inserções na base. Também é permitido ao 
administrador do sistema fazer alterações manuais 
nessa base através da interface com o usuário, 
possibilitando um maior refinamento e uma 
representação mais precisa da rede. 
A estratégia adotada para coleta distribuída de 
informações sobre os elementos de rede é 
semelhante à usada nos sensores: reaproveitar 
sempre que possível dados colhidos por 
ferramentas especializadas e consagradas,
converter esses dados para formato comum e 
extrair as partes mais relevantes desses dados para 
montar e manter o estado ativo da rede. 
Alguns exemplos de ferramentas que estão 
sendo usadas para criação e manutenção da base: 
• Nmap – The Network Mapper [9]: 
ferramenta amplamente utilizada para 
levantamento remoto de informações sobre 
serviços acessíveis, versões desses serviços e 
dos sistemas operacionais dos nós da rede. 
Por já fornecer saída em formato XML a 
adaptação de dados de saída é simplificada. 
• Enumeradores Windows: informações 
como versões de softwares instalados, 
serviços oferecidos, rotas e conexões de rede 
entre outros podem ser remotamente 
enumerados utilizando sessões nulas Netbios 
[10] ou SNMP [11]. Nos casos onde esses 
serviços não são remotamente acessíveis 
pode-se utilizar coletores locais instalados 
nos servidores windows. 
• HFNetCheck [12]: ferramenta desenvol-vida 
em parceria pela Microsoft e Shavlik 
Technologies permite identificar programas 
desatualizados e oferecendo referências falhas 
associadas. A coleta remota requer 
credenciais válidas no servidor alvo ou 
105 
relações de confiança entre as estações 
coletoras e os alvos. Em algumas situações 
também pode ser necessária a instalação de 
coletores locais. 
Outras ferramentas desenvolvidas 
internamente são utilizadas para complementar as 
informações necessárias que não são 
integralmente fornecidas por ferramentas 
conhecidas, entre elas: 
• Serviços Unix: coletores instalados 
localmente fazem o levantamento de 
informações sobre serviços oferecidos por 
sistemas operacionais Unix. Por serem locais 
têm acesso a informações mais precisas e 
detalhadas que aquelas coletadas pelo Nmap. 
• Regras de Firewall: para avaliar a 
acessibilidade de serviços o módulo de 
análise pode avaliar as regras de firewall que 
protegem as redes. Para isso foram 
desenvolvidos coletores para iptables [13] e 
Firewall-1 [14]. 
• Registro Windows: a presença de chaves 
específicas de registro podem indicar a 
infecção de máquinas windows por vírus ou 
worms. Coletores locais foram desenvolvidos 
com a finalidade de fazer esse levantamento e 
reportá-los para a matriz de 
correlacionamentos. 
2.3. A Matriz de Correlacionamentos 
O sistema proposto neste documento faz parte 
de uma plataforma, ora em desenvolvimento, para 
gerenciamento escalável de segurança de 
ambientes, com foco na minimização da 
intervenção manual para uma análise de 
segurança, mantendo a ótica da continuidade do 
processo. Esta plataforma deve prover uma 
estrutura que permita a realização de 
levantamentos de segurança automatizados, 
contando também com recursos para 
armazenamento, extração e análise cumulativa dos 
dados de segurança recolhidos. 
Existe uma vasta gama de ferramentas para 
análise de segurança, mas a maioria é bem 
específica, fortemente orientada a uma 
determinada plataforma ou para determinados 
serviços. Como não seria factível reimplementar 
todas estas ferramentas de forma integrada, a 
plataforma deve ser flexível e permitir a 
integração das várias ferramentas existentes, 
normalizando os diferentes formatos de saída, de 
forma a facilitar o posterior processamento e 
análise. 
Neste sentido, a plataforma funciona como um 
agregador das diferentes ferramentas existentes no 
mercado, que se integram a ela. Essa integração 
também provê outros benefícios: a plataforma 
deve esforçar-se para prover uma console única de 
gerência das ferramentas, tanto para execução e 
fornecimento de opções quanto para o 
armazenamento e recuperação de informação. 
Depois que as informações recolhidas pelas 
ferramentas são normalizadas e integradas na 
plataforma, existe espaço para realização de 
operações de análises mais detalhadas e que 
agregam uma visão abrangente do ambiente, ao 
invés da visão fragmentada provida por cada 
ferramenta individualmente. Por exemplo: 
• análises históricas de tendências, ataques e 
falhas de configuração; 
• geração de relatórios consolidados com a 
visão geral da segurança do ambiente em 
termos de vários critérios (vulnerabilidades, 
novos pontos ativos, etc.); 
• disparo de alarmes programados em caso de 
eventos de segurança pré-definidos, como a 
descoberta de um sistema vulnerável, ou um 
registro de ataque oriundo de um IDS como o 
snort; 
• correlação de eventos de intrusão que 
individualmente não se distinguem mas que 
analisados em conjunto podem revelar 
ataques; 
2.4. Interface com o Usuário 
Um ponto crucial para o bom funcionamento 
do sistema é uma interface amigável e intuitiva 
com o usuário. Os eventos já classificados devem 
ser mostrados de forma simples e direta permitido 
ao administrador rapidamente identificar a 
gravidade do ataque e tomar decisões em tempo 
hábil. 
Também deve ser permitido ao administrador 
modificar os valores do estado da rede 
possibilitando a alteração em tempo real dos 
resultados das análises nos casos em que os 
resultados iniciais são equivocados, pois as 
premissas estavam erradas. Com isso a qualidade 
da análise tende a evoluir ao longo do tempo 
tornando-se cada vez mais representativa. 
 
3. IMPLEMENTAÇÃO 
3.1. Linguagens de Programação 
A escolha da linguagem de programação para 
implementação das diversas partes do sistema está 
intimamente ligada às necessidades de cada uma 
dessas partes. 
Os sensores e coletores foram implementados 
na linguagem Perl, pelas seguintes motivações: 
flexibilidade, portabilidade, popularidade e larga 
106 
biblioteca de componentes publicamente 
disponíveis. Até agora, esta decisão tem se 
sustentado, dadas as facilidades oferecidas pela 
linguagem. Atualmente os sensores e coletores já 
foram testados em vários sistemas operacionais 
como Linux, FreeBSD, Solaris, AIX, HP-UX, 
Windows NT e Windows 2000. 
A Matriz de Correlacionamentos está sendo 
implementada utilizando a linguagem Java. Essa 
decisão foi tomada porque esse devido a 
necessidade de robustez, escalabilidade, 
extensibilidade e estabilidade. A linguagem Java 
adequa-se melhor a este tipo de problema, por 
suas características de orientação a objeto e 
robustez. Além disso a decisão pela utilização de 
um sistema de produção embarcado em uma 
linguagem de programação orientada a objetos 
norteou a escolha do JEOPS (descrito na seção 
3.5) e colaborou para a adoção de Java no módulo 
de análise. 
3.2. Mapeamento Objeto Relacional 
Os dados que representam o estado da rede 
assim como os resultados das análises e os 
eventos devem ser salvos em banco de dados. Só 
assim esses dados podem ser mantidos após 
reinicializações do sistema e podem ser usados 
para posterior geração de relatórios, assim como 
para a avaliação das análises. Ao mesmo tempo 
esses dados devem ser acessados pelo módulo de 
análise da forma mais simples e direta o possível. 
Por esses motivos optou-se pela utilização do 
Torque [15]. 
O Torque é uma camada de persistência. Ele 
gera todos os recursos necessários para a 
aplicação acessar o banco de dados, incluindo 
classes representando as tabelas e os dados além 
de um ambiente de tempo de execução com 
características como controle de transações e pool 
de conexões. Algumas vantagens de usar o 
Torque: 
• O processo de criação das tabelas no banco e 
das classes de acesso é semi-automático, 
bastando especificar o modelo de dados em 
XML. 
• O próprio processo de criação de esquemas 
XML representando o modelo de objetos 
ajuda a criar a documentação do sistema. 
• O acesso aos dados é bastante facilitado, 
abstraindo (pelo menos para as operações 
básicas) a necessidade do conhecimento de 
SQL, JDBC, etc. 
3.3. Mecanismos de Comunicação 
A troca de dados entre os módulos de análise 
e os sensores e coletores é realizada utilizando
um 
canal de comunicação seguro, cifrado e 
mutuamente autenticado utilizando o protocolo 
SSL/TLS com criptografia forte e certificados 
digitais padrão X.509 fornecidos por Autoridade 
Certificadora gratuita [16]. Através deste canal 
são trocadas mensagens de diferentes tipos, 
incluindo requisições de execução, respostas a 
pedidos de execução, notificações originadas 
pelos sensores, entre outras. As mensagens são 
formatadas de acordo com o padrão XML, o que 
traz uma série de benefícios: estrutura hierárquica 
de mensagens, independência dos dados, 
diferentes tipos de codificação e facilidades para 
extensão e mudanças no formato da mensagem. 
3.4. Módulo de Análise 
O módulo de análise da matriz de 
correlacionamentos é o elemento central da 
arquitetura. Ele recebe os eventos coletados pelos 
sensores, agrupa-os e classifica-os através de 
sistemas de produção. Durante a análise pode ser 
necessário acionar novos agentes em pontos 
distintos da rede para adicionar informações vitais 
para a realização da análise à base de 
conhecimento. 
Inicialmente os eventos são agrupados de 
acordo com critérios como endereços de origem e 
destino, tipos de ataques, etc. Esse agrupamento é 
feito através de regras simples de produção. Para 
cada novo evento, tenta-se associá-lo a um ou 
mais análises existentes. Caso ele não se encaixe 
em nenhum critério de agrupamento uma nova 
análise é criada contendo apenas esse evento. 
Através da correlação com o estado da rede 
cada evento recebe um escore de risco que é 
montado através da seguinte fórmula: 
 
Risco = 103 . Vuln + Pri (102 . Serv + Ativo) , 
onde: 
• Pri: Prioridade definida para esse evento na 
base de assinaturas do snort 
• Vuln: Define o grau de vulnerabilidade do 
serviço ao ataque (valores 0 ou 9) 
• Serv: Define se o serviço é oferecido na 
máquina alvo (valores 0 ou 1) 
• Ativo: Define se a máquina alvo está ativa na 
rede (valores 0 ou 1) 
 
O uso das potências de 10 na equação acima 
gera escores que permitem, por si só, sem a 
necessidade de cálculos adicionais, identificar se 
os critérios de vulnerabilidade, serviço oferecido e 
107 
servidor ativo foram satisfeitos e qual foi a 
prioridade do evento original do snort. Por 
exemplo, um risco com o valor 51818 diz que a 
máquina alvo está ativa e o serviço é oferecido 
com grau de vulnerabilidade 5. Além disso sabe-
se que a prioridade da regra original é 18. 
Os escores de todos os eventos de uma 
análise são somados criando um escore geral da 
análise. As análises são mostradas para o usuário 
pela ordem decrescente dos escores totais. As 
análises e os eventos são também identificados em 
uma escala de cores variando do verde ao 
vermelho, identificando visualmente a gravidade 
do ataque. 
3.5. Sistema de Produção – JEOPS 
O módulo de análise descrito na seção 
anterior foi implementado utilizando dois 
conjuntos de regras de produção: um para agrupar 
os eventos e outro para classificar esses eventos. 
Para isso foi utilizado o JEOPS (Java Embedded 
Object Production System) [17], um sistema 
desenvolvido no Centro de Informática da UFPE 
que estende a linguagem Java adicionado um 
mecanismo de embutir regras de produção com 
encadeamento progressivo em aplicações Java. 
Atualmente está sendo utilizada a versão 1.0 do 
JEOPS devido à possibilidade de utilização de 
regras em arquivos texto, possibilitando 
prototipação e testes rápidos. À medida que as 
regras forem se consolidando haverá uma 
migração natural para as versões mais recentes do 
JEOPS, que permitem a compilação das regras de 
produção além de permitir uma maior integração 
com os tipos de dados de Java. 
As regras do JEOPS são formadas por três 
blocos: declarações, premissas e ações. As 
declarações indicam quais objetos da base de 
conhecimento serão utilizadas naquela regra. As 
premissas são expressões em Java, normalmente 
envolvendo os elementos da base de 
conhecimento e que retornam valores booleanos. 
Se todas as premissas forem satisfeitas as ações 
das regras são executadas. Pode acontecer de mais 
de uma regra estar apta a ser disparada ao mesmo 
tempo. Nesses casos a política de resolução de 
conflitos especificada pelo programador é 
utilizada. 
No módulo de análise a base de regras de 
agrupamento dos eventos é simples, sendo 
formado por poucas regras de produção, algumas 
delas listadas abaixo. 
A primeira regra agrupa os eventos que 
contém a mesma origem e mesmo destino. Ao 
processar um evento o sistema verifica se existem 
análises ativas com a mesma origem e destino 
desse evento. Se existirem o evento é adicionado à 
essa análise: 
 
rule sameSourceAndTarget { 
declarations 
 analysis.snort.EventClassifier ec; 
 db.snort.Event ev; 
preconditions 
 ev != null; 
 ec.byPeers(ev.source(),ev.target()); 
actions 
 ec.addEventToAnalyzer(ev); 
 ec.setAnalyzerGroupedByPeer(ev); 
 modified(ec); 
 //-- tirar o evento da base 
 retract(ev); 
} 
A segunda regra trata do caso específico das 
varreduras (port scans), que nunca possuem o 
destino definido. Nesses casos o evento é 
adicionado a todas às análises que possuem 
eventos com a mesma origem da varredura: 
rule eventIsPortScan { 
declarations 
 analysis.snort.EventClassifier ec; 
 db.snort.Event ev; 
preconditions 
 ev != null; 
 ev.target().equals("Port Scan"); 
actions 
 ec.addPortScanToAnalyzers(ev); 
 modified(ec); 
 retract(ev); } 
A última regra é disparada quando o evento 
não foi agrupado em nenhum dos outros critérios. 
Nesse caso é criada uma nova análise e o evento 
adicionado a ela: 
rule default { 
declarations 
 analysis.snort.EventClassifier ec; 
 db.snort.Event ev; 
preconditions 
 ec != null; event != null; 
actions 
 ec.createAnalyzer(event); 
 retract(event); 
 modified(ec); 
} 
As estratégia de resolução de conflitos para 
essas regras foi a de prioridade, ou seja, ordem de 
definição da regra. Assim, a ordem em que as 
regras aparecem no arquivo define qual vai ser 
disparada em casos de conflitos. 
As regras de análise dos eventos que ajudam 
a definir seus riscos também são simples e 
procuram codificar o conhecimento de um 
especialista e reproduzir as ações para priorizar os 
eventos mais graves. Basicamente elas verificam 
se as condições para definir se uma máquina está 
ativa, se um serviço é oferecido e seu grau de 
108 
vulnerabilidade. Uma particularidade dessas 
regras é que existe um encadeamento, ou seja, as 
conclusões de uma regra são utilizadas nas 
premissas de outras tornando a análise mais 
complexa do que o agrupamento. A estratégia de 
resolução de conflitos adotada foi a “OneShot” 
que diz que uma regra só pode ser disparada uma 
única vez. 
A regra abaixo, por exemplo, faz uma 
consulta ao estado da rede para identificar se o 
alvo faz parte da rede protegida. Quando acionada 
ela atualiza o risco do evento: 
// Alvo faz parte da rede protegida 
rule isValidTarget { 
declarations 
 db.netinfo.NetInfo netState; 
 db.snort.Event ev; 
preconditions 
 ev != null; 
 netState != null; 
 netState.servExists(ev.getTarget()); 
actions 
 event.setValidTarget(true); 
 event.updateSeverity(); 
 modified(event); 
} 
 Já a regra abaixo verifica se o serviço é 
oferecido pelo servidor alvo do suposto ataque: 
// Verifica se o servico é oferecido 
rule isServiceOffered { 
declarations 
 db.netinfo.NetInfo ni; 
 db.snort.Event e; 
preconditions 
 e != null; 
 ni != null; 
 e.isTargetValid(); 
 e.hasPortInfo(); 
 ni.offered(e.target(),e.dport()); 
actions 
 event.setServiceOffered(true); 
 event.updateSeverity(); 
 modified(event); 
} 
 
 O próprio processo de verificação de 
precondições em regras pode automaticamente 
ativar coletores para complementar o estado ativo 
da rede. Isso acontece nos casos em que não 
existem dados
suficientes no estado para testar as 
precondições ou quando as informações estão 
desatualizadas. 
 Outras regras são utilizadas para classificar o 
grau de vulnerabilidade dos serviços alvos do 
ataque e são codificadas de forma a reproduzir o 
comportamento do especialista no processo de 
priorização. Por exemplo, a regra abaixo verifica 
se o serviço está na sua versão mais atual, 
aumentando o risco grau de vulnerabilidade em 
casos negativos: 
 
rule isServiceOutdated { 
declarations 
 db.netinfo.NetInfo ni; 
 db.snort.Event e; 
preconditions 
 e.isServiceOffered(); 
 ni.notLatest(e.target(),e.dport()); 
actions 
 event.updateVulnerability(2); 
 modified(event); 
} 
 Conforme mencionado anteriormente o grau 
de vulnerabilidade varia entre 0 e 9 e é 
modificado à medida que regras relacionadas à ele 
são ativadas no sistema de produção. 
 
4. RESULTADOS OBTIDOS 
4.1. Priorização de Eventos 
A utilização de regras de produção para 
análise e classificação de eventos do snort, 
permitiu um melhoramento da apresentação 
desses eventos para o administrador, reduzindo 
significativamente o esforço necessário para 
implantar e utilizar no dia-dia um sistema de 
detecção de intrusão de redes. 
A classificação, agrupamento e ordenação dos 
alertas permite ao gerente ter uma visão em tempo 
real dos ataques a sua rede, enfatizando eventos 
considerados mais perigosos e minimizando 
eventos pouco perigosos, que caso contrário 
apenas serviriam para dificultar a identificação de 
potenciais problemas. 
A figura 1 mostra a interface de visualização das 
análises e eventos. As colunas em destaque 
indicam a gravidade (risco) dos eventos e das 
análises (grupos de eventos). A cor e o risco da 
primeira análise indica que um evento perigoso 
foi detectado. 
4.2. Criação do Estado da Rede 
Para os testes realizados e descritos nesse 
documento o estado da rede monitorada foi 
incrementalmente construído de forma semi-
automatizada. Os coletores eram disparados 
através da interface gráfica, a base de dados 
atualizada e os resultados mostrados ao usuário, 
permitindo fazer pequenos ajustes para refinar 
esses resultados e corrigir eventuais falhas. A 
visualização desse estado representa por si só um 
subproduto importante do sistema, independente 
das análises por ele realizadas. 
109 
4.3. Geração de Relatórios 
Com base nos resultados das análises tem 
sido possível gerar relatórios com estatísticas de 
ataques, serviços vulneráveis, sugestões de cursos 
de ação entre outros. O operador também pode 
selecionar um ou mais grupos de eventos ou 
análises para gerar relatórios detalhados sobre os 
mesmos, que podem ser salvos em formato 
HTML facilitando a sua apresentação e 
incorporação em outros relatórios. 
 
 
 
Figura 1 – telas de resultados das análises ativas 
 
5. TRABALHOS FUTUROS 
5.1. Atualização Automática do Estado 
A evolução da representação do estado ativo 
da rede e dos agentes de análise tende a 
automatizar o processo de criação e atualização 
desse estado necessitando cada vez menos da 
intervenção manual do administrador do sistema. 
Idealmente espera-se incorporar esse processo à 
instalação do sistema. 
5.2. Incorporação de outros IDSs 
Testes preliminares realizados em paralelo a 
escrita desse documento apontam para a 
possibilidade de melhoria significativa da 
qualidade das análises através do 
correlacionamento dos eventos gerados pelo snort 
com outros eventos de detectores de intrusão de 
host como o AIDE ou que monitoram arquivos de 
log dos servidores e dos firewalls da rede. 
5.3. Realimentação dos Sensores 
Durante o processo de alimentação do estado 
ativo da rede podem ser detectados serviços 
conhecidos, mas em portas não convencionais. A 
princípio os sensores podem não possuir regras 
para essas portas não detectando potenciais 
ataques a esses serviços. Nesses casos os sensores 
podem facilmente ser reconfigurados 
adicionando-se regras para os serviços conhecidos 
nas portas encontradas. 
 
6. REFERÊNCIAS 
 
[1] Snort The Open Source Network Intrusion 
Detection System – http://www.snort.org 
[2] Helmer, Wong, Honavar, and Miller 
Intelligent Agents for Intrusion Detection; Iowa 
State University - 1998 
[3] Spafford, Gopalakrishna - A Framework for 
Distributed Intrusion Detection Using Interest 
Driven Cooperating Agents; Purdue University 
2001 
[4] Carver, Hill, Surdu, Pooch - A Methodology 
for Using Intelligent Agents to provide Automated 
Intrusion Response; proceedings of the 2000 IEEE 
[5] Lee and Stolfo Data Mining Approaches for 
Intrusion Detection; Proceedings of the 7th 
USENIX Security Symposium , 1998 
[6] Anderson, Frivold, Tamaru, Valdes – NIDES 
Next Generation Intrusion Detection Expert 
System; Computer Science Laboratory, SRI 1994 
[7] Porras and Neumann – EMERALD: Event 
Monitoring Enabling Responses to Anomalous 
Live Disturbances; 1997, Proc. 20th NIST-NCSC 
National Information System Security Converence 
[8] Lares, C. The Arpwatch Manual Page; 
Lawrence Berkeley Laboratory 1992 
[9] Fyodor - The Art of Port Scanning; Phrack 
Magazine Volume 7, Issue 51 September 01, 
1997, article 11 of 17
 
[10] Ritter - Enum, A tool to enumerate, using 
null and user sessions, Win32 (NT) information 
http://razor.bindview.com/tools/ 
[11] Jacob - Athena-2k, An auditing tool for 
Windows SNMP http://www.sps.lane.edu/~jshaw/ 
110 
[12] Shavlik & Microsoft – HFNetChk 
http://hfnetchk.shavlik.com/ 
[13] The netfilter/iptables project - the Linux 2.4.x 
firewalling subsystem; http://www.netfilter.org/ 
[14] Checkpoint Firewall-1 Data Sheet 
http://www.checkpoint.com/products/downloads/f
irewall-1_datasheet.pdf 
[15] Apache Torque http://db.apache.org/torque/ 
[16] Carnut, Mattos, Hora, Silva – FreeICP.ORG: 
2nd Anual PKI Research Workshop 2003 
[17] Figueira, Ramalho – JEOPS - The Java 
Embedded Object Production System, UFPE 2000