¿Cómo creo un servidor de FreeRadius en Ubuntu?
Juan Perón definió claras políticas a seguir para los partidarios de su
doctrina, y también indicaciones para quienes no lo eran. También enseñó
cómo instalar un servidor RADIUS para emplear acceso Wifi firmado
digitalmente bajo el estándar WPA2-Enterprise en Ubuntu
(...)
Siempre he dicho que el que no piense como nosotros, debe sacarse la
camiseta peronista y se va. Por perder un voto no vamos a ponernos
tristes, al fin y al cabo nadie ha podido teñir el océano con un vaso de
tinta. Si fuese comunista, iría a la sede del Partido Comunista.
Si eso pasa en la política, imagínense lo que sucede con las redes Wifi
que toda empresa tiene por ahí: son muy propicias para que cualquiera
quiera colgarse y aprovecharse.
Analicemos el problema y seamos honestos. Probablemente vuestra
contraseña de Wifi empresarial sea algo bastante simple. La mayoría de
la gente lo hace así pues debe convenir verbalmente dicha contraseña con
nuevos usuarios, muchas veces molestos y realmente temporales, los
cuales han de tipearlas en un incómodo Smartphone. De este modo que es
probable que la contraseña no tenga 63 caracteres aleatorios y a lo sumo
sea algo tontorrón, asi como "riverboca canchapelota".
Para contar con una verdadera seguridad, deberíamos emplear un
certificado de encripción precompartido. Esto elevaría nuestra seguridad
desde el concepto de "aquello que debemos saber" (nuestra contraseña de
wifi) a "aquello que hemos de tener" (un archivo "llave" de certificado
de encriptación).
Para ello existe el estándar RADIUS. Se trata de un acrónimo para
"Servicio de Autenticación Remota para Usuarios Ingresante", y describe
una serie de maneras para poder acceder a un servicio (en este caso,
loguearnos a una red inalámbrica) sin necesidad de una clave memorizada,
sino por medio de la revisión de un archivo certificado y con
vencimiento, emitido por el mismo servidor.
La mayoría de los routers modernos cuentan con soporte para la norma
WPA2-Enterprise, la cual establece el uso de un servidor de tecnología
RADIUS para la autenticación de clientes.
Ahora bien, existen muchos esquemas versátiles en el que podemos usar la
tecnología RADIUS, pero en aras de una sencillez y robustez
Justicialista, os propondré una en la que se empleará un demonio basado
en Ubuntu Server que generará certificados para los usuario, firmados
digitalmente y con vencimiento de un año. Luego estos habrán de
instalarlos en sus dispositivos.
Asumiremos que tenemos un router Wifi que soporta WPA2-Enterprise. Su
punto de acceso debe estar configurado con una IP estática. También
necesitamos un servidor con una dirección IP estática corriendo Ubuntu
16.04LTS, sobre el cual correremos el servidor RADIUS.
En primer nos conectamos al servidor como Conductores (root), a fin de
instalar el paquete del demonio FreeRADIUS en él. Ya he expicado antes
cómo instalar Ubuntu Server 16.04LTS a fin de emplearlo como router, de
manera que podremos emplear dicho equipo. Una vez dispuestos en la
consola del servidor ingresamos:
sudo su
...Tras autenticarnos con nuestra contraseña de administrador
ingresaremos los consabidos Comandos de Organización:
apt-get update
apt-get install freeradius make
En breves instantes se descargará la paquetería necesaria. Acto seguido
procederemos a configurar algunas cosas del demionio RADIUS en sí. Le
desactivamos la opción de proxy del servidor (a no ser que la
necesitemos), por medio de:
nano /etc/freeradius/radiusd.conf
Esto abrirá el editor de texto GNU Nano con el archivo de configuración
radiusd.conf, el cual ya contendrá información. Hemos de modificar la
cadena proxy_requests para que tome un valor negativo, de modo que
quedará de la siguiente manera:
proxy_requests = no
También podrían querer revisar dentro del archivo radiusd.conf las
funciones de registro en este archivo de configuración, para modificar
qué información se registra y dónde se almacenará tal registro. En el
bloque de texto log{} pueden emplear la cadena "auto=yes" a fin de que
el servidor registre en su archivo bitácora toda vez que alguien se
conecta al Wifi. También registrará allí a cuál punto de acceso se han
conectado. Una vez concluidas las modificaciones al archivo en el editor
Nano, lo grabamos con Ctrl+o y salimos del editor con Ctrl+x.
Vean señores, han de comprender que el cliente de RADIUS propiamente
dicho no es en este caso la laptop o el teléfono del usuario. El cliente
RADIUS es el Punto de Acceso Inalámbrico (normalmente el router Wifi),
debido a que es éste quien realiza los pedidos de autenticación contra
nuestro servidor Ubuntu dotado de FreeRADIUS. Por defecto, el demonio
FreeRADIUS configurará el localhost en el servidor como un cliente
también, pero como no necesitamos este proceder, lo desactivaremos.
Ingresamos:
nano /etc/freeradius/clients.conf
...y desactivamos tal comportamiento, comentando mediante el agregado de
"#" a las siguientes líneas:
#client localhost {
# Allowed values are:
# dotted quad (1.2.3.4)
# hostname (radius.example.com)
# ipaddr = 127.0.0.1
# OR, you can use an IPv6 address, but not both
# at the same time.
# ipv6addr = :: # any. ::1 == localhost
...
#}
...acto seguido agregamos al fichero una entrada para nuestro router
wifi "routerpirulo". Crearemos una nueva contraseña aleatoria que
ingresaremos en el router wifi y el mismo la empleará para autenticarse
contra el demoniu RADIUS. En el mismo archivo
/etc/freeradius/clients.conf modificamos:
client routerpirulo {
ipaddr = 192.168.1.100
secret = vIvApErOnCaRaJo
require_message_authenticator = yes
}
Naturalmente modificamos las partes que se ejemplifican en negrita.
Tendremos que agregar otras entradas similares en el archivo
/etc/freeradius/clients.conf, una por cada cliente (router wifi o puntos
de acceso inalámbrico) que se encuentren presentes en nuestra red. Os
recomiendo emplear una contraseña distinta para cada uno de ellas, amén
de necesitar una dirección IP estática para cada router wifi/punto de
acceso. También debemos configurar dichos datos de cliente en el
router/punto de acceso:
Configuración del EAP
A continuación habremos de editar el fichero de configuración para el
Protocolo de Autenticación Extensible (EAP). En vez de indicarles qué
líneas han de comentarse con "#", os indicaré qué necesitan hacer.
Ingresamos:
nano /etc/freeradius/eap.conf
...y debemos asegurarnos que luzca de la siguiente manera:
# -*- texto -*-
# Archivo /etc/freeradius/eap.conf de ejemplo
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 4096
tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = micontraseñaserverkey
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.pem
CA_path = ${cadir}
CA_file = ${cadir}/ca.pem
dh_file = ${certdir}/dh
random_file = /dev/urandom
cipher_list = "HIGH"
make_cert_command = "${certdir}/bootstrap"
ecdh_curve = "prime256v1"
cache {
enable = no # opcionalmente activar
lifetime = 24 # horas
max_entries = 255
}
verify {
tmpdir = /tmp/radiusd
client = "/usr/bin/openssl verify -CAfile ${..CA_file} %{TLS-Client-Cert-Filename}"
}
ocsp {
enable = no # opcionalmente activar
override_cert_url = yes
url = "http://127.0.0.1/ocsp/"
}
}
ttls {
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = no
virtual_server = "inner-tunnel"
}
}
La contraseña "micontrseñaserverkey" indicada arriba deberá coincidir
con la que emplearemos al general las claves del servidor mas adelante.
Sugiero que sea complicada y aleatoria. Lo que hemos hecho
principalmente es desactivar otros protocolos como LEAP y PEAP y
MSCHAPv2 entre otros, ninguno de los cuales recomiendo emplear. Sólo
activaremos el stack de protocolos peronista, el EAP-TLS.
Ahora hemos de desactivar los servidores por defecto. Para ello
indicamos el siguiente comando de organización para borrarlos: sudo rm
/etc/freeradius/sites-enabled/*
...y procedemos a crear un nuevo fichero de configuración para el servidor con:
nano /etc/freeradius/sites-available/mynetwork
...y nos aseguramos que contenga algo como lo siguiente:
######################################################################
authorize {
preprocess
eap {
ok = return
}
expiration
logintime
}
authenticate {
eap
}
preacct {
preprocess
acct_unique
suffix
files
}
accounting {
detail
unix
radutmp
exec
attr_filter.accounting_response
}
session {
radutmp
}
post-auth {
exec
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
pre-proxy {
}
post-proxy {
eap
}
Luego de guardar los cambios y salir del editor, lo enlazaremos con el
directorio sites-enabled de la siguiente manera:
sudo su -
cd /etc/freeradius/sites-enabled/
ln -s ../sites-available/mynetwork ./mynetwork
Podremos entonces detener el demonio FreeRADIUS y reiniciarlo en modo
debug para asegurarnos que todo arranque correctamente y no "tire"
errores. Ello lo haremos con los siguientes comandos de organización:
service freeradius stop
freeradius -X
Si todo va bien, el servicio FreeRADIUS debería arrancar como un
rastrojero, a la primera y sin toser. La terminal del sistema debería
devolvernos la indicación Ready to process requests ("Listo para
procesar pedidos"). Será ahora el momento para estar atentos a cualquier
mensaje de error gorila que el servicio nos devuelva, y si eso sucede
investigarlos. Una vez que finalicemos la evaluación, presionamos Ctrl+C
para detener la ejecución del servicio en nuestro Servidor.
Configurar los Certificados SSL
Asumiendo que todo salió bien, ahora comenzaremos a generar los
certificados SSL. Para ello comenzamos eliminando los inseguros
certificados que vienen por defecto y a la vez haremos un trabajo de
integrado básico:
cd /etc/freeradius/certs/
rm *.pem
rm *.key
mkdir /var/certs
mkdir /var/certs/freeradius
chgrp ssl-cert /var/certs/freeradius
chmod 710 /var/certs/freeradius
cp /usr/share/doc/freeradius/examples/certs/* /var/certs/freeradius/
cd /var/certs/freeradius/
rm bootstrap
chmod 600 *
make destroycerts
make index.txt
make serial
A continuación, editamos el archivo ca.cnf con:
nano ca.cnf
....y le modificamos algunas de las opciones por defecto. En particular,
debemos prestar atención y modificaremos las siguientes líneas del
fichero:
[ CA_default ]
..
default_days = 1825
default_md = sha1
..
[ req ]
default_bits = 4096
input_password = micontraseñaserverkey
output_password = micontraseñaserverkey
..
Observen bien. con 1825 días de validez, este certificado SSL del
servidor durará unos buenos 5 años (podríamos cambiar los días indicados
en la cadena default_days por los que querramos). La contraseña
"micontraseñaserverkey" indicada arriba debe coincidir con la que
pusimos en el archivo eap.conf anteriormente, y debería ser una cadena
generada aleatoriamiente. Nunca deberíamos tener que ingresar esta
contraseña a mano en ningún cliente, de modo que podemos asegurarnos que
la misma sea realmente complicada.
Ahora generaremos el archivo ca.pem.
make ca.pem
make ca.der
make printca
Acto seguido, editamos el archivo:
nano server.cnf
...y realizamos cambios que reflejen los del archivo anterior:
[ CA_default ]
..
default_days = 1825
default_md = sha1
..
[ req ]
..
default_bits = 4096
..
Bajo la etiqueta "[server]" ingresamos nuestra información de contacto
apropiada. Conforme esté todo listo, generaremos el archivo server.pem:
make server.pem
Crear los Certificados de Usuario
Conforme lleguemos a este punto, generaremos los certificados para los
clientes. Para ello primero modificaremos el archivo Makefile con:
nano Makefile
...locallizamos las líneas que dicen:
client.p12: client.crt
openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
client.pem: client.p12
openssl pkcs12 -in client.p12 -out client.pem -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
cp client.pem $(USER_NAME).pem
...y las cambiamos para que digan lo siguiente:
client.p12: client.crt
openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
cp client.p12 $(USER_NAME).p12
client.pem: client.p12
openssl pkcs12 -in client.p12 -out client.pem -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
cp client.pem $(USER_NAME).pem
client_android.p12: client.crt
openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.pem -name "$(USER_NAME)" -out client_android.p12 -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
cp client_android.p12 $(USER_NAME)_android.p12
Nota: las líneas anteriores se cortarán en su navegador, pero si se
seleccionan, copian y pegan, deberían aparecer formateadas
correctamente.
Debemos asegurarnos que las líneas adelantadas sean tabulaciones y no
espacios, o el archivo no funcionará. Este cambio creará un caso
especial para los certificados para Android, y renombrará los archivos
para que sean más sencillos para identificar.
Editamos client.cnf para establecer nuestras opciones por defecto como
lo hicimos anteriormente, pero esta vez para cualquier certificado de
cliente. Para ello ingresamos:
nano client.cnf
Probablemente querramos acortar los días por defecto a 365 (necesitará
regenerar las claves para el dispositivo cuando concluyan el año/fecha).
Debemos cambiar la cadena default_md a sha1 y default_bits a 4096:
[ CA_default ]
..
default_days = 365
default_md = sha1
..
[ req ]
..
default_bits = 4096
input_password = contraseñacliente
output_password = contraseñacliente
emailAddress = mail@correcto.delcliente
commonName = nombre_del_cliente
..
En la sección [ req ] del archivo client.cnf se encuentran las cadenas
input_password e output_password. Ponga en ambas la misma, y tenga en
mente que esta contraseña será necesaria cuando el certificado se
instale en el cliente, de manera que deberá tener un teclado para
tipearlas. La sección [client] identifica únicamente al usuario en los
archivos de bitácora, de modo que asegúrese que las cadenas emailAddress
y commonName estén configuradas correctamente.
Ahora generaremos los certificados de cliente con:
make client.pem
make client_android.p12
Para generar otro certificado para otro cliente, simplemente editamos el
archivo de nuevo con:
nano client.cnf
...lo modificamos con los datos y ejecutamos nuevamente los comandos
make client.pem y make client_android.p12 para generar otro certificado
nuevo, y repetiremos el procedimiento para cada dispositivo cuyo acceso
deseemos permitir a nuestra red Wifi empresarial. Finalmente
configurareos los permisos apropiados para los certificados y crearemos
los enlaces que necesitamos, con los siguientes Comandos de
Organización:
chmod 600 *
chmod 640 ca.pem
chmod 640 server.pem
chmod 640 server.key
chgrp ssl-cert ca.pem
chgrp ssl-cert server.pem
chgrp ssl-cert server.key
cd /etc/freeradius/certs/
ln -s /var/certs/freeradius/ca.pem ca.pem
ln -s /var/certs/freeradius/server.pem server.pem
ln -s /var/certs/freeradius/server.key server.key
No debemos olvidar que si creamos nuevos certificados de clientes (por
ejemplo, al cumplirse los 365 días) debemos volver a ejecutar las
primeras cuatro líneas de los comandos anteriores a fin de asegurarnos
que los permisos de los certificados sea nuevamente acorde a nuestras
necesidades. Cada Certficado en su Lugar Para conectarse, los archivos
pueden requerirse con la siguiente nomenclatura:
Linux: ca.pem y [usuario].p12
Android: [usuario]_android.p12
Window$: ca.der y [usuario].p12
Tengan en cuenta que al usar Wifi a través de un servidor RADIUS, las
versiones recientes de Android mostrarán constantemente una advertencia
de que su conexión está siendo monitoreada. Existen maneras en un smart
Android rooteado de instalar el archivo [usuario]_android.p12 en la
carpeta de root, pero aún así esto no afecta la operación del
dispositivo.