O que você precisa saber antes de implementar 802.1x em redes *com* fio

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 para fazer controle de acesso, e a literatura sobre a implementação de 802.1x em ambientes sem fio é fartíssima, 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 aqui 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 no principalmente relacionadas no upgrade e gerência do equipamento atual, e no conjunto de dispositivos que precisam ser suportados pela solução. Para evitar surpresas desagradáveis durante o projeto, coloquei aqui alguns pontos que você precisa saber antes de embarcar nessa:

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

2. 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 Windows antigos (NT 4.0, etc.) e outros. As portas 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 guest VLANs, 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.

3. A Microsoft recomenda 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.

4. 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. Isso é corrigido no Windows Vista, mas 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.

5. Mais grave é um problema específico da implementação do Windows para 802.1x em redes wired: a configuração do 802.1x em interfaces com fio só pode ser feita de forma manual. 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. A alternativa aqui infelizmente é esperar pelo Windows Vista, que implementa estas políticas de grupo e suporte no netsh, ou usar uma implementação de terceiros que permita automatização.

Se você ainda está animado, a Microsoft publica um guia para implementar 802.1x em redes com fio, que está disponível em https://www.microsoft.com/downloads/details.aspx?familyid=05951071-6b20-4cef-9939-47c397ffd3dd&displaylang=en. Em breve vou falar de uma outra solução que também evita que equipamentos indesejáveis acessem os seus recursos de rede: o isolamento de domínios e servidores usando IPsec.

UPDATE: O gerenciamento da configuração do 802.1x pode agora ser feito via políticas de grupo no Windows Vista e no Windows XP Service Pack 3.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  June 18, 2007
  Estou implementando e achei uma documentação do technet que exemplifica a utilização de um servidor de certificado raiz e um outro para emitir os certificados, essa informação confere? Obrigado,