Métodos de Defesa

Capítulo 5

5.1 Configurações do Concentrador

Defesa do equipamento. Desabilitar o envio de SSID (ou ESSID). Substituição de endereço MAC. Desabilitar acessos ao concentrador via rede

sem fio. Ignorar clientes que enviam SSID (ESSID) como

“ANY”. Utilizar concentrador em modo-ponte (bridge). Defesa dos equipamentos-clientes. Desabilitar comunicação entre os clientes.

5.1.1 Defesa do Equipamento

Defesa do Equipamento

ConcentradorProteção contra acesso não autorizado.Proteção contra DoSGarantir a segurança e privacidade dos

clientes.Demais formas de atques

5.1.1.1

Desabilitar a difusão de SSID

5.1.1.2

Modificar o nome SSID padrão

5.1.1.3

Substituição do Endereço MAC do AP

Substituição do Endereço MAC do AP

Seguindo a linha de segurança por obscuridade.

É possível, em alguns APs, modificar seu endereço MAC.

Fazendo com que a associação deste endereço, que normalmente é feita pelas ferramentas de varredura, com o fabricante do equipamento seja desfeita.

Substituição do Endereço MAC do AP

Essa mudança, quando feita no momento da instalação do AP, não causa nenhum problema ao usuário.

Portanto, evita a identificação do fabricante do AP, por parte de um atacante.

Substituição do Endereço MAC do AP

Esse procedimento é possível através de APs baseados em sistemas operacionais apropriados.

OpenWRT

Substituição do Endereço MAC do AP

OpenWrt is a GNU/Linux based firmware for embedded devices such as residential gateways (routers).

Ver Linksys WRT54GVer Asus WL500G

5.1.1.4

Desabilitar acessos ao AP via rede sem fio

Desabilitar acessos ao AP via rede sem fio

A maioria dos APs permitem configuração via HTTP, através de URLs (default), que são IPs inválidos (192.168.x.x ou 10.0.x.x) fornecidos pelo fabricante.

Desabilitar acessos ao AP via rede sem fio

Mas não há uma forma cifrada para tais acessos.

Assim, é uma boa prática desabilitar acesso ao AP, pelo lado da rede sem fio, para evitar captura de usuários e senhas ou outras informações por um possível atacante.

Desabilitar acessos ao AP via rede sem fio

Permitir que um computador se conecte ao AP para alterar as configurações apenas através da rede cabeada, se esta opção estiver disponível.

Desabilitar acessos ao AP via rede sem fio

Desta maneira um possível atacante, via rede sem fio, não poderá acessar o AP diretamente para promover mudanças na configuração.

Verifique a documentação do seu AP sobre como efetuar estas mudanças, caso estejam disponíveis.

Desabilitar acessos ao AP via rede sem fio

Essa recomendação pressupõe que a rede cabeada conte com mecanismos de proteção que permitam monitorar ou autenticar usuários e, assim, possam restringir ou registrar os possíveis acessos a um AP.

Desabilitar acessos ao AP via rede sem fio

O administrador pode configurar, na rede cabeada, algum software de segurança (Firewall, IDS) para monitorar e registrar todos os acessos ao AP.

Desabilitar acessos ao AP via rede sem fio

Usando um switch e montar uma VLAN consistindo do AP e da rede cabeada, no sentido de dificultar a captura de informações.

VLAN ???

Desabilitar acessos ao AP via rede sem fio

Stunnel é um software de segurança que permite criptografar conexões TCP dentro do protocolo SSL.

Stunnel requer funcionar com as bilbiotecas SSL, tal como OpenSSL, para se poder compilar Stunnel.

5.1.1.5

Utilizar o AP em modo-ponte (bridge)

O que é uma ponte ?

Uma carcterística de uma ponte é permitir o acesso de um ponto ao outro.

Assim, a não ser que exista uma forma de configuração ou de topologia que limite essa funcionalidade natural de uma ponte, todos os equipamentos de um lado ficarão visíveis do outro.

Utilizar o AP em modo-ponte (bridge)

Se o administrador não contar com recursos para bloquear o acesso ao AP:

porque a rede é um acesso eventual para mudar configuração.

porque a rede cabeada não é considerada segura.

Utilizar o AP em modo-ponte (bridge)

Configurar o AP para funcionar no modo-ponte (camada 2).

Sendo ponte, não existe o endereço IP, o que impede o acesso remoto total ao AP, através de um browser.

Utilizar o AP em modo-ponte (bridge)

Habilitar a visibilidade do endereço IP apenas para a rede cabeada (o chamado “IP de Serviço”).

Utilizar o AP em modo-ponte (bridge)

Problema 1: a perda total do acesso remoto.

Solução: Este problema pode ser minimizado em alguns APs habilitando-se a visibilidade do endereço IP apenas para a rede cabeada.

Utilizar o AP em modo-ponte (bridge)

Se a rede cabeada for considerada segura ou a rede sem fio e a cabeada forem separadas por um firewall que possa selecionar quem e de que maneira pode usar o IP do AP e acessá-lo, esta poderá ser uma opção a ser considerada.

Ver no AP como suportar um firewall.

Utilizar o AP em modo-ponte (bridge)

Problema 2: Protocolos como TKIP, AES ou até mesmo a autenticação via RADIUS, não funcionam.

A segurança da rede fica limitado, sem poder utilizar um nível de segura superior como o WPA.

5.1.1.6

Ignorar clientes que enviam SSID igual a “ANY”

Ignorar clientes que enviam SSID igual a “ANY”

SSID como “ANY” caracteriza um cliente que busca qualquer AP disponível.

Podendo ser um atacante tentando explorar o ambiente.

Ignorar clientes que enviam SSID igual a “ANY”

Mesmo que não seja um ataque, a conexão de um cliente enviando “ANY” pode encontrar um AP …

… que não corresponda ao perfil do cliente e do grau de sigilo das informações em trânsito.

Ignorar clientes que enviam SSID igual a “ANY”

A boa prática é conscientizar os clientes a usarem sempre o SSID à qual desejam conectar-se e do lado do AP, ignorar clientes que insistirem usar “ANY”.

Ignorar clientes que enviam SSID igual a “ANY”

Configurar o AP para desabilitar os clientes com SSID igual a “ANY”.

Alguns APs possuem este tipo de funcionalidade.

Ignorar clientes que enviam SSID igual a “ANY”

APs baseados em FreeBSD tem um comando iwcontrol para desabilitar clientes com SSID igual a “ANY”.

> iwcontrol --I iface –E 0|1|2|30=disabled1=hide SSID in beacon frames2=ignore clients with a “ANY” SSID3=1 and 2 combined

5.1.2 Defesa dos Equipamentos Clientes

Defesa dos Equipamentos Clientes

Inviolabilidade de comunicação, dados e equipamento do usuário.

Acesso indevido às configurações de segurança dos clientes, para um atacante não conseguir revelar chaves e outrasinformações.

5.1.2.1

Desabilitar comunicação entre os clientes

Desabilitar comunicação entre os clientes

Desabilitar comunicação entre os clientes

TLS

TLS

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols which provide secure communications on the Internet for web browsing, e-mail, Internet faxing, instant messaging and other data transfers.

SSL 3.0 x TLS 1.0

There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same.

Cryptographic Protocols

A security protocol (cryptographic protocol or encryption protocol) is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods.

Cryptographic Protocols

Are widely used for secure application-level data transport.

A cryptographic protocol usually incorporates at least some of these aspects:

Cryptographic Protocols

Key agreement or establishment.Entity authentication. Symmetric encryption and message

authentication. Secured application-level data

transport. Non-repudiation methods.

Characteristics of TLS

Transport Layer Security (TLS) is a cryptographic protocol that is used to secure web (HTTP) connections.

It has an entity authentication mechanism, based on the X.509 system;

Characteristics of TLS

A key setup phase, where a symmetric encryption key is formed by employing public-key cryptography;

An application-level data transport function.

Standard TLS does not have non-repudiation support.

How TLS works ?

TLS handshake

A Client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.

TLS handshake

The Server responds with a ServerHello, containing the chosen protocol version, a random number, cipher, and compression method from the choices offered by the client.

TLS handshake

The Server sends its Certificate (depending on the selected cipher, this may be omitted by the Server).

These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP based certificates.

*

The client uses the CA's public key to validate the CA's digital signature on the server certificate.

If the digital signature can be verified, the client accepts the server certificate as a valid certificate issued by a trusted CA.

**

The client verifies that the issuing Certificate Authority (CA) is on its list of trusted CAs.

The client checks the server's certificate validity period. The authentication process stops if the current

date and time fall outside of the validity period.

TLS handshake

The server may request a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest.

TLS handshake

The Server sends a ServerHelloDone message, indicating it is done with handshake negotiation.

TLS handshake

The Client responds with a ClientKeyExchange which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher).

TLS handshake

The Client and Server then use the random numbers and PreMasterSecret to compute a common secret called the "master secret".

TLS handshake

All other key data is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".

TLS handshake

The Client now sends a ChangeCipherSpec message, essentially telling the Server, "everything I tell you from now on will be encrypted“.

Note that the ChangeCipherSpec is itself a Record Layer protocol, and has type 20, and not 22.

TLS handshake

Finally, the Client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.

TLS handshake

The Server will attempt to decrypt the Client's Finished message, and verify the hash and MAC. If the decryption or verification fails, the handshake is considered failed and the connection should be torn down.

TLS handshake

Finally, the Server sends a ChangeCipherSpec and its encrypted Finished message, and the Client performs the same decryption and verification.

TLS handshake

At this point, the "handshake" is complete and the Application protocol is enabled, with content type of 23. Application messages exchanged between Client and Server will be encrypted.

TLS handshake

If any one of the steps in previous mention fails, the TLS/SSL handshake fails, and the connection is not created.

Handshake Protocol (22)

+ Bits 0–7 8-15 16-23 24–31

0 22 Version (MSB) Version (LSB) Length (MSB)

32 Length (LSB) Message type Message length

64 Message length (cont.) Handshake message

... Handshake message Message type Message length

... Message length Handhshake message

TLS Handshake Message Types

0 HelloRequest 1 ClientHello 2 ServerHello 11 Certificate 12 ServerKeyExchange 13 CertificateRequest 14 ServerHelloDone 15 CertificateVerify 16 ClientKeyExchange 20 Finished

Message length

This is a 3-byte field indicating the length of the handshake data, not including the header.

SSL v3 and TLS Record Layer

+ Bits 0–7 8-15 16-23 24–31

0 Protocol Version (MSB) Version (LSB) Length (MSB)

32 Length (LSB) Protocol Message(s)

... Protocol Message (cont.)

... MAC (optional)

Protocol Field

This field identifies the Record Layer Protocol Type contained in this Record.

20 ChangeCipherSpec 21 Alert 22 Handshake 23 Application

Version Field

This field identifies the major and minor version of SSL for the contained message.

For a ClientHello message, this need not be the highest version supported by the client.

Version (MSB, LSB)

Versions are: 3 | 0 SSL v3 3 | 1 TLS 1.0 3 | 2 TLS 1.1

Length field

The length of protocol message(s), not to exceed 214 bytes.

Protocol message(s) 

One or more messages identified by the Protocol field.

Note that this field may be

encrypted depending on the state of the connection.

MAC field

A message authentication code computed over the protocol message, with additional key material included.

Note that this field may be encrypted, or not included entirely, depending on the state of the connection.

ChangeCipherSpec Protocol

+ Bits 0–7 8-15 16-23 24–31

0 20 Version (MSB) Version (LSB) 0

32 1 1 (CCS protocol type)

Alert Protocol

+ Bits 0–7 8-15 16-23 24–31

0 21 Version (MSB) Version (LSB) 0

32 2 Level Description

Level 

This field identifies the level of alert.

Level Types

1 Warning - connection or security may be unstable.

2 Fatal - connection or security may be compromised,

or an unrecoverable error has occurred.

Description field

This field identifies which type of alert is being sent.

TLS/SSL Security

(1) Exemplo típico do uso de certificado digital

Quando você acessa um site com

conexão segura, como por exemplo o acesso a sua conta bancária pela Internet (vide Parte IV: Fraudes na Internet), é possível checar se o site apresentado é realmente da instituição que diz ser, através da verificação de seu certificado digital.

(2) Exemplo típico do uso de certificado digital

Quando você consulta seu banco pela Internet, este tem que se assegurar de sua identidade antes de fornecer informações sobre a conta.

(3) Exemplo típico do uso de certificado digital

Quando você envia um e-mail importante, seu aplicativo de e-mail pode utilizar seu certificado para assinar "digitalmente" a mensagem, de modo a assegurar ao destinatário que o e-mail é seu e que não foi adulterado entre o envio e o recebimento.

AC

Os certificados digitais possuem uma forma de assinatura eletrônica da AC que o emitiu.

Graças à sua idoneidade, a AC é normalmente reconhecida por todos como confiável, fazendo o papel de "Cartório Eletrônico".

TLS/SSL security measures

The client uses the CA's public key to validate the CA's digital signature on the server certificate.

If the digital signature can be verified, the client accepts the server certificate as a valid certificate issued by a trusted CA.

TLS/SSL security measures

The client verifies that the issuing Certificate Authority (CA) is on its list of trusted CAs.

TLS/SSL security measures

The client checks the server's certificate validity period.

The authentication process stops if the current date and time fall outside of the validity period.

man-in-the-middle attack

In cryptography, a man-in-the-middle attack (MITM) is an attack in which an attacker is able to read, insert and modify at will, messages between two parties without either party knowing that the link between them has been compromised.

man-in-the-middle attack

The attacker must be able to observe and intercept messages going between the two victims.

The MITM attack can work against public-key cryptography and is also particularly applicable to the original Diffie-Hellman key exchange protocol, when used without authentication.

TLS/SSL security measures

To protect against Man-in-the-Middle attacks, the client compares the actual DNS name of the server to the DNS name on the certificate.

TLS/SSL security measures

Protection against several known attacks (including man in the middle attacks), like those involving a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.

TLS/SSL security measures

Numbering all the application records with a sequence number, and using this sequence number in the MACs.

TLS security measure TLS only

Using a message digest enhanced with a key (so only a key-holder can check the MAC).

This is specified in RFC 2104.

TLS/SSL security measures

The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.

TLS security measure TLS only

The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together.

This provides protection if one of these algorithms is found to be vulnerable.

TLS/SSL security measures

SSL v3 improved upon SSL v2 by adding SHA-1 based ciphers, and support for certificate authentication.

Additional improvements in SSL v3 include better handshake protocol flow and increased resistance to man-in-the-middle attacks.

EAP-TLS

Usado para autenticação.Certificados digitais entre o cliente e o

servidor de autenticação (RADIUS), tendo o AP como intermediário.

A autenticação pode ser mútua.Baseia-se na comprovação da

autenticidade (os certificados do cliente e do servidor foram assinados pela mesma AC).

EAP-TLS

Quando o RADIUS aceita os certificados, ele informa ao AP que está permitindo o acesso à rede da máquina do cliente (neste caso, não há autenticação do usuário).

Cenário para EAP-TLS - Cliente

Certificado digital do cliente, assinado por AC.

Chave Privada do Certificado-Cliente.

Senha da Chave Privada do Cliente.

Cenário para EAP-TLS - AP

Porta que está rodando o serviço RADIUS (padrão 1812)

Senha de acesso ao serviço RADIUS.

Cenário para EAP-TLS - Servidor

Certificado digital do servidor, assinado por AC.

Chave Privada do Certificado-Servidor.Senha da Chave Privada do Servidor.Permitir acesso da rede/IP do AP

(client.conf, no caso FreeRADIUS).Validação do usuário em arquivo local,

sistema ou em uma base externa (LDAP).