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çõesAntonio Augusto SantosCopyright © 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.2or 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’’.

iv

ÍndicePrefácio ....................................................................................................................... xI. Introdução ................................................................................................................ 1

1. Introdução ........................................................................................................ 21. Introdução ................................................................................................ 22. Footprinting .............................................................................................. 23. Varredura ................................................................................................. 24. Enumeração .............................................................................................. 25. Ganho de acesso ....................................................................................... 2

2. Analisadores de protocolo e Sniffers ..................................................................... 31. Introdução ................................................................................................ 3

1.1. Filtros de captura ............................................................................ 32. TCPdump e Windump ................................................................................ 53. Wireshark ................................................................................................ 8

3.1. Opções de captura ......................................................................... 103.2. Filtros de exibição ......................................................................... 143.3. Analises dos pacotes ...................................................................... 18

4. Cain & Abel ........................................................................................... 225. Dsniff .................................................................................................... 226. Contramedidas ........................................................................................ 22

6.1. Detectando sniffers ........................................................................ 223. Escaneamento de rede ...................................................................................... 23

1. Introdução .............................................................................................. 232. Network Scan ......................................................................................... 23

2.1. Ping Sweep .................................................................................. 232.2. Tracerouting ................................................................................. 23

3. Port scanning .......................................................................................... 233.1. Nmap .......................................................................................... 233.2. p0f .............................................................................................. 23

4. Scan de vulnerabilidades ........................................................................... 23II. Ataques e defesas as camadas de rede ......................................................................... 24

4. Camada de dados ............................................................................................ 251. Introdução .............................................................................................. 252. MAC Spoof ............................................................................................ 253. ARP Flood ............................................................................................. 264. ARP Poisoning ........................................................................................ 265. Ataques DHCP ........................................................................................ 26

5.1. DHCP Starvation .......................................................................... 265.2. DHCP Rogue Server ...................................................................... 26

6. Ferramentas ............................................................................................ 266.1. Dsniff ......................................................................................... 266.2. gobbler ........................................................................................ 266.3. arpwatch ...................................................................................... 266.4. ettercap ....................................................................................... 276.5. john the ripper .............................................................................. 276.6. cain and abbel .............................................................................. 27

7. Protegendo a camada 2 ............................................................................. 275. Camada de rede .............................................................................................. 28

1. Introdução .............................................................................................. 282. IP Spoof ................................................................................................ 283. Ataques ICMP ........................................................................................ 28

3.1. Mudança de rota usando ICMP ........................................................ 283.2. Teardrop/Ping of Death .................................................................. 28

4. Protegendo a camada 3 ............................................................................. 284.1. Evitando redirects .......................................................................... 284.2. Evitando spoof no sistema operacional .............................................. 28

Segurança de Redes

v

4.3. IPSec .......................................................................................... 286. Camada de transporte ....................................................................................... 29

1. Introdução .............................................................................................. 292. Syn Flood .............................................................................................. 293. TCP Hijacking ........................................................................................ 294. UDP Flooding ......................................................................................... 295. Protegendo a camada 4 ............................................................................. 29

5.1. Protegendo-se de synfloods ............................................................. 297. Camada de Aplicação ....................................................................................... 30

1. DNS ...................................................................................................... 301.1. DNS Spoof .................................................................................. 301.2. DNS Snooping .............................................................................. 301.3. MITM ......................................................................................... 301.4. Protegendo o DNS ........................................................................ 30

2. SMTP .................................................................................................... 302.1. Spoof de e-mail ............................................................................ 30

3. FTP ....................................................................................................... 304. Telnet .................................................................................................... 30

III. Ferramentas para proteção ....................................................................................... 318. Snort ............................................................................................................ 32

1. Introdução .............................................................................................. 322. Configurando o Snort ............................................................................... 32

2.1. include ........................................................................................ 322.2. Variáveis ..................................................................................... 322.3. Output ......................................................................................... 342.4. Config ......................................................................................... 36

3. Pré-processadores .................................................................................... 373.1. Stream5 ....................................................................................... 373.2. sfPortscan .................................................................................... 383.3. HTTP Inspect ............................................................................... 393.4. Outros pré-processadores ................................................................ 40

4. Regras ................................................................................................... 404.1. Cabeçalho .................................................................................... 414.2. Corpo .......................................................................................... 414.3. Exemplos de regras ....................................................................... 44

9. Firewall ........................................................................................................ 451. Introdução .............................................................................................. 452. Netfilter/Iptables ...................................................................................... 45

2.1. Introdução .................................................................................... 452.2. Funcionalidade básica do iptables ..................................................... 462.3. Alvos e Matches ........................................................................... 482.4. Trabalhando com a tabela NAT ....................................................... 532.5. Trabalhando com tabela Mangle ....................................................... 532.6. Filtragem na camada 7 ................................................................... 542.7. Protegendo-se de ataques de rede com o Iptables ................................. 54

3. ISA ....................................................................................................... 5410. VPN ........................................................................................................... 55

1. Introdução .............................................................................................. 552. OpenVPN ............................................................................................... 553. RRAS .................................................................................................... 554. ISA ....................................................................................................... 55

11. Proxies ........................................................................................................ 561. Introdução .............................................................................................. 562. Squid ..................................................................................................... 563. Dans Guardian ........................................................................................ 564. ISA ....................................................................................................... 56

12. Criptografia ................................................................................................. 571. Introdução .............................................................................................. 57

Segurança de Redes

vi

2. Tipo de criptografia ................................................................................. 572.1. Criptografia simétrica ..................................................................... 572.2. Criptografia assimétrica .................................................................. 57

3. Assinatura digital ..................................................................................... 574. Hashes ................................................................................................... 575. Infra-estrutura de chave pública .................................................................. 576. Kerberos ................................................................................................ 57

IV. Exploração de aplicações ........................................................................................ 5813. Vulnerabilidades na Web ................................................................................ 59

1. Introdução .............................................................................................. 592. Directory Transversal e execução de código remota ........................................ 593. SQL Injection ......................................................................................... 594. XSS ...................................................................................................... 595. Vulnerabilidades dos Browsers ................................................................... 596. Google hacking ....................................................................................... 59

14. Explorando vulnerabilidades dos sistemas ........................................................... 601. Introdução .............................................................................................. 60

1.1. Metasploit .................................................................................... 6015. Quebrando senhas ......................................................................................... 61

1. Introdução .............................................................................................. 612. Tipos de ataques ...................................................................................... 61

2.1. Ataques de dicionário .................................................................... 612.2. Ataques de força bruta ................................................................... 612.3. Ataques hibridos ........................................................................... 61

3. Rainbow Tables ....................................................................................... 61V. Apêndices .............................................................................................................. 62

A. Cabeçalhos dos pacotes .................................................................................... 63B. GNU Free Documentation License ..................................................................... 64

vii

Lista de Figuras2.1. Exemplo de captura de pacotes do tcpdump ................................................................. 62.2. Exemplo de captura de pacotes AR ............................................................................ 72.3. Exemplo de captura de pacotes DNS .......................................................................... 72.4. Tela principal do Wireshark ...................................................................................... 92.5. Visão detalhada de pacote TCP ............................................................................... 102.6. Opções de captura do Wireshark .............................................................................. 112.7. Filtrando pacotes TCP no Wireshark ......................................................................... 152.8. Selecionando como decodificar um pacote ................................................................. 162.9. Configuração de filtros de exibição .......................................................................... 172.10. Funcionalidade follow tcp do Wireshark .................................................................. 182.11. Resumo das propriedades da captura ....................................................................... 192.12. Hierarquia de protocolos ....................................................................................... 202.13. Analise de “conversas” ......................................................................................... 212.14. Grafico de E/S de rede ......................................................................................... 229.1. Fluxo de um pacote nas chains do netfilter ................................................................ 46

viii

Lista de Tabelas2.1. Opções de “Capture” ............................................................................................. 122.2. Opções de “Capture File(s)” .................................................................................... 132.3. Opções de “Stop Capture...” .................................................................................... 132.4. Opções de “Display Options” .................................................................................. 142.5. Opções de “Name Resolution” ................................................................................. 142.6. Opções de comparação do Wireshark ........................................................................ 162.7. Operações lógicas com expressões ........................................................................... 172.8. Opções de uso do operador substring ........................................................................ 18

ix

Lista de Exemplos2.1. Monitorando trafego telnet ....................................................................................... 42.2. Monitorando trafego destinado a um host .................................................................... 42.3. Monitorando todo o trafégo UDP ............................................................................... 42.4. Monitorando trafego para porta TCP 80 do servidor 192.168.5.1 ...................................... 42.5. Excluindo trafégo DNS da monitoração ...................................................................... 42.6. Monitorando as portas ............................................................................................ 42.7. Monitorando a comunicação entre um cliente de 192.168.4.1 e um servidor web192.168.5.3 .................................................................................................................. 42.8. Filtrando conexões SSH vindas de um dado cliente ....................................................... 42.9. Detectando worms .................................................................................................. 5

x

PrefácioHistórico de RevisõesRevisão 0.0.1 08 Jan 2008 AntonioSantos• Versão InicialRevisã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”

Parte I. Introdução

2

Capítulo 1. Introdução1. Introdução

2. Footprinting

3. Varredura

4. Enumeração

5. Ganho de acesso

3

Capítulo 2. Analisadores de protocoloe Sniffers

1. IntroduçãoUm analisador de protocolo (também conhecido como sniffer) é uma ferramenta que nós permiteanalisar o trafego de rede, mostrando informações detalhadas sobre pacotes e frames capturados apartir 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 nacamada 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 capturaA 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 Linuxa 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ãoimportantes 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 serprocessados. 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 tantospacotes, gerando assim um número razoável de descartes. A utilização de filtros vai então permitirque 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 osfiltros de visualização do Wireshark (vistos com em detalhes na Seção 3.2), mas justamente por issoeles são tão rápidos. Note que esse tipo de filtro normalmente pode ser usado em qualquer sniffer queutilize 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áriasnos pacotes ou especificar um procotolo que estamos procurando. A listagem abaixo mostra algumasdas opções básicas disponíveis para filtragem de pacotes. Na Seção 1.1.1 veremos alguns exemplosde 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..

Analisadores de protocolo e Sniffers

4

dst Define que o pacote deve ter como destino o host/net/port especificado..

ether, ip, tcp,udp, arp

Define que o pacote deve ser do protcolo definido..

broadcast Define que o pacote deve ser de broadcast. Pode-se também especificar o protocolopara o qual desejamos filtrar os broadcasts. O protocolo padrão é ethernet, filtrandoassim 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 úteispara 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 assimque 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 exemplosusando 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 dizermosque 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 umservidor 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)


5

1.1.2. Filtragem avançada de pacotes

Uma opção extremamente avançado, e pouco documentada, desses filtros é a possibilidade de verificaro valor de uma sequência de bytes dentro do pacote. Esse tipo de verificação pode ser interessantepara 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 precisariamosusar 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á quenosso indice começa de zero), possui o valor 2. Se olharmos a estrutura do protcolo TCP veremos queo 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ãovale 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 pacotesonde, 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 (oasopçõ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çõesque 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] == 48Welchia: 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 tamanhode 48 bytes (ip[2:2] == 48). Já o Welchia possui como principal caracteríticas o fato de ser um pacoteICMP-Echo (icmp[0] == 8), ter um tamanho de 92 bytes (ip[2:2] == 92), e de o payload do apcoteICMP começar com 4 bytes contento o valor hexadecimal “A” (icmp[8:4] == 0xAAAAAAAA).

2. TCPdump e WindumpAgora que já sabemos como funcionam os filtros de captura podemos começar o estudo de algunsanalisadores de conteúdo. Para começar vamos analisar o mais clásico de todos: o tcpdump, e suaversã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 oferecidaspelo 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 permitemque ele converta um pacote capturado da rede para um formato legivel para seres humanos. Comocada pacote carrega em si um protocolo diferente, também diferente são as saídas produziadas pelotcpdump. Na Figura 2.1 é exibida a captura de três pacotes, correspondentes ao hanshake inicial deuma conexão telnet. Note que o tcpdump mostra diversas informações relacionadas a troca de pacotes.


6

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 exibidasinformações que dependem do protocolo que foi capturado. No caso do TCP/IP, o tcpdump sempremostra uma saída com o seguinte formato: src > dst: flags data-seqno ack windowurgent options, onde somente os campos src, dst e flags estão sempre presente. Vamos analisarcada 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 comosuas portas. Esse campo possui sempre o formato host.porta > host.port . No caso do primeiro pacotede nosso exemplo ele está saindo do host 192.168.254.1, na porta 50586, e indo com destino ao host192.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 nolugar de seus IPs. Note também que, ao invés de mostrar o número da porta de destino ele exibiu oprotocolo 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 nossoexemplo 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 é apenasum pacote de ACK.

O próximo campo mostra qual o número de sequência do pacote, ou seja, a qual bytes da conexãoaquele pacote se refere. No exemplo acima os dois pacotes inicais possuem um número de sequência553835055 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á esperandoreceber um pacote com número de sequência igual a um. Isso ocorre pois, depois que o inicio de umaconexão foi detecado, o tcpdump imprime o valor do ack relativo ao inicio da conexão, e não maiso número de sequência original.

Os parâmetro win indica o tamanho da janela disponível pelo host para receber pacotes adicionais. Ocampo 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 apenasas opções disponiveis para pacotes TCP. A Figura 2.2 e Figura 2.3 mostram exemplos adicionaisreferentes a uma captura pacotes arp e DNS respectivamente.

1Em sistemas Linux esse arquivo normalmente está localizado em /etc/, enquanto que no Windows ele fica em C:\WINDOWS\system32\drivers\etc.


7

Figura 2.2. Exemplo de captura de pacotes AR

11:05:35.223066 arp who-has 192.168.254.1 tell 192.168.254.25411: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 umacaptura 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 aceleramem muito o processo de exibição dos pacotes iniciais, já que não vai haver um delay paraa resolução reversa de nomes. É sempre recomendável que essa opção seja usada e, casonecessá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 interfaceencontrada. Existe a opção de se escutar em todas as interfaces da máquina usando a pseudointerface any, no entanto nesse caso o modo promiscuo não vai poder ser habilitado. NoWindows 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 vaidesabilitar esse modo. Caso queiramos ter certeza que estamos capturando somente pacotesdestinados 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 umaoutra ferramenta (como o Wireshark).

-r Lê os pacotes de um arquivo dado, ao invés de a partir da interface de rede. Útil para verificaro 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çãofique com o menor valor possível para que possamos ter uma captura enxuta. Quanto maisinformação for capturada de cada pacote mais lenta ela ficará.

-x, -xx,-X, -XX

Essas opções permitem mostrar o conteúdo do pacote em sua forma hexadecimal (-x e -xx), ou em hexadimal e ASCII (-X e -XX). Pode-se escolher entre mostrar informações dacamada de dados (-xx e -XX) ou não (-x e -X).


8

3. WiresharkEnquanto o tcpdump e o Windump são ferramentas fantasticas, que permitem que capturemos pacotesem qualquer lugar e a qualquer momento eles não oferecem descrições minuciosas sobre os pacotescapturados. 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 outracaracterí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ídotendo 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 eexibir informações detalhadas sobre mais de 400 protocolos de rede. Essa lista inclui não somenteprotocolos da familia TCP/IP como também de redes IPX e AppleTalk, por exemplo. Além de todasessas 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 ainterface 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 emmais detalhes na Seção 3.2.

lista de pacotes É a parte colorida da figura. Nessa parte são exibidos algumasinformações sobre todos os pacotes que foram capturados pelowireshark.

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 dopacote em questão, tanto no formato hexa quanto em ASCII.Essa saída é idêntica aquela conseguida com a opções -XX dotcpdump.

É interessante notar também que existe uma sincronização entre os dados exibidos/selecionados naparte de detalhamento de pacotes e a visão em bytes, de tal forma que ao selecionarmos um campona visão de detalhamento a sequência de bytes correspondente a essa opção será também selecionadana visão em byte, e vice-versa.


9

Figura 2.4. Tela principal do Wireshark


10

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 capturapode ser iniciada de diversas maneiras. Uma delas é acessando a opção Capture # Options (C-k), apartir 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 podemosver todas as opções disponíveis para fazermos uma captura.


11

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 tabelamostra as opções disponíveis nos frames com o nome dado.


12

Tabela 2.1. Opções de “Capture”

Interface Permite selecionar a itnerface onde será feita acaptura. Por padrão o Wireshark escuta na primei-ra interface não loopback que ele encontra, maspode-se mudar essa opção escolhendo-se uma dasinterfaces listadas nessa guia. Note que em algunssistemas 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 possuanenhuma IP associado a ela será exibido a mensa-gem “unknow”.

Link Layer Header Type A depender da interface selecionada esse campopode 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 dearmazenamento de pacotes capturados. Aumentaro valor dessa opção (que tem valor padrão 1Mb)pode ajudar caso tenha-mos cenários onde muitospacotes 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 notcpdump, 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 queremoscapturar 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 dessecampo caso não estejamos interessados em todasas informações do pacote, ou então quando que-remos obter um melhor desempenho nas nossascapturas, já que quanto menos informações captu-rarmos menor será o trabalho que nossa CPU vaiter.

Capture filter Como o Wireshark é baseado na libpcap, é pos-sível especificarmos filtros de captura no mesmoestilo 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 aopção de filtros de exibição (Seção 3.2), mas es-tes tem um objetivo completamente diferente dosfiltros de captura.


13

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

File Esse campo, caso preenchido, define o arquivoonde 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 deserem 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 gigabytestiver sido capturado.

Next file every... Cria um novo arquivo assim que o número espe-cifico de segundos, minutos, horas ou dias tiverpassado.

Ring buffer with n files Cria um buffer circular para o armazenamento dosdados. 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, eos dados iniciais são perdidos.

Stop capture after n file(s) Para a captura assim que o número especificadode 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 onúmero definido de pacotes tiver sido capturado.

... after n megabytes(s) Essa opção serve para parar a captura depois queo número definido de megabytes tiver sido captu-rado.

... after n minute(s) Essa opção serve para parar a captura depois queo número definido de minutos tiver se passado.


14

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

Update list of packets in real time Serve para atualizar a lista de pacotes em temporeal com os novos pacotes capturados. Essa op-ção consome mais CPU e portanto pode gerar umamaior perda de pacotes.

Automatic scrolling in live capture Permite que a lista de pacotes seja roalda de formaque os novos pacotes estejam sempre visiveis. Es-sa opção pode tornar o acompanhamento da cap-tura extremamente complicada em redes com altovolume.

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 dostipos 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, ondeXX:XX:XX são as seis últimas letras do endere-ço MAC da placa, e FAB é o nome do fabricantedaquela placa.

Enable network name resolution Permite ao Wireshark tentar resolver o nome doshosts que estão sendo capturados na rede. Esta op-ção torna a exibição de pacotes mais lenta, já queuma 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 jeitoque o tcpdump. Essa opção permite que ao invésde 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 essesfiltros nós podemos fazer uma filtragem extremamente detalhada dos pacotes que estamos analisandopara 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 deser feita num nível mais alto, consumindo assim mais CPU. Usar filtros de exibição para um volumemuito 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 deum campo no pacote, o valor de um campo, comparar valores de dois campos, etc. Para trabalharmoscom filtros de exibição podemos usar a barra de filtro disponivel logo abaixo da barra de menus natela principal do Wireshark.

Vamos trabalhar com alguns exemplos para podermos entender melhor como funciona esse processode captura. Por exemplo, caso quisessemos filtrar nossa captura de modo que ela exibda somentepacotes TCP, bastaria colocarmos a linha tcp, na barra de filtragem. O resultado disso é mostradona Figura 2.7.


15

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 onúmero do pacote começa por 11, isso ocorre pois os 10 primeiros pacotes não eram TCP, e por issoestão ocultos. No entanto esses pacotes continuam presentes na nossa captura, o filtro serve apenaspara 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. Ouseja, se tivermos um servidor HTTP escutando na porta 83 nós não poderemos usar o filtro HTTPpara detectar esse trafego.

No entanto essa barreira pode ser contornada. Caso saibamos que existe um servidor Web rodando naporta 8083 nós podemos definir que todo o trafégo que for destinado a porta 8083 deve ser tratadocomo HTTP. Para fazer isso basta selecionarmos um dos pacotes envolvidos na conexão é acessarmosa opção Analyse # Decode As..., a partir daí nós podemos definir que todos os pacotes destinados aporta 8083 devem ser tratadoos como pacotes HTTP. Isso pode ser visto na Figura 2.8.


16

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 Wiresharkpode ajudar nessa questão também. Ele nós permite procurar em todo o pacote capturado por qualquerstring que especificarmos. Juntando essa funcionalidade com o conhecimento do protocolo HTTP nóspodemos criar um filtro que vai procurar, em todos os pacotes, a ocorrência palavra HTTP/1.1, queidentifica uma resposta HTTP. Com isso nós podemos saber quais pacotes estão relacionados comuma 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 podemosusar 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 descritasna 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 paracada um desses protocolos ele pode também mostrar (praticamente) todas as características dele. Alémde servir para podermos visualizar em maiores detalhes um protocolo essas características tambémpodem servir como mecanismos de filtragem.

Por exemplo, como já visto anteriormente o Wireshark pode exibir todos os campos relacionados apacotes 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 usarmoso 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 a192.168.254.1. Caso queiramos filtrar apenas pacotes Telnet, podemos usar o filtro:


17

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 deprotocolos que podemos escolher para filtrar, edentro de cada um deles a quantidade de opções quetemos. Uma lista detalhada de todo os protocolos, campos e suas descrições pode ser encontrado emhttp://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 diversasmaneiras 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, casodesejassemos filtrar todos os pacotes capturados que possuem placas de rede da VMware. Atravésdo cadastro de OUIs do site da IETF (http://standards.ieee.org/regauth/oui/index.shtml), nós podemosdescobrir que um dos OUIs atribuitos à VMWare é 00:0C:29. Com essa informação nós podemos criaro seguinte filtro: eth.addr[0-2] == 00:0C:29, que diz que no campo eth.addr (o MAC daplaca), 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.

http://www.wireshark.org/docs/dfref/

http://standards.ieee.org/regauth/oui/index.shtml


18

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 seinicia em x.

[:x] Deve-se comparar tudo desde o começo até o bytex.

[x:] Deve-se comparar tudo desde o byte x até o finaldo campo.

[x] Deve-se comparar o valor do byte x.

[x:y,z-w,k] É possível combinar qualquer um dos formatosacimas de uma única vez, separando os delimita-dores por virgula.

3.3. Analises dos pacotesAlém de ser uma grande ferramenta de captura o Wireshark também permite que nós façamos diversasanálises com os pacotes que capturamos. Uma dessas analises nos permite verificar de forma textualtodo 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, deforma 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 queremosverificar, e selecionar a opção Capture # Options, a partir do meu principal. Podemos ver na Figura 2.10um exemplo que mostra as informações capturadas numa seção telnet. Note como podemos fácilmenteidentificar o usuário e a senha usados na conexão. Essa é a principal razão pela qual devemos usarSSH 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 nossacaptura. A primeira opção que nós temos quando acessamos esse campo é Summary. Essa opçãomostra uma visão detalhada de nossa captura, informado, entre outras coisas, o momento em que acaptura teve inicio e quando ela teve fim, qual a interface que foi usada para a captura e qual filtrode catura foi usado.


19

Ainda nessa tela nós temos algumas informações gerais sobre os pacotes, que mostra,: o tmepo total decaptura, 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 tantopara 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 osprotocolos e subprotocolos que foram capturados. Essa opção pode ser acesar através do menu Staistics# Protocol Hierarchy.


20

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 vaiser menor que o total de pacotes daquele tipo. Por exemplo, na figura o protocolo TCP é responsávelpor 43,69% do total de pacotes, no entanto a soma de todos seus subprotocolos não chega a essevalor. Nessa caso uma razão para isso é que pacotes TCP ACK não são contatos como pacotes dacamada superior.

• Um mesmo pacote pode conter mais um protocolo do mesmo tipo, como é o caso de protocolos detunelamento. 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 pacotestrafegados. 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 quantode destino. A janela de conversations pode ser vista na . Note que é possível selecionarmos diversosprotocolos na aba superior.


21

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óspermite 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çãoem tempo real.

Na Figura 2.14 nós podemos ver um exemplo do grafico de E/S. Note que esse grafico possui três filtroshabilitados. O primeiro (em preto) mostra todo o trafego capturado, o segundo (vermelho) possui umfiltro 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 tempomaior 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.


22

Figura 2.14. Grafico de E/S de rede

4. Cain & Abel

5. Dsniff

6. Contramedidas

6.1. Detectando sniffers

23

Capítulo 3. Escaneamento de rede1. 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

Parte II. Ataques e defesasas camadas de rede

25

Capítulo 4. Camada de dados1. Introdução

2. MAC SpoofEssa é a técnica mais básica para o ataque à camada 2. Ainda veremos técnicas de spoof aplicadas emmuitas outras partes dos nosso estudo, e em todas ela possui o mesmo funcionamento básico: permitirque 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 nossaplaca de rede. Enquanto o endereço MAC está definido na placa de rede, é o sistema operacional quedecide 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áriopara a configuração de placa de rede. A sintaxe usada para mudar o endereço MAC de uma interfacede 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, umantes da mudança do MAC e outros depois.

Camada de dados

26

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 rawsockets em ambientes Unix ou Windows. Para os que conhecem Python o Scapy torna essa tarefamuito mais simples.

3. ARP FloodEsse tipo de ataque é comumente em redes formadas por Switches, e consiste em enviar vários pacotesARP 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 umgrande 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 totalparalização da rede, o switch passa a operar em um modo parecido com um HUB, enviando todos ospacotes para todas as portas (já que ele não tem mais como saber qual MAC está associado a qualporta), permitindo assim a um atacante escutar o todo o trafego que passa por aquela rede, e mesmorealizar ataques de homem do meio.

Esse tipo de ataque foi inicialmente concebido por Ian Vitek em 1999, e pode ser realizado atualmenteatravés de diversas ferramentas, como o dsniff.

4. ARP PoisoningEnvenenamento 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 talforma 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

Camada de dados

27

6.4. ettercap

6.5. john the ripper

6.6. cain and abbel

7. Protegendo a camada 2A camada de dados implementada no modelo Ethernet é extremamente vulnerável, não possuindonenhuma medida de segurança que possa ser implementada no próprio protocolo. O meio mais comumde proteção contra ataques nessa camada é a utilização de switches que possam associar um MAC aum 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 outrostipos de ataque, como o envenenamento de ARP e ataques a DHCP, que independem de um MACfalsificado. Para a primeira situação uma solução é a implementação de switches mais inteligentes quepossam detectar uma resposta ARP suspeita e barra-la. Além disso os sistemas operacionais devemser 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 mensagensDHCP (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ãode mercado.

28

Capítulo 5. Camada de rede1. Introdução

2. IP Spoof

3. Ataques ICMP

3.1. Mudança de rota usando ICMP

3.2. Teardrop/Ping of Death

4. Protegendo a camada 3

4.1. Evitando redirects

4.2. Evitando spoof no sistema operacional

4.3. IPSec

29

Capítulo 6. Camada de transporte1. Introdução

2. Syn Flood

3. TCP Hijacking

4. UDP FloodingComo o UDP é um pacote não orientado a conexão não existe muito que um atacante possa fazercontra ele a nivel de rede. O melhor que um atacante pode fazer usando UDP é tentar uma avalanchede 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ãoquer dizer que as aplicações que fazem uso desse protocolo sejam automaticamente seguras. Existemdiversos protocolos de camada sete (como o DNS), que usam UDP, e já apresentaram no passadodiversos problemas de segurança.

5. Protegendo a camada 4

5.1. Protegendo-se de synfloods

30

Capítulo 7. Camada de Aplicação1. DNS

1.1. DNS Spoof

1.2. DNS Snooping

1.3. MITM

1.4. Protegendo o DNSDNS Transaction Signatures (TSIG)

2. SMTP

2.1. Spoof de e-mail

3. FTP

4. Telnet

Parte III. Ferramentas para proteção

32

Capítulo 8. Snort1. Introdução

O Snort é um sistema de detecção de intrusão (IDS) de rede (NIDS), de código livre disponível emwww.snort.org. O objetivo do Snort é monitorar o trafego de rede e avisar caso seja detectado algumpacote 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 desdeconexões a servidores de IRC até tentativas de ataques de worms, virus, portscans, etc. Existe aindaa 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 paracada ambiente. Por exemplo, o Snort monitora por tentativas de exploração de falhas conhecidas paraservidores IIS, mas se seu ambiente possuir somente servidores rodando Apache os alertas geradospelo Snort (apesar de te alertarem de que existe alguém tentando comprometer sua rede), não devemser 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 escolhade onde vamos instalar nosso IDS depende em muito do que queremos monitorar. Caso desejemosmonitorar um único host de nossa rede (ou se a rede for composta de apenas uma máquina), o Snortpode tranqüilamente ser instalado no próprio host. Caso desejemos monitorar um conjunto de máquinadevemos fazer a instalação de tal forma que o Snort fique no mesmo segmento de rede das máquinasque queremos monitorar e, além disso, ele deve ser capaz de escutar todo o trafego endereçado aqualquer uma das máquinas.

Um observação antes de começarmos: O Snort é uma ferramenta extremamente ampla de poderosa, eo que será abordado aqui são somente alguns dos pontos mais importantes de sua configuração. Paraaqueles que desejarem informações mais aprofundadas sobre o Snort é recomendada a leitura do seumanual, disponível em http://www.snort.org/docs/snort_manual/2.8.0/snort_manual.pdf.

2. Configurando o SnortO snort.conf é o arquivo que controla todo o funcionamento do Snort. Nele são definidas as regras quedão ao Snort a sua capacidade de detectar ataques, bem como configurações para o seu funcionandocomo, 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 dosnort.

2.1. includeEssa 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 desabilitadasde 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áveisO 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

Snort

33

alteração de configurações de forma fácil e pontual, sem precisar realizar mudanças em várias partesdo arquivo.

As variáveis no Snort são usadas para representar três objetos básicos: strings, portas TCP/UDP eIPs. 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 essenã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 obtero valor de uma variável devemos usar a sintaxe $VARIAVEL. O exemplo abaixo ilustra a utilizaçãocombinada 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), deum 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 algunsexemplos de definições de porta:

portvar EXEMPLO1 80var1 PORT_EXEMPLO2 [1]var1 EXEMPLO2_PORT [80:90]portvar EXEMPLO3 anyportvar 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 exemploabaixo 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émpodem ser aplicados aqui.

O exemplo abaixo ilustra uma situação onde queremos definir uma variável que referencie o host1.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çãotambém pode ser usado com portas.

1Atualmente 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.

Snort

34

[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ãodetalhadas 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 essavariável para verificar se os ataques são direcionados as redes que eles devemproteger.

EXTERNAL_NET É a chamada rede “externa”, ou seja, o ambiente hostil que estará tentando invadirnossos servidores. Normalmente ele pode ser definido como !$HOME_NET.

Em casos onde se deseja monitorar uma rede LAN deve-se configurar tantoHOME_NET quando EXTERNAL_NET para any, já que nesse caso não existerede interna/externa.

*_SERVERS Existem diversas variáveis do tipo HTTP_SERVERS e SMTP_SERVERS queservem para que possamos definir quais são os nossos servidores para cada tipode serviço. Isso é usado para evitar que o Snort perca tempo verificando um aexistê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 facade 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 processode controle muito bem estabelecido na empresa, o qual vai permitir que essasconfiguraçõ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 como include.

2.3. OutputO Snort deve armazenar seus alertas em algum lugar,e como sempre a flexibilidade é um dos carroschefes aqui. A opção output, permite a utilização de plugins para definir onde o snort vai armazenaros alertas gerados. As possibilidades de saída incluem, entre outras, um arquivo de texto plano, umservidor 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 osalertas. 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.128PROTO:255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:158 DF

Snort

35

Nessas linhas podemos ver todas as informações referentes ao ataque que foi detectado. A primeiralinha pode ser vista como o cabeçalho do alerta, e detalha qual o código do alerta (122:1:0, que pode serusado para verificar no site do Snort informações mais detalhadas sobre esse ataque) e uma informaçãodescritiva 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 dopacote referente ao ataque.

Esse tipo de alerta pode ser configurado usando o plugin alert_full. Esse plugin tem como parâmetroo arquivo onde os logs devem ser armazenados. Por exemplo, caso desejássemos armazenar os alertasno 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 geraos alertas em apenas uma linha. Esse plugin é chamado de alert_fast. Nele o mesmo alerta mostradoacima 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 paraque depois possa fazer uma analise dos mesmos. Por padrão os pacotes são armazenados num formatode texto do próprio Snort. Armazenar os logs nesse formato não é uma boa idéia pois acarreta numaperda 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 nomercado 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 sintaxedela é 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 iniciamoso Snort um novo arquivo é gerado, com o nome que especificamos e com um timestamp no padrãoUNIX adicionado no final do nome (isto é, o número de segundos passados desde 1° de janeiro de1970).

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 apossibilidade de manipulação das informações geradas por ele (usando, por exemplo, o BASE). Aconfiguraçã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. Casoescolhamos 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ãomssql, mysql, postgresql, oracle e odbc.

Snort

36

A terceira opção são listas de parâmetros usadas para a conexão com o banco de dados. Abaixo segueuma 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 umbando de dados mysql configurado na própria máquina poderíamos usar uma linha parecida com aque 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 sidocriado, eles podem ser encontrados no diretório contrib na distribuição do código fonte do Snort.

2.4. ConfigO uso da diretiva config permite a mudança de diversos parâmetros para o funcionamento interno doSnort. 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 pacotespor padrões de tentativas de ataque. Essa configuração tem grandes efeitos no uso da memória e navelocidade 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 entreum 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 ainterface “any”, que representa todas as interfaces de rede. No entanto esse modo não suporta operarem 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çãoequivale 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çãoequivale 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. Essaregra é útil, por exemplo, para evitar alertas desnecessários para pacotes NFS. Deve-se especificar oprotocolo (TCP, UDP, ICMP ou IP) e logo em seguida a porta, ou intervalos de porta.

Snort

37

2.4.5. utc

Armazena os logs em referência ao UTC, ao invés de no formato de horário local.

3. Pré-processadoresPré-processadores são módulos que adicionam muita flexibilidade ao Snort. Eles podem ser vistoscomo plugins, escritos em C/C++ e que servem para inspecionar os pacotes antes deles chegarem naengine 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 menorgasto de processamento, quando comparados com o uso de regras como as que na seção XX. Algumasdas funcionalidades desempenhadas pelo pré-processadores incluem: combinação de fragmentos TCPem 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çõesanteriores. 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ósvamos apresentar a seguir alguns dos pré-processadores que apresentam funcionalidades que podemser mais facilmente aproveitadas em qualquer ambiente.

3.1. Stream5Esse pré-processador da ao Snort a capacidade de ser uma IDS statefull, isto é, agora ele pode saberde qual sessão um pacote TCP, UDP ou mesmo ICMP faz parte. Isto é muito importante pois, porpadrão, o Snort é stateless, isto é, ele só vê cada pacote independentemente e não consegue analisarcorrelaçõ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 desessão do protocolo para surtirem efeito. Sem esse pré-processador o Snort não tem como detectaresse tipo de acontecimento. O Stream5 também permite que usemos a palavra flow na nossa definiçãode 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ãopara que nossas regras possam ser verificadas contra toda a sessão. Isto é importante para aplicaçõescomo Telnet, onde um pacote é enviado para cada tecla que pressionamos. Sem esse plugin seriaimpossí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, eminglês) todos os pacotes da sessão para que possamos verificar se a string que desejamos foi enviadacomo parte da sessão.

As configurações possíveis para o Stream5 são stream5_global, stream5_tcp, stream5_udp estream5_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 podemser usadas desde que separadas por virgula.

track_tcp, track_udp,track_icmp

Habilita ou desabilita o suporte ao monitoramento de sessões TCP, UDP eICMP, respectivamente. O padrão para todos é estarem habilitados. Ex.: pre-processor stream5_global: track_tcp yes.

max_tcp, max_udp,max_icmp

Define qual o número máximo de sessões TCP, UDP ou ICMP que devemser monitoradas. Os valores padrões são, 256.000, 128.000 e 64.000, respec-tivamente. Ex.: preprocessor stream5_global: max_udp 512.000.

Snort

38

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 umalerta 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íticadesse 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 deuma 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, eexiste um host na nossa rede que possui um timeout de 1 minu-to. Com isso, se um atacante ficar sem enviar pacotes por maisde 30 segundos, o Snort vai parar de monitorar a sessão, mas amáquina alvo vai aceitar o pacote normalmente. Também não sepode escolher valores muito altos para essa opção pois isso podefazer 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ãosejam monitoradas. Ex: preprocessor stream5_tcp: timeout 60

ports Determina em que direção e em qual portas as sessões devemser remontadas. Pode-se escolher, por exemplo, que somente asconexões da porta 80 oriundas dos servidores web e telnet sejamremontadas. Essa configuração pode aparecer mais uma vez emcada 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.: preprocessorstream5_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 seusvalores 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. sfPortscanEsse 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, masusando 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 dissoele 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:

Snort

39

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çõessã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çõescomo 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 sergravados. 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 pelosmódulos Stream5 ou Flow.

3.3. HTTP InspectEsse 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 abaixoilustra duas URLs que representam o mesmo recurso (e para o servidor Web, elas são exatamente amesma 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 vezesesses 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 outraa configuração por servidor, que define como uma URL deve ser verificada, a depender de para qualservidor ela esteja sendo enviada.

3.3.1. Configuração global

Essa opção normalmente é usada para se especificar o mapa de caracteres usado para decodificarcaracteres unicode para servidores IIS. Essa configuração possui a seguinte sintaxe:

Snort

40

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 quedeve 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çõespossí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ãoexiste nenhum outro caso mais especifico. A segunda opção (profile) define o perfil padrão que deveser usado para as comunicações desse servidor. As opções iis e apache são configuram várias outrasopções para que elas funcionem da melhor forma possível com essas dois servidores, enquanto a opçãoall serve para detectar todos os tipos de ataque, independente de qual servidor está rodando na máquinaalvo. A terceira opção (ports) define quais portas devem ter sua comunicação decodificada, valoreslógicos aqui incluem as portas 80, 8081 e 8080 (normalmente associadas com servidores Web). Aporta 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çõesmais avançadas para detectar ataques mais sutis é recomendável a leitura do manual do Snort.

3.4. Outros pré-processadoresAlém do decodificador de HTTP o Snort possui alguns outros pré-processadores que servem paramonitorar comportamento suspeito no trafégo de diversos serviços da camada sete, como por exemploSSH, Telnet, SMTP e RPC.

É recomendável a leitura do manual do Snort para que se possa verificar com detalhes o funcionamentode cada um deles.

4. RegrasChegamos agora na parte mais interessante do Snort. As regras são, por assim dizer, o coração doSnort. 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 paraum administrador alterar as regras usadas para a detecção de um ataque, ou, até mesmo, criar novasregras a partir do zero. Veja abaixo um exemplo de uma regra do Snort que serve para detectar umatentativa 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, depoisde terminarmos essa sessão será possível ver com claridade o real significado de cada campo existenteaqui, 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 cadauma dessas parte em separado.

Snort

41

4.1. CabeçalhoO cabeçalho de uma regra do Snort serve como um filtro para evitar que um processamento maispesado 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 partesque 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 suagravaçã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 gerandomuito ruído.

activate, dyna-mic

Usado em conjunção com outras regras que possuem a ação definda como dynamic.Essas duas regras em conjunto servem para detectar ataques que são compostos poruma seqüência de pacotes, e que não poderiam ser detectados analisando um pacoteindependentemente.

4.1.2. Protocolo

Essa é a segunda opção que devemos usar e deve ser desde já bem clara: ela vai especificar quaisprotocolos 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 portassã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 elementoda 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 servepara evitar que todos os pacotes passem pela estrito controle que pode ser feito aqui. As regras de

Snort

42

corpo são extremamente poderosas, flexíveis e, acima de tudo, pesadas. Nesse campo nos podemosespecificar desde da mensagem que será mostrada junto com os alertas, até poder analisar se o pacoteem 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 formaitem:”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çõesimportantes 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 umaregra (regras feitas “em casa” devem ter sid acima de um milhão), enquanto o revidentifica 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. Umacategoria, 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 sidoum 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, entreoutras coisas, comportamentos “não convencionais” dos protocolos (como um pacote IP com todosos flags ativados).

ipopts Serve para verificar se algumas opções do IP estão presentes, como por exemplo: IPSecurity (sec), Loose Source Routing (lsrr), Strict Source Routing (ssrr). Apenas umaopçã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íveissã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ívelusar alguns modificadores para verificar: 1)se as flags especificadas, ou outras, estãoativadas (+); 2) se qualquer uma das flags especificadas está ativa (*); 3) verificar senenhuma 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 protocolocontido 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.

Snort

43

4.2.3. Teste de payloadEsses testes servem para verificar o payload (isto é, conteúdo) de um dado pacote. A principal cláusulaapresentada 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, eledeve 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 ouminúsculas. Ex.: content: “hAcKeR”; nocase;.

rawbytes Especifica que a busca deve ser realizada no conteúdo original do pacote, e não noresultado 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 deveser 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. HTTPEnquanto essas regras também tratam do payload de um pacote elas tem a característica especial nosentido que elas servem especificamente para pacotes HTTP normalizados, isto é, depois que elespassaram por um pré-processador. Todas as cláusulas apresentadas a seguir são modificadores daclá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 Webpor 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 ohttp_uri. Ex: uricontent:”google.com”

urilen Verifica o tamanho da URI contida no pacote. Ela pode verificar o tamanhoexato da URI (urilen: 10), seu tamanho mínimo (urilen: <5), o tamanhomáximo (urilen > 10), ou se seu tamanho está dentro de um intervalo (urilen:5<>10).

4.2.5. OutrosOpçõ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 paraverificar a direção incluem as opções to_server e to_client. Além disso é tambémpossí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ãoou 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 paraidentificar quais outras regras devem ser acionadas. Ex: activate: 1

Snort

44

activiated_by Usando junto com a ação dynamic de uma regra (visto anteriormente). Servepara 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

45

Capítulo 9. Firewall1. Introdução

2. Netfilter/Iptables

2.1. Introduçãonetfilter é um framework para gerenciamento de pacotes no Linux disponível desde a versão 2.4 doKernel. O netfilter na verdade é um conjunto de bibliotecas e comandos que fazem comunicação como 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 netfiltersã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 demanipular 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 doLinux. 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 regraspara a filtragem de pacotes (para muitos a razão de ser de um firewall). Essa tabela, porpadrã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 à Internetatravés de um único endereço IP. O netfilter suporta os mais diversos tipos de NAT, comoSNAT e DNAT.

mangle Essa tabela permite a manipulação dos pacotes das mais diversas maneiras. Permitindo aalteração de informações contidas no mesmo, como, por exemplo, mudar o valor TTL, doTOS, etc.

Dentro de cada uma dessas tabelas existem diversas chains. Cada chain é uma sequência de regrasverificada na ordem em que aparecem que vão determinar qual ação deve ser tomada para um dadopacote. Cada tabela possui algumas chains pré-definidas, que são as responsáveis pelo recebimentode 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 cincopontos onde o netfilter pode capturar um pacote, inspecioná-lo e fazer alguma modificação. Essascinco localizaçãoes são mostradas na Figura 9.1. É importante conhecer essas localizações pois elasajudam 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 aquipassam ú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 firewallde rede.

input Pacotes com destino a nossa máquina são inspecionados através desse chain. Aquipassam exclusivamente pacotes destinados a nossa máquina, sejam eles originados

Firewall

46

de outras máquinas da rede ou dela própria. Novamente aqui não é o local de regrasrelacionadas 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 tomequalquer decisão de roteamento em relação a esse pacote. Nesse momento aindanã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, olugar mais indicado para serem feitas filtragens em firewalls funcionando comoroteadores.

postrouting Essa chain é parecida com os a forward, a diferença é que aqui passam não somenteos pacotes vindos de outras redes, mas também aqueles que saem de nossa máquinae 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 emtodas as três tabelas). Quando uma situação dessa ocorrer devemos saber que existe uma ordem depreferê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, bemcomo 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 naSeção 2.3.2.

Firewall

47

-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 chainseja 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 sersatisfeitas: 1) não pode haver nenhuma chain que possua comoalvo a chain que queremos apagar; 2) A chain que queremosapagar deve estar vazia (sem regras). Se nenhum argumento forespecificado 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 detoda a tabela serão zerados. Caso a opção -L seja passado jun-tamente com essa opção os contadores serão exibidos antes deserem 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ériede “matches”, e de um alvo. Os matches são opções que devemestar presentes no pacote para que ele possa “casar” com umaregra (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 tomadapara com aquele pacote, caso ele case com a regra definida.

-D, --delete <chain> <regra | nume-ro>

Reomve uma regra de uma dada chain. Existem dois meios dese 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 regradentro da chain.

-I, --insert <chain> [numero] <re-gra >

Enquanto a opção -A nos permite inserir uma regra no fina ldeuma chain, a opção -I nos permite inserir novas regras em qual-quer posição dentro da chain. Caso nenhum valor seja apssadopara ela, por padrão a nova regra é inserida na primeira posição.

-R, --replace <chain> numero <re-gra>

Substitui a regra existente na posção especificada pela nova re-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çãoou inserção). Além desses parâmetros o iptables também suporta uma série de extensões chamadas dematches, que permitem a especificação de regras mais ricas, verificando as mais diversas propriedadesde 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-nation

Permite especificar qual deve ser o endereços de origem (-s), ou de destino(-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).

Firewall

48

Existem ainda diversos outros alvos disponíveis no netfilter, alguns dessesserão estudados na Seção 2.3.2. Adicionamento uma chain também podeser 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 definidanela 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 aquelepacote, mas, ainda assim, os contadores associados àquele regra vão serincrementados, indicando que occoreu um “match”.

-i, --in-interface, -o, --out-interface

Permite definir através de qual interface de rede o pacote deve estar che-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 asregras, como por exemplo, opções de conifugração de interface de entrada esaí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 (wwwno 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 descritasna Seção 2.2.3. Esses módulos permitem fazer filtragens mais especificas, verificando não só váriaspropriedades 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 modulosrelacionados 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 listaextensiva. Caso deseje-se conhecer todos os modulos disponíveis recomenda-se a leitura das páginasde 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: casoessa opção seja passada imediatamente antes da especificação de um porta, a regra vai passar a aceitarpacotes 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

Firewall

49

pacotes ou mesmo o tamanho médio de cada pacote. Essas informações podem ser úteis para detectarataques de negação de serviço, onde grandes volumes de informação estão sendo transmitidos tentandosobreccaregar 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|both>

Permite especificar em qual direção de trafégo o volume temde ser avaliado.

--connbytes-mode <packets|by-tes|avgpkt>

Define o que queremos monitorar. As opções listadas permi-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 den.

--connlimit-mask <mascara> Define qual mascara deve ser aplicada para verificar quantoshosts de uma mesma rede estão con conexões silmutâneas aonosso 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 verificcaro 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 serum número, ou uma expressão que designa o tipo em questão. Parauma lista de todos os tipos suportados pelo netfilter use o comandoiptables -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 evitarataques de DoS ou qualquer tentativa de portscan. Usando-se o limit é possível sabermos quando onú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 passoude 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 doespecificado vão disparar essa regra. Essa opção é um número se-guida por um sufixo que vai especificar a unidade de tempo. Essesufico pode ser : /second,/minute,/hour,/day. O valor padrão é 3 pa-cote por horas (3/hour).

Firewall

50

--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 colocarmoso valor 10 aqui estamos dizendo que mais 10 pacotes devem passarcom essa frequência antes do limite começar a fazer efeito. O valorpadrão é 5.

2.3.1.5. mac

Serve para filtrar pacotes com base no endereço MAC de origem. Essa regra é valida somente naschains 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 tipoXX: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 poisalguns 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 evaliarse uma conexão TCP a porta 80 do nosso servidor não esta vindo através de um broadasct.

--pkt-type <unicast|broadcast|multi-cast>

Permite especificar que tipo de pacote queremos filtrar.

2.3.1.7. recent

Esse é um filtro especialmente útil e complexo. Ele permite a criação de uma lista de IPs baseados emuma condição, essa lista pode então ser usar para filtragem. É possível por exemplo criar uma lista daspessoas que estão tentando acessar a porta 139 de seu firewall, e então usar essa lista para criar umaoutra 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çõesdesse 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 alista 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 naverificaçã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

Firewall

51

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ãosendo monitoradas pelo nosso firewall, permitindo sabermos se um dado pacote re#esenta uma novaconexão, se ele já faz parte de uma conexão existente ou até mesmo sabermos se ele esta relacionadoa 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 tercuidado 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 é especialmenteverdade 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, masela faz uma verificação mais elaborada, baseada no estado das diversas conexõesmonitoradas pelo firewall.

A parte que fala sobre recriar uma conexão, é de extrema importância, e por vezespassa desapercebida para a maioria dos usuários. Para o netfilter um pacote somentecom a flag ACK habilitada também é considerado como uma nova conexão. Issoacontece 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 (ouseja, não é necessário que o three way handshake ocorra.

Por exemplo, numa situação onde o firewall tem de ser reinicaido e haviam doishosts que já estavam com uma conexão estabelecida, os hosts não precisam saberque o firewall parou de funcionar por alguns minutos. Para eles, desde que o periodode 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 haviampara anteriormente.

O ponto negativo dessa abordagem é que ela permite que o firewall possua umaabertura para ACK scans. É possível evitar esse tipo de scans usando a opção detcpflags, para verificar se um pacote possui comente o bit ACK habilitado. Poroutro lado, fazendo isso nós perderemos aoportunidade de reestabelecimento deconexões qunado o firewall apresentar algum problema. Devemos fazer então aescolha 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 osbits 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 praconsiderar 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 pacotesrelacionados a novas conexões pacotes SYN/FIN não vão ser pegos por ela. Aoinvés disso elas vão ser verificadas pelas regras seguintes, podendo então o pacoteser aceito pelo firewall. Com isso uma nova conexão vai ser aberta, mesmo quandonós pensavamos que isso não poderia ocorrer.

Esse é o design padrão do netfilter já a muito tempo. Os desenvolvedores estãocompletamente cioentes dessa “peculiaridade”, e eles não tem intenção de mudar

Firewall

52

esse modo de funcionamento., devendo os usuários do netfilter/iptables estaremcientes disso e escreverem suas regras de forma a não cairem em problemas comoesses. Uma solução para a questão do SYN/FIN é adicionar uma regra que rejeitapacotes invalidos logo no começo da chain. Além disso o uso de uma política denegue tudo e só depois libere pode ajudar a diminuir a probabilidade de seu firewallcair numa situação dessas.

ESTA-BLISHED

Esse estado é alcançado quando a conexão é aceita pelos dois hosts, isso ocorre natroca 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 normalde uma conexão TCP, já o segundo ocorre quando o firewall teve de ser reiniciadoe dois hosts já estavam no meio de um sessão. Esse comportamente foi discutidoem detalhes na sessão anterior.

Pacotes que estão nesse estado geralmente podem ser considerados seguros, já quepara 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 algumarelação com uma conexão já existente. Um exemplo desse tipo de conexão é aconexã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 cadaprotocolo 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 nenhumaconexã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 tentativasde portscan ou de exploração de falhas de implementação de algum protocolo derede. Recomendo fortemente que uma primeira regra em qualquer firewall sejadescartar pacotes invalidos.

2.3.1.9. tcp

Oferece diversas extensões que podem ser usadas para verificação de informações disponíveis nocabeç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-ce-port [!]porta[:porta], --dport[!]porta[:porta], --destination-port[!]porta[:porta]

Serve para verificar a porta de origem/destino de um dado pa-cote. Pode-se também selecionar um intervalo de portas, usan-do a sintaxe de_porta:ate_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 mapeamentode rede.

Opções do Match TTL

--ttl-eq <ttl> Verifica se o campo TTL possui exatamente o valor especificado.

Firewall

53

--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 únicaopção que podemos verificar é a porta de origem e destino.

Opções do match UDP

--source-port, --destination port-port [!] porta[:porta]

Serve para especificar a porta de origem/destino de um pacoteUDP. É possível especificar um intervalo de portas separandoa porta inicial e a final com dois pontos. O uso da exclamaçãoantes da especificação da porta serve para verificar se o pacotenão está destinado à porta especificada.

2.3.2. Alvos

2.4. Trabalhando com a tabela NAT

2.5. Trabalhando com tabela MangleA 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 noCapítulo 1, Seção 2, um atacante pode usar informações de TOS e TTL para determinar qual sistemaoperacional está rodando na máquina alvo. O que nós podemos fazer aqui é mudar informações sobreTTL e TOS de todos os pacotes saindo de nossa rede, de tal forma que eles não permitam a um atacanteidentificar nosso sistema operacional.

É possível alterar o campo TOS usando um dos seguintes alvos: ECN, DSCP ou TOS. Essas opçõessão necessárias graças as diversas interpretações que já foram dadas a esse campo. Cada alvo dessesuporta uma série de opções. É recomendado a leitura do manual do iptables para conhecer todasas opções. Por exemplo, caso quisessemos zerar todos os bits do campo TOS (padrão em sistemasoperacionais Windows), poderiamos usar o seguinte comando:

iptables -t mangle -A POSTROUTING -j TOS --set-tos 0iptables -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 seguintesopçõ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ãode máquinas Windows), bastariamos usar o seguinte comando:

Firewall

54

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 paraimpedir 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 umdado pacote seja encontrada, ainda assim todas as outras regras vão ser analisadas. Isso é necessáriopois as vezes queremos fazer mais de uma alteração em um pacote. Essa é uma das razões que tornamessa tabela uma lugar inapropriado para a colocação de filtros de pacotes. Outra forte razão é que essenã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 IptablesAgora que já conhecemos toda a sintaxe do iptables e sabemos o que tem para nos oferecer podemosestudar algumas das possibilidades que temos a nossa disposição. O objetivo dessa seção é mostrarcomo 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 ataquesde 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 ACCEPTroot@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 ACCEPTroot@router:~# iptables -A INPUT -p tcp --syn –j DROP

3. ISA

55

Capítulo 10. VPN1. Introdução

2. OpenVPN

3. RRAS

4. ISA

56

Capítulo 11. Proxies1. Introdução

2. Squid

3. Dans Guardian

4. ISA

57

Capítulo 12. Criptografia1. 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

Parte IV. Exploração de aplicações

59

Capítulo 13. Vulnerabilidades na Web1. 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

60

Capítulo 14. Explorandovulnerabilidades dos sistemas1. Introdução

1.1. Metasploit

61

Capítulo 15. Quebrando senhas1. 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

Parte V. Apêndices

63

Apêndice A. Cabeçalhos dos pacotes

64

Apêndice B. GNU FreeDocumentation 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 licensedocument, but changing it is not allowed.

0. PREAMBLEThe 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, withor without modifying it, either commercially or noncommercially. Secondarily, this License preservesfor the author and publisher a way to get credit for their work, while not being considered responsiblefor 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 copyleftlicense designed for free software.

We have designed this License in order to use it for manuals for free software, because free softwareneeds free documentation: a free program should come with manuals providing the same freedomsthat the software does. But this License is not limited to software manuals; it can be used for anytextual work, regardless of subject matter or whether it is published as a printed book. We recommendthis License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONSThis License applies to any manual or other work, in any medium, that contains a notice placed bythe copyright holder saying it can be distributed under the terms of this License. Such a notice grantsa world-wide, royalty-free license, unlimited in duration, to use that work under the conditions statedherein. The "Document", below, refers to any such manual or work. Any member of the public is alicensee, and is addressed as "you". You accept the license if you copy, modify or distribute the workin 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 dealsexclusively with the relationship of the publishers or authors of the Document to the Document'soverall subject (or to related matters) and contains nothing that could fall directly within that overallsubject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may notexplain any mathematics.) The relationship could be a matter of historical connection with the subjector with related matters, or of legal, commercial, philosophical, ethical or political position regardingthem.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those ofInvariant Sections, in the notice that says that the Document is released under this License. If a sectiondoes 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 InvariantSections 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-CoverText may be at most 5 words, and a Back-Cover Text may be at most 25 words.

GNU Free Documentation License

65

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 (fordrawings) some widely available drawing editor, and that is suitable for input to text formatters or forautomatic translation to a variety of formats suitable for input to text formatters. A copy made in anotherwise Transparent file format whose markup, or absence of markup, has been arranged to thwartor 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, Texinfoinput 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 canbe read and edited only by proprietary word processors, SGML or XML for which the DTD and/orprocessing tools are not generally available, and the machine-generated HTML, PostScript or PDFproduced 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 areneeded to hold, legibly, the material this License requires to appear in the title page. For works informats which do not have any title page as such, "Title Page" means the text near the most prominentappearance 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 XYZor contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZstands 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 Licenseapplies to the Document. These Warranty Disclaimers are considered to be included by reference inthis License, but only as regards disclaiming warranties: any other implication that these WarrantyDisclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYINGYou 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 tothe Document are reproduced in all copies, and that you add no other conditions whatsoever to those ofthis License. You may not use technical measures to obstruct or control the reading or further copyingof 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 displaycopies.

3. COPYING IN QUANTITYIf 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 enclosethe copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on thefront cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identifyyou as the publisher of these copies. The front cover must present the full title with all words of thetitle equally prominent and visible. You may add other material on the covers in addition. Copyingwith changes limited to the covers, as long as they preserve the title of the Document and satisfy theseconditions, 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 oneslisted (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.


66

If you publish or distribute Opaque copies of the Document numbering more than 100, you must eitherinclude a machine-readable Transparent copy along with each Opaque copy, or state in or with eachOpaque copy a computer-network location from which the general network-using public has accessto 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 youbegin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thusaccessible 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 redistributingany large number of copies, to give them a chance to provide you with an updated version of theDocument.

4. MODIFICATIONSYou may copy and distribute a Modified Version of the Document under the conditions of sections2 and 3 above, provided that you release the Modified Version under precisely this License, with theModified Version filling the role of the Document, thus licensing distribution and modification ofthe Modified Version to whoever possesses a copy of it. In addition, you must do these things in theModified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, andfrom those of previous versions (which should, if there were any, be listed in the History sectionof the Document). You may use the same title as a previous version if the original publisher of thatversion gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship ofthe modifications in the Modified Version, together with at least five of the principal authors ofthe Document (all of its principal authors, if it has fewer than five), unless they release you fromthis 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 usethe 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 givenin 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 thetitle, year, new authors, and publisher of the Modified Version as given on the Title Page. If thereis no section Entitled "History" in the Document, create one stating the title, year, authors, andpublisher of the Document as given on its Title Page, then add an item describing the ModifiedVersion as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copyof the Document, and likewise the network locations given in the Document for previous versionsit was based on. These may be placed in the "History" section. You may omit a network location fora work that was published at least four years before the Document itself, or if the original publisherof 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 acknowledgementsand/or dedications given therein.


67

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Sectionnumbers 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 ModifiedVersion.

N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with anyInvariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as SecondarySections and contain no material copied from the Document, you may at your option designate someor all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in theModified 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 ofyour Modified Version by various parties--for example, statements of peer review or that the text hasbeen 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 asa Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage ofFront-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 byyou 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 theold one.

The author(s) and publisher(s) of the Document do not by this License give permission to use theirnames for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTSYou may combine the Document with other documents released under this License, under the termsdefined in section 4 above for modified versions, provided that you include in the combination all of theInvariant Sections of all of the original documents, unmodified, and list them all as Invariant Sectionsof 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, inparentheses, the name of the original author or publisher of that section if known, or else a uniquenumber. Make the same adjustment to the section titles in the list of Invariant Sections in the licensenotice 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 DOCUMENTSYou may make a collection consisting of the Document and other documents released under thisLicense, and replace the individual copies of this License in the various documents with a singlecopy that is included in the collection, provided that you follow the rules of this License for verbatimcopying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under thisLicense, provided you insert a copy of this License into the extracted document, and follow this Licensein all other respects regarding verbatim copying of that document.


68

7. AGGREGATION WITH INDEPENDENTWORKS

A compilation of the Document or its derivatives with other separate and independent documents orworks, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyrightresulting from the compilation is not used to limit the legal rights of the compilation's users beyondwhat 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 theDocument.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if theDocument is less than one half of the entire aggregate, the Document's Cover Texts may be placedon covers that bracket the Document within the aggregate, or the electronic equivalent of covers ifthe Document is in electronic form. Otherwise they must appear on printed covers that bracket thewhole aggregate.

8. TRANSLATIONTranslation is considered a kind of modification, so you may distribute translations of the Documentunder the terms of section 4. Replacing Invariant Sections with translations requires special permissionfrom their copyright holders, but you may include translations of some or all Invariant Sections inaddition to the original versions of these Invariant Sections. You may include a translation of thisLicense, and all the license notices in the Document, and any Warranty Disclaimers, provided that youalso include the original English version of this License and the original versions of those notices anddisclaimers. In case of a disagreement between the translation and the original version of this Licenseor 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. TERMINATIONYou may not copy, modify, sublicense, or distribute the Document except as expressly provided forunder 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 receivedcopies, or rights, from you under this License will not have their licenses terminated so long as suchparties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSEThe Free Software Foundation may publish new, revised versions of the GNU Free DocumentationLicense from time to time. Such new versions will be similar in spirit to the present version, but maydiffer 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 thata particular numbered version of this License "or any later version" applies to it, you have the optionof following the terms and conditions either of that specified version or of any later version that hasbeen published (not as a draft) by the Free Software Foundation. If the Document does not specifya version number of this License, you may choose any version ever published (not as a draft) by theFree Software Foundation.

http://www.gnu.org/copyleft/


69

ADDENDUM: How to use this License foryour documents

To use this License in a document you have written, include a copy of the License in the documentand 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 theterms of the GNU Free Documentation License, Version 1.2 or any later versionpublished 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 thesection 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 Textsbeing LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, mergethose 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.

Seguranca_de_Redes

Documents

Transcript of Seguranca_de_Redes