INSTITUTO FEDERAL DO ESPÍRITO SANTO

CAMPUS SERRA

MONITORAMENTO DE TRÁFEGO VIA HONEYPOT VIRTUAL DE BAIXA

INTERATIVIDADE

FRANZVITOR ALMEIDA FIORIM

MONOGRAFIA DE CONCLUSÃO DO CURSO DE

TECNOLOGIA EM REDES DE COMPUTADORES

Orientador: Prof. MSc. Gilmar Luiz Vassoler

Serra, 02 de setembro de 2010.

 FRANZVITOR ALMEIDA FIORIM

MONITORAMENTO DE TRÁFEGO VIA HONEYPOT

VIRTUAL DE BAIXA INTERATIVIDADE

TRABALHO DE CONCLUSÃO DE CURSO APRESENTADO

COMO PARTE DAS ATIVIDADES PARA OBTENÇÃO DO
TÍTULO DE TECNÓLOGO, DO CURSO DE TECNOLOGIA
EM REDES DE COMPUTADORES DO INSTITUTO FEDERAL
DO ESPÍRITO SANTO, CAMPUS SERRA.

Prof. Orientador: Prof. MSc. Gilmar Luiz Vassoler

Serra, 2010
 (FICHA CATALOGRÁFICA)

Catalogação na fonte: Rogeria Gomes Belchior - CRB 12/417

F519m Fiorim, Franzvitor Almeida

Monitoramento de tráfego via honeypot virtual de baixa interatividade /

Franzvitor Almeida Fiorim. – 2010.

68 f. : il. ; 31 cm

Orientador: Gilmar Luiz Vassoler

Monografia (graduação) – Instituto Federal do Espírito Santo,

Coordenadoria do Curso de Redes de Computadores, Curso Superior de
Tecnologia em Redes de Computadores, 2010.

1. Redes de computadores – Medidas de segurança. 2. Software livre. 3.

Computadores – Medidas de segurança. I. Vassoler, Gilmar Luiz. II. Instituto
Federal do Espírito Santo. III. Título

CDD 005.8
 Franzvitor Almeida Fiorim

Monitoramento de Tráfego via Honeypot Virtual de Baixa Interatividade

Trabalho de Conclusão de Curso apresentado à Coordenadoria do Curso de Redes de

Computadores do Instituto Federal de Educação, Ciência e Tecnológica do Espírito Santo,
como requisito parcial para a obtenção do título de Tecnólogo em Redes de Computadores.

Aprovado em 02 de setembro de 2010.

COMISSÃO EXAMINADORA

______________________________________________

Profº. M.Sc. Gilmar Luiz Vassoler

Instituto Federal do Espírito Santo

Orientador

______________________________________________

Profº. José Inácio Serafini

Instituto Federal do Espírito Santo

______________________________________________

Alamir Costa Louro

Mogai Tecnologia da Informação

 DECLARAÇÃO DO AUTOR

Declaro, para fins de pesquisa acadêmica, didática e técnico-científica, que o presente

Trabalho de Conclusão de Curso pode ser parcial ou totalmente utilizado desde que se faça
referência à fonte e ao autor.

Serra, 02 de setembro de 2010

FRANZVITOR ALMEIDA FIORIM

“Dedico este trabalho a minha bisavó
Hilda e ao meu avô Antônio.”
AGRADECIMENTOS

Agradeço a minha mãe, Solange, ao

meu pai, Clóvis, por toda educação, amor e
carinho. Aos meus meus familiares paternos e
maternos, aos mais próximos como tio
Roberto, tia Liceia e tia Márcia agradeço
ainda a grande contribuição a minha
infância. Agradeço ainda aos amigos feitos
durante o período da graduação, em especial
a Jean Carlos, Juliana Cristina, Pedro
Garcia, Frederico da Costa, Wesklen Kiefer,
Wekler Mendes e Thalison Pelegrine.
Deves ser a mudança que desejas ver no
mundo.
Mahatma Mohandas Karamchand Gandhi
 RESUMO

Neste trabalho foi feito o estudo e a implementação de uma ferramenta honeypot virtual
de baixa interatividade na redes do Ifes – Instituto Federal de Educação Tecnológica do
Espirito Santo. Por meio de experimentação em um ambiente real, os dados foram coletados e
analisados posteriormente por um conjunto de ferramentas e scripts especializados com o
intuito de entender as características de determinados ataques e mensurar a exposição de uma
máquina sem mecanismos de defesa a internet. Este trabalho poderá ser útil como base para
outros trabalhos relacionados à detecção de atividades maliciosas em redes de computadores.

Palavras-chave: segurança de redes, honeypots, honeynet, Honeyd, Honeycomb, software

livre.
 ABSTRACT

This work was done the study and implementation of a virtual honeypot tool of
interactivity in the networks of low IFES - Instituto Federal de Educação Tecnológica do
Espirito Santo. Through experimentation in a real environment, the data were collected and
later analyzed by a set of specialized tools and scripts in order to understand the characteristics
of certain attacks and measure the exposure of a machine without defense mechanisms to the
Internet. This could be useful as a basis for other work related to the detection of malicious
activity on networks of computers.

Keywords: network security, honeypot, honeynet, Honeyd, Honeycomb, free software.

 LISTA DE FIGURAS

Figura 1.1: Estatística sobre a quantidade total de incidentes reportados ao CERT.br.............17

Figura 3.1: Visão geral da arquitetura implementada pelo Honeyd..........................................29

Figura 3.2: Diagrama da arquitetura do Honeycomb................................................................34

Figura 4.1: Estrutura da distribuição da faixa de IP's referente a rede /28................................38

Figura 5.1: Número de pacotes recebidos por dia.....................................................................42

Figura 5.2: Média do número de pacotes recebidos por dias da semana...................................43

Figura 5.3: Histograma relativo ao número de pacotes recebidos pelos honeypots em relação a
hora do dia. ...............................................................................................................................43
 LISTA DE QUADROS

Quadro 3.1 ...............................................................................................................................31

 LISTA DE TABELAS

Tabela 1: Exemplo de log do Honeyd.......................................................................................33

Tabela 2: Dias com maior trafego de pacotes...........................................................................42

Tabela 3: Número total de pacotes recebidos por cada protocolo............................................44

Tabela 4: Lista de países que mais enviaram pacotes para os honeypots virtuais.....................45

Tabela 5: Porcentagem de pacotes recebidos pelos honeypots virtuais no período de coleta dos
dados.........................................................................................................................................45

Tabela 6: Relação do trafego de pacotes recebidos com as portas de destino..........................46

Tabela 7: Sistemas operacionais que mais originaram ataques..................................................47

 LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

ARP Address Resolution Protocol

BOF BackOfficer Friendly

CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de

Segurança no Brasil

CVE Common Vulnerabilities and Exposures

DCE Distributed Computing Environment

DDoS Distributed Denial of Service

DNS Domain Name System

GNU GNU is Not Unix

HTTP HyperText Transfer Protocol

ICMP Internet Control Message Protocol

IDS Intrusion Detection System

IGMP Internet Group Management Protocol

IIS Internet Information Services

IP Internet Protocol

NAT Network Address Translation

 13

NetBIOS Network Basic Input Output System

NIDS Network Intrusion Detection System

NTP Network Time Protocol

RAM Random-Access Memory

RPC Remote Procedure Call

SMB Server Message Block

SQL Structured Query Language

SSH Secure Shell

TCP Transmission Control Protocol

UDP User Datagram Protocol

UML User Mode Linux

WINS Windows Internet Name Service

 SUMÁRIO

1 Introdução...............................................................................................................16
1.1 Contexto......................................................................................................................... 16
1.2 Motivação....................................................................................................................... 18
1.3 Objetivo.......................................................................................................................... 18
1.4 Metodologia.................................................................................................................... 18
1.5 Estrutura da monografia.................................................................................................18
2 Fundamentação Teórica........................................................................................20
2.1 Honeypot........................................................................................................................ 20
2.1.1 Classificação dos honeypots....................................................................................................... 20
2.1.2 Nível de interatividade ................................................................................................................ 21
2.1.3 Estrutura dos Honeypots............................................................................................................. 24
2.1.4 Visão geral de cinco honeypots................................................................................................... 24
2.1.5 Benefícios de um Honeypot........................................................................................................ 26
3 Ferramentas utilizadas..........................................................................................28
3.1 Honeyd........................................................................................................................... 28
3.1.1 Recursos...................................................................................................................................... 29
3.1.2 Configuração do Honeyd............................................................................................................. 31
3.1.3 Logs do Honeyd........................................................................................................................... 32
3.2 Honeycomb.................................................................................................................... 33
3.2.1 Rastreamento de conexões......................................................................................................... 35
3.2.2 Análise de protocolos................................................................................................................... 35
3.2.3 Exibição das assinaturas............................................................................................................. 36
4 Proposta..................................................................................................................37
4.1 Implementação do ambiente..........................................................................................37
4.2 Ganhos........................................................................................................................... 39
4.3 Problemas encontrados.................................................................................................40
5 Resultados Obtidos...............................................................................................41
5.1 Dados capturados..........................................................................................................41
 15

5.2 Análise dos dados.......................................................................................................... 41

5.2.1 Análise de trafego referente ao dia 28/03/2010..........................................................................48
5.2.2 Análise de trafego referente ao dia 27/03/2010..........................................................................49
5.2.3 Análise de trafego referente ao dia 19/03/2010..........................................................................49
5.3 Considerações sobre os problemas de assinaturas......................................................50
6 Considerações finais.............................................................................................52
6.1 Considerações...............................................................................................................52
6.2 Trabalhos futuros........................................................................................................... 53
Referências bibliográficas.......................................................................................54
Anexo I.......................................................................................................................55
 1 INTRODUÇÃO

1.1 Contexto

O crescimento dos sistemas computacionais conectados em rede e a oferta cada vez maior
dos serviços oferecidos pela Internet, trazem às instituições o desafio de oferecê-los de
maneira confiável, estável e íntegra. Com essa popularização e crescimento tecnológico
surgiram dificuldades para manter a segurança e estabilidade da infraestrutura envolvida.

A MITRE Corporation em 1999 iniciou o desenvolvimento do Common Vulnerabilities

and Exposures (CVE) que é uma lista, ou dicionário, que fornece nomes comuns padronizados
para as vulnerabilidades de segurança da informação. Na última versão lançada em Agosto de
2010 haviam sido catalogadas 42.982 vulnerabilidades. No Brasil o Centro de Estudos,
Resposta e Tratamento de Incidentes de Segurança no Brasil (CERT.br) mantém estatísticas
de incidentes a ele reportados. A Figura 1.1 apresenta o número de incidentes reportados ao
CERT.br deste 1999 até Junho de 2010.
 17

Figura 1.1: Estatística sobre a quantidade total de incidentes reportados ao CERT.br

Fonte: http://www.cert.br/stats/incidentes/inc-stats.png

A segurança das redes de computadores não pode ser restrita apenas a aspectos técnicos
como firewall's, roteadores, ou outras tecnologias. Envolve também usar aspectos políticos e
sociais, inseridos, normalmente, na política de segurança a rede.

Deste modo, os administradores da rede devem estar conscientes quanto ao nível de

segurança que proporcionam a seus usuários, com base na infraestrutura disponível e na
avaliação dos aspectos não técnicos que influem nas questões de segurança.

A ausência de mecanismos de detecção de ataques contribui para que essas redes sejam
alvo de ataques, sem que alertas sejam produzidos, desta maneira os administradores das redes
não são informados sobre essas ações. Além disso, a falta de informações sobre ataques a rede
pode dar aos administradores a falsa sensação de proteção e segurança.
 18

1.2 Motivação

A motivação para o desenvolvimento deste trabalho surgiu da inciativa de criação de um

honeypot no IFES (Instituto Federal do Espirito Santo) para o grupo de pesquisa em
segurança de redes de computadores LabSeg.

Optou-se por examinar as potencialidades e fraquezas da tecnologia de honeypots para

que alguma ação local de detecção de incidentes possa ser iniciada e gerar assinaturas para
worms e tráfego malicioso. No entanto os honeypots sozinhos não proporcionam segurança;
devendo, desse modo, estarem integrados com outras tecnologias já como firewall, Sistemas
de Detecção de Intrusão (IDS), entre outras; além de uma política de segurança estabelecida e
respeitada dentro de uma determinada rede.

1.3 Objetivo

Criar um mecanismos de monitoramento para se obter informações sobre os ataques que

são realizados sobre a faixa de IP no Ifes – Campus Serra. Com base nestas informações será
possível apresentar uma recomendação dos mecanismos de proteção que devem ser utilizados
nas máquinas e nos servidores.

1.4 Metodologia

A metodologia adotada neste trabalho foi observar os ataques que chegam ao honeypot de
maneira passiva para análise posterior dos dados obtidos. O conjunto de análise destes dados
será realizado por ferramentas especializadas e scripts personalizados para a obtenção de
estatísticas a partir dos arquivos de log gerados pelo honeypot.

1.5 Estrutura da monografia

No capítulo 2 são apresentados os conceitos gerais relacionados aos honeypots, assim

como as diversas classificações existentes, além de uma visão geral sobre os custos, benefícios
e exemplos da utilização da tecnologia para auxiliar a resolução de alguns problemas
relacionados a segurança de redes de computadores.
 19

O capitulo 3 apresenta o modo de funcionamento das ferramentas utilizadas nesse

trabalho. Descreve portanto, a forma de um framework para criação de honeypots virtuais, o
Honeyd e o seu plugin para geração de assinaturas, o Honeycomb. Neste capítulo também são
apresentadas as funcionalidades presentes no Honeyd e no Honeycomb.

O capítulo 4 descreve a solução baseada no ambiente construído. Além de ganhos da

implementação deste trabalho.

As considerações finais e as propostas para trabalhos futuros a serem desenvolvidos

dentro do mesmo escopo deste trabalho são apresentados no capítulo 5.
 2 FUNDAMENTAÇÃO TEÓRICA

“Um honeypot é um recurso computacional de

segurança dedicado a ser sondado, atacado ou
comprometido.”
Neil Provos

2.1 Honeypot

Pode-se definir um honeypot como um recurso computacional, cujo valor está no uso não
autorizado ou ilícito deste recurso. Ou segundo Neil Provos [1],“Um honeypot é um recurso
computacional de segurança dedicado a ser sondado, atacado ou comprometido.”

Honeypots não substituem sua infraestrutura de segurança, pois não faz nenhum tipo de
prevenção. Muito embora, o monitoramento do trafego de dados do honeypot nos permite
recolher informações que não são disponíveis por NIDS (Network Intrusion Detection
System). Por exemplo, podemos registrar os caracteres digitados em uma sessão interativa,
mesmo que o tráfego de rede seja criptografado. Os NIDS para detectar comportamento
malicioso necessitam de assinaturas conhecidas de ataques e muitas vezes não conseguem
detectar comportamento não conhecidos. Por outro lado, honeypots podem detectar
vulnerabilidades ainda não conhecidas. Por exemplo, podemos detectar comportamento
malicioso ao observar o tráfego de rede do honeypot, mesmo se os meios da exploração não
forem conhecidos [1]. Com base nestes comportamentos maliciosos pode-se inferir quais os
melhores mecanismos de segurança para a rede em questão.

2.1.1 Classificação dos honeypots

Há diferentes tipos de honeypots e estes variam de acordo com o contexto em que eles são
aplicados, cada um tendo suas vantagens e desvantagens. O tipo de honeypot a ser usado
depende do objetivo a ser alcançado.
 21

2.1.2 Nível de interatividade

Os honeypots podem ser classificados de acordo com o nível de interatividade, como os

autores Provos e Holz que os classificam em: alta e baixa [1]. Está divisão, pode-se resumir
basicamente a quão próximo o honeypot é de um sistema real.

2.1.2.1 Honeypots de alta interatividade

Honeypots de alta interatividade oferecem ao atacante um sistema completo para

interação. Este tipo de honeypot não emula serviços, funcionalidades ou sistema operacional.
Em vez disso, fornece sistemas e serviços reais. Assim, eles geram uma vasta quantidade de
informações sobre os atacantes [2].

Esta abordagem, no entanto, tem vários inconvenientes. Pois, o atacante poderá ter acesso
a dados pessoais ou comprometer o sistema. Por isso, máquinas virtuais podem ser uma boa
opção para este modelo. Visto que, a máquina virtual não teria nenhuma função operacional,
e poderia ser facilmente substituídas em caso de comprometimento do sistema. Algumas
opções de virtualização disponíveis para honeypots de alta interatividade são: VMware1, User
Mode Linux2 (UML) e VirtualBox3 [1]. O The Honeynet Project mantém um projeto de
honeypot de alta interatividade chamado Honeywall4 [3].

2.1.2.1.1 Vantagens e desvantagens de honeypots de alta interatividade

Honeypots de alta interatividade podem fazer qualquer coisa que é permitido fazer com
um sistema real. Eles normalmente são sistemas computacionais convencionais, como um
computador comum, um roteador ou um switch. Porém, este sistema não têm tarefas
convencionais na rede e não há usuários regularmente ativos. Assim, ele não deve ter qualquer
processo incomum, nem gerar qualquer tráfego de rede, além dos daemons regulares ou
serviços em execução no sistema. Estes pressupostos ajudam na detecção de ataques, pois
cada interação com um dos honeypots é suspeito e pode apontar para uma ação possivelmente

1 Vmware – http://www.wmware.com/
2 User Mode Linux – http://user-mode-linux.sourceforge.net/
3 VirtualBox - http://www.virtualbox.org
4 Honeywall - https://projects.honeynet.org/honeywall/
 22

mal-intencionada. Esta ausência de falsos positivos é uma das principais vantagens dos
honeypots de alta interação, em comparação com sistemas de detecção de intrusão (IDS).

Com honeypots de alta interatividade podemos coletar informações detalhadas sobre os

procedimentos de um atacante, ferramentas utilizadas por ele, táticas e motivações. Por
exemplo, pode-se aprender mais sobre procedimentos típicos de phishing5 e técnicas de roubo
de identidade.

No entanto, o grande risco de honeypots de alta interatividade é o fato de que o atacante

pode ter acesso total a um sistema e a partir desde comprometer outros pertencentes a rede
local ou Internet.

Então em vez de implementar honeypots de alta interatividade em maquinas físicas, um

alternativa é utilizar a arquitetura de maquinas virtuais. Basicamente o sistema operacional da
máquina física hospeda os sistemas virtualizados. Caso o honeypot seja comprometido pode-se
substitui-lo em poucos minutos e então retornar a coleta de dados.

Uma desvantagem que deve-se levar em consideração é o fato de que o atacante pode
diferenciar uma máquina real de uma virtual. Nesse caso, um atacante avançado
comprometeria a honeypot virtual e depois voltaria o honeypot ao estado inicial, a fim de
enganar o investigador, ocultando os dados referentes ao período em que ocorreu o ataque.

2.1.2.2 Honeypots de baixa interatividade

Honeypots de baixa interatividade são tipicamente os mais fáceis para se instalar,

configurar e manter [1]. Esta tecnologia normalmente emula uma variedade de serviços. A
interação do atacante a esses serviços é limitada. Por exemplo, um invasor pode tentar fazer
ataque de força bruta para efetuar o login. O honeypot coletaria essas tentativas, mas não
existiria um sistema operacional real caso o login fosse efetuado [4]. Sendo assim a interação
do atacante se resume a tentativas de efetuar login.

A principal característica dos honeypot de baixa interatividade é a detecção de tentativas

de conexão, pois oferecem funcionalidades limitadas (a maioria é emulada por uma aplicação).
A dificuldade está em monitorar os mecanismos de alerta ou na leitura de logs [4].
5 Phishing é uma fraude eletrônica, caracterizada por tentativas de adquirir informações sigilosas, ao se passar por
uma instituição conhecida.
 23

A quantidade de informação gerada sobre o atacante, por este tipo de honeypot é muito
limitada. Honeypots de baixa interatividade registram basicamente:

• Horário e data do ataque

• Endereço IP e porta de origem do ataque

• Endereço IP e porta de destino do ataque

2.1.2.2.1 Vantagens e desvantagens de honeypots de baixa interatividade

Em honeypots de alta interatividade, quando um adversário explora o sistema, ele pode

obter permissão para instalar outros novos softwares ou modificar o sistema operacional. Isso
não acontece em honeypots de baixa interatividade. Pois em honeypots de baixa interatividade
é oferecido acesso limitado ao sistema operacional, porque não é a intenção dos honeypots de
baixa interatividade representar um sistema operacional completo. Com isso, um honeypot de
baixa interatividade não são uma boa solução para capturar exploits zero-day6. Por outro lado,
pode ser usado para detectar exploits conhecidos e medir a quantidade de vezes que a rede foi
atacada.

Há várias vantagens de se usar honeypots de baixa interatividade. Entre elas destaca-se a

facilidade de instalar, configurar e manter. Não exigem recursos computacionais que possam
ser comprometidos pelo atacante. Mas isso também pode ser descrito como desvantagem.
Visto que, são apenas uma ilusão de serviços reais. De acordo com Lance Spitzner [5], “Em
geral, os honeypots de baixa interatividade são a melhor solução de detecção. Eles são mais
fáceis de implantar e manter do que honeypots de alta interatividade e oferecem menor risco.”

Alguns exemplos interessantes de uso deste tipo de honeypot são para detecção de
servidores comprometidos efetuando ataques como varredura de portas, detecção de
worms/vírus e determinar a tendência dos ataques.

6 Zero-day é uma ameaça que explora vulnerabilidades desconhecidas ou que não há correção disponível.
 24

2.1.3 Estrutura dos Honeypots

Os honeypots também podem ser classificados quanto a estrutura computacional que

utilizam, sendo neste caso divididos entre honeypots físicos e virtuais.

2.1.3.1 Honeypots físicos

Os Honeypots físicos são instalados em maquinas físicas e oferecem um sistema inteiro

para interação, ou seja pode ser que o sistema esteja distribuído. Logo, ser um honeypot físico
implica em ser de alta interatividade, possibilitando o comprometimento do sistema. Esses tipo
de honeypot exige maior disponibilidade de tempo, principalmente quanto a instalação e
manutenção.

Quando há grandes faixas de endereçamento IP, uma melhor estrutura seria a estrutura de
honeypots virtuais. Pois esta estrutura seria menos custosa, pelo fato de implementação e
administração rápida.

2.1.3.2 Honeypots virtuais

Honeypots virtuais emulam sistemas operacionais e/ou serviços. Então se o honeypot

sofrer algum tipo de ataque e for comprometido, será fácil recriá-lo. Um sistema de honeypot
virtual pode ser usado para emular vários serviços, cada um com endereço IP e porta diferente
[6].

Neste conjunto também fazem parte os honeypots de alta interatividade que fazem uso de
ferramentas de virtualização como VirtualBox, VMWare, Xen, User Mode Linux, etc.

2.1.4 Visão geral de cinco honeypots

Existem várias soluções de honeypots disponíveis, nesta sessão, serão destacadas cinco
soluções diferentes. Dentre elas, serão abordadas soluções proprietárias e livres, de diferentes
plataformas e níveis de interatividade.
 25

2.1.4.1 BackOfficer Friendly

BackOfficer Friendly (BOF) é uma solução simples e livre de honeypots desenvolvido por
Marcus Ranum. É uma solução de baixa interatividade, com suporte a varias versões
Windows [4]. Porém seus recursos são limitados a ouvir portas.

2.1.4.2 Specter

Specter é uma solução comercial de honeypots de baixa interatividade desenvolvido pelo

NETSEC. Além de emular vários serviços, o Specter, pode também emular sistemas
operacionais. Porém por ser uma solução de honeypot de baixa interatividade, emula serviços
com interatividade limitada, é de fácil implementação, de manutenção simples, e é de baixo
risco [4].

2.1.4.3 Honeyd

Honeyd é uma solução Open Source7 de honeypot de baixa interatividade desenvolvido

por Neil Provos para plataformas UNIX/Like8. Baseia-se principalmente em uma interface
modo texto, para instalação e configuração.

Seu principal objetivo é capturar e alertar atividades suspeitas, possibilitando monitorar

um faixa de IP com milhões de sistemas. Caso detecte uma tentativa de acesso a algum
endereço no qual não exista nenhum sistema que responda, assumirá então a identidade da
vítima e, em seguida, interagirá com o o atacante, aumentando a capacidade de detecção [1].

2.1.4.4 ManTrap

ManTrap é um honeypot comercial de alta interatividade, disponível para a plataforma

Solaris. Não emula serviços e sim sistemas operacionais. Pode-se instalar aplicativos de
produção, tais como DNS, Servidores Web, ou banco de dados. Esses sistemas operacionais
virtuais tem a mesma interação que um sistema de produção padrão. Assim, pode-se aprender
muito com as técnicas utilizadas pelo atacante. O ManTrap pode detectar varreduras de portas

7 OpenSource ou código aberto é uma terminologia usada para um padrão de desenvolvimento de software em que o
código fonte acompanha o software.
8 UNIX/Like são sistemas operacionais baseados em UNIX.
 26

e tentativas de conexão, além de capturar ataques desconhecidos e novas vulnerabilidades.

Porém, isso implica em risco maior. Porque como o honeypot é um sistema operacional
completo, ele pode ser usado para atacar ou comprometer outros sistemas [4].

2.1.4.5 Honeynet

Honeynets é um tipo de honeypot de alta interatividade projetado para capturar

informações extensas sobre ameaças. A diferença entre um honeypot e uma honeynet é que a
honeynet disponibiliza uma rede inteira para interação do atacante. Ou seja é uma rede que
contém um ou mais honeypot. Porém qualquer interação com o honeypot caracteriza uma
sonda ou ataque. Devido a grande interatividade os arquivos de logs e alertas podem conter
vários gigabytes, o que gera um grande esforço e demanda de tempo para analise,
identificação de ataques e eliminação falsos positivos. Segundo Honeynet Project [7]:

“Em muitos aspectos, é como o clássico problema da agulha no palheiro, como

tentativa de encontrar o incidente crítico entre volumes de informações. Desde de
que uma honeynet é nada mais que uma rede de honeypots, toda atividade é
capturada e caracterizada como desautorizada ou mal-intencionada. Tudo o que se
faz é capturar agulhas. E priorizar qual dessas agulhas tem o maior valor, em
seguida, analisá-los com maior detalhe.

Em muitos aspectos, uma honeynet é como um aquário. Você cria um ambiente

onde você pode assistir a tudo o que acontece dentro dele. No entanto, em vez de
colocar pedras, corais e algas marinhas no seu aquário, você coloca os servidores
de DNS do Linux, as impressoras HP e os roteadores Juniper em sua arquitetura.”

2.1.5 Benefícios de um Honeypot

Honeypots podem ser usados para fins de produção ou de investigação. Se usado para fins
produtivos pode efetuar prevenção, detecção ou auxiliar na resposta de um ataque. Já quando
usado para fins de investigação, será efetuado coleta de informações, para estudar as
atividades do atacante, ou alerta e prevenção de ataque ou trafego malicioso. Normalmente
honeypots de alta interatividade são usados para fins de investigação e honeypots de baixa
interatividade para fins produtivos.

Uma das aplicações de honeypots é a ajuda contra ataques automatizados como worms.
Estes ataques podem ser resumidos em varrer redes à procura de sistemas vulneráveis. Caso
encontre algum sistema vulnerável, esse tipo de ferramenta automatiza o ataque, e em seguida
assume o controle do sistema. Nessa situação, uma medida contra worms é retardar a
 27

varredura, podendo até pará-los. Pois quando esses honeypots são alvo de varreduras, a
interação com o atacante se torna mais lenta. Isso é feito usando truques TCP como o
tamanho de janela zero, caracterizando-o em um padrão de exploração, com isso pode-se
retardar ou impedir a propagação de um worm[5]. Honeypots de baixa interatividade podem
ser usados também para confundir invasores humanos, ao fazê-los perderem tempo com os
serviços limitados. Mesmo que um atacante saiba que uma instituição faça uso de uma solução
de honeypots, ele ficará intimidado, pois ele não saberá quais são os serviços ou sistemas reais,
e quais são os do honeypot. Assim, o ataque pode ser identificado pelo honeypot.

Outras aplicação de honeypots, é o uso destes mecanismos para resposta a incidentes. Por
exemplo, se uma empresa tem um serviço crítico sendo executado em uma máquina que foi
alvo de algum ataque, como fazer uma boa analise forense se este serviço não pode ficar
offline? A alternativa é realizar a analise forense com o serviço em produção o que pode
comprometer a analise. Honeypots são de grande valor em situações como a anterior, porque
podem ser usados em paralelo com os sistema reais, possibilitando, assim, se fazer uma melhor
analise destes honeypots para verificar o impacto de incidentes a sistema que executa um
serviço crítico. Visto que pode-se subir ou descer serviços de honeypots, pois os mesmos não
deveriam ter nenhum trafego de rede.

Para poder responder a um ataque, será necessário um conhecimento aprofundado do que

o atacante fez, como ele interrompeu o serviço, e as ferramentas utilizadas. Neste caso, os
honeypots de alta interação são mais adequados para essa solução, pois proporcionam uma
maior interação com o atacante.
 3 FERRAMENTAS UTILIZADAS

3.1 Honeyd

O Honeyd é um honeypot de baixa interatividade, considerado uma framework para

criação de honeypots virtuais, que permite capturar conexões e tentativas de ataques a partir
da emulação de serviços TCP e UDP, além de mensagens ICMP destinadas aos honeypots.

A interação do Honeyd com os atacantes é limitada apenas ao nível de rede. Por isso, ao
invés de simular todos os aspectos de um sistema operacional, simula sua pilha TCP/IP. O
Honeyd precisa fazer com que seus honeypots virtuais operem em múltiplos endereços IP
simultaneamente, de maneira a preencher a rede com vários honeypots virtuais, simulando
diferentes sistemas operacionais e serviços. A fim de aumentar o realismo da simulação, este
framework é capaz de simular topologias de rede, o que dá suporte a tunelamento e
mecanismo de balanceamento de carga.

Na Figura 3.1 é apresentado como o Honeyd recebe o tráfego direcionado a seus

honeypots. Veja que a máquina física intercepta o tráfego de rede ao enviar para os endereços
IP dos honeypots configurados e simula suas respectivas respostas.
 29

Figura 3.1: Visão geral da arquitetura implementada pelo Honeyd.

Adaptado de Virtual Honeypots: From Botnet Tracking to Intrusion Detection [1].

3.1.1 Recursos

Logo abaixo é apresentado alguns recursos do Honeyd de acordo com Neil Provos [1].

• Simular milhares de hosts virtuais ao mesmo tempo: A principal razão de usar o

Honeyd é a sua capacidade de criar milhares de honeypots virtuais. Assim um atacante
pode interagir com cada hospedeiro da rede e pode-se ter um comportamento diferente
dependendo de como foi configurado.

• Configuração de serviços através de arquivos de configuração: pode-se destinar a

configuração de cada máquina virtual e seus serviços a cada endereço IP.
 30

• Simulação de sistemas operacionais no nível de pilha do TCP/IP: o que permite

enganar o Nmap9 e o Xprobe10, fazendo-os acreditar que o honeypot virtual está
executando um sistema operacional real.

• Simula topologias de roteamento: é possível configurar a latência, perda de pacotes e

largura de banda.

3.1.1.1 Recebimento de dados na rede

O Honeyd é projetado para responder a pacotes de rede cujos endereços IP de destino

pertençam a um dos honeypots simulados. Porém, para que o Honeyd possa responder
corretamente os pacotes, é necessário que a rede na qual a máquina física pertence reconheça
os endereços dos honeypots.

Algumas maneiras de se fazer isso são:

• Através de roteamento específico para os endereços virtuais.

• Utilizar um daemon/proxy ARP.

Foi utilizado neste trabalho o daemon Arpd, pois é a alternativa indicada como tools no
site oficial do Honeyd11.

3.1.1.2 Sistema de personalidades

É comum, que atacantes usem ferramentas de fingerprinting12 como Xprobe ou Nmap,

durante o processo de reconhecimento do alvo, para coletar informações sobre o IP ou a rede
que será alvo do ataque. Então, para que o honeypot pareça um servidor com serviços reais
para estas ferramentas, o Honeyd simula o comportamento da pilha TCP/IP de um sistema
operacional. Essa simulação é chamada de personalidade (personality) de uma honeypot
virtual.

9 Nmap é um software livre para escaneamento de portas.

10 Xprobe é um software livre que lhe permite determinar qual o sistema operacional instalado em uma máquina remota.

11 Página de tools no site oficial do Honeyd - http://www.honeyd.org/tools.php

12 FingerPrinting é uma coleta passiva dos atributos de configuração de um dispositivo computacional, por meio de uma
rede de computadores.
 31

A simulação é feita através de mudanças no cabeçalho do datagrama e do segmento, de

maneira que eles apresentem as mesmas características dos providos de sistemas operacionais
definidos como personalidade no arquivo de configuração do Honeyd.

O Honeyd usa a base de dados do fingerprinting do próprio Nmap como referência para o
comportamento dos protocolos TCP e UDP. Por outro lado, a base de dados do Xprobe, é
usada como referência para o comportamento do protocolo ICMP.

3.1.2 Configuração do Honeyd

A configuração do Honeyd é feita através de um arquivo de texto, que especifica quais

endereços IP serão atribuídos a cada honeypot e quais serviços estarão disponíveis por host. O
pequeno exemplo do arquivo de configuração do Honeyd e apresentado no Quadro 3.1.

create default

set default personality "Linux 2.2.14"

set default default tcp action block

add default udp port 53 "./scripts/dnstool.py"

Quadro 3.1: Exemplo do arquivo de configuração do Honeyd.

3.1.2.1 Comandos

Os comandos do Honeyd se resumem basicamente a create, set, add e bind. Abaixo um

breve comentário sobre cada comando:

• create – Este comando possibilita a criação de novos templates13. Ao contrario dos

comandos set e add que são usados para mudar as configurações de um template
específico.

• set – Atribui uma personalidade do arquivo de fingerprint do Nmap para um template

e, esta personalidade define o comportamento da pilha de rede. Além de definir o

13 Template ou modelo se refere a um sistema computacional totalmente configurado.

 32

comportamento padrão para os protocolos de rede suportados. O comportamento

padrão é definido por um dos seguintes valores: block, reset ou open.

◦ open significa que as portas estão abertas por padrão, afeta pacotes UDP ou TCP.

◦ block significa que todos os pacotes para um protocolo especificado são

descartados por padrão. Se a configuração especificada foi a de block, o honeypot
não reponderá os pacotes destinados ao protocolo especificado ou porta. Pode se
usar essa configuração para simular um firewall.

◦ reset indica que todas as portas são fechadas por padrão. Se for para para o
protocolo UDP, o honeypot responderá com uma mensagem ICMP de destino
inalcançável. Se for TCP, responderá um RST ao pacote SYN.

• add – Permite especificar quais serviços estarão acessíveis remotamente e qual a

plicação deve ser executado em cada porta.

• bind – É responsável por fazer a associação de um template a um endereço IP. Se

nenhum template é associado a um endereço IP, será utilizado então o template
padrão.

3.1.3 Logs do Honeyd

O Honeyd suporta várias maneiras de registro de log. As quais podem ser divididos em
dois níveis: os logs a nível de conexão (eventos referentes a camada de rede e transporte) e os
logs que registram atividades dos serviços (ou seja os eventos da aplicação, sendo seu formato
definido por cada serviço).

Os logs em nível de conexão registram todas as tentativas de conexão e conexões

completadas para todos os protocolos suportados pelo honeypot, e a partir deste log é possível
extrair estatísticas relacionadas sobre quais portas foram mais contactadas pelo atacante. Os
dados encontrados no arquivo de log são: o protocolo de transporte utilizado, o endereço IP
de origem, o endereço IP de destino, a porta de origem, a porta de destino, etc. Como pode
ser visto na Tabela 1.
 33

Tabela 1: Exemplo de log do Honeyd.

Origem Destino
Data Protocolo T Info Cometario
IP Porta IP Porta
02/04/10 15:35 tcp(6) S 10.3.6.139 1827 10.1.2.124 3128 [Windows XP SP1]
02/04/10 15:35 tcp(6) - 10.3.6.139 4378 10.1.2.84 8080 48 S [Windows XP SP1]
02/04/10 15:36 tcp(6) - 10.4.7.196 2671 10.1.2.175 2380 40 RA [FreeBSD 5.0-5.1]
02/04/10 15:39 tcp(6) E 10.3.6.139 1827 10.1.2.123 3128 9950 240
02/04/10 15:40 Icmp(1) - 10.3.5.182 10.1.3.99 11(0): 56

A primeira coluna (Data) apresenta o momento em que o o pacote foi recebido pelo
Honeyd. Já a segunda coluna (Protocolo) contém informações sobre o protocolo utilizado,
geralmente TCP, UDP ou ICMP. A terceira coluna (T) exibe o tipo de conexão, que pode ser:
S para inicio de conexão, E para fim de conexão, e - para representar que não há nenhuma
conexão estabelecida. As quatro colunas seguintes são atribuídas a informações sobre IP e
porta (IP de origem, IP de destino, porta de origem e porta de destino), sendo que para alguns
protocolos essa coluna não se aplica, pois eles não utilizam portas (como é o caso do ICMP
que pertence a camada de rede) [8]. A coluna Info contém informações sobre a conexão ou o
pacote, como por exemplo: tamanho do pacote e flags do cabeçalho. A última coluna
(Comentário) contém um palpite sobre o sistema operacional que originou a conexão ou
tentou se conectar ao honeypot com base no fingerprinting.

3.2 Honeycomb

Honeycomb é um sistema para geração automáticas de assinaturas para NIDS's. Esse sistema é
um extensão para o honeypot de código aberto Honeyd e tem suporte as assinaturas do Snort
e Bro, que são os NIDS's de código aberto mais conhecidos. A pequena abrangência de IDS's
suportados deve-se porque não há um padrão definido para as assinaturas. Logo, cada IDS
possui um padrão diferente para suas assinaturas.

A Figura 3.2 demostra a arquitetura do Honeycomb, na situação de configuração típica do

Honeyd, com o Honeyd simulando diferentes máquinas, cada uma executando serviços pré-
configurados.
 34

Figura 3.2: Diagrama da arquitetura do Honeycomb

Fonte: Honeycomb – Creating Intrusion Detection Signatures Using Honeypots [9].

A integração do Honeycomb com o Honeyd tem muitas vantagens sobre uma abordagem
que captura tráfego direto na rede. A primeira delas é que não há duplicação de esforço: pois
o Honeyd acessa o tráfego de rede, inspecionando o tráfego por meio do uso da biblioteca
libcap e passando pacotes relevantes as pilhas de rede dos hosts simulados e eventualmente
para sistemas configurados. Logo, poupa-se esforço visto que, uma vez que se faz uso de
pacotes que já foram transferidos para o espaço do usuário [9].

Tem-se também a vantagem pelo fato de não existir o problema de cold-start, uma vez
que não existe a dessincronização do estado atual das conexões. Porque quando o Honeyd
recebe um pacote que inicia uma nova conexão, o Honeycomb fica sabendo que a mesma
conexão foi iniciada. A questão de perder o início de uma conexão deixa de ser um problema,
que é comumente encontrado em sistemas que rastreiam o tráfego de rede diretamente para a
inspeção do tráfego [9].
 35

3.2.1 Rastreamento de conexões

O Honeycomb mantém o estado para um número limitado de conexões TCP e UDP 14, o
qual possui peculiaridades com relação a maneira de manter os estados das conexões de rede.
Como o objetivo é gerar assinaturas a partir da comparação do novo tráfego que chega ao
honeypot com aos tráfego vistos anteriormente, não se pode apagar todos os estados de
conexões imediatamente quando uma conexão é terminada (o que pode ocorrer pelo cliente ou
servidor). Ao invés disso, marcam-se apenas as conexões como terminadas, mas as mantém o
maior tempo possível, ou até ter certeza que não será benéfico armazená-las por mais tempo.

Conexões que trocam uma quantidade grande de informação são potencialmente mais
valiosas para detectar padrões de tráfego novos. Porém, o sistema também precisa prevenir
que port scans transbordem a capacidade das tabelas hash de conexões, o que pode causar a
perda de conexões valiosas. Por isto, tanto conexões UDP como TCP são armazenadas em
dois estágios: primeiro as conexões são armazenadas em uma tabela handshake e, se ocorrer
troca de pacotes na conexão, são então movidas posteriormente para uma tabela established.

O Honeycomb realiza também a remontagem de fluxo: para TCP, os fluxos são

remontados até a quantidade de bytes máxima configurada que podem ser trocados em uma
conexão. Estes fluxos são guardados como uma lista de mensagem trocadas até o tamanho
máximo permitido. Então, a mensagem é definida como todos os dados que foram
transmitidos apenas em uma direção, sem qualquer outros dados vindos de outra direção.

Por exemplo, uma tipica requisição HTTP é armazenada em duas mensagens: uma para o
HTTP request (requisição) e uma para o HTTP reply (resposta). Para o UDP é similar,
mensagens são criadas para todos os payloads15 que vem em uma direção, desprezando-se
quaisquer outros dados de outra direção, como mostra a Figura 3.2.

3.2.2 Análise de protocolos

Após a atualização do estado de conexão, o Honeycomb cria um registro vazio de

assinatura para o fluxo e começa a inspecionar o pacote. Cada assinatura tem um identificador

14 Quando é falado de conexões UDP, deseja-se referir a pacotes trocados entre os mesmos pares de endereço IP e porta.

15 Payload, ou carga útil, refere-se ao dado real sendo transmitido. É seguido por um cabeçalho que identifica o
transmissor e o receptor do dado sendo transportado, e é descartado ao chegar no destinatário.
 36

único e armazena os fatos descobertos sobre o trafego investigado, independente de qualquer

formato/linguagem de assinatura utilizadas por cada NIDS. O registro de assinaturas
(signature record) é então acrescido continuamente por meio do processo detecção, sendo
mantido um contador do número de fatos registrados.

A análise do protocolo de rede é feita nos níveis da camada de rede (IP) e transporte
(TCP e UDP), usando técnicas de header-walking utilizadas em processos de normalização de
tráfego. No lugar de anomalias detectadas corretamente, são armazenadas a assinatura em si,
como por exemplo os deslocamentos (offset) inválidos de fragmentação IP e combinações não
usuais de flags TCP. Para realizar essas checagens, o Honeycomb não precisa fazer qualquer
comparação com os pacotes visto por ele anteriormente.

Após essas verificações, o Honeycomb faz então a comparação de cabeçalhos com cada
conexão do mesmo tipo (TCP ou UDP) atualmente armazenada. Se a conexão armazenada já
foi movida para o segundo nível da tabela hash, então o Honeycomb tenta olhar a mensagem
correspondente e usar os cabeçalhos associados com a mensagem. Se algum tipo de
sobreposições (como identificadores IP ou faixa de rede) são detectadas, a análise de
assinaturas é clonada e torna-se específica para os fluxos comparados. Os fatos descobertos
são então armazenados na forma de uma nova assinatura.

3.2.3 Exibição das assinaturas

O conteúdo das assinaturas geradas são enviados periodicamente para o módulo de saída
que implementa o formato dos registros de assinaturas. Durante o desenvolvimento deste
trabalho, apenas os módulos que convertem os registros da assinatura nos formatos lidos pelo
Bro16 e Snort 17, e um módulo que escreve as strings das assinaturas em um arquivo estavam
implementados.

O regime de apresentação periódica de relatórios é uma maneira fácil de certificar-se que

todas as assinaturas são relatadas, e permite também o acompanhamento da evolução dos
registros de assinaturas através do identificador de assinatura.

16 Bro - http://www.bro-ids.org/

17 Snort - http://www.snort.org/
 4 PROPOSTA

A proposta deste trabalho baseia-se na utilização de um honeypot de baixa interatividade

para obtenção de dados sobre ataques a rede do Ifes, avaliação e usos deste tipo de tecnologia.
Para tanto, foi escolhido o Honeyd com base nas justificativas do próximo paragrafo.

Foi feita a escolha por honeypots de baixa interatividade devido a vários fatores como: a
possibilidade de aprender os conceitos básicos envolvidos nos ataques de forma mais simples
do que a requerida na análise de incidentes de honeypots de alta interatividade, os recursos
computacionais disponíveis para a realização dos experimentos, o menor custo de manutenção
e devido a melhor adequação do contexto da rede onde foram instalados.

4.1 Implementação do ambiente

O primeiro item executado para a montagem do ambiente foi a alocação de uma máquina
física para à execução do experimento. Como dito na Fundamentação Teórica, os honeypots
de baixa interatividade não necessitam de uma máquina que tenha um alto poder de
processamento e/ou grande capacidade de memória, com isso pode-se usar máquinas que já
não são mais adequadas para ambientes de produção. O qual foi o caso neste trabalho, a
máquina utilizada já não fazia parte das máquinas alocadas para ambiente de produção,
pertencia a um dos laboratórios de informática do campus Serra, porém foi substituída. Suas
configurações incluem o processador Intel Pentium 4 de 3.0GHhz e 1GB de memória RAM.
Estas configurações são mais do que suficientes para a execução do Honeyd.

O sistema operacional utilizado foi a distribuição GNU/Linux CentOS 5.4, pois a mesma
possibilitou a instalação do Honeyd com a integração do plugin Honeycomb, sem que
houvessem problemas de segmentation fault, como constatado no Debian GNU/Linux versão
5.0.
 38

Para evitar a indisponibilidade do ambiente (Honeyd com adição do plugin Honeycomb),

foi criado um script em Shell para verificar se o processo Honeyd estava sendo executado, se
o retorno fosse falso o Honeyd era iniciado e o script geraria um log com a data e hora em que
o serviço foi iniciado. Quanto a integridade em relação a data e hora, foi configurado a
sincronia do relógio com o NTP (Network Time Protocol).

Foi disponibilizado pelo Ifes uma sub-rede /28 (que contém 16 endereços IP), porém só
podem ser utilizados 14 (quatorze) endereços IP, sendo o primeiro alocado para endereço de
rede e o último para endereço de broadcast. Dentre os 14 (quatorze) endereços IP validos,
foram utilizados nesse trabalho 10 (dez), pois os outros 4 (quatro) endereços foram
disponibilizado para outros projetos. Portanto, a subdivisão destes 10 (dez) IP's foi feita da
seguinte forma: um endereço para a máquina física (que hospedará o Honeyd e suas
“emulações”) e outros 9 (nove) IP's serão destinados aos templates do Honeyd, conforme
pode ser visto na Figura 4.1.

A fim de evitar o comprometimento de futuras pesquisas que poderão utilizar a mesma

sub-rede deste trabalho, não será disponibilizado os reais endereços IP da rede. Porém será
adotado uma regra de comparação, na qual o primeiro dos 9 (nove) IP's alocados pelo Honeyd
serão renomeados para a.b.c.03 e o último para a.b.c.11. Pode-se ter uma melhor visão desta
alocação por meio da Figura 4.1.

Figura 4.1: Estrutura da distribuição da faixa de IP's referente a rede /28

 39

Para que os honeypots virtuais gerenciados pelo Honeyd pudessem receber as requisições
de atacantes externos foi necessário que o tráfego destinado aos endereços IP's dos quais eles
estavam configurados fosse direcionado para a máquina física. Dentro deste contexto foi
utilizado o ARPd, que é um daemon cuja tarefa é responder às requisições ARP, realizadas
para descobrir qual máquina responderá por determinado endereço IP. Assim, o ARPd produz
o pacote ARP de resposta e diz que a interface da máquina física pode responder a requisições
referentes a determinado endereço IP configurado para um honeypot virtual do Honeyd.
Quando o pacote chega até a interface da máquina física, o Honeyd pode então capturá-lo e
fazer as devidas operações com o mesmo, seja abrir, manter, fechar uma conexão, ou ainda
repassar o pacote para determinado serviço que esteja configurado.

O plugin Honeycomb foi compilado separadamente e depois integrado ao Honeyd. Ele foi
utilizado apenas para verificar o funcionamento do mecanismo de plugins do Honeyd e para
avaliar como ocorre a geração de assinaturas de detecção de intrusão e as razões para geração
deste tipo de assinaturas.

4.2 Ganhos

Foi descrito no tópico 2.1.2.2.1, as vantagens de utilizar o honeypot virtual de baixa

interatividade Honeyd são: instalação, configuração e manutenção.

Dentre os ganhos do uso desta ferramenta pode-se notar o baixo custo de tempo, tanto
para implementação quanto para a manutenção, visto que não é necessário um
acompanhamento constante para evitar o comprometimento do sistema, como acontece em
honeypots de alta interatividade.

Como é utilizado um honeypot virtual, tem-se o economia de hardware, pois pode-se ter
vários templates de diferentes sistemas operacionais no mesmo sistema real.

Pelo fato do Honeyd consumir poucos recursos de hardware, foi possível emular os 10
(dez) templates utilizados para povoar a rede disponível para este trabalho em uma mesma
máquina física. E mesmo com o Honeyd e o plugin Honeycomb a carga máxima do sistema
real não ultrapassou 9% e carga média 0.9%.
 40

O principal ganho em utilizar o Honeyd com o plugin Honeycomb é o fato de que no

Honeycomb não há perda de desempenho no processo de geração de assinaturas. Pois, quando
é feito o processamento do pacote pelo Honeyd os dados contidos são também analisados pelo
plugin Honeycomb, não sendo necessário um novo processamento para analise deste pacote
para gerar assinaturas.

4.3 Problemas encontrados

Durante a implementação do ambiente e a escrita deste trabalho foram encontrados alguns

problemas que serão descritos abaixo.

Quanto a implementação, a grande dificuldade foi o problema de segmentation fault ao

executar o Honeyd com o plugin Honeycomb, o que consumiu três semanas de trabalho, visto
que a primeira opção de sistema operacional foi a distribuição Debian GNU/Linux, devido sua
grande popularidade quanto a estabilidade, confiabilidade e segurança. Porém, não foi obtido
êxito, pois logo após a iniciar o processo (Honeyd), era constatado através dos arquivos de
log's a queda do processo devido a falhas de segmentação (segmentation fault). A solução foi
usar a distribuição GNU/Linux CentOS, que foi indicada pelo fórum do Honeyd como a que
tem um melhor suporte ao Honeyd com o plugin Honeycomb. No entanto, constatado-se
algumas quedas devido a falhas de segmentação, por meio da leitura do arquivo gerado pelo
script que verificava se o Honeyd havia caído. Mas essas quedas não foram frequentes, em
média uma a cada 2 dias.

Já a segunda dificuldade foi relacionada a pouca documentação sobre o plugin

Honeycomb. Só foram encontrados 2 artigos sobre essa aplicação, ambos do próprio
desenvolvedor do projeto. Por isso também houve dificuldade quando a implementação do
ambiente, pois não havia instruções de instalação, apenas a lista de dependências para
compilação do Honeyd com o plugin Honeycomb. Devido a este fato foi criado e incluído
neste trabalho como anexo um guia de compilação e instalação do Honeyd com o plugin
Honeyd e suas dependências.
 5 RESULTADOS OBTIDOS

5.1 Dados capturados

Assim como descrito na sessão 4.1 Implementação do ambiente, o período de coleta de

dados ocorreu entre o dia 5 (cinco) de Março e o dia 11 (onze) de Abril. Neste período foram
trafegados 336.213 pacotes, sendo a média de 8.847 pacotes por dia.

É importante ressaltar que toda rede a qual os honeypots faziam parte não deveriam
receber qualquer tipo de tráfego, pois não se tratava de uma rede de produção. Logo, assumiu-
se que todo o tráfego direcionado aos endereços IP alocados aos honeypots eram tentativas de
ataque/intrusão.

5.2 Análise dos dados

Para análise do arquivo de log gerado pelo Honeyd foi utilizado a ferramenta Sawmill18,
pois o tamanho do arquivo de log analisado foi de 28 MB. Foram feitos testes com o
Honeyview e o Honeysum, que são indicados como tools no site oficial do Honeyd para gerar
gráficos de seus logs, porém no quesito qualidade dos gráficos e organização das informações
o Sawmill demonstrou melhores resultados.

A primeira análise realizada foi a do número de pacotes recebido por dia pelos honeypots
durante os 40 dias de observação. A qual pode-se observar de acordo com a Figura 5.1. Já a
Tabela 2 mostra os dias com maior trafego de pacotes referentes ao período de coleta de
dados.

18 Disponível em versões para plataforma Microsoft Windows e GNU/Linux através do endereço:

http://www.sawmill.net .
 42

Figura 5.1: Número de pacotes recebidos por dia.

Tabela 2: Dias com maior trafego de

pacotes.

Dia Número de pacotes

28/03/10 17850
27/03/10 17315
19/03/10 17245
23/03/10 15486
26/03/10 14701
20/03/10 12141
14/03/10 11318
11/03/10 10840
05/04/10 10768
13/04/10 10510

Com base na Tabela 2 pode-se notar a grande diferença entre os três dias com maior
trafego (28, 27 e 19 de Março) e a média de tráfego(8.847 pacotes por dia) de todo o período
de coleta. Por isso, optou-se posteriormente por fazer uma análise pontual desses dias para
tentar descobrir algumas características dos ataques que neles ocorreram.

Por conseguinte, foi examinado o número de pacotes recebidos em relação aos dias da
semana. A Figura 5.2 exibe o comparativo a quantidade de pacotes recebidos pelos honeypots
virtuais em relação a este critério. Com base nesta figura, pode-se notar que os números de
pacotes recebidos em um dia não se difere tanto se comparado a algum outro dia da semana.
Logo, pode-se concluir que os ataques não tiveram um dia especifico para acontecer,
principalmente pelo fato de em sua maioria serem automatizados.
 43

Figura 5.2: Média do número de pacotes recebidos por dias da semana.

Na Figura 5.3 demonstra a relação quanto à distribuição dos pacotes recebidos em relação
a hora do dia. Nesta relação, é notória a queda em relação aos pacote recebidos no período
entre 2:00 e 7:00 horas. Uma possível justificativa é obtida analisando os seguintes tópicos:

• Mais de 78% dos ataques são originados por maquinas com Windows XP
SP1.

• A maior porcentagem dos ataques são originados do Brasil (responsável por

49,8% do tráfego de pacotes).

Levando em consideração os tópicos acima, pode-se supor que os sistemas atacantes

estão sendo utilizados como botnets19, visto que esses sistemas estão desatualizados 20. Como
também, essa suposição, explicaria a queda de ataques no período entre 2:00 às 7:00 horas,
pois, no Brasil, o uso pessoal e comercial nesses horários é reduzido.

Figura 5.3: Histograma relativo ao número de pacotes recebidos pelos honeypots em relação a hora do dia.

19 Botnets são uma coleções de robôs que atuam sob um único gerenciamento, se tornaram uma ameaça importante à
segurança da rede.
20 O ultimo SP (Service Pack) do Windows XP é o SP3.
 44

A Tabela 3 contém estatísticas em relação aos protocolos mais utilizados. Note que há
protocolos da camada de transporte (TCP e UDP) e protocolos da camada de rede (ICMP e
IGMP).

Tabela 3: Número total de pacotes recebidos

por cada protocolo.

Pacotes
Protocolo
Numero Porcentagem
TCP(6) 247,304 73.2 %
ICMP(1) 52,224 15.5 %
UDP(17) 38,266 11.3 %
IGMP(2) 28 0.0 %

Total 337,822 100.0 %

De acordo com a Tabela 3 o protocolo com mais pacotes recebidos é o TCP (73,2%),
isso devido a esse protocolo ser muito utilizado por worms e port scan. Por outro lado,
pacotes UDP, que neste trabalho representaram 11.3%, são normalmente utilizados em
ataques de negação de serviço.

Pacotes ICMP representaram 15,5% do total de pacotes recebidos; neste caso não há
como determinar o motivo de seu uso uma vez que eles podem ser utilizados desde para a
varredura de hosts a partir de ping feitos por usuários (ou worms) até ataques de negação de
serviço baseados no envio de pacotes ICMP.

Apenas uma pequena parcela dos pacotes (28 pacotes) foram relativos ao protocolo
IGMP. Com base nesse protocolo não é possível afirmar a natureza destes pacotes uma vez
que o Honeyd apenas registra poucas informações sobre eles. As vulnerabilidades mais
comuns que utilizam esse tipo de protocolo estão relacionadas a falhas na família de sistemas
operacionais Windows.

A Tabela 4 lista os países que mais enviaram pacotes para os honeypots. Note que apesar
desta lista, o verdadeiro controlador dos ataques pode não pertencer aos países listados
abaixo, o mesmo pode ter comprometido hosts dos países listados para só então atingir o alvo.
 45

Tabela 4: Lista de países que mais enviaram

pacotes para os honeypots virtuais.
Pacotes
Pais
Números Porcentagem
Brasil 156217 49,80%
China 34680 11,10%
EUA 21670 6,90%
Taiwan 9376 3,00%
Coreia do Sul 5085 1,60%
Japão 4283 1,40%
Canadá 3988 1,30%
Rússia 3737 1,20%
Alemanha 3688 1,20%
México 2894 0,90%

De acordo com os trabalhos e artigos gerados como o de (STEDING-JESSEN;

VIJAYKUMAR; MONTES, 2008) [10], pode-se notar que países como Alemanha, Brasil,
Canadá, Coreia do Sul, China, Estados Unidos, Taiwan e Japão também são listados entre os
10 (dez) países em que mais originam atividades maliciosas. Porém, as abordagens foram
distintas visto que a classificação de (STEDING-JESSEN; VIJAYKUMAR; MONTES, 2008)
[10] foi feita com base no número de spams enviados.

Um outro aspecto analisado foi a quantidade de pacotes recebidos por cada honeypot
virtual criado. A Tabela 5 mostra exatamente o percentual de pacotes recebidos por cada
endereço IP dos honeypots virtuais.

Tabela 5: Porcentagem de pacotes

recebidos pelos honeypots virtuais
no período de coleta dos dados.

IP Porcentagem
a.b.c.3 25.2 %
a.b.c.5 21.8 %
a.b.c.8 9.3 %
a.b.c.10 8.4 %
a.b.c.4 8.0 %
a.b.c.9 7.7 %
a.b.c.11 7.1 %
a.b.c.7 6.8 %
a.b.c.6 5.7 %
 46

As diferenças nos valores se devem ao fato de que diferentes atacantes lançaram

quantidades distintas de pacotes aos honeypots e que, em geral, os ataques não sondam todos
os honeypots, mas apenas parte deles.

O próximo quesito avaliado foi a relação de pacotes recebidos com as 10 (dez) portas de
destino que receberam maior tráfego, como mostra a Tabela 6.

Tabela 6: Relação do trafego

de pacotes recebidos com as
portas de destino.

Portas Pacotes
445 24.6 %
139 20.0 %
1433 13.4 %
22 6.1 %
137 3.2 %
135 2.7 %
8080 2.1 %
80 1.8 %
138 1.4 %
4899 1.2 %

A porta 445 é utilizada pelo SMB (Server Message Block) em sistemas Windows. Esse
serviço possibilita o compartilhamento de arquivos entre sistema Windows. É também
utilizadas por trojans e backdoors como: Nimda, Lioten, Sasser e Spybot.

As portas 137, 138 e 139 são utilizadas pelo serviços de NetBIOS do Windows. O
NetBIOS fornece um conjunto uniforme de comandos para solicitação de serviços de baixo
nível, exigidos para gerenciar nomes, orientar sessões e enviar datagramas entre os nós de uma
rede. Um exemplo de uso malicioso destas portas é quando o atacante faz ataques de DDOS
as sessões de NetBIOS. Mas também pode ser usado por ferramentas de invasão como:
Chode, Nimda, Msinit e Bugbear.

A porta 1433 é utilizada normalmente pelo serviço Microsoft SQL Server para edições
para desktop, que são geralmente fornecidas com outras aplicações da Microsoft. Um dos
worms que explora esta porta é o Slammer, cujo seu pico de atividade ocorreu no ano de
2003.
 47

A porta 22 é a porta padrão utilizada pelos servidores SSH. É utilizada também por
trojans como o Adore SSHD e o Shaft.

A porta 135 é usada pelo DCE/RPC Locator service (que é usado para gerenciar
remotamente serviços como o servidor DHCP, DNS e WINS). Um exemplo de worm que
utiliza essa porta é o Blaster, sendo seu período de maior propagação entre os anos de 2003 a
2005.

As portas 80 e 8080 são utilizadas normalmente por servidores Web (como exemplo
Apache, Microsoft IIS e o Apache Tomcat).

A porta 4899 é uma das portas utilizadas pelos serviços de controle/acesso remoto VNC e
Radmin.

Outro item avaliado foi a relação dos 10 (dez) sistemas operacionais que mais originaram
ataques. Como base na Tabela 7, pode-se notar que a grande maioria dos ataques, onde foi
possível realizar a resolução remota do sistema operacional do host através da base de
fingerprinting do Nmap ou do Xprobe, eram provenientes de sistemas Windows. Em menor
escala temos Linux e outros sistemas operacionais como Solaris e FreeBSD.

Tabela 7: Sistemas operacionais que mais

originaram ataques.

Sistema Operacional Pacotes

Windows XP SP1 78,20%
Linux 2.6.1-7 14,50%
Windows 2000 RFC1323 3,80%
Windows 2000 2,30%
Windows XP 0,50%
Windows 98 0,30%
Linux google 0,20%
Solaris 2.9 0,05%
Linux 2.4 cluster 0,02%
FreeBSD 4.0-4.2 0.01%
 48

O fato de que a maioria dos pacotes recebidos terem sido originados de sistemas
Windows é coerente a lista de portas mais utilizadas para os ataques como mostra a Tabela 6,
pois a maioria está ligada a serviços que executados exclusivamente em estações Windows.

5.2.1 Análise de trafego referente ao dia 28/03/2010

Após restringir a análise do arquivo de log à parte relativa aos ataques ocorridos no dia
28/03/2010, procurou-se analisar os outros campos afim de descobrir que tipo de ataque
ocasionou o número de ataques maior do que o dobro da média de pacotes recebidos por dia,
que é de 8.847.

Ao utilizar essas estatísticas extraídas por meio da ferramenta de leitura de logs Sawmill,
detectou-se que dos 17.850 pacotes recebidos, 69,9% desses utilizavam o protocolo TCP,
enquanto 24,5% utilizavam UDP e apenas 5,6% eram de mensagens ICMP. Foi também
verificado que a maioria dos pacotes (65,3%) teve como destino o IP a.b.c.3, mas não foi
possível determinar a razão deste comportamento, visto que havia outro template com as
mesmas configurações e esse obteve praticamente o mesmo percentual de pacotes recebidos
do que os demais endereços IP alocados a este trabalho.

Ao analisar os endereços IP de origem dos pacotes, observou-se que 23,2% deles vieram
do endereço 187.113.92.167, que é um endereço IP de origem brasileira, mais especificamente
do estado do Espirito Santo. No momento do ataque a máquina alocada a este IP utilizava o
sistema operacional com kernel Linux 2.6.1-7.

As portas que mais receberam pacotes foram a 445/TCP e 139/TCP, com respectivamente
10,7% e 10,6% do total de pacotes recebidos. Os serviços Windows que utilizam essas portas
tem um longo histórico de vulnerabilidades exploradas, um exemplo seria o Conficker.

Neste dia foi recebido pacotes originados de sistemas FreeBSD e NetBSD, porém ambos
juntos não ultrapassam o percentual de 0,1% do total de pacotes recebidos.
 49

5.2.2 Análise de trafego referente ao dia 27/03/2010

O tráfego referente ao dia 27 de Março de 2010 foi selecionado e aplicado os mesmos

procedimentos de avaliação do tópico acima, no qual foi analisado os logs gerados no dia 19
de março de 2010. A partir das informações obtidas, vale notar que o número de pacotes
recebidos nesse dia é bem próximo ao dobro da média (8.847 pacotes por dia) de pacotes
recebidos durante todos o período de coleta de dados deste trabalho.

Ao analisar esses logs, nota-se que dos 17.315 pacotes recebidos neste dia, 52,6% desses
utilizavam o protocolo TCP, enquanto 39,6% utilizavam UDP e apenas 7,8% eram de
mensagens ICMP. A maioria dos pacotes (51,6%) teve como destino o IP a.b.c.3, mas
também não foi possível determinar a razão deste comportamento, visto que havia outro
template com as mesmas configurações e esse obteve praticamente o mesmo percentual de
pacotes recebidos do que os demais endereços IP alocados a este trabalho.

Os pacotes recebidos neste dia estavam distribuídos de forma mais igualitária em

comparação com o dia 28 de Março de 2010, mas houve o destaque do endereço IP
189.17.212.38 que foi responsável por 11% do total de pacotes recebidos no dia 27 e por
13.4% do todos de pacotes recebidos nos 40 dias de coleta de dados deste trabalho. Esse
endereço IP pertence a range de endereços alocados ao Brasil, mais precisamente ao estado de
Pernambuco. No momento do ataque este IP estava alocado a uma máquina com Windows
XP SP1.

As portas que receberam os pacotes foram a 139/TCP, 445/TCP e 137/TCP. Os serviços

Windows que utilizam essas portas tem um longo histórico de vulnerabilidades exploradas.
Sendo a maioria originados de sistemas Windows, como descrito no decorrer do tópico 5.1.

Neste dia foi recebido pacotes originados de sistemas como NetBSD, SunOS e
ExtremeWare, porém juntos não ultrapassam o percentual de 0,3% do total de pacotes
recebidos.

5.2.3 Análise de trafego referente ao dia 19/03/2010

Após restringir a análise do arquivo de logs à parte relativa aos ataques ocorridos no dia
19/03/2010, procurou-se analisar os outros campos afim de descobrir que tipo de ataque
 50

ocasionou o número de ataques próximo ao dobro da média de pacotes recebidos por dia, que
é de 8.847.

Utilizando então as estatísticas, detectou-se que dos 17.245 pacotes recebidos, 87,4%
desses utilizavam o protocolo TCP, enquanto 7,8% eram de mensagens ICMP e apenas 4,8%
utilizavam UDP. Foi também verificado que os pacotes foram recebidos por todos os
honeypots virtuais em nível praticamente equivalente.

Ao observar os endereços IP de origem dos pacotes, observou-se que 65,2% deles

originaram-se do endereço IP 200.168.125.31: que é um endereço IP pertencente a uma
empresa de telefonia de São Paulo - Brasil e no momento do ataque estava alocado a uma
máquina que utilizava o sistema operacional Windows XP SP1.

Após a observação da maior parte dos pacotes terem sido originados pelo endereço IP
200.168.125.31, foi feito então uma analise das portas que receberam maior quantidade de
pacotes originados deste IP. Porém, nenhuma das portas receberam uma quantidade de
pacotes superior a 0,1% do total. Devido os pacotes terem como origem mais de 5.015 portas
diferentes e nenhuma delas recebeu mais do que 0,1% do total de pacotes, pode-se concluir
que este IP efetuou um ataque de varredura de portas, a fim de identificar vulnerabilidades.

O único sistema operacional diferente do família Microsoft Windows que originou ataque
neste dia foi o Linux versão do kernel 2.6.1-7, que foi responsável por 2,3% do total de
pacotes recebidos. Dentre os ataques originados por sistemas Linux, 81,1% dos ataques foram
originados pelo endereço IP 201.6.118.136, endereço esse pertencente a uma empresa de
internet a cabo, também de São Paulo – Brasil. Quanto a porta de destino que mais recebeu
pacotes originados de maquinas Linux foi a porta 22/TCP com 92,8% dos pacotes .
Possivelmente um ataque com o propósito de explorar os servidores SSH que usam a porta 22
como padrão em sistemas Unix-like.

5.3 Considerações sobre os problemas de assinaturas

Ao analisar o arquivo de assinaturas do Honeycomb foi constatado que o arquivo de

tamanho 1,9 GB não continha nenhuma assinatura válida, apenas alertas. Um outro ponto
negativo foi o fato de geração de regras referente a tráfego de broadcast e endereços
 51

multicast, gerados por algumas máquinas que pertenciam a mesma sub-rede onde foram feitos
os experimentos.
 6 CONSIDERAÇÕES FINAIS

6.1 Considerações

Como resultado deste trabalho, tem-se a implementação de um primeiro ambiente de

monitoramento de ataques por meio da utilização da tecnologia de honeypots. Estrutura essa
que permite a geração de informações sobre ataques a rede do Ifes, e possibilita que alertas
sejam gerados para os administradores de rede do Ifes, sem depender totalmente do envio de
avisos sobre ataques por meios externos.

Foi constatado o quão exposta está uma máquina com acesso direto a internet, sem
proteções como firewall, antivírus e outros mecanismos de segurança. Pois no ambiente
montado para o experimento no primeiro dia, obteve por exemplo um número de pacotes
próximo a média total (8.847 pacotes por dia), já no segundo dia foi obtido um número de
pacotes maior do que a média total.

O Honeyd mostrou-se eficaz na geração de estatística de atividade maliciosa relacionada

as camadas de rede e de transporte. E de acordo com os experimentos mostrou também que
essa ferramenta pode ser útil na determinação de alguns comportamentos do tráfico malicioso
presente em redes onde os honeypots forem instalados.

Analisando os resultados obtidos neste trabalho, conclui-se ainda que o aumento atual das
ameaças de segurança é um fator decisivo para que a instituição se preocupe cada vez mais
com a a segurança da rede e justifique um maior incentivo de novos trabalhos nessa área e no
uso da tecnologia de honeypots.

Os processos de instalação e configuração das ferramentas utilizadas foram incluídos

como anexo no fim deste trabalho.
 53

6.2 Trabalhos futuros

Como trabalhos futuros, propõe-se a avaliação de outros tipos de honeypots, além da

implementação destes tanto na rede interna quanto externa. Visto que este trabalho focou no
uso de honeypots apenas na rede externa e com o uso de honeypots de baixa interatividade,
sendo recomendado o uso de honeypots de alta interatividade, para avaliar as técnicas
utilizadas por atacantes.
 REFERÊNCIAS BIBLIOGRÁFICAS

[1] Neil Provos; Thorsten Holz. Virtual Honeypots: From Botnet Tracking to Intrusion
Detection, Addison Wesley Professional, 2007. ISBN 978-0-321-33632-3

[2] The Honeynet Project. Know Your Enemy: Revealing the Security Tools, Tactics, and
Motives of the, Addison Wesley Professional, 2001. ISBN 978-0201746136.

[3] Honeynet Project. Research Alliance, Know Your Enemy: Honeywall CDROM, 2005.
Acessado em 23 de agosto de 2010. Disponível em:
<http://old.honeynet.org/papers/cdrom/roo/index.html>.

[4] Lance Spitzner. Honeypots: Tracking Hackers, Addison Wesley, 2002. ISBN 0321108957.

[5] Lance Spitzner. Honeypots Definitions and Value of Honeypots, 2003. Acessado em 23 de
agosto de 2010. Disponível em: <http://www.tracking-hackers.com/papers/honeypots.html>.

[6] Roger A. Grimes. Honeypots for Windows, Apress, 2005. ISBN 1590593359.

[7] Honeynet Project. Know Your Enemy: Honeynets, 2006. Acessado em 23 de agosto de
2010. Disponível em: <http://old.honeynet.org/papers/honeynet/>.

[8] James F. Kurose, Keith W. Ross. Computer Networking: A Top-Down Approach,

Addison-Wesley, 2009. ISBN 0-13-608084-7.

[9] Christian Kreibich, Jon Crowcroft. Honeycomb – Creating Intrusion Detection

Signatures Using Honeypots, 2003.

[10] Klaus Steding-Jessen, Nandamudi L. Vijaykuma, Antonio Montes.

Using low-interaction honeypots to study the abuse of open proxies to send spam .
INFOCOMP Journal of Computer Science, v. 7, n. 1, p. 45–5 , 2008.
 ANEXO I

GUIA DE INSTALAÇÃO E CONFIGURAÇÃO DO HONEYD COM O PLUGIN

HONEYCOMB
 56

INTRODUÇÃO

Esse guia de instalação e configuração do Honeyd com plugin Honeycomb tem como
objetivo prover, instruções simples de como instalar o Honeyd e o Honeycomb de forma
rápida e precisa, tendo em vista uma eventual implementação de um honeypot de baixa
interatividade. Avaliei ser necessária tal abordagem para que, com os códigos de exemplo que
fazem parte de nosso modelo de instalação, seja possível familiarizar-se rapidamente com a
ferramenta e suas possibilidades. Nos capítulos finais, são apresentadas configurações
sugeridas para o Honeyd.

PRÉ-REQUISITOS

Abaixo, os pré-requisitos para a instalação:

SISTEMA OPERACIONAL

Estas instruções foram escritas utilizando o Centos 5.2.

PACOTES REQUERIDOS

É necessário ter os seguintes pacotes instalados antes de prosseguir:

• Compilador GCC e bibliotecas de desenvolvimento

• Compilador Python

• Compilador Perl

• Biblioteca libcap, libtool e zlib

Você pode usar gerenciador de pacotes YUM para instalá-los, seguindo os comandos
abaixo:

#> yum install pcre pcre-devel libpcap libpcap-devel gcc gcc-c++

libtool readline-devel zlib-devel python-devel
 57

INICIANDO A INSTALAÇÃO

Vamos agora compilar e instalar o Honeyd, Honeycomb e as bibliotecas Libevent, Libnet

e Libtree.

INSTALAÇÃO DA BIBLIOTECA LIBEVENT

Crie diretório para armazenar os downloads:

#> mkdir ~/downloads

#> cd ~/downloads

Baixe os códigos fonte em .tar:

#> wget http://monkey.org/~provos/libevent-1.4.8-stable.tar.gz

Extraia o arquivo comprimido .tar:

#> tar -zxvf libevent-1.4.8-stable.tar.gz

Entre no diretório onde foi extraído o arquivo:

#> cd libevent-1.4.8-stable

Rode o script de configuração da biblioteca Libevent, passando o diretório onde será feita
a instalação, da seguinte maneira:
 58

#> ./configure –prefix=/usr/local/libevent

Compile o código fonte da Libevent:

#> make

Instale os binários

#> make install

Saia do diretório atual e volte para o ~/downloads:

#> cd ..

INSTALAÇÃO DA BIBLIOTECA LIBDNET

Baixe os códigos fonte em .tar:

#> http://prdownloads.sourceforge.net/libdnet/libdnet-
1.11.tar.gz?download

Extraia o arquivo comprimido .tar:

#> tar -zxvf libdnet-1.11.tar.gz

Entre no diretório onde foi extraído o arquivo:

 59

#> cd libdnet-1.11

Rode o script de configuração da biblioteca Libdnet, passando o diretório onde será feita
a instalação, da seguinte maneira:

#> ./configure –prefix=/usr/local/libdnet

Compile o código fonte da Libdnet:

#> make

Instale os binários:

#> make install

Saia do diretório atual e volte para o ~/downloads:

#> cd ..

INSTALAÇÃO DO HONEYD

Baixe os códigos fonte em .tar:

#> wget http://www.citi.umich.edu/u/provos/honeyd/honeyd-

1.5c.tar.gz
 60

Extraia o arquivo comprimido .tar:

#> tar -zxvf honeyd-1.5c.tar.gz

Entre no diretório onde foi extraído o arquivo:

#> cd honeyd-1.5c

Rode o script de configuração da biblioteca Libdnet, passando por parâmetro as

bibliotecas Libevent e Libdnet , seguido por o parâmetro Python, da seguinte maneira:

#> ./configure --prefix=/usr/local/honeyd --with-

libevent=/usr/local/libevent --with-libdnet=/usr/local/libdnet
--with-python

Compile o código fonte do honeyd:

#> make

Instale os binários:

#> make install

Copie o diretório scripts do para para /usr/local/honeyd:

#> cp -r scripts/ /usr/local/honeyd

 61

Saia do diretório atual e volte para o ~/downloads

#> cd ..

INSTALAÇÃO DA BIBLIOTECA LIBTREE

Baixe os códigos fonte em .tar:

#> wget http://www.icir.org/christian/downloads/libstree-

0.4.2.tar.gz

Extraia o arquivo comprimido .tar:

#> tar -zxvf libstree-0.4.2.tar.gz

Entre no diretório onde foi extraído o arquivo:

#> cd libstree-0.4.2

Rode o script de configuração da biblioteca Libdnet, da seguinte maneira:

#> ./configure

Compile o código fonte do honeyd:

#> make
 62

Instale os binários:

#> make install

Saia do diretório atual e volte para o ~/downloads

#> cd ..

INSTALAÇÃO DO HONEYCOMB

Baixe os códigos fonte em .tar:

#> wget http://www.icir.org/christian/downloads/honeycomb-

0.7.tar.gz

Extraia o arquivo comprimido .tar:

#> tar -zxvf honeycomb-0.7.tar.gz

Entre no diretório onde foi extraído o arquivo:

#> cd honeycomb-0.7

Rode o script de configuração do Honeycomb, passando por parâmetro o Honeyd e as

bibliotecas Libevent e Libdnet, alem de habilitar o debugging, da seguinte maneira:

#> ./configure --with-honeyd=/usr/local/honeyd/bin/honeyd

--with-libdnet=/usr/local/libdnet/bin –with-
libevent=/usr/local/libevent --enable-debugging
 63

Copiar o diretório dos fonts do Honeyd para ../honeyd:

#> cp -R ../honeyd-1.5c honeyd/

Compile o código fonte do honeyd

#> make

Instale os binários:

#> make install

REINSTALAÇÃO DO HONEYD COM O PLUGIN HONEYCOMB

Entre no diretório onde foi extraído o arquivo:

#> cd honeyd

Rode o script de configuração do Honeycomb, passando por parâmetro o local de

instalação do Honeyd, as bibliotecas Libevent e Libdnet, o Python e o plugin Honeycomb, da
seguinte maneira:

#> ./configure --prefix=/usr/local/honeyd --with-

libevent=/usr/local/libevent --with-libdnet=/usr/local/libdnet
--with-python --with-plugins=honeycomb

Remove arquivos deixados pela instalação anterior do Honeyd:

 64

#> make clean

Compile o código fonte do honeyd:

#> make

Instale os binários:

#> make install

Criar link’s simbólicos do Honeycomb e da biblioteca Libtree:

#> ln -s /usr/local/lib/libhoneycomb.so /usr/lib/libhoneycomb.so

#> ln -s /usr/local/lib/libstree.so.0 /usr/lib/libstree.so.0

 65

EXEMPLO DE SCRIPT DE CONFIGURAÇÃO DOS TEMPLATES

### Template Padrão
create default
# Seta configurações para o template Padrão
set default personality "Microsoft Windows 98SE"
set default default tcp action reset
set default default udp action reset
set default default icmp action open
# Adiciona serviços específicos
add default tcp port 139 open
add default tcp port 137 open
add default udp port 137 open
add default udp port 135 open
### Cria o template Windows 200
create win2k
bind 192.168.0.1 win2k
set win2k personality "Microsoft Windows 2000 Server SP3"
set win2k default tcp action reset
set win2k default udp action reset
set win2k default icmp action block

add win2k tcp port 21 "sh scripts/win32/win2k/msftp.sh $ipsrc $sport $ipdst

$dport"
add win2k tcp port 25 "sh scripts/win32/win2k/exchange-smtp.sh $ipsrc
$sport $ipdst $dport"
add win2k tcp port 80 "sh scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst
$dport"
add win2k tcp port 110 "sh scripts/win32/win2k/exchange-pop3.sh $ipsrc
$sport $ipdst $dport"
add win2k tcp port 143 "sh scripts/win32/win2k/exchange-imap.sh $ipsrc
$sport $ipdst $dport"
add win2k tcp port 389 "sh scripts/win32/win2k/ldap.sh $ipsrc $sport $ipdst
$dport"
add win2k tcp port 5901 "sh scripts/win32/win2k/vnc.sh $ipsrc $sport $ipdst
$dport"
add win2k udp port 161 "perl scripts/unix/general/snmp/fake-snmp.pl public
private --config=scripts/unix/general"

# Adiciona serviços específicos

add win2k udp port 137 proxy $ipsrc:137
add win2k udp port 138 proxy $ipsrc:138
add win2k udp port 445 proxy $ipsrc:445
add win2k tcp port 137 proxy $ipsrc:137
add win2k tcp port 138 proxy $ipsrc:138
add win2k tcp port 139 proxy $ipsrc:139
add win2k tcp port 445 proxy $ipsrc:445