Métodos de Defesa Capítulo 5.

Apresentação em tema: "Métodos de Defesa Capítulo 5."— Transcrição da apresentação:

1 Métodos de Defesa Capítulo 5

2 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.

3 5.1.1 Defesa do Equipamento

4 Defesa do Equipamento Concentrador
Proteção contra acesso não autorizado. Proteção contra DoS Garantir a segurança e privacidade dos clientes. Demais formas de atques

5 Desabilitar a difusão de SSID
Desabilitar a difusão de SSID

6 Modificar o nome SSID padrão
Modificar o nome SSID padrão

7 Substituição do Endereço MAC do AP
Substituição do Endereço MAC do AP

8 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.

9 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.

10 Substituição do Endereço MAC do AP
Esse procedimento é possível através de APs baseados em sistemas operacionais apropriados. OpenWRT

11 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 WRT54G Ver Asus WL500G

12 Desabilitar acessos ao AP via rede sem fio
Desabilitar acessos ao AP via rede sem fio

13 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 ( x.x ou 10.0.x.x) fornecidos pelo fabricante.

14 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.

15 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.

16 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.

17 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.

18 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.

19 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 ???

20 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.

21 Utilizar o AP em modo-ponte (bridge)
Utilizar o AP em modo-ponte (bridge)

22 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.

23 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.

24 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.

25 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”).

26 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.

27 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.

28 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.

29 Ignorar clientes que enviam SSID igual a “ANY”
Ignorar clientes que enviam SSID igual a “ANY”

30 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.

31 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.

32 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”.

33 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.

34 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|3 0=disabled 1=hide SSID in beacon frames 2=ignore clients with a “ANY” SSID 3=1 and 2 combined

35 5.1.2 Defesa dos Equipamentos Clientes

36 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.

37 Desabilitar comunicação entre os clientes
Desabilitar comunicação entre os clientes

38 Desabilitar comunicação entre os clientes

39 Desabilitar comunicação entre os clientes

40 TLS

41 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, , Internet faxing, instant messaging and other data transfers.

42 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.

43 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.

44 Cryptographic Protocols
Are widely used for secure application-level data transport. A cryptographic protocol usually incorporates at least some of these aspects:

45 Cryptographic Protocols
Key agreement or establishment. Entity authentication. Symmetric encryption and message authentication. Secured application-level data transport. Non-repudiation methods.

46 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;

47 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.

48 How TLS works ?

49 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.

50 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.

51 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.

52 * 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.

53 ** 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.

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

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

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

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

58 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".

59 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.

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

61 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.

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

63 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.

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

65 Handshake Protocol (22) 22 + Bits 0–7 8-15 16-23 24–31 Version (MSB)
22 Version (MSB) Version (LSB) Length (MSB) 32 Length (LSB) Message type Message length 64 Message length (cont.) Handshake message ... Handhshake message

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

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

68 SSL v3 and TLS Record Layer
+ Bits 0–7 8-15 16-23 24–31 Protocol Version (MSB) Version (LSB) Length (MSB) 32 Length (LSB) Protocol Message(s) ... Protocol Message (cont.) MAC (optional)

69 Protocol Field This field identifies the Record Layer Protocol Type contained in this Record. 20 ChangeCipherSpec 21 Alert 22 Handshake 23 Application

70 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.

71 Version (MSB, LSB) Versions are: 3 | 0 SSL v | 1 TLS | 2 TLS 1.1

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

73 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.

74 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.

75 ChangeCipherSpec Protocol
+ Bits 0–7 8-15 16-23 24–31 20 Version (MSB) Version (LSB) 32 1 1 (CCS protocol type)

76 This field identifies the level of alert.
Alert Protocol + Bits 0–7 8-15 16-23 24–31 21 Version (MSB) Version (LSB) 32 2 Level Description Level   This field identifies the level of alert.

77 Level Types 1 Warning - connection or security may be unstable.
2 Fatal - connection or security may be compromised, or an unrecoverable error has occurred.

78 This field identifies which type of alert
Description field This field identifies which type of alert is being sent.

79 TLS/SSL Security

80 (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.

81 (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.

82 (3) Exemplo típico do uso de certificado digital
Quando você envia um importante, seu aplicativo de pode utilizar seu certificado para assinar "digitalmente" a mensagem, de modo a assegurar ao destinatário que o é seu e que não foi adulterado entre o envio e o recebimento.

83 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".

84 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.

85 TLS/SSL security measures
The client verifies that the issuing Certificate Authority (CA) is on its list of trusted CAs.

86 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.

87 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.

88 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.

89 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.

90 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.

91 TLS/SSL security measures
Numbering all the application records with a sequence number, and using this sequence number in the MACs.

92 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.

93 TLS/SSL security measures
The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties.

94 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.

95 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.

96 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).

97 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).

98

99 Cenário para EAP-TLS - Cliente
Certificado digital do cliente, assinado por AC. Chave Privada do Certificado-Cliente. Senha da Chave Privada do Cliente.

100 Cenário para EAP-TLS - AP
Porta que está rodando o serviço RADIUS (padrão 1812) Senha de acesso ao serviço RADIUS.

101 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).