Ya se han descrito algunos ejemplos de cómo organizar el WiFi corporativo. Aquí detallaré cómo implementé una solución similar y los problemas que encontré al conectarme desde diferentes dispositivos. Usaremos el LDAP existente con los usuarios registrados, levantaremos FreeRadius y configuraremos WPA2-Enterprise en el controlador Ubnt. Parece sencillo. Veamos…
Un poco sobre los métodos EAP
Antes de comenzar a implementar la tarea, debemos definir qué método de autenticación utilizaremos en nuestra solución.
De Wikipedia:
EAP es un marco de autenticación que se utiliza frecuentemente en redes inalámbricas y conexiones punto a punto. El formato fue descrito por primera vez en el RFC 3748 y actualizado en el RFC 5247.
EAP se utiliza para elegir el método de autenticación, la transmisión de claves y el manejo de estas claves mediante módulos de conexión llamados métodos EAP. Existen muchos métodos EAP, tanto definidos junto con EAP como emitidos por fabricantes individuales. EAP no define el nivel de enlace, solo define el formato de los mensajes. Cada protocolo que utiliza EAP tiene su propio protocolo de encapsulación de mensajes EAP.
Los métodos en sí:
- LEAP es un protocolo propietario, desarrollado por CISCO. Se han encontrado vulnerabilidades. Actualmente no se recomienda su uso.
- EAP-TLS es bien soportado por los proveedores de conexiones inalámbricas. Es un protocolo seguro ya que es un sucesor de los estándares SSL. La configuración del cliente es bastante complicada. Se necesita un certificado de cliente además de la contraseña. Es compatible con muchos sistemas.
- EAP-TTLS es ampliamente soportado en muchos sistemas, ofrece buena seguridad utilizando certificados PKI solo en el servidor de autenticación.
- EAP-MD5 es otro estándar abierto. Ofrece seguridad mínima. Es vulnerable, no soporta la autenticación mutua ni la generación de claves.
- EAP-IKEv2 se basa en el Protocolo de Intercambio de Claves de Internet versión 2. Proporciona autenticación mutua y establece una clave de sesión entre el cliente y el servidor.
- PEAP es una solución conjunta de CISCO, Microsoft y RSA Security como estándar abierto. Está ampliamente disponible en productos y proporciona una muy buena seguridad. Se asemeja a EAP-TTLS, ya que solo requiere un certificado del lado del servidor.
- PEAPv0/EAP-MSCHAPv2 — después de EAP-TLS, este es el segundo estándar más utilizado en el mundo. Se utiliza la relación cliente-servidor en Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — creado por Cisco como una alternativa a PEAPv0/EAP-MSCHAPv2. No protege los datos de autenticación en ningún caso. No es compatible con Windows OS
- EAP-FAST — método desarrollado por Cisco para corregir las deficiencias de LEAP. Utiliza Credential de Acceso Protegido (PAC). No está completamente desarrollado
De toda esta diversidad, realmente la elección no es tan amplia. Se requería del método de autenticación: buena seguridad, soporte en todos los dispositivos (Windows 10, macOS, Linux, Android, iOS) y, por supuesto, cuanto más simple, mejor. Por lo tanto, se optó por EAP-TTLS en combinación con el protocolo PAP.
Puede surgir la pregunta: ¿Por qué usar PAP? ¿acaso no transmite contraseñas en texto claro?
Sí, es cierto. La comunicación entre FreeRadius y FreeIPA se realizará exactamente así. En modo depuración se puede rastrear cómo se envían el nombre de usuario y la contraseña. Y que se envíen, solo ustedes tienen acceso al servidor FreeRadius.
Para más detalles sobre el funcionamiento de EAP-TTLS se puede leer
FreeRADIUS
Levantaremos FreeRadius en CentOS 7.6. Aquí no hay nada complicado, lo instalamos de la manera habitual.
yum install freeradius freeradius-utils freeradius-ldap -ySe instala la versión 3.0.13 de los paquetes. La última se puede obtener en
Después de esto, FreeRadius ya está en funcionamiento. Se puede descomentar la línea en /etc/raddb/users
steve Cleartext-Password := "testing"Inicie el servidor en modo depuración
freeradius -XY realizamos una conexión de prueba desde localhost
radtest steve testing 127.0.0.1 1812 testing123Recibimos la respuesta Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, lo que significa que todo está bien. Sigamos adelante.
Conectamos el módulo ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapY lo cambiamos de inmediato. Necesitamos que FreeRadius pueda acceder a 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 el servidor radius y verificamos la sincronización de los usuarios LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Editamos eap en mods-enabled/eap
Aquí añadiremos dos instancias de eap. Solo diferirán en los certificados y las claves. Más abajo explicaré por qué exactamente así
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"
}
}A continuación editamos site-enabled/default. Nos interesan las secciones authorize y 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
}En la sección authorize eliminamos todos los módulos que no necesitamos. Solo dejamos ldap. Agregamos una verificación del cliente por nombre de usuario. Es precisamente para esto que añadimos los dos instancias de eap arriba.
Multi EAPEl hecho es que al conectar algunos dispositivos usaremos certificados del sistema y especificaremos el dominio. Tenemos un certificado y una clave de una autoridad certificadora confiable. A mi parecer, este procedimiento de conexión es más sencillo que enviar un certificado autofirmado a cada dispositivo. Sin embargo, no pudimos evitar el uso de certificados autofirmados. Los dispositivos Samsung y Android <= versión 6 no pueden usar certificados del sistema. Por lo tanto, creamos una instancia separada de eap-guest con certificados autofirmados para ellos. Para todos los demás dispositivos, utilizaremos eap-client con un certificado confiable. User-Name se determina por el campo Anonymous al conectar el dispositivo. Se permite usar solo 3 valores: Guest, Client y un campo vacío. Todo lo demás se descarta. Esto se configura en las políticas. Daré un ejemplo más adelante.
Editaremos las secciones authorize y authenticate en 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
}Luego debemos especificar en las políticas qué nombres se pueden usar para el acceso anónimo. Editamos policy.d/filter.
Debemos encontrar líneas similares a esta:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Y agregar los valores necesarios en el elsif:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Ahora necesitamos movernos al directorio certs. Aquí debemos colocar la clave y el certificado de la autoridad certificadora confiable que ya poseemos, y generar certificados autofirmados para eap-guest.
Modificamos los parámetros en el archivo ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "CA FreeRadius"Escribimos los mismos valores en el archivo server.cnf. Cambiamos solo
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "Server Certificate FreeRadius"Creamos:
makeListo. Los obtenidos server.crt y server.key ya están escritos arriba en eap-guest.
Y por último, agregaremos nuestros puntos de acceso en el archivo client.conf. Tengo 7. Para no agregar cada punto por separado, escribiremos solo la red en la que se encuentran (mis puntos de acceso están en una VLAN separada).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Controlador Ubiquiti
En el controlador levantamos una red separada. Que sea 192.168.2.0/24
Vamos a Configuración -> perfil. Creamos uno nuevo:
Escribimos la dirección y el puerto del servidor radius y la contraseña que escribimos en el archivo clients.conf:
Creamos un nuevo nombre para la red inalámbrica. Como método de autenticación seleccionamos WPA-EAP (Enterprise) y especificamos el perfil radius creado:
Guardamos todo, aplicamos y seguimos adelante.
Configuración de clientes
¡Comencemos con lo más complicado!
Windows 10
La dificultad radica en que Windows aún no puede conectarse a WiFi corporativo por dominio. Por lo tanto, hay que agregar manualmente nuestro certificado en el almacén de certificados de confianza. Aquí se puede usar tanto uno autofirmado como uno de una autoridad de certificación. Yo usaré el segundo.
Luego, necesitamos crear una nueva conexión. Para ello vamos a los ajustes de red e Internet -> Panel de control de redes y recursos compartidos -> Crear y configurar una nueva conexión o red:
Escribimos manualmente el nombre de la red y cambiamos el tipo de seguridad. Luego presionamos cambiar parámetros de conexión y en la pestaña Seguridad seleccionamos la autenticación de red — EAP-TTLS.
Entramos en parámetros, especificamos la privacidad de la autenticación — client. Como centro de certificación de confianza elegimos el certificado que añadimos, marcamos la opción «No mostrar al usuario un mensaje si no se puede autenticar el servidor» y como método de autenticación elegimos — contraseña sin cifrar (PAP).
A continuación, accedemos a los parámetros adicionales, marcamos la opción "Especificar el modo de autenticación". Elegimos "Autenticación de usuario" y hacemos clic en guardar credenciales. Aquí debemos ingresar username_ldap y password_ldap
Todo lo guardamos, aplicamos y cerramos. Se puede conectar a la nueva red.
Linux
He probado en Ubuntu 18.04, 18.10, Fedora 29, 30.
Primero, descargamos el certificado. No encontré en Linux si hay posibilidad de utilizar certificados del sistema y si realmente hay algún almacén.
Nos conectaremos a través del dominio. Por lo tanto, se necesita el certificado de la autoridad certificadora que emitió nuestro certificado.
Toda la conexión se realiza en una ventana. Elegimos nuestra red:
anónimo — cliente
dominio — el dominio para el cual se emitió el certificado
Android
no-Samsung
A partir de la versión C 7, al conectarse a WiFi se pueden utilizar certificados del sistema, indicando solo el dominio:
dominio — el dominio para el cual se emitió el certificado
anónimo — cliente
Samsung
Como ya mencioné anteriormente, los dispositivos Samsung no pueden utilizar certificados del sistema al conectarse a WiFi y no tienen la posibilidad de conectarse por dominio. Por lo tanto, es necesario agregar manualmente el certificado raíz de la autoridad certificadora (ca.pem, se obtiene en el servidor Radius). Aquí se utilizará el auto-firmado.
Descargamos el certificado en nuestro dispositivo e instalamos.
Instalación del certificado
En este caso, será necesario establecer un patrón de desbloqueo de pantalla, pin o contraseña, si aún no está configurado:
Mostré la opción complicada para instalar el certificado. En la mayoría de los dispositivos, es suficiente con hacer clic en el certificado descargado.
Una vez instalado el certificado, se puede proceder a la conexión:
certificado — especificamos el que instalamos
usuario anónimo — invitado
macOS
Los dispositivos de Apple, de fábrica, solo pueden conectarse a EAP-TLS, pero aún así es necesario cargarles un certificado. Para especificar otro método de conexión, se debe utilizar Apple Configurator 2. Por lo tanto, es necesario descargarlo previamente en una Mac, crear un nuevo perfil y agregar todas las configuraciones necesarias de WiFi.
Apple Configurator
Aquí especificamos el nombre de nuestra red
Tipo de seguridad — WPA2 Enterprise
Tipos de EAP aceptados — TTLS
Nombre de usuario y contraseña — dejamos en blanco
Autenticación interna — PAP
Identidad externa — cliente
Pestaña de confianza. Aquí especificamos nuestro dominio
Todo. El perfil se puede guardar, firmar y distribuir en los dispositivos
Una vez que el perfil esté listo, debes descargarlo en Mac e instalarlo. Durante la instalación, tendrás que ingresar el username_ldap y password_ldap del usuario:
iOS
El proceso es similar a macOS. Necesitas usar un perfil (puedes utilizar el mismo que para macOS. Cómo crear un perfil en Apple Configurator, verlo arriba).
Descargamos el perfil, lo instalamos, ingresamos las credenciales, nos conectamos:
Y eso es todo. Hemos configurado el servidor Radius, lo hemos sincronizado con FreeIPA y hemos indicado a los puntos de acceso Ubiquiti que utilicen WPA2-EAP.
Preguntas posibles
Q: ¿Cómo transmitir el perfil/certificado al empleado?
R: Todos los certificados/perfiles los guardo en FTP con acceso a través de la web. He creado una red de invitados con limitaciones de velocidad y acceso solo a internet, a excepción del FTP.
La autenticación se mantiene durante 2 días, después de lo cual se restablece y el cliente queda sin internet. Así, cuando un empleado quiere conectarse a WiFi, primero se conecta a la red de invitados, accede al FTP, descarga el certificado o perfil que necesita, los instala y después puede conectarse a la red corporativa.
Q: ¿Por qué no usar el esquema con MSCHAPv2? ¡Es más seguro!
R: En primer lugar, ese esquema funciona bien en NPS (Windows Network Policy System), en nuestra implementación es necesario configurar adicionalmente LDAP (FreeIPA) y almacenar los hashes de las contraseñas en el servidor. No se aconseja hacer configuraciones adicionales, ya que esto puede conducir a varios problemas de sincronización de cuentas. En segundo lugar, el hash es MD4, por lo que esto no aumenta significativamente la seguridad.
Q: ¿Se pueden autorizar dispositivos por direcciones MAC?
R: NO, no es seguro, un atacante puede cambiar las direcciones MAC, y además la autorización por direcciones MAC no es compatible con muchos dispositivos.
Q: ¿Por qué usar todos estos certificados? ¡Se puede conectar sin ellos!
R: Los certificados se utilizan para autenticar el servidor. Es decir, el dispositivo al conectarse verifica si se trata de un servidor en el que se puede confiar. Si es así, la autenticación avanza; de lo contrario, la conexión se cierra. Se puede conectar sin certificados, pero si un atacante o un vecino establece su propio servidor RADIUS y un punto de acceso con el mismo nombre que el nuestro, podrá interceptar fácilmente las credenciales del usuario (no olvidemos que se transmiten en texto claro). Al usar un certificado, el enemigo solo verá en sus registros nuestros nombres de usuario ficticios: guest o client, y un error del tipo - Certificado CA desconocido.
Un poco más sobre macOSNormalmente, en macOS, la reinstalación del sistema se realiza a través de internet. En modo de recuperación, se debe conectar el Mac a WiFi, y aquí no funcionará ni nuestra red WiFi corporativa ni la red de invitados. Personalmente, establecí otra red, una normal por WPA2-PSK, oculta, solo para operaciones técnicas. Alternativamente, se puede crear de antemano una unidad USB de arranque con el sistema. Pero si el Mac es posterior a 2015, será necesario encontrar un adaptador para esta unidad USB)
Fuente: habr.com
