Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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!”
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
ii
Agradecimentos Aos professores orientadores, Mário Antunes e Miguel Frade, por todo o tempo
disponibilizado e ajuda prestada.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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/).
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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 34 – Resultado do Nmap ______________________________________________________80
Figura 35 – Estatística dos alertas ____________________________________________________80
Figura 36 – Listagem dos alertas _____________________________________________________80
Figura 37 – Nmap FIN Stealth Scan ___________________________________________________82
Figura 38 – Resultado do Nmap ______________________________________________________83
Figura 39 – Estatística dos alertas ____________________________________________________83
Figura 40 – Listagem dos alertas _____________________________________________________83
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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)
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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).
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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”
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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";)
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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; \
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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=
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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:
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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>
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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:
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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:
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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:
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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)
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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:
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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”
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
CPU: Intel P3 450 MHz
RAM: 256 MB
Disco: 4 GB
Placa Rede: 3Com Corporation
3c905C
Ubuntu 5.10
CPU: Intel P3 1100 MHz
RAM: 1 GB
Disco: 80 GB
Placa Rede: Marvell Yukon
88E8036
Windows Server 2003
CPU: Intel P3 1100 MHz
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Síntese do Teste Numero do teste: 2 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 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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Tabela 10 – Teste 2
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
78
Ao seleccionar o total de alertas obtém-se a listagem dos mesmos:
Figura 32 – Listagem dos alertas
Síntese do Teste Numero do teste: 3 Data: 17-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Registo dos endereços IP de origem e destino do scan.
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.
Tabela 11 – Teste 3
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
-p – Portos pretendidos
-P0 – Não envia pacotes ICMP ao terminal
-e – Interface de rede
-S – Endereço IP origem pretendido
-g – Porto Origem
192.168.232.90 – Endereço IP do alvo
Figura 33 – Nmap SYN Stealth Scan com IP Spoofing
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
80
A Figura 34 demonstra o estado dos portos analisados:
Figura 34 – Resultado do Nmap
A Figura 35 demonstra a estatística dos alertas registados pelo Snort:
Figura 35 – Estatística dos alertas
Ao seleccionar o total de alertas obtém-se a listagem dos mesmos:
Figura 36 – Listagem dos alertas
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
81
Síntese do Teste Numero do teste: 4 Data: 17-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
Resultado Esperado Detecção positiva do scan a todos os portos referidos.
Detecção da utilização de IP spoofing alertando para tal facto.
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.
Registo dos endereços IP de origem e destino do scan.
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.
Tabela 12 – Teste 4
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).
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
-p – Portos pretendidos
-P0 – Não envia pacotes ICMP ao terminal
192.168.232.91 – Endereço IP do alvo
FIN Stealth Scan
Figura 37 – Nmap FIN Stealth Scan
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
83
A Figura 38 demonstra o estado dos portos analisados:
Figura 38 – Resultado do Nmap
A Figura 39 demonstra a estatística dos alertas registados pelo Snort:
Figura 39 – Estatística dos alertas
Ao seleccionar o total de alertas obtém-se a listagem dos mesmos:
Figura 40 – Listagem dos alertas
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
84
Síntese do Teste Numero do teste: 5 Data: 21-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Alerta para todos os portos que foram alvo do scan.
Registo dos endereços IP de origem e destino 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.
Tabela 13 – Teste 5
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
88
Figura 45 – Alertas após execução do Nessus
Síntese do Teste Numero do teste: 6 Data: 30-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Tabela 14 – Teste 6
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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).
Síntese do Teste Numero do teste: 7 Data: 30-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
Objectivos Verificar a capacidade de detecção do Snort a um ataque ao
daemon NTP.
Passos a executar
Iniciar o sensor.
Executar o plugin “ntpd overflow” do Nessus.
Parar o sensor.
Verificar os alertas gerados com o auxílio do BASE.
Resultado Esperado Detecção da tentativa de ataque “buffer overflow” ao daemon NTP,
classificando-o como attempted-admin.
Registo dos endereços IP de origem e destino do ataque.
Resultado Obtido Detecção da tentativa de “buffer overflow” ao daemon NTP,
classificando-o correctamente como attempted-admin.
Registo dos endereços IP de origem e destino do ataque.
Conclusão O Snort detectou correctamente o ataque feito, como se pode
observar o resultado esperado coincide com o resultado obtido.
Tabela 15 – Teste 7
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Síntese do Teste Numero do teste: 8 Data: 30-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
Objectivos Verificar a capacidade de detecção do Snort a um ataque ao
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.
Verificar os alertas gerados com o auxílio do BASE.
Resultado Esperado Detecção das várias (cerca de 500) tentativas de login com
diversas combinações de users/password.
Registo dos endereços IP de origem e destino do ataque.
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.
Tabela 16 – Teste 8
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
95
Na Figura 53 estão listados os alertas gerados pelo Snort.
Figura 53 – Alertas após execução do ataque
Síntese do Teste Numero do teste: 9 Data: 31-08-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Tabela 17 – Teste 9
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
99
Síntese do Teste Numero do teste: 10 Data: 01-09-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Verificar os alertas gerados com o auxílio do BASE.
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.
Tabela 18 – Teste 10
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
100
Nessus Scan
Figura 59 – Nessus Scan à Máquina Snort
Síntese do Teste Numero do teste: 11 Data: 02-09-2006
Versão do Snort: 2.4.4 Data das Regras: 09-08-2006
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.
Tabela 19 – Teste 11
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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/.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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/.
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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>
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;
>Query OK, 0 rows affected (0.02 sec)
mysql> SET PASSWORD FOR snort@localhost=PASSWORD('password_do_snort.conf');
>Query OK, 0 rows affected (0.25 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to
snort@localhost;
>Query OK, 0 rows affected (0.02 sec)
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort;
>Query OK, 0 rows affected (0.02 sec)
mysql> exit
>Bye
Executar os seguintes comandos para criar as tabelas
mysql -u root -p < ~/snortinstall/snort-2.4.3/schemas/create_mysql snort
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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";
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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 ..
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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..
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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;)
Estudo de Sistemas de Detecção e Prevenção de Intrusões
Uma Abordagem Open Source
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.