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
