Seguranca de Redes

Segurança de Redes
Uma abordagem baseada em aplicações

Antonio Augusto Santos
Segurança de Redes: Uma abordagem baseada em aplicações
Antonio Augusto Santos
Copyright © 2008 Antonio Augusto Santos
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled ‘‘GNU Free Documentation License’’.
Índice
Prefácio ....................................................................................................................... x
I. Introdução ................................................................................................................ 1
1. Introdução ........................................................................................................ 2
1. Introdução ................................................................................................ 2
2. Footprinting .............................................................................................. 2
3. Varredura ................................................................................................. 2
4. Enumeração .............................................................................................. 2
5. Ganho de acesso ....................................................................................... 2
2. Analisadores de protocolo e Sniffers ..................................................................... 3
1. Introdução ................................................................................................ 3
1.1. Filtros de captura ............................................................................ 3
2. TCPdump e Windump ................................................................................ 5
3. Wireshark ................................................................................................ 8
3.1. Opções de captura ......................................................................... 10
3.2. Filtros de exibição ......................................................................... 14
3.3. Analises dos pacotes ...................................................................... 18
4. Cain & Abel ........................................................................................... 22
5. Dsniff .................................................................................................... 22
6. Contramedidas ........................................................................................ 22
6.1. Detectando sniffers ........................................................................ 22
3. Escaneamento de rede ...................................................................................... 23
1. Introdução .............................................................................................. 23
2. Network Scan ......................................................................................... 23
2.1. Ping Sweep .................................................................................. 23
2.2. Tracerouting ................................................................................. 23
3. Port scanning .......................................................................................... 23
3.1. Nmap .......................................................................................... 23
3.2. p0f .............................................................................................. 23
4. Scan de vulnerabilidades ........................................................................... 23
II. Ataques e defesas as camadas de rede ......................................................................... 24
4. Camada de dados ............................................................................................ 25
1. Introdução .............................................................................................. 25
2. MAC Spoof ............................................................................................ 25
3. ARP Flood ............................................................................................. 26
4. ARP Poisoning ........................................................................................ 26
5. Ataques DHCP ........................................................................................ 26
5.1. DHCP Starvation .......................................................................... 26
5.2. DHCP Rogue Server ...................................................................... 26
6. Ferramentas ............................................................................................ 26
6.1. Dsniff ......................................................................................... 26
6.2. gobbler ........................................................................................ 26
6.3. arpwatch ...................................................................................... 26
6.4. ettercap ....................................................................................... 27
6.5. john the ripper .............................................................................. 27
6.6. cain and abbel .............................................................................. 27
7. Protegendo a camada 2 ............................................................................. 27
5. Camada de rede .............................................................................................. 28
1. Introdução .............................................................................................. 28
2. IP Spoof ................................................................................................ 28
3. Ataques ICMP ........................................................................................ 28
3.1. Mudança de rota usando ICMP ........................................................ 28
3.2. Teardrop/Ping of Death .................................................................. 28
4.1. Evitando redirects .......................................................................... 28
4.2. Evitando spoof no sistema operacional .............................................. 28
iv
Segurança de Redes
4.3. IPSec .......................................................................................... 28

6. Camada de transporte ....................................................................................... 29
1. Introdução .............................................................................................. 29
2. Syn Flood .............................................................................................. 29
3. TCP Hijacking ........................................................................................ 29
4. UDP Flooding ......................................................................................... 29
5.1. Protegendo-se de synfloods ............................................................. 29
7. Camada de Aplicação ....................................................................................... 30
1. DNS ...................................................................................................... 30
1.1. DNS Spoof .................................................................................. 30
1.2. DNS Snooping .............................................................................. 30
1.3. MITM ......................................................................................... 30
1.4. Protegendo o DNS ........................................................................ 30
2. SMTP .................................................................................................... 30
2.1. Spoof de e-mail ............................................................................ 30
3. FTP ....................................................................................................... 30
4. Telnet .................................................................................................... 30
III. Ferramentas para proteção ....................................................................................... 31
8. Snort ............................................................................................................ 32
1. Introdução .............................................................................................. 32
2. Configurando o Snort ............................................................................... 32
2.1. include ........................................................................................ 32
2.2. Variáveis ..................................................................................... 32
2.3. Output ......................................................................................... 34
2.4. Config ......................................................................................... 36
3. Pré-processadores .................................................................................... 37
3.1. Stream5 ....................................................................................... 37
3.2. sfPortscan .................................................................................... 38
3.3. HTTP Inspect ............................................................................... 39
3.4. Outros pré-processadores ................................................................ 40
4. Regras ................................................................................................... 40
4.1. Cabeçalho .................................................................................... 41
4.2. Corpo .......................................................................................... 41
4.3. Exemplos de regras ....................................................................... 44
9. Firewall ........................................................................................................ 45
1. Introdução .............................................................................................. 45
2. Netfilter/Iptables ...................................................................................... 45
2.1. Introdução .................................................................................... 45
2.2. Funcionalidade básica do iptables ..................................................... 46
2.3. Alvos e Matches ........................................................................... 48
2.4. Trabalhando com a tabela NAT ....................................................... 53
2.5. Trabalhando com tabela Mangle ....................................................... 53
2.6. Filtragem na camada 7 ................................................................... 54
2.7. Protegendo-se de ataques de rede com o Iptables ................................. 54
3. ISA ....................................................................................................... 54
10. VPN ........................................................................................................... 55
1. Introdução .............................................................................................. 55
2. OpenVPN ............................................................................................... 55
3. RRAS .................................................................................................... 55
4. ISA ....................................................................................................... 55
11. Proxies ........................................................................................................ 56
1. Introdução .............................................................................................. 56
2. Squid ..................................................................................................... 56
3. Dans Guardian ........................................................................................ 56
4. ISA ....................................................................................................... 56
12. Criptografia ................................................................................................. 57
1. Introdução .............................................................................................. 57
v
Segurança de Redes
2. Tipo de criptografia ................................................................................. 57

2.1. Criptografia simétrica ..................................................................... 57
2.2. Criptografia assimétrica .................................................................. 57
3. Assinatura digital ..................................................................................... 57
4. Hashes ................................................................................................... 57
5. Infra-estrutura de chave pública .................................................................. 57
6. Kerberos ................................................................................................ 57
IV. Exploração de aplicações ........................................................................................ 58
13. Vulnerabilidades na Web ................................................................................ 59
1. Introdução .............................................................................................. 59
2. Directory Transversal e execução de código remota ........................................ 59
3. SQL Injection ......................................................................................... 59
4. XSS ...................................................................................................... 59
5. Vulnerabilidades dos Browsers ................................................................... 59
6. Google hacking ....................................................................................... 59
14. Explorando vulnerabilidades dos sistemas ........................................................... 60
1. Introdução .............................................................................................. 60
1.1. Metasploit .................................................................................... 60
15. Quebrando senhas ......................................................................................... 61
1. Introdução .............................................................................................. 61
2. Tipos de ataques ...................................................................................... 61
2.1. Ataques de dicionário .................................................................... 61
2.2. Ataques de força bruta ................................................................... 61
2.3. Ataques hibridos ........................................................................... 61
3. Rainbow Tables ....................................................................................... 61
V. Apêndices .............................................................................................................. 62
A. Cabeçalhos dos pacotes .................................................................................... 63
B. GNU Free Documentation License ..................................................................... 64
vi
Lista de Figuras
2.1. Exemplo de captura de pacotes do tcpdump ................................................................. 6
2.2. Exemplo de captura de pacotes AR ............................................................................ 7
2.3. Exemplo de captura de pacotes DNS .......................................................................... 7
2.4. Tela principal do Wireshark ...................................................................................... 9
2.5. Visão detalhada de pacote TCP ............................................................................... 10
2.6. Opções de captura do Wireshark .............................................................................. 11
2.7. Filtrando pacotes TCP no Wireshark ......................................................................... 15
2.8. Selecionando como decodificar um pacote ................................................................. 16
2.9. Configuração de filtros de exibição .......................................................................... 17
2.10. Funcionalidade follow tcp do Wireshark .................................................................. 18
2.11. Resumo das propriedades da captura ....................................................................... 19
2.12. Hierarquia de protocolos ....................................................................................... 20
2.13. Analise de “conversas” ......................................................................................... 21
2.14. Grafico de E/S de rede ......................................................................................... 22
9.1. Fluxo de um pacote nas chains do netfilter ................................................................ 46
vii
Lista de Tabelas
2.1. Opções de “Capture” ............................................................................................. 12
2.2. Opções de “Capture File(s)” .................................................................................... 13
2.3. Opções de “Stop Capture...” .................................................................................... 13
2.4. Opções de “Display Options” .................................................................................. 14
2.5. Opções de “Name Resolution” ................................................................................. 14
2.6. Opções de comparação do Wireshark ........................................................................ 16
2.7. Operações lógicas com expressões ........................................................................... 17
2.8. Opções de uso do operador substring ........................................................................ 18
viii
Lista de Exemplos
2.1. Monitorando trafego telnet ....................................................................................... 4
2.2. Monitorando trafego destinado a um host .................................................................... 4
2.3. Monitorando todo o trafégo UDP ............................................................................... 4
2.4. Monitorando trafego para porta TCP 80 do servidor 192.168.5.1 ...................................... 4
2.5. Excluindo trafégo DNS da monitoração ...................................................................... 4
2.6. Monitorando as portas ............................................................................................ 4
2.7. Monitorando a comunicação entre um cliente de 192.168.4.1 e um servidor web
192.168.5.3 .................................................................................................................. 4
2.8. Filtrando conexões SSH vindas de um dado cliente ....................................................... 4
2.9. Detectando worms .................................................................................................. 5
ix
Prefácio
Histórico de Revisões
Revisão 0.0.1 08 Jan 2008 AntonioSantos
• Versão Inicial
Revisão 0.0.2 11 Jan 2008 AntonioSantos
• Migração para docbook
• Adicionado conteúdo na seção “Snort”
• Adicionado conteúdo referente ao iptables na seção “Firewall”
• Adicionado conteúdo na seção “Camada de dados”

Revisão 0.0.3 18 Fev 2008 AntonioSantos
• Agora distribuido através da GFDL
• Adicionado conteúdo sobre tcpdump e wireshark na seção “Analisadores de protocolo e Sniffers”
x
Parte I. Introdução
Capítulo 1. Introdução
1. Introdução
2. Footprinting
3. Varredura
4. Enumeração
5. Ganho de acesso
2
Capítulo 2. Analisadores de protocolo
e Sniffers
1. Introdução
Um analisador de protocolo (também conhecido como sniffer) é uma ferramenta que nós permite
analisar o trafego de rede, mostrando informações detalhadas sobre pacotes e frames capturados a
partir de uma dada interface de rede.
Normalmente os analisadores de protocolo trabalham colocando a placa de rede em modo promíscuo.

Nesse modo a placa captura, não só os frames destinados a ela (esse tipo de ferramenta funciona na
camada de dados, nível 2 do modelo OSI), mas também qualquer frame que esteja passando pelo mes-
mo domínio de colisão onde está a máquina. Esse tipo de sniffing é conhecido como sniffer passivo,
e funciona quando estamos conectados a um hub, por exemplo.
1.1. Filtros de captura

A maioria dos sniffers disponíveis atualmente usa a uma implementação da pcap (Packet Capture)
para servir como ponte entre o sniffer e a placa de rede, viabilizando a captura de pacotes. Para Linux
a biblioteca chama-se libpcap, e para windows WinPcap, mas ambas tem a mesma finalidade.
O fato é que essa bilioteca oferece filtros que permitem decidirmos o que queremos capturar ou não.
Esses filtros são de grande valia para podermos não só filtrar informações que julgamos desnecessárias
(como pedidos de resolução de nomes DNS), mas também para evitarmos que muitos pacotes que são
importantes para nós sejam rejeitos pelo sistema operacional.
Esse segundo ponto é de extrema importância e merece alguma explicação: quando o sistema opera-
cional recebe pacotes de rede ele armazena todos esses pacotes em um buffer para que eles possam ser
processados. Quando estamos fazendo um sniffer em modo promiscuo o número de pacotes proces-
sados pode aumentar consideralvemente, e esse buffer pode não ser suficiente para armazenar tantos
pacotes, gerando assim um número razoável de descartes. A utilização de filtros vai então permitir
que reduzamos o número de pacotes capturados evitando assim menos descartes, e reduzindo a pos-
sibilidade de perdermos informações importantes.
O problema com os filtros de captura é que eles não combrem uma grande gama de opções como os
filtros de visualização do Wireshark (vistos com em detalhes na Seção 3.2), mas justamente por isso
eles são tão rápidos. Note que esse tipo de filtro normalmente pode ser usado em qualquer sniffer que
utilize a libpcap ou a winpcap (e todos os sniffers livres que eu conheço usam essas biliotecas).
Esses filtros de captura normalmente tratão de informações contidas na camada 2 ou 3 da pilha TCP/
IP, mas podem também tratar informações mais genéricas, permitindo buscar informações arbritrárias
nos pacotes ou especificar um procotolo que estamos procurando. A listagem abaixo mostra algumas
das opções básicas disponíveis para filtragem de pacotes. Na Seção 1.1.1 veremos alguns exemplos
de filtros usando essas opções.
Opções básicas de filtragem

host Define que o endereço IP do pacote deve ser igual ao especificado.
net Define que o endereço IP do pacote deve fazer parte da rede especificada. .
port Define a porta TCP/UDP que queremo filtrar..
src Define que o pacote deve ter como origem o host/net/port especificado..
3
Analisadores de protocolo e Sniffers
dst Define que o pacote deve ter como destino o host/net/port especificado..
ether, ip, tcp, Define que o pacote deve ser do protcolo definido..
udp, arp
broadcast Define que o pacote deve ser de broadcast. Pode-se também especificar o protocolo
para o qual desejamos filtrar os broadcasts. O protocolo padrão é ethernet, filtrando
assim broadcasts nesse meio..
1.1.1. Exemplos de filtros de captura

Nessa seção nós vamos ver alguns exemplos de utilização dos filtros de captura que podem ser úteis
para capturar nosso trafégo de rede. vamos começar com alguns exemplos básicos e ir avançando até
exemplos mais avançados.
Exemplo 2.1. Monitorando trafego telnet

port 23
Exemplo 2.2. Monitorando trafego destinado a um host

host 172.18.5.4
Exemplo 2.3. Monitorando todo o trafégo UDP

udp
É possível também combinar algumas das opções básicas usando operadores lógicos, permitindo assim
que verifiquemos se mais de uma condição é verdadeira (AND), pelo menos uma das condições dada
é verdadeira (OR) ou se a condição em questão é falsa (NOT). Vejamos a seguir alguns exemplos
usando essas opções.
Exemplo 2.4. Monitorando trafego para porta TCP 80 do servidor 192.168.5.1

host 192.168.5.1 and tcp and port 80
Exemplo 2.5. Excluindo trafégo DNS da monitoração

udp and port 53
Exemplo 2.6. Monitorando as portas

udp and port 53
Em alguns casos, como no caso do TCP/IP, é possível usarmos as opções SRC e DST, para dizermos
que queremos uma dada informação esteja contida nos campos de origem ou de destino do pacote,
respectivamente.
Exemplo 2.7. Monitorando a comunicação entre um cliente de 192.168.4.1 e um

servidor web 192.168.5.3
src host 192.168.4.1 and dst host 192.168.5.3 and tcp and dst port
80
Exemplo 2.8. Filtrando conexões SSH vindas de um dado cliente

not (src host 192.168.4.3 and dst port 23)
4
1.1.2. Filtragem avançada de pacotes

Uma opção extremamente avançado, e pouco documentada, desses filtros é a possibilidade de verificar
o valor de uma sequência de bytes dentro do pacote. Esse tipo de verificação pode ser interessante
para filtrar alguns pacotes que possuem propriedades conhecidas.
Por exemplo, se suspeitassemos de uma tentativa de DoS no nosso servidor Web e quisessemos veri-
ficar todos os pacotes de abertura de conexão (syn) que estão passando com destino a esse servidor,
as regras de filtragem básicas não seriam suficientes. Para fazer esse tipo de filtragem precisariamos
usar um comando como o descrito abaixo.
dst port 80 and tcp[13] == 2
Nesse caso estamos filtrando apenas pacote destinado a porta 80 e onde o decimo quarto byte (já que
nosso indice começa de zero), possui o valor 2. Se olharmos a estrutura do protcolo TCP veremos que
o 14° byte representa as opções do pacote, de tal forma que cada bit representa uma opção (CWR,
ECE, URG, ACK, PSH, RST, SYN e FIN). O que fazemos aqui então é verificar se o valor em questão
vale 2, que representa a situação onde somente o bit SYN está habilitado.
Para verificações mais complexas nós podemos usar uma operação lógica bit a bit, usando os opera-
dores: & e |, que permitem fazer um “e” e um “ou” lógico. Por exemplo, para verificarmos pacotes
onde, pelo menos, os bits SYN e FIN estão habilitados nós poderiamos usar as seguintes opções:
dst port 80 and tcp[13] & 0x3 == 0x3
Com isso nós estamos filtrando os pacotes destinados a um servidor web e que o byte 14 do TCP (oas
opções), tenham o formato 0x3, o que quer dizer que os bits SYN e FIN estão ativados.
Enquanto o uso dessa opção pode ser extremamente complexo, elas oferecem grande leque de opções
que podem nos ajudar a detectar problemas de forma mais fácil e direta.
Exemplo 2.9. Detectando worms

Blaster: dst port 135 and tcp port 135 and ip[2:2] == 48
Welchia: icmp[0] == 8 and ip[2:2] == 92 and icmp[8:4] == 0xAAAAAAAA
O exemplo acima detecta os worms Blaster e Welchia usando algumas características deles. O Blaster
é identificado por atacar sempre através da porta 135 (dst port 135), e por ter um pacote com tamanho
de 48 bytes (ip[2:2] == 48). Já o Welchia possui como principal caracteríticas o fato de ser um pacote
ICMP-Echo (icmp[0] == 8), ter um tamanho de 92 bytes (ip[2:2] == 92), e de o payload do apcote
ICMP começar com 4 bytes contento o valor hexadecimal “A” (icmp[8:4] == 0xAAAAAAAA).
2. TCPdump e Windump
Agora que já sabemos como funcionam os filtros de captura podemos começar o estudo de alguns
analisadores de conteúdo. Para começar vamos analisar o mais clásico de todos: o tcpdump, e sua
versão para windows, o windump.
Ambas as ferramentas são analisadores de conteúdo que trabalham em modo texto e exibem informa-
ções do nosso trafégo de rede. Essas informações não são tão detalhadas quanto aquelas oferecidas
pelo Wireshark, que estudaremos mais adiante, mas permitem ao administrador mais experiente, ve-
rificar e diagnosticar problemas de forma rápida, sem desperdiçar muitos recursos da máquina.
Assim como a maioria dos analisadores de protocolo, o tcpdump possui dissectors, que permitem
que ele converta um pacote capturado da rede para um formato legivel para seres humanos. Como
cada pacote carrega em si um protocolo diferente, também diferente são as saídas produziadas pelo
tcpdump. Na Figura 2.1 é exibida a captura de três pacotes, correspondentes ao hanshake inicial de
uma conexão telnet. Note que o tcpdump mostra diversas informações relacionadas a troca de pacotes.
5
Figura 2.1. Exemplo de captura de pacotes do tcpdump
23:57:57.389417 IP 192.168.254.1.50586 > 192.168.254.254.Telnet: S

553835055:553835055(0) win 5840 <mss
1460,sackOK,timestamp 4687169 0,nop,wscale 6>
23:57:57.391295 IP 192.168.254.254.Telnet > 192.168.254.1.50586: S
3126300124:3126300124(0) ack 553835056 win 5792
<mss 1460,sackOK,timestamp 3815796 4687169,nop,wscale 7>
23:57:57.391330 IP 192.168.254.1.50586 > 192.168.254.254.Telnet: .
ack 1 win 92 <nop,nop,timestamp 4687169
3815796>
Em todas nossas capturas a primeira informação que temos é a hora em que o pacote foi capturado,
baseado no relógio local, e o tipo do pacote capturado (nesse caso IP). Logo depois são exibidas
informações que dependem do protocolo que foi capturado. No caso do TCP/IP, o tcpdump sempre
mostra uma saída com o seguinte formato: src > dst: flags data-seqno ack window
urgent options, onde somente os campos src, dst e flags estão sempre presente. Vamos analisar
cada uma dessas opções em relação a captura acima.
Os dois primeiros campos de nossa saída referem-se aos hosts envolvidos na comunicação, bem como
suas portas. Esse campo possui sempre o formato host.porta > host.port . No caso do primeiro pacote
de nosso exemplo ele está saindo do host 192.168.254.1, na porta 50586, e indo com destino ao host
192.168.254.254, na porta do protocolo Telnet (ou seja, a porta 23).
Note que nesse exemplo foi mostrado apenas o IP das estações envolvidas, mas caso o tcpdump con-
seguisse, através de uma consulta reversa de DNS, os nomes dos hosts em questão seriam exibidos no
lugar de seus IPs. Note também que, ao invés de mostrar o número da porta de destino ele exibiu o
protocolo associado aquela porta. Para fazer isso ele consulta o arquivo services do sistema1.
Logo em seguida são mostradas as flags presentes no pacote. Cada flag é representada por uma letra,
e são uma combinação dos seguintes valores: S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR)
ou E (ECN-Echo). Caso nenhuma flag exista no pacote será mostrado um ponto (“.”). Note no nosso
exemplo que os dois primeiros pacotes possuem a flag S habilitada, já que eles fazem parte da inicia-
lização de uma conexão. O último pacote não contém nenhuma flag habilitada, visto que ele é apenas
um pacote de ACK.
O próximo campo mostra qual o número de sequência do pacote, ou seja, a qual bytes da conexão
aquele pacote se refere. No exemplo acima os dois pacotes inicais possuem um número de sequência
553835055 e 3126300124. Como esses pacotes não contém dados seu tamanho (entre parênteses) é
zero.
Quando o campo ack está presente significa que o host que está enviando o ack recebeu um determi-
nado número de bytes e está agora esperando pelo pacote com um número de sequência indicado,
como é o caso do segundo pacote. No entanto, note que no o terceiro pacote informa q está esperando
receber um pacote com número de sequência igual a um. Isso ocorre pois, depois que o inicio de uma
conexão foi detecado, o tcpdump imprime o valor do ack relativo ao inicio da conexão, e não mais
o número de sequência original.
Os parâmetro win indica o tamanho da janela disponível pelo host para receber pacotes adicionais. O
campo urg aparece com seu valor igual a 1 um quando o pacote possui seu bit URG marcado. Como
última saída o tcpdump mostra, entre os sinais de maior e menor, as opções presentes no pacote.
Como foi dito o tcpdump pode interpretar vários protocolos de rede, o exemplo anterior cobre apenas
as opções disponiveis para pacotes TCP. A Figura 2.2 e Figura 2.3 mostram exemplos adicionais
referentes a uma captura pacotes arp e DNS respectivamente.
1
Em sistemas Linux esse arquivo normalmente está localizado em /etc/, enquanto que no Windows ele fica em C:\WINDOWS\system32\drivers
\etc.
6
Figura 2.2. Exemplo de captura de pacotes AR
11:05:35.223066 arp who-has 192.168.254.1 tell 192.168.254.254

11:05:35.223098 arp reply 192.168.254.1 is-at 00:11:d8:37:d8:b9
Figura 2.3. Exemplo de captura de pacotes DNS
11:03:57.672263 IP 192.168.254.1.32919 > 192.168.254.254.53:

52466+ PTR? 122.110.132.222.in-addr.arpa. (46)
11:03:59.301428 IP 192.168.254.254.53 > 192.168.254.1.32919:
52466 NXDomain 0/1/0 (104)
11:04:01.171547 IP 192.168.254.1.32919 > 192.168.254.254.53:
21306+ A? www.uol.com.br. (32)
11:04:01.629648 IP 192.168.254.254.53 > 192.168.254.1.32919:
21306 1/0/0 A 200.221.2.45 (48)
A listagem abaixo mostra algumas das opções mais comumentes usadas quando estamos fazendo uma
captura usando o tcpdump ou o Windump.
Opções básicas tcpdump e Windump
-n Desabilita a resolução de nomes normalmente feita por essas aplicações. Isso pode aceleram
em muito o processo de exibição dos pacotes iniciais, já que não vai haver um delay para
a resolução reversa de nomes. É sempre recomendável que essa opção seja usada e, caso
necessário, o nome de um host individual seja traduzido depois.
-i Define em qual interface o tcpdump deve escutar. Por padrão ele escuta na primeira interface
encontrada. Existe a opção de se escutar em todas as interfaces da máquina usando a pseudo
interface any, no entanto nesse caso o modo promiscuo não vai poder ser habilitado. No
Windows essa opção é um ID que vai de 1 até o número de interfaces instaladas na máquina.
-D Lista as interfaces instaladas na máquina e que podem ser usadas pelo tcpdump. No Win-
dows também mostra ID que devemos usar para especificar a interface que queremos cap-
turar.
-p Desabilita o modo promiscuo. Desse modo apenas pacotes destinado a máquina onde o tcp-
dump está rodando vai ser capturado. Note que, caso a interface de rede que queremos cap-
turar já esteja em modo promiscuo (habilitado por um outro programa), essa opção não vai
desabilitar esse modo. Caso queiramos ter certeza que estamos capturando somente pacotes
destinados a nossa máquina podemos usar o seguinte filtro: ether host {local-hw-
addr} or ether broadcast.
-w Salva os pacotes capturar no arquivo especificado, ao invés de mostrá-los na tela. Essa opção
é útil quando queremos capturar pacotes em um dado local para posterior analise em uma
outra ferramenta (como o Wireshark).
-r Lê os pacotes de um arquivo dado, ao invés de a partir da interface de rede. Útil para verificar
o conteúdo de uma seção capturada anteriormente com a opção -w.
-s Captura somente o número de bytes specificados de cada pacote. O valor padrão, 68, é
suficiente para maioria das capturas em ambientes TCP/IP. É interessante que essa opção
fique com o menor valor possível para que possamos ter uma captura enxuta. Quanto mais
informação for capturada de cada pacote mais lenta ela ficará.
-x, -xx, Essas opções permitem mostrar o conteúdo do pacote em sua forma hexadecimal (-x e -
-X, - xx), ou em hexadimal e ASCII (-X e -XX). Pode-se escolher entre mostrar informações da
XX camada de dados (-xx e -XX) ou não (-x e -X).
7
3. Wireshark
Enquanto o tcpdump e o Windump são ferramentas fantasticas, que permitem que capturemos pacotes
em qualquer lugar e a qualquer momento eles não oferecem descrições minuciosas sobre os pacotes
capturados. Além disso, para poder tirar proveito máximo dessas ferramentas é necessário que o ana-
lista conheça diversas minuciais dos protocolos com os quais ele está trabalhando. Por fim, uma outra
característica negativa dessas ferramentas (para alguns) é que elas funcionam em linha de comando.
É então que entra em ação o Wireshark™. Um analisador de protocolo com interface grafica construído
tendo como base a libpcap, que não só oferece todas as funcionalidades do tcpdump como muito mais.
Por exemplo, atualmente o Wireshark possui mais de 400 dissectors, isto é, ele pode interpretar e
exibir informações detalhadas sobre mais de 400 protocolos de rede. Essa lista inclui não somente
protocolos da familia TCP/IP como também de redes IPX e AppleTalk, por exemplo. Além de todas
essas características ele está disponível tanto para Windows quanto para Linux!
A tela inicial do Wireshark pode ser vista na Figura 2.4. Nela nós podemos ver como é dividida a
interface principal do Wireshark. Nessa figura nós podemos destacar quatro áreas:
barra de filtragem Essa é a caixa de texto presente logo abaixo da barra de me-
nu do Wireshark. Ela permite que sejam definidos filtros de vi-
sualização que podemos usar para filtrar pacotes depois de já
capturados. As opções de filtragem de exibição serão vistas em
mais detalhes na Seção 3.2.
lista de pacotes É a parte colorida da figura. Nessa parte são exibidos algumas
informações sobre todos os pacotes que foram capturados pelo
wireshark.
detalhamento de pacote Mostra informações mais detalhadas de cada pacote. Em mui-

tos casos é possível ver o valor de todos os campos de um pa-
cote exibidos de forma clara.
visão em bytes do pacote Para aqueles mais “hardcore” que desejam ver cada byte do
pacote em questão, tanto no formato hexa quanto em ASCII.
Essa saída é idêntica aquela conseguida com a opções -XX do
tcpdump.
É interessante notar também que existe uma sincronização entre os dados exibidos/selecionados na
parte de detalhamento de pacotes e a visão em bytes, de tal forma que ao selecionarmos um campo
na visão de detalhamento a sequência de bytes correspondente a essa opção será também selecionada
na visão em byte, e vice-versa.
8
Figura 2.4. Tela principal do Wireshark
9
Figura 2.5. Visão detalhada de pacote TCP
3.1. Opções de captura

O inicio de uma sessão de captura é onde toda diversão começa no Wireshark. Uma seção de captura
pode ser iniciada de diversas maneiras. Uma delas é acessando a opção Capture # Options (C-k), a
partir do menu principal. Para pararmos uma captura temos de acessar a opção Capture # Stop (C-e).
Quando exibir as opções de captura nos deparamos com a tela mostrada na Figura 2.6. Nela podemos
ver todas as opções disponíveis para fazermos uma captura.
10
Figura 2.6. Opções de captura do Wireshark
As tabelas a seguir mostram um resumo de cada uma das opções oferecidas na tela acima. Cada tabela
mostra as opções disponíveis nos frames com o nome dado.
11
Tabela 2.1. Opções de “Capture”
Interface Permite selecionar a itnerface onde será feita a

captura. Por padrão o Wireshark escuta na primei-
ra interface não loopback que ele encontra, mas
pode-se mudar essa opção escolhendo-se uma das
interfaces listadas nessa guia. Note que em alguns
sistemas nem todas as interfaces podem ser lista-
das, em especial, em sistemas windows a interfa-
ce de loopback nunca esta disponível.
IP Address Esse campo mostra o endereço IP associado a in-
terface selecionada. Caso a interface não possua
nenhuma IP associado a ela será exibido a mensa-
gem “unknow”.
Link Layer Header Type A depender da interface selecionada esse campo
pode estar habilitado para que seja possível esco-
lher qual meio físico queremos capturar. Dificil-
mente essa opção precisará ser alterada.
Buffer Size Opção disponível somente em sistemas Windows,
que permite modificarmos o tamanho do buffer de
armazenamento de pacotes capturados. Aumentar
o valor dessa opção (que tem valor padrão 1Mb)
pode ajudar caso tenha-mos cenários onde muitos
pacotes estão sendo descartados.
Capture packets in promiscuos mode Habilita a captura de pacotes em modo promiscuo.
Caso essa opção esteja desmarcada apenas paco-
tes originados ou destinados a máquina onde es-
tamos serão capturados. Do mesmo modo que no
tcpdump, essa opção não tem efeito caso a inter-
face já esteja em modo promiscuo.
Limit each packet to n bytes Permite selecionarmos quantos bytes queremos
capturar de cada pacote. O padrão no Wireshark
é capturar 65535 bytes de cada pacote, caso es-
sa opção seja zero todo o pacote será capturado.
Pode ser interessante diminuirmos o valor desse
campo caso não estejamos interessados em todas
as informações do pacote, ou então quando que-
remos obter um melhor desempenho nas nossas
capturas, já que quanto menos informações captu-
rarmos menor será o trabalho que nossa CPU vai
ter.
Capture filter Como o Wireshark é baseado na libpcap, é pos-
sível especificarmos filtros de captura no mesmo
estilo daqueles vistos na Seção 1.1. Todas as op-
ções e considerações feitas naquela seção se apli-
cam aqui. Note que o Wireshark também possui a
opção de filtros de exibição (Seção 3.2), mas es-
tes tem um objetivo completamente diferente dos
filtros de captura.
12
Tabela 2.2. Opções de “Capture File(s)”
File Esse campo, caso preenchido, define o arquivo

onde os pacotes capturados vão ser armazenados.
Caso ele esteja em branco então os pacotes são ar-
mazenados num arquivo temporário que será des-
cartado quando o programa for fechado.
Use multiple files É possível salvar os pacotes capturados em vári-
os arquivos. Isso pode ser interessante caso quei-
ramos deixar os pacotes menores e mais fáceis de
serem manipulados. O primeiro arquivo tem o no-
me especificado de acordo com o campo acima,
os subsequentes tem um número, começando de 1,
adicionado ao seu nome. Um novo arquivo é gera-
do com base em uma das duas condições a seguir.
Next file every... Cria um novo arquivo assim que o número espe-
cifico de bytes, kilobytes, megabytes ou gigabytes
tiver sido capturado.
Next file every... Cria um novo arquivo assim que o número espe-
cifico de segundos, minutos, horas ou dias tiver
passado.
Ring buffer with n files Cria um buffer circular para o armazenamento dos
dados. Nesse modelo existem, no máximo n ar-
quivos para armazenar os pacotes, quando o nú-
mero limite de arquivos é alcançado o mais antigo
é então usado para armazenar os novos pacotes, e
os dados iniciais são perdidos.
Stop capture after n file(s) Para a captura assim que o número especificado
de arquivos tiver sido criado.
Tabela 2.3. Opções de “Stop Capture...”
... after n packet(s) Essa opção serve para parar a captura depois que o
número definido de pacotes tiver sido capturado.
... after n megabytes(s) Essa opção serve para parar a captura depois que
o número definido de megabytes tiver sido captu-
rado.
... after n minute(s) Essa opção serve para parar a captura depois que
o número definido de minutos tiver se passado.
13
Tabela 2.4. Opções de “Display Options”
Update list of packets in real time Serve para atualizar a lista de pacotes em tempo
real com os novos pacotes capturados. Essa op-
ção consome mais CPU e portanto pode gerar uma
maior perda de pacotes.
Automatic scrolling in live capture Permite que a lista de pacotes seja roalda de forma
que os novos pacotes estejam sempre visiveis. Es-
sa opção pode tornar o acompanhamento da cap-
tura extremamente complicada em redes com alto
volume.
Hide capture info dialog Mostra ou esconde uma janela contendo informa-
ções sobre a captura. Essas informações, entre ou-
tras coisas, contém o número de pacotes captura-
dos até o momento bem como a porcentagem dos
tipos de protocolos capturados.
Tabela 2.5. Opções de “Name Resolution”
Enable MAC name resolution Permite ao Wireshark “traduzir” o nome do fa-

bricante de uma placa de rede, mostrando o en-
dereço MAC no formato: FAB:XX:XX, onde
XX:XX:XX são as seis últimas letras do endere-
ço MAC da placa, e FAB é o nome do fabricante
daquela placa.
Enable network name resolution Permite ao Wireshark tentar resolver o nome dos
hosts que estão sendo capturados na rede. Esta op-
ção torna a exibição de pacotes mais lenta, já que
uma consulta DNS tem de ser feita antes da exibi-
ção, além de gerar um trafégo adicional na rede.
Enable transport name resolution Permite ao Wireshark exibir o nome dos protoco-
los usados ao invés de suas portas, do mesmo jeito
que o tcpdump. Essa opção permite que ao invés
de vermos um pacote destinado a porta 80, veja-
mos que ele foi destinado a porta, comumente as-
sociada, HTTP.
3.2. Filtros de exibição

Os filtros de exibição do Wireshark são uma de suas maiores vantagens dessa ferramenta. Com esses
filtros nós podemos fazer uma filtragem extremamente detalhada dos pacotes que estamos analisando
para encontrar diretamente a situação que queremos depurar. A desvantagem dos filtros de exibição
é que ele são lentos quando capturados com os filtros de captura, já que a analise dos pacotes tem de
ser feita num nível mais alto, consumindo assim mais CPU. Usar filtros de exibição para um volume
muito grande de pacotes também pode ser uma tarefa lenta.
Esses filtros permitem, entre outras coisas, verificarmos: o tipo do protocolo da captura, a prsença de
um campo no pacote, o valor de um campo, comparar valores de dois campos, etc. Para trabalharmos
com filtros de exibição podemos usar a barra de filtro disponivel logo abaixo da barra de menus na
tela principal do Wireshark.
Vamos trabalhar com alguns exemplos para podermos entender melhor como funciona esse processo
de captura. Por exemplo, caso quisessemos filtrar nossa captura de modo que ela exibda somente
pacotes TCP, bastaria colocarmos a linha tcp, na barra de filtragem. O resultado disso é mostrado
na Figura 2.7.
14
Figura 2.7. Filtrando pacotes TCP no Wireshark
Note que nessa situação somente os pacotes TCP são exibidos. Perceba na primeira coluna, que o
número do pacote começa por 11, isso ocorre pois os 10 primeiros pacotes não eram TCP, e por isso
estão ocultos. No entanto esses pacotes continuam presentes na nossa captura, o filtro serve apenas
para exibir ou esconder os pacotes.
Além do TCP o Wireshark aceita diversos outros protocolos, como por exemplo, DNS, ARP, HTTP,
etc. No entanto o tipo dos protocolos são baseados na verdade na porta de origem/destino usada. Ou
seja, se tivermos um servidor HTTP escutando na porta 83 nós não poderemos usar o filtro HTTP
para detectar esse trafego.
No entanto essa barreira pode ser contornada. Caso saibamos que existe um servidor Web rodando na
porta 8083 nós podemos definir que todo o trafégo que for destinado a porta 8083 deve ser tratado
como HTTP. Para fazer isso basta selecionarmos um dos pacotes envolvidos na conexão é acessarmos
a opção Analyse # Decode As..., a partir daí nós podemos definir que todos os pacotes destinados a
porta 8083 devem ser tratadoos como pacotes HTTP. Isso pode ser visto na Figura 2.8.
15
Figura 2.8. Selecionando como decodificar um pacote
Mas o que fazer quando não sabemos qual protocolos estão passando por nossa rede? O Wireshark
pode ajudar nessa questão também. Ele nós permite procurar em todo o pacote capturado por qualquer
string que especificarmos. Juntando essa funcionalidade com o conhecimento do protocolo HTTP nós
podemos criar um filtro que vai procurar, em todos os pacotes, a ocorrência palavra HTTP/1.1, que
identifica uma resposta HTTP. Com isso nós podemos saber quais pacotes estão relacionados com
uma conexão HTTP e aplicar a opção de decode detalhada anteriormente.
Para procurarmos por todos os pacotes que contem uma palavra especifica nós podemos usar o ope-
rador contains. Esse operador pode ser aplicado a praticamente todos os campos disponiveis no Wi-
reshark (os mais usados serão vistos na XX). Para verificarmos então uma conexão HTTP podemos
usar a expressão tcp contains "HTTP/1.1".
Além da opção contains o Wireshark possui algumas outras funções de comparação que são descritas
na Tabela 2.6.
Tabela 2.6. Opções de comparação do Wireshark

Literal Simbolico Descrição
eq == Igual
ne != Diferente
gt > Maior que
lt < Menor que
ge >= Menor ou igual
le <= Maior ou igual
Como já dito anteriormente o Wireshark possui centenas de protocolos que ele pode identificar, e para
cada um desses protocolos ele pode também mostrar (praticamente) todas as características dele. Além
de servir para podermos visualizar em maiores detalhes um protocolo essas características também
podem servir como mecanismos de filtragem.
Por exemplo, como já visto anteriormente o Wireshark pode exibir todos os campos relacionados a
pacotes da pilha TCP/IP. Podemos então usar essas informações para filtrar os pacotes exibidos. Di-
gamos que queremos ver somente os pacotes IP vindo do host 192.168.254.1, para isso basta usarmos
o filtro:
ip.src == 192.168.254.1
Esse filtro nós diz que: para pacotes IP, verifique se o campo src (endereço de origem), é igual a
192.168.254.1. Caso queiramos filtrar apenas pacotes Telnet, podemos usar o filtro:
16
tcp.port == 22
Para termos acesso a todos os possíveis filtros basta clicarmos na opção Expression na barra de filtra-
gem do Wireshark. Será então exibida para nós a tela mostrada na Figura 2.9. Note a quantidade de
protocolos que podemos escolher para filtrar, edentro de cada um deles a quantidade de opções que
temos. Uma lista detalhada de todo os protocolos, campos e suas descrições pode ser encontrado em
http://www.wireshark.org/docs/dfref/.
Figura 2.9. Configuração de filtros de exibição
As expressões detalhadas anteriormente podem também ser combinadas entre si das mais diversas
maneiras usandos os operadores lógicos descritos na Tabela 2.7.
Tabela 2.7. Operações lógicas com expressões
Literal Simbolico Descrição

and && E lógico
or || Ou lógico
xor ^^ Ou exclusivo lógico
not ! Negação
[...] Substring
Desses talvez o operador de substring mereça uma explicação mais detalhada. Esse operador permi-
te que comparemos certos valores delimitados dentro de um campo com outros. Por exemplo, caso
desejassemos filtrar todos os pacotes capturados que possuem placas de rede da VMware. Através
do cadastro de OUIs do site da IETF (http://standards.ieee.org/regauth/oui/index.shtml), nós podemos
descobrir que um dos OUIs atribuitos à VMWare é 00:0C:29. Com essa informação nós podemos criar
o seguinte filtro: eth.addr[0-2] == 00:0C:29, que diz que no campo eth.addr (o MAC da
placa), os bytes de 0 até 2 devem ter o valor 00:0C:29.
A Tabela 2.8 mostra os possíveis formatos que podem ser usados para verificações usando substrings.
17
Tabela 2.8. Opções de uso do operador substring

Formato Descrição
[x-y] O caso já mostrado. Define que a comparação de-
ve ser feita com os valoes entre os bytes x e y.
[x:y] Deve-se comparar o campo de tamanho y que se
inicia em x.
[:x] Deve-se comparar tudo desde o começo até o byte
x.
[x:] Deve-se comparar tudo desde o byte x até o final
do campo.
[x] Deve-se comparar o valor do byte x.
[x:y,z-w,k] É possível combinar qualquer um dos formatos
acimas de uma única vez, separando os delimita-
dores por virgula.
3.3. Analises dos pacotes

Além de ser uma grande ferramenta de captura o Wireshark também permite que nós façamos diversas
análises com os pacotes que capturamos. Uma dessas analises nos permite verificar de forma textual
todo o trafégo que passou numa conexão TCP/IP. Isto é extremamente interessante quando queremos,
por exemplo, capturar senhas que trafegam em texto claro, ou então depurar uma conexão HTTP, de
forma que posamos ver todo o conteúdo HTML na tela.
Para ativarmos essa opção basta selecionarmos um dos pacotes que faz parte da conexão que queremos
verificar, e selecionar a opção Capture # Options, a partir do meu principal. Podemos ver na Figura 2.10
um exemplo que mostra as informações capturadas numa seção telnet. Note como podemos fácilmente
identificar o usuário e a senha usados na conexão. Essa é a principal razão pela qual devemos usar
SSH ao invés de Telnet.
Figura 2.10. Funcionalidade follow tcp do Wireshark
Além disso o meu Statistics nós permite obter as mais diversas informações detalhadas sobre a nossa
captura. A primeira opção que nós temos quando acessamos esse campo é Summary. Essa opção
mostra uma visão detalhada de nossa captura, informado, entre outras coisas, o momento em que a
captura teve inicio e quando ela teve fim, qual a interface que foi usada para a captura e qual filtro
de catura foi usado.
18
Ainda nessa tela nós temos algumas informações gerais sobre os pacotes, que mostra,: o tmepo total de
captura, o número total de pacotes e de bytes capturados, o tamanho médio de cada pacote e a veloci-
dade média em pacotes, byte e megabits por segundo. Note na que essas informações são exibidas tanto
para a captura como um todo quanto para somente os pacotes que estão sendo exibidos no momento.
Figura 2.11. Resumo das propriedades da captura
O detalhamento da hierarquia dos protocolos também é de extrema valia para o diagnostico da rede.
Como pode ser visto na Figura 2.12 através dessa opção é exibido uma visão detalhada de todos os
protocolos e subprotocolos que foram capturados. Essa opção pode ser acesar através do menu Staistics
# Protocol Hierarchy.
19
Figura 2.12. Hierarquia de protocolos
Alguns pontos no entanto merecem destaque quanto as informções exibidas aqui:
• O campo % Packet mostra o valor porcentual do protocolo em questão em relação a toda a captura,
e não em relação ao protocolo superior na hierarquia.
• Quase todos os pacotes contém mais de um protocolo, assim a soma da porcentagem total será
sempre maior que 100%.
• Alguns pacotes podem não conter camadas mais altas, assim a soma de todos os sub-protocolos vai
ser menor que o total de pacotes daquele tipo. Por exemplo, na figura o protocolo TCP é responsável
por 43,69% do total de pacotes, no entanto a soma de todos seus subprotocolos não chega a esse
valor. Nessa caso uma razão para isso é que pacotes TCP ACK não são contatos como pacotes da
camada superior.
• Um mesmo pacote pode conter mais um protocolo do mesmo tipo, como é o caso de protocolos de
tunelamento. Nesass situações o protocolo será contado duas vezes.
Já as janelas de Conversations e Endpoints tem basicamente a mesma idéia: exibir o total de pacotes
trafegados. A diferença é que, enquanto a janela de Endpoints mostra somente quanto cada host tra-
fegou no total, a janela de conversations mostra o volume trafegado em cada conexão estabelecida.
No caso do TCP e do UDP isso quer dizer que cada linha mostra o IP e a porta tanto de origem quanto
de destino. A janela de conversations pode ser vista na . Note que é possível selecionarmos diversos
protocolos na aba superior.
20
Figura 2.13. Analise de “conversas”
Por último vamos dar uma breve olhada na opção de grafico de E/S do Wireshark. Essa opção nós
permite avaliar o trafego presente em nossa rede. Um dos pontos mais interessantes dessa opção é
que nós podemos definir filtros (usando a sintaxe dos filtros de exibição), e verificar essa variação
em tempo real.
Na Figura 2.14 nós podemos ver um exemplo do grafico de E/S. Note que esse grafico possui três filtros
habilitados. O primeiro (em preto) mostra todo o trafego capturado, o segundo (vermelho) possui um
filtro para exibir somente pacotes http, e o terceiro (verde) filtra pacotes cuja porta TCP seja 39940.
Alguns pontos interessantes de configuração são:
Tick interval Intervalo de captura da amostragem.
Pixels per tick Define quantos pixels un tick ocupa. Quando menor esse valor mais “aper-
tado” fica o grafico. Como consequências podemos ver um espaço de tempo
maior sem usarmos a barra de rolagem.
Unit Define a unidade usada para exibição no grafico. Os valores são: Pac-
kets/Tick, Bytes/Tick, Bits/Tick e Advanced.
21
Figura 2.14. Grafico de E/S de rede
4. Cain & Abel
5. Dsniff
6. Contramedidas
6.1. Detectando sniffers
22
Capítulo 3. Escaneamento de rede
1. Introdução
2. Network Scan
2.1. Ping Sweep
2.1.1. ICMP Sweep
2.1.2. Arp Sweep
2.2. Tracerouting
2.2.1. TCP Traceroute
3. Port scanning
3.1. Nmap
3.1.1. Tipos de scan
Connect
Syn scan
Ack scan
Fin scan
XMas scan
Null scan
UDP Scan
3.2. p0f
4. Scan de vulnerabilidades
23
Parte II. Ataques e defesas
as camadas de rede
Capítulo 4. Camada de dados
1. Introdução
2. MAC Spoof
Essa é a técnica mais básica para o ataque à camada 2. Ainda veremos técnicas de spoof aplicadas em
muitas outras partes dos nosso estudo, e em todas ela possui o mesmo funcionamento básico: permitir
que finjamos ser quem não somos.
No caso da camada de dados isso é possível através da mudança do endereço MAC associado a nossa
placa de rede. Enquanto o endereço MAC está definido na placa de rede, é o sistema operacional que
decide se esse endereço obtido da placa vai ser usado ou não.
Em máquinas Linux é possível mudar o endereço MAC de uma máquina usando o ifconfig, utilitário
para a configuração de placa de rede. A sintaxe usada para mudar o endereço MAC de uma interface
de rede é o seguinte:
ifconfig <interface> hw ether <novo endereço mac>
Veja o exemplo abaixo, onde mudamos o MAC da interface eth0.
root@gokou:~#ifconfig eth0
eth0 Encapsulamento do Link: Ethernet Endereço de
HW 00:0C:29:23:EB:32
inet end.: 192.168.4.128 Bcast:192.168.4.255
Masc:255.255.255.0
endereço inet6: fe80::20c:29ff:fe23:eb32/64 Escopo:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1
pacotes RX:366549 erros:0 descartados:0 excesso:0 quadro:0
Pacotes TX:230521 erros:0 descartados:0 excesso:0
portadora:0
colisões:0 txqueuelen:1000
RX bytes:503719794 (480.3 MB) TX bytes:91920219 (87.6 MB)
IRQ:17 Endereço de E/S:0x1400
root@gokou:~# ifconfig eth0 hw ether 0a:0b:0c:0d:0e:0f
root@gokou:~# ifconfig eth0 down
root@gokou:~# ifconfig eth0 hw ether 0a:0b:0c:0d:0e:0f
root@gokou:~# ifconfig eth0 up
root@gokou:~# ifconfig eth0
eth0 Encapsulamento do Link: Ethernet Endereço de
HW 0A:0B:0C:0D:0E:0F
inet end.: 192.168.4.128 Bcast:192.168.4.255
Masc:255.255.255.0
endereço inet6: fe80::80b:cff:fe0d:e0f/64 Escopo:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1
pacotes RX:366550 erros:0 descartados:0 excesso:0 quadro:0
Pacotes TX:230542 erros:0 descartados:0 excesso:0
portadora:0
colisões:0 txqueuelen:1000
RX bytes:503719854 (480.3 MB) TX bytes:91923437 (87.6 MB)
IRQ:17 Endereço de E/S:0x1400
Veja abaixo dois pings executados a partir do host em questão e capturados com o tcpdump -e, um
antes da mudança do MAC e outros depois.
25
Camada de dados
21:58:20.858195 192.168.4.128 # 192.168.4.1 ICMP Echo (ping)

request
Ethernet II, Src: 00:0c:29:23:eb:32, Dst: 00:50:56:c0:00:01
21:59:48.086708 192.168.4.128 # 192.168.4.1 ICMP Echo (ping)
request
Ethernet II, Src: 0a:0b:0c:0d:0e:0f, Dst: 00:50:56:c0:00:01
Em máquinas Windows a mesma coisa pode ser feita usando-se...
Além dessas opções é possível fazer MAC Spoof a nível de linguagem de programação, usando raw
sockets em ambientes Unix ou Windows. Para os que conhecem Python o Scapy torna essa tarefa
muito mais simples.
3. ARP Flood
Esse tipo de ataque é comumente em redes formadas por Switches, e consiste em enviar vários pacotes
ARP para o switch de forma que ele fique tão sobrecarregado que acabe agindo como um HUB.
A idéia por trás desse tipo de ataque é que todo switch na verdade é um computador dedicado, e co-
mo tal possui recursos limitados. Um desses recursos é chamado de CAM (Content Addressable Me-
mory), e é nele que ficam armazenadas as tabelas ARP usadas pelo switch. Se um atacante enviar um
grande número de pacotes com informações de MAC incorretas ele pode sobrecarregar essa memória,
fazendo com o switch não consiga aprender novos IPs. Depois que isso acontece, para evitar uma total
paralização da rede, o switch passa a operar em um modo parecido com um HUB, enviando todos os
pacotes para todas as portas (já que ele não tem mais como saber qual MAC está associado a qual
porta), permitindo assim a um atacante escutar o todo o trafego que passa por aquela rede, e mesmo
realizar ataques de homem do meio.
Esse tipo de ataque foi inicialmente concebido por Ian Vitek em 1999, e pode ser realizado atualmente
através de diversas ferramentas, como o dsniff.
4. ARP Poisoning
Envenenamento de ARP é a técnica básica para poder escutarmos o trafego alheio em uma rede co-
mutada. Esse técnica consiste basicamente em enviarmos pacotes ARP forjado para um alvo, de tal
forma que ele pense que nós somos uma outra máquina da rede.
5. Ataques DHCP
5.1. DHCP Starvation
5.2. DHCP Rogue Server
6. Ferramentas
6.1. Dsniff
6.2. gobbler
6.3. arpwatch
26
Camada de dados
6.4. ettercap
6.5. john the ripper
6.6. cain and abbel
7. Protegendo a camada 2
A camada de dados implementada no modelo Ethernet é extremamente vulnerável, não possuindo
nenhuma medida de segurança que possa ser implementada no próprio protocolo. O meio mais comum
de proteção contra ataques nessa camada é a utilização de switches que possam associar um MAC a
um porta, de tal forma que o ARP Spoof possa ser eliminado.
Enquanto a eliminação do ARP Spoof já é proteção, ela está longe de ser suficiente para evitar outros
tipos de ataque, como o envenenamento de ARP e ataques a DHCP, que independem de um MAC
falsificado. Para a primeira situação uma solução é a implementação de switches mais inteligentes que
possam detectar uma resposta ARP suspeita e barra-la. Além disso os sistemas operacionais devem
ser atualizados para que seja possível evitar envenenamentos de ARP usando endereços de broadcasts.
Já para a situação do DHCP existe uma RFC que detalha a utilização de autenticação para mensagens
DHCP (RFC 3118 – Authentication for DHCP Messages). Resta agora saber quando os desenvolve-
dores irão implementar essa técnica nos seus produtos, e mais ainda, quando ela se tornará padrão
de mercado.
27
Capítulo 5. Camada de rede
1. Introdução
2. IP Spoof
3. Ataques ICMP
3.1. Mudança de rota usando ICMP
3.2. Teardrop/Ping of Death
4.1. Evitando redirects
4.2. Evitando spoof no sistema operacional
4.3. IPSec
28
Capítulo 6. Camada de transporte
1. Introdução
2. Syn Flood
3. TCP Hijacking
4. UDP Flooding
Como o UDP é um pacote não orientado a conexão não existe muito que um atacante possa fazer
contra ele a nivel de rede. O melhor que um atacante pode fazer usando UDP é tentar uma avalanche
de pacotes UDP para a vítima na esperança que o volume de dados possa derrubar a máquina.
No entanto é bom notar que o protocolo UDP é pouco vulnerável a ataques a nível de rede, o que não
quer dizer que as aplicações que fazem uso desse protocolo sejam automaticamente seguras. Existem
diversos protocolos de camada sete (como o DNS), que usam UDP, e já apresentaram no passado
diversos problemas de segurança.
5.1. Protegendo-se de synfloods
29
Capítulo 7. Camada de Aplicação
1. DNS
1.1. DNS Spoof
1.2. DNS Snooping
1.3. MITM
1.4. Protegendo o DNS

DNS Transaction Signatures (TSIG)
2. SMTP
2.1. Spoof de e-mail
3. FTP
4. Telnet
30
Parte III. Ferramentas para proteção
Capítulo 8. Snort
1. Introdução
O Snort é um sistema de detecção de intrusão (IDS) de rede (NIDS), de código livre disponível em
www.snort.org. O objetivo do Snort é monitorar o trafego de rede e avisar caso seja detectado algum
pacote que se encaixa em uma série de regras pré-definidas.
O Snort vem com diversas regras pré-definidas por padrão. Essas regras podem monitoram desde
conexões a servidores de IRC até tentativas de ataques de worms, virus, portscans, etc. Existe ainda
a opção de criar regras personalizadas, o que é extremamente recomendado, visto que cada cenário
é único e deve ser tratado como tal.
Além disso várias das regras que vem por padrão com o Snort devem ser melhor configuradas para
cada ambiente. Por exemplo, o Snort monitora por tentativas de exploração de falhas conhecidas para
servidores IIS, mas se seu ambiente possuir somente servidores rodando Apache os alertas gerados
pelo Snort (apesar de te alertarem de que existe alguém tentando comprometer sua rede), não devem
ser considerados críticos, já que ele não podem afetar suas máquinas.
Um dos pontos chaves para o perfeito funcionamento do Snort é a escolha de sua localização. A escolha
de onde vamos instalar nosso IDS depende em muito do que queremos monitorar. Caso desejemos
monitorar um único host de nossa rede (ou se a rede for composta de apenas uma máquina), o Snort
pode tranqüilamente ser instalado no próprio host. Caso desejemos monitorar um conjunto de máquina
devemos fazer a instalação de tal forma que o Snort fique no mesmo segmento de rede das máquinas
que queremos monitorar e, além disso, ele deve ser capaz de escutar todo o trafego endereçado a
qualquer uma das máquinas.
Um observação antes de começarmos: O Snort é uma ferramenta extremamente ampla de poderosa, e

o que será abordado aqui são somente alguns dos pontos mais importantes de sua configuração. Para
aqueles que desejarem informações mais aprofundadas sobre o Snort é recomendada a leitura do seu
manual, disponível em http://www.snort.org/docs/snort_manual/2.8.0/snort_manual.pdf.
2. Configurando o Snort
O snort.conf é o arquivo que controla todo o funcionamento do Snort. Nele são definidas as regras que
dão ao Snort a sua capacidade de detectar ataques, bem como configurações para o seu funcionando
como, por exemplo, onde e como ele deve guardar informações sobre os alertas detectados.
A seguir serão apresentadas em diversas seções alguns dos comandos usados para a configuração do
snort.
2.1. include
Essa diretiva permite a inclusão de outros arquivos no arquivo de configuração principal do Snort,
possibilitando assim a criação de configurações modulares que podem ser habilitadas ou desabilitadas
de forma mais fácil. A sintaxe dessa comando é bem simples: include <caminho/arquivo>
Por exemplo, caso quiséssemos incluir um arquivo chamado references.config, armazena-

do em /etc/snort/configs poderiámos simplesmente usar o comando include /etc/snort/con-
figs/references.config
2.2. Variáveis
O arquivo de configuração do Snort permite que o usuário defina variáveis que podem então ser usa-
das em qualquer ponto do arquivo de configuração. Essas variáveis servem para que seja possível a
32
Snort
alteração de configurações de forma fácil e pontual, sem precisar realizar mudanças em várias partes
do arquivo.
As variáveis no Snort são usadas para representar três objetos básicos: strings, portas TCP/UDP e
IPs. Para isso o Snort nos permite definir três tipos de variáveis: var, portvar e ipvar. Dessas a última
(ipvar) estará disponível somente quando o Snort for compilado com suporte ao Ipv6. Quando esse
não for o caso devemos usar variáveis do tipo var para representar IPs.
2.2.1. Strings
As variáveis que contém string são as mais simples, possui a forma var <nome_variavel> <string>.
Onde, por convenção, o nome_variavel, é escrito sempre em maiúsculo. Veja exemplo abaixo:
var RULE_PATH /etc/snort/rules
Nesse caso estamos definindo uma variável chamada RULE_PATH que vai conter o valor /etc/
snort/rules.
Agora que temos nossa primeira variável devemos saber como usá-la. Sempre que quisermos obter
o valor de uma variável devemos usar a sintaxe $VARIAVEL. O exemplo abaixo ilustra a utilização
combinada do uso de variáveis com o comando include:
var RULES_PATH rules/

include $RULE_PATH/example.rule
2.2.2. Porta
As variáveis de porta permitem a definição de uma única porta (usando um valor entre 0 e 65535), de
um conjunto de portas (separadas por virgulas) ou até mesmo de um intervalo de portas(usando “:”).
Também é possível especificar qualquer porta usando o operador especial any. Veja abaixo alguns
exemplos de definições de porta:
portvar EXEMPLO1 80
var1 PORT_EXEMPLO2 [1]
var1 EXEMPLO2_PORT [80:90]
portvar EXEMPLO3 any
portvar EXEMPLO4 [80,91:95,100:200]
Nas variáveis declaradas acima estão armazenadas, respectivamente, as portas: 80; 80 a 90; 1; todas;
80, 91 a 95 e 100 a 200.
É possível também inverter o conteúdo de uma variável de portas usando o operador “!”. O exemplo
abaixo ilustra seu uso. A variável em questão vai então ser equivalente ao uso de todas as portas,
exceto aquelas entre a 70 e a 90.
portvar EXEMPLO5 [!70:90]
2.2.3. IP
Variáveis que armazenam IP podem armazenar um único IP ou um conjunto desses. Além disso é
possível usar a notação CIDR para representar uma subrede completa. Os operadores any e ! também
podem ser aplicados aqui.
O exemplo abaixo ilustra uma situação onde queremos definir uma variável que referencie o host
1.1.1.1 e a rede 2.2.2.0/25, com exceção das máquinas 2.2.2.2 e 2.2.2.3. Note que esse tipo de operação
também pode ser usado com portas.
1
Atualmente o uso de var para a declaração de portas ainda é permitido, desde que o nome da variável comece ou termine com a palavra PORT.
Esse suporte será removido em versões futuras do Snort.
33
Snort
[1.1.1.1,2.2.2.0/24,![2.2.2.2,2.2.2.3]]
2.2.4. Variáveis importantes no snort.conf

O snort.conf vem por padrão com algumas variáveis pré-definidas, algumas das mais importantes são
detalhadas abaixo.
HOME_NET Define qual a rede definida como “interna”, isto é, a rede onde o Snort se encon-
tra. Essa definição é de extrema importância pois a maioria das regras usa essa
variável para verificar se os ataques são direcionados as redes que eles devem
proteger.
EXTERNAL_NET É a chamada rede “externa”, ou seja, o ambiente hostil que estará tentando invadir
nossos servidores. Normalmente ele pode ser definido como !$HOME_NET.
Em casos onde se deseja monitorar uma rede LAN deve-se configurar tanto
HOME_NET quando EXTERNAL_NET para any, já que nesse caso não existe
rede interna/externa.
*_SERVERS Existem diversas variáveis do tipo HTTP_SERVERS e SMTP_SERVERS que

servem para que possamos definir quais são os nossos servidores para cada tipo
de serviço. Isso é usado para evitar que o Snort perca tempo verificando um a
existência de um ataque na porta 80 do nosso servidor de e-mail, por exemplo.
Por padrão essas variáveis são definidas com o valor de $HOME_NET.
Apesar de favorecer o desempenho do Snort essas variáveis podem ser uma faca
de dois gumes, já que nem sempre a nossa configuração de rede é estática e algu-
ém pode resolver instalar um web-mail no seu servidor SMTP. A melhor política
é deixar essas variáveis com seu valor padrão, a não ser que exista um processo
de controle muito bem estabelecido na empresa, o qual vai permitir que essas
configurações sejam alteradas para refletir a nova realidade.
RULE_PATH Essa variável guarda o local onde as suas regras do Snort estão armazenadas.
Ela já foi vista em alguns exemplos acima, onde ela é usada em conjunto com
o include.
2.3. Output
O Snort deve armazenar seus alertas em algum lugar,e como sempre a flexibilidade é um dos carros
chefes aqui. A opção output, permite a utilização de plugins para definir onde o snort vai armazenar
os alertas gerados. As possibilidades de saída incluem, entre outras, um arquivo de texto plano, um
servidor de syslog ou um banco de dados. É possível também usar múltiplas saídas para um armaze-
namento redundante. O formato para a configuração de um dos plugins de saída é o seguinte:
output <plugin>: <configurações>
Vamos agora apresentar alguns dos plugins disponíveis para geração de saídas no Snort.
2.3.1. alert_full e alert_fast

Por padrão o Snort loga seus alertas para o arquivo alert no diretório logs (por padrão /var/log/snort/).
Esse arquivo é um arquivo de texto e tem informações completas sobre os pacotes que geraram os
alertas. Um exemplo de saída desse tipo de alerta pode ser visto abaixo.
[**] [122:1:0] (portscan) TCP Portscan [**]

[Priority: 3]
01/06-20:59:40.744183 192.168.4.1 -> 192.168.4.128
PROTO:255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:158 DF
34
Snort
Nessas linhas podemos ver todas as informações referentes ao ataque que foi detectado. A primeira
linha pode ser vista como o cabeçalho do alerta, e detalha qual o código do alerta (122:1:0, que pode ser
usado para verificar no site do Snort informações mais detalhadas sobre esse ataque) e uma informação
descritiva do ataque. A segunda linha mostra a prioridade desse alerta. A prioridade mais importante
é a um. A terceira e a quarta linha mostram detalhes sobre informações dos protocolos de rede do
pacote referente ao ataque.
Esse tipo de alerta pode ser configurado usando o plugin alert_full. Esse plugin tem como parâmetro
o arquivo onde os logs devem ser armazenados. Por exemplo, caso desejássemos armazenar os alertas
no arquivo meus_alertas, poderiamos colocar a seguinte linha no snort.conf:
output alert_full: meus_alertas
Para aqueles que acham que os alertas completos são muito extensos existe outra opção, que gera
os alertas em apenas uma linha. Esse plugin é chamado de alert_fast. Nele o mesmo alerta mostrado
acima no modo rápido teria a seguinte forma:
01/06-20:59:40.744183 [**] [122:1:0] (portscan) TCP Portscan [**]

[Priority: 3] {PROTO:255} 192.168.4.1 -> 192.168.4.128
A sintaxe para a utilização do alert_fast é a mesma do alert_full.
2.3.2. tcpdump_log
Além de gerar alertas o Snort também armazena os pacotes relacionados com o ataque detectado para
que depois possa fazer uma analise dos mesmos. Por padrão os pacotes são armazenados num formato
de texto do próprio Snort. Armazenar os logs nesse formato não é uma boa idéia pois acarreta numa
perda de desempenho muito grande. Uma alternativa é a gravação dos pacotes no formato pcap. Esse
é um formato binário que permite ao Snort ganhar velocidade na gravação do mesmo. Além disso,
como os logs estão agora num formato conhecido, podemos usar diversas ferramentas disponíveis no
mercado para analisá-los (como o Wireshark e o tcpdump).
Para fazer com que o snort gere logs nesse formato devemos usar a diretiva tcpdump_log. A sintaxe
dela é igual aquela do alert_full e alert_fast, esperando somente um nome de arquivo. Para configu-
rarmos o Snort para logar seus pacotes para o arquivo tcpdump.log no diretório padrão de log, basta-
riámos usar o seguinte comando:
output tcpdump_log: tcpdump.log
Uma peculiaridade desse plugin é que ele não gera apenas um arquivo de saída. Cada vez que iniciamos
o Snort um novo arquivo é gerado, com o nome que especificamos e com um timestamp no padrão
UNIX adicionado no final do nome (isto é, o número de segundos passados desde 1° de janeiro de
1970).
2.3.3. Database
Esse plugin permite que armazenos tanto os alertas quanto os logs do Snort um banco de dados. Es-
sa abordagem tem óbvios benefícios tanto no tocante ao desempenho quando no que diz respeito a
possibilidade de manipulação das informações geradas por ele (usando, por exemplo, o BASE). A
configuração desse plugin tem a seguinte sintaxe:
output database: <log | alert> , <tipo do banco>, <lista de

parametros>
A primeira opção define que tipo de informações queremos mandar para o banco de dados. Caso
escolhamos alert, apenas alertas vão ser enviados, caso coloquemos log, tanto as informações de log
(detalhes dos pacotes) quando alertas vão ser enviados para o banco.
A segunda opção define com qual banco de dados nos vamos nos conectar. As opções possíveis são
mssql, mysql, postgresql, oracle e odbc.
35
Snort
A terceira opção são listas de parâmetros usadas para a conexão com o banco de dados. Abaixo segue
uma lista com os parâmetros mais usados:
host Host onde o banco de dados está rodando
port Porta para ser usada na conexão
dbname Nome do banco de dados
user Usuário usado para conexão
password Senha do usuário (em texto plano!)
Por exemplo, caso desejássemos configurar o Snort para enviar todas as suas informações para um
bando de dados mysql configurado na própria máquina poderíamos usar uma linha parecida com a
que segue:
output database: log, mysql, user=root password=mypass dbname=snort

host=127.0.0.1
Existem diversos scripts SQL para criar as tabelas necessárias para o Snort depois do banco ter sido
criado, eles podem ser encontrados no diretório contrib na distribuição do código fonte do Snort.
2.4. Config
O uso da diretiva config permite a mudança de diversos parâmetros para o funcionamento interno do
Snort. Sua sintaxe é a seguinte:
config <diretiva> [: valor]
Iremos listar aqui alguns dos parâmetros mais conhecidos/importantes numa configuração típica.
2.4.1. detection
Permite fazer configurações sutis na engine de detecção do Snort. A opção mais importante aqui é
search-method. Essa opção define qual método o Snort deve usar enquanto verificando os pacotes
por padrões de tentativas de ataque. Essa configuração tem grandes efeitos no uso da memória e na
velocidade com que o Snort consegue processar os pacotes que ele recebe.
Os dois extremos dessa configuração são ac (grande uso de memória e maior velocidade no processa-
mento) e lowmem (baixo uso de memória e baixa velocidade). A diferença do uso de memória entre
um e outro pode chegar até 800%, enquanto que a diferença em velocidade é de cerca de 20%.
2.4.2. interface
Serve para configurar qual interface de rede o Snort deve escutar. No Linux é possível especificar a
interface “any”, que representa todas as interfaces de rede. No entanto esse modo não suporta operar
em modo promíscuo. Essa opção é interessante quando deseja-se monitorar apenas uma parte da rede,
ou então quando múltiplas instâncias do Snort vão estar rodando na mesma máquina. Esse opção
equivale a a opção “-i” da linha de comando do Snort.
2.4.3. logdir
Define em qual diretório o Snort deve armazenar seus logs. O valor padrão é /var/log/snort. Essa opção
equivale a opção “-l” da linha de comando do Snort.
2.4.4. ignore_ports
Serve para definir portas que o Snort vai ignorar enquanto estiver realizando seu processamento. Essa
regra é útil, por exemplo, para evitar alertas desnecessários para pacotes NFS. Deve-se especificar o
protocolo (TCP, UDP, ICMP ou IP) e logo em seguida a porta, ou intervalos de porta.
36
Snort
2.4.5. utc
Armazena os logs em referência ao UTC, ao invés de no formato de horário local.
3. Pré-processadores
Pré-processadores são módulos que adicionam muita flexibilidade ao Snort. Eles podem ser vistos
como plugins, escritos em C/C++ e que servem para inspecionar os pacotes antes deles chegarem na
engine responsável pela verificação baseada em regras. Esses pré-processadores são de grande utili-
dade para o Snort pois eles permitem verificações mais detalhadas e em mais baixo nível e com menor
gasto de processamento, quando comparados com o uso de regras como as que na seção XX. Algumas
das funcionalidades desempenhadas pelo pré-processadores incluem: combinação de fragmentos TCP
em um único pacote, verificação de uma tentativa de port-scan, entre outros.
A utilização e configuração dos processadores é bem simples, e segue o padrão que já vimos nas seções
anteriores. A sintaxe comum para a configuração de um processador é como segue:
preprocessor <nome_do_preprocessador>: [opções]
Quando o campo opções é omitido o pré-processador vai ser carregador com suas opções padrões. Nós
vamos apresentar a seguir alguns dos pré-processadores que apresentam funcionalidades que podem
ser mais facilmente aproveitadas em qualquer ambiente.
3.1. Stream5
Esse pré-processador da ao Snort a capacidade de ser uma IDS statefull, isto é, agora ele pode saber
de qual sessão um pacote TCP, UDP ou mesmo ICMP faz parte. Isto é muito importante pois, por
padrão, o Snort é stateless, isto é, ele só vê cada pacote independentemente e não consegue analisar
correlações entre pacotes que fazem parte, por exemplo, de uma sessão HTTP.
Diversos tipos de ataque, como aqueles de homem do meio, se baseiam em alterações na cama de
sessão do protocolo para surtirem efeito. Sem esse pré-processador o Snort não tem como detectar
esse tipo de acontecimento. O Stream5 também permite que usemos a palavra flow na nossa definição
de regras, o que nós permite saber se um dado pacote está indo em direção ao cliente ou ao servidor
(detalhes sobre isso podem ser visto mais abaixo).
Uma outra capacidade oferecida pelo Stream5 é a de reunir diversos pacotes de uma mesma sessão
para que nossas regras possam ser verificadas contra toda a sessão. Isto é importante para aplicações
como Telnet, onde um pacote é enviado para cada tecla que pressionamos. Sem esse plugin seria
impossível de verificarmos, por exemplo, se um usuário está tentando abrir o arquivo /etc/passwd, já
que cada pacote ia conter um único caractere. O Stream5 permite que reagrupemos (reassembly, em
inglês) todos os pacotes da sessão para que possamos verificar se a string que desejamos foi enviada
como parte da sessão.
As configurações possíveis para o Stream5 são stream5_global, stream5_tcp, stream5_udp e

stream5_icmp. Abaixo detalharemos algumas opções para as duas primeiras opções.
3.1.1. stream5_global
Define características globais para o funcionamento desse pré-processador. Mais de uma opção podem
ser usadas desde que separadas por virgula.
track_tcp, track_udp, Habilita ou desabilita o suporte ao monitoramento de sessões TCP, UDP e

track_icmp ICMP, respectivamente. O padrão para todos é estarem habilitados. Ex.: pre-
processor stream5_global: track_tcp yes.
max_tcp, max_udp, Define qual o número máximo de sessões TCP, UDP ou ICMP que devem
max_icmp ser monitoradas. Os valores padrões são, 256.000, 128.000 e 64.000, respec-
tivamente. Ex.: preprocessor stream5_global: max_udp 512.000.
37
Snort
memcap Define o tamanho máximo da memória que pode ser alocada para armaze-
namento de pacotes TCP, em bytes. O valor padrão é 8388608 (8MB). Ex.:
preprocessor stream5_global: memcap 134217728.
flush_on_alert Define se a sessão TCP deve ser enviada para os arquivos de logs quando um
alerta for gerado. O padrão é não enviar. Ex.: preprocessor stream5_global:
flush_on_alert yes.
3.1.2. stream5_tcp
Define opções relacionadas a checagem de pacotes TCP. É possível descrever mais de uma política
desse tipo a depender de qual host ou rede queremos monitorar, usando a opção bind_to.
bind_to Determina qual para qual endereço IP (host ou rede), o resto des-
sa política se aplica. O padrão é any (aplicar para qualquer trafé-
go). Ex: preprocessor stream5_tcp: bind_to 192.168.4.56
timeout Determina qual o tempo máximo que uma sessão pode ficar oci-
osa e ainda continuar monitorada pelo Snort. Essa configuração
é extremamente importante pois o valor para a desconexão de
uma sessão varia a depender do sistema operacional,e pode per-
mitir que um atacante evite nosso IDS. É possível, por exemplo,
que configuremos o timeout desse modulo para 30 segundos, e
existe um host na nossa rede que possui um timeout de 1 minu-
to. Com isso, se um atacante ficar sem enviar pacotes por mais
de 30 segundos, o Snort vai parar de monitorar a sessão, mas a
máquina alvo vai aceitar o pacote normalmente. Também não se
pode escolher valores muito altos para essa opção pois isso pode
fazer com que uma sessão use todos os recursos disponíveis pa-
ra a monitoração de sessão, fazendo com que novas sessões não
sejam monitoradas. Ex: preprocessor stream5_tcp: timeout 60
ports Determina em que direção e em qual portas as sessões devem

ser remontadas. Pode-se escolher, por exemplo, que somente as
conexões da porta 80 oriundas dos servidores web e telnet sejam
remontadas. Essa configuração pode aparecer mais uma vez em
cada linha. Ex.: preprocessor stream5_tcp: ports server 80 21.
detect_anomalies Detecta e alerta quando anomalias nos pacotes TCP forem detec-
tadas. O padrão é não verificar tais anomalias. Ex.: preprocessor
stream5_tcp: detect_anomalies on.
check_session_hijacking Verifica tentativas de roubo de sessão, para isso é feita uma ve-
rificação nos MACs de origem e destino em cada pacote, se seus
valores forem diferentes dos usados para iniciar a sessão um aler-
ta é gerado. O padrão é essa verificação estar desabilitada. Ex.:
preprocessor stream5_tcp: check_session_hijacking on.
3.2. sfPortscan
Esse pré-processador permite a detecção de diversos tipos de portscans, especialmente aqueles em-
pregados pelo Nmap. Alguns dos tipos de portscans que podem ser detectados aqui são: portscans
“normais” (um host analisando outro host), portscans camufladas (um host analisando outro host, mas
usando técnicas de spoof para esconder a origem dos scans), portscans distribuidos (vários hosts ana-
lisando um outro host), portsweeps (um host analisando uma única porta em vários hosts). Além disso
ele pode monitorar portscans não só do tipo TCP, mas como também UDP e ICMP.
As opções de configuração desse modulo são as seguintes:
38
Snort
proto Determina quais protocolos devem ser monitorados. As opções são TCP,
UDP, ICMP, ip_proto ou all. Ex: preprocessor sfportscan: proto { tcp icmp }
scan_type Determina que tipos de portscans devem ser monitorados. As opções são:
portscan, portsweep, decoy_portscan, distributed_portscan ou all. Ex.: pre-
processor sfportscan: scantype { portscan decoy_portscan }
sense_level Define qual sensibilidade do módulo para a detecção dos scans. As opções
são: low, medium e high. As configurações mais sensíveis (medium e high)
podem requerer que o sensor seja configurado pelo usuário usando opções
como o ignore, para evitar muitos falsos positivos. Ex.: preprocessor sfports-
can: sense_level { medium }
watch_ip Define quais IPs/redes e portas devem ser monitorados. O formato é o se-
guinte: watch_ip <ip1[:porta[,port1-port2]]>. Ex.: preprocessor sfportscan:
watch-ip { 192.168.4.130:80, 10.100.0.0/16:20-25 }
ignore_scanners Ignora os hosts/redes especificados como de origem de scans. Útil para desa-
bilitar falsos positivos em hosts como proxies ou gateways, que fazem mui-
tas conexões em um curto espaço de tempo. Ex.: preprocessor sfportscan:
ignore_scanners { 192.168.4.255 }
ignore_scanned Ignora os seguintes hosts de alvos de scans. Também pode ser usado pa-
ra se evitar falsos positivos. Ex.: preprocessor sfportscan: ignore_scanned
{ 192.168.4.255 }
logfile Especifica em qual arquivos os alertas gerados por esse modulo devem ser
gravados. Esses alertas são gerados em adição aos alertas gerados normal-
mente, e contém informações mais detalhadas sobre a tentativa de ports-
can. Caso o arquivo não comece com uma barra eles são armazenados re-
lativos ao diretório de logs do Snort. Ex.: preprocessor sfportscan: logfile
{ portscan.log}
Obs.: O sfPortscan necessita que o controle de fluxo esteja habilitado. Esse controle é oferecido pelos
módulos Stream5 ou Flow.
3.3. HTTP Inspect

Esse pré-processador permite ao Snort decodificar URLs para que elas possam ser processadas poste-
riormente por outras regras. Esse pré-processamento é extremamente importante pois diversas tenta-
tivas de ataques podem tentar esconder suas reais intenções usando essas técnicas. O exemplo abaixo
ilustra duas URLs que representam o mesmo recurso (e para o servidor Web, elas são exatamente a
mesma coisa), mas estão escritas de forma totalmente diferente.
http://www.somewhere.tld/cgi-bin/form-mail.pl?execstuff
http://0/%63g%69%2d%62in/%66%6fr%6d%2d%6d%61%69l%2e%70l?
%65%78%65%63%73%74uf%66
Escrever URLs codificadas também serve como meio de ataques a servidores Web, pois muitas vezes
esses servidores não fazem uma verificação eficaz das URLS.
A configuração normal desse módulo consiste em duas partes: uma é a configuração global, e outra
a configuração por servidor, que define como uma URL deve ser verificada, a depender de para qual
servidor ela esteja sendo enviada.
3.3.1. Configuração global

Essa opção normalmente é usada para se especificar o mapa de caracteres usado para decodificar
caracteres unicode para servidores IIS. Essa configuração possui a seguinte sintaxe:
39
Snort
preprocessor http_inspect: global iis_unicode_map unicode.map 860
A primeira opção (global) diz que essa é uma configuração global, a segunda opção (iis_unicode_map)
define qual o map que deve ser usado, em seguida vindo o nome do mapa e o código de página que
deve ser utilizado. Para servidores em português o código de página é 860.
3.3.2. Configuração por servidor

Essa opção serve para definir quais opções devem ser usadas especificamente, por servidor. É possí-
vel inclusive sobrescrever a opção de mapa unicode para um servidor especifico. As configurações
possíveis aqui são extremamente extensas e flexíveis. A sintaxe dessa configuração é a seguinte:
preprocessor http_inspect_server: [server <default|ip>] [profile <iis|apache|all>] [ports <{ por-

tas }>] [demais opções]
A primeira opção (server) serve para definir para qual servidor essa configuração deve ser aplicada.
Caso o valor dela seja configurado para default, ela vai ser usada como a regra padrão, caso não
existe nenhum outro caso mais especifico. A segunda opção (profile) define o perfil padrão que deve
ser usado para as comunicações desse servidor. As opções iis e apache são configuram várias outras
opções para que elas funcionem da melhor forma possível com essas dois servidores, enquanto a opção
all serve para detectar todos os tipos de ataque, independente de qual servidor está rodando na máquina
alvo. A terceira opção (ports) define quais portas devem ter sua comunicação decodificada, valores
lógicos aqui incluem as portas 80, 8081 e 8080 (normalmente associadas com servidores Web). A
porta 443 não deve ser usada, já que todo o trafego que passa por ela vai estar criptografado.
Essa configuração básica deve ser suficiente para a maioria dos casos. Caso se deseje verificar opções
mais avançadas para detectar ataques mais sutis é recomendável a leitura do manual do Snort.
3.4. Outros pré-processadores

Além do decodificador de HTTP o Snort possui alguns outros pré-processadores que servem para
monitorar comportamento suspeito no trafégo de diversos serviços da camada sete, como por exemplo
SSH, Telnet, SMTP e RPC.
É recomendável a leitura do manual do Snort para que se possa verificar com detalhes o funcionamento
de cada um deles.
4. Regras
Chegamos agora na parte mais interessante do Snort. As regras são, por assim dizer, o coração do
Snort. São elas que dão tanta flexibilidade e poder a esse IDS.
A grande diferença do Snort quando comparado com outros IDS do mercado é que é possível para
um administrador alterar as regras usadas para a detecção de um ataque, ou, até mesmo, criar novas
regras a partir do zero. Veja abaixo um exemplo de uma regra do Snort que serve para detectar uma
tentativa de proliferação do Worm Codered em servidores IIS.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

(msg:”WEB-IIS CodeRed v2 root.exe access”;
flow:to_server,established;
uricontent:”/root.exe”; nocase; classtype:web application-attack;
reference:url, www.cert.org/advisories/CA-2001 19.html;
sid:1256; rev:7;)
Enquanto a principio essa regra pode parecer extremamente complexa e desprovida de sentido, depois
de terminarmos essa sessão será possível ver com claridade o real significado de cada campo existente
aqui, e até mesmo fazer melhorias nela.
As regras do Snort são dividas em duas partes: o cabeçalho e o corpo. A seguir nos estudaremos cada
uma dessas parte em separado.
40
Snort
4.1. Cabeçalho
O cabeçalho de uma regra do Snort serve como um filtro para evitar que um processamento mais
pesado seja gasto em pacotes onde ele não é necessário. No exemplo que foi dado acima o cabeçalho
é a parte até o parênteses, ou seja:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
Todas as regras vão possuir sempre os mesmos elementos. Vamos abaixo detalhar cada uma das partes
que compõe o cabeçalho de uma regra.
4.1.1. Ação
log Faz com que os pacotes que casaram com essa regra sejam gravados. O local de sua
gravação depende das configurações dos plugins se saída.
alert Gera um alerta na saída configurada e loga os pacotes que fazem parte do “ataque”
detectado.
pass Essa ação não faz nada. Ela serve para desabilitar a saída de regras que estão gerando
muito ruído.
activate, dyna- Usado em conjunção com outras regras que possuem a ação definda como dynamic.
mic Essas duas regras em conjunto servem para detectar ataques que são compostos por
uma seqüência de pacotes, e que não poderiam ser detectados analisando um pacote
independentemente.
4.1.2. Protocolo
Essa é a segunda opção que devemos usar e deve ser desde já bem clara: ela vai especificar quais
protocolos devem ser processados por essa regra. As opções são: IP, ICMP, TCP e UDP.
4.1.3. Rede de origem/destino

Define entre quais redes/hosts a comunicação deve estar sendo feita para que essa regra seja disparada.
No exemplo acima, a rede de origem e a de destino estão sendo representadas por duas variáveis,
respectivamente $EXTERNAL_NET e $HTTP_SERVERS.
4.1.4. Porta de origem/destino

Representam quais portas TCP/UDP estão envolvidas na comunicação. No exemplo acima as portas
são, respectivamente, any (qualquer porta) e a variável $HTTP_PORTS.
4.1.5. Direção do trafego

Essa opção fica entre as duas tuplas rede/porta e vai definir em qual sentido a comunicação está ocor-
rendo (isto é, quem é o cliente e quem é o servidor). Existem duas opções possíveis:
-> Nesse caso a comunicação foi iniciada pelo elemento da esquerda (ele é o cliente), e o elemento
da direita deve ser considerado como o servidor.
<> Nesse caso não importa quem iniciou a comunicação. Todo trafego passando entre os dois ele-
mentos deverá ser vistoriado.
4.2. Corpo
É no corpo das regras que reside a parte mais “interessante” do Snort. A definição do cabeçalho serve
para evitar que todos os pacotes passem pela estrito controle que pode ser feito aqui. As regras de
41
Snort
corpo são extremamente poderosas, flexíveis e, acima de tudo, pesadas. Nesse campo nos podemos
especificar desde da mensagem que será mostrada junto com os alertas, até poder analisar se o pacote
em questão possui o valor 0xC3 valor no seu décimo byte.
As opções do corpo de uma regra são sempre separadas por ponto e vírgula e possuem a forma
item:”valor”. Nas próximas seções nós vamos olhar brevemente alguns dos principais campos dispo-
níveis.
4.2.1. Identificação
Essas opções não influenciam na detecção propriamente dita, mas servem para forneces informações
importantes sobre do que se trata cada alerta.
msg Define a mensagem que deve ser usada para o alerta disparado por essa regra. Ex:
alert:”Alguém está tentando te hackear”.
reference Para o caso de o ataque ser conhecido pode-se adicionar uma referência ao mesmo,
onde podem ser encontradas mais informações sobre o ataque. Existem diversas re-
ferências prontas para fontes conhecidas como a Bugtraq, o CVE e a McAfee. Ex:
reference:bugtraq,1387; reference:cve,CAN-2000-1574;
sid, rev Servem para identificar uma regra dentro do Snort. O sid identifica unicamente uma
regra (regras feitas “em casa” devem ter sid acima de um milhão), enquanto o rev
identifica qual revisão de uma dada regra está em uso. Ex: sid:1000001; rev:2;
classtype Usado para associar uma categoria a uma regra. Útil para quando queremos, por exem-
plo, definir que várias regras fazem parte de um grupo maior, como ataque web. Uma
categoria, antes de ser usada, tem de ser definida usando a opção config classification,
discutido anteriormente. Ex.: classtype:attempted-admin; classtype:network-scan;
priority Associa uma prioridade a uma regra. Útil para saber o quão devastador pode ter sido
um ataque que sofremos recentemente. As prioridade mais importantes tem valor um.
Ex.: priority: 1; priority: 20;
4.2.2. Cabeçalhos dos pacotes

Opções usadas para fazer diversas verificações nos cabeçalhos dos pacotes. Útil para detectar, entre
outras coisas, comportamentos “não convencionais” dos protocolos (como um pacote IP com todos
os flags ativados).
ipopts Serve para verificar se algumas opções do IP estão presentes, como por exemplo: IP
Security (sec), Loose Source Routing (lsrr), Strict Source Routing (ssrr). Apenas uma
opção pode ser verifica de cada vez. Ex: ipopts: lsrr; iptops: ssrr;
flags Verifica a presença ou não de diversas flags relacionadas ao TC. As opções possíveis
são: S (SYN), F (FIN), R (RST), P (PSH), A (ACK), U (URG), 1 (Primeiro bit reser-
vado), 2 (Segundo bit reservado) e 0 (Nenhuma flag definida). Além disso é possível
usar alguns modificadores para verificar: 1)se as flags especificadas, ou outras, estão
ativadas (+); 2) se qualquer uma das flags especificadas está ativa (*); 3) verificar se
nenhuma das flags especificadas estão ativas (!). Ex: flags: *SF; flags: !A
itype, icode Usados para verificar o tipo e o código de um pacote ICMP. Ex: itype: 0; icode: 0
ip_proto Usado para checar o campo do cabeçalho IP responsável por identificar qual o protocolo
contido no payload. Pode-se ser usado qualquer um dos protocolos definidos em /etc/
protocols (c:\windows\system32\drivers\etc\protocol). Ec.: ip_proto: igmp; ip_proto:
ipv6;
sameip Verifica se a origem a o destino de um pacote IP são os mesmos.
42
Snort
4.2.3. Teste de payload

Esses testes servem para verificar o payload (isto é, conteúdo) de um dado pacote. A principal cláusula
apresentada aqui é a content. Todas as outras são na verdade modificadores para o content.
content Verifica se uma data string (em ASCII ou Hexa), existe dentro do payload de um pacote
(ou seja, na camada sete). Caso desejemos fazer uma busca por um valor em hexa, ele
deve estar entre pipes (|). Ex: content: “hacker” ; content: “|00 D0 B0|”;.
nocase Especifica que a busca deve desconsiderar se a palavra está escrita em maiúsculas ou
minúsculas. Ex.: content: “hAcKeR”; nocase;.
rawbytes Especifica que a busca deve ser realizada no conteúdo original do pacote, e não no
resultado dado pelos pré-processadores.
depth Especifica até onde a busca pelo padrão deve ir. Um exemplo é visto no próximo tópico.
offset Especifica a partir de onde a busca pelo padrão deve ser iniciada. Ex.: content: "cgi-
bin/phf"; offset:4; depth:20;
distance Especifica a partir de onde, em relação ao padrão descrito anteriormente, a busca deve
ser iniciada. Um exemplo é visto no próximo tópico.
within Especifica até onde, em relação ao padrão descrito anteriormente, a busca deve ser feita.
content:"ABC"; content: "EFG"; distance: 1; within:10;
4.2.4. HTTP
Enquanto essas regras também tratam do payload de um pacote elas tem a característica especial no
sentido que elas servem especificamente para pacotes HTTP normalizados, isto é, depois que eles
passaram por um pré-processador. Todas as cláusulas apresentadas a seguir são modificadores da
cláusula content, e devem, portanto ser usadas logo após ela.
http_client_body Verifica o conteúdo do corpo de uma mensagem HTTP (um página Web
por exemplo). Ex: content: “sexo”; http_client_body;
http_uri Usado para verificar a URI (a popular URL...), usada numa requisição web.
Ex: content:”google.com”; http_uri;
uricontent Forma reduzida de se pesquisar numa URI, substituindo o content e o

http_uri. Ex: uricontent:”google.com”
urilen Verifica o tamanho da URI contida no pacote. Ela pode verificar o tamanho
exato da URI (urilen: 10), seu tamanho mínimo (urilen: <5), o tamanho
máximo (urilen > 10), ou se seu tamanho está dentro de um intervalo (urilen:
5<>10).
4.2.5. Outros
Opções interessantes que não se encaixam em nenhuma outra categoria.
flow Usado para acompanhar a direção e o estado de uma conexão. As opções para
verificar a direção incluem as opções to_server e to_client. Além disso é também
possível verificar se a conexão já está estabelecida usando a opção established.
Ex: flow:to_server,established;
session Usado para logar todo o conteúdo de um dada seção TCP. Útil para gravar con-
versas telnet, por exemplo. Pode-se especificar se desejasse gravar toda a sessão
ou somente os caracteres imprimiveis, usando as opções all e printable, respec-
tivamente. session: printable;
activates Usado junto com a ação activate de uma regra (visto anteriormente). Serve para
identificar quais outras regras devem ser acionadas. Ex: activate: 1
43
Snort
activiated_by Usando junto com a ação dynamic de uma regra (visto anteriormente). Serve
para identificar quando essa regra vai ser acionada.
count Deve ser usado junto com a cláusula activated_by. Serve para determinar quan-
tos pacotes essa regra deve capturar antes de voltar a ficar desativada. Ex:
activated_by: 1; cout: 50;
4.3. Exemplos de regras
44
Capítulo 9. Firewall
1. Introdução
2. Netfilter/Iptables
2.1. Introdução
netfilter é um framework para gerenciamento de pacotes no Linux disponível desde a versão 2.4 do
Kernel. O netfilter na verdade é um conjunto de bibliotecas e comandos que fazem comunicação com
o Kernel para aceitar/rejeitar ou modificar pacotes que estejam destinados a nossa máquina.
O iptables é um programa que usamos para nos comunicarmos com os módulos do netfilter e pas-
sarmos as instruções que queremos que ele execute. Enquanto os modulos mais usados do netfilter
são aqueles relacionados com filtro de pacotes (na camada 3) e NAT (Network Address Translation),
existem diversas outras funcionalidades que o netfilter oferece, como por exemplo a possibilidade de
manipular pacotes na camada 7, alterando seu conteúdo.
O iptables, como o próprio nome indica, trabalha com um conceito de tabelas. Essas tabelas são equi-
valentes as partes que um pacote está passando enquanto ele atravesa as diversas partes da pilha IP do
Linux. Abaixo estão descritas as três tabelas existentes nas atuais implementações do netfilter.
filter Essa é talvez a tabela mais usada pelos usuário do iptables. É nela que são definidas regras
para a filtragem de pacotes (para muitos a razão de ser de um firewall). Essa tabela, por
padrão, suporta filtragens baseadas nos cabeçalhos dos pacotes das camadas 3 e 4.
nat Permite a realização de tradução de endereços. A técnica de NAT foi desenvolvida, a prin-
cípio, para permitir que um maior número de máquinas pudessem ter acesso à Internet
através de um único endereço IP. O netfilter suporta os mais diversos tipos de NAT, como
SNAT e DNAT.
mangle Essa tabela permite a manipulação dos pacotes das mais diversas maneiras. Permitindo a
alteração de informações contidas no mesmo, como, por exemplo, mudar o valor TTL, do
TOS, etc.
Dentro de cada uma dessas tabelas existem diversas chains. Cada chain é uma sequência de regras
verificada na ordem em que aparecem que vão determinar qual ação deve ser tomada para um dado
pacote. Cada tabela possui algumas chains pré-definidas, que são as responsáveis pelo recebimento
de regras pela tabela. Além das chains padrões é possível ao usuário criar quantas chains ele desejar,
o que é útil, por exemplo, para agrupar verificações relacionadas.
Como foi dito anteriormente cada tabela possui uma series de chains pré-definidas, que são responsá-
veis pela captura do pacote em enquanto ele atravesa a pilha IP do Linux. No Linux existem cinco
pontos onde o netfilter pode capturar um pacote, inspecioná-lo e fazer alguma modificação. Essas
cinco localizaçãoes são mostradas na Figura 9.1. É importante conhecer essas localizações pois elas
ajudam a determinar onde uma regra deve ser posta para que ela tenha o resultado que esperamos.
output É aqui que os pacotes que estão saindo de nossa máquina são analisados. Por aqui
passam única e exclusivamente pacotes que foram gerados localmente. Tais paco-
tes podem estar indo com destino a outras máquinas ou então vão acessar um ser-
viço na própria máquina. Essa não é o local para regras pertinentes a um firewall
de rede.
input Pacotes com destino a nossa máquina são inspecionados através desse chain. Aqui
passam exclusivamente pacotes destinados a nossa máquina, sejam eles originados
45
Firewall
de outras máquinas da rede ou dela própria. Novamente aqui não é o local de regras
relacionadas a um firewall de rede.
prerouting Por essa chain passam todos os pacotes que chegam na nossa máquina (com desti-
no a ela ou não). As verificações nessa chain acontecem antes que o kernel tome
qualquer decisão de roteamento em relação a esse pacote. Nesse momento ainda
não se sabe se o pacote está destino a outra máquina (quando o nosso firewall está
agindo como um roteador), ou para nós mesmos.
forward Por essa chain passam pacotes que foram identificados como não sendo destina-
dos a nossa máquina, mas que vieram de outras redes. Esse é, provavelmente, o
lugar mais indicado para serem feitas filtragens em firewalls funcionando como
roteadores.
postrouting Essa chain é parecida com os a forward, a diferença é que aqui passam não somente
os pacotes vindos de outras redes, mas também aqueles que saem de nossa máquina
e estão partindo com destino a outras máquinas.
Figura 9.1. Fluxo de um pacote nas chains do netfilter
Algumas dessas chains se repetem em mais de uma tabela (output, por exemplo, está presente em
todas as três tabelas). Quando uma situação dessa ocorrer devemos saber que existe uma ordem de
preferência entre as tabelas. A tabela que tem mais prioridade é a mangle, seguida da nat e por só por
último as regras da tabela filter são analisadas.
A seguir vamos verificar algumas das funcionalidades oferecidas pelo netfilter/iptables para nós, bem
como avaliar algumas especificidades relacionadas a cada tabela.
2.2. Funcionalidade básica do iptables

2.2.1. Operações com chains
-L, --list [chain] Lista todas as regras pertencentes a uma dada chain. Caso ne-
nhuma chain seja especificada, lista todas as as regras da tabela.
-P, --policy <chain> <politica> Muda a política padrão associada a uma chain. A politica pa-
drão pode ser qualquer uma daquelas que serão detalhadas na
Seção 2.3.2.
46
Firewall
-N, --new-chain <chain> Cria uma nova chain com o nome especificado.
-F, --flush [chain] Apaga todas as regras de uma dada chain. Caso nenhuma chain
seja especificada todas as regras da tabela são apagadas.
-X, --delete-chain [chain] Remove uma chain definida pelo usuário da tabela. É importan-
te notar que para a chain ser apagada duas condições devem ser
satisfeitas: 1) não pode haver nenhuma chain que possua como
alvo a chain que queremos apagar; 2) A chain que queremos
apagar deve estar vazia (sem regras). Se nenhum argumento for
especificado o iptables vai tentar apagar todas as chains espe-
cificadas pelo usuário.
-Z, --zero [chain] Zera os contadores de pacotes e de volumes na chain especifi-

cada. Caso nenhuma chain seja especificada os contadores de
toda a tabela serão zerados. Caso a opção -L seja passado jun-
tamente com essa opção os contadores serão exibidos antes de
serem zerados.
2.2.2. Operações com regras

-A, --append <chain> <regras> Adiciona uma nova regra na última posção da chain especifica-
da. Uma regra tem um formato básico, consistindo de uma série
de “matches”, e de um alvo. Os matches são opções que devem
estar presentes no pacote para que ele possa “casar” com uma
regra (coisas tipo, o endereço IP de origem, e a porta de desti-
no, por exemplo). Já o alvo determina qual ação vai ser tomada
para com aquele pacote, caso ele case com a regra definida.
-D, --delete <chain> <regra | nume- Reomve uma regra de uma dada chain. Existem dois meios de
ro> se especificar qual regra vai ser removida. O primeiro é redi-
gitando novamente toda a regra que desejamos excluir. O se-
gundo é usando um número, que indica qual a posição da regra
dentro da chain.
-I, --insert <chain> [numero] <re- Enquanto a opção -A nos permite inserir uma regra no fina lde
gra > uma chain, a opção -I nos permite inserir novas regras em qual-
quer posição dentro da chain. Caso nenhum valor seja apssado
para ela, por padrão a nova regra é inserida na primeira posição.
-R, --replace <chain> numero <re- Substitui a regra existente na posção especificada pela nova re-
gra> gra especificada.
2.2.3. Parâmetros
Nessa seção vão ser detalhados os parâmetros básicos suportados pelo netfilter/iptables. Esses parâ-
metros devem ser usados durante a especificação de uma regra (para inclusão, deleção, substituição
ou inserção). Além desses parâmetros o iptables também suporta uma série de extensões chamadas de
matches, que permitem a especificação de regras mais ricas, verificando as mais diversas propriedades
de um pacote.
-p, --protocol Especifica qual protocolo deve estar presente no pacote IP. As opções vá-
lidas são tcp, udp, icmp e all.
-s, --source, -d, --desti- Permite especificar qual deve ser o endereços de origem (-s), ou de destino
nation (-d) de pacote IP, para que ele case com essa regra.
-j, --jump Especifica qual ação deve ser tomada caso um pacote case com essa regra.
Ações válidas incluem deixar o pacote passar (ACCEPT), não aceitar o pa-
cote e enviar uma mensagem informando do ocorrido (REJECT), ou sim-
plesmente rejeitar o pacote sem dar nenhum aviso (DROP).
47
Firewall
Existem ainda diversos outros alvos disponíveis no netfilter, alguns desses

serão estudados na Seção 2.3.2. Adicionamento uma chain também pode
ser usada com alvo de uma regra. Isso quer dizer que, a partir daquele ponto,
o pacote deve ser verificado contra a chain alvo. Caso nenhum rega definida
nela case com o pacote as regras seguintes vão continuar sendo verificadas.
Caso nenhuma ação seja espeficida nenhuma ação vai ser feita com aquele
pacote, mas, ainda assim, os contadores associados àquele regra vão ser
incrementados, indicando que occoreu um “match”.
-i, --in-interface, -o, -- Permite definir através de qual interface de rede o pacote deve estar che-
out-interface gando (-i) ou saindo (-o), para que a regra case com sucesso. A opção -
i é valida somente nas chains de INPUT, FORWARD e PREROUTING,
equanto que a opção -o é valida somente nas opções de FORWARD, OUT-
PUT e POSTROUTING.
2.2.4. Outras opções

-v, --verbose Habilita a saída “incrementada”, que exibe informações adicionais sobre as
regras, como por exemplo, opções de conifugração de interface de entrada e
saída. Além disso são exibidos também contadores, que mostram quantos pa-
cotes já casaram com uma dada regra e qual o volume de informação repre-
sentada por aqueles pacotes.
-n, --numeric Habilita a saída númerica. Por padrão o iptables tenta resolver os ips para no-
mes de hosts, e exibe o nome do serviço ao invés do número da porta (www
no lugar de 80, por exemplo). A opção -n desabilita essas conversões.
--line-numbers Exibe uma coluna que mostra o número de cada regra dentro de uma chain.
Útil quando estamos com preguiça de contar quantas regras temos ;).
2.3. Alvos e Matches

2.3.1. Matches
Os matches no iptables são módulos que extendem as funcionalidades básicas disponíveis descritas
na Seção 2.2.3. Esses módulos permitem fazer filtragens mais especificas, verificando não só várias
propriedades adicionais de um pacote, mas como também, permitindo verificar informações que cor-
relacionam vários pacotes.
Os matches na verdade são modulos do kernel, que extendem as funcionalidades básicas do netfilter.
Esses modulos podem ser carregados de duas maneiras: através de opção -p (que carrega os modulos
relacionados a filtragem TCP, UDP e ICMP), ou usando-se a opção -m. Depois que o módulo está
carregado várias outras opções passam a estar disponíveis para escrevermos nossas regras.
Nas próximas seções nós vamos apresentar alguns modulos disponíveis para na distribuição do ipta-
bles, bem como as opções que podemos usar com eles. Novamente essa não planeja ser uma lista
extensiva. Caso deseje-se conhecer todos os modulos disponíveis recomenda-se a leitura das páginas
de manual do iptables, bem como uma visita ao site do netfilter (www.netfilter.org).
Uma observação importante é que muitas regras suportam a utilização do operador “!”. Esse é o ope-
rador de negação, e serve para inverter o sentido das opções passadas depois dela. Por exemplo: caso
essa opção seja passada imediatamente antes da especificação de um porta, a regra vai passar a aceitar
pacotes que não estejam direcionados para a porta especificada.
2.3.1.1. connbytes
Esse módulo serve para acompanharmos qual o volume de dados trafégado em uma dada conexão.
Esse volume pode ser visto tanto quanto a quantidade absoluta de bytes tranferidos, a quantidade de
48
Firewall
pacotes ou mesmo o tamanho médio de cada pacote. Essas informações podem ser úteis para detectar
ataques de negação de serviço, onde grandes volumes de informação estão sendo transmitidos tentando
sobreccaregar a banda.
Opções do match connbytes

[!] --connbytes de[:ate] Permite especificar conexões por onde já foi trafegado um vo-
lume maior que “de” e, opcionalmente, menor que “para”.
--connbytes-dir <original|reply| Permite especificar em qual direção de trafégo o volume tem

both> de ser avaliado.
--connbytes-mode <packets|by- Define o que queremos monitorar. As opções listadas permi-

tes|avgpkt> tem especifionar, respectivamente: número de pacotes transmi-
tidos, volume em bytes transmetidos, tamanho médio dos pa-
cotes.
2.3.1.2. connlimit
Essa extensão permite restringir o número de conexões TCP abertas por IP ou por uma faixa de IPs.
Ela serve, por exemplo, para evitar tentativas de DoS sobrecarregando um servidor.
Opções do match connlimit

[!] --connlimit-above <n> Determina quando o número de conexões existentes passou de
n.
--connlimit-mask <mascara> Define qual mascara deve ser aplicada para verificar quantos
hosts de uma mesma rede estão con conexões silmutâneas ao
nosso servidor.
2.3.1.3. icmp
Oferece exensões para verificações de algumas propriedades do protocolo ICMP. Essa extensão é au-
tomáticamente carregada quando usamos a opção -p icmp. Com essa extensão é possível verificcar
o tipo de um pacote ICMP.
Opções do match ICMP

--icmp-type [!] tipo Permite verificar o tipo de um pacote ICMP. A opção tipo pode ser
um número, ou uma expressão que designa o tipo em questão. Para
uma lista de todos os tipos suportados pelo netfilter use o comando
iptables -p icmp -h.
2.3.1.4. limit
Essa é uma das extensões mais usadas e que oferecem uma grande capacidade para o netfilter de evitar
ataques de DoS ou qualquer tentativa de portscan. Usando-se o limit é possível sabermos quando o
número de pacotes por unidade de tempo que estamos recebendo está acima de um limite pr-édefinido.
Podemos saber, por exemplo, quando o número de pedidos de conexão ao nosso servidor web passou
de 50 conexões por segundo (o que pode caracterizar um tentativa de negação de serviço).
Opções do match limit

--limit <frequencia> Especifica qual o limite que queremos monitorar. Valores acima do
especificado vão disparar essa regra. Essa opção é um número se-
guida por um sufixo que vai especificar a unidade de tempo. Esse
sufico pode ser : /second,/minute,/hour,/day. O valor padrão é 3 pa-
cote por horas (3/hour).
49
Firewall
--limit-burst <valor> Define o número pacotes que devem estar dentro da frequência de-
finida para que a regra seja disparada. Por exemplo, se colocarmos
o valor 10 aqui estamos dizendo que mais 10 pacotes devem passar
com essa frequência antes do limite começar a fazer efeito. O valor
padrão é 5.
2.3.1.5. mac
Serve para filtrar pacotes com base no endereço MAC de origem. Essa regra é valida somente nas
chains de PREROUTING, FORWARD e INPUT, ligadas a uma interface ethernet.
Opções do match MAC

--mac-source [!] endereço Estabelece que o pacote em questão deve estar vindo desse en-
dereço MAC. O formato do endereço deve ser algo do tipo
XX:XX:XX:XX:XX:XX.
2.3.1.6. pkt-type
Permite filtrar trafégo com base na camada de dados. Esse tipo de filtro é extremamente útil pois
alguns sistemas operacionais aceitam abrir conexões TCp/UDP em pacotes enviados via broadcasts
(um comportamento que obviamente não faz sentido). Podemo então usar essa condição para evaliar
se uma conexão TCP a porta 80 do nosso servidor não esta vindo através de um broadasct.
--pkt-type <unicast|broadcast|multi- Permite especificar que tipo de pacote queremos filtrar.

cast>
2.3.1.7. recent
Esse é um filtro especialmente útil e complexo. Ele permite a criação de uma lista de IPs baseados em
uma condição, essa lista pode então ser usar para filtragem. É possível por exemplo criar uma lista das
pessoas que estão tentando acessar a porta 139 de seu firewall, e então usar essa lista para criar uma
outra regra que vai barrar todas as conexões dessas pessoas por 60 segundos.
Opções do modulo recent

--name Especifica qual lista deve ser usada para a execução das demais ações
desse módulo. Caso nenhum nome seja especificada o valor “DE-
FAULT” é usado.
[!] --set Essa opção vai adicionar o IP de origem do pacote sendo avaliado a
lista passada. Caso esse IP já exista na lista sua entrada vai ser atuali-
zada. Caso a opção “!” seja passada essa ação vai gerar uma falha na
verificação da regra.
[!] --rchek Serve para chegar se o endereço de origem já está na lista especificada.
[!] --update
[!] --remove
[!] --seconds
[!] --hitcount hits
--rttl
--rsource
--rdest
50
Firewall
2.3.1.8. state
O state é outro match extremamente poderoso, e que faz muito uso da capacidade statefull do netfilter.
Essa extensão nos permite verificar o estado de um dado pacote em relação a outras conexões que estão
sendo monitoradas pelo nosso firewall, permitindo sabermos se um dado pacote re#esenta uma nova
conexão, se ele já faz parte de uma conexão existente ou até mesmo sabermos se ele esta relacionado
a uma conexão já existente.
Essa extensão suporta somente uma opção --state, que vai defini, em lista separada por virgular,
em quais estados nós queremos que um pacote esteja quando tomarmos nossa decisão. É preciso ter
cuidado com uma coisa: os estados representados pelo netfilter (e usados nessa regra), não são mape-
ados diretamente para os estados de um conexão TCP para o kernel do Linux.(isso é especialmente
verdade para o estado NEW, em relação a pacotes ACK e SYN/FIN).
Vejamos na tabela a seguir a descrição de cada um dos possíveis estados que podem ser especificados.
NEW Nessa categoria estão associados os pacotes que vão iniciar ou recriar uma conexão.
Pacotes que vão iniciar uma conexão são, básicamente, os pacotes SYN. Ou seja,
essa regra fuciona mais ou menos como a opção --syn para o match tcp, mas
ela faz uma verificação mais elaborada, baseada no estado das diversas conexões
monitoradas pelo firewall.
A parte que fala sobre recriar uma conexão, é de extrema importância, e por vezes
passa desapercebida para a maioria dos usuários. Para o netfilter um pacote somente
com a flag ACK habilitada também é considerado como uma nova conexão. Isso
acontece para que, caso o firewall sofra alguma interrupção em seu funcionamento,
as conexões que estivessem passando por ele não precisem ser re-estabelecidas (ou
seja, não é necessário que o three way handshake ocorra.
Por exemplo, numa situação onde o firewall tem de ser reinicaido e haviam dois
hosts que já estavam com uma conexão estabelecida, os hosts não precisam saber
que o firewall parou de funcionar por alguns minutos. Para eles, desde que o periodo
de timeout da conexão não tenha terminado, o recebimento de um ack do outro lado
é o suficiente para que eles possam retomar a conexão do lugar onde eles haviam
para anteriormente.
O ponto negativo dessa abordagem é que ela permite que o firewall possua uma
abertura para ACK scans. É possível evitar esse tipo de scans usando a opção de
tcpflags, para verificar se um pacote possui comente o bit ACK habilitado. Por
outro lado, fazendo isso nós perderemos aoportunidade de reestabelecimento de
conexões qunado o firewall apresentar algum problema. Devemos fazer então a
escolha que achamos que vai gerar o menor impacto em nosso ambiente.
Um outro fato importante que deve ser notado aqui diz respeito a pacotes com os
bits SYN e FIN habilitados. Essa combinação de flags é incoerente e não tem neh-
num sentido dentro do protocolo. No entanto, a maioria dos sistemas operacionais
(inclusive o Linux), verificam somente a presença da flag SYN 1em um pacote pra
considerar que ele serve para iniciar uma conexão. Com isso pacotes SYN/FIN po-
dem ser usadas para iniciar normalmente uma conexão TCP em ambientes Linux.
O problema aqui reside no fato que, para o netfilter, um pacote SYN/FIN não é
um pacote relacionado a uma nova conexão, mas sim um pacote inválido. Ou seja,
se em uma dada chain do netfilter nós tivermos um regra que vai rejeitar pacotes
relacionados a novas conexões pacotes SYN/FIN não vão ser pegos por ela. Ao
invés disso elas vão ser verificadas pelas regras seguintes, podendo então o pacote
ser aceito pelo firewall. Com isso uma nova conexão vai ser aberta, mesmo quando
nós pensavamos que isso não poderia ocorrer.
Esse é o design padrão do netfilter já a muito tempo. Os desenvolvedores estão

completamente cioentes dessa “peculiaridade”, e eles não tem intenção de mudar
51
Firewall
esse modo de funcionamento., devendo os usuários do netfilter/iptables estarem

cientes disso e escreverem suas regras de forma a não cairem em problemas como
esses. Uma solução para a questão do SYN/FIN é adicionar uma regra que rejeita
pacotes invalidos logo no começo da chain. Além disso o uso de uma política de
negue tudo e só depois libere pode ajudar a diminuir a probabilidade de seu firewall
cair numa situação dessas.
ESTA- Esse estado é alcançado quando a conexão é aceita pelos dois hosts, isso ocorre na
BLISHED troca de pacotes SYN/SYN-ACK ou então quando são vistos dois pacotes ACK/
ACK passando nas duas direções. A primeira situação é o estabelecimento normal
de uma conexão TCP, já o segundo ocorre quando o firewall teve de ser reiniciado
e dois hosts já estavam no meio de um sessão. Esse comportamente foi discutido
em detalhes na sessão anterior.
Pacotes que estão nesse estado geralmente podem ser considerados seguros, já que
para chegarem aqui, eles tiverem de ser aprovados por outras regras.
RELATED Esse estado trata de conexões que estão sendo criadas agora, mas que tem alguma
relação com uma conexão já existente. Um exemplo desse tipo de conexão é a
conexão de dados do FTP, que é criada somente após a conexão de comandos.
Por sua natureza unica esse tipo de estado precisa de uma certa ajuda. Para cada
protocolo que pode gerar uma conexão relacionada deve existir um ajudante (hel-
per), que vai identificar conexões relacionadas a ele. Existem ajudantes para cone-
xões de FTP, IRC, Quake3, SNMP, entre outros.
INVALID Pacotes invalidos são aqueles que não puderam ser identificados (como por exem-
plo, por falta de memória no firewall), respostas ICMP não relacionadas a nenhuma
conexão existente ou ainda pacotes que possuem opções de cabeçalho incorretas
(como por exemplo com os bits SYN e FIN setados ao mesmo tempo).
Esse estado é muito importante pois é nele que se encaixam a maioria das tentativas
de portscan ou de exploração de falhas de implementação de algum protocolo de
rede. Recomendo fortemente que uma primeira regra em qualquer firewall seja
descartar pacotes invalidos.
2.3.1.9. tcp
Oferece diversas extensões que podem ser usadas para verificação de informações disponíveis no
cabeçalho TCP de um pacote. Ela é carregada automáticamente quando a opção "-p tcp" é usada.
Opções do match TCP

--sport [!]porta[:porta], --sour- Serve para verificar a porta de origem/destino de um dado pa-
ce-port [!]porta[:porta], --dport cote. Pode-se também selecionar um intervalo de portas, usan-
[!]porta[:porta], --destination-port do a sintaxe de_porta:ate_porta.
[!]porta[:porta]
2.3.1.10. ttl
Verifica o valor do campo TTL de um pacote IP. Útil para verificar, por exemplo, TTLs excepcional-
mente baxos destinados a sua rede, que podem estar sendo usados como uma tentativa de mapeamento
de rede.
Opções do Match TTL

--ttl-eq <ttl> Verifica se o campo TTL possui exatamente o valor especificado.
52
Firewall
--ttl-gt <ttl> Verifica se o valor do campo TTL é maior que o valor especificado.
--ttl-lt <ttl> Verifica se o valor do campo TTL é menor que o valor especificado.
2.3.1.11. udp
Oferece exensões para verificações de algumas propriedades do protocolo UDP. Essa extensão é au-
tomáticamente carregada quando usamos a opção -p tcp. Dada a simplicidade do protocolo a única
opção que podemos verificar é a porta de origem e destino.
Opções do match UDP

--source-port, --destination port- Serve para especificar a porta de origem/destino de um pacote
port [!] porta[:porta] UDP. É possível especificar um intervalo de portas separando
a porta inicial e a final com dois pontos. O uso da exclamação
antes da especificação da porta serve para verificar se o pacote
não está destinado à porta especificada.
2.3.2. Alvos
2.4. Trabalhando com a tabela NAT
2.5. Trabalhando com tabela Mangle

A tablea de mangle permite mudar os valores de TOS ou TTL de um pacote IP. Nenhuma outra mu-
dança pode ser feita nos pacotes nessa tabela. Alterações referentes ao endereço/porta de origem/des-
tino devem ser feitas na tabela de NAT. Para alcançar essa objetivo alguns alvos foram feitos especi-
almente para essa tabela, a maioria deles relacionados à ToS.
No nosso atual contexto a maior importância que a capacidade de alterar valores de ToS e TTL é
poder esconder de possíveis atacantes características dos nossos servidores internos. Como foi visto no
Capítulo 1, Seção 2, um atacante pode usar informações de TOS e TTL para determinar qual sistema
operacional está rodando na máquina alvo. O que nós podemos fazer aqui é mudar informações sobre
TTL e TOS de todos os pacotes saindo de nossa rede, de tal forma que eles não permitam a um atacante
identificar nosso sistema operacional.
É possível alterar o campo TOS usando um dos seguintes alvos: ECN, DSCP ou TOS. Essas opções
são necessárias graças as diversas interpretações que já foram dadas a esse campo. Cada alvo desse
suporta uma série de opções. É recomendado a leitura do manual do iptables para conhecer todas
as opções. Por exemplo, caso quisessemos zerar todos os bits do campo TOS (padrão em sistemas
operacionais Windows), poderiamos usar o seguinte comando:
iptables -t mangle -A POSTROUTING -j TOS --set-tos 0

iptables -t mangle -A POSTROUTING -j DSCP --set-dscp 0
Já o campo TTL pode ser alterado usando o alvo de mesmo nome: TTL. Esse alvo aceita as seguintes
opções:
• --ttl-set <valor>: Coloca o valor especificado no campo TTL.
• --ttl-dec <valor>: Diminui o valor do TTL do pacote em “valor” vezes.
• --ttl-inc <valor>: Aumenta o valor do TTL do pacote em “valor” vezes.
Por exemplo, se quisessemos que nossa máquina Linux passasse a enviar TTLs com valor 128 (padrão
de máquinas Windows), bastariamos usar o seguinte comando:
53
Firewall
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 128
Isso faz com que atacantes tentando identificar a nossa máquina tivessem informações incoerentes,
atrapalhando assim o processo de footprinting. As mudanças acima, por exemplo, são suficientes para
impedir que o p0f detecte uma máquina Linux com o Kubuntu 7.10.
Uma característica peculiar da tabela mangle é que nela, mesmo que uma regra correspondente a um
dado pacote seja encontrada, ainda assim todas as outras regras vão ser analisadas. Isso é necessário
pois as vezes queremos fazer mais de uma alteração em um pacote. Essa é uma das razões que tornam
essa tabela uma lugar inapropriado para a colocação de filtros de pacotes. Outra forte razão é que esse
não é o objetivo dessa tabela. Toda filtragem de pacote deve ser mantida nas tabelas de nat e filter.
2.6. Filtragem na camada 7
2.7. Protegendo-se de ataques de rede com o Iptables

Agora que já conhecemos toda a sintaxe do iptables e sabemos o que tem para nos oferecer podemos
estudar algumas das possibilidades que temos a nossa disposição. O objetivo dessa seção é mostrar
como o netfilter/iptables pode ser usado pra nós auxilir a evitar diversos problemas encontrados co-
mumente no nosso ambiente de rede.
Inicialmente serão mostrados alguns exemplos simples, cobrindo a filtragem de pacotes mais trivial,
e iremos avançando para exemplos mais complexos, que nós permitiram, por exemplo, evitar ataques
de DoS, como o Syn flood.
2.7.1. ICMP flood e ICMP Redirects

root@router:~# iptables -A FORWARD -p icmp --icmp-type echo-request
-m limit --limit 10/s -j ACCEPT
root@router:~# iptables -A FORWARD -p icmp --icmp-type echo-request
–j DROP
root@router:~# iptables -A FORWARD -p icmp --icmp-type redirect –j

DROP
2.7.2. Syn flood

root@router:~# iptables -A INPUT -p tcp --syn -m limit --limit 10/s
-j ACCEPT
root@router:~# iptables -A INPUT -p tcp --syn –j DROP
3. ISA
54
Capítulo 10. VPN
1. Introdução
2. OpenVPN
3. RRAS
4. ISA
55
Capítulo 11. Proxies
1. Introdução
2. Squid
3. Dans Guardian
4. ISA
56
Capítulo 12. Criptografia
1. Introdução
2. Tipo de criptografia
2.1. Criptografia simétrica
2.2. Criptografia assimétrica
3. Assinatura digital
4. Hashes
5. Infra-estrutura de chave pública
6. Kerberos
57
Parte IV. Exploração de aplicações
Capítulo 13. Vulnerabilidades na Web
1. Introdução
2. Directory Transversal e execução de códi-
go remota
3. SQL Injection
4. XSS
5. Vulnerabilidades dos Browsers
6. Google hacking
59
Capítulo 14. Explorando
vulnerabilidades dos sistemas
1. Introdução
1.1. Metasploit
60
Capítulo 15. Quebrando senhas
1. Introdução
2. Tipos de ataques
2.1. Ataques de dicionário
2.2. Ataques de força bruta
2.3. Ataques hibridos
3. Rainbow Tables
61
Parte V. Apêndices
Apêndice A. Cabeçalhos dos pacotes
63
Apêndice B. GNU Free
Documentation License
Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston,
MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document
"free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with
or without modifying it, either commercially or noncommercially. Secondarily, this License preserves
for the author and publisher a way to get credit for their work, while not being considered responsible
for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must them-
selves be free in the same sense. It complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms
that the software does. But this License is not limited to software manuals; it can be used for any
textual work, regardless of subject matter or whether it is published as a printed book. We recommend
this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by
the copyright holder saying it can be distributed under the terms of this License. Such a notice grants
a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated
herein. The "Document", below, refers to any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work
in a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it,
either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals
exclusively with the relationship of the publishers or authors of the Document to the Document's
overall subject (or to related matters) and contains nothing that could fall directly within that overall
subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of historical connection with the subject
or with related matters, or of legal, commercial, philosophical, ethical or political position regarding
them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under this License. If a section
does not fit the above definition of Secondary then it is not allowed to be designated as Invariant.
The Document may contain zero Invariant Sections. If the Document does not identify any Invariant
Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-
Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover
Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
64
GNU Free Documentation License
A "Transparent" copy of the Document means a machine-readable copy, represented in a format who-
se specification is available to the general public, that is suitable for revising the document straight-
forwardly with generic text editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input to text formatters or for
automatic translation to a variety of formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent. An image format is not Trans-
parent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo
input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-con-
forming simple HTML, PostScript or PDF designed for human modification. Examples of transpa-
rent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can
be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the machine-generated HTML, PostScript or PDF
produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are
needed to hold, legibly, the material this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means the text near the most prominent
appearance of the work's title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ
or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ
stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications",
"Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Docu-
ment means that it remains a section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License
applies to the Document. These Warranty Disclaimers are considered to be included by reference in
this License, but only as regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially,
provided that this License, the copyright notices, and the license notice saying this License applies to
the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of
this License. You may not use technical measures to obstruct or control the reading or further copying
of the copies you make or distribute. However, you may accept compensation in exchange for copies.
If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display
copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document,
numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the
front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present the full title with all words of the
title equally prominent and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title of the Document and satisfy these
conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones
listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
65
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either
include a machine-readable Transparent copy along with each Opaque copy, or state in or with each
Opaque copy a computer-network location from which the general network-using public has access
to download using public-standard network protocols a complete Transparent copy of the Document,
free of added material. If you use the latter option, you must take reasonably prudent steps, when you
begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus
accessible at the stated location until at least one year after the last time you distribute an Opaque copy
(directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing
any large number of copies, to give them a chance to provide you with an updated version of the
Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections
2 and 3 above, provided that you release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing distribution and modification of
the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the
Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and
from those of previous versions (which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version if the original publisher of that
version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of
the modifications in the Modified Version, together with at least five of the principal authors of
the Document (all of its principal authors, if it has fewer than five), unless they release you from
this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use
the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given
in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there
is no section Entitled "History" in the Document, create one stating the title, year, authors, and
publisher of the Document as given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy
of the Document, and likewise the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section. You may omit a network location for
a work that was published at least four years before the Document itself, or if the original publisher
of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section,
and preserve in the section all the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
66
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section
numbers or the equivalent are not considered part of the section titles.
M.Delete any section Entitled "Endorsements". Such a section may not be included in the Modified
Version.
N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any
Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some
or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of
your Modified Version by various parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as
a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by)
any one entity. If the Document already includes a cover text for the same cover, previously added by
you or by arrangement made by the same entity you are acting on behalf of, you may not add another;
but you may replace the old one, on explicit permission from the previous publisher that added the
old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms
defined in section 4 above for modified versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections
of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sec-
tions may be replaced with a single copy. If there are multiple Invariant Sections with the same na-
me but different contents, make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if known, or else a unique
number. Make the same adjustment to the section titles in the list of Invariant Sections in the license
notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original docu-
ments, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowled-
gements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorse-
ments".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this
License, and replace the individual copies of this License in the various documents with a single
copy that is included in the collection, provided that you follow the rules of this License for verbatim
copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this
License, provided you insert a copy of this License into the extracted document, and follow this License
in all other respects regarding verbatim copying of that document.
67
7. AGGREGATION WITH INDEPENDENT

WORKS
A compilation of the Document or its derivatives with other separate and independent documents or
works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights of the compilation's users beyond
what the individual works permit. When the Document is included in an aggregate, this License do-
es not apply to the other works in the aggregate which are not themselves derivative works of the
Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the
Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed
on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if
the Document is in electronic form. Otherwise they must appear on printed covers that bracket the
whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document
under the terms of section 4. Replacing Invariant Sections with translations requires special permission
from their copyright holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include a translation of this
License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you
also include the original English version of this License and the original versions of those notices and
disclaimers. In case of a disagreement between the translation and the original version of this License
or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requi-

rement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for
under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void,
and will automatically terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses terminated so long as such
parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation
License from time to time. Such new versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that
a particular numbered version of this License "or any later version" applies to it, you have the option
of following the terms and conditions either of that specified version or of any later version that has
been published (not as a draft) by the Free Software Foundation. If the Document does not specify
a version number of this License, you may choose any version ever published (not as a draft) by the
Free Software Foundation.
68
ADDENDUM: How to use this License for

your documents
To use this License in a document you have written, include a copy of the License in the document
and put the following copyright and license notices just after the title page:
Copyright (C) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.2 or any later version
published by the Free Software Foundation; with no Invariant Sections, no Front-
Cover Texts, and no Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts."
line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts
being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge
those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these exam-
ples in parallel under your choice of free software license, such as the GNU General Public License,
to permit their use in free software.
69

Seguranca de Redes

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Seguranca de Redes

Загружено:

Авторское право:

Доступные форматы

Segurança de Redes

Uma abordagem baseada em aplicações

4.3. IPSec .......................................................................................... 28

2. Tipo de criptografia ................................................................................. 57

• Adicionado conteúdo na seção “Snort”

• Adicionado conteúdo referente ao iptables na seção “Firewall”

• Adicionado conteúdo na seção “Camada de dados”

• Adicionado conteúdo sobre tcpdump e wireshark na seção “Analisadores de protocolo e Sniffers”

Normalmente os analisadores de protocolo trabalham colocando a placa de rede em modo promíscuo.

1.1. Filtros de captura

Opções básicas de filtragem

port Define a porta TCP/UDP que queremo filtrar..

1.1.1. Exemplos de filtros de captura

Exemplo 2.1. Monitorando trafego telnet

Exemplo 2.2. Monitorando trafego destinado a um host

Exemplo 2.3. Monitorando todo o trafégo UDP

Exemplo 2.4. Monitorando trafego para porta TCP 80 do servidor 192.168.5.1

Exemplo 2.5. Excluindo trafégo DNS da monitoração

Exemplo 2.6. Monitorando as portas

Exemplo 2.7. Monitorando a comunicação entre um cliente de 192.168.4.1 e um

Exemplo 2.8. Filtrando conexões SSH vindas de um dado cliente

1.1.2. Filtragem avançada de pacotes

dst port 80 and tcp[13] == 2

dst port 80 and tcp[13] & 0x3 == 0x3

Exemplo 2.9. Detectando worms

Figura 2.1. Exemplo de captura de pacotes do tcpdump

23:57:57.389417 IP 192.168.254.1.50586 > 192.168.254.254.Telnet: S

Figura 2.2. Exemplo de captura de pacotes AR

11:05:35.223066 arp who-has 192.168.254.1 tell 192.168.254.254

Figura 2.3. Exemplo de captura de pacotes DNS

11:03:57.672263 IP 192.168.254.1.32919 > 192.168.254.254.53:

Opções básicas tcpdump e Windump

detalhamento de pacote Mostra informações mais detalhadas de cada pacote. Em mui-

Figura 2.4. Tela principal do Wireshark

Figura 2.5. Visão detalhada de pacote TCP

3.1. Opções de captura

Figura 2.6. Opções de captura do Wireshark

Tabela 2.1. Opções de “Capture”

Interface Permite selecionar a itnerface onde será feita a

Tabela 2.2. Opções de “Capture File(s)”

File Esse campo, caso preenchido, define o arquivo

Tabela 2.3. Opções de “Stop Capture...”

Tabela 2.4. Opções de “Display Options”

Tabela 2.5. Opções de “Name Resolution”

Enable MAC name resolution Permite ao Wireshark “traduzir” o nome do fa-

3.2. Filtros de exibição

Figura 2.7. Filtrando pacotes TCP no Wireshark

Figura 2.8. Selecionando como decodificar um pacote

Tabela 2.6. Opções de comparação do Wireshark

Figura 2.9. Configuração de filtros de exibição

Tabela 2.7. Operações lógicas com expressões

Literal Simbolico Descrição

Tabela 2.8. Opções de uso do operador substring

3.3. Analises dos pacotes

Figura 2.10. Funcionalidade follow tcp do Wireshark

Figura 2.11. Resumo das propriedades da captura

Figura 2.12. Hierarquia de protocolos

Alguns pontos no entanto merecem destaque quanto as informções exibidas aqui:

Figura 2.13. Analise de “conversas”

Tick interval Intervalo de captura da amostragem.

Figura 2.14. Grafico de E/S de rede

4. Cain & Abel

2.1.2. Arp Sweep

[] [122:1:0] (portscan) TCP Portscan []

01/06-20:59:40.744183 [] [122:1:0] (portscan) TCP Portscan []