802.1X em redes com fio consideradas prejudiciais -- Coluna do TechNet - Gerenciamento de segurança - agosto de 2005

802.1X em redes com fio consideradas prejudiciais

Publicado em: 9 de agosto de 2005

Escrito por Steve Riley
Gerente de programas sênior
Unidade de tecnologia e negócios de segurança

Consulte outrascolunas de Gerenciamento de segurança.

Computadores não autorizados. Computadores não autorizados não são as coisas mais assustadoras que podem infestar sua rede? Você faz o máximo para construir uma rede protegida, mantém seus clientes em dia com atualizações e assinaturas de antivírus... e ainda assim suspeita que essas máquinas não autorizadas estejam provocando problemas em sua rede. Como evitar que elas entrem?

O uso do 802.1X para controlar quem pode acessar uma rede é uma solução cada vez mais popular. O 802.1X (http://standards.ieee.org/getieee802/download/802.1X-2001.pdf) é um método de controle de acesso baseado em portas definido pelo IEEE (Institute of Electrical and Electronic Engineers) que pode ser configurado para exigir autenticação mútua entre o cliente e a rede. Se a autenticação não ocorrer, nenhuma comunicação será permitida. O 802.1X funciona com o protocolo EAP (ftp://ftp.rfc-editor.org/in-notes/rfc3748.txt) para autenticar o cliente na rede e a rede no cliente, garantindo que os dois lados se comuniquem com entidades reconhecidas.

Infelizmente, há uma falha básica no 802.1X com fio que reduz consideravelmente sua eficácia em evitar que máquinas não autorizadas entrem. Descreverei como uma invasão pode tirar proveito de um ponto fraco na maneira como o protocolo é implementado. Mas primeiro, vamos rever como o 802.1X funciona.

Funcionamento do 802.1X

O 802.1X foi projetado para funcionar em qualquer tipo de rede: com fio, sem fio, de arame farpado e até mesmo pombo correio (ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt, ftp://ftp.rfc-editor.org/in-notes/rfc2549.txt) e tambor (http://eagle.auc.ca/~dreid). O 802.1X precisa de uma infra-estrutura de suporte, especialmente de clientes que ofereçam suporte ao 802.1X, comutadores de LAN e pontos de acesso sem fio que podem participar do 802.1X, um servidor RADIUS e de algum tipo de banco de dados de contas (como o Active Directory).

Um cliente, chamado de suplicante, faz uma conexão inicial a um autenticador, ao comutador da LAN ou a um ponto de acesso sem fio. O autenticador é configurado para exigir o 802.1X de todos os suplicantes e ignorar qualquer conexão de entrada que não esteja de acordo. O autenticador pede a identidade do suplicante que será encaminhada ao servidor de autenticação (RADIUS).

O RADIUS segue qualquer mecanismo necessário para autenticar o cliente de entrada. Geralmente, isso envolve a configuração de uma conversação do 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ção do EAP. Observe que o próprio EAP não define nenhum tipo de segurança própria; os protocolos de autenticação usados devem incorporar sua própria segurança. O Windows oferece suporte a dois métodos diferentes de EAP:

• EAP-TLS. O servidor de autenticação configura uma sessão de TLS (Transport Layer Security) com o suplicante. O servidor envia seu certificado digital ao suplicante, que é validado pelo suplicante. Em seguida, o suplicante envia seu certificado digital ao servidor de autenticação, que é validado pelo servidor. Assim, o cliente e a rede se autenticam mutuamente e, desde que cada lado confie no certificado do outro e os certificados sejam válidos, a autenticação é bem-sucedida.

• PEAP (EAP protegido). O PEAP inicia como o EAP — o servidor de autenticação configura uma sessão de TLS com o suplicante e envia seu certificado digital ao suplicante para validação. Se o suplicante confiar no certificado, ele usa um de vários métodos para autenticar-se com o servidor. No momento, o único método de autenticação do lado do suplicante no Windows é o MS-CHAPv2, no qual o suplicante usa contas tradicionais (identificações do usuário ou do computador e senhas) para a autenticação. Isso é chamado de PEAP-EAP-MS-CHAPv2. Observe que PEAP-EAP-TLS também é uma opção configurável, embora não exista nenhum motivo para essa escolha. Ele estabelece uma segunda sessão de TLS completamente separada dentro da primeira. Essa duplicação de sessões de TLS é mais lenta do que o EAP-TLS puro.

Quando o RADIUS tiver autenticado o suplicante, o suplicante terá permissão para se comunicar na rede por trás do autenticador (lembre-se de que esse é o comutador da LAN ou o ponto de acesso sem fio). Embora um autenticador tenha uma porta de rede física, considere-o como tendo duas "portas virtuais". O tráfego de suplicantes autenticados passa pela porta controlada, que bloqueia o tráfego de suplicantes não autenticados. Durante o processo de autenticação, o autenticador precisa comunicar-se com o servidor RADIUS, o que ocorre por meio da porta não controlada. Depois da autenticação do suplicante, a porta controlada muda para um estado conectado para aquele suplicante.

Usando o 802.1X para segurança com fio

Para que o 802.1X seja eficiente em redes com fio, a infra-estrutura precisa estar suficientemente atualizada. Todos os comutadores da rede, ou pelo menos aqueles aos quais os clientes e servidores se conectam, devem oferecer suporte ao 802.1X. Cada comutador requer um certificado digital que ele apresenta aos clientes ao autenticá-los. Isso poderá ser uma proposta muito cara, se você usar certificados de autoridades públicas; portanto, economize um pouco e construa uma autoridade de certificação empresarial do Windows. Todos os computadores que ingressarem em seu domínio confiarão nessa CA e, portanto, confiarão nos certificados emitidos por ela.

Todos os seus clientes devem ter uma pilha de IP compatível com o 802.1X. Se você estiver executando o Windows XP, a pilha interna do Windows XP foi testada e aprovada para uso do 802.1X em redes com fio. Se você não estiver executando o Windows XP (e não puder atualizar), terá uma opção: a Microsoft lançou uma pilha do 802.1X para o Windows 2000 (https://support.microsoft.com/kb/313664).

No Windows XP e no Windows 2000, pode ocorrer um problema conhecido. Se você tiver configurado o 802.1X apenas para autenticação de máquina (e não para máquina e usuário), se estiver usando o PEAP (não o EAP-TLS) e se a senha da conta da máquina do computador estiver vencida, o computador não poderá fazer logon no domínio. Duas DLLs envolvidas na autenticação de clientes não trocam mensagens de maneira apropriada, principalmente porque foram escritas muito antes do 802.1X fazer parte do design. É quase impossível alterar essas DLLs. Isso exigiria um design completamente novo delas, e há muitos outros riscos de dependência. Você deve estar configurado com o PEAP e a autenticação apenas de máquina. Se estiver usando o EAP-TLS, o problema não existirá porque a autenticação será tratada por um conjunto diferente de DLLs. Se estiver usando a autenticação de máquina e de computador, a senha da máquina será redefinida quando a autenticação do usuário for bem-sucedida.

E sobre os dispositivos de rede que não podem participar do 802.1X? Dispositivos como impressoras, dispositivos de armazenamento de rede, um PC DOS antigo que executa algum aplicativo arcaico, decrépito e totalmente sem suporte, mas com uma missão crítica? Lembre-se de que, em primeiro lugar, a razão da implementação do 802.1X é garantir que apenas dispositivos autorizados possam se comunicar. Agora você precisa criar uma exceção. Mas antes de fazer isso, sua diretiva de segurança permite criá-la? Verifique primeiro. Também será necessário criar exceções para a inicialização de novos sistemas (talvez um segmento fisicamente isolado que esteja isento do 802.1X). Observe que a necessidade do 802.1X eliminará a habilidade de usar a inicialização PXE na rede.

Por que o 802.1X em redes com fio é insuficiente?

O 802.1X é a base perfeita para segurança sem fio, o que exploramos muitas vezes no passado em conferências e em documentações no site da Microsoft (https://www.microsoft.com/wifi). Mas seu uso para segurança com fio tem algumas desvantagens significativas. Trabalhar com dispositivos não participantes, como discutimos acima, é uma delas. A falta de capacidade de gerenciamento é outra: na diretiva de grupo AD, existem vários objetos de diretiva de grupo para você gerenciar o 802.1X em redes sem fio. Esses GPOs não existem para interfaces com fio e não existem APIs publicadas para gerenciar computadores cliente do 802.1X com fio. Algumas razões arquitetônicas impedem a adição de GPOs no Windows 2000 e no Windows XP para 802.1X com fio. Devido a essa falta de capacidade de gerenciamento centralizado, a implementação do 802.1X em larga escala no Windows não é viável.

Finalmente, há um ponto fraco importante no protocolo: ele autentica apenas o estabelecimento de uma conexão. Quando um suplicante faz a autenticação e a porta do comutador é aberta, comunicações adicionais entre o suplicante e o comutador não são autenticadas. Isso cria uma situação em que é possível que um invasor entre na rede. (Meus agradecimentos a Svyatoslav Pidgorny, MVP de segurança da Microsoft, por me mostrar essa vulnerabilidade.)

A configuração da invasão requer acesso físico à rede. Um invasor precisa desconectar um computador (que chamaremos de a "vítima") de sua porta do comutador da rede protegida pelo 802.1X, conectar um hub à porta, conectar a vítima ao hub e conectar um computador invasor (que chamaremos de o "sombra") ao hub. Isso será muito fácil se o invasor estiver fisicamente dentro de suas instalações e se os conectores de Ethernet estiverem acessíveis. Ou o invasor pode conectar-se a um ponto de acesso não gerenciado no hub e conduzir a invasão a partir do seu estacionamento. (Naturalmente, o invasor pode tentar ocultar-se desabilitando essa transmissão de SSI do AP.)

A breve interrupção da conexão da vítima à rede não interferirá no sucesso do invasor. Quando o computador vítima for reconectado, ele se autenticará no comutador novamente. Não importa que um hub esteja no caminho agora, porque um hub é um pouco mais do que um cabo com portas. Eletricamente, a vítima ainda está conectada ao comutador.

Em seguida, o invasor configura os endereços MAC e IP do computador sombra com os mesmos endereços do computador vítima. Uma pequena pesquisa na rede revelará isso. O invasor também configura um firewall do host para eliminar todo o tráfego de entrada que não seja uma resposta às comunicações que iniciou.

Agora, eis porque o 802.1X em uma rede com fio é realmente insuficiente. Após o computador vítima ter se autenticado e a porta do comutador estar aberta, o invasor pode conectar-se a outros recursos da rede protegida. Isso ocorre porque não existe nenhuma autenticação por pacote do tráfego depois que a porta é aberta. Como o computador sombra tem os mesmos endereços MAC e IP que o computador vítima, do ponto de vista do comutador, parece que há apenas um único computador conectado à porta. A falta de acompanhamento de autenticação por pacote do 802.1X cria a situação para esta invasão intermediária que acabei de descrever. O 802.1X autentica apenas a conexão. Ele assume que todo o tráfego que flui pela conexão é legítimo. Essa suposição é o defeito básico do 802.1X.

Observe que o invasor pode comunicar-se apenas por meio de protocolos sem estados, como ICMP ou UDP. Assim, o invasor pode executar ping nos computadores da rede e receber uma concessão de DHCP (o mesmo endereço IP da vítima). Mas o invasor não pode se comunicar por meio de TCP na rede, pois o computador vítima redefinirá todas as conexões iniciadas pelo host do sombra. Esta é a seqüência:

1. O computador sombra envia um pacote SYN a um servidor na rede protegida.

2. O servidor retorna um SYN-ACK, que tanto o sombra quanto a vítima recebem.

3. O computador vítima não está esperando esse SYN-ACK e retorna um RST ao servidor.

4. O servidor retorna um RST-ACK (confirmando o RST recebido e enviando o seu próprio), que tanto o sombra quanto a vítima recebem.

5. O sombra não está esperando esse RST-ACK mas irá obedecer e encerrar a conexão.

Há uma exceção muito interessante à regra. Se o computador vítima estiver executando um firewall que elimina SYN-ACKs de entrada não solicitados, o que a maioria faz, a vítima não processará o SYN-ACK recebido na etapa 2 e, portanto, não enviará o RST ao servidor. O restante da seqüência acima não ocorrerá e o computador sombra poderá ter acesso completo à rede protegida. Essa é a única ocorrência que conheço em que um firewall pessoal em um computador pode reduzir a segurança do restante da rede! Naturalmente, isso não é motivo para que você não implante os firewalls pessoais. Seus benefícios excedem grandemente a probabilidade de essa invasão realmente ocorrer.

Então, o que você pode fazer?

Primeiro, entenda o escopo da invasão. Redes sem fio não são vulneráveis porque o 802.1X+EAP cria sessões mutuamente autenticadas com chaves de criptografia por suplicante, (isso é chamado de “WEP dinâmico”). Como as chaves nunca são enviadas pelo ar, a invasão do computador sombra não funcionará; ele não terá como adquirir a chave. O sombra não pode conectar-se ao ponto de acesso onde o computador vítima já está conectado. Portanto, de certa forma, redes sem fio com 802.1X+EAP são realmente mais seguras do que redes com fio.

Mas, para redes com fio, eu recomendo o IPsec em vez do 802.1X. Não, o IPsec não evitará que um invasor obtenha um endereço IP ou que se comunique pela LAN (basta desabilitar a porta do comutador de alguém que está tentando executar DoS em sua rede), mas ele evitará que o invasor obtenha outros recursos protegidos pelo IPsec. A conexão e a autenticação de pacotes do IPsec é que o tornam uma opção superior ao 802.1X. Na Microsoft, usamos o IPsec para implementar uma noção que chamamos de isolamento de domínio em nossa rede corporativa. Ela funciona bem para nós e sugerimos que você a experimente também. Saiba mais sobre esse assunto aqui:

• Improving Security with Domain Isolation (em inglês)

• Server and Domain Isolation Using IPsec and Group Policy (em inglês)

Pesquise “domain isolation” no Microsoft.com para localizar ainda mais informações. Os princípios que descrevemos nos documentos sobre isolamento de domínio são a base para as tecnologias de proteção de acesso à rede (NAP) no Windows Longhorn Server. É importante começar o planejamento para isso agora. A implementação de um isolamento de domínio na rede hoje o colocará à frente no caminho para o isolamento de clientes e a verificação da integridade ainda mais eficientes.