Gerenciamento de Segurança - Agosto de 2005
802.1X em Redes com Fio Consideradas Perigosas
Publicado em: 9 de agosto de 2005
Por Steve Riley
Gerente de Programas Sênior
Unidade de Tecnologias e Negócios de Segurança
Veja outras colunas de Gerenciamento de Segurança (em inglês).
Alguns links nesta coluna estão em inglês.
Computadores invasores. Estas não são uma das coisas mais assustadoras que podem infestar sua rede? Você faz de tudo para proteger sua rede, mantém seus clientes com assinaturas anti-malware e atualizações… e no entanto você ainda suspeita que estas máquinas estejam causando problemas na sua rede. Como mantê-las à distância?
Usar o 802.1X para controlar quem acessa uma rede é uma solução cada vez mais aplicada. O 802.1X (http://standards.ieee.org/getieee802/download/802.1X-2001.pdf) é método de controle de acesso baseado em portas definido Institute of Electrical and Electronic Engineers (IEEE) que pode ser configurado para exigir autenticação mútua entre o cliente e a rede. Se não houver autenticação, as comunicações não são permitidas. O 802.1X trabalha com o Extensible Authentication Protocol (EAP, ftp://ftp.rfc-editor.org/in-notes/rfc3748.txt) para autenticar o cliente para a rede e a rede para o cliente, garantindo que ambos os lados se comuniquem com entidades reconhecidas.
Ah, porém existe uma falha fundamental no 802.1X wired que reduz seriamente sua eficácia no afastamento de máquinas invasoras. Descreverei como um ataque pode tirar vantagem de uma fraqueza na maneira como o protocolo é implementado. Mas, em primeiro lugar, vamos dar uma olhada em como o 802.1X funciona.
Como o 802.1X funciona
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) (ftp://ftp.rfc-editor.org/in-notes/rfc1149.txt, ftp://ftp.rfc-editor.org/in-notes/rfc2549.txt) e bongo drum (http://eagle.auc.ca/~dreid). O 802.1X requer um a 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 supplicant (suplicante) faz uma conexão inicial para um para um authenticator (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 authentication server (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. Note que 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. O Windows suporta dois métodos EAP diferentes:
| • | EAP-TLS. 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. |
| • | EAP Protegido (PEAP). 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.
Usando o 802.1X para segurança com fio
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 digita que apresenta ao autenticar os clientes. Só isso já seria uma proposta bastante onerosa se você certificados de autoridades públicas, então economize um pouco e construa uma autoridade de certificados corporativos do Windows. 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 stack do 802.1X para o Windows 2000 (http://support.microsoft.com/kb/313664).
Tanto no Windows XP quanto no Windows 2000, 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 sua 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.
Porque o 802.1X em redes com fio é insuficiente
O 802.1X é o alicerce perfeito para a segurança de redes sem fio, que já exploramos diversas vezes no passado em conferências e documentações no site da Microsoft (http://www.microsoft.com/wifi). Mas usá-lo para segurança em redes com fio traz desvantagens significativas. Trabalhar com dispositivos não participativos, como discutimos acima, é 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 Windows 2000 e Windows XP 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.
Finalmente, 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. (Obrigado Svyatoslav Pidgorny, MVP da Microsoft para segurança, por me mostrar esta vulnerabilidade.)
A preparação de um ataque requer acesso físico à rede. Um invasor precisa desconectar um computador (vamos chamá-lo e "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 já descrito aqui. 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:
1. | O computador sombra envia um pacote SYN para um servidor numa rede protegida. |
2. | O servidor retorna um SYN-ACK, que tanto a sombra quanto a vítima recebem. |
3. | O computador vítima não está esperando este SYN-ACK então ele retorna um RST para o servidor. |
4. | O servidor retorna um RST-ACK (reconhecendo o recebimento do RST e enviando seu próprio), que tanto a sombra quanto a vítima recebem. |
5. | A sombra não está esperando este RST-ACK, mas obedecerá e finalizará a conexão. |
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.
Então, o que devo fazer?
Em primeiro lugar, compreenda 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ão-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, eu realmente aconselho 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. Na Microsoft usamos o IPsec para implementar uma noção que chamamos de isolamento do domínio em nossa rede corporativa. Ele funciona bem para nós e sugerimos que você experimente também. Saiba mais aqui:
| • | |
| • | Isolamento do Domínio e Servidor Usando o IPsec e Política de Grupo |
Procure por "isolamento do domínio" no site Microsoft.com para encontrar ainda mais informações. Os princípios que descrevemos nos documentos sobre o isolamento do domínio representam o alicerce para as futuras tecnologias de proteção de acesso à rede (network access protection -NAP) no Windows Longhorn Server. É importante começar a planejar agora. A implementação do isolamento do domínio hoje o colocará na dianteira em relação ao isolamento do cliente e à checagem da saúde no futuro.