c



c



 
  



   


  

802.1x é o padrão definido pela IEEE para autenticação para acesso a portas de
rede, onde um sistema tem que provar sua identidade antes de poder se conectar a
rede, e é o método mais popular para controle de acesso em redes wireless. Tanto os
padrões WPA quanto WPA2 utilizam 802.1x em ambientes sem fio, seja usando senhas
ou certificados digitais.

O 802.1x também pode ser utilizado para controle de acesso em redes com fio,
o que permite que uma organização possa efetivamente controlar quem pode plugar
sistemas em sua rede corporativa. A autenticação normalmente é feita usando senhas
(PEAP) ou certificados digitais (EAP-TLS), e pode autenticar tanto o equipamento quanto
o usuário que está logado. O 802.1x tem a vantagem de ser um padrão de fato
suportado por basicamente todos os fabricantes de equipamentos de rede e de sistema
operacional, e realmente fornece segurança ao contrário de soluções ͞tabajara͟ como
controle de MAC address por porta e uso de IP estático.

A implementação do 802.1x em redes com fio no entanto é um outro bicho

completamente diferente de um ambiente wireless, e precisa ser avaliada e planejada
com muito mais cuidado. As diferenças estão principalmente relacionadas ao upgrade e
gerência do equipamento atual, e no conjunto de dispositivos que precisam ser
suportados pela solução.
   ! 

O 802.1x é projetado para trabalhar em qualquer tipo de rede: com ou sem fio,
barbed wire (arame farpado), e até Carrier pigeon ( pombo correio ) e bongo drum. O
802.1x requer uma infra-estrutura de suporte, clientes nominais que suportem o 802.1x,
switches do LAN e pontos de acesso sem fio que podem participar no 802.1x, um
servidor RADIUS, e algum tipo de banco de dados de contas ( como o Active Directory ).

Um cliente, chamado suplicante faz uma conexão inicial para um autenticador,

um switch de rede ou um ponto de acesso sem fio. O autenticador é configurado para
exigir o 802.1X de todos os suplicantes e irá ignorar qualquer conexão de entrada que
não se adequar. O autenticador solicita ao suplicante sua identidade, a qual ele passará
adiante para o à

à
 

(RADIUS).

O RADIUS segue qualquer mecanismo necessário para autenticar o cliente que

está entrando. Em geral, isto envolve a instalação de uma conversa EAP entre o
suplicante e o servidor de autenticação (o autenticador é apenas um dispositivo de
passagem aqui) e o estabelecimento de um método de autenticação dentro da conversa
EAP. O EAP em si não define qualquer tipo de segurança sozinho - os protocolos de
identificação usados devem incorporar sua própria segurança. É suportado dois
métodos EAP diferentes mencionados acima, eles são:

° "#. O servidor de autenticação instala uma sessão de segurança da

camada de transporte (transport layer security - TLS) com o suplicante. O servidor
envia seu certificado digital para o servidor de autenticação, que o servidor valida.
Dessa forma o cliente e a rede se autenticaram mutuamente, e desde que cada lado
confie no certificado, e o que certificado seja válido, a autenticação é bem sucedida.

°  

 $° %. O PEAP começa como um EAP- o servidor de
autenticação instala uma sessão TLS com o suplicante e envia seu certificado digital
para o suplicante para validação. Se o suplicante confia no certificado, ele usa um dos
diversos métodos para se autenticar para o servidor. Neste momento o único método
de autenticação disponível do lado do suplicante no Windows é o MS-CHAPv2, no qual
 o suplicante usa contas tradicionais (IDs e senhas de usuários e computadores) para
autenticar. Este método é chamado de PEAP-EAP-MS-CHAPv2. Note que o PEAP-EAP-
TLS é também um switch configurável, apesar de não haver razão alguma para escolhê-
la. Ela estabelece uma segunda sessão TLS completamente separada dentro da
primeira; esta duplicação de sessões TLS é mais lenta do que o EAP-TLS apenas.

Assim que o RADIUS tenha autenticado o suplicante, o suplicante pode se

comunicar na rede atrás do autenticador (lembre-se, esta é o switch LAN ou o ponto de
acesso sem fio). Apesar de um autenticador ter uma porta de rede física, pense nele
como tendo duas "portas virtuais". O tráfego dos suplicantes autenticados passa pela
porta controlada, que bloqueia o tráfego de suplicantes não autenticados. Durante o
processo de autenticação o autenticador deve se comunicar com o servidor RADIUS, o
que ocorre através da porta não controlada. Após a autenticação de um suplicante, a
porta controlada transita para um estado conectado para aquele suplicante.

Para que o 802.1X seja eficiente em redes com fio, a infra-estrutura precisar ser
razoavelmente atualizada. Todos os switches em sua rede ou pelo menos aquelas às
quais os clientes e servidores se conectam , devem suportar o 802.1X. Cada switch
requer um certificado digital que apresenta ao autenticar os clientes. Só isso já seria
uma proposta bastante onerosa se você tem certificados de autoridades públicas, então
economize um pouco e construa uma autoridade de certificados corporativos. Todos os
computadores que fazem parte do seu domínio irão confiar neste CA (certificate
authoritiy - autoridade de certificado) e portanto confiarão nos certificados que ele
emite.

Todos os seus clientes devem ter um stack de IP capaz para 802.1X. Se você
estiver executando o Windows XP, o stack embutido no Windows XP foi testado e
aprovado para o uso do 802.1X em redes com fio. Se você não estiver executando o
Windows XP (e não puder atualizar), você tem um switch: a Microsoft lançou um  
do 802.1X para outras versões.

Um problema conhecido pode surgir se você tiver configurado o 802.1X apenas

para autenticação da máquina (e não da máquina e do usuário) e estiver usando PEAP (e
não EAP-TLS), e a senha da conta da sua máquina tiver validade vencida, o computador
não poderá fazer o logon no domínio. Os dois DLLs envolvidos na autenticação do
cliente não trocam mensagens adequadamente principalmente porque eles foram
escritos muito antes do 802.1X fazer parte do design. É praticamente impossível alterar
estes DLLs; exigiria que o seu design fosse completamente refeito e isso é muito
arriscado. Você deve estar configurado com PEAP e autenticação apenas na máquina. Se
você estiver usando EAP-TLS, o problema não existe porque a autenticação é
manipulada através de um conjunto de DLLs diferente. Se você estiver usando
autenticação de computador e máquina, a senha da máquina será zerada quando
ocorrer a autenticação bem-sucedida do usuário.

E aqueles dispositivos de rede que não podem fazer parte do 802.1X? Coisas
como impressoras, dispositivos de armazenamento de rede, aqueles velhos PCs
executando DOS, caquéticos, totalmente incapazes de suportar aplicações que são, no
entanto, de missão crítica? Lembre-se do porquê da implementação do 802.1X, e terá
certeza de que apenas dispositivos autorizados podem se comunicar. Agora você precisa
criar uma exceção. Mas, antes de fazer isto, verifique se é permitido pela sua política de
segurança. Você também terá que criar exceções para o desenvolvimento autônomo
(bootstrapping) de novos sistemas (talvez num seguimento isolado fisicamente que está
dispensado no 802.1X). Note que a exigência do 802.1X eliminará sua capacidade de
usar a inicialização (boot) PXE em sua rede.

= & ' 

O 802.1X é o alicerce perfeito para a segurança de redes sem fio. Mas usá-lo
para segurança em redes com fio traz desvantagens significativas. Trabalhar com
dispositivos não participativos, é uma delas. A falta de capacidade de gerenciamento é
outra: num grupo de política de grupo AD, diversos objetos da política de grupo existem
para o gerenciamento do 802.1X em redes sem fio. Estes GPOs não existem para
interfaces com fio, e não existem APIs publicadas para o gerenciamento de
computadores clientes.

802.1X com fio. Algumas razões arquitetônicas previnem a adição de GPOs ao

para 802.1X com fio. Dada a falta de capacidade de gerenciamento centralizado, a
implantação do 802.1X em larga escala no Windows não é viável.
 —inalmente, existe uma fraqueza importante no protocolo: ele autentica apenas
no momento de estabelecimento de uma conexão. Assim que o suplicante autentica e a
porta do switch é aberta, as demais comunicações entre o suplicante e o switch não são
autenticadas. Isto cria uma situação na qual é possível para um invasor fazer parte da
rede.

A preparação de um ataque requer acesso físico à rede. Um invasor precisa

desconectar um computador (vamos chamá-lo de "vítima") de sua porta de switch da
rede protegida 802.1X, conectar um hub à porta, conectar a vítima ao hub, e conectar
um computador de ataque (que chamaremos agora de "sombra") ao hub. Isto é
bastante fácil se o invasor estiver fisicamente dentro de suas instalações e se as suas
tomadas da Ethernet estiverem acessíveis. Ou o invasor pode conectar uma ponta de
acesso não gerenciada ao hub e então conduzir o ataque de seu estacionamento. (É
claro que o invasor pode tentar se esconder inabilitando este broadcast SSI da AP.)

A breve desconexão da vítima da rede não interferirá no sucesso do ataque.

Quando o computador vítima for re-conectado, ele autentica para o switch novamente.
Não importa se um hub estiver no caminho agora, porque um hub é praticamente um
fio com portas. Eletricamente, a vitima ainda estará conectada ao switch.

Em seguida o invasor configura os endereços de IP e MAC do computador

sombra para que sejam iguais aos do computador vítima. Um exame rápido na rede
revelará isso. O invasor também configura um firewall host para deixar cair todo o
tráfego interno que não seja uma resposta às comunicações que ele iniciou.

Agora, eis porque o 802.1X em uma rede com fio é realmente insuficiente. Após
o computador vítima ter autenticado e a porta switch ter aberto, o invasor pode se
conectar aos recursos na rede protegida. É por isso que não existe autenticação do
tráfego por pacote assim que a porta é aberta. Como o computador sombra tem os
mesmos endereços de IP e MAC do computador vítima, do ponto de vista do switch
parece apenas que existe um único computador conectado à porta. A falta de
autenticação sucessiva por pacote do 802.1X cria a situação para este ataque de man-in-
the-middle. O 802.1X autentica apenas a conexão; ele assume que todo o tráfego que
passa pela conexão é legítimo. Esta suposição é principal falha do 802.1X.

Note que um invasor pode se comunicar apenas através de protocolos sem

declaração como o ICMP ou UDP. Portanto o invasor poderia "pingar" computadores na
rede e receber um DHCP de empréstimo (o mesmo endereço de IP da vítima). Mas o
invasor não pode se comunicar através do TCP com a rede o computador vítima irá zerar
qualquer conexão iniciada pelo host sombra. Eis a sequência:




 


 

 

















 

 
 



 







 




!




"#
 









"#
%&


 


"#



 


'(

 

 
 


 


 


 


"#
 
 


* !+ 


,

Existe uma exceção muito interessante à essa regra. Se o computador vítima

estiver executando um firewall que deixe cair SYN-ACKs de entrada não solicitados, o
que a maioria faz, a vítima não processará o SYN-ACK recebido na fase 2 e portanto não
enviará o RST para o servidor. O resto da seqüência acima não ocorrerá e o computador
sombra pode ter acesso total à rede protegida. Esta é a única instância que conheço
onde um firewall pessoal num computador pode reduzir a segurança do restante da
rede! É claro que isto não deve impedir a implantação de firewalls pessoais; seus
benefícios superam de longe a probabilidade deste ataque realmente ocorrer.

#(

Compreendendo o escopo do ataque. Redes sem fio não são vulneráveis porque
o 802.1X+EAP cria sessões com chaves de encriptação por suplicante, (isto é chamado
"WEP dinâmico"). Como as chaves nunca são enviadas pelo ar, o ataque do computador
sombra não funcionará, não há forma de se obter a chave. O sombra é incapaz de se
conectar ao ponto de acesso onde o computador vítima já está conectado. Portanto, de
certa forma, as redes sem fio com 802.1X+EAP são na verdade mais seguras do que as
com fio.
 Mas para as redes com fio, é muito utilizado o IPsec ao invés do 802.1X. Não, o
IPsec não impedirá que um invasor obtenha um endereço de IP ou que se comunique
através de sua LAN (apenas inabilite a porta switch para alguém tentando DoS na sua
rede), mas ele impedirá que o invasor obtenha ouros recursos protegidos IPsec. É a
conexão Ipsec e a autenticação do pacote que torna esta opção melhor que o 802.1X.

° 



Todas as portas de rede corporativa precisam ter autenticação 802.1x

habilitadas para obter segurança, com a exceção de lugares onde a segurança física é
estritamente mantida (como datacenters). Manter em um mesmo segmento de rede
portas autenticadas e portas sem autenticação é deixar aberto a porta para a entrada de
um atacante. Isso significa que provavelmente todo o seu equipamento de rede terá que
suportar e estar configurado com autenticação e pode implicar em um custo para fazer
upgrade do seu equipamento de rede atual.

Você terá que lidar com o problema de ter na rede equipamentos que não
suportam autenticação 802.1x, como impressoras de rede, sistemas Operacionais
antigos e outros. Asportas utilizadas por estes sistemas terão que ser identificadas e
colocadas em VLANs"inseguras", isoladas via firewall das VLANs "seguras" que exigem
autenticação de porta. Isto cria na verdade toda uma infraestrutura de rede separada
para ser mantida, que pode ser um problema ainda maior por exemplo em organizações
que tem uma estrutura distribuída em agências e filiais.

(Alguns equipamentos de rede suportam  
   , onde são colocadas

automaticamente os sistemas que não suporta 802.1x ou que falham a autenticação.
Isso elimina o trabalho de "cadastrar" as portas usadas por estes sistemas.)

Uma abordagem também usada em muitas organizações é criar "VLANs de

impressão"dedicadas somente para impressoras, e ter os servidores de impressão com
duas interfaces de rede, uma para a rede corporativa, e outra para essa VLAN. Isso não
só elimina o problema com 802.1x como também isola as impressoras, muitas delas
rodando Windows ou outros sistemas operacionais e fora do sistema de patches
regulares da organização, de serem vetores de ataque contra sistemas corporativos.
 Sempre utilizar autenticação por equipamento, mesmo que você também faça
autenticação por usuário. O motivo para essa recomendação é que se o sistema não
consegue se autenticar por si só, ele somente vai entrar na rede depois do usuário se
logar, e dessa forma não vai receber políticas de grupo de máquina ou rodar scripts de
startup. A recomendação fica ainda mais óbvia no caso de servidores.

Existe duas formas de autenticação principais que podem ser usadas para
autenticar o equipamento, PEAP (senhas) ou EAP-TLS (certificados digitais). PEAP
normalmente usa a senha da conta de máquina do sistema no Active Directory, que é
mantida pelo próprio Windows e que torna todo o processo de autenticação
transparente. Existe no entnato um problema em utilizar 802.1x em redes com fio com
autenticação de equipamento por PEAP: quando a senha do Windows no AD expira, o
sistema não consegue se autenticar na rede para fazer a troca e fica sem acesso a rede
até que uma intervenção manual seja feita. Para evitar isso hoje a recomendação é que,
se você usa autenticação de equipamento usando senha no AD, habilite também a
autenticação por usuário Ou use certificados digitais, que é tão fácil de implementar e
manter quanto senhas do AD (se você tiver uma CA Windows, é claro) e não tem esse
problema.

Mais grave é um problema específico da implementação do Windows para

802.1x em redes wired: aconfiguração do 802.1x em interfaces com fio só pode ser feita
de formamanual. Isto é, não existem políticas de grupo, interface para scripts ou chaves
de registry para configurar o suplicante em interfaces com fio (elas existem para
interfaces wireless). Um problema pequeno para redes pequenas, mas normalmente
inaceitável para redes corporativas onde tudo deve ser automatizado.