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
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.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 WRT54G
Ver 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|3
0=disabled
1=hide SSID in beacon frames
2=ignore clients with a “ANY” SSID
3=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 applicationlevel 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 nonrepudiation 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 servergenerated 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
64
Message length (cont.)
...
Handshake message
...
Message length
Message length
Handshake message
Message type
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 publickey 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).