Estudo de Sistemas de Detecção e Prevenção de Intrusões ...read.pudn.com/downloads448/ebook/1886864/Estudo_de_Sistemas_… · Setembro de 2006 . Instituto Politécnico de Leiria

Instituto Politécnico de Leiria Escola Superior de Tecnologia e Gestão

Estudo de Sistemas de Detecção e Prevenção de Intrusões

Uma Abordagem Open Source

Marco Paulo Crespo Silva Miguel Nuno Saraiva Sampaio

Leiria Setembro de 2006

Instituto Politécnico de Leiria

Escola Superior de Tecnologia e Gestão



Relatório final da disciplina de “Projecto I”, do curso de Licenciatura em Engenharia Informática e Comunicações

Realizado entre Março e Setembro de 2006

Autores Marco Paulo Crespo Silva – 12239

Miguel Nuno Saraiva Sampaio – 10433

Orientadores Mário João Gonçalves Antunes

Miguel Monteiro de Sousa Frade

Leiria Setembro de 2006



i

Dedicatória Este trabalho é dedicado ao curso de Engenharia Informática e Comunicações, um

curso com um perfil tecnológico soberbo que infelizmente foi vítima de más decisões

administrativas. “No mercado de trabalho provaremos o nosso valor!”



ii

Agradecimentos Aos professores orientadores, Mário Antunes e Miguel Frade, por todo o tempo

disponibilizado e ajuda prestada.



iii

Resumo Este trabalho surgiu no âmbito da disciplina de “Projecto I” do curso de Engenharia

Informática e Comunicações. Uma vez que a segurança de informação se

encontrava nos assuntos preferidos dos autores, decidiu-se fazer uma autoproposta

para um projecto na área de segurança, abordando uma ferramenta open source.

Este relatório apresenta um estudo sobre os Sistemas de Detecção de Intrusão (IDS

– Intrusion Detection Systems) e incide sobre uma ferramenta open source

específica, o Snort.

Foi feito um enquadramento às tecnologias da segurança de informação e aos

conceitos associados. Os IDS foram dissecados como objecto de estudo, pois são um

elemento importante em qualquer rede informática bem protegida.

O Snort foi a ferramenta eleita pois é o IDS que tem a melhor classificação no top de

ferramentas de segurança de rede mais utilizadas mundialmente. Foi abordada a sua

arquitectura bem como as regras, peças fundamentais em todo o processamento de

pacotes, visto que, juntamente com o mecanismo de detecção, são os elementos

responsáveis pela análise do tráfego que viaja na rede. No entanto, tem melhor

desempenho quando combinado com uma ferramenta que interaja e efectue alterações

na firewall, através da leitura dos logs (p.e. Guardian).

Cada teste foi documentado de acordo com um padrão que define os resultados

esperados, resultados obtidos e conclusão específica acerca do teste. Desta forma foi

possível explorar o funcionamento e desempenho da aplicação em estudo.

O projecto deu origem a dois documentos: o relatório e um tutorial de instalação do

Snort escrito em Português, brevemente a submeter à comunidade Snort, para ser

incluído na secção que contém guias de instalação (www.snort.org/docs/).

http://www.snort.org/docs/



iv

Índice 1 Introdução .............................................................................................................1

2 Enquadramento.....................................................................................................2

2.1 Segurança da Informação ..................................................................................... 4

2.2 Políticas de Segurança ........................................................................................... 5

2.3 Modelo para a Segurança da Informação............................................................ 5

2.4 Tecnologias de Segurança da Informação ........................................................... 8

2.5 Problemas e Soluções para a Segurança da Informação .................................. 10

3 Sistemas de Detecção de Intrusão ......................................................................16

3.1 Entidades e Padrões ............................................................................................. 16

3.1.1 Common Intrusion Detection Framework ......................................................................16

3.1.2 Intrusion Detection Working Group ...............................................................................18

3.2 Conceitos Básicos ................................................................................................. 21

3.3 Função dos Sistemas de Detecção de Intrusão................................................... 22

3.4 Critérios de Avaliação da Qualidade dos Sistemas de Detecção de Intrusão . 23

3.5 Categorias dos Sistemas de Detecção de Intrusão............................................. 25

3.6 Técnicas ou Princípios de Detecção de Intrusão ............................................... 27

3.7 Considerações Finais sobre IDS.......................................................................... 33

4 Um Sistema de Detecção de Intrusão de Rede: o Snort ....................................34

4.1 História do Snort.................................................................................................. 34

4.2 Arquitectura Interna do Snort............................................................................ 35

4.2.1 Mecanismo de Captura e Descodificação de Pacotes .....................................................36

4.2.2 Plugins Pré-Processador .................................................................................................37

4.2.3 Mecanismo de Detecção .................................................................................................40

4.2.4 Plugins de Saída..............................................................................................................43

4.3 Regras.................................................................................................................... 44

4.3.1 Cabeçalho da Regra ........................................................................................................46



v

4.3.2 Opções da Regra.............................................................................................................50

4.3.3 Exemplo..........................................................................................................................68

4.3.4 Conclusão Final sobre as Regras ....................................................................................69

5 Testes ...................................................................................................................70

5.1 Cenário de Testes ................................................................................................. 70

5.2 Regra Simples....................................................................................................... 72

5.2.1 Transferência de Ficheiro de Texto ................................................................................72

5.2.2 Transferência de Ficheiro de Texto Comprimido ...........................................................74

5.3 Nmap ..................................................................................................................... 75

5.3.1 Nmap SYN Stealth Scan.................................................................................................76

5.3.2 Nmap SYN Stealth Scan com IP Spoofing.....................................................................78

5.3.3 Nmap FIN Stealth Scan ..................................................................................................81

5.4 Nessus .................................................................................................................... 84

5.4.1 Ataque DoS ao Serviço RPCSS do Windows.................................................................87

5.4.2 Ataque ao Serviço ntpd de Vários Sistemas Baseados em Unix.....................................89

5.4.3 Ataque ao Serviço SMB (Brute Force por Vários Users e Passwords)...........................89

5.5 Vulnerabilidade nos Ficheiros Windows Metafile ............................................ 91

5.6 Vulnerabilidade do Internet Explorer ............................................................... 96

5.7 Snort + Guardian ................................................................................................. 99

5.8 Conclusão Final sobre os Testes........................................................................ 101

6 Conclusões.........................................................................................................102

Anexo 1 Tutorial Instalação do Snort......................................................................107

Anexo 2 Regras Simples ...........................................................................................114

Anexo 3 Conteúdo do Ficheiro test.txt .....................................................................115



vi

Índice de Figuras Figura 1 – Estatística de ataques (www.mycert.org.my)_____________________________________2

Figura 2 – Abordagens anti-intrusão ___________________________________________________3

Figura 3 – Excerto da RFC 2196 (www.ietf.org/rfc/rfc2196.txt) ______________________________7

Figura 4 – Interacção dos componentes no modelo CIDF __________________________________17

Figura 5 – Componentes de um IDS segundo o IDWG _____________________________________19

Figura 6 – Classificação de IDS ______________________________________________________25

Figura 7 – Classificação de IDS segundo a fonte de informação _____________________________25

Figura 8 – Classificação de IDS segundo o sensor________________________________________27

Figura 9 – Classificação de IDS segundo a técnica de detecção _____________________________28

Figura 10 – Abordagens da detecção de intrusão por anomalias_____________________________28

Figura 11 – Abordagens da detecção de intrusão por regras________________________________30

Figura 12 – Outras abordagens para classificar os IDS ___________________________________32

Figura 13 – Abordagem segundo a dificuldade de implementação ___________________________33

Figura 14 – Arquitectura do Snort ____________________________________________________36

Figura 15 – Funções de descodificação de pacotes _______________________________________37

Figura 16 – Plugins de pré-processadores ______________________________________________38

Figura 17 – Ordem pela qual são verificados os tipos de regras _____________________________41

Figura 18 – Listas de regras consoante o protocolo_______________________________________42

Figura 19 – RTNs e respectivos OTNs _________________________________________________42

Figura 20 – Estrutura de uma regra ___________________________________________________45

Figura 21 – Estrutura do cabeçalho de uma regra________________________________________45

Figura 22 – Estrutura das opções de uma regra__________________________________________46

Figura 23 – Referências no BASE_____________________________________________________54

Figura 24 – Cenário de testes ________________________________________________________70

Figura 25 – BASE sem alertas _______________________________________________________72

Figura 26 – Transferência do ficheiro test.txt____________________________________________72

Figura 27 – Alertas gerados após transferência do ficheiro de texto __________________________73



vii

Figura 28 – Transferência do ficheiro test.rar ___________________________________________74

Figura 29 – Nmap SYN Stealth Scan___________________________________________________77

Figura 30 – Resultado do Nmap ______________________________________________________77

Figura 31 – Estatística dos alertas ____________________________________________________77

Figura 32 – Listagem dos alertas _____________________________________________________78

Figura 33 – Nmap SYN Stealth Scan com IP Spoofing _____________________________________79




Figura 37 – Nmap FIN Stealth Scan ___________________________________________________82




Figura 41 – Nessus Scan ____________________________________________________________85

Figura 42 – Vulnerabilidades encontradas pelo Nessus ____________________________________86

Figura 43 – Estatística dos alertas gerados pelo Snort ____________________________________86

Figura 44 – Alertas da classe attempted-admin após execução do Nessus______________________87

Figura 45 – Alertas após execução do Nessus ___________________________________________88

Figura 46 – Alertas após execução do Nessus ___________________________________________90

Figura 47 – Primeiro passo no framework ______________________________________________91

Figura 48 – Ligação efectuada na máquina Windows2003 _________________________________92

Figura 49 – Segundo passo no framework ______________________________________________92

Figura 50 – Segundo passo no framework ______________________________________________93

Figura 51 – Terceiro passo no framework ______________________________________________94

Figura 52 – Terceiro passo no framework ______________________________________________94

Figura 53 – Alertas após execução do ataque ___________________________________________95

Figura 54 – Cenário do teste à vulnerabilidade do Internet Explorer _________________________96

Figura 55 – Cenário do teste à vulnerabilidade do Internet Explorer _________________________97

Figura 56 – Acesso á máquina Backtrack_______________________________________________97



viii

Figura 57 – Informação do acesso da máquina Windows XP________________________________98

Figura 58 – Gestor de tarefas do Windows______________________________________________98

Figura 59 – Nessus Scan à Máquina Snort _____________________________________________100



ix

Índice de Tabelas Tabela 1 – Medidas de segurança da informação_________________________________________10

Tabela 2 – Alertas de alto risco, prioridade 1____________________________________________56

Tabela 3 – Alertas de médio risco, prioridade 2 __________________________________________57

Tabela 4 – Alertas de baixo risco, prioridade 3 __________________________________________57

Tabela 5 – Tipos de ICMPs e seus valores ______________________________________________61

Tabela 6 – Flags do cabeçalho TCP ___________________________________________________64

Tabela 7 – Opções da palavra-chave resp ______________________________________________66

Tabela 8 – Descrição do Hardware e Software das máquinas utilizadas nos testes_______________71

Tabela 9 – Teste 1 _________________________________________________________________73

Tabela 10 – Teste 2 ________________________________________________________________74

Tabela 11 – Teste 3 ________________________________________________________________78

Tabela 12 – Teste 4 ________________________________________________________________81

Tabela 13 – Teste 5 ________________________________________________________________84

Tabela 14 – Teste 6 ________________________________________________________________88

Tabela 15 – Teste 7 ________________________________________________________________89

Tabela 16 – Teste 8 ________________________________________________________________90

Tabela 17 – Teste 9 ________________________________________________________________95

Tabela 18 – Teste 10 _______________________________________________________________99

Tabela 19 – Teste 11 ______________________________________________________________100



1

1 Introdução A importância de interligar computadores tem crescido substancialmente a par do

objectivo de aumentar a produtividade, o lucro e o desenvolvimento das organizações.

Através de ferramentas e técnicas cada vez mais sofisticadas, estas organizações são

constantemente expostas a um conjunto de ataques à sua rede informática.

Há vários relatos diários em páginas da Internet que descrevem constantes ataques

realizados a organizações, mostrando assim a fragilidade dos seus sistemas de

informação. Existe um esforço diário para combater os ataques maliciosos aos

sistemas, conforme se constata nas páginas web da SecurityFocus

(www.securityfocus.com), SecuriTeam (www.securiteam.com), e CERT

(www.cert.org). Estas páginas são actualizadas diariamente com novas

vulnerabilidades de segurança, permitindo aos administradores de sistemas a

correcção dessas vulnerabilidades diminuindo o tempo de exposição aos atacantes.

Neste prisma, os Sistemas de Detecção de Intrusão são um mecanismo importante

para monitorizar e detectar, de forma contínua, as actividades e intenções dos

atacantes.

Este projecto aborda os Sistemas de Detecção de Intrusão estando englobado na

disciplina de “Projecto I” do 1º Ciclo da Licenciatura em Engenharia Informática e

Comunicações da Escola Superior de Tecnologia e Gestão de Leiria.

Este relatório está dividido em seis capítulos. Após esta breve introdução no Capítulo

1, no Capítulo 2 é feito um enquadramento geral à segurança da informação. No

Capítulo 3 são explicados os Sistemas de Detecção de Intrusão e todas as suas

vertentes, bem como as vantagens e desvantagens. No Capítulo 4 é abordado o

Sistema de Detecção de Intrusão open source Snort, o qual é testado no Capítulo 5.

No Capítulo 6 é feita a conclusão ao estudo da ferramenta Snort.

Em anexo é apresentado um tutorial de instalação do Snort e aplicações necessárias

para o seu funcionamento, bem como o Guardian, ferramenta que permite adicionar

reactividade perante os alertas gerados por este IDS.

http://www.securityfocus.com/

http://www.securiteam.com/

http://www.cert.org/



2

2 Enquadramento O crescente desenvolvimento tecnológico das últimas décadas ao nível das redes de

computadores é uma mais valia importante, uma vez que permite uma maior

eficiência produtiva e económica por parte das organizações.

No entanto, a vulgarização das Tecnologias da Informação e Comunicação (TIC)

levou ao aumento dos problemas na segurança informática, pois a informação é agora,

na sua maior parte informatizada.

A segurança é um problema actual. Devido ao crescente número de ciberataques é

fundamental a utilização de bons sistemas de defesa. As intrusões são um dos

principais ataques actualmente a serem utilizados (Figura 1). É extremamente

importante o desenvolvimento de ferramentas que detectem e mesmo previnam que

estes intrusos possam danificar ou alterar o funcionamento normal dos sistemas

informáticos.

Figura 1 – Estatística de ataques (www.mycert.org.my)

Os Sistemas de Detecção de Intrusão são uma parte importante de todo o sistema de

defesa. Este é geralmente constituído por seis abordagens anti-intrusão: preempção,

prevenção, dissuasão, detecção, deflexão e reacção. A Figura 2

http://www.mycert.org.my/



3

(www.dei.estg.ipleiria.pt/cs/files/19-IDS.pdf) ilustra a ordem destas abordagens,

explicadas de seguida:

Figura 2 – Abordagens anti-intrusão

• Preempção – medidas levadas a cabo antes de uma tentativa de intrusão para

diminuir a probabilidade da sua ocorrência. Por exemplo: a educação dos

utilizadores e a promoção da política de segurança.

• Prevenção – a prevenção da intrusão a nível interno e externo procura evitar,

ou pelo menos limitar severamente, o sucesso de uma intrusão. Por exemplo as

firewalls.

• Dissuasão – aumentar a percepção do risco de ser apanhado através de

mensagens de aviso e aumentar os obstáculos para aumentar o tempo e esforço

despendido pelo atacante, para que este desista de realizar o ataque.

• Detecção – técnicas que procuram diferenciar tentativas de intrusão do uso

normal dos sistemas, analisando e processando a informação registada para se

encontrar assinaturas de ataques conhecidos, comportamentos anormais ou

resultados de interesse.

• Deflexão – atrair os possíveis intrusos para um sistema desenvolvido para

controlar e observar as actividades dos intrusos, fazendo-os crer que o

conseguiram contornar. Por exemplo os honeypots.

• Reacção – dotar os sistemas com capacidades de decisão para reagirem a uma

intrusão, libertando-os da constante dependência de um administrador. Permite

reacção em tempo real.

http://www.dei.estg.ipleiria.pt/cs/files/19-IDS.pdf



4

Assim, é necessário assegurar diversos componentes cruciais para que a informação

se mantenha segura e garantir desta forma a sobrevivência das organizações, como

sejam: requisitos de segurança, políticas de segurança e mecanismos de

segurança.

Os requisitos de segurança respondem á questão trivial “O que é que se pode esperar

que a segurança faça por nós?”. As políticas de segurança definem os passos e

medidas necessárias para atingirem determinados objectivos. Por fim, os mecanismos

de segurança estabelecem os instrumentos, tecnologias e procedimentos a serem

usados para assegurar a efectivação dos dois componentes descritos anteriormente.

Nas secções seguintes serão abordados vários aspectos que permitem assimilar os

conceitos de base relacionados com a segurança da informação, assim como as

politicas, tecnologias e modelos da mesma. Serão também dados alguns exemplos de

problemas e soluções dentro deste tema.

2.1 Segurança da Informação

A segurança da informação assenta em três pilares essenciais: confidencialidade,

integridade e disponibilidade.

• Confidencialidade – pressupõe que a informação só poderá ser acedida ou

revelada a utilizadores devidamente autorizados;

• Integridade – capacidade de garantir a detecção da alteração da informação

transportada ou armazenada;

• Disponibilidade – pressupõe a acessibilidade ou disponibilização imediata de

serviços ou recursos do sistema, sempre que tal seja solicitado pelos legítimos

utilizadores, mesmo na sequência de ataques.

A autenticidade e o não repúdio são dois princípios adicionais, importantes na

segurança da informação. O primeiro permite assegurar a identidade do utilizador tal

como ele a reclama e assim dar-lhe acesso à informação. Este princípio só é garantido

com a confidencialidade e integridade e só assim, já com a autenticação correcta, é

que é possível determinar se o acesso à informação foi devidamente consentido. Por

sua vez, o não repúdio assegura que o utilizador não pode, posteriormente, negar a

autoria de determinada transacção ou evento, assim como garantir a identidade do



5

respectivo utilizador. Este princípio é de extrema importância, e deve ser

efectivamente assegurado, pois, por exemplo, em transacções financeiras electrónicas,

é necessário assegurar a origem, o transporte e a entrega de uma transacção.

2.2 Políticas de Segurança

Uma política de segurança é um conjunto de regras, normas e práticas, de extrema

importância e respeitado por todos os intervenientes da organização. Tem em vista a

segurança da informação da organização, contra potenciais violações dos princípios

referidos anteriormente.

A política de segurança vem então definir o que é permitido e proibido num sistema

através de uma das seguintes abordagens: proibitiva, em que tudo o que não é

permitido é expressamente proibido ou permissiva, em que tudo o que não é proibido

é expressamente permitido.

As organizações que manifestam grande preocupação com as questões relacionadas

com a segurança da informação apostam em políticas que respeitam uma abordagem

proibitiva. Por exemplo, não permitir aos funcionários ter acesso às aplicações fora do

âmbito da função que desempenham (p.e. não terem acesso ao browser comum entre

outras aplicações).

As políticas de segurança e respectivas abordagens estão definidas pela organização

num documento também ele denominado de “Política de Segurança”. É um

documento que todos os intervenientes (empregados, direcção e administradores) têm

de respeitar no desenvolvimento do seu trabalho, como por exemplo a mudança de

password, ou até a não utilização do browser. Este documento deve sofrer

actualizações correctivas periódicas, a fim de o tornar adaptativo às necessidades da

organização e à sua esperada evolução ao longo do tempo.

2.3 Modelo para a Segurança da Informação

Um modelo para a segurança da informação assenta nos seguintes conceitos:

vulnerabilidade, ameaça, ataque, risco e impacto.



6

Uma vulnerabilidade é uma falha da implementação e operação do hardware ou

software, ou seja, uma potencial via para tentativas de utilização não autorizadas no

sistema ou mesmo exposição involuntária de informação.

Uma ameaça é definida pela intenção de se infligir danos num determinado sistema

informático, com a realização de ataques. As ameaças podem ser externas ou

internas, sendo as últimas as que têm maior percentagem de sucesso pois um

utilizador legitimo, que já “conhece os cantos à casa”, tem maior probabilidade e

facilidade de causar danos relevantes no sistema. Uma ameaça pode assim ficar

definida como a possibilidade da ocorrência de um acesso não autorizado e deliberado

ao sistema com intenção de manipular informação, podendo assim torná-lo

inconsistente ou mesmo inutilizável.

O risco consiste na possibilidade do sistema ser incapaz de assegurar o cumprimento

da sua política de segurança quando sujeito a um ataque. Desta forma, o grau de risco

de um sistema fica definido pela exposição das suas vulnerabilidades de segurança e

pelo teor da ameaça manifestada num determinado intervalo de tempo.

São duas as filosofias que as organizações podem ter perante o risco:

• Anulação do risco – pressupõe a remoção de qualquer vulnerabilidade do

sistema e a destruição de qualquer tentativa de ataque (ou ameaça). Por

exemplo com updates ao sistema para corrigir vulnerabilidades e com

firewalls e IDS de forma a evitar e detectar as tentativas de ataque.

• Gestão do risco – pressupõe a aceitação de um determinado grau de risco, o

qual pode ser visto como um padrão normal. Neste prisma a relevância é

depositada num conjunto de meios para lidar com ataques bem sucedidos.

Neste caso certos riscos são aceitáveis. Por exemplo, o servidor é alcançável

por “ping” (ICMP), mas no entanto os serviços principais estão protegidos e

escondidos. Sendo o risco nulo algo perto da utopia, é frequente as

organizações optarem por esta filosofia.

Os custos e prejuízos resultantes de um ataque ao sistema são quantificados pelo

impacto. Por exemplo, o downtime de um servidor web de uma organização de

comércio electrónico e todos os custos e prejuízos que resultam do ataque que o

causa. Convém referir a necessidade da existência de um compromisso entre despesas



7

e impacto, para que não se entre em gastos desnecessários para um impacto que não

os justifique, ou seja, os gastos não poderão ser superiores ao valor da informação a

proteger (Figura 3).

Figura 3 – Excerto da RFC 2196 (www.ietf.org/rfc/rfc2196.txt)

Assim, um modelo para a segurança da informação deverá assentar nas seguintes

acções:

1. Estudar em pormenor as ameaças e vulnerabilidades.

2. Avaliar o impacto e custos de eventuais ataques.

3. Prever o maior número possível de ataques.

4. Definir e implementar medidas adequadas de dissuasão, detecção, prevenção e

correcção que permitam uma acção sobre as ameaças e vulnerabilidades.

São adoptadas diversas medidas ou soluções, aconselhadas pelo modelo, de forma a

minimizar as ameaças e ataques (redução do impacto implícita):

• Medidas dissuasivas – Reduzir a probabilidade de ocorrência de ataques. Por

exemplo, pela realização de acções de consciencialização no sentido de alertar

os utilizadores que têm acesso ao sistema, que existem riscos. Alertar que

estes podem estar associados a simples acções inofensivas, como por exemplo,

a navegação por páginas de Internet desconhecidas, que podem abrir “portas”

a ataques futuros.

• Medidas de detecção – Descobrir a realização de ataques e tentar evitar a sua

concretização (p.e. IDS).

Estas medidas permitem desencadear outras de tipos diferentes:

• Medidas de prevenção – Proteger as vulnerabilidades detectadas precavendo

falhas ou pontos fracos que o sistema apresenta. (p.e. Criptografia)

http://www.ietf.org/rfc/rfc2196.txt



8

• Medidas de correcção – Reduzir o impacto de um ataque corrigindo o risco

associado ao sistema.

As medidas referidas anteriormente fazem parte da política de segurança a ser

adoptada.

Existem assim, ao nível de soluções, dois grandes campos de actuação do modelo para

a segurança da informação:

• Foro sociológico e psicológico – Medidas dissuasivas e de correcção em que

são aplicadas medidas de consciencialização humana aos utilizadores do

sistema bem como aos administradores.

• Foro tecnológico ou da engenharia – Medidas de detecção e de prevenção

em que, as medidas aplicadas são baseadas em tecnologia, p.e. IDS, firewall,

criptografia, esteganografia, antivírus.

2.4 Tecnologias de Segurança da Informação

A implementação de tecnologias específicas é uma acção necessária para garantir a

segurança da informação, requerendo a implementação de:

• Medidas proactivas – dizem respeito às acções realizadas através de um

conjunto de tecnologias, de forma a assegurar a segurança dos dados ou

recursos de um sistema mesmo que ocorra ou esteja em execução uma

violação ou quebra de segurança. Estas medidas permitem salvaguardar a

informação antes que uma ameaça potencial possa ser materializada num

ataque. Por exemplo: (1) salvaguarda dos dados antes de serem transmitidos

por uma rede pública de comunicação; (2) garantir um grau de confiança antes

de uma comunicação ser efectuada pela rede; (3) identificar vulnerabilidades

do sistema antes destas serem aproveitadas por intrusos, ou por aplicações mal

intencionadas; (4) proteger o sistema contra acções de potenciais vírus

informáticos; (5) proteger informação crítica antes que esta seja interceptada

por intrusos e (6) impedir que intrusos possam modificar ou alterar

configurações de equipamentos.

• Medidas reactivas – englobam as acções de remedeio realizadas por uma

determinada tecnologia, ou conjunto, de forma a assegurar a segurança dos



9

dados ou recursos de um sistema após a ocorrência de uma violação ou quebra

de segurança. Estas medidas permitem actuar sobre incidentes específicos de

segurança mal estes tenham ocorrido, decidir acerca da permissão ou negação

dos pedidos de acesso ao sistema (à rede, às aplicações ou aos terminais),

monitorizar os terminais numa rede para que se possa actuar assim que uma

intrusão tenha ocorrido, recolher informação ou investigar incidentes de

segurança que tenham ocorrido ou permitir o acesso a serviços remotos.

Estes dois tipos de tecnologias de segurança de informação podem ser aplicadas a

vários níveis:

• Aplicação.

• Rede.

• Terminal.

Ao nível da aplicação tentam-se proteger os dados ou os recursos partilhados pelos

programas. Ao nível de rede assegura-se a protecção dos dados ou recursos que estão

a ser transmitidos por um sistema de computadores interligados. Ao nível do terminal

tentam-se proteger os dados ou os recursos que estão integrados num computador.

As assinaturas digitais, os certificados digitais, a criptografia, as redes privadas

virtuais (redes VPN – Virtual Private Network – aplicação concreta de criptografia),

os antivírus, os protocolos de segurança (Internet Protocol Security e Kerberos), o

hardware de segurança (módulos de encriptação e routers) e os kits de

desenvolvimento de software de segurança (Java Security Manager e Microsoft .NET)

são considerados tecnologias de segurança de informação proactivas.

As tecnologias de segurança de informação reactivas englobam as firewalls (quando

associadas a IDS), o controlo de acessos, as palavras passe, a biometria, os sistemas

de detecção de intrusão (Intrusion Detection Systems - IDS), o logging e o acesso

remoto.



10

Estes exemplos apresentam-se organizados na Tabela 1:

Níveis

Medidas Aplicação Rede Terminal

Proactivas

Criptografia

• Assinaturas Digitais

• Certificados Digitais

Kits de desenvolvimento de software seguro (Java Security

Manager, Microsoft .NET)

VPN

Hardware Segurança

(Routers)

Antivírus

Firewalls

Reactivas

Palavras Passe

Logging

IDS Palavras Passe

Biometria

Logging

Acesso Remoto

HIDS

Tabela 1 – Medidas de segurança da informação

2.5 Problemas e Soluções para a Segurança da Informação

Para enumerar algumas soluções na segurança da informação apresentam-se de

seguida alguns dos problemas mais conhecidos:

• Vírus – Qualquer tipo de código malicioso que apague os dados ou interfira

com o funcionamento normal dos computadores. Actualmente os vírus são

produzidos com objectivos diversos e utilizam técnicas bastante sofisticadas.

Portanto, os administradores devem estar atentos á criação diária de novos

vírus de forma a actualizarem os programas antivírus com actualizações que

vão sendo disponibilizadas pelos fabricantes.

• Sniffers – Programas que procuram capturar informações destinadas a uma

outra máquina (sniffing). Um computador diz-se em modo promíscuo quando

captura todos os pacotes, independentemente de serem ou não destinados a ele.

Geralmente os crackers (atacantes especializados e mal intencionados) quando

executam/desenvolvem um ataque, não anunciam a sua presença nem

divulgam os ataques bem sucedidos. Instalam dispositivos de monitorização

que reúnem informação sobre a rede utilizando-a para construir os seus



11

ataques. Os sniffers também são muito utilizados por administradores de rede

para gerir e analisar o tráfego de pacotes.

• Backdoor – Este conceito, também ele denominado como “porta dos fundos”,

encontra-se definido na “RFC 2828” como sendo um mecanismo que dá

acesso a um sistema e aos seus recursos através de um procedimento diferente

do habitual. Normalmente é utilizado na fase de teste após o desenvolvimento

de software ou hardware, não sendo de conhecimento público. Não possui

necessariamente uma intenção maliciosa.

No entanto existem autores que discordam um pouco desta definição,

afirmando que um backdoor é, no fundo, uma falha na segurança de um

sistema deixada deliberadamente pelo fabricante.

Uma vez conhecida essa falha deixada pelo fabricante, o hacker (atacante

especializado) ou o cracker (hacker mal intencionado) pode fazer uso dela

para ter acesso a outros computadores sem ser bloqueado pelos mecanismos de

segurança. Neste caso o backdoor é denominado trapdoor.

Geralmente os atacantes tem uma listagem de backdoors deixados pelos

fabricantes, que irão utilizar contra os potenciais alvos.

• DoS – O DoS (Denial Of Service) é uma ameaça em que um invasor, após ter

acedido e dominado um computador alheio, consegue gerar e enviar uma

grande quantidade de dados, seja para uma rede, terminal ou servidor, com a

finalidade de sobrecarregar a vitima, deixando as actividades da mesma

indisponíveis (negação do serviço) ou muito lentas. Este tipo de ataque não

tem a intenção de corromper ou modificar dados do computador, apenas de

deixar o serviço indisponível. É praticamente impossível prevenir este tipo de

ameaça, tornando-a assim extremamente perigosa para a organização que tem

o serviço parado, pois pode corresponder a uma perda de dinheiro e

credibilidade.

• Scanners – Ferramentas que têm o intuito de descobrir terminais numa rede

bem como informações sobre os mesmos. Estas podem ser vulnerabilidades,

problemas ou erros de configuração de servidores, portos abertos e senhas

fracas. Hoje em dia, os scanners são desenvolvidos para diversas plataformas



12

e são mais flexíveis, pois à medida que são descobertos novos problemas, os

fabricantes e developers incorporam testes novos nas suas ferramentas,

preparando-as para testar as vulnerabilidades.

Um exemplo deste tipo de ferramenta é aplicação denominada Nessus, que foi

utilizada para a realização do presente estudo e que será referida no capítulo

dos testes (Capítulo 5).

• Spoofing – Existem vários tipos e níveis de técnicas de spoofing. O conceito

consiste em mascarar os pacotes IP com endereços de origem falsos. Para

reduzir a possibilidade de um ataque de spoofing deve-se fazer uma

autenticação criptografada e gestão de sessão. Existem basicamente três tipos

de spoofing: o de IP, o de DNS e o de ARP.

• Social Engineering – A engenharia social é um método utilizado por pessoas

maliciosas que se aproveitam da fragilidade e da inocência dos utilizadores de

recursos informáticos, com o intuito de obter informações necessárias para

realizarem um ataque. Estas informações importantes podem ser obtidas

através de telefonemas, correio electrónico, chat rooms, phising bancário e até

pessoalmente. Umas das soluções para evitar este tipo de ameaça é oferecer

aos funcionários da organização algumas palestras e treinos sobre o assunto,

onde serão apresentadas várias dicas que podem ajudar a minimizar este

problemas e melhorar a segurança da organização.

Existem assim diversas soluções para combater as ameaças à segurança da

informação, entre as quais:

• Criptografia – é geralmente entendida como sendo o estudo dos princípios e

das técnicas pelas quais a informação pode ser transformada da sua forma

original para outra ilegível (cifragem), a menos que seja conhecida uma

"chave secreta", o que torna difícil a leitura da mensagem por alguém não

autorizado. Assim sendo, só o destinatário pode ler a informação, visto só este

possuir a chave.

Os algoritmos de cifragem geralmente são públicos, logo a segurança é obtida

através das chaves que são utilizadas.



13

o Algoritmos de cifragem simétricos ou de chave única – É utilizada a

mesma chave para cifrar e decifrar, emissor e receptor concordam

previamente sobre que chave utilizar, tendo essa chave que ser trocada

entre ambos através de um canal seguro.

o Algoritmos assimétricos – Cada extremo da comunicação tem duas

chaves, uma pública de conhecimento geral e uma chave privada

mantida em segredo pelo dono. Tudo o que seja cifrado com a chave

pública de um determinado extremo apenas será decifrado por quem

detiver a chave privada do dono da chave pública.

• Esteganografia – é o estudo e uso de técnicas para ocultar a existência de uma

mensagem dentro de outra, sendo um conceito diferente de criptografia. Na

estenografia pretende-se ocultar a existência da mensagem, enquanto que na

criptografia pretende-se ocultar o significado da mensagem. Muitas vezes as

duas são utilizadas em conjunto.

A forma mais comum da utilização desta técnica é a alteração do bit menos

significativo de cada pixel de uma imagem, transformando-o num bit da

mensagem que se pretende ocultar, este método apenas alterará ligeiramente a

qualidade da imagem. Esta técnica também pode ser utilizada em outros meios

digitais como por exemplo áudio e vídeo.

• Segurança Física – relaciona-se directamente com os aspectos associados ao

acesso físico a recursos e informações, sejam esses recursos informação,

meios de suporte e armazenamento ou mecanismos de acesso às informações.

Nem todas as organizações foram pensadas de raiz para possuírem uma rede

de dados estruturada, o que leva a que as salas de distribuição de piso, edifício

ou de campus nem sempre estejam bem localizadas. Estas podem estar

situadas em locais de fácil acesso, em que, por exemplo, um qualquer

indivíduo que visite a organização lhes possa aceder facilmente, adquirindo

acesso por exemplo, à consola de um router ou servidor.

• Cópias de Segurança (Backups) – devem ser feitas cópias de segurança

regularmente para que a informação esteja salvaguardada de qualquer tipo de

ameaças, sejam elas naturais ou provocadas por ataques. Existem dois tipos de



14

cópias de segurança: incrementais e completos. As cópias de segurança

incrementais são aquelas em que apenas se guarda os dados que sofreram

actualizações desde a última cópia de segurança completa, nas cópias de

segurança completas é feita a cópia de todos os dados armazenados no disco

rígido.

Antes de se efectuar a cópia de segurança deve ser escolhido o tipo de

dispositivo onde será guardada a informação e o local onde esse dispositivo

será guardado. As empresas que trabalham com grandes quantidades de dados,

recorrem a backups offsite, ou seja, diariamente ou semanalmente é feita uma

cópia dos dados num local longe da origem para que em caso de catástrofe

estes fiquem a salvo, existem empresas especializadas em offsitebackups pelo

mundo inteiro. Estas mesmas empresas replicam todos os dados pelos quais

são responsáveis em vários locais do mundo.

• Antivírus – são programas com a capacidade de detectarem e eliminarem

vírus. Os antivírus possuem uma base de dados contendo as assinaturas dos

vírus que são conhecidos até ao momento e que podem ser detectados e

removidos. Desta forma, somente após a actualização da base de dados, os

vírus recém-descobertos podem ser detectados e removidos. Actualmente os

antivírus são programas que estão constantemente a monitorar o sistema e

verificam em tempo real se existem vírus em ficheiros que estão a ser

descarregados da Internet, do servidor de e-mail ou copiados da rede local.

• Logs – registo de eventos à medida que vão ocorrendo, efectuado pelo sistema

operativo ou pelas aplicações. Os logs têm extrema importância, por exemplo,

quando se pretende descobrir que pessoa esteve presente numa máquina em

determinado dia e hora bem como as tentativas de login erradas. São úteis

ainda para que o administrador da rede possa detectar possíveis causas de

falhas do sistema.

Geralmente os logs são armazenados no disco do próprio sistema onde foram

gerados. Tal procedimento não é aconselhado uma vez que uma das tarefas de

um atacante é apagar os logs referentes à sua passagem pelo sistema. Uma

técnica utilizada é a criação de um loghost, máquina onde são guardados todos

os logs de uma forma segura e ao mesmo tempo centralizada.



15

• Firewalls – é o nome dado ao dispositivo de rede ou software que tem por

função regular o tráfego entre redes distintas e impedir a transmissão de dados

nocivos ou não autorizados de uma rede para outra. Dentro deste conceito

incluem-se, geralmente, os filtros de pacotes e proxy de protocolos.

Existe na forma de software e hardware, ou na combinação de ambos. A

instalação depende do tamanho da rede, da complexidade das regras que

autorizam o fluxo de entrada e saída de informações e do grau de segurança

desejado.

• IDS – processo de monitorização de eventos que ocorrem em computadores e

em recursos de rede, para que estes possam ser analisados de forma a

encontrar quaisquer sinais evidentes de intrusão. Este conceito será abordado

em pormenor no Capítulo 3

• VPN – assentam no estabelecimento de uma ligação segura entre dois pontos

através de uma rede insegura, por exemplo a Internet. Ou seja, é criado um

túnel entre esses dois pontos onde a informação circula cifrada e autenticada.

Esta é uma aplicação concreta da criptografia.

A evolução das redes de computadores permitiu a convergência de vários sistemas de

comunicação à escala global, como: voz, dados e imagem. Tal facto permitiu ás

organizações a troca de informação e a partilha de recursos de uma forma rápida e

segura.

Contudo esta evolução não trouxe apenas benefícios, todo este avanço tecnológico,

por vezes desmesurado, trouxe a crescente preocupação com a segurança que deve ser

implementada a diversos níveis da rede.

Tópicos como por exemplo, politicas de privacidade de utilizadores, autenticação

biométrica, comparação de custos para implementação de modelos e mecanismos de

segurança entre sistemas operativos Windows e UNIX, buffer overflows, Cross Site

Scripting, SQL Injection, forensic computing, fuzzers, entre outros, seriam tópicos

interessantes de análise.



16

3 Sistemas de Detecção de Intrusão As organizações preocupam-se cada vez mais com a protecção relativa a ataques aos

seus sistemas informáticos, que colocam em causa a segurança da informação. Os

Sistemas de Detecção de Intrusão são indispensáveis, tendo em conta o aumento de

actividades danosas. Tal prende-se com o facto de serem das principais tecnologias

disponíveis para garantir uma segurança automatizada dos sistemas.

3.1 Entidades e Padrões

Independentemente da arquitectura ou do método utilizado para a detecção, todos os

IDS possuem componentes em comum. Cada um desses componentes, muitas vezes

agrupados, desempenha um papel importante na tarefa de identificar acções

consideradas prejudiciais ao sistema. Assim, deve-se conhecer a anatomia de um IDS,

seja com o intuito de desenvolver novas técnicas e modelos, ou pela necessidade de

avaliar as diferentes soluções disponíveis.

Tem vindo a ser feito um grande esforço para padronizar a nomenclatura e a função

de cada um dos componentes que compõe um IDS, principalmente para facilitar a

interacção entre diferentes ferramentas deste tipo.

3.1.1 Common Intrusion Detection Framework

O CIDF (Common Intrusion Detection Framework – http://gost.isi.edu/cidf/)

constituiu uma primeira tentativa de padronizar o funcionamento dos IDS, no final da

década de 90, como uma iniciativa de Teresa Lunt funcionária da DARPA (Defense

Advanced Research Projects Agency). A necessidade de padronização surgiu pelo

aparecimento de ataques cada vez mais sofisticados, capazes de serem distribuídos

através de redes metropolitanas durante longos períodos, exigindo assim a utilização

de IDS distribuídos. Neste tipo de ambiente distribuído a capacidade dos IDS e dos

seus componentes poderem partilhar informações "avançadas" tornou-se algo

extremamente importante.

Entre os objectivos do CIDF Work Group estavam o desenvolvimento de protocolos

e interfaces de programação, de forma a que projectos de pesquisa em IDS pudessem

partilhar informações e recursos. O Work Group objectivava ainda que diferentes

http://gost.isi.edu/cidf/



17

componentes de um IDS compartilhassem informações da forma mais detalhada e

completa possível e que um sistema pudesse ser reutilizado em contextos diferentes

daquele para o qual tinha sido originalmente configurado.

O esforço principal do CIDF Work Group foi definir uma "linguagem" da camada

de aplicação para descrever as informações de interesse do sistema, a qual foi

chamada de CISL (Common Intrusion Specification Language) e um protocolo para

codificar esta informação e partilhá-la entre componentes.

Figura 4 – Interacção dos componentes no modelo CIDF

O CIDF definiu assim uma arquitectura que divide os IDS em componentes e um

modelo de camadas que apresenta a comunicação entre estes componentes. Esta

arquitectura define os IDS como contendo quatro componentes que comunicam

através da passagem de mensagens, denominadas GIDOs (Generalized Intrusion

Detection Objects), que são representadas através de um formato comum definido

pela linguagem CISL.

Como disposto na Figura 4, os quatros componentes que compõem o modelo CIDF

são: E-Box (gerador de eventos), A-Box (analisador de eventos), D-Box (base de

dados de eventos) e C-Box (contra medidas).

A E-Box gera os eventos e é responsável pela obtenção dos dados e pela posterior

padronização do formato desses dados. Em ambientes Unix pode-se capturar pacotes

da rede através da biblioteca de programação libpcap, em ambiente Windows é a

biblioteca winpcap que realiza esta função. Os eventos devem ser gerados assim que

ocorrem, em tempo real, e o armazenamento de eventos deve ficar sob a



18

responsabilidade das Base de Dados de Eventos – Componente D-Box. A E-Box não

processa os dados gerados, ficando a cargo do componente especializado na função de

processamento (A-Box), que por sua vez, após analisar os eventos (violação de

políticas, anomalias, intrusão), envia os resultados para outros componentes.

A A-Box analisa os eventos e constitui o componente mais importante dos IDS, pois

realiza a detecção de intrusões, identificando o que é e o que não é uma intrusão. Este

componente recebe as informações de outros componentes, analisa-as e envia-as de

forma resumida para outros componentes.

A D-Box é uma base de dados e representa o elemento responsável pelo

armazenamento dos eventos obtidos na E-Box para futura análise, ou mesmo da A-

Box (dados já analisados). A importância da D-Box é fundamental pois os dados

armazenados são cruciais para o desempenho dos vários componentes dos IDS.

O último componente é o C-Box. Basicamente este componente é formado por

unidades de resposta que são responsáveis pelas contra medidas para os eventos.

Podem ser desde simples alarmes a avisar os responsáveis pela rede, tal como podem

tomar decisões tipo encerramento de processos ou desligar de um servidor. Em geral,

este componente comunica com outros dispositivos da rede como por exemplo

firewalls.

O fluxo destes componentes basicamente segue da seguinte forma: os pacotes (TCP,

UDP ou ICMP) são capturados pelo gerador de eventos (vulgo sensor), que os entrega

ao analisador. Este consulta a base de dados de eventos e quando detecta um tipo de

ataque, armazena a detecção noutra base de dados e a partir daí já pode lançar uma

unidade de contra medidas.

O esforço desenvolvido em volta do framework CIDF incentivou a criação de um

working group do IETF (Internet Engineering Task Force), denominado IDWG

(Intrusion Detection Working Group).

3.1.2 Intrusion Detection Working Group

O IDWG (http://www.ietf.org/html.charters/OLD/idwg-charter.html) é um grupo de

trabalho do IETF cujo objectivo foi definir formatos de dados e procedimentos de

troca para a partilha de informações de interesse entre IDS. O trabalho do IDWG

resultou na especificação de um formato para troca de mensagens (IDMEF - Intrusion

http://www.ietf.org/html.charters/OLD/idwg-charter.html



19

Detection Message Exchange Protocol) e de um protocolo de comunicação para o

transporte de mensagens IDMEF (IDXP - Intrusion Detection Exchange Protocol).

Entre as razões do IDWG para a especificação do IDMEF e do IDXP estiveram: o

grande número de IDS gratuitos e comerciais com características distintas de

funcionamento, gerar eventos relativos a intrusões num formato comum entre os IDS,

facilitando o uso destes, além da possibilidade de integração de diferentes

componentes de IDS distintos.

O IDWG determinou uma arquitectura para IDS mais detalhada que o CIDF. Os

componentes especificados não são necessariamente implementados por todos os IDS,

podendo ser incluídos num único módulo ou distribuídos em vários módulos.

Figura 5 – Componentes de um IDS segundo o IDWG

As fontes de dados representam os dados que vão ser alvo de auditorias, por exemplo,

o tráfego de um segmento de rede. Os sensores são destinados a reunir eventos

suspeitos da fonte de dados e passá-los ao analisador, tal como demonstra a Figura 5.

As actividades especificadas na interligação da fonte de dados com o sensor,

correspondem a eventos que ocorrem na fonte e que são de interesse do operador,

como por exemplo, uma sessão telnet em horário inesperado, ou utilizadores a

acederem a serviços não autorizados.



20

Os analisadores recebem eventos capturados e passados pelos sensores que podem

gerar alertas e processá-los. Esses eventos suspeitos que foram capturados são

classificados de acordo com a política de segurança do administrador da rede. Em

muitos sistemas tanto os sensores como os analisadores fazem parte do mesmo

componente.

Quando um desses eventos suspeitos é capturado e está relacionado com alguma regra

definida na política de segurança, será gerado um alerta, que por sua vez será enviado

ao gestor. Este componente é manipulado por um operador ou pelo administrador da

rede e é o responsável por configurar os demais componentes do IDS, além de gerir a

notificação dos alertas e emitir relatórios estatísticos. O gestor quando recebe um

alerta, emite uma notificação ao operador, através de e-mail, alerta sonoro ou outra

forma de notificação e este último tomará providências, sejam elas automáticas ou

não, como resposta ao alerta notificado.

O IDMEF tem a finalidade de ser um formato de dados padrão que os IDS podem

usar para reportar alertas sobre eventos suspeitos. O desenvolvimento deste formato

padrão possibilitará a configuração de sistemas que utilizem componentes comerciais,

open source e de pesquisa, de acordo com os seus pontos fortes e fracos, permitindo

assim uma implementação optimizada.

O ponto mais óbvio para implementar o IDMEF é o canal de dados entre o

analisador ou o sensor, e o gestor que recebe os alertas, ou os alarmes. Mas existem

outros pontos onde o IDMEF pode ser útil, tal como sistemas de base de dados que

armazenam resultados de vários IDS, sistemas de correlação de eventos que podem

aceitar alertas de vários produtos e também, a troca de informações relativas a

incidentes de segurança entre organizações. O modelo de dados do IDMEF é uma

representação orientada a objectos dos dados de alertas que podem ser enviados do

analisador para o gestor

O IDXP possibilita a troca de mensagens IDMEF e de dados no formato binário entre

componentes de um IDS. Em parte, é especificado como um perfil específico do

protocolo BEEP (Blocks Extensible Exchange Protocol). O BEEP

(www.beepcore.org) é um framework para protocolos de aplicação genéricos que

funcionam com interacções assíncronas e orientadas à conexão. Muitos dos

http://www.beepcore.org/



21

requerimentos exigidos ao IDXP são preenchidos pela framework do BEEP, por

exemplo, transmissão fidedigna de mensagens e autenticação mútua.

O IDWG continuou a desenvolver estes conceitos, com esperança que se tornassem o

padrão que servisse de base ao desenvolvimento de IDS com um grau de

interoperabilidade máximo. Este working group parou os seus trabalhos devido a uma

perda de motivação e interesse pelos objectivos propostos (http://www1.ietf.org/mail-

archive/web/ietf-announce/current/msg02352.html), deixando todo o trabalho

(IDMEF e IDXP) em estado de RFC experimental, para o qual foi reclassificado no

primeiro trimestre de 2006 (http://www1.ietf.org/mail-archive/web/ietf-

announce/current/msg02371.html).

3.2 Conceitos Básicos

Existem diversos conceitos básicos que serão explorados de seguida de forma a

melhor compreender os IDS e o ambiente envolvente.

Intrusão – é definida como o conjunto de acções desencadeadas pelo intruso que

compromete a estrutura básica da segurança da informação de um sistema

informático: integridade, confidencialidade e disponibilidade.

A política de segurança define com clareza o que é uma intrusão, ou seja, este

instrumento expressa claramente o que é permitido e o que não é.

Intruso – definido como qualquer utilizador ou entidade que acede ou invade um

sistema sem que para tal tenha obtido autorização.

A detecção de um intruso é uma tarefa complexa, uma vez que este pode ter em seu

poder a identificação de um outro utilizador legítimo ou um comportamento muito

semelhante ao de um utilizador legítimo.

A distinção correcta entre um utilizador legítimo e um utilizador intruso é de extrema

importância. Assim, pode-se fazer a distinção de dois tipos de intrusos:

• Intruso Externo – todos os utilizadores que não pertencem ao sistema e que

implementam acções de intrusão ao mesmo;

http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02352.html






22

• Intruso Interno – todos os utilizadores que têm algum tipo de autorização de

acesso legítimo ao sistema e que, normalmente ultrapassando os seus direitos

de acesso, tentam realizar acções de intrusão a esse mesmo sistema.

Detecção de intrusão – consiste no processo de monitorização de eventos que

ocorrem em computadores e em recursos de rede, para que estes possam ser

analisados de forma a encontrar quaisquer sinais evidentes de intrusão.

Um IDS é definido por englobar toda a tecnologia (software ou hardware) que

permite automatizar o processo de monitorização e de análise de eventos inesperados

e que podem indiciar a ocorrência de actividades maliciosas de intrusão.

Estes mecanismos devem ser implementados pelos sistemas para permitirem a

detecção dos dois tipos de intrusos referidos anteriormente.

A classificação de IDS pode respeitar várias abordagens: tipo de fontes de informação

de onde são recolhidos os dados, técnicas ou princípios de detecção utilizados ou tipo

das intrusões detectadas.

3.3 Função dos Sistemas de Detecção de Intrusão

O conjunto de funções atribuídas aos IDS engloba todas as actividades maliciosas,

anómalas ou incorrectas que ocorrem num sistema informático. Assim o IDS tem o

papel de identificar positivamente todos os verdadeiros ataques e identificar

negativamente todos os falsos ataques. O IDS pode responder em tempo real a

processos ou eventos de intrusão através da análise de todo o processo e das marcas

(assinaturas) ou padrões comportamentais de uma intrusão. As seguintes actividades

são realizadas pelos IDS e através de graus variáveis de precisão:

• Monitorização e análise de actividades de sistema e dos utilizadores;

• Realização de auditorias à infra-estrutura, às falhas e às vulnerabilidades do

sistema;

• Identificação do modelo de actividades do sistema, de forma a reconhecer-se

sinais de ataques e de alertas;

• Realização de uma análise estatística a um modelo de comportamento

anómalo;



23

• Avaliação da integridade dos ficheiros de dados e de sistema;

• Realização de auditorias de gestão ao sistema operativo e de reconhecimento

do comportamento dos utilizadores que desobedecem à política de segurança

da organização.

Os IDS integram-se dentro das medidas de detecção definidas no modelo para a

segurança da informação (detecção e comunicação da intrusão ao responsável pela

segurança do sistema), não possuindo um carácter verdadeiramente preventivo no

sentido de impedir a ocorrência de uma intrusão. No entanto existem IDS capazes de

reagir aquando da detecção de acções não autorizadas, de forma a conter ou parar o

causador, por exemplo desligando a ligação à rede. Um exemplo elucidativo é ao ser

detectado um port scan, que visa encontrar portos abertos que possam ser

aproveitados por cavalos de tróia (trojan horses), o IDS poderá bloquear ligações

vindas desse terminal.

3.4 Critérios de Avaliação da Qualidade dos Sistemas de Detecção de Intrusão

São vários os parâmetros que permitem avaliar a qualidade de um IDS, entre os quais:

• Adaptabilidade – expressa a capacidade que o IDS possui em reconhecer

ligeiras modificações de ataques já conhecidos;

• Extensibilidade – traduz a capacidade que o sistema de detecção possui em

poder ser personalizado (Por exemplo interagir com diversos tipos de bases de

dados);

• Eficiência ou precisão da detecção – traduz a capacidade que o IDS possui

para detectar correctamente a ocorrência de intrusões;

A eficiência dos IDS é contabilizada através do número de erros de detecção

que ocorrem, tendo em conta os seguintes critérios:

o Falsos Positivos – acontecem no caso de um evento ser incorrectamente

identificado pelo IDS como sendo uma intrusão, quando na realidade esta

não aconteceu, ou seja, constitui um falso alarme. Deste modo, um falso



24

positivo pressupõe que um comportamento legítimo de um utilizador é

identificado pelo IDS como um comportamento de intrusão;

o Falsos Negativos – acontecem no caso do IDS não conseguir identificar

um ataque, quando na realidade o respectivo evento é efectivamente uma

intrusão. Deste modo, um falso negativo pressupõe que um

comportamento de intrusão é identificado pelo IDS como sendo um

comportamento de utilização normal.

• Impacto no desempenho do sistema – constitui um parâmetro que procura

reflectir o peso do processamento associado à função IDS, face à quantidade

de processamento da função normal do sistema. Neste parâmetro pode ser

quantificado o grau de utilização do processador e os eventuais atrasos no

processamento normal dos dados e o tráfego de rede gerado.

De referir que actualmente não existe um sistema padronizado para efectuar

benchmarks aos IDS.



25

3.5 Categorias dos Sistemas de Detecção de Intrusão

Existem diversas abordagens possíveis na classificação de IDS como se demonstra na

Figura 6.

Figura 6 – Classificação de IDS

Uma das maneiras de catalogar IDS é em função das fontes de informação de onde

são recolhidos os dados analisados. Destes tipos de processamento da informação

resultam três abordagens:

Figura 7 – Classificação de IDS segundo a fonte de informação



26

• IDS baseados na Rede (Network-based IDS - NIDS) – obtêm dados através

da monitorização do tráfego na rede informática de forma a descobrir

possíveis sinais de intrusão, sendo-lhes habitualmente reconhecidas as

seguintes características:

o São relativamente baratos;

o Tornam as evidências de ataques difíceis de esconder;

o Permitem uma detecção e resposta a ataques em tempo real,

minimizando desta forma os estragos causados pelas intrusões;

o Podem detectar tentativas de ataques falhados;

o São independentes do sistema operativo.

• IDS baseados em Máquinas (Host–based IDS - HIDS) – obtêm os dados do

sistema operativo ou das aplicações que estão numa determinada máquina

(host) que está sujeita a intrusões. A recolha dos dados é frequentemente feita

com o recurso a logs do sistema. Este método de actuação permite que a

recolha de dados reflicta com precisão o que está a efectivamente a acontecer

no terminal. Os HIDS possuem as seguintes características:

o Não necessitam de hardware adicional;

o Permitem uma detecção e resposta a ataques em tempo quase real;

o Dependem do sistema operativo que está instalado no terminal;

o Adaptam-se bem a sistemas que utilizem a encriptação nas

comunicações.

• IDS Híbridos – são um misto dos NIDS e dos HIDS (p.e. Prelude).

Existem diversos tipos de dados que podem ser recolhidos pelos IDS:

• Dados referentes ao tráfego de rede;

• Dados referentes à linha de comandos do sistema operativo;

• Dados referentes às chamadas de sistema do sistema operativo;

• Dados gerados ou manipulados pelas aplicações;

• Todos os caracteres transmitidos;



27

• Dados referentes a keystrokes;

• Logs de segurança activa (p.e. HTTP e FTP).

A localização das tecnologias de recolha de dados (sensores) também pode servir para

classificar os IDS:

Figura 8 – Classificação de IDS segundo o sensor

• Sensores Externos – englobam todos os componentes de monitorização que

estão separados das aplicações e dos objectos que estão a ser monitorizados.

Têm a seu favor o facto de poderem ser facilmente modificados, adicionados

ou removidos de um terminal e da sua implementação não estar sujeita à

linguagem de programação utilizada para aplicar restrições impostas pelos

objectos que estão a monitorizar. No entanto, apresentam como desvantagens

o facto de poderem ser desactivados ou modificados pelos intrusos e de terem

impacto assinalável no desempenho do host, no caso dos HIDS.

• Sensores Internos – encontram-se integrados no próprio código da aplicação

que está a ser monitorizada. Este tipo de sensores apresenta como vantagens o

facto de não poderem ser facilmente modificados e de não provocarem um

impacto assinalável no desempenho do host. As principais desvantagens estão

no facto de serem difíceis de implementar já que esta tem de ser efectuada

utilizando a mesma linguagem da aplicação que pretendem monitorizar, de

serem complicados de actualizar ou modificar e poderem causar sérias

consequências no desempenho do sistema se forem projectados ou

implementados de uma maneira incorrecta.

3.6 Técnicas ou Princípios de Detecção de Intrusão

Denning apresentou o modelo de detecção de intrusões pelo qual muitos se baseiam.

Neste modelo são utilizados os registos de auditoria (audit records), pacotes de rede

ou ainda qualquer outra actividade observável, para a detecção de anomalias no

sistema.



28

As técnicas de detecção de intrusões dividem-se em várias categorias:

Figura 9 – Classificação de IDS segundo a técnica de detecção

• Detecção por Anomalias (Anomaly Detection):

Consiste na tentativa de determinar uma intrusão através da verificação da

ocorrência de um desvio relativamente aos padrões de utilização normal

estabelecidos para o sistema. Estas técnicas assumem que todas as actividades

de intrusão são necessariamente anómalas.

Se um perfil de actividade normal (Baseline) poder ser estabelecido para um

determinado sistema, então todas as variações estatísticas significativas do

estado do sistema relativamente a esse perfil poderão ser catalogadas como

uma tentativa de intrusão.

Este tipo de sistema detecta tudo o que seja anómalo. No entanto, esta técnica

quando aplicada, tende para uma elevada taxa de falsos positivos e falsos

negativos.

São várias as abordagens de implementação do princípio de detecção de

intrusão por anomalias:

Figura 10 – Abordagens da detecção de intrusão por anomalias



29

• Abordagem estatística – pressupõe que inicialmente sejam gerados os

perfis de comportamento dos utilizadores do sistema, em termos de

parâmetros estatísticos adequados. Posteriormente, e à medida que o

sistema vai sendo utilizado, o detector de anomalias gera

continuamente uma variância do perfil actual relativamente ao original.

A principal vantagem está no facto deste método ser francamente

adaptável, de tal modo que pode facilmente descobrir o

comportamento dos utilizadores do sistema. Contudo, apresenta como

desvantagem o facto do método poder ser gradualmente viciado por

intrusos, de tal modo que habituem o sistema de treino à utilização

intrusiva, aumentando a taxa de falsos negativos;

• Criação de padrão de predição (Predictive Pattern) – tenta vaticinar

a ocorrência de eventos futuros baseando-se para tal em eventos que já

tenham acontecido. Os sistemas que utilizam este método são bastante

adaptativos a mudanças, uma vez que os maus padrões são eliminados

continuamente;

• Redes neuronais – passa pelo treino de uma rede neuronal através da

qual se procura vaticinar a próxima acção ou comando desencadeado

pelo utilizador do sistema. Para tal, a rede é treinada com um conjunto

de comandos representativos do utilizador, pelo que após o período de

treino, a rede tenta comparar os comandos actuais com o perfil actual

do utilizador já existente nesta rede.

O IDES (Real-time Intrusion Detection Expert System), o Wisdom & Sense

(Detection of Anomalous Computer Session Activity), o Hyperview (Neural

Network Component for Intrusion Detection) e o DPEM (Distributed Program

Execution Monitoring) são exemplos de IDS baseados em detecção de

anomalias.

• Detecção por má utilização, detecção por regras ou detecção por marcas

(Signature Detection):

A detecção de intrusão por regras baseia-se na utilização de padrões de

ataques já conhecidos ou de pontos vulneráveis do sistema para tentar



30

descobrir e identificar a ocorrência de intrusões. Ao pressupor que existem

meios para representar ataques sob a forma de um padrão, de uma marca ou de

uma assinatura (signature), esta técnica é capaz de detectar até pequenas

variantes do mesmo ataque.

Esta técnica detecta todos os comportamentos semelhantes a padrões já

conhecidos. No entanto pode apresentar alguns problemas, entre os quais:

• A descoberta de um padrão que inclua todas as variações possíveis de

um ataque pertinente e que não seja coincidente com uma actividade de

não intrusão;

• A inabilidade para detectar intrusões que ainda não sejam conhecidas

pelo IDS.

Ao contrário da detecção de intrusão por anomalias, que se baseia em falhas

no comportamento normal do sistema, a detecção por regras tenta implementar

um modelo que detecta o comportamento de intrusão do atacante. Uma vez

que ambas as abordagens (detecção por anomalias e detecção por regras) têm

falhas, é frequente as tecnologias de IDS serem baseadas nas duas.

São várias as abordagens para os princípios de detecção de intrusão por regras:

Figura 11 – Abordagens da detecção de intrusão por regras

• Baseada num modelo – advoga que certos cenários de intrusão podem

ser identificados pela observação de determinadas actividades. Como

tal, se estas actividades forem monitorizadas, então poderá ser possível

descobrir tentativas de intrusão. Com base no modelo de intrusão, o

sistema pode então prever o próximo movimento do atacante. Estas

previsões podem ser utilizadas para confirmar hipóteses de intrusão ou

para tomar medidas preventivas. As principais desvantagens estão no

facto de os padrões para cenários de intrusão terem de ser facilmente

reconhecidos e não estarem associados a um comportamento normal;



31

• Baseada na coincidência de padrões (Pattern Matching) –

pressupõe a codificação das assinaturas de intrusões conhecidas em

padrões que são posteriormente comparados com os padrões

monitorizados. Como tal, neste modelo é feita uma tentativa para fazer

coincidir eventos de entrada com padrões representativos de cenários

de intrusão. A principal desvantagem está no facto de que detecta

somente ataques que se baseiam em comportamentos não autorizados

já conhecidos.

O DIDS (Distributed Intrusion Detection System), o ASAX (Architecture and

Rule-Based Language for Universal Audit Trail Analysis) e o USTAT (State

Transition Analysis) são exemplos de implementações de sistemas baseados

na detecção por regras.

O Haystack, o MIDAS (Expert Systems in Intrusion Detection), o NADIR

(Automated System for Detecting Network Intrusion and Misuse) e o NIDES (Next

Generation Intrusion Detection Expert System) são exemplos de IDS que se baseiam

nas duas abordagens (baseadas em anomalias e em regras).

Uma abordagem mais recente para a implementação de IDS é a detecção de intrusões

baseada em data mining. Estes sistemas necessitam da realização de auditorias (trails

audit) especializadas de forma a identificar padrões anómalos de utilização. No

entanto, o volume de dados gerados nestas auditorias é problemático. Assim, neste

contexto é necessário utilizar data mining em IDS, pois esta técnica apresenta

potencial suficiente para minimizar o problema da detecção automática de padrões

anómalos a partir da monitorização de grandes quantidades de dados auditados.

Os IDS que implementam data mining ainda estão numa fase prematura, mostrando-

se problemáticos, pois apresentam taxas elevadas de falsos positivos, possuem uma

baixa eficiência durante a fase de treino e avaliação (problemas de análise em tempo

real) e são mais complexos que os sistemas já existentes.

Existem outras perspectivas a ter em conta para se catalogar os IDS, entre elas o tipo

de detecção, a reactividade e o tipo de análise (número de máquinas), tal como

demonstra a Figura 12.



32

Figura 12 – Outras abordagens para classificar os IDS

Existem diversos tipos de intrusão, que por sua vez também dividem os IDS em

categorias ordenadas pelo grau de dificuldade de implementação:

• Intrusões Bem Conhecidas – englobam todos os ataques perfeitamente

conhecidos, estando por isso bem definido um padrão estático dos seus

comportamentos, já que apresentam uma fraca variabilidade;

• Intrusões Genéricas – semelhantes às anteriores, mas podem apresentar uma

variabilidade maior. Este tipo de intrusões exploram falhas genéricas

existentes nos sistemas, pelo que existe uma maior probabilidade para a

ocorrência de variações no padrão do respectivo ataque;

• Intrusões Desconhecidas – são as mais difíceis de detectar, uma vez que o

sistema não possui nenhum padrão acerca do comportamento deste tipo de

ataques.



33

Dificuldade de Implementação

Intrusões Bem Conhecidas

Intrusões Genéricas

Intrusões Desconhecidas

Figura 13 – Abordagem segundo a dificuldade de implementação

3.7 Considerações Finais sobre IDS

Não existe um método de detecção ideal, quer por anomalias, quer por assinaturas,

visto ambos terem vantagens valiosas. Num plano utópico teríamos um IDS com um

número baixo de falsos positivos e negativos apresentados pelos sistemas baseados

em detecção por assinaturas, combinado com a dinâmica dos sistemas de detecção por

anomalias. Este IDS teria actualizações constantes do baseline (padrão de

normalidade), cautelosas, precisas e que não corressem o risco de considerar como

normais diversas actividades maliciosas. Estaria sempre actualizado contra ataques

não conhecidos.

Existem diversas ferramentas que utilizam técnicas mistas, como referido (Secção

3.6), no entanto ainda estão em fase evolutiva, longe de alcançarem resultados fiáveis.

O Snort, objecto de estudo deste relatório (Capitulo 4), é um IDS de rede (Network

IDS) que se baseia em detecção por assinaturas. É actualmente o 3º no Top 100 de

ferramentas de segurança de rede sendo o IDS com melhor classificação. Esta tabela

classificativa, que apresenta as 100 melhores ferramentas de segurança de rede, na

opinião de 3243 utilizadores da mailing list nmap-hackers, pode ser consultada em

http://sectools.org.

http://seclists.org/#nmap-hackers

http://sectools.org/



34

4 Um Sistema de Detecção de Intrusão de Rede: o Snort

O Snort (www.snort.org) é uma ferramenta open source para soluções NIDS –

Network Intrusion Detection System.

O logótipo do Snort é um “porco”, em alusão à tarefa de farejar e capturar todos os

pacotes que estão a passar na rede. Uma vez que o Snort tem a capacidade de analisar

todo o conteúdo dos pacotes, comparando-o com um vasto conjunto de regras em

tempo real, tornou-o desde o seu aparecimento, um IDS de eleição.

O facto de ser disponibilizado em open source permite que as pessoas fortemente

interessadas em aplicar um NIDS na sua rede o possam testar sem qualquer

preocupação de adquirir ou comprar licenças de softwares proprietários. Tal facto

permitiu ainda, que ao longo do tempo fosse sofrendo bastantes actualizações e

correcções como ainda hoje acontece frequentemente, possibilitando também que os

utilizadores possam desenvolver as suas próprias regras para detecção de ataques

existindo sempre um espírito de partilha das mesmas.

4.1 História do Snort

O Snort foi desenvolvido em linguagem de programação C baseando-se na biblioteca

de programação libpcap (biblioteca para captura de pacotes de rede), que é utilizada

em ferramentas de captura de tráfego de rede, tais como os sniffers (p.e. Ethereal).

Inicialmente, o criador do Snort, Marty Roesch, queria construir uma ferramenta de

sniffing para ambiente Linux melhor do que as existentes no mercado, tal como o

popular tcpdump, ferramenta nativa de sistemas baseados em Unix, utilizado para

captura de pacotes.

De entre as principais utilidades que Marty Roesch gostaria de implementar no seu

sniffer (chamado inicialmente de APE), constavam:

• Funcionamento em diversos sistemas operativos.

• Decomposição de pacotes em formato hexadecimal – hexdump

(posteriormente o tcpdump implementou esta função através do parâmetro -X).

http://www.snort.org/



35

Depois de concluir o objectivo de capturar pacotes, Marty começou a desenvolver o

Snort para desempenhar as funções de IDS, pois não existiam softwares livres e

eficientes que desempenhassem esta função. Em 1999 consegue atingir o objectivo de

habilitar o Snort a comparar o tráfego de rede com as regras que ele definiu. Neste

mesmo ano, a comunidade científica de open source começou a testar o Snort

permitindo assim que este fosse alvo de diversas actualizações, o que o tornou mais

fácil de configurar e adaptar para utilização em ambientes organizacionais.

A versão mais actual do Snort é a 2.4.X e desde a versão 2.0.X, o Snort contou com

uma reformulação total na sua estrutura, uma vez que inicialmente não possuía

suporte a pré-processadores nem a inserção de plugins. Com o passar do tempo

evoluiu para obter melhor desempenho, permitindo capturar o maior número de

pacotes possível da rede. Esta evolução permitiu ainda guardar os ataques registados

em base de dados (MySQL, Postgres, entre outros), aparecendo neste momento os

pré-processadores que, entre outras funcionalidades, detectam chamadas RPC

(chamadas a funções remotas), agrupam pacotes desfragmentados e detectam port

scans, antes que seja aplicado o mecanismo de detecção de ataques.

4.2 Arquitectura Interna do Snort

O Snort é dividido logicamente em múltiplos componentes. Estes componentes

trabalham juntos para detectar os ataques à rede e gerar saídas no formato

especificado pelo IDS. A arquitectura interna do Snort é baseada nos seguintes

componentes:

• Mecanismo de captura/descodificação de pacotes

• Plugins de pré-processador

• Mecanismo de detecção

• Plugins de saída

A Figura 14 mostra como estes componentes estão organizados sequencialmente.

Todos estes componentes serão abordados em detalhe nas próximas secções.



36

Figura 14 – Arquitectura do Snort

4.2.1 Mecanismo de Captura e Descodificação de Pacotes

Para que o Snort consiga capturar o tráfego de rede são necessárias duas

configurações:

• Configurar a placa de rede em modo promíscuo.

• Instalar a biblioteca libpcap/winpcap para capturar os pacotes.

O comportamento padrão de uma placa de rede é ignorar o tráfego que não é

destinado ao seu endereço MAC. É necessário mudar este comportamento para que

não seja verificado o endereço MAC de destino.

O Snort (“snort.c”) funciona através de funções da biblioteca libpcap. Começa por

verificar a interface e coloca-a no modo promíscuo, em seguida entra no chamado

loop de execução com a função pcap_loop(). Neste loop infinito, a função

pcap_loop() espera que sejam recebidos pacotes da placa de rede e, então, chama a

função ProcessPacket(). Esta chama as funções de descodificação da camada de rede

“decode.c” (Figura 15).

A libpcap é uma biblioteca independente da plataforma e funciona em todos os

sistemas UNIX e Windows (WinPcap), portanto, foram aproveitadas todas as

potencialidades oferecidas por essa biblioteca.

Após os pacotes serem capturados têm de ser descodificados, por exemplo para um

pacote ICMP. A função ProcessPacket() chama a função DecodeEthPkt(), que

descodifica a estrutura Ethernet. Dentro da função DecodeEthPkt(), a função

DecodeIP() descodifica o protocolo IP. Finalmente, a função DecodeICMP()

descodifica o pacote ICMP sendo a informação guardada em estruturas de dados

apropriadas. A Figura 15 ilustra as diferentes funções de descodificação e a ordem em

que são processadas.



37

Figura 15 – Funções de descodificação de pacotes

4.2.2 Plugins Pré-Processador

Após a captura e descodificação dos pacotes vem a etapa dos plugins de pré-

processador. Nesta etapa, os pacotes sofrem ajustes e reagrupamentos para quando

forem enviados para o mecanismo de detecção, as regras possam ser aplicadas de uma

forma mais optimizada.

A necessidade de implementar pré-processadores deu origem ao lançamento do Snort

v1.5. A ideia principal por trás da introdução deste mecanismo foi fornecer uma

estrutura para permitir alertar, eliminar e modificar os pacotes (pré-processamento),

antes de chegarem ao mecanismo de detecção principal do Snort. A Figura 16 mostra

a funcionalidade dos pré-processadores.



38

Pré-Processador Mecanismo de Detecção

Plug-in stream4

Plug-in portscan

Plug-in frag2

PRÉ-

PROCESSADORES

Figura 16 – Plugins de pré-processadores

Se fosse apenas inspeccionado o payload de cada pacote individualmente e

comparado com regras simples, teríamos um programa leve, capaz de suportar redes

rápidas e bastante sobrecarregadas. Mas, este tipo de IDS gera muitos falsos positivos.

Se as regras forem muito específicas, muitos ataques serão perdidos – estas perdas são

os falsos negativos, pois não são alertadas. Grande parte do problema na escrita de

regras tradicionais correctas reside na minúscula capacidade de expressão na

linguagem da assinatura ou na incapacidade do IDS entender os protocolos mais

detalhadamente.

Este tipo de IDS pode usar detecção por anomalia do protocolo, sendo gerado um

alerta sempre que os pacotes não estejam de acordo com as normas definidas, os IDS

baseados em assinaturas/regras também podem manter o estado das ligações.

Os pré-processadores são realmente úteis, pois tornam mais fácil a escrita das regras.

Diminuem a presença de falsos positivos/negativos e fornecem a um IDS de

correspondência de regras a capacidade de superar o seu modelo de detecção

tradicionalmente simples, mantendo um bom desempenho.



39

Os vários pré-processadores disponíveis para serem usados com o Snort podem estar

ligados ou desligados. O Snort permite que o administrador de rede crie os seus

próprios pré-processadores para que estes estejam adequados às necessidades.

4.2.2.1 O Pré-Processador Frag2

A fragmentação é algo que acontece frequentemente no protocolo TCP/IP, visto que o

tráfego pode viajar entre diversos routers com MTUs de diferentes tamanhos. A

fragmentação acontece quando os pacotes são divididos em partes menores para que

caibam em ligações com MTUs menores. Entretanto, apesar de ser útil, a

fragmentação de pacotes também pode ser uma maneira extremamente eficaz para

fazer o tráfego passar pelos IDS sem que um alerta seja despoletado.

Uma ferramenta famosa que realiza a fragmentação de pacotes é o Fragrouter. Este,

capta o tráfego da rede e fragmenta-o em partes menores, antes de o colocar na rede,

fugindo efectivamente de sistemas que façam correspondência com regras. Os IDS

baseados em regras só veriam partes dos pacotes quando passam pela rede. O

inconveniente da fragmentação é que pode ser usada como um ataque de DOS (Denial

of Service). Um IDS tem de remontar os pacotes fragmentados, o que exige uma

quantidade significativa de recursos de memória. Assim, se o volume de tráfego for

suficientemente alto e existirem muitos pacotes fragmentados na rede, o IDS poderá

estar demasiadamente ocupado para observar um ataque que esteja a ocorrer.

Devido a estes problemas foi criado o pré-processador frag2, que remonta os pacotes

fragmentados antes que estes cheguem ao mecanismo de detecção, de modo a que as

regras possam ser aplicadas ao tráfego de uma sessão e não a simples pacotes

fragmentados. O pré-processador frag2 também grava alertas quando limites de

fragmentação são alcançados.

4.2.2.2 O Pré-Processador Stream4

O pré-processador stream4 foi projectado para o Snort poder ter um registo do estado

das ligações ponto-a-ponto, passando a detectar sessões de ligações, detectando

técnicas de footprinting (obter informações da entidade que se pretende atacar) e a

utilização de programas como o Nmap.

Quando é feita uma conexão TCP (Camada 3 do TCP/IP) de um cliente para um

servidor, vários eventos ocorrem, é feito o three-way handshake para estabelecer a



40

ligação, os dados são transferidos e finalmente é terminada a ligação. Usando o pré-

processador stream4, durante as fases anteriormente apresentadas, o Snort constrói

tabelas internas para representar essas sessões procedendo à sua eliminação quando as

ligações são terminadas. Uma vez que o Snort usa as suas próprias tabelas de estado

pode analisar uma sessão completa e não apenas flags SYN, ACK e FIN individuais

para um destino em particular.

4.2.2.3 Os Pré-Processadores para Port Scans

Uma parte importante de uma ferramenta IDS é a sua capacidade de detectar os port

scans. Os port scans são usados por invasores para identificar quais as portas que

estão abertas, de seguida tentam explorar falhas de segurança adjacentes aos serviços

que estão a utilizar essas portas.

Um port scan TCP típico é enviar um pacote com o bit de sincronismo activo (flag

SYN) para um servidor. O servidor responde com o bit de sincronismo e acknowledge

(SYN+ACK) se a porta estiver aberta, se estiver fechada responde com as flags

(SYN+RST) activas. Enviando SYNs para várias portas e observando se as flags de

reposta são o conjunto SYN e ACK, descobrem-se portas abertas.

4.2.3 Mecanismo de Detecção

O mecanismo de detecção pode ser considerado como o componente mais importante

do Snort. Todos os dados provenientes dos pré-processadores são verificados através

de um conjunto de regras (assinaturas).

As regras do Snort são baseadas em texto e normalmente estão armazenadas numa

subdirectoria da directoria de instalação do Snort sendo constituídas por duas partes, o

cabeçalho e as opções. Por exemplo, dentro do ficheiro “dos.rules” estão incluídas

todas as regras referentes a ataques DoS.

Quando o Snort arranca são criadas várias listas ligadas em memória com a

informação de todas as regras, sendo estas percorridas quando se pretende comparar

os dados dos pacotes com as regras.

Existem 5 tipos de regras, definidos no cabeçalho.

• Activation: Alerta e de seguida chama uma regra do tipo “dynamic”



41

• Dynamic: Regista o tráfego quando chamada por uma regra do tipo

“Activation”

• Alert: Gera um alerta e guarda o registo do pacote e os dados

• Pass: Ignora o pacote

• Log: Regista mas não alerta

Figura 17 – Ordem pela qual são verificados os tipos de regras

Após as regras estarem ordenadas pelo tipo, para cada tipo de regra existem lista para

os protocolos suportados, sendo esses protocolos os seguintes:

• Protocolo TCP (SNMP, HTTP, FTP)

• Protocolo UDP (DNS, SNMP, DHCP, RIP)

• Protocolo ICMP (Traceroute, ping)

• Protocolo IP (IGMP)

Cada nó das listas referentes aos protocolos representa uma regra, sendo a estrutura de

dados designada por RTN (Rule Tree Node), essa estrutura de dados contém as

variáveis onde está guardada a informação sobre o endereço IP origem e destino,

porto origem e destino a que se refere a regra. Nessa estrutura de dados está ainda

contida uma lista ligada para as opções da regra, a estrutura de dados que representa

um nó da lista de opções é designada por OTN (Option Tree Node).

Na Figura 18 está ilustrado um exemplo de regras do tipo alert onde se pode observar

as listas ligadas separadas por protocolo bem como os RTN.



42

Figura 18 – Listas de regras consoante o protocolo

Todas as regras contêm uma lista de opções, na Figura 19 estão ilustrados os RTNs e

respectivos OTNs, mais especificamente, cada nó da lista de protocolos (RTN)

contém uma lista de opções as designadas OTN (Option Tree Node).

Figura 19 – RTNs e respectivos OTNs



43

Sempre que sejam adicionadas, removidas ou actualizadas regras, é necessário

reiniciar o Snort, pois todas as regras são carregadas para a memória quando o Snort

arranca.

Na Secção 4.3 pode ser encontrada mais informação sobre as regras do Snort.

O conteúdo dos pacotes é comparado com as regras da seguinte forma:

• Chegado o pacote ao mecanismo de detecção, são percorridos os cabeçalhos

das regras pela seguinte ordem: Activation, Dynamic, Alert, Pass e Log.

• Para cada cabeçalho verifica os RTN e os OTN. Por exemplo, para um pacote

HTTP que coincida com uma regra do tipo Alert, visto o este pertencer ao

protocolo TCP será percorrida a lista de RTNs do tipo TCP que se encontram

associados ao cabeçalho alert.

• Caso seja encontrada uma regra em que o endereço IP origem, porto origem,

endereço IP destino e porto destino coincidam com os do pacote que está a ser

examinado, é percorrida a lista de OTNs dessa regra e caso as opções da regra

coincidam com os dados do pacote, será gerado uma alerta de acordo com o

especificado na regra.

Caso o administrador assim o entenda, poderá ser alterada a ordem como é feita a

pesquisa, ou seja, caso se pretenda que sejam verificadas primeiro as regras do tipo

PASS basta executar o Snort com o modo “–o”, este modo de operação poderá ser um

pouco arriscado uma vez que, se o pacote coincidir com uma regra do tipo PASS esse

pacote não será comparado com mais nenhuma regra, será imediatamente descartado

do mecanismo de detecção.

4.2.4 Plugins de Saída

Após os pacotes serem capturados, descodificados, passarem pelos pré-processadores,

serem analisados pelo mecanismo de detecção e caso coincida com uma regra é

necessário que o alerta e o conteúdo do pacote sejam guardados para posterior análise

humana para se verificar se não é um falso positivo. Os plugins de saída são os

responsáveis pela parte final do IDS.



44

Os plugins de saída podem interagir com a firewall, podem enviar alertas via e-mail,

popups, gravar em ficheiros de textos, gravar numa base de dados MySQL entre outras

acções.

Existem muitas ferramentas adicionais que podem ser usadas com o Snort, como

plugins para Perl, PHP, BASE, ACID, etc.

Os plugins Snortsam e o Guardian têm a capacidade de actuar em tempo real, sendo

assim possível bloquear o endereço IP origem dos pacotes através da alteração da

iptables. No teste 11 deste relatório foi utilizado o Guardian, cujo guia de instalação

está no tutorial presente no Anexo 1.

Caso o Snort esteja configurado para guardar os alertas e o conteúdo dos pacotes

numa base de dados, uma ferramenta como o BASE torna-se útil para a visualização

dos mesmos, uma vez que tem a capacidade de gerar páginas web com toda a

informação disponível.

4.3 Regras

As intrusões têm um determinado tipo de assinatura, assim como os vírus. A

informação sobre estas assinaturas é usada para criar as regras do Snort. Podem ser

usados honeypots para descobrir o que os intrusos estão a fazer e alguma informação

sobre as técnicas e ferramentas utilizadas. Além disso existem as bases de dados de

vulnerabilidades que os intrusos geralmente exploram. Estes ataques já conhecidos

também são usados como assinaturas para se saber se alguém está a tentar explorar as

vulnerabilidades referidas. Estas assinaturas podem estar presentes em partes do

cabeçalho de um pacote ou mesmo nos dados. As regras do Snort são baseadas em

assinaturas de intrusos e podem ser usadas para verificar várias partes do pacote de

dados. As versões mais recentes do Snort (a partir da versão 2) suportam análise a

cabeçalhos da camada de aplicação bem como das camadas 3 (Rede) e 4 (Transporte).

As regras são aplicadas ordenadamente em todos os pacotes independentemente do

seu tipo.

Uma regra pode ser usada para: gerar uma mensagem de alerta, fazer registo de um

evento, ou ignorar o pacote de dados. As regras do Snort são escritas em texto e com

uma sintaxe de simples compreensão sendo a maior parte escrita numa só linha. No

entanto também se podem ter regras em várias linhas usando o caracter '\' no fim das



45

mesmas. As regras são geralmente colocadas no ficheiro de configuração, tipicamente

“snort.conf”. Também podem ser usados vários ficheiros desde que incluídos no

ficheiro de configuração.

As regras do Snort operam na camada de rede (IP) e protocolos da camada de

transporte (TCP/UDP). Contudo existem métodos para detectar anomalias nos

protocolos da camada de ligação e aplicação.

Como demonstra a Figura 20 todas as regras têm duas partes lógicas: o cabeçalho e as

opções.

Figura 20 – Estrutura de uma regra

O cabeçalho da regra contém informação acerca da acção a tomar. Também contém

critérios para comparação com os pacotes de dados. A parte das opções geralmente

contém uma mensagem de alerta e informação sobre qual a parte do pacote a ser

usada para gerar a mensagem de alerta. Esta parte contém critérios adicionais para

comparar a regra com pacotes de dados. Uma regra pode detectar um ou vários tipos

de actividades de intrusão.

A Figura 21 mostra os campos do cabeçalho de uma regra:

Figura 21 – Estrutura do cabeçalho de uma regra

A acção de uma regra determina o tipo de acção a ser tomada quando os critérios

coincidem. Tipicamente as acções são gerar um alerta, registar uma mensagem ou

mesmo invocar outra regra.



46

A parte do protocolo é usado para determinar e filtrar qual o protocolo em particular

ao qual a regra será aplicada.

A parte do endereço define os endereços de origem e destino. Os endereços podem ser

de um simples terminal, de vários terminais ou rede. Estas partes também podem ser

usadas para excluir alguns endereços de uma rede completa. De notar que existem

dois campos endereço na regra. Os endereços de origem e destino ficam dependentes

do campo direcção (p.e. ->).

No caso dos protocolos TCP ou UDP a parte do porto determina o porto de origem e

destino também tendo em conta a parte que define a direcção. No caso dos protocolos

da camada de rede como o IP e ICMP os portos não têm qualquer significado.

O campo direcção determina qual o endereço de origem e qual o de destino.

As opções da regra são a parte mais importante da detecção de intrusão do Snort, uma

vez que combinam a facilidade de uso com a alta capacidade de abrangência e

flexibilidade.

Todas as opções da regra do Snort são separadas uma das outras pelo caracter ponto e

virgula (‘;’) e as palavras-chave das opções das regras são separadas dos seus

argumentos pelo caracter dois pontos (‘:’). São 4 as principais categorias para as

opções das regras: Meta-Data, Payload Detection, Non-Payload Detection e Post-

Detection, sendo cada uma delas opcionais.

Figura 22 – Estrutura das opções de uma regra

4.3.1 Cabeçalho da Regra

4.3.1.1 Acção

A acção é a primeira parte do cabeçalho da regra do Snort. Mostra que acção irá ser

tomada quando as condições da regra são verificadas. A acção é tomada apenas



47

quando todas as condições são verificadas. Existem cinco acções predefinidas. No

entanto, é possível definir acções conforme necessário.

• Pass

Esta acção diz ao Snort para ignorar o pacote, desempenha um papel importante para

acelerar a operação do Snort em casos em que não queremos aplicar verificações em

determinados pacotes.

• Log

Esta acção é usada para registar um pacote. Os pacotes podem ser registados de

diferente maneiras. Os pacotes podem ser registados com diversos níveis de detalhe

dependendo dos argumentos da linha de comandos e do ficheiro de configuração.

• Alert

A acção de alerta é usada para enviar uma mensagem de alerta quando as condições se

verificarem verdadeiras para determinado pacote. Um alerta pode ser enviado de

diversas maneiras. Por exemplo, pode ser enviado um alerta para um ficheiro, base de

dados ou para a consola. A diferença funcional entre as acções log e alert é o facto de

que as ultimas enviam uma mensagem de alerta e depois registam o pacote. A acção

de log apenas regista o pacote.

• Activate

Esta acção é usada para criar um alerta e activa de seguida outra regra para verificar

mais condições. As regras dinâmicas, como explicadas de seguida, são utilizadas para

este propósito. A acção activate é usada quando se necessita de fazer mais testes ao

pacote capturado.

• Dynamic

As regras de acção dynamic são invocadas por regras activate. Em circunstâncias

normais não são aplicadas directamente a um pacote. Uma acção dinâmica apenas

pode ser activada por uma acção activate definida noutra regra.

• Acções definidas pelo utilizador

O utilizador pode criar as suas próprias acções se assim o entender, pode atribuir um

nome á acção e definir quais as medidas a tomar quando existir correspondência entre



48

os dados e as opções das regras. Por exemplo, se o utilizador pretender que o alerta do

ataque seja registado numa base de dados e num ficheiro log no formato TCPDump

no ficheiro “alertas.txt”, este tem de definir uma acção personalizada uma vez que,

não existe nenhuma acção por defeito que faça essas duas operações em conjunto.

ruletype regista

{

type alert

output log_tcpdump: alertas.txt

output database: log, mysql, user=snort dbname=snort \ host=localhost

}

4.3.1.2 Protocolos Suportados

A regra apenas será comparada com pacotes que pertençam ao protocolo definido no

campo protocol. Actualmente o Snort compreende os seguintes protocolos: IP, ICMP,

TCP e UDP.

Se o protocolo for IP, o Snort verifica o cabeçalho da camada de ligação de dados

para determinar o tipo de pacote. Se for usado um dos outros protocolos, o Snort usa o

cabeçalho IP para determinar o tipo de protocolo.

4.3.1.3 Endereços IP Origem e Destino

Existem duas partes de endereços numa regra do Snort. Estes endereços são utilizados

para verificar a origem e o destino do pacote. O endereço pode ser um único endereço

IP ou um endereço de rede. Pode ser utilizada a palavra “any” para aplicar a regra a

todos os endereços. O endereço de rede é seguido por uma ‘/’ e pelo número de bit na

mascara de rede. Por exemplo, o endereço 192.168.2.0/24 representa a rede IP

192.168.2.0 com 24 bits na mascara de rede.

• Exclusão de endereços

Também se pode especificar uma lista de endereços numa regra de Snort. Por

exemplo, se a rede local consistir em duas rede (192.168.2.0 e 192.168.8.0) e se, se

quiser aplicar a regra a todos os terminais menos os que fizerem parte destas duas

redes, pode ser utilizado uma regra onde os endereços aparecem separados por uma

vírgula.



49

alert icmp ![192.168.2.0/24,192.168.8.0/24] any -> any any \ (msg: "Ping with TTL=100"; ttl: 100;)

De notar que o parêntesis recto é usado em conjunto com o símbolo da negação. Se

não se usar a negação não é necessário usar o parêntesis recto.

4.3.1.4 Porto Origem e Destino

O porto é usado para aplicar a regra a pacotes originados de ou que vão para um porto

em particular ou uma gama de portos. Por exemplo, pode-se usar o porto 23 para

aplicar a regra a pacotes originário de um servidor de Telnet. Pode-se utilizar a

palavra “any” para aplicar a regra a todos os pacotes independentemente do porto.

Obviamente que o porto só tem sentido nos protocolos TCP e UDP. A seguinte regra

é aplicada a todos os pacotes que vêm dum servidor Telnet em 192.168.2.0/24 e que

contêm a palavra "confidencial":

alert tcp 192.168.2.0/24 23 -> any any \

(content: "confidencial"; msg: "Detectado confidencial";)

A mesma regra pode ser aplicada a tráfego que vem ou vai para um qualquer servidor

de Telnet na rede, com a simples modificação da direcção como demonstrado na regra

seguinte:

alert tcp 192.168.2.0/24 23 <> any any \

(content: "confidencial"; msg: "Detectado confidencial";)

Os portos são úteis quando se pretende aplicar uma regra apenas para um tipo

particular de pacotes de dados. Por exemplo, se uma vulnerabilidade estiver

relacionada apenas com um servidor HTTP pode-se usar o porto 80 na regra de forma

a detectar quem quiser explorar as vulnerabilidades do servidor. Desta forma o Snort

aplica a regra apenas a tráfego do servidor web e não a todos os pacotes TCP.

• Gamas de portos

Pode-se também usar uma gama de portos em vez de especificar apenas um no campo

do porto. Usa-se uma vírgula para separar o início e o fim da gama. Por exemplo, a

próxima regra cria um alerta para todo o tráfego UDP proveniente dos portos 1024 ao

2048 de qualquer terminal:

alert udp any 1024:2048 -> any any (msg: "UDP ports";)



50

• Fronteiras superiores e inferiores

Pode-se especificar apenas a fronteira das gamas a serem verificadas. Por exemplo,

uma gama definida por :1024 define todos os portos até 1024 enquanto que uma

definida por 1000: seriam todos os portos a partir do 1000.

• Símbolo de negação

Assim como nos endereços também se pode aplicar a negação com os portos de forma

a excluir um ou vários portos. A próxima regra regista todo o tráfego UDP excepto

aquele originado no porto 53.

log udp any !53 -> any any log udp

Também se pode negar uma gama de portos como por exemplo 53:554.

log udp any ![53:554] -> any any log udp

4.3.1.5 Operadores de Direcção

O campo direcção determina os endereços e portos de origem e de destino de uma

regra. As seguintes normas aplicam-se ao campo direcção:

• O símbolo -> mostra que o endereço e porto na parte esquerda do campo

direcção serão a origem do pacote, enquanto que os da direita serão o destino.

• O símbolo <– mostra que o endereço e porto na parte direita do campo

direcção serão a origem do pacote, enquanto que os da esquerda serão o

destino.

• O símbolo <> mostra que a regra será aplicada aos pacotes a viajar em

qualquer dos sentidos. É uma norma útil para quando se quer monitorizar

pacotes de dados do cliente e também do servidor.

4.3.2 Opções da Regra

As opções das regras seguem-se ao cabeçalho e estão contidas dentro de parêntesis.

Podem existir uma ou mais opções desde que separadas por um ponto e virgula. Se

forem usadas várias opções estas são interpretadas como um E (AND) lógico. A acção

no cabeçalho da regra é invocada apenas quando os critérios das opções são todos

verdadeiros. Todas as opções são definidas por palavras-chave e algumas contêm



51

também alguns argumentos. Em geral uma opção pode ter duas partes: a palavra-

chave e o argumento, separados por dois pontos (‘:’).

4.3.2.1 Meta-Data

Estas opções fornecem informações personalizadas sobre a regra, mas não têm

qualquer efeito para a detecção.

De seguida são mostrados exemplos de como se podem usar estas opções. De realçar

que apenas servem para melhorar os recursos de produção de relatórios e

configuração dentro do Snort.

• MSG

A opção “msg” é usada para adicionar uma mensagem à regra, sendo essa mensagem

usada para registar a ocorrência do ataque no ficheiro de logs e utilizada para dar o

alerta. A mensagem que pretendemos atribuir a determinada regra tem de estar entre

aspas. Geralmente é atribuída uma mensagem a todas as regras para ser facilmente

identificável quando for gerado um alerta referente às mesmas. Normalmente a opção

“msg” é utilizada da seguinte forma:

msg: “Texto da mensagem”

Para se poderem utilizar caracteres especiais estes têm de ser precedidos do caracter

‘\’.

• REFERENCE

A palavra-chave “reference” pode, como o nome indica, adicionar uma referência à

informação presente noutro sistema disponível na Internet. Não tem nenhum papel no

mecanismo de detecção propriamente dito e pode ser ignorada quando se escreve uma

regra para o Snort. Existem diversos sistemas de referências, como o CVE (Common

Vulnerabilities and Exposures http://cve.mitre.org/), Nessus e o site web do Snort.

Estes sistemas mantêm informação adicional sobre ataques conhecidos. Ao usar-se

esta palavra-chave pode-se criar uma ligação para a informação adicional na

mensagem de alerta. Por exemplo, a seguinte regra localizada no ficheiro

“netbios.rules” distribuído com o Snort:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 \

(msg:"NETBIOS SMB-DS Session Setup NTMLSSP unicode asn1 \

overflow attempt"; flow:established,to_server; \

http://cve.mitre.org/



52

content:"|00|"; depth:1; content:"|FF|SMBs"; within:5; \

distance:3; byte_test:1,&,128,6,relative; pcre:"/^.{27}/R"; \

byte_test:4,&,2147483648,21,relative,little; \

content:!"NTLMSSP"; within:7; distance:27; \

asn1:double_overflow, bitstring_overflow, \

relative_offset 27, oversize_length 2048; \

reference:bugtraq,9633; reference:bugtraq,9635; \

reference:cve,2003-0818; reference:nessus,12052; \

reference:nessus,12065; \

reference:url,www.microsoft.com/technet/security/bulletin/MS04

-007.mspx; classtype:protocol-command-decode; sid:3003; \

rev:4;)

Esta regra vai gerar a seguinte entrada no ficheiro “/var/log/snort/log”:

[**] [1:3003:4] NETBIOS SMB-DS Session Setup NTMLSSP unicode asn1

overflow attempt [**]

[Classification: Generic Protocol Command Decode] [Priority: 3]

08/23-20:47:51.656254 192.168.232.78:2247 -> 192.168.234.4:445

TCP TTL:128 TOS:0x0 ID:54848 IpLen:20 DgmLen:1500 DF

***A**** Seq: 0xB23D0420 Ack: 0xC64730F0 Win: 0xFF45 TcpLen: 20

[Xref => http://www.microsoft.com/technet/security/bulletin/MS04-

007.mspx]

[Xref => http://cgi.nessus.org/plugins/dump.php3?id=12065]

[Xref => http://cgi.nessus.org/plugins/dump.php3?id=12052]

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0818]

[Xref => http://www.securityfocus.com/bid/9635]

[Xref => http://www.securityfocus.com/bid/9633]

As últimas linhas deste alerta mostram referências para locais onde se pode encontrar

mais informação sobre o alerta gerado. O ficheiro “reference.config” tem um papel

importante pois contém o URL para alcançar as referências pretendidas. Por exemplo,

as seguintes linhas do ficheiro “reference.config” definem os URLs referentes ao

CVE, ao Bugtraq e ao Nessus.

config reference: cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=



53

config reference: bugtraq http://www.securityfocus.com/bid/

config reference: nessus http://cgi.nessus.org/plugins/dump.php3?id=

Assim, quando se escrevem regras apenas é necessário definir as referências do

seguinte modo: reference:bugtraq,9633;, reference:bugtraq,9635;,

reference:cve,2003-0818;, reference:nessus,12052;,

reference:nessus,12065;.

Quando são gerados alertas os plugins de saída verificam qual o URL definido no

“reference.config” da entidade à qual se refere a palavra-chave “reference” e

acrescentam a esse URL o id referido no campo “reference”.

Exemplo:

Referencia definida na regra: reference:cve,2003-0818

Ficheiro “reference.config”:

config reference: cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=

Logo, o URL completo será:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0818

Este mecanismo permite reduzir o tamanho dos ficheiros das regras uma vez que, os

URLs não são constantemente repetidos. Poderão se especificados URLs completos

no “reference”.

Podem ser colocadas várias referências numa só regra. As referências também são

usadas por ferramentas como o BASE (Figura 23) para fornecer informação adicional

sobre uma vulnerabilidade particular.



54

Figura 23 – Referências no BASE

• SID

Esta palavra-chave é usada para adicionar um identificador do Snort às regras. Os

módulos de output ou scanners de logs podem usar o SID para identificar as regras.

Os autores reservaram os SIDs para as regras da seguinte forma:

• 0-99 – Reservada para uso futuro.

• 100-1000000 – Reservada para regras que venham com uma distribuição do

Snort.

• Todos os valores acima de 1000000 podem ser usados para regras criadas pelo

utilizador.

O único argumento desta palavra-chave é um número. A seguinte regra adiciona o

SID 1000001.

alert ip any any -> any any (ipopts: lsrr; msg: "Loose source

routing attempt"; sid: 1000001;)

Ao usar-se os SIDs as ferramentas como o BASE podem mostrar a regra que gerou

determinado alerta.



55

• REV

Esta palavra-chave é adicionada às opções das regras do Snort para mostrar o número

da revisão da regra. Quando se actualizam regras, pode-se usar esta palavra-chave

para distinguir as diferentes revisões. Os módulos de output também podem utilizar

este número para identificar a revisão. A seguinte regra mostra que a revisão é a 2:

alert ip any any -> any any \

(ipopts: lsrr; msg: "Loose routing attempt"; rev: 2;)

• PRIORITY

Esta palavra-chave atribui uma determinada prioridade a uma regra. A prioridade é

um argumento numérico para esta palavra-chave. O número 1 é a prioridade mais alta.

Esta palavra-chave é geralmente combinada com a palavra-chave “classtype”. A regra

seguinte tem prioridade 10:

alert ip any any -> any any \

(ipopts: lsrr; msg: "Loose source routing attempt"; \

priority: 10;)

Esta palavra-chave pode ser usada para diferenciar alertas de alta e baixa prioridade.

• CLASSTYPE

Pode-se atribuir classificações e prioridades às regras para as agrupar e distinguir.

Para se perceber esta palavra-chave convém rever o ficheiro “classification.config”

que está incluído no ficheiro “snort.conf” através da palavra-chave “include”. Cada

linha do ficheiro “classification.config” tem a seguinte sintaxe:

config classification: name,description,priority

O campo “name” contém o nome usado para a classificação. O nome é usado com a

palavra-chave “classtype” nas regras do Snort. No campo “description” tem-se uma

pequena descrição do tipo de classe. O campo prioridade é um número que mostra a

prioridade da classificação que pode ser modificada usando a palavra-chave “priority”

dentro das opções da regra. Pode-se também colocar estas linhas no ficheiro

“snort.conf”. Um exemplo deste parâmetro de configuração seria o seguinte:



56

config classification: DoS,Denial of Service Attack,2

Na linha anterior a classificação é DoS e a prioridade é 2. A seguinte regra usa a

prioridade por omissão com a classificação DoS:

alert udp any any -> 192.168.1.0/24 6838 (msg:"DoS"; \

content: "server"; classtype:DoS;)

A próxima regra é semelhante, apenas sofre a alteração da prioridade por omissão

para esta classificação:

alert udp any any -> 192.168.1.0/24 6838 (msg:"DoS"; \

content: "server"; classtype:DoS; priority:1)

Ao usar-se classificações e prioridades para regras e alertas pode-se distinguir entre

alertas de alto, médio e baixo risco, podem ser definidos mais níveis pelo

administrador. Esta capacidade é muito útil para se dar prioridade aos ataques de alto

risco.

A Tabela 2, Tabela 3 e Tabela 4 mostram os tipos de classes padrões, descrição e suas

prioridades.

Tipo de classe Descrição Prioridade

attempted-admin Tentativa de obtenção do privilégio de administrador Alta (1)

attempted-user Tentativa de obtenção do privilégio de utilizador Alta (1)

shellcode-detect Código executável detectado Alta (1)

successful-admin Sucesso na obtenção do privilégio de administrador Alta (1)

successful-user Sucesso na obtenção do privilégio de utilizador Alta (1)

trojan-activity Trojan detectado Alta (1)

unsuccessful-user Insucesso na obtenção do privilégio de utilizador Alta (1)

web-application-attack Ataque a uma aplicação Web Alta (1)

Tabela 2 – Alertas de alto risco, prioridade 1



57

Tipo de classe Descrição Prioridade attempted-dos Tentativa de DoS Média (2)

attempted-recon Tentativa de reconhecimento Média (2) bad-unknown Tráfego potencialmente perigoso Média (2)

denial-of-service Detecção de Ataque de Negação de Serviço Média (2) misc-attack Ataques diversos Média (2)

non-standard-protocol Detecção de um protocolo ou evento não padrão Média (2)

rpc-portmap-decode Descodificação de uma pesquisa RPC Média (2) successful-dos Ataque de DoS bem sucedido Média (2)

successful-recon-largescale Falha em larga escala de informação Média (2)

successful-recon-limited Falha na informação Média (2) suspicious-filename-

detect Nome de ficheiro suspeito Média (2)

suspicious-login Tentativa de login usando um nome suspeito Média (2)

system-call-detect Chamada a um sistema Média (2) unusual-client-port-

connection Ligação a um porto estranho por parte de um utilizador Média (2)

web-application-activity Vulnerabilidade de uma aplicação Web Média (2)

Tabela 3 – Alertas de médio risco, prioridade 2

Tipo de classe Descrição Prioridade icmp-event Evento genérico ICMP Baixa (3)

misc-activity Actividades diversas Baixa (3) network-scan Detecção de um port scan Baixa (3) not-suspicious Tráfego não suspeito Baixa (3)

protocol-command-decode

Descodificação de comandos relativos a protocolos Baixa (3)

string-detect String suspeita Baixa (3) unknown Tráfego desconhecido Baixa (3)

Tabela 4 – Alertas de baixo risco, prioridade 3

4.3.2.2 Payload Detection

As opções referentes ao payload detection são as mais poderosas e importantes uma

vez que se referem exclusivamente aos dados que viajam dentro dos pacotes

capturados, permitindo que os ataques sejam facilmente detectados. Seguidamente são

apresentados vários exemplos de palavras-chave.



58

• CONTENT

Uma das capacidades importantes do Snort é o facto de conseguir encontrar um

padrão de dados dentro de um pacote. O padrão pode ser apresentado na forma de

string ASCII ou como dados binários na forma de caracteres hexadecimais. Como os

vírus, as intrusões também têm assinaturas e esta palavra-chave serve para encontrar

estas últimas dentro dos pacotes.

A seguinte regra detecta o padrão "GET" na parte dos dados de todos os pacotes TCP

que estão a sair da rede com o endereço 192.168.1.0 e que têm como destino um

endereço que não faça parte desta rede. A palavra-chave GET é muitas vezes usada

em ataques relacionados com HTTP, no entanto, esta regra apenas serve para explicar

o funcionamento desta palavra-chave.

alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any \

(content: "GET"; msg: "GET matched";)

A seguinte regra tem o mesmo efeito mas para um padrão hexadecimal.

alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any \

(content: "|47 45 54|"; msg: "GET matched";)

Também se pode utilizar ambos os padrões, em ASCII e hexadecimal dentro da

mesma regra. De notar, que os caracteres hexadecimais têm de estar entre barras

direitas, exemplo: "|47 45 54|".

Ao usar-se esta palavra-chave é preciso ter em atenção:

• A comparação de conteúdos é um processo dispendioso a nível computacional

e deve-se ter cuidados em não abusar nas regras que a utilizam.

• Ao fornecer conteúdo em formato de string ASCII deve-se sempre escapar as

aspas, dois pontos e símbolos das barras.

• Pode-se utilizar várias palavras-chave de conteúdo numa só regra para

descobrir assinaturas no pacote de dados.

• A comparação de conteúdos é sensível a maiúsculas.



59

Existem outras três palavras-chave a ser usadas com o “content”, estas trazem

critérios adicionais de detecção de padrões dentro de um pacote. Sendo elas:

• offset e depth – Restringe a pesquisa em determinada parte do pacote de

dados

• nocase – Torna a pesquisa não sensível a maiúsculas

4.3.2.3 Non-Payload Detection

Além das opções específicas para a região de dados dos protocolos, há opções

específicas para os protocolos suportados pelo Snort. Estas opções dizem respeito a

parâmetros presentes na região do cabeçalho dos protocolos. Essas opções fortalecem

as regras à medida que melhoram o desempenho de detecção de pacotes capturados.

a) IP

• ipopts – As opções de IP são importantes na identificação de numerosos tipos

de ataques baseados em IP. Muitas das opções de IP são usadas na escrita de

regras para identificar ataques de dispositivos de rede, tentativas de mapear

uma rede e ataques de DoS baseados neste protocolo.

O formato destas opções IP é a seguinte:

ipopts:<rr|eol|nop|ts|sec|lsrr|ssrr|satid|any>;

Em que:

rr – Record route (Registar rota)

eol – End of list (Fim da lista)

nop – No option (Sem opção)

ts – Time Stamp (Carimbo temporal)

sec – IP security option (Opção segurança IP)

lsrr – Loose source routing (Encaminhamento pouco rigido definido pela

origem)

ssrr – Strict source routing (Encaminhamento rigido definido pela origem)

satid – Stream identifier (Identificador de stream)

any – any IP options are set (Quaisquer opções de IP que estejam definidas)

Apenas pode ser utilizada uma “ipopts” por regra.



60

• fragbits – A palavra-chave “fragbits” serve para verificar os bits MF (More

Fragments), DF (Don`t Fragment) e RB (Reserved Bits) do cabeçalho IP. O

formato desta opção é a seguinte:

fragbits: [+*!]<[MDR]>;

Em que:

M – Verifica o bit MF (More Fragments) do cabeçalho.

D – Verifica o bit DF (Don`t fragment).

R – Verifica o bit RB (Reserved Bit).

+ – Equivalente ao operador lógico E (AND).

* – Equivalente ao operador lógico OU (OR)

! – Operador negação

• fragoffset – Permite comparar o campo fragment offset do cabeçalho IP com

um valor decimal. O formato desta opção é o seguinte: fragoffset:[<|>]<number>

• ttl – Permite verificar o campo ttl (time-to-live). O formato desta opção é o seguinte:

ttl:[[<number>-]><=]<number>;

b) ICMP

• icmp_id – Permite comparar o "id" presente no cabeçalho de um pacote ICMP

com um valor decimal. O formato desta opção é o seguinte:

icmp_id: <ICMP_id_number>

• icmp_seq – Permite comparar o número de sequência presente no cabeçalho

de um pacote ICMP com um valor decimal. O formato desta opção é o

seguinte:

icmp_seq: <ICMP_seq_number>



61

• itype – A opção “itype” examina o valor do campo ICMP type presente no

cabeçalho ICMP. Esta opção serve para identificar o tipo de pacote ICMP. O

formato desta opção é o seguinte:

itype: "ICMP_type_number"

A Tabela 5 ilustra os valores possíveis para este campo.

Valor do campo tipo de ICMP Descrição

0 Echo Reply

3 Destination Unreachable

4 Source Quench

5 Redirect

8 Echo request

11 Time exceed

12 Parameter problem

13 Timestamp request

14 Timestamp reply

15 Information request

16 Information reply

Tabela 5 – Tipos de ICMPs e seus valores

• icode – A opção “icode” examina o valor do campo code presente no

cabeçalho ICMP. O campo code fornece informação detalhada sobre o tipo de

pacote ICMP que estamos a receber. O formato desta opção é o seguinte:

icode: "ICMP_codee_number"

Deverá ser consultada a “RFC 792” para obter mais informação sobre o

significado dos códigos referentes a pacotes ICMP.

c) TCP

• seq – A palavra-chave “seq” é usada para testar o número de sequência de um

pacote TCP. O argumento desta palavra-chave é um número de sequência. O

formato genérico é o que se segue:



62

seq: "sequence_number";

Os números de sequência são parte do cabeçalho TCP.

• ack – O protocolo TCP contém um campo com o número de

acknowledgement de 32 bits. Este campo mostra o próximo número de

sequência que o transmissor do pacote TCP está à espera de receber. Este

campo apenas é significativo quando a flag ACK está activa no cabeçalho

TCP.

Ferramentas como o Nmap (http://www.nmap.org) usam esta capacidade do

cabeçalho TCP para fazer “ping” a uma máquina. Por exemplo, e entre outras

técnicas usadas pelo Nmap, ele pode enviar um pacote TCP para o porto 80

com a flag ACK activa e o número de sequência a 0. Como o pacote não é

aceite pelo receptor, e não está de acordo com as regras do TCP, este responde

com um pacote RST. Quando o Nmap recebe o pacote RST, fica a saber que o

terminal está "vivo". Este método funciona bem para terminais que não

respondam a pedidos “ping” do tipo ICMP ECHO REQUEST.

Para detectar este tipo de “ping” TCP pode-se usar uma regra semelhante á

seguinte que vai enviar uma mensagem de alerta:

alert tcp any any -> 192.168.1.0/24 any (flags: A; \

ack: 0; msg: "TCP ping detected";)

Esta regra gera uma mensagem de alerta quando se recebe um pacote com a

flag ACK activa e com o número de acknowledgement com o valor 0. O

destino deste pacote terá que ser um terminal na rede 192.168.1.0/24. Pode-se

usar qualquer valor com a palavra-chave ACK numa regra, no entanto apenas

é adicionado para detectar este tipo de ataque. Geralmente se a flag ACK está

activa o valor de acknowledgement não é zero.

http://www.nmap.org/



63

• flow – Esta palavra-chave é usada para aplicar regras a sessões TCP de

pacotes a fluir numa determinada direcção. Pode-se usar opções com esta

palavra-chave para determinar a direcção. As seguintes opções podem ser

usadas:

• to_client

• to_server

• from_client

• from_server

As opções começadas por "to" são usadas para respostas e as começadas por

"from" para pedidos.

Existem outras opções que servem para se aplicar a regra a diferentes estados da

ligação TCP:

• A opção “stateless” é usada para aplicar a regra sem considerar o estado da

sessão TCP.

• A opção “established” é usada para aplicar a regra apenas a sessões TCP já

estabelecidas.

• A opção “no_strem” activa regras que vão ser aplicadas a pacotes que não

façam parte de uma stream.

• A opção “stream_only” é usada para aplicar as regras apenas aos pacotes

que fazem parte de uma stream.

As streams TCP são geridas pelo pré-processador stream4.

• flags – Esta palavra-chave é usada para descobrir que flag bits estão activos

dentro do cabeçalho TCP de cada pacote. Cada flag pode ser usada como

argumento da palavra-chave “flags” nas regras do Snort. Estes flag bit são

usados para várias ferramentas de segurança como por exemplo o Nmap

(http://www.nmap.org). O Snort suporta a verificação das flags listadas na

Tabela 6:




64

Flag Caracter/Argumento

FIN ou Flag de Finalização F

SYN ou Flag de Sincronismo S

RST ou Flag de Reset R

PSH ou Flag de Push P

ACK ou Flag de Acknowledge A

URG ou Flag de Urgente U

Bit reservado 1 1

Bit reservado 2 2

Nenhuma Flag activa 0

Tabela 6 – Flags do cabeçalho TCP

Também se pode usar os símbolos: !, +, e * como nos flag bits do cabeçalho IP

para as operações lógicas AND, OR e NOT sobre os flag bits a serem testados.

A seguinte regra detecta qualquer tentativa de scan a usar pacotes TCP SYN-

FIN:

alert tcp any any -> 192.168.1.0/24 any (flags: SF; \

msg: “SYNC-FIN packet detected”;)

d) UDP

• rpc – Esta palavra-chave é usada para detectar pedidos baseados em RPC.

Aceita três números como argumentos:

• Numero da aplicação

• Número de procedimento

• Número da versão

Estes argumentos são separados por uma vírgula. Também se pode utilizar um

asterisco para comparar todos os números numa localização particular dos



65

argumentos. A seguinte regra detecta pedidos RPC para o número TPC 1000,

para todos os procedimentos e versão número 3:

alert ip any any -> 192.168.1.0/24 any (rpc: 10000,*,3; \

msg: "RPC request to local network";)

4.3.2.4 Post Detection

• logto – Esta palavra-chave diz ao Snort para registar, num ficheiro especial de

logs, todos os pacotes que façam disparar a respectiva regra. É especialmente

útil para combinar dados vindos de actividade Nmap, scans CGI HTTP, etc.

De notar que esta opção não funciona quando o Snort está em modo de registo

binário. O formato de uso é o seguinte:

logto:"filename";

• session – Esta palavra-chave é usada para extrair dados do utilizador de uma

sessão TCP. Existem vários casos em que analisar os dados introduzidos pelos

utilizadores em sessões Telnet, rlogin, FTP ou Web se torna muito útil para

detectar ataques.

Existem dois argumentos possíveis, “printable” e “all”. O primeiro imprime

apenas os dados que o utilizador veria normalmente ou seria capaz de

introduzir. O segundo substitui os caracteres não imprimiveis nos seus

equivalentes hexadecimais.

O exemplo seguinte regista todas as string imprimiveis de um pacote telnet:

log tcp any any <> any 23 (session:printable;)

De referir que esta palavra-chave pode tornar o Snort muito lento, logo não

deve ser usada em situações de carga elevada.

• resp – Esta palavra-chave é usada para tentar fechar sessões quando um alerta

é gerado. No Snort isto é chamado de resposta flexível.

A resposta flexível suporta os seguintes mecanismos para tentar fechar

sessões:



66

Opção Descrição

rst_snd Envia pacotes TCP-RST para o socket emissor

rst_rcv Envia pacotes TCP-RST para o socket transmissor

rst_all Envia pacotes TCP-RST em ambas as direcções

icmp_net Envia um ICMP_NET_UNREACH para o emissor

icmp_host Envia um ICMP_HOST_UNREACH para o emissor

icmp_port Envia um ICMP_PORT_UNREACH para o emissor

icmp_all Envia todos os pacotes ICMP referidos em cima para o emissor

Tabela 7 – Opções da palavra-chave resp

Estas opções podem ser combinadas para enviar várias respostas para o

terminal alvo.

Seguindo o formato “resp”:

<resp_mechanism>[,<resp_mechanism>[,<resp_mechanism>]];

Pode-se elaborar regras como a seguinte que é uma tentativa de fechar

qualquer ligação TCP ao porto 1524:

alert tcp any any -> any 1524 (flags:S; resp:rst_all;)

De referir que é preciso ter atenção em não criar regras que coloquem o Snort

em loop infinito ao definir uma regra como a seguinte:

alert tcp any any -> any any (resp:rst_all;)

• react – Esta palavra-chave, baseada em resposta flexiva, implementa reacção

ao tráfego que activa uma regra do Snort. A reacção básica é bloquear sites

interessantes que os utilizadores queiram utilizar. A Flex Resp (resposta

flexível) permite ao Snort fechar activamente a ligação e/ou enviar uma

notificação visível no browser. Nesta notificação pode ser colocado o que se

pretender. Os seguintes argumentos são válidos para esta opção:

• block – fecha a ligação e envia a notificação visível.

• warn – envia a notificação (ainda não disponível)



67

Os argumentos básicos podem ser combinados com os seguintes:

• msg – inclui o texto da opção “msg” na notificação.

• proxy: <port_nr> – usa o porto do proxy para enviar a notificação.

Os diversos argumentos são separados por uma vírgula. A palavra-chave

“react” deve ser colocada no fim da lista de opções. O seu formato é o

seguinte:

react: \

<react_basic_modifier[, react_additional_modifier]>;

De referir que esta capacidade não está activa por omissão.

• tag – A palavra-chave “tag” permite às regras registarem mais do que o

simples pacote que as activou. Assim que uma regra é activada, o tráfego

adicional que envolve os terminais de origem e/ou o destino é marcado. O

tráfego marcado é registado para permitir uma análise dos códigos de resposta

e tráfego pós ataque. Os alertas marcados serão enviados para o mesmo plugin

de saída que o alerta original, mas é da responsabilidade do plugin gerir

convenientemente estes alertas especiais. O formato de uso é o seguinte:

tag: <type>, <count>, <metric>, [direction]

type

• session – regista pacotes da sessão que disparou a regra.

• host – regista pacotes do terminal que causou o disparo da regra.

count – especificado como o número de unidades. As unidades são

especificadas no campo <metric>.

metric

• packets – marca o terminal/sessão durante <count> pacotes.

• seconds – marca o terminal/sessão durante <count> segundos.

Aqui fica um exemplo de uma regra que regista os primeiros 10 segundos de

qualquer sessão telnet:



68

alert tcp any any -> any 23 \

(flags:s,12; tag:session,10,seconds;)

4.3.3 Exemplo

Para melhor compreensão é apresentada uma regra que se encontra no ficheiro

“icmp.rules”:

alert icmp $EXTERNAL_NET any -> $HOME_NET any \

(msg:"ICMP PING NMAP"; dsize:0; itype:8; reference:arachnids,162;\

classtype:attempted-recon; sid:469; rev:4;)

Em suma a regra vai actuar sobre pacotes ICMP provenientes da rede externa e que

tenham como destino a rede interna, independentemente do porto. Este padrão de

actuação pertence aos PING ICMP efectuados pelo Nmap, como demonstra a

mensagem a ser registada. Este pacote terá tamanho de dados zero e é do tipo de

ICMP 8, ou seja, Echo Request. Está definida uma referência para

http://www.whitehats.com/info/IDS162. É dada a classificação de tentativa de

reconhecimento com o ID do Snort número 469. Esta é a quarta revisão da regra.

As expressões têm o seguinte significado:

• alert – Faz o log do evento e alerta o utilizador da forma que estiver

configurada no ficheiro “snort.conf”

• icmp – Apenas relativo a tráfego ICMP

• $EXTERNAL_NET – Rede definida como externa no ficheiro de configuração

“snort.conf”

• any – De qualquer porto

• -> - Na direcção da esquerda para a direita, o que significa que a origem é a

rede considerada externa

• $HOME_NET – Rede definida como interna no ficheiro de configuração

“snort.conf”

• any – Para qualquer porto

• msg:"ICMP PING NMAP" – Regista a mensagem “ICMP PING NMAP”

http://www.whitehats.com/info/IDS162



69

• dsize:0 - Tamanho de dados igual a zero

• itype:8 - ICMP do tipo 8 (Echo Request)

• reference:arachnids,162 - Referência para o site

http://www.whitehats.com/info/IDS162/

• classtype:attempted-recon - Classifica a regra como tentativa de

reconhecimento

• sid:469 - Snort ID 469

• rev:4 - Revisão 4 da regra

4.3.4 Conclusão Final sobre as Regras

As regras são uma das partes mais importantes do Snort, pois são elas que definem as

assinaturas que o mecanismo de detecção utiliza para detectar ataques. O site do Snort

tem actualizações frequentes das regras (http://www.snort.org/rules/) visto estarem

constantemente a aparecer novos perigos e problemas.

A vasta qualidade de opções disponíveis permite que o administrador de rede tenha

um controlo amplo sobre o Snort e o seu funcionamento.

http://www.whitehats.com/info/IDS162/

http://www.snort.org/rules/



70

5 Testes

5.1 Cenário de Testes

Na Figura 24 está representado o cenário de testes utilizado no estudo do Snort. Nele,

estão representadas as máquinas que o compõem bem como os respectivos endereços

IP e sistemas operativos, na Tabela 8 encontra-se a descrição do hardware e software

relevante de cada máquina. De notar, que o equipamento utilizado para interligar as

diversas máquinas foi um hub (Cisco 1538 M), isto porque replica o tráfego

proveniente de uma porta por todas as outras, chegando assim ao Snort todos os dados

transmitidos pelos outros equipamentos. Actualmente o equipamento eleito para

desempenhar esta função é o switch, este aumenta o desempenho da rede uma vez que

a ocorrência de erros/colisões é menor, mas a implementação de IDS em redes

comutadas pode apresentar alguns problemas porque, ao contrário do hub, o switch

envia os dados provenientes da origem apenas para a porta onde se encontra ligada o

dispositivo de destino, não replicando assim os dados por todas as outras como o hub.

Logo, se neste cenário fosse utilizado um switch em vez de um hub, nunca poderia ser

monitorizado todo o tráfego de rede, mas sim apenas o tráfego destinado à máquina

onde se encontra instalado o IDS. Este problema poderia ser resolvido com um switch

que contenha uma porta do tipo Port Spam, para onde é enviado todo o tráfego

proveniente das demais portas.

Figura 24 – Cenário de testes



71

Máquina Hardware Software

CPU: Intel P4 3.0 GHz

RAM: 512 MB

Disco: 80 GB

Placa Rede: Intel PRO/1000 CT

Ubuntu 5.10

Snort 2.4.4 + BASE 1.2.4

Apache 2.0.54

PHP 5.0.5

MySQL 4.0.24

CPU: Intel P3 1100 MHz

RAM: 1 GB

Disco: 80 GB

Placa Rede: Marvell Yukon

88E8036

Windows XP SP2


RAM: 256 MB

Disco: 4 GB

Placa Rede: 3Com Corporation

3c905C

Ubuntu 5.10


RAM: 1 GB

Disco: 80 GB

Placa Rede: Marvell Yukon

88E8036

Windows Server 2003


RAM: 368 MB

Disco: 20 GB

Placa Rede: SiS 900

FastEthernet

BackTrack v.1.0

Nessus Server 3.0.3

Nessus Client 1.0.0 RC5

Tabela 8 – Descrição do Hardware e Software das máquinas utilizadas nos testes



72

Como já foi referido, foi utilizado o BASE como frontend para consultar a base de

dados MySQL, onde ficam guardados os alertas. O seu aspecto normal, sem alertas

gerados, é ilustrado na Figura 25.

Figura 25 – BASE sem alertas

5.2 Regra Simples

Foram criadas sete regras simples e incluídas no ficheiro “badwords.rules” com o

objectivo de encontrar as palavras: “hack”, “back orifice”, “crack”, “vírus”, “atack”,

“trojan” e “rootkit”, que circulem pela rede em plain text. As regras criadas

encontram-se no Anexo 2.

5.2.1 Transferência de Ficheiro de Texto

Foi transferido pela rede o ficheiro “test.txt” da máquina WindowsXP para a máquina

BackTrack, como demonstrado na Figura 26. O ficheiro “test.txt” encontra-se no

Anexo 3.

BackTrack v.1.0192.168.232.93

Windows XP192.168.232.90

test.txt

Figura 26 – Transferência do ficheiro test.txt



73

Na Figura 27 encontram-se os alertas gerados após a transferência do ficheiro estar

completa.

Figura 27 – Alertas gerados após transferência do ficheiro de texto

Síntese do Teste Numero do teste: 1 Data: 17-08-2006

Versão do Snort: 2.4.4 Data das Regras: 09-08-2006

Objectivos

Verificar o funcionamento das regras bem como do mecanismo de

detecção.

Testar a capacidade do Snort detectar palavras que circulem na

rede em ficheiros que contêm texto não cifrado.

Passos a executar

Iniciar o sensor.

Transferir o ficheiro da máquina WindowsXP para a máquina

BackTrack através do acesso a uma pasta partilhada.

Parar o sensor.

Verificar os alertas gerados com o auxílio do BASE.

Resultado Esperado Alertas para as palavras “trojan” e “hack” uma vez que, se

encontram no ficheiro de texto a transferir.

Resultado Obtido 1 Alerta para a palavra “trojan”.

1 Alerta para a palavra “hack”.

Conclusão

O Snort consegue detectar que o payload de um pacote viola mais

do que uma regra e despoleta os respectivos alertas. Ao verificar

que uma regra foi violada mais do que uma vez no mesmo payload

apenas gera um alerta.

Tabela 9 – Teste 1



74

5.2.2 Transferência de Ficheiro de Texto Comprimido

Foi transferido pela rede o ficheiro “test.rar” da máquina WindowsXP para a máquina

BackTrack, como demonstra a Figura 28.

Figura 28 – Transferência do ficheiro test.rar

Windows XP

192.168.232.90BackTrack v.1.0192.168.232.93

test.rar



Objectivos

Verificar o funcionamento das regras bem como do mecanismo de

detecção.

Testar a capacidade do Snort detectar palavras que circulem na

rede em ficheiros compactados.

Passos a executar

Iniciar o sensor.

Copiar o ficheiro da máquina WindowsXP para a máquina

BackTrack através do acesso a uma pasta partilhada.

Parar o sensor.


Resultado Esperado Alertas para as palavras “trojan” e “hack” uma vez que, fazem parte

do conteúdo do ficheiro de texto que se encontra compactado.

Resultado Obtido Não foram gerados alertas.

Conclusão Os ficheiros compactados bem como os dados cifrados são uma

grande limitação para os IDS de rede. No entanto, nos IDS de

terminal não se encontra esta limitação.




75

5.3 Nmap

O Nmap é uma ferramenta de scan de portos distribuída pela “Insecure.Org”. Os seus

objectivos são: detectar portos abertos num terminal alvo; determinar quais os

serviços que estão a correr nesses mesmos portos e inferir sobre qual o sistema

operativo a correr no computador (também denominado de fingerprinting). Tornou-se

assim numa das ferramentas cruciais em qualquer toolbox (conjunto de ferramentas)

de um administrador de rede, sendo usado para testes de penetração e segurança em

geral.

As capacidades do Nmap são:

• Descobrir terminais numa rede – Por exemplo, com a detecção de máquinas

que respondam a pings ou que tenham determinados portos abertos.

• Scan de portos – Enumeração dos portos abertos num ou em mais terminais

alvo.

• Detecção de versão de serviços – Interrogação dos serviços de rede em escuta

nos terminais remotos para determinar o nome da aplicação e o número da

versão.

• Detecção de SO – Determinar remotamente o sistema operativo e algumas

características de hardware dos terminais de rede.

O Nmap é frequentemente usado para:

• Realizar auditorias à segurança de um computador, fazendo a identificação das

ligações de rede que podem ser estabelecidas com o mesmo.

• Identificar portos num determinado computador de forma a preparar um

ataque (hacking).

• Fazer um inventário, manutenção e gestão de bens/recursos da rede.

• Realizar auditorias à segurança da rede, com a detecção de serviços

inesperados.

De seguida são apresentados os testes executados com esta ferramenta.



76

5.3.1 Nmap SYN Stealth Scan

Esta técnica permite descobrir portos abertos através do envio de pacotes com a flag

SYN activa para os demais portos, como se tratasse de um estabelecimento de ligação.

Caso a resposta ao pacote SYN seja um pacote com a flag RST activa conclui-se que

a máquina alvo não está a aceitar ligações naquele porto, se a resposta for um pacote

com as flags SYN e ACK activas é enviado um pacote RST para terminar a ligação e

conclui-se que a máquina está a aceitar ligações naquele porto. Para o Nmap construir

estes pacotes para envio é necessário o utilizador ter os privilégios de root.

Como mostra a Figura 29, a máquina BackTrack utiliza o Nmap para identificar se os

seguintes portos da máquina WindowsXP se encontram á escuta: 22 (SSH), 23

(Telnet), 80 (HTTP), 110 (Post Office Protocol - Version 3), 139 (Netbios Session

Service), 443 (HTTPS), 3306 (MySQL), 5900 (VNC) ou 8080 (HTTP-Alt).

Para se obter o efeito pretendido tendo em conta a técnica SYN Stealth, foi utilizado o

seguinte comando:

nmap -sS -p 22,23,80,110,139,443,3306,5900,8080 -P0 192.168.232.90

Parâmetros:

-sS – Técnica de scan TCP SYN Stealth

-p – Portos pretendidos

-P0 – Não envia pacotes ICMP ao terminal

192.168.232.90 – Endereço IP do alvo



77

Windows XP192.168.232.90

BackTrack v.1.0192.168.232.93

Nmap SYN Stealth Scan

Figura 29 – Nmap SYN Stealth Scan

A Figura 30 demonstra o estado dos portos analisados:

Figura 30 – Resultado do Nmap

A Figura 31 demonstra a estatística dos alertas registados pelo Snort:

Figura 31 – Estatística dos alertas



78

Ao seleccionar o total de alertas obtém-se a listagem dos mesmos:

Figura 32 – Listagem dos alertas



Objectivos Verificar a capacidade de detecção do Snort a um scan SYN

Stealth a portos bem conhecidos.

Passos a executar

Iniciar o sensor.

Executar o Nmap para o scan aos seguintes portos: 22, 23, 80,

110, 139, 443, 3306, 5900 e 8080.

Parar o sensor.


Resultado Esperado Detecção positiva do scan a todos os portos referidos.

Registo dos endereços IP de origem e destino do scan.

Resultado Obtido Detecção do menor e maior porto alvo do scan e de todos os

portos que se encontravam abertos.


Conclusão

O Snort apenas teve a capacidade de detectar o intervalo do scan

(porto menor e maior – 22:8080), ou seja, não gera alertas para

todos os portos alvo como por exemplo o porto 3306 referente ao

servidor MySQL.

Detectou ainda o fecho da ligação (RST) nas situações em que o

porto se encontrava aberto e respondeu ao pedido de ligação.

Conseguiu registar correctamente o endereço IP de origem e

destino do scan.


5.3.2 Nmap SYN Stealth Scan com IP Spoofing

Neste teste é utilizada a mesma técnica de scan do que no anterior bem como os

portos alvo, no entanto é adicionado IP Spoofing. Como demonstra a Figura 33 a

máquina BackTrack envia os pacotes SYN com o endereço IP origem da máquina

Windows 2003 fazendo-se passar por esta.



79

Para se obter o efeito pretendido tendo em conta a técnica SYN Stealth, foi utilizado o

seguinte comando:

nmap -sS -p 22,23,80,110,139,443,3306,5900,8080 -P0 -e eth0 -S

192.168.232.92 -g 666 192.168.232.90

Parâmetros:

-sS – Técnica de scan TCP SYN Stealth



-e – Interface de rede

-S – Endereço IP origem pretendido

-g – Porto Origem


Figura 33 – Nmap SYN Stealth Scan com IP Spoofing



80









81



Objectivos Verificar a capacidade de detecção do Snort a um scan SYN

Stealth em que foi utilizada a técnica IP spoofing para esconder o

verdadeiro endereço IP da máquina BackTrack.

Passos a executar

Iniciar o sensor.

Executar o Nmap para o scan aos seguintes portos:

22, 23, 80, 110, 139, 443, 3306, 5900 e 8080 e indicando qual o

endereço IP e porto origem a incluir nos pacotes que são enviados.

Parar o sensor.



Detecção da utilização de IP spoofing alertando para tal facto.


Resultado Obtido Detecção do menor e maior porto alvo do scan e de todos os

portos que se encontravam abertos.


Conclusão Tal como no teste 3 o Snort teve a capacidade de detectar o port

scan, mas não teve a capacidade de detectar o IP spoofing.


5.3.3 Nmap FIN Stealth Scan

Um pacote com a flag FIN activa serve para terminar uma ligação. Se a porta para

onde foi enviado o FIN, estiver aberta, não existe resposta ao FIN, se estiver fechada a

resposta dada pelo sistema operativo será um RST. De referir, no caso dos sistemas

operativos Windows este tipo de scan não produz resultados conclusivos uma vez que

em ambos os casos o sistema operativo não retorna qualquer resposta.

Esta técnica de scan viola o protocolo TCP uma vez que envia pacotes que não são

esperados quando se tenta iniciar uma ligação.

Como mostra a Figura 37, a máquina BackTrack utiliza o Nmap para identificar se os

seguintes portos da máquina Ubuntu se encontram á escuta: 22 (SSH), 23 (Telnet), 80

(HTTP), 110 (Post Office Protocol - Version 3), 139 (Netbios Session Service), 443

(HTTPS), 3306 (MySQL), 5900 (VNC) ou 8080 (HTTP-Alt).



82

Para se obter o efeito pretendido tendo em conta a técnica FIN Stealth, foi utilizado o

seguinte comando:

nmap -sF -p 22,23,80,110,139,443,3306,5900,8080 -P0 192.168.232.91

Parâmetros:

-sF – Técnica de scan TCP FIN Stealth




FIN Stealth Scan

Figura 37 – Nmap FIN Stealth Scan



83









84



Objectivos Verificar a capacidade de detecção do Snort a um scan FIN Stealth

a portos bem conhecidos.

Passos a executar

Iniciar o sensor.

Executar o Nmap para o scan aos seguintes portos: 22, 23, 80,

110, 139, 443, 3306, 5900 e 8080.

Parar o sensor.




Resultado Obtido Detecção do menor e maior porto alvo do scan.

Alerta para todos os portos que foram alvo do scan.


Conclusão

Ao contrário do teste 3 referente ao SYN scan, neste teste o Snort

teve capacidade de alertar individualmente quais os portos alvo de

um scan.

Conseguiu registar correctamente o endereço IP de origem e

destino do scan.


5.4 Nessus

O Nessus é uma ferramenta desenvolvida para automatizar o teste e descoberta de

diversos problemas de segurança já conhecidos. Tipicamente é alguém, um grupo de

hackers, uma companhia de segurança, ou um investigador, que descobre um meio

específico de violar a segurança de um determinado produto de software. A

descoberta pode ser acidental ou através de pesquisa directa; a vulnerabilidade, em

vários níveis de detalhe, é então lançada para a comunidade de segurança. O Nessus

foi desenvolvido para ajudar a identificar e resolver estes problemas já conhecidos,

antes que um hacker possa tirar partido dos mesmos. O Nessus é uma excelente

ferramenta que possui imensas capacidades.

Uma das várias vantagens do Nessus é ser uma aplicação cliente/servidor. Os

servidores podem ser colocados em vários pontos estratégicos da rede permitindo a

execução de testes de vários pontos de vista. Todos os servidores podem ser



85

controlados por um cliente central ou vários clientes distribuídos. O servidor pode

correr em quase todas as variantes de Unix. Até corre em MAC OS X e IBM/AIX,

mas o Linux é onde a instalação é mais simples. Estas capacidades oferecem uma

enorme flexibilidade para o teste de penetração. Os clientes por sua vez estão

disponíveis quer para Windows quer para Unix. O servidor do Nessus executa o teste,

enquanto que o cliente fornece a configuração e as funcionalidades de relatório.

A base de dados de vulnerabilidades do Nessus é actualizada diariamente. No entanto,

devido á modularidade do Nessus é também possível criar novos plugins para

executar testes. O Nessus é suficientemente inteligente para testar serviços que corram

em portas fora do normal, ou para testar diversas instâncias de um serviço (um

servidor HTTP a correr quer nos portos 80 e 8080).

A máquina BackTrack irá efectuar o ataque baseado num scan a uma máquina que

está a correr o Windows 2003 Server. A máquina BackTrack comporta o cliente e o

servidor de Nessus.

Windows 2003192.168.232.92

BackTrack v.1.0192.168.232.93

Nessus Scan (Todos os Plugins)

Figura 41 – Nessus Scan



86

A base de dados do Nessus possui no momento aproximadamente 12000 plugins, não

foi utilizado o mecanismo de port scan do Nessus uma vez que, os testes efectuados

nas Secções 5.3.1, 5.3.2 e 5.3.3 foram destinados especificamente à capacidade de

detecção de port scans por parte do Snort.

A Figura 42 demonstra as vulnerabilidades encontradas pelo Nessus:

Figura 42 – Vulnerabilidades encontradas pelo Nessus

A Figura 43 demonstra a estatística dos alertas gerados pelo Snort:

Figura 43 – Estatística dos alertas gerados pelo Snort



87

Devido ao elevado número de alertas gerado é impossível fazer uma análise detalhada

de todos eles. A Figura 44 mostra os alertas gerados da classe attempted-admin (ver

Tabela 2). Nas Secções 5.4.1 e 5.4.2 foram executados individualmente os plugins que

geraram os alertas referidos, a capacidade de detecção do Snort nesses casos será

analisada com detalhe.

Figura 44 – Alertas da classe attempted-admin após execução do Nessus

Na Secção 5.4.3 será executado o plugin que gerou o alerta “NETBIOS SMB-DS

repeted logon failure” e analisado em detalhe a detecção do Snort.

5.4.1 Ataque DoS ao Serviço RPCSS do Windows

Neste teste foi executado o plugin “MS RPC Services null pointer reference DoS”,

cujo objectivo é enviar pedidos mal-formados para o serviço RPCSS (Remote

Procedure Call Server Service) do Windows. Os pedidos mal-formados geram um

buffer overflow facto aproveitado para introduzir shellcode para se obter controlo

sobre a máquina, ao ocorrer o buffer overflow o serviço de RPC fica indisponível

(DoS).

O código fonte do plugin encontra-se na página WEB do Nessus (

www.nessus.org/plugins/index.php?view=viewsrc&id=11159). Observando o código

fonte conclui-se que o ataque é efectuado cinco vezes utilizando cinco portos origem

diferentes, o Snort detectou essas cinco tentativas como demonstra a Figura 45.

http://www.nessus.org/plugins/index.php?view=viewsrc&id=11159



88

Figura 45 – Alertas após execução do Nessus



Objectivos Verificar a capacidade de detecção do Snort a um ataque ao

Serviço RPC Windows 2003 Servidor.

Passos a executar

Iniciar o sensor.

Executar o plugin “MS RPC Services null pointer reference DoS” do

Nessus.

Parar o sensor.


Resultado Esperado

Detecção das cinco tentativas de ataque, e registo dos diferentes

portos origem.

Capacidade de detectar que apenas foi tentativa de ataque e

classificá-lo correctamente. O Sistema Operativo Windows alvo

não está vulnerável a este ataque, como tal o ataque não deverá

produzir efeito.

Registo dos endereços IP de origem e destino do ataque.

Resultado Obtido Detecção das cinco tentativas de ataque bem como endereços IP e

portos origem e destino, classificando-o como attempted, uma vez

que a execução do ataque não provocou efeito.

Conclusão O Snort detectou correctamente o ataque feito, como se pode

observar o resultado esperado coincide com o resultado obtido.




89

5.4.2 Ataque ao Serviço ntpd de Vários Sistemas Baseados em Unix

Neste teste foi executado o plugin “ntpd overflow”, cujo objectivo é enviar

determinados pedidos UDP para o daemon Network Time Protocol (versão 4.0.99k e

anteriores) do Sistema Operativo. Os pedidos geram um DoS por buffer overflow no

daemon e assim permitem ao atacante executar código arbitrário como root. O código

fonte deste plugin encontra-se na página WEB do Nessus

(http://www.nessus.org/plugins/index.php?view=viewsrc&id=10647).




daemon NTP.

Passos a executar

Iniciar o sensor.

Executar o plugin “ntpd overflow” do Nessus.

Parar o sensor.


Resultado Esperado Detecção da tentativa de ataque “buffer overflow” ao daemon NTP,

classificando-o como attempted-admin.


Resultado Obtido Detecção da tentativa de “buffer overflow” ao daemon NTP,

classificando-o correctamente como attempted-admin.


Conclusão O Snort detectou correctamente o ataque feito, como se pode

observar o resultado esperado coincide com o resultado obtido.


5.4.3 Ataque ao Serviço SMB (Brute Force por Vários Users e Passwords)

Neste teste foi executado o plugin “SMB log in as users”, cujo objectivo é enviar

determinados pedidos de ligação ao servidor SMB, utilizando para tal diversas

combinações de users/passwords. Este plugin pode ter efeitos nocivos em servidores

que tenham políticas de segurança muito elevadas e que bloqueiem as contas por




90

demasiados acessos indevidos. O código fonte deste plugin encontra-se na página

WEB do Nessus (http://www.nessus.org/plugins/index.php?view=viewsrc&id=10404)

Figura 46 – Alertas após execução do Nessus




Serviço SMB (tentativa de login Brute Force).

Passos a executar

Iniciar o sensor.

Executar o plugin “SMB log in users” do Nessus.

Parar o sensor.


Resultado Esperado Detecção das várias (cerca de 500) tentativas de login com

diversas combinações de users/password.


Resultado Obtido

Detecção das respostas negativas às tentativas de login,

classificando-o como unsuccessful-user.

Registo dos endereços IP de origem e destino inversos ao

esperado.

Registo dos diferentes portos utilizados para cada tentativa.

Conclusão

O Snort detectou a resposta ao ataque feito, colocando o endereço

IP do servidor como origem e o do atacante como destino.

O facto de detectar apenas as respostas é uma mais valia, pois os

pedidos de login são frequentes nas organizações, ao contrário de

respostas negativas de logins falhados em massa.

Este é o chamado alerta invertido.





91

5.5 Vulnerabilidade nos Ficheiros Windows Metafile

Neste teste é explorado a vulnerabilidade na livraria GDI incluída nos Windows XP,

2003, e Windows Vista.

Esta vulnerabilidade utiliza a função metafile “Escape()” para executar código

arbitrário através do procedimento SetAbortProc. É afectado o visualizador de

imagens e de fax do Windows, que ao abrir o ficheiro dá acesso à já referida execução

de código arbitrário.

Foi utilizado o framework Metasploit presente no SO BackTrack, mais

especificamente o módulo “Windows XP/2003/Vista Metafile Escape() SetAbortProc

Code Execution”, este fica à espera de ligações no porto 8080. Como mostra a Figura

47.

Figura 47 – Primeiro passo no framework

No Windows Server 2003 ao aceder-se a http://192.168.232.93:8080/funny_picture.wmf e

aceitar-se visualizar o aparentemente inofensivo ficheiro “funny_picture.wmf” o

visualizador de imagens do Windows bloqueia e não é apresentada qualquer imagem,

como demonstra a Figura 48.

http://192.168.232.93:8080/funny_picture.wmf



92

Figura 48 – Ligação efectuada na máquina Windows2003

Após a máquina Windows Server 2003 aceder à suposta imagem existente na

máquina Backtrack, como mostra a Figura 49 é possível estabelecer um Reverse

Handler com a máquina Windows.

Figura 49 – Segundo passo no framework



93

Ao clicar em “session 1” é estabelecida a sessão, e o atacante fica com acesso remoto

à linha de comandos da máquina Windows, podendo ser executado qualquer comando

sem restrições uma vez que se tem permissões de Administrador, a Figura 50

demonstra a listagem de ficheiros e directorias da unidade C da máquina Windows.

Figura 50 – Segundo passo no framework



94

A Figura 51 demonstra a criação da pasta “attack” na raiz da unidade.

Figura 51 – Terceiro passo no framework

A Figura 52 comprova a existência da nova pasta.

Figura 52 – Terceiro passo no framework



95

Na Figura 53 estão listados os alertas gerados pelo Snort.

Figura 53 – Alertas após execução do ataque



Objectivos Verificar a capacidade de detecção do Snort a um ataque à

vulnerabilidade nos Ficheiros Windows Metafile.

Passos a executar

Iniciar o sensor.

Executar o módulo “Windows XP/2003/Vista Metafile

Escape() SetAbortProc Code Execution” da framework

MetaExploit 2.6.

Explorar a sessão estabelecida. Parar o sensor.


Resultado Esperado Detecção dos pedidos de ligação ao ficheiro WMF.

Detecção dos pedidos de sessão e exploração.

Resultado Obtido Detecção dos pedidos de ligação ao ficheiro WMF.

Detecção dos pedidos de sessão e exploração.

Conclusão

O Snort detectou a resposta ao ataque feito, colocando o endereço

IP da vítima como origem e o do atacante como destino.

O Snort consegue detectar o acesso ao ficheiro e os pedidos feitos

na sessão, correlacionando os dois acontecimentos e alertando o

ataque observado.




96

5.6 Vulnerabilidade do Internet Explorer

Neste teste é explorada uma vulnerabilidade do Internet Explorer (versão 6.0.3790.0).

Esta vulnerabilidade utiliza a função “createTextRange()” de forma a corromper a

memória de uma forma que, sobre certas circunstâncias, pode levar a um acesso

corrupto ou inválido a um ponteiro para uma tabela.

O Internet Explorer 6 e 7 Beta 2 da Microsoft permite aos atacantes remotos causarem

um DoS e a execução de código arbitrário através da já referida função

“createTextRange()” sobre o objecto, que resulta na chamada de um ponteiro inválido.

Foi utilizado o framework Metasploit presente no SO BackTrack, mais

especificamente o módulo “Internet Explorer createTextRange() Code Execution”,

este fica á espera de ligações no porto 8080. Como mostra a Figura 54 e a Figura 55.

Windows XP192.168.232.90

BackTrack v.1.0192.168.232.93

Figura 54 – Cenário do teste à vulnerabilidade do Internet Explorer



97

Figura 55 – Cenário do teste à vulnerabilidade do Internet Explorer

No Windows XP ao aceder-se a http://192.168.232.93:8080 aparece texto na janela do

Internet Explorer com a contagem em percentagem do ataque que vai sobrecarregar a

memória do Sistema Operativo, como demonstra a Figura 56.

Figura 56 – Acesso á máquina Backtrack



98

Na Figura 57 é visível o acesso pela máquina Windows XP.

Figura 57 – Informação do acesso da máquina Windows XP

Após a máquina Windows XP fechar o browser o processo deixa de sobrecarregar a

memória tal como é visível na Figura 58.

Figura 58 – Gestor de tarefas do Windows



99



Objectivos Verificar a capacidade de detecção do Snort a um ataque a uma

vulnerabilidade do Internet Explorer.

Passos a executar

Iniciar o sensor.

Executar o módulo “Internet Explorer createTextRange() Code

Execution” da framework MetaExploit 2.6.

Parar o sensor.


Resultado Esperado Detecção dos pacotes com informação maliciosa.

Resultado Obtido O Snort não foi capaz de detectar qualquer pacote.

Conclusão O Snort não é capaz de detectar qualquer informação relativa ao

ataque efectuado.


5.7 Snort + Guardian

O Guardian é um script em PERL que monitoriza o ficheiro de alertas do Snort, e

toma uma atitude reactiva perante os endereços IP referentes aos alertas de possíveis

ataques bloqueando-os na firewall. Antes de se começar a utilizar o Guardian é

conveniente testar o Snort na rede e reduzir ao máximo os falsos positivos que este

gera. Isto, porque o Guardian bloqueia os endereços IP que constem no ficheiro de

alertas do Snort, excepto os definidos no ficheiro “guardian.ignore”. Note-se que o

Guardian apenas tem capacidade de alterar a iptables da própria máquina onde está a

correr, pelo que não existirá qualquer tipo de reacção a ataques destinados a outras

máquinas da rede. No Tutorial de Instalação do Snort são explicados os passos

necessários para a configuração e execução do Guardian (Anexo 1).

Para testar o funcionamento do conjunto de ferramentas Snort e Guardian a máquina

BackTrack executou um scan à máquina Snort @ Ubuntu através do programa

Nessus, a Figura 59 mostra o cenário do teste.



100

Nessus Scan

Figura 59 – Nessus Scan à Máquina Snort



Objectivos Verificar a capacidade de reacção a ataques por parte do conjunto

de ferramentas Snort e Guardian.

Passos a executar

Iniciar o sensor.

Iniciar o Guadian.

Executar o Nessus na máquina BackTrack.

Parar o sensor.

Verificar a iptables da máquina Snort.

Resultado Esperado

Detecção de acções maliciosas á máquina Snort vindas da

máquina Backtrack.

Alteração da iptables pelo Guardian para bloquear qualquer tipo de

tráfego relacionado com o endereço IP da máquina BackTrack.

Resultado Obtido

O Snort detectou as acções maliciosas à máquina Snort vindas da

máquina Backtrack.

O Guardian alterou a iptables para bloquear o tráfego vindo da

máquina BackTrack.

Conclusão

O conjunto de ferramentas Snort e Guardian fornecem um bom

sistema de reacção a ataques, passando por exemplo, essa

reacção pelo bloqueio do endereço IP do atacante na iptables.

Esta acção apenas é executada para ataques direccionados à

máquina onde se encontra configurado o Snort e o Guardian.




101

5.8 Conclusão Final sobre os Testes

Como é esperado, devido à sua natureza, este IDS só detecta os ataques que estejam

compreendidos no universo de regras. Não tem qualquer tipo de mecanismo que

permita evoluir no sentido de detectar ataques que não estejam contemplados nas

regras.

Foram detectados alguns problemas, entre os quais, o facto de não ser possível actuar

normalmente nas redes comutadas, ou seja, quando se utiliza um switch. Decidiu-se

utilizar um hub para ultrapassar essa limitação, no entanto esta situação seria

facilmente ultrapassada com a utilização de um switch com Port Spam.

Outros dos problemas foi a dificuldade em inspeccionar ligações encriptadas. A

aplicação também não teve a capacidade para analisar e detectar IP Spoofing.

É necessário acrescentar, que o carácter reactivo só é conseguido com o auxílio de

aplicações adicionais, como por exemplo o Guardian que consegue este efeito

interagindo com a firewall à medida que monitora os logs criados pelo Snort.



102

6 Conclusões O estudo do Snort, realizado neste projecto, permitiu concluir sobre diversos aspectos

dos Sistemas de Detecção de Intrusão, vulgarmente designados IDS. Este trabalho

permitiu reflectir e chegar a diversas conclusões:

• Os IDS por assinaturas têm a desvantagem de não se adaptarem a novas

situações, não contempladas pelas regras. Já os IDS por detecção de anomalias

definem um baseline que serve de comparação constante. No entanto, estes

últimos também tem problemas, como é o caso de definições de baselines

pouco precisos.

• A necessidade constante da presença humana para monitorizar as alterações no

tráfego de rede e situações não contempladas, referidas no ponto anterior, é

um entrave para se chegar a um IDS totalmente automatizado.

• O Snort tem a vantagem de ter bons plugins para inspeccionar os pacotes em

detalhe, no entanto, segundo as conclusões tiradas dos testes efectuados, é

facilmente “ludibriado” pela técnica de IP Spoofing. Não tem a capacidade de

comparar endereços da camada de ligação (endereços MAC) e aperceber-se de

que existem incongruências graves.

• A falta de mecanismos reactivos no Snort é uma desvantagem notória nesta

ferramenta. Para obtermos reactividade foi necessário aliar o Guardian ao

Snort.

O Snort, sendo o IDS mais usado pela comunidade de segurança da informação, foi

extremamente importante para tirar estas conclusões, todas elas baseadas no estudo

desta ferramenta.

O factor humano tem ainda um grande peso sobre o funcionamento normal de um

IDS. A falta de automatismo e carácter adaptativo, sem falhas, é um problema, sendo

a intervenção de um Administrador, especializado e com intervenções constantes,

algo imprescindível.

Este IDS de rede, mesmo sendo baseado em assinaturas, exige, após a sua

implementação na rede, um período de monitorização por parte do Administrador que



103

terá a tarefa árdua de “afinar” o sistema, de forma a reduzir o número de falsos

positivos gerados.

Esta ferramenta baseia-se, como referido, em regras. No entanto, além de fazer parte

da comunidade open source, estas regras actualizadas têm um preço estipulado

actualmente em 1400€ anuais. No entanto, passados 5 dias do seu lançamento, passam

a ser distribuídas gratuitamente pela comunidade.

Para finalizar, fica a referência de que há trabalho futuro a executar nesta área, quer a

estudar os IDS, quer a desenvolver software (p.e. Plugins para o Snort). Há que seguir

os passos do CIDF e IDWG rumo á perfeição, para que cada vez menos, seja notada a

dependência do factor humano. Todo o esforço em prol da adaptabilidade máxima

quer com auxílio das redes neuronais, predição por inteligência artificial ou análise

estatística avançada.

Deste projecto resultou um tutorial de instalação do Snort e ferramentas necessárias

para o seu funcionamento, que será brevemente enviado e disponibilizado á

comunidade do Snort.



104

Referências Livros:

• REHMAN, R. – Intrusion Detection Systems with Snort, Noreen Regina, ISBN 0131407333,

2003.

• KOZIOL, J. – Intrusion Detection with Snort, Sams, ISBN 157870281X, 2003.

• VENTOR, H.; ELOFF, J. – A Taxonomy for Information Security Technologies, ISBN

1581139748, 2003.

• SCOTT, C.; WOLFE, P.; HAYES, B. – Snort for Dummies, ISBN 0764568353, 2004.

• COX, K.; GERG, C. – Managing Security with Snort and IDS Tools, O’Reilly, ISBN

0596006616, 2004.

• KLEVINSKY, T.; GUPTA, A.; LABIBERTE, S. – Hack I.T. – Security Through Penetration

Testing, Simple Nomad, ISBN 0201719568, 2002.

• OREBAUGH, A.; BILES, S.; BABBIN, J. – Snort Cookbook, O’Reilly, ISBN 0596007914,

2005.

Documentos:

• SIMÕES, P. – Detecção e análise de vulnerabilidades de rede e qualidade de serviço de

aplicações de negócio (aplicação Sirel), 2005,

http://www.di.fc.ul.pt/disciplinas/pei/pei0405/conteudo/documentos/relatorios-0405/pedro-

simoes-26590.pdf.

• SILVA, A.; FERREIRA, R.; BEZERRA, R. – Metodologia para desenvolvimento de

assinaturas de detecção de intrusão com a ferramenta Snort, 2005,

http://www.redes.cefetgo.br/gl_downloads/tcc/pdf/tcc_11211213750.pdf.

• SANTOS B. – Detecção de intrusos utilizando o Snort, 2005,

http://www.ginux.ufla.br/documentacao/monografias/mono-BrunoSantos.pdf.

• VASCO, R. – Sintese sobre sistemas de IDS.

• VAZ, T.; CAMÕES, T.; ARAÚJO, G. – Sistemas de Detecção de Intrusão Livres: suas

limitações e uma arquitetura proposta sobre concentração de mensagens e correlacionamento

de eventos,

http://www.uefs.br/erbase2004/documentos/wticgbase/Wticgbase2004ArtigoIC005.pdf.

• LOPES, M.; GONÇALO, L. – Ferramentas de apoio à segurança, 2005,

http://paginas.fe.up.pt/~jvv/Disciplinas/2k4-5/SSR/Apresentacoes/trab.t2.4.doc.

• The Snort Core Team – The Snort FAQ, http://www.snort.org/docs/faq/1Q05/faq.pdf.

http://www.di.fc.ul.pt/disciplinas/pei/pei0405/conteudo/documentos/relatorios-0405/pedro-simoes-26590.pdf

http://www.di.fc.ul.pt/disciplinas/pei/pei0405/conteudo/documentos/relatorios-0405/pedro-simoes-26590.pdf

http://www.redes.cefetgo.br/gl_downloads/tcc/pdf/tcc_11211213750.pdf

http://www.ginux.ufla.br/documentacao/monografias/mono-BrunoSantos.pdf

http://www.uefs.br/erbase2004/documentos/wticgbase/Wticgbase2004ArtigoIC005.pdf

http://paginas.fe.up.pt/%7Ejvv/Disciplinas/2k4-5/SSR/Apresentacoes/trab.t2.4.doc

http://www.snort.org/docs/faq/1Q05/faq.pdf



105

Apresentações:

• ANTUNES, M – Diapositivos das aulas de Interligação de Redes I, ESTG – Leiria, 2005.

• ANTUNES, M – Diapositivos das aulas de Interligação de Redes II, ESTG – Leiria, 2006.

• FRADE, M. – Diapositivos das aulas de Comunicações Seguras, ESTG – Leiria, 2005.

• LEBRE, R. – Snort IDS, INESC-ID, http://mega.ist.utl.pt/~ic-aas/2004/slides/praticas/4-

Snort.pdf.

RFCs:

• FRASER, B. – Site Security Handbook (RFC2196), 1997, http://www.ietf.org/rfc/rfc2196.txt.

• POSTEL, J. – Internet Control Message Protocol (RFC0792), 1981,

http://www.ietf.org/rfc/rfc792.txt.

• SHIREY, R. – Internet Security Glossary (RFC2828), 2000,

http://www.ietf.org/rfc/rfc2828.txt.

Internet Drafts:

• FEINSTEIN, B.; MATTHEWS, G.; WHITE, J. – The Intrusion Detection Exchange Protocol

(IDXP), 2002, http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-07.txt.

• DEBAR, H.; CURRY, D.; FEINSTEN, B. – The Intrusion Detection Message Exchange

Format, 2006, http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt.

• KAHN, C.; BOLINGER, D.; SCHNACKENBERG, D. – Communication in the Common

Intrusion Detection Framework, 1998, http://gost.isi.edu/cidf/drafts/communication.txt.

Websites:

• Wikipedia, http://www.wikipedia.com/.

• Perl, http://www.perl.org/.

• PHP, http://www.php.org/.

• BASE, http://sourceforge.net/projects/secureideas/.

• Snort, http://www.snort.org/.

• Nessus, http://www.nessus.org/.

• Guardian, http://www.chaotic.org/guardian/.

• MySQL, http://www.mysql.org/.

• Nmap, http://www.nmap.org/.

• MyCert, http://www.mycert.org.my/.

http://mega.ist.utl.pt/%7Eic-aas/2004/slides/praticas/4-Snort.pdf

http://mega.ist.utl.pt/%7Eic-aas/2004/slides/praticas/4-Snort.pdf




http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-07.txt

http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt

http://gost.isi.edu/cidf/drafts/communication.txt

http://www.wikipedia.com/

http://www.perl.org/

http://www.php.org/

http://sourceforge.net/projects/secureideas/


http://www.nessus.org/

http://www.chaotic.org/guardian/

http://www.mysql.org/


http://www.mycert.org.my/



106

• Security Focus, http://www.securityfocus.com/.

• SecuriTeam, http://www.securiteam.com/.

• CERT, http://www.cert.org/.

• BEEP Core, http://www.beepcore.org/.

• CVE, http://www.cve.mitre.org/.

• WhiteHats, http://www.whitehats.com/.

• IETF, http://www.ietf.org/.

• CIDF, http://gost.isi.edu/cidf/.

• SecTools, http://sectools.org/.

• Sourceforge, http://sourceforge.net/.

• Milw0rm, http://milw0rm.com/.

• IronGeek, http://www.irongeek.com/.

• SANS Institute, http://www.sans.org/resources/idfaq/aint.php.

• Invasão.com.br, http://www.invasao.com.br/.

• BWHacks Forum, http://www.bwhacks.com/forums/index.php.

• OpenDen, http://www.openden.com/.

• Mestasploit, http://www.metasploit.org/.

• Prelude, http://www.prelude-ids.org/.

http://www.securityfocus.com/

http://www.securiteam.com/

http://www.cert.org/

http://www.beepcore.org/

http://www.cve.mitre.org/

http://www.whitehats.com/

http://www.ietf.org/

http://gost.isi.edu/cidf/

http://sectools.org/

http://sourceforge.net/

http://milw0rm.com/

http://www.irongeek.com/

http://www.sans.org/resources/idfaq/aint.php

http://www.invasao.com.br/

http://www.bwhacks.com/forums/index.php

http://www.openden.com/

http://www.metasploit.org/

http://www.prelude-ids.org/



107

Anexo 1 Tutorial Instalação do Snort

Introdução A ideia geral deste guia é mostrar a facilidade do processo de instalação de um sensor e todo o sistema

de logging para o Snort (Ferramenta IDS).

Partimos de um sistema operativo com o X instalado, embora geralmente os sensores sejam instalados

em servidores sem ambiente gráfico.

São abordadas duas perspectivas, a instalação pela linha de comandos, dos pacotes dos quais se

fizeram o download e também aquela em que se utiliza o apt-get/Adept, ferramenta debian, para a

instalação facilitada destes mesmos pacotes.

Requisitos Instalar os seguintes serviços de uma das duas maneiras possíveis:

Por download e instalação manual:

• PHP (www.php.net) • MySQL (www.mysql.com) • Apache (www.apache.org)

Também estão disponíveis via apt-get: • sudo apt-get install apache2 • sudo apt-get install mysql-server • sudo apt-get install php5 • sudo apt-get install php5-mysql

Configurar o iptables para permitir, por exemplo, todo o tráfego IP (fase de testes):

• sudo iptables -I INPUT -i eth0 -p ip -j ACCEPT

Testar o Apache com o seguinte código php:

• sudo nano /var/www/index.php

<?php

phpinfo();

?>

em http://127.0.0.1 ou http://localhost

http://www.php.net/

http://www.mysql.com/

http://www.apache.org/



108

Instalar o ADODB e o (Basic AnalysisBASE and Security Engine) disponíveis respectivamente em:

• http://prdownloads.sourceforge.net/adodb/

• http://prdownloads.sourceforge.net/secureideas/

Instalação do Snort Fazer o download do Snort e do PCRE:

• http://www.snort.org

• http://prdownloads.sourceforge.net/pcre/

Através do Adept verificar se está instalado o libpcap0.8, libpcap0.8-dev, libpcre3 e o libpcre3-dev

(necessários para a instalação do Snort).

Instalar via Adept se necessário.

Instalar PCRE

• sudo tar -xvzf pcre-6.3.tar.gz • cd pcre-6.3 • sudo ./configure • sudo make • sudo make install

Instalar Snort

• sudo tar -xvzf snort-2.4.4.tar.gz • cd snort-2.4.4 • sudo ./configure --with-mysql=<localização do mysql> • sudo make • sudo make install

Em caso de se verificar a seguinte mensagem de erro:

snort: error while loading shared libraries: libpcre.so.0: cannot open shared

object file: No such file or directory

Criar um symlink pela seguinte formula:

sudo ln -s /usr/local/lib/libpcre.so.0 <localização do ficheiro>

http://prdownloads.sourceforge.net/adodb/

http://prdownloads.sourceforge.net/secureideas/


http://prdownloads.sourceforge.net/pcre/



109

Ex: sudo ln -s /usr/local/lib/libpcre.so.0 /usr/lib/libpcre.so.0

Fazer download das regras e extrair para /etc/snort/rules

Configurar o ficheiro snort.conf (/etc/snort)

var HOME_NET any (Para capturar todos as redes)

var EXTERNAL_NET !$HOME_NET (Tudo que não for HOME_NET é externo)

var RULE_PATH /etc/snort/rules (caminho correcto para as regras)

--preprocessor

output database: log, mysql, user=snort password=<password escolhida>

dbname=snort host=localhost

Configurar a base de dados no MySQL:

mysql

mysql> SET PASSWORD FOR root@localhost=PASSWORD('password');

>Query OK, 0 rows affected (0.25 sec)

mysql> create database snort;

>Query OK, 1 row affected (0.01 sec)

mysql> grant INSERT,SELECT on root.* to snort@localhost;


mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password_do_snort.conf');


mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to

snort@localhost;


mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort;


mysql> exit

>Bye

Executar os seguintes comandos para criar as tabelas

mysql -u root -p < ~/snortinstall/snort-2.4.3/schemas/create_mysql snort



110

Enter password: mysql root password

Verificar se a BD do Snort foi criada correctamente

mysql -p

>Enter password:

mysql> SHOW DATABASES;

+------------+

| Database

+------------+

| mysql

| Snort

| test

+------------+

3 rows in set (0.00 sec)

mysql> use snort

>Database changed

mysql> SHOW TABLES;

+------------------+

| Tables_in_snort

+------------------+

| data

| detail

| encoding

Version 13 Page 13 of 20 Updated 10/24/2005 7:39 PM

| event

| icmphdr

| iphdr

| opt

| reference

| reference_system

| schema

| sensor



111

| sig_class

| sig_reference

| signature

| tcphdr

| udphdr

+------------------+

16 rows in set (0.00 sec)

exit;

Instalar o ADODB: Voltar à directoria inicial de instalação e fazer:

cp adodb462.tgz /var/www/

cd /var/www/

tar -xvzf adodb462.tgz

rm –rf adodb462.tgz

Instalar e configurar o BASE: Voltar à directoria inicial de instalação e fazer:

cp base-1.2.tar.gz /var/www/html

cd /var/www/html

tar –xvzf base-1.2.tar.gz

rm –f base-1.2.tar.gz

mv base-1.2 base (this renames the base-1.2 directory to just “base”)

cd /var/www/html/base

cp base_conf.php.dist base_conf.php

Editar o ficheiro “base_conf.php” e introduzir os seguintes parâmetros:

$BASE_urlpath = "/base";

$DBlib_path = "/var/www/adodb/ ";

$DBtype = "mysql";

$alert_dbname = "snort";

$alert_host = "localhost";

$alert_port = "";

$alert_user = "snort";



112

$alert_password = "password_do_snort_conf";

/* Archive DB connection parameters */

$archive_exists = 0; # Set this to 1 if you have an archive DB

Consultar o BASE

https://<endereço.ip>/base/html

Na página inicial de setup do BASE clicar no link “setup page” e depois clicar no botão “setup AG”.

Estará pronto a correr o Snort e consultar os logs em https://<endereço.ip>/base/html.

Instalação do Guardian Esta ferramenta permite alterações no iptables, permitindo assim que haja prevenção por parte do

conjunto Snort + Guardian.

De seguida são apresentados os passos para instalação desta ferramenta:

Fazer o download do Guardian (http://www.chaotic.org/guardian/)

Executar os seguintes comandos:

• mv guardian-x-x.tar.gz /usr/src • tar -xvzf guardian-x-x.tar.gz • cd guardian-x-x • cd scripts • ls

freebsd_block.sh freebsd_unblock.sh ipchain_block.sh ipchain_unblock.sh

iptables_block.sh iptables_unblock.sh

O Guardian trabalha com os seguintes scripts, guardian_block.sh e guardian_unblock.sh. Terá que ser

escolhido o filtro de pacotes a usar e instalar os scripts necessários. O mais frequente é o iptables.

• cp iptables_block.sh /usr/bin/guardian_block.sh • cp iptables_unblock.sh /usr/bin/guardian_unblock.sh • chmod 755 /usr/bin/guardian_block.sh /usr/bin/guardian_unblock.sh

Copiar o resto do programa para os locais necessários:

• cd ..

http://www.chaotic.org/guardian/



113

• cp guardian.pl /usr/bin • chmod 755 /usr/bin/guardian.pl

• cp guardian.conf /etc/

Configurar os valores no ficheiro “guardian.conf”:

Interface eth0 -> interface eth0, a que vai ter os terminais bloqueados

AlertFile /var/adm/secure -> mudar para /var/log/snort/alert

TimeLimit 86400 -> mudar para quanto tempo em segundos o endereço IP fica bloqueado

pela firewall, 99999999 remove esta opção.

Criar o arquivo de log do Guardian:

touch /var/log/guardian.log

Criar o ficheiro “guardian.ignore”, com os ips que irá ignorar:

touch /etc/guardian.ignore

Iniciar o Guardian:

guardian.pl -c /etc/guardian.conf

OS shows Linux

Warning! HostIpAddr is undefined! Attempting to guess..

Got it.. your HostIpAddr is 192.168.1.1

My ip address and interface are: 192.168.1.1 eth0

Loaded 3 addresses from /etc/guardian.ignore

Becoming a daemon..



114

Anexo 2 Regras Simples Regras criadas para os testes 1 e 2 (Secções 5.2.1 e 5.2.2).

alert tcp any any -> any any (msg:"Palavra encontrada -> hack <- |

Teste Regras | Proj IDS"; content:"hack"; nocase; rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> back orifice

<- | Teste Regras | Proj IDS"; content:"back orifice"; nocase;

rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> crack <- |

Teste Regras | Proj IDS"; content:"crack"; nocase; rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> virus <- |

Teste Regras | Proj IDS"; content:"virus"; nocase; rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> attack <- |

Teste Regras | Proj IDS"; content:"atack"; nocase; rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> trojan <- |

Teste Regras | Proj IDS"; content:"trojan"; nocase; rev:1;)

alert tcp any any -> any any (msg:"Palavra encontrada -> rootkit <- |

Teste Regras | Proj IDS"; content:"rootkit"; nocase; rev:1;)



115

Anexo 3 Conteúdo do Ficheiro test.txt Conteúdo do ficheiro de texto transferido no teste 1 (Secção 5.2.1).

Este texto é uma adaptação do artigo que se encontra em:

www.tomsnetworking.com/2006/03/21/out_to_get_you

It's A Jungle Out There, Hackers are a real menace.

The cost to business of online fraud is over $50 billion a year in the US alone. Fraud directly aimed at the online consumer is averaging about $5 billion a year.

Think about that. We attend the cinema and are treated to an advisory before the show about video and music piracy potentially benefiting terrorism, and the specter of the 9/11 horror is never far from our minds. So where are those online fraud billions going? And what are we doing to stop them from funding criminals and terrorists?

The truth is that for a decade or more, the online financial industry, banks, credit card companies, payment gateways, merchants, wealth management agents and so on, have all had it within their power to eradicate the majority of online fraud. Online banking and card payment consumers are being targeted primarily through techniques called phishing, pharming, trojans and spyware, man in the middle (MITM) technic, and social engineering. All used by hackers.

Documents

Estudo de Sistemas de Detecção e Prevenção de Intrusões ...read.pudn.com/downloads448/ebook/1886864/Estudo_de_Sistemas_… · Setembro de 2006 . Instituto Politécnico de Leiria