Já foram descritos alguns exemplos de organização de WiFi corporativo. Aqui, explicarei como implementei uma solução semelhante e os problemas que enfrentei ao conectar em diferentes dispositivos. Vamos usar o LDAP existente com usuários cadastrados, configurar o FreeRadius e ajustar o WPA2-Enterprise no controlador Ubnt. Parece simples. Vamos ver...
Um pouco sobre os métodos EAP
Antes de começar a executar a tarefa, é necessário determinar qual método de autenticação usaremos em nossa solução.
Do Wikipedia:
EAP é um framework de autenticação frequentemente utilizado em redes sem fio e conexões ponto a ponto. O formato foi descrito pela primeira vez no RFC 3748 e atualizado no RFC 5247.
O EAP é usado para escolher o método de autenticação, transmitir chaves e processar essas chaves com módulos conectáveis chamados de métodos EAP. Existem muitos métodos EAP, tanto definidos junto com o próprio EAP quanto lançados por fabricantes individualmente. O EAP não define o nível de canal; ele apenas define o formato das mensagens. Cada protocolo que utiliza o EAP possui seu próprio protocolo de encapsulamento de mensagens EAP.
Os próprios métodos:
- LEAP é um protocolo proprietário desenvolvido pela CISCO. Vulnerabilidades foram encontradas. Atualmente, não é recomendado usar.
- EAP-TLS é bem suportado entre os fornecedores de conexões sem fio. É um protocolo seguro, pois é o sucessor dos padrões SSL. A configuração cliente é bastante complexa. Um certificado de cliente é necessário além da senha. É suportado em muitos sistemas.
- EAP-TTLS é amplamente suportado em muitos sistemas, oferecendo boa segurança, usando certificados PKI apenas no servidor de autenticação.
- EAP-MD5 é outro padrão aberto. Oferece segurança mínima. É vulnerável, não suporta autenticação mútua e geração de chaves.
- EAP-IKEv2 baseia-se no Protocolo de Troca de Chaves da Internet versão 2. Garante autenticação mútua e estabelecimento de chave de sessão entre cliente e servidor.
- PEAP é uma solução conjunta da CISCO, Microsoft e RSA Security como um padrão aberto. Amplamente disponível em produtos, fornece segurança muito boa. É similar ao EAP-TTLS, exigindo apenas um certificado no lado do servidor.
- PEAPv0/EAP-MSCHAPv2 — após o EAP-TLS, este é o segundo padrão amplamente utilizado no mundo. Utiliza a interação cliente-servidor na Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — criado pela Cisco como uma alternativa ao PEAPv0/EAP-MSCHAPv2. Não protege os dados de autenticação em nenhuma circunstância. Não é suportado em sistemas Windows
- EAP-FAST — método desenvolvido pela Cisco para corrigir as falhas do LEAP. Usa Credential de Acesso Protegido (PAC). Completamente não concluído
Apesar de toda essa variedade, a escolha não é tão grande. O método de autenticação deveria ter: boa segurança, suporte a todos os dispositivos (Windows 10, macOS, Linux, Android, iOS) e, de fato, quanto mais simples, melhor. Portanto, a escolha recaiu sobre o EAP-TTLS em conjunto com o protocolo PAP.
Pode surgir a pergunta — Por que então usar PAP? pois ele transmite senhas em texto claro?
Sim, isso mesmo. A comunicação entre FreeRadius e FreeIPA será exatamente assim. Em modo de depuração, pode-se rastrear como são enviadas o nome de usuário e a senha. E que sejam enviadas, contanto que você tenha acesso ao servidor FreeRadius.
Para mais detalhes sobre o funcionamento do EAP-TTLS, você pode ler
FreeRADIUS
Vamos instalar o FreeRadius no CentOS 7.6. Aqui não há nada complicado, vamos instalar da maneira usual.
yum install freeradius freeradius-utils freeradius-ldap -yA versão 3.0.13 será instalada dos pacotes. A última pode ser obtida em
Após isso, o FreeRadius já estará funcionando. Você pode descomentar a linha em /etc/raddb/users
steve Cleartext-Password := "testing"Inicie o servidor em modo de depuração
freeradius -XE fazemos uma conexão de teste com o localhost
radtest steve testing 127.0.0.1 1812 testing123Recebemos a resposta Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, significa que está tudo certo. Vamos em frente.
Conectamos o módulo ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapE logo o modificamos. Precisamos que o FreeRadius possa acessar o FreeIPA
mods-enabled/ldap
ldap {
server="ldap://ldap.server.com"
port=636
start_tls=yes
identity="uid=admin,cn=users,dc=server,dc=com"
password=**********
base_dn="cn=users,dc=server,dc=com"
set_auth_type=yes
...
user {
base_dn="${..base_dn}"
filter="(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
}
...Reiniciamos o servidor radius e verificamos a sincronização dos usuários LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Editamos o eap em mods-enabled/eap
Aqui vamos adicionar duas instâncias de eap. Elas diferirão apenas pelos certificados e chaves. Explicarei um pouco mais abaixo, por que exatamente assim
mods-enabled/eap
eap eap-client { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_file = ${certdir}\/fisrt.key
certificate_file = ${certdir}\/first.crt
dh_file = ${certdir}\/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}
eap eap-guest {
default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_passwotd=blablabla
private_key_file = ${certdir}\/server.key
certificate_file = ${certdir}\/server.crt
dh_file = ${certdir}\/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}Em seguida, editamos site-enabled/default. Precisamos das seções authorize e authenticate.
site-enabled/default
authorize {
filter_username
preprocess
if (&User-Name == "guest") {
eap-guest {
ok = return
}
}
elsif (&User-Name == "client") {
eap-client {
ok = return
}
}
else {
eap-guest {
ok = return
}
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
logintime
pap
}
authenticate {
Auth-Type LDAP {
ldap
}
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
pap
}Na seção authorize, removemos todos os módulos desnecessários. Mantemos apenas ldap. Adicionamos uma verificação do cliente pelo username. É exatamente para isso que adicionamos acima duas instâncias de eap.
Multi EAPO fato é que, ao conectar alguns dispositivos, usaremos certificados do sistema e especificaremos o domínio. Temos um certificado e uma chave de uma autoridade certificadora confiável. Na minha opinião, esse procedimento de conexão é mais simples do que enviar um certificado autoassinado para cada dispositivo. No entanto, não conseguimos escapar completamente dos certificados autoassinados. Dispositivos Samsung e Android <= versão 6 não conseguem usar certificados do sistema. Portanto, criamos uma instância separada de eap-guest com certificados autoassinados para eles. Para todos os outros dispositivos, usaremos eap-client com certificado confiável. O User-Name é determinado pelo campo Anonymous ao conectar o dispositivo. Apenas 3 valores são permitidos: Guest, Client e campo vazio. Todos os outros são descartados. Isso é configurado nas políticas. Um exemplo será fornecido mais tarde.
Vamos editar as seções authorize e authenticate em site-enabled/inner-tunnel
site-enabled/inner-tunnel
authorize {
filter_username
filter_inner_identity
update control {
&Proxy-To-Realm := LOCAL
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
digest
logintime
pap
}
authenticate {
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
Auth-Type PAP {
pap
}
ldap
}Em seguida, precisamos definir nas políticas quais nomes podem ser usados para entrada anônima. Editamos policy.d/filter.
Precisamos encontrar linhas que se assemelhem a isso:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name não está anonimizado"
}
reject
}E abaixo, em elsif, adicionamos os valores necessários:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name não está anonimizado"
}
reject
}Agora precisamos nos mover para o diretório certs. Aqui devemos colocar a chave e o certificado da autoridade certificadora confiável que já temos, e precisamos gerar certificados autoassinados para eap-guest.
Alteramos os parâmetros no arquivo ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = BR
stateOrProvinceNmae = Estado
localityNmae = Cidade
organizationName = NONAME
emailAddress = admin@admin.br
commonName = "CA FreeRadius"Inserimos os mesmos valores no arquivo server.cnf. Alteramos apenas
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = BR
stateOrProvinceNmae = Estado
localityNmae = Cidade
organizationName = NONAME
emailAddress = admin@admin.br
commonName = "Certificado do Servidor FreeRadius"Criamos:
makePronto. Obtidos server.crt e server.key já estão listados acima em eap-guest.
E por último, adicionaremos nossos pontos de acesso no arquivo client.conf. Eu tenho 7. Para não adicionar cada ponto separadamente, listaremos apenas a rede na qual eles estão (meus pontos de acesso estão em uma VLAN separada).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Controlador Ubiquiti
No controlador, levantamos uma rede separada. Vamos usar 192.168.2.0/24
Vamos nas configurações -> perfil. Criamos um novo:
Inserimos o endereço e a porta do servidor radius e a senha que configuramos no arquivo clients.conf:
Criamos um novo nome de rede sem fio. Como método de autenticação, escolhemos WPA-EAP (Enterprise) e indicamos o perfil radius criado:
Salvamos tudo, aplicamos e seguimos em frente.
Configuração dos clientes
Vamos começar pelo mais complicado!
Windows 10
A complexidade é que o Windows ainda não consegue se conectar ao WiFi corporativo pelo domínio. Portanto, é necessário adicionar manualmente nosso certificado ao repositório de certificados confiáveis. Aqui podemos usar tanto o autoassinado quanto o de uma autoridade certificadora. Eu vou usar o segundo.
Em seguida, precisamos criar uma nova conexão. Para isso, vamos em configurações de rede e Internet -> Painel de Controle de Redes e Compartilhamento -> Criar e Configurar uma Nova Conexão ou Rede:
Digitamos manualmente o nome da rede e alteramos o tipo de segurança. Em seguida, clicamos em alterar configurações da conexão e na aba Segurança escolhemos autenticação de rede — EAP-TTLS.
Entramos nas configurações, configuramos a privacidade da autenticação — client. Como centro de certificação confiável, escolhemos o certificado que adicionamos, marcamos a opção "Não solicitar ao usuário se não for possível autenticar o servidor" e o método de autenticação escolhido é — senha não criptografada (PAP).
Em seguida, vamos para as configurações adicionais, marcamos a opção "Indique o modo de autenticação". Selecionamos a opção "Autenticação do usuário" e pressionamos salvar as credenciais. Aqui será necessário inserir username_ldap e password_ldap
Tudo salvo, aplicamos, e fechamos. Podemos nos conectar à nova rede.
Linux
Eu testei no Ubuntu 18.04, 18.10, Fedora 29, 30.
Para começar, vamos baixar o certificado. Não encontrei no Linux se há possibilidade de usar certificados do sistema e se existe realmente esse repositório.
Vamos nos conectar pelo domínio. Portanto, precisamos do certificado da autoridade certificadora, que emitiu nosso certificado.
Toda a conexão é feita em uma única janela. Selecionamos nossa rede:
anonymous — client
domain — domínio para o qual o certificado foi emitido
Android
non-Samsung
A partir da versão 7, ao conectar via WiFi, é possível usar os certificados do sistema, informando apenas o domínio:
domain — domínio para o qual o certificado foi emitido
anonymous — client
Samsung
Como mencionado anteriormente, dispositivos Samsung não conseguem usar certificados do sistema ao conectar via WiFi e não têm a possibilidade de se conectar pelo domínio. Portanto, é necessário adicionar manualmente o certificado raiz da autoridade certificadora (ca.pem, obtido no servidor Radius). Aqui será utilizado um certificado autoassinado.
Baixamos o certificado para nosso dispositivo e o instalamos.
Instalação do certificado
Nesse caso, será necessário instalar um padrão de desbloqueio de tela, código PIN ou senha, se ainda não estiverem configurados:
Mostrei a versão complexa da instalação do certificado. Na maioria dos dispositivos, basta pressionar o certificado baixado.
Quando o certificado estiver instalado, podemos prosseguir para a conexão:
certificado — indicamos aquele que instalamos
usuário anônimo — guest
macOS
Dispositivos Apple, desde o início, podem se conectar apenas ao EAP-TLS, mas ainda assim é necessário fornecer o certificado a eles. Para indicar outro método de conexão, você precisará usar o Apple Configurator 2. Assim, é necessário baixá-lo no Mac, criar um novo perfil e adicionar todas as configurações WiFi necessárias.
Apple Configurator
Aqui indicamos o nome da nossa rede
Tipo de Segurança — WPA2 Enterprise
Tipos de EAP Aceitos — TTLS
Nome de Usuário e Senha — deixamos em branco
Autenticação Interna — PAP
Identidade Externa — client
Aba Trust. Aqui indicamos nosso domínio
Pronto. O perfil pode ser salvo, assinado e distribuído para os dispositivos
Após a criação do perfil, ele deve ser baixado para o Mac e instalado. Durante a instalação, será necessário informar o username_ldap e o password_ldap do usuário:
iOS
O processo é similar ao do macOS. É necessário usar o perfil (pode ser o mesmo do macOS. Como criar o perfil no Apple Configurator, veja acima).
Baixamos o perfil, instalamos, inserimos as credenciais e nos conectamos:
Isso é tudo. Configuramos o servidor Radius, sincronizamos com o FreeIPA e instruímos os pontos de acesso Ubiquiti a usar WPA2-EAP.
Possíveis perguntas
P: Como transmitir o perfil/certificado para o funcionário?
A: Eu armazeno todos os certificados/perfis em FTP com acesso via web. Criei uma rede de convidados com limitação de velocidade e acesso apenas à internet, exceto ao FTP.
A autenticação dura 2 dias, após os quais é redefinida e o cliente fica sem internet. Assim, quando o funcionário deseja se conectar ao WiFi, ele primeiro se conecta à rede de convidados, acessa o FTP, baixa o certificado ou perfil necessário, os instala e então pode se conectar à rede corporativa.
P: Por que não usar o esquema com MSCHAPv2? Ele é mais seguro!
A: Em primeiro lugar, esse esquema funciona bem no NPS (Windows Network Policy System), mas na nossa implementação é necessário configurar o LDAP (FreeIpa) e armazenar os hashes das senhas no servidor. Realizar configurações adicionais não é desejável, pois isso pode levar a vários problemas de sincronização de usuários. Em segundo lugar, o hash é MD4, o que não aumenta significativamente a segurança.
P: É possível autenticar dispositivos por endereços MAC?
A: NÃO, isso não é seguro; um invasor pode falsificar endereços MAC, além de que a autenticação por endereços MAC não é suportada em muitos dispositivos.
P: Por que usar todos esses certificados? Poderíamos nos conectar sem eles.
A: Os certificados são usados para autenticar servidores. Ou seja, o dispositivo, ao se conectar, verifica se este é um servidor confiável ou não. Se for, a autenticação prossegue; caso contrário, a conexão é encerrada. É possível conectar-se sem certificados, mas se um intruso ou um vizinho configurar um servidor radius e um ponto de acesso com o mesmo nome que o nosso, ele poderá facilmente interceptar as credenciais do usuário (não nos esquecendo de que elas são transmitidas em texto aberto). Quando um certificado é utilizado, o inimigo verá apenas em seus logs nossos nomes de usuário fictícios — guest ou client — e um erro do tipo — Certificado CA Desconhecido.
mais um pouco sobre macOSNormalmente, na macOS, a reinstalação do sistema é feita pela internet. No modo de recuperação, o Mac deve ser conectado ao WiFi, e aqui não funcionará nem nosso WiFi corporativo, nem a rede de convidados. Pessoalmente, criei outra rede, uma normal com WPA2-PSK, oculta, apenas para operações técnicas. Ou então é possível preparar previamente um pen drive de inicialização com o sistema. Mas se o Mac for de 2015 para frente, precisaremos encontrar um adaptador para esse pen drive).
Fonte: habr.com
