Segurança em Redes Informáticas - 6.ª Edição Atualizada e Aumentada by Grupo Lidel

EDIÇÃO FCA – Editora de Informática Av. Praia da Vitória, 14 A – 1000-247 Lisboa Tel: +351 213 511 448 fca@fca.pt www.fca.pt DISTRIBUIÇÃO Lidel – Edições Técnicas, Lda. Rua D. Estefânia, 183, R/C Dto. – 1049-057 Lisboa Tel: +351 213 511 448 lidel@lidel.pt www.lidel.pt LIVRARIA Av. Praia da Vitória, 14 A – 1000-247 Lisboa Tel: +351 213 541 448 livraria@lidel.pt Copyright © 2021, FCA – Editora de Informática ® Marca registada da FCA PACTOR Editores, Lda ISBN edição impressa: 978-972-722-923-9 3.ª edição atualizada e aumentada: janeiro 2010 6.ª edição atualizada e aumentada impressa: outubro 2021 Impressão e acabamento: CAFILESA – Soluções Gráficas, Lda. – Venda do Pinheiro Depósito Legal n.º 489921/21 Capa: José M. Ferrão – Look-Ahead Todos os nossos livros passam por um rigoroso controlo de qualidade, no entanto aconselhamos a consulta periódica do nosso site (www.fca.pt) para fazer o download de eventuais correções. Não nos responsabilizamos por desatualizações das hiperligações presentes nesta obra, que foram verificadas à data de publicação da mesma. Os nomes comerciais referenciados neste livro têm patente registada. _____________________________________________________________________________________ Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em parte, por qualquer processo eletrónico, mecânico, fotocópia, digitalização, gravação, sistema de armazenamento e disponibilização de informação, sítio Web, blogue ou outros, sem prévia autorização escrita da Editora, exceto o permitido pelo CDADC, em termos de cópia privada pela AGECOP – Associação para a Gestão da Cópia Privada, através do pagamento das respetivas taxas.

Índice Nota do Autor 1

Introdução

1.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1

Defesa contra catástrofes físicas . . . . . . . . . . . . . . . . . . . . . .

1.1.2

Defesa contra faltas ou falhas previsíveis . . . . . . . . . . . . . . . . .

1.1.3

Defesa contra atividades não autorizadas . . . . . . . . . . . . . . . .

Vulnerabilidades, ataques, riscos e defesas . . . . . . . . . . . . . . . . . . . .

1.2.1

Complexidade do problema . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2

Atitudes realistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

Defesa de perímetro vs. defesa em profundidade . . . . . . . . . . . . .

Políticas vs. mecanismos de segurança . . . . . . . . . . . . . . . . . . . . . .

1.2

1.3

1.4

1.3.1

Definição de políticas

1.3.2

Padrão ISO 17799 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.3

Escolha de mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.4

Segurança pela ocultação (security by obscurity) . . . . . . . . . . . . 16

1.5

. . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Segurança em sistemas distribuídos . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4.1

xix

Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Estrutura do livro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Criptografia

2.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2

Criptografia e criptanálise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3

Evolução da tecnologia de cifra . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4

Tipos de cifra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.4.1

Cifras monoalfabéticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.2

Cifras polialfabéticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Segurança em Redes Informáticas

2.5

2.4.2.2

Teste de Kasiski . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5.1

Abordagens teóricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5.2

Abordagens práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.2.1

Difusão e confusão . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5.2.2

Boas-práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Cifras contínuas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Cifras modernas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.6.1

2.6.2

2.7

Índice de coincidência . . . . . . . . . . . . . . . . . . . . . . 31

Abordagens à criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5.3 2.6

2.4.2.1

Modo de operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.6.1.1

Cifras por blocos . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6.1.2

Cifras contínuas . . . . . . . . . . . . . . . . . . . . . . . . . 38

Tipo de chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.6.2.1

Cifras simétricas . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6.2.2

Cifras assimétricas . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6.2.3

Cifras mistas ou híbridas . . . . . . . . . . . . . . . . . . . . 40

Exemplos de cifras modernas . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.1

Cifras simétricas por blocos . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7.1.1

2.7.2

Cifras simétricas contínuas . . . . . . . . . . . . . . . . . . . . . . . . 45 2.7.2.1

2.7.3

Caso de estudo: DES . . . . . . . . . . . . . . . . . . . . . . 43

Caso de estudo: A5 . . . . . . . . . . . . . . . . . . . . . . . 46

Cifras assimétricas (por blocos) . . . . . . . . . . . . . . . . . . . . . . 48 2.7.3.1

Caso de estudo: Algoritmo de Diffie-Hellman . . . . . . . . . 50

2.7.3.2

Caso de estudo: RSA . . . . . . . . . . . . . . . . . . . . . . 51

2.7.3.3

Caso de estudo: ElGamal . . . . . . . . . . . . . . . . . . . . 52

2.7.3.4

Caso de estudo: Curvas elípticas . . . . . . . . . . . . . . . . 53 2.7.3.4.1

2.8

Aplicação das cifras por blocos: Modos de cifra . . . . . . . . . . . . . . . . . 56 2.8.1

Escolha de uma curva elíptica . . . . . . . . . . . . 55

ECB e CBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Índice 2.8.2

OFB e CFB de n bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.8.3

CTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.8.4

Comparação dos modos de cifra . . . . . . . . . . . . . . . . . . . . . . 60

2.8.5

Tratamento de sub-blocos . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.8.6

Reforço da segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.8.7

2.9

2.8.6.1

Cifra múltipla . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.8.6.2

Branqueamento (whitening) . . . . . . . . . . . . . . . . . . . 65

Padrão PKCS #1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.8.7.1

RSAES-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . . . 66

2.8.7.2

RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Funções de síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.10 Autenticadores de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.10.1 Autenticadores de mensagens (MAC) . . . . . . . . . . . . . . . . . . . 72 2.10.1.1 Caso de estudo: CBC-MAC . . . . . . . . . . . . . . . . . . . 73 2.10.1.2 Caso de estudo: DES-MAC . . . . . . . . . . . . . . . . . . . 73 2.10.1.3 Caso de estudo: Keyed-MD5 . . . . . . . . . . . . . . . . . . 74 2.10.1.4 Caso de estudo: HMAC . . . . . . . . . . . . . . . . . . . . . 74 2.10.2 Cifra autenticada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.10.2.1 Caso de estudo: EPBC . . . . . . . . . . . . . . . . . . . . . 76 2.10.2.2 Caso de estudo: GCM . . . . . . . . . . . . . . . . . . . . . . 76 2.10.2.3 Caso de estudo: CCM . . . . . . . . . . . . . . . . . . . . . . 78 2.10.3 Assinaturas digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.10.3.1 Caso de estudo: ElGamal . . . . . . . . . . . . . . . . . . . . 81 2.10.3.2 Caso de estudo: DSS, DSA e ECDSA . . . . . . . . . . . . . 82 2.10.3.3 Preparação de assinaturas RSA com apêndice . . . . . . . . 83 2.10.4 Assinaturas às cegas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3

Gestão de Chaves Públicas

3.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.2

Geração, salvaguarda e uso das chaves privadas . . . . . . . . . . . . . . . . . 87 © FCA – EDITORA DE INFORMÁTICA

vii

Segurança em Redes Informáticas

3.3

3.4

3.2.1

Smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.2.2

Padrão PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.2.3

CryptoAPI (Cryptographic Application Programming Interface) . . . . 90

Distribuição de chaves públicas . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.3.1

Distribuição manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.3.2

Distribuição embebida . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.3.3

Distribuição interativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.3.4

Distribuição ad hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Certificação digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3.4.1

Estrutura dos certificados digitais . . . . . . . . . . . . . . . . . . . . . 93

3.4.2

Cadeias de certificação . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.4.3

Gestão de certificados autocertificados . . . . . . . . . . . . . . . . . . 95

3.4.4

Modelos de certificação . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.4.5

3.5

3.6

Monopólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.4.4.2

Oligarquia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.4.4.3

Certificação cruzada . . . . . . . . . . . . . . . . . . . . . . . 99

3.4.4.4

Malha (mesh) . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.4.4.5

Anárquico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Infraestruturas de gestão de chaves públicas . . . . . . . . . . . . . . . 101 3.4.5.1

CRL (Certificate Revocation List) . . . . . . . . . . . . . . . 102

3.4.5.2

OCSP (Online Certificate Status Protocol) . . . . . . . . . . 104

Caso de estudo: Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . . . . . 104 3.5.1

Autenticação com o smartcard do Cartão de Cidadão

3.5.2

Assinaturas digitais com o smartcard do Cartão de Cidadão . . . . . . 107

3.5.3

Hierarquias de certificação do Cartão de Cidadão . . . . . . . . . . . . 108

3.5.4

Segurança oferecida pelo Cartão de Cidadão . . . . . . . . . . . . . . . 111

3.5.5

Middleware do Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . 112

. . . . . . . . . 107

Caso de estudo: Chave Móvel Digital . . . . . . . . . . . . . . . . . . . . . . . 113 3.6.1

viii

3.4.4.1

Middleware da CMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Índice 3.7

Caso de estudo: PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.7.1

Chaveiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

3.7.2

Geração de um par de chaves . . . . . . . . . . . . . . . . . . . . . . . 116

3.7.3

Gestão de chaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.7.3.1

Divulgação de chaves públicas . . . . . . . . . . . . . . . . . 117

3.7.3.2

Importação de chaves públicas . . . . . . . . . . . . . . . . . 118

3.7.3.3

Certificação de chaves públicas . . . . . . . . . . . . . . . . . 118

3.7.4

Cadeias de certificação . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

3.7.5

Revogação de pares de chaves . . . . . . . . . . . . . . . . . . . . . . . 121

3.7.6

Cifra e decifra de conteúdos . . . . . . . . . . . . . . . . . . . . . . . . 121

3.7.7

Assinatura de conteúdos . . . . . . . . . . . . . . . . . . . . . . . . . . 122

3.7.8

Cifra, decifra e assinatura de conteúdos . . . . . . . . . . . . . . . . . 123

Vulnerabilidades em Máquinas de Sistemas Distribuídos

125

4.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.2

Detetores de vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 4.2.1

4.2.2

4.2.3

Identificação de sistemas operativos . . . . . . . . . . . . . . . . . . . 125 4.2.1.1

Flâmulas (banners) . . . . . . . . . . . . . . . . . . . . . . . 126

4.2.1.2

Impressão digital da pilha de protocolos IP (IP fingerprinting)126

4.2.1.3

Caso de estudo: Nmap . . . . . . . . . . . . . . . . . . . . . . 127

4.2.1.4

Caso de estudo: RING . . . . . . . . . . . . . . . . . . . . . . 130

Inventariação de serviços

. . . . . . . . . . . . . . . . . . . . . . . . . 131

4.2.2.1

Portos TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.2.2.2

Mediação com servidores FTP . . . . . . . . . . . . . . . . . 132

4.2.2.3

Mediação com oráculos (idle scan) . . . . . . . . . . . . . . . 133

4.2.2.4

Portos UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

4.2.2.5

Portos de transporte não fixos . . . . . . . . . . . . . . . . . 134

4.2.2.6

Reconhecimento de versões de servidores . . . . . . . . . . . 135

Inventariação de deficiências de administração . . . . . . . . . . . . . . 136 4.2.3.1

Caso de estudo: OpenVAS e Nessus . . . . . . . . . . . . . . 137 © FCA – EDITORA DE INFORMÁTICA

Segurança em Redes Informáticas

4.3

4.4

Cenários absurdos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 4.3.1

Teardrop attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

4.3.2

Land attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

4.3.3

Ataque ECHO-CHARGEN . . . . . . . . . . . . . . . . . . . . . . . . 141

4.3.4

Sobrefragmentação de datagramas IP: Ping-of-Death . . . . . . . . . . 141

4.3.5

Excesso de meias-ligações TCP: SYN flooding attack . . . . . . . . . . 142

Problemas de realização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 4.4.1

Ataque de esmagamento da pilha (stack smashing attack) . . . . . . . 147

4.4.2

Ataque com sequências de formatação (format string attack) . . . . . 150

Vulnerabilidades em Redes Locais e de Grande Escala

153

5.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

5.2

Levantamento de informação arquitetural . . . . . . . . . . . . . . . . . . . . 153

5.3

Tradução de nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5.4

5.3.1

Uso de nomes DNS enganadores . . . . . . . . . . . . . . . . . . . . . 155

5.3.2

Resolução errada de nomes DNS (DNS spoofing) . . . . . . . . . . . . 156

5.3.3

Obtenção errada de endereços MAC (MAC spoofing) . . . . . . . . . . 160

Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 5.4.1

Captura de senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.4.2

Captura de dados em ligações sem fios . . . . . . . . . . . . . . . . . . 166 5.4.2.1

5.5

5.6 x

Caso de estudo: 802.11 WLAN e WEP . . . . . . . . . . . . 166

Autenticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 5.5.1

Pedidos fraudulentos sobre UDP . . . . . . . . . . . . . . . . . . . . . 168

5.5.2

Iniciação fraudulenta de ligações TCP . . . . . . . . . . . . . . . . . . 168

5.5.3

Reencaminhamento de tráfego IP . . . . . . . . . . . . . . . . . . . . . 169 5.5.3.1

Datagramas ICMP Redirect . . . . . . . . . . . . . . . . . . . 169

5.5.3.2

Opção Source Route do IP . . . . . . . . . . . . . . . . . . . 169

5.5.4

Sequestro de ligações TCP (TCP hijacking) . . . . . . . . . . . . . . . 170

5.5.5

Problemas de autoria e integridade em correio eletrónico . . . . . . . . 173

Prestação de serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 © FCA – EDITORA DE INFORMÁTICA

Índice 5.6.1

Amplificação de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . 175

5.6.2

Caso de estudo: Ataques Smurf e Fraggle . . . . . . . . . . . . . . . . 175

5.6.3

Caso de estudo: Amplificação de tráfego com servidores . . . . . . . . 177

5.6.4

Ataques ao serviço DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 179

6 Firewalls

181

6.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.2

Arquitetura de uma firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 6.2.1

Estrutura básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

6.2.2

Firewalls pessoais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

6.2.3

Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

6.2.4

DMZ (zona desmilitarizada) . . . . . . . . . . . . . . . . . . . . . . . . 185

6.2.5

Barreiras múltiplas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

6.2.6

Localização de serviços públicos . . . . . . . . . . . . . . . . . . . . . . 187

6.2.7

Tradução de endereços (NAT) . . . . . . . . . . . . . . . . . . . . . . . 188

6.2.8 6.3

IP masquerading . . . . . . . . . . . . . . . . . . . . . . . . . 188

6.2.7.2

Port forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 189

Encapsulamento (tunneling) . . . . . . . . . . . . . . . . . . . . . . . . 189

Modelo de intervenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 6.3.1

6.4

6.2.7.1

Filtro de datagramas (packet filter) . . . . . . . . . . . . . . . . . . . . 190 6.3.1.1

Exemplos de filtragem . . . . . . . . . . . . . . . . . . . . . . 190

6.3.1.2

Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.3.1.3

Aspetos operacionais . . . . . . . . . . . . . . . . . . . . . . 193

6.3.2

Filtro de circuitos (circuit gateway) . . . . . . . . . . . . . . . . . . . . 194

6.3.3

Filtro aplicacional (application gateway) . . . . . . . . . . . . . . . . . 197 6.3.3.1

Controlo de acesso de utentes . . . . . . . . . . . . . . . . . . 198

6.3.3.2

Análise e alteração de conteúdos . . . . . . . . . . . . . . . . 198

6.3.3.3

Registo pormenorizado . . . . . . . . . . . . . . . . . . . . . 199

6.3.3.4

Representação . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Serviços oferecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 © FCA – EDITORA DE INFORMÁTICA

Segurança em Redes Informáticas

6.5

Autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

6.4.2

Redirecionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

6.4.3

Controlo de operações e conteúdos . . . . . . . . . . . . . . . . . . . . 201

6.4.4

Comunicação segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

6.4.5

Proteção face a ataques DoS ou de reconhecimento de sistemas . . . . 202

Topologias elementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 6.5.1

Gateway simples (dual-homed gateway) . . . . . . . . . . . . . . . . . 204

6.5.2

Máquina escondida (screened host) . . . . . . . . . . . . . . . . . . . . 205

6.5.3

Sub-rede escondida (screened subnet) . . . . . . . . . . . . . . . . . . . 206

6.6

Caso de estudo: Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

6.7

Caso de estudo: Sistemas MS Windows . . . . . . . . . . . . . . . . . . . . . . 209

Sistemas de Deteção de Intrusões 7.1

6.4.1

213

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 7.1.1

Intrusões e sua deteção . . . . . . . . . . . . . . . . . . . . . . . . . . 214

7.1.2

Perfil de uma intrusão . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

7.1.3

Perfil da defesa contra intrusões

. . . . . . . . . . . . . . . . . . . . . 215

7.2

Arquitetura dos IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

7.3

Classificação dos IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 7.3.1

Método de deteção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

7.3.2

Fonte de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

7.3.3

Instante de deteção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

7.3.4

Reatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

7.3.5

Tipo de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

7.4

Limitações dos IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

7.5

Caso de estudo: Tripwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

7.6

Caso de estudo: Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

7.7

Caso de estudo: AntiSniff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Redes Privadas Virtuais xii

229

Índice 8.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

8.2

Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

8.3

Chaves de sessão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 8.3.1

Algoritmo de Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . . 231

8.4

Tipos de VPN

8.5

Tecnologias usadas pelas VPN

8.6

Caso de estudo: VPN SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 8.6.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Túneis seguros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 8.6.1.1

Túneis de saída

. . . . . . . . . . . . . . . . . . . . . . . . . 235

8.6.1.2

Túneis de entrada . . . . . . . . . . . . . . . . . . . . . . . . 237

8.6.1.3

Túneis dinâmicos

. . . . . . . . . . . . . . . . . . . . . . . . 237

8.6.2

Autenticação e autorização . . . . . . . . . . . . . . . . . . . . . . . . 238

8.6.3

Especificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

8.6.4

Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

8.7

Caso de estudo: VPN SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 239

8.8

Caso de estudo: VPN IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

8.9

8.8.1

Associações de segurança . . . . . . . . . . . . . . . . . . . . . . . . . 242

8.8.2

Negociação e instalação das associações de segurança . . . . . . . . . . 242

8.8.3

Afetação das associações de segurança à comunicação . . . . . . . . . 243

8.8.4

Modo de transporte e modo de túnel . . . . . . . . . . . . . . . . . . . 244

8.8.5

Mecanismos AH e ESP

8.8.6

Utilização típica numa VPN . . . . . . . . . . . . . . . . . . . . . . . . 246

. . . . . . . . . . . . . . . . . . . . . . . . . . 244

Caso de estudo: VPN PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 8.9.1

Comunicação sobre PPTP . . . . . . . . . . . . . . . . . . . . . . . . . 248

8.9.2

Segurança numa interação PPTP . . . . . . . . . . . . . . . . . . . . . 251

8.9.3

8.9.2.1

Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

8.9.2.2

MPPE (Microsoft Point-to-Point Encryption) . . . . . . . . 253

Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

8.10 Caso de estudo: VPN L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

xiii

Segurança em Redes Informáticas

8.10.1 Comunicação sobre L2TP . . . . . . . . . . . . . . . . . . . . . . . . . 255 8.10.2 Segurança numa interação L2TP . . . . . . . . . . . . . . . . . . . . . 256 8.11 Caso de estudo: OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 8.12 Casos de estudo: PPP sobre SSL ou sobre SSH . . . . . . . . . . . . . . . . . 257 9

Segurança em Redes Sem Fios 802.11 (WLAN ou Wi-Fi)

259

9.1

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

9.2

Arquitetura de uma rede 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . 260 9.2.1

Identificadores de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

9.2.2

Comunicação em redes estruturadas . . . . . . . . . . . . . . . . . . . 260

9.2.3

Localização de redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

9.2.4

Associação a redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

9.3

Visão geral da segurança em redes estruturadas . . . . . . . . . . . . . . . . . 264

9.4

WEP (Wired Equivalent Privacy) . . . . . . . . . . . . . . . . . . . . . . . . . 266

9.5

9.6

9.4.1

Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

9.4.2

Confidencialidade e controlo de integridade . . . . . . . . . . . . . . . 268

9.4.3

Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

9.4.4

Algumas soluções consideradas . . . . . . . . . . . . . . . . . . . . . . 274

Evolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 9.5.1

WPA (Wi-Fi Protected Access) . . . . . . . . . . . . . . . . . . . . . . 275

9.5.2

802.11i (ou WPA2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

9.5.3

Alterações nas tramas 802.11 . . . . . . . . . . . . . . . . . . . . . . . 276

TKIP (Temporal Key Integrity Protocol) . . . . . . . . . . . . . . . . . . . . . 277 9.6.1

Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

9.6.2

Controlo de integridade . . . . . . . . . . . . . . . . . . . . . . . . . . 280

9.7

AES-CCMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

9.8

802.1X (Port-based Authentication Protocol) . . . . . . . . . . . . . . . . . . . 284

xiv

9.8.1

Interlocutores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

9.8.2

Portos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

9.8.3

Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Índice

9.9

9.8.3.1

Primeira etapa: Descoberta e associação 802.11 . . . . . . . . 288

9.8.3.2

Segunda etapa: Autenticação EAP . . . . . . . . . . . . . . . 288

9.8.3.3

Terceira etapa: Acordo em quatro passos . . . . . . . . . . . 289

9.8.4

Simplificação para ambientes SOHO . . . . . . . . . . . . . . . . . . . 289

9.8.5

Chaves de chave de sessão . . . . . . . . . . . . . . . . . . . . . . . . . 291

9.8.6

Protocolo de acordo em quatro passos . . . . . . . . . . . . . . . . . . 293

9.8.7

Protocolo de acordo de chaves de grupo . . . . . . . . . . . . . . . . . 294

EAP (Extensible Authentication Protocol) . . . . . . . . . . . . . . . . . . . . 295 9.9.1

Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

9.9.2

EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

9.9.3

EAP-TTLS (EAP Tunneled TLS) . . . . . . . . . . . . . . . . . . . . 297

9.9.4

PEAP (Protected EAP) . . . . . . . . . . . . . . . . . . . . . . . . . . 298

9.9.5

EAP-PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

9.9.6

EAP-SIM e EAP-AKA

. . . . . . . . . . . . . . . . . . . . . . . . . . 300

9.10 Ataques à prestação de serviço (DoS) . . . . . . . . . . . . . . . . . . . . . . . 301 9.10.1 Ataques usando tramas de gestão . . . . . . . . . . . . . . . . . . . . . 301 9.10.1.1 802.11w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 9.10.2 Outros ataques DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 10 Protocolos de Autenticação

305

10.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 10.2 Caracterização dos protocolos de autenticação . . . . . . . . . . . . . . . . . . 306 10.2.1 Elemento de prova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 10.2.2 Ataques com dicionários . . . . . . . . . . . . . . . . . . . . . . . . . . 307 10.2.2.1 Medidas defensivas . . . . . . . . . . . . . . . . . . . . . . . . 308 10.2.3 Apresentação da prova . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 10.2.3.1 Desafio-resposta com funções invertíveis . . . . . . . . . . . . 309 10.2.3.2 Desafio-resposta com funções não invertíveis . . . . . . . . . 310 10.2.3.3 Frescura das respostas . . . . . . . . . . . . . . . . . . . . . . 311 10.2.3.4 Senhas descartáveis . . . . . . . . . . . . . . . . . . . . . . . 312 © FCA – EDITORA DE INFORMÁTICA

Segurança em Redes Informáticas

10.2.4 Autenticação mútua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 10.2.4.1 Ataques por reflexão . . . . . . . . . . . . . . . . . . . . . . . 314 10.2.4.2 Medidas defensivas contra ataques DoS . . . . . . . . . . . . 315 10.2.4.3 Medidas defensivas contra ataques com dicionários . . . . . . 316 10.2.5 Distribuição de chaves de sessão . . . . . . . . . . . . . . . . . . . . . 317 10.2.6 Autenticação mediada por entidade terceira confiável . . . . . . . . . . 317 10.2.7 Autenticação indireta . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 10.2.8 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 10.3 Autenticação de pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 10.3.1 Autenticação com senha memorizada . . . . . . . . . . . . . . . . . . . 322 10.3.1.1 Caso de estudo: Sistemas UNIX . . . . . . . . . . . . . . . . 322 10.3.1.2 Caso de estudo: Sistemas MS Windows . . . . . . . . . . . . 323 10.3.1.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 10.3.2 Autenticação com chave secreta partilhada . . . . . . . . . . . . . . . 324 10.3.2.1 Caso de estudo: Marcadores RFID . . . . . . . . . . . . . . . 324 10.3.2.2 Caso de estudo: Redes GSM . . . . . . . . . . . . . . . . . . 325 10.3.3 Autenticação com chave privada . . . . . . . . . . . . . . . . . . . . . 328 10.3.3.1 Caso de estudo: Cartão de Cidadão . . . . . . . . . . . . . . 329 10.3.3.2 Caso de estudo: Cliente SSH . . . . . . . . . . . . . . . . . . 329 10.3.3.3 Caso de estudo: Cliente SSL/TLS . . . . . . . . . . . . . . . 330 10.3.3.4 Caso de estudo: Cliente de aplicações Web com Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 10.3.4 Autenticação com senhas descartáveis . . . . . . . . . . . . . . . . . . 336 10.3.4.1 Caso de estudo: S/Key e OTP . . . . . . . . . . . . . . . . . 337 10.3.4.2 Caso de estudo: HOTP . . . . . . . . . . . . . . . . . . . . . 341 10.3.4.3 Caso de estudo: Chave Móvel Digital (CMD) . . . . . . . . . 342 10.3.4.4 Caso de estudo: RSA SecurID . . . . . . . . . . . . . . . . . 342 10.3.5 Autenticação biométrica . . . . . . . . . . . . . . . . . . . . . . . . . . 343 10.3.5.1 Autenticação vs. identificação . . . . . . . . . . . . . . . . . . 344 10.3.5.2 Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 xvi

Índice 10.3.5.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 10.3.5.4 Afinação e erros . . . . . . . . . . . . . . . . . . . . . . . . . 347 10.3.5.5 Vantagens e desvantagens . . . . . . . . . . . . . . . . . . . . 347 10.3.5.6 Exploração em sistemas de identificação nacionais . . . . . . 349 10.3.6 Metaprotocolos de autenticação . . . . . . . . . . . . . . . . . . . . . . 350 10.3.6.1 Caso de estudo: SAML Web Browser SSO Profile . . . . . . 351 10.3.6.2 Caso de estudo: OpenID . . . . . . . . . . . . . . . . . . . . 354 10.3.7 Middleware integrador . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 10.3.7.1 Caso de estudo: PAM . . . . . . . . . . . . . . . . . . . . . . 356 10.4 Autenticação de máquinas ou servidores . . . . . . . . . . . . . . . . . . . . . 358 10.4.1 Distribuição da chave pública da máquina ou do servidor . . . . . . . 358 10.5 Serviços de autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 10.5.1 Caso de estudo: Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 359 10.5.1.1 Protocolo Needham-Schroeder . . . . . . . . . . . . . . . . . 360 10.5.1.2 O KDC do Kerberos . . . . . . . . . . . . . . . . . . . . . . . 361 10.5.1.3 Principals, domínios e nomes . . . . . . . . . . . . . . . . . . 361 10.5.1.4 Credenciais do Kerberos . . . . . . . . . . . . . . . . . . . . . 362 10.5.1.5 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 10.5.1.6 Sincronização de relógios . . . . . . . . . . . . . . . . . . . . 365 10.5.1.7 Pré-autenticação e ataques com dicionários . . . . . . . . . . 365 10.5.1.8 Interligação entre domínios . . . . . . . . . . . . . . . . . . . 366 10.5.2 Caso de estudo: RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 366 10.5.2.1 Estrutura das mensagens RADIUS . . . . . . . . . . . . . . . 368 10.5.2.2 Níveis de indireção . . . . . . . . . . . . . . . . . . . . . . . . 370 10.5.2.3 Novos mecanismos de proteção . . . . . . . . . . . . . . . . . 370 10.5.2.4 Problemas de segurança do RADIUS . . . . . . . . . . . . . 373 10.5.3 Caso de estudo: Serviço Autenticação.Gov . . . . . . . . . . . . . . . . 374 10.5.3.1 Autenticação com o Cartão de Cidadão . . . . . . . . . . . . 377 10.5.3.2 Autenticação com a Chave Móvel Digital (CMD) . . . . . . . 378

xvii

Segurança em Redes Informáticas

10.5.3.3 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 11 Controlo de Acesso, Autorização e Delegação

383

11.1 Controlo de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 11.1.1 Gestão das ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 11.1.2 Gestão das capacidades . . . . . . . . . . . . . . . . . . . . . . . . . . 385 11.1.3 Políticas de controlo de acesso . . . . . . . . . . . . . . . . . . . . . . 385 11.1.3.1 Role-Based Access Control (RBAC) . . . . . . . . . . . . . . 386 11.1.3.2 Attribute-Based Access Control (ABAC) . . . . . . . . . . . . 390 11.2 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 11.2.1 Arquitetura do XACML . . . . . . . . . . . . . . . . . . . . . . . . . . 392 11.2.2 A linguagem de especificação de políticas . . . . . . . . . . . . . . . . 393 11.3 OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 11.3.1 Identificação e registo de aplicações . . . . . . . . . . . . . . . . . . . . 397 11.3.2 Serviço de autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 11.3.2.1 Authorization Endpoint . . . . . . . . . . . . . . . . . . . . . 398 11.3.2.2 Token Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 399 11.3.3 Tipos de aplicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 11.3.4 Fluxos de operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 11.3.4.1 Racional do nome dos fluxos . . . . . . . . . . . . . . . . . . 400 11.3.4.2 Fluxo authorization code . . . . . . . . . . . . . . . . . . . . 402 11.3.4.3 Fluxo resource owner password credentials . . . . . . . . . . 403 11.3.4.4 Fluxo client credentials . . . . . . . . . . . . . . . . . . . . . 404 11.3.4.5 Fluxo implicit . . . . . . . . . . . . . . . . . . . . . . . . . . 404 11.3.5 OpenID Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Glossário de Termos – Português Europeu/Português do Brasil

409

Referências Bibliográficas

411

Índice Remissivo

431

xviii

1 Introdução 1.1 Introdução No âmbito da segurança de sistemas computacionais, podem considerar-se três grandes áreas de atividade, todas relevantes e com as suas especificidades: defesa contra catástrofes, defesa contra faltas ou falhas previsíveis e defesa contra atividades não autorizadas. Essas três grandes áreas serão seguidamente introduzidas de forma sumária.

1.1.1

Defesa contra catástrofes físicas

A defesa contra catástrofes físicas visa principalmente conseguir que um sistema computacional, ou o serviço que esse sistema presta, consiga sobreviver a catástrofes onde existam consequências a nível físico. A definição exata do que é uma catástrofe desse tipo não é fácil, mas podem considerar-se as seguintes como exemplos comuns: Catástrofes ambientais – Tremores de terra, incêndios, inundações, queda de raios, tempestades magnéticas, etc.; Catástrofes políticas – Ataques terroristas, motins, etc.; Catástrofes materiais – Degradação irreparável ou perda ou roubo de equipamentos computacionais, como discos magnéticos, computadores portáteis, etc. Todas estas catástrofes são potenciais causas de dano físico irreparável de equipamentos informáticos e, mais relevante ainda, potenciais causas de perda irreparável de informação armazenada. Imaginemos, por exemplo, a quantidade de informação que se perdeu com a destruição do World Trade Center em Nova Iorque a 11 de setembro de 2001. A defesa contra catástrofes físicas segue normalmente uma estratégia de sobrevivência usando redundância de equipamentos ou informação. Para que a sobrevivência seja assegurada pode-se usar hardware com redundância (por exemplo, blocos de discos magnéticos montados em RAID – Redundant Array of Independent Disks) ou equipamentos redundantes com informação replicada (por exemplo, dois sistemas iguais e com a mesma informação em locais diferentes e suficientemente distantes). Esta última forma de redundância poderá permitir que o sistema afetado continue a prestar o serviço esperado com uma perturbação © FCA – EDITORA DE INFORMÁTICA

Segurança em Redes Informáticas

que será determinada apenas pelo tempo que levarem a entrar em funcionamento efetivo os sistemas alternativos não afetados. A forma mais elementar de sobrevivência de informação consiste na realização periódica de cópias de salvaguarda (cópias de backup). Se estas cópias forem guardadas suficientemente longe do local da catástrofe, então poderão ser usadas para repor parte ou a totalidade da informação afetada pela catástrofe. Esta é a forma habitual como as pessoas protegem a informação que consideram relevante nos computadores pessoais ou organizacionais que usam. No entanto, os sistemas de salvaguarda temporizados, ou seja, que só atuam em determinados instantes temporais bem definidos, não conseguem manter cópias rigorosamente iguais dos dados do sistema sujeito a catástrofes, mas cópias consideradas suficientemente próximas para minimizar de forma substancial o impacto da catástrofe. Para além disso, a estratégia de sobrevivência deverá minimizar de forma realista, isto é, tendo em conta relações custo/benefício, a possibilidade de ocorrência de catástrofes ou de dano causado pelas mesmas. Assim, infraestruturas computacionais críticas podem ser concentradas em zonas antissísmicas ou abrigadas em abrigos antissísmicos, colocadas em locais elevados para minimizar a possibilidade de ocorrência de inundações, protegidas convenientemente da queda de raios, etc. No entanto, tal nem sempre é fácil ou possível dentro das limitações operacionais e de custos da organização que gere o sistema de informação a proteger.

1.1.2

Defesa contra faltas ou falhas previsíveis

A defesa contra faltas ou falhas previsíveis visa sobretudo minimizar o impacto de problemas que ocorrem com uma frequência maior, mas cujo impacto global é normalmente menor. A definição exata do que são faltas ou falhas previsíveis também não é fácil, mas podem considerar-se as seguintes como exemplos comuns: Quebra no fornecimento de energia elétrica ou falha na fonte de alimentação de um equipamento computacional; Bloqueio na execução de aplicações ou sistemas operativos; Falhas temporárias de conectividade em troços de rede. Nesta lista está um conjunto de eventos que são expectáveis no funcionamento diário de um sistema computacional, e para os quais existem inúmeras soluções mais ou menos complexas que permitem tolerá-los até um certo grau. As falhas no fornecimento de energia elétrica podem ser toleradas com sistemas alternativos funcionando com baterias ou com geradores a combustível e as falhas nas fontes de alimentação podem ser resolvidas com fontes redundantes. O bloqueio de aplicações ou sistemas operativos não é normalmente passível de ser tolerado com redundância sem recorrer a conjuntos de máquinas (clusters), obrigando habitualmente 2

2 Criptografia 2.1 Introdução A criptografia é a arte ou ciência que permite escrever de forma a ocultar conteúdos (do grego krypthós – oculto + graph – raiz de graphein, escrever). O objetivo da criptografia é permitir que um conjunto limitado de entidades, tipicamente duas, possam trocar informação que é ininteligível para terceiros. O uso da criptografia revela-a, isto é, um texto criptografado é claramente ininteligível para quem não sabe como decifrá-lo. Este aspeto pode ser indesejável, porque tanto pode fornecer indícios de onde existe informação sensível que foi ocultada, como é ilegal (por existirem leis ou regulamentos que proíbam a produção ad hoc de conteúdos criptografados). Para contornar este problema, existe outra técnica conhecida como esteganografia (do grego steganós – oculto + graph – raiz de graphein, escrever). O objetivo da esteganografia é permitir que um dado conteúdo sensível possa ser ocultado dentro de outro conteúdo aparentemente inocente e que aparenta estar correto. Um exemplo clássico deste tipo de técnica é a escrita com tinta invisível. Um exemplo mais atual consiste em ocultar conteúdos dentro de imagens, usando para o efeito os bits menos significativos de cada pixel das mesmas. Em ambos os casos, o conteúdo ocultado é impercetível ao olho humano, mas quem souber como a informação foi ocultada poderá localizá-la e recuperá-la facilmente. A criptanálise é a arte ou ciência de violar informação criptografada ou sistemas criptográficos. O desenvolvimento de técnicas criptográficas motiva, naturalmente, o desenvolvimento de métodos de criptanálise para contrariar os propósitos das primeiras. Estes métodos destinam-se a descobrir, através dos mais variados processos, os elementos ocultados através da criptografia ou as técnicas ou os aspetos particulares usados para a efetuar (algoritmos, chaves, etc.). Finalmente, designa-se por criptologia o ramo do saber que se dedica ao estudo da criptografia e da criptanálise. Um criptólogo é alguém que se dedica a estudar problemas tanto de criptografia como de criptanálise. Na prática, esse estudo é, em parte, indissociável, porque o desenho ou uso correto de técnicas criptográficas pressupõe que exista alguma noção dos riscos de criptanálise das mesmas.

Segurança em Redes Informáticas

2.2 Criptografia e criptanálise A criptografia baseia-se no uso de cifras. Uma cifra é uma técnica concreta de criptografia, isto é, uma forma específica de ocultar informação. Assim, uma cifra transforma um texto em claro num texto cifrado ou criptograma. A operação inversa é a decifra, que transforma um criptograma no texto em claro original. Se a decifra for mal efetuada, porque o criptograma está corrompido ou porque houve uma má escolha de algoritmos ou chaves de decifra, então o resultado é imprevisível: cifra decifra texto em claro −−−→ criptograma −−−−−→ texto em claro original

A operação da maioria das cifras e decifras é definida através da especificação de um algoritmo e de uma chave. O algoritmo define o modelo genérico de transformação de dados; a chave é um parâmetro do algoritmo que permite variar o seu comportamento de forma complexa (ver Figura 2.1). Chave de cifra Algoritmo de cifra Criptograma

Texto em claro Algoritmo de decifra

Chave de decifra Figura 2.1 – Modelo de geral de operação de cifras e decifras, definido por um algoritmo e uma chave

O objetivo da criptanálise é, como se disse anteriormente, descobrir textos ocultados usando cifras ou descobrir segredos usados em sistemas de cifra para ocultar um ou mais textos. À luz do que antes se disse sobre cifras, temos então que os objetivos da criptanálise são, geralmente, a obtenção de: Texto original relativo a um dado criptograma; Chave de cifra (ou de uma outra equivalente) usada para produzir um ou mais criptogramas; Algoritmo de cifra (ou de um outro equivalente) usado para produzir um ou mais criptogramas. As técnicas de criptanálise são inúmeras e seria fastidioso enumerá-las todas neste texto. Importa, no entanto, referir as formas de ataque criptanalítico mais significativas: 24

3 Gestão de Chaves Públicas 3.1 Introdução As chaves assimétricas, descritas no Capítulo 2, são, hoje em dia, bastante convenientes para autenticar pessoas, entidades ou servidores contactáveis através da Internet e com quem não se partilha, à partida, qualquer segredo. A contrapartida, no entanto, é que a gestão de chaves públicas é algo que tem de fazer parte do dia a dia dos utentes e a mesma não é fácil ou é mesmo bastante confusa. Neste capítulo tentaremos mostrar os aspetos básicos da gestão de chaves públicas sob o ponto de vista do utente e daremos como exemplo a utilização das chaves públicas no âmbito da exploração do Cartão de Cidadão. No final do capítulo explicaremos, de forma pormenorizada, o modelo funcional de uma ferramenta de proteção de conteúdos, o PGP (Pretty Good Privacy), que foi desenvolvida para ser usada pelos utentes sem recurso a serviços centrais de gestão de chaves assimétricas, mas que não é trivial de ser compreendida por utentes que não sejam especialistas em gestão desse tipo de chaves. Adicionalmente, serão referidas as formas de usar a ferramenta para cifrar e decifrar conteúdos, bem como as operações para assinar conteúdos e verificar essa assinatura.

3.2 Geração, salvaguarda e uso das chaves privadas Como se afirmou na secção 2.6.2.2, um dos principais problemas subjacentes à utilização de criptografia assimétrica é o confinamento rigoroso das chaves privadas aos seus legítimos detentores. Tal significa que essas chaves devem ser geradas pelos próprios, guardadas por eles em suportes de armazenamento seguros e usadas por si em ambientes seguros, onde seja impossível, ou improvável, a sua divulgação para terceiros.

3.2.1 Smartcards Uma das formas de cumprir todos estes requisitos é usar um smartcard. Este consiste num computador de dimensões e capacidade de cálculo reduzidas, embutido na superfície de um cartão de dimensões normalizadas. Um smartcard possui uma interface normalizada de comunicação com o exterior, definida por diversos padrões ISO 7816. Pode ou não ter

Segurança em Redes Informáticas

contactos elétricos com o exterior; o Cartão de Cidadão, por exemplo, possui contactos, enquanto o PEP (Policy Enforcement Point) não possui. Um smartcard pode possuir a capacidade de geração de pares de chaves assimétricas e de uso exclusivamente interno, para cifras e decifras, da respetiva chave privada. Desta forma, a chave privada pode ser gerada e guardada pelo smartcard e nunca precisa de sair deste para ser utilizada pelo seu dono, beneficiando deste modo da proteção que lhe é conferida, em termos de não divulgação a terceiros, pelo ambiente de computação controlado do smartcard. Os smartcards são, geralmente, construídos de maneira a respeitarem normas de proteção física. Estas são fundamentais para garantir que os dados secretos neles armazenados, como as chaves privadas, não podem ser extraídas ou modificadas usando a interface disponibilizada, técnicas de manipulação direta do circuito eletrónico ou mesmo ataques indiretos (conhecidos como side-channel attacks). Estes ataques baseiam-se na aquisição de informação secreta de um sistema criptográfico através da análise da sua concretização física – por exemplo, tempos de execução de operações criptográficas, potência consumida ao longo de operações criptográficas ou emanações eletromagnéticas durante operações criptográficas são fontes de informação que podem ser utilizadas para determinar parte ou a totalidade dos bits de uma chave privada guardada num smartcard. Em termos programáticos, um smartcard é usado através do envio de comandos, denominados APDU (Application Protocol Data Unit). Um APDU é uma mensagem com formato normalizado que serve para enviar um comando a um smartcard e receber resultados da execução desse comando. Muito embora os APDU tenham uma estrutura-padrão, o seu conteúdo não está normalizado e depende do fabricante do smartcard ou de quem o programou. Por este facto, não é, em geral, prático que as aplicações que exploram as funcionalidades dos smartcards usem diretamente os respetivos APDU, porque isso as obrigaria a saberem dialogar com uma grande variedade de smartcards. Alternativamente, as aplicações podem usar uma interface de mais alto nível, que fornece um conjunto de primitivas genéricas de manipulação de objetos do smartcard, tais como pares de chaves ou as suas chaves privadas. Um exemplo de tal interface é definida pelo padrão PKCS #11 [251]; outro exemplo é a CryptoAPI (Cryptographic Application Programming Interface), definida pela Microsoft e disponibilizada nos sistemas MS Windows.

3.2.2

Padrão PKCS #11

O padrão PKCS #11, definido pela RSA Laboratories1 , especifica uma interface programática, chamada Cryptoki (Cryptographic token interface), para dispositivos que possuem informação criptográfica ou executam operações criptográficas, como é o caso dos smartcards. A Cryptoki segue uma orientação por objetos, no sentido em que define os tipos de objetos que permite manipular, e resolve os problemas de independência da tecnologia (por 1 https://www.rsa.com

4 Vulnerabilidades em Máquinas de Sistemas Distribuídos 4.1 Introdução Neste capítulo são descritas vulnerabilidades de sistemas operativos ou de serviços instalados em máquinas ligadas a uma rede local ou de maior escala. Os aspetos abordados serão, fundamentalmente, fragilidades relativas a problemas de desenho, de realização ou de administração de sistemas operativos e serviços. Outro aspeto muito importante que se pretendeu descrever com algum pormenor foi a deteção de vulnerabilidades, algo que é fundamental tanto para quem se defende, como para quem ataca. Quem ataca tem de procurar os pontos fracos no seu alvo antes de investir da forma mais eficaz no seu comprometimento. Quem se defende deve colocar-se na posição (e na mente) de quem ataca e usar os mesmos meios de diagnóstico, ou mesmo melhores, para detetar e eliminar vulnerabilidades antes que estas possam ser exploradas por terceiros. Pretendeu-se, também, descrever a forma de atuação das ferramentas de identificação de vulnerabilidades, uma vez que esse conhecimento é fundamental para detetar e contrariar a sua atividade – o que será descrito nos Capítulos 6 e 7.

4.2 Detetores de vulnerabilidades Os ataques, em especial os efetuados de forma adaptativa por pessoas experientes, usam diversas fontes de informação para detetar vulnerabilidades que possam ser exploradas para levar a bom termo a sua ação ilícita. As fontes de informação podem ser diversas e é da conjugação da informação prestada por todas elas que derivam normalmente as ações concretas efetuadas num ataque.

4.2.1

Identificação de sistemas operativos

Para conduzir o melhor possível um ataque é desejável conhecer o sistema que se pretende atacar. Dessa forma, minimizam-se esforços e evitam-se tentativas infrutíferas, o que é sempre desejável para evitar atividades desnecessárias que podem ser detetadas e revelar a © FCA – EDITORA DE INFORMÁTICA

125

Segurança em Redes Informáticas

tentativa de ataque em curso. É nesta linha de raciocínio que têm grande importância as ferramentas de identificação de sistemas operativos. Estas ferramentas identificam os sistemas a partir das suas diferenças de comportamento. Quanto mais diferenças existirem em relação a um comportamento-base, mais pistas haverá para identificar corretamente um sistema. De preferência, esse comportamento-base deverá ser universal, ou seja, deverá existir em todas as máquinas acessíveis remotamente (nomeadamente através da Internet).

4.2.1.1 Flâmulas (banners) Uma das formas de identificação do sistema operativo de uma máquina, provavelmente a mais simples, consiste em recolher informação prestada por servidores que se executam nessa máquina. Com efeito, muitos servidores anunciam, numa flâmula com uma espécie de mensagem de boas-vindas (banner), o seu nome, a sua versão e, frequentemente, o sistema operativo em que estão a executar. Interagindo com esses servidores, é possível fazer uma primeira identificação do sistema, eventualmente muito genérica – por exemplo, qual a família de sistemas a que pertence, se UNIX/Linux, MS Windows, MacOS, Cisco IOS – que pode ser crítica para decidir quais as possibilidades de ataque do mesmo. Naturalmente, esta forma de identificação é incapaz de identificar máquinas que não possuam servidores, o que é o caso da grande maioria das máquinas-cliente. Para além disso, a possibilidade de supressão ou alteração dos anúncios prestados pelos servidores pode facilmente incapacitar ou iludir o processo de identificação.

4.2.1.2 Impressão digital da pilha de protocolos IP (IP fingerprinting) Um comportamento-base mais universal, e que é analisado por diversas ferramentas de identificação de sistemas operativos, é o da pilha de protocolos IP, que engloba o conjunto de protocolos mais usados na Internet. Com efeito, esta pilha de protocolos tem todos os ingredientes para permitir uma identificação fidedigna, tais como: Todos os sistemas com ligação à Internet possuem a pilha, logo, são potencialmente identificáveis, a menos que não se consiga comunicar com eles; A especificação do comportamento-padrão não é totalmente exaustiva e em muitas áreas sugere apenas comportamentos adequados ou a evitar, o que potencia a existência de diferentes realizações; O comportamento-padrão admite extensões, que são fontes de diferenças; Quaisquer desvios ao comportamento-padrão obrigatório são não só elementos fundamentais para retirar ambiguidade da identificação, como também bons indicadores de versões específicas de sistemas operativos; A reação a situações aberrantes pode não ser coberta pela especificação, o que abre espaço a algum livre-arbítrio dos programadores, logo, à existência de diferenças;

126

5 Vulnerabilidades em Redes Locais e de Grande Escala 5.1 Introdução Neste capítulo são descritas vulnerabilidades de redes de máquinas, tanto locais como de grande escala. Os aspetos abordados serão, fundamentalmente, fragilidades dos protocolos de comunicação e das infraestruturas globais de apoio, como é o caso do serviço de nomes DNS. Neste capítulo não se pretende fazer um levantamento exaustivo de todos os problemas que existem nessa área, porque isso seria uma tarefa imensa, dada a enorme variedade de protocolos aplicacionais. Pelo contrário, pretendeu-se dar a conhecer diversas vulnerabilidades dos sistemas de apoio à comunicação em redes locais e na Internet, isto é, nos sistemas de resolução de nomes, no protocolo de rede IP, que é hoje o padrão “de facto” na comunicação à escala mundial, e nos protocolos de transporte TCP e UDP, os mais usados por aplicações distribuídas. A nível dos protocolos aplicacionais, é feita apenas uma pequena incursão pelo correio eletrónico, por se ter tornado um veículo quase indispensável no dia a dia de quem usa computadores.

5.2 Levantamento de informação arquitetural A informação arquitetural consiste numa descrição, mais ou menos pormenorizada, das máquinas que fazem parte de uma rede e de qual a sua função nessa mesma rede. Entre as fontes primárias de informação arquitetural estão os registos dos domínios DNS. Os serviços DNS, para além de facultarem traduções elementares entre nomes legíveis e endereços IP, através dos registos A, AAAA e PTR, permitem manter e disponibilizar outros tipos de registos para serviços específicos (por exemplo, NS para identificar servidores DNS, MX para entrega de e-mails), bem como registos informativos generalistas (por exemplo, HINFO e TXT). Estes últimos são úteis para fornecer informação acessória para gestão da rede, mas podem representar um perigo por fornecerem informação relevante do domínio DNS potencialmente útil para um atacante. Consequentemente, devem ser evitados ou possuir um conteúdo inócuo para a segurança do sistema. Outra hipótese, mais complexa de

153

Segurança em Redes Informáticas

administrar, consiste em possuir dois servidores autoritários por zona: um para atender pedidos exteriores aos domínios da zona e outro para atender os pedidos interiores. O primeiro deverá fornecer uma informação mínima, em particular apenas traduções de nomes que precisam de ser conhecidos noutros domínios. O segundo fornece uma informação completa e potencialmente mais rica sobre os recursos internos dos domínios da zona. Uma solução complementar para evitar a prestação de informação em demasia por um servidor DNS é impedir a transferência em bloco de informação mantida por uma zona DNS (transferência de zona, zone transfer). Note-se que mesmo uma zona que apenas possua os registos mínimos (SOA, NS e A) permite recolher informação potencialmente interessante para um atacante, uma vez que os nomes das máquinas permitem, regra geral, deduzir a sua finalidade. Por exemplo, os nomes das máquinas podem estar associados a nomes de utilizador de pessoas, a serviços internos, a projetos ou a repositórios centrais de dados pessoais (por exemplo, servidores de ficheiros) e de controlo (por exemplo, MS Windows Domain Servers), gateways/routers internos, etc. Assim, as transferências de zona devem estar autorizadas apenas dos servidores primários da zona para os servidores secundários da mesma (ou ainda para os servidores primários de zona de subdomínios delegados).

5.3 Tradução de nomes A tradução de nomes é um dos aspetos mais críticos da interação entre pessoas, serviços e máquinas. No universo da Internet existem inúmeros serviços de nomes, com graus de abrangência muito distintos, que estão permanentemente envolvidos quando se trata de estabelecer uma interação entre duas entidades, sejam pessoas, serviços ou máquinas. A interferência com a resolução de nomes, expressão que normalmente se usa para designar a tradução de um nome para outro, permite realizar ataques de personificação de máquinas ou serviços. A personificação de serviços, ou de máquinas onde os mesmos se executam, consiste em enganar os seus clientes e levá-los a comunicar com um servidor impostor. Para isso, há que conduzir a comunicação do cliente para o servidor impostor sem que as partes legítimas (o cliente e o servidor legítimo) se apercebam disso. As resoluções de nomes tipicamente associadas à comunicação na Internet sobre IP são duas: nomes DNS ↔ endereços IP e endereços IP ↔ endereços MAC. Para efetuar personificações, pode-se agir de duas formas: atuar a nível do encaminhamento de datagramas IP, de forma a levar os mesmos para um servidor impostor; ou enganar o cliente quando este efetua operações de tradução de nomes relativos ao IP do servidor. Atuando a nível da tradução de nomes relativos ao IP do servidor, há pelo menos duas maneiras de o fazer: a nível da tradução de nomes DNS ou a nível da tradução de endereços IP para endereços MAC: Serviço de nomes DNS – Para simplificar a vida aos utentes da Internet, estes não têm de, normalmente, decorar os endereços IP dos servidores que pretendem usar, os quais são números sem qualquer informação lógica. Em alternativa podem usar nomes 154

6 Firewalls 6.1 Introdução As firewalls surgiram na década de 1990, pelo menos com essa designação, para lidar com os riscos inerentes à ligação de redes privadas de organizações a outras redes não controladas pelas mesmas organizações, nomeadamente a Internet. A publicação seminal sobre a estrutura e a funcionalidade das firewalls é de 1994 [53] e, na mesma, definiram-se diversos conceitos que fazem parte do jargão atual de descrição das firewalls. O termo firewall não será traduzido neste livro, ao contrário do que se fez com muitos outros termos, porque o mesmo, independentemente de descrever ou não com rigor a sua funcionalidade, está profundamente enraizado no léxico informático. Uma firewall tem dois objetivos fundamentais, ambos relacionados com segurança: proteção por isolamento de máquinas ligadas à rede e controlo de interações entre máquinas (Figura 6.1). Estes dois objetivos podem, em certos aspetos, ser coincidentes. Em ambos os casos, as decisões tomadas por uma firewall são controladas por um conjunto de regras e aplicações que as interpretam e reagem em função do tráfego que chega à firewall. Essas regras e aplicações são, juntamente com as máquinas e redes que formam a firewall, a concretização da política de segurança da mesma. Firewall Máquina ou rede protegida

acesso −→ × indesejado

Isolamento

acesso × ←− indesejado

←→

Controlo

←→

Máquina ou rede potencialmente perigosa

Figura 6.1 – Funcionalidade genérica de uma firewall

A proteção por isolamento de uma máquina ligada à rede é, atualmente, um requisito crítico, para máquinas tanto pessoais como organizacionais. Com efeito, a ligação de uma máquina a uma rede é, simultaneamente, uma vantagem e um risco. É uma vantagem, porque lhe permite usar serviços contactando outras máquinas ligadas direta ou indiretamente a essa rede. É também uma vantagem, porque lhe permite disponibilizar serviços a essas mesmas máquinas. Mas é um risco, pois expõe vulnerabilidades da máquina que podem ser exploradas por

181

Segurança em Redes Informáticas

atacantes. Essas vulnerabilidades podem ser diversas, desde erros do sistema ou das aplicações até à má configuração de serviços, de segurança ou outros. É ainda um risco para outras máquinas, visto que a máquina pode ser usada para lançar ataques, o que pode acontecer independentemente da vontade dos seus utentes (por exemplo, após o comprometimento da mesma por uma ciberpraga). O controlo de interações entre máquinas permite definir e concretizar, de maneira simples e centralizada, uma política organizacional de controlo sobre as interações via rede. Essas interações podem acontecer entre um conjunto de máquinas/redes pertencentes ao mesmo domínio de segurança da firewall ou entre essas máquinas/redes e as demais da Internet. O controlo das interações permite implantar políticas de autorização e alteração de fluxos de informação e políticas de inspeção e alteração de conteúdos. É inegável que é mais fácil certificarmo-nos da segurança de uma organização se se controlar a interação com o exterior num único ponto em vez de se aplicar esse mesmo controlo a cada componente individual da rede organizacional. É nessa perspetiva que deve ser enquadrada a atuação de uma firewall. O isolamento ou controlo imposto por uma firewall pode ser aplicado de uma maneira centralizada em termos organizacionais, muito embora possa efetivamente ser concretizado por diversos equipamentos distribuídos. Tal simplifica a concretização de políticas de segurança relativas às interações entre máquinas/redes organizacionais e máquinas/redes alheias. Este aspeto é muito importante quando se lida com grandes quantidades de máquinas e redes heterogéneas, com inúmeras vulnerabilidades conhecidas e desconhecidas, que se pretende defender de ataques iniciados em redes alheias. No entanto, as vulnerabilidades continuam a existir e podem ser exploradas por atacantes que obtenham acesso a máquinas da rede protegida. Por tudo isto, uma firewall é, atualmente, um elemento indispensável na ligação de máquinas pessoais e redes privadas a redes alheias potencialmente perigosas, nomeadamente à Internet. Contudo, conceber, implantar e manter uma firewall é uma tarefa complexa, que exige bons conhecimentos a nível dos protocolos de comunicação e das vulnerabilidades existentes nos diversos sistemas em relação à implantação desses mesmos protocolos. As firewalls foram inicialmente concebidas e idealizadas para fazer uma defesa de perímetro (perimeter defense), de modo a garantir uma interação limitada e controlada entre uma rede protegida e outra insegura que assegurasse o funcionamento correto da primeira. Esta não é a abordagem mais segura, mas uma abordagem simples e pragmática. Uma abordagem diferente, muito mais complexa de implantar, consiste em assegurar uma defesa em profundidade (defense in depth). Nesta abordagem, as diversas componentes da rede protegida não devem depender de mecanismos terceiros, devendo aplicar autonomamente os mecanismos necessários para assegurar as políticas de segurança da rede a que pertencem. Esta abordagem levou ao desenvolvimento de firewalls pessoais, que não são mais do que sistemas de firewall instalados em computadores pessoais e que asseguram a proteção destes, independentemente dos mecanismos de proteção da rede a que estão ligados.

182

7 Sistemas de Deteção de Intrusões 7.1 Introdução Os sistemas computacionais são cada vez mais poderosos e, por essa razão, também mais complexos de configurar e explorar. Todos estes fatores contribuem para que tais sistemas possuam cada vez mais vulnerabilidades, conhecidas ou desconhecidas dos seus utentes. Além disso, alguns sistemas COTS (Commercial Off-The-Shelf ) atuais, como a maioria dos sistemas MS Windows, possuem configurações predefinidas com diversas vulnerabilidades. No entanto, como a maioria dos utentes não é especialista em segurança nem está a par dos riscos que acarretam certas decisões de configuração, é fácil de ver que muitos dos sistemas computacionais, em particular os domésticos, são alvos fáceis para atacantes minimamente conhecedores de algumas técnicas de intrusão. O objetivo dos sistemas de deteção de intrusões (IDS – Intrusion Detection Systems) é detetar e contrariar intrusões. Estes sistemas operam, de certa maneira, de forma independente dos mecanismos explicitamente concebidos e usados para garantir um uso correto do sistema – uso esse que pressupõe uma ausência de intrusões. Uma analogia simples é a dos alarmes dos automóveis ou casas, que detetam indícios de que alguém entrou no habitáculo da viatura ou numa divisão da casa (por exemplo, através da vibração do ar), muito embora o carro e a casa possuam mecanismos tradicionais de controlo de acesso – as fechaduras que, em princípio, deviam ser suficientes para impedir intrusões. Os IDS começaram a ser estudados no início da década de 80 do século XX, tendo sido inicialmente referidos num artigo seminal de J. P. Anderson [12]. No final da década de 80, outro artigo seminal, de D. Denning [71], propôs métodos realistas de realização de certo tipo de IDS. No início da década de 90, com o crescimento explosivo da Internet, ganharam novo fôlego e, hoje em dia, são sistemas bastante sofisticados, tanto comerciais como públicos, mas ainda algo complexos de entender e gerir. Como esta é ainda uma tecnologia emergente, em que existem poucos consensos e padrões, neste capítulo dedicado aos IDS iremos sobretudo abordar aspetos de análise e classificação de sistemas atuais em vez de normas inerentes à sua especificação e uso. A terminar serão referidos dois IDS de referência, completamente diferentes e bastante populares por serem eficazes e gratuitos: Tripwire e Snort.

213

Segurança em Redes Informáticas

7.1.1

Intrusões e sua deteção

Uma intrusão é qualquer conjunto de ações com o intuito de comprometer a integridade, a confidencialidade ou a disponibilidade de um recurso. Uma intrusão resulta da execução de um ou mais ataques aos sistemas que gerem esse recurso, ataques esses que podem ou não provocar alterações permanentes na informação guardada nesses sistemas. Logo, podem-se detetar intrusões, ou tentativas de intrusão, procurando indícios de ataques, ou seja, procurando ações estranhas ou suspeitas ou alterações estranhas ou suspeitas na informação armazenada. Assim, um IDS é um conjunto de componentes, de software ou de hardware, com a função de detetar, identificar e reagir a atividades não autorizadas ou anormais num sistema-alvo.

7.1.2

Perfil de uma intrusão

Para se desenvolver um IDS, em primeiro lugar é preciso perceber qual é o conjunto típico de iniciativas tomadas pelos atacantes para atacar e concretizar intrusões em sistemas computacionais. A primeira iniciativa consiste num reconhecimento externo, em que o atacante tenta obter uma noção topológica do sistema-alvo. Neste reconhecimento, o atacante procura detetar, em particular, sistemas de proteção, como componentes de firewalls ou IDS. Este reconhecimento é vital para assegurar que os ataques com vista à intrusão não sejam detetados. Neste reconhecimento, o atacante pode recorrer a diversos serviços de nomes, como serviços de DNS, ou à recolha de informação através do envio e receção de mensagens com formatos específicos (opção Record Packet Route em cabeçalhos IP, diversas mensagens ICMP, etc.). A segunda iniciativa consiste num reconhecimento interno, em que cada máquina é auditada para detetar vulnerabilidades. Esta auditoria, já pormenorizada no Capítulo 4, tem por finalidade conhecer tão bem quanto possível qual o hardware da máquina, o sistema operativo, os serviços prestados a clientes externos e os utentes, máquinas ou pessoas que a eles têm acesso. Normalmente, esta iniciativa envolve diversos contactos com a máquina sob análise, o que implica um tráfego de rede que será tipicamente anormal, a menos que o atacante consiga camuflá-lo de modo eficaz. A terceira iniciativa consiste em efetuar ataques aos sistemas onde foram detetadas vulnerabilidades. Os ataques podem implicar ações não usuais, como o envio de mensagens deliberadamente mal formatadas, ou ações aparentemente corretas e legítimas, como a exploração de uma conta com uma senha de autenticação comprometida. Desta iniciativa podem resultar diversas situações, como a falha de serviços, a obtenção ou a alteração de informação reservada ou, no pior caso, a criação de uma sessão remota com privilégios de administração.

214

8 Redes Privadas Virtuais 8.1 Introdução O conceito de rede privada virtual (VPN – Virtual Private Network) é usado hoje em dia para rotular diversas soluções de comunicação segura. Em que consiste, então, este conceito e de que maneira pode ser posto em prática, tanto em termos topológicos como protocolares, serão os assuntos deste capítulo. Uma VPN consiste numa extensão segura de uma rede privada sobre uma rede insegura (e, normalmente, pública). Ou seja, consiste na criação de um ambiente seguro em rede sobre um conjunto de redes que, à partida, têm de ser consideradas potencialmente inseguras. Existe um consórcio de fabricantes de produtos relacionados com VPN, designado por VPNC (VPN Consortium 1 ). Esse consórcio produziu um documento que apresenta as definições e os requisitos tecnológicos das VPN [290]. Este documento distingue dois tipos de VPN: confiáveis (trusted VPN) e seguras (secure VPN). As VPN confiáveis garantem que o encaminhamento dos dados numa rede pública não passa por fornecedores de acesso e encaminhamento, exceto por aqueles em que o emissor confia. No entanto, esta não é uma aproximação flexível e passível de evoluir em larga escala. As VPN seguras garantem que a segurança dos dados entre o emissor e o recetor é independente da honestidade dos fornecedores de acesso e encaminhamento. Esta é a abordagem mais flexível, mais facilmente escalável e que tem tido maior implementação nos meios informáticos, empresariais e domésticos. Neste capítulo falaremos apenas destas VPN e, para simplificar, referir-nos-emos a elas sem o qualificativo “seguras”. Para que o leitor não se sinta baralhado, deixamos aqui claro que, em grande medida, as soluções técnicas apresentadas no documento do VPNC são diferentes das apresentadas neste capítulo. Com efeito, o documento apenas considera soluções baseadas em IPSec e SSL, enquanto, neste capítulo, são abordadas outras soluções, como SSH, PPTP e OpenVPN, e é dado um enquadramento de como o SSL pode ser usado para estabelecer várias VPN, muito embora não o faça de raiz. 1 https://www.vpnc.org

229

Segurança em Redes Informáticas

8.2 Definição Uma VPN atua como um “cabo de rede virtual” que permite uma ligação externa a uma rede organizacional protegida. Como, no entanto, esse “cabo virtual” é realizado comunicando sobre redes públicas inseguras, é necessário dotá-lo de técnicas seguras de comunicação de dados para assegurar a confidencialidade e a integridade dos dados trocados. Segundo o VPNC [290], as VPN possuem os seguintes requisitos: Todo o tráfego que flui na VPN tem de ser cifrado (para garantir a sua confidencialidade perante terceiros) e autenticado (para impedir que terceiros o alterem). Se alguma destas características não for assegurada, então não estaremos em presença de uma VPN no sentido estrito do termo. A manipulação criptográfica de dados trocados numa sessão deve ser efetuada, usando uma ou mais chaves de sessão. Estas devem ser chaves simétricas aleatórias e secretas, conhecidas apenas pelos interlocutores, e efémeras, ou seja, não devem ser guardadas para além do necessário para garantir a segurança da sessão; Os atributos de segurança de uma VPN, nomeadamente os identificadores da sessão e os algoritmos e chaves de sessão que vão ser usados na mesma, têm de ser acordados entre os extremos que a exploram, os quais devem ser autenticados; Ninguém exterior à VPN consegue afetar os atributos de segurança de uma VPN. Os atacantes não conseguem alterar os atributos de segurança de uma VPN nem interferir com os parâmetros criptográficos, nomeadamente chaves de cifra, que são usados pela VPN. As VPN deveriam igualmente evitar que pudessem ser usadas para explorar ataques DoS. Exemplos de tais ataques poderiam ser tentativas falsas de instanciação de uma VPN ou injeção de tráfego numa VPN. No entanto, tal não é habitualmente uma preocupação.

8.3 Chaves de sessão As chaves de sessão são valores críticos para a segurança das VPN, muito embora existam outros aspetos tanto ou mais relevantes. As chaves de sessão não são necessariamente chaves de cifra, mas valores secretos iguais partilhados por conjuntos limitados de interlocutores, tipicamente apenas dois, que servem para derivar parâmetros criptográficos comuns pelos interlocutores; esses parâmetros é que incluem, normalmente, as chaves de cifra. As chaves de sessão devem ser acordadas pelas partes interatuantes na sessão no seu início e descartadas assim que a sessão terminar, para reforçar o seu secretismo. Há muitas maneiras de negociar chaves de sessão e cada tipo de VPN usa a sua própria. Normalmente, a negociação é feita recorrendo a segredos de longa duração, detidos pelas partes negociadoras, que permitem proteger ou autenticar as trocas de dados efetuadas 230

9 Segurança em Redes Sem Fios 802.11 (WLAN ou Wi-Fi) 9.1 Introdução As redes sem fios, e em particular as redes 802.11, também conhecidas como redes WLAN (Wireless Local Area Network) ou redes Wi-Fi1 , são, hoje em dia e inegavelmente, cómodas para suportar a comunicação de dados em diversos cenários operacionais. No entanto, colocam também diversos problemas de segurança, nomeadamente quando confrontadas com a contrapartida clássica: as redes cabladas. Os problemas de segurança colocados pelas redes sem fios, já sumariamente abordados na secção 5.4.2.1, são sobretudo quatro: A autenticação entre um equipamento móvel (STA – Station) e as redes sem fios a que acede; O controlo de acesso de um STA a uma rede sem fios; A confidencialidade das mensagens trocadas via rádio; A autenticidade, ou controlo de integridade, das mensagens recebidas. O problema da segurança em redes sem fios 802.11 complicou-se com a pressão do mercado, que levou a que tivessem aparecido padrões demasiado inseguros. Daí resultaram paliativos mais ou menos eficazes e soluções eficazes mas que implicavam o abandono de todos os equipamentos entretanto comercializados. Por tudo isso, atualmente, a segurança em redes 802.11 é um puzzle algo complexo de siglas e tecnologias que confunde muitas vezes o utilizador final. Ao longo deste capítulo tentaremos mostrar as motivações de cada tecnologia e a sua interligação num todo. Para facilitar a compreensão de conceitos de segurança subjacentes às redes sem fios 802.11, vamos fazer uma breve introdução de alguns aspetos elementares do seu funcionamento. 1 Wi-Fi, acrónimo de Wireless Fidelity, é uma marca licenciada pela Wi-Fi Alliance para catalogar a tecnologia inerente a redes sem fios baseadas nos padrões 802.11. O seu logótipo é .

259

Segurança em Redes Informáticas

9.2 Arquitetura de uma rede 802.11 O padrão 802.11 permite duas arquiteturas de rede alternativas, ilustradas na Figura 9.1: ad hoc e estruturadas. Nas arquiteturas ad hoc, cada STA pode comunicar com outros segundo um modelo P2P. O conjunto de equipamentos que constitui cada rede ad hoc forma um IBSS (Independent Basic Service Set). Neste livro não serão abordados aspetos de gestão ou de segurança das redes ad hoc 802.11. Nas arquiteturas estruturadas, os STA comunicam com os AP, que funcionam como switches, apenas possuindo portas para comunicar com redes cabladas e antenas para comunicar com os STA (ou com outros AP) via rádio. Um conjunto de STA que esteja a usar um AP específico forma um BSS (Basic Service Set). Este conjunto pode ser alargado de forma a englobar outros AP, o que constitui um ESS (Extended Service Set). A interligação entre os vários AP designa-se por Sistema de Distribuição (DS – Distribution System) e pode ser concretizado por uma rede cablada ou por uma rede sem fios. DS

AP STA

STA STA

IBSS

STA

AP STA

STA

BSS

STA

STA STA

BSS ESS

Figura 9.1 – Arquiteturas de rede 802.11: ad hoc (IBSS) e estruturadas (BSS e ESS)

9.2.1

Identificadores de rede

As redes sem fios 802.11, ad hoc ou estruturadas, reconhecem-se através de um identificador de 32 octetos – SSID (Service Set IDentifier). Nas arquiteturas ad hoc o SSID pode ser escolhido arbitrariamente pelos interlocutores, devendo apenas ser diferente de outros SSID pertencentes a outras redes sem fios da vizinhança. Nas arquiteturas estruturadas, o SSID é estabelecido ao nível dos AP. Cada AP pode, normalmente, servir várias redes sem fios, cada uma com o seu SSID distinto, mas tal capacidade operacional depende apenas do fabricante.

9.2.2

Comunicação em redes estruturadas

Numa rede sem fios estruturada 802.11, a comunicação entre um STA e um AP é feita recorrendo a tramas de diversos tipos. Existem três tipos-base de tramas, cada um com 260

10 Protocolos de Autenticação “Strazzabosco: Alto là! Chi va là? Serg. Lo Russo: Sono io, Lo Russo. Farina: Parola d’ordine! Serg. Lo Russo: Sono io, ho detto. Strazzabosco: Farsi riconoscere, parola d’ordine! Serg. Lo Russo: Vi ho detto che sono io, Lo Russo. Farina: Parola d’ordine o spariamo! Serg. Lo Russo: Oh! Va beh! Eh? Savoia o morte. Farina: Va bene sergente, lei può avanzare. Serg. Lo Russo: Va bene un cazzo! Controparola d’ordine! Farina: Mementa odare semper. Serg. Lo Russo: No! Sbagliato! Farina: Come? Strazzabosco: Folgore! Serg. Lo Russo: No! Munaron Felice: Quella s’è de ieri. Pizza margherita! Serg. Lo Russo: Se, quattro stagioni adesso! Munaron Libero: E’ regina Margherita. Farina: Regina. Serg. Lo Russo: Va bene. E noi dovremmo spezzare le reni alla Grecia con questi quattro deficienti qua. Voi domani siete tutti consegnati, è chiaro? Colasanti: Ma va’ a cagare.”

“Mediterraneo”, Gabriele Salvatores (1991)

10.1 Introdução A autenticação de entidades consiste na obtenção de um comprovativo de que possuem um atributo que afirmam possuir, ou que é suposto possuírem. Normalmente, esse atributo é uma identidade, mas poderá não ser. Por exemplo, um lugar de estacionamento reservado para um médico poderá ser ocupado por um veículo conduzido por alguém que prove ser médico. Outro exemplo é um CAPTCHA1 , que supostamente deverá permitir autenticar uma entidade como ser humano, diferenciando-o de um programa de computador. A autenticação de entidades envolve um processo de prova, na qual o autenticador obtém uma prova fidedigna de que a entidade autenticada, ou autenticado, possui o atributo que afirma possuir. Para a realização dessa prova é necessário que o autenticador possua alguma informação confiável na qual irá basear a verificação da prova. Se tal informação não existir, 1 Completely Automated Public Turing test to tell Computers and Humans Apart – teste de Turing público e completamente automatizado para diferenciar computadores de humanos. © FCA – EDITORA DE INFORMÁTICA

305

Segurança em Redes Informáticas

então será impossível realizar a prova e a autenticação não poderá ser realizada. Por exemplo, a prova de autenticidade usando um documento de identidade (Cartão de Cidadão, por exemplo), parte do pressuposto de que o documento de identidade é confiável, ou seja, que é genuíno, foi produzido corretamente e não foi alterado. As entidades envolvidas em processos de autenticação podem ser de diversos tipos: humanos, serviços, servidores, máquinas ou redes. A autenticação realiza-se sobre outras entidades ou sobre dados, como documentos ou mensagens. Este último tipo de autenticação foi globalmente abordado na secção 2.10, relativa aos autenticadores de dados. Um protocolo de autenticação é um conjunto de mensagens trocadas entre vários interlocutores e que tem por objetivo realizar a autenticação de um ou mais deles perante um ou mais dos demais. Tipicamente, os protocolos de autenticação envolvem apenas dois interlocutores. Mas existem protocolos mais complexos que envolvem mais entidades, vulgar e genericamente designadas como entidades terceiras confiáveis.

10.2 Caracterização dos protocolos de autenticação Existem inúmeros protocolos de autenticação, alguns com variantes, mas a sua caracterização pode ser feita tendo em conta um conjunto reduzido de paradigmas usados.

10.2.1

Elemento de prova

Os protocolos de autenticação podem ser caracterizados segundo o elemento usado para realizar a prova de autenticidade. Há três paradigmas em termos de elementos de prova: O que se sabe – Neste paradigma, uma entidade prova a sua autenticidade mostrando que conhece uma determinada informação secreta, designada genericamente por senha. Esta senha, se for apenas conhecida pelos intervenientes diretos no processo de autenticação, permitirá provar que o interlocutor é quem afirma ser. Quando este paradigma é usado com humanos, é usual que a senha seja uma informação fácil de memorizar para evitar a sua escrita e, assim, minimizar o risco de transmissão a terceiros. A memorização, no entanto, levanta problemas complexos, que serão abordados na secção 10.2.2; O que se possui – Neste paradigma, uma entidade prova a sua autenticidade mostrando que possui um determinado dispositivo de segurança ou que é o dono legítimo desse dispositivo de segurança. Um dispositivo de segurança é um equipamento portátil que possui um comportamento conhecido do autenticador que permite validar a sua autenticidade. Assumindo que o dispositivo de segurança está sempre na posse de uma determinada entidade a que foi

306

11 Controlo de Acesso, Autorização e Delegação Os sistemas informáticos potenciam os mais variados tipos de interações entre entidades, mas tipicamente as políticas de segurança definidas para um determinado domínio de segurança especificam limitações várias que definem o universo de interações autorizadas. A forma como as políticas são definidas e postas em prática é muito variada e seria fastidioso fazer uma listagem exaustiva das mesmas. Assim, neste capítulo iremos fazer um breve introdução aos conceitos-base de controlo de acesso, à forma como os mesmos lidam com o problema de dar ou não autorização para a realização de uma operação, e de que forma se pode realizar operações de delegação, ou seja, de passagem de autorizações de acesso para terceiros. Para ilustrar os conceitos, serão abordadas duas contribuições bastante populares nesta área: a arquitetura de controlo de acesso XACML e protocolo de delegação OAuth 2.0.

11.1 Controlo de acesso O controlo de acesso tem por objetivo dar uma resposta à seguinte pergunta: A entidade E pode realizar a ação A sobre o objeto O? A esta pergunta só deve ser dada geralmente uma de duas respostas: sim ou não. E é essa, fundamentalmente, a tarefa de um sistema de controlo de acesso. Um sistema de controlo de acesso parte do princípio que entre a entidade E, que pretende realizar a ação, e o objeto O, que é o alvo da mesma, existe uma entidade denominada monitor de controlo de acesso. Um monitor de controlo de acesso é uma componente incontornável, por definição; ou seja, a entidade não tem forma de realizar ações sobre o objeto sem que as mesmas sejam sancionadas pelo monitor de controlo de acesso. Um monitor de controlo de acesso usa um conjunto de políticas de controlo para decidir se um determinado acesso deverá ser concedido ou negado. Há várias formas de construir essas políticas, mas são dois os modelos-base para as colocar em prática: As políticas são parte intrínseca do monitor de controlo de acesso, isto é, fazem parte da sua forma fundamental de operar. Neste caso, diz-se que estamos perante um sistema que usa um controlo de acesso obrigatório (Mandatory Access Control, MAC), pelo facto de as políticas não serem mutáveis (a menos que se mude o monitor de controlo de acesso); © FCA – EDITORA DE INFORMÁTICA

383

Segurança em Redes Informáticas

As políticas são definidas externamente ao monitor de controlo de acesso, podem ser alteradas ao longo do tempo e o monitor tem a capacidade de as interpretar de forma a tomar decisões. Neste outro caso, diz-se que estamos perante um sistema que usa um controlo de acesso discricionário (Discricionary Access Control, DAC), pelo facto de as políticas poderem mudar de forma discricionária. Este poder de mudança é, habitualmente, concedido a quem é considerado o dono do objeto ou, alternativamente, a quem possui o direito de mudar discricionariamente o controlo de acesso ao objeto. Em qualquer dos modelos podemos considerar a existência de uma estrutura de dados abstrata, denominada matriz de controlo de acesso. Esta matriz é uma tabela conceptual, onde cada linha representa uma entidade e cada coluna um objeto. A entidade é caracterizada por um conjunto de atributos que são fulcrais para a tomada de decisão de controlo de acesso a cada objeto. O elemento que está no cruzamento entre a linha de uma entidade e a coluna de um objeto elenca os direitos de acesso dessa entidade a esse objeto. Regra geral, os direitos de acesso a cada objeto estão associados ao mesmo, o que dá origem a algo que se designa por Lista de Controlo de Acesso (Access Control List, ACL). Dado um determinado pedido por parte da Entidade E de realização da ação A sobre um objeto O, a matriz de controlo de acesso pode ser usada de duas formas fundamentais: O monitor de controlo de acesso obtém a ACL do objeto O e, da sua análise, conclui se a ação A deve ser autorizada ou negada para a entidade E. Na análise da ACL são habitualmente elementos de decisão críticos a ação A (por exemplo, leitura, escrita, criação, eliminação, etc.), que se pretende realizar e a entidade E, que a solicita. Porém, pode haver outros fatores relevantes para a tomada de decisão, como, por exemplo, a hora em que a operação está a ser requerida, o facto de a ação ter por base o desejo de um ser humano ou de um programa de computador, etc; Numa primeira fase a entidade E requer a emissão de uma capacidade (capacity) para requerer a realização da ação A sobre o objeto O. Uma capacidade é um objeto informático, também designado por chave, que não é forjável (só o monitor de controlo de acesso a consegue produzir) e que encapsula uma indicação de que o seu detentor (E) possui o direito de realizar a ação A sobre O. Depois, numa segunda fase, a entidade E requer a realização da ação A sobre o objeto O, mas a esse pedido acrescenta a capacidade previamente obtida para esse efeito. Esta capacidade será primeiro validada pelo monitor de controlo de acesso, depois confrontada com o pedido, e se tudo estiver em conformidade (por exemplo, a ação requerida está autorizada pela capacidade), a ação é autorizada.

11.1.1

Gestão das ACL

As ACL podem especificar direitos concedidos (positivos), não concedidos (nulos) ou retirados (negativos). De um modo geral, usam-se apenas os primeiros: concede-se um direito às 384