Vous êtes sur la page 1sur 90

CENTRO ESTADUAL DE EDUCAO TECNOLGICA

PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES

RICARDO BASTOS GARCIA

SISTEMA DE DETECO DE INTRUSO E BLOQUEIO DE


ATAQUES UTILIZANDO IDS-SNORT

LINS/SP
1 SEMESTRE/2013

CENTRO ESTADUAL DE EDUCAO TECNOLGICA


PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES

RICARDO BASTOS GARCIA

SISTEMA DE DETECO DE INTRUSO E BLOQUEIO DE


ATAQUES UTILIZANDO IDS-SNORT

Trabalho de Concluso de Curso apresentado


Faculdade de Tecnologia de Lins, para obteno
de ttulo de tecnlogo em Redes de Computadores
Orientador: Prof. Dr. Fernando A. Garcia Muzzi

LINS/SP
1 SEMESTRE/2013

RICARDO BASTOS GARCIA

SISTEMA DE DETECO DE INTRUSO E BLOQUEIO DE


ATAQUES UTILIZANDO IDS-SNORT

Trabalho

de

Concluso

de

Curso

apresentado Faculdade de Tecnologia


de Lins Prof. Antonio Seabra, como parte
dos

requisitos

necessrios

para

obteno do ttulo de Tecnlogo em


Redes de Computadores sob orientao
do Prof. Dr. Fernando A. Garcia Muzzi
Data de aprovao: ___/___/___

____________________________
Orientador (Prof. Dr. Fernando A. Garcia Muzzi)
______________________________
Examinador 1 (Nome do Examinador)
______________________________
Examinador 2 (Nome do Examinador)

Dedicatria

Antes de tudo, dedico este trabalho a


Deus que conduziu meus caminhos na
superao dos momentos mais difceis. A
meus pais, Deoclcio Garcia Fernandes, in
memorian, e Maria Inez Bastos Garcia, in
memorian, e a minha amada filha Julia.

Ricardo Bastos Garcia

AGRADECIMENTOS

Neste momento to importante pra mim, eu no poderia deixar de agradecer


s pessoas de que, de alguma maneira contriburam para que este momento
acontecesse.
Agradeo em especial ao meu orientador, Prof. Dr. Fernando A. Garcia
Muzzi, por quem tive a honra de ser orientado, assim tambm, pelas orientaes
proveitosas e competentes, e acima de tudo, por nos fazer acreditar que este
trabalho sempre seria possvel.
Ao professor Ygor Gonzaga de Oliveira, que no est mais entre ns, e cuja
amizade muito contribuiu em grandeza de esprito.
Aos professores Alexandre Ponce, Adriana de Bortoli e Luciane Noronha
pela correo do nosso trabalho e pela disposio para tirar as dvidas.
Ao professor Julio Fernando Lieira pela ajuda e pelo material cedido, que
muito me ajudou na construo dos principais captulos.
A todos os demais professores agradeo pela dedicao a aulas
ministradas.
E aos amigos de turma pelos momentos em que compartilhamos
conhecimentos, companheirismo, amizade, dificuldades sempre superadas e
alegrias.

Ricardo Bastos Garcia

RESUMO

A tecnologia da informao tem evoludo rapidamente. Computadores mais


avanados, redes mais velozes e abrangentes, softwares inteligentes de gesto,
tudo para auxiliar nas mais diversas atividades. Porm, ao mesmo tempo, existem
alguns que preferem fazer uso de toda esta tecnologia para causar algum dano a
outrem. Assim surgiram os chamados hackers. Com o propsito de prevenir a ao
destes indivduos, criar uma poltica de segurana de vital importncia para
proteger as informaes. Segurana a direo em que se pode viajar, mas que de
fato, nunca se chegar ao destino. um processo dinmico de constante
acompanhamento, aprendizado e melhoria. Muitas so as ferramentas usadas na
configurao de um sistema de segurana de redes. Entre estas ferramentas esto
os IDS. Os IDS so sistemas de deteco de intruso que monitoram as atividades
da rede procurando por padres de comportamento que se enquadre em tentativas
conhecidas de acessos no autorizados. Nesse contexto, foi usado como base ao
longo deste trabalho o IDS Snort. utilizada para anlise uma plataforma de
simulao, utilizando-se mquinas virtuais, instalando e configurando as ferramentas
necessrias para criar um ambiente para testes. As principais contribuies so a
deteco e conteno das tentativas de invaso e avaliao dos resultados para
construo de conhecimento da segurana da rede interna.

Palavras-chave : Segurana, IDS, Ataques, Conteno.

ABSTRACT

Information technology has evolved rapidly. Most advanced computers, faster


networks and comprehensive, intelligent management software, all to assist in
various activities. However, while there are some who prefer to make use of all this
technology to cause harm to others. Thus appeared the so-called "hackers". In order
to prevent the action of these individuals, creating a security policy is vitally important
to protect the information. Security is the direction in which they can travel, but never
actually reach the destination. It is a dynamic process of constant monitoring,
learning and improvement. Many tools are used in the configuration of a system of
network security. Among these tools are the IDS. The IDS are intrusion detection
systems that monitor the activities of the network looking for patterns of behavior that
fits known attempts at unauthorized access. In this context, we use as the basis of
this work over the Snort IDS. It is a platform used for analysis, simulation using virtual
machines, installing and configuring the tools necessary to create an environment for
testing. The main contributions are the detection and containment of intrusion
attempts and evaluating results to build knowledge of internal network security.

Keywords: Security, IDS, Attacks, Containment.

LISTA DE ILUSTRAES
Figura 1.1 Posicionamento dos NIDS ................................................................... 26
Figura 1.2 Posicionamento dos HIDS ................................................................... 27
Figura 1.3 Localizao dos IDS na rede ............................................................... 31
Figura 1.4 Funcionamento do IPS na rede ............................................................ 32
Figura 2.1 Arquitetura do Snort ............................................................................. 38
Figura 2.2 Pr-processador do Snort .................................................................... 39
Figura 2.3 Verificao de regras do Snort .............................................................. 40
Figura 2.4 Mecanismo de deteco do Snort ........................................................ 41
Figura 2.5 Componentes de alerta do Snort .......................................................... 42
Figura 2.6 Camadas TCP/IP ................................................................................. 47
Figura 3.1 Layout do pacote ICMP ........................................................................ 55
Figura 3.2 Conexo normal cliente-servidor .......................................................... 58
Figura 3.3 Conexo com Syn flood ........................................................................ 58
Figura 3.4 Cabealho UDP .................................................................................... 59
Figura 3.5 Envio e recebimento de dados - servidores ......................................... 60
Figura 3.6 Akamai DDoS em tempo real ............................................................ 61
Figura 4.1 Ataque DDoS ....................................................................................... 62
Figura 4.2 Tabelas do MySQL usadas pelo Snort .................................................. 63
Figura 4.3 Tela inicial do B.A.S.E. ......................................................................... 64
Figura 4.4 Ambiente de testes................................................................................ 68
Figura 4.5 Tela do B.A.S.E. - Ataque T50 - deteco ............................................ 70
Figura 4.6 Trfego de pacotes na rede - deteco T50 ........................................ 71
Figura 4.7 Trfego de pacotes na rede deteco e bloqueios T50 .................... 71
Figura 4.8 Utilizao da CPU pelo processo Snort T50 ...................................... 72
Figura 4.9 Relatrio de alertas do B.A.S.E. ........................................................... 73
Figura 4.10 Bloqueios feitos no iptables - T50 ...................................................... 73
Figura 4.11 Trfego de pacotes na rede deteco Bonesi ................................. 74
Figura 4.12 Trfego de pacotes na rede deteco e bloqueios Bonesi .............. 74
Figura 4.13 Utilizao da CPU pelo processo Snort - Bonesi ............................... 75
Figura 4.14 Comparao entre os injetores pacotes recebidos ......................... 76
Figura 4.15 Pacotes avaliados x alertas/bloqueios gerados ................................. 77

Figura A.1 Criao da virtual machine .................................................................. 82


Figura A.2 Memria reservada para VM ............................................................... 83
Figura A.3 Espao em disco reservado para VM .................................................. 83
Figura A.4 Adaptador de rede da VM .................................................................... 84
Figura A.5 Selecionando ISO para instalao ....................................................... 84
Figura A.6 Tela de instalao do ubuntu ............................................................... 85
Figura A.7 Tela do B.A.S.E. .................................................................................. 88

LISTA DE TABELAS
Tabela 3.1 Tipos de mensagens ICMP .................................................................. 56
Tabela 3.2 Tipos de respostas ICMP .................................................................... 57
Tabela 4.1 Funo das VMs nos testes ................................................................ 62

LISTA DE QUADROS
Quadro 4.1 Protocolos usados no ataque com T50 ............................................... 70
Quadro 4.2 Resultado do Snort com T50 - deteco ............................................. 71
Quadro 4.3 Resultado do Snort com T50 - bloqueios ........................................... 75

LISTA DE ABREVIATURAS E SIGLAS


ACID Analysis Console for Intrusion Databases
DMZ DeMilitarized Zone
HD

Hard Disk

HIDS Host-Based Intrusion Detection System


HTTP Hyper Text Transfer Protocol
ICMP Internet Control Message Protocol
IDS

Intrusion Detection System

IMAP Internet Message Access Protocol


IP

Internet Protocol

IPS

Intrusion Prevention System

IPSEC IP Security Protocol


IPX

Internetwork Packet Exchange

ISP

Internet Service Provider

LAN Local Area Network


NIC

Network Interface Card

NIDS Network-Based Intrusion Detection System


POP Point Of Presence
RPC Remote procedure Call
SIP

Session Initiation Protocol

SMTP Simple Mail Transfer Protocol


SNMP Simple Network Management Protocol

SPAN Switched Port Analyzer


SPX Sequenced Packet Exchange
SQL Structured Query Language
SO

Sistema Operacional

TCP Transmission Control Protocol


URL Uniform Resource Locator
VPN Virtual Private Network

LISTA DE SMBOLOS
@ - Arroba
- Marca Registrada
- Registado

SUMRIO
INTRODUO ..................................................................................... 17
1 IDS .................................................................................................. 20
1.1 SEGURANA..................................................................................................... 20
1.2 AMEAAS E ATAQUES .................................................................................... 21
1.3 PRINCPIOS DE PREVENO E PROTEO ................................................. 23
1.4 SISTEMAS DE DETECO DE INTRUSES ................................................... 24
1.4.1 Tipos de IDS.................................................................................................... 25
1.4.1.1 NIDS ............................................................................................................. 25
1.4.1.2 HIDS ............................................................................................................. 26
1.4.1.3 Sistemas Hbridos ....................................................................................... 27
1.5 DEFICINCIAS DOS IDS .................................................................................. 28
1.6 METODOLOGIAS DE DETECO .................................................................. 29
1.7 DETECO BASEADA EM CONHECIMENTO ................................................ 29
1.8 DETECO BASEADA EM COMPORTAMENTO ............................................ 30
1.9 POSICIONAMENTO DOS SENSORES ............................................................ 30
1.9.1 Localizao do IDS na rede ........................................................................... 30
1.10 SISTEMAS DE PREVENO DE INTRUSES ............................................. 32
1.11 DETECO DE ANOMALIAS ......................................................................... 33
1.11.1 Anomalias em Padres de Comportamento ................................................. 33
1.11.2 Anomalias em Padres de Trfego .............................................................. 34
1.11.3 Anomalias em Padres de Protocolos .......................................................... 34
1.12 TESTES DE INTRUSO ................................................................................. 34
1.13 SEGURANA INTEGRADA ............................................................................ 34
1.14 CONSIDERAES FINAIS ............................................................................ 35

2 SNORT ............................................................................................ 37
2.1 DEFININDO O SNORT ..................................................................................... 37
2.2 ARQUITETURA ................................................................................................. 37
2.3 PRE-PROCESSADOR E MECANISMO DE DETECO ................................. 39
2.4 SISTEMA DE ALERTA E LOG .......................................................................... 41
2.5 FUNCIONAMENTO DO SNORT ....................................................................... 42
2.5.1 Filtros e Criao de Assinaturas ..................................................................... 44

2.5.1.1 Politicas de Filtragem .................................................................................. 44


2.5.1.1.1 Deny Everything (Negar Tudo) ................................................................. 44
2.5.1.1.2 Allow Everything (Permitir Tudo) .............................................................. 45
2.5.2 Assinaturas ..................................................................................................... 45
2.5.2.1 Composio das Assinaturas ...................................................................... 46
2.5.2.2 Aes .......................................................................................................... 46
2.5.2.3 Protocolos ................................................................................................... 46
2.5.2.4 Endereos IP ............................................................................................... 48
2.5.2.5 Nmeros de Portas ...................................................................................... 48
2.5.2.6 Operador de direo .................................................................................... 49
2.5.2.7 Opes de Regra ........................................................................................ 49
2.6 CONSIDERAES FINAIS .............................................................................. 50

3 FORMAS DE ATAQUES E INVASES ........................................... 51


3.1 A RAZO DE SER INVADIDO .......................................................................... 51
3.2 PROBING .......................................................................................................... 52
3.3 TROJAN HORSES ............................................................................................ 52
3.4 BACKDOORS ................................................................................................... 52
3.3 BUFFER OVERFLOW ....................................................................................... 53
3.4 PASSWORD CRACKERS ................................................................................. 53
3.5 SPOOFING ....................................................................................................... 54
3.6 ATAQUES DE NEGAO DE SERVIO - DoS ............................................... 54
3.6.1 Pings e ICMP ................................................................................................. 55
3.6.2 Echo Request e Echo Reply ........................................................................... 56
3.6.3 Transformando um Ping em Arma ................................................................. 56
3.6.4 Formas de Ataque DoS .................................................................................. 57
3.7 DDoS ................................................................................................................. 59
3.8 CONSIDERAES FINAIS .............................................................................. 61

4 TESTES E RESULTADOS ............................................................. 62


4.1 METODOLOGIA ................................................................................................ 62
4.2 FERRAMENTAS UTILIZADAS .......................................................................... 63
4.2.1 MySQL ........................................................................................................... 63
4.2.2 PHP ................................................................................................................ 64
4.2.3 B.A.S.E. .......................................................................................................... 64

4.2.4 Apache ........................................................................................................... 65


4.2.5 oinkmaster ...................................................................................................... 65
4.2.6 Libpcap ........................................................................................................... 65
4.2.7 Adodb ............................................................................................................. 65
4.2.8 Guardian ......................................................................................................... 66
4.2.9 Wireshark ....................................................................................................... 66
4.2.10 T50 ............................................................................................................... 66
4.2.11 BoNeSi ......................................................................................................... 67
4.2.12 VitualBox ...................................................................................................... 67
4.3 AMBIENTE DE TESTES ................................................................................... 67
4.4 RESULTADOS EXPERIMENTAIS ..................................................................... 69
4.5 SIMULAO DE ATAQUE COM INJETOR T50 ................................................ 69
4.6 SIMULAO DE ATAQUE COM INJETOR BONESI ........................................ 74
4.7 COMPARAO ENTRE OS INJETORES ......................................................... 76
4.8 DIFICULDADES ENCONTRADAS ..................................................................... 78
4.9 TRABALHOS FUTUROS ................................................................................... 78
CONCLUSO ........................................................................................................... 78
REFERNCIA BIBLIOGRFICA .............................................................................. 80
ANEXO A ................................................................................................................. 82

17

INTRODUO
Uma revoluo est em curso, na qual a informao vale muito. As redes de
computadores necessitam cada vez mais ateno voltada a sua segurana, pois
muitas so as tecnologias envolvidas, e estas, em constante evoluo. A
possibilidade de acesso no autorizado, interno ou externo, pe em risco a
integridade das informaes contidas nestas redes.
Entende-se por integridade a informao que no foi manipulada sem
autorizao, isto , um arquivo pode ser removido ou alterado normalmente
com autorizao devida, porm, caso um agente externo o faa, esta
informao est com sua integridade comprometida. (LARI; AMARAL, 2004,
p.5).

Criar um sistema seguro significa anular ou minimizar as chances de um


invasor conseguir obter acesso a ele. Assim como as tecnologias envolvidas, as
tentativas para burlar a segurana tambm esto em constante evoluo. Para que
administradores de redes possam agir no sentido de impossibilitar ou mesmo conter
estas tentativas de intruso, estes devem, primeiramente, tomar conhecimento desta
possvel movimentao no autorizada agindo em suas redes.
Neste contexto, existem tcnicas e ferramentas que so usadas pelos
administradores de rede para monitorar a movimentao em suas redes. Dentre as
ferramentas esto os sistemas de deteco de intruso, que tem suas razes nos
sistemas de auditoria financeira, e cuja ideia bsica o monitoramento das
atividades do trfego da rede, reportando assim ao administrador, situaes
anmalas que possam ocorrer.
Sendo a preveno o melhor mtodo contra a invaso de sistemas, este
trabalho tem como objetivo geral mostrar o funcionamento de uma ferramenta de
deteco de intruso implementada em sistema operacional Linux e configurado
para fazer conteno (bloqueio) de ataques DDoS.
Como ferramenta IDS foi adotada o Snort. O IDS muito difundido no
mundo do software livre e apesar de sua distribuio gratuita, uma ferramenta
poderosa.
Para alcanar o objetivo geral foram buscados os seguintes objetivos
especficos:

Instalar e configurar o Snort para que faa o monitoramento das

18

atividades de um host num ambiente de teste e, utilizando seu conjunto prdefinido de regras, reporte as tentativas de intruso, bem como, as utilize na
gerao de regras no firewall;

Para

adicionar

funcionalidade

ao

Snort,

instalar

configurar

ferramentas auxiliares, sendo estas : Banco de Dados MySQL, servidor Web


Apache, Linguagem PHP5, analisador de trfego BASE, atualizador
automtico de regras para o Snort OINKMASTER e o GUARDIAN, que age
no que se refere a conteno de ataques, gerando regras no firewall do
sistema;

Criar ambiente para simulao fazendo uso de mquinas virtuais

criadas com o software VitualBox;

Simular um ataque do tipo DDoS utilizando injetores de pacotes;

Fazer anlise das tentativas de intruso reportadas pelo Snort em um

host sob ataque DDoS e comparando-as com o mesmo cenrio, porm com
o modo de conteno (bloqueio) ativado;

Avaliar as informaes levantadas na simulao.

Diante disto, este trabalho se justifica como forma de avaliar a utilizao de


um sistema de deteco de intruso de distribuio gratuita, complementando o uso
do firewall do sistema operacional como mecanismos de segurana indispensveis.
Inicialmente ser feita uma explanao do conceito de IDS, seu
funcionamento e classificao de intruses, quais os tipos de monitoramento,
vantagens e desvantagens, apresentados no primeiro captulo.
No captulo 2 apresentado o SNORT, ferramenta IDS com licena opensource, indicada para monitorar redes TCP/IP e usada para detectar trfego
suspeito, assim como ataques externos.
O captulo 3 mostra de forma resumida as principais formas de ataques e
invases e as vulnerabilidades que estas exploram, bem como, o ataque do tipo
DDoS que ser utilizado na simulao de ataque ao host.
No captulo 4 mostrado o desenvolvimento do trabalho, as ferramentas
utilizadas em conjunto com o Snort afim de que este adquira as funcionalidades
necessrias para a realizao do objetivo do trabalho, bem como as demais
ferramentas utilizadas para criarmos as mtricas para avaliao.
Finalmente no captulo 5 so discutidos os resultados experimentais,

19

apresentados os grficos estatsticos, quadros comparativos, assim como as


concluses referentes aos testes de avaliao e desempenho e concluses finais.

20

1 IDS
O objetivo deste captulo mostrar os conceitos que envolvem a segurana
dos sistemas nas redes de computadores. Em seguida, apresentar a definio do
que um Intrusion Detection System (IDS), abordando seus aspectos, princpios de
preveno, tipos de atuao, metodologias de deteco, vantagens e deficincias,
assim como sua importncia e contribuio no segmento das tecnologias de
segurana da informao.

1.1 SEGURANA
A questo chave em redes de computadores o compartilhamento de
recursos, em especial o de dados, que precisam estar ao alcance de todos os
usurios da rede independentemente de sua localizao fsica. A internet
proporcionou essa interligao em nvel mundial, ligando computadores de
empresas, indivduos, dispositivos mveis e usurios domsticos, permitindo o
acesso de qualquer ponto para qualquer ponto do planeta. Porm, ao mesmo tempo
em que a tecnologia disponibiliza esse poderoso recurso, tambm remete ao
complexo tema voltado a segurana de sistemas nas redes de computadores.
Segundo Lieira (2012), quando se analisa a segurana em sistemas de
informao, necessrio ter em mente duas premissas:. Primeiro, a segurana no
uma tecnologia. No um dispositivo que se possa comprar e que torne uma rede
100% segura, assim como no possvel tambm, comprar ou criar um software
capaz de tornar um computador 100% seguro. E segundo, a segurana no um
estado que se pode atingir. A segurana uma direo em que se pode viajar,
porm, nunca se chegar de fato ao destino. O que se pode fazer administrar um
nvel aceitvel de risco.
Ainda de acordo com Lieira (2012), outro aspecto de segurana o fato
desta no ser esttica, ou seja, um trabalho de constante atualizao, redefinio
e implementao. Usando como analogia o ato de tentar subir uma escada rolante
infinita que desce. Pode-se correr alguns degraus acima e ento parar para
recuperar o flego; aps descansar, descobrir que a escada rolante o levou para
baixo ou at o mesmo para alm do ponto de incio. Para se manter no mesmo nvel,
preciso manter um esforo contnuo. E para avanar e conseguir maior segurana,

21

ser necessrio um esforo ainda maior. Como em uma escada rolante, no basta a
quantidade do esforo; o esforo precisar ser realizado na direo correta. A
pergunta que surge ento , como caminhar na direo correta? A resposta a essa
pergunta , atravs de uma Poltica de Segurana. Ou seja, traar regras do que
pode e do que no pode ser feito nos sistemas de informao da empresa, assim
como conscientizar os usurios desses sistemas, da necessidade de seguir essas
regras.
A tarefa de prover segurana a um sistema comea com a elaborao de
uma poltica de segurana, onde fatores humanos e gerenciais so
considerados. Isso quer dizer que a implementao da segurana depende
das necessidades de quem utiliza o sistema. (LARI e AMARAL, 2004, p.5)

Conforme Lari e Amaral (2004), um exemplo comum, o uso da porta 21


utilizada pelo File Transfer Protocol (FTP). Esse protocolo possibilita a troca de
arquivos dentro da rede, porm , ao mesmo tempo, uma brecha de segurana para
invaso. Sempre que o firewall bloqueia essa porta, evitando assim ataques a
mesma, os usurios no podero enviar arquivos por meio dela para outra mquina
da rede interna. Logo, esse tipo de bloqueio deve ser avaliado na poltica de
segurana.
Segundo Lari e Amaral (2004), avaliar a segurana de uma rede remete a
questes como, quanto vale a informao e quanto pagar para proteg-las em uma
empresa. Responde-se a isto afirmando que o valor que se d a informao
proporcional a quanto se gasta em proteg-la. Esta uma tendncia mundial, pois
os gastos com segurana crescem e se fazem cada vez mais necessrios medida
que novos ataques vo surgindo.

1.2 AMEAAS E ATAQUES


De acordo com Nobre (2007), uma ameaa, consiste em uma possvel
violao de um sistema computacional, que pode ser acidental ou intencional. Uma
ameaa acidental aquela que no foi planejada, podendo ser, por exemplo, uma
falha no hardware ou no software. J uma ameaa intencional est associada
intencionalidade premeditada. Podendo ser desde um monitoramento no
autorizado do sistema at ataques sofisticados, como os realizados por Hackers.
Ainda de acordo com Nobre (2007), algumas das principais ameaas aos

22

sistemas nas redes de computadores envolvem destruio ou modificao de


informaes, roubo, remoo ou perda de informao, revelao de dados
confidenciais ou no, e em casos extremos, chegando at a paralisao dos
servios de rede.
Um ataque acontece quando se efetiva uma ameaa intencional. Estes
ocorrem por vrios motivos. Variam desde a pura curiosidade, interesse em adquirir
maior conhecimento sobre os sistemas, inteno em conseguir ganhos financeiros,
extorso, chantagem de algum tipo, espionagem industrial ou venda de informaes
confidenciais. Outro tipo de interesse o de ferir a imagem de um governo ou uma
determinada empresa ou servio, e quando isso acontece, a notcia da invaso
proporcional fama de quem a sofreu e normalmente representa um desastre em
termos de repercusso pblica. (NOBRE, 2007)
Segundo Nobre (2007), consideram-se trs aspectos bsicos que um
sistema de segurana da informao deve atender para evitar a concretizao das
ameaas: Preveno, Deteco e Recuperao. O primeiro deles, a Preveno,
subdividi-se em trs tipos distintos, que so primeiramente a proteo de hardware,
normalmente chamada de segurana fsica, que impede acessos fsicos no
autorizados infra-estrutura da rede, prevenindo roubos de dados, desligamento de
equipamentos e demais danos quando se est fisicamente no local. O segundo, a
proteo de arquivos e dados proporcionada pela autenticao, controle de acesso e
sistemas antivrus, sendo que, no processo de autenticao verificada a identidade
do usurio, que disponibiliza apenas as transaes pertinentes ao mesmo e os
programas antivrus garantem a proteo do sistema contra programas maliciosos. E
o terceiro tipo de preveno, a proteo de permetro, que se encontra nas
ferramentas de firewall e routers que cuidam desse aspecto, mantendo a rede
protegida contra tentativas de intruso interna e externa rede.
O segundo aspecto, a deteco, que subdividi-se em dois tipos. O primeiro
so os alertas no qual os sistemas de deteco de intruses alertam os
responsveis pela segurana sobre qualquer sinal de invaso ou mudana suspeita
no comportamento da rede que possa significar um padro de ataque. Os avisos
podem ser via e-mail, mensagem no console de gerncia, celular, etc.. E o segundo
tipo que a auditoria que consiste em periodicamente analisar os componentes
crticos do sistema e procurar por mudanas suspeitas. Esse processo pode ser
realizado por ferramentas que procuram, por exemplo, modificaes no tamanho dos

23

arquivos de senhas, usurios inativos, etc. (NOBRE, 2007)


Finalmente o terceiro aspecto bsico em um sistema de segurana refere-se
a recuperao. Considera-se trs tipos de recuperao de dados. A cpia de
segurana dos dados (backup), que consiste em manter sempre atualizados e
testados os arquivos de segurana em mdia confivel e separados fsica e
logicamente dos servidores. O segundo tipo que so os aplicativos de backup, que
so ferramentas que proporcionam a recuperao rpida e confivel dos dados
atualizados em caso da perda das informaes originais do sistema. E o terceiro tipo
que a considerar que o backup do hardware, ou seja, a existncia de hardware
reserva, fornecimento autnomo de energia, linhas de dados redundantes, etc., que
podem ser justificados levando-se em conta o custo da indisponibilidade dos
sistemas. (NOBRE, 2007)

1.3 PRINCPIOS DE PREVENO E PROTEO

A anlise das possveis ameaas e riscos que a rede est submetida


definem as formas de proteo da informao. Isso objetiva de manter sua
confidencialidade, disponibilidade e integridade, e tambm para atender aos
objetivos de gesto traados pela alta direo. (NOBRE, 2007)
As informaes podem ser classificadas de acordo com o eventual
impacto gerado decorrente de acesso, divulgao ou conhecimento no
autorizado. Logo, a segurana de uma rede de computadores est
relacionada necessidade de proteo dessas informaes contra acessos
no autorizados ou contra a utilizao indevida dos recursos
computacionais, alm de preservar a integridade dos dados armazenados
contra a manipulao de qualquer natureza. (NOBRE, 2007,p.13)

Ainda de acordo com Nobre (2007) (apud SILVA E TORRES, 2003, p. 17), a
preservao da confidencialidade, integridade e disponibilidade da informao
utilizada nos sistemas de informao requer medidas de segurana, que por vezes
so tambm utilizadas como forma de garantir a autenticidade e o no repdio.
As medidas de segurana podem ser classificadas em duas grandes
categorias. Esta classificao se d em funo do modo como estas medidas
abordam as ameaas. So elas, preveno e proteo. A preveno o conjunto
das medidas que visam reduzir a possibilidade das ameaas concretizarem-se.
Essas medidas precisam ser implementadas antes da concretizao da ameaa, ou

24

seja, antes do incidente ocorrer. O efeito das medidas de preveno extingue-se


quando uma ameaa se transforma num ataque. (NOBRE, 2007)
As medidas de proteo tm como objetivo dotar os sistemas de informao
com ferramentas capazes de garantir a integridade da rede frente a um ataque,
bloqueando acessos indevidos e, at mesmo, respondendo instantaneamente s
tentativas de intruso. (NOBRE, 2007)

1.4 SISTEMAS DE DETECO DE INTRUSES


Por analogia, compara-se um IDS a um alarme contra ladres um alarme
contra ladres configurado para monitorar locais de acesso, atividades suspeitas e
invasores conhecidos. O modo mais simples de definir um IDS poderia ser
descrevendo-o como uma ferramenta especializada que sabe como ler e interpretar
o contedo dos arquivos de log de roteadores, firewalls, servidores e outros
dispositivos da rede onde atua. Alm disso, um IDS pode frequentemente armazenar
um banco de dados com assinaturas de ataques conhecidas e assim, pode
comparar padres de atividade, trfego ou comportamento que v nos logs
monitorados, com essas assinaturas, para reconhecer quando ocorre uma
correspondncia prxima entre uma assinatura e um comportamento corrente ou
recente. (CASWELL, 2003)
Pode-se dizer que um IDS est para uma rede assim como um pacote de
software antivrus est para os arquivos que entram em um sistema : ele inspeciona
o contedo do trfego da rede para procurar e desviar possveis ataques,
exatamente como um pacote de software antivrus inspeciona o contedo de
arquivos, anexos de e-mail, contedo de web recebidos, etc., para procurar
assinaturas de vrus (padres que correspondem a software danoso conhecido) ou
possveis aes maldosas (padres de comportamento que so no mnimo
suspeitos, se no completamente inaceitveis). (CASWELL, 2003)
Segundo Nobre (2007), os IDS so sistemas automticos que funcionam
como verdadeiros sniffers e, em tempo real, analisam o trfego na rede e detectam
tentativas no autorizadas de acesso infra-estrutura lgica. O grande objetivo
destes sistemas proporcionar uma reao efetiva aos ataques que um segmento
de rede possa vir a sofrer.
Desta forma, ainda de acordo com Nobre (2007), os IDS so frequentemente

25

considerados como uma das principais ferramentas defesa contra agressores,


tornando-se um componente essencial para um bom sistema de segurana em rede.
Eles atuam baseando-se nos tipos conhecidos de ataques e tambm verificando
alteraes de comportamento no trfego de dados. Sempre que detectada alguma
alterao no comportamento desse trfego ou identificado algum padro de ataque,
o sistema pode enviar um alerta aos administradores da rede, contra-atracar ou
simplesmente se defender baseado em alguma configurao predefinida.
Um IDS no utiliza medidas preventivas, age como um informante assim que
um ataque detectado. Firewalls e routes bem configurados podem evitar a maioria
dos ataques contra seus sistemas, porm, esta estrutura no tem visibilidade ao que
acontece do lado de fora de seu permetro. Alm disso, o firewall no pode proteger
o sistema de ataques realizados por meio de portas legtimas permitidas. Em
contrapartida, o IDS pode, alm de detectar ataques atravs das portas permitidas e
oriundas do exterior, como tambm tem visibilidade do que acontece no permetro
da sua rede interna. (NOBRE, 2007)

1.4.1 Tipos de IDS

Os IDSs podem ser divididos em baseados em redes, baseados em host e


distribudos. Os IDSs que monitoram backbones de rede e procuram assinaturas de
ataque so chamados Network-Based Intrusion Detection System (NIDS), enquanto
aqueles que operam em hosts defendem e monitoram os sistemas operacionais e
sistemas de arquivos contra sinais de invaso, so chamados Host-Based Intrusion
Detection System (HIDS). (CASWELL, 2003)

1.4.1.1 NIDS

Os NIDS so assim chamados porque monitoram o trfego da rede inteira.


Mais precisamente, monitora um segmento da rede. Normalmente, uma Network
Interface Card (NIC) de computador opera no modo no-promscuo. Nesse modo de
operao, apenas os pacotes destinados ao endereo Mdia Access Control (MAC)
especfico da NIC so encaminhados pilha para anlise. O NIDS deve operar no
modo promscuo para monitorar o trfego da rede no destinado ao seu prprio
endereo MAC. No modo promscuo, o HIDS pode captar todas as comunicaes do

26

segmento de rede. (CASWELL, 2003)

Figura 1.1 Posicionamento dos NIDS e abrangncia do segmento


Fonte : modificado pelo autor. Caswell, 2003, p.4.

Na Figura 1.1, observa-se uma rede usando trs IDSs. As unidades foram
colocadas em segmentos estratgicos da rede e podem monitorar o trfego de todos
os dispositivos que esto no segmento. Essa configurao representa uma topologia
de rede de segurana de permetro padro, onde as subredes selecionadas que
abrigam os servidores pblicos so protegidas pelo IDS.

1.4.1.2 HIDS

O HIDS difere do NIDS de duas maneiras. O HIDS protege apenas o


sistema host em que ele reside e sua placa de rede opera no modo no-promscuo.
Uma desvantagem do modo promscuo o de poder usar muito a CPU de uma
mquina, tornando-a lenta.(CASWELL, 2003)
Uma vantagem do HIDS a capacidade de personalizar o conjunto de
regras para uma necessidade especfica. Por exemplo, no h necessidade de
examinar mltiplas regras projetadas para detectar exploraes de Domain Name
System (DNS) em um host que no est executando servios de domnio.

27

Consequentemente, a reduo do nmero de regras pertinentes melhora o


desempenho e diminui a sobrecarga do processador. (CASWELL, 2003)

Figura 1.2 Posicionamento dos HIDS e abrangncia do host


Fonte : modificado pelo autor. Caswell, 2003, p.5.

1.4.1.3 Sistemas Hbridos


Segundo Nobre (2007), um sistema IDS hbrido une as vantagens dos dois
tipos, HIDS e NIDS, a fim de proporcionar uma melhor capacidade de deteco de
intruses. O IDS hbrido funciona como o NIDS coletando o trfego de pacotes da
rede, processando as informaes e detectando e respondendo a ataques do
mesmo modo como ocorre no HIDS.
Com relao ao gerenciamento, alguns sistemas podem ter uma
centralizao dos IDS, pois alguns sensores, baseados em rede, so localizados em
diversos segmentos de rede e outros IDS, baseados em host, so usados em
servidores. O gerenciador pode controlar as regras dos dois tipos, formando o IDS
hbrido. (NOBRE, 2007)
Ainda segundo Nobre (2007) (apud STREBE E PERKINS, 2002, p. 288)
sistemas IDS sempre requerem recursos da rede para funcionarem corretamente.

28

Sistemas NIDS usualmente funcionam em firewalls ou computadores dedicados;


isso normalmente no problema porque esses recursos so disponveis.
Entretanto, Sistemas HIDS destinados a proteger servidores podem ter srias
restries para funcionamento. No caso dos servidores da zona neutra, a
DeMilitarized Zone (DMZ) ou "zona desmilitarizada", o uso de IDS hbrido
vantajoso uma vez que ataques especficos a cada servidor podem ser identificados
com maior preciso.

1.5 DEFICINCIAS NOS IDS


Segundo Nobre (2007), outra questo potencialmente problemtica tem a
ver com o volume de dados gerado. Numa rede com elevados ndices de atividade,
os dados registrados pelos sensores podem atingir propores significativas, o que
implica dificuldades na capacidade de deteco e de gesto. Estes sistemas
requerem acompanhamento em tempo real como forma de validao das
ocorrncias registadas, e se considera-se ainda que existem registros dos
servidores, routers, firewalls, antivrus, etc., a carga administrativa associada pode
ser muito grande.
Uma deficincia da maioria dos sistemas de deteco de intruso o fato
do seu funcionamento se basear no mesmo princpio dos sistemas antivrus,
ou seja, utilizam bases de dados com assinaturas de ataques: se ataques
conhecidos so detectados, as tentativas so bloqueadas com relativa
facilidade, caso contrrio, podem passar impunemente. (NOBRE,
2007,p.15)

A instalao de um IDS deve ser cuidadosamente avaliada, j que seu custo


cresce proporcionalmente a capacidade de proteo desejada. No entanto, todo o
esforo dedicado ao planejamento de instalao de um IDS poupar tempo na
gesto da informao gerada. (NOBRE, 2007)
Ao lidar com os dados gerados, necessrio confirmar a sua aplicabilidade,
ou seja, verificar se no se trata de falsos positivos: um falso positivo a
identificao de uma atividade legtima como sendo um ataque. Os responsveis
pela segurana da rede devero analisar os dados obtidos e confirmar se so
ataques reais ou no. (NOBRE, 2007)
Os dados relativos atividade maliciosa registados pelo IDS podem
ocasionar vrias reaes: alertas administrativos (incluindo chamadas para

29

celulares) e reaes automticas (interrupo da conexo ou bloqueio do IP de


origem, por exemplo). (NOBRE, 2007)

1.6 METODOLOGIAS DE DETECO

De acordo com Lari e Amaral (2004), as formas de deteco so divididas


sob dois aspectos: aqueles que analisam as informaes baseadas em eventos
passados (conhecimento) e aqueles que analisam o estado corrente do sistema
(comportamento).

1.7 DETECO BASEADA EM CONHECIMENTO

Para Lari e Amaral (2004), os IDS so normalmente usados para auditar os


dados gerados em busca de anomalias conhecidas e report-las ao administrador.
Estes sistemas buscam por uma destas caractersticas: padres de ataque
conhecidos ou inconsistncias que no podem ser geradas por operao normal.
Alm disso, eles tentam reduzir o grande volume de dados para proporcionar
sumrios indicativos de novas tendncias.
Ainda segundo Lari e Amaral (2004), a grande vantagem desse tipo de
abordagem que, em teoria, produz pouco falso positivo. Ao possuir uma base de
dados com assinaturas de ataques j conhecidos, realizada uma checagem com o
evento capturado pelo sistema. A partir da so gerados alarmes que denunciam a
presena de aes potencialmente danosas ao bom funcionamento. (LARI E
AMARAL, 2004)
A necessidade de um conhecimento amplo do ambiente onde o IDS ser
instalado. Deve-se ter em mos, para a elaborao das assinaturas, os sistemas
operacionais aplicativos usados nos servidores e nas estaes de trabalho,
especificaes de hardware e a topologia de sua rede interna, informao esta de
grande valor, pois a quantidade de sensores a serem alocados na rede depende
diretamente da topologia da mesma. (LARI E AMARAL, 2004)
Neste tipo de deteco, reduzir os dados gerados o foco principal, visto
que, o objetivo eliminar informaes que so irrelevantes deteco, produzindo
assim, relatrios reduzidos para investigao futuras. (LARI E AMARAL, 2004)
Uma contnua atualizao das assinaturas uma tarefa que requer uma

30

anlise cuidadosa das vulnerabilidades que possam afetar o seu sistema como um
todo, pois se no houver alguma assinatura que no tenha utilidade para seu
ambiente, podemos elevar o nmero de falsos positivos. (LARI E AMARAL, 2004)

1.8 DETECO BASEADA EM COMPORTAMENTO

De acordo com Lari e Amaral (2004), a deteco baseada em


comportamento assume que um evento pode ser detectado observando um desvio
de comportamento esperado tanto dos sistemas como dos usurios. Este tipo de
abordagem possui dois desafios bsicos. O primeiro caracterizar o que vem a ser
comportamento normal e o segundo, detectar desvios de maneira correta. Estes
sistemas tendem a produzir muitos falsos positivos e resultados difceis de serem
interpretados. Os falsos positivos podem ser reduzidos, mas em contrapartida, podese elevar o nmero de falsos negativos.
Ainda de acordo com Lari e Amaral (2004), um ponto a ser destacado nesta
abordagem a possibilidade de detectar novos ataques e vulnerabilidades e de
possuir uma dependncia menor aos mecanismos do sistema operacional. A
desvantagem reside no fato de que ataques que usam aes legtimas podem obter
acesso ao sistema sem nos fornecer algum alarme.

1.9 POSICIONAMENTO DOS SENSORES

Para Nobre (2007), um dos problemas para a utilizao de IDS,


especificamente do NIDS, a limitao de desempenho causada pela segmentao
cada vez maior das redes pela utilizao de switches, j que os NIDS trabalham em
modo promscuo analisando todos os pacotes que passam pelo segmento da rede.
possvel utilizar o NIDS em redes segmentadas por switches usando sensores
HIDS em conjunto com o NIDS, nos IDS hbridos. Os sensores podem ser usados de
diversas formas, as quais iro refletir o grau de monitoramento do ambiente de rede.

1.9.1 Localizao do IDS na Rede

De acordo com Nobre 2007, o IDS pode ser utilizado em diversas posies
na rede e cada posio significa um tipo de proteo especfico. Outra considerao

31

importante quanto ao posicionamento do IDS em relao ao firewall da rede:

Posicionado antes do firewall, a deteco considerada simultnea

aos ataques (deteco de ataques);

Posicionado aps o firewall, a deteco passa a ser de intruses

(deteco de intruses) ou de erros cometidos pelos usurios internos (misuse).

Figura 1.3 - Localizao de IDS na rede


Fonte : Nobre, 2007, p.17

Na Fig. 1.3 observa-se os seguintes posicionamentos:


IDS 1 detecta tentativas de ataques externos, oferecendo uma fonte de
informaes sobre os tipos de ameaas de intruso para a rede corporativa;
IDS 2 funciona no prprio firewall, detectando tentativas de ataque contra
este;
IDS 3 detecta tentativas de ataque contra os servidores localizados na
DMZ 1, que conseguem passar pelo firewall;
IDS 4 detecta tentativas de ataque contra recursos internos da rede que
passaram pelo firewall e que podem ocorrer via VPN, por exemplo;

32

IDS 5 detecta tentativas de ataque contra os servidores localizados na


DMZ 2, que passaram pelo firewall, pela VPN ou por algum outro servio na DMZ 1;
IDS 6 detecta tentativas de ataques internos na rede corporativa.

1.10 SISTEMAS DE PREVENO DE INTRUSES

Segundo Nobre (2007), o funcionamento do IDS como sniffer apresenta


alguns problemas, como o fluxo de pacotes fragmentados, no confiveis e que
chegam fora de ordem. Os sistemas funcionam em modo passivo, apenas
escutando o trfego, no sendo capazes de controlar esse trfego, seja ignorando,
modificando, atrasando ou injetando pacotes para defender a rede.

Figura 1.4 - Funcionamento do IPS na rede


Fonte : Nobre, 2007, p.18

Ainda para Nobre (2007), a identificao desses pontos fracos, relacionados


a determinados tipos de IDS, levou ao desenvolvimento de novos sistemas que
buscam detectar e prevenir ataques contra a rede de comunicao. Operando de
forma inline na preveno de intruses, eles so conhecidos como Sistemas de
Preveno de Intruses Intrusion Prevention System (IPS).
A operao inline difere da operao passiva na forma de capturar os
pacotes dos segmentos de rede. Enquanto o IDS que opera no modo passivo
captura o trfego do segmento de rede, o IDS que opera no modo inline assume
uma posio como um firewall, onde todo o trfego da rede passa por ele, como o
que mostrado na Figura 1.4. Essa caracterstica permite que o IDS inline seja
capaz de detectar os ataques e, alm disso, tambm de preveni-los atravs de
bloqueio, pois os pacotes dos atacantes no chegam aos servidores da rede.
(NOBRE, 2007)

33

1.11 DETECO DE ANOMALIAS

Para Nobre (2007), uma anomalia definida como algo diferente, anormal,
peculiar ou que no seja facilmente classificado. No contexto de segurana de
computadores, uma anomalia pode ser definida como aes ou dados que no
sejam considerados normais por um determinado sistema, usurio ou rede.
Ainda para Nobre (2007), essa definio abrange ainda uma grande
variedade de itens e pode incluir tpicos como padres de trfego, atividades dos
usurios e comportamento de aplicativos. Acredita-se que pelo menos uma
significativa poro das ameaas ou condies que causem alarme deve manifestarse como anomalias, sendo assim detectveis. A maioria dos sistemas de deteco
de anomalias que se concentram em segurana normalmente se enquadra em trs
categorias gerais: comportamental, padro de trfego ou protocolo.

1.11.1 Anomalias em Padres de Comportamento


Segundo Nobre (2007), sistemas de deteco que procuram por anomalias
em padres de comportamento (normalmente o comportamento de usurios), so
normalmente de caractersticas, porm eles podem abranger tambm alguns
critrios de estatsticas, como os tipos de aplicativos e protocolos usados em vrias
horas do dia, a relao entre a origem e o destino das atividades da rede ou at
mesmo os tipos de anexos de e-mail que so enviados atravs de um sistema.
1.11.2 Anomalias em Padres de Trfego
De acordo com Nobre (2007), os sistemas de deteco que procuram por
anomalias em padres de trfego da rede, normalmente so de natureza estatstica,
apesar de inclurem algumas caractersticas como volume de trfego, mistura de
protocolos e vrias distribuies na origem e no destino.
Ainda de acordo com Nobre (2007), para ilustrar, pode-se considerar o
gerenciamento de uma rede ou sistemas simples de monitorao de negao de
servios, que possuem a vantagem de operar em um domnio muito maior e variado,
e que podem ser criados a partir de um nmero de bons modelos de estatsticas. A
desvantagem que esses sistemas freqentemente no so capazes de detectar a

34

maioria das anomalias qualitativas ou quantitativas sutis. Eles apresentam tambm


algumas dificuldades na definio de uma base confivel para o desempenho da
anlise de estatsticas.

1.11.3 Anomalias em Padres de Protocolos


Segundo Nobre (2007), os sistemas de deteco que procuram por
anomalias em padres de protocolos so normalmente sistemas de caractersticas.
Estes tendem a variar um pouco de acordo com a implementao, mas os mais
eficientes so freqentemente implementados como sistemas de modelo rgido.
Esse tipo de sistema tira proveito do fato de que os protocolos sozinhos so
geralmente muito restritos. Eles tendem a limitar muito a natureza e ordem das
transaes e so geralmente muito bem descritos por alguma implementao ou
documento de referncia.
Ainda de acordo com Nobre (2007), outra vantagem desse sistema que ele
pode detectar uma grande variedade de anomalias dentro do espao do protocolo,
podendo ser construdo com muita eficincia. A desvantagem, porm, que pode
ser difcil de estimar o efeito da anomalia observada de forma acurada, uma vez que
alguns tipos de transaes de protocolo problemticas (como ataques, por exemplo)
no se manifestam como anomalias.

1.12 TESTES DE INTRUSO


Os testes de intruso so tentativas de acesso aos sistemas da rede
corporativa por parte de pessoas autorizadas, que podem ser realizados sem
qualquer conhecimento prvio dos sistemas a testar, ou com a indicao das
respectivas caractersticas. Estes testes podem ser realizados tanto a partir do
interior da rede como a partir da Internet, dependendo a deciso sobre o ponto inicial
do teste, das caractersticas da organizao (nmero de sistemas, nmero de
funcionrios, tipo de aplicaes) e dos resultados que possam ser obtidos da
anlise. (NOBRE, 2007)
1.13 SEGURANA INTEGRADA
De acordo com Nobre (2007), esse mtodo combina vrias tecnologias de

35

segurana com compatibilidade de polticas, gerenciamento, servio e suporte, e


pesquisa avanada para uma proteo mais efetiva. Atravs da combinao de
vrias funes, a segurana integrada pode proteger a rede com mais eficincia
contra a variedade de ameaas e, em cada nvel, para minimizar os efeitos dos
ataques.
As tecnologias de segurana principais que podem ser integradas incluem:
Firewall - Controla todo o trfego de dados atravs da verificao das
informaes que entram e saem da rede a fim de garantir que no ocorram
acessos no autorizados;
Deteco de Intruso - Detecta o acesso no autorizado e fornece
diferentes alertas e relatrios que podem ser analisados para polticas e
planejamento da segurana;
Filtragem de Contedo - Identifica e elimina o trfego de pacotes no
desejado na rede;
Redes Privadas Virtuais (VPN) - Asseguram as conexes alm do
permetro da rede local, permitindo que redes locais se comuniquem com
segurana atravs da Internet;
Gerenciamento de Vulnerabilidade - Permite a avaliao da posio de
segurana da rede descobrindo falhas de segurana e sugerindo melhorias;
Proteo Antivrus - Protege contra vrus, worms, Cavalos de Tria e
outras pragas virtuais.
Ainda de acordo com Nobre 2007, Individualmente, essas tecnologias de
segurana podem ser incmodas para instalar e geralmente so difceis e caras de
gerenciar e atualizar. Entretanto, quando integradas em uma soluo nica, elas
oferecem uma proteo mais completa enquanto a complexidade e o custo de
operao e manuteno so reduzidos.

1.14 CONSIDERAES FINAIS

Este captulo mostra que o cuidado com a segurana de redes deve ser
observada com muito critrio. um assunto complexo que envolve inmeros
conceitos e a criao de polticas de segurana imprescindvel.
H a necessidade de se desenvolver uma viso ampla dos sistemas de

36

deteco de intruso, para uma melhor de configurao, considerando-se o


ambiente ao qual ele ser implementado.
O prximo captulo fala sobre o IDS de distribuio gratuita chamado Snort,
um dos sistemas de deteco de intruso mais utilizados para sistemas Linux.

37

2 SNORT
O objetivo deste captulo mostrar a estrutura do Snort. Sua origem, como
funciona seu mecanismo de deteco e a anlise dos pacotes, o pr-processador, e
o uso das regras do Snort que funcionam como assinaturas pr-registradas de
tentativas de invaso conhecidas.

2.1 DEFININDO O SNORT


De acordo com Caswell (2003), o Snort um sistema de deteco de
invaso de rede de cdigo-fonte aberto, capaz de realizar anlise de trfego em
tempo real, em redes Internet Protocol (IP). O Snort pode realizar analise de
protocolo, pesquisa/correspondncia de contedo, ou seja, capacidade de
inspecionar o payload do pacote, e ser usado para detectar uma variedade de
ataques.
Desde 1998, quando o Snort teve a primeira verso divulgada, percebemos
o preenchimento de uma lacuna nos mecanismos de segurana. (LARI e AMARAL,
2007, p.24)
Segundo Lari e Amaral (2007), o Snort fornece aos administradores de rede
informaes importantes na tomada de decises mediante atividades suspeitas que
ocorram na rede, pois o mesmo faz uma anlise detalhada do trfego em questo.
Uma caracterstica importante do Snort est na sua capacidade de inspecionar o
payload do pacote, ou seja, a rea onde encontra-se o contedo do pacote.

2.2 ARQUITETURA
De acordo com Lari e Amaral (2007), o Snort considerado um IDS leve,
ou seja, pode ser colocado em funcionamento com muito pouco esforo tanto no
sentido computacional quanto no sentido de configurao e suporte. Sendo assim,
seus recursos podem ser melhor aproveitados com a checagem de pacotes e no
com IDS em si. A base do Snort est montada sobre a biblioteca LibPcap que prov
funes de acesso a recursos de rede de baixo nvel, como monitoramento de
segurana.
Conforme Caswell (2003), existem trs modos principais nos quais os o

38

Snort pode ser configurado, sendo estes : farejador (sniffer), registrador de pacotes
(packet logging) e deteco de invaso. O modo farejador simplesmente l os
pacotes que trafegam na rede e os exibe continuamente no console. O modo
registrador de pacotes faz esta leitura do trfego e grava os pacotes em disco. J o
modo de deteco de invaso mais complexo, pois faz com que o Snort analise os
pacotes da rede procurando correspondncias em relao a um conjunto de regras
pr-definidas (assinaturas), executando diversas aes com base no que encontra.
Ainda conforme Caswell (2003), o Snort possui vrios componentes
importantes, a maioria deles exige plug-ins para personalizar sua implementao.
Esses componentes incluem pr-processadores e plug-ins de alerta, que permitem
ao Snort manipular um pacote para tornar o contedo mais administrvel pelo
mecanismo de deteco, e o sistema de alerta, que pode enviar sua sada atravs
de vrios mtodos. O Snort consiste em quatro componentes bsicos : farejador
(sniffer), pr-processador, mecanismo de deteco e sada.
Segundo Caswell (2003), em sua forma mais bsica, o Snort um farejador
de pacotes. Porm, ele projetado para processar os pacotes atravs do prprocessador e depois procurar uma correspondncia desses pacotes com uma srie
de regras (atravs do motor de deteco). Como ilustra a Figura 2.1.

Figura 2.1 - Arquitetura do Snort


Fonte : Caswell, 2003, p.26. Modificado pelo autor.

O farejador de pacotes um dispositivo (de hardware ou software) usado


para fazer escuta em redes. Ele funciona de maneira semelhante a uma escuta
telefnica, mas usado para redes de dados, em vez de redes de voz. (CASWELL,
2003)
Conforme Caswell, (2003), um farejador de rede permite que um dispositivo
de software ou hardware, escute o trfego da rede de dados. No caso da Internet,
isso normalmente consiste em trfego IP, mas pode ser outro tipo de trfego. Como

39

o trfego IP consiste em tipos diferentes de trfego de rede, como, Transmission


Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message
Protocol (ICMP), protocolos de roteamento, etc, muitos farejadores analisam os
vrios protocolos de rede para transformar os pacotes em algo legvel para seres
humanos.
Os farejadores de pacotes tem vrios usos: anlise, diagnstico e soluo
de problemas de rede, anlise e comparativo de desempenho e obter senhas em
texto puro e outros dados interessantes.

2.3 PRE-PROCESSADOR E MECANISMO DE DETECO


De acordo com Caswell (2003), o pr-processador captura os pacotes brutos
e os verifica em relao a certos plug-ins. Esses plug-ins conferem certo tipo de
comportamento do pacote. Uma vez determinado que o pacote tem um tipo em
particular de comportamento, ele ento enviado para o mecanismo de deteco,
como mostra a figura 2.2.

Figura 2.2 - Pr-processador do Snort (CASWELL, 2003)


Fonte : Caswell, 2003, p.28.

Ainda de acordo com Caswell (2003), o mecanismo de deteco ou motor de


deteco, a parte mais importante do IDS no Snort. Ele captura os dados
provenientes do pr-processador e seus plug-ins, e esses dados so comparados
com um conjunto de regras. Se h correspondncia dos dados do pacote com

40

alguma das regras, ento eles so enviados para o processo de registro/alerta. Os


conjuntos de regras so agrupados por categoria (cavalos de Tria, estouro de
buffer, acesso a vrios aplicativos) e so atualizados regularmente.
As regras consistem em duas partes:

O cabealho da regra: basicamente a ao de executar (log ou alerta),


o tipo de pacote de rede (TCP, UDP, ICMP etc.), endereos IP e portas
de origem e destino;

A opo da regra: o contedo do pacote que deve fazer com que ele
corresponda regra.

Segundo Lari e Amaral (2004), o Snort armazena suas regras (assinaturas)


de uma maneira bastante simples mas, ao mesmo tempo, poderosa. Consiste em
uma lista ligada bidimensional, com dois campos denominados Chain Headers e
Chain Options. Os atributos comuns s regras (endereos IP de origem e destino e
portas de origem e destino) so armazenados no Chain Headers. Todos os outros
atributos disponveis em uma regra ficam no Chain Options. Assim, ao avaliar um
pacote de acordo com uma de suas assinaturas, o Snort procura no campo Chain
Headers da lista as caractersticas bsicas da regra.
Ao encontrar a Chain correspondente a regra, o Snort procura os atributos
restantes no campo Chain Options. Esta estrutura acaba tomando um formato como
mostra a Figura 2.3.

Figura 2.3 Verificao de regras do Snort.


Fonte : Lari e Amaral, 2004, p.27.

41

Na curvatura de aprendizado do Snort, a mais ngreme refere-se a entender


o mecanismo de deteco e suas regras. O Snort tem uma sintaxe especfica que
ele usa com suas regras. A sintaxe da regra pode envolver o tipo de protocolo, o
contedo, o comprimento, o cabealho e vrios outros elementos, incluindo
caracteres de lixo para definir regras de estouro de buffer. A Figura 2.4 mostra o
funcionamento do mecanismo de deteco. (CASWELL, 2003)
Aps passarem mecanismo de deteco do Snort, os dados precisam ir para
algum lugar. Se estes dados tem correspondncia com alguma regra no mecanismo
de deteco, ento um alerta disparado. Os alertas podem ser enviados para um
arquivo de log, atravs de uma conexo de rede, atravs de sockets UNIX ou
Windows Popup (SMB), ou de interrupes Simple Network Management Protocol
(SNMP). Os alertas tambm podem ser armazenados em um banco de dados SQL,
como MySQL e Postgres. (CASWELL, 2003)

Figura 2.4 - Mecanismo de deteco do Snort.


Fonte : Caswell, 2003, p.29.

2.4 SISTEMA DE ALERTA E LOG

Conforme Lari e Amaral (2004), o sistema log do Snort selecionado em


tempo de execuo atravs de linhas de comando. As opes so : logar pacotes na
forma normal, codificada; logar no formato mais inteligvel ou logar no formato
TCPDump. A escolha da opo depende exclusivamente da performance desejada
dos sistemas. O formato do TCPDump o mais econmico nesse sentido, pois

42

condensa as informaes em poucos campos. Tambm possvel desligar os logs


completamente, melhorando ainda mais a performance.
Ainda conforme Lari e Amaral (2004), os alertas, por outro lado, podem ser
enviados para o syslog do UNIX, para arquivos texto em dois formatos diferentes ou
para mensagens WinPopup, usando o cliente Samba num sistema Windows.
Assim como o mecanismo de deteco e o pr-processador, o componente
de alerta usa plug-ins para enviar os alertas para banco de dados e atravs de
protocolos de interligao em rede, como traps SNMP e mensagens WinPopup. A
Figura 2.5 ilustra esse funcionamento. (CASWELL, 2003)

Figura 2.5 - Componente de alerta do Snort.


Fonte : Caswell, 2003, p.30.

2.5 FUNCIONAMENTO DO SNORT

Conforme Lari e Amaral (2004), para o Snort funcionar, necessrio instalar


a libpcap, pcap (packet capture), uma biblioteca para capturar pacotes na rede. O
Snort funciona de trs maneiras diferentes :
Sniffer : com placa de rede funcionando em modo promscuo, a mesma

43

captura pacotes e mostra os mesmos no formato que desejar. Abaixo esto alguns
comandos bsicos para funcionamento em modo sniffer. (LARI E AMARAL, 2004)
Para capturar os pacotes e imprimir os cabealhos do pacote TCP/IP :
./ snort -v
Se desejar analisar o cabealho IP e TCP/UDP/ICMP e os dados existentes
na camada de aplicao : (LARI E AMARAL, 2004)
./ snort -vd
Para mostrar os cabealhos IP e TCP/UDP/ICMP, os dados do pacote e o
cabealho da camada de enlace : (LARI E AMARAL, 2004)
./

snort -vde

Registrador de pacotes : grava os pacotes capturados no disco rgido. Os


comandos acima mostrados so bastante teis, mas se deseja registrar os pacotes
capturados necessrio especificar um diretrio, no caso /var/log/snort, ento
faramos : (LARI E AMARAL, 2004)
./ snort vde l /var/log/snort
Quando se usa o parametro l, o Snort no possui um critrio para
armazenar os registros em diretrios, usando o endereo IP do computador remoto
ou endereo IP de sua rede interna como nome de diretrio. Assumindo que a rede
interna possui o endereo IP 192.168.1.0-192.168.1.255, para organizar em
diretrios que tenham os endereos IP de computadores remotos como nomes dos
subdiretrios, acrescenta-se uma opo na linha de comando anterior : (LARI E
AMARAL, 2004)
./ snort vde l /var/log/snort h 192.168.1.0/24
Uma vez que os pacotes foram registrados em um arquivo binrio, pode-se
ler os pacotes com qualquer sniffer que aceite o formato binrio do tcpdump, como o
prprio tcpdump ou o ethereal. O Snort tambm pode ler os pacotes usando o
parmetro r, que o coloca na modalidade playback. Utiliza-se o seguinte comando :
(LARI E AMARAL, 2004)
./ snort dv r

/var/log/snort/<packet.log>

Deteco de intruso, isto , analisa o trfego de rede e compara com um


conjunto de regras pr-configuradas (assinaturas) e exibe alertas ou toma alguma
atitude caso haja correspondncia de entre o contedo dos pacotes e algumas
destas regras. Lari e Amaral (2004) afirmam que para habilitar o Snort no modo de
deteco de intruso, mostrando pacotes no console, usamos o parmetro que

44

indica o arquivo snort.conf, onde esto localizadas as regras, como mostra o


comando :
./ snort vde c /etc/snort/snort.conf

2.5.1 Filtros e criao de assinaturas

Segundo Lari e Amaral 2004, uma vez instalado, o IDS dever fornecer
somente o trfego que interessa, deixando de lado o trfego da rede que
considerado normal. Para ajudar nesta tarefa, ser preciso avisar aos sensores o
que filtrar. A assinatura define ou descreve um trfego de rede nos moldes do que
interessa, e a tarefa do responsvel aprender a observ-la e entend-la. O filtro
transcreve a descrio da assinatura para um cdigo que possvel ser lido pelo
computador no qual est instalado o IDS.

2.5.1.1 Polticas de filtragem

Conforme Lari e Amaral (2004), muitos ataques so impedidos de terem


xito devido poltica de segurana implementada no firewall. A poltica do firewall
ou de filtragem do roteador governada por duas escolhas : negar tudo (deny
everything) ou permitir tudo (allow everything). A poltica de filtragem de pacotes do
firewall ou do roteador o melhor companheiro do IDS.

2.5.1.1.1 Deny Everything (Negar tudo)


De acordo com Lari e Amaral (2004), negar tudo implica em muito mais
que polticas de segurana. Esta regra nega o que no for especificamente
permitido, isto , o sensor dever possuir uma regra para cada trfego que deseja
permitir sua entrada no permetro de defesa. Se o trfego no conseguir achar uma
regra para esta situao, ter o pacote descartado. Esta regra facilita muito o
desempenho do IDS, pois s configurar uma regra para violao das polticas do
firewall. Este um ponto importante, pois a poltica de negar tudo pode deixar a
sua estao sem comunicao com as outras estaes, o que pode-se caracterizar
como um famoso ataque Denial of Service (DoS), feito pelo administrador do prprio
sistema, sem a necessidade de incurses de hackers, script-kiddies ou outras

45

atividades maliciosas.

2.5.1.1.2 Allow Everything (permitir tudo)


Ainda de acordo com Lari e Amaral (2004), permitir tudo no
especificamente negado uma poltica de firewall de alto risco, mas pode ser
necessrio em situaes em que a liberdade e flexibilidade so valores que esto
acima da segurana, como em laboratrio de pesquisa ou em instituies
educacionais. Esta abordagem faz com que a implementao e sua posterior
customizao seja trabalhosa, pois o IDS ficar encarregado de alarmar somente os
eventos que violaram as polticas implementadas. Com esta poltica fica muito difcil
detectar eventos maliciosos que podem causar danos ao ambiente da rede. Este
princpio fere a teoria do IDS manter relao com as polticas de filtragem do
roteador e do firewall.

2.5.2 Assinaturas

Conforme Lari e Amaral (2004), uma das premissas no assunto que envolve
a segurana de redes a segurana integrada. Um firewall com suas polticas
implementadas deve sempre estar relacionado com IDS e assim fornecer uma
soluo nica para o permetro de defesa da rede. Infelizmente, os analistas evitam
agregar as polticas de filtragem do firewall e apenas incorporam os filtros de
ataques j bem conhecidos pela comunidade. Este fato acontece decorrente de trs
situaes :

O analista no tem conhecimento slido de TCP/IP;

As equipes de firewall e deteco de intruso no se comunicam e no

compartilham informaes;

O analista no possui tempo para otimizar a soluo de segurana que

possui, um caso tpico de pequenas empresas em que o analista responsvel


por tudo em seu ambiente (bancos de dados, proxy, IDS, firewall, correio eletrnico
e aplicativos pertinentes ao ambiente).
Com o resultado deste desencontro de informaes, poderemos ter um IDS
sobrecarregado, com o desempenho afetado pela grande quantidade de
informaes que o mesmo dever checar. (LARI E AMARAL, 2004)

46

2.5.2.1 Composio das assinaturas


As assinaturas do Snort so divididas em duas partes lgicas; o cabealho e
opes. O cabealho contm a ao da assinatura, protocolo, endereos IP de
origem e de destino e sub-mscara de rede, informaes sobre portas de destino e
origem. A parte de opes contm mensagens de alertas e informaes sobre que
parte do pacote dever ser examinada para determinar que ao dever ser tomada
mediante o evento ocorrido. (LARI E AMARAL, 2004)

2.5.2.2 Aes
O cabealho contm informaes sobre quem, onde e o que de um pacote,
como tambm o que deve ser feito em caso de algum pacote se confrontar
positivamente com uma das regras do Snort. (LARI E AMARAL, 2004)
Existem 5 aes a serem tomadas : alert, log, pass, activate e dynamic.

Alert : gera um alerta usando o mtodo selecionado e depois grava o


pacote.

Log : registra o pacote.

Pass : ignora o pacote.

Activate : alerta e ativa uma outra regra dinmica.

Dynamic : permanece ocupado at ser ativado por uma regra ativa e


depois age como uma regra para registro.

Para ilustrar, o exemplo a seguir criar um tipo de regra que registrar os


eventos no syslog (utilitrio do UNIX) e no bando de dados MySQL. (LARI E
AMARAL, 2004)
ruletype redalert { Type alert output
Alert_systlog : LOG_AUTH LOG_ALERT output database: log,
mysql, user=snort
dbname=snort host= localhost }

2.5.2.3 Protocolos
Neste campo da assinatura est o protocolo. O Snort, um excelente sistema
de deteco de intruso capaz de analisar vrios protocolos com trfego suspeito

47

com : TCP, UDP, ICMP e IP. Atualizou o tratamento dos protocolos HTTP e DCE /
RPC , SIP, POP e IMAP3. Atualizaes para o pr-processamento de HTTP e DCE /
RPC agora permitem o Snort remontar as solicitaes e respostas, mesmo quando
distribudos por pacotes de muitos, e de forma inteligente limpar os resultados.
O Snort realiza a anlise em tempo real sobre o trfego de rede IP para detectar
tentativas de sonda ou atacar a rede usando um conjunto de regras definidas pelo
usurio que caracteriza esses ataques.
O pr-processador SIP melhorado pode identificar os canais de chamada e
detectar anomalias em comunicaes SIP. Os pr-processadores POP3 e IMAP so
capazes de decodificar anexos de email em Base64 e uuencoded e o prprocessador SMTP agora capaz de lidar com os dois ltimos formatos. Um prprocessador de reputao experimental IP permite o Snort criar lista uma negra ou
lista branca pacotes com base no endereo IP.
Outras melhorias incluem suporte para leitura de arquivos grandes e registro
pcap URLs HTTP, nomes de arquivos anexos e os destinatrios de e-mail ao gerar
eventos. H tambm atualizao das regras e opes, melhor portabilidade para
desenvolvedores e documentao melhorada.
Apesar de poder decodificar outros tipos de protocolos, o Snort focado na
pilha de protocolos TCP/IP. Usando a pilha de protocolos TCP/IP, a Figura 2.6 ilustra
o nvel de atuao dos componentes do Snort. (LARI E AMARAL, 2004)

Figura 2.6 Camadas TCP/IP.


Fonte : Caswell, 2003, p.73.

48

As camadas do TCP/IP :

Camada de aplicao (5) Por exemplo, protocolo HiperText Transfer


Protocol (HTTP), Simple Mail Transfer Protocol (SMTP);

Camada de transporte (4) Por exemplo, protocolo TCP e UDP;

Camada de rede (3) Por exemplo, protocolo IP e ICMP;

Camada de enlace (2) Por exemplo, protocolo Ethernet, Token Ring;

Camada fsica (1) Por exemplo, placa de rede, cabos, conectores.

2.5.2.4 Endereos IP
De acordo com Lari e Amaral (2004), no neste campo do cabealho da regra
esto os endereos IP e as portas de conexo. A palavra any pode ser usada para
definir qualquer endereo. Os endereos so representados da seguinte forma : o
nmero IP seguido do CIDR (Classless Inter-Domain Routing). O bloco CIDR de
mscara /24 indica uma rede classe C, /16 uma rede classe B e /32 especifica um
endereo exato de uma mquina. Por exemplo, uma combinao mostra a
configurao 192.168.1.0/24 e teria como alvo todas as estaes com endereos de
192.168.1.1 a 192.168.1.255. No exemplo a seguir, descrita uma regra que alerta
qualquer conexo originada de sua rede interna em direo a seus endereos
privativos.
Alert tcp ![192.168.1.0/24,10.1.1.0/24] any->
[192.168.1.0/24,10.1.1.0/24] 111 (contente: |00 01 86 a5|;
msg: Acesso externo ;)

2.5.2.5 Nmero de portas


O nmero de porta pode ser especificado de vrias maneiras, incluindo
any, portas estticas, uma faixa de nmeros e pela negao. (LARI E AMARAL,
2004)
Exemplo : log udp any any -> 192.168.1.0/24 1:1024 log udp
Trfego vindo de qualquer porta e com destino de portas variando de 1 a
1024.

49

2.5.2.6 Operador de direo

Segundo Lari e Amaral (2004), o operador de direo indica que sentido o


pacote ir percorrer e assim a regra ir atuar de forma a tomar a medida correta. O
endereo IP e nmero da porta que ficam no lado esquerdo indicam a origem da
conexo, e o endereo IP e nmero da porta que ficam no lado direito indicam o
destino da conexo.
Exemplo : log tcp any any -> 192.168.1.0/24 23

Esta regra registra todos os pacotes que tenham origem em qualquer


endereo IP e qualquer porta, e como destino, a faixa de endereos de 192.168.1.1
a 192.168.1.255 na porta 23. (LARI E AMARAL, 2004)

2.5.2.7 Opes de regra

De acordo com Lari e Amaral (2004), as opes que as regras do Snort


possue so o ponto chave do detector de intruso, combinando flexibilidade e
facilidade de uso. Todas as opes so separadas por ponto-e-vrgula (;). Seguem
algumas palavras-chaves disponveis :
msg : imprime uma mensagem em alerta e registra o pacote
logto : registra o pacote em um arquivo especfico no lugar de um arquivo
padro.
ttl : testa o valor do campo TTL do cabealho IP
tos : testa o valor do campo TOS do cabealho IP
id : testa o campo de identidade da fragmentao do cabealho IP
ipoption : observa os campos de opes do IP
dsize : testa o tamanho do payload do pacote contra um valor fornecido
flags : testa os flags do TCP
content : procura por um molde no contedo do pacote
depth : configura um tamanho mximo no qual a procura dever ser feita
resp : ativa uma resposta para um dado comportamento do pacote
reference : referncia para ataques externos
sid : identidade da regra so Snort

50

rev : nmero da reviso da regra


classtype : identificador da classificao
priority : identificador do grau de impacto da regra
ip_proto : valor do protocolo no cabealho do IP
sameip : determina se o endereo IP de origem igual ao endereo de
destino
window : testa o tamanho do pacote TCP para um valor especificado
react : ativa uma resposta. Ex. bloquear algum site
seq : testa o nmero de sequence do TCP contra um valor fornecido
ack : testa o nmero de acknowledgement do TCP contra um valor
fornecido.

2.6 CONSIDERAES FINAIS

Este captulo objetivou mostrar o Snort na sua forma conceitual, assim


como, a maneira como funcionam os aspectos de anlise, deteco, alerta e
possvel conteno.

51

3 FORMAS DE ATAQUES E INVASES

O objetivo deste captulo apresentar de forma sucinta as principais formas


de ataques e invases e as respectivas vulnerabilidades que estas exploram. Dentre
estas o Denial of Service (DoS) ou ataque de negao de servio, que o tipo de
ataque usado neste trabalho visando construir conhecimento sobre este tipo de
vulnerabilidade.

3.1 A RAZO DE SER INVADIDO

De acordo com Santos (2005), qualquer cdigo ou programa passvel de


erros, pois, so projetados e escritos por seres humanos, estando ento, sujeitos a
falhas. Vulnerabilidades no se localizam somente nos cdigos fonte dos
programas, mas tambm, em sistemas mal configurados. Configuraes padres e
sistemas desatualizados tambm geram muitas vulnerabilidades. Alm disso, a falta
de uma poltica de segurana tambm falha grave no segmento de tecnologia da
informao.
Ainda de acordo com Santos (2005), sistemas podem apresentar erros, e os
mais graves so aqueles ligados a servios de redes. Uma observao importante a
ser feita em relao a segurana em sistemas de computador que, deve-se manter
em execuo somente os servios necessrios, pois, quanto menos servios ativos,
menor sero os problemas de segurana.
Conforme Santos (2005), sistemas operacionais so passveis de falhas e
no h um que seja totalmente seguro. Cabe ao administrador consciente, implantar
um sistema dentro dos padres de segurana, usando para isso ferramentas
disponibilizadas para este fim.
Assim sendo, para minimizar os incidentes de segurana, existem algumas
recomendaes bsicas :

Manter atualizados o sistema operacional e os aplicativos utilizados,


principalmente os servios de rede disponveis, fundamentalmente
atualizaes pertinentes ao aspecto de segurana;

Executar somente servios necessrios, desabilitando os desnecessrios

52

e removendo-os da instalao se possvel;

Usar senha com poderes administrativos somente quando a tarefa a ser


executada exija tal privilgio;

Prover segurana fsica tambm importante. Somente pessoas


autorizadas devem ter acesso a servidores;

Fazer uso de ferramentas de segurana. Em um servidor invadido,


grande o estrago causado (tempo sem o servio, perda de dados,
imagem afetada, etc). importante coletar dados para uma posterior
auditoria e deve-se reinstalar o servidor.

3.2 PROBING

Probing no uma tcnica propriamente dita, mas uma forma de obter


informaes sobre a rede ou sistema. As informaes obtidas podem servir de base
para uma possvel invaso, com isso, pode-se utiliza-lo para descobrir quais servios
esto disponveis na rede. As tcnicas de realizao de probing podem ser
facilmente detectadas ou impedidas atravs de implementaes eficientes no
mecanismo de segurana na rede. (SANTOS, 2005)

3.3 TROJAN HORSES

So programas de computadores que realizam determinadas tarefas sem


que seus usurios saibam, e que, normalmente afetam a segurana do sistema.
Estas tarefas obscuras vo desde permitir que terceiros acompanhem ou tomem
conhecimento do que se digita no teclado, como dados de acesso (senhas e logins),
at abrir portas de acesso, gerando oportunidade para uma possvel invaso.
(SANTOS, 2005)

3.4 BACKDOORS

Normalmente um invasor procura garantir uma forma de retornar a um


computador invadido, sem precisar utilizar-se dos mtodos empregados na
realizao da invaso. Na maioria dos casos, o invasor quer retornar ao computador
invadido sem ser notado. Este ento, instala um programa no computador que

53

permitir acesso a qualquer momento. (SANTOS, 2005)


O nome dado ao programa que abre esta porta para futuros acessos
backdoor. O backdoor permitir acesso ao sistema mesmo que a falha que originou
o primeiro acesso seja corrigida, isso claro se o backdoor no for removido. Um
backdoor pode ser escrito na forma de programa, script, ou at como uma srie de
procedimentos (criao de uma conta com acesso de administrador, etc), entre
outras maneiras. (SANTOS, 2005)

3.3 BUFFER OVERFLOW

O buffer overflow resultado do estouro de capacidade de armazenamento


de um buffer. As ameaas deste tipo so consideradas crticas e bastante srias e,
apesar de muito conhecidas, originam-se exclusivamente na falta de conhecimento
do programador no desenvolvimento seguro de um software. Vulnerabilidade que
vem sendo amplamente utilizada para invases remotas de computadores, onde o
invasor consegue comprometer a estabilidade do sistema. Tecnicamente buffer
overflow um problema com a lgica interna do programa, mas a explorao dessa
falha pode levar a srios prejuzos. (SANTOS, 2005)
O objetivo da explorao contra um programa vulnervel a buffer overflow
conseguir que o invasor controle o programa atacado, e se este possuir privilgios
suficientes, controlar a mquina (nvel de administrador). (SANTOS, 2005)

3.4 PASSWORD CRACKERS

Password Crackers so programas desenvolvidos para quebrar senhas de


usurios ou de programas. Este tipo de programa pode ser tanto usado para auxiliar
o administrador descobrir senhas fracas existentes no sistema, bem como ser
usado por um invasor para descobrir senhas de usurios, e us-las sem que o
proprietrio perceba. Em geral, Password Crackers tentam descobrir a senha do
usurio atravs de um processo de fora bruta. Comumente lentos, a eficincia dos
password crackers depende inteiramente da qualidade das senhas. (SANTOS,
2005)

54

3.5 SPOOFING

A tcnica de spoofing consiste na falsificao do remetente da mensagem


de um pacote de transmisso de dados, para que o receptor o trate com se fosse de
um outro utilizador. A tcnica de spoofing tambm utilizada por invasores para
dificultar a descoberta da origem da invaso, uma vez que, as informaes de
origem dos pacotes so forjadas. (SANTOS, 2005)
Os principais e mais utilizados tipos de spoofing so : IP Spoofing, ARP
Spoofing e DNS Spoofing. Como a tcnica de spoofing constitui a falsificao de
alguma informao, o IP Spoofing falsifica o IP, fingindo ser outro diferente do
original. A tcnica de ARP Spoofing consiste na falsificao do MAC address,
redirecionando o trfego para o impostor. No DNS Spoofing, o invasor compromete
o servidor DNS e explicitamente altera as tabelas de endereo de IP hostname,
direcionando uma consulta DNS para outro servidor que no seja o proprietrio do
nome. (SANTOS, 2005)

3.6 ATAQUES DE NEGAO DE SERVIO DoS

De acordo com Santos (2005), os ataques conhecidos

como DoS so

caracterizados por uma tentativa explcita do atacante de impossibilitar que um


usurio legtimo utilize determinado servio. Ataques do tipo DoS geralmente no
comprometem a privacidade dos dados. A finalidade deste tipo de ataque tirar um
servio, servidor, computador ou at mesmo uma rede do ar. Ataques do tipo DoS
muitas vezes so utilizados para atrapalhar ou desacreditar um servio.
Ainda de acordo com Santos (2005), qualquer maneira de tirar um
computador, servio ou rede do ar pode ser considerado um ataque DoS. Como
exemplo, pode-se citar um ataque com o intuito de gerar milhares de logs at encher
o disco ou partio. Se o administrador colocar logs na mesma partio do sistema,
tal ataque gerar um problema pois todo espao do disco ser ocupado.
Segundo Arajo e Assumpo (2010), ataques DoS podem ser podem ser
realizados localmente ou remotamente, a saber :

Localmente : ataques realizados quando o atacante tem acesso ao


sistema. Esse acesso pode ser de forma fsica comprometendo a

55

integridade do hardware ou de forma computacional exaurindo os


recursos de processamento e memria da mquina.

Remotamente : ataques que inviabilizam o sistema a distncia atravs de


falhas dos servios de rede sem necessariamente possuir uma conexo
com o alvo.

Ainda segundo Arajo e Assumpo (2010), ataques DoS so realizados


atravs de inmeras formas. Ataques locais podem ser realizados atravs de um
buffer overflow ou simplesmente desligando a fonte de alimentao do alvo. Todo
ataque local exige que o atacante tenha acesso direto ao alvo, diferentemente dos
ataques remotos onde a distncia do alvo exige do atacante o uso de slidos
conhecimentos do conjunto de protocolos TCP/IP.

3.6.1 Pings e ICMP

O ICMP um protocolo que pertence ao conjunto de protocolos TCP/IP,


atuando na camada 3, sua funo verificar e diagnosticar problemas de rede. Sua
arquitetura apresentada na Figura 3.1.

Bit 0-7

Bit 8-15

Verso / DIH

Tipo de servio

Identificao
Cabealho IP

Time To Live -TTL

(160 bits ou 20 Bytes)

Bit 16-23

Comprimento
Bandeiras e offset

Protocolo

Checksum

Endereo IP de origem
Endereo IP de destino
Tipo de mensagem

Cdigo

ICMP Payload

Extinguir

(64+8+ bits ou bytes)

Data (opcional)

Figura 3.1 Layout do pacote ICMP


Fonte : Santos, 2005, p.24

Bit 24-31

Checksum

56

Segundo Arajo e Assumpo (2010), os pacotes ICMP trafegam sobre a


forma de datagramas como os outros pacotes, e estes tambm esto sujeitos a
erros. Alm do cabealho IP o pacote ICMP contm um cabealho ICMP onde
especificado o tipo de mensagem, o cdigo de retorno que identifica a resposta ao
remetente indicando a situao encontrada. A tabela 3.1 mostra os tipos de
mensagens ICMP.
Tabela 3.1 Tipos de mensagens ICMP
Cdigo do tipo

Mensagem ICMP

Resposta de echo (resposta ping)

Destino impossvel de alcanar

Extino de origem

Redirecionamento

Eco (solicitao ping)

11

Tempo de vida excedido

12

Problema de parmetro

13

Solicitao de estampa de tempo

14

Retorno de estampa de tempo

17

Solicitao de mscara de endereo

18

Retorno de mscara de endereo

Fonte : Hatch et al, 2002, p.162

3.6.2 Echo request e echo reply

De acordo com Arajo e Assumpo (2010), quando utiliza-se o comando


ping para verificar conectividade entre hosts dentro de uma rede, envia-se uma
mensagem de requisio denominada echo request. Como resposta a requisio
retornada uma mensagem de confirmao chamada de echo reply. Esta mensagem
retorna se houve resposta por parte do host que recebeu a requisio, caso no
houver resposta, este informa o possvel motivo da no alcanabilidade (destination
unreacheable). A Tabela 3.2 mostra os possveis sub-tipos de respostas.

3.6.3 Transformando um ping em arma

Segundo Arajo e Assumpo (2010), com envio de pacotes ICMP atravs

57

do ping, pode-se obter respostas sobre a conectividade de um host em uma rede,


porm o uso indevido dessas requisies pode gerar gargalos na comunicao e
consumo de recursos computacionais. A partir disso possvel levar servidores ao
travamento (negao de servio). Se um atacante enviar pings de tamanhos
invlidos, pode obstruir o canal de comunicao ou, se conseguir gerar inmeras
requisies a um servidor forando este a tentar responder a todas, pode inviabilizar
os servios deste.
Tabela 3.2 Destination unreachable : possveis sub-tipos de resposta ICMP
Code

Escription

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Network Unreachable error


Host Unreachable error
Protocol Unreachable error (the designated transpor is not supported)
Port Unreachable error (the designated protocol is unable to inform the host of the
Source
route
failed error
incoming
message)
Destination network unknown error
Destination host unknown error
Source host isolated error (military use only)
The destination network is administratively prohibited
The destination host is administratively prohibited
The network is unreachable for type of servisse
The host is unreachable for type of servisse
Communication administratively prohibited (administrative filtering prevents packet
Host
precedence
violation (indicates the requested precedence is not permitted for
from being
forwarded)
Precedence
cutoff
in effect
(precedence
of datagram is below the level set by the
the combination
of host
or network
and port)

Fonte : Santos, 2005, p.26

network administrators)

3.6.4 Formas de ataques DoS

De acordo com Arajo e Assumpo (2010), ataques DoS ocorrem a partir


de inmeras formas. A seguir as formas de ataques mais conhecidas e aplicadas:
Ping of Death : uma das primeiras formas de ataque DoS, consiste no envio
de pacotes com tamanhos que ultrapassam os 65536 bytes (o tamanho mximo
permitido a um pacote). As redes atuais no so mais vulnerveis a esse tipo de
ataque.
SYN flood : ataque baseado no estabelecimento de conexo do protocolo
TCP, este chamado de Tree-Way Handshake, onde o cliente solicita a conexo
atravs de um SYN e o servidor confirma a conexo mandando um SYN-ACK de

58

volta ao cliente, contudo este no envia o ACK para confirmar a conexo fazendo o
servidor esperar um tempo limite (time-out), gerando assim um congestionamento na
rede j que o ACK ausente na comunicao ocupa recursos do servidor (memria e
processamento) e limita o uso de conexes ativas que um software pode realizar
podendo limitar suas funcionalidades ou at trav-lo caso o nmero de conexes
limites seja atingido.

Figura 3.2 Conexo normal cliente-servidor


Fonte : Elaborado pelo autor, 2013

Em uma conexo com SYN flood o atacante envia diversas vezes pacotes
maliciosos com SYN e recebe respostas vlidas, porm, no confirmando a
conexo, deixando de enviar o ACK. O servidor sobrecarregado e novas conexes
no so realizadas com sucesso.

Figura 3.3 Conexo com SYN Flood


Fonte : Elaborado pelo autor, 2013

59

Smurf : tcnica conhecida como reflexo consiste na utilizao de


servidores de difuso (broadcast) para enviar requisies a todas as mquinas da
rede. Assim o atacante envia uma solicitao a servidores broadcast com um IP
falso fornecendo um endereo alvo fazendo com que todas as mquinas da rede
reenviem uma resposta ao servidor de broadcast que repassa ao alvo
congestionando assim toda solicitao ao mesmo.
UDP flood : tcnica que utiliza o protocolo UDP para enviar requisies a um
alvo. Diferentemente do SYN flood, esta tcnica dispara requisies a todas as
portas do alvo que por sua vez ir tentar identificar a qual processo essas
requisies pertencem. Assim aps a identificao o alvo tentar enviar uma
mensagem ICMP ao destinatrio que encontrou o destino da requisio enquanto
continua sendo inundado com novas requisies at entrar em colapso.

Nmero da porta de origem

Nmero da porta de destino

(16 bits)

(16 bits)

Tamanho

Soma de verificao

(16 bits)

(16 bits)

Dados
Figura 3.4 Cabealho UDP
Fonte : Hatch et al, 2002, p.161

De acordo com Hatch et al (2002), como no TCP, o UDP usa endereo IP


para enviar as informaes ao sistema correto. O UDP usa nmeros de porta para
enviar os dados ao processo correto no sistema de destino. J que o cabealho
UDP no verificado pelo sistema remetente, a porta de origem pode ser qualquer
porta que um intruso quiser que seja. J que nenhuma verificao de conexo
exigida para UDP, muito fcil forjar tanto o endereo IP de origem quanto o
nmero da porta UDP de origem.

3.7 DDoS
De acordo com Arajo e Assumpo (2010), o Distribuited Denial of Service
(DDoS) um ataque DoS amplificado. O atacante ao invs de usar uma nica
mquina para enviar um ataque, ele usa uma rede que pode conter at milhares de

60

mquinas para intensificar o seu ataque.


Segundo Jordo (2011), o ataque DDoS atinge sua meta excedendo os
limites do servidor. Para tal, os responsveis pelo ataque criam programas
maliciosos que so instalados em diversas mquinas, as quais realizaro mltiplos
acessos simultneos ao site em questo.

Figura 3.5 Servidores so limitados tambm no envio e recebimento de dados


Fonte : Elaborado pelo autor, 2013

Ainda segundo Jordo (2011), como os servidores possuem limitaes com


relao ao nmero de acessos em um mesmo instante, acaba ocorrendo que o
servidor no consegue atender as requisies e retirado do ar. Um ataque DDoS
pode simplesmente reiniciar os servidores ou pode causar o travamento do sistema
que opera por trs do site.
Para aumentar a eficcia do ataque, um DDoS muitas vezes conta com a
ajuda de mquinas zumbis, que integram uma rede zumbi. Computadores desse tipo
foram infectados por pragas que tornam o acesso Internet extremamente lento,
isso porque eles esto sob o comando de outra mquina, tambm conhecido como
computador-mestre. (JORDO, 2011)
E justamente por contar com uma legio de mquinas atacando que o
DDoS tm grande eficincia. Por se tratar de milhares de computadores realizando o
ataque, fica muito mas difcil combat-lo, porque os responsveis pela segurana do
servidor no conseguem estabelecer regras para impedir todos os acessos que

61

esto causando danos. (JORDO, 2011)


Para tentar combater um ataque DDoS, os profissionais que trabalham
contra o ataque precisam efetuar configuraes nos equipamentos que levam at o
site desejado. Em geral, so utilizados filtros que vo determinar quais IPs podem
acessar o site e quais so perigosos para o servidor. (JORDO, 2011)

Figura 3.6 Site Akamai, exibe a ocorrncia de ataques DDoS em tempo real.
Fonte : Akamai, 2013

Outra soluo recorrer a empresas especializadas, como o Akamai, que


utilizam diversos computadores para conter o ataque. Essa tcnica efetiva porque
as mquinas esto em diferentes locais do planeta e combatem os zumbis dividindo
a tarefa, de modo que cada computador de defesa combata um nmero reduzido de
mquinas. (JORDO, 2011)

3.8 CONSIDERAES FINAIS

Este captulo teve como objetivo mostrar como funcionam os principais tipos
de ataques e invases e, mais especificamente o DDoS, e como este age na
tentativa de sobrecarregar servidores visando a retirada do ar dos servios destes.

62

4 TESTES E RESULTADOS
Neste captulo mostrara-se como foi elaborada a aplicao dos testes, as
ferramentas utilizadas para executar as simulaes e coleta de dados, mostrar o
ambiente criado para os testes, bem como os resultados esperados.

4.1 METODOLOGIA

Nesta pesquisa, sero considerados basicamente dois fatores como objeto


de estudo e cada fator poder assumir valores em duas situaes conforme o injetor
de pacotes usado nos testes.
Tabela 4.1 Funo das mquinas utilizadas na simulao
Fatores

Tempo de Ataque
BoNeSi

T50

Deteco de Intruso - Gerando Alertas

30 min.

30 min.

Deteco de Intruso - Gerando Alertas e Bloqueios

30 min.

30 min.

Fonte : Elaborado pelo autor, 2013

A carga de trabalho gerada para a realizao dos testes aplicada a partir


de ferramentas que possibilitam realizar Stress Testing em rede locais. So eles, os
injetores de pacotes BoNeSi e o injetor T50, que permitem realizar uma simulao
de

ataque

DDoS

como

se fossem mquinas zumbis

simultaneamente, como ilustra a Figura 4.1.

Figura 4.1 Ataque DDoS.


Fonte : Elaborado pelo autor, 2013

realizando

ataque

63

O principal propsito de um ataque DDoS inviabilizar um servio, ou seja,


tirar determinado servio do ar, porm, o objetivo dos testes aqui aplicados de
avaliar o impacto da conteno realizada pelo IDS em conjunto com o firewall.

4.2 FERRAMENTAS UTILIZADAS

Algumas ferramentas foram usadas para adicionar funcionalidades ao Snort


ou trabalhar em conjunto com ele. Algumas bibliotecas tambm so mencionadas
por serem necessrias ao funcionamento de uma ou mais ferramentas.
Todas as ferramentas que foram utilizadas na elaborao deste trabalho so
de uso gratuito, disponveis para download e sem restries de uso.

4.2.1 MYSQL

Conforme Lari e Amaral (2004), o MySQL o banco de dados relacional de


cdigo aberto, escrito em C e C++, mais utilizado em todo mundo. Suas maiores
virtudes so a velocidade, a confiabilidade e a portabilidade. Pode lidar com grandes
bases de dados e j foi testado com mais de 50 milhes de registros.

Figura 4.2 Tabelas criadas no MySQL e usadas pelo Snort.


Fonte : Elaborado pelo autor, 2013

Neste trabalho, o MySQL funcionar como banco de dados onde o Snort


armazenar seus alertas.

64

4.2.2 PHP

De acordo com Lari e Amaral (2004), o HyperText Preprocessor (PHP)


uma linguagem de script de cdigo livre muito utilizada pela comunidade de software
livre. Esta linguagem visa o desenvolvimento de aplicaes para internet dentro do
HTML, ou seja, em um cdigo HTML pode-se inserir linhas de cdigo PHP para
realizar determinada tarefa, como, coletar dados de formulrios, enviar cookies,
entre outros.

4.2.3 BASE

Neste trabalho, o PHP precisa ser instalado, pois o Basic Analysis and
Security Engine (BASE) se baseia nesta linguagem.

Figura 4.3 BASE Ferramenta estatstica para analise dos dados do Snort.
Fonte : Elaborado pelo autor, 2013

Esta ferramenta apresenta estatsticas de alertas, permitindo descobrir o


nmero de acessos divididos por protocolo, por portas de origem e destino, entre

65

outras informaes. Cada pacote individual registrado pode ser exibido em um


formato decodificado, mostrando vrias flags, opes e contedos dos pacotes.

4.2.4 APACHE

O uso do BASE neste trabalho fornece uma interface Web para um


acompanhamento dos eventos ocorridos em nosso ambiente de teste e gerados
pelo Snort. Construda em PHP, uma importante ajuda para acompanhamento dos
resultados e auditoria de dados.
Neste contexto encontramos o Apache. O Apache o servidor de web mais
utilizado em todo mundo. mantido pela The Apache Software Foundation.

4.2.5 OINKMASTER

Como j relatado no captulo sobre o Snort, este realiza a deteco de


tentativas de invaso atravs da comparao dos pacotes capturados com sua base
de dados de regras. A atualizao destas regras se d pela adio de regras novas
ou por modificao das regras antigas. Existem vrias fontes de regras para Snort,
sendo a principal delas localizada no site oficial do Snort, www.snort.org.
O oinkmaster uma ferramenta desenvolvida em Perl para automatizar o
processo de download e mesclagem das regras do Snort.

4.2.6 LIBPCAP

A Libpcap uma biblioteca de funes que ajuda o programador a realizar


tarefas relacionadas com redes de computadores. No lugar de programar com
sockets, por exemplo, o programador pode utilizar funes j definidas, como
captura de pacotes diretamente da placa de rede. (LARI e AMARAL, 2004)

4.2.7 ADODB

De acordo com Lari e Amaral (2004), a Adodb uma biblioteca de classes


utilizada por banco de dados que facilita o trabalho do programador no sentido da
flexibilidade. Normalmente, um programa em PHP possui funes que chamam

66

determinado banco de dados.


A Adodb suporta vrios banco de dados, entre eles, MySQL, PostgreSQL,
Interbase, Firebird, Informix, Oracle, MS SQL 7, Foxpro, Access, ADO, Sybase e
outros. Usa-se essa biblioteca neste trabalho, para conectar o MySQL junto com o
Snort.

4.2.8 GUARDIAN

O Snort uma ferramenta que gera alertas das tentativas de invaso. O


Snort sozinho no faz o bloqueio automtico de ataques. Para esta tarefa ou
compila-se o Snort com suporte ao mdulo inline ou utiliza-se uma ferramenta extra
para a realizao deste bloqueio. Neste trabalho optou-se pela utilizao da
ferramenta chamada Guardian.
O Guardian tem a capacidade de ler os logs do Snort em tempo real, agindo
contra um possvel invasor no momento da tentativa. O Guardian apresenta scripts
para realizar bloqueios compatveis com os firewalls Iptables, Ipchain e Ipfw.

4.2.9 WIRESHARK

O wireshark, antigamente conhecido como Ethereal, um programa que


analisa o trfego de rede, e o organiza por protocolos. As funcionalidades so
parecidas com o tcpdump mas com interface Grafic User Inferface (GUI), com mais
informaes e com a possibilidade de uso de filtros.
ento possvel controlar o trfego de uma rede e saber tudo o que entra e
sai do computador, em diferentes protocolos, ou da rede a qual o computador est
ligado. Neste trabalho, este programa ser usado analisar o trfego do host antes e
sob ataque DDoS, afim de verificar os bloqueios de dados e trfego de rede.

4.2.10 T50

O T50 uma ferramenta desenvolvida por um brasileiro, Nelson Brito, capaz


de usar uma forma de teste para determinar a estabilidade de um determinado
sistema. Trata-se de testar alm da capacidade operacional normal, muitas vezes a
um ponto de ruptura, afim de avaliar os resultados.

67

O T50 suporta at 15 protocolos e pode atingir at 120.000 pacotes por


segundo em redes 100BaseT, e 1.000.000 de pacotes por segundo em redes
1000BaseT. Neste trabalho o T50 ser usado em nossos testes simulando um
ataque do tipo DDoS.
O T50 pode ser encontrado no link http://t50.sourceforge.net/.

4.2.11 BONESI

Projetado para estudar o efeito de ataques DDoS, o BoNeSi uma


ferramenta criada para simular ataque de Botnet em um ambiente de rede. O
BoNeSi gera inundaes de pacotes ICMP, UDP e TCP (HTTP) de tamanho
definido, a partir de diferentes endereos IP.
Primeira ferramenta criada para simular inundaes HTTP a partir de redes
de bot em larga escala, o BoNeSi tambm tenta evitar gerar pacotes identificveis
com padres simples (que podem ser facilmente filtrados).
O BoNeSi pode ser encontrado no link http://code.google.com/p/bonesi/.

4.2.12 VIRTUALBOX

Software que permite que um nico host possa criar e executar um ou mais
ambientes virtuais, o Oracle VirtualBox um software de virtualizao de uso
gratuito para uso domstico ou em empresas, e tambm tem seu cdigo disponvel
sob os termos da GNU General Public Licence (GLP).
Neste trabalho, o VirtualBox ser usado para criar-se as VMs que contm os
programas implementados, assim como, todo o ambiente usado para test-los. O
virtualBox pode ser encontrado no site www.virtualbox.org.

4.3 AMBIENTE DE TESTES

O ambiente de testes utilizado nesta avaliao de desempenho foi um


ambiente de rede local. O aplicativos T50 e Bonesi, utilizados para injeo de
pacotes, embora simulem um ataque DDoS, e possam ser modificados para uso na
rede externa, so compilados para uso somente em rede local, com o objetivo de

68

fazer stress testing na rede, com objetivo de avaliar desempenho. Seus autores
assim indicam o uso destes programas.
O ambiente de rede local foi construdo atravs de software de virtualizao
VirtualBox. A mquina hospedeira possui as seguintes configuraes de hardware e
Sistema Operacional (SO) : Processador Intel Core i7-2600 3.40 GHz, memria
RAM 4,00 GB, 1 TB Hard Disk (HD) e o SO Windows 7 Professional 64 bits.
Nas Virtual Machines (VM) ou mquinas virtuais, foram utilizadas as
seguintes configuraes de hardware e SO : memria RAM 1,5 MB, 30MB HD e SO
XUbuntu verso 12.10. A interface de rede foi configurada como modo bridge e usa
comunicao padro Ethernet 100BASE-TX.
A Figura 4.4 ilustra o ambiente geral dos testes utilizando as VMs que so
compostas pela Virtual-VM1, que representa o servidor de segurana, onde est
instalado o Snort e demais aplicativos, e onde sero feitas as contenes
(bloqueios) no nvel em que o Guardian estiver habilitado. E mostra tambm as
demais mquinas, que so as VMs que contm os injetores de pacotes e de onde se
originam os ataques.

Figura 4.4 Ambiente de Testes


Fonte : Elaborado pelo autor, 2013

69

Vale ressaltar que a mquina hospedeira, e consequentemente, as VMs, no


estavam com conexo Internet.

4.4 RESULTADOS EXPERIMENTAIS

Para a obteno dos resultados dos experimentos nestes testes, foram


realizadas quatro simulaes de ataques do tipo DDoS, a partir dos injetores de
pacotes.
Duas simulaes foram feitas a partir do injetor de pacotes T50, sendo que
na primeira, deteco, o objetivo era avaliar o nmero de alertas gerados a partir das
tentativas de intruso, tendo suas correspondncias no banco de dados de regras
do Snort, estando o Guardian nesta fase, desabilitado. Na segunda simulao,
deteco com bloqueio, o objetivo avaliar os bloqueios criados no firewall do Linux
(iptables), a partir dos alertas gerados pelo Snort. Fazendo assim, com que se
verificasse a efetiva conteno das tentativas de ataque. Nesta fase o Guardian
encontrava-se habilitado.
Outras duas simulaes de ataques com as mesmas caractersticas e
objetivos das citadas acima, foram realizadas utilizando-se desta vez, o injetor de
pacotes BoNeSi.
As mquinas virtuais alvos dos ataques, uma para cada simulao, foram
clonadas a partir de uma mquina virtual base, com todos os aplicativos instalados
e configurados, porm sem nenhum registro resultante de qualquer ataque ou
captura de pacotes, para que no houvesse influncia no resultado final de cada
teste. Uma mquina virtual foi usada individualmente para cada injetor de pacotes,
embora no houvesse razo para usar-se uma nica VM com os dois programas
injetores instalados.

4.5 SIMULAO DE ATAQUE COM O INJETOR T50

Na primeira simulao usando o injetor de pacotes T50, realizou-se o ataque


ao Host com Snort, sem iniciar o servio do Guardian. Assim sendo, o Snort analisou
os pacotes que correspondiam a assinaturas de ataques contidas em seu banco de
dados de regras, gerando os respectivos alertas. O Snort retornou os resultados
como mostra a Figura 4.5.

70

Figura 4.5 Tela do BASE, ataque do T50 com Guardian desabilitado


Fonte : Elaborado pelo autor, 2013.

O T50 foi executado a partir da seguinte linha de comando :


./t50 192.168.0.110 --flood --turbo
Onde, 192.168.0.110, corresponde ao IP do host a ser atacado. O parmetro
flood refere-se ao nmero de pacotes enviados, no caso, ilimitado (podendo atingir
at 120.000 pacotes no caso da rede 100BaseT), e o parmetro turbo usado para
intensificar o ataque.
Quadro 4.1 Protocolos usados no ataque com T50
Protocolos
IPv4
UDP
TCP
IPv6
UDP6
ARP

eth : 1387 pacotes analisados (100%)


Pacotes
1363
3
1360
20
11
4

Percentual
98,270%
0,216%
98,053%
1,442%
0,793%
0,288%

Fonte : Elaborado pelo autor, 2013

O Quadro 4.1 mostra os protocolos dos pacotes analisados pelo snort no


tempo de ataque com T50.
Nos grficos exibidos nas figuras 4.6 e 4.7, verifica-se o trfego de rede nos

71

momentos das simulaes de ataques (dados em milhares de pacotes por segundo,


em intervalos de 10s). Observa-se que o trfego se mantm semelhante nas duas
simulaes, porm nota-se um pico maior ocorrendo a partir dos 1800s, momento
em que foi finalizada a execuo do injetor de pacotes. Pode-se observar este
aumento de trfego nos 150s seguintes, e sendo maior, na simulao em que foi
realizado a deteco com bloqueio.

Figura 4.6 Trfego de pacotes na rede durante ataque. deteco T50


Fonte : Elaborado pelo autor, 2013

Figura 4.7 Trfego de pacotes na rede durante ataque. deteco com bloqueio T50
Fonte : Elaborado pelo autor, 2013

Quadro 4.2 Resultados gerados pelo Snort nas simulaes com T50.
Deteco

Deteco e Bloqueio

Pacotes Recebidos

50.989.996

49.609.890

Pacotes Descartados

50.988.338

49.607.817

Pacotes Analisados

1658

Pacotes por minuto

53

Alertas Gerados
Tempo de Execuo

1442
1887,395s

0,003% / recebidos

2073

0,004% / recebidos

64
86,972% / analisados

1429

68,934% / analisados

1934,327s

Fonte : Elaborado pelo autor, 2013

Como mostrado no Quadro 4.2, na linha Pacotes Analisados, observa-se


um maior nmero de pacotes na simulao de deteco com bloqueio.
A Figura 4.8 mostra o percentual de utilizao da CPU pelo processo do
Snort, onde compare-se as simulaes de somente deteco e deteco com
bloqueio. Durante o tempo de simulao de ataque (30min.), observa-se que no h

72

grande variao do uso da CPU na comparao entre as duas simulaes.


Os dados foram obtidos a partir do uso do comando top do Linux, que
fornece uma viso dinmica dos processos que esto sendo executados,
monitorando, entre outros dados, o percentual de utilizao do processador por cada
processo.
A seguinte sintaxe foi utilizada para registrar os dados :
#top b n 62 d 30 u snort > teste.txt

Onde, -b gera processamento em lote, -n refere-se ao nmero de repeties


das verificaes, -d o intervalo de tempo (em segundos) entre cada verificao, -u
exibir somente o processo Snort, enviando o resultado para um arquivo texto.

Figura 4.8 Uso da CPU pelo processo Snort na simulao com T50
Fonte : Elaborado pelo autor, 2013

A Figura 4.9 mostra parte do relatrio de alertas gerados pelo BASE, onde
observa-se as informaes como assinatura da invaso, os endereos de IP origem
(atacante) e destino (alvo), protocolo e porta utilizada no ataque.

73

Figura 4.9 Relatrio de Alertas do BASE na simulao com T50


Fonte : Elaborado pelo autor, 2013

Na simulao com T50 foram gerados 1429 alertas, e a partir destes, foram
criadas 1387 regras no firewall. A Figura 4.10 mostra parte das regras criadas no
iptables, sendo todas elas na chain INPUT.

Figura 4.10 Bloqueios feitos no iptables na simulao com T50.


Fonte : Elaborado pelo autor, 2013

74

4.6 SIMULAO DE ATAQUE COM O INJETOR BONESI

Assim como feito com o injetor T50, duas simulaes foram realizadas com
o injetor de pacotes Bonesi, avaliando-se os mesmos itens das simulaes
anteriores.
O Bonesi foi executado a partir da seguinte linha de comando:
bonesi i 50k-bots 196.168.0.110:80
Onde, o parmetro -i refere-se ao arquivo que contem uma lista de IPs
vlidos que faro o papel dos IPs origem, ou seja, de onde partem os ataques
(mquinas zumbis). O Bonesi conta com um arquivo, o 50k-bots, que possui uma
lista com 50.000 endereos de IPs vlidos usados como atacantes. E finalmente, os
dois ltimos parmetros referem-se ao IP e porta destino, ou alvo do ataque.
Nos grficos exibidos nas Figuras 4.11 e 4.12, verifica-se que o trfego da
rede nos momentos dos ataques tem maior oscilao entre as duas simulaes do
que a constatada nas simulaes com o injetor T50. Aqui observa-se tambm, um
pico maior ocorrendo a partir dos 1800s, momento em que foi finalizada a execuo
do injetor de pacotes. Pode-se observar este aumento de trfego nos 150s
seguintes, e no caso da simulao com o Bonesi, este pico maior na simulao em
que foi realizada somente deteco, ao contrrio do que observou-se nas
simulaes com o T50.

Figura 4.11 Trfego de pacotes durante ataque deteco Bonesi.


Fonte : Elaborado pelo autor, 2013

Figura 4.12 Trfego de pacotes durante ataque - deteco bloqueio Bonesi.


Fonte : Elaborado pelo autor, 2013

Nas simulaes usando o injetor Bonesi, foram constatados resultados bem

75

distintos, principalmente no que se refere aos pacotes analisados e os alertas


gerados. Comparando-se estas simulaes com as feitas usando o T50, observa-se
um nmero de pacotes analisados bem maior, ao passo que o nmero de alertas
gerados foi bem menor que nos nmeros constatados com o T50. Pode-se verificar
estes nmeros no Quadro 4.3, nas linhas Pacotes Analisados e Alertas Gerados.
Observa-se tambm um consequente aumento no nmero de pacotes analisados
por minuto.
Quadro 4.3 Resultados gerados pelo Snort nas simulaes com Bonesi.
Deteco

Deteco e Bloqueio

Pacotes Recebidos

36.184.131

49.055.322

Pacotes Descartados

36.177.109

49.045.784

Pacotes Analisados

7022

Pacotes por minuto

292

Alertas Gerados
Tempo de Execuo

17

0,019% / recebidos

9538

0,019% / recebidos

307
0,242% / analisados

1847,395s

17

0,178% / analisados

1864,277s

Fonte : Elaborado pelo autor, 2013

A utilizao da CPU pelo processo Snort tambm foi maior na simulao


com o injetor Bonesi, como mostrado na Figura 4.13.

Figura 4.13 Uso da CPU pelo processo Snort na simulao com Bonesi.
Fonte : Elaborado pelo autor, 2013

76

4.7 COMPARAO ENTRE OS INJETORES

Como mencionado anteriormente, foi usado nas simulaes um tempo de


ataque de trinta minutos. Nesta amostragem de tempo, o Snort acusou um nmero
de pacotes recebidos que no apresenta grandes variaes entre as quatro
simulaes, como mostra a Figura 4.14.

Figura 4.14 Comparao entre os injetores dos pacotes recebidos.


Fonte : Elaborado pelo autor, 2013

Na comparao entre os dois injetores de pacotes, em ambas as situaes,


ou seja, somente alertas e gerando bloqueios (contenes), constata-se que nas
simulaes usando o Bonesi, o nmero de pacotes analisados bem maior do que o
observado nas simulaes com o T50. Porm, observa-se que o nmero de pacotes
analisados no corresponde necessariamente a um nmero maior na incidncia de
alertas. Pois, nas simulaes com o T50, o nmero de alertas gerados foi baixo em
relao ao nmero maior de pacotes analisados, como mostrado nos grficos da
figura 4.15.
Conclui-se nesse caso que, na simulao com o injetor T50, embora um
nmero menor de pacotes tenha sido analisado, entre eles encontra-se um maior
nmero que tem correspondncias nas assinaturas constantes no banco de dados

77

do Snort, ou seja, entre os pacotes analisados um maior nmero de pacotes que


contm cdigo malicioso.

Figura 4.15 Pacotes Analisados x Alertas/Bloqueios


Fonte : Elaborado pelo autor, 2013

Uma constatao feita, na simulao de deteco e bloqueio usando o


injetor Bonesi, em que somente 17 alertas foram gerados, nenhuma regra de
bloqueio foi criada no firewall (iptables), ou seja, os pacotes atacantes passaram
pelo servidor de segurana.
Nas situaes em que o objetivo era a realizao de conteno, na
simulao com o injetor Bonesi, e constatando-se o grande nmero de pacotes
analisados pelo Snort, com um pequeno nmero de alertas gerados, constata-se
que a maior parte dos pacotes com contedo malicioso injetado pelo Bonesi, no
encontrou correspondncia nas assinaturas de tentativas de intruso contidas no
banco de dados do Snort, ou seja, este injetor tem maior capacidade de burlar o
IDS, considerando-se as regras disponibilizadas que nele esto contidas.
Constatou-se tambm que a conteno de ataques com o uso das
ferramentas Snort/Guardian foi feita, porm sua eficincia, ou a falta dela, est
relacionada constante manuteno do conjunto de regras do Snort.

78

4.8 DIFICULDADES ENCONTRADAS

Algumas dificuldades foram encontradas no desenvolvimento do trabalho:

O uso dos injetores no ambiente virtual no possibilitou um resultado


realista.

Os injetores usados no ambiente de maquinas virtuais causava


travamento na maquina alvo durante as simulaes, impedindo um
melhor acompanhamento, s possibilitando colher resultados aps a
finalizao do injetor.

4.9 TRABALHOS FUTUROS

Entre os possveis trabalhos futuros pode-se indicar:

Uma comparao entre as formas inline do Snort e a optada por este


trabalho usando o guardian como ferramenta adicional para realizar
conteno;

A construo de um injetor de pacotes, o que permite construir


conhecimento mais detalhado sobre os ataques

Criar regras no Snort especficas para ataques DoS;

Configurao do Snort em plano, que consiste em uma variante do Snort


em que as regras so criadas a partir do conhecimento da rede local.

CONCLUSO

A implementao de um IDS composta neste trabalho, foi realizada para


mostrar como pode-se criar uma camada extra de segurana na rede local ou em
host, possibilitando, alm da construo de conhecimento sobre segurana da rede
local, a capacidade de realizar a conteno das tentativas de violao da segurana.
O uso do IDS constitui fundamental ferramenta de auxlio na manuteno da
segurana e seu grau de eficincia est intimamente ligado ao conjunto de
informaes construdo sobre a rede local e do conhecimento inerente a redes de

79

computadores. E, ao mesmo tempo em que constitui ferramenta de segurana, o


IDS bem utilizado, tambm, fonte de constante informao e aprendizado sobre
trfego de dados, aperfeioando o nvel de segurana do ambiente onde est
implantado.
A principal contribuio deste trabalho foi na construo de conhecimento
acerca da implantao um sistema de deteco de intruso. Coletar dados a
respeito do comportamento do IDS quando sobre ataques e avaliar sua eficincia
trabalhando em conjunto com outras ferramentas para realizao da conteno
destes ataques.

80

REFERNCIA BIBLIOGRFICA

AKAMAI. Real time web monitor. Akamai Technologies, 2013. Disponvel:


http://www.akamai.com/html/technology/dataviz1.html

ARAJO, FELIPE GUSTAVO SOUZA; ASSUMPO, MARCELO HOOVER


PIMENTEL. SIGIN SISTEMA PARA GERENCIAMENTO DE DETECO DE
ATAQUES DE NEGAO DE SERVIO . 2010. Trabalho Final de graduao
(Bacharelado em Informtica) Instituto de Cincias Exatas e Tecnolgicas,
Universidade Catlica do Salvador - UCSAL, Bahia
CASWELL, BRIAN at al. Snort 2 Sistema de Deteco de Intruso - Open
Source. Rio de Janeiro : Alta Books, 2003.
HATCH, BRIAN; LEE JAMES; KURTZ GEORGE HACKERS Linux EXPOSTOS
Segredos e Solues Para a Segurana do Linux. So Paulo : Makron Books,
2002.

JORDO, FABIO DDoS: como funciona um ataque distribudo por negao de


servio. 2011. Disponvel em : http://www.tecmundo.com.br/segurana/10970-ddoscomo-funciona-um-ataque-distribuido-por-negacao-de-servico.htm Acesso em 10
Abril. 2013.

LARI, PAULO AUGUSTO MODA; AMARAL, DINO MACEDO Snort, MySQL,


Apache e ACID. Rio de Janeiro : Brasport, 2004.

LIEIRA, JULIO FERNANDO Segurana de Redes. 2012, 87p. Apostila Segurana


de Redes de Computadores, Fatec Lins, Lins SP.

NOBRE, J.C.A.. Ameaas e Ataques aos Sistemas de Informao : Prevenir e


Antecipar : Cadernos UniFOA, Volta Redonda, ano 2, n. 5, dez 2007. Disponvel :
http://www.unifoa.edu.br/pesquisa/caderno/edicao/05/11.pdf

81

SANTOS, B.R. DETECO DE INTRUSOS UTILIZANDO O SNORT . 2005. TCC.


(PS GRADUAO EM ADMINISTRAO DE REDES) - Departamento de
Computao, Universidade Federal de Lavras, Minas Gerais

82

ANEXO A Instalao e Configurao

Neste anexo mostramos a instalao e configurao dos aplicativos


utilizados no desenvolvimento deste trabalho. Ao longo do capitulo 4, onde so
descritas estas ferramentas, constam o site ou link onde elas podem ser
encontradas, entretanto, outros mais sero referenciados neste anexo.

Criando e instalando as mquinas virtuais

As VMs criadas para os testes, usaram todas, as mesmas configuraes e


sistema operacional, portanto, para a VM usada como servidor de segurana e para
as demais VMs onde so instalados os injetores, o mesmo procedimento ser
usado.

Figura A.1 Criao da VM Descrio e SO utilizado na VM


Fonte : Elaborado pelo autor, 2013

O tipo de sistema operacional utilizado surgir assim que digitarmos o ttulo


Xubuntu, sendo este o Linux verso Ubuntu, como mostra a figura A.1.

83

Figura A.2 Memria reservada para VM


Fonte : Elaborado pelo autor, 2013

Figura A.3 Espao de HD reservado para VM


Fonte : Elaborado pelo autor, 2013

84

Como figura A.3 mostra que foi selecionado um espao em HD de 30GB


para a VM Servidor de Segurana, porm para as demais VMs o espao sugerido na
instalao (8,00 GB) ser o suficiente, j que somente os aplicativos injetores sero
instalados.

Figura A.4 Adaptador de rede da VM


Fonte : Elaborado pelo autor, 2013.

Figura A.5 Selecionando a ISO contendo a instalao do SO.


Fonte : Elaborado pelo autor, 2013.

85

Como mostrado na figura A.4, no item configuraes da VM, opo rede,


indicamos o tipo de conexo utilizada nesta interface.

Figura A.6 Tela de instalao do XUbuntu 12.10


Fonte : Elaborado pelo autor, 2013.

Assim como mostra a figura A.5, no item configuraes da VM, opo


armazenamento, indicamos onde est o arquivo de instalao do SO. Este pode
estar em DVD-ROM ou em imagem ISO. A instalao do XUbuntu pode ser
encontrada no site www.ubuntu-br.org.
Ao se executar a VM criada, o processo de instalao e para conclu-lo
basta aceitarmos as opes padro oferecidas durante o processo, sem
necessidade de demais configuraes.

Instalando aplicativos e ferramentas

Como mencionado anteriormente, neste trabalho o Snort ir funcionar em


conjunto com outros aplicativos afim de proporcionar-lhe as funcionalidades
necessrias para atingirmos nossos objetivos. Entre eles esto o banco de dados
MySQL, o servidor Web Apache, a linguagem PHP5 com bibliotecas grficas e o

86

Snort propriamente dito.


#sudo apt-get install mysql-server
#sudo apt-get install apache2
#sudo apt-get install php5
#sudo apt-get install php5-mysql
#sudo apt-get install php5-gd
#sudo apt-get install php-pear
#sudo apt-get install snort
#sudo apt-get install snort-mysql

Baixar e descompactar adodb :


http://prdownloads.sourceforge.net/adodb/
#cp /home/ricardo/Downloads/adodb518a.tgz /var/www
#cd /var/www
#tar xvzf adodb518a.tgz
#rm f adodb518a.tgz

Configurao do MySQL :
#mysql
>set password for root@localhost=password(pwmysql);
>create database snort_db;
>grant insert,select on root.* to snort@localhost;
>set password for snort@localhost=password(pwsnort);
>grant create,insert,select,delete,update on snort_db.* to
snort@localhost;
>grant create,insert,select,delete,update on snort_db.* to
snort;

87

>exit;
#gzip d /usr/share/doc/snort-mysql/create_mysql.gz
#mysql u root p < /usr/share/doc/snort-mysql/create_mysql
snort_db
Configurao do Snort :
#sudo nano /etc/snort/snort.conf
ipvar HOME_NET any
ipvar EXTERNAL_NET any
var RULE_PATH /etc/snort/rules
output database : log, mysql, user=snort password=pwsnort
dbname=snort_db host=localhost

Executando o Snort :
Modo sniffer :
#snort vde
Modo deteco de intruso
#snort vde c /etc/snort/snort.conf

Basic Analysis and Security Engine (BASE) :


http://prdownloads.sourceforge.net/secureideas/
#cp /home/ricardo/Downloads/base-1.4.5.tar.gz /var/www
#cd /var/www
#tar xvzf base-1.4.5.tar.gz
#rm f base-1.4.5.tar.gz
#cd base-1.4.5
#cp base_conf.php.dist base_conf.php
#sudo nano base_conf.php
Alterar parmetros no arquivo :
$BASE_urlpath
= /base-1.4.5;

88

$DBlib_path

= /var/www/adodb5;

$DBtype

= mysql;

$alert_dbname

= snort_db;

$alert_host

= localhost;

$alert_port

= ;

$alert_user

= snort;

$alert_password = pwsnort;

Instalar bibliotecas auxiliares para gerao de grficos :


#pear config-set preferred_state alpha
#pear install Image_Color
#pear install Image_Canvas
#pear install Image_Graph

Executar no navegador : http://localhost/base-1.4.5


clicar na opo setup page
clicar boto

Create BASE AG

Figura A.7 Tela inicial do BASE


Fonte : Elaborado pelo autor, 2013.

89

Instalando o Guardian :
http://www.chaotic.org/guardian/

#mv /home/Ricardo/Downloads/guardian-1.7.tar.gz /usr/src


#cd /usr/src
#tar xvzf guardian-1.7.tar.gz
#cd guardian-1.7
#cd scripts
#cp iptables_block.sh /usr/bin/guardian_block.sh
#cp iptables_unblock.sh /usr/bin/guardian_unblock.sh
#chmod 755 /usr/bin/guardian_block.sh
/usr/bin/guardian_unblock.sh
#cd /usr/src/guardian-1.7
#cp guardian.pl /usr/bin
#chmod 755 /usr/bin/guardian.pl
#cp guardian.conf /etc/
#sudo nano /etc/guardian.conf

Alterar itens de configurao do arquivo:


HostIpAddr <IP Frente com Intenet>
Interface

eth0

AlertFile /var/log/snort/alert
TargetFile /etc/snort/guardian.target
TimeLimit 86400

Criar os arquivos :
#touch /var/log/guardian.log
#touch /etc/guardian.ignore
#touch /etc/snort/guardian.target

Editar arquivo :
#nano /etc/snort/guardian.target
<IP a ser monitorado>

90

Iniciar o Guardian :
#/usr/src/guargian-1.7/guardian.pl c /etc/guardian.conf

Usando logs do snort :

Quando se configura o snort para gravar os alertas no MySQL, os arquivos


de log deixam de ser gerados. Logo aps a configurao do MySQL no arquivo de
configurao do Snort (/etc/snort/snort.conf), deve-se adicionar a linha de
configurao abaixo para que os arquivos de log de alerta do snort sejam tambm
gerados :
output database: log, mysql, user=snort password=123456
dbname=snort host=localhost
output alert_full: /var/log/snort/alert

Para parar o servio do guardian :


#kill -9 $(pgrep guardian.pl)

Instalao do oinkmaster
http://oinkmaster.sourceforge.net/downloads.shtml

#mv /home/Ricardo/Downloads/oinkmaster-2.0.tar.gz /usr/src


#cd /usr/src
#tar xvzf oinkmaster-2.0.tar.gz
#cd oinkmaster-2.0
#cp /usr/src/oinkmaster-2.0/oinkmaster.pl /usr/bin
#cp /usr/src/oinkmaster-2.0/oinkmaster.conf /etc/
Inserir no arquivo /etc/oinkmaster :
url = file:///home/ricardo/Downloads/snortrules-snapshot2930.tar.gz
Iniciar o oinkmaster usando opo por arquivo baixado :
#oinkmaster c o /etc/snort/rules