monografia ids
DESCRIPTION
Monografia sobre sistemas de detecção de intrusãoTRANSCRIPT
UNIVERSIDADE FEDERAL DO PARÁINSTITUTO DE CIÊNCIAS EXATAS E NATURAIS
UM ESTUDO SOBRE
SISTEMAS DE DETECÇÃO DE INTRUSÃO
ANTONIO EDIVALDO DE OLIVEIRA GASPAR
KARLA LIDIANE DE S. DE JESUS
MILENE CHAVES DA SILVA
MONOGRAFIA DE CONCLUSÃO DO CURSO DE PÓS-GRADUAÇÃO
SUPORTE A REDES DE COMPUTADORES E TECNOLOGIAS INTERNET
Orientador: Prof MSc. Jorge Koury Bechara
Belém-PA, 26 de junho de 2008.
ANTONIO EDIVALDO DE OLIVEIRA GASPAR
KARLA LIDIANE DE S. DE JESUS
MILENE CHAVES DA SILVA
UM ESTUDO SOBRE SISTEMAS DE DETECÇÃO DE INTRUSÃO
Monografia de conclusão de curso apresentada como parte das atividades para obtenção
do título de especialista, do curso de Pós-Graduação em Suporte a Redes de
Computadores e Tecnologia Internet do Instituto de Ciências Exatas e Naturais da
Universidade Federal do Pará.
Orientador: Prof. MSc. Jorge Koury Bechara
Belém-PA, junho 2008
UM ESTUDO SOBRE SISTEMAS DE DETECÇÃO DE
INTRUSÃO
Monografia de conclusão de curso apresentada como parte das atividades para obtenção do título de especialista, do curso de Pós-graduação de Suporte a Redes de Computadores e Tecnologia Internet e aprovada na sua forma final pelo Instituto de Ciências Exatas e Naturais da Universidade Federal do Pará.
Data da aprovação: ____ de _____________________ de ________.
Conceito: ________________________
_________________________________________________________
Orientador: Prof. MSc. Jorge Koury Bechara
Belém-PA, 26 de junho de 2008
“Existe uma fronteira muito tênue entre ajudar administradores a protegerem seus
sistemas e prover um livro de receitas para pessoas sem escrúpulos”
Robert H. Morris
RESUMO
Sistema de Detecção de Intrusão (IDS) é um dos elementos essenciais à infra-estrutura de segurança, que objetiva identificar tentativas de intrusão de modo que uma resposta apropriada possa ser invocada. IDS podem ainda auxiliar os administradores na recuperação de danos, na identificação e no rastreamento de ações do atacante. O presente trabalho objetiva apresentar as diversas abordagens sobre IDS, sua classificação, principais características, aplicabilidade, vantagens e desvantagens. O objetivo principal foi apresentar o Snort, um software Open Source para detecção de intrusões, juntamente com os principais tipos de ataques da atualidade. Também descreve inúmeras simulações e análises que objetivam avaliar a capacidade de detecção e a eficiência das assinaturas do Snort.
Palavras-chave: Sistemas de Detecção de Intrusão (IDS), Detecção de Intrusão Baseada em Host (HIDS), Detecção de Intrusão Baseada em Rede (NIDS), Máquinas Virtuais (VM), Snort.
ABSTRACT
The intrusion detection systems (IDS), compose one of the elements of the against-intrusion infrastructure that objective to identify attempts of way intrusion that an appropriate reply can be invoked. IDS can still assist the administrators in the recovery of damages, the identification and the tracking of action of the aggressor. The present work intends to show to the diverse concepts and studies on Detection systems of Intrusion, its classification, applicability, advantages and disadvantages. The main objective is to present the Snort, an Open Source software for detention of intrusions, together with the main methodologies of attacks of the present time, through innumerable implementations and analyses on the detention capacity and efficiency of the signatures of the Snort.
Keywords: Intrusion Detection System (IDS), Host based Intrusion Detection System (HIDS), Network Intrusion Detection System (NIDS), Virtual Machine (VM), Snort.
LISTA DE ILUSTRAÇÕES
1.1 Total de Incidentes reportados ao CERT.Br de 1999 a 2007.............................. 18
1.2 Evolução das ameaças computacionais levando em consideração a velocidade de propagação, adaptado de [GOMES, 2006] ................................ 19
1.3a Worm Code Red infectou mais de 302.500 hosts em pouco mais de nove horas em 19 de junho de 2001 .......................................................................... 19
1.3b Worm SQL Slammer em menos de 30 minutos infectou mais de 74.800 hosts em 25 de janeiro de 2003 .................................................................................. 20
1.4 Segurança da Informação através da correlação entre quatro princípios básicos, adaptado de [LAUREANO, 2005] ........................................................ 22
1.5 Técnicas de contra-intrusão, adaptado de [JORGE, 2006] ............................... 29
1.6 Defense in depth usando estratégia de defesa em camadas ........................... 30
1.7 Choke point representado por um servidor Firewall .......................................... 30
1.8 Firewall protegendo uma rede de computadores .............................................. 33
1.9 Servidor IDS monitorando a rede interna e externa ao Firewall ....................... 35
2.1 Classificação de IDS ........................................................................................... 48
2.2 Diferenciação entre as classes de detecção de intrusão ................................. 50
2.3 Rede utilizando IDS baseados em host (FileServer e MailServer)e rede (monitorando as interfaces interna e externa do Frewall) ...................... 51
2.4 Módulos de um IDS ........................................................................................... 52
2.5 IDS em uma arquitetura distribuída através do uso de vários agentes (sensores) 53
2.6 Exemplo de Mensagem IAP ............................................................................... 58
3.1 Sofisticação do ataque vs. conhecimento técnico do intruso, adaptado de [ALLEN, 2000] ................................................................................................. 61
3.2 Anatomia de um ataque ..................................................................................... 63
3.3 Utilização de HIDS em hosts uma rede de computadores ............................... 74
3.4 Níveis de abstração entre as diferentes abordagens de IDS ............................. 76
3.5 Fluxo do ambiente cliente-servidor OSSEC usando agentes ........................... 81
4.1 Posicionamento do Sensor NIDS na rede ........................................................ 86
4.2a Exemplo de tráfego de rede sem anomalias (período de uma semana) ......... 87
4.2b Exemplo de tráfego de rede sem anomalias (período de três semanas) ......... 87
4.3 Anomalia Flash Crowd, detectada em um link de comunicação ...................... 90
4.4 Ataque de Negação de Serviço – DoS ............................................................. 93
4.5 Ataque de Negação de Serviço Distribuído – DdoS ......................................... 93
4.6 Sistemática de um ataque DDoS ....................................................................... 94
4.7 Fluxo de funcionamento do Snort ...................................................................... 101
4.8 Pilha funcional do Snort .................................................................................... 102
4.9 Posicionamento do IPS e sensores Snort em uma rede de computadores ..... 104
5.1 Monitor de máquinas virtuais (VMM), tipos I e II ................................................ 108
5.2 Tela principal do Vmware Workstation 5 ............................................................ 109
5.3 Cenário 1, host atacante Backtrack 3 ................................................................ 112
5.4 Máquinas virtuais e sistema anfitrião do cenário 1 ............................................. 112
5.5 Configuração da interface Host-only no Vmware Workstarion .......................... 113
5.6 Alertas de detecção de intrusão do Snort para o Web Scanner Nikto ............... 115
5.7 Classificação do ataque para o Web Scanner Nikto .......................................... 115
5.8 Estatísticas de detecção de intrusão do Snort para o Web Scanner Nikto ....... 116
5.9 Estatísticas de detecção de intrusão para o Web Scanner Nikto usando evasão ............................................................................................................... 118
5.10 Alertas gerados para o Web Scanner Nikto usando evasão .............................. 119
5.11 Alertas de port scanning para o teste do nmap ................................................ 121
5.12 Estatísticas de intrusão para o nmap ............................................................... 121
5.13 Classificação da assinatura de intrusão para o nmap ....................................... 121
5.14 Alertas identificando o port scanning com a opção TCP SYN Stealth ativa ..... 122
5.15 Classificação das assinaturas para o nmap em modo Stealth ......................... 122
5.16 Estatísticas de alertas para o nmap em modo Stealth. ..................................... 123
5.17 Estatísticas de alertas para o nmap usando o parâmetro “--data-length” .......... 125
5.18 Alertas para o nmap usando o parâmetro “--data-length” .................................. 125
5.19 Cenário 2 para simulações das ferramentas Retina, Nessus e Metasploit. ....... 126
5.20 Máquinas virtuais e sistema anfitrião do cenário 2 ............................................ 126
5.21 Tela principal do software Retina ..................................................................... 128
5.22 Estatísticas de alertas exibidas pelo fonrtend BASE no teste de intrusão usando o Retina ................................................................................................. 128
5.23 Alertas produzidos pelo Snort após a utilização do Retina contra a máquina alvo 129
5.24 Figura 5.24. Scanner Nessus ............................................................................. 130
5.25 Estatísticas de alertas exibidas pelo frontend BASE no teste do Nessus ......... 131
5.26 Alertas de detecção para o port scanner Nessus ............................................. 131
5.26 Metasploit Framework ........................................................................................ 132
5.28 Exploração da vulnerabilidade Windows Metafile Escape() SetAbortProc Code Execution ............................................................................................................ 135
5.29 Pesquisa no MSF para a vulnerabilidade ms06-001 wmf SetAbortProc ........... 136
5.30 Seleção do payload para a vulnerabilidade ms06-001 ...................................... 136
5.31 Escolha das opções gerais do exploit ................................................................ 136
5.32 Conclusão da configuração do exploit ............................................................... 137
5.33 Alertas gerados para a exploração da vulnerabilidade ms06-001 wmf SetAbortProc
137
5.34 Estatísticas geradas para a exploração da vulnerabilidade ms06-001wmf SetAbortProc ..................................................................................................... 137
5.35 Relatório do scanner Nessus indicando a vulnerabilidade ms03-026 ................ 140
5.36 Seleção do exploit no MSF para a vulnerabilidade ms03-026 ........................... 140
5.37 Seleção do payload para a vulnerabilidade ms03-026 ....................................... 141
5.38 Bind Shell para acesso remoto ao computador da vítima ................................. 141
5.39 Constatação de criação de uma pasta após o ataque ....................................... 142
5.40 Estatísticas de alertas no frontend BASE o teste obtenção de acesso ............. 142
5.41 Alertas do Snort o teste obtenção de acesso .................................................... 142
5.42 Assinaturas do Snort para o teste obtenção de acesso ..................................... 142
LISTA DE TABELAS
Tabela 4.1 Ferramentas para ataque DoS e tipo de tráfego respectivo ............................... 96
Tabela 5.1 Hosts usados na simulação do cenário 1 ............................................................ 112
Tabela 5.2 Resumo de funções e exemplos de uso do Nikto ...... ........................................ 114
Tabela 5.3 Síntese da simulação e resultados obtidos na detecção (teste 1) ....................... 116
Tabela 5.4 Opções de evasão de IDS do Nikto ..................................................................... 117
Tabela 5.5 Síntese da simulação e resultados obtidos na detecção (teste 3). ...................... 121
Tabela 5.6 Síntese da simulação e resultados obtidos na detecção (teste 4)........................ 123
Tabela 5.7 Opções de evasão do nmap ............................................................................... 124
Tabela 5.8 Síntese da simulação e resultados obtidos na detecção (teste 5)........................ 125
Tabela 5.9 Hosts usados na simulação do Cenário 2 ............................................................ 126
Tabela 5.10 Síntese da simulação e resultados obtidos na detecção (teste 6)........................ 129
Tabela 5.11 Descrição do teste e resultados para o tráfego gerado pelo Nessus .................. 131
Tabela 5.12 Resultados para a execução do exploit ms06-001 wmf SetAbortProc via MSF.......... 138
Tabela 5.13 Resultados para a execução do exploit ms03-026 Buffer Overrun In RPC Interface ... 143
SUMÁRIO
Autoria: .......................................................................................................................3 RESUMO......................................................................................................................5 Abstract.......................................................................................................................6 Lista de ilustrações....................................................................................................7 Lista de tabelas........................................................................................................10 Sumário.....................................................................................................................11 Introdução.................................................................................................................161 Fundamentos de Segurança Computacional.....................................................171.1 Princípios de segurança da informação....................................................................201.1.1 Outros conceitos importantes.....................................................................................................23
1.2 Política de Segurança .................................................................................................251.2.1 Normas existentes......................................................................................................................26
1.2.2 Formas e metodologias de proteção...........................................................................................27
1.2.3 Estratégias de segurança...........................................................................................................29
1.3 Mecanismos de proteção............................................................................................311.3.1 Atualização do Sistema Operacional...........................................................................................32
1.3.2 Detecção de Vírus......................................................................................................................33
1.3.3 Firewalls......................................................................................................................................33
1.3.4 Password crackers.....................................................................................................................34
1.3.5 Criptografia.................................................................................................................................34
1.3.6 Scanners de Vulnerabilidades.....................................................................................................34
1.3.7 Configuração dos Sistemas........................................................................................................34
1.3.8 Detecção de Intrusão..................................................................................................................35
1.3.9 Ferramentas de Descoberta de Rede e Scanners de Portas......................................................35
1.3.10 Política de segurança ...............................................................................................................35
1.3.11 Respostas à Incidentes.............................................................................................................36
1.3.12 Testes de Negação de Serviço.................................................................................................36
2 Sistemas de Detecção de Intrusão......................................................................372.1 Terminologias...............................................................................................................38
2.2 Conceitos e definições de IDS....................................................................................39
2.3 Justificativa para o uso de IDS..................................................................................41
2.4 Limitações....................................................................................................................42
2.5 Vulnerabilidades...........................................................................................................442.5.1 IP Spoofing.................................................................................................................................44
2.5.2 Inserção......................................................................................................................................44
2.5.3 Evasão........................................................................................................................................46
2.5.4 Negação de serviço ou Deny of Service (DoS)...........................................................................47
2.6 Classificação de IDS....................................................................................................482.6.1 Método de Detecção...................................................................................................................48
2.6.1.1 Baseado em assinatura...........................................................................................................48
2.6.1.2 Baseado em anomalia.............................................................................................................49
2.6.2 Arquitetura...................................................................................................................................50
2.6.2.1 Segundo o alvo........................................................................................................................50
2.6.2.2 Segundo a localização.............................................................................................................51
2.6.3 Comportamento pós-detecção....................................................................................................53
2.6.4 Segundo a freqüência de uso.....................................................................................................54
2.7 Entidades e padrões....................................................................................................542.7.1 Intrusion Detection Exchange Format Working Group - IDWG...................................................55
2.8 Protocolos para troca de mensagens entre IDS........................................................552.8.1 IDMEF.........................................................................................................................................56
2.8.2 O Modelo de Dados IDREF........................................................................................................56
2.8.3 IAP - Internet Intrusion Alert........................................................................................................57
2.8.3.1 Modelo de Comunicação.........................................................................................................57
2.8.3.2 Sintaxe das Mensagens...........................................................................................................57
2.9 Considerações sobre Avaliação de IDS.....................................................................58
3 DETECÇÃO DE INTRUSÃO BASEADA EM HOST (HIDS)..................................613.1 Ataques Locais.............................................................................................................62
3.2 Classificação dos invasores de sistemas..................................................................64
3.3 Ameaças digitais..........................................................................................................663.3.1 Worm..........................................................................................................................................66
3.3.2 Adwares e spywares.................................................................................................................68
3.3.3 Bots e Botnets.............................................................................................................................68
3.3.4 Cavalos de tróia (trojan horse)....................................................................................................69
3.3.4.1 Backdoor.................................................................................................................................69
3.3.4.2 Keylogger e Screenlogger.......................................................................................................70
3.3.5 Rootkits.......................................................................................................................................71
3.3.6 Exploits.......................................................................................................................................72
3.4 IDS baseado em Host .................................................................................................733.4.1 Conceito......................................................................................................................................73
3.4.2 Principais Características dos HIDS...........................................................................................75
3.4.3 IDSs baseados em rede x host...................................................................................................76
3.4.4 Verificadores de integridade .......................................................................................................79
3.5 Exemplos de HIDS.......................................................................................................793.5.1 TRIPWIRE..................................................................................................................................80
3.5.2 OSSEC......................................................................................................................................80
4 DETECÇÃO DE INTRUSÃO BASEADA EM REDE (NIDS)..................................844.1 IDS baseado em rede (NIDS).......................................................................................844.1.1 Posicionamento do sensor na rede.............................................................................................86
4.2 Anomalias no Tráfego de Rede...................................................................................87
4.3 Classificação de Anomalias na Rede.........................................................................894.3.1 Anomalias de Operação da Rede...............................................................................................89
4.3.2 Anomalias ‘Flash Crowd’............................................................................................................89
4.3.3 Anomalias de Medição...............................................................................................................90
4.3.4 Ataques.......................................................................................................................................90
4.3.4.1 Classificação de Ataques a Redes..........................................................................................90
4.3.4.2 Ataques de Negação de Serviço DoS......................................................................................92
4.3.4.2.1 Tipos de ataques DoS..........................................................................................................94
4.3.4.2.2 Ferramentas para ataque DoS ............................................................................................96
4.3.4.3 Ataques de Varredura (Probing)..............................................................................................96
4.3.4.4 Ataques de Penetração...........................................................................................................98
4.4 O NIDS Snort................................................................................................................994.4.1 Funcionamento do Snort...........................................................................................................100
4.4.2 Componentes do Snort.............................................................................................................102
4.5 Sistemas de Prevenção de Intrusão (IPS)................................................................104
5 Simulações e Resultados...................................................................................1065.1 Utilização de Máquinas Virtuais................................................................................1065.1.1 Máquinas Virtuais......................................................................................................................107
5.1.2 Tipos de máquinas virtuais........................................................................................................108
5.1.3 Vmware Workstation.................................................................................................................108
5.2 Metodologia e ambiente proposto............................................................................109
5.3 Seleção das ferramentas de ataque..........................................................................111
5.4 Cenário 1 – Nikto e Nmap..........................................................................................1115.4.1 Distribuição Linux Backtrack.....................................................................................................113
5.4.2 Nikto Web Server Scanner........................................................................................................114
5.4.2.1 Teste de evasão usando o Nikto............................................................................................117
5.4.3 Nmap Security scanner.............................................................................................................119
5.4.3.1 Teste de evasão usando o Nmap .........................................................................................122
5.5 Cenário 2 - Retina, Nessus e Metasploit Framework..............................................1265.5.1 Retina Network Security Scanner.............................................................................................127
5.5.2 Network Scanner Nessus..........................................................................................................129
5.5.3 Explotation atack com o Metasploit Framework.......................................................................132
5.5.3.1 Vulnerabilidade ms06-001 wmf SetAbortProc.......................................................................134
5.5.3.2 Vulnerabilidade ms03-026 Buffer Overrun In RPC Interface..................................................138
Considerações finais.............................................................................................144 Referências bibliográficas....................................................................................144 ANEXO 1 Tutorial de Instalação do Snort.............................................................................150
ANEXO 2 Conteúdo do DVD...................................................................................................155
INTRODUÇÃO
A segurança na Internet sempre foi motivo de preocupação, tanto para usuários finais
quanto para grandes corporações. Isso deve-se em parte, à enorme desconfiança na utilização
de uma rede pública para transmitir dados como senhas de banco, números de cartão de
crédito e outras transações relacionadas ao comércio eletrônico.
Paralelamente ao aumento dos negócios on-line, o número de ataques às redes só tem
aumentado. Vírus de computador, worms, spywares, exploits, e é claro, hackers e scriptkids;
são alguns exemplos de ameaças que se proliferam na Internet todos os dias. Ataques
automatizados também possibilitaram aos usuários iniciantes, ou com pouco conhecimento,
explorar sem muito esforço o número crescente de máquinas vulneráveis.
A conseqüência desse cenário é o consumo cada vez maior de soluções que prometem
alguma segurança. As abordagens de segurança compõe uma lista, quase sem fim; e variam
desde a instalação de firewalls de rede, passando pela configuração segura (hardening) de
servidores, anti-vírus corporativo, anti-spyares, anti-rootkit, verificadores de integridade, até o
desenvolvimento de aplicações baseadas em rígidas metodologias e testes de segurança.
Apesar de muitas soluções serem adotadas separadamente, o conjunto de várias dessas
medidas pode garantir um nível aceitável de segurança.
Os sistemas de detecção de intrusão, ou simplesmente IDS, procuram antecipar possíveis
tentativas de invasão através de detecção na rede de padrões de ataques conhecidos ou pela
detecção de ocorrência bem sucedida de invasões através de mudanças significativas sofridas
nos sistemas.
O presente trabalho pretende mostrar a importância de soluções IDS na concepção atual
de segurança, através da apresentação de definições, classificação e aplicabilidade. Esta
abordagem tem como metodologia a análise de informações disponíveis em fontes
bibliográficas específicas, artigos e informações nos sites de segurança de maneira a
fundamentar as discussões e simulações propostas.
O trabalho foi dividido em cinco Capítulos. No primeiro foram introduzidos alguns
fundamentos inerentes à segurança computacional. Ressalta a importância das normas,
estratégias e mecanismos utilizados na infra-estrutura de segurança.
O segundo Capítulo pretende conceituar de forma genérica o tema, cobrindo as
terminologias, definições sobre Sistemas de Detecção de Intrusão, sua importância,
classificação, características, limitações e vulnerabilidades; apresentando ainda, algumas
tentativas de padronização de sua arquitetura.
O Capítulo três aprofunda a discussão do tema, apresentando as características de Sistema
de Detecção de Intrusão baseado em Host (Host based IDS - HIDS). Neste capítulo, também
são abordados conceitos sobre a anatomia de ataques a hosts, a classificação atual para os
intrusos, os principais tipos de ameaças, comparação entre as abordagens HIDS e NIDS. Este
Capítulo também cita, como exemplo, os HIDS Trippewire e OSSEC.
O Capítulo quatro apresenta a modalidade mais comumente encontrada de IDS, o IDS
baseado em rede (Network IDS - NIDS). Mostra o posicionamento do Sensor NIDS na rede,
conceitua anomalia de tráfego, ataques à redes de computadores e formas de resposta ativa às
ameaças. Como exemplo, é abordado o NIDS Snort, software open source utilizado no
último capítulo, o qual foi reservado à simulações de testes de detecção de intrusão.
O quinto e último Capítulo, mostra a metodologia de testes e os resultados obtidos com as
simulações de detecção de intrusão usando máquinas virtuais e o NIDS Snort.
Sistemas de Detecção de Intrusão são ferramentas indispensáveis para organizações que
desejam adotar um modelo que permita analisar intrusões de forma centralizada, ou
distribuída. Monitoram as ameaças às redes, automatizando o processo de análise dos
incidentes de segurança, o que agiliza o acompanhamento e a resposta aos ataques.
1 FUNDAMENTOS DE SEGURANÇA COMPUTACIONAL
Desde sua criação no fim dos anos 60, a Internet tem evoluído continuamente em sua
proposta de solução para integração entre redes de computadores, sistemas e pessoas. Além de
um elemento de integração, esta tecnologia proporcionou ainda a expansão do fluxo de
informações, transformando cada vez mais a sociedade, seus hábitos e processos.
Esta pretenção original por conectividade universal, no entanto, foi sufocada por diversos
problemas de segurança. Pois, a estrutura dos protocolos utilizados na Internet limita a
possibilidade de prevenir, identificar ou detectar possíveis ataques, tornando portanto, todos
os sistemas sujeitos a ameaças internas, externas, acidentais ou maliciosas.
Neste contexto, os ataques podem ocorrer por falhas de segurança não previstas ou, até
mesmo, através de sistemas não protegidos ou com vulnerabilidades desconhecidas pelos
administradores.
Estatísticas compiladas pelo Centro de Estudos, Resposta e Tratamento de Incidentes de
Segurança no Brasil (CERT.Br)1, apresentadas no gráfico da figura 1.1, demonstram este
cenário através do aumento no número de incidentes de segurança reportados no período de
1999 a 2007.
1. Grupo de resposta a incidentes de segurança para a Internet brasileira (mantido pelo NIC.br).
17
Figura 1.1. Total de Incidentes reportados ao CERT.Br de 1999 a 2007.
O uso de recursos da Internet nas empresas trouxe, portanto, novas vulnerabilidades e
desafios a serem vencidos. Se não bastassem as preocupações existentes com espionagem
industrial, fraudes, erros e acidentes, as empresas precisam investir também em segurança
contra hackers2, invasões, vírus de computador, cavalos de tróia3 e outras ameaças que
penetram através desta nova porta de acesso.
Outra característica decorrente ao crescimento da Internet, é que o tempo de propagação
dos ataques têm reduzido ao passo que a abrangência dos danos causados tem aumentado de
forma significativa. A Figura 1.2 demonstra que houve uma mudança no objetivo dos ataques,
pois em sua primeira geração, as ameaças tinham como alvo máquina local; atualmente as
ameaças visam a prejudicar o funcionamento da infra-estrutura das redes, causando um
verdadeiro colapso, uma vez que quase todas as operações ligadas aos computadores são
fundamentadas no funcionamento das redes. Além disso, o tempo de impacto para que a
ameaça se alastre pela infra-estrutura reduziu de semanas para minutos, e tende a ser em
segundos futuramente.
2 Hacker. usuário com grande habilidade técnica em tecnologia que consegue acessar informações restritas, reservadas ou confidenciais, sem autorização, empregando meios ilícitos
3 Cavalo de Tróia. Um programa malicioso, enviado à vítima como um arquivo inofensivo, que possa levar o usuário a executá-lo. Uma vez instalado, o trojan pode abrir uma ou várias portas do computador para que quem o enviou possa ter acesso remoto.
18
Figura 1.2. Evolução das ameaças computacionais levando em consideração a velocidade de propagação, adaptado de [GOMES, 2006]
Um claro exemplo da evolução das ameaças às redes pode ser observado nos dois casos
de worms4 que se espalharam pela Internet nos anos de 2001 e 2003: o Code Red e o SQL
Slammer. O worm Slammer, que infectou vários sistemas em 2003, tem como objetivo atingir
sistemas Microsoft SQL Server 2000 e MSDE 2000 que não tenham sido atualizados com o
patch de segurança, provocando intenso volume de tráfego na rede, tanto na Internet como em
redes privadas internas. O worm Code Red foi observado pela primeira vez em 19 julho de
2001, quando multiplicou-se mais de 250 mil vezes, em aproximadamente nove horas. Cada
cópia do worm varreu a Internet à procura de servidores com Windows NT ou Windows 2000
que não tinham instalado o patch de segurança da Microsoft. As Figuras 1.3 (a) e (b) a seguir,
demonstram que o tempo de propagação dessas ameaças aos seus alvos diminuiu de 24 horas
para apenas 30 minutos (fonte: www.caida.org).
Figura 1.3 (a) Worm Code Red infectou mais de 302.500 hosts em pouco mais de nove horas em 19 de junho de 2001.
4 Worm é um vírus de computador que se dissemina criando cópias funcionais de si mesmo (ou de partes) em outros sistemas. A propagação se dá por conexão de rede ou anexos de e-mail.
19
1ª GeraçãoBoot viruses
1ª GeraçãoBoot viruses
2ª GeraçãoVírus de macro;mail bomb;Negação de Serviço (DoS);Danos limitados;
3ª GeraçãoNetwork DoS;Blended threat;(Worm e virus + trojan)Widespread System Hacking;
Próx. GeraçãoSubversão de mecanismos prevenção;Danos à infra-estrutura;Massive Worms;DDoS;Mais ameaças;
Semanas Dias Minutos Segundos
Computador
Redesindividuais
Várias redes
Redes regionais
Tempo de impacto na infra-estrutura global
Obj
etiv
o e
abra
ngên
cia
das
amea
ças
Figura 1.3 (b) Worm SQL Slammer em menos de 30 minutos infectou mais de 74.800 hosts em 25 de janeiro de 2003.
Como resposta a tantas ameaças faz-se necessário conhecer, desenvolver procedimentos e
ferramentas para enfrentar esses novos desafios. Este capitulo, é uma preparação para o estudo
a ser desenvolvido no presente trabalho, apresentando uma breve discussão sobre os riscos
associados as redes de computadores, conceitos sobre segurança computacional, políticas e
mecanismos de proteção .
1.1 Princípios de segurança da informação
No contexto da tecnologia da informação, pode-se definir genericamente segurança como
a tentativa de minimizar a vulnerabilidade de bens (qualquer coisa de valor) e recursos, sendo
vulnerabilidade qualquer fraqueza que possa ser explorada para atacar um sistema [SOARES,
1995]. Por outro lado, a segurança visa também aumentar a produtividade dos usuários através
do maior controle sobre os ativos de informática, viabilizando o uso de aplicações críticas nas
empresas.
Os três conceitos principais que caracterizam a segurança da informação, segundo o
padrão ABNT(2001) NBR ISO/IEC, são resumidos pela sigla CIA (do inglês “Confidentiality,
Integrity and Availability”), que em português significa confidencialidade, integridade e
disponibilidade; descritos a seguir:
Confidencialidade: proteção contra leitura ou cópia da informação por quem não
está explicitamente autorizado por seu proprietário. Esta proteção deve incluir as
informações de propriedade do usuário bem como as geradas em razão do uso de
20
algum sistema e que possam permitir a inferência de informações confidenciais, por
exemplo, registros de acesso ou identificações de estações de trabalho;
Disponibilidade: proteção de qualquer serviço ou sistema contra a degradação ou
não disponibilidade sem autorização. Há casos onde a disponibilidade da informação
é considerada vital para o correto funcionamento da organização, como por exemplo,
sistemas bancários ou ainda sistemas médico/hospitalares;
Integridade: proteção de qualquer informação ou sistema contra remoção ou
alteração de qualquer espécie sem a permissão explicita de seu proprietário. Ou seja,
é a proteção dos dados ou informações contra modificações intencionais ou
acidentais não-autorizadas;
Tais conceitos são conhecidos como atributos básicos em segurança da informação,
princípios que orientam a análise, o planejamento e a implementação da segurança para um
determinado conjunto de informações que se deseja proteger. A combinação em proporções
apropriadas destes fundamentos facilita o suporte para que as empresas alcancem os seus
objetivos, tornando os sistemas de informação mais seguros e confiáveis.
Outra definição utilizada pelo National Computer Security Center (NCSC)5 identifica um
ambiente computacional como seguro quando se estabeleçam mecanismos para garantir a
confidencialidade e a integridade dos dados e/ou comunicações sem que as mesmas se tornem
indisponíveis aos usuários. Desta forma, uma ameaça à segurança da informação alcançará
êxito quando ocorrer a quebra de uma ou mais de suas três propriedades fundamentais.
Outros autores, entretanto, defendem que para considerar uma informação segura, o
sistema deve ainda obedecer os seguintes aspectos:
Autenticidade: garante que a informação ou o usuário da mesma é autêntico; atesta
com exatidão, a origem do dado ou informação;
Não repúdio: trata da possibilidade de identificar a autoria de determinada ação sem
equívocos, ou seja, o não repúdio fornece prova irrefutável da realização de uma
5 http://www.nsa.gov/
21
ação específica pelo usuário, como transferir dinheiro, autorizar uma compra ou
enviar uma mensagem;
Privacidade: é a capacidade de um usuário realizar ações em um sistema sem que
seja identificado,onde a informação pode ser considerada confidencial, mas não
privada. Por este motivo, este conceito foge do escopo de confidencialidade. Uma
informação privada deve ser vista, lida, alterada somente pelo seu dono;
Auditoria: consiste na rastreabilidade dos diversos passos que um negócio ou
processo realizou ou que uma informação foi submetida, identificando os
participantes, os locais e horários de cada etapa. Auditoria em software significa uma
parte da aplicação, ou conjunto de funções do sistema, que viabiliza uma auditoria;
Legalidade: garante a legalidade (jurídica) da informação; aderência ou
compatibilidade de um sistema à legislação, onde todos os ativos estão de acordo
com as cláusulas contratuais pactuadas ou a legislação política institucional, nacional
ou internacional vigentes.
Em [STONEBURNER, 2001] é sugerido que a segurança é obtida somente através da
relação e correta implementação de quatro princípios da segurança: confidencialidade,
integridade, disponibilidade e auditoria. A próxima figura 1.4 ilustra a relação entre os
princípios para a obtenção da segurança da informação.
Figura 1.4. Segurança da Informação através da correlação entre quatro princípios básicos,
adaptado de [LAUREANO, 2005]
22
A confidencialidade é dependente da integridade, pois se a integridade de um sistema for
perdida, os mecanismos que controlam a confidencialidade não são mais confiáveis.
A integridade é dependente da confidencialidade, pois se alguma informação confidencial
for perdida (senha de administrador do sistema, por exemplo) os mecanismos de integridade
podem ser desativados.
Auditoria e disponibilidade são dependentes da integridade e confidencialidade, pois estes
mecanismos garantem a auditoria do sistema (registros históricos) e a disponibilidade do
sistema (nenhum serviço ou informação vital é alterado).
Uma vez estabelecidos tais princípios, o nível de segurança desejado pode ser
consubstanciado em uma “política de segurança”, a qual deve estabelecer normas e
mecanismos para que este nível desejado seja seguido, monitorado e mantido.
1.1.1 Outros conceitos importantes
Existem outras terminologias importantes relacionadas à segurança da informação. Nesta
seção, serão apresentados alguns termos mais usados neste estudo, acompanhados de suas
respectivas descrições.
Ativo: um recurso de valor, como os dados de um banco de dados ou do sistema de
arquivos, ou um recurso do sistema;
Vulnerabilidade: a vulnerabilidade pode ser definida como uma falha no projeto,
implementação ou configuração de um software ou sistema operacional que, quando
explorada através de um ataque, resulta na violação da segurança de um sistema;
Ameaça: qualquer ação, acontecimento ou entidade que possa agir sobre um ativo,
através de uma vulnerabilidade e conseqüentemente podendo prejudicar de forma
temporária ou permanente o funcionamento deste sistema. As ameaças apenas
existem se houverem vulnerabilidades, sozinhas pouco representam. Segundo Soares
[SOARES, 1995], uma ameaça consiste na possibilidade de violação da segurança de
23
um sistema. Em inglês, é utilizado o termo “threat” para definir ameaça, podendo
existir vários tipos de threat [SHIREY, 2000]:
a) Ameaça inteligente: circunstância onde um adversário tem a potencialidade
técnica e operacional para detectar e explorar uma vulnerabilidade de um
sistema;
b) Ameaça: potencial: existe quando houver uma circunstância, potencialidade,
ação ou evento que poderia romper a segurança e causar o dano;
c) Ameaça de Análise: uma análise da probabilidade das ocorrências e das
conseqüências de ações prejudiciais a um sistema;
d) Conseqüências de uma ameaça: resultado da ação de uma ameaça. Inclui:
divulgação, usurpação, decepção e rompimento;
Além da classificação por tipo, conforme descrito em [SÊMOLA, 2003], as ameaças
podem ser divididas quanto a sua intencionalidade:
a) Naturais: decorrentes de fenômenos da natureza, como incêndios naturais,
enchentes, terremotos, tempestades, poluição, etc;
b) Involuntárias: ameaças inconscientes, quase sempre causadas pelo
desconhecimento. Podem ser causados por acidentes, erros, falta de energia, etc;
c) Voluntárias: ameaças propositais causadas por agentes humanos como hackers,
invasores, espiões, ladrões, criadores e disseminadores de vírus de computador,
incendiários.
Interceptação: considera-se interceptação o acesso a informações por entidades não
autorizadas (violação da privacidade e confidencialidade das informações);
Interrupção: pode ser definida como a interrupção do fluxo normal das mensagens
ao destino;
24
Modificação: consiste na modificação de mensagens por entidades não autorizadas,
violação da integridade da mensagem.
Personificação: considera-se personificação a entidade que acessa as informações
ou transmite mensagem se passando por uma entidade autêntica, violação da
autenticidade;
Ataque ou exploração: a RFC 28286 conceitua o termo ataque como uma ação
inteligente que ameaça a segurança de um sistema, um ataque pode ter sucesso ou
não e estará explorando uma vulnerabilidade no sistema alvo ou inerente aos
protocolos. A concretização de uma ameaça, ocasionada por uma ação intencional,
configura um ataque. Um ataque pode ser ativo, tendo por resultado a alteração dos
dados; passivo, quando objetiva a liberação dos dados; ou destrutivo visando à
negação do acesso aos dados ou serviços. O fato de um ataque estar acontecendo não
significa necessariamente que ele terá sucesso. O nível de sucesso de um ataque
depende da vulnerabilidade do sistema ou da atividade e da eficácia de contra
medidas existentes.
1.2 Política de Segurança
De acordo com o RFC 2196(The Site Security Handbook)7, uma política de segurança
consiste num conjunto formal de regras que devem ser seguidas pelos utilizadores dos
recursos de uma organização.
Uma política de segurança forma a base para o estabelecimento do que é ou não
permitido. Formalmente, uma política de segurança é uma afirmação que divide os estados do
sistema em um conjunto de estados autorizados, ou seguros, e em um conjunto de estados não
autorizados, ou não seguros. Dessa forma, um sistema seguro é um sistema que se inicia em
um estado autorizado e evolui entre estados seguros.
6 http://tools.ietf.org/html/2828
7 http://tools.ietf.org/html/2196
25
Infelizmente, na prática, alguns problemas comprometem a garantia ou manutenção deste
conceito. Frequentemente é comum encontrar uma resistência coletiva dentro das
organizações para com as medidas de segurança. Pois, lamentavelmente, na maioria dos casos,
aspectos que propiciam a facilidade no acesso à informação têm um peso maior, em
detrimento de valores como a reputação da empresa, a integridade, a confiabilidade e a
disponibilidade dos dados [CAMPELLO e WEBER, 2001].
Contrariamente à esta postura, uma política de segurança deve estabelecer mecanismos e
normas de controle que permitam criar níveis adequados de proteção à informação. A política
de segurança fornece, portanto, um enquadramento para a implementação de mecanismos de
segurança, objetivando definir processos de segurança adequados para evitar que as ameaças
tenham sucesso.
Em síntese, podemos concluir que as políticas de segurança normalmente descrevem as
relações, direitos e deveres que usuários e equipes técnicas devem estabelecer para com os
sistemas. A política de segurança da informação visa ainda identificar riscos e implantar
medidas que de forma efetiva tornem estes riscos gerenciáveis.
1.2.1 Normas existentes
Uma das primeiras normas definidas foi a BS7799 - Code of Practice for Information
Security Management. Após um trabalho intenso de consulta pública e internacionalização,
em primeiro de dezembro de 2000 a norma foi aceita como um padrão internacional ISO/IEC
17799:2000.
A aderência ao ISO/IEC 17799 permite que as empresas demonstrem publicamente que
foi feito um investimento no sentido de proteger a Confidencialidade, Integridade e
Disponibilidade das informações. O padrão define 127 controles que permitem identificar as
necessidades de segurança apropriadas para o ambiente definido como escopo do sistema de
gerência de segurança a ser implantado. A norma ISO/IEC 17799 apresenta controles de
segurança para implantação e administração de sistemas e redes, guias para implantação de
Políticas de Segurança, planos de continuidade de negócio e aderência à legislação.
26
Em abril de 2001, a versão brasileira da norma ISO foi posta em consulta pública. A
ABNT homologou a versão brasileira da norma, denominada NBR ISO/IEC 17799 em
setembro de 2001.
A atual norma inglesa BS7799 não se limita a aspectos meramente técnicos de
processamento, IT e redes, mas abrange todos os aspectos de segurança da organização,
alguns destes itens são descritos a seguir:
a) Política e Organização da Segurança;
b) Gestão da Segurança Física e Controle de Acesso;
c) Procedimentos de Desenvolvimento e Manutenção de Sistemas;
d) Gestão da Continuidade de Negócios;
e) Aderência à Legislação.
1.2.2 Formas e metodologias de proteção
Uma importante estudo sobre modalidades de proteção aos sistemas foi proposto por
[ZWICKY, 2000], o qual ressalta as seguintes formas possíveis de proteção:
a) Nenhuma segurança: a abordagem mais simples, representada pela ausência de
preocupações com segurança;
b) Segurança por obscuridade: freqüentemente adotada, essa abordagem baseia-
se na premissa do desconhecimento, ou seja, considera um sistema seguro pelo
simples fato de ninguém conhecê-lo (sua existência, seus métodos, seu conteúdo,
etc). Exemplos práticos dessa abordagem são algoritmos criptográficos cujo
segredo é o próprio método, sistemas operacionais de código fechado, etc;
c) Segurança baseada na máquina: significa concentrar todos os esforços de
segurança nas máquinas propriamente ditas, ou seja, tentar minimizar as
ameaças existentes em cada um dos computadores existentes em um sistema. O
principal problema dessa abordagem é a diversidade e o número de máquinas
existentes em grandes corporações, dificultando muito a manutenção dos
mecanismos utilizados;
27
d) Segurança baseada em rede: significa reforçar o controle dos acessos de rede a
todas as máquinas e serviços do sistema, evitando preocupações máquina-a-
máquina. Como desvantagem, esse método impossibilita o acesso a eventos
ocorridos exclusivamente dentro das máquinas, como é o caso de acessos
indevidos a determinados dispositivos, tentativas locais de subversão, etc.
Além da classificação proposta por ZWICKY, outro estudo citado por [HALME e BAUER,
1995], enumera seis estágios gerais, não exclusivos, visando proteger uma organização de
ataques:
Preempção: atacar a ameaça de segurança antes que ela tenha chance de disparar seu
ataque. Esta medida pró-ativa é difícil de ser praticada uma vez que muitos ataques
são criados e não podem ser previstos;
Prevenção: eliminar ou reduzir de modo significativo todas as possibilidades de
sucesso de um ataque específico. Exemplos deste método são as identificações e
autorizações de usuários, controle de acesso e criptografia de informações. Este
método de prevenção é necessário, mas não necessariamente suficiente, uma vez
que, na medida em que os sistemas tem se tornado mais complexos, poderão existir
vulnerabilidades desconhecidas e exploráveis nos sistemas, originadas a partir de
vários erros de programação (bugs). Um exemplo clássico, é proliferação de vírus e
worms que visam explorar os erros de programação nos Sistemas Operacionais;
Desencorajamento: intimidar os atacantes para que os mesmos desistam dos
ataques, através do aumento de riscos e conseqüências negativas. No entanto, parece
óbvio que se os recursos protegidos são muito importantes, ou se as violações
dificilmente são descobertas, os atacantes raramente se assustarão ante as
dificuldades. Para o invasor, o desafio e a chance de adquirir conhecimentos e
notoriedade compensa os riscos;
Detecção: identificar tentativas de intrusão de modo que uma resposta apropriada
possa ser invocada. Este recurso pode também auxiliar os administradores na
28
identificação de incidentes, recuperação de danos e rastreamento de ações do
atacante. Ex: utilização de detectores de intrusão baseados em host ou rede;
Deflexão: tem por objetivo iludir ou atrair a atenção do invasor para um host
previamente projetado para a finalidade de ser invadido(conhecido como pote de mel
ou honey pot), de modo que nenhum dano real aconteça, levando-o a acreditar que
seu ataque foi bem sucedido. Este recurso possui a vantagem de se criar um
ambiente controlado para estudar a ação do atacante. A maior dificuldade, no
entanto, é configurar o “pote de mel” de modo a torná-lo mais realístico possível
para enganar um atacante experiente;
Contramedida: procedimento de segurança que trata uma ameaça e reduz um risco.
Corresponde ao conjunto de ações que pretende ativamente responder às intrusões
enquanto elas estão ocorrendo. A efetividade de uma contramedida é diretamente
proporcional à precisão da detecção de uma intrusão. Uma ação errônea em um
usuário normal, no entanto, pode negar ao usuário o acesso legítimo aos serviços.
Estas técnicas de contramedidas podem cooperar mutuamente de forma a estabelecer
múltiplas camadas de proteção aos recursos do sistema, como ilustrado na figura 1.5 a seguir.
Figura 1.5. Técnicas de contra-intrusão, adaptado de [JORGE, 2006].
1.2.3 Estratégias de segurança
No contexto de estratégias a serem adotadas em segurança da informação, [ZWICKY,
2000] descreve métodos importantes visando tornar o sistema mais robusto:
29
Preempção
Prevenção Externa
Desencorajamento Externo
Prevenção Interna
Desencorajamento Interno
Detecção
DeflexãoContra
Medidas
Recursosdo
SistemaPote de
Mel
Tentativas de intrusão
Perímetro do Sistema
Least privilege: segue o princípio do “privilégio mínimo”, onde qualquer objeto
(usuário, programa, sistema, etc) possui apenas os privilégios estritamente
necessários para executar as suas tarefas;
Defense in depth (defesa em profundidade): utilizar redundância em mecanismos de
segurança, caso um componente falhe há outro(s) garantindo a segurança. De acordo
com este princípio, não se deve depender de apenas um mecanismo de segurança não
importando quão forte ele pareça ser. Ao invés disso, recomenda-se que sejam
utilizados múltiplos mecanismos de segurança e que estes estejam configurados no
nível mais alto possível de segurança e redundância. A figura 1.6 a seguir exibe um
diagrama genérico que ilustra a aplicação deste conceito, onde a defesa é obtida pela
estratégia de divisão da segurança nas seguintes camadas: prevenção do sistema
(por exemplo, através de um firewall); detecção de intrusão (usando um sistema de
Detecção de Intrusos) e mecanismos tolerantes à falha.
Figura 1.6. defense in depth usando estratégia de defesa em camadas.
Choke point: é o ponto de acesso por onde tudo que transita entre a rede interna e
externa deve necessariamente passar; portanto é um ponto que possibilita um alto
controle e monitoramento. A figura 1.7 a seguir, ilustra o conceito de choke point,
usando um servidor firewall como ponto único de acesso à rede:
Figura 1.7. choke point representado por um servidor Firewall.
Weakest link: consiste em determinar qual o ponto mais fraco no sistema de
segurança;
30
Tolerância Detecção Prevenção
Fail safe: em caso de falha o sistema se mantém em um estado seguro (indisponível,
mas seguro);
Universal participation: a participação de todos os usuários, funcionários, etc, é
indispensável para que um bom sistema de segurança seja eficiente. A educação dos
usuários é fundamental para o sucesso na segurança (“do que adianta um forte
sistema de segurança quando os usuários utilizam senhas facilmente dedutíveis?”);
Diversity of defense: investir na diversidade dos sistemas de segurança dificulta o
trabalho do atacante porque ele precisa explorar as vulnerabilidades de sistemas
diferentes;
Simplicidade: sistemas simples são mais seguros. A complexidade esconde falhas
difíceis de serem percebidas.
A estratégia fail safe reserva ainda duas posturas de proteção possivelmente adotadas:
a) postura padrão de negação: especificar apenas o que é permitido e proibir o
resto. Possui como característica básica a prudência, ou seja, estabelece que
“tudo aquilo que não é expressamente permitido é proibido”;
b) postura padrão de permissão: especificar somente o que é proibido e permitir o
resto. Esta postura utiliza o conceito de permissividade, ou seja, “tudo aquilo que
não é expressamente proibido é permitido”.
Certamente a postura mais segura é a prudente. Deve-se permitir somente aquilo que se
considera seguro. Do contrário, falhas em serviços não seguros e legais podem ser facilmente
aproveitadas caso sejam descobertas.
1.3 Mecanismos de proteção
Atualmente, existem vários mecanismos propostos para implementação das técnicas de
segurança citadas nas seções anteriores, que utilizam desde medidas simples, como
autenticação, até ferramentas complexas como firewall e detecção de intrusão.
31
Vale ressaltar que, assim como nenhum sistema é totalmente seguro, nenhum mecanismo
de segurança é perfeito. Pois tão importante quanto o balanceamento de vantagens e
desvantagens das diferentes abordagens, é a complementação destes mecanismos para a
criação de um ambiente mais controlado e confiável.
Os dispositivos são classificados como físicos ou lógicos, descritos a seguir:
Controles físicos: limitam o contato ou acesso direto a informação ou a infra-
estrutura que a suporta. Ex: Portas, trancas, paredes, blindagem, etc;
Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que
encontra-se em ambiente controlado, geralmente eletrônico, e que, de outro modo,
ficaria exposta a alteração não autorizada. São exemplos de controles lógicos:
criptografia, assinatura digital, mecanismos de garantia da integridade da
informação (hashing), firewalls, Sistemas de Detecção de Intrusão (IDS), etc.
Com o uso destes recursos, a proteção das redes contra os diversos tipos de ataques
existentes torna-se trivial. Pois, em muitos casos, as simples correções de segurança detêm um
grande número de ataques e invasões. Por exemplo, um firewall bem configurado e um
antivírus atualizado conseguem fazer um bom serviço de proteção à rede. Mas existem
diversas outras alternativas que podem ser utilizadas para garantir ainda mais a segurança das
redes de computadores. Nas seções a seguir, é descrita a lista de doze diferentes itens que
podem ser usados para garantir a segurança das redes, de acordo com o instituto americano
NIST8 (1999).
1.3.1 Atualização do Sistema Operacional
As empresas ou comunidades responsáveis por seu desenvolvimento e distribuição
liberam normalmente atualizações para fixar problemas em seus sistemas. A não atualização
dos sistemas pode facilmente permitir que intrusos invadam a rede devido a inúmeras
vulnerabilidades. A melhor alternativa portanto, é sempre executar atualizações para corrigir
eventuais problemas nos computadores mais importantes da rede e então implementar outras
soluções de segurança para manter a rede segura;
8 National Institute of Standards and Technology - http://www.nist.gov/
32
1.3.2 Detecção de Vírus
Programas antivírus são essenciais para a segurança das redes de computadores. A
solução mais efetiva, neste caso, é possuir o produto instalado em todos os computadores e ter
uma política de atualização da base de dados dos antivírus, a partir de um servidor central,
evitando que as estações precisem executar esta tarefa individualmente;
1.3.3 Firewalls
O Servidor firewall é um dispositivo (ou conjunto) colocado entre duas ou mais redes,
que implementa uma barreira de segurança. Um firewall pode ser considerado um choke
point, pois todo o tráfego entre as redes interna e externa deve passar obrigatoriamente por
ele. Desta forma, é um ótimo local para a aplicação de trechos da política de segurança.
Estando bem configurado pode proteger a rede contra a maior parte dos ataques existentes
atualmente. A figura 1.8 a seguir ilustra a utilização de um firewall protegendo uma rede
composta por uma rede interna (Green), rede wlan (Blue) e rede de servidores DMZ (Orange);
Figura 1.8. Firewall protegendo uma rede de computadores.
33
1.3.4 Password crackers
Estes aplicativos são utilizados pelos invasores para descobrir as senhas de arquivos
criptografados. Descobrindo estas senhas, o invasor pode utilizá- las para acessar a rede e,
com alguns truques, obter acesso total sobre a rede. Estes aplicativos também podem ser
utilizados pelos administradores de rede para descobrir as senhas que são fracas ou fáceis de
serem descobertas afim de evitar que outros descubram estas senhas.
1.3.5 Criptografia
A criptografia baseia-se em algoritmos e métodos computacionais eficientes para garantir
a privacidade das informações trocadas entre duas entidades (a garantia de que somente as
duas partes envolvidas consigam compreender os dados transmitidos) e a autenticidade dessas
entidades (a garantia de que as partes envolvidas não terão suas identidades forjadas por uma
terceira). Comumente, os invasores invadem as redes com informações colhidas no tráfego
diário destas redes. Muitas das quais não estão criptografadas, tais como senhas e nomes de
usuários. Um invasor pode retirar estas informações e utilizá- las para obter acesso e controle
sobre a rede. Informações importantes, entretanto, podem ser criptografadas antes de serem
transmitidas na rede ou mesmo, determinadas conexões importantes com os servidores podem
ser protegidas por meio de criptografia.
1.3.6 Scanners de Vulnerabilidades
Estes aplicativos permitem fazer a execução de relatórios sobre as vulnerabilidades da
rede. Possuem uma base de dados com informações sobre ataques, vulnerabilidades, falhas e
atualizações a partir do qual permitem a realização destes relatórios.
1.3.7 Configuração dos Sistemas
A instalação dos sistemas operacionais, por padrão, possui diversos serviços que são
automaticamente habilitados. Muitas vezes, serviços que nem utilizados são, permitindo que
invasores se utilizem destes para penetrar na rede. A melhor solução é deixar somente os
serviços que serão realmente utilizados no sistema.
34
1.3.8 Detecção de Intrusão
Sistemas de detecção de intrusão são utilizados para monitorar um host ou uma rede
inteira e enviar alertas sobre eventos maliciosos. A monitoração da rede pode ser realizada
pela captura de pacotes através da interface de rede em modo promíscuo9. A figura 1.9 a
seguir ilustra um IDS de Rede (Network IDS – NIDS).
Figura 1.9. Servidor IDS monitorando a rede interna e externa ao firewall.
1.3.9 Ferramentas de Descoberta de Rede e Scanners de Portas
Sistemas como estes fazem o mapeamento da rede, identificando serviços que estão sendo
executados em cada computador. Este tipo de ataque permite encontrar vulnerabilidades e
identificar quais são os computadores menos protegidos, sendo que estas ferramentas podem
ser utilizadas pelos administradores para documentar os ativos e serviços disponíveis, bem
como descobrir as falhas das próprias redes.
1.3.10 Política de segurança
É um conjunto de diretrizes, normas e procedimentos que devem ser seguidos e visam
conscientizar e orientar todos os colaboradores da empresa do uso seguro do ambiente
informatizado, a partir do qual é possível identificar o nível de segurança que a empresa quer
alcançar.
9 Modo promíscuo, em relação à Ethernet, é um tipo de configuração de recepção na qual todos os pacotes que trafegam pelo segmento de rede ao qual o receptor está conectado são recebidos pelo mesmo, não recebendo apenas os pacotes endereçados ao próprio.
35
1.3.11 Respostas à Incidentes
Todas as redes, não importam o quão seguras elas sejam, possuem eventos de segurança e
a equipe de administração da rede deve saber como manipular estes eventos, mesmo antes de
algum evento acontecer. É geralmente constituído por um plano de contingência e de
resolução de problemas.
1.3.12 Testes de Negação de Serviço
Estes tipos de ataques são muitos comuns na Internet. Servidores são desligados, serviços
são parados, etc. Podem ser muito danosos, especialmente quando o intruso é esperto o
suficiente para lançar ataques de negação de serviço que não podem ser rastreados.
Atualmente, existem empresas que podem ser contratadas para realização de ataques deste
tipo, permitindo que os administradores visualizem quais são os pontos mais vulneráveis da
suas redes.
36
2 SISTEMAS DE DETECÇÃO DE INTRUSÃO
Sistemas de computação seguros, visam estabelecer níveis de operação para prover
confidencialidade, disponibilidade e integridade aos dados. Atualmente existe um elevado
número de ferramentas e sistemas de segurança que pretendem fornecer ao menos um destes
princípios. A maioria das empresas, entretanto, acaba ignorando os sistemas de detecção de
intrusão (IDS - Intrusion Detection System) concentrando suas defesas em soluções
preventivas como firewalls, anti-vírus, controle de acesso e criptografia. No entanto, existem
inúmeras limitações em abordagens baseadas apenas em prevenção:
É difícil, talvez impossível, construir um sistema útil totalmente seguro. Isto é, a
possível existência de alguma falha de projeto em um sistema com grande número
de componentes não pode ser excluída. Também não pode ser excluída a possível
ocorrência de falhas administrativas, tanto em sua prática quanto na configuração de
equipamentos e definição de políticas;
É impraticável jogar fora toda uma infra-estrutura (possivelmente não-segura) de
computadores, redes e software em favor de sistemas novos e seguro;
A filosofia de segurança baseada em prevenção reprime as atividades de um usuário,
sendo sua produtividade inferior em comparação a sistemas onde a operação é mais
“aberta”;
Sistemas baseados em criptografia não podem se defender contra chaves perdidas ou
roubadas e senhas quebradas;
37
Finalmente, um sistema seguro pode ainda ser vulnerável a usuários internos
legítimos (insiders) fazendo mau-uso de seus privilégios.
Este capítulo pretende aprofundar o tema detecção de intrusão, abordando conceitos
relacionados a intrusos e intrusões em sistemas computacionais, a importância do uso de
sistemas de detecção da intrusão, as limitações e vulnerabilidades encontrados nos IDS.
Pretende ainda ressaltar a sua classificação, descrever os padões disponíveis e os critérios de
interoperabilidade entre IDS.
2.1 Terminologias
Nesta seção, serão apresentados alguns termos utilizados no estudo de detecção de
intrusão acompanhados de suas respectivas descrições.
Intrusão: como definido em [HEADY, LUGER et al, 1990], “uma intrusão é qualquer
conjunto de ações que tentem comprometer a integridade, confidencialidade ou
disponibilidade dos dados e/ou do sistema”. De forma geral, alguns autores
conceituam um intruso como alguém que tenta invadir um sistema ou fazer mau uso
do mesmo. Para classificar e diferenciar as ações nocivas das legítimas, faz-se
necessária a definição de uma política de segurança.
As intrusões podem ser classificadas em:
a) Intrusão devido ao mau uso do sistema: são os ataques realizados a pontos fracos
do sistema, pontos este conhecidos. Eles podem ser detectados a partir da
monitoração de certas ações realizadas em determinados objetos;
b) Intrusão devido a mudança de padrão: são detectadas com a observação de
mudanças de uso em relação ao padrão normal do sistema. Primeiro monta-se
um perfil do sistema, em seguida, através de monitoração, procura-se por
divergências significantes em relação ao perfil construído;
38
Evento: um evento pode ser definido como todos os pacotes que podem ser
observados dentro de uma janela de tempo, uma transição de estado de seção, ou um
alerta gerado;
Detecção de Intrusão: processo automático de detectar e emitir alarmes quando
uma intrusão ocorre;
Cenário de ataque: seqüência de ataques que um atacante dispara com o objetivo de
atingir determinados propósitos;
Alerta: mensagem que um IDS gera quando detecta uma intrusão em andamento;
Correlação de Alerta: procedimento que automaticamente correlaciona alertas
baseados em suas similaridades e também reconstrói os cenários de ataque para que
mais informações contextuais e de ambiente possam ser fornecidas aos
administradores.
2.2 Conceitos e definições de IDS
Detecção de intrusão constitui o monitoramento de hosts ou fluxos de rede com o intuito
de identificar ações não autorizadas. Um IDS tenta detectar, no estado de um determinado
sistema (ou host) ou no tráfego de rede, padrões de comportamento que denotem a ocorrência
de ataques ou usos impróprios aos sistemas, alertando o responsável pelo sistema ou rede
sobre a ocorrência e a natureza destes incidentes.
As primeiras pesquisas sobre Sistemas de Detecção de Intrusão (IDS) datam de 1970,
cujo desenvolvimento constitui uma evolução dos antigos sistemas de auditoria, conhecidos
como sistemas especialistas, os quais definiam um processo de geração, gravação e revisão
dos registros cronológicos dos eventos dos sistemas [MAIA, 2005]. Por sua vez, [SILVA, 2007]
define detecção de intrusão como o processo de monitoração de eventos em sistemas
computacionais em rede ou no tráfego de rede, onde a verificação destes objetiva encontrar de
traços de intrusões, ataques, mau uso, ou ações que violem a política de segurança da
organização, a partir da qual os níveis de disponibilidade, confidencialidade e integridade de
sistemas de informação críticos, foram estabelecidos.
39
O objetivo de um IDS, portanto, é detectar e alertar, preferencialmente em tempo real,
sobre o uso indevido (ou não autorizado) de sistemas em decorrência de ameaças lógicas;
circunscritas a sistemas de computação presentes tanto em ambientes internos como externos
de uma organização [MAKHERJEE et al 1994]. O desenvolvimento de sistemas de detecção de
intrusão em tempo real é motivado, segundo [DENNING, 1987], por quatro fatores primordiais:
A maioria dos sistemas computacionais utilizados possui alguma falha de segurança
que pode ser explorada por usuários mal intencionados. Descobrir e corrigir todas
estas potenciais falhas de segurança não é viável técnica e comercialmente;
Inviabilidade de substituição de sistemas com falhas de segurança por versões mais
seguras;
Desenvolver sistemas completamente livres de falhas de segurança, mesmo que isto
seja uma meta crítica do projeto, é considerado tarefa virtualmente impossível;
Mesmo sistemas altamente seguros podem ser comprometidos por usuários internos
que abusem de seus privilégios.
Em seu artigo [DENNING, 1987] sugere um modelo de sistema de detecção de intrusão em
tempo real capaz de detectar interrupções, penetrações e outras formas de abuso. Esse modelo
baseia-se na hipótese de que uma violação de segurança pode ser detectada monitorando-se os
registros de auditoria dos sistemas à procura de padrões de uso anormal. O modelo proposto
por [DENNING, 1987] estabeleceu uma metodologia estruturada baseada em perfis, para
representar o comportamento dos usuários e sistemas. Esta metodologia baseava-se nas
seguintes premissas básicas para detecção de intrusão:
Observar o comportamento dos usuários e sistemas, para adquirir conhecimento
sobre esses eventos a partir dos registros de auditoria, como por exemplo a partir do
registro do sistema ou do tráfego da rede, objetivando de detectar comportamentos
anômalos;
40
O modelo de detecção deve ser independente do tipo de sistema, ambiente de
aplicação, vulnerabilidade do sistema ou tipo de intrusão, provendo a arquitetura
genérica para um sistema especialista de detecção da intrusão;
Através do ajuste fino de um sistema, as atividades intrusivas podem ser
identificadas e diferenciadas das atividades normais.
Uma das vantagens de um IDS em relação aos métodos tradicionais de análise de
incidentes é a possibilidade de correlacionar diferentes tipos de dados. Coletar informações
locais como os logs e o estado dos processos em execução, ou capturar na rede pacotes
destinados à determinada porta, são exemplos de ações distintas com um mesmo fim: gerar
dados que representem indícios de uma intrusão[SILVA, 2007].
2.3 Justificativa para o uso de IDS
O cenário atual indica que a vasta quantidade de aplicações financeiras disponíveis na
Internet e as vulnerabilidades de sistemas e protocolos possibilitam um cenário a cada dia
mais propenso a tentativas de intrusões.
Logo, sistemas vulneráveis podem ser atacados a qualquer momento, tornando imperativa
a necessidade de reconhecer e denunciar intrusões, a qual deve ocorrer o mais cedo possível,
preferencialmente em tempo real. Neste contexto, destacam-se as seguintes premissas:
a) Sistemas de detecção de intrusão podem ser úteis como complementos aos
mecanismos preventivos, detectando intrusões, gerando alertas e acionando
contramedidas sempre que as propriedades de segurança dos cada vez mais
complexos sistemas de informação estiverem sob ataque;
b) Um IDS pode fornecer avisos de que o sistema está sob ataque, mesmo não
sendo o sistema vulnerável ao ataque. Esses avisos podem ajudar os usuários a
modificarem sua postura defensiva para aumentar a resistência ao ataque;
c) IDS podem auxíliar na análise complexa de logs, a maneira mais comum para
descobrir indícios de anomalias, tanto em hosts como no tráfego de rede, é
41
através de análise nos logs como em estações de trabalho e servidores firewall. A
inspeção manual destes registros, que na maioria das vezes ocorre através de
linhas de comando, é considerada uma prática viável, mas com o tempo, torna-se
fatigante, pois estes arquivos de logs comumente apresentam tamanhos
consideráveis, os quais precisam de tempo e paciência para serem analisados.
Atuando como mecanismo de alerta o IDS, por sua vez, funciona como um repositório
automático de eventos de segurança, selecionando apenas ocorrências de interesse estratégico,
organizadas e classificadas segundo o grau de criticidade.
O IDS pode também disponibilizar formas de acesso mais rápidas aos dados através de
interfaces de consulta, o que automatiza a tarefa de gerar os dados para auditoria, diminuindo
assim o trabalho de criação de relatórios. Estes dados são extremamente úteis pois podem ser
usados para estabelecer relação de culpabilidade do atacante, assim como a extensão dos
danos causados.
2.4 Limitações
Não obstante as suas inúmeras vantagens, existem situações indesejáveis que podem
ocorrer em mecanismos de detecção de intrusão, cuja probabilidade de ocorrência pode
induzir a erros. Os mais comuns são conhecidos como falsos positivos, falsos negativos e
erros de subversão., descritos a seguir:
a) Falso positivo: termo utilizado para designar uma situação em que um IDS
aponta uma atividade como sendo um ataque quando na verdade não é.
Basicamente, um falso positivo é um alarme falso;
b) Falsos negativos: Em outras palavras, ocorre quando alguém compromete um
sistema monitorado por um IDS e o IDS não gera alertas para atividades que
deveriam ser classificadas como sendo a do comportamento de um ataque.
Falsos negativos podem aparentar uma falsa idéia de segurança. Entre os os
motivos para ocorrência de falsos positivos destacam-se:
42
■ As informações contidas nas regras ou configuração podem não ser
suficientes para a confirmação da ocorrência do ataque;
■ O IDS pode estar sobrecarregado pelo tráfego intenso na rede. Este
motivo dificulta o reconhecimento de padrões de ataque, que acabam
sendo ocultados pelo grande volume de informações na rede;
■ O ataque não identificado pode ser conseqüência de uma evasão (consiste
de técnicas para enganar uma ferramenta IDS fazendo com que o ataque
passe despercebido) bem sucedida.
c) Erros de subversão: este tipo de erro é mais complexo e parecido com falso
negativo. Um intruso pode usar o conhecimento sobre a operação interna do IDS
para alterar o seu estado, possivelmente permitindo comportamento anômalo do
sistema.
A ocorrência de falsos negativos é mais perigosa do que a ocorrência de falsos positivos,
uma vez que uma entidade está sendo vítima de um ataque que não é de conhecimento do
administrador da rede. Sem este conhecimento, o administrador não pode aplicar as medidas
de defesa necessárias para combater o ataque.
O erro de subversão, por sua vez, indica a necessidade do IDS estar corretamente
configurado, pois neste caso, apesar de ser uma ferramenta de alerta para redes que estão
sofrendo ataques, o IDS também podem ser o alvo. Logo, se um intruso suspeitar da
existência de um IDS numa rede de seu interesse, a primeira coisa que faria seria atacá-lo, na
tentativa de desabilitá-lo ou tornar sua configuração inútil para que não identifique suas ações.
Existem outros fatores limitantes à atuação das ferramentas de detecção de intrusão,
como:
Segmentação da rede (Redes Switched): Em redes com Switch ao invés de HUB
dificulta a captura de pacotes em arquiteturas centralizadas;
Limitação de recursos do sensor: processamento, armazenamento e memória que
são utilizados para se analisar o tráfego;
43
Redes com altas taxas de transmissão: além do problema de captura de pacotes em
Redes de Alta-Transmissão, a análise de regras pode exigir um processamento
considerável (ex: redes ATM, GigaBit Ethernet, etc);
Serviços criptografados (Virtual Private Network): torna-se inviável a um IDS
analisar os pacotes que estão transitando na interface e conseqüentemente muitos
ataques podem passar despercebidos. O mesmo aplica-se a serviços criptografados
como SSL e SSH.
2.5 Vulnerabilidades
Com sua crescente popularização, os IDS vêm se tornando alvos freqüentes de ataques.
Esta seção expõe os principais tipos de ataques conhecidos.
2.5.1 IP Spoofing
É uma técnica de subversão de sistemas baseados no protocolo TCP/IP que consiste em
mascarar (spoof) pacotes IP utilizando endereços de remetentes falsificados. Neste caso o
atacante pode se fazer passar por outra máquina e assim enganar o IDS.
2.5.2 Inserção
Neste tipo de ataque um atacante coloca na rede pacotes especialmente modificados que
são descartados pelo sistema alvo (por erros de CRC, por exemplo) mas tratados pelo IDS.
Com isso, pode-se iludir o detector inserindo pacotes que mascarem um ataque, ganhando a
aparência de uma ação autorizada. O sistema alvo, por sua vez, descarta esses pacotes forjados
e aceita somente aqueles que representam o próprio ataque.
A seguir são enumerados os tipos de ataques de inserção:
a) Long URLs: existem várias técnicas que visam melhorar o desempenho dos
IDSs. Uma dessas técnicas limita a quantidade de informações de uma requisição
HTTP a serem analisadas. Dessa forma, é possível a inserção de uma quantidade
44
suficiente de caracteres para mover o código de ataque para além do escopo da
análise do IDS, o que faz com que o ataque não seja detectado;
b) Self Reference: os caracteres “..” quando utilizados para acessar diretórios
conduzem o usuário para um diretório superior (diretório pai) ao diretório atual.
Já o caracter “.” faz referência ao diretório atual. Sendo assim, então
“c:\temp\.\.\.\.\.\” é equivalente a “c:\temp\”. O objetivo da técnica denominada
Self Reference é confudir os mecanismos de análise de assinaturas dos IDSs
enviando o seguinte tipo de requisição “Get /./cgibin/./phf”;
c) URL Encoding: conforme a RFC 261610, caracteres binários arbitrários podem
ser passados em uma requisição HTTP desde que estejam na seguinte notação:
%xx, onde xx corresponde ao valor hexadecimal do caracter. Uma vez que a
requisição “Get /cgi-bin/teste.cgi HTTP/1.0” seja codificada torna-se “Get /cg%69-b
%69n/t%65st%65.cg%69 HTTP/1.0”. Portanto, os IDSs, antes de analisarem,
qualquer string devem decodificar a mesma;
d) Multiple Slashes: os servidores web aceitam requisições contendo múltiplas
barras, slashes, como em “Get /cgi-bin//scripts///phf.cgi HTTP/1.0”. Contudo, existe a
possibilidade que alguns IDSs ao analisarem esses tipos de requisições falhem
devido ao fato de que a assinatura existente contenha apenas uma barra;
e) Parameter Hiding: uma requisição de página web pode conter informações
adicionais, parâmetros, que serão utilizadas para construir o conteúdo de páginas
dinâmicas. Esses parâmetros são determinados após um sinal de interrogação no
identificador uniforme de recursos, Uniform Resource Locator (URL), como em
“Get /index.htm?user=normal HTTP/1.0”. Alguns IDSs, a fim de otimizar o processo
de análise de pacotes ignoram todas as informações após a indicação de
parâmetros; sendo assim, há a possibilidade da inserção de um código malicioso
após essa parte da requisição;
10 http://www.ietf.org/rfc/rfc2616.txt
45
f) Reverse Traversal: consiste em uma tentativa de iludir os IDSs através de uma
requisição na qual existam referências a outros diretórios que não estejam
especificados na base de assinaturas dos IDSs. Por exemplo, a requisição “Get
/cgi-bin/phf.cgi HTTP/1.0”, é facilmente detectada. Alguns IDSs, porém, podem
desconsiderar esta mesma requisição quando requerida da seguinte forma: “Get
/cgi-bin/scripts/../phf.cgi HTTP/1.0”.
2.5.3 Evasão
Ao contrário do ataque de inserção, na evasão o atacante realiza o processo inverso: cria
pacotes que serão descartados pelo IDS e tratados pelo sistema alvo. Assim, um usuário mal
intencionado pode realizar um ataque utilizando pacotes que não serão vistos pelos detectores,
mas sim pelo sistema alvo. A evasão também existe uma classificação específica de ataques.
a) Case Sensitivity: refere-se a capacidade do IDSs de detectar requisições tanto em
letras maiúsculas, quanto em letras minúsculas (não são case sensitivity), caso
contrário o ataque será bem sucedido, pois sistemas operacionais tais como o
Windows 98 e Windows 2000 Server não diferem letras maiúsculas de letras
minúsculas (não são case sensitivity), ou seja, o arquivo phf.cgi pode ser
referenciado tanto como PHF.cgi quanto como PHF.CGI;
b) Method Matching: No intuito de explorar as vulnerabilidades de um script e,
ainda, tentar inviabilizar a detecção de tal ataque, pode-se utilizar métodos
alternativos de solicitações tais como Put, Head e Post. Dessa forma, embora
alguns IDSs identifiquem a requisição “Get /cgi-bin/phf.cgi HTTP/1.0” podem
vir a não identificar uma requisição do tipo “Put /cgi-bin/phf.cgi HTTP/1.0”;
c) Session Splicing: Diferentemente dos ataques de fragmentação, este ataque
consiste no envio de diversos pacotes. Por exemplo, a solicitação “Get /cgi-
bin/phf.cgi HTTP/1.0” pode ser dividida em múltiplos pacotes “Ge”, “t”, “/”,
“cgi”, “-bin”, “p”, “hf.c”, “gi”, “H”, “T”, “TP”, “/1”, “.0”. Sendo assim o
processo de detecção é ainda mais difícil e para que seja possível os IDSs devem
ser capazes de analisar uma seqüência de pacotes;
46
d) HTTP Mis-formating: Conforme a RFC 2616 a estrutura de uma requisição a
um servidor web deve seguir o seguinte formato: método <espaço> URL
<espaço> versão CRFL CRFL; onde CRFL corresponde a uma linha em branco
obrigatória. No entanto muitos servidores web aceitam requisições que não
estejam plenamente em conformidade com essas especificações, por exemplo:
método <tabulação> URL <tabulação> versão CRFL CRFL. Portanto existe a
possibilidade de iludir alguns IDSs, pois ao ser realizada a comparação entre o
pacote e a base de assinaturas de ataques não haverá relação, logo o pacote será
considerado uma solicitação normal e não um ataque;
e) DOS Directory Syntax: em plataformas Windows o separador de diretórios é
representado por ‘\’, enquanto que a especificação do protocolo HTTP determina
que o separador de diretórios web seja ‘/’. Isso faz com que toda vez que uma
requisição do tipo “Get /cgi-bin/phf.cgi” é enviada a um servidor web da
Microsoft, esse tenha que converter ‘/’ para ‘\’, de forma que a aplicação em
questão interprete a requisição como “Get \cgi-bin\phf.cgi”. Portanto, este
servidor aceita requisições como, “\cgi-bin\phf.cgi”, o que faz com que o IDS, ao
analisar o pacote HTTP, não encontra a assinatura de um ataque conhecido.
2.5.4 Negação de serviço ou Deny of Service (DoS)
Ataque cujo objetivo é esgotar os recursos de um serviço ou rede tornando-o inacessível
ou com tempo de resposta alto. Os ataques de negação de serviços são normalmente
executados usando ferramentas que enviam de forma indiscriminada requisições a um
determinado servidor, sobrecarregando os recursos do mesmo e, por vezes, tornando o sistema
inoperável. Na grande maioria desses ataques o endereço de origem é forjado (spoofing) e,
portanto, dificultam o processo de auditoria. Todos os sistemas conectados à Internet e que
estejam executando serviços de rede baseados no protocolo TCP estão sujeitos a ataques de
negação de serviços.
47
2.6 Classificação de IDS
Segundo a metodologia proposta por [SILVA, 2007, p 57], os sistemas de detecção de
intrusão podem ser classificados a partir do método de detecção utilizado, da arquitetura do
sistema, da freqüência de uso e do comportamento deste após a detecção de eventos suspeitos
ou intrusivos, conforme ilustrado na Figura a seguir (figura 2.1).
Figura 2.1 – Classificação de IDS
2.6.1 Método de Detecção
Quanto ao método utilizado para detectar ataques, o IDS pode ser baseado em assinatura
(abuso ou baseado em conhecimento) ou em anomalia (baseado em comportamento).
Anomalias são desvios do comportamento normal de uso e assinaturas, por outro lado, são
padrões conhecidos de ataques:
2.6.1.1 Baseado em assinatura
O método de detecção por assinatura, como também é conhecido, consiste no casamento
de padrões de dados contra bases de dados contendo padrões de ataques conhecidos referentes
48
a atividades hostis ocorridas no passado. São altamente eficientes na identificação de ataques
e vulnerabilidades conhecidos, mas fracos na identificação de novas ameaças aos sistemas.
2.6.1.2 Baseado em anomalia
O método de detecção por anomalia, por outro lado, busca dados raros ou não usuais em
um conjunto de dados, aplicando medidas estatísticas ou de inteligência artificial para
comparar atividades correntes de usuários, rede ou sistemas contra o conhecimento histórico
armazenado sobre estes elementos. Problemas comuns com os sistemas baseados em
anomalias são que requerem treinamento extensivo de dados históricos, através de algoritmos
de aprendizagem artificial, e tendem a possuir um custo computacional maior, porque devem
realizar medições freqüentes, necessitam de tempo suficiente para convergir e possuem a
sobrecarga de manter informação das ações realizadas no passado e ser atualizados a cada
novo comportamento dos sistemas, usuários ou rede. Isto resulta em armazenamento de
grande quantidade de dados e satisfatórios recursos de CPU para processá-los. A atualização
de várias métricas de perfil do sistema deve ser feita sob medida rede a rede, sistema a sistema
e, às vezes, usuário a usuário, devido ao fato dos padrões de comportamento e de uso do
sistema variarem muito.
O comportamento do tráfego normal é modelado por um método sistemático. O crescente
número de ataques requer uma atualização contínua da base de conhecimento dos sistemas de
detecção baseados em assinaturas. Além disto, existe também um número desconhecido de
vulnerabilidades descobertas mas não reveladas que não se encontram disponíveis para análise
e inclusão na base de conhecimento. A maioria dos ataques é polimorfa e os atacantes
exploram este polimorfismo para evadir os sistemas detectores.
A solução óbvia seria utilizar uma abordagem de detecção por anomalia, modelando o
que é normal ao invés do que é anômalo. Entretanto, apesar de vários sistemas de detecção
por anomalia baseados em host terem sido propostos e implementados, tanto na literatura
quanto na prática, a detecção por anomalia baseada em rede é ainda um campo aberto de
pesquisa.
49
Enquanto as assinaturas de ataques são, em geral, mais simples de processar e localizar,
os padrões de anomalia auxiliam mais freqüentemente na identificação de eventos suspeitos
na rede. Alguns IDSs combinam as técnicas de detecção por assinatura e por anomalia; estes
são conhecidos como sistemas híbridos.
A Figura 2.2 a seguir, representa bem a diferenciação entre essas duas classes de
detecção.
Figura 2.2: Diferenciação entre as classes de detecção de intrusão
2.6.2 Arquitetura
A arquitetura de um IDS está dividida em duas categorias. A primeira define a natureza
do alvo a ser monitorado: baseado em host, rede ou híbrido. A segunda categoria identifica o
tipo de localização ou composição formada pelo IDS: centralizado, hierárquico ou distribuído.
Estas definições são descritas a seguir.
2.6.2.1 Segundo o alvo
Um IDS pode ser classificado pelo tipo de alvo a ser monitorado, como baseado em rede,
baseado em host ou híbrido. Estas atividades de coleta de dados, no entanto, sejam elas feitas
no host ou na rede, determinam o tipo do IDS, baseado em host, em rede ou híbrido.
IDSs baseados em host (Host Intrusion Detection System - HIDS) utilizam dados
coletados na própria máquina: arquivos de log, registros de auditoria, integridade do
sistema de arquivos, etc; permitindo a determinação exata de quais usuários e
processos estão realizando operações maliciosas no sistema. É capaz de monitorar
50
acessos e alterações em arquivos de sistemas críticos, modificações nos privilégios
dos usuários, processos, programas que estão sendo executados, uso da CPU e
memória, entre outros eventos;
IDSs baseados em rede (Network Intrusion Detection System - NIDS) realizam a
monitoração do sistema através da captura e análise de cabeçalhos e conteúdo de
pacotes de rede, os quais podem ser comparados com padrões de ataques conhecidos
ou assinaturas previamente armazenadas em regras, arquivos ou bancos de dados, ou
com padrões normais do tráfego, para verificação de algum desvio do
comportamento normal da rede. A figura 2.3 ilustra uma rede utilizando IDS tanto
baseados em host (HIDS) como em rede (NIDS);
Figura 2.3. Rede utilizando IDS baseados em host (FileServer e MailServer) e rede (monitorando as interfaces interna e externa do firewall).
IDSs Híbrido: grande parte das ferramentas atuais de detecção de intrusão explora o
melhor das arquiteturas baseadas em host e rede, adotando soluções híbridas. Em
busca de equilíbrio entre desempenho, simplicidade, abrangência e robustez,
algumas implementações recentes provêem coleta de diferentes dados de hosts e do
tráfego de rede, e interagem mecanismos centralizados com distribuídos.
2.6.2.2 Segundo a localização
Uma arquitetura hierárquica para IDS consiste na distribuição parcial dos componentes
do IDS de modo que os módulos de detecção distribuídos subordinados se comuniquem
segundo a coordenação de gerentes centralizados, com a interação entre os módulos do
51
sistema sendo regida por fortes relações de subordinação. Esta abordagem surgiu para resolver
alguns problemas referentes à implementação de sistemas completamente distribuídos.
A figura 2.4 ilustra de forma genérica os módulos normalmente encontrados em um IDS.
De acordo com a arquitetura e localização destes módulos, estes sistemas podem ser
classificados em centralizados, hierárquicos e distribuídos.
Figura 2.4 Módulos de um IDS
Algumas vantagens próprias dos sistemas distribuídos continuam existindo enquanto a
solução de problemas, como a detecção de falhas nos módulos do sistema, é facilitada através
da estrutura hierárquica. A figura 2.5 ilustra o uso de IDS em uma arquitetura distribuída, cuja
rede monitorada por vários agentes (sensores) detectores de intrusão, geram informações que
servirão de base para os alertas. Neste caso a análise é fundamentada na correlação dos
diversos dados coletados pelos agentes.
52
Módulo deGerenciamento
Dados (raw data)
Sensor demonitoração
Módulo deDetecção
Exemplos
Alarmes
Base de Conhecimento Configurações
Fonte de informaçõesAmbiente monitorado
Figura 2.5. IDS em uma arquitetura distribuída através do uso de vários agentes (sensores).
Em contrapartida, aumentam as chances de ataques ao sistema, principalmente pela
criação de pontos únicos de falha, representados pelos módulos mais altos da cadeia de
hierarquia. Se um desses módulos falhar, todo o sistema pode tornar-se indisponível,
contrapondo-se à principal motivação no uso de sistemas distribuídos.
2.6.3 Comportamento pós-detecção
Esta classificação dos sistemas de detecção de intrusão leva em consideração as ações
tomadas quando um padrão de intrusão é detectado:
IDS passivo: sistemas de detecção de intrusão que, ao detectar um padrão de ataque,
apenas geram notificações (via e-mails, SMNP, etc) para um operador ou
53
administrador especialista através de console de gerenciamento informando sobre os
ataques e ameaças emergentes, não reagindo aos ataques.
IDS Ativo: projetado para realizar, por exemplo, bloqueio automático de conexões
provenientes ou enviar pacotes de término (pacotes TCP com flags FIN e RST) de
conexão para a fonte de fluxos de pacotes que sejam considerados intrusão. Podem
possuir integração com roteadores ou firewalls. Esta classe de sistema, também
conhecido como IPS (Intrusion Prevention System), tem sido alvo de pesquisas
recentes.
2.6.4 Segundo a freqüência de uso
Quanto à freqüência de uso, o IDS pode estar continuamente analisando os eventos de
rede (análise em tempo real) ou ser configurado para análise periódica dos eventos de rede
(análise off-line ou pos-mortem).
2.7 Entidades e padrões
Conforme visto nos tópicos anteriores, o sistema de detecção de intrusão (IDS) é uma
solução composta por diversos componentes como sensores, agentes e console de
gerenciamento que, muitas vezes, pertencem a fabricantes diferentes. Um grande esforço vem
sendo feito na tentativa de padronizar a nomenclatura e a função de cada um desses
componentes, principalmente para facilitar a interação entre diferentes ferramentas de
detecção de intrusão. Enquanto alguns elementos são aceitos em grande parte da literatura,
outros ainda são motivos de discrepâncias na definição da anatomia de um IDS.
O CIDF (Common Intrusion Detection Framework) foi uma tentativa inicial de
padronização de IDS e começou a ser desenvolvido em 1997. O objetivo era permitir a
intercomunicação entre dispositivos. No entanto, este projeto está parado desde o início do
ano 2000. Apesar de bastante citado na literatura científica, o CIDF não chegou a se
transformar em um padrão nem teve grande repercussão no mercado, mas encorajou a criação
54
do grupo Intrusion Detection Exchange Format (IDWG), pelo IETF11, cujos resultados serão
discutidos a seguir.
2.7.1 Intrusion Detection Exchange Format Working Group - IDWG
Em agosto de 1998 foi criado o grupo IDWG (Intrusion Detection Exchange Format
Working Group), pertencente ao IETF, o qual desenvolveu a proposta de padronização do
formato de dados e protocolos de comunicação para viabilizar a troca de informações, cujo
resultado foi a especificação de um protocolo, o IDXP (Intrusion Detection Exchange
Protocol).
Dentre os documentos elaborados por este grupo, destaca-se o “Intrusion Detection
Message Exchange Requirements”, o qual especifica a proposta do formato de mensagens
IDMEF (Intrusion Detection Message Exchange Format) e os requisitos necessários para
implementação deste, além da definição do protocolo de comunicação IDP (Intrusion
Detection Protocol). Para o IDP foram apresentados alguns requisitos fundamentais para
permitir a transmissão entre as entidades participantes.
Autenticação mútua entre sensores e console de gerenciamento;
Transmissão segura de mensagens por meio de mecanismos que garantam a
confidencialidade e integridade do conteúdo das mensagens durante o processo de
comunicação, através da utilização de algoritmos de criptografia;
Resistência a ataques de Negação de Serviço (DoS);
Proteção contra ataques do tipo replay, baseado no envio malicioso de suplicadas.
2.8 Protocolos para troca de mensagens entre IDS
Existe um problema associado à implementação e uso de detecção de intrusos em
arquiteturas distribuídas em redes de computadores de larga escala: a integração entre os
sensores, uma vez que sensores de fabricantes diferentes não conseguem trocar informações.
11 Internet Engineering Task Force - http://www.ietf.org
55
Quando as redes remotas são independentes, a administração centralizada se torna difícil, pois
nem sempre os produtos de IDS que estão sendo utilizados são os mesmos.
2.8.1 IDMEF
Inicialmente o grupo IDWG definiu o modelo geral de um sistema de detecção de
intrusão, a terminologia utilizada e os requisitos necessários para a interoperabilidade dos
sistemas. Entre os requisitos está o desenvolvimento de um formato e de um protocolo
específico para a troca de informações entre sistemas de detecção de intrusão. A fim de
separar a semântica do mecanismo de comunicação, o formato das mensagens de detecção de
intrusão deve ser independente do protocolo de comunicação utilizado.
O compartilhamento é feito através do envio de alertas formatados de acordo com o
Intrusion Detection Message Exchange Format (IDMEF). O modelo de dados IDMEF é uma
representação de alertas orientada a objetos. Com ele consegue-se um padrão na especificação
de alertas, permitindo o relacionamento entre ambientes de pouca ou grande complexidade.
O formato das mensagens é independente do protocolo de comunicação, mas o Intrusion
Detection Exchange Protocol (IDXP) é sugerido pelo IDWG para o envio desses alertas.
Recentemente, o formato Intrusion Detection Response Exchange Format (IDREF) foi
proposto para a formatação de mensagens de resposta aos alertas. Tanto as mensagens IDMEF
quanto as IDREF são baseadas na linguagem Extensible Markup Language – XML.
2.8.2 O Modelo de Dados IDREF
O modelo de dados IDREF (Intrusion Detection Response Exchange Format) visa
estender os trabalhos do grupo IDWG de forma a implementar mecanismos de envio de
respostas aos alertas detectados. O modelo IDREF possui um forte relacionamento com o
modelo IDMEF, pois as informações contidas em uma resposta dependem das informações
prestadas pelo alerta. Sendo assim, muitas das informações existentes no modelo IDREF
podem ter como origem informações de um alerta IDMEF recebido.
56
2.8.3 IAP - Internet Intrusion Alert
O protocolo IAP (Intrusion Alert Protocol) foi especificamente construído para
transportar alertas e troca de dados entre agentes IDS. Como todo protocolo, ele é baseado em
um modelo de comunicação e troca de mensagens. O IAP utiliza o TCP como protocolo a
nível de transporte é primariamente destinado a transmissão de dados do sensor/analisador
para a estação de gerenciamento que informa a ocorrência, grava o evento e toma as
determinadas contramedidas.
2.8.3.1 Modelo de Comunicação
O protocolo IAP utiliza um modelo de comunicação similar ao HTTP 1.0. Um dos
componentes faz requisições e o outro responde, mas algumas adaptações foram necessárias
para que ele pudesse funcionar de maneira mais eficiente. A primeira é que o componente que
estabelece a conexão pode responder e solicitar, isto é, não está caracterizado quem é o
servidor e quem é o cliente. A segunda é que o protocolo HTTP suporta vários níveis de
servidores proxy com a utilização do armazenamento de informações (cache). Já o protocolo
IAP suporta somente um tipo de proxy que é similar a um túnel do protocolo HTTP, através
do qual as informações são trocadas, mas não entendidas.
2.8.3.2 Sintaxe das Mensagens
As mensagens que são trocadas através do protocolo IAP são baseadas em textos. Na
figura 2 é mostrada uma requisição IAP que inclui o início de uma mensagem IDMEF. Toda
requisição começa com uma linha contendo o tipo da operação e a versão do protocolo IAP
que está sendo utilizada. Os cabeçalhos "Content-Length:" e "Content-Type:" são utilizados
para indicar o tamanho e o tipo de informação que está sendo transferida. Todo cabeçalho é
seguido por uma linha em branco e a mensagem, que pode estar vazia.
Toda requisição é respondida por uma mensagem que tem um formato similar. Na
primeira linha tem a versão do protocolo IAP e 3 dígitos de código de retorno que indicam se
a solicitação foi bem sucedida ou não. Esta linha é seguida por cabeçalhos, uma linha em
57
branco e a mensagem, como na requisição. Um exemplo de mensagem IAP está demonstrado
na figura 2.6.
Figura 2.6: Exemplo de Mensagem IAP
2.9 Considerações sobre Avaliação de IDS
Vários indicadores permitem a avaliação da qualidade de sistemas de Detecção de
Intrusão, entre os quais:
a) Adaptabilidade: expressa a capacidade que o IDS possui de reconhecer ligeiras
modificações de ataques já conhecidos.
b) Extensibilidade: traduz a capacidade que o sistema de detecção possui em ser
personalizado.
c) Eficiência ou precisão de detecção: traduz a capacidade que o IDS possui para
detectar corretamente a ocorrência de intrusões. A eficiência de um IDS é
contabilizada através do número de erros que ocorrem.
d) Impacto ou desempenho de um sistema: constitui um parâmetro que procura
refletir o peso do processamento associado à função do 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.
Avaliar sistemas de detecção de intrusão é uma tarefa complexa devido aos seguintes
motivos:
58
É difícil obter dados de alta qualidade para realizar a avaliação devido às questões de
privacidade e competitividade, muitas organizações não desejam compartilhar seus
dados com outras instituições;
Mesmo se dados reais estejam disponíveis, rotular as conexões de rede como normal
ou intrusivas requer muito tempo por parte dos especialistas humanos;
A mudança constante do tráfego de rede pode não somente introduzir novos tipos de
intrusões, mas pode também alterar os aspectos de comportamento normal, tornando
a construção de marcas comparativas ou de referência muito difícil;
Quando medindo o desempenho de um IDS, há a necessidade de medir não somente
a taxa de detecção (ou seja, quantos ataques foram detectados corretamente), mas
também a taxa de alarmes falsos (ou seja, quantas conexões normais foram
incorretamente detectadas como ataques) bem como o custo da má (incorreta)
classificação;
A complexidade da avaliação de um IDS torna-se também complexa pelo fato de que
alguns ataques (por exemplo, negação de serviço e varredura) podem usar centenas
de pacotes ou conexões de rede, enquanto outros tipos de ataques geralmente usam
somente uma ou algumas poucas conexões.
Redes de computadores geram grandes quantidades de dados durante sua operação
normal e as atividades constituintes de um ataque formam uma parte muito pequena do
tráfego e dos dados de auditoria. Esta parte pequena de instâncias de ataques nos dados de
treinamento redobram a dificuldade da tarefa de aprendizagem dos métodos inteligentes.
Sistemas baseados em detecção por anomalia são mais flexíveis, ou seja, generalizam bem
para novos cenários de ataques.
Infelizmente, devido a grande diversidade das atividades de comunicação que
normalmente ocorre em um ambiente de rede, estes modelos em geral produzem uma grande
taxa de alarmes falsos. Os desenvolvedores têm limitado o escopo dos modelos de detecção
por anomalia a um usuário ou uma aplicação somente, onde a complexidade é possível de ser
trabalhada [SILVA , 2007].
59
Sistemas de reconhecimento de padrões ou detectores por assinatura são melhores na
eliminação de alarmes falsos, porque estes comparam o tráfego corrente observado a um
repositório de modelos de ataques conhecidos. Em contrapartida, estes sofrem de uma taxa de
detecção mais baixa com relação a novas atividades hostis.
60
3 DETECÇÃO DE INTRUSÃO BASEADA EM HOST (HIDS)
O cenário atual das ameaças às redes de computadores, onde a popularização de
ferramentas de ataque automatizado contribuíram para o aumento das estatísticas de intrusão,
tornaram extremamente simples a atividade de comprometer um host ou diversas redes.
Entre os fatores que caracterizam esta situação, destacam-se o aumento da sofisticação
dos ataques e a diminuição dos conhecimentos técnicos necessários para conduzi-los.
Segundo [ALLEN, 2000], na década de 1980, os intrusos eram especialistas, tinham alto nível
de perícia e desenvolviam individualmente seus métodos de invasão. Atualmente, qualquer
usuário com o mínimo de conhecimento pode produzir um ataque através de ferramentas
automatizadas. Conforme ilustrado na Figura 3.1, usuários experientes estão ficando mais
astutos e seus ataques mais sofisticados, em compensação, o conhecimento requerido para que
o intruso novato possa lançar um ataque conhecido está diminuindo.
Figura 3.1. Sofisticação do ataque vs. conhecimento técnico do intruso, adaptado de [ALLEN, 2000]
61
Alguns ataques têm como objetivo a introdução de códigos ou softwares conhecidos
como Malwares (Malicious Softwares - Códigos Maliciosos) desenvolvidos para executar
uma ação danosa em um computador, prejudicando o desempenho do sistema alvo e até
mesmo a privacidade de seu usuário.
A maioria dos ataques locais a sistemas computacionais derivam ou servem de base para
ataques remotos, que, segundo os mesmos conceitos e princípios fazem uso dos meios de
comunicação para executar as explorações. Torna-se essencial, portanto, conhecer as ameaças
que comprometem a segurança dos hosts. Neste contexto, o uso de Sistemas de Detecção de
Intrusão baseados em host (HIDS) constituem uma das principais ferramentas na monitoração
e prevenção destas ameaças.
Esta capítulo tem o objetivo de apresentar e discutir as principais formas de ataques locais
a hosts e a importância dos HIDS na proteção dos sistemas computacionais. Para tanto,
apresenta o seguinte contexto:
a) Discutir e caracterizar a anatomia de ataques a hosts, ou ataques locais;
b) Classificar os tipos de atacantes e as principais formas de ataques;
c) Conceituar e descrever vantagens e desvantagens da abordagem de detecção de
intrusão baseada em host;
d) Apresentar algumas soluções HIDS baseadas em software livre.
3.1 Ataques Locais
Os ataques a redes de computadores geralmente iniciam com o levantamento de
informações e escolha de alvos específicos. Um servidor configurado incorretamente, um
serviço vulnerável ou um administrador de rede com pouco conhecimento, são fatores que
contribuem para que um atacante consiga obter o acesso e o controle de um host e, a partir
deste, invadir outras máquinas na rede. A fase inicial de coleta de dados é denominada
Footprint, onde são levantadas informações importantes do host alvo, como serviços ativos e
vulneráveis passivos de exploração remota. O processo de Footprint pode ser dividido em:
62
Engenharia Social: práticas utilizadas para obter acesso a informações importantes
ou sigilosas em organizações ou sistemas por meio da persuasão ou exploração da
confiança das pessoas, falsos e-mails (spam), etc;
FingerPrint: tem por objetivo determinar qual o sistema operacional do host alvo;
Ataques de Varreduras: scanners de portas, enumeração de serviços e
vulnerabilidades, etc. O scanner é um software que, dado um determinado alvo, seja
ele um software, um computador ou um dispositivo de rede, irá analisá-lo em busca
de vulnerabilidades existentes (senhas padrão, serviços inseguros escutando em
portas públicas, sistemas vulneráveis a falhas conhecidas, etc);
Após a fase inicial de levantamento de informações o atacante identifica uma máquina
com alguma vulnerabilidade e a explora, podendo obter acesso privilegiado. Nesse momento a
preocupação é não ser detectado (apagando logs e registros de acesso) e garantir futuros meios
de acesso ao sistema através da instalação de backdoors. Este ciclo eventualmente recomeça
com a utilização da máquina invadida para a varredura e invasão de outros sistemas
vulneráveis. O procedimento típico de invasão de um host pode ser dividido genericamente
em 5 passos básicos, como pode ser visto no diagrama da figura. 3.2.
Figura 3.2 Anatomia de um ataque
Conforme descrito, frequentemente um atacante tenta elencar e invadir os computadores
mais vulneráveis de uma rede. Entre os principais motivos da invasão, destacam-se:
Base para outros ataques: o objetivo final do cracker nem sempre é a máquina que
ele invadiu, mas outras máquinas mais importantes na rede, ou seja, uma
63
determinada máquina pode ser usada como um trampolim para atacar outros alvos.
Em outras palavras, uma máquina invadida geralmente serve para executar atos
maldosos, de modo que pareça que o atacante partiu da máquina comprometida,
encobrindo a real origem do ataque. A máquina comprometida pode ser usada ainda
como parte de um grupo de computadores que combinados podem realizar um
ataque de negação distribuído (DdoS);
CPU: frequentemente invasões são articuladas objetivando utilizar o processamento
do host comprometido para execução de programas. Por que desperdiçar seus
próprios recursos quando se pode usar uma máquina de terceiro para fazer isso por
eles?
Espaço em disco: uso do espaço em disco para distribuição de software pirata
(warez, MP3, vídeos, etc). O espaço em disco no host comprometido também pode
ser usado como meio para execução de crimes e fraudes digitais, como hospedagem
de páginas falsas de bancos;
Roubo de dados: objetivando furtar segredos industriais, registros bancários ou
senhas de cartão de crédito;
Destruição de dados e danos à reputação: algumas invasões visam expor o usuário
negativamente ou sabotar empresas. Isto ocorre através da divulgação de dados
confidenciais ou mesmo destruição dados estratégicos;
Conhecimento e notoriedade: muitos atacantes são motivados pelo simples desafio
de invadir sistemas. A oportunidade de obter mais conhecimento e notoriedade, são
os elementos que impulsionam os invasores, e para tanto eles não medem esforços
para provar que sistemas totalmente seguros não existem;
3.2 Classificação dos invasores de sistemas
Os invasores são divididos basicamente nas seguintes categorias:
64
a) Hacker: pessoa que possui grande facilidade de análise, assimilação,
compreensão dos aspectos relacionados à computação em geral. Geralmente são
pessoas com alta capacidade mental e com pouca atividade social. Conhecem
profundamente aspectos de linguagem de programação e um ou mais sistemas
operacionais, o que permite o desenvolvimento de ferramentas que utilizam
falhas nesses sistemas para invadi-los. Entretanto, o hacker busca essencialmente
o conhecimento. Por falta de informação, a mídia classifica equivocadamente
qualquer pessoa que cometa alguma fraude ou crime digital, como hacker;
b) Cracker: indivíduo com um nível de conhecimento igual ou superior aos
hackers. Mas que, usualmente, além de invadir o sistema, causa danos aos
proprietários através do roubo de informações, alterações de conteúdo, etc;
c) Phreaker: é um invasor especializado em telefonia. Aplica seus conhecimentos
para utilizar ilegalmente os serviços das companhias telefônicas. Foram os
pioneiros e portanto, deram origem às demais categorias;
d) Lamer e Script Kiddie: o termo Lamer (de acordo com o dicionário britânico,
uma pessoa inepta ou ineficaz), muito utilizado no final dos anos 80 e meados
dos anos 90, é empregado para designar uma pessoa que não possui
conhecimentos técnicos sobre computadores, porém, faz-se passar por um
especialista. Costuma-se pensar também que lamer é um hacker iniciante, um
aprendiz; o que na verdade é um equívoco. Um lamer é julgado assim por suas
atitudes e não por seus conhecimentos. Já Script Kid seria o sinônimo moderno
para o antigo termo lamer. Este indivíduo geralmente utiliza alguma ferramenta
de invasão já disponível para download na Internet, ao invés de criar suas
próprias ferramentas ou estratégias. Desenvolvem atividades relacionadas com
segurança da informação utilizando-se do trabalho intelectual dos verdadeiros
especialistas técnicos, mas não possuem conhecimento de programação.
Geralmente o Script Kiddie é um usuário sem muitos conhecimentos técnicos, que deseja
invadir algum sistema sem nenhum objetivo importante.
65
3.3 Ameaças digitais
Existem diferentes tipos de métodos de ataques e ameaças digitais. Programas
desenvolvidos com a intenção de prejudicar computadores pessoais e executar ações danosas
em servidores são conhecidos como malwares (malicious code, malicious software). Estes
códigos maliciosos geralmente recebem a seguinte classificação: keyloggers, cavalos de tróia
(trojans ou trojan horse), vermes (worms), vírus, rootkits e exploits.
Apesar da classificação de ameaças ser bastante extensa, nesta seção serão abordadas
apenas as ferramentas diretamente relacionadas ao comprometimento, invasão, roubo de
dados e manutenção de privilégios em sistemas computacionais.
3.3.1 Worm
Depois dos vírus de computador, os worms tornaram-se a forma de ameaça mais
conhecida na Internet, sob a forma de código malicioso com características similares aos
vírus. Worms em geral se replicam e se propagam para outros computadores. Para tanto
necessita explorar vulnerabilidades do host remoto (exploiting), o que é a maior dificuldade
neste processo.
Worms são organismos autônomos e em seu processo de duplicação e propagação não
necessitam de qualquer intervenção do atacante ou do usuário do computador atacante.
Worms também não necessitam infectar programas executáveis como os vírus, necessitando
apenas estarem presentes em um computador na rede local ou internet.
Não existe uma classificação universal para worms, contudo, com relação ao seu método
de replicação pode-se considerar worms execução autônoma e execução pelo usuário.
a) Worms de execução autônoma, como comentado anteriormente, são organismos
presentes em computadores contaminados e que não necessitam interação
humana em seu processo de replicação. Estes exploram vulnerabilidades de
serviços e fazem uso de TCP/IP, e-mail, compartilhamento de arquivos,
dispositivos de armazenamento removíveis, e serviços da Internet;
66
b) Worms de execução pelo usuário necessitam da interação do usuário para dar
início ao processo de infecção do computador. Nestes casos é utilizada
engenharia social para persuadir e convencer o usuário a executar e instalar um
arquivo da internet ou um arquivo anexo em e-mail. A partir deste momento o
worm pode se alto enviar para outro grupo de computadores. A execução de
código remotamente por worms se dá em quatro etapas principais: Verificação
de vulnerabilidade, Exploração, Proliferação e Cópia.
Com o código copiado localmente (fase de Cópia) e executando no computador da
vítima, a próxima fase é a de Proliferação, quando este computador passa ao papel de atacante
e se prolifera para novos alvos, utilizando o mesmo método de Verificação de vulnerabilidade,
Exploração e cópia.
Os worms geralmente estão relacionados a atividades de intrusão pois também podem
servir de base para ataques DDoS, roubo de dados e instalação de códigos passiveis de
exploração remota, como buffer overflow.
O Morris worm ou “Internet worm” foi um dos primeiros worms distribuídos pela
Internet; trata-se também do primeiro worm a receber atenção da mídia. Ele foi escrito por
Robert Tappan Morris Jr, estudante da Cornell University e para despistar sua origem, foi
disseminado a partir do MIT em 2 de Novembro de 1988, realizando um ataque de DoS e em
10% dos computadores conectados a Internet.
Este Worm fez uso de dois programas Unix, sendmail e fingerd, o que possibilitou a
exploração de um tipo de vulnerabilidade de buffer overflow (stack overflow) no fingerd,
infectando universidades, computadores da NASA, organizações militares, e agências do
governo federal americano. Este código malicioso foi importante primeiro porque foi prova de
conceito da possibilidade de ataques remotos explorando vulnerabilidades de protocolos e
serviços de rede. Assim como, evidenciou a vulnerabilidade dos centros de pesquisa e
agências conectados à internet que não estavam preparados para responder a incidentes deste
porte.
O Computer Emergency Response Team/Coordination Center (CERT/CC) foi criado, a
partir do incidente do Worm de Morris, pela DARPA (Defense Advanced Research Projects
67
Agency, parte do Departamento de Defesa dos Estados Unidos) com o intuito de prover
iniciativas de pesquisas em vulnerabilidades de segurança, aumento de segurança de sistemas,
e coordenação de times de resposta a incidentes de larga escala.
3.3.2 Adwares e spywares
Paralelamente a atividade de malwares existe uma atividade, mais recente que vírus e
worms, conhecida como Adware. Adwares são aplicações instaladas em computadores alvos
(geralmente sem o consentimento e conhecimento do usuário), agregados a softwares gratuitos
ou de uso limitado. Adwares têm a função de monitorar a atividade do usuário com o intuito
exclusivamente comercial. As informações captadas, contém as preferências do usuário de
navegação na internet, e são enviadas para empresas fabricantes ou comerciais para
posteriores propagandas e ofertas de produtos. Quando o usuário parte para navegação na
Web através de seu navegador, alguns popups são abertos pelo adware com propaganda
direcionada, e o usuário é redirecionado para páginas que comercializam estes produtos.
O estudo de Adware é importante pois a disseminação da atividade de Adwares propiciou
o surgimento de spywares. Spywares são também programas espiões, mas com o intuito
malicioso de roubar informações pessoais como dados financeiros, contas de acesso a internet
banking e números de cartão de crédito.
Spywares têm os mais diversos fins maliciosos, contudo, não somente verificam sites
acessados, mas também armazenam e transmitem para o atacante informações armazenadas
em cookies, senhas e outras informações capturadas pela digitação, informações comerciais e
financeiras, como nomes de bancos, agência e conta, e outros.
3.3.3 Bots e Botnets
De modo similar ao worm o bot é um programa capaz se propagar automaticamente,
explorando vulnerabilidades existentes ou falhas na configuração de softwares instalados em
um computador. Adicionalmente ao worm, dispõe de mecanismos de comunicação com o
invasor, permitindo que o bot seja controlado remotamente.
68
Normalmente, o bot se conecta a um servidor de IRC (Internet Relay Chat) e entra em um
canal (sala) determinado. Então, ele aguarda por instruções do invasor, monitorando as
mensagens que estão sendo enviadas para este canal. O invasor, ao se conectar ao mesmo
servidor de IRC e entrar no mesmo canal, envia mensagens compostas por seqüências
especiais de caracteres, que s˜ao interpretadas pelo bot. Estas seqüências de caracteres
correspondem a instruções que devem ser executadas pelo bot.
Botnets são redes formadas por computadores infectados com bots. Estas redes podem ser
compostas por centenas ou milhares de computadores. Um invasor que tenha controle sobre
uma botnet pode utiliza-la para aumentar a potencia de seus ataques, por exemplo, para enviar
centenas de milhares de e-mails de phishing ou spam, desferir ataques de negação de serviço,
etc.
3.3.4 Cavalos de tróia (trojan horse)
São programas maliciosos que aparentemente parecem programas úteis aos usuários, mas
que executam ocultamente tarefas maliciosas, podendo coletar informações ou abrir uma
brecha de segurança como um backdoor. Diferentemente de vírus e worms, trojan horses não
se propagam, necessitando ser instalados pelos próprios usuários.
Geralmente um trojan é instalado com o auxílio de um ataque de engenharia social, com
apelos para convencer a vítima a executar o arquivo do servidor, o que muitas vezes acaba
acontecendo, dada a curiosidade do internauta.
Nos tópicos a seguir, serão abordados os tipos mais freqüentes de Trojan Horse.
3.3.4.1 Backdoor
Originalmente um backdoor (também conhecido por Porta dos fundos) consiste de uma
porta usada por vários fabricantes para gerenciamento remoto de seus produtos. Dentre as
funcionalidades exercidas destacam-se as atualizações e correções de erros em aplicativos.
Entretanto, um Backdoor pode ser uma falha de segurança que pode existir em um
programa de computador ou sistema operacional, que pode permitir a invasão do sistema por
69
um cracker para que ele possa obter um total controle da máquina. Um backdoor pode
também ser incluído por um atacante que queira garantir o seu retorno ao computador
invadido. O computador da vítima, uma vez comprometido, pode ser novamente invadido sem
a necessidade de execução de todas as fases que precedem uma invasão.
Alguns backdoors são conhecidos como RAT (Remote Administrator Tool) ou ProRAT.
ProRat é um backdoor da classe RAT, que possui muitas funções de espião. Seu nome é uma
fusão da palavra inglesa professional, juntamente com a sigla RAT. Criado em Visual Basic,
dentre outras, este código malicioso pode executar as seguintes funções:
Keystrokes(Keylogger), roubo de senhas, controle total sobre arquivos, fazer screenshots,
visualizar informações do sistema, download de arquivos, etc.
3.3.4.2 Keylogger e Screenlogger
Keylogger (registrador do teclado) é um software de computador cuja finalidade é
monitorar tudo o que é digitado. Muitas vezes esses programas são utilizados com objetivos
ilícitos, através de spywares, "trojan horses", entre outros. Os Keylogger na maioria das
vezes se infiltram no computador da vítima através de e-mails e links falsos. Geralmente, a
pessoa só nota que o Keylogger foi instalado depois que o cracker responsável pelo mesmo já
tenha entrado no sistema através das senhas capturadas.
Há Keylogger produzidos apenas para fins ilícitos, o que acaba sendo muito perigoso para
as pessoas que são infectadas devido a seu criador poder ser um script kiddie, baixá-lo e
configurá-lo com o intuito de roubar dados como senhas de jogos, MSN, e-mails e Orkut.
Existem também os chamados keybank e os screenlogger. Keybank são Keylogger feitos
especialmente para roubar senhas bancárias e de cartão, os screenlogger, por sua vez,
armazenam a posição do cursor e captura a tela apresentada no monitor no momento em que o
mouse é clicado.
O consumo destas aplicações em termos de processamento, memória e tráfego de rede
fazem-no imperceptível, podendo enviar via e-mail ou ftp as informações capturadas para um
espião externo. Alguns conseguem manter-se ocultos no Task Manager do Windows (na lista
70
de processos), ocultam seus arquivos de logs, e misturam-nos aos do próprio sistema
operacional. Para tanto, a maioria dos Keyloggers utiliza o recurso Windows Hooks.
Hook são mecanismos pelos quais eventos podem ser interceptados antes de alcançarem
uma aplicação. A função pode agir em eventos modificando-as ou descartando-as.
As facilidades fornecidas por Hooks permeiam o processamento ou modificação de
qualquer mensagem, gravação ou inserção da mensagem de volta ao keyboard e eventos de
mouse, etc.
3.3.5 Rootkits
Um invasor, ao realizar uma invasão, pode utilizar mecanismos para esconder e assegurar
a sua presença no computador comprometido. O conjunto de programas que fornece estes
mecanismos é conhecido como rootkit.
Os rootkits possuem esse nome por serem, inicialmente, “kits” de programas para a
plataforma Linux/Unix para manter o acesso ao sistema previamente comprometido, agindo
como backdoor. O termo rootkit, portanto, refere-se a um conjunto de ferramentas usadas pelo
invasor não para obter privilégios de root, mas sim para manter esses privilégios. Como
“root” é o usuário com o controle total do computador nas plataformas Unix, originou-se o
nome “rootkit” para denominar estes conjuntos de aplicativos.
Um rootkit pode fornecer programas com as mais diversas funcionalidades. Dentre eles,
podem ser citados:
Programas que substituem os comandos reais de um sistema operacional:
objetivando esconder atividades e informações deixadas pelo invasor (normalmente
presentes em todos os rootkits), tais como arquivos, diretórios, processos, conexões
de rede, etc;
LogClean: Programas para remoção de evidências em arquivos de logs;
71
Sniffers: para capturar informações na rede onde o computador está localizado,
como por exemplo senhas que estejam trafegando em claro, ou seja, sem qualquer
método de criptografia;
Scanners: para mapear potenciais vulnerabilidades em outros computadores;
Outros tipos de malware: como cavalos de tróia, keyloggers, ferramentas de ataque
de negação de serviço, etc.
Quando um rootkit é instalado, ele altera vários arquivos binários e instala novos
módulos no núcleo do sistema operacional. Estes procedimentos alteram o comportamento do
sistema operacional fazendo com que o rootkit fique imperceptível a um usuário ou qualquer
ferramenta de detecção de malwares.
3.3.6 Exploits
Um exploit é um programa utilizado para explorar uma vulnerabilidade de outro
programa. Exploits são também conceituados como códigos maliciosos, porção de dados ou
uma seqüência de comandos que se aproveita das vulnerabilidades de um sistema
computacional ou serviços em execução. Estas ferramentas tem por finalidade : executar
comandos arbitrários, obter um shell não autorizado e aumentar os privilégios de usuário por
meio de erros de programação de serviços ou aplicações vulneráveis. A maioria dos exploits
para Linux são escritos em linguagem C, Perl ou script shell.
Exploits são geralmente elaborados por hackers como programas de demonstração das
vulnerabilidades, a fim de que as falhas sejam corrigidas, ou por crackers a fim de ganhar
acesso não autorizado a sistemas. Por isso muitos crackers não publicam seus exploits,
conhecidos como 0 days, e o seu uso massificado deve-se aos script kiddies.
Não existe entretanto um programa chamado exploit, existem exploits para explorar
vulnerabilidades específicas de sotwares específicos, de versões específicas. O grau de
especificidade remete ao estudo de Buffer Overflows (que é traduzido como estouro de pilha),
contudo, nem sempre exploits estão baseados em buffer overflows, mas frequentemente este
72
tipo de vulnerabilidade é explorada, pois, a grande maioria das vulnerabilidades encontradas
em alguns serviços são baseadas no buffer overflow.
Um buffer overflow é uma anomalia, e ocorre quando, ao inserir uma quantidade de dados
maior do que o programa está preparado para tratar (causando estouro do buffer) ele irá
executar instruções que não estão programadas, em um endereço de memória diferente do
normal. Desta forma, seria possível colocar instruções nos próprios dados que está inserindo,
fazendo o computador executar ações arbitrárias, não previstas. Permitindo assim ao exploit
executar um comando aleatório, obter um shell ou mesmo ler arquivos no sistema.
Os exploits são enquadrados em dois tipos:
a) Exploit para execução local: o usuário mal intencionado deve ter uma conta no
sistema e estar logado para executá-lo localmente. Este tipo de exploit
geralmente é utilizado para o usuário ganhar um maior privilégio ou ler um
arquivo que ele não possui permissão;
b) Exploit para execução remota: o invasor não precisa ter um conta no sistema
remoto, o invasor somente precisa ter acesso a rede. Este tipo de exploit é
utilizado para obter algum acesso não autorizado através da rede.
Até meados dos anos 90, acreditava-se que os exploits exploravam exclusivamente
problemas em aplicações e serviços para plataformas Unix. A partir do final desta década,
especialistas demonstraram a capacidade de explorar vulnerabilidades em plataformas de uso
massivo, por exemplo, sistemas operacionais Win32 (Windows 9x, NT, 2000 e XP).
3.4 IDS baseado em Host
3.4.1 Conceito
Um IDS baseado em host monitora eventos e logs de máquinas individuais (hosts) e
servidores para detectar atividades suspeitas o mal uso ou intrusão no sistema. Ele aplica
análise de assinatura contra múltiplos eventos de log e de comportamento do sistema, pode
também tomar ações pró-ativas como barrar todo o tráfego para o host infectado.
73
Consistem, tipicamente, de sistemas especialistas que fiscalizam diversos tipos de
atividades, como chamadas de funções do sistema operacional, integridade do sistema de
arquivos, acesso a arquivos considerados críticos, entre outros recursos; procurando por
padrões que determinem desvios significativos em relação ao perfil de uso considerado
regular.
A detecção de intrusão baseada em host é a precursora dessa área, sendo que o alvo das
primeiras ferramentas desenvolvidas com esse fim foram os conhecidos mainframes. Nesse
ambiente, todos os usuários estavam localizados em um único ponto, fazendo uso dos mesmos
recursos de armazenamento, processamento, etc., e tornando mais fácil a tarefa de
monitoramento do sistema. [CAMPELLO e WEBER, 2001]. O HIDS pode fazer uma análise
mais precisa e confiável, indicando que processos e usuários estão envolvidos em algum tipo
de ataque ao sistema operacional, e também suas conseqüências.
O principal esforço, dessa forma, era realizar vistorias periódicas nos registros de
atividade do sistema, tentando detectar possíveis eventos não autorizados, e, em um estágio
mais avançado, utilizar ferramentas que analisavam esses registros de forma automatizada.
Essas ferramentas, então, analisam a atividade do sistema através de dados coletados na
própria máquina, permitindo a determinação exata de quais usuários e processos estão
realizando operações maliciosas no sistema, o que garante boa precisão na detecção.
A figura 3.3 a seguir, ilustra a utilização de HIDS em hosts de uma rede de computadores.
Figura 3.3 Utilização de HIDS em hosts uma rede de computadores
74
Uma sub-categoria desse tipo de IDS, citado por vários autores, é representado pelos
chamados IDS baseados em aplicação. Preocupados em analisar dados gerados por aplicações
específicas, como transações de bancos de dados, por exemplo, esses IDS representam um
nível de abstração mais elevado na cadeia de detecção. As fontes mais comuns de informação
usadas por IDS baseados em aplicação, são chamadas ao sistema, os arquivos de transação e
logs da aplicação. Por serem desenvolvidos para monitorar atividades específicas, este tipo de
IDS geralmente consome menos recursos do host e são mais precisos em relação aos HIDS.
Esta classificação é ilustrada na figura 3.4 a seguir.
Figura 3.4 - Níveis de abstração entre as diferentes abordagens de IDS
3.4.2 Principais Características dos HIDS
Para detectar intrusões, o HIDS pode se basear em três fontes de informações:
Sistema de arquivos: Através da comparação com dados de um sistema de arquivos
considerado confiável, o IDS verifica a integridade do sistema de arquivos, procurando
por modificações classificadas como não autorizadas. Para diminuir a quantidade de
falsos positivos, uma estratégia seria configurar o IDS especificando quais arquivos e
diretórios podem ser alterados;
Conexão da rede: O IDS pode identificar atividades maliciosas através da análise das
informações trocadas entre o host e uma entidade remota;
Conexão de portas TCP/UDP: pode mapear portas abertas em serviços ativos e
descobrir tentativas de aberturas de sessões UDP ou TCP em portas não autorizadas;
Arquivos de log: Ο IDS pode detectar atividades maliciosas através da análise de
informações contidas nos arquivos de log do sistema.
Alguns autores destacam ainda as seguintes características:
75
Verificar o sucesso ou falha de um ataque;
Ataques que ocorrem fisicamente num servidor podem ser detectados;
Ataques que utilizam criptografia podem não ser notados pelos NIDS, mas
descobertos pelos HIDS, pois o SO primeiro decifra os pacotes;
Independem da topologia da rede;
Geram poucos “falsos positivos”, que são alarmes falsos de ataques;
Não necessita de hardware adicional.
O HIDS trabalha fazendo monitoração de login, para verificar se os logs de autenticação
estão se comportando normalmente ou se existem atividades inesperadas como, por exemplo,
tentativas de obtenção privilégios de administradores para quem não tem esse perfil.
3.4.3 IDSs baseados em rede x host
Uma das vantagens de um IDS em relação aos métodos tradicionais de análise de
incidentes é a possibilidade de correlacionar diferentes tipos de dados. Coletar informações
locais como os logs e o estado dos processos em execução, ou capturar na rede pacotes
destinados a determinada porta, são exemplos de ações distintas com um mesmo fim: gerar
dados que representem indícios de uma intrusão. Essas coletas, no entanto, sejam elas feitas
no host ou na rede, determinam o tipo do IDS (baseado em host ou em rede) e apresentam
vantagens e desvantagens características.
As principais vantagens dessa abordagem são:
a) Independência de rede: independente da forma de comunicação utilizada entre
as máquinas (cifrada ou não, com switches ou não), as tarefas de um IDS
baseado em host não são diretamente afetadas;
b) Não necessita de Hardware adicional: ao contrário dos NIDS, os HIDS não
necessitam de servidores ou appliances adicionais para serem incorporados aos
76
hosts. No entanto, algumas topologias podem utilizar um host gerente para
correlação e registro de eventos centralizados.
c) Detecção de ataques internos: é mais fácil, para um IDS baseado em host,
porque é capaz de monitorar atividades específicas do sistema (logon, logoff, uso
do admin, podem ainda detectar ataques que utilizam criptografia, etc) e detectar
atividades não autorizadas que representem abusos de privilégio por parte de
usuários ou programas, desta forma gerando pouco falso positivos;
d) Reação: embora não sendo uma atividade de responsabilidade direta do IDS,
pode-se, com maior eficiência e facilidade, confinar/avaliar danos e recuperar
erros usando uma ferramenta baseada em host.
Como desvantagens são apresentados os seguintes itens:
a) Dificuldade de instalação: cada máquina monitorada deve conter ao menos um
elemento do IDS baseado em host instalado localmente, dificultando sua
instalação em redes de larga escala;
b) Dificuldade de manutenção: pelo mesmo motivo apresentado acima, a tarefa de
manutenção dessas ferramentas é dificultada;
c) Dependência do S.O.: É dependente do S.O. (um HIDS de Linux é totalmente
diferente de um HIDS de Windows);
d) Ataques ao próprio IDS: como os elementos da detecção devem estar
localmente instalados, um atacante que conseguir invadir tal máquina pode
desabilitar ou destruir a ferramenta instalada;
e) Dificuldade de tratar ataques de rede: alguns ataques são especialmente
direcionados à infra-estrutura de rede, dificilmente tratados por IDS desse tipo;
f) Desempenho: ferramentas desse tipo são extremamente intrusivas, ou seja,
interferem diretamente no funcionamento e desempenho do sistema monitorado;
g) Dependência de plataforma: é altamente dependente da plataforma de
monitoramento, devendo sofrer muitas modificações para se adaptar a outros
ambientes.
77
Sistemas interligados em rede, por sua vez, representaram um novo paradigma no
contexto de detecção de intrusão, sendo que a partir de então usuários migravam de uma
máquina para outra, possivelmente com identidades diferentes, trocavam informações pela
rede e, no caso de pessoas mal intencionadas, lançavam ataques que poderiam atingir todas as
máquinas daquela rede. Para lidar com essa nova realidade, sistemas que realizavam uma
análise local dos dados precisavam interagir para garantir uma detecção em toda a
organização, trocando volumosas trilhas de auditoria ou simples alarmes.
O uso em grande escala da Internet voltou a atenção dos IDS para ataques à própria rede.
Seqüestro de seções TCP12, varredura de portas, negação de serviço, dentre outros, são
exemplos de ataques dificilmente detectados por analisadores baseados em host. Assim, foram
desenvolvidas ferramentas específicas que capturam e analisam pacotes de rede, permitindo a
busca por ataques direcionados a detalhes específicos de rede e, inclusive, a determinadas
máquinas, através da análise dos dados transportados nesses pacotes.
Por esse motivo, a maioria dos IDS disponíveis atualmente são baseados em rede.
Capturando pacotes em um backbone, segmento de rede ou nas entradas de uma organização,
uma grande quantidade de informação pode ser monitorada com esse tipo de ferramenta, sem
interferir no funcionamento ou desempenho das máquinas afetadas. Normalmente
direcionados a explorar vulnerabilidades latentes no sistema operacional, em protocolos ou
em serviços, sua principal função é detectar ataques que seriam dificilmente percebidos por
uma ferramenta que trabalhe com dados de um único host, direcionando esforços ao tráfego de
toda a rede.
3.4.4 Verificadores de integridade
Até mesmo os hosts mais bem protegidos podem ser ocasionalmente invadidos. É
importante que o administrador do sistema descubra essas violações o mais rápido possível.
Existem uma grande variedade de ferramentas de auditoria e de verificação para essa
finalidade. Para detectar programas mal-intencionados que o intruso incluem na rede, os
12 Seqüestro de seções TCP: baseia-se fundamentalmente na possibilidade de se prever o número de seqüência do TCP, preferiu-se classificá-lo como sendo derivado de uma deficiência do IP.
78
verificadores de integridade examinam arquivos do sistema para determinar se houve
alterações não autorizadas ou inesperadas.
As ferramentas de auditoria registram e organizam eventos de sistema de modo que um
ataque possa ser rapidamente reconhecido e combatido. O principal problema com esses tipos
de ferramentas reside em sobrecarregar o administrador do sistema com uma série de
informações. Para combater isso, muitas das novas ferramentas tentam combinar logs de
diversos hosts e filtrar informações que não sejam pertinentes. O real desafio é determinar
exatamente o que é relevante e o que não é.
Um problema com ferramentas de integridade e auditoria é que se estiverem localizadas
no sistemas que está sendo protegido, elas ficam sujeitas a ataques. Por exemplo, o intruso
pode modificar o programa básico e altera a integridade para ajustá-lo ao novo programa
adulterado. Por essa razão, recomenda-se que informações de segurança importantes sejam
armazenadas em outros sistemas ou em um meio físico que não possa ser modificado, como
uma unidade WORM (write-once read-many) .
3.5 Exemplos de HIDS
Existe uma grande variedade de HIDS disponíveis, comerciais ou registrados sobre GPL.
Nesta seção serão abordadas dois tipos de IDS utilizados atualmente: o tripwire e o OSSEC.
3.5.1 TRIPWIRE
O Tripwire é uma ferramenta para UNIX desenvolvida para monitoramento das
modificações ocorridas no sistema de arquivos, mas não funciona como um IDS ativo porque
ele não é capaz de realizar ações específicas para determinados tipos de ocorrências de alerta.
A verificação de integridade dos arquivos deve ser feita com a intervenção do administrador.
Após a instalação do Tripwire deve ser criado um banco de dados com informações dos
arquivos que devem ser monitorados por ele, assim ele poderá fazer checagens periódicas
buscando identificar qualquer alteração ocorrida nestes arquivos, baseando-se nas informações
armazenadas no banco de dados criado.
79
Para garantir a segurança e a integridade do banco de dados, ele é armazenado de forma
criptografada, onde será exigida a chave criptográfica e fornecida a passphrase, que é na
verdade uma senha usada para gerar a chave.
O uso do Tripwire pode trazer melhorias no nível de segurança, pois, apesar de não
bloquear possíveis ataques de forma dinâmica, a constante verificação da integridade dos
arquivos, pode determinar a dimensão dos danos causados por estes ataques e, dependendo, da
freqüência com que é realizada, pode evitar maiores estragos pela identificação de pontos
ultrapassados no sistema de segurança.
As informações do Tripwire podem ser muito úteis para a tomada de medidas judiciais
contra invasores, pois representam provas da invasão com detalhes dos passos dados no
sistema.
3.5.2 OSSEC13
O OSSEC é um Host IDS Open Source criado pelo Daniel Cid. Ele é usado para análise
de log, detecção de rootkits, alertas e repostas pró-ativas. O OSSEC realiza operações de
Analise de Logs, Detecção de rootkits, integridade de Sistemas, checagem de integridade,
alertas e resposta ativa (resposta em tempo real). Ele possui três métodos de funcionamento:
a) Local - apenas na maquina onde está instalado:no modo standalone o host
funciona como cliente e servidor, com uma lógica de processos mais simples, já
que não necessita de comunicação com o servidor, porém com as características
minimas de funcionamento, cumprindo todas as funcionalidades de
monitoramento. Este modo é útil para servidores isolados ou em ambientes onde
existem restrições de comunicação. A desvantagem deste modelo é que todos os
registros ficam no servidor no qual precisamos fazer a análise forense, mas caso
o servidor tenha sido comprometido, tais registros naturalmente inspiram pouca
confiança;
b) Agente - onde funciona como cliente, enviando todas as informações para o
servidor processar e analisar. Serve para centralização dos logs no servidor
13 http//:www.ossec.org
80
central de logs, esse sendo monitorado pelo OSSEC. A comunicação entre agente
e servidor é feita através de mensagens UDP. Para garantir a confiabilidade os
pacotes são criptografados mediante a uma chave simétrica e única, gerada pelo
servidor para cada host cliente. Os agentes são importantes pois podem ser
adicionados em estações com usuários leigos (estações Win/Linux) e em
servidores;
c) Servidor - onde analisa e une os logs e informes de vários agentes. tende a
centralizar múltiplos pontos de gerenciamento de logs, em um único ponto de
analise e alertas. Nesta configuração também é possível que o servidor receba as
mensagens de um servidor Syslog remoto para analisar. A figura 3.5 exibe o
fluxo de um ambiente cliente-servidor,usando agentes e a centralização de
registros em um servidor OSSEC.
Figura 3.5. Fluxo do ambiente cliente-servidor OSSEC usando agentes.
A comunicação entre agentes e servidor pode ser feito via plain text ou modo
criptografado, com gerenciamento próprio de chaves do OSSEC.
O Ossec suporta os vários tipos de logs como Unix pam, Unix telnetd, sshd (OpenSSH) ,
Proftpd, Samba, Su, Sudo, Solaris ftpd, Imapd and pop3d, Horde imp, vsftpd, Named (bind),
Postfix, Pure-ftpd, Sendmail, Iptables firewall, Solais ipfilter firewall, AIX ipsec/firewall,
Netscreen firewall, Snort IDS, Apache web server (access log and error log), IIS web server,
Squid proxy, Windows event logs, Generic unix authentiction (adduser, logins, etc).
Outra funcionalidade interessante do Ossec é o detector de rootkits (syscheckd). Este
scanner utiliza duas metodologias para identificar rootkits:
81
Identificação baseada em assinaturas;
Identificação baseada em anomalias.
Para a identificação baseada em assinaturas utiliza dois arquivos onde são detalhadas as
características únicas de várias tipos de rootkits e trojans horses, por exemplo (lista)
A lista a seguir, exibe algumas assinaturas de rootkits conhecidos:
# adore Worm
dev/.shit/red.tgz ! Adore Worm ::/rootkits/adorew.php
usr/lib/libt ! Adore Worm ::/rootkits/adorew.php
usr/bin/adore ! Adore Worm ::/rootkits/adorew.php
*/klogd.o ! Adore Worm ::/rootkits/adorew.php
*/red.tar ! Adore Worm ::/rootkits/adorew.php
A identificação baseada em anomalias utiliza um enfoque mais inteligente, pois não
busca rootkits conhecidos, mas por busca detectar anomalias no sistema. As anomalias podem
ser:
Inspecionar o diretório /dev, neste caso só deveriam existir arquivos de dispositivos
e scripts Makedev;
Procurar no System Files por arquivos com anomalias de permissão, por exemplo,
arquivos cujo proprietário seja root mas que tenha permissão de escrita para
"outros", ou arquivos com suid, diretórios escondidos, etc;
Buscar processos escondidos, utilizando as funções getsuid() e kill() para fazer uma
lista de pid’s que estão sendo usados para depois comparar esta lista com a saida do
comando ps. Se houverem diferenças existe a possibilidade de um rootkit a nível de
kernel ou uma versão modificada do comando ps;
Buscar portas escondidas mediante o uso do comando bind() contra cada porta udp e
tcp;
Revisar todas as interfaces de rede em busca de interfaces em modo promiscuo e
comparar com a lista de comando ipconfig.
82
O OSSEC pode ser instalado em diversos Sistemas Operacionais, dentre os principais,
destacam-se:
Slackware 10.1 and 10.2;
Open e FreeBSD;
Fedora e RedHat
Ubuntu 5.04, 5.10 and 6.06;
MacOSX 10
Debian 3.1 Sarge
Suse ES 9
Windows XP/2000 (agent only)
O OSSEC HIDS tenta diminuir o tempo demandado pelo administrador com o
monitoramento do sistema, avisando o administrador de ataques, mudança ou alguma ameaça
no sistema, sem a necessidade de analise total dos logs, em tempo real.
Analise de logs, segurança local na maquina, entre outros fatores atualmente demanda
muito tempo, coisa rara para administradores. O OSSEC tenta minimizar o impacto dessa
falta de tempo, monitorando o sistema em tempo real, avisando o administrador de ataques,
mudança ou alguma ameaça no sistema, sem a necessidade de analise total dos logs, valendo
lembrar que analise de logs sempre será importante, independente de ferramentas auxiliares.
83
4 DETECÇÃO DE INTRUSÃO BASEADA EM REDE (NIDS)
Os ataques às redes de computadores frequentemente são antecipados por fazes de
reconhecimento e coleta de informações como enumeração e scanning; posteriormente
ocorrem as tentativas de obtenção do acesso. Estas ações conduzidas por hackers (ou crackes)
implicam em explorar vulnerabilidades remotamente. Conseqüentemente, devido à sua
natureza, estas atividades produzem “rastros” que são passíveis de serem identificados por
ferramentas para detecção de intrusão baseadas em rede, ou Network IDS (NIDS).
Este capítulo pretende apresentar conceitos e aplicações referentes aos NIDS abordando
os seguintes aspectos:
a) Conceituar o tema NIDS;
b) Classificar os tipos de anomalias de tráfego e ataques às redes de computadores;
c) Apresentar o Snort,um dos NIDS mais populares da atualidade.
4.1 IDS baseado em rede (NIDS)
O NIDS é um sistema responsável pela captura pacotes de dados, analisando o tráfego de
rede dos sistemas monitorados e comparando esses pacotes com um banco de dados de
assinaturas. Uma assinatura é um padrão presente em um pacote que pode indicar atividades
suspeitas e detectar um ou múltiplos tipos de ataques. Caso o resultado dessa comparação seja
positivo, pode ser gerado um alerta e um registro que pode resultar em uma ação.
Semelhante a um sniffer, este tipo de IDS coloca a interface de rede no chamado modo
promíscuo, que permite “escutar”, indistintamente, todos os pacotes que trafegam na sub-rede
84
no qual está inserido. As fontes de informação usadas por um IDS de rede variam desde dados
de gerenciamento, obtidos através de agentes SNMP, por exemplo, até pacotes de rede
carregando protocolos de mais alto nível (HHTP, SMTP, SMB, etc). A análise de todas essas
informações oferece subsídios aos sistemas de detecção de intrusão, agregando precisão e
desempenho às suas tarefas.
A maioria dos ataques, como negação de serviço, DNS Spoofing, entre outros, são
dificilmente detectados por HIDS, o que motivou o desenvolvimento de ferramentas
específicas que capturam e analisam pacotes de rede. Por esse motivo, a maioria dos IDS
disponíveis atualmente são baseados em rede. Sua principal função é detectar ataques que
seriam dificilmente percebidos por uma ferramenta que trabalhe com dados de um único host,
direcionando esforços ao tráfego de toda a rede.
Características positivas dos NIDS:
Detecção de ataques externos e internos;
Monitoramento pode ser fornecido por múltiplos sensores em arquiteturas
distribuídas;
Ataques de DoS e varredura como port scanning, IP spoofing, SYN flooding e
Teardrop podem ser detectados;
Pode detectar tentativas de ataques (ataques que não tiveram resultados);
Fica mais difícil um cracker apagar seu rastro;
Impõe dificuldades para o cracker saber se existe ou não um NIDS;
Causa pouco impacto no desempenho da rede existente, já que os NIDS são
compostos, em sua maioria, por dispositivos passivos.
Desvantagens dos NIDS:
Dificuldade em processar todos os pacotes observados em redes com alto tráfego,
podendo ainda apresentar perda de pacotes em redes congestionadas;
Em redes que fazem uso de switches, muitas vezes não existe o recurso no
equipamento para copiar o tráfego de todas as portas para uma porta apenas, de
forma que fica difícil colocar o IDS em um ponto que capture todo o tráfego da rede;
85
Não são capazes de analisar dados criptografados, prática cada vez mais comum nas
redes;
Algumas soluções possuem dificuldades em tratar tráfego fragmentado;
4.1.1 Posicionamento do sensor na rede
A captura de pacotes para análise em um NIDS é realizada por um elemento de rede
normalmente conhecido como sensor. Existem várias possibilidades para o posicionamento
deste dispositivo na rede sendo monitorada e que influenciam diretamente na utilidade e
qualidade dos resultados obtidos.
A Figura 4.1 apresenta os arranjos comumente utilizados para o posicionamento de
sensores em uma rede de computadores.
Figura 4.1. Posicionamento do Sensor NIDS na rede.
Na primeira forma de posicionamento, apresentada na ilustração (a) da Figura (4.1), o
sensor é colocado fora dos limites de proteção do firewall, de modo que todo o tráfego
destinado à rede monitorada é selecionado para a coleta de pacotes. Esta configuração permite
a observação de ataques direcionados ao firewall e a recursos protegidos por este. Em
contrapartida, a quantidade de dados a serem tratados é consideravelmente maior.
86
Na ilustração (b), o sensor, posicionado dentro dos limites de proteção do firewall
observa apenas o tráfego permitido e destinado à rede monitorada, eliminando assim a coleta
de todos os pacotes bloqueados. Desta forma, a quantidade de dados a serem tratados reduz
razoavelmente.
Finalmente na ilustração (c), dois sensores são posicionados: um dentro dos limites de
proteção do firewall e outro fora. Além das características apresentadas para as ilustrações
anteriores, esta abordagem permite, através da comparação do tráfego coletado pelos sensores
em ambos os lados do firewall, validar as regras de controle deste dispositivo.
4.2 Anomalias no Tráfego de Rede
Anomalias no tráfego de rede são padrões que diferem do comportamento normal do
tráfego previamente observado. Através da simples análise visual, observa-se na figuras 4.2
(a) e (b), que ilustram o monitoramento efetuado no tráfego de uma determinada rede, que se
o mesmo não sofrer alterações ou anomalias que afetem seu comportamento (por exemplo,
congestionamento, ataques, falhas na infra-estrutura, etc), em alguns casos, a sua
representação gráfica geralmente tenderá a um comportamento semelhante em todos os dias
observados, repetindo-se continuamente, podendo ocorrer pequenas alterações não
acentuadas.
A figura 4.2(a) representa o tráfego amostrado durante uma semana, onde observa-se este
padrão estatístico de repetição. O gráfico seguinte, figura 4.2(b) ilustra três semanas
consecutivas para o mesmo padrão de tráfego.
Figura 4.2(a). Exemplo de tráfego de rede sem anomalias (período de uma semana).(curva em verde: upload / curva em azul: download)
Figura 4.2(b). Exemplo de tráfego de rede sem anomalias (período de três semanas).(curva em verde: upload / curva em azul: download)
87
De acordo com [SILVA, 2007], é possível detectar o comportamento anômalo, a partir da
premissa que este será notoriamente diferente de um comportamento considerado padrão,
praticado usualmente por um usuário legítimo. Desta forma, podem ser implementados
modelos estatísticos de detecção de anomalias, ou baseados em regras (assinaturas) que
detectam o uso indevido. Anomalias em redes, portanto, apresentam-se como mudanças
significantes e pouco comuns nos padrões conhecidos de tráfego em um ou múltiplos enlaces
da rede. O diagnóstico dessas anomalias envolve a amostragem de tráfego, detecção,
identificação e a quantificação desses fenômenos.
As anomalias podem representar, entre outros fatores, indícios de ataques, eventos
relacionados à falha, abusos (ou mau uso) na rede, etc. Nem toda anomalia na rede, está
relacionada a um ataque, mas todo tráfego suspeito deve ser monitorado e analisado. A seguir,
são listadas algumas considerações em relação à necessidade de diagnosticar anomalias de
rede [LAKHINA et al., 2004]:
Anomalias podem congestionar a rede e esgotar os recursos de um roteador;
Apesar de não necessariamente gerar impacto ao tráfego global da rede, algumas
anomalias podem causar grande impacto para um cliente ou um usuário final;
Tão logo ocorram, os administradores de rede devem detectar as anomalias e
classificá-las de modo a selecionar a resposta apropriada.
Anomalias podem compreender um vasto domínio de eventos, o qual representa o
principal desafio na sua detecção e classificação: de abuso a rede (por exemplo, ataques DoS,
scans e worms), falhas de equipamentos (por exemplo, interrupções), comportamento não
comum de usuários (por exemplo, alterações bruscas sob demanda, alto volume de tráfego e
uso de programas P2P) e mesmo devido a eventos novos e previamente desconhecidos.
Anomalias no tráfego de rede, incluindo ataques e outros eventos suspeitos, podem ser
detectadas pelos NIDS a partir de dados coletados do tráfego de rede, que são informações
obtidas dos cabeçalhos e conteúdo dos pacotes de rede. Seqüestro de conexões TCP, varredura
de portas, DNS spoofing, negação de serviço, dentre outros, são alguns exemplos de ataques
88
dificilmente detectados por analisadores baseados em host. Para detectar tais eventos, são
necessárias ferramentas que capturam e analisam ataques direcionados a componentes de rede.
4.3 Classificação de Anomalias na Rede
Um estudo feito por [BARFORD, 2001], classificou as anomalias no tráfego de rede em
quatro principais categorias: anomalias de operação da rede, ‘flash crowd’, anomalias de
medição e ataques; descritas a seguir.
4.3.1 Anomalias de Operação da Rede
Identificadas visualmente, em muitos casos, através de súbitos aclives e declives no
tráfego de rede da rede, alterações súbitas na taxa de bits seguidas de taxas de bits que são
estáveis, em um nível diferente do padrão normal, em determinado período de tempo. Entre
outros eventos, podem ser causados por:
a) eventos de falhas na rede (interrupção de funcionamento de equipamentos);
b) a adição de novos equipamentos (traffic shape ou modelagem de tráfego);
c) configuração inadequada temporária de dispositivos;
d) definição de limites de taxas podem resultar em eventos que geram diferenças
significativas no comportamento da rede.
4.3.2 Anomalias ‘Flash Crowd’
Em geral, estão relacionadas a eventos como o lançamento de uma nova versão do
software, resultando no aumento do acesso a um site Web, por exemplo, devido a algum tipo
de publicidade nacional. O comportamento flash crowd é identificado por um rápido
crescimento nos fluxos de um determinado tipo tráfego (por exemplo, fluxos FTP/HTTP),
esgotando conseqüentemente os recursos de comunicação do site web (semelhante a um
ataque DoS), ou ainda o link de comunicação, tendendo com o tempo ao retorno gradual da
normalidade. Um exemplo típico de anomalia flash crowd é ilustrado na figura 4.3 a seguir,
onde o fluxo de upload crescente (no sentido da rede interna para Internet) denuncia o súbito
89
aumento no acesso de um (ou vários) servidor(s) de uma determinada rede de computadores,
entre 6:19h e 8:45h, congestionando conseqüentemente o link de comunicação.
Figura 4.3. Anomalia Flash Crowd, detectada em um link de comunicação(curva em verde: upload / curva em azul: download)
4.3.3 Anomalias de Medição
Anomalia cuja natureza não apresenta características de problemas atribuídos à infra-
estrutura ou por uso abusivo da rede. Normalmente estão relacionadas a informações
incorretas repassadas por equipamentos (roteadores, switch, etc) dos parâmetros ou
indicadores de rede, como: latência, throughput, perda de pacotes; ou seja, o equipamento
funciona corretamente mas apresenta informações não condizentes com a realidade, devido a
um problema do software de gerência ou na coleta de dados.
4.3.4 Ataques
Ataques em redes de computadores compreendem um “conjunto de ações ilícitas que
tentam comprometer a integridade, confidencialidade, ou disponibilidade de recursos na
rede”, independente do sucesso ou não destas ações. Regras de privacidade podem ser
quebradas devido a um ataque, comprometendo a confidencialidade da informação.
Informações podem ser alteradas, modificando a integridade dos dados e a infra-estrutura de
rede pode tornar-se indisponível e não confiável.
4.3.4.1 Classificação de Ataques a Redes
Violações às propriedades de segurança de dados e sistemas computacionais em rede
podem ser descritas como:
90
Anomalia Flash crowd
a) Impedimento de acesso a recursos e sistemas em rede por um usuário, humano
ou máquina, autorizado (violação de disponibilidade);
b) Acesso aos dados sem autorização (implícita ou explícita) do proprietário da
informação (violação de confidencialidade);
c) Alteração ilegal do estado do sistema ou de dados residindo ou trafegando no
sistema (violação de integridade).
A grande maioria dos ataques bem sucedidos ocorre devido a vulnerabilidades ou falhas
potenciais existentes nos sistemas em rede, que podem estar relacionadas com uma
configuração incorreta do sistema ou falha no desenvolvimento do software.
Existem diferentes classificações para ataques. Estes podem ser classificados quanto à sua
origem, ao seu alvo e quanto aos seus objetivos.
Quanto à origem, os ataques podem ser externos ou internos:
a) Ataques externos: são lançados de fora da rede por um atacante que tenta acessar
a rede para obter informações, divertir-se ou tornar indisponíveis determinados
serviços da rede alvo;
b) Ataques internos: são aqueles provenientes de usuários internos à rede que
abusam de seus direitos e privilégios para realizar atividades não autorizadas e
para obter acesso não autorizado a recursos e sistemas em rede.
Uma classificação de ataques com base em alvo pode ser descrita como:
a) Ataques à rede: visam impedir os usuários de utilizar recursos de rede ou tornar
os serviços de rede indisponíveis. Podem também monitorar o tráfego de rede
para coletar informações convenientes para ações futuras;
b) Ataques a sistemas: o propósito destes ataques é comprometer o sistema, bem
como modificar informações ou remover arquivos críticos, tais como arquivos de
senhas e de configuração do sistema. Neste contexto, encontram-se os ataques
91
que visam à modificação de páginas web (deface) para depreciação ou
ridicularização da imagem de empresas.
Quanto a seus objetivos, os ataques mais freqüentes a redes de computadores podem ser
classificados como negação de serviço ou DoS; varredura ou Probing; obtenção de acesso,
também conhecido por U2R (User to Root) e R2L (Remote to Local). Estes ataques podem
ser lançados no local ou remotamente, através de uma conexão de rede, sem qualquer conta de
usuário ou acesso privilegiado ao sistema alvo, mas utilizando apenas o acesso publico
concedido pelo sistema alvo.
Uma estratégia típica utilizada pelos atacantes é disparar um ataque utilizando uma conta
de usuário sem privilégio para ganhar acesso inicial ao sistema. Uma vez obtido o acesso ao
sistema, o atacante utiliza conta de usuário autorizado para tentar elevar seus privilégios e
obter controle completo do alvo.
A maioria dos ataques é executada através de scripts, conhecidos como exploits, os quais
automatizam os processos de tentativa de conexões em varias portas, enviando pacotes
“fabricados” ou com códigos para consultas a bases de dados de sistemas, entre outros. Certos
atacantes realizam também técnicas de falsificação de endereço (spooffing) de origem dos
pacotes. Deste modo, o atacante consegue esconder sua origem ou até mesmo se passar por
outra máquina conseguindo um acesso privilegiado.
4.3.4.2 Ataques de Negação de Serviço DoS
O principal objetivo deste tipo de ataque é tentar reduzir o desempenho ou tornar
inoperante um serviço, estação servidora ou equipamento ligado em rede. Alguns exemplos
conhecidos de ataques desta categoria são: Apache2, Mail bomb, SYN Flood, Ping of death,
Smurf, Syslogd, Teardrop e Udpstorm. Algumas estratégias utilizadas nos ataques DoS,
incluem:
a) Inundação (Flood) visando impedir que usuários legítimos façam uso dela;
b) Impedir ou romper a conexão entre duas máquinas visando impedir o acesso a
um serviço;
c) Impedir ou negar o acesso de um determinado serviço ou site.
92
Os três tipos principais de ataques de negação de serviço são:
a) Exploração de falhas: exploram vulnerabilidades no software do sistema alvo
causando falhas em seu processamento ou extinguindo seus recursos;
b) Flooding: enviam a um sistema mais informação do que ele é capaz de
manipular, bloqueando assim qualquer tipo de uso deste recurso através da
obstrução do canal de comunicação, ou esgotamento de recursos como memória
e processamento;A figura 4.4 a seguir ilustra este conceito.
Figura 4.4. Ataque de Negação de Serviço – DoS.
c) Ataques de negação de serviço distribuído (Distributed DoS – DdoS): são
inundações de ataques DoS onde vários computadores efetuam ataques
simultaneamente, conforme ilustrado na figura 4.5 a seguir.
Figura 4.5. Ataque de Negação de Serviço Distribuído - DDoS.
Neste tipo de ataque é realizada uma sobrecarga ou inundação de pacotes contra um
determinado serviço, host ou rede, gerando muitas vezes uma quantidade de dados global
93
Serviço interrompido
Serviço interrompido
maior que a rede ou host pode suportar, tornando a rede ou serviços instáveis e
conseqüentemente prejudicando o seu desempenho.
Estes ataques possuem uma estrutura previamente montada, onde diversas máquinas
lançam um ataque sobre uma vítima. É comum o uso de várias “máquinas zumbis” para que o
número de requisições de conexão ao servidor seja muito maior (figura 4.6) do que o
produzido por uma única máquina. São ataques mais eficientes e complexos e difíceis de
bloquear, uma vez que são originados de vários computadores atacando inúmeras portas.
Figura 4.6. Sistemática de um ataque DDoS
4.3.4.2.1 Tipos de ataques DoS
Esta seção é dedicada a enumerar e descrever os tipos de ataques DoS conhecidos.
a) Smurf: ataque que utiliza de redes que permitam tráfego na interface de
broadcast. O ataque consiste na falsificação do endereço de origem de um
pacote ICMP echo request, fazendo com que uma grande quantidade de
respostas, pacotes ICMP echo reply, sejam direcionadas ao endereço que foi
falsificado;
b) UDP Storm: a exemplo do ataque anterior o objetivo é congestionar a rede e, por
conseguinte, diminuir a largura de banda da mesma. Ao se estabelecer uma
conexão entre dois serviços UDP, por exemplo, echo/UDP e chargen/UDP,
serão gerados uma grande quantidade de pacotes na rede até que ocorra uma
intervenção externa, como, por exemplo, reiniciar o serviço inetd;
94
Atacante
Mestre
Zumbi Zumbi Zumbi Zumbi
Mestre
Zumbi Zumbi Zumbi Zumbi
Mestre
Zumbi Zumbi Zumbi Zumbi
Site Alvo
c) SYN Flood: este ataque explora as limitações do processo inicial de uma
conexão denominado handshake, procedimento que, através do envio de pacotes
TCP com os flags SYN e ACK habilitados entre cliente e servidor, permite
efetuar o inicio de uma conexão a um serviço. O objetivo é exceder os limites
definidos para o número de conexões que podem ser estabelecidas à um
determinado serviço. Isso faz com que não seja possível estabelecer quaisquer
outras conexões a esse serviço até que o número de conexões em espera seja
reduzido. O problema mais crítico que envolve esse tipo de ataque e os IDSs é a
alta probabilidade de falsos positivos, uma vez que nem todas as tentativas de
conexões em um pequeno intervalo de tempo, podem ser consideradas tentativas
de SYN Flood;
d) Teardrop: ao contrário do ataque denominado Smurf, que utiliza a “força bruta”
para gerar o ataque, utilizando-se de falhas em diferentes implementações da
pilha TCP/IP. Este ataque explora a incapacidade de alguns sistemas
operacionais de reconstituir pacotes IP fragmentados. Como resultado, os
sistemas suscetíveis a esse ataque têm o seu funcionamento (S.O)
comprometido;
e) ICMP Fragmentation: para ser transmitido entre redes locais, um pacote IP
deve ser fragmentado toda vez que exceder o limite do maior quadro que uma
determinada rede local é capaz de transmitir (Maximum Transfer Unit - MTU).
Nesse caso, é necessário dividir o pacote IP em fragmentos menores que a MTU.
O protocolo ICMP é um protocolo auxiliar ao IP, que carrega informações de
controle e diagnóstico, informando falhas como TTL do pacote IP excedido,
erros de fragmentação e roteadores congestionados. O ataque em questão
consiste no envio de um pacote ICMP mal formado para uma determinada
estação, fazendo com que a estação de destino ao receber este pacote reduza a
MTU desnecessariamente. Isto faz com que a conexão entre essas duas estações
fique extremamente lenta. Além disso, em função da quantidade de pacotes
enviados uma razoável quantidade da largura de banda é consumida.
95
4.3.4.2.2 Ferramentas para ataque DoS
Diversos tipos ferramentas de DoS foram desenvolvidos nos últimos anos. A Tabela 4.1
exibe algumas das principais ferramentas e respectivos ataques de DoS conhecidos. A maioria
dessas ferramentas podem ser encontradas em sites na Internet como o Packet Storm14.
Ferramentas Tipo de tráfego gerado
Smurf inundação de pacotes ICMP echo-reply
Trinoo inundação de datagramas UDP em portas aleatórias
TFN e TFN2K inundação de pacotes ICMP, UDM e TCP syn (flag syn setado); pacotes errôneos; smurf
TFN2K (ping flood) inundação pacotes ICMP e smurf
TFN2K Targa 3 Pacotes IP inválidos
stacheldraht v.2.666 Inundação de pacotes ICMP, UDP, TCP syn (flag syn setado), TCP null (nenhum flag setado), TCP ack (flag ack setado) e smurf
Shaft Inundação de pacotes ICMP, UDP, TCP syn
mstream inundação de pacotes TCP ack (flag ack setado)
Tabela 4.1. Ferramentas para ataque DoS e tipo de tráfego respectivo.
4.3.4.3 Ataques de Varredura (Probing)
Realizam varredura de uma rede ou de sistemas-alvo, através do envio de diferentes tipos
de pacotes de rede, em busca de vulnerabilidades e informações de interesse para o
planejamento de ataques. Tais informações são usadas para compreender as características de
funcionamento da rede, incluindo a sua topologia, os hosts ativos e suas respectivas
configurações de software, incluindo sistema operacional, versões de serviços ativos,
possíveis vulnerabilidades, etc.
Também denominados ataques de sondagem (ou “Probing”), estes não penetram ou
comprometem os sistemas. Em geral, estes ataques possuem várias denominações,
dependendo das atividades que executam: network ou port scanners, port ou network
mappers ou vulnerability scanners. A seguir, são descritos os tipos mais relevantes de ataques
de varredura:
14 http:www.packetstormsecurity.com
96
a) TCP connect: a chamada de sistema connect(), provida pelo sistema
operacional, é usada para estabelecer conexão com um conjunto de portas na
máquina alvo. Caso a porta esteja no estado listening, connect irá estabelecer
uma conexão; caso contrário o usuário receberá a mensagem de porta
inalcançável;
b) SYN Scan: técnica conhecida como “half-open scanning” por não estabelecer
uma conexão TCP completa. O primeiro pacote a ser enviado está com o flag
SYN configurado para estabelecer uma conexão real e, portanto, deve aguardar
uma resposta da estação para a qual o pacote foi enviado. Ao receber uma
resposta com os flags SYN/ACK ligados isto indica que a porta está no estado
listening. Já uma resposta com o flag RST ligado é uma indicação que a porta
está fechada. Se o flag SYN/ACK é recebido, o flag RST é imediatamente
enviado para encerrar a conexão;
c) ACK Scan: este tipo de sondagem envia pacotes com o flag ACK para uma
porta específica. Caso seja retornado um pacote TCP com flag RST ligado, a
porta é classificada como "não filtrada"; caso seja retornado um ICMP
unreachable, a porta é classificada como "filtrada";
d) Window Scan: tipo de scan é muito similar ao ACK scan, no entanto é possível
detectar portas abertas mesmo quando essas estão sendo filtradas por um
firewall. Isso ocorre devido ao tamanho da janela TCP existentes em diversos
sistemas operacionais (por exemplo: FreeBSD, SunOS e OpenVMS);
e) FIN Scan : consiste em enviar um pacote com o flag FIN habilitado para uma
determinada porta. Segundo a RFC 793 as portas que estiverem fechadas devem
responder com um pacote TCP com o flag RST ligado, enquanto que as portas
que estiverem abertas devem ignorar o pacote em questão;
f) UDP Scan : método usado para determinar quais as portas UDP estão abertas. A
técnica implica em enviar 0 bytes de dados de pacotes UDP para cada porta da
estação alvo. Caso a resposta seja uma mensagem ICMP port unreachable então
a porta está fechada;
97
g) TCP Ping: através desta técnica é possível determinar quais as estações que
estão ativas no momento. Para tal, ao invés de enviar pacotes ICMP echo
request e aguardar pelas respostas são enviados pacotes com flag ACK
habilitado por toda a rede. Estações que estiverem ligadas devem responder com
um pacote TCP com o flag RST habilitado;
h) TCP fragmentation scanning: esta forma de sondagem utiliza várias outras
técnicas de varredura de portas tais como SYN scan, FIN scan, etc. Os pacotes
enviados a estação alvo são fragmentados, ou seja, o cabeçalho TCP é dividido
em vários pacotes. Com isso, os IDSs que não possuem mecanismos eficientes
de remontagem de pacotes não conseguem identificar essa forma de ataque, pois
os diversos datagramas enviados individualmente não correspondem a uma
ameaça;
i) Identificação Remota de Sistemas Operacionais (fingerprinting): a fim de
identificar o sistema operacional instalado em uma determinada estação, se
utiliza um conjunto de técnicas que detectam características da implementação
do protocolo TCP/IP do sistema operacional que está instalado na estação alvo.
Uma vez que essas características tenham sido identificadas é realizada uma
comparação dessas informações com a base de dados da ferramenta de ataque, a
fim de definir qual o sistema operacional da estação em questão.
Embora seja difícil evitar que alguém lance uma sonda de varredura de portas contra um
sistema em particular, a exposição pode ser minimizada através da desativação de todos os
serviços desnecessários.
4.3.4.4 Ataques de Penetração
Os ataques de penetração, conhecidos como ataques R2L e U2R, realizam aquisição ou
alteração não autorizada dos privilégios, recursos ou dados do sistema, violando as
propriedades de integridade e controle dos recursos e dados. Com estes ataques, pode-se
ganhar controle de um sistema ao explorar uma variedade de falhas de software.
98
a) Ataque R2L (Remote to Local): ocorre quando um usuário remotamente realiza
um acesso não autorizado a uma maquina e consegue privilégios de usuário
local. Neste tipo de ataque, são enviados pacotes para uma maquina na rede na
qual o atacante não tem conta e, em seguida, são exploradas algumas
vulnerabilidades desta máquina que permitem a obtenção de acesso local como
se fosse um usuário daquela maquina;
b) Ataque U2R (User to Root): ocorre quando um atacante inicia a exploração do
host com uma conta de usuário normal do sistema e consegue explorar
vulnerabilidades deste para ganhar acesso de root ao sistema.
4.4 O NIDS Snort15
Snort é uma ferramenta NIDS Open Source originalmente projetado para ambientes de
rede com tráfego moderado. É baseado em uma linguagem orientada a regras, capaz de
executar análises de tráfego e registros de pacotes em tempo real, combinando os benefícios
dos métodos de inspeção baseados em assinatura de ataques, protocolo e anomalia.
Sua popularidade deve-se à flexibilidade nas configurações de regras, em constante
atualização, simplicidade e eficiência, o que o tornou também um padrão “de fato” para a
indústria.
O Snort surgiu em 1998 de um projeto chamado APE, desenvolvido por Marty Roesch.
Marty, que estava insatisfeito com algumas características do programa tcpdump, um software
desenvolvido para captura de pacotes, cujo objetivo é auxiliar a análise do tráfego do TCP/IP.
Na época do seu lançamento, o APE possuía mais recursos e funcionalidades que o tcpdump.
No mesmo ano, Marty modificou o projeto, utilizando a denominação Snort. A primeira
versão funcionava apenas como um software de captura de pacotes. Os primeiros testes de
Marty com o Snort incluíam o monitoramento de sua conexão de modem a cabo e a depuração
de aplicativos de rede. Em 1999, foi introduzido no Snort a primeira análise baseada em
assinatura, adicionando a este software a funcionalidade de detecção de intrusão.
15 http:www.snort.org
99
Em 22 de dezembro de 1998, o Snort foi disponibilizado no site Packet Storm pela
primeira vez. Naquela época, o Snort possuía cerca de 1600 linhas de código e um total de
dois arquivos. Mais tarde o projeto foi ampliado e portado para outras plataformas, como
sistemas Linux, FreeBSD, NetBSD, OpenBSD, Windows, Sparc Solarios, Power PC, MacOS
X e PA-RISC HP-UX, e nas plataformas de hardware Intel, RISC, PowerPC e Sparc.
O fato de ser disponibilizado em Open Source permitiu ao uso do Snort sem qualquer
preocupação de aquisição licenças de softwares proprietários, possibilitando também aos
utilizadores desenvolver as suas próprias regras para detecção de ataques. Tal fato permitiu
que, ao longo do tempo, inúmeras correções e melhorias fossem incorporadas ao Snort, o que
ainda acontece atualmente.
4.4.1 Funcionamento do Snort
Quando um pacote chega até uma interface de rede, ele passa por uma série de estágios
até que se possa gerar um alerta, log ou descarte.
Os estágios de processamento são antecipados pela fase de captura de pacotes. Para
funcionar corretamente, o Snort necessita de um mecanismo que capture o tráfego à medida
que ele passe pela rede. Este mecanismo é a biblioteca Libpcap, responsável por colocar a
placa de rede no modo de operação promíscuo. A biblioteca Libpcap foi escrita como parte do
tcpdump. Esta biblioteca permite que programadores escrevam códigos para receber pacotes
da camada de link de dados, permitindo o desenvolvimento de programas para decodificar,
exibir ou registrar pacotes.
Assim que os pacotes chegam da placa de rede e são repassados para o mecanismo de
decodificação do Snort pela biblioteca Libpcap, o Snort precisa decodificar os pacotes brutos
da camada de link de dados. O decodificador de pacotes é responsável por implementar esta
função. Nesta etapa, o Snort poderá, então, assumir três modalidades de funcionamento,
descritas a seguir:
a) Sniffer: esta modalidade simplesmente captura os pacotes e exibe continuamente
as informações no monitor. (ex: ./snort -vde);
100
b) Packet logger: codificador fará com que os dados sejam formatados em
ASCII38 ou então no formato binário e arquivados no disco rígido
(ex: ./snort -dev -l ./log);
c) Network intrusion detection system: Esta modalidade é a mais complexa e
versátil, permitindo que o Snort analise o tráfego da rede de encontro a regras
definidas pelo usuário, executando diversas ações baseadas em suas regras.
(ex: ./snort -c /etc/snort/snort.conf -i eth0 -D).
Após a decodificação de pacotes, os dados são então enviados para os pré-processadores
que estiverem ativos, conforme ilustrado na figura 4.7 a seguir. Os pré-processadores efetuam
ajustes e reagrupamentos nos pacotes para que as regras sejam aplicadas de uma forma mais
otimizada.. Posteriormente os dados passam para o sistema de detecção de assinaturas
responsável pela comparação dos dados com o banco de dados de regras pré-estabelecidas no
arquivo de configuração do Snort.
Figura 4.7. Fluxo de funcionamento do Snort
Ocorrendo sucesso na comparação das informações, outros componentes (módulos de
saída) irão gerar alertas e registrar as ocorrências em arquivos de logs. Caso contrário o pacote
será descartado.
101
4.4.2 Componentes do Snort
O Snort possui uma arquitetura modular, ou seja, é dividido em componentes que
trabalham em conjunto na captura de pacotes, detecção de ataques e no registro de alertas. A
figura 4.8 a seguir apresenta a pilha funcional do Snort.
Figura 4.8. Pilha funcional do Snort
Esta seção é dedicada a descrição mais detalhada a respeito destes módulos funcionais,
destacando a biblioteca libpcap, o decodificador de pacotes, pré-processadores, ferramenta de
detecção e outros componentes; descritos a seguir.
a) Libpcap: O Snort utiliza a biblioteca de funções libpcap, responsável por
capturar tráfego de rede de baixo nível, como dados do cabeçalho dos pacotes
TCP, UDP e ICMP (em nível de Transporte), IP (em nível de Rede) e Ethernet
(em nível de Enlace);
b) Decodificador de pacotes: neste estágio é possível determinar qual protocolo
está sendo utilizado em um determinado pacote. Assim, é possível comparar as
informações com regras pré-estabelecidas referentes àquele protocolo. É possível
gerar alertas de cabeçalhos incompletos ou mal formados, com seu conteúdo
acima do normal, opções incomuns ou incorretas, dentre outros;
c) Pré-processadores (Pre-processors): são componentes ou plug-ins que
organizam ou modificam pacotes de dados antes que o sistema de detecção
realize alguma operação caso um determinado pacote esteja sendo utilizado por
102
algum intruso. Alguns pré-processadores efetuam detecção por anomalia em
cabeçalhos de pacotes e geração de alertas. Os pré-processadores também podem
ser utilizados para desfragmentar pacotes. Quando uma grande fatia de dados é
transferida para um host, o pacote é normalmente fragmentado;
d) Mecanismos de detecção: é o componente do Snort que manipula os dados do
decodificador de pacotes ou do pré-processador e os compara com as regras.
Para que isso seja possível, primeiro, a ferramenta de detecção procura
determinar qual conjunto de regras deve ser utilizada para comparação com o
pacote. As regras estão divididas primeiramente por protocolos, TCP, UDP,
ICMP ou IP. E então por características dos protocolos. Uma vez determinado o
conjunto de regras, a ferramenta de detecção segue os padrões estabelecidos em
cada regra. A primeira regra da lista a combinar com a informação do pacote é a
primeira a disparar. Por padrão o Snort dispara o alerta apenas uma vez a cada
pacote mas o Snort também é capaz de gerar alertas depois da ocorrência de um
certo número de combinações bem sucedidas, dentro de um determinado período
de tempo;
e) Subsistema de resposta: Após as regras terem sido comparadas, entram em
ação os componentes responsáveis por gerar alertas e logs. O mecanismo de log
será responsável por registrar os pacotes que dispararam as regras. O mecanismo
de alerta é utilizado para notificar o administrador sobre o problema emergente.
Da mesma forma que os pré-processadores essas funções são todas configuradas
no arquivo de configuração do Snort;
f) Módulos de saída (Output Modules): basicamente, os módulos de saída
controlam os tipos de saída gerados pelo sistema de logs e alertas. Dependendo
da configuração do Snort, os módulos de saída podem realizar o log de alertas
para o diretório padrão de logs do Snort, ou para outro formato de arquivo, como
XML (eXtensible Markup Language), ou para um banco de dados.
103
4.5 Sistemas de Prevenção de Intrusão (IPS)
Resposta ativa pode ser definida como uma reconfiguração dinâmica ou alteração nos
mecanismos que controlam o acesso a rede ou sessões. Quando se fala em alterar pacotes com
o objetivo de anular ataques que estão acontecendo a dispositivos internos, está se falando de
IPS (Intrusion Prevention System). Em outras palavras, o IPS é posto em linha, ou no caminho
do tráfego, e evita que o ataque chegue até o sistema alvo, respondendo automaticamente a
uma ameaça tentando minimizá-la ou, melhor ainda, contê-la completamente. Tudo isso sem a
interferência de um administrador.
A figura 4.9 ilustra este conceito e exibe o posicionamento de um sistema IPS em relação
ao tráfego. Nesta figura outros sensores distribuídos na rede também podem gerar alertas
auxiliar o IPS na criação de regras através do correlacionamento de eventos, diminuindo assim
a chance de falso positivos.
Figura 4.9. Posicionamento do IPS e sensores Snort em uma rede de computadores.
Em geral, todo IPS é um IDS, a diferença é que o IPS toma uma ação quando detecta
algum ataque. Exemplos destas ações são: enganar conexões TCP, finalizando-as em ambos
os sentidos ao se perceber que um possível ataque está a caminho; enviar pacotes ICMP, num
esforço de convencer o invasor de que a máquina alvo está fora do ar e reconfigurar firewalls
ou routers que estão no caminho, para bloquear o tráfego.
Alguns IPS são capazes inclusive de disparar outros softwares como, por
exemplo,nameserver, lookups, nmap ou traceroutes, com a intenção de buscar informações
sobre o atacante. Com isso, é possível ter uma certa automação e o administrador de sistema
104
não precisa estar atento todo o tempo ao que está se passando pela rede. Em contrapartida, a
configuração incorreta do mesmo poderá gerar sérias conseqüências.
De maneira geral, há quatro diferentes estratégias para respostas ativas baseadas na rede,
cada uma delas correspondendo a uma camada diferente do protocolo, são elas: link de dados;
rede; transporte e aplicação.
No nível de link de dados, é possível desabilitar a porta do swicth por onde a informação
(ataque) é transportado. No nível de rede é possível alterar alguma regra no firewall ou router.
Bloqueando todos os pacotes de ou para o endereço do invasor. No nível de transporte, é
possível finalizar conexões utilizando os protocolos TCP (TCP FIN) ou encaminhar
mensagens de host inatingível utilizando o ICMP. E no nível de aplicação, é possível alterar
os dados do pacote individualmente.
Snortsam16 e o Guardian17 são plug-ins de saída para o Snort que têm a capacidade de gerar
regras de firewall, bloqueando tentativas de invasão em tempo real. O Snortsam funciona
como um agente de software e fornece uma ligação entre a detecção de uma exploração e a
configuração de um firewall para bloquear o endereço IP de origem do ataque. O Guardian é
uma ferramenta que tem a capacidade de ler os logs do Snort em tempo real e gerar regras de firewall
bloqueando os IP's de origens dos ataques.
16 http:www.snortsam.net17 http:www.chaotic.org/guardian
105
5 SIMULAÇÕES E RESULTADOS
Este capítulo apresenta os cenários utilizados para a realização das simulações de ataques,
visando avaliar e discutir os resultados obtidos pela detecção de intrusão com o NIDS Snort.
A intenção é aproximar os testes de um ambiente de rede sob ataque real, através do qual
serão feitas análises do tráfego durante a realização das simulações.
As implementações apresentadas neste capítulo utilizaram a abordagem de consolidação
de um ambiente de simulação baseado em máquinas virtuais. Em vez da utilização de vários
equipamentos com seus respectivos sistemas operacionais, usou-se somente um computador,
abrigando os diversos sistemas operacionais (e suas respectivas aplicações e serviços),
hospedados em máquinas virtuais; cuja características e aplicabilidades são na seção a seguir.
5.1 Utilização de Máquinas Virtuais
A utilização de máquinas virtuais está se tornando uma alternativa, tanto para ambientes
de produção, quanto para teste e avaliação de software. Dentre as inúmeras vantagens,
destacam-se:
a) Compatibilidade do software: a máquina virtual fornece uma abstração
compatível de modo que todo o software escrito para ela funcione;
b) Isolamento: faz com que os softwares que funcionam na máquina virtual e nas
outras máquinas virtuais e máquinas reais estejam totalmente isolados;
106
c) Encapsulamento: é usado para manipular e controlar a execução do software na
máquina virtual;
Uma das principais desvantagens na utilização de máquinas virtuais fica por conta do
desempenho, pois adicionar uma camada de software a um sistema pode afetar o desempenho
do software que funciona na máquina virtual e o custo para a execução de um processo fica
mais alto que em um computador real, mas os benefícios do uso de sistemas virtuais
compensam esta deficiência.
5.1.1 Máquinas Virtuais
A pesquisa e utilização de máquinas virtuais não é um fato recente, suas origens
remontam no final dos anos 50. As máquinas virtuais foram originalmente desenvolvidas para
centralizar os sistemas de computador utilizados no ambiente VM/370 da IBM.
Segundo descreve [RAITZ, 2005], uma máquina virtual (VM) pode ser definida como
uma máquina abstrata, ao contrário de uma máquina emulada, que permite que a máquina real
seja particionada de tal modo que diversos sistemas operacionais sejam executados ao mesmo
tempo. Um emulador é um software que simula um computador real, o que possibilita
executar um aplicativo de uma plataforma em outra; por exemplo, um aplicativo do Windows
executando no Linux (ex: Wine).
Segundo [LAUREANO, 2004], a funcionalidade e o nível de abstração de uma máquina
virtual encontra-se em uma posição intermediária entre uma máquina real e um emulador, de
forma que os recursos de hardware e de controle são abstraídos e usados pelas aplicações. O
software de máquina virtual cria um ambiente através de um monitor de máquina virtual
(Virtual Machine Monitor – VMM), também denominado “sistema operacional para sistemas
operacionais”, que é um computador com seu próprio sistema operacional dentro de outro
sistema operacional (host). O VMM pode criar uma ou mais máquinas virtuais sobre uma
única máquina, sem que nenhuma interfira na outra e também não interfira no sistema real
onde o software de máquina virtual está instalado.
107
Enquanto um emulador fornece uma camada de abstração completa entre o sistema em
execução e o hardware, um VMM abstrai o hardware subjacente e controla uma ou mais
máquinas virtuais. Cada VM fornece facilidades para uma aplicação ou um “sistema
convidado” que acredita estar executando sobre um ambiente normal de acesso físico ao
hardware.
5.1.2 Tipos de máquinas virtuais
Existem basicamente duas abordagens para a construção de sistemas de máquinas
virtuais: o tipo I (figura 5.1a), onde o monitor de máquinas virtuais é implementado entre o
hardware e os sistemas convidados, e o tipo II (figura 5.1b), onde o monitor é implementado
como um processo de um sistema operacional real subjacente, denominado sistema anfitrião.
Figura 5.1. Monitor de máquinas virtuais (VMM), tipos I e II.
5.1.3 Vmware Workstation18
O VMware® Workstation é um produto comercial para virtualização de desktop e
funciona como um monitor de máquinas virtuais para desenvolvimento/testes de software. Ele
permite que os usuários executem simultaneamente, em um único PC, vários sistemas
operacionais baseados em x86, inclusive Windows, Linux e NetWare, e os respectivos
aplicativos, por meio de máquinas virtuais portáteis interligadas em rede, sem que seja
necessário particionar o disco rígido ou reinicializar a máquina (ver Figura 5.2).
18 www.vmware.com/br/pdf/ws_datasheet_br.pdf
108
Figura 5.2.Tela principal do Vmware Workstation 5
O VMware Workstation funciona criando máquinas virtuais seguras e totalmente isoladas
que encapsulam um sistema operacional e seus aplicativos. A camada de virtualização
VMware mapeia os recursos físicos de hardware para os recursos da máquina virtual, de
forma que cada máquina virtual tenha seus próprios componentes, como CPU, memória,
discos, dispositivos de I/O etc., e seja o equivalente exato de uma máquina x86 padrão. O
VMware Workstation é instalado no sistema operacional do host e oferece amplo suporte a
hardware, pois herda o suporte a dispositivos do host.
Os arquivos das máquinas virtuais são armazenados em “discos virtuais” que aparecem
como arquivos dentro de uma pasta no sistema anfitrião. Cada sistema operacional pode ter
uma configuração de rede distinta, com seu próprio endereço IP, assim como outras
funcionalidades. As máquinas virtuais ficam acessíveis na rede, permitindo que se rode
qualquer serviço, sem comprometer a segurança do sistema principal.
5.2 Metodologia e ambiente proposto
Este trabalho tem como pressuposto a utilização de máquinas virtuais de tipo II para
simulação dos ambientes de teste. A lista a seguir descreve o hardware e os softwares
utilizados para a montagem do ambiente de simulação:
109
a) Software VMM (tipo II): VMWare Workstation 5;
b) Sistema Anfitrião para o VMM: Windows XP Professional (SP2);
c) Hardware: Microcomputador PC-AT, Processador Intel Pentium 4 Dual
Core(3GHz), 2GB de Memória, Hard Disk 80GB (SATA);
d) Sistemas Operacionais convidados: Windows XP, Windows 2003 Server,
Ubuntu Linux Server 8.04, Backtrack 3;.
e) Software NIDS: Snort versão 2.8.2;
f) Frontend para consulta dos alertas: BASE19(Basic Analysis and Security
Engine). O Snort armazena os alertas gerados na base MySQL ;
g) Download via oinkmaster20 do conjunto de regras do SourceFire21 (regras VRT -
Vulnerability Research Team - Certified Rules for Snort CURRENT) e regras do
Bleeding Edge Threats22
Nas simulações foram avaliadas a capacidade de detecção, o volume de trafego detectado,
a exatidão em relação a identificação do tráfego de ataque e a utilização de técnicas de evasão.
A metodologia proposta é composta por etapas de: definição do ambiente de simulação
(escolha dos computadores envolvidos nos testes, utilização de um monitor de máquinas
virtuais, escolha Sistemas Operacionais, softwares, etc); seleção das ferramentas utilizadas
nos ataques; montagem do ambiente de simulação; geração do tráfego; coleta e análise dos
resultados.
Os cenários propostos foram concebidos visando identificar o tráfego malicioso
produzido pelas seguintes metodologias e ferramentas de ataque:
a) Cenário 1:
Information Gathering: web scanning e enumeração e portas;
19 http://base.secureideas.net/
20 http://oinkmaster.sourceforge.net/
21 http://www.snort.org
22 http://www.bleedingthreats.net/
110
b) Cenário 2:
Vulnerability Assessment: identificação de falhas/vulnerabilidades de
segurança
Exploit and Attack: obtenção de acesso;
5.3 Seleção das ferramentas de ataque
Essa etapa foi dedicada à pesquisa e obtenção de ferramentas que permitissem gerar o
tráfego desejado e implementar o cenário proposto. Como o principal objetivo era a analisar a
capacidade de detecção do Snort frente aos diversos ataques, foi dada preferência a escolha e
ferramentas de ataque automatizado.
Ao longo dessa etapa as principais fontes utilizadas para busca de ferramentas e
aprendizado sobre o uso das mesmas foram:
a) Sites que disponibilizam informações sobre segurança e vulnerabilidades de
sistemas computacionais;
b) Artigos e periódicos publicados que descrevem simulações e resultados usando
estas ferramentas;
c) Sites dos desenvolvedores (insecure.org e packetstorm.rlz.cl).
5.4 Cenário 1 – Nikto e Nmap
O primeiro cenário de estudo tem como proposta a execução testes com as ferramentas
nmap e nikto, a fim aferir a sensibilidade das assinaturas em relação a fase de obtenção de
informações (Information Gathering). Na fase Information Gathering o atacante tenta
levantar o maior número informações possíveis sobre a rede alvo: hosts ativos, serviços e
respectivas versões, versão dos sistema sistemas operacionais, etc; normalmente esta etapa é
precursora aos ataques para obtenção de acesso, bem como ataques DoS. De forma
complementar, também serão apresentados alguns testes usando técnicas de evasão de IDS,
visando demonstrar tentativas para enganar o Snort e realizar intrusões sem gerar alertas.
111
A figura 5.3 a seguir ilustra a rede de teste para o primeiro cenário, onde será avaliada a
capacidade de detecção do NIDS Snort. Nesta figura são representadas as máquinas virtuais
usadas na simulação, endereços IP, os Sistemas Operacionais usados; bem como seus
respectivos papéis no ambiente de simulação.
Figura 5.3. Cenário 1, host atacante Backtrack 3.
A tabela 5.1 a seguir apresenta um resumo descritivo da figura anterior, com os
respectivos recursos alocados para cada máquina virtual no sistema hospedeiro.
Host Descrição S.O Memória HD(GB) IP Interface de rede 1 Alvo Windows 2003 Server 192 MB 1.7 192.168.10.10 Host only2 Atacante Linux Backtrack 3 80 MB Live CD 192.168.10.66 Host only3 Servidor Snort Ubuntu Linux 8.04 232 MB 9 192.168.10.2 Host-only
10.13.1.136 Bridge4 Monitoramento Windows XP(Sistema anfitrião) 2 GB 80GB 10.13.1.133 -----
Tabela 5.1. Hosts usados na simulação do cenário 1
A figura 5.4 a seguir apresenta o diagrama de blocos que ilustra a disposição máquinas
virtuais em relação ao Vmware Workstation e ao sistema anfitrião (Windows XP).
Figura 5.4. Máquinas virtuais e sistema anfitrião do cenário 1.
112
Conforme apresentado na tabela 5.1, para que alcançar os resultados desejados, o tráfego
da rede de teste (monitorada) foi isolado através de uma configuração “host-only” do Vmware
Workstation (ver figura 5.5), a qual permite a criação de uma interface de rede virtual, cujo
tráfego não se mistura ao tráfego recebido pela interface de rede real (no sistema anfitrião).
Desta forma é possível criar uma rede privada isolada da rede de produção.
Figura 5.5. Configuração da interface Host-only no Vmware Workstarion.
É possível observar também que no Cenário 1, o host atacante é representado pela
distribuição Linux Backtrack 3. A seção a seguir apresenta maiores informações sobre esta
distribuição.
5.4.1 Distribuição Linux Backtrack23
Backtrack é atualmente a melhor distribuição de Linux com foco em ferramentas de
segurança e testes de penetração (PenTest). O Backtrack pode ser usado diretamente do CD-
ROM (Live CD), possui interface gráfica (KDE, Flux Box, etc), e em minutos, pode
disponibilizar um conjunto de aplicações específicas para: obtenção de informações e
reconhecimento (Footprinting); enumeração e scanning; testes em Web Servers; testes em
redes wireless; exploit e obtenção de acesso; elevação de privilégios e manutenção do
acesso.
Atualmente BackTrack consiste de mais de 300 ferramentas diferentes e atualizadas, que
são logicamente estruturadas de acordo com o fluxo de trabalho de profissionais de segurança.
Essa estrutura permite até mesmo a novatos encontrar as ferramentas relacionadas à uma
tarefa específica para ser cumprida. Por estes motivos, o BackTrack tornou-se uma das
principais distribuições de segurança atualmente.
23 www.remote-exploit.org/backtrack.html
113
5.4.2 Nikto24 Web Server Scanner
O primeiro teste no Cenário 1 consiste em listar as vulnerabilidades de um servidor Web
Apache 2 usando o Web Server Scanner Nikto.
Nikto é um web server scanner Open Source (GPL), escrito em perl, que realiza diversos
tipos de testes em servidores Web, incluindo em arquivos CGIs potencialmente perigosos,
auxiliando na identificação de problemas específicos em mais de 250 tipos de servidores.
A utilização é via linha de comandos, porém é poderosa, podendo gerar relatórios nos
formatos txt, html e csv através de varredura em servidores Web de forma simples e rápida.
Nem todos os resultados apresentados pelo Nikto, entretanto, estão relacionados a falhas de
segurança. Frequentemente, também são apresentados dados de caráter informativos, podendo
ser úteis e cuja existência geralmente é ignorada por webmasters ou engenheiros de segurança.
A tabela 5.2 a seguir exibe um resumo dos principais parâmetros do Nikto.
Exemplo Comando
Atualização os plug-ins Ex: #nikto.pl -update
Usando o Nikto Ex: #nikto.pl -host 192.168.10.10 -C all -o relatorio.txt; onde:- C all : força a checagem de todos os diretórios em busca de arquivos cgi;-host : endereço IP da vitima -o : Gera um arquivo de relatório
Tabela 5.2. Resumo de funções e exemplos de uso do Nikto
A ferramenta Nikto, por padrão, pode ser encontrada na distribuição Backtrack 3.0, cuja
invocação no menu “Backtrack”, aciona a “janela Shell” que dá o acesso a este script e suas
respectivas opções de execução.
A listagem a seguir demonstra a utilização do Nitko a partir da máquina do atacante
(Backtrack) e a identificação do Servidor Web Apache 2.2.9, instalado na máquina alvo
Windows 2003 Server.
24 www.cirt.net/nikto2
114
# nikto.pl -C all -h 192.168.10.10- Nikto v1.36/1.37------------------------------------------------------------------------+ Target IP: 192.168.10.10+ Target Hostname: 192.168.10.10+ Target Port: 80+ Start Time: Wed Jun 18 13:29:46 2008------------------------------------------------------------------------- Scan is dependent on "Server" string which can be faked, use -g to override+ Server: Apache/2.2.9 (Win32)+ Allowed HTTP Methods: GET,HEAD,POST,OPTIONS,TRACE + 14472 items checked - 0 item(s) found on remote host(s)+ End Time: Wed Jun 18 13:30:31 2008 (45 seconds)------------------------------------------------------------------------+ 1 host(s) tested
As estatísticas de alertas do Snort, armazenados na base MySQL do host Sensor, foram acessadas
via interface Web na URL “http://10.13.1.136/base”. Baseado no tráfego gerado pelo atacante, o
frontend BASE gerou os alertas (figura 5.6) e a classificação para o tipo de intrusão (figura 5.7).
Figura 5.6. Alertas de detecção de intrusão do Snort para o Web Scanner Nikto
Figura 5.7. Classificação do ataque para o Web Scanner Nikto
115
Figura 5.8. Estatísticas de detecção de intrusão do Snort para o Web Scanner Nikto
A tabela 5.3 apresenta a síntese descritiva para o teste do Cenário 1 usando o Nikto.
Síntese do teste
Numero do Teste: 1 Tipo de ataque: Web Scanning Tempo: 45 segundos
Metodologia
Descrição Utilização da ferramenta nikto web scanning contra o host alvo, objetivando testar a sensibilidade de detecção de assinaturas do Snort
Ferramentas/comandos Nikto: #nikto.pl -C all -h 192.168.10.10
Passos _ Zerar a contagem de alertas na interface (BASE);_ iniciar o nikto, iniciar o tcpdump para contagem de pacotes;_ Anotar os resultados e capturar as telas do BASE;_ Produzir os relatórios;
Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2Windows 2003 Server (alvo) - 192.168.10.10Backtrack 3 (atacante) - 192.168.10.66
Resultados obtidos
Número de alertas gerados: 817 Alertas únicos: 86
Número de pacotes TCP UDP
3735 0
Conclusão O Snort conseguiu identificar e alertar corretamente sobre o scanning gerado pelo Nikto.
Tabela 5.3. Síntese da simulação e resultados obtidos na detecção (teste 1).
A figura 5.8 exibe estatísticas de tráfego, demonstrando que o Nikto produz
essencialmente tráfego TCP, uma vez que simula o acesso de um cliente ao servidor Web em
busca de arquivos que indiquem algum tipo de vulnerabilidade. Os resultados demonstraram
que o Snort detectar corretamente scanning do Nikto e gerar os alertas apropriados,
identificando o scanning através das assinaturas “web-application-activity” e ““web-
application-attack”.
116
5.4.2.1 Teste de evasão usando o Nikto
O Nikto não foi concebido como uma ferramenta essencialmente furtiva, ou seja, capaz de
realizar técnicas de evasão por padrão, no entanto, ele oferece suporte a bibliotecas de outro
popular Web Scanner, o Whisker25, implementando métodos evasivos, ou anti-IDS. Por isso,
além de ser um excelente recurso para administradores que querem checar a segurança de
servidores Web e scripts CGI, o Nikto também pode ser usado por atacantes para obter
informações úteis a um possível ataque, sem gerar alertas em sistemas de detecção de
intrusão.
A tabela 5.4 apresenta as opções de evasão encontrados no Nikto.
Opção Descrição1 Random URI encoding (non-UTF8)2 Add directory self-reference /./3 Premature URL ending4 Prepend long random string to request5 Fake parameters to files6 TAB as request spacer instead of spaces7 Random case sensitivity8 Use Windows directory separator \ instead of /9 Session splicing
Observações: Opções devem ser usadas com o parâmetro -e. Ex: nikto.pl -C all -host 200.128.X.X -e 9
Tabela 5.4. Opções de evasão de IDS do Nikto
As técnicas de evasão usadas pelo Nikto são uma forma de automatizar a geração de tráfego
anômalo. Independente da ação executada o objetivo dste tipo de ataque é dificultar a detecção,
fazendo com que, no processo de análise do conteúdo de um pacote, o IDS perca informações
vitais para identificação do ataque. Aplicações no host alvo, por sua vez, recebem as
informações de forma integral, contidas nos pacotes enviados e, portanto, serão vítimas do
ataque.
Muitos sistemas têm problemas em detectar e manusear pacotes fragmentados ou perdem
performance na utilização de módulos para remontagem de seção. As ferramentas de ataque
exploram estas deficiências para contornar o perímetro de segurança imposto por ferramentas
NIDS.
25 http://www.securityfocus.com/tools/727
117
Para o teste de evasão foi usado o mesmo Cenário do teste anterior (para o web scanner
Nikto), entretanto, usando a opção de evasão (-e) e o parâmetro “-9” (session Splicing).
O ataque usando Session Splicing consiste no envio de diversos pacotes. Por exemplo, a
solicitação “Get /cgi-bin/phf.cgi HTTP/1.0” pode ser dividida em múltiplos pacotes “Ge”, “t”, “/”,
“cgi”, “-bin”, “p”, “hf.c”, “gi”, “H”, “T”, “TP”, “/1”, “.0”. Sendo assim o processo de detecção é ainda
mais difícil para alguns NIDS. Como este parâmetro quebra os pacotes de consulta em
pedaços muitos pequenos, o resultado é que o scanning torna-se bastante lento e gera mais
alertas que o método tradicional.
O Nikto gerou o seguinte relatório para evasão Session Splicing.
»---------------------------------------------------------------------------- Nikto 1.36/1.37 - www.cirt.net+ Target IP: 192.168.10.10+ Target Hostname: 192.168.10.10+ Target Port: 80+ Using IDS Evasion: Random URI encoding (non-UTF8)+ Start Time: Tue Jun 10 10:10:21 2008---------------------------------------------------------------------------- Scan is dependent on "Server" string which can be faked, use -g to override+ Server ID string not sent- Server did not understand HTTP 1.1, switching to HTTP 1.0+ Server does not respond with '404' for error messages (uses '400').+ This may increase false-positives.+ /mo%64%75le%73.ph%70?n%61m%65=%4de%6d%62%65%72%73%5f%4c%69%73%74%26l%65tte%72=Al%6c&%73or%74%62%79=p%61%73%73 - PHP Nuke module allows user names and passwords to be viewed. See http://www.frog-man.org/tutos/PHP-Nuke6.0-Members_List-Your_Account.txt for other SQL exploits in this module. (GET)+ 16261 items checked - 1 item(s) found on remote host(s)+ End Time: Tue Jun 10 10:11:22 2008 (61 seconds)---------------------------------------------------------------------------+ 1 host(s) tested
As figuras a seguir, capturadas do BASE, ilustram os resultados obtidos para o teste de
evasão.
Figura 5.9. Estatísticas de detecção de intrusão para o Web Scanner Nikto usando evasão.
118
Figura 5.10. Alertas gerados para o Web Scanner Nikto usando evasão.
O resultado do teste de evasão usando o nikto não foi satisfatório. Pois, além do Nikto não
conseguir identificar o tipo de servidor Web, foram gerados muitos falsos positivos, e alertas
não relacionados ao ataque propriamente dito.
É importante destacar que usando o conjunto de regras “Unregistered”, o Snort não
conseguiu detectar o scanning do nikto usando a evasão session splicing.
5.4.3 Nmap26 Security scanner
Nmap é um software livre que efetua um port scan e permite ao administrador ou
possíveis invasores vasculhar uma rede verificando quais servidores estão ativos e quais
serviços eles estão oferecendo.
Desenvolvido pelo auto-proclamado hacker Fyodor, o nmap é muito conhecido pela sua
rapidez e pelas opções que dispõe. O nmap é um programa CUI (Console User Interface),
26 http://nmap.org/
119
pois é usando via linha de comandos, mas também existe uma interface gráfica (GUI), o
NmapFE27 (Nmap Front End), que torna a sua utilização mais simples.
O nmap oferece muitos parâmetros úteis para descoberta de rede e diversas tecnologias
de scanner, como por exemplo, UDP, TCP connect, TCP SYN, ICMP entre outras.
Para o teste do nmap, foi necessário habilitar os pré-processadores sfPortscan e frags3,
no arquivo de configuração do Snort (/etc/snort/snort.conf), como descrito a seguir:
a) Habilitar o sfPortscan e alterar a diretiva “sense_level” para "high":
b) Ajustar a configuração do preprocessador frags3 para policy linux:
Antes do ajuste citado acima, usando a configuração padrão, o Snort não estava
conseguindo gerar alertas para o port scanning do nmap.
O nmap foi usado para descobrir as portas e os respectivos serviços disponíveis do host
192.168.10.10 (alvo). A lista a seguir exibe o resultado desta ação.
bt~# nmap -sV 192.168.10.10
Starting Nmap 4.20 ( http://insecure.org ) at 2008-06-19 12:21 GMTInteresting ports on 192.168.10.10:Not shown: 1691 closed portsPORT STATE SERVICE VERSION80/tcp open http Apache httpd 2.2.9 ((Win32))135/tcp open msrpc Microsoft Windows RPC139/tcp open netbios-ssn445/tcp open microsoft-ds Microsoft Windows 2003 microsoft-ds1025/tcp open msrpc Microsoft Windows RPC1026/tcp open msrpc Microsoft Windows RPCMAC Address: 00:0C:29:87:D3:0A (VMware)Service Info: OS: WindowsSe r v i c e d e t e c t i o n p e r f o r m e d . P l e a s e r e p o r t a n y i n c o r r e c t r e s u l t s a t h t t p : / / i n s e $Nmap finished: 1 IP address (1 host up) scanned in 59.855 seconds
A opção “-sV” (version detection) é usada para determinar qual a versão dps serviços
estão rodando. As Figuras 5.11, 5.12 e 5.13, exibem os alertas, estatísticas e classificação,
respectivamente, capturadas no frontend BASE para o teste usando o nmap.
27 http://nmap.org/SoC/NmapFE.html
120
# Disabled by defaultpreprocessor sfportscan: proto { all } \ memcap { 10000000 } \ sense_level { high }
preprocessor frag3_global: max_frags 65536preprocessor frag3_engine: policy linux timeout 180 \ bind_to [192.168.10.0/24] \ detect_anomalies
Figura 5.11. Alertas de port scanning para o teste do nmap.
Figura 5.12. Estatísticas de intrusão para o nmap
Figura 5.13. Classificação da assinatura de intrusão para o nmap
A tabela 5.5 apresenta a síntese descritiva para o teste usando o Nmap.
Síntese do testeNumero do Teste: 3 Tipo de ataque:port scanning Tempo:59 segundos
MetodologiaDescrição utilização da ferramenta nmap objetivando testar a sensibilidade de
detecção de assinaturas do SnortFerramentas/comandos nmap -sV 192.168.10.10 (version detection)Passos _ Zerar a contagem de alertas na interface (BASE)
_ iniciar o retina, iniciar o tcpdump para contagem de pacotes._ iniciar o port scanning nmap_ Anotar os resultados e capturar as telas do BASE;
Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2Windows 2003 Server (alvo) - 192.168.10.10Backtrack 3 (atacante) - 192.168.10.66
Resultados obtidosNúmero de alertas gerados: 7 Alertas únicos: 2Número de pacotes TCP UDP
1194 0Conclusão O Snort conseguiu detectar com êxito o ataque gerado pelo nmap.
Tabela 5.5.Síntese da simulação e resultados obtidos na detecção (teste 3).
121
5.4.3.1 Teste de evasão usando o Nmap
Conforme observado no teste 3, o port scanning do nmap pode ser facilmente detectado caso a
rede possua um NIDS como o Snort, ou outro detector de intrusões ativo. Para tentar contornar, o
Nmap oferece a opção de fazer um half-open scan, especificando a opção “-sS”. Operando neste
modo, o Nmap apenas envia um pacote SYN para cada porta alvo e espera receber um pacote ACK
de confirmação sem, entretanto, responder com o segundo pacote ACK, que abriria a conexão. Esta
técnica é conhecida por TCP SYN Stealth. Isso permite burlar muitos programas de detecção de
intrusão, que monitoram e registram apenas conexões efetivamente estabelecidas. A lista a seguir
exibe o resultado usando a parâmetro TCP SYN Stealth.
bt~# nmap -sS 192.168.10.10
Starting Nmap 4.20 ( http://insecure.org ) at 2008-06-19 13:27 GMTInteresting ports on 192.168.10.10:Not shown: 1691 closed portsPORT STATE SERVICE80/tcp open http135/tcp open msrpc139/tcp open netbios-ssn445/tcp open microsoft-ds1025/tcp open NFS-or-IIS1026/tcp open LSA-or-ntermMAC Address: 00:0C:29:87:D3:0A (VMware)Nmap finished: 1 IP address (1 host up) scanned in 14.626 seconds
As Figuras 5.14, 5.15 e 5.16, exibem, respectivamente, os alertas, classificação e estatísticas,
capturadas no frontend BASE para o teste usando o nmap no modo TCP SYN Stealth.
Figura 5.14. Alertas identificando o port scanning com a opção TCP SYN Stealth ativa.
Figura 5.15. Classificação das assinaturas para o nmap em modo Stealth.
122
Figura 5.16. Estatísticas de alertas para o nmap em modo Stealth.
A tabela 5.6 apresenta a síntese dos resultados para o teste 4
Síntese do testeNumero do Teste: 4 Tempo: 59 segundos Tipo de ataque:Scanning Stealth
MetodologiaDescrição utilização da ferramenta nmap em modo Stealth objetivando testar a
sensibilidade de detecção de assinaturas do SnortFerramentas/comandos nmap -sS 192.168.10.10Passos _ Zerar a contagem de alertas na interface (BASE)
_ iniciar nmap em modo stealth, iniciar o tcpdump para contagem de pacotes._ Anotar os resultados e capturar as telas do BASE;
Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2Windows 2003 Server (alvo) - 192.168.10.10Backtrack 3 (atacante) - 192.168.10.66
Resultados obtidosNúmero de alertas gerados 7 Alertas únicos: 2Número de pacotes TCP UDP
171 0Conclusão O Snort conseguiu identificar corretamente o scanning gerado pelo
nmap em modo stealth.
Tabela 5.6. Síntese da simulação e resultados obtidos na detecção (teste 4).
Apesar de várias referências indicarem o TCP SYN Stealth do nmap como uma forma de
contornar o perímetro de segurança imposto por firewalls e IDS; para este tipo de evasão, o
Snort conseguiu gerar alertas adequadamente nas simulações realizadas, como apresentado
nos resultados anteriores (ver Tabela 5.6).
Além da opção “-sS” (TCP SYN Stealth), o nmap possui parâmetros específicos para
alterar o formato dos pacotes para tentar enganar firewalls e detectores de intrusão. As opções
apresentadas na Tabela 5.7 a seguir, descrevem os parâmetros usados para implementar este
tipo de ataque.
123
Opção Descrição
-f; --mtu <valor> Fragmentar pacotes (opcional com dado MTU)
D <decoy1,decoy2[,ME],...> Disfarça um rastreio(scan) usando iscas
-S <IP_Address> Disfarçar(Spoof) endereço de origem
-e <iface> Usar um interface especifico
-g/ --source-port <portnum> Usar um determinado numero de porta
--ttl <val> Ajustar o campo IP TTL tempo-de-vida
--spoof-mac <mac address, prefix, or vendor name> Disfarçar(Spoof) o endereço MAC
--data-length <número> Acrescenta dados aleatórios nos pacotes .
Tabela 5.7. Opções de evasão do nmap
O segundo teste de evasão usando nmap foi executado usando a opção de evasão
“--data-length”28. Normalmente o Nmap envia pacotes minimalistas contendo apenas o
cabeçalho. Dessa forma os pacotes TCP têm normalmente 40 bytes e os echo requests ICMP
tem apenas 28. A opção “--data-length” faz com que o Nmap acrescente o número informado
de bytes aleatórios na maioria dos pacotes que envia. Este método também pode causar
lentidão ocasional, mas pode tornar um rastreio(scan) ligeiramente menos chamativo. A lista a
seguir apresenta o resultado deste comando.
bt~# nmap --data-length 150 192.168.10.10
Starting Nmap 4.20 ( http://insecure.org ) at 2008-06-19 14:54 GMTInteresting ports on 192.168.10.10:Not shown: 1691 closed portsPORT STATE SERVICE80/tcp open http135/tcp open msrpc139/tcp open netbios-ssn445/tcp open microsoft-ds1025/tcp open NFS-or-IIS1026/tcp open LSA-or-ntermMAC Address: 00:0C:29:87:D3:0A (VMware)
Nmap finished: 1 IP address (1 host up) scanned in 13.616 seconds
Neste teste, constatou-se que os bytes adicionados (150) pelo parâmetro “--data-length”,
disfarçam a real natureza do pacote, confundindo a detecção do Snort, pois as assinaturas
disponíveis não “combinam” com o tráfego coletado. O resultado é a geração de diversos
falsos positivos, como observado nas figuras 5.17 e 5.18 a seguir:
28 http://nmap.org/man/pt-br/man-bypass-firewalls-ids.html
124
Figura 5.17. Estatísticas de alertas para o nmap usando o parâmetro “--data-length”
Figura 5.18. Alertas para o nmap usando o parâmetro “--data-length”
A tabela 5.8 apresenta a síntese dos resultados para o teste 5
Síntese do testeNumero do Teste: 5 Tipo de ataque: evasão Tempo: 59 segundos
MetodologiaDescrição Testar as assinaturas do Snort com técnicas de evasãoFerramentas nmap –data-legth 150 192.168.10.10Passos _ Zerar a contagem de alertas na interface (BASE);
_ iniciar o nmap, iniciar o tcpdump para contagem de pacotes;_ Anotar os resultados e capturar as telas do BASE.
Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2Windows 2003 Server (alvo) - 192.168.10.10Backtrack 3 (atacante) - 192.168.10.66
Resultados obtidosNúmero de alertas gerados: 7 (falso positivos) Alertas únicos: 4Número de pacotes TCP UDP
310 0Conclusão O Snort não conseguiu detectar o scanning do nmap usando evasão.
Tabela 5.8. Síntese da simulação e resultados obtidos na detecção (teste 5).
Apesar do Snort ter gerado inúmeros alertas, os resultados da Tabela 5.8 demonstram que
o parâmetro –data-lenght pode ser usado como técnica de evasão. Pois, neste caso, o Snort
não conseguiu classificar corretamente o tipo de tráfego, confundindo os pacotes com tráfego
encriptado ou pacotes RPC incompletos.
125
5.5 Cenário 2 - Retina, Nessus e Metasploit Framework
A figura 5.19 a seguir ilustra o segundo cenário de testes utilizando o NIDS Snort para
simulação dos Scanners de vulnerabilidades Retina e Nessus e do Framework MetaSploit.
Nele são representadas as máquinas virtuais usadas na simulação, bem como seus respectivos
Sistemas Operacionais e endereços IP.
Figura 5.19. Cenário 2 para simulações das ferramentas Retina, Nessus e Metasploit.
A tabela 5.9 a seguir apresenta um resumo descritivo da figura anterior, com os
respectivos recursos alocados para cada máquina virtual no sistema hospedeiro.
Host Descrição S.O Memória HD(GB) IP Interface de rede 1 Alvo Windows 2003 Server 192 MB 1.7 192.168.10.10 Host only2 Atacante Windows XP Professional 204 MB 2.5 192.168.10.64 Host only3 Servidor Snort Ubuntu Linux 8.04 232 MB 9 192.168.10.2 Host-only
10.13.1.136 Bridge4 Monitoramento Windows XP(Sistema anfitrião) 2 GB 80GB 10.13.1.133 -----
Tabela 5.9 Hosts usados na simulação do Cenário 2
A figura 5.20 a seguir apresenta o diagrama de blocos que ilustra a disposição máquinas
virtuais em relação ao Vmware Workstation e pelo sistema anfitrião (Windows XP).
Figura 5.20. Máquinas virtuais e sistema anfitrião do cenário 2.
126
5.5.1 Retina29 Network Security Scanner
O software Retina Network Security Scanner, desenvolvido pela eEye Digital Security, é
um netork scanner utilizado para identificar vulnerabilidades de segurança em redes
corporativas.
Além de sua grande precisão, arquitetura aberta e capacidades de varredura não
intrusivas, Retina 5.0 oferece características únicas que o diferenciam de outros softwares de
análise de vulnerabilidades: capacidade ilimitada de localização de equipamentos, relatórios
completos, detecção precisa de sistemas operacionais e nova interface de usuários que
oferecem um nível de precisão de varreduras completo e melhoria na produtividade e
velocidade da ferramenta para funções de gerência de vulnerabilidades. No presente trabalho
foi utilizado o Retina 5.85 (versão evaluation). A lista a seguir, destaca algumas informações
possíveis de se obter com a execução do Retina em um ambiente de rede:
Exibe informações gerais como IP, nome e domínio, tempo de resposta;
Informa quantidade de portas abertas e para cada porta o serviço que está associado a
ela, podendo varrer todas as portas ou pesquisar portas específicas;
Exibe informações detalhadas sobre os serviços oferecidos e a listagem de
vulnerabilidades encontradas, classificando-as conforme o nível de seu risco (Alto,
Médio, Baixo). Esta opção, destaca-se por fornecer uma breve descrição da
vulnerabilidade e sugestões para remedia-la;
Lista e exibe informações detalhadas sobre os serviços oferecidos pelo host e suas
respectivas vulnerabilidades;
Lista os compartilhamentos e informações sobre os mesmos;
Consolida todos os dados de auditoria em um relatório de segurança executivo.
A figura a seguir apresenta a tela de auditoria do Retina.
29 www.eeye.com/html/products/retina/index.html
127
Figura 5.21. Tela principal do software Retina.
O teste com o Scanner Retina consistiu inicialmente na instalação deste software no host
atacante (Windos XP – 192.168.10.64). Posteriormente, o processo de scanning contra o host
alvo (Windows 2003 – 192.168.10.10) foi iniciado usando o modo “All Ports”. Baseado no
tráfego do atacante, no host sensor (Ubuntu 8.04 / Snort / 192.168.10.2) gerou os seguintes
alertas de intrusão para atividade portscan.
As Figuras 5.22 e 5.23, Estatísticas e Alertas respectivamente; e a tabela 5.10, a seguir,
apresentam os resultados obtidos desta análise.
Figura 5.22. Estatísticas de alertas exibidas pelo frontend BASE no teste de intrusão usando o Retina.
128
Figura 5.23. Alertas produzidos pelo Snort após a utilização do Retina contra a máquina alvo.
SÍNTESE DO TESTENumero do Teste: 6 Tipo de ataque: Scanner Tempo: 2 min 1 seg.
MetodologiaDescrição utilização do software Retina, scanner de vulnerabilidades, para aferir
a capacidade do Snort para identificação de PortScanning Ferramentas Retina Network Scanner (modo All ports)Passos _ Zerar a contagem de alertas na interface (BASE);
_ Iniciar o retina; iniciar o tcpdump para contagem de pacotes;_ Anotar os resultados e capturar as telas do BASE.
Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2Windows 2003 Server (alvo) - 192.168.10.10Windows XP (atacante) - 192.168.10.64
Resultados obtidosNúmero de alertas gerados: 17 Alertas únicos: 3Número de pacotes TCP UDP
5233 861Conclusão O Snort conseguiu identificar e classificar corretamente portscan
gerado pelo Retina.
Tabela 5.10. Síntese da simulação e resultados obtidos na detecção (teste 6).
5.5.2 Network Scanner Nessus30
Assim como o Retina, Nessus é um scanner que identifica hosts, portas, serviços e suas
versões, bem como as falhas conhecidas para estes serviços, apontando possíveis correções. O
Nessus é rápido, confiável, possui arquitetura modular e baseada no paradigma
cliente/servidor. O servidor atualmente pode ser executado em ambientes Linux, FreeBSD,
NetBSD e Solaris e clientes estão disponíveis para Linux, Windows e plataformas JAVA.
30 http://www.nessus.org/
129
Após a instalação do Nessus, é necessário realizar a atualização dos plug-ins para
detecção de vulnerabilidades. Esta tarefa pode ser feita através da opção “Update Plugins”.
Para tanto, existe dois processos de registro:
Direct: suporte comercial, com atualizações diárias de plug-ins (U$1,200.00/ano);
Registered: gratuito, no entanto, só oferece atualização semanal aos plug-ins.
A figura 5.24 a seguir exibe a tela do software Nessus.
Figura 5.24. Scanner Nessus
Semelhante ao teste teste com o Scanner Retina, a preparação do ambiente iniciou com a
instalação do Nessus no host atacante (Windows XP – 192.168.10.64) e posteriormente a
atualização dos plug-ins. Foi usado o modo “all plugins/Default settings” para testar a
eficiência das assinaturas do Snort para detecção do portscanning gerado pelo Nessus.
As figuras 5.25 e 5.26 a seguir apresentam os dados obtidos da interface Web BASE para
os alertas registrados no teste do Nessus, assim como a tabela 5.11 um resumo descritivo do
teste.
130
Figura 5.25. Estatísticas de alertas exibidas pelo frontend BASE no teste do Nessus
Figura 5.26. Alertas de detecção para o port scanner Nessus
SÍNTESE DO TESTENumero do Teste: 7 Tipo de ataque: network scanning Tempo:4 minutos e 45 segundos
MetodologiaDescrição Utilização do Nessus para scanning do host, objetivando testar a
eficiência de detecção de assinaturas do SnortFerramentas/comandos Nessus (All plugins / default settings)Passos _ Zerar a contagem de alertas na interface (BASE)
_ Iniciar o Nessus; iniciar o tcpdump para contagem de pacotes.Maquinas Virtuais Ubuntu 8.04 (sensor snort) - 192.168.10.2
Windows 2003 Server (alvo) - 192.168.10.10Windows XP (atacante) - 192.168.10.64
Resultados obtidosNúmero de alertas gerados: 736 Alertas únicos: 143Número de pacotes TCP UDP
18666 117Conclusão O Snort conseguiu identificar o scanning gerado pelo Nessus.
Tabela 5.11 Descrição do teste e resultados para o tráfego gerado pelo Nessus
131
5.5.3 Explotation atack com o Metasploit Framework31
O Metasploit Framework, ou MSF, é uma ferramenta open source, objetiva a criação de
um ambiente de desenvolvimento, teste e exploração de vulnerabilidades de software,
fornecendo aos pesquisadores da área de segurança as ferramentas necessárias e um completo
ambiente de trabalho.
O MSF foi desenvolvido para prover testes de penetração (PenTest) e análise de
vulnerabilidades em redes de computadores. Criado por H.D.Moore, o MFS é um conjunto
das melhores plataformas de aprendizagem e investigação para o profissional de segurança ou
do “hacker ético”. Ele possui centenas de exploits, payloads e ferramentas avançadas que
permitem testar vulnerabilidades em muitos sistemas operacionais, serviços e aplicativos.
A figura 5.27 exibe a tela principal do MSF. Além de disponibilizar um ambiente de
janelas, o MSF também possui a execução de comandos via console e interface Web.
Figura 5.27. Metasploit Framework
31 www.metasploit.com/
132
O Metasploit possui várias ferramentas dentre elas:
msfconsole - metasploit em modo console;
msfcli - interface de automatização de penetração e exploração;
msflogdump - exibe sessões de arquivos de log;
msfplayload - usado para gerar payloads customizados;
msfpescan - utilizado para analisar e de-compilar executáveis e DLLs;
msfencode - um codificador interativo de payload encoder;
msfupdate - utilizado para verificar e fazer download de atualização do framework;
msfweb - Interface gráfica via browser
O ciclo completo da pesquisa suportada pelo MSF compreende as seguintes etapas:
a) Descoberta da Vulnerabilidade: o pesquisador descobre um erro de
programação que pode levar ou não a uma brecha de segurança;
b) Analise: o pesquisador analisa a vulnerabilidade para determinar quais as
maneiras pela qual a mesma pode ser explorada. Perguntas-chave são feitas
nessa fase do desenvolvimento, como por exemplo: De qual maneira a
vulnerabilidade pode ser explorada? Localmente ou remotamente?
c) Desenvolvimento de exploit: após a fase de analise, começa o desenvolvimento
da exploração em si, como prova da existência real da vulnerabilidade. Técnicas
de engenharia reversa, programação, debugger, etc; são usadas nessa fase;
d) Teste do exploit: nessa fase o exploit é testado em diferentes ambientes e
variáveis, service packs, patchs, etc. O exploit em si é a prova definitiva que a
vulnerabilidade pode ser explorada.
As seções seguintes abordam a utilização do MSF para exploração de duas vulnerabilidades
bastante conhecidas, ms06-001 e ms03-026. O objetivo é: descrever sucintamente estas
vulnerabilidades; como podem ser exploradas e, finalmente, demonstrar como o NIDS Snort pode
auxiliar a detecção e alertar sobre ataques de obtenção de acesso; bem como na coleta de
indicadores para elaboração de metodologias e análises de testes de penetração.
133
5.5.3.1 Vulnerabilidade ms06-001 wmf SetAbortProc
O primeiro teste com o MSF consistiu em explorar a vulnerabilidade na biblioteca GDI
MS06-001 (Vulnerability in Graphics Rendering Engine Could Allow Remote Code
Execution)32, que trata de um problema na renderização de gráficos no formato WMF que
pode permitir a execução remota de código arbitrário em máquinas vulneráveis
Esta vulnerabilidade utiliza a função “metafile Escape( )” para executar código arbitrário
através do procedimento SetAbortProc, afetando o visualizador de imagens e de fax do
Windows; que ao abrir o arquivo, dá acesso à referida execução de código arbitrário.
Sistemas afetados:
Microsoft Windows 2000 Service Pack 4;
Microsoft Windows XP Service Pack 1;
Microsoft Windows XP Service Pack 2;
Microsoft Windows XP Professional x64 Edition;
Microsoft Windows Server 2003;
Microsoft Windows Server 2003 Service Pack 1;
Microsoft Windows Server 2003 for Itanium-based Systems;
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems;
Microsoft Windows Server 2003 x64 Edition
Foi utilizado o MSF instalado na máquina atacante Windows XP (192.168.10.64).Os
passos necessários para execução deste ataque são descritos a seguir e ilustrados na figura 5.28:
a) O ataque inicia com a chamada ao exploit “Windows XP/2003/Vista Metafile
Escape() SetAbortProc Code Execution”. Quando lançado, este exploit fica à
espera de conexões no computador do atacante, porta 8080. Para tanto, o
atacante cria um e-mail falso (spam ou phishing) cujo conteúdo informa a URL
para a vítima, por exemplo “http://ip_do_atacante:8080/imagem.wmf”. Ver
Figura 5.28 (a);
32 http://www.rnp.br/cais/alertas/2006/MS06-001.html
134
b) Quanto o usuário recebe o e-mail e clica na URL, o Browser no computador da
vítima é acionado alguns segundos após o download da imagem. O
“Visualizador de imagens e fax do Windows” então é aberto, tentando carregar o
arquivo “imagem.wmf” aparentemente inofensivo. Ver Figura 5.28 (b);
c) Neste momento, o “Visualizador de imagens e fax do Windows” fica bloqueado,
não apresentando qualquer imagem. No entanto, a partir deste ponto do ataque, a
máquina da vítima inicia uma conexão com host do atacante (através de um
Reverse Handler). No MSF,. ao clicar em “session 1”, é estabelecida a sessão e o
atacante ganha um Shell remoto para a máquina alvo (Figura 5.28 (c)). Com este
acesso remoto à linha de comandos da máquina Windows, ele pode executar
comandos diversos, sem restrições, uma vez que possui permissões de
Administrador.
Figura 5.28. Exploração da vulnerabilidade Windows Metafile Escape() SetAbortProc Code Execution
135
As figuras a seguir exibem algumas telas do MSF capturadas durante a execução dos
passos descritos anteriormente.
Na figura 5.30 é escolhido um shell para o payload (Generic Command Shell, Bind TCP
Inline).
Figura 5.30. Seleção do payload para a vulnerabilidade ms06-001.
A figura 5.31 a seguir ilustra a etapa de configuração das opções do exploit, na qual são
informados os campos SRVPORT (porta do servidor que receberá conexões) e URIPATH
(define o caminho após o endereço do host e porta do servidor do atacante, ex:
http://192.168.10.64:8080/imagem.wmf).
Figura 5.31. Escolha das opções gerais do exploit .
136
Ultima tela da criação do exploit é mostrada a seguir, exibe as opções escolhidas para
configuração do ataque no MSF. O botão “Aplicar” conclui a configuração e lança o exploit,
que fica aguardando conexões na porta 8080.
Figura 5.32. Conclusão da configuração do exploit.
Os testes para detecção da exploração da vulnerabilidade ms06-001 foram executados
conforme descrito nesta seção. Os resultados de captura de tráfego e detecção do ataque são
expostos a seguir.
Figura 5.33. Alertas gerados para a exploração da vulnerabilidade ms06-001 wmf SetAbortProc
Figura 5.34. Estatísticas geradas para a exploração da vulnerabilidade ms06-001wmf SetAbortProc
137
A tabela 5.12 a seguir apresenta a síntese do teste usando o MSF (ms06-001).
Síntese do testeNumero do Teste: 8 Tipo de ataque: Obtenção de acesso
MetodologiaDescrição utilização da ferramenta MSF para explorar a vulnerabilidade
ms06-001Ferramentas MSF - exploit Windows XP/2003/Vista Metafile Escape()
SetAbortProc Code ExecutionPassos _ Zerar a contagem de alertas na interface (BASE)
_ configurar o exploit no MSF para aceitar conexões da porta 8080_ Anotar os resultados e capturar as telas do BASE.
Tempo 4 minutos e 25 segundosMaquinas Virtuais Ubuntu 8.04 (sensor Snort) - 192.168.10.2
Windows 2003 Server (alvo) - 192.168.10.10Windows XP (atacante) - 192.168.10.64
Resultados obtidosNúmero de alertas gerados 3Alertas únicos 2Número de pacotes TCP UDP
Conclusão Apesar de apresentar poucos alertas, o Snort produziu indicadores suficientes para identificar o tipo de ataque (wmf metafile access) e a obtenção do acesso remoto (Attack-Responses Directory listing ).
Tabela 5.12 Resultados para a execução do exploit ms06-001 wmf SetAbortProc via MSF
O número baixo de alertas gerados deve-se ao fato do Snort não possuir assinaturas
diretamente relacionadas a este tipo exploração. Os alertas indicados foram para “Web-Client
Microsoft wmf metafile access”, quando a vítima acionou acessou a URL; e para “Attack-
Responses Directory listing”, quando houve uma resposta do Command Shell na máquina
alvo para uma solicitação de listagem do diretório por parte do atacante.
5.5.3.2 Vulnerabilidade ms03-026 Buffer Overrun In RPC Interface33
O segundo teste usando o MSF objetivou aferir as assinaturas do Snort para a
vulnerabilidade MS03-026 (Buffer Overrun In RPC Interface Could Allow Code Execution).
Esta vulnerabilidade foi descoberta em julho de 2003, e afeta uma interface DCOM
(Distributed Component Object Model).na implementação do RPC (Remote Procedure Call)
da Microsoft.
33 http://www.rnp.br/cais/alertas/2003/MS03-026.html
138
Ao explorar essa vulnerabilidade um invasor pode executar um código arbitrário com
privilégios do Sistema local em um sistema afetado. Assim, um invasor pode efetuar qualquer
operação no sistema, inclusive instalar programas, visualizar, alterar ou excluir dados ou até
mesmo criar novas contas com privilégios totais. Para tanto, o invasor deverá enviar uma
solicitação feita especialmente às portas 135, 139, 445 ou a qualquer outra porta RPC
configurada especificamente no computador remoto.
Sistemas Afetados:
Microsoft Windows NT® 4.0
Microsoft Windows NT 4.0 Terminal Services Edition
Microsoft Windows 2000
Microsoft Windows XP
Microsoft Windows Server 2003
A RPC (Chamada de Procedimento Remoto) é um protocolo usado pelo sistema
operacional do Windows. A RPC fornece um mecanismo de comunicação entre processos que
permite que um programa funcione em um computador e execute, um código em um
computador remoto. A vulnerabilidade é inerente à parte do RPC que lida com troca de
mensagens pelo TCP/IP. A falha ocorre devido à manipulação incorreta de mensagens
corrompidas. A correção consiste na aplicação dos patches de segurança recomendados pela
Microsoft.
No teste 2, o relatório do feito pelo scanner Nessus sobre host alvo, indicou esta
vulnerabilidade, conforme observado na figura 5.35 a seguir.
139
Figura 5.35. Relatório do scanner Nessus indicando a vulnerabilidade ms03-026.
As figuras a seguir exibem um resumo dos passos utilizados para configurar o MSF para
explorar esta vulnerabilidade e testar as assinaturas do Snort para detecção deste tipo de
ataque.
Figura 5.36. Seleção do exploit no MSF para a vulnerabilidade ms03-026
140
Figura 5.37. Seleção do payload para a vulnerabilidade ms03-026
A seleção do payload na figura anterior, indica a escolha do “Meterpreter reverse TCP”,
que utiliza a técnica “Inject server DLL”. Neste método, o exploit realiza o upload de um
DLL (metsrv.dll) para o computador vulnerável, através da porta TCP 135.
A figura a seguir exibe o Shell remoto aberto pelo atacante obtido após lançar o exploit.
Figura 5.38. Bind Shell para acesso remoto ao computador da vítima.
O bind Shell foi usado para criar uma pasta chamada “exploit” no computador alvo. Na
figura a seguir, a confirmação da criação da pasta “exploit” no computador da vítima.
141
Figura 5.39. Constatação de criação de uma pasta após o ataque.
Os testes para detecção da exploração da vulnerabilidade ms03-026 foram executados
conforme descrito nesta seção. Os resultados são apresentados a seguir.
Figura 5.40. Estatísticas de alertas no frontend BASE o teste obtenção de acesso
Figura 5.41. Alertas do Snort o teste obtenção de acesso
Figura 5.42. Assinaturas do Snort para o teste obtenção de acesso
142
Síntese do testeNumero do Teste: 9 Tipo de ataque: Obtenção de acesso
MetodologiaDescrição Utilização da ferramenta MSF para explorar a vulnerabilidade
ms03-026Ferramentas MSF: configurar exploit para ms03-026 Buffer Overrun In RPC
InterfacePassos _ Zerar a contagem de alertas na interface (BASE);
_ configurar e lançar o exploit no MSF;_ Anotar os resultados e capturar as telas do BASE.
Tempo 3 minutos e 25 segundosMaquinas Virtuais Ubuntu 8.04 (sensor Snort) - 192.168.10.2
Windows 2003 Server (alvo) - 192.168.10.10Windows XP (atacante) - 192.168.10.64
Resultados obtidosNúmero de alertas gerados 3Alertas únicos 2Conclusão O Snort conseguiu identificar corretamente o ataque do exploit à
vulnerabilidade ms03-026.
Tabela 5.13 Resultados para a execução do exploit ms03-026 Buffer Overrun In RPC Interface
Apesar do Snort usando no teste não possuir uma assinatura específica para ataques do
tipo DCOM, o resultado da detecção mostrou-se satisfatório, uma vez que indicou a atividade
maliciosa “Attacke-Responses Directory Linsging”.
143
CONSIDERAÇÕES FINAIS
O presente trabalho apresentou uma proposta de segurança de rede, através da
implementação de um Sistemas de Detecção de Intrusão.
Os conceitos iniciais abordados demonstraram um fato irrefutável: apesar de intensa
pesquisa e investimentos no mercado de TI, a existência de vulnerabilidades é um fator
inerente tanto a protocolos, Sistemas Operacionais e aplicativos.
Em se tratando de Sistemas Operacionais, particularmente, o cenário é ainda mais grave,
pois, nestes casos os danos relacionados aos ataques de worms, podem atingir proporções
globais. É inútil, portanto, a comparação entre este ou aquele S.O. ser mais vulnerável; pois
basta existir uma única brecha de segurança, passível de exploração, que a ameaça se
concretiza, mesmo sob a guarda de firewalls. O aumento dos ataques, portanto, é uma
realidade não apenas estatística, mas uma prova da sofisticação, complexidade e abrangência
dos ataques.
Logo, a adoção de normas de segurança, criptografia e mecanismos de prevenção é
essencial. Mas tão importante quanto, é a necessidade de monitorar e conhecer tráfego de rede
e através dessa prática gerenciar os riscos relacionados à segurança. Essa constatação motiva
muitas soluções, que tentam agregar diversas funcionalidades, como anti-vírus corporativo,
anti-spyware, detecção e reação à intrusão; representando algumas vezes a última linha de
defesa em sistemas vulneráveis.
Desta forma, os IDS surgem como uma excelente solução de administração, permitindo a
integração de várias tarefas distintas, embora distantes da perfeição. IDS podem, entretanto,
144
auxiliar na melhoria da segurança e, a exemplo do ocorrido nos últimos anos com firewalls e
soluções de anti-vírus corporativo, certamente sofrerão melhoramentos, padronização e irão se
popularizar nos próximos anos.
Neste contexto, o levantamento de informações e simulações realizados no capítulo 5
(Simulações e Resultados), permitiriam diversas abordagens teórico/práticas, bem como
estudar metodologias associadas à proteção e teste de segurança de redes. Além da
oportunidade de aperfeiçoar o discernimento das inúmeras abordagens de testes, este trabalho
permitiu ainda refletir e apontar diversas conclusões:
A necessidade constante da presença humana para acompanhar os logs e analisar os
resultados torna-se um entrave no desenvolvimento de automação para IDS;
A importância do uso de metodologias para avaliação de riscos de segurança;
A importância de customizar o funcionamento do Snort para realidade o tráfego da
rede, tentando assim evitar regras desnecessárias e falsos positivos;
Customização dos pré-processadores Snort e regras para ataques de evasão (quando
possível);
É imprescindível a atualização de regras do Snort e aplicação de regras
personalizadas. A utilização das regras “Unregistered” mostrou-se totalmente
ineficaz.
Necessidade de utilização de regras Emerging Threats (Bleeding Threats);
Utilização do BASE (Basic Analysis and Security Engine), no auxilio de analise de
logs e alertas gerados;
Utilização de outros complementos no auxilio da gerência e configuração tando do
Snort quanto da base regras;
A utilização de IPS ou mecanismos reativos deve ser cuidadosamente avaliada, pois
em caso de falso positivo, pode ocorrer um bloqueio ao tráfego legítimo;
Por outro lado, a metodologia utilizada neste trabalho também pode ser continuada
através de novos experimentos que, certamente, complementariam o escopo apresentado;
conforme descrito a seguir:
Avaliar o conjunto de assinaturas para outros tipos de ataques de evasão;
145
Estabelecer um estudo comparativo entre SourceFire VRT e Bleeding Edge Threats,
o qual pode demonstrar a eficiência ataques evasivos entre esses dois conjuntos de
regras e auxiliar administradores de redes na customização do Snort;
Avaliar o comportamento do tráfego e tipos de assinaturas para outros tipos de
ataques, como, por exemplo: DoS, força bruta, etc;
Todas as simulações realizadas neste trabalho foram executadas em um ambiente de
teste isolado, seria importante avaliar a detecção para os mesmos ataques e a geração
de falso positivos na presença de um tráfego de fundo, ou seja, um fluxo de dados
transmitido paralelo aos ataques, cujo objetivo é simular diferentes situações de
tráfego espúrio;
Avaliar as condições de detecção para outros ataques produzidos pelo MSF,
inclusive com tentativas de evasão.
146
REFERÊNCIAS BIBLIOGRÁFICAS
[DRESCH, 2004] DRESCH, Eduardo. Interoperabilidade e Compartilhamento de Informações Sobre Ataques entre Sistemas de Detecção de Intrusão Utilizando o SNORT: Modelo de conversão para CIDF. 2004. 82 f. Trabalho de Conclusão de Curso. (Graduação em Bacharelado Em Sistemas de Informação) - Sociedade Educacional de Santa Catarina.
[SOARES, 1995] SOARES, Luiz F. G.; LEMOS, Guido; COLCHER, Sérgio. Redes de computadores: das LANs, MANs e WANs às redes ATM. Rio de Janeiro: Campus, 1995.
[JUNIOR, 2006] JUNIOR, Francisco Vieira. Estudo de caso em segurança de redes usando como ferramenta de IDS (Intrusion Detection System) o Snort. FIEB 2006. 9p.Disponível em: http://www.fieb.org.br/iel/bitec/Arquivos/2006/FRANCISCO_VIEIRA_JUNIOR.pdfAcessado em: 13/03/2008.
[CAMPELLO e WEBER, 2001] CAMPELLO, Rafael Saldanha, WEBER, Raul Fernando. Sistemas de Detecção de Intrusão. Disponível em: <http://www.inf.ufrgs.br/gseg/producao/minicurso-ids-sbrc-2001.pdf> Acesso em: 12 de mar de 2008
[SOUZA e MARTINI, 1987] SOUZA, J.M.; MARTINI, M.R.B. Avaliação de confiabilidade de sistemas. In: Simpósio em Sistemas de Computadores Tolerantes a Falhas, 2., Campinas, Ago, 1987. Minicurso. Campinas, UNICAMP, 1987. p.24-28.
[WEBER e JASCH-PÔRTO, 1996] WEBER, Taisy S.; JASCH-PÔRTO, Ingrid; WEBER, Raul. Tolerância a falhas: conceitos e técnicas, aplicações, arquitetura de sistemas confiáveis - Notas de aula. Porto Alegre: Instituto de Informática, UFRGS, 1996.
[ZWICKY, 2000] ZWICKY, Elizabeth D.; COOPER, Simon; CHAPMAN, Brent. Building Internet Firewalls. 2 ed. Sebastopol: O'Reilly & Associates, 2000.
[HORA et al, 2001] HORA, Evandro Curvelo ; MATTOS, Cristiano Lincoln ; SILVA, Fabio ; CARNUT, Marco Antonio . Uma arquitetura extensível para a detecção remota de sniffers. In: Anais Simpósio de Segurança em Informática - SSI'2001, 2001, São José dos Campos/SP.
[FARMER e VENEMA, 1993] FARMER, Dan; VENEMA, Wietse. Improving the Security of Your Site By Breaking Into It. USENET posting, December 1993.
[SILVA, 2005], Renato Maia. Redes neurais artificiais aplicadas à detecção de intrusão em redes TCP/IP. Dissertação (mestrado). Rio de Janeiro RJ PUC, Departamento de Engenharia Elétrica, 2005. 144p.
[HEADY, LUGER et al, 1990] R. Heady, G. Luger, A. Maccabe e M. Servilla “The architecture of a network level intrusion detection system. Technical Report, Computer Science Department, University of New Mexico, Agosto
de 1990
[JORGE, 2006], JORGE, Leandro Silva. Detecção de Intrusão em Redes de Computadores com estatísticas PDF e classificadores Neurais. Dissertação (mestrado). Universidade Presbiteriana Mackenzie. São Paulo SP. 106p.
[LAKHINA, 2004] LAKHINA, A., CROVELLA, M., e Diot, C. (2004). Diagnosing network-wide traffic anomalies. In Proc. of the ACM SIGCOMM’2004, Portland, OR, EUA.
[MAKHERJEE et al 1994] MAKHERJEE, B., HEBERLEIN, L. T., E LEVITT, K. N. Network intrusion detection. IEEE Network 8 (1994), 26–41.
[ALLEN, 2000] ALLEN, Julia et al. State of the Practice of Intrusion Detection Technologies. Technical Report CMU/SEI-99-TR-028, Software Engineering Institute, Carnie Mellon University, jan. 2000.
[ALLEN, 2000] ALLEN, Julia et al. State of the Practice of Intrusion Detection Technologies. Technical Report CMU/SEI-99-TR-028, Software Engineering Institute, Carnie Mellon University, jan. 2000.
[SHIREY, 2000] SHIREY, R. RFC 2828 – Internet Security Glossary. The Internet Society, 2000. Disponível em: http://www.ietf.org/rfc/rfc2828.txt?number=2828.Acessado em: 08/04/2004.
[SÊMOLA, 2003] SÊMOLA, Marcos. Gestão da Segurança da Informação – Uma visão Executiva. Editora Campus. Rio de Janeiro, 2003.
[HALME et al 1995] HALME, Lawrence R.; BAUER, Kenneth R. AINT Misbehaving – A Taxonomy of Anti-Intrusion Techniques. In: NATIONAL INFORMATION SYSTEMS SECURITY CONFERENCE, 18., 1995, Baltimore, MD, USA. Anais… [S.l.: s.n.], 1995.
[STONEBURNER, 2001] STONEBURNER, Gary. Underlying Technical Models for Information Technology Security. NIST Special Publication 800-33, 2001.
[BARFORD, 2001] BARFORD, P.; PLONKA, D. Characteristics of network traffic flow anomalies. In: ACM SIGCOMM INTERNET MEASUREMENT WORKSHOP, 1., 2001, San Francisco, CA. Proceedings… New York, NY: ACM Press, 2001. p. 69-73. ISBN 1581134355.
[MAIA, 2005] MAIA, Roberto Bomeny. Detecção da Intrusão Utilizando Classificação Bayesiana. Tese de Mestrado. COPPE/UFRJ, Rio de Janeiro RJ, 2005. 139 p.
[SILVA, 2007] Silva, S. L. Uma Metodologia para Detecção de Ataques no Tráfego de Redes Baseada em Redes Neurais. Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada. São José dos Campos SP. INPE, 2007. 256 p.
[DENNING, 1987] DENNING, Dorothy. “An intrusion detection model”. IEEE Transactions on Software Engineering, Vol SE 13 No 2, Fevereiro de 1987.
[GOMES, 2006]GOMES, Daniel. Detecção de intrusão em redes de computadores utilizando classificadores one-class. Publicação Escola Politécnica de Pernambuco. Trabalho de Conclusão do Curso de Eng. da Computação. Recife PE, 2006. 74p.
[LAUREANO, 2005] LAUREANO, Marcos Aurelio Pchek. Manual de Gestão de Segurança da Informação. 2005. 132p.
[LAUREANO, 2004] LAUREANO, M. A. P. Uma abordagem para a proteção de detectores de intrusão baseada em máquinas virtuais. Dissertação (Mestrado em Informática Aplicada) - Centro de Ciências Exatas e de Tecnologia, Pontifícia Universidade Católica do Paraná, Curitiba, 2004. 103 f.
[RAITZ, 2005] RAITZ, Luciano. Utilização de Máquinas Virtuais para Implantar um Mecanismo Transparente de Detecção de Intrusão em Servidores Web. Depto. De Sistemas de Computação. Universidade Regional de Blumenau. Blumenau SC: 2005. 50p.
ANEXO 1
TUTORIAL DE INSTALAÇÃO DO SNORT
Este anexo visa apresentar a instalação do Snort com atualização de regras via oinkmaster. Para produzir este anexo, foi utilizado o Snort 2.8.2.1 e o Ubuntu Server 8.04.
1. obtendo privilégios de root e criando o diretório de instalação$ sudo -i
Digite sua senha:
# cd /root# mkdir snorttmp# cd /root/snorttmp
2. Instalando dependências e bibliotecas para compilação # apt-get install build-essential# apt-get install libpcap0.8-dev libmysqlclient15-dev mysql-client-5.0 mysql-server-5.0 bison flex apache2 libapache2-mod-php5 php5-gd php5-mysql libphp-adodb php-pear pcregrep libpcre3-dev
3. Download do snort # cd /root/snorttmp#wget http://www.snort.org/dl/current/snort-2.8.2.1.tar.gz#tar zxvf snort-2.8.2.1.tar.gz
4. Download das regras (snort rules)
Crie um diretório temporário para as regras:# mkdir /root/rules# cd /root/rules
Existem 4 tipos de download de regras do snort
1 - Subscrição (subscription release) - Pago
2 - Registrado (registered user release) - Gratuito
3 - Sem registro (unregistered user release) - Gratuito
4 - Comunidade (Community Rules ) - Gratuito
Recomendamos o método 2. Para o download das regras “Sourcefire VRT Certified Rules
(registered user release)” o registro é obrigatório, mas sem custos. Faça o registro, para a página:
http://www.snort.org/pub-bin/downloads.cgi#VRT
e baixe a versão mais atualizada das regras na URL a seguir:
http://www.snort.org/pub-bin/downloads.cgi/Download/vrt_os/snortrules-snapshot-CURRENT.tar.gz
Salve o arquivo no diretório “/root/snorttmp” e descompacte-o.#tar zxvf snortrules-snapshot-CURRENT.tar.gz
5. Compilar o Snort
# cd /root/snorttmp/snort-2.8.2.1#./configure -enable-dynamicplugin –with-mysql# make# make install
6. Mover arquivos
É necessário mover os arquivos de regras (rules) e o arquivo de configuração do Snort para o local
definitivo.
#mkdir /etc/snort /etc/snort/rules /var/log/snort#cd /root/snorttmp/snort-2.8.2.1/etc#cp * /etc/snort/#cd /root/snorttmp/rules#cp * /etc/snort/rules
7. Configure Snort
Edite o arquivo “/etc/snort/snort.conf “
Procure variável: var HOME_NET any Altere para: var HOME_NET 192.168.10.0/24 #ou outra diferente de 192.168.10.0/24Procure a linha: var EXTERNAL_NET anyAltere para: var EXTERNAL_NET !$HOME_NET #O que não for HOME_NET é externoProcure a linha: RULE_PATH ../rulesAltere para: var RULE_PATH /etc/snort/rules #Caminho para as regras
Procure a linha a seguir e remova o caractere de comentário “#”
#output database: log, mysql, user=root password=test dbname=db host=localhost
Altere para:
output database: log, mysql, user=snort password= snort_password dbname=snort host=localhost
Lembre-se de colocar a mesma senha no campo “snort_password” que será configurada para
acesso a base snort no MySQL.
Salve o arquivo: /etc/snort/snort.conf
Altere as configurações do arquivo de configuração para deixa-lo mais seguro: # chmod 600 /etc/snort/snort.conf
8. Configurar o MysqlFaça o Login no mysql server: # mysql -u root -p
Crie a base de dados snort. Conceda os privilégios de acesso ao usuário “snort” e atribua uma
senha.
mysql> create database snort;mysql> grant all privileges on snort.* to 'snort'@'localhost' identified by 'snort_password'; mysql> exit
Use o “snort schema” para o Layout do banco de dados# mysql -D snort -u snort -p < /root/snorttmp/snort-2.8.2.1/schemas/create_mysql
Verifique se a base de dados do Snort foi criada corretamente
# mysql -u snort -p
mysql> show databases;+--------------------+| Database |+--------------------+| information_schema || snort |+--------------------+2 rows in set (0.00 sec)mysql> use snort;mysql> show tables;+------------------+| Tables_in_snort |+------------------+| data || detail || encoding || event || icmphdr || iphdr || opt || reference || reference_system || schema || sensor || sig_class || sig_reference || signature || tcphdr || udphdr |+------------------+16 rows in set (0.01 sec)mysql> exit
9. Testar o APACHE/PHP
Crie um arquivo index.php com o seguinte conteúdo
# nano /var/www/index.php<?php phpinfo();?>
Teste o funcionamento do Apache/PHP acessando o servidor digitando http://localhost na barra
de endereços do navegador.
10. Faça o download do BASE (Basic Analysis and Security Engine)
# cd /var/www/# wget http://ufpr.dl.sourceforge.net/sourceforge/secureideas/base-1.4.0.tar.gz# tar zxvf base-1.4.0.tar.gz# rm /var/www/base-1.4.0.tar.gz # mv /var/www/base-1.4.0 /var/www/base# chmod 757 /var/www/base
11. Digite os comando a seguir para instalar as extensões do pear.
# pear install Image_Color# pear install Image_Canvas-alpha# pear install Image_Graph-alpha
12. Configuração do BASE via WEB.Aponte seu Web Browser para a URL: http://IP_do_short/base/setup.
Na página que abrir, clique em “continue” ....
a) Passo 1 de 5: Em Language: Portugues-PTDigite o caminho para o ADODB: /usr/share/php/adodb
b) Passo 2 de 5:Preencha os camposDatabase type = MySQL, Database name = snort, Database Host = localhost, Database username
= snort, Database Password = SENHA_ACESSO_AO_SnortDB
c) Passo 3 de 5: Se você desejar a autenticação, digite o nome do usuário/senha para acesso. Ex: User name: admin / Password: toor
d) Passo 4 de 5: Clique no botão “Create BASE AG”. Veja se aparece as mensagens:Successfully created 'acid_ag'Successfully created 'acid_ag_alert'Successfully created 'acid_ip_cache'Successfully created 'acid_event'Successfully created 'base_roles'Successfully INSERTED Admin roleSuccessfully INSERTED Authenticated User roleSuccessfully INSERTED Anonymous User roleSuccessfully INSERTED Alert Group Editor roleSuccessfully created 'base_users'
Adds tables to extend the Snort DB to support the BASE functionality - DONE
e) Passo 5 de 5: Se tudo correu bem no passo 4 clique no botão “Now continue to step 5....”
Ao final, aparecerá a página do BASE.
Altere as permissões para o diretório: /var/www/base
# chmod 775 /var/www/base
13. Altere o arquivo “/etc/rc.local”
Adicione a seguinte entrada no final do arquivo. (obs: para “ouvir” a interface eth1).
# /usr/local/bin/snort -c /etc/snort/snort.conf -i eth1 -D
14. Instalação do Oinkmaster
# apt-get install oinkmaster# nano /etc/oinkmaster.conf
Altere a seguinte linha
# url = http://www.snort.org/pub-bin/oinkmaster.cgi/<oinkcode here>/<filename>
Ex: url = http://www.snort.org/pub-bin/oinkmaster.cgi/<oinkcode here>/snortrules-
snapshot-2.8.tar.gz
O oinkcode você pode obter após fazer o registro na página do Snort.
14.3. Testando o Oinkmaster
Apenas simula a instalação.
# oinkmaster -c -o /tmp/rules/
14.2. Usando as Bleeding Edge Threats
Editar o arquivo oinkmaster.conf:
# nano /etc/oinkmaster.conf
Adicione a seguinte linha
url = http://www.bleedingsnort.com/bleeding.rules.tar.gz
Para Instalar:
# oinkmaster -i -o /etc/snort/rules/
Após a instalação, inclua a seguinte linha no final do arquivo “/etc/snort/snort.conf”
include $RULE_PATH/bleeding.conf
Após a instalação será necessário reiniciar o Snort.
ANEXO 2 - CONTEÚDO DO DVD
PASTA “MAQUINAS VIRTUAIS”
Item Descriçãobt3-final.iso ISO da distribuição Backtrack 3 (Final release)
UbuntuServer.zip Ubuntu Server 8.04*
Windows XP Professiona. Windows XP Pro – atacante
PASTA “SOFTWARE”
Item Descriçãoapache_2.2.9-win32-x86-openssl-0.9.8h-r2.msi Servidor WEB Apache 2.2.9 ( for Windows)
framework-3.1.exe MetaSploit Framework 3 (versão .3.1)
idspm.v2.2.0.20.exe IDS Policy Manager: para gerenciamento de regras do Snort.
Nessus-3.0.6.1.exe Security Scanner Nessus, para verificação de falhas/vulnerabilidades.
NessusClient-3.0.0.msi Cliente Nessus
nessus_3.0_advanced_user_guide.pdf Manual do usuário.
nessus_3.0_client_guide.pdf Manual do Cliente Nessus
nessus_3.0_installation_guide.pdf Manual de instalação do Nessus
ossec-agent-win32-1.5.exe Agente OSSEC (for Windows)
ossec-hids-1.5.1.tar.gz Servidor OSSEC (for Linux)
RetinaDemo585.exe Security Scanner Nessus, para verificação de falhas/vulnerabilidades (versão evaluate)
snort-2.8.2.1.tar.gz Servidor IDS Snort (for Linux)
Snort_2_8_2_1_Installer.exe Servidor IDS Snort (for Windows)
VMware-server-installer-1.0.6-91891.exe VMware Server (for Windows)34
VMware-workstation-6.0.4-93057.exe VMware Workstation (for Windows)35
VMware-workstation-6.0.4-93057.i386.tar.gz VMware Workstation (for Linux)
WinPcap_4_0_2.exe Programa análise rede captura pacotes em plataformas Win32
Obs: A cópia desta monografia encontra-se no DVD (monografia_ids.pdf)
34 Licençca VMWare Server : 91AK1-YF7F1-15M71-4LMCD
35 As licenças do VMWare Workstation podem ser obtidas no site www.vmware.com através de registro.