Universidade Católica de Brasília

Pró-Reitoria de Pós-Graduação e Pesquisa

Coordenação de Pós-Graduação em Lato Sensu em Informática

PROJETO FINAL DE PÓS GRADUAÇÃO DE LATO SENSU EM

INFORMÁTICA NA
ESPECIALIDADE DE SEGURANÇA EM REDES DE COMPUTADORES

Título: HONEYNETS

Autor
Laerte Peotta de Melo
peotta@bb.com.br

Orientado Por: Jerônimo Jardim

Brasília, DF – Brasil
Junho de 2004
Laerte Peotta de Melo
peotta@bb.com.br

HONEYNETS

MONOGRAFIA SUBMETIDA AO CORPO DOCENTE DO PROGRA-

MA DE PÓS-GRADUAÇÃO EM INFORMÁTICA DA UNIVERSIDA-
DE CATÓLICA DE BRASÍLIA COMO PARTE DOS REQUISITOS
NECESSÁRIOS PARA OBTENÇÃO DO TÍTULO DE PÓS GRADU-
AÇÃO EM LATO SENSO EM INFORMÁTICA NA ESPECIALIDADE
DE SEGURANÇA EM REDES DE COMPUTADORES.
Orientador: Prof. Jerônimo Jardim

Brasília, DF – Brasil
Junho de 2004
 TERMO DE APROVAÇÃO

Monografia defendida e aprovada como requisito parcial para obtenção de Pós-Graduação para o
curso de Segurança em Redes, defendida e aprovada, em junho de 2004, pela banca examinadora consti-
tuída por:

_____________________________________________________________
Presidente

_____________________________________________________________
Orientador - Prof. Jerônimo Jardim

_____________________________________________________________

Brasília, DF – Brasil
Junho de 2004
“ A arte da guerra se baseia no engano. Portanto, quando és capaz de ata-
car, deves aparentar incapacidade e, quando as tropas se movem, aparen-
tar inatividade. Se estás perto do inimigo, deves fazê-lo crer que estás lon-
ge; se longe, aparentar que se estás perto. Colocar iscas para atrair o inimi-
go.”

-- Sun Tzu, filósofo e general chinês, 400 a.C.

 RESUMO

Hoje em dia, cada vez mais a segurança da informação está se tornando mais importante.

Existem vários modos de se deixar uma rede segura, seja através de dispositivos de hardware, ou de

software, tais como topologias de firewall, detectores de invasão e listas de permissões, mas

nenhum ainda é totalmente segura. O conceito de Honeynet pode ser uma forma de se estar um

passo a frente dos atacantes. As Honeynets são redes totalmente monitoradas montadas

especificamente para estudos de ataques conhecidos ou não, e com várias metodologias para coletar

e tratar informações sobre ataques sofridos. Com o grande crescimento de atividades na Internet, é

imprescindível que existam maneiras além da defesa, o que a maioria dos sistemas hoje em dia está

apto a fazer. A possibilidade de se antever a um ataque e gerar uma estratégia de defesa é um dos

pontos fortes de uma Honeynet. Neste trabalho estaremos demonstrando a eficácia de uma

Honeynet e como funciona um Honeypot. Serão demonstradas duas topologias de rede para

implantação de uma Honeynet, onde serão estudados os resultados obtidos com as análises de nossa

monitoração acerca dos vários tipos de ataques sofridos, entre eles, ataques de spam, worms,

tentativas de se obter acesso, entre outros. Também discutiremos algumas questões sobre a

legalidade da utilização desse tipo de rede, bem como a metodologia para que nossa própria rede

não seja usada como ponto de partida para outros ataques mais elaborados à outras redes.
 ABSTRACT

Nowadays, information security is becoming more and more important. There are many ways to

make a network secure, be it through hardware devices, or software, such as different firewall

topologies, intrusion detectors and acess lists, but none is completely safe. The concept of a Honeynet

can be a form of being one step ahead from the attackers. The Honeynets are completely monitored

networks built specifically to study attacks, known or not, with various methods to collect and process

information about attacks received. With the major growth of activities on the Internet, it's imperative

that there are ways beyond defense, something that most current systems are already able to do. The

possibility of detecting an attack before it happens and being able to create a proper defense strategy is

one of the biggest advantages of a Honeynet. In this paper, we will be demonstrating the efficiency of a

Honeynet and how a Honeypot works. Two proposed network topologies for implementing a Honeynet

will be demonstrated, and the results obtained with the analysis of the collected data will be studied,

revealing the various types of attacks received, from spam attacks, worms, to unauthorized access

attempts, among others. We will also discuss some questions about the legality of using such a

network, as well as the methodology used to avoid our own network being used as a trampolien for

other more elaborate attacks to other networks.

 Sumário
RESUMO................................................................................................................................................................................... 5

ABSTRACT............................................................................................................................................................................... 6

INTRODUÇÃO......................................................................................................................................................................... 9

1. HISTÓRIA............................................................................................................................................................................. 9

2. TIPOS DE HONEYPOTS.................................................................................................................................................. 10
2.1 HONEYPOTS DE BAIXA INTERAÇÃO (LOW-INTERACTION HONEYPOTS).........................................................................................10
2.2 HONEYPOTS DE ALTA INTERAÇÃO (HIGH-INTERACTION HONEYPOTS)......................................................................................... 11
2.3 TOPOLOGIA DE UM HONEYPOT BÁSICO.................................................................................................................................... 12
3 FERRAMENTAS PARA HONEYPOTS........................................................................................................................... 12
3.1 DECEPTION TOOLKIT – DTK............................................................................................................................................... 13
3.2 CYBERCOP STING................................................................................................................................................................13
3.3 RECOURSE MANTRAP.......................................................................................................................................................... 14
3.4 HONEYPERL....................................................................................................................................................................... 14
3.4.1 FakeSquid...............................................................................................................................................................14
3.4.2 FakeHTTP.............................................................................................................................................................. 15
3.4.3 FakeTelnet..............................................................................................................................................................15
3.4.4 FakeSMTP..............................................................................................................................................................16
3.5 HONEYD............................................................................................................................................................................16
3.6 RESUMO DAS FERRAMENTAS.................................................................................................................................................16
4 HONEYNETS.......................................................................................................................................................................17
4.1 TOPOLOGIA DE UMA HONEYNET BÁSICA ................................................................................................................................. 18
5 ANÁLISE FORENSE.......................................................................................................................................................... 19
5.1 ANÁLISE FORENSE VOLTADA A HONEYPOTS............................................................................................................................ 20
5.2 FERRAMENTAS UTILIZADAS PARA ANÁLISE FORENSE...................................................................................................................23
5.2.1 The Coroner´s Toolkit (TCT)................................................................................................................................. 23
5.2.2 Grave-robber..........................................................................................................................................................24
5.2.3 Mactime.................................................................................................................................................................. 26
5.2.4 Utilitários............................................................................................................................................................... 26
5.2.5 Unrm e Lazarus...................................................................................................................................................... 27
5.2.6 EnCase................................................................................................................................................................... 29
5.3 LEGALIDADE DE UM HONEYPOT............................................................................................................................................ 30
6 CRIANDO UMA HONEYNET.......................................................................................................................................... 33
6.1 A ARQUITETURA DE UMA HONEYNET...................................................................................................................................... 34
6.1.1 Topologia Ideal...................................................................................................................................................... 34
6.1.2 Topologia utilizada em laboratório ...................................................................................................................... 36
TOPOLOGIA DE LABORATÓRIO.................................................................................................................................... 37

7. COMPONENTES DE SEGURANÇA DO HONEYPOT................................................................................................ 38

7.1 IDS..................................................................................................................................................................................38
7.1.1 Classificação de ataques........................................................................................................................................40
7.1.2 Dificuldades Relacionadas ao IDS........................................................................................................................ 40
7.1.3 Criptografia e o IDS...............................................................................................................................................41
7.1.4 Tipos de IDS........................................................................................................................................................... 41
7.1.5 IDS Snort................................................................................................................................................................ 42
7.1.6 Utilização do IDS Snort com a Honeynet.............................................................................................................. 43
 7.2 FIREWALL.......................................................................................................................................................................... 44
7.2.1 IPTables Log Analyzer .......................................................................................................................................... 45
7.2.3 Regras do Firewall.................................................................................................................................................47
7.3 HOGWASH..........................................................................................................................................................................48
7.4 KEYSTROKE....................................................................................................................................................................... 49
7.5 SEBEK...............................................................................................................................................................................50
.................................................................................................................................................................................................. 50

8 APLICAÇÃO: DETECÇÃO DE SPAMMERS COM UM HONEYPOT...................................................................... 51

8.1 O QUE É SPAM?.................................................................................................................................................................. 51
8.2 COMO OS ENDEREÇOS SÃO COLETADOS................................................................................................................................... 51
8.3 COLETA DE ENDEREÇOS EM MASSA.........................................................................................................................................52
8.4 PROXIES ABERTOS............................................................................................................................................................... 52
8.5 RELAYS ABERTOS................................................................................................................................................................ 54
8.6 HONEYPOTS E TÉCNICAS DE COLETA DE ENDEREÇOS..................................................................................................................55
8.7 HONEYPOTS E PROXIES ABERTOS............................................................................................................................................56
9 IMPLEMENTAÇÃO........................................................................................................................................................... 59
9.1 DADOS ESTATÍSTICOS – ANALISANDO VÁRIOS TIPOS DE LOGS.....................................................................................................59
9.1.1 LIRE – Log in Report............................................................................................................................................. 59
9.1.2 SnortALog (Snort Analyser Logs).......................................................................................................................... 61
9.2 DETECTANDO ASSINATURAS DOS SISTEMAS OPERACIONAIS.......................................................................................................... 62
9.2.1 Active FingerPrinting.............................................................................................................................................63
9.2.2 Passive FingerPrinting.......................................................................................................................................... 63
9.3 DETECTANDO SISTEMAS OPERACIONAIS EM UM HONEYPOT......................................................................................................... 64
9.4 ANÁLISE DO IDS................................................................................................................................................................66
9.4.1 Análise de Logs do IDS.......................................................................................................................................... 69
9.5 ANÁLISE DO PROXYPOT.......................................................................................................................................................70
9.5.1 Análise dos logs do proxypot................................................................................................................................. 74
9.5.2 Técnicas utilizadas pelos spammers...................................................................................................................... 77
9.5.3 Dados estatísticos do ProxyPot..............................................................................................................................80
9.5.3.1 Número de Mensagens por Classe C................................................................................................................................ 81
9.5.3.2 Bytes por Classe C........................................................................................................................................................... 82
9.5.3.3 Número de Mensagens por País....................................................................................................................................... 83
9.5.3.4 Bytes por País.................................................................................................................................................................. 84
9.5.3.5 Número de Mensagens por IP.......................................................................................................................................... 85
9.5.3.6 Bytes por IP..................................................................................................................................................................... 86
9.5.3.7 Destinatários por IP......................................................................................................................................................... 87
9.5.3.8 Referências por endereço................................................................................................................................................. 88
9.5.3.9 Bytes Enviados por Endereço.......................................................................................................................................... 89
9.5.3.10 Destinatários x Endereços.............................................................................................................................................. 91
9.6 ANÁLISE DOS DADOS DO SNORT.........................................................................................................................................93
9.6.1 Utilização de Protocolos........................................................................................................................................94
9.6.2 Severidade dos ataques.......................................................................................................................................... 95
9.6.3 Detalhamento de ataques por hora........................................................................................................................95
9.6.4 Detalhamento de ataques por dia.......................................................................................................................... 96
9.6.5 Portas mais atacadas............................................................................................................................................. 97
CONCLUSÃO......................................................................................................................................................................... 98

REFERÊNCIAS BIBLIOGRÁFICAS................................................................................................................................ 100

ANEXOS................................................................................................................................................................................ 102
ANEXO 1: PATCH DE MONITORAÇÃO PARA O BASH................................................................................................................102
ANEXO 2: CONFIGURACAO DO IPTABLES PARA HONEYNET.......................................................................................................104
INTRODUÇÃO

Honeynets são redes de computadores constituídas de ferramentas para estudos e

documentação de atividades ilícitas ou suspeitas. Essas redes tem um propósito exclusivo:

Ser comprometida por um invasor a fim de se estudar técnicas utilizadas e métodos de invasão.

Honeypots (literalmente, “potes de mel”), são recursos de segurança preparado

especificamente para ser sondado, atacado ou comprometido, onde todas as atividades são

registradas para estudos e análises.

1. História

Em 1988 surge a primeira referência a redes feitas exclusivamente para estudos de

atividades suspeitas, Clifford Stoll [1] introduziu e publicou a história sobre a invasão sofrida

nos sistemas da LBL (Lawrence Berkeley Laboratory). Onde ao contrário de expulsar o invasor

ele decidiu estudar as atividades dos chamados “Black Hats”, ou atacantes, com o intuito de

registrar seus passos e rastrear sua origem. Este estudo levou cerca de um ano e revelou bem

mais que somente a origem do invasor, revelando outros aspectos tais como os motivos dos

ataques, e quais eram as redes que eram mais interessantes para os atacantes.

Bill Cheswick [2] em 1992, publicou o artigo “An Evening With Berferd in Which a

Cracker is Lured, Endured, And Studied” (Uma Noite com Berferd em que um Cracker é

Atraído, Suportado e Estudado), descrevendo um estudo de caso sobre um atacante que obteve

acesso aos sistemas da AT&T, que foi projetado apenas para ser comprometido. Steven Bellovin

Honeynets 9
[3] também participou do projeto, onde desenvolveu ferramentas que foram utilizadas para

armadilhas e captura de ações.

Fred Cohen, em 1998 desenvolveu o Deception Toolkit (DTK, ou “Kit de Decepção”)1

[4]. Esta foi a primeira ferramenta open-source (de código aberto) feita com o objetivo de

enganar os atacantes. Uma das qualidades do DTK era a de emular diversas vulnerabilidades e

catalogar todas as informações de um ataque. Neste mesmo ano surge o termo “Honeypot”.

Um grupo de pesquisadores e profissionais de segurança liderados por Lance Spitzer [5]

lança, em 1999, uma Honeynet, iniciando o Honeynet Project [6]: Uma rede projetada

exclusivamente para ser comprometida por ataques, e o conceito Honeynets ganha repercussão

mundial, demonstrando a importância do estudo do comportamento dos invasores de uma rede

para o desenvolvimento de novas ferramentas e sistemas de defesa. Foi a partir deste ponto que

também surgiu a Honeynet Research Alliance2 (Aliança de Pesquisa de Honeynet).

2. Tipos de Honeypots

Podemos dividir um honeypot em duas classes: Honeypots de baixa interação e

Honeypots de alta interação.

2.1 Honeypots de Baixa interação (Low-Interaction Honeypots)

Estes sistemas normalmente apenas emulam serviços de uma rede ou mesmo sistemas

1
http://www.all.net/dtk/index.html
2
http://www.honeynet.org/alliance/

Honeynets 10
operacionais específicos. Nesta classe de Honeypots o atacante não interage com o sistema.

Podem-se emular também, vulnerabilidades específicas já conhecidas para se estudar os motivos

de um ataque, bem como as ferramentas usadas para o comprometimento de um sistema.

Como exemplo de um Honeypot de baixa interação podemos citar o seguinte:

netcat –l –p 80 > /var/log/honeypot.log

O comando acima utiliza o programa “netcat”3, que é um sniffer de rede. Um sniffer dfe

rede é um tipo de programa que se destina a ouvir pacotes em uma rede e capturá-los para

análise posterior. Neste caso, o netcat ficará escutando qualquer tipo de requisição que chegue à

porta 80, que é utilizada normalmente por web servers. Este tipo de Honeypot se torna

interessante quando se deseja capturar informações sobre worms conhecidos e desconhecidos,

bem como anomalias da rede. Vale lembrar que a interação neste tipo de Honeypot é nula.

A grande vantagem desse tipo de Honeypot é a grande segurança que se passa, pois o

serviço em si não está rodando na máquina, ou seja, se baseia na premissa básica de segurança,

onde quanto menos serviços, menos vulnerabilidades.

2.2 Honeypots de alta interação (High-Interaction Honeypots)

São sistemas reais, rodando serviços reais e que permitem que o atacante interaja com o

sistema. Alguns aspectos de segurança são considerado,s evitando um ataque de dentro do

Honeypot para fora, e impedindo que o atacante use o Honeypot como ponte para outro ataque.

Será discutido mais adiante como manter um Honeypot de alta interação sob controle. É bom

3
http://netcat.sourceforge.net/

Honeynets 11
lembrar que neste tipo de Honeypot existem vários riscos reais, e devem-se tomar cuidados

especiais para que não seja usado como trampolim para novos ataques a redes, internas e

também externas.

2.3 Topologia de um honeypot básico

Figura 1: Topologia Básica de um honeypot

3 Ferramentas para Honeypots

Diversas ferramentas surgiram depois do DTK, inclusive muitos produtos comerciais

como o Cybercop Sting4, Netfaçade e o Recourse Mantrap5.

4
http://www.pgp.com/products/cybercop-sting/default.asp
5
http://www.recourse.com

Honeynets 12
3.1 Deception Toolkit – DTK

O Deception Toolkit, normalmente chamado DTK, é uma coleção de scripts que emulam

diversas vulnerabilidades conhecidas. Uma dessas vulnerabilidades é a de Sendmail6, em que

um Sendmail simulado disponibiliza um arquivo de senhas falso. Em seguida, esses scripts são

executados em um sistema hospedeiro. O atacante é ludibriado para usar esse arquivo de senhas

e perder tempo valioso para descobrir senhas que não são reais. Esse toolkit também é excelente

para alertar e aprender sobre vulnerabilidades conhecidas.

Um dos principais objetivos de uma Honeynet é aprender vulnerabilidades

desconhecidas, e o Deception Toolkit limita-se a aprender o que já se conhece.

3.2 Cybercop Sting

Para ambientes que rodam o sistema operacional NT da Microsoft7 o Cybercop Sting

emula toda uma rede, replicando as pilhas IP8 dos diversos sistemas operacionais. No caso de

um atacante varrer a rede, poderá encontrar 15 sistemas disponíveis, cada um deles com seu

endereço IP correspondente, entretanto todos os sistemas operacionais virtuais estão contidos

dentro de um único Honeypot físico, onde praticamente todo o sistema é emulado, desde o IP

que passa pelo sistema operacional e os serviços executados. A grande vantagem é que se pode

replicar toda uma rede rapidamente, permitindo, inclusive, controlar as tendências. Entretanto,

um dos problemas é que os serviços emulados são simples e nem sempre correspondem as

6
www.sendmail.org
7
www.microsoft.com
8
Internet Protocol

Honeynets 13
expectativas do atacante, que pode desconfiar de que está sendo monitorado.

3.3 Recourse Mantrap

O Recourse Mantrap (literalmente, “armadilha-refúgio”) é um produto comercial e sua

funcionalidade se aproxima à de uma Honeynet, entretanto não se replica um sistema

operacional, e sim uma imagem de um sistema dentro de outro. Esse método também é

conhecido como prisão ou gaiola, e tem grandes vantagens, pois um sistema operacional

funcional está sendo executado de maneira totalmente protegida. As novas vulnerabilidades

podem ser aprendidas e o “Black Hat” tem um sistema totalmente operacional e completo com o

qual pode-se interagir após estar comprometido, no entanto fica-se limitado ao que o fabricante

pode fornecer em questão de ambientes de sistemas. Uma das grandes dificuldades em relação

ao produto é que não se tem a possibilidade de limitar a ação do intruso, o qual poderá usar o

sistema para ataques externos.

3.4 Honeyperl

O honeyperl9 (união da palavra “honey”(mel) e “perl”, a linguagem em que foi escrito)

sãp conjuntos de scripts de baixa interação, foi desenvolvido pelo grupo Honeynet-br10, e

basicamente é uma ferramenta que integra vários serviços “fake” ou falsos, como o Squid,

Telnet, HTTP, FTP, SNMP. Foi desenvolvido em Perl, o que possibilita ser executado em

plataformas Linux/Windows. Escrito por Daniel B. Cid, Antônio Marcelo, Adriano Carvalho e

Marcelo Gondim. Atualmente está em fase Release Candidate.

O honeyPerl integra diversos “fakes” descritos abaixo:

9
http://www.honeypot.com.br/files/honeyperl.tar.gz
10
http://www.honeynet.br

Honeynets 14
3.4.1 FakeSquid

Desenvolvido por Antonio Marcelo, o FakeSquid11 é o primeiro projeto de grupo

Honeynet-br. Trata-se de um pequeno servidor escrito em Perl, que responde a conexões Telnet

na porta 3128, ou a qualquer porta à escolha do usuário, simulando um servidor de cache

SQUID, daí o seu nome. Loga as tentativas de conexão com o IP de origem do atacante, data e

hora, e todas as informações de Whois. Alertas em tempo real.

3.4.2 FakeHTTP

12
Desenvolvido por Adriano Carvalho o FakeHttp é o segundo projeto do grupo

Honeynet-Br. Trata-se de um pequeno servidor web escrito em Perl, que responde a conexões

Telnet na porta 80, emulando um servidor web Apache 1.3.27. Loga as tentativas de conexão

com o IP de origem do atacante, data e hora, e todas as informações de Whois. Alertas em

tempo real.

3.4.3 FakeTelnet

Desenvolvido por Daniel B. Cid, o FakeTelnet13 é o terceiro projeto projeto do grupo

Honeynet-Br. Trata-se de um pequeno servidor escrito em Perl, que responde a conexões telnet

na porta 23 e que simula um Telnet server. Loga as tentativas de conexão com o IP de origem do

atacante, data e hora, e os comandos enviados pelo atacante. Alertas em tempo real.

11
http://www.honeypot.com.br/files/fakesquid-0.0.5a.tar.gz
12
http://www.honeypot.com.br/files/httpd-fake.v.0.0.4.tar.gz
13
http://www.honeypot.com.br/files/faketelnet-1.3.tar.gz

Honeynets 15
3.4.4 FakeSMTP

Desenvolvido por Daniel B. Cid, o FakeSMTP14 é o quarto projeto projeto do grupo

Honeynet-Br. Trata-se de um pequeno servidor escrito em Perl, que responde a conexões Telnet

na porta 25 e que simula um servidor de email, como por exemplo: Sendmail, Exchange, entre

outros. Loga as tentativas de conexão com o IP de origem do atacante, data e hora, e comandos

enviados pelo atacante. Alertas em tempo real.

3.5 Honeyd

O Projeto honeyd15 é um Honeypot de baixa interação que simula serviços e redes

através de arp spoofing. Ideal para projetos iniciais, o Honeyd é um pequeno daemon que cria

hosts virtuais em uma rede. Estes hosts podem ser configurados para rodar vários tipos de

serviços e são totalmente personalizados e adaptáveis. Ele permite que um simples host apareça

para um atacante como uma rede complexa com múltiplos endereços.

3.6 Resumo das Ferramentas

A principal desvantagem da maioria das ferramentas para estudos de caso envolvendo

Honeynets é que elas possuem assinaturas, e um atacante mais atento pode perceber que está

sendo monitorado, mudando seus alvos para algo mais ativo.

Todas as soluções tem excelente potencial, mas apenas para requisitos específicos. O

14
http://www.honeypot.com.br/files/fakesmtp-0.2.tar.gz
15
http://niels.xtdnet.nl/honeyd/

Honeynets 16
ideal seria ter um ambiente totalmente flexível em que nada fosse emulado, em que os sistemas

fossem iguais aos encontrados na Internet, e no qual se pudesse capturar a ação dos atacantes.

4 Honeynets

A Honeynet se diferencia de uma solução Honeypot, pois se trata de uma ferramenta de

pesquisa. Sendo uma rede criada especificamente para ser comprometida, pode-se utilizá-la para

aprender sobre as ferramentas, táticas e os motivos da comunidade dos atacantes. As duas

maiores diferenças entre os Honeypots e as Honeynets são:

1. Uma Honeynet não é um sistema único e sim uma rede completa, com vários serviços e

sistemas operacionais rodando. Geralmente essas redes ficam abaixo de um firewall, no

qual os dados são capturados, controlados, recebidos e enviados. As informações

capturadas são analisadas para se adquirir conhecimento com o atacante. Dentro de

uma Honeynet pode-se usar qualquer sistema disponível como: Linux, HPUX, Solaris,

Windows NT, roteadores, etc.

2. Todos os sistemas dentro de uma Honeynet são sistemas padrão, ou seja, são sistemas e

aplicativos reais, nada é emulado, e nada é feito para tornar os sistemas menos seguros.

Os riscos e vulnerabilidades descobertos são os mesmos que existem em organizações

atualmente.

Honeynets 17
4.1 Topologia de uma honeynet básica

Figura 2: Topologia Básica de uma honeynet

Honeynets 18
5 Análise Forense

A forense computacional [9] compreende a aquisição, preservação, identificação,

extração, restauração, análise e documentação de evidências computacionais, quer sejam

componentes físicos ou dados que foram processados eletronicamente e armazenados em mídias

computacionais.

O propósito do exame forense é a procura e extração de evidências relacionadas com o

caso investigado, que permitam a formulação de conclusões acerca da infração.

Existem duas abordagens no que diz respeito ao objetivo final da análise forense. Na

primeira, a análise forense busca obter informação de valor legal (coerente com as regras e leis

das evidências e admissível em uma corte de justiça) a ser utilizada em um processo criminal.

Na segunda abordagem, o exame é realizado dentro de uma corporação com o objetivo de

determinar a causa de um incidente e assegurar que o mesmo não ocorra novamente, sem que

haja preocupação com formalidades legais.

Mesmo que não haja intenção de se instituir um processo criminal, toda investigação

deve considerar como prática padrão a utilização de metodologias e protocolos que garantam

sua possível aceitação em uma corte de justiça. Tratar todo caso com a formalidade de um

processo criminal ajuda a desenvolver bons hábitos de investigação.

Honeynets 19
5.1 Análise Forense voltada a Honeypots

A análise forense permite fazer um detalhamento dos dados, com isso pode se recuperar

processos, os arquivos e as ferramentas usadas pelo atacante, permitindo recriar as atividades de

usuário ou identificar atividades que não tenham sido identificadas por outras análises. A

forense é um processo de examinar o sistema comprometido e voltar passo a passo para saber o

que realmente aconteceu. Geralmente isso exige que se deixe o sistema comprometido off-line

ou que se crie uma cópia do sistema e se analise as imagens.

A primeira etapa da análise forense é a captura de dados. Não se deve usar o sistema

comprometido por dois motivos: Confiança e cópias.

1. O sistema comprometido não é confiável. Os sistemas binários, os arquivos de

configuração e até mesmo o kernel16 do sistema podem ter sido modificados pelo

atacante. Se por acaso fosse usado o sistema comprometido para a análise, muito

provavelmente teríamos informações falsificadas. Após comprometer um sistema, o

atacante geralmente instala rootkits17.

2. Toda a análise deve ser feita em uma cópia, isto garante que se alguma modificação de

dados acidental ocorrer, o original permanecerá intacto.

Desenvolvemos um processo seguro para se fazer cópias dos discos dos honeypots, para

tanto há um impasse técnico, onde os honeypots não podem passar de 2 gigas de tamanho total,

isso porque a maioria dos sistemas de arquivos utilizados em sistemas operacionais Unix

16
Sistema operacional que controla as execuções de hardware e software
17
Altera o funcionamento do sistema operacional permitindo acesso total

Honeynets 20
permitem arquivos com no máximo 2 gigas, embora isto não seja mais verdade em sistemas de

arquivos mais recentes, como o ReiserFS e a JFS. Outra vantagem desse método é que o

honeypot permanece on-line, com isso as atividades do atacante podem continuar a ser

monitoradas sem levantar dúvidas quanto ao sistema.

O primeiro passo é iniciar uma instância do netcat 18 ouvindo em um sistema de

confiança.

nc –l –p 5000 > honeypot.hda1

Neste exemplo o netcat está ouvindo a porta 5000, ele toma a entrada dessa porta e a

salva como um arquivo chamado “honeypot.hda1”.

O segundo passo é iniciar a leitura por um CDROM ou disquete que contenha o utilitário

de cópia chamado “dd”19 (Data Dumper) que faz parte do pacote “fileutils” no linux. O “dd”

geralmente é usado para transferir dados de um arquivo para outro, com a opção de traduzir

formatos de dados instantaneamente, e é usado para obter imagens completas e confiáveis do

ponto de vista pericial. A inicialização pelo CDROM ou disquete se faz necessária pela

confiabilidade do sistema estar comprometida, um atacante poderia com facilidade alterar o

utilitário “dd” com um rootkit.

/cdrom/dd if=/dev/hda1 | nc 192.168.0.4 5000

Nesse exemplo totalmente funcional estamos usando o “dd” para fazer uma cópia da

18
http://freshmeat.net/projects/netcat/
19
http://www.gnu.org/manual/fileutils-4.1/html_chapter/fileutils_6.html#SEC39

Honeynets 21
partição /dev/hda1 e canalizar a sua saída pelo netcat em uma máquina (192.168.0.4) montada

para se fazer exclusivamente análise pericial, mantendo a integridade dos dados e a

confiabilidade da análise.

O terceiro passo é garantir a confiabilidade da imagem gerada através de um utilitário de

hash como o MD5SUM, parte integrante da maioria das distribuições, que implementa o

algoritmo MD5.

Feito isso o quarto e último passo é montar a imagem feita em um sistema separado da

rede e totalmente confiável. Para isso utilizamos um método chamado de “loopback”, pelo qual

as imagens podem ser montadas diretamente no sistema Linux como um dispositivo. Com isso

economizamos uma etapa extra que seria copiar as imagens em uma unidade separada e, em

seguida, montar a unidade.

Uma unidade de partição pode ser montada em um sistema Linux da seguinte maneira:

mount –o loop,ro,node,noexec honeypot.hda1 /mnt/honeypot.hda1

Agora podemos iniciar a análise forense dessa unidade. Um método bastante eficiente

seria usar um utilitário de hash como o MD5SUM antes de colocar o Honeypot em operação, e

quando se fosse fazer uma análise, teria-se facilmente as alterações sendo apontadas em

arquivos.

Quando examinamos um sistema comprometido, nosso objetivo é aprender o máximo

possível, não sendo necessariamente nosso objetivo procurar evidências que possam incriminar

o atacante, apenas aprender. Esta é a grande diferença da análise forense computacional voltada

a obtenção de provas e da análise forense de um Honeypot. Mas a diferença termina aí, já que as

Honeynets 22
técnicas utilizadas para obtenção de informações é a mesma nos dois sistemas forenses.

Outro padrão na criação de uma unidade Honeypot é a limpeza do disco rígido, deve se

atentar que em uma análise forense dados de sistemas anteriores podem conter informações que

com isso dificultam e muitas vezes impossibilitam a análise do sistema comprometido. Uma

solução para isso é utilizar o “dd” para fazer uma varredura e limpeza dos discos. Para tanto

podemos partir do seguinte exemplo:

dd if=/dev/zero of=/dev/hda bs=1000k count=2000

Com o comando acima iremos preencher todos os dados do disco rígido com zeros,

eliminando qualquer traço de arquivo ou sistemas anteriores, facilitando e gerando

confiabilidade dos dados armazenados. Outra alternativa é utilizar o dispositivo especial /

dev/random, que gera números pseudo-randômicos, tornando ainda mais difícil a recuperação

dos dados anteriores.

5.2 Ferramentas utilizadas para análise forense

5.2.1 The Coroner´s Toolkit (TCT)

Para análise de sistemas Unix, uma das melhores ferramentas a usar é o The Coroner´s

Toolkit20, a ferramenta que foi desenvolvida por Dan Farmer e Wietse Venema [7], permitindo

capturar informações que poderiam ser impossíveis de se conseguir. Alguns dos muitos recursos

que a ferramenta dispõem incluem:

20
http://www.porcupine.org/forensics

Honeynets 23
 • Coleta de dados automatizada

• Recuperação de arquivos excluídos

• Reconstrução de eventos com base em horários de MAC (Modify/Access/Change)

O TCT apresenta atualmente quatro partes principais:

• grave-robber;

• mactime;

• utilitários (icat, ils, pcat, md5, timeout);

• unrm e lazarus;

Os principais componentes do TCT são detalhados a seguir. No entanto, a maioria das

ferramentas possui uma série de opções de execução, que não são discutidas neste trabalho.

5.2.3.1 Grave-robber

A ferramenta grave-robber pode ser considerada a parte central de todo o TCT. O

grave-robber é basicamente uma ferramenta de coleta de dados que executa uma série de

comandos em uma tentativa de reunir informações básicas sobre o sistema e salvar alguns

arquivos necessários para a análise. É importante mencionar que o grave-robber apenas coleta

informações, não fazendo qualquer esforço no sentido de interpretá-las.

A ferramenta captura os dados de acordo com a ordem de volatilidade (conceito

Honeynets 24
introduzido por Farmer e Venema), e como padrão de execução ela coleta informações

(processos e estado da rede), descobre o que puder sobre a configuração de hardware do sistema

(especialmente sobre os discos e partições) e busca por arquivos críticos (como, por exemplo,

arquivos de log e de configuração).

Antes de iniciar a coleta dos dados, o grave-robber examina alguns dos utilitários e

arquivos mais importantes do sistema, permitindo que o investigador possa utilizá-los com

segurança. Usualmente são verificados os arquivos contidos no diretório /etc e os utilitários

comumente localizados em diretórios como /bin e /usr/bin. Essa atividade é controlada pelo

arquivo de configuração look@first do TCT.

Embora seja um processo bastante demorado, recomenda-se executar o grave-robber

sobre o sistema todo (passando o diretório raiz do sistema como argumento). Como saída, o

grave-robber produz os seguintes arquivos e diretórios (toda saída produzida contém uma marca

de tempo e é gerada a assinatura MD5 do arquivo produzido):

 body: banco de dados para o programa mactime, contendo os atributos dos arquivos

analisados (incluindo os mactimes);

 body.S: contém os atributos de todos os arquivos SUID encontrados;

 command out: sub-diretório contendo a saída dos diversos comandos executados

pelo grave-robber como, por exemplo, o ps e netstat;

 removed but running: sub-diretório contendo arquivos que foram “deletados”, mas

ainda estão em execução;

 icat: sub-diretório contendo arquivos em execução que ainda estão no disco;

Honeynets 25
  proc: sub-diretório contendo arquivos copiados do diretório /proc;

 conf vault: sub-diretório contendo os arquivos e diretórios críticos salvos pelo grave-

robber;

 user vault: sub-diretório contendo os arquivos e diretórios de usuário salvos pelo

grave-robber (arquivos de “history” do shell por exemplo);

 trust: sub-diretório contendo relações de confiança do sistema (como .rhosts, .

forward e tarefas agendadas, por exemplo);

 coroner.log: log de execução do grave-robber, contendo a data e horário de execução

de todos os programas invocados;

 error.log: log de erro do grave-robber;

 MD5 all: assinatura MD5 de tudo que é produzido como saída do programa grave-

robber;

5.2.3.2 Mactime

A ferramenta mactime pode ser usada para processar o arquivo “body”, produzido pelo

grave-robber, ou pode ser executada sobre um determinado diretório. Essa ferramenta produz

uma listagem de todos os arquivos e sub-diretórios que tiveram algum de seus mactimes

alterados a partir de uma determinada data (passada como parâmetro). Tal listagem é ordenada

segundo uma linha de tempo e cada entrada corresponde à alteração de um ou mais “mactimes”

(identificados pelas letras “m”, “a” e “c”).

5.2.3.3 Utilitários

O TCT possui uma série de utilitários que são executados pela ferramenta grave-robber.

Honeynets 26
Entretanto, esses programas auxiliares podem ser bastante úteis em outras situações. Alguns dos

principais utilitários presentes no TCT são descritos como se segue.

A ferramenta icat permite visualizar o conteúdo de um arquivo ou diretório a partir do

número de seu inode. Pode ser usada para recuperar o conteúdo de inodes não alocados.

O utilitário ils lista as informações sobre os inodes de um sistema de arquivos. Em sua

execução padrão o ils lista apenas informações sobre inodes de arquivos deletados.

O script ils2mac pode ser usado para converter a saída do comando ils para o formato do

arquivo “body”, permitindo sua utilização com a ferramenta mactime. Outro utilitário, chamado

pcat, permite visualizar a memória de um processo. O comando md5 computa a assinatura MD5

de um fluxo de bits qualquer (um arquivo, por exemplo). Por fim, a ferramenta timeout permite

a execução de um comando qualquer com uma restrição de tempo. Caso o comando desejado

não termine dentro do limite de tempo estipulado, o comando é terminado.

5.2.3.4 Unrm e Lazarus

A ferramenta unrm é uma variante do programa dd, sendo capaz de copiar os blocos de

dados de um sistema de arquivos. Em sua execução padrão, o unrm extrai apenas os blocos de

dados não alocados do sistema de arquivos. Essa ferramenta é utilizada na tentativa de recuperar

informações deletadas. É importante redirecionar a saída do programa unrm para outro sistema

de arquivos diferente do analisado. Caso contrário, o fluxo de bits gerado irá ocupar os blocos

não alocados que deveriam ser extraídos, possivelmente sobrescrevendo as informações

Honeynets 27
procuradas.

O resultado da execução do programa unrm é apenas um enorme fluxo de bits sem

qualquer sentido aparente. Para tentar reconstruir arquivos deletados ou outros tipos de dados, a

partir de um fluxo de bits qualquer, o TCT possui uma ferramenta chamada lazarus. Esse

programa toma os dados produzidos pela ferramenta unrm e tenta criar alguma estrutura a partir

de dados não estruturados.

Basicamente o processo de análise realizado pelo programa lazarus realiza os seguintes

passos:

1. Leitura de um bloco de dados da entrada ;

2. Determinação do formato dos dados contidos no bloco lido:

• Se o bloco contém texto, o programa testa os dados contra um conjunto de

expressões regulares para tentar determinar do que se trata;

• Se o bloco contém dados binários, o comando “file” é executado sobre o bloco

para determinar o tipo de dado. Se não há sucesso, os primeiros bytes do

bloco são examinados para determinar se os dados parecem estar no formato

ELF (representando um binário executável);

• Se o bloco (contendo dados binários ou texto) é reconhecido nos passos

anteriores como sendo de um determinado tipo, ele é marcado como tal. Se

esse bloco é de um tipo diferente do bloco processado anteriormente, então ele

é salvo como um novo arquivo. Caso contrário, ele é concatenado ao bloco

anterior. Se o bloco não é reconhecido nos passos anteriores, mas é posterior a

Honeynets 28
 um bloco reconhecido, o programa assume que o bloco em questão é uma

continuação dos dados contidos no bloco reconhecido e, portanto, o concatena

ao bloco anterior (considerando o princípio da Localidade);

A saída produzida pelo programa lazarus corresponde aos blocos de dados e um mapa

dos blocos reconhecidos e seus respectivos tipos. É possível gerar uma saída no formato HTML,

contendo um mapa com links que permitem navegar pelos dados

5.2.4 EnCase

No Windows NT os métodos são semelhantes, mas as ferramentas são diferentes.

Opções comerciais como o EnCase21 estão disponíveis para NT.

O EnCase é um sistema integrado de análise forense baseado no ambiente Windows,

desenvolvido pela Guidance Software. O EnCase é amplamente utilizado por agentes da lei e

profissionais de segurança de computadores em todo o mundo. O processo utilizado pelo

EnCase começa com a criação das imagens dos discos (disquetes, Zips, Jaz, CDROMs e discos

rígidos) relacionados ao caso investigado. Depois da criação das imagens, chamadas de “EnCase

evidence files”, pode-se adicioná-las a um único caso e conduzir a análise em todas elas

simultaneamente.

O ambiente Windows não é considerado apropriado, por muitos pioneiros da área, para a

prática forense, uma vez que ele rotineiramente altera os dados e escreve no disco rígido sempre

que é acessado. Entretanto, o EnCase não opera na mídia original ou discos espelhados. Ao

21
http://www.encase.com

Honeynets 29
invés disso, o EnCase monta os “evidence files” como discos virtuais protegidos contra escritas.

Então, o EnCase reconstrói o sistema de arquivos contido em cada “evidence file”,

permitindo ao investigador visualizar, ordenar e analisar os dados, de maneira não-invasiva,

através de uma interface gráfica.

Várias funções e ferramentas de análise são integradas pelo EnCase, podendo ser citadas

as seguintes:

 visualização do caso através de uma interface do tipo Windows Explorer;

 suporte a múltiplos sistema de arquivos, incluindo FAT (12, 16 e 32), NTFS, HFS

(Macintosh), ISO9660 (CDROM), EXT2FS, UFS, PDAs e RAID;

 visualização de todos os arquivos de um caso, incluindo os file slacks (no formato texto ou

hexadecimal);

 visualização e análise remota dos dados contidos na máquina investigada, através da

interface paralela ou da rede;

 busca e visualização de imagens gráficas (mesmo deletadas);

 mecanismo de busca de palavras-chave e expressões;

 relatório do caso, contendo a descrição dos dados e sua cadeia de custódia;

 criação e checagem de assinaturas criptográficas de arquivos;

 customização de filtros e funções através de uma linguagem de scripts;

 visualização de arquivos compostos, incluindo o registro do Windows, anexos de mensagens

de correio eletrônico e arquivos compactados;

 visualização da linha de tempo de utilização dos arquivos;

Honeynets 30
5.3 Legalidade de um Honeypot

No passado, criou-se uma certa confusão sobre quais seriam as implicações legais dos

honeypots. Afinal, trata-se de um conceito relativamente novo, sobre o qual os profissionais de

segurança ainda estão aprendendo. Não existem precedentes legais que se apliquem

especificamente a honeypots, nem existem casos registrados .

Por outro lado, os honeypots podem ser configurados das mais diversas maneiras e

podem assumir os mais variados papéis. Até que um juiz julgue um caso envolvendo um

honeypot, não há como saber o que pode acontecer. De qualquer forma, podemos prever que um

honeypot pode vir a trazer problemas legais em três áreas: indução ao crime, privacidade e

responsabilidade.

No primeiro caso, não se pode alegar tal coisa em um caso envolvendo um honeypot,

pelo simples fato de que um honeypot não induz ninguém a fazer nada que normalmente não

faria. Um atacante encontra e tenta invadir um honeypot por iniciativa própria. O próprio

atacante decidiu realizar uma atividade não autorizada e tentou tomar controle do sistema que

não lhe pertencia.

No segundo caso, a questão é um pouco mais complexa. Dependendo das leis do país,

pode ser ilegal coletar informações sobre o atacante sem o seu conhecimento. Mesmo parecendo

estranho, em alguns lugares, a lei não dá o direito de capturar informações sigilosas, mesmo em

seu prórpio sistema. Alguns lugares até permitem, mas desde que uma autoridade policial, com

a devida autorização judicial, acompanhe o caso. Em outros casos, pode-se utilizar de leis de

proteção de provedores de serviço, onde é possível coletar dados legalmente, desde que seja

para proteger os recursos físicos e lógicos do provedor, de forma a evitar que o serviço seja

interrompido e traga prejuízos.

O tipo de informação a ser coletado também é importante. Por exemplo, coletar apenas

Honeynets 31
informações transacionais, como endereços IP, logs e dados de cabeçalhos de pacotes, como os

gerados por um honeypot de baixa interatividade. Já no caso de honeypots de alta interatividade,

dados de conteúdo são capturados, tais como comunicação de IRC, chats, páginas WEB. Estes

dados podem conter informações consideradas privativas, e que podem ser questionadas em um

tribunal. Uma alternativa simples para se evitar problemas deste tipo, seria colocar uma

mensagem de aviso, notificando o atacante de que todas as informações podem estar sendo

capturadas.

A última questão é a responsabilidade. Afinal, um atacante pode utilizar um honeypot

como ponte para cometer os mais diversos crimes, e prejudicar outras pessoas. Alguns podem

dizer que se as precauções necessárias tivessem sido tomadas, o honeypot não teria sido

utilizado para o mal. Mas aí temos dois problemas: primeiro, honeypots são tecnologias

experimentais, e ainda não existem estudos 100% completos sobre todos os problemas de um

honeypot. Segundo, toda tecnologia de segurança pode apresentar problemas, nenhum sistema é

completamente seguro.

O ideal é utilizar apenas honeypots de baixa interatividade, com serviços emulados, para

evitar este tipo de problema. Caso seja realmente necessário utilizar honeypots de alta

interatividade, devem-se tomar todas as medidas possíveis para conter os ataques de forma

rápida e eficiente.

No Brasil, a lei 9.296/96 é a primeira lei específica para o meio digital [8] e trata,

basicamente do sigilo das transmissões de dados, segundo a qual é vedado a qualquer pessoa ou

entidade o direito de interceptação de mensagens digitais ou telefônicas, bem como quaisquer

comunicações entre dois computadores por meios telefônicos, telemáticos ou digitais. A

interpretação mais recente desta lei observa exatamente esta última parte da lei, "comunicação

entre dois computadores" e a aplica a furto de dados de bancos de dados, invasão e espionagem

Honeynets 32
ou sniffing da rede e outros delitos que envolvam a manipulação de um terceiro a um conjunto

de dados pertencente a outros computadores. Ainda a lei 9.983/00 prevê como crime a ação de

divulgação de segredo, inclusive por meio da Internet tanto a sua transmissão quanto sua

descoberta, sendo considerado como segredo, para efeitos da lei, senhas, dados de clientes ou

quaisquer outras informações que não possam ser obtidas senão através da invasão do site. Esta

lei também inclui como crime ações que englobam mas não se limitam à inserção proposital de

dados inválidos em bancos de dados e da construção e modificação de sistemas sem a

autorização do proprietário. Ainda circula pela Câmara dos Deputados um Projeto de Lei, de

número 89/04, que prevê condutas típicas do meio digital, como disseminação de vírus, invasão

e pichação de sites, entre outros [8].

6 Criando uma Honeynet

As Honeynets não são um único produto ou uma solução, mas sim uma arquitetura

criada para capturar e controlar o fluxo de dados. O segredo de uma arquitetura geral de uma

Honeynet são as camadas. Quanto mais camadas de informações tiver, mais fácil será analisar e

aprender com um ataque. Entretanto, um motivo mais importante ainda para ter camadas de

segurança é para protegê-la contra falhas. Com diversas camadas incorporadas na arquitetura,

todo o sistema estará protegido caso uma única camada falhe.

Sempre que existe um comprometimento de um Honeypot existe também alguma falha.

Essas falhas podem ser em um IDS22 que não capturou os pacotes suspeitos, um firewall que não
22
Intrusion Detect System, em www.snort.org

Honeynets 33
alertou, o DNS23 que não foi determinado ou mesmo o syslog que não enviou ou recebeu os logs

do sistema como deveria. O grande trunfo, então, de uma Honeynet são as proteções quanto à

falhas.

Esta mesma filosofia pode, e deve, ser usada ao criar uma infraestrutura de segurança

para uma empresa ou organização. Este conceito também é conhecido como defesa em

profundidade, ou seja, um único componente de hardware ou software nunca poderá proteger

totalmente uma rede, na melhor das hipótese poderá defender um segmento reduzido de uma

rede, mas mesmo assim, se falhar deixará a rede totalmente desprotegida.

Outra vantagem de uma Honeynet é que a arquitetura ou a topologia montada não

precisa visar o desempenho, e nem deveria. Podem-se utilizar equipamentos muitas vezes

obsoletos para a empresa, ou mesmo que estão em desuso. Uma Honeynet comum não costuma

produzir muito tráfego, em média fica em torno de 1 a 10 Megabytes diários.

6.1 A arquitetura de uma honeynet

Topologia

Em continuação ao estudo de caso estaremos apresentando a seguir duas topologias:

1. Topologia ideal

2. Topologia utilizada em laboratório

A topologia da Honeynet proposta está dividida em duas partes: A rede administrativa e

a Honeynet em si.

23
Domain Name System

Honeynets 34
 A rede administrativa tem as funções principais de conter a saída de tráfego constatado

como malicioso e monitorar todo o tráfego, seja interno ou não. Esta rede se torna transparente

tanto para a Internet quanto para a própria Honeynet, e é composta por diversas camadas de

segurança, utilizando o conceito conhecido como defesa em profundidade.

6.1.1 Topologia Ideal

Na topologia ideal teríamos uma conexão dedicada a internet com um firewall rodando

Iptables/Hogwash atuando como uma bridge filtrando toda a saída e permitindo qualquer tipo de

entrada, um HUB distribui a conexão sendo o melhor local para um sensor IDS do Snort, com

conexão ao banco de dados onde os alertas seria enviados.

O servidor Web rodando Apache estará configurado apenas para conexões SSL,

utilizando um certificado SSL previamente gerado para autenticação. O tráfego fluiria para o

switch, onde um servidor de log (syslog) estaria em modo escuta recebendo as informações via

protocolo UDP, através de um cabo apenas com os pares de RX habilitados, impedindo

qualquer tipo de conexão.

No outro segmento de rede estaria a máquina Honeypot, virtualizando os hosts através

do aplicativo honeyd. Seriam emulados serviços como HTTP, FTP, TELNET e proxy em

máquinas Linux, Solaris, Windows 95/98, Windows NT, Windows XP e 2000.

Honeynets 35
 Topologia Ideal

6.1.2 Topologia utilizada em laboratório

Na topologia utilizada em laboratório, temos uma situação mais simplificada, dadas as

limitações na disponibilidade de hardware, além do fato de precisarmos compartilhar recursos

com outras máquinas da rede interna do laboratório, principalmente no que diz respeito ao link

dedicado à Internet.

Temos uma máquina servindo de firewall, rodando Iptables/Hogwash. Ela atua como

Honeynets 36
uma bridge filtrando toda a saída e permitindo qualquer tipo de entrada. Ao contrário da

topologia ideal, não é utilizado um HUB para distribuir a conexão. Como não dispomos de um

meio compartilhado para monitorar o segmento com o sensor IDS do Snort, optamos por fazer

um IDS de host, monitorando apenas o tráfego da máquina onde está instalado. Esta máquina

possui uma conexão com outra máquina no segmento de gerenciamento, que faz o papel de

servidor de banco de dados (mySQL) e servidor de web (com SSL) para o gerenciamento

remoto do SNORT. Neste segmento de gerenciamento também se encontra o servidor de logs,

onde todos os logs de todas as aplicações são centralizados. Este servidor está conectado a um

HUB em uma rede administrativa separada, e as máquinas que desejam enviar dados de log o

fazem diretamente atráves de interface ethernet dedicada, recebendo as informações via

protocolo UDP.

No outro segmento de rede estaria a máquina Honeypot virtualizando os hosts através do

aplicativo honeyd, seriam emulados serviços como HTTP, FTP, TELNET e PROXY, além de

virtualizar máquinas Linux, Solaris, Windows 95/98, Windows NT, Windows XP e 2000 e

alguns equipamentos de rede. A mesma máquina também abriga o aplicativo ProxyPot,

responsável por simular proxies abertos e capturar tráfego de spammers na rede.

Honeynets 37
 Topologia de Laboratório

7. Componentes de segurança do honeypot

7.1 IDS

Honeynets 38
 A descoberta de um ataque bem sucedido ou não, depende da análise do que está

ocorrendo na rede. Podem-se utilizar sniffers que ficam à escuta do tráfego de dados pela rede e

comparando com um registro de assinaturas de possíveis ataques. Outros métodos de

identificação analisam o comportamento dos sistemas, quando ocorre uma anomalia em relação

ao comportamento usual, o sistema de identificação emite um alerta, neste caso, um

comportamento não usual pode ser um comportamento válido (gerando uma mensagem de

identificação falsa), ou falso positivo, e que deve ser registrado para usos futuros.

Muitas ferramentas de IDS realizam suas operações a partir da análise de padrões do

sistema operacional e da rede tais como: utilização de CPU, I/O de disco, uso de memória,

atividades dos usuários, número de tentativas de login, número de conexões, volume de dados

trafegando no segmento de rede entre outros. Estes dados formam uma base de informação

sobre a utilização do sistema em vários momentos ao longo do dia, outras já possuem bases com

padrões de ataque (assinaturas) previamente montados permitindo também a configuração dos

valores das bases bem como inclusão de novos parâmetros. Com estas informações, a

ferramenta de IDS pode identificar as tentativas de intrusão e até mesmo registrar a técnica

utilizada. Uma ferramenta de IDS deve possuir algumas características, entre elas:

1. Rodar continuamente sem interação humana e deve ser segura o suficiente de forma a

permitir sua operação em background, mas deve ser fácil de compreensão e operação;

2. Ter tolerância a falhas, de forma a não ser afetada por uma falha do sistema, ou seja, sua

base de conhecimento não deve ser perdida quando o sistema for reinicializado;

3. Resistir a tentativas de mudanças de sua base, ou seja, deve monitorar a si próprio de forma

a garantir sua segurança;

Honeynets 39
4. Ter o mínimo de impacto no funcionamento do sistema;

5. Detectar mudanças no funcionamento normal;

6. Ser de fácil configuração, cada sistema possui padrões diferentes e a ferramenta de IDS deve

ser adaptada de forma fácil aos diverso padrões.

7. Deve cobrir as mudanças do sistema durante o tempo, como no caso de uma nova aplicação

que comece a fazer parte do sistema;

8. E deve ser difícil de ser enganado.

7.1.1 Classificação de ataques

Quanto um IDS armazena as informações de um suposto ataque deve ser levado em

consideração alguns aspectos que podem ser classificados em: falso positivo, falso negativo e

erros de subversão.

• Falso positivo ocorre quando a ferramenta classifica uma ameaça como uma possível

intrusão, quando na verdade trata-se de uma ação legítima; Um bom exemplo de falso

positivo é o ataque de SYN FLOOD. O simples fato de acessar um determinado tipo de

página pode gerar uma detecção da ocorrência de um ataque SYN FLOOD.

• Falso negativo ocorre quando uma intrusão real acontece, mas a ferramenta permite que

ela passe como se fosse uma ação legítima;

• Subversão ocorre quando o intruso modifica a operação da ferramenta de IDS para

forçar a ocorrência de falso negativo.

7.1.2 Dificuldades Relacionadas ao IDS

A maior dificuldade relativa a um sistema de detecção de invasão é identificar e

Honeynets 40
classificar o que é realmente uma tentativa de acesso não autorizado ou simplesmente um erro

eventual, ou uma distração para ocupar os administradores de sistemas enquanto o verdadeiro

ataque ocorre.

Devido à complexidade das redes de computadores, suas ligações com softwares e outros

hardwares, é muito difícil avaliar ferramentas de IDS. O rápido crescimento e diversidade de

ataques que surgem a cada dia impedem que uma ferramenta de IDS seja constantemente

atualizada. Estas ferramentas acabam por agir somente sobre alguns tipos de ataques mais

conhecidos ou comparam o tráfego de rede buscando padrões conhecidos de ataques.

O número de tentativas de invasão seria menor, se as ferramentas de IDS que são

utilizadas fossem devidamente configuradas.

7.1.3 Criptografia e o IDS

A criptografia dos pacotes é um problema, especialmente para IDS de redes. A prática de

procurar padrões de assinatura não funciona em pacotes criptografados. E com o crescimento da

utilização de criptografia, fica cada vez mais claro que um IDS deve ter a habilidade de verificar

pacotes criptografados.

A utilização de criptografia por chave-pública elimina a necessidade da verificação, se os

pacotes vierem assinados digitalmente, o que garante a origem e autenticidade dos dados.

Honeynets 41
7.1.4 Tipos de IDS

Os Sistemas de detecção de intrusão podem ser classificados em dois tipos de

implementação:

• Host Based: são instalados em servidores para alertar e identificar ataques e tentativas

de acesso indevido à própria máquina, sendo mais empregados nos casos em que a

segurança está focada em informações contidas em um servidor e os usuários não

precisam ser monitorados. Também é aplicada em redes onde a velocidade de

transmissão é muito alta como em redes "Gigabit Ethernet" ou quando não se confia na

segurança corporativa da rede em que o servidor está instalado.

• Network Based: são instalados em máquinas responsáveis por identificar ataques

direcionados a toda a rede, monitorando o conteúdo dos pacotes ou do tráfego e seus

detalhes como informações de cabeçalhos e protocolos. O IDS tem como um dos

objetivos principais detectar se alguém está tentando entrar no seu sistema ou se algum

usuário legitimo está fazendo mau uso do mesmo. No caso das honeynets os IDS

instalados são do tipo Netword Based.

7.1.5 IDS Snort

No projeto inicial da honeynet foi proposta a utilização de um IDS opensource, para

tanto foi escolhido o IDS Snort 24.

O Snort é um sistema de detecção de intrusão em redes, com código-fonte aberto, capaz

de realizar análise de tráfego e captura de pacotes em tempo real, em redes que utilizam o

protocolo IP. Ele pode analisar protocolos, buscar por conteúdo específico, e pode ser utilizado

para detectar uma variedade de ataques e sondagens, tais como buffer overflows, portscans,

24
www.snort.org

Honeynets 42
ataques de CGI, sondagnes SMB, tentativas de identificação de sistema operacional, e muito

mais.

O Snort possui três usos primários: ele pode ser utilizado como um capturador de

pacotes comum, como o tcpdump, como um analisador de pacotes (útil para depurar tráfego de

rede), ou como um sistema completo de detecção de intrusão em redes. Utiliza uma linguagem

flexível de regras para descrever o tráfego que ele deve coletar ou deixar passar, assim como

uma mecanismo de detecção que utiliza uma arquitetura de plug-ins. Estas regras são

atualizadas diariamente por voluntários, e podem ser obtidas diretamente da Internet, inclusive

por processos automatizados. Alguns dos plug-ins utilizados pelo Snort são chamados de pré-

processadores. Estes pré-processadores realizam funções específicas e cruciais para a eficiência

do Snort, como por exemplo detectar portscans ou padrões de ataques mais complexos (como

por exemplo, variações de ataques com shellcode), ou ainda mecanismos para remontar

sequências de pacotes fragmentados. Também possui a capacidade de gerar alertas,

incorporando mecanismos de alerta como syslog , arquivos texto, bancos de dados, sockets

UNIX, mensagens via NETBIOS, e mensagens via email.

7.1.6 Utilização do IDS Snort com a Honeynet

Na definição da topologia da honeynet aqui descrita estaremos utilizando as seguintes

ferramentas para auxiliar na administração e controle dos alertas gerados pelo Snort.

As ferramentas e utilitários são:

1. web server25 com utilização de criptografia SSL

2. Mysql26 database server;

25
http://www.apache.org
26
http://www.mysql.com/downloads/

Honeynets 43
 3. ACID27 (Analysis Console for Intrusion Databases);

4. IDS Snort 28.

Esta topologia assume que os sensores estarão rodando em hardware dedicados,

separados do banco de dados e do console ACID. Cada sensor é responsável por monitorar um

segmento de rede, e reportar ocorrências de volta ao servidor central MySQL.

Toda a comunicação entre os sensores e o banco de dados é encriptada utilizando-se

SSL. O acesso a estes consoles é restrito, utilizando SSL e autenticação por senha.

Todos os dados são reportados utilizando-se um usuário criado especialmente para tal

propósito, com direitos de leitura e escrita apenas às tabelas utilizadas pelo SNORT. Desta

forma, caso algum invasor ou pessoa mal-intencionada ganhe controle de uma das máquinas

sensoras, não terá acesso algum aos dados coletados, pois estão em uma máquina remota.

Mesmo que se tente utilizar a conexão do sensor com o banco de dados, os danos serão

mínimos, pois a máquina sensora não tem permissão para apagar nenhum dado, e nem mesmo

alterar os dados já processados, pois estes ficam em outra tabela.

O servidor possui controle de segurança individual para cada um dos componentes,

utilizando usuário/senha para acessar cada página, e exigindo acesso nível root para lidar com o

processo principal do SNORT.

7.2 Firewall

Um firewall permite a entrada de todo o tráfego para a Honeynet, possuindo regras

27
http://acidlab.sourceforge.net
28
http://www.snort.org/

Honeynets 44
apenas para a saída de tráfego malicioso. Esse controle é feito na camada de enlace com o

firewall operando como uma bridge.

Um dos pré-requisitos mais importantes em uma honeynet é a concepção de tráfego

malicioso de saída, pois o objetivo maior é acompanhar as ações dos invasores, e não manter

meios para a contenção total do ataque. Para isso geramos algumas regras no firewall que o

protege, conforme o [anexo 2].

Tipicamente, após o comprometimento do sistema, o invasor inicia scans, ataques de

DOS (Negação de serviços), ou mesmo tentativas de comprometer outras redes. Um dos pontos

principais de uma Honeynet é que ela não seja utilizada como ponte de ataques a outras redes

sendo primordial a contenção desse tipo de ataque sem, contudo, inibir outras atividades de

interesse como o download de ferramentas como rootkits, DDOS, ou mesmo comunicação com

outros invasores.

7.2.1 IPTables Log Analyzer

Para determinar acessos remotos e facilitar a busca por taxonomias, utilizamos o

analisador de logs para iptables conhecido como IPTables Log Analyzer29. Ele utiliza o banco de

dados mySQL30 para armazenar os logs de tráfego, e uma interface em PHP 31para buscas e

acessos remotos.

29
http://www.gege.org/iptables
30
www.mysql.org
31
www.php.org

Honeynets 45
 Procedimento para criação do banco de dados do IPTables Log Analyzer:

1. Iniciando o cliente mySQL como root:

[root@localhost /root] mysql -u root –p

2. Criando a tabela iptables e garantindo acessos de gravação e criação, onde xx é a senha para

a tabela.

mysql> create database iptables;

mysql> grant create,select,insert on iptables.* to

iptables_admin@localhost identified by 'xx';

mysql> grant select on iptables.* to iptables_user@localhost

identified by 'xx';

mysql> grant create temporary tables on iptables.*

iptables_user@localhost identified by 'xx';

OBS: xx é onde deve ser informado a senha para acesso ao banco de dados
tanto localmente como remotamente.

3. Utilizando os scripts SQL para geração de tabelas auxiliares e conteúdos.

mysql> source iptables_admin;

mysql> quit

4. Regras adicionais para o iptables.

[root@localhost /root] iptables -N LOG_DROP

[root@localhost /root] iptables -A LOG_DROP -j LOG --log-tcp-options -- log-
ip-options --log-prefix '[IPTABLES DROP] : '
[root@localhost /root] iptables -A LOG_DROP -j DROP

Honeynets 46
Figura 3: Screenshot do IPTables Log Analyzer

7.2.3 Regras do Firewall

O firewall está configurado para atuar como uma bridge não possuindo endereço IP nas

suas interfaces e não decrementa o TTL (Time to Live) dos pacotes IP. Desse modo as chances

do firewall ser detectado e atacado são menores.

O filtro de pacotes Iptables32 é utilizado para implementar as regras que permitem

qualquer tipo de tráfego de entrada, mas descartam tráfego potencialmente malicioso de saída da

honeynet, como por exemplo:

32
www.ipfilter.org

Honeynets 47
 • Tráfego TCP com características não usuais utilizada por portscans ;

• Tráfego TCP destinado a serviços sabidamente vulneráveis;

• Tráfego UDP, dependendo do IP de origem e da porta destino;

• Algumas caracteristicas de pacotes ICMP como o Ping of Death;

• Tráfego de saída com IP de origem forjados.

Vários ataques utilizam-se de sobreposição e ordem inválida de fragmentos para

despistar IDS e firewall da rede. Algumas ferramentas de scan utilizam-se de conjuntos

inválidos de flags TCP com o mesmo objetivo, assim para determinar remotamente o sistema

operacional usado pela máquina. Uma dessas ferramentas que é muito utilizada para esses fins é

o Nmap33 podendo-se forjar flags e determinar o sistema operacional utilizado.

7.3 Hogwash

Na topologia também teremos uma máquina executando o hogwash34, que nada mais é

do que um firewall de camada dois. Essa máquina será configurada para bloquear a saída de

tráfego com conteúdo sabidamente malicioso, evitando assim que a honeynet seja utilizada

como base para ataques externos a rede. O Hogwash utiliza para tanto as regras do IDS Snort.

Uma das vantagens dessa ferramenta é a fácil atualização das assinaturas, que podem vir tanto

da comunidade de segurança em geral como localmente criadas em função do tráfego

malicioso .

33
www.insecurity.org
34
http://sourceforge.net/projects/hogwash/

Honeynets 48
7.4 Keystroke

Hoje em dia, com o advento da criptografia, mais atacantes a estão utilizando para

camuflar seus passos, e com isso esconder o que de fato ocorre enquanto está em posse de um

servidor ou máquina comprometida. Os “Black Hats” também a utilizam para transferências de

arquivos criptografados, fazendo com que os IDS não detectem uma invasão, e possivelmente

com isso gerando um falso negativo.

Neste estudo foram utilizadas várias técnicas para contornar esse problema, uma delas

era a alteração do shell Bash (Bourne Again Shell) [ANEXO 1] de modo que fosse capaz de

capturar informações e através do syslog deamon armazenar o pressionamento de teclas em

arquivos de log, como por exemplo em /var/log/messages.

Este tipo de captura é perfeito quando se executa o shell bash, mas há momentos que um

atacante pode executar outro tipo de shell, como por exemplo o Korn Shell, fazendo com que as

teclas não sejam mais capturadas.

Existe também o problema que a criptografia pode causar, pois o syslog não trabalha

com informações criptografadas, e quando o atacante inicia um serviço baseado no SSH, como é

o caso do SCP, que faz cópias de arquivos utilizando um canal criptografado, se perde o fator

de monitoração, não tendo como decifrar o que o atacante está fazendo no momento e quais

ferramentas ele transferiu para o sistema comprometido.

Honeynets 49
7.5 Sebek

Sebek35 é uma ferramenta usada para coletar a digitação de dados através do teclado,

capturando informações criptografadas SSH/SCP (Secure Shell) de um Honeypot.

É baseada em um LKM (Loadable Kernel Module), ou seja, os mesmos princípios dos

rootkits LKM. Os logs gerados pelo Sebek podem ser enviados remotamente utilizando o

protocolo UDP em uma porta previamente configurada.

Existe um módulo previamente configurado para que todas as informações coletadas

sejam inseridas em um banco de dados Mysql.

35
http://www.honeynet.org/tools/sebek/

Honeynets 50
8 Aplicação: Detecção de Spammers com um Honeypot

8.1 O que é spam?

O termo “spam” é utilizado globalmente para definir qualquer tipo de mensagem

comercial não-solicitada enviada pela Internet. A sua origem vem de um sketch do grupo inglês

Monty Python36 , em que um restaurante serve apenas o mesmo prato, SPAM37 (abreviação de

“Spiced Ham”, ou presunto temperado), e a palavra SPAM é repetida ao extremo o tempo todo,

saturando os clientes. Pode-se dizer que é uma situação semelhante, já que atualmente a

quantidade de spams recebidos na Internet é extremamente alta, superando a quantidade de

emails úteis e consumindo recursos desnecessariamente.

8.2 Como os endereços são coletados

O envio de spam é hoje uma atividade rentável, à margem da legalidade, utilizada para

anúncios em massa. Geralmente os spammers trabalham utilizando três métodos:

• Coleta em massa de endereços válidos de email (harvest): utilizado para criação de

um banco de dados válido de endereços de email de potenciais vítimas;

• Proxies abertos ou Proxies Stealth: utilizados para enviar emails anonimamente para

as vítimas.

• Relays abertos: encontrar servidores que aceitem repassar mensagens para qualquer

destino sem verificação.

36
http://www.ironworks.com/comedy/python/spam.htm
37
http://www.spam.com

Honeynets 51
8.3 Coleta de endereços em massa

A primeira necessidade dos spammers é conseguir uma lista atualizada de vítimas.

Existem muitas maneiras diferentes de coletar milhares e milhares de endereços de email. Todas

as vezes que uma mensagem é enviada para a Usenet, por exemplo, endereços válidos estão

disponíveis para programas automatizados que coletam campos específicos de cada mensagem

postada (From, To), criando rapidamente enormes listas de potenciais vítimas. Outro exemplo

de coleta de endereços pode ser através do uso de listas de discussão mal configuradas, que

retornam a lista de endereços de email dos assinantes. Uma terceira técnica é utilizar programas

automatizados que varrem páginas WWW na Internet. Para cada páginas HTML encontrada, o

programa irá procurar por links “mailto:” (como por exemplo, “clique aqui para enviar um

email), anexando à sua lista cada um dos endereços encontrados.

8.4 Proxies abertos

Os spammers podem também conectar diretamente a um servidor de email remoto, ou

fazer com que mensagens sejam repassadas através de proxies abertos. Por exemplo, o papel de

um proxy de Web é fazer o trabalho de um cliente Web para alguém. Quando um cliente web se

conecta ao proxy, ele pede por uma página WWW em algum lugar na Internet. O proxy então

baixa esta página por conta própria, e retorna os dados obtidos para o cliente. Nos logs do

servidor Web consultado, geralmente poderemos encontrar apenas o endereço do proxy, e não

do cliente que solicitou a página.

Um proxy aberto é um serviço de repasse aberto para o mundo para quase qualquer tipo

Honeynets 52
de solicitação, permitindo a qualquer um permanecer anônimo enquanto navega pela rede. Tais

proxies são úteis para muitos spammers, pois eles podem se manter anônimos enquanto enviam

seus emails não-solicitados.

Abaixo podemos ver um exemplo de uma sessão gravada pelo IDS Snort, mostrando

uma verificação de proxy aberto, provavelmente feita pelo provedor EarthLink. O cliente se

conecta ao proxy na porta TCP 8080, e não pede por uma página Web, mas sim por uma sessão

TCP inicializada com um servidor SMTP (207.69.200.120) utilizando-se da função HTTP

CONNECT. O resto desta sessão TCP é de comandos SMTP, enviados diretamente para o

servidor SMTP (HELO, MAIL FROM, RCPT TO, DATA, QUIT).

$ cat /var/log/snort/192.168.1.66/SESSION\:8080-4072
CONNECT 207.69.200.120:25 HTTP/1.0

HELO [217.128.a.b]
MAIL FROM:<openrelay@abuse.earthlink.net>
RCPT TO:<spaminator@abuse.earthlink.net>
DATA
Message-ID: <36af800461754252ab1107386a9cd8eb@openrelay@abuse.earthlink.net>
To: <spaminator@abuse.earthlink.net>
Subject: Open HTTP CONNECT Proxy
X-Mailer: Proxycheck v0.45

This is a test of third-party relay by open proxy.

These tests are conducted by the EarthLink Abuse Department.

EarthLink, by policy, blocks such systems as they are discovered.

Proxycheck-Type: http
Proxycheck-Address: 217.128.a.b

36af800461754252ab1107386a9cd8eb

Proxycheck-Port: 8080
Proxycheck-Protocol: HTTP CONNECT

This test was performed with the proxycheck program. For further
information see <http://www.corpit.ru/mjt/proxycheck.html/>

.
QUIT

Figura x: Sessão TCP em um servidor proxy aberto.

Honeynets 53
 A utilização de um servidor proxy é uma método bem eficiente para manter a

anonimidade de um spammer. Como os administradores do proxy podem ter logs, os spammers

podem ter medo de que seus endereços IP reais sejam logados. Normalmente, os spammers

apostam que proxies mal-configurados não costumam ter logs. Por medo de terem sua

identidade revelada, muitos deles costumam utilizar cadeias de proxies, ou seja, conectam em

um proxy aberto e pedem para se conectar a outro proxy aberto. Por exemplo:

Figura 1: Spammer utilizando proxies abertos em cadeia

Quanto maior a cadeia utilizada, mais difíceis de os spammers serem encontrados. Há

um limite, no entanto, visto que quanto mais servidores na cadeia, maior o tempo de resposta.

Dependendo deste tempo de resposta, o trabalho do spammer pode ser prejudicado.

8.5 Relays abertos

Um relay aberto (também conhecido com relay inseguro ou relay de terceiros) é um

Agente de Transferência de Correio (ou MTA na sigla em inglês) que aceita repasse de

mensagens de email de terceiros, mesmo que não sejam destinadas ao seu próprio domínio.

Como eles repassam emails que não se destinam a usuários locais, os relays abertos são

utilizados pelos spammers para rotear grandes volumes de mensagens não-solicitadas.

Um MTA mal-configurado basicamente empresta os recursos de sistema e de rede para

um desconhecido que está sendo pago para enviar spam. Normalmente, uma empresa ou

organização que repassa mensagens de spam sem intenção de fazê-lo entra em uma lista negra

Honeynets 54
(blacklist). Estas listas internacionais (como a RBL, por exemplo) contém relações de servidores

de relay abertos, e são consultadas por milhares de outros servidores no mundo para determinar

se devem receber email originado naqueles servidores ou não. Estando em uma destas listas, o

provedor ou a própria organização podem ter emails de seus usuários bloqueados, e podem

perder dinheiro e clientes.

8.6 Honeypots e técnicas de coleta de endereços

Uma das primeiras tarefas de um spammer é coletar endereços de email. Os honeypots

podem ser utilizados de diversas formas para coibir a coleta de endereços, ou até mesmo fazer

com que os spammers coletem informações inválidas.

Uma das técnicas mais utilizadas pelos spammers é a coleta através de páginas Web.

Programas ou scripts lêem as páginas e coletam todos os possíveis endereços de email. Esta

técnica podem ser facilmente combatida por um honeypot, simplesmente gerando endereços

inválidos e aleatórios, infectando o banco de dados dos spammers.

Geralmente os spammers utilizam ferramentas que podem ser reconhecidas pela maneira

como se identificam para o servidor web, através do campo “User-Agent”. Alguns

administradores costumam bloquear identificações específicas reconhecidas como de spammers,

ou até mesmo redirecioná-los para páginas cheias de endereços de email falsos. Mas como esta

identificação pode ser facilmente alterada pelos spammers, são necessárias outras técnicas. Uma

alternativa seria criar links sem texto, contendo endereços inválidos que podem ser coletados

pelos programas dos spammers. Outra idéia é criar quantidades enormes de endereços falsos,

como faz o projeto Wpoison38. O Wpoison é uma CGI, e como pode gerar níveis infinitos de

páginas com mais endereços de emails, pode até mesmo destruir um banco de dados de um
38
http://www.monkeys.com/wpoison/

Honeynets 55
spammer. Os endereços gerados não possuem um padrão fixo, e parecem reais, não podendo ser

detectado facilmente.

Outra alternativa é criar endereços dinamicamente utilizando informações específicas, de

forma que caso este endereço seja utilizado novamente algum dia, tenha-se uma maneira de

rastrear a fonte que enviou o spam. Por exemplo, o código abaixo em PHP insere o endereço IP

de origem e a data no endereço de email em uma página:

<?
// PHP example taken from the frenchhoneynet Web site
// replace by your domain, add recipients filtering on your MTA (mimede-
fang...)
echo '<a href="mailto:'.$REMOTE_ADDR.'_'.date('y-m-j').'-spamming@frenchho-
neynet.org"
title="There is no spoon">For stupid spambots';
?>

Figura x: Código em PHP para gerar endereço de email dinâmico.

Os links gerados por este código terão o seguinte formato:

<a href=mailto:80.13.aa.bb_03-11-17-spamming@frenchhoneynet.org>

Caso um spambot (nome dado aos programas que coletam emails automaticamente)

colete este endereço, e algum dia um spam seja enviado para ele, poderemos saber o endereço

de origem do spammer e a data em que o endereço foi coletado. Com estas informações, um

administrador pode bloquear emails daquele bloco de IPs, ou avisar os administradores do

domínio utilizado para tomarem providências.

Embora estas técnicas simples possam ser eficientes em algumas situações, os spammers

mais sofisticados costumam utilizar proxies abertos para coletar endereços na Web, de forma

que seus endereços reais não apareçam nos logs.

8.7 Honeypots e proxies abertos

Um dos principais métodos utilizados por spammers para chegar aos servidores de

correio é através de proxies abertos que aceitam e retransmitem mensagens abertamente. Mas

Honeynets 56
como um honeypot se encaixa nisto? Podemos simular um proxy aberto com um honeypot para

capturar tráfego de spammers e analisar seu comportamento.

Geralmente podemos ver diversas entradas em logs de firewalls de tentativas de conexão

nas seguintes portas TCP:

• 1080, servidor proxy SOCKS

• 3128, servidor proxy SQUID

• 8080, serviço de cache web

Muitos dos spammers são amadores, e utilizam ferramentas que não entendem. É

comum ver amadores fazendo conexões TCP e enviando alguns pacotes (uma forma de

portscan) por toda a rede procurando proxies abertos, e alguns até mesmo compartilhando suas

listas. Alguns apenas verificam se a porta responde, outros fazem alguns testes para saber se o

proxy realmente está aberto ou não.

Como exemplo prático, podemos utilizar o honeyd para simular servidores proxy e de

relay falsos. Para tanto, basta acrescentar as seguintes linhas ao arquivo de configuração do

honeyd:

create relay
set relay personality "OpenBSD 2.9-stable"
add relay tcp port 25 "sh /usr/local/share/honeyd/scripts/sendmail.sh $ipsrc
$sport $ipdst $dport"
add relay tcp port 3128 "sh /usr/local/share/honeyd/scripts/squid.sh $ipsrc
$sport $ipdst $dport"
add relay tcp port 8080 "sh /usr/local/share/honeyd/scripts/proxy.sh $ipsrc
$sport $ipdst $dport"
set relay default tcp action block
set relay default udp action block
bind 192.168.1.66 relay

Estas diretivas fazem com que o Honeyd simule um computador rodando o OpenBSD

2.9 com o IP 192.168.1.66 e três portas TCP abertas: 25, 128 e 8080. Para enganar um

spammer, é necessário simular parcialmente ou totalmente a negociação normal de cada um

Honeynets 57
destes serviços. Para cada solicitação chegando a estas portas, o Honeyd irá disparar o serviço

simulado correspondente (sendmail.sh, squid.sh, proxy.sh). Se estes scripts quiserem ver os

dados enviados pelos spammers, só precisam ler a entrada de dados padrão (STDIN). Caso

queiram interagir com o spammer, só precisam escrever na saída de dados padrão (STDOUT).

Um dos scripts mais utilizados para simular proxies abertos é o Bubblegum Proxypot39.

Ele é também um dos scripts mais fáceis de utilizar. Com o Proxypot, existem três possíveis

configurações de comportamento:

• smtp1: toda a conexão SMTP é simulada. Nenhum tráfego de SMTP de saída é gerado,

evitando uso de banda desnecessário. No entanto, como é necessário que se escolha uma

versão específica de servidor SMTP para simular, spammers mais experientes podem

detectar o honeypot facilmente. Por exemplo, pedindo para conectar com um servidor

Sendmail, quando o Proxypot está simulando um Qmail, e recebendo resposta afirmativa.

• Smtp2: conecta ao servidor SMTP real, lê o banner (mensagem 220), emita um comando

HELP para descobrir que tipo de servidor está do outro lado e desconecta. A informação

coletada é utilizada para simular uma sessão falsa mais convincente. Por um lado, se o

spammer já sabe a versão do servidor com o qual está se conectando, obterá a mesma

informação e poderá passar como o servidor real. No entanto, este método gera tráfego de

saída e pode ser detectado externamente caso o spammer tenha controle sobre o servidor

com o qual pretende se conectar. Se for detectado, pode ser utilizado para spam também.

• Smtp3: conecta ao servidor SMTP e repassa todos os comandos conhecidos exceto

DATA e EXPN. Os comandos RCPT e VRFY possuem limitação de banda. Este é o caso

mais extremo de simulação e é quase impossível ser mais perfeito, já que o comando

DATA, se for utilizado corretamente, entregaria o email e isto é algo que tentamos evitar.

A única possibilidade de detecção se dá quando o spammer percebe que todos as suas

39
http://world.std.com/~pacman/proxypot.html

Honeynets 58
 tentativas falham no mesmo ponto.

9 Implementação

Talvez o passo mais importante na condução e administração de uma Honeynet, após a

sua implementação, seja a extração e tratamento dos dados. Isto inclui a captura de toda a

atividades do sistema.

Existem diversas técnicas para examinar e tratar logs e dados coletados, sejam eles pelo

IDS, iptables, syslog ou mesmo os logs do sistema. Iremos discutir abaixo as que foram

implementadas em nossa Honeynet.

9.1 Dados Estatísticos – Analisando vários tipos de logs

Um dos grandes problemas enfrentados ao se implementar um honeypot não ocorre

apenas durante a fase de configuração do sistema, pois até mesmo um sistema mal configurado

pode se passar por um honeypot, mas sim na captura e tratamento de dados.

Em nossas pesquisas não encontramos algo totalmente definido que nos permitisse

manusear os logs como um todo. Como em nossa implementação não seria o desenvolvimento

de ferramentas para esse tipo de análise tivemos que testar várias ferramentas que se

propusessem a resolver o problema e que ao mesmo tempo tratasse vários tipos de logs. As

ferramentas escolhidas para o trabalho foram LIRE40 (Log in Report) e SnortALog41 (Snort

Analyser Logs)

40
http://logreport.org/lire/
41
http://jeremy.chartier.free.fr/snortalog/

Honeynets 59
9.1.1 LIRE – Log in Report

A ferramenta Lire é um conjunto de pacotes que automaticamente gera relatórios

tratando os logs da máquina. Essa ferramenta é capaz de tratar e gerar dezenas de relatórios

baseados nos logs de email, WEB, DNS, FTP, servidores de impressão e firewalls. O Lire é

desenvolvido pela Stichting LogReport Foundation. E outra grande vantagem do Lire é que é

uma ferramenta multi plataforma, podendo ser implementada nos seguintes ambientes:

• GNU/Linux Debian, Red Hat Linux, Mandrake Linux,

• FreeBSD (4.1-STABLE, 4.5-PRERELEASE, 4.4-STABLE),

• OpenBSD (2.7, 2.8, 2.9, 3.2), Mac OS X v 10.1)

• Solaris (SunOS 5.6 and 5.7)

• HP-UX (11.11)

• AIX (Thanks Raymond Page)

• GNU/Hurd!

Dezenas de tipos de logs podem ser analisados. Podemos ver na tabela abaixo alguns dos

tipos suportados:

• Sendmail
• Postfix
• qmail
Email:
• exim
• nms (Netscape Messenger Service)
• ArGoSoft
• DBMail
Message: • Netscape Message Store
• Netscape Messaging Multiplexor

Honeynets 60
 • Common Log Format (Apache, IIS, etc.)
• Combined Log Format (Apache, Boa, etc.)
WWW: • Referrer
• Apache mod_gzip
• W3C Extended (Microsoft IIS 4.0 & 5.0)
• DNS Bind version 8
DNS:
• DNS Bind version 9
DNS Zone: • DNS Bind version 8
• Cisco
• Cisco PIX
• ipchains
Firewall: • ipfilter
• iptables
• WELF
• Watchguard
• xferlog (WU-FTPD, ProFTPD, etc)
FTP:
• IIS FTP
• CUPS
Impressoras:
• LPRng
• Squid
Proxy: • WELF
• MS ISA
• MySQL
Banco de Dados:
• PostgreSQL
• BSD-like
• Netscape Messaging Server
• Solaris 8
Syslog:
• Kiwi Syslog Daemon
• Sendmail Switch Log
• WTSyslog
Spamfilter: • SpamAssassin
Dialup • ISDN Log

9.1.2 SnortALog (Snort Analyser Logs)

A Ferramenta SnortAlog analisa os logs gerados para todas as versões do IDS Snort. O

resultado final é de ótima qualidade, permitindo análises refinadas dos dados coletados. Ele

também é capaz de analisar logs para vários outros formatos, como o syslog, além de sumarizar

logs para o Fw-1 (NG e 4.1), netfilter e IPFilter.

O SnortAlog é um conjunto de scripts escrito em Perl que sumariza toda a informação

Honeynets 61
encontrada nos logs. Abaixo mostramos algumas aplicações e vantagens da ferramenta:

• Cria relatórios no formato HTML, PDF e textos;

• Gera a saída dos HTML com gráficos em GIF, PNG ou JPG;

• Operação via linha de comando ou interface grafica;

• Trabalha com Syslog e qualquer tipo de alertas do snort;

• Trabalha com todos os preprocessors do snort;

• Possibilita gerar relatórios para uma interface especifica do snort;

• Plugin específico para gerar as referências as regras do SNORT;

• Resolve endereços IP e domínios;

• Adiciona cores para melhorar a visibilidade;

• Possibilidade de criação de filtros para um endereço IP específico;

• Trabalha com Fw-1 (4.1 and NG) no syslog e fw logexport command;

• Trabalha com Fw-1 SmartDefense;

• Trabalha com Netfilter eIPFilter syslog logs;

• Trabalha com syslog PIX log.

9.2 Detectando assinaturas dos sistemas operacionais

Um dado muito importante ao se analisar dados coletados em um ambiente de segurança

como uma Honeynet, é o “OS FingerPrint”42 [10], ou assinatura do sistema operacional, que se

refere a impressão digital do sistema operacional. Com este dado correlacionado aos outros logs

obtidos, pode-se montar uma estatística sobre quais eventos ocorrem em quais tipos de sistemas

operacionais, e com que frequência. Estes dados podem auxiliar na elaboração de políticas de
42
Operating System FingerPrint

Honeynets 62
segurança e ajudar a proteger melhor um sistema contra ataques externos.

Ele se baseia no fato de que todos os sistemas operacionais têm características únicas,

que podem ser usadas para identificá-los. Os sistemas operacionais podem ser identificados por

algumas peculiaridades presentes no cabeçalho dos pacotes transmitidos por eles.

Existem duas formas de se detectar sistemas operacionais:

• Active FingerPrinting

• Passive FingerPrinting

9.2.1 Active FingerPrinting

Este método consiste em enviar vários pacotes mal formados, e logo em seguida analisar

a resposta fornecida pelo sistema que se deseja identificar. Geralmente, cada sistema

operacional responde de uma maneira diferente a esses pacotes. Essa técnica é utilizada pelo

NMAP43. O problema do Active FingerPrinting é que ele pode ser facilmente detectado por

algum IDS.

9.2.2 Passive FingerPrinting

O outro método existente é o Passive FingerPrinting que, apesar de ter o mesmo conceito

do método ativo, o implementa de uma maneira diferente. O Passive Fingerprinting utiliza logs

obtidos por um sniffer (capturador de pacotes) de rede, como tcpdump, ou escutando

diretamente a interface de rede, separando as conexões originadas do host desejado e

verificando as peculiaridades presentes nos cabeçalhos dos pacotes. O Passive FingerPrinting

43
www.secure.net

Honeynets 63
tem como maior vantagem ser indetectável, pois ele se utiliza de conexões normais, como um

acesso por HTTP ou SMTP. A sua principal desvantagem é que ele não é 100% confiável, já

que a identificação de cada serviço pode ser facilmente forjada.

9.3 Detectando sistemas operacionais em um Honeypot

Cada sistema operacional tem características únicas que tornam possível a detecção.

Listas completas contendo todas as assinaturas conhecidas de todos os sistemas operacionais são

mantidas em diversos lugares da Internet. Um exemplo deste tipo de lista pode ser visto em:

http://opensolutions.com.br/docs/passfing/db-passive.php

Como em nosso honeypot a intenção não é a de ir atrás do atacante e sim de esperar que

ele venha até nós, o método utilizado é a detecção passiva dos sistema operacionais.

Existem diversas ferramentas que se propõem a fazer isso, mas discutiremos apenas a

ferramenta escolhida para análise de nossa Honeynet, que é a ferramenta P0F44.

Esta ferramenta foi desenvolvida por Michal Zalewski e está sendo mantida por William

Stearns. Ela se utiliza das técnicas de Passive e Active Fingerprinting já descritas anteriormente.

Uma das vantagens da ferramenta P0F é que além de determinar o tipo de sistema

operacional de forma passiva diretamente, examinando todos os pacotes que chegam em uma

44
http://www.stearns.org/p0f/

Honeynets 64
interface de rede, pode-se também determinar estas informações através de arquivos de logs

capturados por sniffers (capturadores de pacotes) como o tcpdump45, ethereal46 ou outros. Outra

vantagem que deve ser levada em consideração é que toda a informação coletada pode ser

armazenada diretamente em um banco de dados como o Mysql, agilizando toda a busca e

correlação de dados em uma eventual verificação e análise forense da máquina.

Abaixo apresentamos o resultado obtido pela ferramenta P0F em nossa rede. Ela entrou

em operação em 22/05/2004 e coletou e identificou todos os pacotes que de alguma forma

chegaram à nossa Honeynet. O relatório tem a data final de 31/06/2004.

FingerPrint Sistema Operacional

2750
2500
2250
2000
1750
1500
1250
1000
750
500
250
0
windows Win- Linux Solaris Win- BSD Outros
95/98 dows dows NT
2000 /

Como podemos ver pelo gráfico acima, o sistema operacional predominante é Windows

9x, ou seja, este é o topo de sistema operacional que mais pacotes enviou à nossa Honeynet.

45
http://www.tcpdump.org
46
http://www.ethereal.com

Honeynets 65
Vale lembrar que esse tipo de detecção não é 100% eficaz, pois depende de vários fatores

relacionados ao pacote, que pode ser alterado em vários pontos, como roteadores e firewalls. A

quantidade de pacotes perdidos pelo caminho também pode influenciar, mas com certeza este

número dificilmente afetaria a proporção dos dados expostos aqui.

A informação aqui divulgada é apenas uma síntese, ou seja, a fim de evitar duplicidade

de informação foram sumarizados todos os dados, tomando-se o cuidado de que apenas

endereços IP únicos fossem computados, evitando que uma determinada máquina distorcesse os

dados apenas por ter enviado uma quantidade maior de pacotes, garantindo que o desvio-padrão

não fosse afetado e tornando as informações mais confiáveis.

Abaixo podemos ver como se parece uma entrada nos logs da ferramenta utilizada:

<Sun Jul 4 21:13:47 2004> 200.175.224.242:1071 - Windows 2000 SP4, XP SP1

(2)
-> 200.252.166.148:80 (distance 6, link: sometimes modem)
<Sun Jul 4 21:14:32 2004> 200.175.224.242:1072 - Windows 2000 SP4, XP SP1
(2)
-> 200.252.166.148:80 (distance 6, link: sometimes modem)
<Sun Jul 4 21:16:14 2004> 200.175.224.242:1073 - Windows 2000 SP4, XP SP1
(2)
-> 200.252.166.148:80 (distance 6, link: sometimes modem)

Neste exemplo podemos ver que no dia 4 de julho o IP 200.252.166.148 enviou um

pacote à Honeynet, tentando uma conexão na porta 80 (HTTP). Em seguida, estabeleceu-se uma

conexão à porta 1073 no cliente. Foi detectado o sistema operacional Windows 2000 ou

Windows XP, também foi determinado por características da formação do pacote (assinatura).

Assume-se também que provavelmente esta conexão seja proveniente de um modem, dada a

quantidade de hops e o tempo de ping.

Honeynets 66
9.4 Análise do IDS

O IDS nos fornece três fontes de dados:

1. Os alertas gerados pelo próprio IDS;

2. Captura dos pacotes pelo IDS;

3. Logs das sessões ASCII.

Quando qualquer atividade suspeita é detectada ela será logada pelo IDS,

conseqüentemente pacotes são capturados e armazenados em forma binária fazendo referência a

um ataque, onde poderão sofrer análise mais detalhada. Os logs de sessão ASCII seria o local

onde o IDS armazena todas as informações ASCII detectadas em cada pacote, como o

pressionamento de teclas. Todos os alertas são gravados em um banco de dados rodando Mysql.

O nosso IDS foi previamente configurado para gerar qualquer alerta quando alguma

atividade suspeita for detectada.

Para facilitar e tratar ocorrências com consulta aos histórico dos eventos coletados,

utilizamos a ferramenta ACID (Analysis Console for Intrusion Databases). Na tela abaixo,

vemos o estado do IDS em 20 de Maio de 2004.

Honeynets 67
 O ACID é uma ferramenta para manusear as informações armazenadas no banco de

dados, sendo composto por um conjunto de scripts escritos em PHP que fazem a interface entre

o banco de dados gerado pelo SNORT e o administrador do sistema. Para seu funcionamento

completo é necessário um servidor Apache com suporte a PHP.

O ACID não interage diretamente com o MySQL e sim com o ADODB47. Este módulo

faz a interação direta com o banco de dados, de forma a permitir que o desenvolvedor PHP

possa se abstrair do gerenciador de banco de dados que será usado.

O IDS Snort, em conjunto com o ACID, pode informar em tempo real o que está

acontecendo no sistema, identificando ataques baseados em assinaturas, tais como um Worm se

47
http://php.weblogs.com/adodb

Honeynets 68
propagando ou um buffer overflow.

Abaixo iremos exemplificar uma propagação de worm.

No dia 01 de abril de 2004 às 19:25 o nosso IDS Snort detectou através de sua assinatura

uma tentativa de propagação do worm MS-SQL. O IP 65.35.113.35 foi logado como origem

iniciando pela porta 1091 com destino a porta 1434 UDP. Uma rápida consulta a um servidor

Whois determinou que se tratava de uma máquina localizada nos Estados Unidos.

Consultando o banco de dados sobre o tipo de ataque, foi determinado que se tratava do

“W32/SQL Slammer.worm”, Este worm foi descoberto em janeiro de 2003 e até esta data

encontra-se ativo. Basicamente, o worm explora uma vulnerabilidade do sistema Windows na

biblioteca “ssnetlib.dll”, fazendo uma requisição na porta 1434/UDP e carregando uma

biblioteca chamada “WS2_32.DLL”. Com isto, ele consegue inserir código malicioso e infectar

o sistema. Uma vez infectado, o sistema irá propagar o worm para outros endereços da rede. A

operação de propagação do worm pode gerar um crash no servidor.

O Snort capturou e logou as informações binárias do worm, conforme mostramos

abaixo, com a impressão do payload do pacote.

Payload capturado pelo snort:

length = 376

000 : 04 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
010 : 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
020 : 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
030 : 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
040 : 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
050 : 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
060 : 01 DC C9 B0 42 EB 0E 01 01 01 01 01 01 01 70 AE ....B.........p.
070 : 42 01 70 AE 42 90 90 90 90 90 90 90 90 68 DC C9 B.p.B........h..
080 : B0 42 B8 01 01 01 01 31 C9 B1 18 50 E2 FD 35 01 .B.....1...P..5.
090 : 01 01 05 50 89 E5 51 68 2E 64 6C 6C 68 65 6C 33 ...P..Qh.dllhel3
0a0 : 32 68 6B 65 72 6E 51 68 6F 75 6E 74 68 69 63 6B 2hkernQhounthick
0b0 : 43 68 47 65 74 54 66 B9 6C 6C 51 68 33 32 2E 64 ChGetTf.llQh32.d
0c0 : 68 77 73 32 5F 66 B9 65 74 51 68 73 6F 63 6B 66 hws2_f.etQhsockf
0d0 : B9 74 6F 51 68 73 65 6E 64 BE 18 10 AE 42 8D 45 .toQhsend....B.E
0e0 : D4 50 FF 16 50 8D 45 E0 50 8D 45 F0 50 FF 16 50 .P..P.E.P.E.P..P
0f0 : BE 10 10 AE 42 8B 1E 8B 03 3D 55 8B EC 51 74 05 ....B....=U..Qt.

Honeynets 69
100 : BE 1C 10 AE 42 FF 16 FF D0 31 C9 51 51 50 81 F1 ....B....1.QQP..
110 : 03 01 04 9B 81 F1 01 01 01 01 51 8D 45 CC 50 8B ..........Q.E.P.
120 : 45 C0 50 FF 16 6A 11 6A 02 6A 02 FF D0 50 8D 45 E.P..j.j.j...P.E
130 : C4 50 8B 45 C0 50 FF 16 89 C6 09 DB 81 F3 3C 61 .P.E.P........<a
140 : D9 FF 8B 45 B4 8D 0C 40 8D 14 88 C1 E2 04 01 C2 ...E...@........
150 : C1 E2 08 29 C2 8D 04 90 01 D8 89 45 B4 6A 10 8D ...).......E.j..
160 : 45 B0 50 31 C9 51 66 81 F1 78 01 51 8D 45 03 50 E.P1.Qf..x.Q.E.P
170 : 8B 45 AC 50 FF D6 EB CA .E.P....

O payload capturado pelo Snort mostra claramente o conteúdo do worm.

9.4.1 Análise de Logs do IDS

Existem vários logs que devem ser verificados em uma Honeynet e alguns dos mais

importantes talvez sejam os logs do servidor web. No caso de nossa Honeynet, estamos

utilizando o servidor Apache, que por padrão guarda seus logs em /var/log/httpd.

Examinando o arquivo “access_log”, que armazena os registros de acessos à máquina,

encontramos algo bastante interessante: o worm Code Red.

A entrada abaixo no log denuncia o worm:

200.175.180.23 - - [19/May/2004:23:27:07 -0300] "GET /

default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 404 397 "-" "-"

200.164.252.156 - - [20/May/2004:09:25:51 -0300] "GET /

default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a
HTTP/1.0" 404 397 "-" "-"

Como podemos ver, o servidor Apache logou as informações de tentativa de

transferência do worm para a máquina informando o IP de origem e data e hora da tentativa.

Vale ressaltar que máquinas rodando sistema operacional Linux com apache, que é o caso de

Honeynets 70
nossa Honeynet, não são afetados por este worm.

O Code Red explora um sistema vulnerável através de bug explorado remotamente, que

afeta entre outros:

• Windows 2000 com IIS 4.0 ou IIS 5.0

• Microsoft Windows NT 4.0 with IIS 4.0 or IIS 5.0 ou Index Server 2.0

Quando contaminado, o sistema tenta conectar na 80 de qualquer sistema, de forma

randômica, até uma máquina vulnerável ser encontrada. Quando achada, o worm gera o HTTP

GET, com o exploit remoto (overflow) sobre o Indexing Service do IIS. Nas primeiras versões

do Code Red, eram trocados todos os arquivos “index.html” (páginas principais do sistema),

substituindo seu conteúdo pela seguinte frase:

HELLO! Welcome to http://www.worm.com! Hacked By Chinese!

9.5 Análise do ProxyPot

O ProxyPot é responsável pela simulação de proxies abertos, e pela coleta de dados

referentes a tentativas de envio de spam através de nossa rede. É componente essencial na

implementação de uma Honeynet, visto que a disseminação de spam é um dos principais

problemas da Internet hoje em dia, e merece ser estudado em detalhes.

Nosso ProxyPot precisava ser configurado para ter alto nível de interatividade com os

spammers, de tal forma que parecesse realmente com um proxy aberto, levantando o mínimo

possível de suspeitas sobre o fato de ser apenas uma simulação. Outro requisito era de que ele

não monopolizasse a banda disponível, nem capturasse dados em excesso, pois os recursos

Honeynets 71
disponíveis poderiam não ser suficientes.

A configuração do ProxyPot é relativamente simples: como se trata de um script em Perl,

todos os parâmetros configuráveis são na verdade variáveis a serem definidas no cabeçalho do

script.

A seguir, comentaremos cada um dos valores utilizados em nosso experimento.

my $logfile='/home/log/proxypot';

O local e o nome do arquivo de log que será gerado.

my $logrotate_seconds=86400;

A cada 86400 segundos (24 horas), o arquivo de log em uso será fechado e arquivado.

Um novo arquivo será criado, e o processo continuará. A rotação de logs impede que os

arquivos de log cresçam demais, dificultando a sua análise posterior.

my $mbox=undef;
my $maildir=undef;

Estas duas opções especificam um local para onde todas as mensagens coletadas serão

enviadas, em formato “mailbox” do UNIX. Inicialmente, estas duas opções foram ativadas, mas

a quantidade de arquivos gerados foi excessiva, sendo desativadas depois.

my $max_kilobytes_per_second=10;
my $max_connects_per_destination_host_per_10_minutes=10;
my $max_connects_per_destination_C_per_10_minutes=50;
my $max_connects_per_destination_B_per_10_minutes=200;
my $max_connects_per_destination_any_per_10_minutes=300;
my $max_simultaneous_connections_per_client_host=10;
my $max_simultaneous_connections_per_client_C=15;
my $max_simultaneous_connections_per_client_B=40;
my $max_simultaneous_connections_per_client_any=50;

Estas opções determinam o comportamento do ProxyPot em relação ao uso de banda e

CPU. São determinadas: taxa de transferência máxima em Kbytes; as quantidades máximas de

conexões remotas por classe de IP a cada 10 minutos; número máximo de conexões

simultâneas por classe de IP a cada 10 minutos.

Honeynets 72
my @incoming = (
[ http => 3128 ],
[ http => 8080 ],
[ socks => 1080 ],
[ wingate => 23 ]
);
my @selfaddrs=qw/ 0.0.0.0 /;

Nesta opção, definimos quais serviços serão simulados. No caso, estamos simulando

todos os serviços suportados pelo ProxyPot: Squid (porta 3128/8080), SOCKS (porta 1080) e

Wingate (porta 23). A opção “selfaddrs” define em quais endereços o ProxyPot deverá ouvir por

conexões. No caso, optamos por ouvir em todas as interfaces disponíveis.

my $max_real_proxy_chain_length=10;
my $max_fake_proxy_chain_length=100;

Aqui definimos que proxy chaining será permitido , com uma cascata de até 10 conexões

remotas, e após isso, simulará até 100 conexões em proxy chaining internamente.

my $direct_http_commands=1;
my $smtp_servertype_default='postfix';

Permitiremos comandos do tipo “HTTP CONNECT”, em que o spammer pede para se

conectar em um endereço remoto e faça, por exemplo, proxy chaining. A segunda opção

determina que, caso não seja possível determinar qual o tipo de servidor utilizado remotamente,

envie cabeçalhos de postfix (um servidor de mail) para o spammer.

my @allow_deny = (
# coming from connecting to to port range action
[ '0.0.0.0/0', '127.0.0.0/8', 0 => 65535, 'deny' ],
[ '0.0.0.0/0', '10.0.0.0/8', 0 => 65535, 'deny' ],
[ '0.0.0.0/0', '172.16.0.0/12', 0 => 65535, 'deny' ],
[ '0.0.0.0/0', '192.168.0.0/16', 0 => 65535, 'deny' ],
[ '0.0.0.0/0', 'self/32', 0 => 65535, 'deny' ],
[ '0.0.0.0/0', '0.0.0.0/0', 25 => 25, 'smtp2' ],
[ '0.0.0.0/0', '0.0.0.0/0', 587 => 587, 'smtp2' ],
# [ '0.0.0.0/0', '0.0.0.0/0', 80 => 80, 'http1' ],
[ '0.0.0.0/0', '0.0.0.0/0', 1080 => 1080, 'socks1' ],
[ '0.0.0.0/0', '0.0.0.0/0', 3128 => 3128, 'httpc1' ],
[ '0.0.0.0/0', '0.0.0.0/0', 8080 => 8080, 'httpc1' ],
# [ '0.0.0.0/0', 'client/32', 1024 => 65535, 'raw' ],
[ '0.0.0.0/0', '0.0.0.0/0', 0 => 65535, 'banner' ]
);

Honeynets 73
 Esta é a tabela de permissões utilizada pelo ProxyPot para permitir ou negar conexões.

As primeiras 5 linhas determinam que conexões em endereços inválidos ou para si mesma

devem ser negadas. Um método muito comum utilizado pelos spammers para saber se um

servidor é simulado ou não é justamente pedir para conectar em endereços inválidos, coisa que

um servidor real jamais aceitaria.

As conexões nas portas 25 e 587 serão aceitas de qualquer origem, e serão tratadas pelo

método “smtp2”. Este método faz com que o ProxyPot se conecte ao servidor real de SMTP,

leia a mensagem (banner 220), dê um comando “HELP” para descobrir a versão utilizada e

desconecte. A informação coletada então é repassada para o spammer, simulando uma transação

de forma mais convincente. Optamos por este método por ser o mais convincente sem utilizar

demasiada banda, já que o próximo método disponível (smtp3) repassa todos os comandos do

spammer diretamente ao servidor.

As portas 1080 e 3128/8080 são tratadas pelos métodos “socks1” e “httpc1”,

respectivamente. Os dois métodos aceitam e simulam as conexões, mas não conectam a hosts

externos. Optamos por utilizar estes métodos porque caso as conexões de SOCKS e SQUID

sejam totalmente repassadas aos seus destinos remotos, o spammer pode ter um controle

excessivo sobre o nosso servidor, forçando-o a utilizar banda em excesso e possivelmente

causando um Denial of Service.

Decidimos evitar conexões em modo “raw” pelo mesmo motivo. Não permitimos

conexões na porta 80, pois a nossa intenção era a de rodar um servidor web e analisar o log

deste separadamente.

A última regra permite que conexões em qualquer outra porta sejam repassadas à rotina

interna que tenta encontrar um serviço válido no sistema e tenta pegar a mensagem de

identificação para repassar ao spammer.

Honeynets 74
9.5.1 Análise dos logs do proxypot

Durante as cerca de duas semanas em que o proxypot ficou ativo e capturando dados,

obtivemos aproximadamente 800 mb de mensagens de spam, sendo que, por diversas vezes o

disco da máquina ficou cheio e parou de logar eventos em algumas ocasiões.

Para analisar a massa de dados obtida, utilizamos duas ferramentas para processar os

logs:

• log2mbox: processa os logs gerados, e extrai todas as mensagens capturadas, gerando

arquivos individuais para cada uma das mensagens, no formato Mailbox (padrão do UNIX).

Uma vez extraídas, estas mensagens podem ser lidas ou analisadas a partir de scripts ou

clientes de email padrões.

• Spamstat: o spamstat gera estatísticas sobre as mensagens extraídas pelo log2mbox. Pode-se

gerar diversas estatísticas úteis, tais como:

• IP's ou faixas de IP encontradas;

• endereços de email referenciados;

• números de telefones referenciados;

• tamanhos máximos e mínimos de mensagem (em bytes);

• quantidade de mensagens enviadas por cada host;

• etc.

Honeynets 75
 Os logs que foram gerados originalmente pelo ProxyPot possuem o formato apresentado

abaixo:

Thu Apr 29 19:53:51 2004 83353,1083279231: accepted connection on

200.252.166.148:1080 from 65.110.14.164:2359, created process 16227
Thu Apr 29 19:53:52 2004 Got new connection from 207.36.118.85 with 50
already active. Dropping the new connection.
Thu Apr 29 19:53:54 2004 Cleaned up child process 16179
Thu Apr 29 19:53:54 2004 83338,1083279199: client HELO name: "mwf-
direct.co.uk"
Thu Apr 29 19:53:54 2004 83349,1083279227: receiving socks version 5 request
Thu Apr 29 19:53:54 2004 83348,1083279222: SMTP banner: "220
mx01.mrf.mail.rcn.net ESMTP [NO UCE] RCN Exim 3.35 #7 SD NASTD Thu, 29 A
pr 2004 18:54:17 -0400\r\n"
Thu Apr 29 19:53:54 2004 83348,1083279222: sending HELP probe
Thu Apr 29 19:53:54 2004 83337,1083279199: msg 1: recipient RCPT
TO:<"holezinface@netscape.net">
Thu Apr 29 19:53:54 2004 83344,1083279211: starting new message 1 with MAIL
FROM:<"noemianthony_rm@yahoo.co.uk">
Thu Apr 29 19:53:54 2004 83347,1083279222: SMTP banner: "220 galesburg.net
running Eudora Internet Mail Server 3.2.1\r\n"
Thu Apr 29 19:53:54 2004 83347,1083279222: sending HELP probe
Thu Apr 29 19:53:54 2004 83339,1083279200: msg 1: recipient RCPT
TO:<"marxdhm@hotmail.com">
Thu Apr 29 19:53:55 2004 83354,1083279234: accepted connection on
200.252.166.148:1080 from 65.110.14.183:1444, created process 16228
Thu Apr 29 19:53:55 2004 83345,1083279211: looks like a webshield server
Thu Apr 29 19:53:55 2004 83345,1083279211: using hostname utvprimary.com
Thu Apr 29 19:53:55 2004 Got new connection from 65.110.14.160 with 50
already active. Dropping the new connection.
Thu Apr 29 19:53:55 2004 83343,1083279209: SMTP banner: "220-rly-
na06.mx.aol.com ESMTP mail_relay_in-na6.4; Thu, 29 Apr 2004 18:54:18
-0400\r\n220-America Online (AOL) and its affiliated companies do
not\r\n220- authorize the use of its proprietary computers and
computer\r\n220- networks to accept, transmit, or distribute unsolicited
bulk\r\n220- e-mail sent from the internet. Effective immediately: AOL
\r\n220- may no longer accept connections from IP addresses which
\r\n220 have no reverse-DNS (PTR rec
ord) assigned.\r\n"

No log acima, podemos ver o procedimento básico do ProxyPot. O ProxyPot se faz

passar por um proxy aberto. Como foi configurado com o método “smtp2”, nossa máquina se

conecta ao servidor remoto, captura o banner de identificação, a versão do servidor, e repassa ao

spammer para simular a sessão. Também podemos ver o ProxyPot recusando novas conexões de

um spammer, que já possuía 50 conexões com o nosso endereço.

Um exemplo do log processado pode ser visto abaixo. Neste log, podemos ver

estatísticas sobre cada bloco de IP's referenciado, incluindo a quantidade de mensagens que

Honeynets 76
foram enviadas a partir deste, e a distribuição de cada tipo de spam enviado. No caso, podemos

ver as referências a diversos endereços de sites de produtos que estavam sendo vendidos pelo

spammer, e quantos bytes teriam sido enviados para usuários da Internet caso as mensagens

tivessem sido entregues aos seus destinatários.

/24 statistics:
209.249.6/24 sent 57434 messages
total 48182721 bytes to 57434 recipients
[209.249.6/24] web site statistics:
[209.249.6/24] surerxpills.com was referenced by 11804 messages
[209.249.6/24] total 11047925 bytes to 11804 recipients
[209.249.6/24] surerxpalace.com was referenced by 11745 messages
[209.249.6/24] total 11000113 bytes to 11745 recipients
[209.249.6/24] surerxmed.com was referenced by 11703 messages
[209.249.6/24] total 10931949 bytes to 11703 recipients
[209.249.6/24] surerxmd.com was referenced by 11701 messages
[209.249.6/24] total 10916739 bytes to 11701 recipients
[209.249.6/24] surerxsource.com was referenced by 11651 messages
[209.249.6/24] total 10910637 bytes to 11651 recipients
[209.249.6/24] dsfgreffg.com was referenced by 1537 messages
[209.249.6/24] total 1423784 bytes to 1537 recipients
[209.249.6/24] bajdhdmfg.com was referenced by 1532 messages
[209.249.6/24] total 1415993 bytes to 1532 recipients
[209.249.6/24] bnjvhucxf.com was referenced by 1529 messages
[209.249.6/24] total 1415514 bytes to 1529 recipients
[209.249.6/24] cvnstd4sb.com was referenced by 1525 messages
[209.249.6/24] total 1410795 bytes to 1525 recipients
[209.249.6/24] acafsfw3b.com was referenced by 1495 messages
[209.249.6/24] total 1383017 bytes to 1495 recipients
[209.249.6/24] 66222 references to 10 distinct web sites

Exemplo de log processado.

9.5.2 Técnicas utilizadas pelos spammers

Analisando os logs ainda sem processamento, podemos verificar diversas das técnicas

utilizadas pelos spammers.

Wed Apr 7 17:51:47 2004 15266,1081371107: accepted connection on

200.252.166.148:3128 from 209.249.6.97:49319, created process 23169
Wed Apr 7 17:51:47 2004 15266,1081371107: received HTTP command from
client: "CONNECT 205.158.62.137:25 HTTP/1.0\r\n"
Wed Apr 7 17:51:47 2004 15266,1081371107: allowing request for connection
to 205.158.62.137:25
Wed Apr 7 17:51:47 2004 15258,1081371098: starting new message 2 with MAIL
FROM:<"tyekmzlu@xitech.freeserve.co.uk">
Wed Apr 7 17:51:47 2004 15266,1081371107: connection succeeded
Wed Apr 7 17:51:47 2004 15267,1081371107: accepted connection on

Honeynets 77
200.252.166.148:8080 from 209.249.6.97:49439, created process 23170

No exemplo acima, vemos um proxy chaining em progresso. O spammer conectou-se ao

nosso servidor na porta 3128 (SQUID), e pediu para se conectar ao endereço remoto

205.158.62.137 na porta 25 (SMTP) através do comando HTTP CONNECT.

Wed Apr 7 11:36:47 2004 2299,1081348599: msg 5: recipient RCPT

TO:<"ditadarlin@yahoo.co.uk">
Wed Apr 7 11:36:47 2004 2287,1081348589: starting new message 11 with MAIL
FROM:<"jneely_tb@kali.com.cn">
Wed Apr 7 11:36:48 2004 2299,1081348599: msg 5: DATA beginning
Wed Apr 7 11:36:48 2004 2304,1081348606: unfriendly SMTP banner: "550
<unknown[200.252.166.148]>: Client host rejected:
REJECT \" Spam not accepted from Comite Gestor da Internet no Brasil\"\r\n"

No exemplo acima, vemos uma mensagem sendo recusada pelo servidor remoto.

Possivelmente, o nosso próprio IP pode ter entrado em uma blacklist, ou o servidor está

configurado para aceitar apenas conexões de outros servidores cadastrados.

Wed Apr 7 13:57:38 2004 6886,1081357057: SMTP banner: "220

superpib.pib.com.br ESMTP Prointernet do Brasil (http://www.pib.com.br)\r\n"

Wed Apr 7 13:57:38 2004 6886,1081357057: sending HELP probe

Wed Apr 7 13:57:38 2004 6887,1081357057: client EHLO name:
"gjr.paknet.com.pk"
Wed Apr 7 13:57:39 2004 6887,1081357057: starting new message 1 with MAIL
FROM:<"aurelia_simmons_sp@orion.toppoint.de">
Wed Apr 7 13:57:39 2004 6887,1081357057: msg 1: recipient RCPT
TO:<"martha@mountain.net">

==================

Thu Apr 8 03:41:21 2004 36354,1081406478: starting mostly-fake SMTP session

Thu Apr 8 03:41:21 2004 36354,1081406478: SMTP banner: "220-InterScan

Version 3.8-Build_1080 $Date: 01/31/2003 16:12:00
37$: Ready\r\n220--------------------------------------------------------
\r\n220- ANTENNA.TOLEDO.BR\r\
n220- Servico de Correio Eletronico Internet (E-MAIL)\r\n220-Faculdades
Integradas Toledo - Aracatuba - SP - Brasil\r\
n220--------------------------------------------------------\r\n220 \r\n"

Acima podemos ver dois servidores brasileiros sendo utilizados para enviar spam.

Basicamente, estes servidores não possuem nenhuma proteção, aceitando mensagens de

Honeynets 78
qualquer host. Também não se utiliza nenhum tipo de checagem online em blacklists,

facilitando imensamente o trabalho do spammer. Uma das principais consequências para os

donos destes servidores é o fato de poderem ter seus IP's bloqueados em blacklists mundiais, de

forma que os seus usuários poderão ser prejudicados e terem suas mensagens bloqueadas.

Return-Path: <nbucdoiwqsunxa@qas34de.com>
Delivered-To: <hirshberg@hws.edu>
Delivered-To: <hitmark@hws.edu>
Delivered-To: <hjjcl@hws.edu>
Delivered-To: <hjl@hws.edu>
Received: from 66.153.24.60 ([64.62.141.245]) by obscura
with SMTP via SOCKS5 id "19777,1081378601,1"
(attempted proxy to 66.153.24.60);
Wed, 07 Apr 2004 19:56:46 -0300
X-Message-Info: %HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO%
HEADER_RANDOMIZER_TAG%HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO
Received: from tauruslitmus ([112.40.8.108])
by %HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO-.
countryman.unesco.deplore.%HEADER_SMTP_RDM
(%HEADER_RDM_MAILERS %NEW_HEADER_RDM_DIGITS%NEW_HEADER_RDM_DIGITS%
NEW_HEADER_RDM_DIGITS) (LSMTP for Windows NT v1.1b) with
SMTP id
id <%THE2_HEADER_RND_DIGITS_2%THE2_HEADER_RND_DIGITS_2.%
THE2_HEADER_RND_DIGITS_2.%HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO.%HE
ADER_X_MSSG_INFO%HEADER_X_MSSG_INFO-.%HEADER_X_MSSG_INFO.%
HEADER_X_MSSG_INFO.%HEADER_SMTP_RDM%HEADER_RANDOMIZER_TAGfumflanders>
for <hirshberg@hws.edu>; Tue, 06 Apr 2004 17:09:16 -0700
Received: from who've ([143.24.75.115])
by %HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO-.
exonerate.boyd.mournful.%HEADER_SMTP_RDM
(%HEADER_RDM_MAILERS %NEW_HEADER_RDM_DIGITS%NEW_HEADER_RDM_DIGITS%
NEW_HEADER_RDM_DIGITS) (LISTSERV-TCP/IP release 1.8d) wit
h ESMTP id
id <%THE2_HEADER_RND_DIGITS_2.%THE2_HEADER_RND_DIGITS_2%
THE2_HEADER_RND_DIGITS_2.%HEADER_X_MSSG_INFO%HEADER_X_MSSG_INFO.%HE
ADER_X_MSSG_INFO%HEADER_X_MSSG_INFO-.%HEADER_X_MSSG_INFO.%
HEADER_X_MSSG_INFO.%HEADER_SMTP_RDM%HEADER_RANDOMIZER_TAGborden1>
for <hirshberg@hws.edu>; Tue, 06 Apr 2004 21:02:16 -0300
Message-ID: <h[22

No exemplo acima, podemos ver um caso de mensagem de spam que não deu certo. A

conexão foi feita em nosso servidor através do protocolo SOCKS (porta 1080). Obviamente o

spammer não soube configurar o próprio programa, e ao invés de uma mensagem válida, enviou

uma mensagem com todos os nomes de variáveis no lugar. Podemos perceber a quantidade de

números randômicos utilizados no cabeçalho para gerar ID's de mensagem (%

THE2_HEADER_RND_DIGITS_2), e strings de identificação de programas de email e/ou

Honeynets 79
servidores (%HEADER_RDM_MAILERS).

Return-Path: <pofwqcxnf@ybdyv.org>
Delivered-To: <agcfrjg@fcyxkun.edu>
Received: from ybdyv.org ([207.6.179.155]) by slaughterhouse
with SMTP via SOCKS4 id "105249,1083317559,1"
(attempted proxy to 207.6.179.155);
Fri, 30 Apr 2004 06:32:47 -0300
From: <pofwqcxnf@ybdyv.org>

Message-Id: <8bac01c42e8c$732bb580$f5aed19e@pofwqcxnf
Date: Fri, 30 Apr 2004 00:23:43 -0800
Subject: lbt xnopywj cnnr ghx oowq ktwmb
To: <agcfrjg@fcyxkun.edu>

Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

aah ji hdwa b s lcla lphxf ywcl gjtx ssm lyvq xpf wsbu k pdct gldt rq
vfojcvdw bl rhi msdpc
fb wpn hly xcht

Aqui podemos ver outra técnica comum entre os spammers: para detectar se o proxy é

simulado ou não, na primeira vez em que se conecta ao proxy, é enviada uma mensagem

legítima para um endereço de email válido (no caso, agcfrjg@fcyxkun.edu) de um servidor que

o spammer controla. O programa então espera que esta mensagem chegue ao seu destino para

confirmar que se trata de um proxy aberto válido. O conteúdo da mensagem geralmente é

randômico ou em branco.

Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><font color=3D"#fffffg"><center>biota hungarian a=

ttestation crescent tropopause nirvana quirt commodore imprecate hoar iner=
adicable myth poor potato toilsome catechism crop notorious councilman int=
estinal turk phone indwell edith=20</font></center>
<center><a<center><font face=3D"Verdana" size=3D2>
<a href=3D"http://www.trendhost.org/download1/rol1/index.html"><img
src=3D"http://www.trendhost.org/download1/rol1/cdlg.gif"
border=3D0 width=3D506 height=3D394></a><br>
<br>
<a href=3D"http://www.trendhost.org/download1/rol1/index.html">Locate
and find out anything you'd ever wanted to know about<br>
your boss, spouse, friends, relatives, anyone! Instant unlimited<br>
access to a database of 211+ million U.S. citizens.</a><br>
&nbsp;<br>
<br>
<font color=3D"#fffffg"><center>faulty use trigonal condiment squawroot wo=
mbat calcite maxima quasiparticle mclean tanya conqueror shanty each argin=

Honeynets 80
ine angelina green carport chiang grizzle furious sikorsky boldface galeni=
te frock spectrograph mendacious=20</font></center>

Esta é outra técnica que vem sendo utilizada com cada vez mais frequência pelos

spammers. Para dificultar a detecção de spams por filtros inteligentes (tais como redes

Bayesianas), os programas utilizados pelos spammers incluem blocos de palavras aleatórias,

tornando quase impossível determinar um padrão para os textos utilizados nas mensagens de

propaganda.

9.5.3 Dados estatísticos do ProxyPot

Durante o processo de análise dos logs do ProxyPot, encontramos algumas curiosidades

estatísticas, que demonstram claramente a maneira como os spammers operam. A seguir

comentaremos algumas destas curiosidades.

9.5.3.1 Número de Mensagens por Classe C

Honeynets 81
 Mensagens por Classe C
209.249.6/24 211.220.62/24
65.110.14/24 211.106.212/24
211.157.100/24 211.104.227/24
65.75.162/24 82.114.48/24
216.143.159/24 211.104.219/24
207.36.118/24 211.104.228/24
142.166.250/24 68.160.101/24
218.78.209/24 211.193.110/24
44,22% 64.221.150/24 211.63.169/24
64.62.141/24 157.25.5/24
209.213.221/24 211.193.90/24
211.193.102/24 216.209.252/24
65.182.128/24 218.30.124/24
207.179.133/24
37,20%
1,03%
1,18% 128.206.182/24
1,40%
1,90% 65.40.146/24
3,55%
4,44% 211.193.109/24
128.206.150/24
211.193.91/24
211.193.186/24
211.197.66/24
69.34.193/24
218.154.135/24
211.197.63/24

No gráfico acima, analisando a quantidade de mensagens emitidas por cada bloco classe

C de IP, podemos notar que boa parte do tráfego coletado foi originado em 2 únicos blocos de

IP.

Possivelmente, pertencentes a spammers diferentes, mas que geram alto volume de mensagens

diárias.

9.5.3.2 Bytes por Classe C

Honeynets 82
 Bytes por Classe C
209.249.6/24 211.220.62/24
65.110.14/24 211.106.212/24
211.157.100/24 211.104.227/24
65.75.162/24 82.114.48/24
216.143.159/24 211.104.219/24
207.36.118/24 211.104.228/24
142.166.250/24 68.160.101/24
68,82% 218.78.209/24 211.193.110/24
13,22% 64.221.150/24 211.63.169/24
64.62.141/24 157.25.5/24
3,77% 209.213.221/24 211.193.90/24
211.193.102/24 216.209.252/24
7,11% 65.182.128/24 218.30.124/24
207.179.133/24
128.206.182/24
65.40.146/24
211.193.109/24
128.206.150/24
211.193.91/24
211.193.186/24
211.197.66/24
69.34.193/24
218.154.135/24
211.197.63/24

Aqui podemos ver a distribuição de bytes enviados por cada bloco classe C de IP. A

maior quantidade de bytes foi enviada pelo segmento 65.110.14/24, que também foi responsável

por boa parte da quantidade de mensagens enviadas durante todo o período. Um fato

interessante é que mesmo representando uma fatia menor da quantidade de mensagens, ele

gerou mais tráfego, por possuir mensagens individuais de maior tamanho.

Honeynets 83
9.5.3.3 Número de Mensagens por País

Número de Mensagens por País

Estados Unidos
Austrália
Estados Unidos 54,82% Coréia do Sul
Holanda
Canadá
Austrália 6,06% China
Coréia do Sul 0,46%
Rússia
Canadá 38,64%

Numa análise mais simplista, podemos separar todo o tráfego pelas regiões do mundo de

onde se originou todo o tráfego coletado. Os Estados Unidos geraram mais de 54% de todas as

mensagens coletadas, tendo logo em seguida o Canadá, com 38%. Percebemos a quase ausência

da China, que é considerada uma das maiores geradoras de spam do mundo. Eventualmente,

dado o tempo suficiente para coletar dados, nosso proxy aberto seria descoberto por um

spammer chinês, ou que estivesse contratando serviços de spammers chineses.

Honeynets 84
9.5.3.4 Bytes por País

Bytes por País

Coréia do Sul 0,30% Austrália 11,27% Estados Unidos

Estados Unidos 18,48% Austrália
Coréia do Sul
Holanda
Canadá
Canadá 69,92% China
Rússia

Aqui vemos novamente o Canadá gerando o maior tráfego dentre todos os países. Vale

lembrar que na distribuição de mensagens por classe C, mostrada anteriormente, o segmento

65.110.14/24 era o maior responsável pelo uso de banda. Este segmento de IP se localiza no

Canadá.

Honeynets 85
9.5.3.5 Número de Mensagens por IP

Mensagens por IP
209.249.6.97 207.179.133.85 211.197.66.205
209.249.6.96 142.166.250.133 211.104.228.136
209.249.6.98 218.78.209.62 68.160.101.144
65.110.14.161 64.62.141.247 211.157.100.53
65.110.14.160 64.62.141.248 211.193.110.195
65.110.14.162 128.206.182.147 211.220.62.244
209.249.6.99 65.40.146.190 211.63.169.159
209.249.6.101 65.110.14.182 157.25.5.250
65.110.14.187 211.193.109.240 211.193.90.41
8732 9681 9902 209.249.6.103 64.62.141.243 216.209.252.112
6375 10150 65.110.14.163 64.62.141.246 68.160.101.140
6297 10543 209.249.6.100 64.62.141.245 218.30.124.35
5645
65.75.162.20 64.62.141.244
65.110.14.183 128.206.150.85
209.249.6.102 64.62.141.241
65.110.14.164 211.193.91.156
65.110.14.167 211.193.186.198
211.157.100.52 218.154.135.42
211.157.100.51 69.34.193.60
216.143.159.73 211.197.63.36
207.36.118.85 211.197.66.128
64.221.150.23 211.193.186.122
142.166.250.216 211.220.62.24
209.213.221.204 211.106.212.185
211.193.102.223 211.104.227.41
65.182.128.81 218.78.209.59
218.78.209.61 82.114.48.40
218.78.209.41 211.104.219.153

Na distribuição de mensagens enviadas por IP, percebemos um indício curioso sobre os

métodos utilizados pelos spammers: eles balanceam a carga entre diversos endereços IP de

origem, muitas vezes sub-redes inteiras, um IP por vez, de forma que qualquer tentativa de

bloqueio automático por IP específico por parte da vítima (o proxy aberto) seja inútil. Esta tática

também permite que o spammer permaneça relativamente oculto em sites de grande movimento.

Como a distribuição de conexões será igual, não chamará a atenção de um administrador mais

desatento, pois nas estatísticas não existirá nenhum IP específico que se destaque.

Honeynets 86
9.5.3.6 Bytes por IP

Bytes por IP
209.249.6.97 207.179.133.85 211.197.66.205
209.249.6.96 142.166.250.133 211.104.228.136
209.249.6.98 218.78.209.62 68.160.101.144
65.110.14.161 64.62.141.247 211.157.100.53
65.110.14.160 64.62.141.248 211.193.110.195
65.110.14.162 128.206.182.147 211.220.62.244
209.249.6.99 65.40.146.190 211.63.169.159
209.249.6.101 65.110.14.182 157.25.5.250
65.110.14.187 211.193.109.240 211.193.90.41
209.249.6.103 64.62.141.243 216.209.252.112
65.110.14.163 64.62.141.246 68.160.101.140
209.249.6.100 64.62.141.245 218.30.124.35
8,99% 12,25% 13,64%
65.75.162.20 64.62.141.244
65.110.14.183 128.206.150.85
8,12%
7,58% 209.249.6.102 64.62.141.241
65.110.14.164 211.193.91.156
65.110.14.167 211.193.186.198
5,97% 6,08% 5,88% 211.157.100.52 218.154.135.42
211.157.100.51 69.34.193.60
216.143.159.73 211.197.63.36
207.36.118.85 211.197.66.128
64.221.150.23 211.193.186.122
142.166.250.216 211.220.62.24
209.213.221.204 211.106.212.185
211.193.102.223 211.104.227.41
65.182.128.81 218.78.209.59
218.78.209.61 82.114.48.40
218.78.209.41 211.104.219.153

Vemos novamente o mesmo método sendo aplicado aqui na distribuição por bytes.

Destacamos no gráfico os endereços IP que vão de 65.110.14.160 a 65.110.14.190. Todos estes

endereços enviaram praticamente a mesma quantidade de bytes, criando um gráfico homogêneo.

Da mesma forma, nenhum dos endereços IP se destacaria em uma ferramenta de monitoração,

pois nenhuma se sobressai dentre as outras.

Honeynets 87
9.5.3.7 Destinatários por IP

Destinatários por IP
209.249.6.97 207.179.133.85 211.197.66.205
209.249.6.96 142.166.250.133 211.104.228.136
209.249.6.98 218.78.209.62 68.160.101.144
65.110.14.161 64.62.141.247 211.157.100.53
65.110.14.160 64.62.141.248 211.193.110.195
65.110.14.162 128.206.182.147 211.220.62.244
209.249.6.99 65.40.146.190 211.63.169.159
209.249.6.101 65.110.14.182 157.25.5.250
65.110.14.187 211.193.109.240 211.193.90.41
209.249.6.103 64.62.141.243 216.209.252.112
65.110.14.163 64.62.141.246 68.160.101.140
209.249.6.100 64.62.141.245 218.30.124.35
65.75.162.20 64.62.141.244
65.110.14.183 128.206.150.85
5,92% 8,70% 209.249.6.102 64.62.141.241
5,48% 9,73% 65.110.14.164 211.193.91.156
4,81% 65.110.14.167 211.193.186.198
4,29%
211.157.100.52 218.154.135.42
211.157.100.51 69.34.193.60
3,83%
3,62% 216.143.159.73 211.197.63.36
207.36.118.85 211.197.66.128
64.221.150.23 211.193.186.122
142.166.250.216 211.220.62.24
209.213.221.204 211.106.212.185
211.193.102.223 211.104.227.41
65.182.128.81 218.78.209.59
218.78.209.61 82.114.48.40
218.78.209.41 211.104.219.153

Outra técnica padrão utilizada pelos spammers: distribuir a quantidade de destinatários

por cada mensagem enviada de forma homogênea. O principal motivo deste comportamento é

simplesmente evitar sobrecarregar os proxies abertos que foram encontrados. Proxies abertos

são a principal ferramenta de trabalho de um spammer, um recurso que pode se tornar escasso se

abusado. Eles merecem ser poupados, de forma a não chamar a atenção dos administradores e

ter o serviço bloqueado para uso dos spammers.

Honeynets 88
9.5.3.8 Referências por endereço

Referências por Endereço

surerxpills.com custombright.com
surerxpalace.com via-host.org
12000 surerxmed.com islamonline.net
11000 surerxmd.com co.kr
10000 surerxsource.com thesea67025pills.biz
kermitdoc.com emails.it
9000
onthewebmeds.com emails.no
8000
pharmacy.an yahoo.com
7000 pharmacy2you.com 179bcj.biz
6000 dsfgreffg.com 767gug.biz
5000 bajdhdmfg.com 284njw.biz
bnjvhucxf.com
4000
cvnstd4sb.com
3000
acafsfw3b.com
2000 trendhost.org
1000 61.109.247.95
0 techred3697tabs.biz
rdiscovr.com
Referências
cutesite.biz

Um dos recursos interessantes da ferramenta spamstat é poder separar endereços

eletrônicos, telefones, domínios e URLs referenciados no texto das mensagens. Aqui podemos

ver a quantidade de referências a domínios encontrados em todas as mensagens capturadas pelo

nosso honeypot. A maior parte das mensagens referenciava, alternadamente, diversos sites que

vendem remédios sem receita pela Web. Investigando a propriedade destes domínios,

verificamos que alguns deles possivelmente são de uma mesma empresa (surerxmeds.com,

surerxmd.com, surerxpills.com, surerxpalace.com, surerxsource.com), enquanto outros

(kermitdoc.com) constam como “ACCOUNT SUSPENDED” no whois. A grande maioria

utiliza informações falsas no registro de domínios. Muitas destas empresas registram dezenas de

domínios de uma só vez, e quando são bloqueados, registram outros para continuar enviando

spam.

Um dos sites chama a atenção, por parecer utilizar exclusivamente recursos brasileiros, e

ainda estar ativo, de acordo com a consulta ao whois:

Honeynets 89
domain: onthewebmeds.com
status: production
owner: Jonathan Goldburg
email: jonathan_goldburg@hotmail.com
address: 1601 Rio Grand
city: Austin
state: TX
postal-code: 78701
country: US
admin-c: jonathan_goldburg@hotmail.com#0
tech-c: jonathan_goldburg@hotmail.com#0
billing-c: jonathan_goldburg@hotmail.com#0
nserver: ns3.route.antipuff.nom.br
nserver: ns4.route.antipuff.nom.br
nserver: ns3.samaritanos.biz
nserver: ns4.samaritanos.biz
registrar: JORE-1
created: 2003-12-22 06:06:49 UTC JORE-1
modified: 2004-04-13 17:33:41 UTC JORE-1
expires: 2004-12-22 01:06:31 UTC
source: joker.com

Note a utilização de contas de webmail gratuitas para contatos financeiros e técnicos. O

endereço é possivelmente falso. Não se vê relação entre os domínios dos servidores de DNS

utilizados, nem entre si, nem em relação ao domínio e atividade principal (venda de remédios).

Possivelmente, estes servidores são utilizados sem autorização de seus donos.

9.5.3.9 Bytes Enviados por Endereço

No gráfico abaixo, vemos novamente o mesmo fenômeno se repetindo. A quantidade de

bytes enviados é distribuída entre cada endereço referenciado. Provavelmente, este tipo de

técnica deve permitir ao spammer balancear a carga no DNS, caso possíveis vítimas decidam

realmente seguir os links enviados nos spams. Agrupando-se a carga para diversos endereços

diferentes, o spammer pode também coletar estatísticas mais precisas medindo a efetividade de

cada um dos lotes de spam enviados.

Honeynets 90
 Bytes enviados x Endereço
surerxpills.com custombright.com
surerxpalace.com via-host.org
14000000 surerxmed.com islamonline.net
13000000 surerxmd.com co.kr
12000000 surerxsource.com thesea67025pills.biz
11000000 kermitdoc.com emails.it
10000000 onthewebmeds.com emails.no
9000000 pharmacy.an yahoo.com
8000000 pharmacy2you.com 179bcj.biz
7000000 dsfgreffg.com 767gug.biz
6000000 bajdhdmfg.com 284njw.biz
5000000 bnjvhucxf.com
4000000 cvnstd4sb.com
3000000 acafsfw3b.com
2000000 trendhost.org
1000000
61.109.247.95
0
techred3697tabs.biz
Bytes rdiscovr.com
cutesite.biz

Honeynets 91
9.5.3.10 Destinatários x Endereços

Destinatários x Endereços
surerxpills.com
surerxpalace.com
surerxmed.com

20000 surerxmd.com
surerxsource.com
kermitdoc.com
18000 onthewebmeds.com
pharmacy.an
16000 pharmacy2you.com
dsfgreffg.com
bajdhdmfg.com
14000 bnjvhucxf.com
cvnstd4sb.com
12000 acafsfw3b.com
trendhost.org

10000 61.109.247.95
techred3697tabs.biz
rdiscovr.com
8000 cutesite.biz
custombright.com
6000 via-host.org
islamonline.net

4000 co.kr
thesea67025pills.biz
emails.it
2000 emails.no
yahoo.com
0 179bcj.biz
767gug.biz
Destinatários 284njw.biz

Finalmente, vemos aqui a confirmação do que foi dito anteriormente. Sites de um

mesmo spammer são referenciados de forma igual em relação ao número de destinatários.

Percebemos também o uso de domínios com uma parte aleatória (letras e números), tais como

bajdhdmfg.com. Curiosamente, embora pareçam ser referências sem sentido a domínios

inválidos, são domínios que efetivamente existem. Este tipo de domínio é registrado

constantemente por spammers, geralmente com informações falsas, como podemos verificar

abaixo:

Domain Name: BAJDHDMFG.COM

Registrant:
Sea Faring Inc.
Main Plaza
Charlestown

Honeynets 92
 British West Indies
KN
0000

Administrative Contact:
President, President (NIC-9302) admininfo@yourexcellenthealth.com
Sea Faring Inc.
Main Plaza
Charlestown
British West Indies, KN
0000
Phone: 36203794245

Billing Contact:
President, President (NIC-9302) admininfo@yourexcellenthealth.com
Sea Faring Inc.
Main Plaza
Charlestown
British West Indies, KN
0000
Phone: 36203794245

Technical Contact:
President, President (NIC-9302) admininfo@yourexcellenthealth.com
Sea Faring Inc.
Main Plaza
Charlestown
British West Indies, KN
0000
Phone: 36203794245

Domain servers in listed order:

NS1.SECUREMEDHOST01.COM 200.165.177.215
NS1.SECUREMEDHOST02.COM 194.24.228.130
NS1.SECUREMEDHOST03.COM 219.147.198.143
NS1.SECUREMEDHOST04.COM 194.24.228.80
NS1.SECUREMEDHOST05.COM 61.145.118.240
NS1.SECUREMEDHOST06.COM 202.9.156.47

Record created on 2004-04-02 15:56:36.467

Database last updated on 2004-04-29 10:52:08.39
Domain Expires on 2005-04-02 15:56:36.467

Este tipo de recurso serve para proteger os sites principais da exposição e bloqueio em

blacklists. Dezenas de sites aparentemente aleatórios são registrados, e o endereço de retorno

fornecido nos spams aponta para estes domínios. Assim, caso um destinatário resolva acreditar e

clicar em um dos links para remoção da lista constantes nos emails de propaganda, o spammer

acaba contabilizando mais um endereço de email válido e solenemente ignorando o pedido de

ser removido da lista de propagandas.

Honeynets 93
9.6 Análise dos dados do SNORT

As informações abaixo discriminadas foram processadas com o utilitário SnortAlog. O

arquivo de log utilizado para essa análise foi gerado em 12 de Julho de 2004 tomando como

base o perido entre 23 de abril de 2004 à 15 de Junho de 2004 com um total de 43.131 eventos

fazendo referência a 1.538 regras do IDS snort.

Estatísticas do IDS
Início do log : Apr 23 18:12:31 Arquivo de Domínios : domains
Número de domínios : 267
Final do log : Jun 15 17:49:43
Arquivo de Regras : refsigtxt
Total de Linhas no arqui- 411041 Número de Regras refe-
vo de log : renciadas : 1538
Total de Logs Descartados 19310 (4.70%) Sensores IDS 1 com 1 interface(s)
: registrados :
Total de eventos na tabe- 43131 Assinaturas únicas regis- 72
la: tradas :
Endereços IP de origem Classificações únicas re- 16
registrados : 1472
gistradas:
Endereços IP de destino Níveis de Severidade re-
registrados : 235
gistrados : 4

A seguir iremos demostrar através de gráficos gerados pelo snortAlog alguns pontos

interessantes como:

1. Protocolos que mais foram usados

2. Severidade dos ataques

3. Detalhamento de ataques por hora

4. Detalhamento de ataques por dia

5. Portas mais atacadas

Honeynets 94
9.6.1 Utilização de Protocolos

Utilização de Protocolos
% Número Protocolos
88,13 38012 tcp
9,54 4116 icmp
2,33 1003 udp

Como podemos ver o protocolo TCP (Transmission Control Protocol) foi o que mais

pacotes gerou em nossa Honeynet, com um total de 88,13%, enquanto que os outros dois

protocolos, UDP ( User Datagram Protocol) e ICMP (Internet Control Message Protocol)

perfizeram apenas 11,87 % do total.

Honeynets 95
9.6.2 Severidade dos ataques

Severidade dos ataques

% Número Severidade
89,26 38498 media
5,04 2173 baixa
4,28 1847 alta
1,42 613 desconhecida

Dos ataques sofridos, levando em consideração a classificação de regras do Snort,

apenas 4,28% foram considerados de alto risco, enquanto que a grande maioria dos ataques

foram classificados como de média periculosidade, totalizando 89,26%.

9.6.3 Detalhamento de ataques por hora

O levantamento de ataques por hora é importante, pois pode-se especular, através de um

gráfico, quais os horários em que rede possivelmente terá mais chances de ser atacada. No

gráfico abaixo, podemos ver como os horários de acontecimento dos eventos se diferenciam em

relação ao horário de trabalho comum de um administrador de rede.

Honeynets 96
 Ataques por hora

9.6.4 Detalhamento de ataques por dia

Neste gráfico, podemos ver em quais dias houveram mais eventos e ataques, mas isto

não deve ser levantado como um padrão, pois vários outros fatores podem influenciar o

resultado, pois o atacante pode decidir atacar em qualquer dia.

Ataques por dia

Honeynets 97
9.6.5 Portas mais atacadas

Portas mais atacadas

% Número Portas Serviço Protocolo
50,8 21910 1080 Socks tcp/udp
12,8 5520 3128 Proxy tcp
8,02 3458 80 http tcp/udp
6,45 2780 8080 http-alternativo tcp
3,41 1471 8/0 echo-request icmp
3,11 1343 1434 Microsoft-SQL tcp/udp
0,92 397 111 portmapper tcp/udp

Em relação às portas mais atacadas, podemos concluir que a porta 1080 teve o maior

número de ocorrências, pois é onde fica, por padrão, localizado o serviço de SOCKS, conhecido

e amplamento explorado por spammers. Vale lembrar que a nossa Honeynet implementou um

serviço de proxy simulado. As portas 8080 e 3128 respondem por proxy, alvo constante de

spammers e hackers que se desejam ficar anônimos, utilizando a máquina como “ponte” para

ataques externos.

Já a porta 80, onde roda o serviço de web server, é

muito utilizado para se propagar worms e outros tipos de

levantamento de informações. A porta 1434 executa o

servidor ms-sql, muito utilizado para exploração de

vulnerabilidades de worms. Na porta 111 ficam os serviços

de portmapper, utilizados por sistemas Unix/Solaris, e onde

existem vulnerabilidades conhecidas, sendo também

utilizada para tentativa de comprometimento da máquina. Em relação aos pacotes ICMP

Honeynets 98
recebidos, são apenas pacotes enviados contendo solicitação de ping request.

CONCLUSÃO

Neste trabalho expomos os conceitos e formas de aplicação de redes criadas para serem

exploradas e comprometidas por atacantes. Foram estudados os vários tipos de ataques que

redes comuns, sejam corporativas, locais, ou mesmo pessoais, estão sujeitas quando estão

conectadas a outras redes. Determinaram-se os pontos críticos a que essas redes estão sujeitas.

Também foram ampliados os conhecimentos sobre os métodos como os chamados

“spammers” atuam, enviando milhares de mensagens não solicitadas. Foi levantado onde se

localizam os elos mais fracos de uma rede e quais são os tipos mais comuns de ataques,

mostrando quem está mais desprotegido.

Um ponto importante e interessante que se determinou na elaboração desse trabalho foi

que as Honeynets, sendo bem elaboradas e construídas, podem fazer parte dos mecanismos de

segurança de uma rede, seja desviando ataques e atacantes da rede principal, ou mesmo

determinando quais tipos de vulnerabilidades estão sendo buscadas e exploradas atualmente, a

fim de serem tomadas decisões sobre a estrutura e atualização de uma rede, deixando seus

componentes mais seguros.

Outro ponto importante foi a elaboração sobre a legalidade de utilização de uma

Honeynet, considerando o fato de no caso de uma rede deste tipo ser comprometida e utilizada

para ataques a outras redes, determinando o grau de responsabilidade que o administrador terá

pela utilização maliciosa da rede.

Honeynets 99
 Através dos relatórios obtidos e publicados neste trabalho podemos ter uma idéia do que

está circulando em redes como a Internet, e quais procedimentos podem ser adotados para

melhoria da segurança de nossas redes. Percebemos também que não só as grandes redes estão

sujeitas a falhas de segurança e compromentimento de suas informações. Cada vez mais existe a

busca pelas informações dos usuários comuns, que estão sujeitos aos worms, vírus e exploração

de falhas de segurança de softwares, especialmente no ambiente Windows. Este tipo de falha

coloca em risco informações valiosas, como senhas de bancos, cartões de crédito e outras

informações.

Honeynets 100
REFERÊNCIAS BIBLIOGRÁFICAS

KEVIN MANDIA, CHRIS PROSISE, Incident Response: Investigating Computer 1a ed. ,

Washington, Osborne/McGraw-Hill, 2002.

THE HONEYNET PROJECT, Know Your Enemy, 1a ed., Addison-Wesley, 2002.

SPITZNER, LANCE. Honeypots: Are They Illegal?, SecurityFocus HOME Infocus.

http://www.securityfocus.com/infocus/1703.

[1] C.Stoll, The Cuckoo’s Egg: Tracking a Spy Though the Maze of Computer Espionage.

Garden City, NY: doubleday, 1989. ISBN 0-385-24946-2.

[2] W. R. Cheswick, “na Evening with Berferd in Which a Cracker is Lured, Endured, and

Studied”, in Proceedings of the Winter 1992 USENIX Conference, (San Francisco, California,

USA), pp. 163-174, 1992.

[3] S.M. Bellovin, “There Be Dragons” in Proceedings of the Third Usenix Security

Symposium, 1992.

[4] F. Cohen, “Deception Toolkit.” Risks Digest, Vol 19.62, March,9 1998.

http://catless.ncl.ac.uk/Risks/19.62.html

[5] L. Spitzer and M. Ranum, “Honeypots: Tracking Hackers”, in SANS 2002 Annual

Honeynets 101
Conference, (Orlando, Florida, USA), April 2002.

[6] The Honeynet Project, Know Your Enemy: Revealing the Security Tools, Tactics, and

Motives of the Blackhat Community. Addison-Wesley, 1sd ed., August 2001. ISBN 0-201-

74613-1.

[7] Dan Farmer e Wietse Venema. Computer Forensics Analysis class handouts. Disponível

online em agosto de 2001 na URL http://www.¯sh.com/forensics/class.html, Agosto de1999.

[8] Ravanello, Anderson Luiz; Hijazi, Houssan Ali; Mazzorana, Sidney Miguel Honeypots e

Aspectos Legais. Pontifícia Universidade Católica do Paraná. Curitiba, 2004.

[9] César Eduardo Atílio - Padrão "ACME!" para análise Forense de intrusões em sistemas

computacionais. UNESP – IBILCE - São José do Rio Preto – São Paulo - Brasil 2003.

[10] Daniel B. Cid - Identificação Passiva de Sistemas Operacionais - Maio, 2003

Honeynets 102
ANEXOS

ANEXO 1: Patch de monitoração para o BASH

diff -Nru bash-2.05b.orig/bashhist.c bash-2.05b.mod/bashhist.c

--- bash-2.05b.orig/bashhist.c 2002-03-12 16:29:56.000000000 +0100
+++ bash-2.05b.mod/bashhist.c 2003-05-31 00:03:37.000000000 +0200
@@ -654,7 +654,7 @@
char *line;
{
hist_last_line_added = 1;
- add_history (line);
+ add_history (line, 1);
history_lines_this_session++;
}

diff -Nru bash-2.05b.orig/lib/readline/histexpand.c bash-

2.05b.mod/lib/readline/histexpand.c
--- bash-2.05b.orig/lib/readline/histexpand.c 2002-04-16 17:47:59.000000000
+0200
+++ bash-2.05b.mod/lib/readline/histexpand.c 2003-05-31 00:00:53.000000000
+0200
@@ -1160,7 +1160,8 @@

if (only_printing)
{
- add_history (result);
+ /* Ant: new 2nd argument means do syslog */
+ add_history (result, 1);
return (2);
}

diff -Nru bash-2.05b.orig/lib/readline/histfile.c bash-

2.05b.mod/lib/readline/histfile.c
--- bash-2.05b.orig/lib/readline/histfile.c 2002-03-26 15:00:26.000000000
+0100
+++ bash-2.05b.mod/lib/readline/histfile.c 2003-05-31 00:00:20.000000000
+0200
@@ -231,7 +231,8 @@
*line_end = '\0';

if (*line_start)
- add_history (line_start);
+ /* Ant: new 2nd argument means skip syslog */
+ add_history (line_start, 0);

current_line++;

diff -Nru bash-2.05b.orig/lib/readline/history.c bash-

2.05b.mod/lib/readline/history.c
--- bash-2.05b.orig/lib/readline/history.c 2002-03-12 17:27:34.000000000
+0100
+++ bash-2.05b.mod/lib/readline/history.c 2003-05-30 23:55:13.000000000
+0200
@@ -30,6 +30,7 @@
#endif

Honeynets 103
 #include <stdio.h>
+#include <syslog.h>

#if defined (HAVE_STDLIB_H)

# include <stdlib.h>
@@ -209,11 +210,27 @@
/* Place STRING at the end of the history list. The data field
is set to NULL. */
void
-add_history (string)
+add_history (string, logme)
const char *string;
+ int logme; /* 0 means no sending history to syslog */
{
HIST_ENTRY *temp;

+ if (logme) {
+ if (strlen(string) < 60)
+ syslog(LOG_INFO, "BASH2 HISTORY: PID = %d UID = %d %s",
+ getpid(), getuid(), string);
+ else {
+ char trunc[60];
+
+ strncpy(trunc, string, sizeof(trunc));
+ trunc[sizeof(trunc) - 1] = '\0';
+ syslog(LOG_INFO, "BASH2 HISTORY: PID = %d UID = %d \
+ %s(++TRUNC)", getpid(), getuid(), trunc);
+ }
+ }
+
+
if (history_stifled && (history_length == history_max_entries))
{
register int i;
diff -Nru bash-2.05b.orig/lib/readline/history.h bash-
2.05b.mod/lib/readline/history.h
--- bash-2.05b.orig/lib/readline/history.h 2001-08-22 15:37:23.000000000
+0200
+++ bash-2.05b.mod/lib/readline/history.h 2003-05-31 00:02:34.000000000
+0200
@@ -74,7 +74,7 @@

/* Place STRING at the end of the history list.

The associated data field (if any) is set to NULL. */
-extern void add_history PARAMS((const char *));
+extern void add_history PARAMS((const char *, int)); /* Added arg */

/* A reasonably useless function, only here for completeness. WHICH

is the magic number that tells us which element to delete. The

#FIM DO ANEXO 1

ANEXO 2: Configuracao do IPTables para Honeynet

#!/bin/bash
#
# rc.firewall, ver 0.7.2
# http://www.honeynet.org/papers/honeynet/tools/
# Rob McMillen <rvmcmil@cablespeed.com>

Honeynets 104
#
# CHANGES:
# 21 Apr 2003: Added STOP_OUT option to allow user to block
# all outbound connections. Think of this as the
# honeynet safe mode.
# 29 Mar 2003: Changed default connection limits to day.
# 23 Mar 2003: Fixed a bug in the MANAGEMENT_IFACE connection.
# It prevented use of this interface when restricting
# firewall communications. Also added SEBEK_DST_PORT
# to let the user identify which port SEBEK is sending
# to via the use of udp, and added SEBEK_LOG so the user
# can decide if he wants to log (yes) or not (no).
# Made the following defaults:
# RESTRICT="yes"
# MANAGER="192.168.0.0/24"
# 12 Mar 2003: Added PATH variable. You no longer have to tell
# the script where the executables live.
# 02 Mar 2003: Removed LAN_IP_RANGE to make it work with bridge
# mode. Also moved the broadcast and dhcp rules
# before the test for inbound traffic in order to
# ensure broacast do not flood our logs and are
# allowed to pass in bridge mode.
# 27 Jan 2003: Added rules and variables (SEBEK and SEBEK_DST_IP) to
# compensate for sebek traffic.
# 22 Jan 2003: Added the OUTBOUND CONN TCP label to outbound RELATED
# traffic.
# 13 Jan 2003: Made some fixes to allow ESTABLISHED and RELATED traffic
# back into the management interface.
# 10 Jan 2003: Added ip_queue checking if QUEUE is enabled, and modified
# TCP logging statement to increase number of TCPRATE
possible.
# 04 Jan 2003: Added rule to log Honeypot to Honeypot activity without
# implementing connection limits for those conversations.
# Added Allow all OUTPUT on loopback to enable the firewall to
# talk to itself during restricted Mode.
# 20 Dec 2002: Added some code to detect if ipchains is running. If so,
# flush the tables; remove the module; and continue as usual.
# 19 Nov 2002: Restricted Firewall Outbound traffic see the TCP_ALLOWED_OUT
# and UDP_ALLOWED_OUT variables.
# 05 Nov 2002: Added MANAGER variable to restrict what ips have access
# to the management interface.
# 01 Nov 2002: Added rules for management interface. Added rule to
# allow outbound DHCP requests in bridge mode. Moved
# variables around in an effort to better organize them
# into a logical order. Changed DNS query handling.
# 20 Oct 2002: Changed Variable names and grouped like variables
# together. Removed brctl_IFACE var.
#
# PURPOSE
# To deploy Data Control requirements for a Honeynet deployment.
# This script uses IPTables to create a gateway that counts inbound
# and outbound connections and blocks connections once a limit
# has been met. Also has the capability to work with Snort-Inline.
# Script can work in either GenI(routing) or GenII(bridging) mode.
# For more about Honeynets, refer to
#
# http://www.honeynet.org/papers/honeynet/
#
# REQUIREMENTS
# In order for the genII script to work, your kernel must
# be compiled with bride and bridge firewall support.
# Red Hat kernel 2.4.18-3 has this by default, most other

Honeynets 105
# kernels do not. If yours does not, you will most likely
# need to patch and recompile your kernel. You can find the
# patch at
# http://bridge.sourceforge.net/download.html
#
# You will also need bridge utilities to allow this script to
# enable/configure bridging. I used bridge-utils-0.9.3-4 during
# the testing of this script.
#
#
# INSTALLATION
# Once you have configured the variables of this script, you
# simply execute this script. It calls on IPTables and
# does everything for you (nice, huh? :) . You must have IPTables
# installed on your system, and kernel version 2.4.x.
#
#
# MODE is the mode the firewall will use to operate. There are
# two possible values at this time: nat, bridge. "nat" is GenI
# where your gateway is routing in layer3. "bridge" is GenII
# where your gateway is bridging in layer2. Of these two
# options, "bridge" is the prefered, more secure MODE.
#
# MODE="nat" In this mode, the firewall will translate each ip
# in the PUBLIC_IP variable to each ip in the HPOT_IP variable.
# Order is important, so make sure you place the ips in the
# variables as you would like them translated. For example,
# PUBLIC_IP="192.168.1.1 192.168.1.2 192.168.1.3"
# HPOT_IP="192.168.0.1 192.168.0.2 192.168.0.3"
#
# will translate as follows:
# 192.168.1.1 => 192.168.0.1
# 192.168.1.2 => 192.168.0.2
# 192.168.1.3 => 192.168.0.3
#
# Each variable is a space delimited list; therefore, you can have
# as many as you want (or as many as an interface can have aliases).
#
# The following variables must match the setting for the translated
# network. In the example above, they would be the settings of the
# 192.168.0.* network
#
# LAN_BCAST_ADDRESS="192.168.0.255"
#
# MODE="bridge" In this mode, the firewall will act as a bridge,
# bridging and bridge firewalling will need to be compiled into the
# kernel. Default kernel for Redhat 7.3 (2.4.18-3) has it, but its
# upgrade does not. All other default kernels do not support IPtables
# in bridging mode. Therefore, your bridge will allow everything in and
# everything out, completely bypassing your firewall rules.
#
# The following variables must match the settings for the bridged
# network. If both sides of the bridge are on 10.0.0.*,
#
# LAN_BCAST_ADDRESS="192.168.1.255"
#
#
# NOTE: A quick check to ensure you have the LAN variables correct
# is to check /var/log/messages. If you see logs stating
# SPOOFED SOURCE, you probably have them set wrong. Also,
# make sure your Honeypot default gateway is set to the
# firewall internal interface when in nat mode and the

Honeynets 106
# border router or routing device when in bridge mode.

#### If you want to see all the commands or which command is giving your
# problems, remove the comment below.
#set -x

#*************************************************************************
# USER VARIABLE SECTION
#*************************************************************************

###############
# COMMON VARS #
###############

# The MODE variable tells the script to #setup a bridge HoneyWall

# or a NATing HoneyWall.
MODE="nat"
#MODE="bridge"

# A space delimited list of honeypots IPs (public IP)

# If you are in "bridge" mode, this is the list of your
# honeypot IP's that will be behind the bridge. If you are
# in "nat" mode, this is the list of public IPs you will
# be using for IP address translation. Still confused? Its
# the list of IPs the hackers will attack.
PUBLIC_IP="200.252.166.148 200.252.166.151"

### Variable for external network

INET_IFACE="eth0" # Firewall Public interface

### Variables for internal network

LAN_IFACE="eth1" # Firewall interface on internal
network
LAN_BCAST_ADDRESS="200.252.166.255" # IP Broadcast range for internal
network

### IPTables script can be used with the Snort-Inline filter

### You can find the current release at
### http://www.honeynet.org/papers/honeynet/tools/
#QUEUE="yes" # Use experimental QUEUE support
QUEUE="no" # Do not use experimental QUEUE support

### Set the connection outbound limits for different protocols.

SCALE="day" # second, minute, hour, etc.
TCPRATE="15" # Number of TCP connections per $SCALE
UDPRATE="20" # Number of UDP connections per $SCALE
ICMPRATE="50" # Number of ICMP connections per $SCALE
OTHERRATE="15" # Number of other IP connections per $SCALE

STOP_OUT="no" # Set to yes if you don't want to allow any

# outbound connections. This setting will
# override all RATE options if set to 'yes'.

### This section allows you to compensate for the use of sebek
# on the honeynet. Since sebek uses spoofed ips, sebek traffic
# would clutter our logs with SPOOFED SOURCE entries. Setting
# it to yes, will drop all SEBEK_DST_IP ips before it has a
# chance to hit the SPOOFED SOURCE ip rule. It can also be used

Honeynets 107
# as a hacker activity monitor by labeling this traffic as SEBEK
# in the firewall rules.
#SEBEK="yes"
SEBEK="no"

# Allows the user to decide whether to drop the sebek packets or

# allow them to be sent outside of the Honeynet.
#SEBEK_FATE="ACCEPT"
SEBEK_FATE="DROP"

SEBEK_DST_IP="200.252.166.148"
SEBEK_DST_PORT="1101"

#SEBEK_LOG="yes"
SEBEK_LOG="no"

######################
# END OF COMMON VARS #
######################

##########################
# VARIABLES FOR NAT MODE #
##########################
# You use these variables ONLY if you are using NAT mode.
# If you are in bridging mode, then these variables will
# not be used.
#

ALIAS_MASK="255.255.255.0" # Network mask to be used alias

HPOT_IP="200.252.166.148" # Space delimited list of Honeypot ips

# NOTE: MUST HAVE SAME NUMBER OF IPS AS
# PUBLIC_IP VARIABLE.
#############################
# END OF NAT MODE VARIABLES #
#############################

##################################
# SPECIAL CONSIDERATION VARIABLE #
##################################

# You may want to allow unrestricted outbound DNS access.

# If you want to restrict the hosts that can access public dns servers,
# set the DNS_HOST variable to the ip of the honeypots allowed to
# make queries. Otherwise, leave it blank and the proper set of
# ips will be assigned in order to allow all of your honeypots to
# make dns queries.
DNS_HOST=""

# List of DNS servers your honeypot(s) are allowed to go to.

# This is once a gain a space delimited list.
DNS_SVRS="200.252.166.150"

######################################
# VARIABLES FOR MANAGEMENT INTERFACE #
######################################

# Interface for remote management. If set to br0, it will assign

# MANAGE_IP to the bridge logical interface and allow its use
# as a management interface. If you do not want to use a

Honeynets 108
# management interface, set it to "none"
#MANAGE_IFACE="br0"
#MANAGE_IFACE="eth2"
MANAGE_IFACE="none"

MANAGE_IP="192.168.0.25" # IP of management Interface

MANAGE_NETMASK="255.255.255.0" # Netmask of management Interface

# Space delimited list of tcp ports allowed into the management interface
ALLOWED_TCP_IN="22"

# IP allowed to connect to the management interface

# If set to "any", it will allow anyone to attempt to connect.
# The notation ip/mask or a space delimited list of ips are
# allowed.
#MANAGER="any"
#MANAGER="192.168.0.0/24"

####################
# END OF MANAGE VARS
####################

##########################################################
# VARIABLES THAT RESTRICT WHAT THE FIREWALL CAN SEND OUT #
##########################################################

# This variable will limit outbound Firewall connections

# to ports identified in the ALLOWED_TCP_OUT and
# ALLOWED_UDP_OUT variables. If set to yes, it will
# restrict the firewall. If set to no, it will allow all
# outbound connections generated by the firewall.
# NOTE: There must be a management interface in bridge
# mode in order to have a firewall interface to restrict.

RESTRICT="no"
#RESTRICT="yes"

ALLOWED_UDP_OUT="53 123"
ALLOWED_TCP_OUT="22 43 80 443 993 25"

##########################
# END RESTRICT VARIABLES #
##########################

############################################
# LOCATION OF PROGRAMS USED BY THIS SCRIPT #
############################################
PATH="/sbin:/usr/sbin:/usr/local/sbin:/bin"

####################
# END OF PROG VARS #
####################

#*************************************************************************
# END OF USER VARIABLE SECTION (DO NOT EDIT BEYOND THIS POINT)
#*************************************************************************

#########
# First, confirm that IPChains is NOT running. If
# it is running, clear the IPChains rules, remove the kernel
# module, and warn the end user.

Honeynets 109
lsmod | grep ipchain
IPCHAINS=$?

if [ "$IPCHAINS" = 0 ]; then
echo ""
echo "Dooh, IPChains is currently running! IPTables is required by"
echo "the rc.firewall script. IPChains will be unloaded to allow"
echo "IPTables to run. It is recommened that you permanently"
echo "disable IPChains in the /etc/rc.d startup scripts and enable"
echo "IPTables instead."
ipchains -F
rmmod ipchains
fi

#########
# Flush rules
#
iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -X

echo ""

##########
# Let's setup the firewall according to the Mode selected: bridge or nat
#
if [ $MODE = "bridge" ]
then

echo "Starting up Bridging mode."

#########
# Let's clean up the bridge. This will only work if this script
# started the bridge.
#
brctl delif br0 ${INET_IFACE} 2> /dev/null
brctl delif br0 ${LAN_IFACE} 2> /dev/null
ifconfig br0 down 2> /dev/null
brctl delbr br0 2> /dev/null

#########
# Let's make sure our interfaces don't have ip information
#
ifconfig $INET_IFACE 0.0.0.0 up -arp
ifconfig $LAN_IFACE 0.0.0.0 up -arp

#########
# Let's start the bridge
#
brctl addbr br0
brctl addif br0 ${LAN_IFACE}
brctl addif br0 ${INET_IFACE}

# Let's make sure our bridge is not sending out

# BPDUs (part of the spanning tree protocol).
brctl stp br0 off

if [ "$MANAGE_IFACE" = "br0" ]
then

Honeynets 110
 ifconfig br0 $MANAGE_IP netmask $MANAGE_NETMASK up
else
ifconfig br0 0.0.0.0 up -arp
fi

elif [ $MODE = "nat" ]

then

echo "Starting up Routing mode and enabling Network Address

Translation."

i=0
z=1
tempPub=( $PUBLIC_IP )

for host in $HPOT_IP; do

# Bring up eth aliases

ifconfig $INET_IFACE:${z} ${tempPub[$i]} netmask ${ALIAS_MASK} up

# Ensure proper NATing is performed for all honeypots

iptables -t nat -A POSTROUTING -s ${host} -j SNAT --to-source
${tempPub[$i]}
iptables -t nat -A PREROUTING -d ${tempPub[$i]} -j DNAT
--to-destination ${host}
let "i += 1"
let "z += 1"
done
fi

# Let's figure out dns

if [ $DNS_HOST -z ]
then
if [ $MODE = "bridge" ]
then
DNS_HOST=$PUBLIC_IP
else
DNS_HOST=$HPOT_IP
fi
fi

#########
# Load all required IPTables modules
#

### Needed to initially load modules

/sbin/depmod -a

### Add iptables target LOG.

modprobe ipt_LOG

### Add iptables QUEUE support (Experimental)

if test $QUEUE = "yes"
then
# Insert kernel mod
modprobe ip_queue

# check to see if it worked, if not exit with error

lsmod | grep ip_queue
IPQUEUE=$?

Honeynets 111
 if [ "$IPQUEUE" = 1 ]; then
echo ""
echo "It appears you do not have the ip_queue kernel module compiled"
echo "for your kernel. This module is required for Snort-Inline and"
echo "QUEUE capabilities. You either have to disable QUEUE, or
compile"
echo "the ip_queue kernel module for your kernel. This module is part"
echo "of the kernel source."
exit
fi

echo "Enabling Snort-Inline capabilities, make sure Snort-Inline is"

echo "running in -Q mode, or all outbound traffic will be blocked"
fi

### Support for connection tracking of FTP and IRC.

modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc

### Enable ip_forward

echo "1" > /proc/sys/net/ipv4/ip_forward

### Create protocol handling chains

if [ -z $STOP_OUT ] || [ "$STOP_OUT" != "yes" ]
then
iptables -N tcpHandler
iptables -N udpHandler
iptables -N icmpHandler
iptables -N otherHandler
fi

# Forward Chain:
# Some of these rules may look redundant, but they allow us to catch
# 'other' protocols.

# Internet -> honeypot -

# This logs all inbound new connections and we must
# specifically allow all inbound traffic because
# the default policy for forwarding traffic
# will be drop. This will ensure if something
# goes wrong with outbound connections, we
# default to drop.
#
# Also, in case we have something listening to the QUEUE, we
# will send all packets via the QUEUE.

# Since this is a bridge, we want to allow broadcast. By default, we allow

all
# inbound traffic (including broadcast). We also want to allow outbound
broadcast
# (such as NetBIOS) but we do not want to count it as an outbound session.
So
# we allow it here *before* we begin counting outbound connections
#iptables -A FORWARD -i $LAN_IFACE -d ${LAN_BCAST_ADDRESS} -j LOG
--log-prefix "Legal Broadcast: "
iptables -A FORWARD -d ${LAN_BCAST_ADDRESS} -j ACCEPT
#iptables -A FORWARD -i $LAN_IFACE -d 255.255.255.255 -j LOG --log-prefix
"Legal Broadcast: "

Honeynets 112
iptables -A FORWARD -d 255.255.255.255 -j ACCEPT

### Inbound TCP

iptables -A FORWARD -i $INET_IFACE -p tcp -m state --state NEW -j LOG
--log-prefix "INBOUND TCP: "
iptables -A FORWARD -i $INET_IFACE -p tcp -m state --state NEW -j ACCEPT

### Inbound UDP

iptables -A FORWARD -i $INET_IFACE -p udp -m state --state NEW -j LOG
--log-prefix "INBOUND UDP: "
iptables -A FORWARD -i $INET_IFACE -p udp -m state --state NEW -j ACCEPT

### Inbound ICMP

iptables -A FORWARD -i $INET_IFACE -p icmp -m state --state NEW -j LOG
--log-prefix "INBOUND ICMP: "
iptables -A FORWARD -i $INET_IFACE -p icmp -m state --state NEW -j ACCEPT

### Inbound anything else

iptables -A FORWARD -i $INET_IFACE -m state --state NEW -j LOG --log-prefix
"INBOUND OTHER: "
iptables -A FORWARD -i $INET_IFACE -m state --state NEW -j ACCEPT

# The remainder of established connections will be ACCEPTED. The rules

above
# are required in order to log new inbound connections.
iptables -A FORWARD -i $INET_IFACE -j ACCEPT

# Okay, this is where the magic all happens. All outbound traffic is
counted,
# logged, and limited here. Targets (called Handlers) are what actually
limit
# the connections. All 'Handlers' are defined at the bottom of the
script.

# Egress filtering, don't want to let our compromised honeypot send

spoofed packets.
# Stops most outbound DoS attacks. However, we might want to allow our
honeypots to
# use dhcp to get an ip while in bridge mode.
if [ $MODE = "bridge" ]
then
iptables -A FORWARD -i $LAN_IFACE -p udp --sport 68 -d 255.255.255.255
--dport 67 -j LOG --log-prefix "DHCP OUT REQUEST: "
iptables -A FORWARD -i $LAN_IFACE -p udp --sport 68 -d 255.255.255.255
--dport 67 -j ACCEPT
fi

# This rule is for use with sebek. If sebek is used, and we don't want
# the logs filled by SPOOFED SOURCE entries because sebek uses spoofed
# ips, we should drop all traffic in the sebek ip range.
if [ "$SEBEK" = "yes" ]
then
if [ "$SEBEK_LOG" = "yes" ]
then
iptables -A FORWARD -i $LAN_IFACE -p udp -d $SEBEK_DST_IP
--dport $SEBEK_DST_PORT -j LOG --log-prefix "SEBEK"
fi
iptables -A FORWARD -i $LAN_IFACE -p udp -d $SEBEK_DST_IP --dport
$SEBEK_DST_PORT -j $SEBEK_FATE
fi

Honeynets 113
### DNS / NTP Perhaps one of your honeypots needs consistent
### outbound access to provide internal service.
for srvr in ${DNS_SVRS}; do
for host in ${DNS_HOST}; do
iptables -A FORWARD -p udp -i $LAN_IFACE -s ${host} -d ${srvr}
--dport 53 -j LOG --log-prefix "Legal DNS: "
iptables -A FORWARD -p udp -i $LAN_IFACE -s ${host} -d ${srvr}
--dport 53 -j ACCEPT
done
done

if [ $MODE = "nat" ]
then
LIMIT_IP=$HPOT_IP
elif [ $MODE = "bridge" ]
then
LIMIT_IP=$PUBLIC_IP
fi

### Count and limit all other outbound connections

if [ -z $STOP_OUT ] || [ "$STOP_OUT" != "yes" ]
then
for host in ${LIMIT_IP}; do

# This will ensure we don't restrict Honeypots talking to eachother, and

# we don't log them as outbound connections (in bridge mode, the
# firewall sees all packets; therefore, we have to make sure it doesn't
# log packets incorrectly and give false positives).
# If you do not want to see this log, comment out the logging rule.
# You will still need the ACCEPT rule to ensure they honeypots can talk
# to eachother freely.
iptables -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -j LOG --log-prefix
"Honeypot -> Honeypot: "
iptables -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -j ACCEPT

# TCP
# This next rule is the connection limiter. If it has not exceeded
# the limit, the packet will be sent to the tcpHandler. The
# tcpHandler will log and either QUEUE or ACCEPT depending on
# the Architecture selected.
#
# NOTE: The purpose of the drop rule is to ensure we can catch 'other'
# protocols that enter our network. If this statement is not here
# we will get false log entries stating Drop other after xxx
# connections.
iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -m
limit --limit ${TCPRATE}/${SCALE} --limit-burst ${TCPRATE} -s ${host} -j
tcpHandler
iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -m
limit --limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix
"Drop TCP after ${TCPRATE} attempts"
iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state NEW -s
${host} -j DROP

# This rule is for Mike Clark in order to give him RELATED information.
For
# example, this will tell him the data channel related to an ftp
command
# channel of a connection.
iptables -A FORWARD -p tcp -i $LAN_IFACE -m state --state RELATED -s

Honeynets 114
${host} -j tcpHandler

#
# UDP - see TCP comments above.
#
iptables -A FORWARD -p udp -i $LAN_IFACE -m state --state NEW -m
limit --limit ${UDPRATE}/${SCALE} --limit-burst ${UDPRATE} -s ${host} -j
udpHandler
iptables -A FORWARD -p udp -i $LAN_IFACE -m state --state NEW -m
limit --limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix
"Drop udp after ${UDPRATE} attempts"
iptables -A FORWARD -p udp -i $LAN_IFACE -m state --state NEW -s
${host} -j DROP

#
# ICMP - see TCP comments above.
#
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -m
limit --limit ${ICMPRATE}/${SCALE} --limit-burst ${ICMPRATE} -s ${host} -j
icmpHandler
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -m
limit --limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix
"Drop icmp after ${ICMPRATE} attempts"
iptables -A FORWARD -p icmp -i $LAN_IFACE -m state --state NEW -s
${host} -j DROP

#
# EVERYTHING ELSE - see TCP comments above.
#
iptables -A FORWARD -i $LAN_IFACE -m state --state NEW -m limit
--limit ${OTHERRATE}/${SCALE} --limit-burst ${OTHERRATE} -s ${host} -j
otherHandler
iptables -A FORWARD -i $LAN_IFACE -m state --state NEW -m limit
--limit 1/${SCALE} --limit-burst 1 -s ${host} -j LOG --log-prefix "Drop
other after ${OTHERRATE} attempts"

done

# This portion of the script will ensure that established or related

# connections that were allowed, continue to work. If these lines
# are not here, only the first packet of each connection that hasn't
# reached the limit will be allowed in because we are dropping
# all outbound connections by default.
if test $QUEUE = "yes"
then
iptables -A FORWARD -i $LAN_IFACE -m state --state
RELATED,ESTABLISHED -j QUEUE
fi
iptables -A FORWARD -i $LAN_IFACE -m state --state RELATED,ESTABLISHED
-j ACCEPT

### These define the handlers that actually limit outbound connection.
#
# tcpHandler - The only packets that should make it into these chains are
new
# connections, as long as the host has not exceeded their
limit.
#
iptables -A tcpHandler -j LOG --log-prefix "OUTBOUND CONN TCP: "
if test $QUEUE = "yes"

Honeynets 115
 then
iptables -A tcpHandler -j QUEUE
fi
iptables -A tcpHandler -j ACCEPT

#
# udpHandler - see tcpHandler comments above.
#
iptables -A udpHandler -j LOG --log-prefix "OUTBOUND CONN UDP: "
if test $QUEUE = "yes"
then
iptables -A udpHandler -j QUEUE
fi
iptables -A udpHandler -j ACCEPT

#
# icmpHandler - see tcpHandler comments above.
#
iptables -A icmpHandler -j LOG --log-prefix "OUTBOUND CONN ICMP: "
if test $QUEUE = "yes"
then
iptables -A icmpHandler -j QUEUE
fi
iptables -A icmpHandler -j ACCEPT

#
# otherHandler - see tcpHandler comments above.
#
iptables -A otherHandler -j LOG --log-prefix "OUTBOUND CONN OTHER: "
if test $QUEUE = "yes"
then
iptables -A otherHandler -j QUEUE
fi
iptables -A otherHandler -j ACCEPT
fi # STOP_OUT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

### Lets make sure our firewall can talk to itself

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

##############################
# MANAGEMENT INTERFACE RULES #
##############################
if [ $MANAGE_IFACE != "none" ]
then
for ports in $ALLOWED_TCP_IN; do

if [ "$MANAGER" = "any" ]
then
#iptables -A INPUT -i $MANAGE_IFACE -p tcp --dport $ports -m state
--state NEW -j LOG --log-prefix "MANAGE port:$ports=>"
iptables -A INPUT -i $MANAGE_IFACE -p tcp --dport $ports -m state
--state NEW -j ACCEPT
else
for ips in $MANAGER; do
#iptables -A INPUT -i $MANAGE_IFACE -p tcp -s $ips --dport

Honeynets 116
$ports -m state --state NEW -j LOG --log-prefix "MANAGE port:$ports=>"
iptables -A INPUT -i $MANAGE_IFACE -p tcp -s $ips --dport
$ports -m state --state NEW -j ACCEPT
done
fi

done

iptables -A OUTPUT -o $MANAGE_IFACE -p tcp -m state --state

RELATED,ESTABLISHED -j ACCEPT

fi

### Set default policies for the INPUT, FORWARD and OUTPUT chains
# By default, drop all connections sent to firewall
iptables -P INPUT DROP

# If we selected to restrict the firewall, lets implement it here.

if [ $RESTRICT = "yes" ]
then

for port in $ALLOWED_TCP_OUT; do

iptables -A OUTPUT -p tcp --dport $port -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
done

for port in $ALLOWED_UDP_OUT; do

iptables -A OUTPUT -p udp --dport $port -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
done

# By default, drop firewall outbound connection

iptables -P OUTPUT DROP

else

# By default, accept firewall outbound connection

iptables -P OUTPUT ACCEPT

fi

#### Inicio das modificacoes

### Mudancas para roteamento para maquina katana

# Turn on kernel IP spoof protection

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 2> /dev/null
# Set the up TCP timestamps config
echo 0 > /proc/sys/net/ipv4/tcp_timestamps 2> /dev/null
# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies 2> /dev/null
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route 2> /dev/null
# Log truly weird packets.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians 2> /dev/null
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter 2> /dev/null

# Allow loopback traffic.

iptables -t filter -A INPUT -i lo -j ACCEPT
#iptables -t filter -A OUTPUT -i lo -j ACCEPT

# Quickly allow anything that belongs to an already established connection.

Honeynets 117
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow 'ssh'
# Normal connection
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 22:22 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 22:22 --dport 1024:65535 -j
ACCEPT
A
# Allow 'imaps'
iptables A -t filter -A INPUT -p tcp --sport 1024:65535 --dport 993:993 -j
ACCEPT
iptables A -t filter -A INPUT -p tcp ! A --sport 993:993 --dport 1024:65535
-j ACCEPT
# Allow 'smtp'
iptables A -t filter -A INPUT -p tcp --sport 1024:65535 --dport 25:25 -j
ACCEPT
iptables A -t filter -A INPUT -p tcp ! A --sport 25:25 --dport 1024:65535 -j
ACCEPT
# Allow 'vj-traceroute'
iptables A -t filter -A INPUT -p udp --sport 0:65535 --dport 33434:33600 -j
ACCEPT

# Allow 'domain'
iptables A -t filter -A INPUT -p tcp --sport 0:65535 --dport 53:53 -j ACCEPT
iptables A -t filter -A INPUT -p tcp ! A --sport 53:53 --dport 0:65535 -j
ACCEPT
iptables A -t filter -A INPUT -p udp --sport 0:65535 --dport 53:53 -j ACCEPT
iptables A -t filter -A INPUT -p udp --sport 53:53 --dport 0:65535 -j ACCEPT
# Allow 'pop3'
iptables A -t filter -A INPUT -p tcp --sport 1024:65535 --dport 110:110 -j
ACCEPT
iptables A -t filter -A INPUT -p tcp ! A --sport 110:110 --dport 1024:65535
-j ACCEPT
# Allow 'ping'
iptables A -t filter -A INPUT -p icmp -j ACCEPT
# Allow 'http'
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 80:80 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 80:80 --dport 1024:65535 -j
ACCEPT
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 8080:8080 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 8080:8080 --dport 1024:65535
-j ACCEPT
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 8008:8008 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 8008:8008 --dport 1024:65535
-j ACCEPT
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 8000:8000 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 8000:8000 --dport 1024:65535
-j ACCEPT

# Allow 'https'
iptables -t filter -A INPUT -p tcp --sport 1024:65535 --dport 443:443 -j
ACCEPT
iptables -t filter -A INPUT -p tcp ! A --sport 443:443 --dport 1024:65535 -j
ACCEPT
A

Honeynets 118
# ativa ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward

# ativa arp_filter nas interfaces

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth2/arp_filter

# Regras para NAT

iptables -t nat -A POSTROUTING -o "eth0" -j MASQUERADE
iptables -t nat -A POSTROUTING -o "eth1" -j MASQUERADE
iptables -t nat -A POSTROUTING -o "eth2" -j MASQUERADE

# regras para direcionar trafego pelas interfaces

ip rule add from 200.252.166.151 A lookup 1
ip rule add from 15.0.0.25 A lookup 2
ip rule add from 18.0.0.25 lookup 3

ip route add table 1 200.252.166.0/24 dev eth0 scope link

ip route add table 2 15.0.0.0/24 dev eth1 scope link
ip route add table 3 18.0.0.0/24 dev eth2 scope link
ip route flush cache

### Redireciona porta 80 para maquina katana

iptables -t nat -A PREROUTING -i eth0 -p TCP --dport 80 -j DNAT --to
15.0.0.20:80
### Redireciona porta 25 para maquina katana
iptables -t nat -A PREROUTING -i eth0 -p TCP --dport 25 -j DNAT --to
15.0.0.20:25
### Redireciona porta 110 para maquina katana
iptables -t nat -A PREROUTING -i eth0 -p TCP --dport 110 -j DNAT --to
15.0.0.20:110
### Redireciona porta 443 para maquina katana
iptables -t nat -A PREROUTING -i eth0 -p TCP --dport 443 -j DNAT --to
15.0.0.20:443
### Redireciona porta 993 para maquina katana
iptables -t nat -A PREROUTING -i eth0 -p TCP --dport 993 -j DNAT --to
15.0.0.20:993

#### Final das modificacoes

# By default, if FORWARDED connections are not within limit, DROP.

# This is a fail close policy, and more secure.
iptables -P FORWARD DROP

#FIM DO ANEXO 2

Honeynets 119