FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
ALEXANDRE WILLIAM BATISTA DA SILVA
PAULO HENRIQUE DE MORAIS SILVA
ESTUDO ANALÍTICO E COMPARATIVO DE HONEYPOTS
SÃO JOSÉ DOS CAMPOS
2010
ii
ALEXANDRE WILLIAM BATISTA DA SILVA
PAULO HENRIQUE DE MORAIS SILVA
ESTUDO ANALÍTICO E COMPARATIVO DE HONEYPOTS
Trabalho
de
graduação
apresentado
à
Faculdade de Tecnologia de São José dos
Campos, como parte dos requisitos necessários
para obtenção de título de Tecnólogo em
Redes de Computadores.
Orientador:
Me Murilo da Silva Dantas
SÃO JOSÉ DOS CAMPOS
2010
iii
ALEXANDRE WILLIAM BATISTA DA SILVA
PAULO HENRIQUE DE MORAIS SILVA
ESTUDO ANALÍTICO E COMPARATIVO DE HONEYPOTS
Trabalho
de
graduação
apresentado
à
Faculdade de Tecnologia de São José dos
Campos, como parte dos requisitos necessários
para obtenção de título de Tecnólogo em
Redes de Computadores.
Orientador:
Me Murilo da Silva Dantas
________________________________
ME. ANTONIO WELLINGTON SALES RIOS
________________________________
DR. JOSÉ CARLOS LOMBARDI
________________________________
ME. MURILO DA SILVA DANTAS
__/__/__
DATA DE APROVAÇÃO
iv
AGRADECIMENTOS
Agradeço a Deus acima de tudo, por me dar forças nos momentos difíceis, a Fabiana, minha
noiva, que me apoia em tudo que faço e me orienta pelo melhor caminho. Aos meus
familiares e ao Paulo que se tornou um grande amigo e pude aprender muito neste último ano
no desenvolvimento deste trabalho.
Alexandre William Batista da Silva
v
AGRADECIMENTOS
Agradeço primeiramente a Deus que ao longo de todos esses anos, ajudou-me nos momentos
mais difíceis. A minha mãe, Dona Vera, que mesmo cansada, sempre esteve ao meu lado e ao
meu pai que sempre me apoiou e não hesitou ao dizer sim aos meus pedidos. E ao
companheirismo do meu colega Alexandre, que foi fundamental para o desenvolvimento
deste trabalho.
Agradeço ainda, aos professores Lombardi e Sabha, que nos ajudaram no desenvolvimento
deste trabalho e na implementação dos trabalhosos honeypots.
Paulo Henrique de Morais Silva
vi
A diferença entre a vida e a morte, é aquilo que você faz nesse intervalo.
(Alexandre, Paulo)
vii
RESUMO
Com o passar dos anos a preocupação com os dados digitais e a sua segurança cresce em larga
escala. Sendo assim, as ferramentas de proteção ou contenção de ataques têm conquistado o
interesse dos administradores de rede e chefes dos diversos setores de informática. Neste
aspecto concentra-se o uso da tecnologia honeypot que pode atuar como complemento de
segurança e monitoração dos acessos a rede e servidores. Esta tecnologia pode atuar de duas
formas: como pesquisa ou como produção. A primeira refere-se à honeypots ligados fora da
rede institucional, para pesquisa de comportamento e ataques na rede mundial de
computadores. Já o segundo como atuante nas defesas no meio institucional, buscando uma
análise dos possíveis ataques, uma vez que o invasor pode estar no próprio meio institucional.
Palavras-Chave: Segurança, honeypots, IDS, firewall, ataques, invasor, hacker, cracker.
viii
ABSTRACT
Over the years the concern with the safety and digital data grows on a large scale. Thus the
sum of tools and protective containment of attacks has got the interest of network
administrators and heads of various sectors of information technology. In this aspect focus on
the use of honeypot technology arise and can act as additional security and monitoring to who
has access to the network and servers. This technology can act in two ways: in a research or
production aspects. The first relates to honeypots connected outside the institutional network
for research on behavior and attacks on the World Wide Web. The second acts on defenses for
the institutional environment, looking for a review of possible attacks since the attacker could
be on inside the institutions.
Keywords: security, honeypots, IDS, firewall, attack, attacker, hacker, cracker.
ix
LISTA DE FIGURA
Figura 1 - Estrutura de uma Honeynet .................................................................................. 19
Figura 2 - Estrutura do Backbone Brasileiro Fonte: (RNP, 2004) ......................................... 25
Figura 3 - Distribuição de Honeypots no Brasil (CERT, 2010) ............................................. 36
Figura 4 - N-Stealth em sua versão gratuita 3.7 .................................................................... 45
Figura 5 – LeechFTP............................................................................................................ 46
Figura 6 – PuTTy ................................................................................................................. 46
Figura 7 - Esquema de rede nos testes realizados.................................................................. 53
Figura 8 - Opções de configuração do Valhala ..................................................................... 54
Figura 9 - Configuração do Servidor WEB........................................................................... 55
Figura 10 - Tela de configuração TELNET .......................................................................... 56
Figura 11 - Ambiente de testes Valhala ................................................................................ 57
Figura 12 - Configuração do servidor de FTP ....................................................................... 57
Figura 13 - Ambiente de testes do servidor FTP ................................................................... 58
Figura 14 - Testes de acesso com o LeechFTP ..................................................................... 58
Figura 15 - Configuração do serviço POP3........................................................................... 59
Figura 16 - Teste de acesso via POP3 ................................................................................... 59
Figura 17 - Acesso via prompt do servidor WEB.................................................................. 60
Figura 18 - Testes do servidor WEB Valhala........................................................................ 60
Figura 19 - Configuração do servidor SMTP ........................................................................ 61
Figura 20 - Acesso ao servidor SMTP .................................................................................. 61
Figura 21 - Tentativo de acesso indevido via TELNET ........................................................ 63
Figura 22 - Monitoramento e captura de acessos via TELNET BackOfficer ......................... 64
Figura 23 - Tentativa de acesso IMAP2................................................................................ 64
Figura 24 - Tentativa de acesso POP3 .................................................................................. 65
x
Figura 25 - Tentativa de conexão SMTP .............................................................................. 65
Figura 26 - Escaneamento do servidor WEB com N-Stealth ................................................. 66
Figura 27 - Relatório N-Stealth ............................................................................................ 67
Figura 28 - Acesso ao servidor WEB via browser ................................................................ 67
Figura 29 - Tentativa de acesso via FTP ............................................................................... 68
Figura 30 - Erros no LaBrea ................................................................................................. 69
Figura 31 - Erro ao instalar o LaBrea ................................................................................... 70
Figura 32 - Erro LaBrea ....................................................................................................... 71
Figura 33 - Erro ao executar o LaBrea no Windows Server 2003 .......................................... 71
Figura 34 - Tentativa de Conexão com o Deception Toolkit ................................................. 74
Figura 35 - Erro ao executar o WinHoneyd .......................................................................... 75
Figura 36 - Erro ao executar o WinHoneyd .......................................................................... 75
Figura 37 - Erro ao iniciar o WinHoneyd 1.5........................................................................ 75
Figura 38 - WinHoneyd em execução................................................................................... 76
Figura 39 - Execução do Honeyd no Debian ........................................................................ 77
Figura 40 - Erro ao iniciar o Tiny honeypot .......................................................................... 79
xi
LISTA DE TABELAS
Tabela 1 - Descrição dos Honeynets existentes no Brasil ...................................................... 36
Tabela 2 - Tabela Comparativa entre honeypots de baixa e alta interatividade ...................... 39
Tabela 3 - Pontuação do Honeypot ....................................................................................... 50
Tabela 4 - Tabela de Avaliação de Software ......................................................................... 51
Tabela 5 - Cenário 01 de testes ............................................................................................. 52
Tabela 6 - Cenário 02 de testes ............................................................................................. 53
Tabela 7 - Tabela de pontuação final .................................................................................... 82
xii
LISTA DE ABREVIATURAS E SIGLAS
APT
Advanced Packaging Tool
ASCII
American Standard Code for Information Interchange
DDR2
Double Data Rating
DNS
Domain Name Service
FBI
Federal Bureau of Investigation
FTP
File Transfer Protocol
GB
Gigabyte
GNU
GNU is Not Unix
GPL
General Public License
HD
Hard Disk
HTML
HyperText Markup Language
HTTP
HiperText Transfer Protocol
IDS
Instrusion Detection Service
IIS
Internet Information Services
IMAP2
Internet Message Access Protocol
INPE
Instituto Nacional de Presquisas Espaciais
IP
Internet Protocol
MAC
Media Access Control
MB
Megabyte
MCT
Ministério da Ciência e Tecnologia
PATRIOT
Provide Appropriate Tool Required to Intercept and Obstruct
PF
Packet Filter
POP3
Post Office Protocol
RNP
Rede Nacional de Pesquisa
SAIC
Science Application International Corporation
SMTP
Simple Mail Text Protocol
SO
Sistema Operacional
SPI
Serviço de Perícia em Informática
SSH
Secure Shell
TCP
Transmission Control Protocol
TFTP
Trivial File Transfer Protocol
UDP
User Datagram Protocol
xiii
URL
Uniform Resource Locator
XML
eXtensible Markup Language
WISE
Wireless Information Security Experiment
xiv
SUMÁRIO
1.
INTRODUÇÃO........................................................................................................... 18
1.1.
Motivação .............................................................................................................. 18
1.2.
Objetivos ............................................................................................................... 21
1.2.1.
Objetivo Geral ....................................................................................................... 21
1.2.2.
Objetivos Específicos............................................................................................. 21
1.3.
Metodologia........................................................................................................... 21
1.4.
Organização do Trabalho ....................................................................................... 21
2.
FUNDAMENTAÇÃO TEÓRICA .............................................................................. 23
2.1.
Rede de Computadores .......................................................................................... 23
2.2.
Definição de Inimigos ............................................................................................ 25
2.3.
Fundamentação Jurídica ......................................................................................... 27
2.4.
Introdução à Computação Forense ......................................................................... 29
2.5.
Honeypots .............................................................................................................. 29
2.5.1.
Definição ............................................................................................................... 29
2.5.2.
Tipos ..................................................................................................................... 30
a
Honeypots de Baixa Interatividade ......................................................................... 30
b
Honeypots de Alta Interatividade ........................................................................... 30
2.5.3.
Funcionamento ...................................................................................................... 31
a
Honeypots de Baixa Interatividade ......................................................................... 31
b
Honeypots de Alta Interatividade ........................................................................... 31
2.6.
Honeynets .............................................................................................................. 31
2.6.1.
Definição ............................................................................................................... 31
2.6.2.
Tipos ..................................................................................................................... 31
a
Honeynet Virtual.................................................................................................... 32
b
Honeynet Real........................................................................................................ 32
xv
2.6.3.
Funcionamento ...................................................................................................... 32
a
Virtual ................................................................................................................... 32
b
Real ....................................................................................................................... 32
2.7.
Principais Projetos .................................................... Erro! Indicador não definido.
2.7.1.
Honeynet Project .................................................................................................... 33
2.7.2.
Wireless Honeynet Project ..................................................................................... 33
2.7.3.
Honeynet.BR ......................................................................................................... 34
2.7.4.
Project Honey Pot .................................................................................................. 35
2.7.5.
Brazilian Honeypots Alliance ................................................................................. 36
2.8.
Honeypots, Honeynets e a Segurança da Rede ........................................................ 37
2.9.
Vantagens .............................................................................................................. 39
2.10.
Desvantagens ......................................................................................................... 40
3.
FERRAMENTAS UTILIZADAS ............................................................................... 40
3.1.
Ferramenta de Virtualização .................................................................................. 41
3.2.
Sistemas Operacionais ........................................................................................... 42
3.2.1.
Microsoft Windows ................................................................................................ 42
a
Microsoft Windows XP .......................................................................................... 43
b
Microsoft Windows 7. ............................................................................................ 43
c
Microsoft Windows Server 2003............................................................................. 43
3.2.2.
Linux ..................................................................................................................... 43
a
Ubuntu ................................................................................................................... 44
b
Debian ................................................................................................................... 44
3.3.
Ferramentas de Ataque........................................................................................... 44
3.3.1.
N-Stealth ............................................................................................................... 45
3.3.2.
LeechFTP .............................................................................................................. 45
3.3.3.
PuTTy.................................................................................................................... 46
4.
MÉTODOS E CRITÉRIOS........................................................................................ 47
xvi
4.1.
Definições de critérios ........................................................................................... 47
4.2.
Tabela de pontuação .............................................................................................. 50
4.3.
Cenários de avaliação ............................................................................................ 51
4.3.1.
Cenário 01. ............................................................................................................ 52
4.3.2.
Cenário 02. ............................................................................................................ 52
4.4.
Discriminação de rede............................................................................................ 53
5.
RESULTADOS ........................................................................................................... 54
5.1.
Valhala Honeypot .................................................................................................. 54
5.1.1.
Configurações ........................................................................................................ 54
5.1.2.
Testes .................................................................................................................... 55
5.1.3.
Log ........................................................................................................................ 61
5.2.
BackOfficer Friendly ............................................................................................. 62
5.2.1.
Configurações ........................................................................................................ 62
5.2.2.
Testes .................................................................................................................... 63
5.2.3.
Log ........................................................................................................................ 68
5.3.
LaBrea Tarpit......................................................................................................... 69
5.3.1.
Configurações ........................................................................................................ 69
5.3.2.
Testes .................................................................................................................... 71
5.3.3.
Log ........................................................................................................................ 72
5.4.
Deception Toolkit .................................................................................................. 72
5.4.1.
Configurações ........................................................................................................ 72
5.4.2.
Testes .................................................................................................................... 73
5.4.3.
Log ........................................................................................................................ 74
5.5.
Honeyd .................................................................................................................. 74
5.5.1.
Configurações ........................................................................................................ 74
5.5.2.
Testes .................................................................................................................... 77
5.5.3.
Log ........................................................................................................................ 77
xvii
5.6.
Tiny Honeypot ....................................................................................................... 78
5.6.1.
Configurações ........................................................................................................ 78
5.6.2.
Testes .................................................................................................................... 79
5.6.3.
Log ........................................................................................................................ 79
6.
CONSIDERAÇÕES FINAIS ...................................................................................... 80
6.1.
Honeypots Windows ............................................................................................... 80
6.2.
Honeypots Linux .................................................................................................... 81
6.3.
Tabela de Resultados ............................................................................................. 82
6.4.
Contribuições......................................................................................................... 83
6.4.1.
Publicação ............................................................................................................. 83
6.5.
Trabalhos Futuros .................................................................................................. 83
7.
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 85
ANEXO A .......................................................................................................................... 89
ANEXO B ........................................................................................................................... 91
18
1.
INTRODUÇÃO
1.1. Motivação
A informação cada vez mais agrega grande valor, tanto para as corporações, quanto para
governos e pessoas. Assim sendo, os locais de armazenamento tem-se multiplicado cada vez
mais ao passar dos anos, tornando a preocupação com sua integridade e segurança uma
prioridade e necessidade. Muitas instituições acreditam que o seu setor de informática é um
dos mais caros. Porém se bem estruturado torna-se o mais fundamental dos departamentos.
Caso exista uma estruturação má formulada, a instituição encontra-se vulnerável à ação de
criminosos cibernéticos.
No contexto do ataque encontra-se o Cracker, que pode ser definido como aquele que pratica
a quebra de um sistema de segurança de forma ilegal ou sem ética. A mídia costuma atribuir
equivocadamente tal ação aos Hackers. Porém, este termo refere-se a um mestre em domínio
do computador, que usa seu conhecimento para o bem e para meios lícitos. Segundo
(VIANNA , 2003), um Cracker pode ser definido como um “Hacker do mal”.
Segundo ELLERO e CASIAN (2001), o firewall é uma ferramenta capaz de definir o que é
seguro para acesso e o que pode ser nocivo ao sistema. Responsável ainda pelo controle de
portas abertas para redes distintas. Este inclui dispositivos que realizam a filtragem de pacotes
e de Proxy1 de aplicativos.
Além do firewall, pode-se destacar o Intrusion Detection System (IDS), que, de acordo com
LAUREANO, et al (2003), basicamente é utilizado para detectar possíveis tentativas de
invasões por Crakers, ou até mesmo funcionários da própria instituição mal-intencionados,
detectando possíveis ações nocivas ou de obtenção de dados sigilosos. Este sistema ainda é
capaz de gerar uma resposta automática de acordo com a programação previamente realizada.
Muitas vezes com a união de todos os recursos de proteção funcionando corretamente, a
instituição ainda está suscetível a ataques que geram prejuízos e perda de dados importantes.
1
Proxy: servidor que atende requisições de um cliente, repassando a informação para frente. Quando recebe a
resposta devolve ao cliente.
19
Com o intuito de criar uma camada robusta de segurança numa rede, foi desenvolvido o
conceito de Honeypot (em português, “Pote de Mel”) que se trata de uma máquina na rede que
terá o tráfego nocivo direcionado para ela, ou seja, é uma máquina para receber os ataques.
Esta pode ser uma máquina virtual, ou até mesmo real, que possua configurações idênticas ou
próximas das máquinas da instituição. Todas as ações dentro dessa máquina serão gravadas
em logs para análise e estudo posterior do comportamento do invasor.
Uma vez que a ameaça pode estar dentro da empresa, representada por um funcionário
curioso, os cuidados também podem ser aplicados e assim até descobrir a origem do ataque,
podendo incrementar formas de proteção.
Quando se unem vários Honeypots tem-se uma Honeynet, que nada mais é do que vários
Honeypots interligados por uma interface de rede virtual ou real. Aproximando-se cada vez
mais da realidade da instituição, uma Honeynet passa a sensação para o invasor de que
realmente está dentro da rede e consegue ver várias máquinas com serviços como Telnet, FTP
entre outros. Esses serviços são disponibilizados de acordo com a aplicação que está em
operação de Honeypot. A estrutura de uma Honeynet está esboçada na Figura 1.
Figura 1 - Estrutura de uma Honeynet
20
Como pode ser observado na Figura 1, a honeynet pode ser composta por máquinas reais ou
máquinas virtuais representadas à direita da imagem. Neste exemplo, temos uma máquina
com o sistema IDS e firewall que é responsável por separar o tráfego advindo do roteador
direcionando o que irá para os honeypots ou para a rede da instituição.
Caso tal aplicação esteja sendo executada corretamente ela beneficia o utilizador no âmbito de
segurança, pois deste modo é possível conhecer o inimigo, suas táticas de ataques, a sua
pretensão, e os caminhos e recursos que pretende usar. Além disso, qualquer alteração ou
dano que vier a ser causado não acarretará perda, pois se trata de um sistema pronto para
receber ataques e sua configuração não passa de uma simulação.
Tal configuração também pode ser realizada de modo que haja um sistema de reposição de
arquivos, para que mesmo que existam avarias, estas sejam corrigidas em instantes. Com uma
honeynet instalada as funcionalidades de segurança terão uma significativa ampliação.
Desta forma confina-se o invasor a uma rede onde sua atividade será monitorada,
direcionando qualquer atividade maliciosa ou indevida da rede para a honeynet. As
informações obtidas a partir da monitoração são valiosas, e podem ser utilizadas para diversos
fins de acordo com a motivação que levou o sistema a ser instalado.
Segundo a IPNews (IPNEWS, 2010) de 75% a 90% dos ataques são direcionados para
aplicações web e que as empresas não têm consciência da necessidade de proteger esses
ativos. Em questões do ataque, o honeypot encontra-se como meio de driblar essa ameaça
uma vez que este terá a função de receber os ataques e monitorá-los, protegendo assim a rede
real e seus dados.
Durante o decorrer deste trabalho o objetivo será estabelecer um comparativo sobre as
ferramentas Honeypots existentes, demonstrando eficiência e possibilidades oferecidas por
cada sistema. Sendo assim oferecer aos possíveis usuários o suporte para uma fácil escolha
que atenda as necessidades reais do sistema a ser implantando.
21
1.2. Objetivos
Os objetos deste trabalho serão apresentados nas subseções a seguir.
1.2.1.
Objetivo Geral
O objetivo deste trabalho é analisar ferramentas utilizadas para o sistema de honeypots,
determinando critérios de comparação, indicando para possíveis utilizadores deste recurso um
estudo comparativo de forma que sua escolha seja pautada de acordo com a necessidade da
rede a ser implementada.
1.2.2.

Objetivos Específicos
Analisar as ferramentas livres disponíveis para implementação de honeypots e
honeynets;

Estabelecer critérios de análise de invasão através de honeypots e honeynets; e

Classificar as funcionalidades das ferramentas selecionadas segundo critérios prédefinidos.
1.3. Metodologia
Será realizado um estudo analítico sobre várias ferramentas, que visam à segurança seguindo
o conceito do Honeypot, buscando obter o recurso mais adequado para cada caso. Para tanto
serão realizados testes das mesmas abordadas neste trabalho. Os critérios usados
primordialmente serão de plataforma operante, facilidade de uso, facilidade de configuração e
utilização, confiabilidade na monitoração, eficiência do log gerado, opções de envio de log,
rastreamento do invasor, invisibilidade ao atacante e por fim a realidade do Honeypot. Assim,
é possível estabelecer uma relação entre as ferramentas e os diversos tipos e metodologias de
invasão.
1.4. Organização do Trabalho
O restante deste trabalho encontra-se organizado da seguinte maneira:
22
a) Capítulo 2 – Fundamentação Teórica: neste capítulo será abordado o histórico do
conceito de Honeypots e Honeynets bem como seus principais projetos existentes até a
presente data e suas aplicações;
b) Capítulo 3 – Ferramentas Utilizadas: neste capítulo serão descritas as ferramentas
utilizadas neste trabalho;
c) Capítulo 4 – Materiais e Métodos: aqui serão tratados os critérios para avaliação
comparativa, os cenários a serem implementados e a análise das ferramentas
escolhidas;
d) Capitulo 5 – Resultados: descreve o desempenho das ferramentas testadas;
e) Capítulo 6 – Conclusão: demonstra quais ferramentas são mais eficientes para casos
específicos de invasão.
23
2.
FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta o embasamento teórico do projeto. Aqui serão abordados fundamentos
sobre rede de computadores (Seção 2.1) e também são apresentados os principais tipos de
inimigos e quais as suas motivações (Seção 2.2). Além disso, são explanados os fundamentos
jurídicos que sustentam a proteção aos dados e justifica a defesa contra ataques maliciosos
(Seção 2.3). São tratados os conceitos sobre computação forense (Seção 2.4) e também as
definições de Honeypots (Seção 2.5), Honeynets (Seção 2.6), apresentando os tipos e projetos
existentes (Seção 2.7), e analisando as vantagens e desvantagens da utilização de tais sistemas
(Seção 2.8).
2.1. Rede de Computadores
Durante do século XX o avanço tecnológico foi o grande marco na evolução da sociedade.
Tal crescimento pode ser notado principalmente nas comunicações, um exemplo é a rede de
telefonia que se expandiu por todo o mundo, ou até mesmo invenções como o rádio e a
televisão que revolucionara o modo de transmissão de informações. Além disso, foi registrado
o nascimento e crescimento sem precedentes da indústria de informática (TANENBAUM,
2003).
Com o surgimento da informática a capacidade de coletar, estudar e transmitir informações
teve seu crescimento como nunca tinha sido imaginado antes. Porém nas duas primeiras
décadas do surgimento dos primeiros computadores as informações eram centralizadas e suas
instalações ficavam em salas dedicadas a estes primeiros computadores com paredes de vidro,
que permitiam a visitação e observação desta “maravilha tecnológica”.
As empresas de médio porte ou universidades que possuíam estas máquinas, tinham em seu
poder um ou dois exemplares, já as empresas de grande porte não passavam de algumas
dezenas. Diferentemente da expansão que se atingiu 20 anos depois, na qual é possível
encontrar sistemas computacionais dentro de dispositivos do tamanho de um selo postal.
O encontro entre os computadores e a informação pode ser responsabilizado para a forma que
se organizou os sistemas computacionais. Com o tempo, o velho modelo de computador
centralizado atendendo todas as requisições e realizando as tarefas necessárias, tornou-se
24
obsoleto ao mesmo tempo em que o nível do avanço tecnológico aumentava. Surgia a
necessidade da interconexão entre as máquinas, dando origem a “rede de computadores”.
Nasceu então o que se entende por necessidade básica de uma instituição na primeira década
do século XXI. O termo pode ser definido como trabalhos realizados por estações separadas,
porém interconectados (TANENBAUM, 2003). A conexão não precisa ser necessariamente
com cabos de cobre, esta também podem ser empregada com fibras ópticas ondas de rádio,
microondas, ondas de infravermelho ou ainda satélites de comunicação.
A internet ou a World Wide Web não é propriamente uma rede de computadores, mas sim uma
união de redes espalhadas por todo o mundo. Diferentemente, um sistema distribuído é um
conjunto de computadores independentes, que transmite ao usuário a impressão de um sistema
único. Em teoria estaria um software sobre o sistema operacional responsável pela
transparência do sistema.
Diferentemente dos sistemas distribuídos em redes de computadores os serviços são
concentrados em servidores, ou seja, os clientes terão que buscar esse serviço neste servidor e
realizar a autenticação. Sendo assim os serviços são executados nesta máquina provedora de
serviços. Além disso, caso haja dispositivos com hardware diferente, isto poderá ser
observado pelos utilizadores da rede em questão.
Com o passar dos anos, as redes foram se tornando itens de necessidades básicas das
instituições, principalmente quando existe a necessidade de compartilhamento de dados e
recursos, como impressoras, internet ou até mesmo espaço em disco. As necessidades foram
estendidas também para uso doméstico com o mesmo intuito das organizações comerciais.
Porém com o crescimento em escala acelerada do número de pequenas e médias redes, o
investimento em segurança nem sempre pode acompanhar ou foi classificado pelo
proprietário da rede como prioridade.
Os modelos de arquitetura de rede dividem-se em cliente/servidor e peer-to-peer. O primeiro é
baseado no conceito em que um computador central é responsável por armazenar dados,
concentrar programas e serviços. Já o segundo modelo, é o modelo de não existe
propriamente um servidor e o compartilhamento é dividido entre os usuários, cada um sendo
cliente e servidor ao mesmo tempo.
25
O primeiro Backbone (espinha dorsal, em português) foi construído nos Estados Unidos da
América. Este era dividido em pontos distribuídos e dispersos abaixo da terra, para no caso de
um ataque ou qualquer comprometimento que pudesse vir a acontecer em algum ponto, os
demais continuassem funcionando, já que nenhum em específico é o servidor.
No Brasil o primeiro Backbone foi instalado em meados de 1991 com a Rede Nacional de
Pesquisa (RNP) que era subordinado ao Ministério de Ciência e Tecnologia (MCT). Até hoje
o RNP é o Backbone principal do Brasil e interliga centros de pesquisas, universidades,
instituições do governo, centros culturais entre outras. A seguir, o mapa da distribuição no
Brasil.
Figura 2 - Estrutura do Backbone Brasileiro Fonte: (RNP, 2004)
2.2. Definição de Inimigos
26
Para conhecer o inimigo pode-se analisar sua atuação no mundo virtual. Estes são pessoas que
dominam a informática e a usam para o aproveitamento de vulnerabilidades de algum sistema,
a fim de prejudicar ou obter dados de terceiros. Entre os praticantes de tal ato encontra-se a
formação de grupos e classificação de acordo com o nível de experiência dos integrantes
(ULBRICH , 2009).

Newbie: novato, iniciante ou calouro. Possui pouco conhecimento em informática,
mas busca evoluir sempre.

Luser: derivada da união de duas palavras inglesas user (usuário) e loser (perdedor),
ao contrario do Newbie, este está acomodado e não quer saber nada mais do que o
necessário para a utilização do computador.

Lammer: está no mesmo patamar que os dois anteriores, consegue manipular os
softwares contidos no computador. Mas ao encontrar um programa que invade algum
site ou computador, aprende a utilizar o básico, mas esse tipo de intruso se limita a três
programas: scan, exploit e trojan.

Wannabee: algum indivíduo que quer entrar no mundo de invasão, mas não tem noção
de como é esse meio.

Hacker: a princípio, esse termo era utilizado para definir os carpinteiros que faziam
móveis com machados. Já entre os anos 40 e 50, esse termo era usado para definir
radioamadores e pessoas que tem a eletrônica e a mecânica como hobby. Já nos anos
60, o termo chegou para caracterizar os programadores e especialistas em
computadores. Atualmente, o termo que erroneamente foi caracterizado pela imprensa
em geral para criminosos digitais, é na verdade especialistas em invasão, possuem um
conhecimento aprofundado sobre o sistema operacional e são ótimos programadores.
A especialidade em invasão é utilizada para o bem, ou seja, o Hacker invade o site
sim, mas mostra para o administrador onde está a falha, e mostra como corrigi-la.

Cracker: conhecido também como “Hacker sem ética”. Este pratica o vandalismo
virtual, rouba senhas de usuário para usufruir posteriormente, quebra travas de
softwares comerciais para pirateá-lo e também são excelentes programadores e
27
conseguem fazer tudo que foi citado acima e sem deixar vestígios. A diferença deste
para o Lammer é a persistência, o Cracker utiliza-se de vários programas para
descobrir as vulnerabilidades do alvo. Outra diferença é que o Lammer age sem
nenhum planejamento prévio já o Cracker sabe o porquê invadirá, e caso haja algum
imprevisto conseguirá solucionar o problema.

War Driver: é o tipo mais recente de Cracker, tira proveito das vulnerabilidades que a
rede sem fio propicia.

Carder: especialista em fraude de cartão de crédito. Sabe como conseguir números
validos de cartão e consegue gerar números falsos que passam pela verificação de sites
de compra. E ainda clonam cartões reais para utilização indevida.
2.3. Fundamentação Jurídica
Com o grande tráfego de informação na rede, esta necessita de proteção e tal ação deve
apoiar-se juridicamente na constituição. Com a expansão da rede mundial de computadores
cresceu também o risco nas transferências de dados. Ao utilizar um computador ligado à rede
o usuário corre o risco de ter os dados da sua máquina acessados de maneira ilícita. Com
tantos dados sendo transferidos que possuem valores significativos ou até importância
financeira, como senhas e dados bancários. Existem pessoas que buscam obter tais
informações para uso indevido. Estes são conhecidos como Crackers que utilizam tais
informações para o bem próprio.
A partir do momento em que o usuário se sente lesado e não conhece a fonte e caso decida
procurar na polícia comum à solução do dano sofrido, poderá recorrer ao Instituto Nacional de
Criminalística. Criado em 1974, este é responsável por pesquisas específicas de crimes que
para sua resolução necessitam de equipe técnica para análise e entendimento. Para isso conta
com equipe de profissionais com diploma de nível superior de Química, Física, Engenharia,
Ciências Contábeis, Econômicas, Biológicas, Geologia, Farmácia, Bioquímica e Computação
Científica ou Análise de Sistemas.
Além de formação específica por área e nas respectivas especialidades, são selecionados por
concurso público, mediante nomeação, desde 1974, cujo período de trabalho é integral com
dedicação exclusiva às atividades do cargo. O Serviço de Perícia em Informática (SPI) é o
28
departamento encarregado das investigações referentes à área de crimes na internet, também
conhecidos como Cyber Crimes.
A justiça não tinha base para julgar um crime desse tipo, então não é possível condenar
alguém que cometeu um crime na internet. Assim sendo também não é possível identificar o
autor do crime. Questões como essas acabaram iniciando a criação de leis que buscam
identificar e condenar pessoas que cometem crime na rede. Os Crackers não se intimidam
com as leis existentes, porque os casos solucionados que se relacionam com informática são
relativos à pedofilia e pirataria.
Segundo ULBRICH (2009), a justiça brasileira tem um grave problema quanto à aprovação
de novos projetos de lei que é a falta de conhecimento por parte dos parlamentares que são os
responsáveis por aprovar tais projetos. Outro grave problema são as leis que estão em vigor
no momento que na maioria dos casos solucionados são de pedofilia e pirataria. Quanto à
invasão e “hackeamento” não há nada em específico em vigor.
Após os atentados de 11 de setembro, os Estados Unidos começaram a tratar a segurança
digital como um método de segurança nacional. Mas o início desse novo método de tratar as
informações trafegadas na rede se deu no dia do atentado, com o FBI (Federal Bureau of
Investigation) intimando os provedores a instalar softwares que filtram mensagens de emails e
buscam por algum texto contido, por exemplo, algo relacionado a atentado. A partir desse dia
muita coisa mudou com relação à segurança da rede no âmbito internacional.
Uma das leis criadas foi a USA Act que condena todo e qualquer tipo de vandalismo
eletrônico a pessoa física ou jurídica. A partir das novas leis criadas, os Hackers e Crackers
são considerados terroristas. Segundo a PATRIOT (Provide Appropriate Tools Required to
Intercept and Obstruct Terrorism Act), “aquele que, com conhecimento, cause transmissão de
um programa, informação, código ou comando e, como resultado de tal conduta,
intencionalmente cause dano sem autorização para um computador protegido estará em
violação deste estatuto”.
Na Europa, foi adotada uma conduta semelhante à dos Estados Unidos, onde as agências de
segurança têm o poder de vasculhar as caixas de mensagens sem qualquer aviso prévio ou
pedido de autorização do usuário.
29
Portanto, é possível perceber que o mundo está evoluindo no modo que conduz a segurança
no meio digital. Porém para uma evolução mais rápida será necessário também ultrapassar
algumas barreiras como a privacidade.
2.4. Introdução à Computação Forense
O termo de análise forense iniciou-se a partir de processos judiciais, quando necessita de uma
busca minuciosa de provas, e essa busca une vários tipos de provas, buscando o autor de
crime.
O objetivo geral da computação forense é encontrar e retirar dados de dispositivos, como
computadores, discos magnéticos, mídias de disco ou unidades flash, a fim de utilizar os
dados encontrados que são classificados como evidência diante do fato ocorrido, e
posteriormente assumirão o posto de provas legais diante do ocorrido.
A computação forense pode ser definida como a união e análise de dados de um computador,
ou sistema, ou rede, ou dispositivos de armazenamento de forma que os classifique como
admissíveis em juízo. Tais dados não são obtidos facilmente, e muito menos a olho nu. Por
isso cabe ao perito a análise completa dos dados buscando as evidências.
2.5. Honeypots
Nas subseções a seguir serão apresentados as definições, os tipos e o funcionamento do
Honeypot.
2.5.1.
Definição
Para compreender o que é realmente um Honeypot de acordo com SPITZNER (2003),
enxergue-o como um sistema flexível e que não se aplica para a resolução de problemas
específicos, assim como é a tarefa de um Firewall ou um IDS. A amplitude de suas
funcionalidades vem desde a detecção e o monitoramento de um ataque até o
acompanhamento das atividades das diversas portas de um host. Nisto é que consiste o seu
30
grande poder computacional, com sua grande flexibilidade, pode ser aplicado para fins
distintos.
Para tanto, o objetivo de um honeypot é que ele seja realmente atacado, ou até mesmo
comprometido, uma vez que este está sendo monitorado e as informações obtidas possuem
grande valor, sendo importante para a criação de defesas ou até mesmo o desenvolvimento de
métodos de contra-ataque.
Os honeypots podem atuar de duas formas, como honeypot de pesquisa e ou de produção. O
primeiro é destinado para coletar informações sobre invasores e ferramentas utilizadas pelos
mesmos. Em geral são implementados em redes externas ou não interligados com a rede
principal.
Já o segundo modelo é aplicado em redes internas onde o objetivo é trabalhar como um
elemento de dispersão ou distração para invasores, sendo assim pode diminuir o risco de
ataque a rede principal. Consiste basicamente em direcionar o tráfego para máquinas
preparadas para serem alvos de ataques.
2.5.2.
Tipos
Existem dois tipos de Honeypots, que serão definidos nas subseções a seguir.
a)
Honeypots de Baixa Interatividade
Segundo HOEPERS et al (2007), Honeypots de Baixa Interatividade podem ser tratados como
aqueles que são emulados em serviços virtuais. Ou seja, dentro de máquinas virtuais que
emulam sistemas operacionais e serviços no qual o atacante pode interagir. Em alguns tipos
de Honeypots pode-se até criar arquivos para uma aproximação maior com a realidade. Para
tanto o sistema operacional hospedeiro da máquina virtual deve ser muito bem configurado a
fim de evitar comprometimento. Tem-se como fundamento o número reduzido de dispositivos
físicos.
b)
Honeypots de Alta Interatividade
31
Ainda de acordo com HOEPERS, JESSEN e CHAVES (2007), Honeypots de alta
interatividade são dotados de serviços e máquinas reais. Com isso os atacantes interagem com
sistemas operacionais, aplicações e serviços de cada máquina ligada na rede. Esse sistema é
mais caro devido ao custo computacional, pois existe maior gasto com o hardware utilizado
que em partes torna-se ocioso e com a estruturação física da rede. Porém o invasor encontra
uma simulação muito próxima da realidade da instituição.
2.5.3.
Funcionamento
a)
Honeypots de Baixa Interatividade
Como nesse tipo de Honeypot visa-se um menor consumo de hardware, é utilizada
normalmente uma rede virtualizada, ou seja, está hospedada dentro de uma máquina com um
Sistema Operacional (SO) instalado, que age como base para o que se chama de máquina
virtual. Deste modo podem-se emular diversos SO ao mesmo tempo, simulando arquivos e
documentos. É possível, ainda, monitorar as portas que a aplicação disponibiliza, gerenciando
o tráfego que eventualmente seja malicioso.
b)
Honeypots de Alta Interatividade
Este é uma máquina real projetada especificamente para ser comprometida, ou seja, nesta ao
invés de máquinas virtuais, têm-se um SO real instalado que possui documentos comuns,
simulando máquinas de usuários convencionais com planilhas, textos ou até mesmo fotos.
2.6.
Honeynets
2.6.1.
Definição
Uma Honeynet nada mais é do que a união de vários Honeypots, deste pode-se citar os dois
tipos existentes, as Virtuais e as Reais definidas nas subseções a seguir.
2.6.2.
Tipos
32
a)
Honeynet Virtual
Conjunto de máquinas virtuais rodando sobre uma máquina hospedeira através de um
software de virtualização, capaz de proporcionar ao atacante uma simulação do parque de
máquinas da instituição.
b)
Honeynet Real.
Neste tipo de Honeynet têm-se equipamentos reais que possuem o tráfego que é monitorado e
controlado. A ligação entre os nós é dada através de dispositivos físicos contando com a
interface de rede com Hubs/Switches ou roteadores (se necessário) e várias máquinas reais.
Desta forma cada honeypot é executado em uma estação real. Com esta configuração é
possível criar ambientes mais variados, utilizando-se de diferentes sistemas operacionais e de
disposição da organização dos arquivos.
2.6.3. Funcionamento
a)
Virtual
Em uma rede virtual é possível a divisão em subcategorias: as de Auto-Contenção e as
Híbridas. Na primeira todas as funções que integram a ferramenta, contenção, captura e coleta
de dados, geração de alertas e os Honeypots, estão concentrados em uma única máquina
através de um software de virtualização. Já na segunda, as ferramentas estão separadas dos
Honeypots.
b)
Real
Neste tipo encontra-se também uma máquina com IDS instalado, que atua como gerador de
alertas e coletando dados, em outra máquina tem-se um firewall instalado trabalhando como
contenção e coleta de dados. Além disso, existe uma máquina que ficará responsável pela
reposição de dados que eventualmente sejam destruídos, após algum ataque ao sistema.
2.7. Principais Projetos
33
2.7.1.
Honeynet Project
O Honeynet Project é uma entidade internacional sem fins lucrativos, que foi fundada em
1999. Procura melhorar a segurança na Internet sem custo ao usuário. O projeto possui
membros espalhados pelo mundo, que são voluntários que defendem os ideais do Código
Aberto (Open Source).
Para isso o projeto é sustentado em três atitudes para o cumprimento de tal objetivo. A
primeira é sensibilizar os usuários que as ameaças existem e demonstrar que possíveis
vulnerabilidades podem ser exploradas por Crackers. A segunda é fornecer informações para
melhor proteger e defender o recurso particular do usuário. A terceira e última é fornecer
ferramentas para organizações que queiram continuar sua própria investigação sobre ameaças
virtuais, utilizando-se de técnicas desenvolvidas pela Honeynet Project.
Este projeto reúne muitos projetos na área de Honeypots. É um blog que traz notícias sobre
desenvolvimento de novas ferramentas e simpósios. É um ótimo site para se retirar lições
sobre ferramentas, táticas e ataques de rede, assim como compartilhar lições (HONEYNET,
2009).
2.7.2.
Wireless Honeynet Project
O projeto Wireless Honeynet Project também chamado de HoneySpot teve início no ano de
2002 com Kevin Poulsen, que publicou as primeiras pesquisas de como aplicar um Honeypot
em uma rede Wireless. O principal motivo do início dos estudos deu-se pela extrema falta de
segurança que havia quando a rede wireless cresceu de forma rápida. Com isso as ferramentas
de segurança não acompanharam esse desenvolvimento. Assim sendo, no dia 15 de Junho de
2002 a WISE (Wireless Information Security Experiment) foi iniciada pela SAIC (Science
Applications International Corporation) e o objetivo era corrigir as muitas vulnerabilidades
que o sistema wireless possuía, e possui até hoje.
Ao fim de 2002 foram publicados os primeiros resultados de uma coleta feita em um wireless
honeypot que foi implantado em Ottawa no Canadá. Assim foi provada a fragilidade da rede e
que havia intrusões.
34
No ano de 2004 um artigo mais detalhado foi publicado por Laurent Oudot, um integrante da
Honeypot Project, apresentando todo o conceito sobre Wireless Honeypot, inclusive os
objetivos, as vulnerabilidades e a estrutura necessária para a sua instalação.
Em 2007, um projeto chamado “The Hives” busca como lidar com possíveis ameaças. Por se
tratar de um sistema operado em Linux Live CD, permite ao administrador do sistema a
capacidade de ponto de acesso à rede inteira através de simulações.
Sua estrutura assemelha-se muito com o sistema tradicional para redes cabeadas, porém é uma
rede que oferece sinal e tem seu acesso monitorado. É um sistema preparado para ser
comprometido e sua intenção é que o invasor possa interagir com ele a fim de obter um log
sobre as atividades do intruso trazendo informações sobre ele.
Para esse tipo de aplicação existem três tipos de ataques. O primeiro é quando o invasor
pretende entrar na rede com fio a qual a rede wireless se conecta, deste modo esta é só o meio
de acesso, mas o destino é a rede com fio. O segundo quando o atacante pretende direcionar o
ataque aos clientes utilizadores de redes wireless, ou seja, a rede sem fio, aqui também, é
somente o meio, mas o destino é o utilizador da rede. O terceiro e último ataque é direcionado
para a infraestrutura da rede, na qual o objetivo é ganhar o controle da rede.
2.7.3.
Honeynet.BR
O Honeynet.BR é um projeto criado a partir de pesquisas em andamento sobre Sistemas de
Informação de Segurança do Instituto Nacional de Pesquisas Espaciais (INPE) juntamente
com a CERT.br que aliados implementam um honeypot de pesquisa (Honeynet.BR). Assim,
ambos contribuem para a tarefa internacional que buscar informações sobre atividades da
comunidade Black Hat. Comunidade esta composta por indivíduos que desejam adentrar a
sistemas sem autorização por meios ilícitos. Nos sistemas de busca o Black Hat tem técnicas
que manipulam variáveis utilizadas nos sistemas de buscas web.
O projeto Honeynet.BR é um sistema ativo e têm atuado como um laboratório de pesquisa do
INPE e utilizado no curso de pós-graduação de Computação Aplicada. Sua arquitetura de rede
é basicamente uma Honeynet com algumas modificações. A rede é composta de uma rede
35
administrativa e da própria honeynet. A primeira é composta por três principais componentes,
o firewall, o IDS e uma máquina de computação forense.
O firewall funciona em modo bridge com o OpenBSD e o Packet Filter (PF) rodando,
registrando todo o tráfego e limitando a largura de banda de saída. Um programa foi
desenvolvido de modo que limite a atividade do intruso e que dinamicamente altere as regras
do firewall. Este programa chama-se sessionlimit, que é capaz de monitorar o tráfego de saída
para detectar atividades maliciosas e também analisa o escaneamento de portas abertas pela da
honeynet.
Já o IDS opera com duas interfaces de rede, uma ligada à rede administrativa e outra pela
honeynet. Este é responsável por capturar todo o tráfego e não possui um endereço ip
definido, o que ajuda na transparência do sistema, é responsável ainda por gerar alertas para
todos os usuários por e-mail. A máquina forense computacional é usada para armazenar e
analisar imagens de partições das máquinas da honeynet ferramentas e rastros deixados pelos
invasores.
A honeynet é composta de várias máquinas que executam sistemas operacionais e serviços
diferentes. O log das atividades é gerado e analisado remotamente e todo tráfego interno é
capturado pelo IDS. O Honeynet.BR é um membro da Honeynet Research Alliance desde
junho de 2002.
2.7.4.
Project Honey Pot
Projeto Honey Pot foi criado por Unspam Technologies, uma empresa anti-spam com a
missão de ajudar na elaboração e aplicação das leis anti-spam. Atualmente buscam parcerias
com empresas de softwares e as autoridades para o desenvolvimento de aplicações que
combatam este tipo de ameaça e que possam ser aplicadas penalidades legais aos infratores.
Projeto Honey Pot é o primeiro e único sistema distribuído para identificar spammers e
spambots que utilizam para atingir e vasculhar os endereços de email pertencentes a cada
domínio. Ele é uma ferramenta de monitoração on-line que uma vez instalada no site permite
encontrar possíveis ameaças que rondam os sistemas web e fazem a colheita de endereços.
36
Por tratar-se de uma ferramenta desenvolvida por uma empresa privada, ela tem um custo
para sua instalação.
2.7.5.
Brazilian Honeypots Alliance
Este projeto tem por objetivo alcançar maior capacidade de detecção de ataques em território
brasileiro, assim como obter dados sobre tendência de ataques. Entre suas atitudes destacamse a implantação de uma Honeynet de baixa interatividade, tentando cobrir a maior parte da
faixa IP brasileira. Criar um sistema de análise de dados que permita identificar tendências de
ataques. E atuar juntamente com grupos que desenvolvam respostas a possíveis ameaças. A
Figura 3 mostra as localidades brasileiras que possuem Honeypots instalados.
Figura 3 - Distribuição de Honeypots no Brasil (CERT, 2010)
Tabela lista as instituições participantes e localidades fazendo relação com a Figura 3.
Tabela 1 - Descrição dos Honeynets existentes no Brasil
Cidade
01
São
Instituição
José
dos INPE, ITA
37
Campos
02
Rio de Janeiro
BNDES,
CBPF,
EMBRATEL,
Fiocruz,
Furnas, PUC-RIO, RedeRio
03
São Paulo
ANSP,
Banco
Durand,
HC
Real,
CERT.br,
FMUSP,
Diveo,
LOCAWEB,
PRODESP, TIVIT, UNESP, UOL, USP
04
Campinas
CenPRA, ITAL, UNICAMP
05
São José do Rio UNESP
Preto
06
Piracicaba
USP
07
Petrópolis
LNCC
08
Brasília
Banco do Brasil, Brasil Telecom, CTIR Gov,
Ministério da Justiça, TCU
09
Porto Alegre
CERT –RS, TRI
10
Ribeirão Preto
USP
11
São Carlos
USP
12
Florianópolis
UFSC DAS
13
Uberlândia
CTBC Telecom
14
Lins
FPTE
15
Passo Fundo
UPF
16
Curitiba
Onda, PoP-PR, PUCPR
17
Belém
UFPA
18
São Leopoldo
Unisinos
19
Belo Horizonte
CSIRT PoP-MG, Diveo
20
Recife
EMPREL
21
Salvador
UFBA
22
Vitória
PoP-ES
23
Americana
ADG
FONTE: CERT.BR, 2010
2.8. Honeypots, Honeynets e a Segurança da Rede
38
Até o momento pode ser observado que a ferramenta Honeypot, parece e é de grande utilidade
e poderia resolver e rastrear muitas atividades prejudiciais à rede em questão. Porém é
importante entender quando implementar tal recurso e que benefícios ele trará para cada um
em específico. A sua aplicabilidade estará sempre atrelado ao uso de sistemas de firewall e o
IDS em conjunto, pois o tráfego que será direcionado para a Honeynet será filtrado
previamente por ambas às ferramentas e por elas direcionadas. Dessa forma na Honeynet só
será encontrado o tráfego malicioso e que necessita de monitoração e análise.
O tráfego que circulará dentro de uma honeynet possui grande valor de informações e
acontece em quantidade bem menor do que os softwares IDS, e como este é um tráfego
anômalo o índice de falso-positivo é muito menor. Para honeypots de baixa interatividade sua
implementação é indicada quando o objetivo é se ter um baixo risco de comprometimento e
não se possui uma equipe preparada para cuidar das aplicações ou hardware disponível para
implementar uma honeypots reais. Dessa forma, são indicados para redes de produção. Em
geral este tipo aplica-se melhor quando é necessário alcançar algum dos objetivos abaixo:

Detectar ataques internos;

Identificar varreduras e ataques automatizados;

Identificar tendências;

Manter atacantes afastados de sistemas importantes;

Coletar assinaturas de ataques;

Detectar máquinas comprometidas ou com problemas de configuração;

Coletar código malicioso (malware).
Já os Honeypots de alta interatividade são mais bem aplicados quando o objetivo é de
pesquisa, mas também podem ser utilizados para o mesmo propósito dos de baixa
interatividade, porém este traz um maior risco para a instituição. Este risco apesar de alto é
justificado quando se quer estudar o comportamento de invasores, suas motivações, além de
estudar detalhadamente as ferramentas utilizadas e quais foram às vulnerabilidades
exploradas. É claro que sua implementação necessita de pessoal qualificado e regras de
contenção mais eficientes.
A Tabela 2 mostra uma relação entre os tipos de honeypots demonstrando as principais
diferenças e níveis de dificuldades para determinadas execuções para cada tipo.
39
Tabela 2 - Tabela Comparativa entre honeypots de baixa e alta interatividade
Tabela Comparativa
Características
Baixa interatividade
Alta interatividade
Instalação
Fácil
Mais difícil
Manutenção
Fácil
Trabalhosa
Risco de comprometimento
Baixo
Alto
Obtenção de informações
Limitada
Extensiva
Necessidade de mecanismos de contenção
Não
Sim
Atacante tem acesso ao S.O. real
Não (em teoria)
Sim
Aplicações e serviços oferecidos
Emulados
Reais
Atacante pode comprometer o honeypot
Não (em teoria)
Sim
FONTE: CERT.BR, 2010
Nesse aspecto serão analisadas nas subseções a seguir as vantagens e desvantagens dos
sistemas Honeynets.
2.9. Vantagens dos Honeypots e Honeynets
Sua primeira grande vantagem é o fato de que é um sistema pronto para ser comprometido,
deste modo caso aconteça algum dano, este já será algo esperado. Sendo assim a partir disso
será possível analisar os logs gerados para a criação de uma defesa ou de uma resposta a
determinados tipos de ataques.
Conhecer as vulnerabilidades da rede em que o tráfego será implantado é um dos benefícios,
porém não existe benefício maior do que conhecer seu inimigo. Dentro de cenários de
conflitos, saber as táticas, as atitudes, as armas e as movimentações do oponente torna-se
crucial na definição do vencedor. O mesmo acontece no ambiente virtual, saber com que se
está lidando é um grande avanço na proteção de dados e do sistema como um todo.
As vantagens de se usar honeynets virtuais são que, a manutenção é mais simples, já que
todos os componentes de hardware e software estão na mesma máquina. O ganho em espaço
40
físico também é outro fator relevante, já que toda a Honeynet estará dentro de uma máquina, e
o custo final tende a ser mais baixo, apesar de necessitar de um equipamento mais potente.
E para as honeynets reais são o baixo custo por dispositivo. Além disso, é mais tolerante a
falhas, já que são vários honeypots e a parada de um não prejudicará aos outros, e os atacantes
interagem com ambientes reais, aproximando-os de uma realidade virtual mais compatível
com o da rede real.
2.10.
Desvantagens dos Honeypots e Honeynets
Para as Honeynets virtuais podem se citar o alto custo por dispositivo, pois para emular vários
sistemas dentro de uma máquina, através do software de virtualização, necessita-se de
equipamentos mais robustos e pouco tolerantes a falhas dos dispositivos de hardware, pois se
um hardware falhar toda a honeynet irá parar. Além disso, o software de virtualização pode
limitar o hardware e sistemas operacionais utilizados. Outro fato relevante é que o atacante
pode obter acesso a outras partes do sistema devido ao fato que tudo está compartilhado, ou
seja, todos os recursos de um mesmo dispositivo são usados para todos os SO ao mesmo
tempo.
Importante também lembrar que, qualquer falha pode induzir ao atacante entender que
adentrou um sistema virtual e caiu na verdade dentro de um sistema preparado para receber
ataques, e todos os seus passos foram monitorados. Assim estará de certa forma, comprando
uma briga com o intruso, que se sentirá cada vez mais desafiado.
Para as Honeynets reais, as principais desvantagens são a manutenção mais trabalhosa, uma
vez que haverá mais dispositivos físicos instalados, o maior espaço físico para os diversos
dispositivos é outro fato importante e, além disso, o custo total tende a ser mais elevado.
3.
FERRAMENTAS UTILIZADAS
41
Atualmente com alguns projetos difundidos pela internet, existem ferramentas com licença
livre e também produtos vendidos comercialmente. Dentre eles existem para a plataforma
Windows e Linux.
As ferramentas testadas neste trabalho estão descritas na lista abaixo.
a)
LaBrea Tarpit: Ele é um atrativo de worms, hackers e outras ameaças da internet. Capaz
de trabalhar no Linux, Windows, FreeBSD e Solaris. Ele é capaz de diminuir e até parar um
ataque. Tomando conta de novos endereços IP da rede emulando máquinas virtuais e
respondendo a solicitações.
b)
Deception Toolkit: Trabalha com a plataforma Linux, este foi um dos primeiros
Honeypots a ser criado. Capaz de simular o que o sistema possui de vulnerabilidades,
atendendo solicitações e enviando respostas.
c)
BackOfficer Friendly: Ferramenta desenvolvida para Windows que emula serviços
como TELNET, FTP, SMTP, POP3 e IMAP2. Ele gera respostas falsas quando qualquer um
dos protocolos anteriores é solicitado, o que acaba por enganar o atacante. Porém consegue só
monitorar sete portas por vez. Em 2002 deixou de ser uma ferramenta freeware, sendo
administrado e comercializado pela Check Point® Software Technologies.
d)
Tiny Honeypot: É capaz de operar com serviços FTP e TELNET, trabalhando com a
plataforma Linux.
e)
Valhala: Um dos mais conhecidos entre os usuário de Honeynet, possui tutoriais pela
internet e alguns vídeos. Este possui serviços como o FTP, Telnet, POP3, SMTP, SSH,
Servidor Finger, TFTP, Servidor Port Forwarding e Servidor WEB.
f)
Honeyd: Realiza emulação de centenas de sistemas operacionais. Pode ainda monitorar
todas as portas TCP e UDP. Além disso, é Open Source, ou seja, seu código pode ser alterado.
Trabalha nas plataformas Linux e Windows.
3.1. Ferramenta de Virtualização
42
Para a virtualização de sistemas operacionais a ferramenta utilizada é o VirtualBox, produto
desenvolvido pela empresa SUN, conhecida mundialmente pela linguagem Java. Ao final de
2009 a SUN foi adquirida pela Oracle e que a partir de então possui a responsabilidade por tal
ferramenta. Segundo informações do próprio site é o único software de código aberto sob os
termos GNU General Public License (GPL2).
O VirtualBox é capaz de virtualizar sistemas da plataforma da Microsoft®, plataformas Linux
e também a Unix. Dentre os recursos que oferece está o fundamental para o desenvolvimento
dos testes da Honeynet a virtualização de placas de rede em modo brigde de forma que cada
máquina virtual possa comunicar-se com as demais. Suporta diversos sistemas operacionais
para emulação também dentre eles Windows (NT 4.0, 2000, XP, Server 2003, Vista, Windows
7), DOS / Windows 3. X, Linux (2.4 e 2.6), Solaris e OpenSolaris, e OpenBSD.
Esta ainda possui recursos de compartilhamento de pastas com as demais máquinas virtuais e
a máquina hospedeira, além do suporte a dispositivos USB. Outra grande funcionalidade e
recurso é que o estado da máquina e configurações é armazenado em XML tornando o estado
da máquina independente das máquinas locais, podendo ser executada em outra máquina
desde que possua o VirtualBox instalado.
Por fim o VirtualBox demonstra grandes vantagens para a utilização neste trabalho, sendo que
atende as necessidades exigidas para os testes em questão. Pode suportar diversos SO,
suportando os sistemas hospedeiros mais difundidos e, além disso, é capaz de virtualizar
todos os sistemas em qual se executa os honeypots.
3.2. Sistemas Operacionais
Os sistemas operacionais utilizados para os testes trabalham nas plataformas que cada
honeypot, todos devidamente licenciados ou de licença livre. Os sistemas utilizados são
listados abaixo:
3.2.1.
2
Microsoft Windows
GNU General Public License (Licença Pública Geral), GNU GPL ou simplesmente GPL, é a designação da
licença para software livre idealizada por Richard Stallman no final da década de 1980, no âmbito do
projeto GNU da Free Software Foundation (FSF).
43
a)
Microsoft Windows XP
Sistema operacional desenvolvido pela Microsoft® disponível em 32 e 64 bits, desenvolvido
para utilização em computadores pessoais, escritórios, notebooks e medias centers. Seu nome
deriva da palavra eXPeriência. Este foi lançado como sucessor do Microsoft Windows 2000 e
Microsoft Windows Me.
O Windows XP foi o primeiro construído sobre nova arquitetura e núcleo, Windows NT 5.1,
lançado em 26 de outubro de 2001. Tal sistema ficou conhecido por sua estabilidade e
eficiência que melhoraram significativamente em relação às edições 9x. Com o novo núcleo e
interface conquistou usuários domésticos e corporativos. Neste trabalho a versão utilizada foi
a Professional tendo em vista que a aplicação Honeypot tende a ser utilizada no meio
corporativo.
b)
Microsoft Windows 7.
Lançado em 22 de julho de 2009 o Windows 7 é o sucessor do Windows Vista que
aparentemente durou apenas 3 anos no mercado como último produto da Microsoft, foi
lançado com nova proposta em ser melhor ainda que seu antecessor. Este, segundo a
Microsoft, ganhou aprimoramento em sua capacidade de interface gráfica e os recursos como
leitura nativa de Blu-Ray e HD DVD. Neste trabalho a versão utilizada foi a Professional.
c)
Microsoft Windows Server 2003
Sistema desenvolvido pela Microsoft, este é voltado para utilização em servidores. Foi
lançado em 24 de abril de 2003, sucedendo a versão 2000 do mesmo sistema. Conhecido com
W2k3, o seu núcleo basicamente é como o Microsoft Windows XP, com algumas funções
desligadas a fim de garantir estabilidade em seu funcionamento.
Tal sistema aumentou as funcionalidades em relação ao seu antecessor em questões de
gerenciamento e no Active Directory implementando mais funcionalidades nesta nova versão.
3.2.2.
Linux
44
a)
Ubuntu
O sistema operacional utilizado neste trabalho é o Ubuntu, sistema que é baseado no Linux e
totalmente gratuito, e segue os termos de compromisso GNU General Public License (GPL)
cada versão é lançada de 6 em 6 meses, neste trabalho a versão utilizada para a
implementação é a 10.04 lançada em abril de 2010. O nome Ubuntu é uma palavra africana
que significa “Humanidade para os outros”, condizendo com sua atitude de um software livre.
Os sistemas Ubuntu possuem a versão Long Time Support (LTS), ou seja, durante três anos dá
suporte gratuito aos seus usuários e no caso do sistema desenvolvido para servidores cinco
anos. Suas novas versões serão sempre gratuitas e podem ser obtidas através da internet com
atualizador dentro do próprio sistema.
b)
Debian
O Debian é uma distribuição Linux não comercial e livre, atende fortemente aos princípios do
GNU, ou seja, é totalmente livre e tem seu código fonte aberto. O seu desenvolvimento é
mantido por um grupo de voluntários espalhados pelo mundo.
Este sistema é conhecido pelo sistema de gestão de pacote chamado APT, que permite
atualizações de maneira fácil e instalação de novos pacotes ou para pacotes mais estáveis.
Atualmente o Debian Stable encontra-se na versão 5.0. Versão esta que será utilizada no
desenvolvimento deste trabalho. O grande foco deste Sistema Operacional é a utilização em
servidores uma vez que contem pacotes mais antigos, o que garante mais estabilidade ao
sistema.
3.3. Ferramentas de Ataque
45
3.3.1.
N-Stealth
Este software é capaz de agir como scanner em portas HTTP, tentando encontrar
vulnerabilidades, e tentando abrir URL’s maliciosas como, por exemplo, TEXT.CGI,
WEBSENDMAIL entre outras. Seu layout pode ser observada na Figura 4.
Figura 4 - N-Stealth em sua versão gratuita 3.7
3.3.2.
LeechFTP
O LeechFTP é um dos mais antigos e conhecidos softwares que realizam tal tarefa. Com ele é
possível gravar as conexões mais realizadas em bookmarks, além de várias conexões ao
mesmo tempo. Foi desenvolvido para trabalhar desde o Windows 95 até os atuais.
Neste trabalho ele será utilizado como ferramenta auxiliar para conexões vias FTP em
listagens de diretórios. A Figura 5 mostra o seu visual.
46
Figura 5 – LeechFTP
3.3.3.
PuTTy
É um programa cliente para protocolos de rede SSH, TELNET e Rlogin. Esses protocolos são
usados para rodar uma sessão remota num computador, sobre uma rede. O software
implementa o cliente no fim da sessão: o fim no qual a sessão é exibida, ao invés do fim em
que ela é executada. Neste trabalho será utilizado para testes com conexões TELNET. A
Figura 6 mostra o seu visual.
Figura 6 – PuTTy
47
4.
MÉTODOS E CRITÉRIOS
4.1. Definições de critérios
Os critérios utilizados na avaliação dos honeypots foram desenvolvidos de acordo com os
padrões e definições descritos segundo (SPTIZER, 2010) a cerca de honeypots. E seguindo
também padrões de projetos escritos por (SOMMERVILLE, 2007). Os critérios usados
primordialmente serão:
a) Plataforma operante, operação em múltiplas plataformas: Operação ou
disponibilidade do software em várias plataformas para o ambiente institucional
se apresenta como vantagem significativa, uma vez que num parque
computacional pode-se encontrar SO diferentes. Tal diferença é notada ao
analisar a tendência das empresas, por exemplo, utilizarem servidores Linux e
clientes Windows.
b) Facilidade de uso, layout organizado: Segundo os princípios de engenharia de
software o software, bem organizado é aquele que demonstra um layout
organizado e sem muitos sub-menus de acesso, proporcionando ao usuário fácil
acesso
e
claro
entendimento
das
ferramentas
a
serem
utilizadas
(SOMMERVILLE, 2007).
c) Facilidade de configuração usabilidade na hora de definir as configurações
necessárias para utilização do sistema: As devidas configurações para o sistema
iniciar com funcionamento pleno devem possuir fácil acesso e ser apresentado de
maneira clara, a fim de que não confunda o seu possível usuário
(SOMMERVILLE, 2007).
d) Facilidade
de
gerenciamento,
monitoria
de
máquinas
simplificada
e
acompanhamento de suas atividades: O sistema Honeypot é eficiente a partir do
momento em que seu gerenciamento torna-se possível e passe através deste a
entregar ao usuário informações de acesso ou de tentativas de acesso nas portas
monitoradas.
48
e) Confiabilidade na monitoração, captura de dados verídicos: Os dados que são
entregues a partir do Honeypot ou da Honeynet só possuem valores pertinentes
ao usuário no momento em que estes relatam somente a verdade. Números de ip
de atacantes errados impossibilitam a descoberta da origem do ataque, e tal
ferramenta acaba por assumir a tarefa designada a um Firewall. Eficiência do log
gerado. Necessário conter dados de qualidade, para geração de contra-ataque ou
defesa: Dados de qualidade para um Honeypot são considerados aqueles que
trazem informações sobre o invasor e suas possíveis motivações. Tais dados
podem ser observados abaixo:

Endereço IP

Endereço MAC

Porta Utilizada

Data e Hora

Diretórios acessados

Arquivos acessados

Downloads

Uploads

Usuário Utilizado

Senha Utilizada
f) Opção de entrega de log: Os recursos utilizados em redes tendem a oferecer
flexibilidade e maior praticidade, compartilhando recursos, tarefas, ou até mesmo
processos. Deste modo a troca de dados pode se dar através da mídia que
interconecta os nós da rede.
O programa Honeypot que apresentar opções de entrega diferenciadas ou usem
dos recursos da própria rede para o envio do mesmo, estará por si só
aproveitando um recurso básico da rede. E também irá aumentar a capacidade de
gerenciamento do administrador de rede, já que este não necessitará mais
percorrer os Honeypots verificando os logs, já que estes estarão concentrados,
por exemplo, em um servidor de email.
49
g) Rastreamento do invasor, capaz de obter dados do invasor: Todo Honeypot tem
como objetivo a monitoração dos acontecimentos a cerca de ataques ou
comprometimentos que possam acontecer. Esse acompanhamento das atividades
devem retornar informações que de alguma forma possam trazer dados sobre o
atacante, dispondo assim, a ferramenta utilizada, da capacidade de rastrear e
obter dados do possível invasor, que podem estar entre os citados no item f.
h) Invisibilidade ao atacante, atacante acreditar que está em uma rede real: A
usabilidade de um Honeypot ou de uma Honeynet está diretamente atrelada a
uma armadilha que busca ludibriar o seu inimigo que no contexto da informática
pode ser tratado de uma forma geral como Craker. Para este o sistema não pode
demonstrar que na verdade é uma arquitetura falsa e tem por objetivo monitorar
seus passos.
Dessa forma é necessário enviar respostas às solicitações do invasor, sendo capaz
de produzir respostas aparentemente verdadeiras, do mesmo modo em que
encontraria em sistemas convencionais ou institucionais. Tal sistema deve
produzir dentro dos serviços disponíveis solicitações de login e senha e possuir
na sua base um par de informações de autenticação verídicas.
i) Realidade do Honeypot. Maior aproximação de uma máquina real da instituição,
incluindo dados e sistemas, sendo capaz de simular mais de um tipo de sistema
operacional: Um Honeypot é definido como um sistema preparado para ser
atacado ou até mesmo comprometido sendo que as ações realizadas em seu
sistema estão sendo monitoradas. Para tanto este precisa possuir um sistema,
mesmo falso, que traga ao invasor a impressão de que realmente existe um
sistema de arquivos, um diretório raiz, pastas compartilhadas ou até mesmo
serviços como email ou impressão.
50
Além disso, é importante que cada Honeypot possa assumir endereços atribuídos dentro na
própria rede obedecendo a normalização de classes e de valores dentro das configurações do
IPv43.
4.2. Tabela de pontuação
A tabela de pontuação apresenta-se como método de avaliação das aplicações tendo em vista
os princípios do funcionamento de um honeypot, basedo em (SPTIZER, 2010). Os critérios
devem levar em conta a interatividade com o usuário, seguindo critérios descritos em
(SOMMERVILLE, 2007).
A base da pontuação varia de 0 a 10, conforme a característica do software em questão. Sendo
que, cada item é avaliado de acordo com as disponibilidades das opções de cada item dos
critérios descritos na seção 4.1 deste trabalho.
Tabela 3 - Pontuação do Honeypot
Critério de avaliação
Atende às Necessidades
Atende Parcialmente
Limitado
Não Atende
Conceito Valor
Ótimo
8 - 10
Bom
6-8
Regular
3-6
Ruim
0-3
FONTE: SILVA,2010
Os critérios discriminados na Tabela 3 tem a definição dos requesitos da seguinte forma:
“Atender às necessidades” significa disponibilizar serviços com opções satisfatórias; já
“atender parcialmente” é disponibilizar o recurso, porém não atender completamente às
necessidades; ser “limitado” é não oferecer uma segunda opção de plataforma e, por fim, não
atender às necessidades significa apresentar falhas em pontos importantes para a proposta
honeypot.
3
No IPV4, os endereço IP são compostos por 04 blocos de 08 bits (32 bits no total), que são
representados através de números de 0 a 255, como "200.156.23.43" ou "64.245.32.11".
51
A pontuação será executada a partir da implementação, a implementação é um critério de
avaliação. A pontuação total estará fechada quando o honeypot estiver completamente
configurado e em funcionamento, e quando isso não for possível mesmo assim será atribuída
a pontuação que se enquadre na sua situação atual.
Ao final de cada teste, será gerada uma tabela que obedecerá ao padrão que pode ser
observado na Tabela 4:
Tabela 4 - Tabela de Avaliação de Software
Critério de avaliação Nota
Resultado
Plataforma
10
Ótimo
Layout
10
Ótimo
Configuração
10
Ótimo
Gerenciamento
10
Ótimo
Confiabilidade
10
Ótimo
Eficiência do Log
10
Ótimo
Opção de Entrega
10
Ótimo
Rastreamento
10
Ótimo
Invisibilidade
10
Ótimo
Realidade Honeypot
10
Ótimo
Realidade da
10
Ótimo
Honeynet
FONTE: SILVA, 2010
Neste exemplo, foi atribuída para todos os itens a nota 10 que equivale, conforme a tabela 3,
ao resultado ótimo.
4.3. Cenários de avaliação
Para a realização dos testes de cada software, o foi adotado dois cenários, a fim de simular as
possibilidades que possam existir nas mais diversas situações das instituições que desejam
52
implementar o sistema honeypot. Cenário 01, servidor Microsoft Windows Server 2003, com
clientes Microsoft Windows XP e Seven e Ubuntu 10.04.
Já no cenário 02, a plataforma livre foi adotada como sistema base. Nesta foi proposto um
servidor Linux, podendo ser o Centos ou Debian. E para os clientes, Microsoft Windows XP e
Seven e distribuições como Debian e Ubuntu.
4.3.1.
Cenário 01.
No primeiro cenário o servidor é baseado na plataforma Windows utilizando a versão Server
2003, as configurações podem ser visualizadas na Tabela 5.
Tabela 5 - Cenário 01 de testes
Processador
Memória
RAM
HD
Endereço IP
SO
Hospedeiro
Intel Dual Core
T2390
Servidor
Simulado VM
Atacante 01
Simulado
VM
2,00 GB
250 GB
-
512 MB
10 GB
192.168.1.1
Windows Server
2003
296 MB
512 MB
05 GB
05 GB
192.168.1.10 192.168.1.11
Ubuntu
Windows XP 10.04
Windows Seven
Atacante 02
Simulado
VM
Sistemas emulados no hospedeiro com Oracle VirtualBox 3.1.8 r61349
4.3.2.
Cenário 02.
O segundo cenário é baseado na plataforma Linux. Para os testes o servidor é o Debian 5.0 na
sua versão estável, as configurações utilizadas no sistema podem ser observadas na Tabela 6.
53
Tabela 6 - Cenário 02 de testes
Processador
Memória
RAM
HD
Endereço IP
SO
Hospedeiro
Intel Dual Core
T2390
Servidor
2,00 GB
250 GB
-
512 MB
10 GB
192.168.1.2
Windows Seven
Debian 5.0 Stable
Simulado VM
Atacante 01
Simulado
VM
Atacante 02
Simulado
VM
296 mb
512 mb
05 GB
05 GB
192.168.1.10 192.168.1.11
Ubuntu
Windows XP 10.04
Sistemas emulados no hospedeiro com Oracle VirtualBox 3.1.8 r61349
4.4. Discriminação de rede
A rede adotada é uma rede virtual intermediada pela máquina virtual da Oracle na qual simula
uma rede local comum que pode ser tida como exemplo base em ambientes corporativos. A
Figura 7 representa a estrutura básica do modelo implementado para testes.
Figura 7 - Esquema de rede nos testes realizados
54
5.
RESULTADOS
Neste capítulo serão apresentados os testes realizados com os honeypots estudados nesse
trabalho. Para tanto serão descritas as configurações utilizadas para cada honeypot e as
tentativas de acesso em cada sistema.
5.1. Valhala Honeypot
O Valhala Honeypot é um honeypot desenvolvido por Marcos Flávio Assunção, um brasileiro
que desenvolveu seu sistema. Este software é capaz de operar no Microsoft Windows e emular
diversos serviços além de ser totalmente em português e para iniciantes é ótimo para se
aprender muito a cerca desta tecnologia.
5.1.1.
Configurações
Neste trabalho a versão posta em testes foi a sua última, 1.8, disponível para download no site
do criador (http://valhalahoneypot.sourceforge.net). A Figura 8 mostra seu menu de
configuração assim como os serviços que pode emular.
Figura 8 - Opções de configuração do Valhala
55
Quando a opção Servidor WEB é selecionada, ele abre uma segunda tela na qual é dada a
opção de configuração de tal serviço. Isto pode ser observado na Figura 9.
Figura 9 - Configuração do Servidor WEB
5.1.2.
Testes
Os testes foram fundamentados segundo a estruturação de rede descrita no item 4.4 deste
trabalho.
A Figura 10 demonstra a configuração do Servidor TELNET. Na sinalização o banner, está
configurado para simular um servidor Windows Server 2003, e como login e senha teste, e
teste. Para a simulação também existe a possibilidade de criar diversas pastas dentro dos
diversos diretórios disponíveis para criação.
A direita da tela ainda existe a opção de definir a letra da unidade a ser listada, assim como o
nome do volume. Além disso, pode-se atribuir à unidade um número de série. A possibilidade
de criar arquivos falsos também é uma funcionalidade significativa, podendo determinar hora
e data dos arquivos.
Ainda existem opções de configuração do MAC-ADDRESS, nome da placa, DNS e número
máximo de comandos a se permitir.
56
Figura 10 - Tela de configuração TELNET
O servidor com o Valhala honeypot foi configurado na máquina que possui o Windows Server
2003 instalado, descrita anteriormente no item 4.3.a, e o acesso via TELNET a partir do
prompt de comando da máquina de testes Windows XP. Na Figura 11 está representado o
ambiente de testes realizado com as máquinas acima mencionadas.
No que a listagem de pastas foi realizada com sucesso, sendo que as pastas existentes foram
simuladas no ambiente de configuração do serviço de TELNET do Valhala. Muitos
comandos, este software honeypot foi capaz de reconhecer e enviar respostas em tempo real.
Porém o honeypot não conseguiu reconhecer alguns comandos básicos, por exemplo, deletar
uma pasta “deltree <nome da pasta>”, o sistema responde que existe argumento inválido ou
não reconheceu o comando.
57
Figura 11 - Ambiente de testes Valhala
A Figura 12 mostra a configuração do serviço de FTP
Figura 12 - Configuração do servidor de FTP
58
A porta padrão foi mantida e como diretório raiz, um diretório temporário no disco C:. Como
usuário padrão foi utilizado o “root” e senha “1234”. Quando realizada a conexão via prompt
de comando da máquina atacante a tentativa de ataque é reconhecida instantaneamente e já
com a captura de log, como pode ser observado na Figura 13.
Figura 13 - Ambiente de testes do servidor FTP
A tentativa de acesso também foi realizada a partir do Leech FTP como segue na Figura 14.
Figura 14 - Testes de acesso com o LeechFTP
A Figura 15 demonstra a configuração realizada para a habilitação do serviço de POP3 no
honeypot em questão.
59
Figura 15 - Configuração do serviço POP3
Na configuração do serviço é possível determinar o banner para o serviço e ainda criar
respostas de emails falsos sendo possível adicionar um pequeno corpo a mensagem. O teste
do servidor e do acesso remoto foi feito via prompt de comando como demonstrado na Figura
16.
Figura 16 - Teste de acesso via POP3
Os testes sobre o servidor WEB, também foram realizados seguindo a configuração mostrada
como exemplo neste capítulo no item a, da Figura 9. Utilizando dessas configurações foi
60
realizada a conexão via prompt utilizando a porta 80, o acesso foi imediatamente identificado
pelo honeypot e pode ser observado com mais detalhes na Figura 17.
Figura 17 - Acesso via prompt do servidor WEB
Para os testes sobre o servidor WEB implementado foi adotado o escaneamento do mesmo
através do N-Stealth como pode ser observado na Figura 18, na qual a esquerda está o
software de rastreamento e a direita o Valhala honeypot.
Figura 18 - Testes do servidor WEB Valhala
Como teste do honeypot em questão também foram aplicados testes sobre o servidor de
SMTP. As configurações disponibilizadas são simples e de fácil aplicação, é necessário
somente introduzir o banner a ser utilizado no servidor e a porta na qual ele irá operar, por
padrão foi mantida a porta 25. Sua tela de configuração pode ser observada na Figura 19.
61
Figura 19 - Configuração do servidor SMTP
Quando houve a tentativa de acesso do servidor pela porta configurada, o sistema honeypot
conseguiu detectar corretamente a ameaça e identificar a origem do ataque, como pode ser
notado na Figura 20.
Figura 20 - Acesso ao servidor SMTP
5.1.3.
Log
Como o log pode ser salvo, para análise posterior este também pode ser enviado via e-mail,
porém precisa de um servidor de e-mail configurado para o seu funcionamento. O log gerado
a partir da tentativa de invasão a partir do TELNET pode ser observado a seguir.
62
(16:02:17) O IP 192.168.1.10 tentou invasão por telnet (conexão)
(16:02:20) O IP 192.168.1.10 tentou invasão por telnet (USUÁRIO teste)
(16:02:22) O IP 192.168.1.10 tentou invasão por telnet (SENHA teste)
(16:02:37) O IP 192.168.1.10 tentou invasão por telnet (dir )
(16:02:58) O IP 192.168.1.10 tentou invasão por telnet (deltree arquivos )
(16:03:20) O IP 192.168.1.10 tentou invasão por telnet (dir )
(16:03:39) O IP 192.168.1.10 tentou invasão por telnet (del dkafsjfsjvsteste teste )
(16:04:03) O IP 192.168.1.10 tentou invasão por telnet (delete arquivos )
(16:05:09) O IP 192.168.1.10 tentou invasão por telnet (del arquivos )
(16:05:46) O IP 192.168.1.10 tentou invasão por telnet ()
Note que no log pode-se ver o horário da tentativa de acesso ao endereço de IP do host o
serviço que tentou acessar e o comando digitado. A captura do texto “(del dkafsjfsjvsteste
teste )” parece confusa, porém o texto teste iniciou-se, houve erro de digitação e o mesmo
quando apagado utilizando o backspace do teclado gerou essas combinações de letra.
Desse modo o sistema de captura também captura a digitação de teclas que não são letras,
porém torna o log confuso e de difícil compreensão com a sequência atribuída para tal
comando. O log com mais detalhes pode ser observado no ANEXO 01a.
O log é salvo em formato texto sendo que o nome do arquivo é a data a qual corresponde
aquele log, facilitando o seu uso e análise. Esta pode ser feita por softwares especializados
que se encarregam de gerar estatísticas para uma análise mais simplificada.
5.2. BackOfficer Friendly
Este honeypot pode emular serviços como o TELNET, FTP, SMTP, POP3 e IMAP2, este
sistema é livre para o uso pessoal. A versão usada para testes neste trabalho é a 1.01.
5.2.1.
Configurações
O uso desse honeypot é bastante indicado para iniciantes que queiram conhecer o que é o
serviço. Suas configurações são limitadas entre ativar e desativar o serviço.
63
5.2.2.
Testes
Para os testes foram ativados os servidores de TELNET, FTP, WEB, POP3 e IMAP2, e como
ferramentas de tentativas de intrusão o PuTTy, N-Stealth e o Leech FTP.
A Figura 21 demonstra o teste utilizando o PuTTy, na qual tenta-se acesso via TELNET.
Figura 21 - Tentativo de acesso indevido via TELNET
Como o sistema não permite configuração do serviço de TELNET, não existe a possibilidade
da configuração de usuário e senha neste honeypot. Enquanto na máquina de ataque estava
tentando conexões com a máquina servidora, nesta última o honeypot estava capturando as
tentativas de acesso conforme demonstrado na Figura 22.
64
Figura 22 - Monitoramento e captura de acessos via TELNET BackOfficer
Note que todo o conteúdo digitado no console do PuTTy foi capturado pelo BackOfficer.
Em seguida o servidor IMAP2 foi para um teste, e o seu acesso foi realizado da máquina
atacante e através do prompt de comando digitado o seguinte comando:
telnet <ip do servidor> 143
Comando no qual resultou a resposta que pode ser observada na Figura 23. E a direita da
mesma imagem pode-se notar que o software honeypot identificou a tentativa de ataque e
capturou o IP da máquina que solicitou o acesso.
Figura 23 - Tentativa de acesso IMAP2
A conexão via POP3 também foi realizada através do prompt de comando, como pode ser
notado na Figura 24. O teste foi executado através do seguinte comando:
telnet <ip do servidor> 110
65
Figura 24 - Tentativa de acesso POP3
Note que nesta tentativa de acesso também foi identificada pelo BackOfficer listando o IP da
máquina atacante dia, mês e horário. A conexão via SMTP, Figura 25, foi realizada da mesma
forma, seguindo o mesmo critério de conexão via telnet, como segue abaixo:
telnet <ip do servidor> 25
Figura 25 - Tentativa de conexão SMTP
Já conexão do servidor WEB, foi realizada pelo N-Stealth, ou seja, colocada para testes de
vulnerabilidades e escaneamento do servidor. Em seu resultado o software de análise exibiu o
resultado que pode ser observado na Figura 26.
66
Figura 26 - Escaneamento do servidor WEB com N-Stealth
Ao final do escaneamento o software em questão cria um relatório em formato HTML do
servidor analisado. Os resultados são mostrados de forma detalhada e obtendo dados
importantes sobre os sistemas os quais podem ser utilizados por invasores para ataques
específicos.
Em seu relatório o N-Sealth é capaz de buscar e encontrar o Nome da Máquina e as
vulnerabilidades que essa possa vir a possuir. Neste caso, foram encontradas 03 exposições
em HTTP. Além disso, pode rastrear o caminho onde se encontra a página controladora,
conhecida como servlet, e que, se comprometida, pode derrubar o serviço WEB.
Pode identificar também que o servidor em questão é IIS (Internet Information Services), da
Microsoft, fato este que concede ao atacante grande vantagem uma vez que pode direcionar os
ataques para este serviço.
Porém todos os serviços são apenas uma simulação e qualquer tipo de ataque não
comprometerá a máquina. Toda a análise gerada neste documento HTML pode ser observada
na Figura 27.
67
Figura 27 - Relatório N-Stealth
O acesso ao servidor WEB também foi realizado via browser enviando uma solicitação
através do endereço http://192.168.1.1, e como pode ser notado na Figura 28 o servidor
retorna para o browser falha na autorização de acesso, erro 401.
Figura 28 - Acesso ao servidor WEB via browser
Com o BackOfficer, também foi testado o serviço de FTP e como ferramenta de testes de
conexão foi usado o LeechFTP, porém como o honeypot em questão não possui opções de
68
configuração não foi possível a listagem de pastas, ou acesso a diretórios como pode ser visto
na Figura 29.
Figura 29 - Tentativa de acesso via FTP
Com a tentativa de acesso é possível notar que o honeypot consegue identificar o pedido de
conexão via FTP, porém não há a interação com o invasor, simplesmente há a resposta de
serviço indisponível por parte do servidor, retornando ao usuário o erro 503.
5.2.3.
Log
Os logs gerados em relação ao Valhala, apresentam um formato mais completo onde aparece
o dia da semana, o mês, dia do mês, o horário, o serviço acessado, a ação realizada o IP e as
informações enviadas. O exemplo de log pode ser visto abaixo:
Wed Nov 10 20:14:59 Telnet connection from 192.168.1.10
Wed Nov 10 20:15:06
Telnet login attempted from 192.168.1.10: user: root, password:
1234
Wed Nov 10 20:15:21
1234
Telnet login attempted from 192.168.1.10: user: aluno, password:
69
5.3. LaBrea Tarpit
Este é um honeypot que é capaz de assumir novos endereços IP em uma rede. Seu trabalho é
voltado para observação de requisições ARP, monitorando-as. Ele também é capaz de aceitar
conexões.
5.3.1.
Configurações
Sua operação na plataforma Windows, trata-se de apenas um executável, que está na versão
2.5. Porém para o seu funcionamento é necessário o uso de bibliotecas como o winpcap e
libdnet. Atualizadas e instaladas no Windows Server 2003. O Labrea foi desenvolvido para a
versão 3.2 do WinPcap, porém a versão encontra internet é somente a 4.1.2.
Sendo assim, mesmo instalados todos os requisitos descritos em seu arquivo INSTALL e na
sua documentação não foi possível iniciar o serviço do LaBrea e emular todos os seus
serviços e o erro que este apresentou pode ser observado na Figura 30.
Figura 30 - Erros no LaBrea
Sua implementação no Linux também passou pelos mesmos problemas. Sua instalação pode
ser realizada através do repositório do Debian digitando o seguinte comando:
#apt-get install labrea
70
Ele instalará todos os pacotes necessários para o seu funcionamento de acordo com o seu
manual. Porém este não consegue funcionar, capturar pacotes e gerar logs, mesmo com as
configurações realizadas no arquivo LaBrea.cfg.
O segundo passo que pode ser realizado é a instalação passo a passo, primeiramente
descompactando os arquivos, que podem ser obtidos via FTP. Antes de executar o arquivo de
configuração é necessário verificar se a máquina possui um compilador C/C++ instalado, caso
não tenha instale-o, caso contrário o erro da Figura 31 será exibido.
Figura 31 - Erro ao instalar o LaBrea
Porém o libdnet não consegue ser localizado quando arquivo “Configure” é executado. E a
mensagem emitida pela compilação pode ser observada na Figura 32.
71
Figura 32 - Erro LaBrea
Já quando instalado no Windows o LaBrea solicita toda vez que instalado, a leitura do arquivo
INSTALL, mesmo com o WinPcap 4.0.2, instalado versão que está disponível para download,
lembrando que este honeypot foi desenvolvido para a versão 3.1. A máquina Windows Server
também possui a versão 2.4 do libdnet, também requesito para o seu funcionamento, porém
este honeypot foi desenvolvido para a versão 1.7 deste. O erro pode ser visto na Figura 33.
Figura 33 - Erro ao executar o LaBrea no Windows Server 2003
5.3.2.
Testes
Não foram realizados testes uma vez que o sistema não pôde ser corretamente inicializado.
72
Last_WORKING_DIR= “/dtk”
Last_WHICH_PERL= “/usr/bin/perl”
Last_WHICH_PERL_LIB= “/usr/lib/perl5”
Last_HOST_NAME= “awph”
Last_NEW_OS= “Linux”
Last_FAKE_OS= “NT”
Last_LOG_COMPRESSED= “2”
Last_MAX_LENGTH= “200”
Last_TIME_OUT= “20”
Last_MAX_LOOP= “20”
Last_EMAIL_TO= “awph@awph”
Last_Password= “!0”
Last_TBPKEY= “fhuiasdhiasnxkjsadhsad”
O quadro acima representa a configuração realizada no Labrea a fim de definir os diretórios e
emular os servidores de testes.
5.3.3.
Log
O log gerado está a partir de sua execução não obteve nenhuma gravação de dados.
5.4. Deception Toolkit
Este é um honeypot que é capaz de simular vulnerabilidades no sistema. Sendo capaz ainda de
receber solicitações e enviar respostas ao invasor.
5.4.1.
Configurações
Para a instalação do Deception, primeiro foi feito o seu download através do comando:
#wget http://all.net/dtk/dtk.tar (use sempre caixas de texto)
73
Seguindo assim para sua instalação, primeiro deve-se executar o comando “./Configure”. Ao
executar tal comando a compilação retorna um erro. Quando analisado o código foi
identificado um erro de sintaxe. E na linha a qual está “.dtk.config” existe um erro de sintaxe.
Sendo assim código correto é “./dtk.config”.
Com tal procedimento é possível compilar e instalar o sistema corretamente e escolher as
configurações de preferência do usuário. Para este trabalho foram adotadas as seguintes linhas
de configuração, que pode ser acessada em “/dtk/dtk.config”:
No arquivo “/etc/hosts” foi verificada a existência das configurações das portas 110, 111, 421
e 10752. Estas que serão usadas nas conexões e no arquivo “/etc/hosts.allow” foram
adicionados as seguintes linhas:
##REAL SERVICES
ftpd:
all
httpd:
all
##DECEPTION SERVICES
in.pop3d: all: twist /dtk/Generic.pl %a 110 %u %d unknown
in.wrapd: all: twist /dtk/Generic.pl %a 421 %u %d unknown
att111:
all: twist /dtk/Generic.pl %a 111 %u %d unknown
tomcat:
all: twist /dtk/Generic.pl %a 8080 %u %d unknown
att10752: all: twist /dtk/Generic.pl %a 10752 %u %d unknown
dtk:
5.4.2.
all: twist echo ‘O DTK está rodando’
Testes
Os serviços foram iniciados e constam no log de debug do Debian. Porém quando há a
tentativa de acesso essa não responde a conexão não é estabelecida como pode ser observado
na Figura 34.
74
Figura 34 - Tentativa de Conexão com o Deception Toolkit
Neste caso o Deception está bloqueando as entradas dos serviços, porém não consegue
interagir com o invasor ou capturar dados do mesmo.
5.4.3.
Log
O log gerado a partir de sua execução não obteve nenhuma gravação de dados. Nem mesmo
os bloqueios que este gerou.
5.5. Honeyd
Este software é basicamente um emulador de hosts virtuais simulando diversos sistemas
operacionais diferentes. Neste trabalho as versões testadas foram a 1.5c para Windows e a 1.5
para Linux.
5.5.1.
Configurações
Para sua execução no Microsoft Windows foi necessário instalar o WinPcap e o Packet.dll.
Porém esta última quando adicionada gera um erro em sua execução que pode ser observado
na Figura 35.
75
Figura 35 - Erro ao executar o WinHoneyd
A solução encontrada foi substituir o packet.dll por outra versão mais recente, e quando
realizado um novo teste, outro erro foi encontrado o que também impediu o seu
funcionamento. O novo erro pode ser visualizado na Figura 36.
Figura 36 - Erro ao executar o WinHoneyd
O problema pode ser resolvido instalando a versão 4.0.2 do WinPcap. Porém ao iniciar o
sistema, este emitiu erros que estão presente no arquivo “nmap.print”, as linhas em que
apresentam erros podem ser observadas na Figura 37.
Figura 37 - Erro ao iniciar o WinHoneyd 1.5
No site do projeto do WinHoneyd (http://www.netvigilance.com/winhoneyd), menciona os
erros como não preocupantes e podem ser ignorado, para isso foi removidas no arquivo
“nmap.prints” as linhas referentes aos erros em questão. Isto gerou como resultado a Figura
38.
76
Figura 38 - WinHoneyd em execução
As configurações adicionados no arquivo “honeyd.config” foram as seguintes, mostradas no
quadro abaixo:
create windowsxp-mydoom
set windowsxp-mydoom personality “Microsoft Windows XP Professional SP1"
set windowsxp-mydoom uptime 2314219
set windowsxp-mydoom default tcp action reset
set windowsxp-mydoom default udp action reset
set windowsxp-mydoom default icmp action open
set windowsxp-mydoom uid 32767 gid 32767
add windowsxp-mydoom tcp port 1080 “perl scripts/mydoom.pl -l C:\LOGS\mydoom.log”
add windowsxp-mydoom tcp port 3127 “perl scripts/mydoom.pl -l C:\LOGS\mydoom.log”
add windowsxp-mydoom tcp port 3128 “perl scripts/mydoom.pl -l C:\LOGS\mydoom.log”
add
windowsxp-mydoom
tcp
port
10080
“perl
scripts/mydoom.pl
-l
C:\LOGS\mydoom.log”
bind 192.168.1.20
Já no Linux o Honeyd foi instalado através do repositório do Debian e sua implementação
pode ser realizada com sucesso. Após sua inicialização este passou a monitorar as requisições
77
UDP e TCP de toda a rede 192.168.1.0 na qual o servidor foi configurado, isso pode ser
observado na Figura 39.
Figura 39 - Execução do Honeyd no Debian
Note que todos os endereços requisitados pela rede que esta em análise pode ser capturado e
ainda o honeypot realizou respostas ARP para as máquinas que solicitaram:
Nov 27 16:55:53 aptg honeyd[2295]: arp reply 192.16.8.1.2 is-at 00:60:67:7c:bf
5.5.2.
Testes
Com a máquina previamente configurada e o log sendo gerado, no servidor Windows Server
2003, o passo seguinte a ser realizado foi a tentativa de acesso. Quando o acesso foi disparado
não houve resposta por parte do honeypot.
5.5.3.
Log
78
O log gerado só contém os momentos em que foi iniciado e aquele em que sua execução foi
finalizada, para o Windows. Já no Linux o log pode armazenar todas as solicitações TCP e
UDP da rede em análise, como se pode analisar no quadro a seguir:
Nov 27 16:56:57 aptg named[1903]: error (network unreachable) resolving
‘www.google.com/A/IN’: 2001:500:2f::f#53
Nov 27 16:57:32 aptg honeyd[2295]: arp reply 192.168.1.2 is–at 00:60:97:7c:2e:bf
Nov 27 16:58:27 aptg named[1903]: error (network unreachable) resolving
‘imo.im/A/IN’: 2001:500:1::803f:235#53
Nov 27 17:00:41 aptg named[1903]: error (network unreachable) resolving
‘imo.im/A/IN’: 2001:503:ba3e::2:30#53
5.6. Tiny Honeypot
Este é um honeypot que trabalha respondendo a requisições FTP e TELNET.
5.6.1.
Configurações
A instalação desse honeypot, pode ser realizada via repositório do Debian, através do
comando:
# apt-get install tinyhoneypot
Dessa forma o repositório APT, se encarrega de instalar todas as suas dependências. As
configurações realizadas no “thp.conf” localizada no diretório /etc/thpot, podem ser
conferidas no Anexo B.
Quando iniciando o sistema, este retorna o erro da Figura 40:
79
Figura 40 - Erro ao iniciar o Tiny honeypot
Neste erro o honeypot diz que não pode ler o arquivo de configuração, porém este encontra-se
no local em que a configuração esta pronta para buscá-lo.
5.6.2.
Testes
Não foram realizados testes uma vez que o sistema não pôde ser iniciado.
5.6.3.
Log
Não há log para esse honeypot sendo que sua inicialização não pôde ser realizada.
80
6.
CONSIDERAÇÕES FINAIS
Este trabalho apresentou uma análise comparativa entre os honeypots livres e passíveis de
implementação. Para isso, foi necessária a instalação e testes dos diversos softwares
disponíveis na internet e de ferramentas de acesso. Uma vez que o projeto honeypot tem
adquirido cada vez mais aspectos de serviço de pesquisa do que de implementação para
produção e segurança.
Alguns honeypots apresentaram problemas em sua implementação devida principalmente a
estes serem desenvolvidos para bibliotecas já obsoletas e não serem compatíveis com as atuais
disponíveis. Algumas observações podem ser levantadas em relação aos diferentes honeypots
analisados. Para tanto é necessário analisá-los separadamente e isolando os casos de Windows
e Linux.
6.1. Honeypots Windows
Os honeypots analisados que operam no sistema Microsoft Windows e que possuíram êxito na
sua instalação e configuração apresentaram algumas características semelhantes, com algumas
diferenças de funcionalidades. O Valhala em relação ao BackOfficer Friendly (BOF) possui
mais opções de configurações além de conseguir simular mais serviços.
O BOF não consegue interagir com o usuário, e simplesmente passa a detectar a tentativa de
invasão e recusa a conexão. Mesmo que seja suficiente para capturar dados do atacante, este
não consegue levantar quais as motivações e quais os arquivos que o invasor pretendia
modificar, deletar ou colocar na rede. Além disso, não é possível conhecer quais são os
caminhos trilhados dentro do serviço.
A organização do log se dá de forma diferente, sendo que o Valhala, além de possuir a
vantagem de salvar os logs automaticamente pode enviá-los via email. Já o BOF, em sua
versão gratuita, não possui tais opções, e o log fica restrito ao seu console.
81
6.2. Honeypots Linux
Os honeypots desenvolvidos para Linux sofrem todos o mesmo problema, as bibliotecas as
quais foram desenvolvidos e testados hoje estão obsoletas e o seu código de configuração para
compilação com erros de localização das bibliotecas.
Para a implementação de honeypots para tal ambiente existe a necessidade de sua
reprogramação e análise de seu código fonte para que esta consiga o êxito. Na instalação os
honeypots estavam preparados para encontrar determinada estrutura, e ambiente, mesmo
quando reconfigurados na sua compilação estes ainda apresentaram erros devido aos pacotes
que não são compatíveis.
82
6.3. Tabela de Resultados
Segundo os critérios de avaliações definidos em (SILVA, 2010) foram adotas as seguintes
notas aos honeypots avaliados:
Tabela 7 - Tabela de pontuação final
Critério de
Valhala BOF
avaliação
Win
Honeyd
Honeyd
Labrea
Labrea
Tiny
(Windows) (Linux) Honeypot
Deception
Tookit
Plataforma
4
4
10
10
10
10
4
4
Layout
10
8
6
6
6
6
6
6
Configuração
8
10
6
9
6
6
6
6
Gerenciamento
10
8
0*
8
0*
0*
0*
0*
Confiabilidade
10
10
0*
10
0*
0*
0*
0*
Eficiência do
10
10
0*
6
0*
0*
0*
0*
10
4
4
4
0*
0*
4
4
Rastreamento
10
10
0*
6
0*
0*
0*
0*
Invisibilidade
6
6
0*
10
0*
0*
0*
0*
Realidade
10
6
0*
6
0*
0*
0*
0*
8,8
7,6
2,6
7,5
2,2
2,2
2,0
2,0
Log
Opção de
Entrega
Honeypot
MÉDIA
* Não pode ser avaliado
Dentre os honeypots avaliados, pode-se notar que o Valhala honeypot, obteve a maior nota, e
pode disponibilizar mais recursos que o BackOfficer. Sua implementação além de simples e
eficaz. Deste modo este apresenta-se como ótima solução para servidores que utilizam sistema
Microsoft.
83
6.4. Contribuições
Neste trabalho foi apresentado um comparativo entre o honeypots, partindo dessa análise
pode-se escolher qual a melhor alternativa a ser implementada tendo em vista da necessidade
do usuário ao aplicar na rede em questão.
Além disso, é possível conhecer cada um, entendendo opções de configuração e
funcionalidades disponíveis. Bem como a principal que está diretamente ligada as suas
vantagens, o log. Partindo dessas premissas pretende-se facilitar a escolha do gerente de rede
ou de quem deseje implementar tais ferramentas.
6.4.1.
Publicação
Artigo publicado, com o tema Sistema de Pontuação para avaliação de honeypots. Estudo de
Caso: Valhala, no Anais do 12º Simpósio de Iniciação Científica e Tecnológica. Simpósio
promovido pela Faculdade de Tecnologia de São Paulo.
6.5. Trabalhos Futuros
Os seguintes tópicos são proposições para trabalhos futuros:

Estudo de ferramentas para análise de logs: Com a obtenção de informação necessária
isso pode vir a tomar grandes proporções e os log podem atingir páginas e mais
páginas. Com a utilização de ferramentas de análise de log pode-se otimizar o tempo
aproveitando-se só de informações extremamente necessárias.

Ferramentas honeypots aplicadas no meio corporativo: O sistema honeypot passou a
ter caráter de pesquisa e ser utilizado como ferramenta de trabalho para instituições
como a CERT. No âmbito corporativo este também pode ser utilizado como mais uma
barreira de proteção, uma vez que alguns honeypots podem até freiar completamente
um ataque.

Utilização de honeypots como instrumentos na investigação de crimes virtuais:
Monitorar criminosos através de escutas telefônicas, acompanhamentos de
84
movimentações financeiras são soluções utilizadas atualmente. Com a informatização
o crime também passou a ocorrer na internet e de forma digital, sendo assim o
honeypot pode acompanhar também atividades criminosas realizadas através de
computadores na internet, como o roubo de informações.
85
7.
REFERÊNCIAS BIBLIOGRÁFICAS
BOGO, K C. A história da Internet – Como tudo começou. Disponível em
http://kplus.cosmo.com.br/materia.asp?co=11&rv=Vivencia. Acesso em: 14 nov. 2010.
CERT® Coordination Center Software Engineering Institute Carnegie Mellon University
Pittsburgh. PA 15213-3890 U.S.A. [on-line] Disponível em: http://www.cert.org. Acessado
em 28 mai 2010.
CHAPMAN, D. BRENT; ZWICKY, ELIZABETH, D. Building Internet Firewalls.
O'Reilly Associates, Inc. ed. 1, Setembro 1995.
DRAGON. Intrusion Detection. Disponível em http://www.enterasys.com/ids. Acesso em 18
jun 2010
IMASTERS. Disponível em.
http://imasters.uol.com.br/artigo/4175/forense/introducao_a_computacao_forense/. Acesso
em 25 mar. 2010.
IPNEWS, 90% de ataques são contra aplicações da web. Disponível em
http://www.ipnews.com.br/voip/infra-estrutura/seguranca/09-de-ataques-s-o-contraaplicacoes-da-web.html
ELLERO, T. L. C. e Casian A. M. (2001) “Firewall – Utilizando o Netfilter do Kernel 2.4 +
IPTables”
DAVID
"Del"
ElsonIntrusion
Detection,
Theory
and
Practice.
Disponível
em:
http://www.securityfocus.com/frames/index.html. Acessado em 27 mar 2010
KENT S.; ATKINSON, R. Security Architecture for the Internet Protocol – RFC2401, The
Internet Society, 1998: http://www.ietf.cnri.reston.va.us/rfc/rfc2401.txt
86
LAUREANO, M.; MAZIERO, C.; JAMHOUR E. Detectando Intrusões na Máquina Virtual
User-Mode Linux. 5º FISL. 5º ,2004. Anais do 5º Workshop sobre Software Livre, Porto
Alegre, P. 59-62.
OPEN
SOLARIS.
Disponível
em
http://br.sun.com/practice/software/solaris/opensolaris/index.jsp. Acesso em: 22 jun. 2010.
PATRIOT, Disponível em http://www.whitehouse.gov/omb/legislative_sap_107-1_hr2975-h.
Acesso em 12 de nov 2010.
RNP. Disponível em http://www.rnp.br/backbone/. Acesso em 03 mai. 2010.
ROCHA, LUIS FERNANDO. Honeynet: eficácia no mapeamento das ameaças virtuais.
Módulo Security Magazine. [on-line]. Disponível na Internet via www
url:http://www.modulo.com.br/index.jsp?page=3&catid=7&objid=2056&pagenumber=0&id
iom=0 Acesso em 5 de jun de 2010.
SASHA;
LIFELINE.
Distributed
tools,
Phrack
magazine,
2000,
v.10,
n.56
http://www.phrack.com/search.phtml?view&article=p56-12
SASHA; BEETLE. A strict anomoly detection model for ids, Phrack magazine, 2000, v.10,
n.56 http://www.phrack.com/search.phtml?view&article=p56-12
SERASA. Disponível em http://www.serasaexperian.com.br/guiainternet/51.htm. Acesso em:
18 mai. 2010.
SHADOW Indications Technical Analysis Coordinated Attacks and Probes, Naval Surface
Warfare
Center
Dahlgren
Division,
14
de
dezembro
de
1998,
http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt
SILVA, A. W. B.; SILVA, P. H. de M.; DANTAS, M. da S. Sistema de Pontuação para
avaliação de honeypots. Estudo de Caso: Valhala. Faculdade de Tecnologia de São Paulo,12.
2010, São Paulo. Anais do 12º Simpósio de Iniciação Científica e Tecnológica, São Paulo.
Faculdade de Tecnologia de São Paulo, 2010. p. 55.
87
SPTIZNER, LANCE. Passive Fingerprinting. [on-line]. Disponível na Internet via www
url:http://www.securityfocus.com. Acesso em 11 de nov de 2010.
TANENBAUM, S. A. (2003). Redes de Computadores. Tradução da 4ª Edição. Elsevier.
Editora Ltda Rio de Janeiro.
TRACKING
HACKERS.
Disponível
em
http://www.tracking-
hackers.com/papers/honeypots.html. Acesso em: 28 mai. 2010.
ULBRICH, H. C; VALLE, J. D. Universidade Hacker. 6 ª Edição. Editora Digerati Books,
2009
UBUNTU-br. Disponível em http://www.ubuntubrasil.org/ubuntu. Acesso em: 14 abr. 2010.
UFSC. Disponível em
http://www.buscalegis.ufsc.br/revistas/index.php/buscalegis/article/viewFile/5836/5405.
Acesso em: 19 mar. 2010.
VIANNA, W. da S. Segurança em Redes. 2003 CEFET, Disponível em www.professor
.cefetcampos.br/wvianna/segurança-de-redes Acesso em 16 de Nov 2010.
WIKIPÉDIA. Disponível em http://pt.wikipedia.org/wiki/OpenSolaris. Acesso em: 22 jun.
2010.
WIKIPÉDIA. Disponível em http://pt.wikipedia.org/wiki/Windows_7. Acesso em: 10 jun.
2010.
WIKIPÉDIA. Disponível em http://pt.wikipedia.org/wiki/Windows_XP. Acesso em: 08
jun.2010.
WIKIPÉDIA.
Disponível
em
http://pt.wikipedia.org/wiki/Instituto_Nacional_de_Criminalística. Acesso em: 21 mai. 2010.
88
WINHONEYD. Disponível em http://www.netvigilance.com/winhoneyd. Acesso em 09 de
novembro 2010
89
ANEXO A – Log Valhala
Log Valhala
(10:47:20)
O
IP
192.168.1.10
tentou
invasão
por
web
(GET
web
(GET
web
(GET
web
(GET
//cgi/aaaaaa/../class/./mysql.class)
(10:47:20) O IP 192.168.1.10 tentou invasão por web (Conexão )
(10:47:21)
O
IP
192.168.1.10
tentou
invasão
por
//cgi/aaaaaa/../classified.cgi)
(10:47:21) O IP 192.168.1.10 tentou invasão por web (Conexão )
(10:47:21)
O
IP
192.168.1.10
tentou
invasão
por
//cgi/aaaaaa/../classifieds)
(10:47:21) O IP 192.168.1.10 tentou invasão por web (Conexão )
(10:47:21)
O
IP
192.168.1.10
tentou
invasão
por
//cgi/aaaaaa/../classifieds.cgi)
(10:50:10) O IP 192.168.1.10 tentou invasão por PF FTP (Conexao (21))
(10:58:15) O IP 192.168.1.10 tentou invasão por PF FTP (Conexao (21))
(11:01:27) O IP 192.168.1.10 tentou invasão por PF TCP1 (Desconexão)
(11:01:44) O IP 192.168.1.10 tentou invasão por PF FTP (Conexao (21))
(11:03:22) O IP 192.168.1.10 tentou invasão por PF TCP1 (Desconexão)
(11:03:56) O IP 192.168.1.10 tentou invasão por PF FTP (Conexao (21))
(11:08:40) O IP 192.168.1.10 tentou invasão por PF TCP1 (Desconexão)
(11:08:50) O IP 192.168.1.10 tentou invasão por telnet (conexão)
(11:08:55) O IP 192.168.1.10 tentou invasão por telnet (USUÁRIO aluno)
(11:08:57) O IP 192.168.1.10 tentou invasão por telnet (SENHA 1234[6~)
(11:09:13) O IP 192.168.1.10 tentou invasão por telnet (USUÁRIO )
(11:09:14) O IP 192.168.1.10 tentou invasão por telnet (SENHA )
(11:09:14) O IP 192.168.1.10 tentou invasão por telnet (USUÁRIO )
(11:09:15) O IP 192.168.1.10 tentou invasão por telnet (SENHA )
(11:10:59) O IP 192.168.1.10 tentou invasão por ftp (conexão)
(11:11:52) O IP 192.168.1.10 tentou invasão por ftp (ALUNOO )
(11:11:56) O IP 192.168.1.10 tentou invasão por ftp (IR )
(11:11:59) O IP 192.168.1.10 tentou invasão por ftp (DOR )
(11:12:02) O IP 192.168.1.10 tentou invasão por ftp (DIT r)
(11:12:04) O IP 192.168.1.10 tentou invasão por ftp (DIR )
(11:12:07) O IP 192.168.1.10 tentou invasão por ftp (LS )
(11:12:09) O IP 192.168.1.10 tentou invasão por ftp (EXIT )
(11:12:10) O IP 192.168.1.10 tentou invasão por ftp (QUIT )
(11:12:10) O IP 192.168.1.10 tentou invasão por ftp (desconexão)
(11:12:19) O IP 192.168.1.10 tentou invasão por ftp (conexão)
90
(11:12:36) O IP 192.168.1.10 tentou invasão por ftp ( [A[A[Bquit)
(11:12:40) O IP 192.168.1.10 tentou invasão por ftp (QUIT )
(11:12:40) O IP 192.168.1.10 tentou invasão por ftp (desconexão)
(11:16:15) O IP 192.168.1.10 tentou invasão por finger ( @192.168.1.1)
(11:21:00) O IP 192.168.1.10 tentou invasão por web (Conexão )
(11:24:47) O IP 192.168.1.10 tentou invasão por telnet (conexão)
(11:24:51) O IP 192.168.1.10 tentou invasão por telnet (USUÁRIO aluno)
(11:24:53) O IP 192.168.1.10 tentou invasão por telnet (SENHA 1234)
(11:24:55) O IP 192.168.1.10 tentou invasão por telnet (dir )
(11:25:00) O IP 192.168.1.10 tentou invasão por telnet (cd arquivos )
(11:25:08) O IP 192.168.1.10 tentou invasão por telnet (cd.. )
(11:25:20) O IP 192.168.1.10 tentou invasão por telnet (cd backup )
(11:25:34) O IP 192.168.1.10 tentou invasão por telnet ([A[A[B )
(11:27:43) O IP 192.168.1.10 tentou invasão por telnet (quit )
(11:27:54) O IP 192.168.1.10 tentou invasão por telnet (exit )
(11:30:07) O IP 192.168.1.10 tentou invasão por smtp (conexão)
(11:42:56) O IP 192.168.1.10 tentou invasão por pop3 (conexão)
(22:41:59) O IP 192.168.1.10 tentou invasão por ftp (conexão)
(22:41:59) O IP 192.168.1.10 tentou invasão por ftp (USUÁRIO alexandre)
(22:41:59) O IP 192.168.1.10 tentou invasão por ftp (SENHA 310387)
(22:42:04) O IP 192.168.1.10 tentou invasão por ftp (desconexão)
(22:42:05) O IP 192.168.1.10 tentou invasão por ftp (conexão)
(22:42:05) O IP 192.168.1.10 tentou invasão por ftp (USUÁRIO alexandre)
(22:42:05) O IP 192.168.1.10 tentou invasão por ftp (SENHA 310387)
(22:42:07) O IP 192.168.1.10 tentou invasão por ftp (desconexão)
(22:43:19) O IP 192.168.1.10 tentou invasão por ftp (conexão)
(22:43:20) O IP 192.168.1.10 tentou invasão por ftp (USUÁRIO aluno)
(22:43:20) O IP 192.168.1.10 tentou invasão por ftp (SENHA 1234)
(22:43:20) O IP 192.168.1.10 tentou invasão por ftp (REST 1)
(22:43:20) O IP 192.168.1.10 tentou invasão por ftp (REST 0)
(22:43:20) O IP 192.168.1.10 tentou invasão por ftp (SYST )
(22:43:21) O IP 192.168.1.10 tentou invasão por ftp (PWD )
(22:43:21)
O
IP
192.168.1.10
tentou
invasão
por
192,168,1,10,19,137)
(22:43:21) O IP 192.168.1.10 tentou invasão por ftp (ASCII)
(22:43:21) O IP 192.168.1.10 tentou invasão por ftp (LISTAR )
(22:44:23) O IP 192.168.1.10 tentou invasão por ftp (NOOP )
(22:45:24) O IP 192.168.1.10 tentou invasão por ftp (NOOP
ftp
(PORT
91
ANEXO B
Configuração thpot
# Interface to listen on
$intf = "eth0;
# Session timeout - wouldja believe that some systems
# just don't cleanup stale sockets?
$timeout = "300"; # seconds
# Hostname to use in responses:
$hostname = "awph";
# ip address to state for incoming connections, ie: ftp data channel
# NOTE: if commented out, thp will try to determine it from the
# interface specified above. This will fail if thp user (nobody, by
default)
# doesn't have permission to read /proc/net/dev
#$thpaddr = "127.0.0.1";
$thpaddr = "192.168.1.2";
# Domain name to use in responses:
$domain = "localdomain";
# location of thp scripts, libs, etc.
$thpdir = "/usr/share/thpot";
# Directory for all logging.
$logdir = "/var/log/thpot";
# Specific
$logfile =
# Specific
$errfile =
Should be mode 0700 nobody:nobody
name for the master logfile.
"$logdir/captures";
name for errors
"$logdir/errors";
# Log format - "single" or "multi". Single line format is easier to parse,
but
# does not make any entry into the capture log until the session is
complete.
# Multiline gives you separate "start" & "end" lines, but is a pain in the
toches
# to do anything with.
$logtype = "multi";
# Program to run to generate the shell MOTD. I like fortune.
#$greetbin = "/usr/games/fortune";
$greetbin = "/bin/false";
# The home directory of the virtual root user
$homedir = "/etc";
# If a shell prompt is to be returned, here ye go. NOTE: this may be
# changed later as the intruder changes working directory.
$prompt = "[root\@$hostname root]# ";
# ftp Server version choices (edit them if you like)
92
my @fver;
$fver[1] =
$fver[2] =
$fver[3] =
$fver[4] =
$fver[5] =
$fver[6] =
$fver[7] =
$fver[8] =
"FTP Server (Version wu-2.6.0(1))";
"FTP Server (Version wu-2.6.1(2))";
"FTP Server (Version wu-2.6.1-16)";
"FTP Server (BSDI Version 7.00LS)";
"FTP Server (PFTP 0.13)";
"NcFTPd Server";
"Microsoft FTP Service (Version 5.0)";
"Microsoft FTP Service (Version 4.0)";
# ftp version to emulate:
$ftpver = $fver[int(rand(@fver-1))+1];
# Should we allow ftp data connections?
# 0 = no
# 1 = yes
$allowftpdata = "1";
# Do you want to specify a port for passive (PASV) ftp data transfer?
# Leave this commented out if you prefer thp to select a random port. If
you
# choose a specific port here, it is a great idea to un-disable
xinetd.d/thp.pasv
# and edit it listen on that port.
$pasvport = 33701;
# the http vendor is emulated via selecting the appropriate directory of
responses
#$httpdvend = "Microsoft-IIS";
$httpdvend = "Apache";
# http version is reported in headers, responses, etc. and SHOULD be a
sensible
# match with the $httpdvend. If your Server reports itself as IIS/1.3.9,
that
# might raise an eyebrow.
#$httpdver = "5.0";
#$httpdver = "6.0";
$httpdver = "1.3.9";
#$httpdver = "1.3.19";
# sshd version to emulate:
my @sver;
$sver[1] = "SSH-1.5-1.2.26";
$sver[2] = "SSH-1.5-1.2.27";
$sver[3] = "SSH-2.0-OpenSSH_3.4p1";
$sshver = $sver[int(rand(@sver-1))+1];
#smtp version to emulate
my @smver;
$smver[1] ="ESMTP Sendmail 8.12.2/8.12.2/SuSE Linux 0.6;";
$smver[2] ="ESMTP Exim 3.12 #1";
$smver[3] ="ESMTP Sendmail 8.9.3/8.9.3/Debian 8.9.3-21;";
$smver[4] ="ESMTP Server (Microsoft Exchange Internet Mail Service
5.5.2653.13)";
$smver[5] ="ESMTP Sendmail 8.11.6/8.11.6;";
$smtpver = $smver[int(rand(@smver-1)) + 1];
93
# If an attacker is looking for Windows files specifically, should thp
accommodate
# them, even if your $httpdvend (above) is something else?
$chameleon = "yes";
# If you do wish to be a chameleon, what should your fake version be?
$chamelver = "5.0";