Inicio > Hacking, Networking, Services - Software > Wireless Hacking – Instalación y Configuración de FreeRadius – Parte XVIII

Wireless Hacking – Instalación y Configuración de FreeRadius – Parte XVIII


Hasta este punto se ha venido hablando de WPA/WPA2 utilizando PSK como mecanismo para la generación de claves Pre-compartidas entre Supplicant y Authenticator, sin embargo este mecanismo es frecuentemente utilizado en redes domesticas y resulta poco practico en entornos con un número de clientes considerable (como un entorno empresarial) en dichos casos, lo que normalmente se suele implementar para la identificación y autenticación de usuarios es un servidor Radius que se encarga de almacenar cuentas de usuarios y es utilizado directamente por el AP cada vez que un usuario quiere asociarse y autenticarse en una red.

Existen algunas implementaciones de servidores Radius disponibles en el mercado (libres y propietarias) sin embargo en esta publicación el enfoque será el uso de FreeRadius (ver http://freeradius.org/) el principal motivo es que FreeRADIUS es un servidor Radius de autenticación ampliamente usado en el mercado por empresas y varias comunidades académicas. Sin embargo, antes de comenzar a hablar sobre este servidor de autenticación, es necesario comprender que mecanismos de autenticación soporta y en que consisten, en concreto, es de especial interés mencionar el mecanismo EAP (Extensible Authentication Protocol) el cual es un framework de autenticación que se emplea no solamente en redes inalámbricas, sino también en sistemas empresariales cuyo medio de comunicación son redes cableadas. EAP es un framework soporta más de 40 tipos diferentes de autenticación que pueden verse en detalle aquí: http://wiki.freeradius.org/EAP.

Ahora se procede a instalar el servidor FreeRadius en una plataforma Linux (Debian Squeeze), antes de continuar es necesario instalar las dependencias necesarias, que en principio solamente es necesario tener la librería libssl-dev

>apt-get install libssl-dev

Ahora dirigirse a la sección de descargas del sitio oficial de FreeRADIUS aquí: http://freeradius.org/download.html

Una vez descargado y descomprimido el fichero tar.gz de distribución, es necesario ejecutar los scripts de compilación

>./configure

>make

>make install

Ahora que el servidor se encuentra instalado en la máquina, es el momento de comenzar a configurarlo.

CONFIGURACIÓN FREERADIUS

Para que un AP pueda utilizar este servidor recién instalado, tiene que indicarse de forma explicita desde la configuración del router, la máquina en el segmento de red donde se encuentra en ejecución este servidor. Hacer esto, depende exclusivamente de la interfaz administrativa que tiene cada router, en cualquier caso lo más común es que la configuración incluya los siguientes valores:

Modo de Autenticación: WPA o WPA2

IP Servidor Radius: Dirección IP donde se encuentra en ejecución el servidor Radius.

Puerto Servidor Radius: Puerto de escucha donde se encuentra activo el servidor Radius, por defecto suele ser el 1812.

Key Radius: Clave compartida entre el servidor Radius y el AP.

Cifrado WPA: Puede ser AES, TKIP o TKIP+AES

Una vez que el AP tiene esta configuración establecida, es necesario seguir los siguientes pasos mínimos para que el servidor de autenticación funcione correctamente:

  1. Creación de certificados auto firmados. Para ello, es necesario dirigirse al directorio raddb/certs ubicado en el directorio raíz del servidor. Desde allí ejecutar el script bootstrap. Este script en realidad lo único que hace es invocar a openssl para la creación de los certificados auto firmados, tarea que desde luego, puede realizarse también de forma manual invocando directamente a openssldesde linea de comandos.Ahora bien, con los comandos anteriores, se generarán una serie de ficheros que corresponden a las claves publica/privada y los certificados del lado del servidor que deben ser accesibles al servidor al momento del arranque, por lo tanto todos los contenidos generados por el script anterior deben de ser copiados al directorio donde el servidor espera que estén.
    >cp -r * /usr/local/etc/raddb/certs/
  2. Ahora se puede arrancar el servidor para comprobar que todo esta correcto, sin embargo conviene ver las opciones disponibles en el comando radiusd
    >radiusd -h Usage: radiusd [-d db_dir] [-l log_dir] [-i address] [-n name] [-fsvXx]Options:

    -C Check configuration and exit.

    -d raddb_dir Configuration files are in “raddbdir/*”.

    -f Run as a foreground process, not a daemon.

    -h Print this help message.

    -i ipaddr Listen on ipaddr ONLY.

    -l log_file Logging output will be written to this file.

    -m On SIGINT or SIGQUIT exit cleanly instead of immediately.

    -n name Read raddb/name.conf instead of raddb/radiusd.conf

    -p port Listen on port ONLY.

    -s Do not spawn child processes to handle requests.

    -t Disable threads.

    -v Print server version information.

    -X Turn on full debugging.

    -x Turn on additional debugging. (-xx gives more debugging).


    Existen algunas opciones interesantes tales como -f (ejecutar como demonio) -i (establecer una dirección IP para la escucha del servidor) -l (fichero de log) -p (puerto de escucha) -s (Para definir un único proceso padre y no hacer un fork del proceso) -X (depuración completa) -x (Depuración extra)
    En este caso concreto podría ejecutarse el siguiente comando

    >radiusd -s -X -t

    Después de esto, se puede comprobar que el puerto 1812 se encontrará abierto y esperando conexiones.

  3. Ahora bien, tal como se ha indicado en el primer paso, tanto el cliente (que en este caso es el AP) como el servidor radius deben compartir “el secreto” es decir, la clave que será empleada para realizar la autenticación entre ambas instancias. Aunque existen varios ficheros de configuración asociados al servidor de autenticación, de momento es de especial interés el que se encarga de definir el SSID del AP y el passphrase que se compartirá entre AP y el servidor radius. Dicho fiero es: /usr/local/etc/raddb/clients.conf en dicho fichero se debe incluir una configuración como la siguiente:
    client 192.168.1.0/16 {requiere_message_authenticator = nosecret = “clave”

    shortname = “ssid_prueba”

    }

    Como puede apreciarse, se ha definido el segmento de red al que aplicará esta regla de configuración, así como el SSID y la clave compartida entre el AP y el servidor radius.

  4. Ahora iniciando el servidor con la opción -X se podrá ver la configuración que se ha aplicado, buscar entre los logs generados la configuración anteriormente ingresada.

Una vez se han completado los pasos anteriores, un cliente puede intentar conectarse y en dicho caso, el proceso de autenticación será diferente, por ejemplo en el caso de utilizar el Network Manager que viene incluido en distribuciones Debian y Ubuntu, aparecerá lo siguienteDe momento no se ha creado ningún usuario, por lo tanto en los campos correspondientes a usuario y password se puede ingresar cualquier cosa. Al hacerlo, se generan una serie de logs en el servidor radius iniciado anteriormente, en donde se intenta encontrar al usuario para posteriormente verificar si las credenciales de acceso son correctas, dado que no se ha creado ningún usuario, evidentemente el proceso de autenticación fallará, sin embargo llegados a este punto, puede afirmarse que el AP se encuentra recibiendo peticiones de conexión y posteriormente las despacha al servidor radius para que se encargue de la gestión de la autenticación de usuarios.

En la próxima publicación se hablará más del procedimiento de autenticación llevado a cabo por el servidor radius y los ficheros de configuración que tiene el servidor para controlar su comportamiento.

  1. Aún no hay comentarios.
  1. No trackbacks yet.
Disculpa, debes iniciar sesión para escribir un comentario.
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 772 seguidores

%d personas les gusta esto: