Sistema de Prevenção de Intrusão Com Snort. Igor Neiva e Sandro Herman. UCB.

UNIVERSIDADE
CATÓLICA DE
BRASÍLIA
PROGRAMA DE PÓS-GRADUAÇÃO
LATO SENSU EM REDES DE COMPUTADORES
SISTEMAS DE PREVENÇÃO DE INTRUSÃO BASEADO EM
SOFTWARE LIVRE: DEBIAN E SNORT
IGOR DA SILVA NEIVA MAIA

SANDRO HERMAN PEREIRA REHEM
BRASÍLIA 2º/2005
Lato Sensu em Redes de Computadores
Universidade Católica de Brasília
IGOR DA SILVA NEIVA MAIA
SANDRO HERMAN PEREIRA REHEM
SISTEMAS DE PREVENÇÃO DE INTRUSÃO BASEADO EM
SOFTWARE LIVRE: DEBIAN E SNORT
Projeto final apresentado ao Programa de

Pós-Graduação “Lato Sensu” em Redes de
Computadores da Universidade Católica de
Brasília, como requisito a obtenção do grau de
Especialista em Rede de Computadores.
Orientador: Jerônimo Jardim
Brasília
DEZEMBRO/2005
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort i

TERMO DE APROVAÇÃO
Monografia defendida e aprovada como requisito parcial obtenção do grau de
Especialista em Rede de Computadores, defendida e aprovada, em 12 de dezembro de
2005, pela banca examinadora constituída por:
JERÔNIMO JARDIM
(ORIENTADOR)
LAERTE PEOTA
(EXAMINADOR INTERNO)
Brasília
UCB
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort ii

Aos nossos pais, familiares e namoradas pela
compreensão e incentivo nos momentos mais
difíceis.
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort iii

Agradecemos:
Primeiramente a Deus.
À Universidade Católica de Brasília.
Ao Professor Mestre Jerônimo Jardim
Incentivador e esclarecedor de muitas dúvidas
surgidas ao longo do projeto
E a todos aqueles que nos ajudaram e
incentivaram no desenvolvimento das
atividades realizadas neste projeto.
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort iv

LISTA DE FIGURAS
Ilustração 1.1 – Crescimento dos sistemas de informação...................... ...............................1
Ilustração 2.2 – Estatísticas de incidentes relatados ao CERT/CC.........................................5
Ilustração 2.3 – Estatísticas de incidentes relatados ao CERT.br............................... .............5
Ilustração 2.4 – Comparativo entre conhecimento e sofisticação dos ataques........................ 6
Ilustração 2.5 – Processos para implementação de segurança..............................................9
Ilustração 3.6 – IDS como segunda camada de defesa da rede..................... ......................25
Ilustração 3.7 – Localização dos sensores................................................................... .........31
Ilustração 4.8 – Princípio fundamental de defesa ativa. ................................ .......................37
Ilustração 4.9 – Arquitetura de IPS.............................................................................. ..........39
Ilustração 5.10 – Mecanismo de processamento de pacotes no Snort................................ ..51
Ilustração 5.11 – Exemplo de assinatura do Snort.................................... ............................56
Ilustração 6.12 – Disposição do Snort Inline............................................. ............................63
Ilustração 6.13 - Mecanismo de processamento de pacotes no Snort Inline.........................63
Ilustração 7.14 – Topologia utilizada em laboratório.................................................... ..........66
Ilustração 7.15 – Tela de configuração inicial do BASE.................................................. .......82
Ilustração 7.16 – Tela de status da configuração inicial do BASE.........................................82
Ilustração 8.17 – Análise de logs no BASE............................................... ............................84
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort v

RESUMO
Este trabalho visa a implantação de um IPS (Intruder Prevention System) utilizando o
Snort Inline como ferramenta. Inicialmente é apresentada a teoria envolvida no projeto,
definindo IPS e suas funcionalidades. Logo após, são descritas as ferramentas necessárias
para a implementação do ambiente do IPS, bem como a implementação em si. Em seguida,
são apresentados os dados da coleta a respeito de ataques e sua análise. Finalmente, são
feitas as considerações finais e sugestões de trabalhos futuros.
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort vi

ABSTRACT
This work aims at the implantation of IPS (Intruder Prevention System) using the
Snort Inline as tool. This work initially presents the theory involved in the project, explaining
what a IPS is for and how it works. Afterwards, all the tools needed to implement the IPS
environment are described, as well as the implementation itself. Thereafter, the collected
data about the attacks and their analysis are presented. Finally, final statements are made
and future works are suggested.
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort vii

ÍNDICE
Capítulo Página
LISTA DE FIGURAS................................................................................................ ...............v
RESUMO.......................................................................................................................... .....vi
1 INTRODUÇÃO..................................................................................................... ................1
1.1 Objetivo......................................................................................................... ................3
1.2 Escopo.................................................................................................... ......................4
2 SEGURANÇA.......................................................................................... ............................4
2.1 Políticas de Segurança............................................................................................... ..7
2.2 Crimes Computacionais..................................................................... ...........................9
2.3 Firewalls............................................................................................ ..........................11
2.4 Ameaças e Ataques.............................................................................................. ......12
2.4.1 Classificação.............................................................................. ..........................12
2.4.2 Tipos de Ataques.................................................................................. ................13
2.4.3 Exemplos de Ataques.............................................................................. .............14
2.5 Intrusão................................................................................................ .......................17
2.5.1 Classificação de uma Intrusão........................................................................ ......18
2.5.2 Detecção de uma Intrusão................................................................................. ...19
3 SISTEMAS DE DETECÇÃO DE INTRUSÃO.................................................. ...................20
3.1 Tipos de IDS........................................................................................................ ........21
3.1.1 IDS baseados em Redes (NIDS)............................................................ ..............21
3.1.2 IDS baseados em Hosts (HIDS)....................................................... ....................25
3.1.3 IDS baseados em kernel .......................................................... ...........................29
3.2 Consoles e Sensores........................................................................ ..........................29
3.2.1 Gerência..................................................................................................... ..........29
3.2.2 Sensores....................................................................................... .......................30
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort viii

3.3 Assinaturas........................................................................................................... .......33
3.4 Estímulos e Respostas........................................................................................ ........33
4 SISTEMAS DE PREVENÇÃO DE INTRUSÃO.................................................................. .35
4.1 Surgimento da Necessidade da Pesquisa..................................................... ..............35
4.2 Princípios fundamentais......................................................................... .....................36
4.2.1 Defesa ativa.......................................................................................................... 36
4.2.2 IPS........................................................................................................................ 38
4.3 Riscos e impactos............................................................................... ........................43
4.4 Soluções disponíveis no mercado................................................................ ...............45
4.4.1 Ferramentas gratuitas........................................................................................... 46
4.4.2 Ferramentas comerciais................................................................... ....................48
5 SNORT.............................................................................................................................. .50
5.1 Mecanismo..................................................................................................... .............51
5.2 Configuração................................................................................................. ..............52
5.2.1 Variáveis................................................................................................... ............53
5.2.2 Preprocessor..................................................................................... ...................53
5.2.3 Assinaturas............................................................................................... ............55
5.2.4 Saída...................................................................................................... ..............60
6 SNORT INLINE............................................................................................. .....................62
6.1 Mecanismo IPtables................................................................................. ...................63
6.1.1 Mecanismo IPFW.......................................................................... .......................64
6.2 Configuração................................................................................................. ..............64
6.2.1 Mecanismo Inline............................................................................................... ...64
7 IMPLEMENTAÇÃO................................................................................ ............................66
7.1 Sistema Operacional................................................................................ ...................67
7.1.1 Instalação............................................................................................ .................68
7.2 Firewall.............................................................................................................. ..........68
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort ix

7.2.1 Configuração..................................................................................... ...................68
7.3 Sensor............................................................................................................... ..........69
7.3.1 Snort Inline................................................................................... ........................70
7.3.2 Bridge.................................................................................................... ...............74
7.3.3 IPtables.................................................................................... ............................75
7.4 Gerência................................................................................................................. .....76
7.4.1 MySQL..................................................................................... ............................76
7.4.2 Apache HTTP................................................................................... ....................79
7.4.3 BASE............................................................................................................ ........79
8 RESULTADOS........................................................................................ ...........................83
8.1 Resultados obtidos.......................................................................................... ............83
8.2 Análise e Discussão dos Resultados................................................................ ...........85
8.3 Problemas diagnosticados e futuras implementações........................................ .........85
CONCLUSÃO........................................................................................... ...........................87
REFERÊNCIAS BIBLIOGRÁFICAS................................................................... ..................89
Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort x

Pós Graduação em Redes de Computadores
1 INTRODUÇÃO
A cada dia milhares de sistemas estão sendo interconectados, operando em conjunto
com outros sistemas, tornando a vida das pessoas cada dia mais fácil e, por conseqüência,
mais perigosa. São sistemas de controle médico: máquinas de vigilância de pacientes,
diagnósticos pela rede e até cirurgias online; Controle aéreo: interoperabilidade entre
diversos aeroportos; Trânsito: semáforos, pontes móveis, pedágios; Até sistemas de
monitoramento de vulcões que mandam seus alarmes pela rede.
Com a popularização das redes de computadores, principalmente a Internet, elas
assumiram um papel fundamental na atividade de empresas e instituições como
universidades, bancos, corretoras, ONGs, e-commerce, entre outras. Assim, essas redes
passaram a trafegar, armazenar e disponibilizar informações, muitas vezes, valiosas e
sigilosas, Ilustração 1.1 .
Ilustração 1.1 – Crescimento dos sistemas de informação.
A disponibilização cada vez mais acelerada de diversos serviços de rede multiplicou
as portas de acesso aos sistemas computacionais, multiplicando também a possibilidade da
ocorrência de acessos indevidos. Na medida em que se amplia o acesso às informações e
Sistemas de Prevenção de Intrusão baseado em Software Livre: De 1

mais recursos são disponibilizados aos clientes internos e externos, mais difícil se torna
garantir a integridade do ambiente. Este problema é agravado pela diversidade de
inovações tecnológicas implementadas a cada dia. Com isso a segurança da informação é
umas das maiores preocupações das grandes organizações no mundo atual, proteger a
rede corporativa contra ataques é uma tarefa constante dos administradores de segurança
da informação de uma empresa, para que os negócios da Empresa não sejam afetados por
ações maléficas, que viriam a se tornar alvo de tentativas de ataques, que em geral, buscam
o acesso não autorizado e a tentativa de indisponibilizar o sistema.
Tecnicamente uma rede de computadores funciona como elos de uma corrente e a
fragilidade da mesma se dá pela possível fragilidade de um único elo mais desprotegido. A
abertura e disponibilização de acesso a uma porta em uma rede segura pode ser um elo
bastante frágil, caso não seja realizada um controle criterioso. Tudo um processo de análise
de segurança deve ser realizado de forma a tornar segura todo o acesso e garantindo que
toda a informação trafegue da forma mais segura possível.
Durante toda a evolução, os primatas que criaram o hábito de acender uma fogueira
na entrada das suas cavernas durante a noite viviam mais, ao contrário dos outros que, vez
por outra, eram devorados por tigres dentes-de-sabre. Este costume se espalhou e, mesmo
que os mais novos não soubessem o motivo da fogueira, este "comportamento adquirido"
era de extrema importância para a sua sobrevivência. Saindo da filosofia é preciso
conscientizar a todos de que a segurança é muito mais do que um simples ramo de
trabalho, ela está presente no cotidiano e é preciso se adaptar. Segurança deve ser uma
preocupação geral, caso contrário estar-se-ia sujeito a ficar nas mãos de pessoas que se
aproveitam do fato de não se dar a devida importância ao assunto.
Para tornar uma rede de computadores mais segura são necessárias ferramentas
complexas de analise de dados/tráfego, pois a quantidade de informações são extramentes
altas e a rapidez na análise é uma exigência da segurança da informação. Existe uma
necessidade crescente por sistemas de segurança.

O elemento mais comum para segurança é atribuído a firewalls e as práticas
atribuídas a listas de acesso em outros elementos de rede. Mas um tipo importante de
software de segurança que surgiu foram os IDS (Intrusion Detection System), entretanto não
é interessante somente em detectar ataques, mas preveni-los. Essa mudança de foco levou
ao desenvolvimento de uma nova classe de ferramentas de segurança, os Sistemas de
Prevenção de Intrusão (IPS), que têm se tornado uma tendência.
Um firewall é um requisito básico para redes conectadas à Internet, sem um firewall
não há o mínimo de segurança para proteger as redes corporativas bem como os
computadores pessoais.
Os IDS (Sistemas de Detecção de Intrusão) são planejados para farejar o tráfego e
analisar a reconhecer atividades e ataques em rede e hosts, detectando atividades
maliciosas o detector de intrusos, permite reagir a ameaças contra o ambiente corporativo.
Um IPS é um sistema que detecta e obstrui automaticamente ataques
computacionais a recursos protegidos. Um contraste com os IDS tradicionais, que localiza e
notifica os administradores sobre anomalias, um IPS defende o alvo sem uma participação
direta dos administradores. Tal proteção pode envolver o uso de técnicas baseadas em
assinatura ou técnicas conhecidas para identificar um ataque, bloquear um tráfego malicioso
ou alguma chamada de sistema que posa causar algum dano. O IPS combina as
funcionalidades de um IDS mais um firewall para oferecer uma solução que
automaticamente bloqueia ações ofensivas e detecta ataques.
1.1 Objetivo
O projeto visa implementar um sistema de prevenção de intrusão com plataforma e
ferramentas de uso livre, abordando estudo dos conceitos de Redes de Computadores.
Visando um aprofundamento no segmento de segurança da informação torna-se
desejável conhecer as ferramentas disponíveis para esta implementação.

Ao final espera-se que seja uma fonte de referência: objetiva e de fácil entendimento;
e propor novas possibilidades de continuidade do projeto.
1.2 Escopo
O sistema operacional adotado foi o Debian, organizado pelo projeto
autodenominado. O Debian é um sistema operacional livre baseado no projeto GNU o qual é
a distribuição oficial Linux. O Debian usa o kernel Linux, mas a maior parte das ferramentas
do SO vêm do projeto GNU, daí o nome GNU/Linux .
A ferramenta, capaz de analisar o tráfego e registro de pacotes na rede, adotada foi o
Snort®. O Snort é um sistema de detecção e prevenção contra intrusos que utiliza linguagem
dirigida por regras, o qual combina os benefícios de assinatura, protocolo e anomalias
baseados nos métodos de inspeção e .
A implementação do ambiente proposto utiliza máquinas virtuais emuladas.
2 SEGURANÇA
Segurança significa minimizar a vulnerabilidade de bens e recursos. Vulnerabilidades
podem ser exploradas para se violar um sistema ou as informações nele contidas. A
Segurança Computacional está relacionada à necessidade de proteção contra o acesso ou
a manipulação, intencional ou não, de informações confidenciais por elementos não
autorizados: é a utilização não autorizada do computador ou de seus dispositivos periféricos.
As estatísticas de incidentes de ataques mostram um crescimento quase exponencial
nos últimos anos, de forma assustadora. De acordo com o CERT/CC (Computer Emergency
Response Team Coordination Center), esse número aumentou de 9859 para 137529
incidentes relatados, no período de 1999 a 2003, Ilustração 2.1. Os dados a partir de 2004
ainda não foram publicados .

Ilustração 2.2 – Estatísticas de incidentes relatados ao CERT/CC.
De acordo com o CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes
de Segurança no Brasil), o número de incidentes relatados aumentou de 3107 para 75722,
no período de 1999 a 2004, até setembro de 2005 foram 46205, Ilustração 2.2 .
Ilustração 2.3 – Estatísticas de incidentes relatados ao CERT.br.
Juntamente com a evolução no número de ataques, evoluíram também as técnicas
utilizadas para procedê-los. Assim, obter acesso não autorizado aos sistemas, deixou de ser

uma prática somente de especialistas, para ser diversão de usuários que tenham interesse e
possuam as ferramentas corretas, Ilustração 2.3 .
Ilustração 2.4 – Comparativo entre conhecimento e sofisticação dos ataques.
Dado ao uso disseminado de ferramentas automáticas, os ataques a sistemas
tornam os incidentes bastante comuns, entretanto existem poucas informações a respeito do
impacto dos ataques. Em virtude desse quadro assim como em uma guerra, conhecer o
inimigo é algo de extrema importância. No mundo dos computadores, saber as técnicas e
ferramentas empregadas nos ataques às redes de computadores é algo fundamental para
que as técnicas de defesa mantenham sua eficácia.
Mesmo assim, com a tecnologia disponível no momento, é praticamente impossível
impedir que um ataque aconteça. Não existe um mecanismo único que forneça uma solução
para esse problema. Desta forma, foi introduzido o conceito de segurança em profundidade,
que faz uso de várias camadas de segurança, englobando os sistemas de informação e as
redes que os interligam.
Existem diferenças fundamentais na segurança voltada para o mercado corporativo,
onde se depara com a utilização de tecnologias avançadas, alta capacidade de tráfego, alta
disponibilidade e gerenciamento de estações, quando comparadas à segurança voltada

para o mercado doméstico, do usuário da internet. Esta pesquisa contribui com a resolução
dos problemas de corporações.
A necessidade de proteção deve ser definida em termos das possíveis ameaças e
riscos e dos objetivos de uma organização formalizados em uma política de segurança.
2.1 Políticas de Segurança
Uma política de segurança é a expressão formal das regras pelas quais é fornecido
acesso aos recursos tecnológicos da empresa. Ou seja, é um conjunto de leis, regras e
práticas que regulam como uma organização gerencia, protege e distribui suas informações
e recursos. Um sistema é considerado seguro em relação a uma política de segurança, caso
garanta o cumprimento das leis, regras e práticas definidas na mesma.
O principal propósito de uma política de segurança é informar aos usuários, equipe e
gerentes, as suas obrigações para a proteção da tecnologia e do acesso à informação. A
política deve especificar os mecanismos através dos quais estes requisitos podem ser
alcançados. Outro propósito é oferecer um ponto de referência a partir do qual se possa
adquirir, configurar e auditorar sistemas computacionais e redes, para que sejam adequados
aos requisitos propostos. Portanto, uma tentativa de utilizar um conjunto de ferramentas de
segurança na ausência de pelo menos uma política de segurança implícita não faz sentido.
Uma política de uso apropriado pode também ser parte de uma política de
segurança. Ela deve expressar o que os usuários devem e não devem fazer em relação aos
diversos componentes do sistema, incluindo o tipo de tráfego permitido nas redes. Essa
política deve ser tão explícita quanto possível para evitar ambigüidades ou maus
entendimentos.
As decisões que um administrador toma ou deixa de tomar, relacionadas à
segurança, irão determinar a quão segura ou insegura é a rede, quantas funcionalidades ela
irá oferecer, e qual será a facilidade de utilizá-la. No entanto, não se consegue tomar boas
decisões sobre segurança, sem antes determinar quais são as metas de segurança. Até que

sejam determinadas, não se poderá fazer uso efetivo de qualquer coleção de ferramentas
de segurança, pois simplesmente não se sabe o que checar e quais restrições impor.
Os objetivos devem ser formulados a partir das seguintes determinantes:
a. Serviços oferecidos versus Segurança fornecida
Cada serviço oferecido para os usuários carrega seus próprios riscos de segurança.
Para alguns serviços, o risco é superior ao benefício do mesmo, e o administrador deve
optar por eliminar o serviço ao invés de tentar torná-lo menos inseguro.
b. Facilidade de uso versus Segurança
O sistema mais fácil de usar deveria permitir acesso a qualquer usuário e não exigir
senha, isto é, não haveria segurança. Solicitar senhas torna o sistema um pouco menos
conveniente, porém mais seguro. Requerer senhas "one-time" geradas por dispositivos,
torna o sistema ainda mais difícil de utilizar, mas bastante mais seguro.
c. Custo da segurança versus o Risco da perda
Há muitos custos diferentes para segurança: monetário (o custo da aquisição de
hardware e software como firewalls, e geradores de senha "one-time"), desempenho
(tempo cifragem e decifragem), e facilidade de uso. Há também muitos níveis de risco:
perda de privacidade (a leitura de uma informação por indivíduos não autorizados),
perda de dados (corrupção ou deleção de informações), e a perda de serviços (ocupar
todo o espaço disponível em disco, impossibilidade de acesso à rede). Cada tipo de
custo deve ser contra balanceado ao tipo de perda [7].

Ilustração 2.5 – Processos para implementação de segurança.
Pode haver requisitos regulamentares que afetem alguns aspectos da política de
segurança (como a monitoração). Os criadores da política de segurança devem considerar a
busca de assistência legal na criação da mesma. No mínimo, a política deve ser revisada
por um conselho legal.
2.2 Crimes Computacionais
A era da Internet é cada vez mais presente na vida das pessoas. Esta por sua vez,
tende a trazer grandes benefícios para o cotidiano dos seres humanos. Contudo, nem
sempre há o uso devido das tecnologias. Da mesma forma ocorre com a Internet: é possível
usá-la para o bem ou para o mal.
Entre os males causados pelo uso indevido da Internet, pode-se citar os crimes
virtuais. O conjunto de normas, princípios e instruções que regulam as relações jurídicas
emergentes da atividade informática, constitui a intersecção entre direito e informática.
O crime virtual está por todo o mundo, inclusive no Brasil, mais nem sempre é
publicado, e não se restringe somente ao vírus digital. Isso ocorre pelo fato de que os
computadores se tornaram populares e estão ao alcance de todos. Por sua vez, a ética nem

sempre engloba os princípios da Informática, fazendo com que a segurança nos
computadores seja deturpada.
Atualmente, para os usuários da Internet não existe limite para o crime por
computador, pois a fiscalização é muito fraca.
No Brasil existem inúmeros casos de crimes virtuais, onde, segundo fontes como
revistas, jornais e documentários, pode-se notar que este assunto não é tão recente quanto
parece. Existem alguns tipos de diversificações de denominações referentes a este assunto,
que são:
• Computer crime;
• Abuso de computador;
• Crime de computação;
• Criminalidade mediante computadores;
• Delito informático;
• Fraude informática;
• Delinqüência econômica;
• Computer kriminalistat;
Conceituando crime informático, para a Cooperação Econômica e Desenvolvimento
(OECD): "Computer crime é qualquer conduta ilegal, não autorizada, que envolva
processamento automático de dados e/ou transmissão de dados”.
Um crime pode ser realizado com base nas diferentes áreas de um computador,
como na unidade de entrada, na de saída, na unidade central de processamento, num
dispositivo de armazenamento ou de transmissão de informações. Sendo que os crimes
ocorrem de acordo com a criatividade do agente.
Segundo Ulrich Sieber, os crimes podem ser classificados da seguinte forma:
• Fraude por manipulação de um computador contra um sistema de processamento de
dados;

• Espionagem informática;
• Furto de tempo;
• Acesso não autorizado a sistemas;
• Ofensas tradicionais;
Segundo C.M Romeo Casabona são:
• Manipulação de entrada de dados (input);
• Manipulação no programa;
• Manipulação na saída de dados (output);
• Manipulação a distância;
Totalmente ligados ao computer crime, estão os Hackers. Os Hackers interagem com
os demais dentro de uma estrutura anarquista, sem liderança forte ou padrão rígido a seguir.
E tem como finalidade desbravar novos horizontes, mesmo que o objetivo principal seja a
infiltração de valores novos para a sociedade, a contra cultura.
2.3 Firewalls
Firewall é o mecanismo de segurança interposto entre a rede interna e a rede
externa com a finalidade de liberar ou bloquear o acesso de computadores remotos aos
serviços que são oferecidos em um perímetro ou dentro da rede corporativa. Este
mecanismo de segurança pode ser baseado em hardware, software ou uma mistura dos
dois.
O firewall é o ponto de conexão com a rede externa, tudo o que chega à rede interna
deve passar pelo firewall, ele é também o responsável por aplicar as regras de segurança,
autenticar usuários, registrar tráfego para auditoria e deve limitar a exposição dos hosts
internos aos hosts da Internet, para que elas não seja alcançáveis, por exemplo, o servidor
de banco de dados. Entretanto, algumas tarefas não podem ser executadas, como, proteger

a rede contra usuários internos mal intencionados, conexões que não passam por ele,
ameaças novas, no qual ele não foi parametrizado para executar uma ação.
Um ataque pode ocorrer explorando as vulnerabilidades do aplicativo em máquinas
protegidas por firewalls com listas permitindo o acesso. São três os fatores em risco: a
reputação, os computadores e as informações guardadas; e são três os fatores precisam ser
resguardados: a privacidade, a integridade e a disponibilidade. Existem situações de riscos
como, roubo de conexão depois dela ter sido autenticada, espionagem de dados secretos
enquanto em trânsito pela rede e um usuário não autenticado convence a rede que ele foi
autenticado.
O firewall não deve ser substituído por IPS, deve existir uma barreira de segurança
adicional na rede.
2.4 Ameaças e Ataques
Uma ameaça consiste em uma possível violação da segurança de um sistema.
Algumas das principais ameaças às redes de computadores são:
• Destruição de informação ou de outros recursos
• Modificação ou deturpação da informação
• Roubo, remoção ou perda de informação ou de outros recursos
• Revelação de informação
• Interrupção de serviços.
2.4.1 Classificação
As ameaças podem ser classificadas como:
• Acidentais ou Intencionais
• Ativas ou Passivas

Ameaças acidentais são as que não estão associadas à intenção premeditada. Por
exemplo, descuidos operacionais e bugs (falhas) de software e hardware. A concretização
das ameaças intencionais variam desde a observação de dados com ferramentas simples
de monitoramento de redes, a ataques sofisticados baseados no conhecimento do
funcionamento do sistema.
Ameaças passivas são as que, quando realizadas, não resultam em qualquer
modificação nas informações contidas em um sistema, em sua operação ou em seu estado.
Uma estação que processa todos os quadros que recebe em uma rede local (incluindo os
que não são a ela endereçados) é um exemplo de realização de uma ameaça passiva. Uma
realização de ameaça ativa a um sistema envolve a alteração da informação contida no
sistema, ou modificações em seu estado ou operação. Uma estação de uma rede em anel
que não retransmite mensagens quando deveria fazê-lo (ela não é a responsável pela
retirada da mensagem do anel) é um exemplo de realização de uma ameaça ativa.
2.4.2 Tipos de Ataques
A materialização de uma ameaça intencional configura um ataque. Alguns dos
principais ataques que podem ocorrer em um ambiente de processamento e comunicação
de dados são:
• Personificação (masquerade): uma entidade faz-se passar por outra. Uma entidade
que possui poucos privilégios pode fingir ser outra, para obter privilégios extras
• Replay: Uma mensagem, ou parte dela, é interceptada, e posteriormente transmitida
para produzir um efeito não autorizado. Por exemplo, uma mensagem válida,
carregando informações que autenticam uma entidade A, pode ser capturada e
posteriormente transmitida por uma entidade X tentando autenticar-se no sistema
(possivelmente personificando a entidade A).
• Modificação: O conteúdo de uma mensagem é alterado implicando em efeitos não
autorizados sem que o sistema consiga detectar a alteração.

• Recusa ou impedimento de serviço: ocorre quando uma entidade não executa sua
função apropriadamente ou atua de forma a impedir que outras entidades executem
suas funções. Uma entidade pode utilizar essa forma de ataque para suprimir as
mensagens, por exemplo, direcionadas a entidade encarregada da execução do
serviço de auditoria de segurança. Outro exemplo de utilização dessa forma de
ataque é a geração de mensagens com intuito de atrapalhar o funcionamento de
algoritmos de roteamento.
• Ataques internos: Ocorre quando usuários legítimos comportam-se de modo não
autorizado ou não esperado
• Armadilhas (trapdoor): Ocorre quando uma entidade do sistema é modificada para
produzir efeitos não autorizados em resposta a um comando (emitido pela entidade
que está atacando o sistema) ou a um evento, ou seqüência de eventos
predeterminado. Um exemplo desse ataque seria a modificação do processo de
autenticação de usuários para dispensar a verificação da senha em resposta a uma
combinação de teclas específica, por exemplo, “Ctrl+Alt+U”, ou a um evento do tipo
“hora do sistema 23:35:00”
• Cavalos de Tróia: Nesse ataque, uma entidade executa funções não autorizadas. Um
procedimento de login modificado, que além de sua função normal de iniciar a
sessão de trabalho dos usuários, grava suas senhas em um arquivo desprotegido, é
um exemplo de Cavalo de Tróia
2.4.3 Exemplos de Ataques
2.4.3.1 Backdoors
Antigamente, todo sistema tinha uma "porta dos fundos" (ou backdoor), por onde o
criador do sistema poderia entrar a qualquer hora, independente de quem fosse o
responsável pelo mesmo.

O autor garantiria sua entrada criando uma passagem secreta, que somente ele
saberia o local.
Há algum tempo vários programadores deixavam sempre um local por onde eles
poderiam passar no futuro. Hoje isso é mais difícil, pois existem muito mais pessoas
interessadas em procurar falhas do que antes.
De qualquer forma, quando se fala em "encontrar uma backdoor" ou "deixar uma
backdoor em algum sistema", geralmente, refere-se a uma característica secreta e
obviamente não documentada que permite o acesso de quem implantou esta backdoor.
É perfeitamente possível existir backdoors em scripts de IRC, programas de FTP, ou
qualquer outro serviço encontrado pela Internet. Portanto, os programas devem ser bem
escolhidos.
Algumas versões de Cavalos de Tróia possuem a capacidade de se anexar a outros
programas, fazendo com que este se transforme em uma backdoor, sem que se perceba
nada de diferente no sistema.
2.4.3.2 Portscan
Portscan é o processo de conexão em diversas portas TCP/UDP com o intuito de
identificar quais portas estão em listening, ou seja, aptas para receber uma conexão. Deste
modo é possível identificar alguns dados sobre o sistema, assim como serviços (TCP/UDP)
que o mesmo executa, sistema operacional, etc.
Existem 6 tipos de Portscans:
• TCP Connect Scan: Este tipo de Portscan conecta na porta de destino e completa as
3 etapas do Handshake (completar a conexão): SYN - SYN/ACK - ACK. Ou seja:
envia o SYN, recebe o SYN/ACK e retorna o ACK novamente. Este tipo de Portscan
é facilmente detectado pelo destino, devido o fato de completar as conexões (3
etapas do handshake).

• TCP SYN Scan: O TCP Syn Scan por outro lado, emprega uma técnica chamada
half-open scanning, ou seja: A conexão TCP não é realizada por completo. O Pacote
SYN é enviado ao destino, se o destino retornar o pacote SYN/ACK é porque
provavelmente a porta esta disponível. Ao não enviar o terceiro pacote (ACK) evita-
se do Portscan ser logado pelo sistema (Ao menos nas ferramentas mais
rudimentares).
• TCP FIN Scan: Funciona somente em Unix Based, enviando um pacote FIN na porta
de destino, o mesmo responde com um sinal RST para todas as portas fechadas.
• TCP Xmas Tree Scan: Deste modo, o host fonte envia 3 pacotes (FIN, URG e PUSH)
para o host remoto, o mesmo retornando com um pacote RST para todas as portas
fechadas.
• TCP Null Scan: Esta técnica 'desliga' todas as flags, o host remoto. Também envia
pacotes RST para todas as portas fechadas.
• UDP Scan: Com o UDP scan, o host envia um pacote UDP pra determinada porta no
host de destino. Se o host responde com um sinal ICMP 'ICMP Port Unreachable', a
porta esta fechada, se não recebe esta resposta, pode-se deduzir que a porta esta
aberta.
2.4.3.3 Exploits locais e remotos
Exploits locais são programas geralmente feitos em C que exploram a
vulnerabilidade de programas e sistemas para ganhar acesso root (de administrador). 90%
dos exploits são para sistemas Linux. Os exploits locais são scripts em C que irão rodar no
servidor a partir de uma shell adquirida , os exploits locais são os melhores de se usar , por
sua variedade e confiança de acesso (desde que se saiba o que está fazendo). Alguns
possuem pequenos trojans para dar acesso ao desenvolvedor. Existem vários tipos de
exploits locais, cada um com sua função e seu jeito de executar.

Os Exploits remotos como o próprio nome já diz, são parecidos com os exploits
locais, no entanto, não precisam de uma shell para “hackear” a máquina desejada, o que é
necessário é uma base para rodá-lo, geralmente um sistema UNIX/Linux, pois esses
exploits são, em geral, em C ou Perl; os exploits remotos exploram bugs remotamente,
dando a hackers1 acesso privilegiado no sistema.
2.5 Intrusão
De forma simples, pode-se dizer que um intruso é alguém que tenta invadir um
sistema ou fazer mau uso do mesmo. Uma intrusão pode ser definida como qualquer
conjunto de ações que tentem comprometer a integridade, confidencialidade ou
disponibilidade dos dados e/ou do sistema.
Para se diferenciar as ações legítimas das nocivas, faz-se necessária a definição da
política de segurança.
É comum pensar que uma instituição está sujeita, na maior parte do tempo, as
tentativas de invasão externas, ou seja, ataques originados de fora da instituição,
geralmente da Internet. No entanto, estudos revelam que a maior porcentagem de ataques
tem origem dentro da própria instituição (intrusos internos), que poderia melhor conhecer a
topologia da rede, que sabe onde os dados sensíveis estão armazenados e quais são os
recursos de segurança disponíveis.
Levando-se em consideração o fato de que a maioria dos mecanismos de segurança
é implementado com o objetivo de proteger a instituição dos ataques externos, muitos
ataques ocorrem e muitas vezes não são notados; ou, quando o são, já é tarde demais. Faz-
se necessário, então, um mecanismo que previna os dois tipos de ataque, uma tentativa
externa ou interna. Um IPS eficiente previne os dois tipos de ataques.
1
Hackers são pessoas com grande conhecimento de sistemas operacionais e linguagens de
programação que utilizam disso para explorar fraquezas de outras máquinas

2.5.1 Classificação de uma Intrusão
Todas as intrusões devem estar definidas na política de segurança. Enquanto não for
definido o que é permitido e o que não é permitido no sistema, é inútil tentar entender uma
intrusão.
Uma intrusão pode ser definida como qualquer conjunto de ações que tentem
comprometer a integridade, confidencialidade ou disponibilidade dos dados e/ou do sistema.
Pode-se classificar as intrusões em duas classes principais:
• Intrusão devido ao mau uso do sistema - são os ataques realizados a pontos fracos
do sistema (pontos conhecidos). Eles podem ser detectados a partir da monitoração
de certas ações.
• Intrusão devido a mudança de padrão - são detectados com a observação de
mudanças de uso em relação ao padrão normal do sistema. Primeiro monta-se um
perfil do sistema, em seguida, através de monitoração, procura-se por divergências
significantes em relação ao perfil construído.
Como a intrusão de mau uso segue padrões bem definidos, ela pode ser descoberta
através da comparação de padrões em relação a auditoria do sistema. Por exemplo, uma
tentativa de criar um arquivo com set UID root pode ser detectada através da análise dos
logs realizados pela chamadas ao sistema.
Uma intrusão devido a mudança de padrões é detectada observando-se divergências
significantes em relação a utilização normal do sistema. Pode-se construir um modelo a
partir de valores derivados da operação do sistema. Estes valores são apurados a partir de
parâmetros do sistema, tais como utilização da CPU, número de conexões por minuto,
número de processos por usuário, entre outros.
Uma variação significativa nestes padrões pode ser um indício de intrusão. Devido
ao grupo de valores que podem definir a utilização normal do sistema, pode-se assumir o
seguinte:

• A exploração das vulnerabilidades de um sistema envolve a utilização
indevida/anormal do sistema; então, podem ser descobertas violações de segurança
a partir de padrões anormais de uso de sistema.
• Intrusões devido à mudança de padrões são difíceis de serem detectadas. Não
existe um padrão fixo que possa ser monitorado, desta forma deve-se trabalhar com
aproximação. O ideal seria a combinação de padrões humanos com programas.
Desta forma, o sistema seria monitorado constantemente a procura de intrusão ao
mesmo tempo em que teria a capacidade de ignorar as ações de usuários legítimos.
2.5.2 Detecção de uma Intrusão
Muitas ferramentas de IDS realizam suas operações a partir da análise de padrões
do sistema operacional e da rede tais como: utilização de CPU, I/O de disco, uso de
memória, atividades dos usuários, número de tentativas de login, número de conexões,
volume de dados trafegando no segmento de rede, entre outros. Estes dados formam uma
base de informação sobre a utilização do sistema em vários momentos do tempo, outras já
possuem bases com padrões de ataque previamente montadas permitindo também a
configuração dos valores das bases bem como inclusão de novos parâmetros.
Com estas informações, uma ferramenta de IDS pode identificar as tentativas de
intrusão e até mesmo registrar a técnica utilizada.

3 SISTEMAS DE DETECÇÃO DE INTRUSÃO
Um Sistema de Detecção de Intrusos (IDS) é uma ferramenta de Segurança
Computacional que se bem desenvolvida e programada poderá ser aliada a outros
dispositivos de segurança, como firewall, para incrementar a proteção dos sistemas e dados
da rede.
Um IDS é uma aplicação que detecta ataques na rede ou no computador. O IDS
pode ajudar a tratar ameaças em invasões na rede ou em sistemas computacionais. Segue
alguns benefícios de se usar um IDS:
• Detectar um ataque: O IDS pode informar se existe um worm na rede, se a mesma
está sendo atacada ou se um computado está comprometido.
• Fortalecer políticas: Um IDS pode monitorar uma rede interna para verificar o
comportamento da rede interna e o uso de políticas aceitáveis.
• Proporcionar trilhas de auditoria: O IDS pode prover uma trilha de auditoria, para se
saber como começou o ataque e de onde ele veio.
• Justificativa do recurso: Um IDS pode armazenar informações sobre como o firewall
está trabalhando e exatamente quantas pessoas estão “de fora”. Essa informação é
muito importante quando justificativas para o melhoramento do firewall e de recursos
da rede são necessários.
Dessa forma, um IDS constitui uma segunda linha de defesa, que tem sido o foco de
muitas pesquisas recentemente. Esse interesse é motivado por um bom número de
considerações. Algumas dessas considerações estão listadas a seguir:
• Se um intruso é detectado rapidamente, ele pode ser identificado e retirado do
sistema antes que qualquer dano seja feito. Quanto mais cedo se detectar um
intruso, menos riscos de ações prejudiciais o sistema estará correndo;
• Um sistema de detecção de intrusões eficiente pode servir como um meio de
desencorajar a ação de intrusos;

• A detecção de intrusões habilita a aquisição de informações sobre técnicas de
intrusão que podem ser usadas para reforçar a prevenção na ação de intrusos;
A detecção de intrusões é baseada na suposição de que o comportamento de um
intruso difere do comportamento de um usuário legítimo de forma que possa ser
quantificado. Naturalmente, não se pode esperar que exista uma exata distinção entre um
ataque e uma ação normal de um usuário. Mas usando-se abordagens estatísticas e de
probabilidade pode-se chegar a resultados bastante satisfatórios.
3.1 Tipos de IDS
Basicamente, os IDSes são classificados da seguinte maneira:
• Baseados em Host (Host Based), que realizam análises somente no host ou servidor
onde o mesmo foi instalado;
• Baseados em rede (Network Based), que analisam o tráfego de um segmento
independentemente do número de servidores instalados. Os IDSes baseados em
rede ainda podem ter outras classificações, geralmente baseadas em assinaturas
(signature based) e baseados em tráfego (traffic based).
• Baseados em kernel (Kernel Based), que cuida basicamente de bufferOverflow,
estouro da capacidade de armazenamento temporário.
Essa classificação será mais bem detalhada nos itens a seguir.
3.1.1 IDS baseados em Redes (NIDS)
Sistemas de Detecção de Intrusos baseados em rede são aqueles que monitoram o
tráfego de um segmento de rede inteiro. Uma placa de interface de rede (NIC – Network
Interface Card) pode operar em dois modos:
• Modo normal: onde os pacotes destinados ao computador (como determinado pelo
endereço ethernet ou MAC do pacote) são retransmitidos da rede para o host, e
quadros com outros endereços são descartados pelo host.

• Modo promíscuo: tem o objetivo de analisar todo o tráfego que passa por aquele
segmento de rede, mesmo não sendo destinados para aquela máquina.
Uma placa de rede normalmente pode ser trocada do modo normal para promíscuo,
e vice-versa, usando funções de baixo nível do sistema operacional que diz diretamente a
placa de rede para fazer essa mudança. Sistemas de Detecção de Intrusos baseado em
redes normalmente requerem que a placa de rede esteja em modo promíscuo.
3.1.1.1 Sniffers de Pacotes e Monitores de Rede
Sniffer é um programa ou dispositivo que monitora o fluxo de dados em uma rede.
Sniffers de pacotes e monitores de rede foram projetados originalmente para ajudar no
processo de monitorar o tráfego de uma rede Ethernet.
Esses produtos basicamente capturam todos os pacotes que trafegam na rede, uma
vez capturados, surgem várias possibilidades:
• Pacotes podem ser contados: contando os pacotes e somando seu tamanho total
durante um determinado tempo (incluindo overheads como cabeçalhos de pacotes) é
possível ter uma boa indicação da utilização da rede.
• Pacotes podem ser examinados detalhadamente: por exemplo, seria possível
capturar um conjunto que chega a um servidor Web para diagnosticar algum
problema com o servidor.
Produtos sniffers de pacotes ficaram mais sofisticados nos últimos anos. Programas
como Ethereal e versões mais recentes do Network Monitor podem desmontar vários tipos
de pacotes para mostrar que tipo de comunicação está ocorrendo dentro dos pacotes.
Sniffers de pacotes também podem ser usados de modo destrutivo. Por exemplo, um
sniffer de pacote pode ser usado para descobrir uma senha Unix de alguém observando os
pacotes telnet, pois uma vez que o invasor tenha comprometido a rede, uma de suas
primeiras ações poderia ser a instalação de um sniffer de pacote.

3.1.1.2 Sniffers de Pacotes e Modo Promíscuo
Todos os sniffers de pacotes requerem que a interface de rede esteja em modo
promíscuo. Somente em modo promíscuo todos os pacotes recebidos pela NIC irão ser
repassados para o sniffer. O sniffer normalmente requer privilégios administrativos na
máquina que está sendo executado de forma que o hardware da placa de rede possa ser
manipulado para estar em modo promíscuo.
Outro ponto a se considerar é a utilização de switchs no lugar de hubs numa rede.
Observe que os pacotes recebidos em uma interface de um switch não serão sempre
enviados a outras interfaces do switch. Por isso, em um ambiente que utiliza switchs no
lugar de hubs (segmento único), o uso de sniffers de pacotes freqüentemente será inútil.
Infelizmente, do ponto de vista da segurança, um sniffer de pacote é um benefício
limitado. A tarefa de capturar todos os pacotes da rede, desmontá-los, e manualmente
executar uma ação baseado no conteúdo do pacote é muito demorado, até mesmo para um
grupo de especialistas treinados. Isto é basicamente o que um sistema de detecção de
intrusão baseado em rede faz.
3.1.1.3 Tipos de NIDS
Os IDSes baseados em redes podem eventualmente ser divididos em:
• IDS baseado em assinaturas (signature based), a análise é realizada através de
assinaturas de ataques onde o conteúdo dos pacotes é analisado e comparado com
ataques conhecidos, identificando anomalias através de uma base pré-definida.
• IDS baseado em tráfego (traffic based), a análise é baseada nos cabeçalhos dos
pacotes e, por definição, não há análise de seus conteúdos. Na prática, isto significa
que alguns ataques não serão capturados por um IDS e vice-versa. Também é
verdade que um IDS baseado em tráfego exige um esforço muito maior do
profissional que realizará as análises e identificará dentre o tráfego capturado, o que
é ataque e o que não é. O conceito de falso positivo, onde tráfego legítimo é

considerado ataque erroneamente, é agora transferido para o analista responsável.
Cabe a ele garantir a identificação de ataques através de sua análise.
3.1.1.4 Atividades Principais
Alguns dos tipos de detecção contra intrusos que um IDS baseado em rede pode
realizar estão apresentados a seguir:
• Examinar pacotes que passam pela rede.
• Para pacotes legítimos, permitir sua passagem (talvez os registrando para futura
análise).
• Encerrar a transmissão do pacote enviando as mensagens connection closed do
TCP ou port unreachable do ICMP para o sistema alvo e o que está enviando o
pacote, quando um pacote arrisca a segurança ou integridade de um sistema.
Dessa maneira, um IDS baseado em rede pode executar uma efetiva segunda
camada de defesa para um sistema que está atrás de um firewall, Ilustração 3.1. Algumas
implementações também usam IDS no lugar do firewall, porém, isso não é recomendado.
Sistemas de detecção contra intrusos baseado em rede podem executar,
opcionalmente, algumas outras tarefas, por exemplo:
• Monitorar a rede por Port-scan,
• Monitorar conexões válidas por ataques bem conhecidos,
• Identificar tentativas de falsificações de IP de vários tipos.
Quando uma atividade indesejável é detectada, um sistema de Detecção de Intrusos
baseado em rede pode realizar ações. Essas ações podem incluir interferências no futuro
tráfego do intruso ou reconfigurar um firewall próximo para bloquear todo tráfego
proveniente do computador ou rede do intruso, Ilustração 3.1.

Ilustração 3.6 – IDS como segunda camada de defesa da rede.
3.1.2 IDS baseados em Hosts (HIDS)
Uma vez que um pacote tenha atingido o computador destino, ainda há disponível
uma terceira linha de defesa além do firewall e monitor de rede. Ela é chamada de Sistema
de Detecção de Intrusos baseado em Host, do inglês Host Intrusion Detection System
(HIDS), e está disponível em vários tipos.
3.1.2.1 Tipos de HIDS
Os dois principais tipos de sistemas de Detecção de Intrusos baseado em host são:
• Monitores de rede: monitoram as conexões do host e tentam determinar se
quaisquer dessas conexões representam uma ameaça. Conexões de rede que
representam algum tipo de tentativa de invasão são contra-atacadas. Observe que
estes são diferentes dos sistemas de Detecção de Intrusos baseado em rede devido
a só capturar o tráfego de rede destinado ao host em que está sendo executado, e

não todo tráfego que passa na rede. Por essa razão eles não requerem modo
promíscuo da interface de rede.
• Monitores de host. Estes monitoram arquivos, sistemas de arquivo, logs ou outras
partes do host procurando tipos específicos de atividade suspeita que poderiam
representar uma tentativa de invasão (ou uma invasão bem sucedida). A equipe de
administração de sistemas pode então ser notificada sobre qualquer problema
encontrado.
As principais funções desempenhadas por um IDS de host são:
1. Monitoramento de Conexões
É possível na maioria dos hosts monitorar os pacotes que tentam acessar o host antes
desses pacotes serem passados para a camada de rede do próprio host. Este
mecanismo tenta proteger um host interceptando os pacotes que chegam ao host antes
deles causarem qualquer dano.
Algumas das ações que podem ser tomadas incluem:
o Detectar tentativas de conexão a portas TCP ou UDP não autorizadas, como
tentativas de conectar a portas onde não há serviços. Isto é freqüentemente
indicativo de um possível cracker fazendo um poke around (inspeção) para
encontrar fraquezas.
o Detectar Portscan. De novo, esta é uma questão que deve ser enfocada,
alertando um firewall ou modificando a configuração IP local para negar
acesso ao host de um possível invasor.
2. Monitoramento de Atividade de Login
Apesar dos melhores esforços de administradores de rede e os mais recentes softwares
de Detecção de Intrusos, ocasionalmente um invasor se moverá silenciosamente e
conseguirá conectar em um sistema usando um tipo de ataque desconhecido. O invasor

obterá uma senha de rede por meios desconhecidos (sniffer de pacote ou outra maneira)
e terá a habilidade de entra remotamente no sistema. Procurar por atividade incomum no
sistema é um trabalho de análise. Esse tipo de análise monitora tentativas de logon e
logout, e alerta o administrador do sistema as atividades que são incomuns e
inesperadas.
3. Monitoramento de Atividade do root
O objetivo de todos invasores é obter acesso de superusuário (root) ou administrativo no
sistema que eles têm comprometido. Sistemas com boa manutenção e seguros que são
usados como servidores Web e banco de dados irão normalmente ter pouca ou
nenhuma atividade do superusuário (root) exceto em tempos específicos do dia ou noite
para agendadas manutenções de sistema. Felizmente, os crackers não acreditam em
manutenção de sistema. Eles raramente agem nas janelas de tempo das manutenções
agendadas e freqüentemente trabalham em horas estranhas do dia. Eles realizam
atividades no sistema que são incomuns até mesmo para o mais ativo administrador de
sistema. Há uma linha de defesa: monitorar qualquer ação realizada pelo usuário root ou
administrador do sistema. Muitos sistemas Unix permitem registrar todas as atividades
do usuário root e pacotes como Logcheck podem então examinar estes registros a
procura de atividades incomuns e notificar sobre isso.
Administradores de sistemas operacionais Open Source (código aberto) tem uma opção
final: alterar o kernel para registrar tipos específicos de atividades. Como isso é feito está
fora do escopo desse trabalho, no entanto há vários sites na Internet que detalham como
fazer isso.
4. Monitoramento de Sistemas de Arquivos
Uma vez que um invasor tenha comprometido um sistema (e apesar de suas melhores
esperanças e melhores esforços dos sistemas de Detecção de Intrusos que você
utilizará, ninguém pode contar completamente que um dia um invasor não irá
comprometer um sistema), então começará a mudar os arquivos no sistema. Por

exemplo, um invasor bem sucedido poderia querer instalar um sniffer de pacote ou
Portscan, ou modificar alguns dos arquivos do sistema ou programas para desabilitar
algum método de Detecção de Intrusos.
Instalar um software no sistema normalmente envolve modificar alguma parte do
sistema. Estas modificações normalmente serão na forma de modificar arquivos ou
bibliotecas no sistema.
Programas como Tripwire, Fcheck e AIDE são projetados para detectar quando arquivos
são modificados e alertar o administrador do sistema sobre essas mudanças.
Por exemplo, as seguintes abordagens podem ser utilizadas:
o Criar MD5 ou outro checksum criptográfico de tudo do sistema de arquivo e
armazenar estes em bancos de dados. Quando um arquivo mudar, seu
checksum irá mudar.
o Armazenar a data e hora de criação e modificação de todos os arquivo do
sistema de arquivos. Procure por quaisquer mudanças nesses tempos.
o Manter um registro de qualquer programa suid (executado como root por
qualquer usuário) do sistema. Se quaisquer desses ou mudar ou se um novo
for instalado ou apagado então há um problema.
o Os métodos usados pelo Tripwire, Fcheck e AIDE variam um pouco, mas eles
são todos baseados nos métodos anteriores. Estes programas também se
preocupam em ter certeza de que o banco de dados de checksum
criptográfico conhecido não foi comprometido. Por exemplo, seria possível
para um invasor com conhecimento de sistemas operacionais e softwares de
detecção de intrusos modificar os arquivos do sistema e também modificar o
checksum criptográfico do banco de modo que nada pareceria ter sido
modificado.

3.1.3 IDS baseados em kernel
Sistemas de detecção de intrusos baseados em kernel são uma nova forma de arte e
estão começando a ser utilizados em plataformas mais comuns, especialmente no Linux e
outros sistemas UNIX.
Há dois sistemas principais de detecção de intrusos baseado em kernel disponível
para Linux. Estes são OpenWall e LIDS. Estes sistemas utilizam a abordagem de prevenir
buffer overflows, aumentando a proteção do sistema de arquivos, bloqueando sinais e
geralmente dificultando um invasor de comprometer um sistema. O LIDS também previne
certas ações do usuário root como instalar um sniffer de pacote ou modificar as regras do
firewall.
3.2 Consoles e Sensores
Consoles e sensores são responsáveis pela averiguação do tráfego de um
determinado segmento da rede da empresa, onde normalmente estão localizados recursos
críticos como servidores. Eles não conhecem quem pode ou não acessar determinado
recurso, o que é admitido ser acessado, nem quando o recurso pode ser acessado. Eles
apenas sabem quais são os padrões de tentativa de mau uso dos recursos disponibilizados
naquele segmento. Pode se entender que o console e o sensor ficam à espera de ações
suspeitas e são capazes de avisar quando essas atividades ocorrem.
3.2.1 Gerência
A gerência geralmente é feita por uma console, que é a interface entre o sistema de
detecção de intrusos e o administrador. O console recebe todas as informações que foram
concentradas e serve como apresentação do panorama atual, bem como pode armazenar
um conjunto de registros de todas as ocorrências de mau uso. Essas informações ajudarão

ao administrador determinar qual o perfil de cada uma das tentativas de invasão mais
freqüentes.
Uma verificação de detecção de intrusão é baseada na análise de console do IDS.
Uma empresa, ao comprar um IDS observa os seguintes fatores:
• Real-Time;
• Capacidade de resposta automática;
• Detecções reais;
• Interação do sistema com os sistemas operacionais como Windows Server/UNIX.
Para todas as detecções mostradas no console, o analista tem a oportunidade de
analisar o evento desejado. O sistema determina a construção de um relatório, ao qual o
analista revê e comenta antes de enviar. Um sensor fora da proteção do firewall é definido
para detectar ataques que originalmente venham da Internet. DNS, e-mail, e Servidores
Web são o objetivo principal de todos os atacantes direcionados à Internet. Estes sistemas
de detecção têm interagido com a Internet para uma melhor proteção contra invasões. Desta
forma, deve-se ter um software de IDS que informe bem por meio do console tudo que
acontece na rede.
3.2.2 Sensores
Um sensor é responsável por enviar alarmes para um console de gerenciamento
quando uma atividade não autorizada for detectada. O sensor pode fornecer detalhes da
atividade bem como controlar outros sistemas, como roteadores, para terminar as sessões
não autorizadas.
Um sistema baseado na detecção de intrusão não estará trabalhando corretamente
se o sensor não estiver colocado corretamente.
Apesar de nem todos os ataques poderem ser detectados, um sensor na saída do
firewall é a melhor localização para tentar detectar o ataque. O benefício desse tipo de
localização é que a análise permite determinar quais são os tipos de ataques a que um site

e firewall estão expostos. É recomendado sensores IDSes em todos os segmentos de rede
e IPSes nas interconexões mais importantes, como, por exemplo, redes de parceiros,
Ilustração 3.2.
Ilustração 3.7 – Localização dos sensores.
O lugar mais comum para a localização de um sensor é fora do firewall, mas
certamente não é o único lugar que beneficia a empresa. Muitos sensores podem ser
usados em lugares opcionais para o suporte da segurança, incluindo os seguintes:
• Redes interligadas podem direcionar conexões para clientes e fornecedores muitas
vezes sobre a proteção do firewall pessoal;

• Sub-Redes que parecem ter o objetivo externo (Internet), ou que têm mostrado
indicações de intrusão ou outras irregularidades.
3.2.2.1 Classificação de sensores
De acordo com o seu campo de ação, os sensores podem ainda ser classificados de
dois tipos:
• Sensores de rede: Estes devem localizar-se em segmentos estratégicos, observando
o tráfego da rede, o formato de pacotes, entre outros;
• Sensores de hosts: Estes ficam dentro dos servidores críticos, observando as ações
realizadas no sistema operacional, as ações dos serviços e o comportamento da
pilha TCP/IP.
3.2.2.2 Características de sensores
Os sensores devem interagir entre si a fim de construírem uma matriz de eventos
que tem por objetivo a qualificação do padrão de ataque, minimizando, desta forma, a
ocorrência de alertas falsos (falso positivo).
Outras características fundamentais são: o gerenciamento centralizado, a
possibilidade do sensor interagir com outros elementos de rede como firewall, roteadores e
consoles de gerência; e a possibilidade de construir uma base de conhecimento centralizada
de forma a permitir uma visão ampla do nível de segurança da rede.
Desta forma, quando algum ataque for detectado pelos sensores, torna-se possível
ações de conta-ataque que podem ser: envio de e-mail para o administrador, envio de
mensagem via pager, ativação de alertas nas estações de gerência via SNMP,
reconfiguração de elementos de rede como firewall e roteadores, e até mesmo o
encerramento da conexão através do envio de pacotes de reset (flag RST do TCP) para a
máquina atacante e para a máquina atacada, com o objetivo de descarregar a pilha TCP.
Em um sistema de segurança, uma característica de fundamental importância é o
aprendizado constante com a utilização de estratégias múltiplas.

3.3 Assinaturas
Os programas de Detecção e Prevenção de Intrusão sabem como selecionar uma
política de segurança. Cada sistema de prevenção de intrusos trabalha o fator sites/firewall
em seu Sistema de prevenção de intrusos. Infelizmente, muitas análises que utilizam a
detecção de intrusão não dão importância às políticas dos filtros e procuram apenas
indicadores (assinaturas) de ataques conhecidos. Existem razões preliminares para que isso
aconteça:
• O firewall e o IDS não buscam muita informação;
• O analista não explora a ferramenta.
O resultado é que se o sistema for projetado para aceitar uma política de segurança,
muitos locais podem não adotar a mesma política. A maioria de sistemas de Detecção de
Intrusos muitas vezes não são configurados para combinar com todas as políticas. Isto
sobrecarrega o filtro dos softwares de detecção.
As assinaturas de intrusão estão ainda em desenvolvimento. Não obstante,
softwares de detecção de vírus conseguem filtrar, atualmente, cerca de 20.000 detecções de
assinaturas de vírus. As indústrias de antivírus são capazes de reagir à novos vírus
rapidamente. Freqüentemente, muitos trabalhos são desenvolvidos para analisar uma
assinatura isolada e atualizar o software de antivírus para incluir no filtro o novo código
disponível e distribuí-lo pela Web.
3.4 Estímulos e Respostas
Grande parte dos IDSes possuem altas taxas de falsos positivos. Em outras
palavras, não definem com absoluta certeza se o tráfego que atravessa a rede é prejudicial
ou inócuo e alarmam mesmo quando não há problema. Então, cabe ao analista fazer a
distinção entre um ataque real e um falso positivo. Para tomar essa decisão, é preciso
definir quando um tráfego aparenta ser normal e quando não é. Ou seja, é preciso definir o
comportamento esperado para uma aplicação típica e para os protocolos de rede.

As RFCs são documentos padrões sobre os quais o TCP/IP e a Internet foram
construídos. Elas descrevem como algo deve supostamente trabalhar quando todos seguem
as mesmas regras. Infelizmente os hackers descobriram que diferentes implementações do
TCP/IP reagem de forma diferente com o intuito de violar os padrões definidos nas RFCs.
Esse é um dos principais artifícios de hacking: explorar condições excepcionais que
os desenvolvedores do código TCP/IP não previram. Hackers atentam para a identificação
do sistema operacional, enviando estímulos estranhos e observando as respostas e reações
dos hosts. Existem respostas únicas para os mesmos estímulos dependendo das
circunstâncias e da disponibilidade do serviço requisitado. As respostas também dependem
da capacidade do host ou roteador de responder a uma conexão em particular. Cada
protocolo possui suas respostas esperadas.
Existem inúmeras variações de atividades anormais, com diferentes propósitos.
Algumas tentam evadir a vigilância dos IDSes/IPSes e enganar a filtragem. Outras são
descaradamente hostis. Deve-se tomar cuidado para não confundir atividades que
realmente são respostas normais do host e também entender que programas como o Nmap
usam um estímulo único para deduzir respostas, identificando características peculiares do
sistema operacional.
Não se deve nunca menosprezar as atividades percebidas: um echo reply de
ICMP, não necessariamente significa que o host de origem não seja um agressor. Se há
alguma dúvida quanto a atividade observada, o melhor conselho é examinar todo o
datagrama capturado e verificar seus campos de cabeçalho e dados procurando por
anomalias. Deve-se adotar a atitude de que nada é previsível quando se analisa o tráfego
de uma rede.

4 SISTEMAS DE PREVENÇÃO DE INTRUSÃO
Os Sistemas de Prevenção de Intrusos (IPS) constituem uma nova ferramenta que,
atualmente, é considerada uma das primeiras linhas de defesa de um sistema de
informações. Em poucas palavras, o sistema age através da monitoração silenciosa dos
pacotes de rede, alertando quando identificar uma determinada seqüência que venha a se
concretizar como um ataque. Na maioria dos casos, o IPS toma ações pró-ativas,
derrubando as conexões mal intencionadas antes que venham a causar algum prejuízo para
o sistema protegido.
A prevenção de intrusão é uma tecnologia recente e promissora na área de
segurança de redes. Os sistemas de prevenção de intrusão surgiram como uma evolução
dos IDSes e combinam a capacidade de profunda inspeção de pacotes com características
de filtragem naturais dos firewalls, porém de forma transparente.
A diferença entre IPS e IDS está no fato de que, enquanto os IDSes agem somente
após a ocorrência da intrusão, como um alarme que detecta a presença de um invasor, os
IPSes foram desenvolvidos como medidas de prevenção, como o próprio nome já diz, para
bloquear possíveis ataques antes que eles tenham sucesso, ou pelo menos para limitar
suas conseqüências negativas, caso venham a ocorrer.
IPS e IDS são ferramentas de segurança que se complementam, por isso não podem
ser vistos como soluções opostas. A tecnologia de IPS tem evoluído muito nos últimos
tempos, mas surge como um novo recurso de proteção para uma rede, não como um
substituto a outras tecnologias.
4.1 Surgimento da Necessidade da Pesquisa
IPS é uma adição essencial, mas não constitui um substituto aos firewalls (barreiras
de proteção). Quando esses são configurados corretamente evitam o tráfego indesejável.
Uma vez que o intruso tenha acesso a um sistema dentro da rede, outros sistemas

tornam-se vulneráveis, e embora o firewall não pare esse tipo de ataque, o IPS sim.
Monitorando o tráfego da rede atrás do firewall, o IPS pode detectar e terminar tentativas de
obter acesso não autorizado. Outra vantagem é que utilizando um IPS dentro da rede pode-
se reduzir boa parte do tráfego indesejável, ou seja, mesmo se o administrador escolher não
terminar as conexões indesejáveis, vários alarmes serão gerados pelo IPS para indicar que
o firewall não está fazendo seu trabalho adequadamente.
4.2 Princípios fundamentais
4.2.1 Defesa ativa
Um dos ramos principais e novos da prevenção do intrusos é a chamada defesa
ativa, ao contrário da defesa passiva, como monitoração passiva de sistemas e redes, as
listas de controle de acesso (ACLs) nos roteadores e os firewalls. A defesa ativa significa a
análise da condição dos sistemas e das redes fazendo que é apropriado para tratar o que
está errado. De acordo com Dave Dittrich da Universidade de Washington, há quatro níveis
da defesa ativa:
• Levantamento de dados locais, análise e bloqueio;
• Levantamento remoto de dados externos;
• Levantamento remoto de dados internos; e
• Alterações de dados remotos, supressão do ataque e interdição.
A Ilustração 4.1 mostra uma possível arquitetura da defesa ativa. Os numerosos
hosts dentro de uma rede hipotética coletam dados de detecção de intrusos e emitem a um
analisador central, sempre que apropriado, emite mudanças de políticas aos hosts
individuais, mantém e executam determinadas instruções na memória, mudam o índice de
determinados arquivos, e assim por diante. O firewall externo é a camada mais externa da
infra-estrutura da defesa ativa, detecta ataques relativamente diretos tais como SYN
flooding. Os IDS baseado em rede, dentro dessa rede, recolhem informações dos sensores

localizados no gateways externos e na entrada de diversas sub-redes; envia mudanças de
ACLs para os firewalls e dados aos analisadores centrais onde as bases dos ataques serão
decifrados.
Ilustração 4.8 – Princípio fundamental de defesa ativa.
Um dos fatores mais importantes (e controversos) da defesa ativa e da prevenção de
intrusos está em determinar uma resposta apropriada. A noção da resposta apropriada inclui
uma consideração chamada proporcionalidade de resposta, o que assegura que a resposta
seja proporcional à ameaça. No caso de um host está inundando uma rede com pacotes
fragmentados, bloquear o tráfego desse host, certamente é a resposta mais apropriada. Se
uma grande quantidade de hosts operados por uma ISP atacassem repetidamente uma
organização, o bloqueio de todo o tráfego do range de endereços IPs da ISP, poderia ser
uma possível resposta. Alguns defensores da defesa ativa acreditam que mesmo que um
host remoto esteja atacando repetidamente a rede de uma organização, contra-atacar o
host talvez com a inundação utilizando pacotes fragmentados, causando desse modo um
crash, seria o curso de uma ação apropriada.
Embora a prevenção de intrusos pareça promissor (como mencionado), ainda é
muito recente. As taxas de ataques externos para sistemas de prevenção de intrusos, não
são elevados a ponto de necessitar um excesso de preocupação com ataques.
Adicionalmente os alarmes falsos podem facilmente causar um eficiente DoS em sistemas
individuais. Os sistemas de prevenção de intrusos futuramente, poderão impedir uma

quantidade maior de ataques, não somente a nível de host individuais, mas também dentro
de redes de organizações e possivelmente dentro da própria Internet. A última possibilidade
é particularmente intrigante.
4.2.2 IPS
Os sistemas IPS são similares aos IDSes. Podem ser IPS baseados em hosts
(HIPS), que trabalha melhor protegendo a aplicação ou um IPS baseado em rede (NIPS ou
Inline). As ações do usuário, devem corresponder a ações predefinidas em uma base de
conhecimento; se uma ação não estiver na lista de aceitações, o IPS impedirá a ação. Ao
contrário do IDS, no IPS a lógica deve ser aplicada antes que a ação esteja sendo
executada em memória. Outro método do IPS consiste na comparação dos checksums de
controle de arquivo, há uma listagem de controle de checksums “bons” que é verificada,
antes de permitir que o arquivo seja executado, se não for permitido, o IPS impedirá as
chamadas no sistema.
Um IPS consiste tipicamente em quatro componentes principais:
• Traffic normalizer
• Service scanner
• Detection engine
• Traffic shaper
O traffic normalizer interpreta o tráfego na rede, analisa e reestrutura os pacotes,
assim como executa as funções básicas de bloqueio. O traffic normalizer alimenta a
detection engine e o service scanner. O service scanner, constrói uma tabela de referência,
que classifica a informação e ajuda o traffic shaper a controlar o fluxo de informações. A
detection engine faz uma comparação entre a tabela de referência e determina a resposta
apropriada. A figura abaixo mostra o processo.

Ilustração 4.9 – Arquitetura de IPS.
Os pontos positivos da prevenção de intrusos:
• Protege a camada de aplicação;
• Previne ataques em vez de simplesmente reagir a eles;
• Pode usar uma aproximação de uma forma particular;
• Fornece uma defesa profunda;
• Permite correlação de eventos em real-time;
Os pontos negativos da prevenção de intrusos:
• Gera falso-positivos, que podem criar problemas sérios se as respostas
automatizadas forem usadas;
• Cria gargalos na rede;
• É uma tecnologia nova;
• É caro.
4.2.2.1 Network Intrusion Prevention (NIPS)
A principal diferença entre uma rede com sistema de resposta ativa e uma rede com
IPS é um dispositivo inline, isto é, está situado exatamente no caminho que os pacotes
passam para chegar na rede. Um roteador pode ser um dispositivo inline, pois ele é
responsável pela passagem dos pacotes IP entre redes conectadas.

Quando um IPS está inline, entre um atacante e o sistema-alvo. Não somente os
ataques com grande número de mecanismos podem ser parados, mas também ataques
individuais. O IPS inline não é obrigado a repassar pacotes determinados como maliciosos.
Por exemplo, um IPS inline pode derrubar portas em um switch, interagir com políticas de
firewall externos ou ACLs dos roteadores e gerar tráfego de sessão na camada de
transporte.
Outra contramedida importante disponível nos IPSes inline é a modificação dos
dados na camada de aplicação. Essa técnica permite o IPS alterar o pacote de dados de
modo que os ataques na camada de aplicação torne-se inútil antes de atingir o alvo.
4.2.2.1.1 Contramedidas
Existem 4 classes de contramedidas que um IPS de rede pode utilizar para parar um
ataque na rede. Cada classe aplica-se uma camada da pilha de protocolos. As camadas de
sessão e apresentação do modelo OSI foram colocadas dentro da camada de aplicação.
Abaixo, segue a lista das classes de contramedidas e a lista das camadas correspondentes
na pilha de protocolos:
• Contramedidas na camada de enlace: Administrativamente shutdown na porta do
switch que está saindo o ataque. Essa atitude só é praticável para ataques que são
gerados de um sistema local. Ter a possibilidade de parar a porta é importante,
desde que não seja um shutdown indefinido.
• Contramedidas na camada de rede: Interagir com o firewall externo ou roteador, para
adicionar uma regra geral para bloquear todas as comunicações de endereço IP
individual ou a rede inteira. Um IPS inline pode realizar a mesma coisa sem ter que
apelar para um dispositivo externo, desde que pacotes de um IP específico possa ser
simplesmente bloqueado depois que um ataque foi detectado. Similar a respostas da
camada de enlace, os timeouts são importantes na camada de rede, desde que as
modificações nas regras do firewall ou nas ACLs dos roteadores possam ser
removidas.

• Contramedidas na camada de transporte: Gerar pacotes TCP RST para derrubar
sessões TCP maliciosas ou emitir algum pacote ICMP de erro, dos diversos
disponíveis para responder a um tráfego UDP malicioso. Os timeouts, não são
aplicáveis aqui, porque as bases de contramedidas são dribladas pelo atacante a
cada sessão ou a cada pacote.
• Contramedidas na camada de aplicação: Alertas de dados maliciosos na camada de
aplicação não podem causar danos antes de alcançar o sistema alvo. Essa
contramedida requer que o IPS esteja inline, no caminho da comunicação.
Previamente calculado o checksum na camada de transporte deve ser recalculado
nessa camada. Similar a camada de rede, timeouts não são aplicáveis. Desde que
os efeitos da troca de dados na camada de aplicação sejam transitórios e não
desapareçam uma vez que os pacotes alterados são encaminhados através do IPS
4.2.2.1.2 Resposta ativa baseada em host
Um sistema de resposta ativa para host é normalmente implementado em um
software e é instalado diretamente em um host. Uma vez que um evento suspeito foi
detectado em um host (através do arquivo de log, detecção de um arquivo específico,
chaves de registros associados a algum exploid conhecido, ou um server suspeito
conectado em uma porta alta), um sistema de resposta ativa baseada em host é carregado
com ações. Como em uma resposta ativa baseada em rede, a expectativa para um sistema
de resposta ativa baseada em host as contramedidas não necessariamente prevenirão um
ataque inicialmente bem sucedido. A ênfase está em tentar, amenizar os efeitos e danos
causados por um ataque depois da detecção. Depois que um ataque é detectado, repostas
automáticas, podem incluir alterações de permissões em filesystems, mudando as
permissões de acessos dos usuários ao sistema, automaticamente remover worms ou vírus
do host e então pegar os pasos para remover o código ofendido através das operações
normais do filesystem . O VirusScan é um bom exemplo de antivirus e removedor de
produtos. A adição de novas regras no firewall é uma resposta que normalmente requer o

conhecimento de um endereço IP ofendido o qual, às vezes, pode ser extraído do log do
sistema.
Isso pode ser usado para adicionar uma regra de bloqueio contra um IP ofendido
para uma política de filtro de rede local em reposta a monitoração feita por um backdoor em
um sistema Linux.
4.2.2.2 Host Intrusion Prevention (HIPS)
Existem muitas técnicas de resposta ativa e prevenção de intrusos, que podem ser
colocados a nível de host. Com o acesso direto as APIs do sistema operacional e no próprio
kernel, o realce de segurança tido recursos por um host IPS podem ser importantes. A
prevenção de ataques não é somente alertada, mas há ganho na habilidade de detectar
atividades maliciosas, desde que truques de evasão no network IDS e links encriptados
sejam sem sentido. As técnicas de IPS baseados em host incluem mecanismos que serão
reforçados pelo kernel do sistema operacional, código de específico de aplicações que
rodam diretamente com o processo de endereçamento de espaço de uma aplicação, e
medidas de proteção da pilha que serão reforçados por um compilador especializado (ou
runtime no kernel).
Quando uma aplicação está comprometida, tentará provavelmente executar uma
operação que requer uma chamada de sistema, fornecida pelo kernel (exemplo inicialização
de um novo servidor, escrita no disco, ou fazendo uso de uma interface de rede todos
requerem o uso intervenção do kernel). O mecanismo de prevenção construídos
diretamente no kernel é a única coisa que permite ou nega a qualquer aplicação a
habilidade de executar chamadas no sistema. O Linux Intrusion Detection System (LIDS),
fornece um patch para o Kernel do Linux que implementa restrições a chamadas de sistema.
Também deve ser mencionado que no modelo normal do Unix, enquadra-se na categoria
Discretionary Access Control, que não é tão forte quanto as implementações de segurança

e capacidade de prevenção dos sistemas que implementam o Mandatory Access Control
dentro do Kernel do sistema operacional.
Prevenção de Buffer Overflow é das mais importantes tecnologias HIPS disponível
devido a vulnerabilidades existentes. Métodos de prevenção de buffer overflow (ou pelo
menos os seus efeitos) são categorizadas em tempo de compilação e tempo de execução:
• Métodos de tempo de compilação envolvem modificações especiais de compiladores
que interferem com o objetivo final de um ataque o qual é forçar uma aplicação a
rodar um código arbitrário fornecido pelo atacante;
• Métodos de tempo de execução são fortalecidos pelo Kernel do sistema operacional
que inclui anormalidades como tornar uma pilha não executável.
4.2.2.2.1 Contramedidas
Algumas contramedidas de resposta ativa e preventiva podem ser utilizadas em um
host para responder e mitigar os ataques:
• Modificação no sistema: alteração de permissões no sistema de arquivos, controle
de usuários, remoção de vírus e worm e reconfiguração do conjunto de regras do
firewall local após o ataque. Todas essas são mecanismos de resposta ativa.
• Mecanismos do kernel: O sistema chama mecanismos de interceptações e de MAC
fortalecidos por aplicações de prevenção de kernel, a partir de recursos
comprometidos, o sistema utilizado por um atacante durante e após tê-lo
comprometido é finalizado usando os serviços providos pelo kernel;
• Prevenção de buffer overflow: medidas de uso de tempo de compilação e tempo de
execução.
4.3 Riscos e impactos
A promessa da proteção de intrusão é muito atrativa, mas há alguns riscos que não
são tão óbvios. Estes riscos devem ser considerados no planejamento de utilização de um
IPS – incluindo o Snort que opera em uma das modalidades do IPS. Sem dúvida há lugar

para o IPS na maioria de ambientes. O mais freqüente e pode ser melhor utilizado como
uma outra camada em uma estratégia robusta de defesa profunda. Alguns dos riscos
associados ao IPS são:
a. Interceptação de sessão e identificação do IPS
Quando um sensor do Snort detecta um ataque e termina uma sessão TCP com o envio
de um pacote RST, as características do pacote podem permitir que o atacante descubra
não só que um IPS foi responsável pela finalização da sessão, mas também sobre que
tipo de sistema, o IPS está rodando. Existem algumas ferramentas que analisam como
os sistemas operacionais tratam e transmitem os pacotes, com isso podem fazer uma
suposição sobre o funcionamento do Sistema operacional. Uma dessas ferramentas, é o
p0f (Passive OS fingerprint Tools). Ele simplesmente fica escutando os pacotes na rede ,
o p0f, pode determinar que tipo de máquina emitiu pacote de RST, permitindo ao
atacante descobrir que um IPS está emitindo tais pacotes. Sabendo disso o atacante
pode procurar uma forma de passar ou tornar o IPS inoperante.
b. Quebrar o bloqueio com um Exploid
Se houver um rápido retardo entre a detecção do ataque pelo IPS e uma mudança na
lista de controle de acesso no dispositivo de borda. O ataque poderá acontecer com a
utilização de um exploid, para estabelecer uma conexão através de um backdor. Mesmo
quando se utiliza o IPS e tudo está conforme o planejado, o dispositivo de borda, pode
está atrasado, o que é um outro argumento para adotar uma política de defesa profunda.
c. Auto-imposição Negação de serviço
Alterar o endereço IP de origem em um pacote é uma coisa trivial. O pacote chega ao
IPS e dispara uma solicitação de alteração na lista de controle de acesso em um
roteador ou firewall de borda, obstruindo assim o endereço de origem alterado. Se o
endereço alterado é um sistema que a rede necessita, resultará em uma condição de
negação de serviço. O spoofing de DNS, impede a resolução de nomes, spoofing em um
servidor de e-mail impede a distribuição dos mesmos, pares de roteadores de borda

(vizinhos BGP) com o endereço alterado, podem para todo o tráfego de internet. A
maioria das soluções de IPS tentam fazer uma lista de exclusão (lista branca), que
contenha endereços que nunca poderão ser bloqueados, impedindo assim a negação de
serviço. O único problema é assegurar que a lista de exclusão esteja completa.
d. Bloqueio de tráfego legitimo
Se um tráfego correto é identificado de forma errada, como um ataque ou um tráfego
bloqueado, isso terá sérias conseqüências. Por exemplo uma empresa que possui um
comercio baseado em web, possui o seu tráfego bloqueado isso acarretará em perda de
dinheiro.
Não há nenhuma regra real a ser seguida. Tem que conhecer como a rede opera de
forma normal (mesmo de forma extrema, mas normal). A melhor dica é deixar o IPS
rodando em modo de teste durante um período de tempo, prestando atenção no
funcionamento do IPS em vários horários, ajustando os pontos iniciais e os alertas de
modo que o tráfego legitimo não seja bloqueado. Uma análise completa de eventos
bloqueados deve ser feita sobre o curso de vida do IPS para assegurar exatidão nos
testes.
Falsos positivos podem causar no IPS bloqueio de tráfego legítimo. Um cuidado extremo
deve ser tomado para permitir somente a obstrução de alertas que dificilmente geram
falsos-positivos . Essas precauções podem permitir que alguns ataques ocorram, mas
não os ataques que certamente causarão problemas.
4.4 Soluções disponíveis no mercado
Alguns IPSes disponíveis no mercado serão descritos e algumas das características
identificadas devem ser observadas ao escolher um Sistema de Prevenção de Intrusos. Os
sistemas aqui examinados representam um espectro do que está disponível, incluindo
pesquisas, sistemas comerciais e sistemas com código aberto, no entanto, muitos outros
estão surgindo dia a dia.

Nem sempre é fácil identificar a melhor solução de detecção de intrusos a ser
implantada. Requisitos técnicos, preços elevados e disponibilidade de recursos, sejam
tecnológicos ou humanos, são alguns motivos que podem inviabilizar a instalação das
ferramentas. Logo, descobrir qual é o melhor sistema ou o mais indicado para um certo
ambiente não é uma tarefa fácil.
4.4.1 Ferramentas gratuitas
No contexto das ferramentas de distribuição gratuita, pode-se citar as seguintes:
4.4.1.1 Snort Inline
O Snort é uma aplicação de segurança desenvolvida por Marty Roesch baseado na
licença GNU/GPL. As três principais funções de detecção: examinador de pacotes (packet
sniffer), registrador de pacotes (packet logger) ou um NIDS.
O Snort_inline, desenvolvido inicialmente por Jed Haile, surgiu como um patch para o
Snort. O Snort_inline é um Intrusion Prevention System (IPS) que usa assinaturas de
Intrusion Detection System (IDS) existentes para tomar as decisões dos pacotes que
passam por ele. Ele usa novos tipos de regras de como serão tratados esses pacotes, por
exemplo, descarta ou rejeita.
O Snort está se tornando rapidamente a ferramenta mais escolhida para prevenção e
detecção de intrusões e, por ser objeto de estudo deste projeto, será descrito com mais
detalhes nos próximos capítulos.
4.4.1.2 LIDS
LIDS (Linux Intrusion Detection System) é um sistema de detecção de intrusão, feito
para proteger sistemas de invasão pelo root. Ele funciona desabilitando algumas funções do
sistema, quando for preciso fazer operações de administração do sistema, pode-se
desabilitar o LIDS.[16]

LIDS é um conjunto indispensável de ferramentas que vem sofrendo muitas
melhorias nos últimos anos e que ele está no auge do seu potencial com a versão 2.4.24 e
2.6 do kernel do Linux.
As ferramentas que acompanham o LIDS são muito fáceis de utilizar e configurar.
Quem trabalha com segurança e deseja alcançar um nível superior de segurança dentro do
seu sistema.
O LIDS, não é uma ferramenta para se utilizar em micros de usuários devido a
robustez de sua configuração, o que causaria uma série de problemas que o tornam de
certa forma inviável, sendo que também temos ótimas ferramentas de IDS para Linux que
usuários podem utilizar, como Snort, Portsentry, entre outras.
Com o LIDS pode-se restringir qualquer acesso sistema e ele manterá o
administrador totalmente informado de tudo que esta havendo no sistema, qualquer tentativa
de burlar sistemas protegidos pelo LIDS é documentada em emails e nos logs.
4.4.1.3 SnortSam
O SnortSam é um agente que se comunica com o Snort para reconfigurar um (ou
mais) firewalls de modo a impedir conexões hostis.
O Snort possui um plugin que lhe permite interagir diretamente com a firewall, no
entanto, este não é muito flexível.
Para funcionar com o SnortSam, é necessário instalar um plugin no Snort de modo
que estes possam interagir.
Com a criação do Conceito de Agente (SnortSam) e Sensor (Snort), pode-se retirar o
tráfego ao sensor, aumentando a sua performance, e criar uma rede paralela à do tráfego
(uma hipótese) com o(s) sensor(es) e agente(s) a comunicarem entre si, possibilitando que
um único sensor que tenha detectado um ataque de um determinado host, proceda a uma
ordem de bloqueio para diversos firewall de uma vez só.

O único trabalho do SnortSam (instalado diretamente no FW) é aceitar pedidos dos
seus sensores (pode ter vários), verificando a autenticidade se para isso tiver sido
configurado, e atuar sobre o seu firewall.
4.4.2 Ferramentas comerciais
WatchGuard, NetScreen, Top Layer, Lucid Security, TippingPoint, Vsecure
Technologies, Network Associates, ISS, Enterasys, Arbor Networks, Secos, NFR, Nitro
Security, CA, SourceFire, Tripwire, Ubizen, Symantec.
4.4.2.1 TippingPoint
Intrusion Prevention System (IPS) TippingPointTM garante aos clientes protecção
antiphishing sem quaisquer custos adicionais. A TippingPoint, uma divisão da 3Com, foi uma
das primeiras soluções globais baseada em rede para bloquear os ataques de phishing e
prevenir o roubo de identidades.
O IPS utiliza vários mecanismos para detectar e evitar as ações de phishing,
incluindo proteção contra vulnerabilidades, proteção baseada na detecção de padrões e
proteção baseada no comportamento.
O phishing ocorre quando um perpetrador se faz passar por uma organização
legítima por forma a obter informações pessoais ou financeiras de um indivíduo e utilizá-las
para fins fraudulentos. Dado que, regra geral, as ações de phishing parecem provir de uma
fonte confiável, é extremamente difícil evitá-los e podem acarretar grandes custos para
aqueles que são atacados.
Os phishers utilizam várias etapas no processo do roubo de identidade e o IPS
TippingPoint bloqueia cada uma das fases dessas tentativas.
4.4.2.2 SourceFire
Hoje, as realidades de um perímetro se dissolvendo e aquantidade de sistemas de
detecção de intrusão (IDS) e sistemas de prevenção de intrusão (IPS) estão levando

empresas a repensar seus paradigmas de segurança de rede e utilizar um approach mais
eficaz.
A SourceFire, criou o conceito SourceFire 3D - Descobrir, Determinar e Defender - é o
primeiro e único sistema de defesa de rede inteligente e detalhado que unifica tecnologias
de intrusão e gerenciamento de vulnerabilidade para fornecer aos clientes a segurança de
rede em tempo real mais efetiva para os desafios do mundo de hoje.
O conceito SourceFire 3D é um processo de descobrir riscos, vulnerabilidades e
ameaças em tempo real, totalmente integrado; determinando o impacto nos negócios; e
tomando a ação mais precisa e apropriada para defender a rede.
O sistema SourceFire 3D, incluindo SourceFire Intrusion Sensors e Agentes,
SourceFire RNA Sensors e o SourceFire Defence Center, oferece a maior segurança efetiva
disponível. Na verdade, todos appliances SourceFire são Plug-n-Protect para o mais baixo
custo de propriedade. Cada appliance inclui hardware, software, sistema operacional e
banco de dados - pré-instalados para facilidade de instalação, ajustado para alto
desempenho e auto-manutenção.

5 SNORT
O Snort foi originalmente desenvolvido em 1998 por Marty Roesch apenas como
sniffer, hoje é um sistema de detecção/prevenção de intrusão leve, capaz de realizar análise
de tráfego e registro de pacotes em tempo real em redes IP, porém suporta outras, como
IPX, por meio de extensões personalizadas. Ele pode realizar análise de protocolos,
similaridades ou pesquisa de conteúdo e pode ser utilizado para detectar uma variedade de
ataques e exames, como buffer overflows, stealth port scans, ataques CGI, exames de
SMB, tentativas de OS fingerprint e muito mais. O Snort utiliza uma linguagem de regras
flexível para descrever o tráfego que é coletado ou passado por ele, bem como um
mecanismo de detecção que utiliza uma arquitetura modular do tipo plug-in. Além disso, o
Snort tem uma capacidade de alertar os dados em tempo real, bem como incorpora
mecanismos de alerta para syslog, para um arquivo especificado pelo usuário, para um
socket UNIX ou até mesmo mensagens do tipo WinPopup para clientes Windows utilizando
smbclient.
Snort tem quatro principais funcionalidades. Ele pode ser configurado nos modos:
• Sniffer (farejador), onde simplesmente lê os pacotes da rede e exibe as informações
continuamente na tela, visualizável por:
# snort -v
• Packet Logger (registrador de pacotes), onde os registros dos pacotes são
armazenados em disco, útil para depuração de tráfego em redes, visualizável por:
# snort –v –l /var/log/snort
• Network Intrusion Detection System (NIDS), o mais complexo e configurável, o qual
permite analisar o tráfego da rede, visualizável por:
# snort –v –l /var/log/snort –c /etc/snort/snort.conf

• Inline, o qual incrementa além da funcionalidade do NIDS a possibilidade de que os
pacotes sejam descartados antes que cheguem ao destino, visualizável por:
# snort –v –l /var/log/snort –c /etc/snort/snort.conf –Q

O Snort pode registrar os pacotes tanto no formato ASCII, padrão, quanto no formato
binário do tcpdump, criando diretórios baseados nos endereços IPs dos hosts remotos.
Plug-ins adicionais permitem extensões de detecções e registros, como, por
exemplo, armazenar os registros em banco de dados (MySQL ou MSSQL), detecções de
fragmentos, detecções de portscan e normalização de HTTP URI.
Em 2001 Martin Roesch fundou a Sourcefire Network Security, mantendo em
paralelo o Projeto Snort. Recentemente, em 06 de outubro de 2005, a Check Point Software
Technologies anunciou a compra da Sourcefire.
5.1 Mecanismo
O mecanismo de processamento de pacotes no Snort utiliza diversos componentes
que realizam tarefas específicas, Ilustração 5.1.
Detection
(plug-ins)
Libpcap Snort Packet Preprocessor Detection Output

Library Decoder (plug-ins) Engine (plug-ins)
Ilustração 5.10 – Mecanismo de processamento de pacotes no Snort.
O caminho percorrido pelos pacotes inclui:
a. Libpcap library
A biblioteca de captura de pacotes é responsável por levar os pacotes da interface de
rede para o Snort. Esse é um processo realizado na camada de enlace do modelo
TCP/IP (camada 2 do modelo de referência OSI). O Snort utiliza Libpcap em sistemas
Linux e Unix, WinPcap em sistemas Windows.
b. Snort Packet Decoder
O decodificador de pacotes trata os pacotes da camada 2 originados da biblioteca de
captura de pacotes. Primeiro ele decodifica os frames da camada de enlace para só

então decodificar os pacotes dos protocolos IP e TCP ou UDP. Ao finalizar a
decodificação, o Snort tem todas as informações necessárias para futuro
processamento.
c. Preprocessor
O pré-processador tem diversos plug-ins que podem ser habilitados no arquivo de
configuração. O pré-processamento opera na decodificação de pacotes desempenhando
várias transformações nos dados para uma forma mais simples de serem tratados pelo
Snort. Pré-processadores podem alertar, classificar ou descartar um pacote antes que
ele seja enviado para o mecanismo de detecção.
d. Detection Engine
O mecanismo de detecção é o coração do Snort. Ele pega informações pré-processadas
e opera nas camadas de transporte e aplicação (camadas 4 e 7 do modelo OSI),
comparando o que está correlacionado com as informações de regras baseados nos
plug-ins de detecção. Essas regras contêm as assinaturas para ataques habilitadas por
meio do arquivo de configuração.
e. Output
Quando um pré-processador ou uma regra é disparada, um alerta é gerado e registrado,
opcionalmente todo o pacote ofensivo ou apenas o cabeçalho juntamente com os IPs de
origem e destino que geraram o evento.
5.2 Configuração
No arquivo de configuração, por padrão snort.conf, é possível habilitar todos os
módulos ou plug-ins, os quais ativam as assinaturas, os pré-processadores e os tipos de
saída que serão utilizados pelo Snort, também é possível passar parâmetros de execução,
como, por exemplo, que o Snort seja executado enjaulado, limitando assim o acesso ao
sistema de arquivo ao usuário e ao diretório especificado para o chroot.

A ordem padrão de aplicação de uma regra no Snort é:
alert->pass->log
5.2.1 Variáveis
A maioria das regras (rules) utiliza referências a variáveis de rede definidas no
arquivo de configuração do Snort como, por exemplo:
• HOME_NET se refere aos endereços IPs visíveis pelo IPS na rede interna.
• EXTERNAL_NET se refere a todos IPs não confiáveis, pode-se utilizar “!” para
indicar a negação de outra variável.
A definição de uma variável é simples, por exemplo:
var HOME_NET [172.16.0.0/24]

var EXTERNAL_NET !HOME_NET
indica que o IP da rede interna, HOME_NET, é 172.16.0.0/24 e que os endereços da rede
externa, EXTERNET_NET, são todos excetos os da rede interna.
Outras variáveis, para servidores de DNS, SMTP, HTTP e SQL, são utilizadas sendo
recomendado alterá-las de acordo com a rede a ser protegida, principalmente se existirem
serviços em outras redes sem ser na rede interna.
5.2.2 Preprocessor
Os pré-processadores foram introduzidos na versão 1.5 do Snort. Eles permitem a
funcionalidade para que o Snort seja extensível a plug-ins modulares, os quais podem ser
integrados ao mecanismo do Snort.
Os pré-processadores do Snort podem ser utilizados tanto para examinar anomalias
nos cabeçalhos dos pacotes, quanto para notificar os pacotes, para que, assim, o
mecanismo de detecção possa interpretá-los apropriadamente. Uma quantidade de ataques
pode não ser detectada pelos métodos baseados em assinaturas, logo os
pré-processadores de exame tentam detectar alguma atividade suspeita. Outros

pré-processadores são responsáveis pela normalização do tráfego, para que possa ser
tratado pelo mecanismo de detecção baseado em assinaturas. Esses pré-processadores
amenizam ataques que tentam evadir, manipulando as características do tráfego, o
mecanismo de detecção do Snort. Adicionalmente o Snort processa os pacotes através de
cada pré-processador tentando descobrir ataques que necessitam mais de um
pré-processador para detectá-lo. Caso o Snort simplesmente parasse de verificar os
atributos de pacotes suspeitos após ele ser detectado em um pré-processador, os invasores
poderiam usar essa deficiência para esconder outro tráfego malicioso.
Os pré-processadores são extremamente úteis e podem realizar:
• Reestruturação de pacotes;
• Decodificação de protocolos; e
• Detecções baseadas em anomalias não disponíveis nas regras e assinaturas.
A sintaxe para habilitar um preprocessor é dada por:
Preprocessor <name>: <options>
O Snort versão 2.4.3 contém os pré-processadores listados a seguir:
• ARP spoof
• ASN.1 detection
• BO
• Flow
• Frag2
• Frag3
• HTTP inspect
• Performance monitor
• RPC decode

• sfPortscan
• Stream4
• Telnet decode
• X-link2State
5.2.3 Assinaturas
O time de Technical Support Specialists e o Vulnerability Research Team (VRT) da
Sourcefire são peritos em procurar, seguir e documentar vulnerabilidades contra o tempo.
Apoiado por vários recursos da comunidade de usuários do Snort, eles são totalmente
comprometidos com a continuidade em aumentar a segurança de rede corporativa.
O VRT após investir consideráveis recursos trabalham para melhorar a qualidade e
minimizar o tempo de disponibilização de regra, o chamado Tempo Zero, criou as VRT
Certified Rules, disponível ao mesmo tempo para usuários do Snort e da Sourcefire, em até
cinco dias. Cada regra é rigorosamente testada baseada em situações reais antes de ser
divulgada.
As VRT Certified Rules são as regras oficiais do Snort.org e são distribuídas sob
licença comercial. Há três modos de obter essas regras:
• Assinantes: acesso às regras assim que estiverem disponíveis;
• Usuários registrados no Snort.org: acesso às regras após cinco dias de lançadas;
• Usuários não registrados: acesso às regras disponíveis com a versão do Snort mais
recente.
Além das regras oficiais é mantido um conjunto de regras enviadas por membros da
comunidade open source, distribuídas baseada no GPL. O VRT também se encarrega de
testá-las para que elas mantenham o Snort íntegro.
Atualmente, o Snort pode analisar quatro protocolos: IP, TCP, UDP e ICMP em mais
de 40 conjuntos de regras. Os cabeçalhos de regra do Snort devem ser considerados a

parte principal da assinatura, pois ele identifica o que deve ser feito quando a regra for
sinalizada, qual protocolo deve ser usado e as informações de origem e destino, incluindo
portas, endereços IP e redes. A Ilustração 5.2 mostra a estrutura do cabeçalho de regra do
Snort.
Ilustração 5.11 – Exemplo de assinatura do Snort.
5.2.3.1 Cabeçalho
O campo ação da regra indica para o mecanismo qual operação deve ocorrer
quando a regra for correspondida, durante a fase de análise de pacotes.
As ações da regra são altamente significativas, pois cada uma delas tem um objetivo
e um resultado diferente. Determinar a ação da regra é fundamental e deve ser
cuidadosamente considerado, antes da designação. As cinco ações de regra criadas por
padrão são:
• pass: A ação pass simplesmente ignora o pacote e continua a análise nos pacotes
posteriores;
• log: A ação de regra log permite registrar um alerta de uma maneira que pode
especificar durante a configuração do sensor Snort;

• alert: A ação de regra alert registra o pacote da mesma maneira que a ação log e
depois alerta o usuário da maneira especificada durante a configuração. Os alertas
podem ser ações muito úteis e devem ser usados eficientemente.
• dynamic: A ação dynamic é única, no sentido de que permanece inativa até que uma
regra activate a dispare. Após ser disparada, ela então atua como uma regra de ação
log;
• activate: A ação de regra activate é a mais complexa criada por padrão dentro do
Snort, pois quando ativada, ela gera um alerta e depois inicia a regra dinâmica
especificada. Isso pode ser excelente para capturar ataques complexos, invasores
usando uma variedade de ferramentas ou mesmo para classificar dados de uma
maneira diferente.
O campo porta serve para determinar quais portas deverão ser analisadas. Por
exemplo:
• ‘1:1000’: a porta 1 a 1000.
• ‘:6000’: onde o número da porta for menor ou igual a 6000.
• ‘6000’:: onde o número da porta for maior ou igual a 6000.
• ‘any’: para determinar “qualquer porta”.
5.2.3.2 Opções
O campo opções é considerado o coração do sistema de detecção do Snort. As
opções, são colocadas entre parênteses ‘()’, separadas por ponto-e-vírgula ‘;’ e as
palavras chaves são separadas dos argumento dois pontos ‘:’.
a. msg
Especifica a mensagem que será exibida no log/alerta quando o pacote for capturado.
Formato: msg:”<mensagem>”.

b. logto
Grava a saída de todos os pacotes capturados pela regra para um arquivo específico.
Formato: logto”<nome do arquivo>” .
c. ttl
Verifica o campo TTL do pacote, é interessante para identificar problemas de tráfego ou
tentativas de traceroute.
Formato ttl:<numero>.
d. dzise
É usado para testar o tamanho do payload (cabeçalho TCP+dados), é interessante para
se testar tentativas de overflow em determinada aplicação.
Formato: dsize: [> |< ] < numero> [< > < numero> ]
e. content:
É um dos principais recursos do Snort. Permite buscar algum dado específico no
Payload do pacote, como por exemplo, uma palavra ou dados em linguagem de máquina
transcritos em hexadecimal. Pode-se utilizar a opção nocase para ignorar maiúsculas e
minúsculas, a opção ofset para indicar os bits onde os dados começam e a opção depth
para indicar a partir de quais bytes a busca será iniciada.
f. regxp
Permite o uso de metacaracteres para refinar a busca com a opção content.
g. flag
Verifica as flags do cabeçalho TCP que indicam o estado de conexão.
Formato: flags: < valor flag> [,valor mascara].
Segue as opções:
• F FIN - Fim de conexão. Não há mais dados do emissor.
• S SYN - Sincronização dos números seqüenciais. Estabelecimento da conexão
• R RST – Reinicia a conexão

• P PSH – Envio dos dados
• A ACK - Reconhecimento/ Confirmação
• U URG - Urgente
h. seq
Verifica o campo seq (numero de seqüência) do cabeçalho TCP. Esse número qual
indica um número para o controle da conexão. Útil quando se tem uma aplicação que
gera os pacotes já com o numero seq pré-definido e se quer testar uma tentativa de
violação destes números.
Formato: seq: < numero>.
i. ack
Verifica o campo com o número de reconhecimento (acknowledgment) do cabeçalho
TCP. Se este bit estiver definido, este campo contém o valor do próximo número
seqüencial que o receptor está esperando receber. Útil para detecção de varreduras
vindas da ferramenta NMAP.
Formato: ack: < numero> .
j. resp
Possibilita enviar resposta ao tráfego suspeito, como por exemplo, mandar um reset à
conexão. É necessário compilar o Snort com a opção --enable- flexresp.
Formato: resp: < resposta[,resposta...]>.
Segue as opções:
• rst_snd - envia pacotes TCP- RST para o remetente.
• rst_rcv - envia pacotes TCP- RST para o destinatário.
• rst_all - envia pacotes TCP- RST para o remetente e o destinatário.
• icmp_net - envia um pacote ICMP_NET_UNREACH para o remetente.
• icmp_host - envia um pacote ICMP_HOST_UNREACH para o remetente.
• icmp_port - envia um pacote ICMP_PORT_UNREACH para o remetente.

• icmp_all - envia todos os pacotes ICMP acima para o remetente.
É necessária a configuração do arquivo de configuração sempre que for
descarregada uma nova versão das regras, por isso é recomendado sempre fazer uma
cópia de segurança.
5.2.4 Saída
Os módulos ou plug-ins de saída podem realizar diferentes operações com os
registros e os alertas de sistema, como:
• Armazenar registros para um arquivo dos eventos gerados, com apenas os
cabeçalhos (fast) ou com todo o pacote ofensivo(full);
• Enviar traps SNMP;
• Enviar mensagens para o syslog com uma determinada facility;
• Enviar os registros para banco de dados como MySQL, MSSQL ou Oracle;
• Gerar uma saída do tipo eXtensible Markup Language (XML);
• Modificar configuração em roteadores e firewalls;
• Enviar mensagens Server Message Block (SMB) para máquinas baseadas em MS
Windows.
Por exemplo, uma tentativa de ataque do tipo MS-SQL Worm propagation, também
conhecido Slammer worm, estando a regra habilitada, gerará um evento do tipo:
[**] [1:2003:2] MS-SQL Worm propagation attempt [**]

[Classification: SQL Attack] [Priority: 2]
10/26-17:59:01.635549 10.0.250.124:1162 -> 192.168.0.3:1434
UDP TTL:30 TOS:0x0 ID:285 IpLen:20 DgmLen:128
Len: 100
[Xref => http://www.securityfocus.com/bi/1233]
O alerta gerado inclui:
• O primeiro número identifica o ID do gerador, que informa qual componente do Snort
gerou esse alerta. A lista de GIDs está no arquivo generators no diretório de

configuração do Snort. Nesse caso o evento foi originado pelo componente
rules_subsystem, ‘1’, mecanismo de detecção baseado em assinatura, ou seja um
alerta geral do Snort;
• O segundo número é o Snort ID também referenciado como Signature ID, disponível
no arquivo gen-msg.map, no caso, por ser um alerta geral, deve-se verificar a
assinatura disponível no diretório de descrição das assinaturas, no caso
/etc/snort/doc/signatures/2003.txt;
• O terceiro número se refere a revisão da assinatura;
• A identificação da assinatura que disparou o alerta para uma regra específica
• A descrição do alerta
• O nível do alerta, sendo quanto maior o risco do ataque, menor é o número da
prioridade do alerta;
• Os IPs e portas de origem e de destino;
• O momento em que ocorreu o evento;
• O protocolo do ataque; e
• A referência com mais informações a respeito do ataque.

6 SNORT INLINE
Jed Haile desenvolveu o Snort_inline como um patch para o Snort versão 1.9, sob a
licença de software de código aberto GPL. Tratado como um Gateway IDS (GIDS), pois
utiliza um mecanismo de controle de dados que combina a capacidade de deteccao de um
NIDS tradicional, incrementado com a funcionalidade de filtro de pacotes, típico de firewalls.
O Projeto Honeynet utiliza o Snort_inline como uma importante ferramenta de
pesquisa em seu toolkit, o qual traz o Linux pré-compilado com o Snort_inline.
O Snort versão 2.3.0 RC1 integrou a funcionalidade de prevenção de intrusão (IPS)
do Snort Inline dentro do projeto oficial do Snort. Essa versão contemplou a portabilidade
para Linux, integrando com o firewall IPtables, e para FreeBSD, integrando com o firewall
IPFW.
O Snort_inline atua como um verdadeiro IPS e pode alterar os pacotes na camada
de aplicação em tempo real.
Esse sistema tem se tornando rapidamente a ferramenta mais escolhida para
prevenção e detecção de intrusões.
A implementação mais comum do Snort_inline é em um sistema Linux configurado
em bridge, a qual não é identificada como um hop adicional no roteamento dos pacotes. A
utilização de bridge, a qual não tem endereço IP, entre dois segmentos de rede faz com que
o IPS não seja identificado no caminho de roteamento. Entretanto é possível a integração de
um firewall tradicional integrado com o Snort_inline fazendo NAT para as sub-redes
protegidas.
Um sistema inline de resposta ativa tem a capacidade de anular ataques em vez de
simplesmente alterar as ACLs dos roteadores ou políticas para bloquear o endereço IP do
atacante.
A Ilustração 6.1 mostra o Snort rodando como firewall/roteador/IPS. Quando o ataque
é detectado, todo tráfego futuro dos atacantes é bloqueado.

Ilustração 6.12 – Disposição do Snort Inline.
6.1 Mecanismo IPtables
O Snort Inline tem o mecanismo de detecção baseado no Snort NIDS. Entretanto o
Snort Inline faz uso da biblioteca de enfileiramento de pacotes, LibIpQ, em vez da biblioteca
LibPCap, Ilustração 6.2.
Bridge
IPtables
IP Detection
Queue (plug-ins)
Libipq Snort Packet Preprocessor Detection/Inline Libnet Output

Library Decoder (plug-ins) Engine Library (plug-ins)
Ilustração 6.13 - Mecanismo de processamento de pacotes no Snort Inline.
O caminho percorrido pelos pacotes torna-se então:
a. Bridge
A bridge deve ter a funcionalidade, habilitada no kernel, de filtragem de pacotes de rede.
b. IPtables
A política do IPtables envia os pacotes para o destino da fila (queue);
c. IP Queue
Enfileira pacotes do espaço do kernel para uma aplicação que esteja rodando no espaço
de usuário

d. Libipq library
A biblioteca Libipq, provida pelo IPtables, permite que o Snort Inline comunique com o
IPtables, capturando os pacotes da fila no espaço de usuário
e. Inline Engine
O Snort Inline examina cada pacote e consulta as informações de regras do Dectetion
Engine do Snort correlacionando com o Inline Engine (drop, sdrop, reject ou replace)
f. LibNet library
A biblioteca LibNet é uma interface de baixo nível utilizada para injetar pacotes na rede
e é responsável por executar as ações do Inline Engine, utilizada também para o
flexresp.
6.1.1 Mecanismo IPFW
No FreeBSD é utilizado o método IPFW_Forward, habilitado após compilar o kernel,
que encaminha os pacotes recebidos na ponte para o IPFW, o processo continua
funcionando de forma semelhante ao IPtables/Linux.
6.2 Configuração
As etapas de configuração do Snort_Inline são similares de um Snort NIDS, sendo
que os objetivos são diferentes: descartar o pacote malicioso antes que o mesmo alcance o
alvo.
6.2.1 Mecanismo Inline
No Snort Inline foram adicionadas três novas ações para as regras, as quais devem
ser alteradas de acordo com a política de segurança da rede. São elas:
• Drop: Descarta os pacotes usando IPtables e registra via Snort

• Reject: A comunicação para TCP é fechada utilizando um TCP RST ou uma
mensagem ICMP Port-unreachble para UDP. Descarta usando o IPtables e registra
via Snort.
• Sdrop: Descarta os pacotes utilizando o IPtables, mas a ação não é registrada.
Por exemplo, para descartar todos os pacotes originados da rede externa para os
servidores web, a assinatura seria alterada para:
drop tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS

rm command attempt"; flow:to_server,established; content:"rm%20"; nocase;
classtype:web-application-attack; sid:1365; rev:5;)
Também foi incluída uma nova opção:
• Replace: Substitui um texto encontrado no content com uma palavra especificada no
replace.
Por exemplo:
alert tcp any any <> any 80 (msg: "tcp replace"; content:"GET";
replace:"BET";)
A ordem padrão de aplicação de uma regra no Snort Inline é:
->activation->dynamic->pass->drop->sdrop->reject->alert->log

7 IMPLEMENTAÇÃO
Para realizar o laboratório de implementação deste projeto foi utilizada a topologia da
rede simples, Ilustração 6.1, com um firewal segmentando as redes de gerência, interna,
DMZ e externa fazendo NAT para acesso à Internet. Lembrando que o IPS deve funcionar
de forma transparente para os usuários internos ou eventuais invasores, isto é, em ponte
entre a interface externa do firewall e a rede do provedor de serviços, a Internet. A console
(gerente) deve-se localizar em uma rede de gerência, protegida, definida com o IP
192.168.0.0 e máscara de rede de 29 bits.
.3 Internet
zeus
Rede
Gerência
192.168.0.0/29 .2
Roteador
de borda
.1 IPS
hades
hefesto
(Firewall)
DMZ
Rede Interna
Ilustração 7.14 – Topologia utilizada em laboratório.
A concepção do projeto foi realizada utilizando três máquinas virtuais simuladas pelo
aplicativo VMware Workstation versão 5.x, onde:
a. Hefesto (Deus do Fogo)
Onde será implementado o elemento ativo de firewall, necessário em qualquer tipo rede,
IPtables, realizando NAT;
b. Zeus (Deus dos Deuses)

Onde será feita a gerência do sensor IPS com interface gráfica baseado em http e
armazenamento dos eventos enviados pelo Snort NIPS em banco de dados MySQL.
c. Hades (Deus do subterrâneo, o oculto)
Onde será implementado a solução NIPS Snort Inline junto com IPtables. Contém três
interfaces de rede, sendo que uma é utilizada para a gerência e as outras duas para
implementação da ponte.
A gerência do sensor poderá ser realizada in loco ou por meio de acesso remoto, em
uma canal criptografado, a partir da máquina de gerência.
Para implementação do IPS e das ferramentas utilizadas para a gerência, almeja-se
utilizar, sempre que possível, o repositório oficial de pacotes do Debian.
7.1 Sistema Operacional
As três máquinas virtuais foram instaladas com o Debian GNU/Linux 3.1 (sarge)
lançado em 06 de junho de 2005 com configuração mínima.
Foram instalados em todas as VMs alguns pacotes úteis ou necessários, são eles:
a. openssh-server
O SSH (Secure Shell) é um programa que permite acessar e executar comandos em
uma máquina remota, provendo uma comunicação cifrada, segura entre os dois hosts,
através de uma rede insegura.
b. ntpdate
É um cliente NTP simples que permite ajustar o horário do sistema automaticamente a
partir de outros sistemas, necessário para determinar o momento exato em que ocorreu
o evento.
c. gcc
GNU C compiler é um compilador necessário para criar os arquivos binários a partir de
fontes de arquivos de instalação.
d. make

GNU Make é necessário durante a compilação de fontes arquivos de instalação.
7.1.1 Instalação
As versões dos pacotes utilizadas neste projeto foram:
• openSSH 4.2p1
• ntpdate 4.2.0a
• gcc 4.0.3 (prerelease)
• make 3.80
Para instalar os pacotes basta executar os seguintes comandos:
hades:~# apt-get install openssh-server

hades:~# apt-get install ntpdate
hades:~# apt-get install gcc
hades:~# apt-get install make
7.2 Firewall
Para a implementação do firewall IPtables, foram utilizadas duas placas de rede
fazendo NAT para a Internet. Sendo que uma interface está na rede gerência e a outra
conectada no mesmo segmento de rede em que estará uma das interfaces do IPS. Esta
interface obterá o IP dinamicamente de um servidor DHCP disposto no mesmo segmento de
rede da outra interface do IPS. Não foram utilizadas as interfaces que conectam as redes
internas e DMZ, por se tratar de um laboratório.
7.2.1 Configuração
As configurações para as interfaces de rede são listadas abaixo:
hefesto:~# vi /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 192.168.0.1

netmask 255.255.255.0
Para habilitar a NAT basta adicionar uma regra na tabela de NAT do IPtables, para
isso basta executar:
hefesto:~# iptables –t NAT –A POSTROUTINGS –o eth0 –j MASQUERADE
Para habilitar as regras durante a iniciação do sistema é recomendado criar um
script.
7.3 Sensor
Para a instalação do IPS Snort Inline foi utilizada a versão de kernel 2.6.8, também
disponível no Debian Sarge 3.1, pois esta versão já vem com a bridge com suporte nativo ao
netfilter, o que evita a necessidade recompilar o kernel com esta característica.
Como o sensor terá duas placas habilitadas em ponte, é recomendada uma terceira
interface que servirá para o acesso e armazenamento de eventos na gerência e eventuais
atualizações. Inicialmente, para a instalação de pacotes é necessário acesso à Internet,
para isso é recomendado que a máquina esteja em um ambiente seguro ou até mesmo
baixar todos os pacotes em uma máquina de homologação, para só então proceder com as
etapas no computador que entrará em produção.
As configurações para as interfaces são listadas a seguir:
hades:~# vi /etc/network/interfaces
auto eth0
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
Na seção 6.1 foi descrito o mecanismo do Snort Inline e apresentado algumas
bibliotecas e aplicativos que interagem diretamente com ele.

7.3.1 Snort Inline
As bibliotecas e programas que são pré-requisitos para que se possa instalar o Snort
Inline são:
• iptables, incluindo as bibliotecas de desenvolvimento;
• libnet, incluindo as bibliotecas de desenvolvimento, versão 1.0.x. Compilar o
Snort_inline com a versão da libnet 1.1.x não funcionará.
• libpcap, incluindo as bibliotecas de desenvolvimento: utilizado para o Snort capturar
passivamente os pacotes.
• libpcre (Perl 5 Compatible Regular Expression), incluindo as bibliotecas de
desenvolvimento: útil para utilização de scripts;
• libmysql, incluindo as bibliotecas de desenvolvimento: utilizado pelo Snort Inline para
enviar os eventos para o banco de dados MySQL.
7.3.1.1 Instalação
As versões dos pacotes utilizados neste projeto foram:
• iptables 1.2.11
• libnet0 1.0.2a
• libpcap0.8 0.9.4
• libpcre3 6.4-1.0.1
• libmysqlclient 4.1.15
Para instalar os pacotes requeridos para o Snort Inline basta executar os seguintes
comandos:
hades:~# apt-get install iptables-dev

hades:~# apt-get install libnet0-dev
hades:~# apt-get install libpcap0.8-dev
hades:~# apt-get install libpcre3-dev
hades:~# apt-get install libmysqlclient14-dev

Para habilitar a função Inline do Snort é necessário compilar o programa a partir do
código fonte, disponível na página oficial do Snort. A versão utilizada neste projeto foi:
• snort 2.4.3
Para instalar o Snort a partir do código fonte basta seguir os seguintes comandos:
hades:~# cd /usr/src/
hades:/usr/src# wget http://www.snort.org/dl/current/snort-2.4.3.tar.gz
hades:/usr/src# tar xfz snort-2.4.3.tar.gz
hades:/usr/src# cd snort-2.4.3
hades:/usr/src/snort-2.4.3# ./configure --enable-inline
--enable-perfmonitor --enable-flexresp --with-mysql
--with-libipq-includes=/usr/include/libipq/
hades:/usr/src/snort-2.4.3# make && make install
Para testar se o Snort foi está devidamente funcionando basta executar o seguinte
comando:
hades:/usr/src/snort-2.4.3# snort –v
Lembrando que é necessário que o módulo ip_queue esteja ativo para testar o
Snort Inline, para isso basta executar:
hades:~# insmod /lib/modules/2.6.8-2-

386/kernel/net/ipv4/netfilter/ip_queue.ko
hades:~# snort –vQ
Ao final da seção será mostrado como tornar o processo de carregar o módulo
automaticamente.
7.3.1.2 Configuração
Agora que o Snort está instado é necessário fazer algumas configurações para que
ele possa funcionar como NIPS.
Como o Snort contém a funcionalidade nativa de funcionar enjaulado, chroot, serão
criados o usuário e o diretório onde será implementada essa função. O usuário não terá um

shell e também não será permitido utilizar a conta para acessar o sistema, para isso, basta
executar:
hades:~# adduser --home /var/log/snort --no-create-home --disabled-login --

disabled-password --system --group snort
Adding system user `snort'...
Adding new group `snort' (105).
Adding new user `snort' (105) with group `snort'.
Not creating home directory.
O diretório onde serão armazenados os logs de alertas gerados pelos eventos
também será utilizado para o chroot, para isso, basta executar:
hades:~# mkdir /var/log/snort

hades:~# chmod 700 /var/log/snort
hades:~# chown -R snort:snort /var/log/snort
A obtenção das assinaturas foi descrita na seção 5.2.3, sendo definido que seriam
utilizadas as regras obtidas por meio de registro no Snort.org. Para atualizar as assinaturas
é necessário um código, denominado oink_code, obtido ao se cadastrar.
Para criar o diretório onde serão armazenadas as regras basta proceder:
hades:~# mkdir /etc/snort
O procedimento a seguir pode sempre ser utilizado para atualizar as regras,
entretanto é recomendada uma cópia de segurança prévia. Para obtenção das regras basta
proceder:
hades:~# cd /tmp
hades:/tmp# wget http://www.snort.org/pub-
bin/oinkmaster.cgi/<oink_code>/snortrules-snapshot-2.4.tar.gz
hades:/tmp# cd /etc/snort
hades:/etc/snort# tar xvvfz /tmp/snortrules-snapshot-2.4.tar.gz
Para evitar atividades de cópia de arquivos sempre que forem atualizadas as regras,
é recomendado fazer uma referência aos arquivos originais por meio de links.

hades:/etc/snort# ln -s rules/classification.config
hades:/etc/snort# ln -s rules/generators
hades:/etc/snort# ln -s rules/gen-msg.map
hades:/etc/snort# ln -s rules/reference.config
hades:/etc/snort# ln -s rules/sid-msg.map
hades:/etc/snort# ln -s rules/sid.map
hades:/etc/snort# ln -s rules/snort.conf
hades:/etc/snort# ln -s rules/threshold.conf
hades:/etc/snort# ln -s rules/unicode.map
A configuração padrão do Snort Inline é feita por meio do arquivo
/etc/snort/snort.conf, o qual será editado para algumas alterações mínimas:
• localização das regras;
• saída dos eventos para que sejam registrados na gerência, MySQL;
• é recomendado configurar a variável HOME_NET afim de diminuir os
falsos-positivos.
Para isso basta proceder:
hades:/etc/snort# vi snort.conf
var RULE_PATH ./rules
output database: log, mysql, user=snort password=snort dbname=snort
host=192.168.0.3 port=3306 sensor_name=hades-IPS
Para utilizar o Snort com todas as opções anteriores e no modo verbose, basta
executar o seguinte comando:
hades:~# snort –v –Q –c /etc/snort/snort.conf –l /var/log/snort –t

/var/log/snor –u snort –g snort
Para utilizar o Snort com todas as opções anteriores e no modo daemon, basta
executar o seguinte comando:
hades:~# snort –D –Q –c /etc/snort/snort.conf –l /var/log/snort –t

/var/log/snor –u snort –g snort
É recomendado criar um script para que o Snort seja iniciado junto com o sistema.

7.3.2 Bridge
Uma ponte envia o tráfego entre múltiplas interfaces de rede de forma transparente,
isso significa que uma ponte conecta duas ou mais ethernets físicas juntas para formar uma
grande ethernet (lógica).
Para que o Snort Inline rode sobre o modo bridge é necessário que o kernel esteja
compilado com o patch bridge/firewall, caso contrário, a bridge não passará os pacotes para
o IPtables e, consequentemente, não passará os pacotes para o Snort_inline.
Uma ferramenta transparente que filtra o tráfego de redes passando por uma bridge,
muito utilizado no universo Linux é a bridge-nf. Bridge-nf é também referenciada como
bridge-netfilter e br-n. Por meio da bridge-nf é possível uma integração do IPtables com a
ponte para implementar um firewall transparente.
Para o Linux kernel 2.4 é necessário aplicar o patch, A funcionalidade da bridge-nf é
compilada automaticamente no Linux Debian kernel 2.6, o qual tem o netfilter e a bridge
habilitados, por padrão.
Por esse motivo foi definido que o Snort Inline NIPS (hades) fosse instalado com a
versão de kernel 2.6.
Entretanto, como a instalação do sistema operacional foi realizada com a mínima
configuração, é necessário instalar o aplicativo que cria a ponte, sendo definido que seria o
bridge-utils (Linux Ethernet bridging).
A versão do pacote utilizado neste projeto foi:
• Bridge-utils 1.0.6
Para instalar o pacote da bridge basta executar o seguinte comando:
hades:~# apt-get install bridge-utils

O procedimento de criar uma ponte é relativamente simples, sendo necessário
apenas dar um nome para a interface bridge lógica e adicionar as interfaces físicas a ela. Os
procedimentos para realizar uma bridge são:
hades:~# brctl addbr br0

hades:~# brctl addif eth1
hades:~# brctl addif eth2
hades:~# ifconfig eth1 0.0.0.0 up
device eth1 entered promiscuous mode
hades:~# ifconfig eth2 0.0.0.0 up
device eth2 entered promiscuous mode
hades:~# ifconfig br0 up
br0: topology change detected, propagating
br0: port 2(eth2) entering forwarding state
br0: topology change detected, propagating
br0: port 1(eth1) entering forwarding state
Para habilitar a bridge durante a iniciação do sistema é recomendado criar um script.
7.3.3 IPtables
O IPtables é um software firewall, que permite conexões statefull, largamente
utilizado no universo open-source.
Para habilitar o módulo de fila, provido pelo o IPtables, ao iniciar o sistema, basta
executar:
hades:~# echo ip_queue >> /etc/modules
Para habilitar a fila no IPtables basta adicionar uma regra na tabela de NAT do
IPtables, para isso basta executar:
hades:~# iptables –A FORWARD –j QUEUE
Para habilitar as regras durante a iniciação do sistema é recomendado criar um
script.

7.4 Gerência
As ferramentas necessárias para a implementação da gerência do sistema de
prevenção de intrusão são:
a. MySQL server
b. Basic Analysis and Security Engine (BASE)
c. Apache web server
A estação de gerência contém uma interface de rede que está configurada para a
rede de gerência
zeus:~# cat /etc/network/interfaces

address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
7.4.1 MySQL
O MySQL é um servidor de banco de dados largamente utilizado no universo open-
source.
Para a instalação do MYSQL, foi utilizado o seguinte comando:
zeus:~# apt-get install mysql-server-4.1
Com isso, foram instalados os pacotes do mysql-server. Uma vez que os pacotes
foram instalados, foi iniciado o daemon do MySQL usando a linha de comando abaixo:
zeus:~# /etc/init.d/mysql start
Foi configurado o usuário da base de dados. Também, criada a base de dados de
Snort para um uso posterior com o sistema de prevenção de intrusos.
zeus:~# mysql -u root
mysql> set password for \

'root'@'localhost'=password('senha');
mysql> create database snort;
mysql> exit
Para a criação das tabelas para o database snort, basta utilizar o modelo fornecido
pelo arquivo de distribuição do Snort.
zeus:~# scp hades:/usr/src/snort-2.4.3/contrib/create_mysql .
zeus:~# mysql –u root -p

Enter password: *****
mysql>connect snort
mysql>source source create_mysql
Um usuário chamado snort será utilizado pelo BASE para conexão à base de
dados snort no MySQL.
mysql>grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort;

mysql>grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to
snort@localhost;
mysql>connect mysql
mysql>set password for “snort”@”localhost” = password(“snort”);
mysql>set password for “snort”@”%” = password(“snort”);
mysql>flush privileges;
mysql>exit;
Foi verificado se os usuários e databases existiam realmente no MySQL e se as
tabelas que serão utilizadas para armazenar os logs e informações sobre o Snort e
manipuladas pelo BASE, haviam sido criadas corretamente.
Para verificação de usuários, basta proceder:

zeus:~# mysql -u root -p
mysql> select user,host from user;

+------------+------------------+
| user | host |
+------------+------------------+
| snort | % |
| root | localhost |
| snort | localhost |
| root | www.mydomain.com |
| snort | www.mydomain.com |
+------------+------------------+
8 rows in set (0.00 sec)
mysql> show databases;

+-------------+
| Database |
+-------------+
| mysql |
| snort |
+-------------+
mysql> connect snort;

mysql> show tables;
+------------------+
| Tables_in_snort |
+------------------+
| data |
| detail |
| encoding |
| event |
| flags |
| icmphdr |
| iphdr |
| opt |
| protocols |
| reference |
| reference_system |
| schema |
| sensor |
| services |
| sig_class |
| sig_reference |
| signature |
| tcphdr |
| udphdr |
+------------------+
19 rows in set (0.00 sec)

7.4.2 Apache HTTP
O Apache é um servidor HTTP open-source largamente utilizado e portável em
diversas plataformas.
Para a instalação do Apache com suporte a PHP basta realizar as seguintes etapas:
zeus:~# apt-get install apache2
zeus:~# apt-get install php4
zeus:~# apt-get install php4-mysql
zeus:~# vi /etc/apache2/httpd.cnf
Load_Module php4_module /usr/lib/apache2/modules/libphp4.so
zeus:~# cat /etc/acidbase/apache.conf >> /etc/apache2/apache.conf
7.4.3 BASE
O BASE (Basic Analisys and Security Engine) é uma ferramenta de análise baseada
em PHP para pesquisar e processar uma base de dados formada por eventos de
segurança, gerados por vários elementos de segurança como IPSes, firewalls e ferramentas
de monitoração de rede . Ele possui várias funcionalidades, sendo elas:
• Ferramenta de query sql e interface de pesquisa para encontrar alertas por meio de
palavras chave (ex. assinaturas, tempo de detecção) bem como informações de rede
(ex. endereços de origem/destino, portas, payload ou flags de cabeçalho);
• Visualizador de pacotes (decoder) que mostra graficamente informações de camada
3 e 4 referentes aos pacotes registrados;
• Gerência de alertas, que provê uma organização lógica dos grupos de alertas para
criar incidentes, excluir os falsos positivos ou arquivar os alertas para transferi-los
para outra base de dados;

• Geração de gráficos e estatísticas, baseadas em tempo, sensor, assinatura,
protocolo, endereço IP, portas TCP/UDP e classificação.
O BASE tem a habilidade de analisar uma grande variedade de eventos que são
pós-processados em sua base de dados. Existem ferramentas para os seguintes formatos:
• usando o Snort:
o alertas do Snort;
o Logs binários no formato do tcpdump.
• usando o logSnorter:
o IPChains;
o IPtables;
o IPFW.
Quando o BASE é acessado, por meio de uma interface web, ele faz queries à
base de dados (MySQL), e busca todas as informações armazenadas a respeito de eventos
registrados pelo IPSes, apresentando-os em forma de um gráfico de barras. A partir desta
tela pode-se verificar quais foram os alertas gerados e fazer buscas pela base de dados. Ao
se visualizar os alertas, estes possuem uma descrição do tipo de alerta, a prioridade que ele
requer e um atalho para o site do Snort [4], onde se pode obter maiores informações a
respeito do ataque. A gerência da base de dados pode também ser feita através do browser.
Desta forma, o BASE se mostra como uma ferramenta útil e completa permitindo
uma completa administração das informações e da base de dados.
Para a instalação do BASE, basta seguir os seguintes comandos:
zeus:~# apt-get install php4-gd

zeus:~# apt-get install adodb
zeus:~# apt-get install JPgraph
zeus:~# apt-get install base

Os vários componentes da instalação do BASE, tem suas próprias dependências
com outros componentes. É importante que os componentes independentes, sejam
instalados primeiramente. Abaixo segue os componentes e seus pré-requisitos:
• MySQL
• Snort
o MySQL Support
• Apache
o OpenSSL Support
o PHP
 OpenSSL Support
 MySQL Support
• BASE
o Adodb
o jpgraph
Inicialmente é necessário copiar o arquivo de distribuição do BASE para o de
configuração, para isso basta seguir os procedimentos:
zeus:~# cd /var/www/html/base
zeus:/var/www/html/base# cp base_conf.php.dist base_conf.php
Os seguintes parâmetros do arquivo base_conf.php foram alterados de seguinte
forma:
zeus:/var/www/html/base# vi base_conf.php
$BASE_urlpath = "../base";
$DBlib_path = "/var/www/html/adodb";
$DBtype = "mysql";

$alert_dbname = "snort";
$alert_host = "localhost";
$alert_port = "";
$alert_user = "snort";
$alert_password = "password_from_snort_conf";
$archive_dbname = "snort";
$archive_host = "localhost";
$archive_port = "";
$archive_user = "snort";
$archive_password = " password_from_snort_conf ";
$ChartLib_path = "/var/www/html/jpgraph-1.16/src";
Para acessar o BASE basta abrir um navegador, e informar o endereço da máquina
em que está o BASE, por exemplo, http://192.168.0.3/base ou
http://zeus/base.
Ilustração 7.15 – Tela de configuração inicial do BASE.
Clicar no link “SETUP PAGE”, na próxima página clicar no botão setup AG, aparecerá
uma nova página, com a página abaixo:
Ilustração 7.16 – Tela de status da configuração inicial do BASE.
Aperte no link “HOME”, para ter acesso a página principal. Feito o BASE deve estar
devidamente ativo pronto para analisar os eventos coletados pelo Snort Inline.

8 RESULTADOS
Decorrida a implementação do sistema de prevenção de intrusão é necessário
avaliar o seu impacto e comportamento na rede, é necessário também analisar o potencial
de prevenção frente a alguns ataques.
A implementação do Snort Inline funcionando como ponte foi inicialmente testada no
Linux Debian kernel 2.4, a qual gerou diversos erros durante a compilação do IPtables com
suporte a Bridge-nf, o que durou aproximadamente três semanas. O escopo do projeto foi
continuado com Snort Inline rodando com IPtables em modo NAT. Como essa situação não
era a desejada inicialmente, foi testado o kernel 2.6, o qual se obteve êxito com o IPtables
rodando em bridge.
Além disso, foi implementada, para melhor visualização dos dados obtidos uma
gerência baseada em HTML.
8.1 Resultados obtidos
Para avaliar o funcionamento do Snort_Inline, iniciou-se uma simulação de
comportamento próximo do real, para isso foram lançados alguns ataques a partir da rede
externa, como pings com tamanhos acima do normal, tentativa de tornar-se root, portscans.
Uma atividade de exploração de vulnerabilidade do servidor web, a fim de acessar os
arquivos do sistema gerou os seguintes alertas:
[**] [1:1122:5] WEB-MISC /etc/passwd [**]

[Classification: Attempted Information Leak] [Priority: 2]
12/01-19:09:55.777632 192.168.189.1:1680 -> 192.168.0.3:80
TCP TTL:128 TOS:0x0 ID:39175 IpLen:20 DgmLen:435 DF
***AP*** Seq: 0xA5B6B438 Ack: 0x221C6EDF Win: 0xFFFF TcpLen: 20
[**] [1:1113:5] WEB-MISC http directory traversal [**]

12/01-19:09:55.777632 192.168.189.1:1680 -> 192.168.0.3:80
[Xref => http://www.whitehats.com/info/IDS297]
[**] [119:18:1] (http_inspect) WEBROOT DIRECTORY TRAVERSAL [**]


12/01-19:09:55.777632 192.168.189.1:1680 -> 192.168.0.3:80

[Xref => http://www.whitehats.com/info/IDS297]
Uma atividade de portscan gerou:
[**] [122:3:0] (portscan) TCP Portsweep [**]

10/27-16:14:51.860906 192.168.0.3 -> 200.199.201.237
PROTO255 TTL:0 TOS:0x0 ID:620 IpLen:20 DgmLen:158
Na regra telnet.rules foi criada a seguinte assinatura:
drop tcp any any -> 192.168.0.1 23 (classtype:attempted-user;msg:"DROP

TELNET 23";)
Uma tentativa de comunicação tcp/23 ao firewall (192.168.0.1) gerou:
[**] [1:0:0] DROP TELNET 23 [**]

[Classification: Attempted User Privilege Gain] [Priority: 1]
12/01-18:51:15.594256 192.168.189.1:1530 -> 192.168.0.1:23
******S* Seq: 0xDD419BC9 Ack: 0x0 Win: 0xFFFF TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
Por meio da gerência, BASE, é possível visualizar todos os eventos coletados.
Ilustração 8.17 – Análise de logs no BASE.
Além disso, o IPS Snort Inline foi disposto por cinco dias em um ambiente real
analisando pacotes que eram destinados à porta tcp/25, SMTP, que continham as strings
‘.lnk’, ‘.pif’, ‘.cmd’, ‘.bat’, ‘.msi’, ‘.exe’, ‘.scr’, ‘.vbs’. Durante esses dias pacotes destinados ou
originados da/para a rede interna não foram entregues, sendo descartados pelo Snort Inline.

8.2 Análise e Discussão dos Resultados
Concluídos os testes de tentativas incidentais de intrusão, pode-se verificar que o
Snort_Inline detectou essas tentativas, registrando-as.
Observou-se que a tentativa de acesso aos arquivos de sistema, foi detectada pelo
mecanismo preprocessor e pelo mecanismo de detecção por assinatura. Esse evento pode
gerar muitos falso-positivos, por exemplo, com simples erros de digitação no navegador
web.
O port-scan foi detectado logo pelo preprocessor e uma simples ação que pode
minimizar os eventos do port-scan na rede é desabilitar o echo-request a partir da rede
externa.
A tentativa de acesso telnet é descartada, entretanto, foi observado que a conexão
demora mais que o normal pra ser finalizada, do lado do cliente, já que não chega ao
servidor.
Esses exemplos demonstram a funcionalidade dos mecanismos de detecção e ação
do Snort_Inline.
Com a implementação da gerência por meio da interface gráfica BASE, tornou mais
acessível a visualização dos eventos coletados.
8.3 Problemas diagnosticados e futuras implementações
Com a utilização do Snort_Inline, foram notados alguns problemas:
a. Disponibilidade do banco
Como os eventos são armazenados em uma máquina remota de banco de dados, caso
não haja conectividade com a máquina de gerência o Snort não é inicializado, o que
pode ser resolvido por meio de um script que faça o teste de conectividade e em caso
negativo altere o arquivo de configuração snort.conf, desabilitando a opção de
armazenamento no banco remoto.
b. Manutenção do arquivo de configuração

Ao se atualizar as regras é necessário que seja feito um backup prévio das regras
correntes, pois quando da aplicação de uma nova versão, existe a possibilidade de
inclusão ou exclusão de features padrão, o que exige que seja reconfigurado o arquivo
do Snort
c. Assinaturas
O processo de atualização de regras não é simples, pois é necessário alterar todas as
assinaturas as quais se deseja descartar os pacotes, o que pode ser feito por meio de
um script.
d. Eventos repetidos:
A análise de logs pode ser facilitada com aplicativos que agrupam eventos repetidos.
e. Alta disponibilidade
Por o IPS ser inline é necessário que todos os sistemas que o compõem estejam ativos,
caso contrário, causará indisponibilidade à rede. O que pode ser minimizado utilizando
técnicas de load-balance ou redundância de link.
Em redes que trafegam uma grande quantidade de dados é possível que haja perda de
pacotes durante a análise, o que pode ser minimizado com o uso registros de alertas no
formato do binário do TCPDump. Scripts podem ser criados para verificar se todos os
sistemas (Snort e bridge) estão ativos.
f. LiveCD
É possível a implementação de sistemas embarcados rodando em um LiveCD ou até
mesmo em memórias flash, o que é útil pois em uma possível invasão do sistema
operacional, não haveria como danificar o sistema de arquivos.
g. Harden
É recomendado utilizar técnicas que tornam o sistema mais fechado possível em
máquinas diretamente expostas, como é o caso de IPS.

CONCLUSÃO
A implementação deste projeto ocorreu sob condições limitadas, como falta de um
conhecimento específico do assunto, inicialmente, pouca documentação a respeito do Snort
Inline bem como falta de recursos de maquinário.
A partir do estudo realizado, foi possível conhecer as principais ferramentas
utilizadas para implementar IPS o qual incrementa a proteção de forma ativa, constituindo
um elemento a mais na defesa em profundidade de segurança da informação.
Uma estratégia de segurança baseada em uma plataforma de segurança,
privilegiando a ação preventiva, auxilia não apenas nos esforços de uma melhor
infraestrutura, mas também colabora com o controle dos gastos com segurança da
informação, reduz a complexidade da administração de segurança e melhora as
comunicações entre as equipes responsáveis pela administração de rede, de sistemas e de
segurança.
Prevenção significa detectar e bloquear um ataque antes que este alcance seus
alvos: servidores, sistemas e computadores pessoais. Por meio da análise do tráfego e
mecanismos avançados, os sistemas de prevenção contra intrusos realizam essa tarefa,
detectando tentativas, a partir de ataques conhecidos ou não, de explorar vulnerabilidades
em computadores e sistemas em geral.
Sistemas de detecção e prevenção de intrusos, assim como softwares de antivírus
possuem problemas semelhantes: novos ataques não são detectados porque às vezes não
há uma assinatura para eles - uma das motivações de se continuar o estudo de Prevenção
de Intrusão, fato que as ameaças aumentam constantemente.
Para uma melhor implementação de IPS é necessário que a rede a ser protegida
seja conhecida. Sistemas de proteção devem amadurecer com o tempo visando,
principalmente, minimizar bloqueio de tráfego desejável, custo e gerenciamento. Entretanto

os IPSes não são a solução para os ataques que ocorrem no cotidiano das redes
corporativas e na Internet, a qual deve ser feita em múltiplas camadas.

REFERÊNCIAS BIBLIOGRÁFICAS
[1] Cisco Secure Intrusion System. Cisco Press.
[2] Debian – The Universal Operating System. Disponível em: <http://www.debian.org/>.
Acesso em 01/09/2005.
[3] Snort. Disponível em: <http://www.snort.org> Acesso em 01/09/2005.
[4] Snort_inline. Disponível em: <http://snort-inline.sourceforge.net/>
[5] CERT Coordination Center. Disponível em: <http://www.cert.org/>. Acesso em:
01/11/2005.
[6] CERT.br -- Centro de Estudos, Resposta e Tratamento de Incidentes de
Segurança no Brasil. Disponível em: <http://www.cert.br/>. Acesso em 23/11/2005.
[7] Seguranças em redes Disponível em :http://www.rnp.br/newsgen/9909/politica.shtml
Acesso em 23/08/2005
[8] Crimes Virtuais. Disponível em
<http://unainet.com.br/crimes_virtuais/crimes_virtuais.htm> . Acesso em: 01/08/2005.
[9] NORTHCUTT, S Inside Network Security Perimeter. Estados Unidos: Sams, 2002
[10] MCCLURE, S. Hackers expostos: segredos e soluções para a segurança de redes
/Stuart McClure, Joel Scambray e George Kurtz; tradução de Daniel Vieira. – Rio de
Janeiro: Campus, 2003. Título original: Hacking exposed.
[11] MELO, S. A arte cracker de levantar informações do alvo, seu perigo e
contramedidas. 2004. Disponível em <http://linuxchix.org/br/palestras> Acesso em
agosto de 2005
[12] Northcutt, Stephan. Network Intrusion Detection System. 2nd Edition.
[13] TIPOS DE IDS Disponível em < www.firewalls.com.br/files/Palestra_IDS.pdf> .
Acesso em agosto de 2005
[14] Tipos de consoles Disponível em
<http://revista.unicamp.br/infotec/artigos/frank4.html> Acesso em setembro de 2005

[15] Linux Ethernet bridging. Disponível em: <http://bridge.sourceforge.net/> . > Acesso
em novembro de 2005
[16] ebtables. Disponível em: <http://ebtables.sourceforge.net/>. Acesso em novembro de
2005
[17] MySQL. Disponível em: <http://www.mysql.org/>. Acesso em agosto de 2005
[18] The Honeynet Project. Know Your Enemy: Learning with User-Mode Linux.
<http://www.honeynet.org/papers/uml/index.html> Acesso em novembro de 2005.
[19] Apache Server. Disponível em: <http://httpd.apache.org/> . Acesso em setembro de
2005
[20] Snort with BASE. Disponível em <http://www.ntsug.org/docs/Snort_base_fc3.pdf> .
Acesso em setembro de 2005
[21] SCHULTZ, E.; ENDORF, C.; MELLANDER, J. The future of intrusion detection
and prevention. In: ______. Intrusion detection and prevention. Emeryville,
California: McGraw-Hill/Osborne, 2003. cap. 17. Disponível em:
<http://searchsecurity.techtarget.com/searchSecurity/downloads/IDP_Ch17.pdf>.
Acesso em:nov. 2005.
[22] Libnet. Disponível em <www.packetfactory.net/Projects/Libnet/>. Acesso em:agosto.
2005
[23] LIDS.Disponível<http://www.rhbr.com.br/modules.php?name=News&new_topic=39>.
Acesso em:nov. 2005.
[24] SnortSam. Disponível em <http://www.snortsam.net/> . Acesso em:nov. 2005.
[25] Sourcefire Network Security. Disponível em: < http://www.sourcefire.com/>. Acesso
em: set 2005
[26] HIPS-NIPS Disponível em
<http://www.scmagazine.com/us/grouptest/details/79d57b71-5ebd-4ce2-93e3-
48ed0b64c5d3/special-report-intrusion-prevention/> Acesso em: nov 2005

[27] Intrusion Prevention and Active Response: Deploying Network and Host IPS. Michael
Rash, Angela Orebaugh, Graham Clark, Becky Pinkard, Jake Babbin
[28] Snort 2.1 Intrusion Detection. Andrew Baker, Jay Beale, Brian Caswell, Mike Poore
[29] Snort 2.0 Intrusion Detection. Jay Beale, James C. Foster, Jeffrey Posluns, Ryan
Russell, Brian Caswell.
[30] Intrusion Detection with Snort. Jack Koziol.
[31] Intrusion Detection with SNORT: Advanced IDS Techniques Using SNORT, Apache,
MySQL, PHP, and ACID. Rafeeq Rehman
[32] Snort for Dummies. Charlie Scott, Paul Wolfe, Bert Hayes.
[33] Snort Cookbook. Angela D. Orebaugh, Simon Biles, Jacob Babbin
[34] Snort and IDS Tools. Kerry J. Cox, Christopher Gerg

Sistema de Prevenção de Intrusão Com Snort. Igor Neiva e Sandro Herman. UCB.

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sistema de Prevenção de Intrusão Com Snort. Igor Neiva e Sandro Herman. UCB.

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE

LATO SENSU EM REDES DE COMPUTADORES

SISTEMAS DE PREVENÇÃO DE INTRUSÃO BASEADO EM

SOFTWARE LIVRE: DEBIAN E SNORT

IGOR DA SILVA NEIVA MAIA

Universidade Católica de Brasília

IGOR DA SILVA NEIVA MAIA

SANDRO HERMAN PEREIRA REHEM

SISTEMAS DE PREVENÇÃO DE INTRUSÃO BASEADO EM

SOFTWARE LIVRE: DEBIAN E SNORT

Projeto final apresentado ao Programa de

Orientador: Jerônimo Jardim

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort i

Universidade Católica de Brasília

Monografia defendida e aprovada como requisito parcial obtenção do grau de

Especialista em Rede de Computadores, defendida e aprovada, em 12 de dezembro de

2005, pela banca examinadora constituída por:

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort ii

Universidade Católica de Brasília

Aos nossos pais, familiares e namoradas pela

compreensão e incentivo nos momentos mais

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort iii

Universidade Católica de Brasília

À Universidade Católica de Brasília.

Ao Professor Mestre Jerônimo Jardim

Incentivador e esclarecedor de muitas dúvidas

surgidas ao longo do projeto

E a todos aqueles que nos ajudaram e

incentivaram no desenvolvimento das

atividades realizadas neste projeto.

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort iv

Universidade Católica de Brasília

Ilustração 1.1 – Crescimento dos sistemas de informação...................... ...............................1

Ilustração 2.2 – Estatísticas de incidentes relatados ao CERT/CC.........................................5

Ilustração 2.3 – Estatísticas de incidentes relatados ao CERT.br............................... .............5

Ilustração 2.4 – Comparativo entre conhecimento e sofisticação dos ataques........................ 6

Ilustração 2.5 – Processos para implementação de segurança..............................................9

Ilustração 3.6 – IDS como segunda camada de defesa da rede..................... ......................25

Ilustração 3.7 – Localização dos sensores................................................................... .........31

Ilustração 4.8 – Princípio fundamental de defesa ativa. ................................ .......................37

Ilustração 4.9 – Arquitetura de IPS.............................................................................. ..........39

Ilustração 5.10 – Mecanismo de processamento de pacotes no Snort................................ ..51

Ilustração 5.11 – Exemplo de assinatura do Snort.................................... ............................56

Ilustração 6.12 – Disposição do Snort Inline............................................. ............................63

Ilustração 6.13 - Mecanismo de processamento de pacotes no Snort Inline.........................63

Ilustração 7.14 – Topologia utilizada em laboratório.................................................... ..........66

Ilustração 7.15 – Tela de configuração inicial do BASE.................................................. .......82

Ilustração 7.16 – Tela de status da configuração inicial do BASE.........................................82

Ilustração 8.17 – Análise de logs no BASE............................................... ............................84

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort v

Universidade Católica de Brasília

Este trabalho visa a implantação de um IPS (Intruder Prevention System) utilizando o

Snort Inline como ferramenta. Inicialmente é apresentada a teoria envolvida no projeto,

para a implementação do ambiente do IPS, bem como a implementação em si. Em seguida,

feitas as considerações finais e sugestões de trabalhos futuros.

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort vi

Universidade Católica de Brasília

and future works are suggested.

Sistemas de Prevenção de Intrusão Baseado em Software Livre: Debian e Snort vii

Universidade Católica de Brasília

LISTA DE FIGURAS................................................................................................ ...............v

1.1 Objetivo......................................................................................................... ................3

1.2 Escopo.................................................................................................... ......................4