Porteiro competente. Usuários de redes sem fio estão. Desbloqueio de porta O ambiente de autenticação do IEEE 802.1X inclui três componentes:

Transcrição

1 Controle de acesso em redes com fio com o IEEE 802.1X SEGURANÇA Porteiro competente Você achava que o padrão IEEE 802.1X era apenas para redes sem fio? Veja como configurar um sistema de controle de acesso de rede com ele e um servidor FreeRADIUS. por Sven Übelacker e Nils Magnus Supreet Vaid Usuários de redes sem fio estão acostumados com o ritual de entrada de dados de login antes da conexão à rede local. O padrão IEEE 802.1X [1] define uma técnica para o controle de acesso a redes baseado em portas usado na maioria dos pontos de acesso sem fio. Muitos administradores não percebem que é possível oferecer controle de acesso para redes convencionais (com fio) com o IEEE 802.1X, que possui um esquema de autenticação com várias vantagens sobre as alternativas como a baseada em porta e MAC, fácil de bisbilhotar e difícil de gerenciar. Na era dos notebooks, um laptop sem autorização pode se conectar a uma rede a partir de qualquer lugar. Entretanto, administradores que procuram uma proteção eficiente podem usar o IEEE 802.1X para impedir acessos não autorizados antes que o intruso chegue até uma janela de navegador ou uma tela de login. Desbloqueio de porta O ambiente de autenticação do IEEE 802.1X inclui três componentes: suplicante: o cliente que solicita acesso à rede; autenticador: um switch Ethernet ou ponto de acesso por meio do qual o suplicante pede acesso; servidor de autenticação: servidor na rede que mantém um banco de dados de autenticação e se comunica com o banco de dados para aprovar ou rejeitar a solicitação de acesso. No caso de pontos de acesso sem fio domésticos, o autenticador e o servidor de autenticação geralmente 62

2 IEEE 802.1X SEGURANÇA se encontram no mesmo dispositivo. Em uma LAN com fio, a situação é um pouco mais complicada. Muitos switches gerenciáveis oferecem suporte a IEEE 802.1X. Um switch bem configurado, portanto, é um bom autenticador, recebendo solicitações de acesso de clientes e comunicando-se com o servidor de back-end normalmente utilizando o popular protocolo de autenticação RADIUS. Antes que o switch (que no contexto do RADIUS é chamado de Network Access Server NAS) permita qualquer tipo de tráfego em uma de suas portas, chamadas pelo padrão de Port Access Entities (PAE), o dispositivo solicitante normalmente um computador desktop ou laptop precisa passar por um processo de autenticação. Essa autenticação ocorre na camada de enlace de dados e se baseia no Extensible Authentication Protocol (EAP). O dispositivo que faz a solicitação precisa rodar um programa cliente (o chamado suplicante, ou supplicant), que apresenta suas credenciais na forma de um quadro Ethernet especial chamado EAPoL. O EAP suporta várias credenciais, mas os certificados de clientes X.509v3 são o tipo mais comum. Os certificados usam um padrão criptográfico estrito e podem ser gerenciados individualmente ou, caso necessário, por meio de uma infraestrutura de chave pública (PKI) com a extensão de protocolo EAP- TLS [2]. Outras opções incluem One Time Passwords (OTP), Projected EAP (PEAP) e TLS tunelado (TTLS). Quando um switch recebe uma solicitação do tipo EAP-Response/ Identity, ele a encaminha a um Servidor de Acesso Remoto (RAS, na sigla em inglês) que atua como servidor de autenticação. O sistema RAS conhece todas as permissões e informa o resultado da autenticação Figura 1 O switch gerenciado Netgear FSM726 tem 24 portas que podem ser configuradas individualmente para suportar operações IEEE802.1X Auto. ao switch. Se for positiva, o switch abre o PAE e permite ao cliente acessar a rede e desempenhar uma ação por exemplo, obter um IP por DHCP. Autenticação Muitos switches gerenciados suportam IEEE 802.1X. Por exemplo, um Netgear FSM726, que custa cerca de 200 dólares nos EUA e tem 2 portas gigabit, o 3Com 2924-SFP Plus, com custo de mais ou menos 270 dólares nos EUA, e o Level One GSW-2494, de 340 dólares. Todos estes dispositivos têm 24 portas e diferem entre si em alguns recursos. Quase todos esses switches incluem uma interface web (figura 1) e alguns usam interface de linha Quadro 1: Cisco IOS de comando para a configuração, como o IOS da Cisco. O artigo 5.1 do padrão 802.1X define as exigências para os switches. Alguns deles, como os que utilizam o IOS, apresentam mais recursos, tais como uma VLAN para convidados que recebe os suplicantes que não receberem permissão de acesso (essa opção de VLAN para convidados é útil para visitantes e conferências). Para disponibilizar um controle de acesso a redes no switch, o administrador precisa alternar as portas (PAEs) do modo Authorized para o modo Auto e dar ao dispositivo de rede a senha e o IP do Servidor de Acesso Remoto. É uma boa ideia adicionar uma VLAN separada para uma sub-rede administrativa isolada No Cisco IOS, o comando dot1x system-auth-control ativa o 802.1X em todo o switch (listagem 1). O comando radius-server host Radius IP adiciona o servidor RADIUS e key define a chave do RADIUS. O comando aaa authentication atribui o grupo radius. Os comandos dot1x pae authenticator e dot1x port-control auto convertem a interface selecionada em interface 802.1X. A VLAN para convidados, que remete o cliente a uma rede não crítica caso a autenticação falhe, é configurada com o comando dot1x guest-vlan vlan-id. Para mais detalhes, confira o Guia de Configuração do IOS [3] ou a wiki do FreeRADIUS [4]. Linux Magazine #61 Dezembro de

3 SEGURANÇA IEEE 802.1X e configurar a porta para Authorized a fim de evitar problemas do tipo ovo e galinha. RADIUS e usuários O switch utiliza o protocolo RA- DIUS (definido na RFC 2865) para conversar com o servidor RAS. A comunicação é protegida por uma chave compartilhada que pode ser gerada pelo administrador com o comando pwgen -s -1 e depois armazenada no switch. Listagem 1: Configuração do Cisco IOS. Com este passo, o administrador termina os preparativos para o dispositivo de rede. Todas as outras configurações do servidor são feitas no servidor RAS. Esse servidor também gerencia o certificado, a menos que seja preferível mantê-los em uma máquina separada por motivos de segurança. O FreeRADIUS [5] é uma boa escolha como servidor de acesso remoto. Bastam poucas modificações nas configurações padrão em 01 Switch# configure terminal 02 Switch(config)# dot1x system auth control 03 Switch(config)# aaa new model 04 Switch(config)# aaa authentication dot1x default radius 05 Switch(config)# radius server host auth port 1812 key heolw6dc 06 Switch(config)# interface fa1/10 07 Switch(config if)# switchport mode access 08 Switch(config if)# dot1x pae authenticator 09 Switch(config if)# dot1x port control auto 10 Switch(config if)# end 11 Switch# show dot1x interface fa1/10 details Listagem 2: Trecho do arquivo ca.cnf. 01 [certificate_authority] 02 countryname = BR 03 stateorprovincename = SP 04 localityname = SaoPaulo 05 organizationname = UebelHacker 06 address = ca@uebelhacker.br 07 commonname = UebelHacker CA Listagem 3: Trecho do arquivo server.cnf. 01 [server] 02 countryname = BR 03 stateorprovincename = SP 04 localityname = SaoPaulo 05 organizationname = UebelHacker 06 address = radius@uebelhacker.br 07 commonname = UebelHacker Radius Server Listagem 4: Modificando o makefile do CA. 01 client.crt: client.csr ca.pem ca.key index.txt serial 02 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(CAPWD) -out client.crt -extensions xpclient_ext -extfile xpextensions -config./client.cnf /etc/raddb/ (no opensuse) ou em /etc/freeradius/ (no Ubuntu) para o administrador ativar o EAP-TLS. As configurações básicas do FreeRA- DIUS são estendidas com a inclusão de vários arquivos personalizados. Por exemplo, o software pode recuperar uma lista de usuários de um banco de dados ou de um serviço de diretório, ou impor restrições de tempo aos usuários. As configurações gerais encontramse no arquivo radius.conf. Como o servidor só é necessário para a autenticação, a seção listen com type = auth é a configuração mais relevante. Para impedir que o software escute solicitações na porta UDP 1812 em todas as interfaces, é necessário configurar o endereço IP na chave ipaddr. Além disso, pode haver a necessidade de modificar suas regras de firewall. Para melhor acompanhamento das solicitações, você pode adicionar uma entrada auth = yes na seção log do arquivo radius.conf. O arquivo clients.conf especifica o segmento administrativo entre o switch e o servidor RAS. A entrada secret contém o segredo compartilhado por eles dois: client /24 { secret = heolw6dc shortname = uebelhackers } Quando o arquivo radius.conf se vincula ao eap.conf, a chave default_eap_type é definida como tls. A senha que ativa o certificado do servidor, que ainda precisa ser criado, é definida na mesma seção que private_key_password. Novos certificados Algumas distribuições incluem um makefile no diretório /etc/raddb/ certs. É possível usar esse makefile junto com o OpenSSL para gerar três tipos de certificados: um certi- 64

4 IEEE 802.1X SEGURANÇA ficado (primeiro) para um pequeno CA, que mais tarde assinará os certificados do servidor (segundo) e do cliente (terceiro). No entanto, se esse diretório estiver vazio, como no caso do Ubuntu 9.04, obtenha os arquivos do GitHub do Free- RADIUS GitHub em raddb/certs [6]. O pacote inclui um arquivo de configuração para cada certificado e um makefile compartilhado. Para criar um novo certificado de CA, é preciso modificar o arquivo ca.cnf. Altere a seção [certificate_authority], como mostra a listagem 2. Os valores de input_password e output_password precisam ser idênticos. Para editar a seção [server] em server.cnf, siga os mesmos passos, mas escolha um commonname diferente para distinguir os certificados (listagem 3). Depois, insira a private_key_password especificada no arquivo eap.conf como senha. Por fim, o comando make all criará os certificados da CA e do servidor, o arquivo Diffie-Hellman (dh) e o arquivo random, ambos importantes componentes no handshake SSL/TLS. Certificados de usuários No EAP-TLS, cada dispositivo precisa de seu próprio certificado de cliente, que pode ser criado no client. cnf. O makefile do FreeRADIUS por padrão assina essas credenciais com o certificado do servidor. Para o CA assiná-los, mude as linhas da listagem 4 e muita atenção à tabulação no início da linha 2. Depois, é possível entregar os certificados da CA diretamente aos suplicantes. O commonname na seção [client] especifica o nome do usuário para permissões e outras configurações no RADIUS. Mais uma vez, o certificado é protegido por senha usando aquela definida em input_password e output_password. [client] countryname = BR stateorprovincename = SP localityname = SaoPaulo organizationname = UebelHacker address = s@uebelhacker.br commonname = uebelacker Diferentemente dos certificados da CA e do servidor, será preciso criar múltiplos certificados aqui um para cada usuário. Como o comando make client gera apenas um certificado, faz sentido gerar um script para essa tarefa. Em seguida, é possível entregar os certificados aos usuários de uma forma segura, preferivelmente em um pen drive ou smartcard. Configuração de usuários A próxima informação de que o RAS precisará são os detalhes dos usuários autorizados. Para simplificar, é possível fornecer a cada Listagem 5: Banco de dados de usuários. usuário um certificado de cliente assinado pela CA. Se você não mudar o arquivo de configuração users no servidor RADIUS, ele dará acesso a qualquer um que possua um certificado válido. Com isso, o switch atribuirá um suplicante à VLAN especificada. No entanto, se for preferível fornecer mais detalhes sobre os usuários ao servidor RAS, há várias opções para isso: o mais rápido seria adicionar os usuários autorizados e os não autorizados ao arquivo users. Veja a listagem 5 com um exemplo desse método. A linha 3 da listagem 5 define o padrão para qualquer suplicante que forneça um certificado válido via EAP. Os detalhes de Tunnel-Type e Tunnel-Medium são pedidos pelo padrão, caso você deseje que o switch atribua uma VLAN por exemplo, 23 como o segmento do usuário. A RFC 2869 define mais extensões para o RADIUS, como a restrição do 01 dau Auth Type := Reject DEFAULT Auth Type := EAP, Login Time := Wk Tunnel Type = 13, 05 Tunnel Medium = 6, 06 Tunnel Private Group Id = 23, 07 Fall Through = Yes uebelacker Auth Type := EAP, Login Time = Any 10 Tunnel Private Group Id = 42 Listagem 6: Arquivo xsupplicant.conf. 01 default_netname = intranet 02 intranet { 03 type = wired 04 allow_types = eap_tls 05 identity = uebelacker 06 eap_tls { 07 user_cert = /caminho/para/s@uebelhacker.br.pem 08 user_key = /caminho/para/s@uebelhacker.br.pem 09 user_key_pass = Senha-Usercert 10 root_cert = /path/to/ca.pem 11 chunk_size = random_file = /dev/urandom 13 } 14 } Linux Magazine #61 Dezembro de

5 SEGURANÇA IEEE 802.1X Figura 2 O Network Manager conhece o serviço EAP-TLS e oferece uma interface gráfica de configuração. login a dias de semana entre 8:00 e 20:00 para evitar invasões noturnas. A primeira linha bloqueia o usuário dau, que acabou de sair da empresa, mas ainda possui um certificado válido. Como alternativa, seria possível implementar essa lógica com as Listagem 7: Arquivo wired.conf. Listas de Revogação de Certificados (CRLs, na sigla em inglês), porém esse passo é um pouco mais complicado. A primeira regra de combinação se aplica a esse arquivo, a menos que você tenha configurado o atributo Fall-Through como mostrado na linha 7. Os outros atributos sobrescrevem as configurações do administrador, uebelacker, que não está sujeito a restrições de tempo e segue direto para o segmento administrativo. O comando radiuss -X executa o RAS em modo de depuração para identificar alguma configuração incorreta. Se o servidor iniciar sem problemas, o RADIUS mostrará que está respondendo às solicitações: Listening on authentication address port 1812 Ready to process requests. Faz sentido executar o daemon no modo de depuração até a porta da rede ser desbloqueada; assim, todas as atividades serão extensamente registradas na saída padrão. 01 eapol_version=2 02 ap_scan=0 03 fast_reauth=1 04 network={ 05 key_mgmt=ieee8021x 06 eap=tls 07 identity= uebelacker 08 ca_cert= /caminho/para/ca.pem 09 client_cert= /caminho/para/s@uebelhacker.br.pem 10 private_key= /caminho/para/s@uebelhacker.br.pem 11 private_key_passwd= Senha-Usercert 12 eapol_flags=0 13 } Listagem 8: DHCP no arquivo interfaces. 01 auto eth0 02 iface eth0 inet dhcp 03 wpa-iface eth0 04 wpa-driver wired 05 wpa-conf /etc/wpa_supplicant/wired.conf Monitoramento É possível monitorar as atividades no modo de produção com tail -f /var/log/radius/radius.log: Info: Ready to process requests. Auth: Login OK: [uebelacker] (from client uebelhackers port 13 cli 00:19:e0:18:38:5c) Esta saída indica que o dono do certificado emitido para uebelacker fez login na porta 13 do switch. O Xsuplicant do projeto Open1X da OpenSEA Alliance [7][8] e o wpa_supplicant [9] suportam esse tipo de login. No entanto, algumas distribuições não incluem nenhum desses dois suplicantes. No Ubuntu 9.04 e posteriores, assim como em várias outras distribuições, o Network Manager atua como interface gráfica para o wpa_supplicant (figuras 2 e 3). No cliente O usuário precisa configurar um perfil 802.1X em /etc/xsupplicant/ xsupplicant.conf (listagem 6), que pode ser testado chamando o suplicante da seguinte maneira: xsupplicant -D wired -i eth0 \ -d 5 -f -c \ /etc/xsupplicant/xsupplicant.conf Após a autenticação 802.1X e a liberação da porta de rede, que será indicada pelo anúncio Changing from AUTHENTICATING to AUTHENTICATED, o script inicial atribui um IP estático ou usa o DHCP normalmente. Caso o Xsupplicant tenha sido iniciado em segundo plano por meio do /etc/ init.d/xsupplicant start e sobreviva a uma reinicialização graças a chkconfig xsupplicant on, a autenticação 802.1X ocorrerá automaticamente. Teste O pacote wpa_supplicant fornece meios de testar a configuração: 66

6 IEEE 802.1X SEGURANÇA wpa_supplicant \ -i eth0 -D wired -c /etc/wpa_supplicant/wired.conf Em seguida, é necessário criar o arquivo de configuração wired.conf como especificado na listagem 7. Como a autenticação 802.1X é baseada em redes com fio, é possível usar a versão 2 do eapol_version e desabilitar a busca de pontos de acesso. O suplicante anuncia o evento CTRL-EVENT-EAP-SUCCESS no caso de uma autenticação bem sucedida. Para executar o cliente permanentemente em segundo plano e autenticá-lo automaticamente no caso de portas 802.1X, os usuários precisam modificar o arquivo /etc/ network/interfaces, como mostrado na listagem 8 para o Debian supondo que se use DHCP. Caso contrário, deve-se mudar o item dhcp para static e definir um endereço IP estático. O comando /etc/ init.d/networking restart ativa essas configurações. Se o cliente alcançar o estado authorized em uma porta sem IEEE 802.1X, a tentativa de login será redundante, mas o cliente funcionará normalmente. Produção O último passo para o administrador é configurar o servidor RADIUS no modo de produção: habilitar o script init usando service freeradius start e digitando chkconfig freeradius on para fazer com que o servidor inicie o FreeRADIUS toda vez que o sistema iniciar. Conclusão Os componentes para autenticação de dispositivos existem em muitos ambientes. A combinação desses componentes fica a cargo do administrador. Para algumas pessoas, o Controle de Acesso à Rede (NAC) ainda inclui outros aspectos, tais como validação técnica de status de versão ou assinaturas de vírus atualizadas, alinhadas à política de segurança. O NAC oferece várias opções de customização: além de LDAP ou integração com bancos de dados SQL, ambientes mais complexos podem necessitar do emprego de um PKI com o uso do Tiny CA [10], por exemplo. Smartcards, como o Aladdin E-Token, protegem os certificados dos usuários. O FreeRADIUS suporta IPv6 a partir da versão 2; no entanto, alguns switches 802.1X podem não seguir os padrões. Se você estiver testando o IKEv2, por exemplo, confira o arquivo experimental.conf do projeto. Há um Mais informações [1] IEEE 802.1x-2004: [2] RFC 5216, EAP-TLS Authentication Protocol : Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: projeto no SourceForge com nome idêntico para pesquisar o IKE2 [11]. Graças ao projeto Hostapd [12], os administradores podem esperar para breve uma nova implementação do EAP no FreeRADIUS, conhecida por EAP2. n [3] Guia Cisco 802.1x: lan/catalyst4500/12.2/31sg/configuration/guide/dot1x.html [4] FreeRADIUS Wiki com comandos Cisco IOS: [5] Projeto FreeRADIUS: [6] FreeRADIUS em GitHub: [7] OpenSEA: [8] Projeto Open1X: [9] WPA supplicant: [10] Tiny CA: [11] Projeto EAP-IKEv2 em Sourceforge: [12] Modos EAP suportados pelo FreeRADIUS: Figura 3 Com a configuração completa, o logon no switch é transparente para os usuários. Linux Magazine #61 Dezembro de