proyecto fin de carrerabibing.us.es/proyectos/abreproy/12446/fichero/pfc-2446... · 5.1 switch 3com...

Equation Chapter 1 Section 1

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Diseño e implantación de un servidor RADIUS

basándose en servidores Kerberos

Autor: José Mª Acero Vázquez

Tutor: Germán Madinabeitia Luque

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2018

iii

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Diseño e implantación de un servidor RADIUS

basándose en servidores Kerberos

Autor:

José Mª Acero Vázquez

Tutor:

Germán Madinabeitia Luque

Profesor colaborador

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2018

v

Proyecto Fin de Carrera: Diseño e implantación de un servidor RADIUS basándose en servidores Kerberos

Autor: José Mª Acero Vázquez

Tutor: Germán Madinabeitia Luque

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2018

El Secretario del Tribunal

vii

A mi familia, sin su apoyo no

hubiese podido llegar hasta aquí

A mis maestros por hacer

realidad mi formación, y en

especial a Germán, por su

paciencia y ayuda en la

elaboración de este PFC

ix

Agradecimientos

Quiero agradecer a todas las personas que me han ayudado de un modo u otro a la elaboración de este

proyecto y también a que pueda llevarse a cabo. Agradezco a mi madre y hermanos su insistencia en que lo

terminase, a mi mujer insistiendo también y haciéndome ver cada día lo importante de llevarlo a buen puerto y

por supuesto a mi hija, cuya sonrisa me animaba cada día a continuar.

También quiero agradecer a la Escuela de Ingenieros de Sevilla en su inmensa labor de educarnos para el

futuro, haciendo mención especial a Germán, cuya paciencia y ayuda agradezco enormemente.

Y no me quiero olvidar de todo el personal de la subdirección de sistemas de información del Servicio

Extremeño de Salud, y en especial a mis compañeros de CDATEX que me han apoyado y ayudado en todo

momento.

A todos: ¡GRACIAS!

José Mª Acero Vázquez

Miajadas, Cáceres 2018

xi

Resumen

Vivimos en un mundo donde la autenticación de usuarios juega un papel muy importante debido a la alta

conectividad de la que disponemos y al elevado número de servicios a los que accedemos. Por ello es

importante contar con sistemas que permitan una autenticación sencilla y fiable y que se pueda adaptar a todas

las casuísticas posibles.

Este es el objetivo de este proyecto fin de carrera, responder a una necesidad que surge en un momento dado y

hacerlo cumpliendo todos los requisitos necesarios y de la forma más sencilla y eficiente posible.

Veremos cómo implantar desde cero un sistema de autenticación basado en RADIUS y Kerberos, cómo

configurarlo y finalmente cómo ejecutarlo en un entorno real.

xiii

Abstract

We live in a world where user authentication plays a very important role due to the high connectivity that we

have and the high number of services we access. It is therefore important to have systems that allow simple

and reliable authentication and that can be adapted to all possible cases.

This is the objective of this final year project, to respond to a need that arises in a given moment and to do it

fulfilling all the requirements and in the most simple and efficient way possible.

We will see how to implement an authentication system based on RADIUS and Kerberos from scratch, how to

setup and execute it in a real environment.

Índice

Agradecimientos ........................................................................................................................................... ix

Resumen ....................................................................................................................................................... xi

Abstract ....................................................................................................................................................... xiii

Índice .......................................................................................................................................................... xiv

Índice de Tablas .......................................................................................................................................... xvii

Índice de Figuras ....................................................................................................................................... xviii

1 Introducción ........................................................................................................................................... 1

2 Descripción del protocolo RADIUS ......................................................................................................... 3 2.1. Introducción ...................................................................................................................................................... 3

2.1.1 Autenticación ............................................................................................................................................. 4 2.1.2 Autorización ............................................................................................................................................... 4 2.1.3 Registro ....................................................................................................................................................... 4

2.2 Propiedades del servidor RADIUS..................................................................................................................... 4 2.3 Funcionamiento del servidor RADIUS .............................................................................................................. 4

2.3.1 Formato de mensaje .................................................................................................................................. 5 2.3.2 Tipos de paquetes RADIUS ........................................................................................................................ 6 2.3.3 Clave compartida (shared-secret) ............................................................................................................ 7 2.3.4 Parejas atributo-valor ................................................................................................................................ 7 2.3.5 Diccionarios ................................................................................................................................................ 9

2.4 Métodos de autenticación ................................................................................................................................ 9 2.4.1 PAP .............................................................................................................................................................. 9 2.4.2 CHAP ......................................................................................................................................................... 10 2.4.3 Extensible Authentication Protocol (EAP) .............................................................................................. 10 2.4.4 Kerberos ................................................................................................................................................... 11 2.4.5 LDAP .......................................................................................................................................................... 11

2.5 Realms.............................................................................................................................................................. 11 2.6 Hints ................................................................................................................................................................. 12 2.7 Alta disponibilidad........................................................................................................................................... 12

3 Kerberos .............................................................................................................................................. 13 3.1 Introducción ..................................................................................................................................................... 13 3.2 Descripción del protocolo Kerberos ............................................................................................................... 14

xv

3.2.1 Pre-authentication. Ticket Granting Ticket ............................................................................................ 14 3.2.2 Uso de servicios. Ticket Granting Service ............................................................................................... 15

4 Directorio Activo de Microsoft ............................................................................................................. 18 4.1 Introducción ..................................................................................................................................................... 18 4.2 Algunas definiciones ........................................................................................................................................ 19 4.3 Cómo funciona ................................................................................................................................................. 20

5 Funcionamiento del sistema auto vlan y autenticación de red 802.1x ................................................. 22 5.1 Switch 3Com .................................................................................................................................................... 22 5.2 Switch Cisco...................................................................................................................................................... 23 5.3 802.1X .............................................................................................................................................................. 23

6 Necesidades del SES ............................................................................................................................. 25 6.1Tipos de conexiones ......................................................................................................................................... 25

6.1.1 Conexiones desde la red GPRS/UMTS .................................................................................................... 25 6.1.2 Conexiones desde los switches y otro equipamiento de red ............................................................... 25 6.1.3 Autenticación de red usando 802.1X ...................................................................................................... 26 6.1.4 Conexiones desde equipamiento inalámbrico ...................................................................................... 26

6.2 Tipos de usuarios ............................................................................................................................................. 28 6.2.1 Usuarios directorio activo ........................................................................................................................ 28 6.2.2 Usuarios ocasionales ................................................................................................................................ 28 6.2.3 Usuarios de switches ............................................................................................................................... 28

6.3 Otros requisitos ................................................................................................................................................ 28

7 Solución adoptada: Freeradius y Kerberos ........................................................................................... 29 7.1 Elementos de la solución ................................................................................................................................. 29

7.1.1 RADIUS ...................................................................................................................................................... 29 7.1.2 Kerberos .................................................................................................................................................... 30

7.2 Interoperabilidad de la solución ..................................................................................................................... 30 7.3 Ventajas/inconvenientes ................................................................................................................................ 30 7.4 Instalación ........................................................................................................................................................ 31

7.4.1 Freeradius ................................................................................................................................................. 31 7.4.2 Kerberos .................................................................................................................................................... 32

7.5 Configuración ................................................................................................................................................... 32 7.5.1 Freeradius ................................................................................................................................................. 32 7.5.2 Kerberos .................................................................................................................................................... 37 7.5.3 Integración Freeradius/Kerberos ............................................................................................................ 38 7.5.4 Integración Kerberos/Directorio Activo ................................................................................................. 39

7.6 Ejecución y comprobación del funcionamiento de los servidores ................................................................ 40 7.6.1 Freeradius ................................................................................................................................................. 40 7.6.2 Kerberos .................................................................................................................................................... 41 7.6.3 Comprobación integración Freeradius/Kerberos .................................................................................. 42 7.6.4 Comprobación integración Kerberos/Directorio Activo ....................................................................... 42

7.7 Alta disponibilidad ........................................................................................................................................... 43

8 Seguridad ............................................................................................................................................. 45 8.1 RADIUS ............................................................................................................................................................. 45 8.2 Kerberos ........................................................................................................................................................... 46

9 Configuración y comprobación del resto de equipos ........................................................................... 49 9.1Configuración de un switch ............................................................................................................................. 49

9.1.1 3Com 4400 ................................................................................................................................................ 49 9.2 Cisco 2960 .................................................................................................................................................... 52

9.2 Configuración controladora inalámbrica ....................................................................................................... 54 9.3 Configuración clientes 802.1X ........................................................................................................................ 56 9.4 Configuración conexión inalámbrica .............................................................................................................. 57

9.5 Comprobación acceso administración switches ........................................................................................... 59 9.5.1 3Com ......................................................................................................................................................... 59 9.5.2 Cisco .......................................................................................................................................................... 59

9.6 Comprobación autenticación 802.1X ............................................................................................................ 60 9.6.1 3Com ......................................................................................................................................................... 60 9.6.2 Cisco .......................................................................................................................................................... 62

9.7 Comprobación acceso inalámbrico ................................................................................................................ 62

BIBLIOGRAFÍA ............................................................................................................................................. 67

Anexo. Ficheros de configuración ................................................................................................................ 68 A.1 Freeradius ........................................................................................................................................................ 68

A.1.1 clients.conf ............................................................................................................................................... 68 A.1.2 users ......................................................................................................................................................... 75 A.1.3 ./mods-enabled/eap ............................................................................................................................... 80 A.1.4 radiusd.conf ........................................................................................................................................... 102 A.1.5 ./sites-enabled/default ......................................................................................................................... 120

A.2 Kerberos ......................................................................................................................................................... 142 A.2.1 /etc/krb5.conf ........................................................................................................................................ 142 A.2.2 /etc/krb5kdc/kdc.conf .......................................................................................................................... 143

xvii

ÍNDICE DE TABLAS

Tabla 2–1. Tipos de atributos 9

ÍNDICE DE FIGURAS

Figura 2-1. Formato de mensaje RADIUS 5

Figura 2-2. Formato de parejas atributo-valor 7

Figura 2-3. Formato de atributos específicos del fabricante 8

Figura 2-4. Autenticación EAP 11

Figura 3-1. Mecanismo de autenticación Kerberos. Fuente: web.mit.edu 15

Figura 3-2. Mecanismo de obtención TGS Kerberos. Fuente: web.mit.edu 16

Figura 4-1. Esquema Directorio Activo 20

Figura 5-1. Esquema funcionamiento 802.1X 23

Figura 5-2. Esquema funcionamiento RADA 24

Figura 6-1. Esquema funcionamiento WPA 27

Figura 9-1. Configuración wlan 54

Figura 9-2. Configuración servidor RADIUS 54

Figura 9-3. Configuración seguridad 55

Figura 9-4. Configuración servidor AAA 55

Figura 9-5. Configuración general 55

Figura 9-6. Configuración 802.1X 56

Figura 9-7. Configuración 802.1X 56

Figura 9-8. Configuración inalámbrica 57

Figura 9-9. Configuración inalámbrica II 58

Figura 9-10. Configuración inalámbrica III 58

1

1 INTRODUCCIÓN

ste proyecto ha sido realizado para el Servicio Extremeño de Salud (en adelante SES), el organismo

público autónomo encargado de gestionar el sistema de salud público extremeño.

La idea de la instalación de un servidor RADIUS surgió a la hora de querer implantar un servicio de datos

móvil. Para ello era necesario que los usuarios que usaban el servicio se autenticasen previamente a la entrada

en la red, puesto que así lo requería el operador de telefonía móvil. Éste daba la posibilidad de hacer ellos

mismos la autenticación o bien delegarla en nosotros. Por comodidad y rapidez en la gestión de los usuarios de

este servicio se optó por la segunda opción. Ello significaba que el servidor RADIUS del SES debía de

comunicarse con el del operador. Además se decidió que tenía que comunicarse también con el directorio

corporativo que ya estaba implantado, para no tener que dar de alta en varios sitios a los usuarios.

En este punto el SES fue consciente de otras posibilidades que se abrían al incluir en su red un servidor de

autenticación, y de esta forma empezaron a surgir nuevas aplicaciones para el servidor, incluso antes de que

éste se montase. Fue necesario un estudio previo sobre todos los servidores disponibles para garantizar una

elección correcta, que cubriese las necesidades actuales y tuviese en cuenta también el futuro, puesto que las

redes del SES están en continua evolución para adaptarse a las nuevas tecnologías y a la creciente demanda de

los usuarios del sistema.

La red del SES está compuesta por una gran variedad de centros de toda índole, atendiendo tanto a su tamaño

como a su funcionalidad. Estos centros son hospitales, centros de salud, consultorios, gerencias de área, otros

edificios administrativos y otros centros de sanidad variados (centros de planificación familiar, de

drogodependencia, salud mental, sociosanitarios, etc). Todos estos centros forman una compleja Intranet con

un punto especial localizado en los Servicios Centrales del SES en Mérida. Este nodo de la red contiene el

grueso de los servidores, los enlaces externos, la salida a internet, etc. En total estamos hablando de una red

con unos 15.000 usuarios repartidos por toda la geografía de Extremadura, desde sus principales ciudades

hasta sus más recónditos pueblos.

Las nuevas funcionalidades requeridas empezaron a tomar forma: autenticación centralizada para el acceso a

los switches, routers y otro equipamiento de red, autenticación para los usuarios de las redes inalámbricas y

uso de la funcionalidad de autoVLAN que poseen los switches. La primera nos iba a permitir gestionar de una

forma única el acceso a todos los switches del SES (incluyendo los de los hospitales, centros de salud, etc).

Hasta ese momento la gestión era local a cada switch, y no era por usuario, sino que existía el mismo usuario

en todos los switches. En cuanto a la segunda funcionalidad, el SES se estaba planteando el uso de redes

inalámbricas en algunas de sus sedes, pero todavía no se había abordado el tema por no tener claro el problema

de la seguridad. Puesto que el alcance de estas redes sobrepasa las fronteras físicas de los edificios se hace

necesario establecer mecanismos de autenticación de acceso a la red, así como mecanismos de cifrado para

impedir que datos tan sensibles como los datos médicos vayan 'libremente' por el aire. Por ello se optó por

montar una infraestructura de red inalámbrica basada en control de acceso usando el protocolo 802.1X y el

protocolo de cifrado WPA2. El tercer uso aplicado, autoVLAN, es una funcionalidad que poseen los switches

para que, dependiendo de las credenciales proporcionadas por el usuario, asigne una u otra vlan, comenzando

E

Introducción

2

ya la seguridad en el nivel físico directamente, puesto que podemos tener los usuarios en vlans separadas, de

forma que no se vean entre ellos, ni siquiera a nivel 2.

Además de la autenticación de los usuarios el servidor RADIUS también permite el registro de todas las

conexiones, facilitando una auditoría posterior. Con este fin se pueden instalar en el servidor una serie de

herramientas que nos permiten obtener estadísticas de uso de los recursos, para poder comprobar su correcto

funcionamiento.

Otra posibilidad que se abrió al estudiar la propuesta fue el tema de usar Kerberos. Kerberos es un sistema

creado en el MIT (Massachusetts Institute of Technology) por el cual los usuarios, una vez identificados,

pueden acceder a distintos recursos de la red sin necesidad de volverse a autenticar de nuevo, usando un

sistema de tickets. Para ello hay que cambiar los sistemas que se quieran "kerberizar" y así poder ofrecer esta

posibilidad.

Hay que indicar que el proyecto ha sido desarrollado íntegramente en el entorno del SES. Debido a ello hay

datos que no se facilitan, tales como contraseñas, direcciones IP, etc, puesto que son datos reales muy sensibles

y que la política de seguridad del SES (y los propios contratos de trabajo de acuerdo a la LOPD) no permite

difundir.

3

2 DESCRIPCIÓN DEL PROTOCOLO RADIUS

N este capítulo vamos a explicar detalladamente en qué consiste y como es la implementación del

protocolo RADIUS.

2.1. Introducción

La amplia difusión y desarrollo de las actuales redes de telecomunicación hacen más necesario que nunca

controlar el acceso que tienen los usuarios a los distintos recursos a su disposición, puesto que el catálogo es

muy amplio y no todo el mundo necesita los mismos accesos y privilegios.

RADIUS (Remote Authentication Dial-In User Service) es un protocolo ampliamente utilizado que permite la

autenticación, autorización y el registro (accounting) de los usuarios remotos que acceden a través de un

servidor de red o servidor de acceso (conocido en la terminología anglosajona como NAS, Network Access

Server).

Originariamente fue desarrollado para el acceso remoto mediante llamada telefónica (dial-up access), pero

ahora está soportado por servidores de VPN (Virtual Private Network), puntos de acceso inalámbricos,

switches con autenticación, servidores de acceso ADSL y otros tipos de servidores de acceso. En sus inicios

fue desarrollado por la empresa Livingston Enterprises (concretamente por Steve Willins, cuyo nombre aún

hoy aparece en la RFC) en respuesta a una solicitud del servidor de acceso a internet Merit Networks. Más

tarde, Livingston se convirtió en Lucent Tecnologies y a partir de ahí trabajaron junto con Merit Networks

para formalizar el protocolo y someterlo a la aprobación de la industria. Actualmente Lucent ofrece un

servidor RADIUS gratuito, aunque no es el que utilizaremos.

RADIUS está especificado en la RFC 2865 (Remote authentication Dial-In User Service, IETF Draft

Standard) y la RFC 2866 (RADIUS Accounting, informational).

Aunque el desarrollo de RADIUS fue anterior, su funcionamiento tiene mucho paralelismo con lo que se

conoce como AAA. AAA son las siglas de Authentication, Authorization and Accounting (esto es,

autenticación, autorización y registro). Este sistema se encarga de dar respuesta a las siguientes tres preguntas:

¿Quién eres?

¿Qué servicios tienes permitidos?

¿Qué haces con esos servicios?

Ahora vamos a ver cómo podemos responder a estas tres preguntas.

E

Descripción del protocolo RADIUS

4

2.1.1 Autenticación

La autenticación es el proceso de verificar la identidad de una persona o máquina. Es la respuesta a la pregunta

¿quién eres? La forma más común de realizar esto es la conocida combinación de usuario y contraseña. Hoy

día hay otros métodos de autenticación más seguros (no hay que distribuir la contraseña, por ejemplo) como

pueden ser los certificados digitales y los mecanismos de infraestructura de llave pública (PKI). Más adelante

entraremos en detalle sobre los mecanismos de autenticación que usaremos.

La autenticación persigue conseguir una relación de confianza entre los dos extremos, una vez que se ha

comprobado que el usuario es válido.

2.1.2 Autorización

Por autorización podemos entender el conjunto de reglas que nos permiten decidir qué puede hacer un usuario

previamente autenticado en un sistema. Es la respuesta a la pregunta “¿Qué servicios tienes permitidos?”.

Estas reglas serán establecidas por el administrador del sistema atendiendo al perfil que tenga el usuario que

pide la autorización, dejándole usar solo los recursos que tenga asignados. Por supuesto estas reglas deben

estar incluidas en la política de seguridad de la organización.

2.1.3 Registro

Una vez que el usuario se ha autenticado en el sistema y que tiene los recursos que le han sido asignados de

acuerdo a su perfil, es interesante saber qué hace con esos recursos. Esto es el registro. Estos datos son

guardados y pueden ser utilizados posteriormente para una auditoría, una predicción sobre el uso futuro de la

infraestructura, un seguimiento del funcionamiento normal de la red, etc. RADIUS no especifica cómo se

tienen que almacenar los datos, tan solo regula los mensajes que se pasan entre el cliente y el servidor. De este

modo al implementar el servidor tenemos libertad para guardar los datos de diversos modos, por ejemplo en

archivos de texto, en una base de datos, en archivos binarios, etc.

2.2 Propiedades del servidor RADIUS

La RFC que define las especificaciones del protocolo RADIUS dicta que:

Está basado en UDP, por lo que es no orientado a conexión.

Usa un modelo de seguridad paso-a-paso.

Es “sin estado”.

Soporta autenticación PAP y CHAP vía PPP.

Usa algoritmos MD5 para proteger las contraseñas.

Soporta el modelo AAA.

2.3 Funcionamiento del servidor RADIUS

El funcionamiento de un servidor RADIUS se basa en el paso de mensajes desde y hacia el servidor. Estos

mensajes se pasan usando el protocolo UDP (User Datagram Protocol), en detrimento del protocolo TCP. El

puerto usado es el 1812 para los mensajes de autenticación y el 1813 para los mensajes de registro. Algunos

servidores también funcionan en los puertos 1645 y 1646, aunque generalmente esto es configurable. Esta

decisión en cuanto al uso del protocolo UDP se debe al funcionamiento en sí del protocolo, en el cual el

tiempo de espera depende sobre todo de la paciencia del usuario delante de la pantalla de login. Es más

conveniente usar un protocolo que si no recibe una respuesta instantánea envíe la petición a otro servidor a

tener que dejar un usuario esperando dos minutos debido a las retransmisiones de tcp. Solo un mensaje

RADIUS va incluido en la 'carga' (payload) del protocolo UDP.

5 Diseño e implantación de un servidor RADIUS basándose en servidores Kerberos

2.3.1 Formato de mensaje

Hemos dicho anteriormente que RADIUS se basa en el paso de mensajes, ahora vamos a ver cuál es el

formato de esos mensajes. Siguen el siguiente formato:

Figura 2-1. Formato de mensaje RADIUS

Tal y como vemos en este esquema la cabecera la componen un octeto con el campo código, otro con el

campo identifier, 2 octetos para el campo length y 8 o 16 octetos para el campo authenticator. La carga del

paquete la constituyen parejas atributo-valor, con una longitud variable

Pasamos a ver cada uno de los campos:

2.3.1.1 Code

El campo “code” es de un octeto de longitud e indica el tipo de mensaje RADIUS que se envía en ese paquete.

Los códigos válidos son:

Access-Request

Access-Accept

Access-Reject

Accounting-Request

Accounting-Response

Access-Challenge

Status-Server

Status-Client

Reserved

Más adelante entenderemos el significado de todos estos campos

2.3.1.2 Identifier

El campo “identifier” es de un octeto de longitud y se usa para el enlazado de las peticiones iniciales y su

posterior respuesta. Es un identificador único del mensaje, que permite detectar mensajes duplicados (posibles

por el uso del protocolo UDP) junto con el puerto UDP origen y el tiempo transcurrido entre mensajes

2.3.1.3 Length

El campo “length” indica la longitud total en octetos del mensaje incluyendo cabecera y carga. Este campo se

verifica cuando el servidor recibe un paquete como medida para comprobar la integridad de los datos.

Sus valores válidos oscilan entre 20 y 4096.

Si llega un mensaje con una longitud mayor que la indicada en este campo, el servidor solo tomará la longitud

indicada en length, ignorando el resto. Si lo que llega es un paquete con una longitud menor que la indicada en

length, el paquete será descartado, sin avisar de ninguna forma este hecho.


6

2.3.1.4 Authenticator

El campo authenticator se usa para asegurar la integridad de los datos de carga (payload). Hay 2 tipos de

valores: los valores de petición (request) y los valores de respuesta (response). Los “request authenticators” se

usan con los mensajes Access-Request y Accounting-Request. En este caso la longitud es de 16 octetos y se

genera de una forma aleatoria para prevenir ataques. El otro tipo, el “response authenticator”, se usa en los

mensajes Access-Accept, Access-Reject y Access-Challenge. El valor de dicho authenticator se calcula usando

un hash MD5 generado a partir de los campos code, identifier, length y request-authenticator, la carga del

paquete y la 'clave compartida' (shared secret, más adelante se explicará el significado de este término).

2.3.2 Tipos de paquetes RADIUS

Pasamos a ver en detalle los distintos tipos de mensajes que maneja el protocolo RADIUS.

2.3.2.1 Access-Request

Este paquete lo envía el cliente cuando requiere los servicios de la red. El cliente envía el paquete de petición

al servidor RADIUS con una lista de los servicios requeridos. Este paquete tiene el campo 'code' igual a 1.

La carga de este mensaje puede incluir (aunque no es obligatorio, como veremos más adelante) el atributo con

el nombre de usuario que solicita el acceso. Un atributo exigido en este mensaje es la dirección IP o el nombre

del equipo de red que está haciendo la petición. También tiene que contener la contraseña del usuario, una

contraseña CHAP o un identificador de estado, pero no ambas cosas. Si la contraseña del usuario viaja por la

red lo hará en un hash MD5, no lo hace en claro, para evitar que se pueda averiguar la contraseña simplemente

capturando los paquetes.

2.3.2.2 Access-Accept

Este mensaje se envía por el servidor RADIUS al cliente para indicarle que el acceso ha sido aceptado. Si

todos los atributos enviados en el Access-Request se aceptan el servidor pondrá el campo 'code' igual a 2 y en

el campo identifier pone el valor que tenía ese mismo campo en el Access-Request. Cuando el cliente recibe el

Access-Accept lo coteja usando el campo 'identifier', descartando el paquete en caso de no coincidir.

La información incluida en la carga de este mensaje variará dependiendo de la configuración del servidor y del

cliente que haya solicitado el acceso, puesto que ofrece información acerca de los parámetros con los cuales se

acepta la conexión, y éstos dependen del mecanismo de autorización, como ya vimos anteriormente. Por

ejemplo, este mensaje podría llevar la dirección IP que se le asigna al equipo solicitante, su máscara de red,

puerta de enlace, vlan a la que pertenece el usuario, etc.

2.3.2.3 Access-Reject

Este mensaje lo envía el servidor cuando deniega el acceso solicitado por el cliente. Según la RFC que lo

regula, el servidor debe enviar siempre una respuesta al cliente, ya sea aceptando o denegando su solicitud. La

denegación puede ser debida a varios motivos: contraseña incorrecta, usuario no autorizado, etc, todo

dependerá de la configuración del servidor.

La carga de este mensaje se limita a una pareja atributo-valor que son el Reply-Message y el Proxy-State. No

puede llevar ningún otro atributo. En el Reply-Message se puede especificar el motivo por el cual se deniega el

acceso, aunque esto no está regulado, dando libertad al fabricante para poder colocar los mensajes oportunos.

2.3.2.4 Access-Challenge

Este paquete se envía desde el servidor cuando desea más información del usuario, bien sea porque recibe

información confusa o porque ésta es incompleta. Cuando el cliente recibe este mensaje responde con un

nuevo mensaje Access-Request con la información solicitada. Este intercambio de mensajes durará hasta que

el servidor tenga toda la información que necesite y ya no solicite más Access-Challenge sino que envíe un

Access-Accept o Access-Reject.


2.3.2.5 Accounting-Request

Mensaje enviado por el cliente al servidor que indica que quiere hacer un registro de la conexión. A excepción

de los atributos User-Password, CHAP-Password, Reply-Request y State, la carga de este mensaje puede

contener cualquier otro atributo de los que están permitidos en los mensajes Access-Accept o Access-Request.

2.3.2.6 Accounting-Response

Mensaje enviado por el servidor al cliente indicando que puede llevar a cabo el proceso de registro. Si esto no

fuera posible el servidor sencillamente no respondería al cliente. Al igual que pasa con el Access-Accept, el

campo identifier es igual en los paquetes de petición y respuesta, por lo que el cliente sabe qué peticiones se

han llevado o no a cabo.

Los atributos permitidos en este tipo de mensajes son el Proxy-State y cualquiera de los vendor-specific (más

adelante hablaremos sobre ellos).

2.3.3 Clave compartida (shared-secret)

La clave compartida es una contraseña conocida por el cliente y el servidor que se usa en las operaciones que

requieren cifrado de datos durante el paso de mensajes. La clave debe tener una longitud mayor de 0, pero se

recomienda que tenga una longitud de al menos 16 octetos. Esta clave nunca viaja por la red, solo se usa en

ambos extremos.

La clave compartida se define para una pareja cliente-servidor (recordando que cliente es el equipo que se

comunica con el servidor RADIUS, por ejemplo un punto de acceso wireless o una batería de modems, no

tiene por qué ser el usuario final), por lo que se puede especificar un clave compartida distinta para cada

cliente, aumentando con ello la seguridad.

2.3.4 Parejas atributo-valor

Las parejas atributo-valor que se pasan en los mensajes RADIUS son una parte esencial de estos paquetes. Por

motivos de seguridad, la RFC RADIUS restringe que ciertos atributos puedan ser usados en ciertos paquetes,

por ejemplo el atributo User-Password no está permitido en un mensaje de respuesta del servidor al cliente.

Los atributos RADIUS están definidos en las RFCs 2865, 2866, 2867, 2868, 2869 y 3162.

2.3.4.1 Formato

Las parejas atributo-valor tienen el siguiente formato:

Figura 2-2. Formato de parejas atributo-valor

Y los siguientes son los significados de cada campo

2.3.4.1.1 Number

Indica el tipo de atributo que lleva. No se pasa el nombre del atributo, solo el número (ya veremos más

adelante como podemos relacionar uno con otro con el uso de diccionarios). El número varía entre 1 y 255,

aunque hay un valor especial (el 26) que permite actuar como pasarela para los atributos específicos de los

fabricantes, de modo que el número de atributos a priori no está limitado.

2.3.4.1.2 Attribute Length

Este campo especifica la longitud del atributo, que puede ser de 3 octetos o mayor.


8

2.3.4.1.3 Value

Contiene el valor del atributo en sí. Este campo se requiere para cada atributo presente en la lista, incluso

aunque su valor sea NULL. La longitud depende de la naturaleza del atributo (por eso es necesario el campo

anterior).

2.3.4.2 Tipos de atributos

La RFC especifica el formato de datos de ciertos atributos. Por ejemplo, una dirección IP no puede ser un

número aleatorio, sino un conjunto de 4 números. Para cumplir con esto, cada valor correspondiente tiene

asignado un tipo, que simplemente indica qué tipo de valor es: hay 6 tipos diferentes:

Integer (INT) Valores enteros, se toman tal como son.

Enumerated (ENUM) Consiste también de un valor entero, pero el valor está basado en un rango de

valores configurable por el usuario, con un significado “definido”.

IP Address (IPADDR) Es un tipo de datos de 32 bit específico para transmitir direcciones IP. Una

versión reciente del protocolo RADIUS incluye soporte para direcciones Ipv6.

Character String (STRING) Estas cadenas de caracteres están pensadas para que sean cadenas en el

formato UTF-8. El dato se pasa como un array de caracteres.

Date (DATE) Es un tipo de 32 bit que representa el número de segundos transcurridos desde el 1 de

Enero de 1970

Binary (BINARY) Puede tomar el valor “0” o “1”

2.3.4.3 Atributos específicos del fabricante

El protocolo RADIUS ofrece mucha flexibilidad a los fabricantes para poder incluir sus propios atributos

específicos. Como ya hemos dicho antes, hay un atributo específico para este fin, el atributo vendor-specific,

de valor 26.

En la siguiente figura se indica cómo encaja el atributo específico del fabricante dentro del atributo estándar

RADIUS:

Figura 2-3. Formato de atributos específicos del fabricante

2.3.4.3.1 Vendor ID

Este campo son 4 octetos que representan al fabricante. Estos códigos son estándares y se definen en la RFC

como “Números asignados”. Así, cada fabricante/vendedor/desarrollador tiene un único número llamado

Network Management Private Enterprise Code o NMPEC.

2.3.4.3.2 Vendor Type

Es de un octeto de longitud e indica la funcionalidad del atributo, tal y como lo hacía el atribute number en las

parejas atributo-valor estándar. Este valor se mueve en el rango 1-255 y su significado lo define el fabricante.

2.3.4.3.3 Length

Este campo también tiene un octeto de longitud e indica la longitud total del atributo específico del fabricante,

con una longitud mínima de 7. Tiene un comportamiento idéntico al campo length de los atributos estándar.


2.3.4.3.4 Value

El valor en sí del atributo. Estos valores llevan características especiales y capacidades no estándares que cada

fabricante implementa. Su longitud viene determinada por el parámetro anterior.

2.3.5 Diccionarios

Como hemos dicho antes, en los atributos no aparece por ningún lado el nombre de éste, sino tan solo el

código que lo representa. Para los ordenadores esto puede estar bien, pero no para los humanos. Para evitar

este inconveniente se usan los diccionarios en los que se establece una relación entre el nombre del atributo y

su código de atributo. También se usan diccionarios para los atributos específicos de fabricante.

El protocolo ofrece flexibilidad a la hora de definir los diccionarios, lo único exigido es su formato y que el

servidor pueda acceder a ellos, pero se pueden almacenar en ficheros de texto, ficheros binarios, bases de

datos, etc, dependiendo de la implementación del servidor RADIUS en concreto.

Una forma posible sería usando una tabla como la siguiente, el la que se indica el número de atributo, su

nombre y su tipo:

Tabla 2–1. Tipos de atributos

# ATTRIBUTE-NAME TYPE

1 User-Name STRING

2 User-Password STRING

3 CHAP-Password STRING

…

8 Framed IP-Addres IPADDR

2.4 Métodos de autenticación

RADIUS soporta distintos protocolos para la autenticación de los usuarios. Los dos más usados son el

Password Authentication Protocol (PAP) y el CHAP (Challenge-Handshake Authentication Protocol). Otros

que también se usan son MS-CHAP (Microsoft Challenge Handshake Authentication Protocol), MS-CHAP

v2 y EAP (EAP-TLS, EAP-TTLS, EAP-MD5, EAP-PEAP, etc). También ofrece la posibilidad de usar otros

protocolos desarrollados por terceros, como por ejemplo los mecanismos de autenticación de usuario de

windows NT, Windows 2000, Linux, etc. Por lo tanto en principio podremos usar cualquier protocolo que esté

soportado por el servidor RADIUS que elijamos, puesto que no todos tienen las mismas características. Pero

gracias al uso de los atributos específicos de fabricante podemos implementar casi cualquier cosa

2.4.1 PAP

Vamos a explicar el funcionamiento de este tipo de autenticación. El cliente lee el identificador y la clave

compartida del mensaje de petición y lo envía encapsulado dentro de una secuencia hash MD5. La contraseña

original (en claro) del usuario se pasa a través de un proceso XOR. El resultado de estos dos procesos se pone

en el campo value del atributo User-Password. El servidor RADIUS hace el proceso inverso al recibir el

mensaje. Cuando la autenticación falla puede deberse a que es incorrecta bien la clave del usuario o bien la

clave compartida.

Cuando usamos PAP con RADIUS, en los paquetes de petición la única condición es que tiene que incluir el

atributo User-Password, ni siquiera el atributo User-Name es necesario en este caso.


10

2.4.2 CHAP

Al contrario que en el caso de PAP, en CHAP se usa el principio de que la contraseña no debe ser enviada en

claro en ningún paquete a través de la red. CHAP cifra el identificador de usuario y contraseña. La máquina

del usuario hace entonces el procedimiento de login, habiendo obtenido una llave (key, en este caso la clave

compartida) desde el cliente RADIUS de al menos 16 octetos de longitud. El cliente hace un hash de esa llave

y devuelve un identificador CHAP, una respuesta CHAP y el nombre de usuario al cliente RADIUS. El cliente

RADIUS, una vez que ha recibido toda la información anterior, pone el identificador chap en el campo

correspondiente dentro del atributo chap-password y envía una respuesta. El valor “desafío” (challenge)

obtenido se pone en el atributo chap-challenge o en el campo authenticator de la cabecera. Para autenticar al

usuario, el servidor RADIUS usa el valor chap-challenge, el identificador chap y la contraseña del usuario (que

tiene almacenada u obtiene de algún modo) y hace otro hash MD5. Este último resultado debe ser igual al

atributo CHAP-Password enviado por el usuario para que se permita el acceso del usuario, rechazándolo en

caso contrario. Hay que hacer notar que el servidor debe tener acceso a la contraseña en claro del usuario para

que este método pueda funcionar (no es un problema del protocolo RADIUS, sino del CHAP), por lo que

habrá que protegerlas adecuadamente (permisos de los ficheros implicados, políticas de seguridad, etc).

2.4.3 Extensible Authentication Protocol (EAP)

EAP fue originariamente creado como una extensión al protocolo PPP (Point to Point Protocol) para permitir

el desarrollo de mecanismos de autenticación de acceso a la red arbitrarios.

EAP está soportado en las recientes versiones de RADIUS, y en este proyecto es uno de los protocolos de

autenticación empleado, por lo que vamos a ver cómo funciona.

EAP soporta mecanismos de autenticación de clave pública/clave privada, tarjetas inteligentes (smarts cards),

contraseñas de un solo uso (one-time passwords) y Kerberos. Para soportar estas nuevas funcionalidades

RADIUS incluye dos nuevos atributos que son el EAP-Message y el Message-Authenticator.

Con los protocolos de autenticación PPP (Point to Point Protocol) como son PAP, CHAP, MS-CHAP y MS-

CHAPv2, el mecanismo de autenticación se elige durante la fase de establecimiento del enlace. Durante la fase

de la autenticación de la conexión, el protocolo elegido se usa para validar la conexión. Sin embargo, con EAP

el mecanismo de autenticación no se elige durante el establecimiento del enlace PPP. En lugar de eso, cuando

se crea el enlace, cada extremo de la conexión PPP usa un esquema específico de autenticación EAP,

conocido como 'tipo EAP'. Ejemplos de tipo EAP son EAP-CHAP, EAP-MSCHAP, EAP-PEAP, EAP-TLS

(TLS: transport level security) y EAP-TTLS.

El servidor RADIUS encapsula los paquetes EAP dentro de paquetes estándar RADIUS, usando el atributo

EAP-Message. Esto permite al servidor RADIUS “hablar” con otro servidor de autenticación usando un

protocolo estándar ya definido y sin necesidad de modificaciones en el propio protocolo RADIUS. Así se

pueden crear nuevos módulos de autenticación tanto en el cliente de acceso como en el servidor de

autenticación. Instalando las bibliotecas EAP necesarias en los dos extremos otro nuevo tipo de EAP puede ser

fácilmente soportado, sin tener que modificar el protocolo RADIUS ni los equipos intermedios que

únicamente tienen que transportar los mensajes EAP.

EAP va también asociado al protocolo de capa de enlace 802.1X. El protocolo IEEE 802.1X, un estándar

IEEE para la autenticación de red, define como EAP se soporta por los equipos 802, incluyendo puntos de

acceso 802.11b/g/n (WiFi) y switches ethernet.

Una transacción EAP ocurre del siguiente modo:

1. El cliente y el servidor de acceso a la red (en nuestro caso, puesto que vamos a usar EAP para el

acceso wireless el servidor de acceso será la controladora inalámbrica) negocian el uso de EAP a

través del protocolo de enlace correspondiente (en nuestro caso, 802.11b/g/n).

2. El servidor de acceso (controladora inalámbrica) envía un mensaje EAP-Request/Identity al cliente

para comprobar su identidad.

3. El cliente responde con un mensaje EAP-Response/Identity

4. El servidor de acceso recibe esta respuesta y se la reenvía al servidor RADIUS dentro de un mensaje

Access-Request, incluyendo la información recibida del cliente en el atributo EAP-Message.


5. El servidor RADIUS responde con un mensaje Access-Challenge que contiene un atributo EAP-

Message.

6. El servidor de acceso desencapsula este mensaje y se lo reenvía al cliente (por ejemplo, le pide el

usuario y la contraseña).

Estos pasos se repiten las veces que sea necesario hasta obtener del servidor RADIUS el correspondiente

Access-Accept o Access-Reject (recordemos que está obligado a responder, según la RFC).

Recalcar que el servidor de acceso a la red se comporta como una 'pasarela' entre el cliente final (usuario) y el

servidor RADIUS, sin realizar ningún tipo de proceso sobre los mensajes EAP, puesto que esta tarea la

realizan el cliente y el servidor RADIUS. Por lo tanto los tipos EAP no tienen por qué estar instalados en el

servidor de acceso, tan solo es necesario que éste soporte EAP como protocolo de autenticación y el paso de

mensajes EAP a un servidor RADIUS, pero no tiene que analizar ni modificar en modo alguno dichos

mensajes.

A continuación mostramos un diagrama con un ejemplo de autenticación EAP:

Figura 2-4. Autenticación EAP

2.4.4 Kerberos

Por supuesto RADIUS soporta el uso de un servidor Kerberos para delegar en él la autenticación de los

usuarios.

2.4.5 LDAP

RADIUS también soporta el uso de un servidor LDAP (Lightweigth Directory Access Protocol) para realizar

la autenticación de los usuarios. En este caso el servidor actuará como pasarela entre las peticiones del usuario

y las encaminará hacia el LDAP

2.5 Realms

Los 'realms' son identificadores que se ponen antes o después (prefijo o sufijo) del nombre de usuario,

separados de éste por un carácter prefijado como puede ser ‘@’,’ \’, o ‘/’, con la finalidad de que el servidor

RADIUS identifique qué servidor usará para la autenticación.

Mediante estos identificadores podemos realizar una función de proxy, dotando al sistema de una alta


12

escalabilidad. Por ejemplo, tres servidores de acceso a internet que operen en el centro, en el sur y en el norte

forman una alianza de forma que cada uno tiene su propio servidor RADIUS, pero puede ofrecer servicio a los

usuarios de las otras redes (que se identificarán usando @operador) llevando las peticiones de estos usuarios al

RADIUS correspondiente, haciendo una especie de 'roaming'. También lo podemos usar si tenemos distintos

dominios en nuestra organización y queremos que cada uno tenga un mecanismo de autenticación distinto.

2.6 Hints

El uso de hints nos permite realizar modificaciones a las peticiones que nos llegan, usando unas determinadas

reglas. Así cuando un paquete llega al servidor se comprueban esas reglas y si el paquete las cumple (por

ejemplo, un nombre de usuario, un determinado sufijo, etc) añadirle o eliminarle los atributos que estén

especificados en la regla. Esto se puede usar para asegurar la compatibilidad entre distintos servidores o entre

distintos clientes que no traten igual la información.

2.7 Alta disponibilidad

En los sistemas actuales la alta disponibilidad es algo muy importante para garantizar la continuidad del

servicio. Para conseguir alta disponibilidad se usan máquinas de respaldo (activo-activo o bien activo-backup),

redundancia geográfica, generadores eléctricos autónomos, etc. En el caso de un servidor RADIUS la alta

disponibilidad es también muy importante, ya que si el usuario no puede entrar en la red, poco importa los

servicios que en ella se ofrezcan. Por esto hay que garantizar que el servicio siempre funcione de acuerdo a sus

criterios de criticidad.

Los clientes RADIUS suelen tener la posibilidad de incluir un servidor primario y otro secundario, de modo

que si el primero cae (o no responde en el tiempo adecuado) se consulte en el segundo. Esto ya es una manera

de garantizar la alta disponibilidad.

Otro modo de tener un servicio RADIUS en alta disponibilidad es usando máquinas en cluster, de forma que

siempre haya al menos una funcionado. Podemos tener incluso máquinas funcionando en paralelo, usando

diversos métodos.

Más adelante, cuando veamos la solución adoptada para el SES estudiaremos cómo se ha resuelto el tema de la

alta disponibilidad.

13

3 KERBEROS

N este capítulo vamos a describir en detalle el sistema Kerberos, que será el sistema que realmente

autentique los usuarios en nuestro sistema.

3.1 Introducción

Kerberos es un protocolo de autenticación de redes creado por el MIT (Massachusetts Institute of Tecnology)

que permite que varios equipos de una red puedan demostrar mutuamente su identidad de manera segura. Fue

desarrollado en la década de l980 inicialmente como ‘Project Athena’. Debe su nombre a Cerbero, el perro de

tres cabezas guardián de la puerta del reino de Hades, de la mitología griega.

La identificación es mutua, de forma que tanto cliente como servidor, es decir tanto el solicitante del servicio

como el que lo ofrece, pueden asegurarse de la identidad del otro, no como ocurre en otros sistemas en los que

solo se identifica el cliente.

Kerberos se basa en criptografía de clave simétrica (los mecanismos de clave asimétrica o clave

pública/privada que se usan en la actualidad todavía no habían entrado en escena cuando se desarrolló

Kerberos inicialmente), y necesita un tercer nodo en el que confían todas las partes. Dicho tercer nodo debe

estar muy bien protegido por ser un elemento primordial en la infraestructura de Kerberos.

Antes de empezar a explicar el protocolo vamos a ver una serie de definiciones necesarias para entender el

sistema Kerberos:

Realm: Define el dominio de autenticación o reino del que se hará cargo el servidor Kerberos. Se

suele utilizar el dominio DNS de la organización y se suele poner en mayúsculas.

Principal: son las entidades que usan el sistema, por lo tanto pueden ser tanto máquinas como

personas:

Usuario: usuario@REALM

Maquina: fqdn@REALM

Servicio: servicio/fqdn@REALM

Ticket: Se utiliza para identificar a los principales. Los facilita el servidor Kerberos de la organización

(el autentication server de forma más precisa)

KDC: Key Distribution Center, es la parte principal del sistema Kerberos, que distribuye los tickets

para los diferentes servicios. Se compone a su vez de autentication server (AS), ticket granting server

(TGS) y una base de datos.

Kerberos Server: se utiliza para modificar los principales.

Ticket granting ticket (TGT): ticket especial que se usa para poder obtener tickets adicionales para el

mismo realm. Este ticket no autoriza el acceso a ningún servicio, se utiliza para autenticar al cliente en sí.

E

Kerberos

14

Para que Kerberos funcione correctamente es necesaria la configuración previa de un servicio DNS (Domain

Name System o servidor de nombres de dominio) y de un servicio de tiempo NTP (Network Time Protocol).

Ambos servicios ya están funcionando en el SES, por lo que obviaremos su instalación y configuración.

Kerberos funciona usando un sistema de tickets, de modo que cuando un usuario entra al sistema, Kerberos le

facilita un ticket con un período de validez determinado y es ese ticket el que permite identificar

inequívocamente al usuario en los sistemas que estén adheridos al sistema Kerberos, evitando así al usuario

tener que introducir su contraseña una y otra vez al acceder a distintos servicios. Esto también puede

conseguirse mediante un sistema “single sign on”, pero éste tiene la desventaja que la información de

usuario/contraseña viaja continuamente por la red. En Kerberos esto no ocurre.

Hemos visto que RADIUS y Kerberos usan información de usuarios. En el SES la información de los usuarios

está almacenada en un directorio corporativo de Microsoft, Active Directory o Directorio Activo. Creaermos

un sistema Kerberos partiendo de cero configurando un nuevo reino y a su vez, este servidor se comunicará

con el directorio activo para los dominios ya existentes. RADIUS recibirá la petición de autenticación, se la

pasará a Kerberos y éste la resolverá o si es necesario la redigirá al directorio corporativo.

Usando Kerberos podemos tener las siguientes ventajas:

Poder usar “single sign on”, es decir tener que teclear una sola vez nuestra contraseña, en lugar de

tenerla que poner una y otra vez para acceder a distintos servicios.

Asociado a lo anterior los desarrolladores de aplicaciones no se tienen que preocupar de la parte

de la autenticación y el control de los usuarios, ya que de esa parte se encargará Kerberos.

La lista de servicios que ya están “kerberizados” es muy extensa por lo que podemos usarlos sin

problemas y además hay muchas guías y protocolos estándares (GSS-API, SSPI, SASL, etc) para

desarrollar una aplicación teniendo Kerberos en mente.

Debido a su gran extensión y aceptación podemos usarlo en entornos mixtos, donde mixto

significa exactamente “cualquier” cosa, desde amplia variedad de sistemas operativos, elementos

de red, aplicaciones, entornos virtualizados, etc, con lo cual sea cual sea el entorno que usemos

Kerberos encajará perfectamente, ya que es fácilmente adaptable y configurable.

La contraseña nunca viaja por la red, de ningún modo, por lo que aunque la red sea insegura

(todas lo son) nuestra contraseña estará a salvo.

Si un usuario cambia su contraseña, el cambio hay que realizarlo (nosotros o el usuario) solo en

un sitio, no en cada servidor al que se accede.

La autenticación de los usuarios está centralizada en un solo punto.

Si queremos desautorizar a un usuario que ya se ha autenticado previamente lo podemos hacer.

No solo se autentica el usuario sino que también se autentica el servidor, y así el cliente sabe que el servidor

que le está atendiendo es quien dice ser, evitando con ello muchos de los ataques que se producen en las redes,

tanto desde dentro como desde fuera.

3.2 Descripción del protocolo Kerberos

La autenticación en Kerberos se da en dos etapas, y vamos a ver cuáles son.

3.2.1 Pre-authentication. Ticket Granting Ticket

En la versión 4 del protocolo el servidor estaba expuesto a ataques de fuerza bruta debido a que un atacante

podía pedir TGTs de forma recursiva usando diferentes principales, y así obtenía los tickets y posteriormente,

ya offline, podía usar la fuerza bruta para intentar averiguar la password del usuario.

Para evitar esto en la versión 5 se incluyen los métodos de pre-autenticación, que especifican que un cliente

debe identificarse frente al KDC antes de pedir un ticket granting ticket (TGT).

Y ahora se distinguen dos pasos:


1. Authentication Service Request (AS_Request). Es el primer mensaje que se envía al KDC e incluye

(en texto claro) el nombre del principal del cliente, el principal del ticket granting server, una marca de

tiempo o timestamp y el tiempo de validez solicitado (normalmente 8 o 10 horas). En este paso si la

pre-autenticación es obligatoria el KDC no envía todavía el TGT, si no que envía un mensaje de pre-

autenticación al cliente. Para esto normalmente se envía un timestamp cifrado con la clave del cliente,

y este a su vez responde nuevo con otro AS_Request incluyendo el timestamp cifrado, con lo que se

consigue la pre-autenticación y ahora sí se envía el TGT, usando el AS_Reply.

2. Authentication Service Reply (AS_Reply). El Authentication Server genera una clave de sesión

aleatoria y hace dos copias, una para el cliente que se suma a la AS_Reply y la segunda copia

permanece en el KDC, para cuando el cliente solicite acceso a los diferentes servicios en el futuro. El

TGT enviado al cliente se almacena en la caché de credenciales. El TGT está cifrado con la clave del

cliente, por lo que solo dicho cliente podrá descifrarlo. El mensaje de respuesta tiene dos partes, una

cifrada con la clave del usuario que incluye la copia de la clave de sesión para el usuario, el tiempo de

vida del ticket y el nombre del principal, y otra parte cifrada primero con la clave del servidor y

posteriormente con la clave del cliente que incluye la copia de la clave de sesión del servidor, un

timestamp del servidor, el tiempo de vida del ticket, el principal del cliente y la IP del cliente.

Como parte del TGT está cifrado con la clave del servidor, aunque realmente se almacena en el cliente, éste no

puede ver su contenido, al no conocer la clave para descifrarlo.

Podemos resumir el mecanismo de autenticación con esta imagen:

Figura 3-1. Mecanismo de autenticación Kerberos. Fuente: web.mit.edu

3.2.2 Uso de servicios. Ticket Granting Service

Una vez el usuario se ha autenticado y tiene el Ticket Granting Ticket (TGT), es hora de usar un servicio de

los que tenga permitidos, para ello requiere otro ticket que es el llamado Ticket Granting Service (TGS), que

generan los correpondientes TGS_Request y TGS_Reply, ambos cifrados por seguridad. El proceso tiene

lugar en tres pasos:

Kerberos

16

1. TGS_Request. Este mensaje consta de varias partes: el propio TGS_request que incluye el principal

del servicio que el cliente quiere usar, el TGT obtenido anteriormente y un autenticador que incluye la

clave generada por el KDC anteriormente y una marca de tiempo. Con este autenticador el KDC

puede comprobar que la petición viene de un cliente autenticado previamente, porque incluye la clave

de sesión que él mismo le generó.

2. TGS_Reply. Ahora el KDC genera unas nuevas claves (keys). El mensaje de respuesta nuevamente se

cifra con la clave generada en el proceso de autenticación, garantizando así que solo el cliente que lo

solicita puede ver el TGS. Al igual que en el proceso anterior hay una parte cifrada con la clave del

usuario que incluye una nueva clave de sesión, el tiempo de vida y el nombre del principal del

servicio. Y por otra parte, el TGS en sí mismo está cifrado primero con la clave generada en el primer

paso de autenticación y después con la clave actual de sesión recién generada e incluye la copia de la

nueva clave asociada al servicio, el tiempo de vida, un timestamp del KDC, el principal del cliente y

la IP del cliente.

3. Petición al servicio. Una vez que el cliente tiene el TGS, lo usará para contactar con el servicio y así

garantizarle que es quién dice ser y de esta forma el servicio sabrá que es un cliente válido y

previamente autorizado. Los pasos a seguir en esta fase dependen del servicio solicitado, por lo que no

entraremos en más detalles.

Podemos resumir el mecanismo de obtención del TGS con esta imagen:

Figura 3-2. Mecanismo de obtención TGS Kerberos. Fuente: web.mit.edu

Para que el servidor Kerberos autentique a un usuario, éste tiene que estar en su base de datos (que como

veremos más adelante, se puede enlazar con bases de datos ya existentes como por ejemplo un LDAP o un

Directorio Activo de Microsoft). En la base de datos de Kerberos está el ‘principal’, que viene a ser como el

“nombre de usuario/máquina” y también su contraseña.

El servicio de red frente al que se autentica el usuario también debe estar en la base de datos principal (master

database) de Kerberos. El principal de un servicio tiene el siguiente formato: servicio/instancia@realm_name.


El carácter ‘/’ separa el primary (servicio por ejemplo web, correo, etc) de la instancia (máquina o servidor que

ejecuta el servicio), y el carácter ‘@’ lo separa del nombre del realm.

Por cada servicio hay también un service key, solo conocido por el servicio y el sistema Kerberos. Dicho

service key también se almacena en la base de datos principal en el lado de Kerberos. En el lado del servidor

se almacena en los llamados keytab. Esta service key viene a ser como la contraseña del servicio por el lado

del servidor por lo que hay que almacenarla de forma segura dentro del servidor. Será la llave que se use para

cifrar la información que deba ser solo visible por el servidor.

Resumiendo lo que hemos visto en este capítulo: cuando un usuario inicia sesión en un dominio protegido por

Kerberos, el cliente manda la petición al servidor, que busca el principal del cliente en su base de datos. Si

dicho principal existe, el servidor devuelve un ticket-granting ticket (TGT), y la clave asociada, cifrada con la

contraseña del usuario para que solo este pueda verla. Entonces el cliente descifra el ticket con su contraseña y

la almacena en el almacén de tickets para poderla usar también posteriormente, mientras sea válida. Si ahora el

cliente quiere acceder a uno de los servicios del dominio, por ejemplo el correo, mira en su almacén de tickets

si tiene un ticket disponible para ello y que no esté caducado. Si no lo tiene, usa el ticket-granting ticket para

pedir al servidor Kerberos un ticket para dicho servicio. El servidor Kerberos comprueba si tiene configurado

ese servicio (comprobando si tiene un principal para ese servicio) y si es así nos da el ticket oportuno. Dicho

ticket vuelve al cliente que lo solicitó y éste lo envía al proveedor del servicio, que lo descifrará usando su

keytab, y si es válido admitirá la petición del cliente y la conexión quedará establecida.

18

4 DIRECTORIO ACTIVO DE MICROSOFT

n este capítulo vamos a describir brevemente en qué consiste y cómo funciona el sistema Directorio

Activo de Microsoft, puesto que es el sistema de directorio corporativo centralizado usado en el SES en

la actualidad.

4.1 Introducción

En una definición amplia un directorio no es más que una lista de objetos. Una guía telefónica es un buen

ejemplo de directorio, donde para cada uno de sus elementos se guarda el nombre, dirección y número de

telefóno.

Una red está formada por múltiples elementos: ordenadores, servidores, impresoras, usuarios, etc. Incluso en

una red pequeña es necesario tener control sobre todos estos elementos porque si no la tarea de administrarlos

se puede volver difícil y sobre todo muy tediosa.

Imaginemos una red de tan solo 10 ordenadores totalmente independientes unos de otros, y 10 usuarios. Si

cada uno de los usuarios quisiera iniciar sesión en cada uno de los ordenadores sería necesario establecer 100

cuentas de usuario en total, que además no tendrían nada que ver una con la otra, no tendrían ningún tipo de

sincronismo, por lo que los cambios hechos en un ordenador no se reflejarían en los 9 restantes. Por supuesto

gestionar todo eso sería un auténtico caos. Es un ejemplo un poco extremo pero hasta hace poco no distaba

mucho de la realidad.

Para resolver este tipo de problemas necesitamos una estructura de directorio corporativo centralizado y

Directorio Activo de Microsoft es una de las soluciones más utilizadas en la actualidad, debido a la gran

extensión de los servidores y sistemas operativos que lo soportan y también a su facilidad de uso. Pero hay

muchos más sistemas de similares características tanto de código abierto como propietarios. Algunos de los

más conocidos son Samba, Mandriva, Novell eDirectory, Sun Java Directory Server y OpenDS.

Directorio Activo es una base de datos central que incluye información sobre todos los elementos asociados a

la infraestructura de red: usuarios, grupos, carpetas, impresoras, políticas, servidores, etc.

Además de almacenar toda la información sobre los elementos también dispone de un conjunto de servicios o

facilidades que relacionan dichos elementos entre si, como que un usuario pueda iniciar sesión en una

máquina, que tenga permiso para usar una impresora, que sus ficheros se guarden en una carpeta de grupo, etc.

Todos esos servicios, facilidades y las herramientas para gestionarlos también forma parte del Directorio

Activo, puesto que sin ellos no se podría realizar la gestión.

Directorio Activo es una herramienta muy potente para llevar a cabo la gestión de una infraestructura de

equipos, porque permite tener todos los elementos bajo control y establecer reglas y políticas que facilitan la

tarea de los administradores de sistemas. Sin dicha herramienta algo tan sencillo como que un usuario se

E


conecte a una impresora determinada podría ocasionar más de un dolor de cabeza y sin embargo usando la

herramienta se convierte en una tarea muy sencilla.

Directorio Activo también permite jerarquía de usuarios en su funcionamiento, de modo que podemos tener

distintos grupos de usuario con distintos perfiles de forma que cada uno tenga acceso solo y exclusivamente a

lo que necesite para desarrollar su trabajo. La granularidad es tal que no solo podemos limitar el acceso a un

objeto en particular, sino que también se puede restringir el acceso a cada una de sus propiedades o atributos.

El servicio de directorio no solo facilita la tarea a los administradores, sino también a los usuarios. Por ejemplo

un usuario puede buscar un recurso sin saber nada acerca de los detalles del recurso, lo que le simplifica su

trabajo diario.

4.2 Algunas definiciones

Antes de continuar, para entender el funcionamiento de Directorio Activo tenemos que tener claros algunos

conceptos que se se usan en este sistema:

Objeto: cualquier elemento que pertenece al directorio, ya sea lógico (carpeta, grupo, dominio, árbol,

bosque) o físico (ordenador, impresora, servidor, etc). En general se subdividen en tres grupos:

usuarios (usuarios, grupos, departamentos, etc), recursos (carpeta compartida, impresora, etc) y

servicios (correo electrónico, acceso a internet, acceso a ficheros, configuración de programas, etc).

Por supuesto hay objetos que pueden contener a su vez otros objetos, como por ejemplo un grupo de

usuarios o el conjunto de impresoras. Dependiendo de la clase a la que pertenezca, cada objeto tendrá

una serie de características específicas, por ejemplo nombre, dirección IP, propietario, etc. Cada

objeto queda identificado a través de de un identificador único global (GUID, Global Unique

Identifier), dicho número es único y no cambia nunca en la base de datos del directorio, se crea

cuando se genera el objeto.

Unidad Organizativa (OU por sus siglas en ingés Organizational Unit): es un tipo especial de objeto

que se usa para organizar el directorio en unidades administrables. En estas OUs podemos delegar

control administrativo. Es decir, una OU nos permite agrupar objetos para poder usarlos en su

conjunto posteriormente, por ejemplo los usuarios de un departamento, todo lo que haya en un

edificio, las impresoras de una planta, etc. Se pueden crear tantas OU como necesitemos, pero hay que

seguir un orden para que la estructura lógica represente lo que nosotros deseamos y lo haga de forma

coherente.

Dominio: una colección de objetos que forma un subconjunto administrativo. Se le pone el nombre

usando el sistema de nombres DNS, por lo tanto es imprescindible que haya al menos un servidor

DNS funcionando en la red. En un dominio se permite aplicar políticas de grupo, pero dichas políticas

se aplican a dicho dominio, no se extienden ni hacia abajo (subdominios) ni hacia arriba.

Árbol: conjunto de dominios que comparten un espacio de nombres común (DNS) y están

organizados según una jerarquía específica. Los distintos dominios se enlazan con relaciones de

confianza transitivas y bidireccionales. Por ejemplo si tuviéramos el dominio empresa.net y un

subdominio de la sección de ventas llamado ventas.empresa.net, la union de ambos formaría un árbol

de dominios.

Bosque: conjunto de varios árboles que no comparten espacio común de nombres. Pueden tener

diversas relaciones de confianza entre ellos. Igual que los árboles tienen dominios con algo en común

entre ellos, en los bosques se pueden agrupar distintos árboles sin ninguna relación aparente, incluso

de organismos o empresas diferentes. Es la jerarquía superior dentro de Directorio Activo. Cada

bosque contine al menos un dominio, que será el dominio raíz del bosque. Cuando creamos el primer

dominio en nuestro sistema, éste se convierte en la raíz de un nuevo árbol y también en la raíz de un

nuevo bosque. El dominio raíz de un bosque contiene el esquema del bosque, que se comparte con el

resto de dominios.

Relación de confianza: es el método de comunicación entre dominios, árboles y bosques. Las

relaciones de confianza permiten a los usuarios de un dominio autenticarse en otro. Las hay

Directorio Activo de Microsoft

20

unidireccionales y bidireccionales. Pueden ser transitivas (A confía B, B confía en C, por lo tanto A

confía en C) o no. También hay tipos especiales de relaciones de confianza: confianza explícita,

confianza de acceso directo, confianza entre dominios, confianza de bosque, confianza externa, etc.

Controlador de dominio (DC): es un servidor o conjunto de ellos cuya función es la de controlar y

mantener el Directorio Activo funcionando. Hay al menos uno por cada dominio, pero lo más usual es

que haya al menos dos, para garantizar la alta disponibilidad del sistema. También es responsable de

de la autenticación de objetos dentro de su ámbito de control.

Sitio: es un grupo de ordenadores conectados en una misma ubicación. La ubicación puede ser la

misma físicamente o estar conectada con el ancho de banda adecuado, es decir podemos tener un sitio

con equipos en dos edificios, por ejemplo. Estas agrupaciones se usan para reducir el ancho de banda

entre distintos controladores de dominio, puesto que si tenemos diferentes DC en distintas ubicaciones

tenemos que tener en cuenta el ancho de banda que se usa entre las distintas sedes, al ser un recurso

limitado.

Partición: cada controlador de dominio puede poseer varias particiones, dependiendo de su extensión:

partición de dominio para el dominio que tiene asingado dicho DC, partición de configuración que

contiene la topología de un bosque con todos los DCs que tenga dicho bosque y partición esquema

para definir objetos de forma única en todo un bosque (puesto que la creación de un objeto es local en

cada dominio). Con la partición esquema podemos definir objetos que sean globales en el bosque, y

así no tener que configurarlos en cada uno de los dominios pertenecientes.

En la siguiente figura podemos ver cómo distintas OU pueden formar un dominio, y cómo varios de estos

dominios se pueden unir formando un árbol.

Figura 4-1. Esquema Directorio Activo

4.3 Cómo funciona

En realidad Directorio Activo es la agrupación de varios elementos que se comunican entre sí: una base de

datos LDAP, servidor de nombres DNS, servidor DHCP, también puede operar como servidor de hora NTP y

por supuesto un sistema de autenticación basado en Kerberos. Y aglutinando todo esto está el corazón del

software Directorio Activo que permite la integración de todos estos elementos, usando la consola MMC

(Microsoft Management Console).

Los objetos son independientes de su ubicación física, por lo que podemos tener por ejemplo los usuarios de

una OU repartidos entre varios edificios, y en un mismo edificio tener varias OUs, lo que da mucha

flexibilidad a la hora de establecer reglas, relaciones y políticas.

Una ventaja de usar Directorio Activo es que tanto usuarios como administradores pueden encontrar objetos

de una forma sencilla, sin tener que conocer detalles sobre el objeto en cuestión. Por ejemplo un usuario podrá


acceder a una carpeta compartida a la que tenga acceso, pero no tiene por qué saber en qué servidor está

alojada dicha carpeta ni cuáles son los detalles de su implementación.

Directorio Activo se instala en uno o más servidores de la red que actuarán como controladores de dominio. Es

una función especial que tienen los servidores con el sistema operativo de Microsoft. Para convertirlo en

controlador de dominio el administrador del sistema tiene que “promocionar” el servidor que quiere convertir.

Es una acción que se realiza de manera sencilla a través de un asistente o también se puede hacer a través de la

línea de comandos de Windows. Si alguna vez queremos que un servidor deje de ser controlador de dominio

(por ejemplo porque hemos adquirido uno con mejores características y lo queremos sustituir) hay que hacer el

proceso inverso que en terminología de Directorio Activo se llama “degradar”. Se recomienda que los

servidores que hacen de controlador de dominio no realicen además otras tareas o funciones como por ejemplo

ser un servidor web, de ficheros, etc, ya que eso podría afectar al rendimiento del sistema.

Por supuesto los controladores también se encargan de la autenticación de usuarios de su dominio, y gracias a

las relaciones de confianza un usuario de un dominio puede iniciar sesión en otro dominio que no sea el suyo.

Así el controlador de dominio se convierte en el KDC (Key Distribution Center) de su sistema Kerberos.

A los dominios se les pueden aplicar políticas de grupo que pueden incluir diversas reglas como acceso a

recursos (correo, internet, ficheros), instalación de software de forma desatendida y centralizada,

actualizaciones, cambios en los programas instalados, cambios en la configuración de los equipos, cambios

visuales, etc, ofreciendo mucha flexibilidad y control a los administradores de sistemas, siempre y cuando el

directorio esté bien definido (sobre todo su esquema lógico) y configurado.

Cuando tenemos más de un controlador de dominio la información se replica entre ellos y todos tienen la

misma importancia en la organización, son iguales entre sí. Cada controlador de dominio (DC) almacena una

copia duplicada de la base de datos del directorio y la sincronización entre ellos es automática.

Otra de las ventajas de Directorio Activo es que aisla la estructura organizativa lógica de la estructura física

real que tengamos implantada, de forma que podemos conseguir dos objetivos:

Cambiar la estructura lógica de una red sin tener que preocuparnos de su parte física.

Al contrario: cambiar toda la estructura física sin que ello nos obligue a cambiar la estructura lógica.

Además de lo que ya hemos visto, Directorio activo también ofrece al administrador de sistemas diversas

herramientas para facilitar su labor:

Servicios de certificado, de modo que podemos implementar una infraestructura de clave pública o

PKI.

Servicios de federación, para que los usuarios del Directorio Activo puedan usar un servicio de single

sign-on para acceder a distintos servicios, por ejemplo servidores web, de correo, etc.

22

5 FUNCIONAMIENTO DEL SISTEMA AUTO VLAN Y

AUTENTICACIÓN DE RED 802.1X

L sistema auto vlan de los switches nos permite asignar a los equipos que se conectan una vlan u otra

atendiendo a ciertos parámetros. Este sistema permite empezar a tratar la seguridad ya en el nivel físico

de la red. Para ello el switch tiene que soportarlo y los switches que tiene el SES (serie 4400 de 3Com y

Cisco 2960) lo soportan.

Una vez que se ha comprobado la identidad del equipo que se intenta conectar a la red se le puede conectar a la

vlan que le pertenece, no conectarlo en ninguna, o incluso desactivar (temporal o definitivamente) el puerto al

que se ha conectado el equipo, eliminando con ello la posibilidad de nuevos intentos a través de ese puerto.

La comprobación de la identidad se puede llevar a cabo de varias formas:

con usuario y contraseña ofrecido por el usuario usando el protocolo de autenticación 802.1X.

a través de su dirección MAC.

También se puede usar una combinación de los dos métodos anteriores.

Todo esto está incluido dentro de la llamada seguridad de puerto de los switches 3Com y Cisco que dispone el

SES, aunque por supuesto otros fabricantes también lo implementan.

5.1 Switch 3Com

Un puerto de un switch 3com 4400 puede estar configurado en los siguientes modos:

Sin seguridad: el puerto funcionará normalmente, sin tener en cuenta nada relativo a la seguridad.

Aprendizaje continuo: el switch va aprendiendo las direcciones MAC que se van conectando hasta

que se alcanza el número máximo de direcciones MAC permitidas. Cuando se alcanza el número

máximo permitido, se sustituye la siguiente que se vea por la primera aprendida.

Aprendizaje automático: igual que el anterior pero al llegar al número máximo permitido, al

siguiente equipo no se le permite la conexión.

Sin aprendizaje: solo se permite la conexión de usuarios especificados, identificados por su MAC.

Login en red: se usa el protocolo de autenticación 802.1X. Cuando un cliente se autentica

correctamente, el puerto se habilita.

Login seguro de red: una combinación de los dos últimos, el usuario tiene que autenticarse y

además ser un equipo válido.

Modo RADA (siglas de Basic RADIUS Authenticated Device Access). Usa un servidor RADIUS

para la autenticación del usuario basándose en su MAC. Este modo es útil cuando no se dispone de

cliente 802.1X o no se quiere utilizar (un equipo sin la configuración 802.1X necesaria, una

impresora, etc).

E


Modo RADA seguro. Igual que el anterior, pero además requiere que el cliente también se

autentique usando 802.1X.

Modo Mixto: usa el modo RADA o el login de red para ofrecer acceso al cliente.

5.2 Switch Cisco

En un switch Cisco partimos de una configuración distinta debido a sus opciones de VoIP: si un puerto está

configurado para poder llevar voz sobre IP, éste funcionará, pero solo para el tráfico de voz sobre IP, incluso

aunque el usuario no se autentique, para permitir que el teléfono siempre esté operativo. Una vez visto esto, las

opciones que tenemos son las siguientes, usando autenticación bien por MAC (port security) o bien 802.1X:

Port-security con single-host: se permite una MAC por puerto. Si el puerto cae y levanta de nuevo se

lleva de nuevo a cabo el proceso de autenticación. Si en el puerto aparece más de una MAC, el puerto

se desactiva

Port-securty con multiples hosts: se permiten varias MAC en un mismo puerto siempre que estén

autenticadas todas; si una falla, el puerto se deshabilita. Se puede establecer un número máximo de

equipos conectados.

Forced-authorized: el puerto siempre estará habilitado y no se llevará a cabo ninguna comprobación

Forced-unauthorized: el puerto siempre estará sin autenticar, ignorando los intentos del cliente.

Auto: el puerto se inicia como no autorizado cuando cambia de estado de down a up en el link, e

intenta la autenticación usando 802.1X, al igual que vimos antes en los 3Com.

5.3 802.1X

El login de red 802.1X permite controlar el acceso de usuarios habilitando o deshabilitando el puerto. Cuando

un equipo intenta acceder a la red (desde el momento en que la tarjeta de red activa el nivel de enlace) se

pregunta su identidad (para ello el equipo ha tenido que ser previamente configurado con 802.1X). Esta

identidad se envía a un servidor RADIUS para su comprobación.

En este modo de funcionamiento el switch solo permite la conexión de un equipo a cada puerto, detectando si

hay un hub o switch entre su puerto y el cliente, desactivando el puerto en ese caso.

En esta figura se muestra un esquema del funcionamiento:

Figura 5-1. Esquema funcionamiento 802.1X

Para el login de red el switch usa el protocolo EAP (Extensible Authentication Protocol).

Funcionamiento del sistema auto vlan y autenticación de red 802.1x

24

En el modo de funcionamiento RADA, en lugar de usar 802.1X se usa una lista de direcciones MAC

permitidas en el servidor RADIUS, siguiendo un esquema similar al visto anteriormente:

Figura 5-2. Esquema funcionamiento RADA

En ambos modos de funcionamiento y para ambos fabricantes (3com y Cisco) la respuesta del servidor

RADIUS incluye información suficiente para indicar al switch la vlan que tiene que asignar al usuario. Los

atributos que van en los mensajes RADIUS para este servicio son:

Framed protocol = PPP

Service-Type = Framed

Tunnel-Type = VLAN

Tunnel-Medium-Type = 802

Tunnel-Private-Group-Id= < Identificador de VLAN o vlan_id>

El último atributo es el que especifica la VLAN. Tiene la forma de un número seguido de “u” o “t” (o ninguno

de los dos) para indicar si el puerto se asigna a la vlan 'sin etiquetar' (Untagged) o 'etiquetado' (Tagged). El

número es el identificativo de la vlan en el switch.

En los switches Cisco además tenemos la posibilidad de incluir una vlan de invitados, de forma que si el

switch no recibe respuesta a sus peticiones de autenticación 802.1x a través de los mensajes del protocolo EAP

asigna el puerto a esa vlan, donde podremos tener por ejemplo un portal de ayuda que guíe al usuario para

poder arreglar su situación, descargarse un cliente 802.1X, ponerse en contacto con el soporte técnico, etc.

25

6 NECESIDADES DEL SES

N este capítulo vamos a ver las necesidades que nuestro sistema va a tener que cumplir. Estos requisitos

están impuestos por la organización y hay que cumplirlos y tenerlos en cuenta en el diseño de la

solución.

6.1Tipos de conexiones

6.1.1 Conexiones desde la red GPRS/UMTS

El SES dispone de dispositivos móviles para ofrecer acceso a su red desde cualquier punto. Cuando estos

equipos tienen que entrar en la red del SES, lanzan una petición a un APN del proveedor de servicios móviles.

Una vez que se comprueba que esa SIM tiene permitido el acceso a la red se le pasan las credenciales a un

servidor RADIUS propio del operador, que hace de proxy hasta nuestro servidor. Cuando a éste le llega la

petición comprobará primero que el origen de la petición es válido y que la clave compartida (shared secret) es

válida. Una vez hecho esto deberá comprobar en el directorio corporativo si las credenciales del usuario son

válidas. Dependiendo del grupo al que pertenece el usuario (definido por @ seguido del nombre de grupo) le

asignará los parámetros de red que le correspondan, concretamente la dirección IP, la máscara de red asociada

a esta dirección, su puerta de enlace y los servidores DNS.

Así, el dispositivo móvil pasa a ser un dispositivo de red más en el SES, con un direccionamiento propio, que

accederá al resto de redes usando su enrutamiento y sus políticas de firewall.

Por lo tanto el RADIUS que usemos tiene que tener soporte para acceder a un directorio activo, soporte de

pools de direcciones y también soporte de grupos (realms).

6.1.2 Conexiones desde los switches y otro equipamiento de red

El servidor RADIUS también se usa para ofrecer una gestión de usuarios centralizada para el acceso a los

distintos routers, switches, firewalls y otro equipamiento de red del SES. De este modo se consiguen tres

objetivos:

Cada usuario tiene su usuario y contraseña, no uno genérico para todos. Esto nos permite también

tener el control para saber qué usuarios han accedido a cada equipo, para auditorías posteriores.

El cambio de usuario y contraseña solo hay que hacerlo en un servidor centralizado, no hay que ir

equipo por equipo cambiando los usuarios.

La configuración inicial de los equipos es mucho más rápida, al no tener que definir los usuarios

manualmente en cada uno, simplemente basta dar de alta el switch en la lista de equipos

autorizados para acceder al servidor RADIUS.

Podemos asignar distintos niveles de acceso a distintos usuarios de forma centralizada y cómoda.

Pero también nos enfrentamos a un problema en este caso: si no hay conexión con el servidor RADIUS no se

E

Necesidades del SES

26

podría entrar en el switch. Para evitar esto los equipos tienen la opción de que pasados 3 intentos de conexión

fallidos al RADIUS usan la lista de usuarios locales que tengan definidos, pero solo en ese caso extremo, y así

siempre tendremos acceso al switch, aunque para este caso extremo en los switches se configurará un único

usuario.

El funcionamiento en este caso es el siguiente: el equipo (switch) lanza la petición al servidor RADIUS,

pasándole las credenciales del usuario. El servidor RADIUS comprueba estas credenciales y si son correctas

le manda el Access-Accept al equipo y también el grado de acceso permitido (administrador, operador, etc)

dependiendo del perfil del usuario.

Con esta solución, además de agilizar el acceso a los equipos podemos mantener fácilmente un registro de las

conexiones que han tenido.

6.1.3 Autenticación de red usando 802.1X

El otro uso que se le dará al RADIUS en su uso con los switches es para la realización de auto vlan con

autenticación de red 802.1X, de forma que dependiendo del usuario que se conecte o la MAC del equipo que

hace la petición, automáticamente se le asigna una vlan u otra. Las MACs que están guardadas se tratan como

si fueran usuarios, añadiendo otro grado de seguridad más, empezando en este caso por el nivel físico.

En este caso vemos que el RADIUS elegido tiene que tener soporte para “entender” los atributos vendor-

specific de 3Com y Cisco, y también tiene que tener soporte para EAP como vimos en el capítulo anterior.

6.1.4 Conexiones desde equipamiento inalámbrico

El SES dispone de una controladora inalámbrica marca Cisco integrada en la electrónica de red central(switch

Cisco 6513) para ofrecer acceso inalámbrico. Este equipo permite la conexión de puntos de acceso

inalámbricos sin inteligencia que son manejados por la controladora. Con este equipo se simplifica muchísimo

la gestión de la red inalámbrica de un edificio o campus, independientemente del número de puntos de acceso

requeridos para ofrecer la cobertura necesaria. Mediante dicho equipo se tiene una visión y una gestión

centralizada de toda la red inalámbrica, no teniendo que configurar cada punto de acceso por separado,

permitiendo además el “roaming” de un punto de acceso a otro, de forma que el usuario siempre tendrá la

mejor cobertura disponible, aunque se mueva entre distintos puntos de acceso (por ejemplo un usuario que se

mueva dentro de un edificio irá pasando por distintos puntos de acceso, conectándose a aquel que le ofrezca

mayor cobertura, siempre y cuando la señal baje del umbral mínimo configurado).

Debido a los requisitos de seguridad exigidos por el SES en cuanto a las conexiones inalámbricas, se ha optado

por el empleo de la tecnología EAP-PEAP (mschapv2) y WPA2 (AES). Estas tecnologías consisten en una

autenticación de usuario basada en RADIUS (EAP-PEAP) y un posterior cifrado de la información transmitida

usando la tecnología WPA2 (Wireless Protected Access). En cuanto a la autenticación se ha usado EAP-PEAP

porque ofrece muy buena seguridad sin necesidad de usar certificados en el cliente, ya que esto último

complicaría mucho la tarea de los administradores y sobre todo de los usuarios, por lo que preferimos

evitarlos.

Dadas las características de los equipos del SES se hacía inviable el uso de certificados en el cliente, aunque sí

es necesaria la instalación de certificados en el servidor RADIUS, por exigencias del protocolo EAP, por lo

que montamos una CA (Certificate Authority, o Autoridad de Certificación) para poder expedir nosotros

mismos los certificados usando SSL.

Para que un PC se pueda conectar a esta red inalámbrica es necesario que disponga de un cliente de acceso que

soporte los protocolos WPA y EAP-PEAP. Los sistemas operativos actuales soportan ambos sin problemas, y

por política de seguridad el equipamiento antiguo que ya no es actualizable no se permite en el SES.

Así, cuando un cliente inicia el intento de conexión, es la controladora la quien envía sus credenciales al

servidor RADIUS. En este caso, y debido a ser EAP, solo se envía el nombre de usuario. El RADIUS

responde con un paquete de “desafío” (challenge), que la controladora le reenvía al cliente, estableciéndose

una negociación hasta que el servidor RADIUS manda el Access-Accept (o el Access-Reject en caso de no ser

un usuario válido).

Por lo tanto, para esta función el RADIUS debe proveer soporte EAP-PEAP.


6.1.4.1 WPA

Aunque no forma parte en sí del objetivo del proyecto vamos a explicar un poco el funcionamiento de WPA:

Wireless Protected Access.

Hasta hace no mucho, la única manera de proteger una red wireless (nos referimos al nivel de enlace, puesto

que en niveles superiores siempre podemos poner otro grado más de protección, como por ejemplo un túnel

IPSEC) era mediante lo que se conoce como WEP (Wired Equivalent Privacy, privacidad equivalente al

cable). Pero este protocolo se reveló inseguro, puesto que si un atacante capturaba paquetes de la red durante

un tiempo (una hora podría ser suficiente) era relativamente fácil averiguar la clave WEP usada en la red.

Además, el que haya muchos paquetes en la red y el uso de claves WEP de poca longitud todavía hace más

fácil el trabajo a los atacantes.

Para solucionar estos problemas, se creó por parte del consorcio WiFI Alliance (asociación sin ánimo de lucro

formada por más de 200 empresas que tienen como objetivo el estandarizar todo lo relacionado con las

comunicaciones inalámbricas) el WPA, que ofrece nuevos mecanismos de cifrado, así como otros mecanismos

de autenticación que generalmente van asociados a este protocolo. Recordemos que la autenticación garantiza

la identidad del usuario, mientras que el cifrado se encarga de 'ocultar' el tráfico que pasa por un enlace.

Un posible esquema de uso para WPA es el siguiente:

Figura 6-1. Esquema funcionamiento WPA

Hay que destacar que WPA se habla entre el cliente final (usuario) y el Access Point correspondiente, pero que

la comunicación entre el access point y el RADIUS no va cifrada con WPA, es decir WPA solo existe “en el

aire”.

WPA se basa en WEP para su funcionamiento, pero se diferencia en que cuando se inicia una sesión, se usa

TKIP (Temporal Key Integrity Protocol) o AES (Advanced encription standard) para obtener la clave WEP de

esa sesión. Además, esa clave WEP se cambia regularmente, evitando uno de los problemas que tenía el

protocolo WEP. Cuando se produce este cambio de clave, también se re-autentica el cliente.

La información facilitada por el servidor RADIUS se utiliza para obtener esa cambiante clave WEP. Aunque

también es posible usar WPA sin tener que utilizar RADIUS: es el llamado WPA-PSK (Pre-Shared Key), en el

que se usa una 'semilla' conocida (Pre-shared key) para ir generando esas claves. Esta solución sigue siendo

mejor que WEP porque esta clave no se usa directamente para cifrar, por lo que no viaja por la red ni se puede

obtener mediante análisis del tráfico.

Por último, indicar que hay una versión de WPA que en lugar de usar TKIP, usa CCMP (Counter Mode with

CBC-MAC Protocol). CCMP usa cifrado AES (Advanced Encription Standard). AES es más seguro que

TKIP. Si bien hemos dicho antes que WPA-TKIP es una mejora sobre el WEP, AES no tiene nada que ver con

él, son protocolos independientes.

Necesidades del SES

28

6.2 Tipos de usuarios

6.2.1 Usuarios directorio activo

Son usuarios pertenecientes al SES que tienen todos sus datos en el directorio corporativo. El directorio

corporativo es un Directorio Activo de Microsoft, configurado con varios servidores actuando como

controladores de dominio.

6.2.2 Usuarios ocasionales

Usuarios invitados que no pueden ser incluidos en el Directorio Activo por falta de tiempo o datos necesarios.

Aquí también se incluyen los usuarios de prueba usados por el personal del SES. Estos usuarios se crearán en

el servidor de forma local debido a su inmediatez y comodidad.

6.2.3 Usuarios de switches

Estos usuarios no pueden coincidir con los que se usarán para el resto de aplicaciones (aunque pertenezcan a la

misma persona), debido a los atributos que es necesario mandar en los mensajes RADIUS para distinguir

distintos niveles de acceso, etc. Por esta razón se crearán usuarios en el servidor RADIUS (para esto no se

usará Kerberos) expresamente para esta tarea.

6.3 Otros requisitos

Dada la criticidad de los sistemas de información del SES, la alta disponibilidad es algo imprescindible para

garantizar siempre la continuidad. En el caso del proyecto que nos ocupa, tanto el servidor RADIUS, como el

de Kerberos también tienen que estar redundados ya que si un usuario no puede entrar en la red, poco importa

los servicios que en ella se ofrezcan. Por esto hay que garantizar que el servicio siempre funcione.

Los clientes RADIUS y Kerberos suelen tener la posibilidad de incluir un servidor primario y otro secundario,

de modo que si el primero cae (o no responde en el tiempo adecuado) se consulte en el segundo. Esto ya es una

manera de garantizar la alta disponibilidad.

Otro modo de tener un servicio RADIUS en alta disponibilidad es usando máquinas en cluster, de forma que

siempre haya al menos una funcionando. Podemos tener incluso máquinas funcionando en paralelo, usando

diversos métodos.

Otra manera de garantizar la alta disponibilidad es usando balanceadores de carga para los servicios que

estamos ofreciendo, de modo que en ellos se crea un servidor virtual (virtual server) y un pool de servidores, y

es el propio balanceador el que garantiza la alta disponibilidad y el balanceo de carga.

29

7 SOLUCIÓN ADOPTADA: FREERADIUS Y

KERBEROS

ara implantar la solución se han seleccionado los sistemas que veremos a continuación, todos ellos

ejecutándose en un servidor testing de Debian, concretamente la versión Debian Buster 7.2.0-19. Se ha

elegido como S.O. Debian por su continua actualización a últimas versiones disponibles así como su

facilidad para instalar y configurar nuevos paquetes.

7.1 Elementos de la solución

7.1.1 RADIUS

Se ha seleccionado el servidor Freeradius, concretamente la última versión disponible que es la 3.0.16.

Freeradius ya no se incluye en la distribución Debian, pero como cualquier otro software se puede instalar

descargándose el paquete .tar.gz de la página www.freeradius.org e instalándolo en el servidor, lo que además

nos permite si lo deseamos ser más específicos en los parámetros de compilación, aunque en este proyecto no

lo utilizaremos ya que es suficiente con la parametrización inicial.

Sus principales características son las siguientes:

Freeradius es uno de los servidores RADIUS más completos y modulares que existen en la

actualidad, estando entre los 5 más utilizados. Se puede utilizar tanto para pequeños sistemas

con unos pocos usuarios hasta para grandes sistemas de autenticación distribuidos. Es rápido,

flexible y muy configurable.

Está incluido dentro del 'Freeradius Server Project', algo más que solo un servidor RADIUS.

Existe más software incluido en este proyecto, como puede ser un módulo de autenticación

PAM, un módulo de autenticación para el servidor web Apache, etc.

Su base es muy similar al servidor RADIUS de Livingston. Muchos de sus ficheros de

configuración son similares y su uso será muy familiar para cualquiera que haya manejado

una variante del servidor RADIUS de Livingston.

Amplio soporte de ficheros de diccionarios con atributos específicos de fabricante. Incluye

soporte para LDAP, bases de datos MySQL, PostgreSQL, Oracle, etc. También soporta

múltiples protocolos de autenticación como EAP, con EAP-MD5, EAP-SIM, EAP-TLS,

EAP-TTLS, EAP-PEAP, y Cisco LEAP.

Tiene también soporte para actuar de proxy RADIUS, incluyendo opciones de redundancia

ante caídas y de balanceo de carga, por lo que es muy escalable.

Puede también tener más de una entrada por defecto, siendo capaz de hacer “falling through”

hacia la siguiente.

P

Solución adoptada: Freeradius y Kerberos

30

Soporte para poder limitar el número de usuarios simultáneos.

Soporte para grupos (huntgroups).

Posibilidad de uso de sentencias #INCLUDE en los ficheros de configuración.

Ha sido escrito por un grupo de desarrolladores con décadas de experiencia en

implementaciones de software para RADIUS, ingeniería de software y desarrollo de paquetes

UNIX. El resultado es la sinergia entre muchos nombres de implementaciones RADIUS

basadas en software libre, incluyendo varios desarrolladores del proyecto Debian

GNU/Linux.

7.1.2 Kerberos

En este caso teníamos claro que la solución iba a ser la oficial de Kerberos, que no es otra que la

implementación de Kerberos hecha por el MIT, concretamente los paquetes de la versión 5 del sistema

Kerberos para la distribución Debian (versión 1.16-2).

Existen otras versiones de Kerberos como pueden ser:

Heimdal Kerberos, versión desarrollada en Suecia y que es la más parecida y compatible con

la versión del MIT.

Active Directory, el conocido directorio activo de Microsoft, no es una implementación de

Kerberos como tal, pero sí está basado en su funcionamiento.

TrustBroker: es una versión comercial, desarrollada por la empresa Cybersafe.

Shishi: una versión GNU de la implementación versión 5 de Kerberos.

Aunque hemos visto que hay otras versiones, la del MIT es la más completa, la que más tiempo lleva

desarrollándose, sobre la que hay más documentación y está implementada en más soluciones a nivel global,

tanto en sistemas operativos (Linux, Unix, Windows, etc) como en servicios adaptados para poder usar la

infraestructura.

7.2 Interoperabilidad de la solución

Por simplicidad y rapidez, se han instalado las dos soluciones en la misma máquina, con lo cual nos evitamos

tener que habilitar comunicaciones entre distintas máquinas, gestiones de usuarios, permisos, etc. En otro

entorno más extenso quizás sea más conveniente dedicar un servidor para cada propósito y en el SES no se

descarta hacerlo así en un futuro próximo, conforme se vayan añadiendo más usuarios al sistema. Esta tarea

será sencilla puesto que tan solo hay que copiar las configuraciones de cada uno de los entornos a los nuevos

servidores elegidos y establecer las comunicaciones necesarias entre ellos.

Esto nos da una idea de lo escalable que es el sistema, siempre que se requiera se pueden hacer los cambios

pertinentes para llevarlo a cabo

7.3 Ventajas/inconvenientes

Como hemos visto en la introducción, Freeradius y Kerberos soportan todo lo necesario para cumplir los

requisitos del SES. Vamos a ver las ventajas frente a soluciones comerciales. Algunas de las ventajas

expuestas no son exclusividad de los componentes elegidos, sino que son aplicables al software libre en

general.

Ventajas:

No tienen costes de adquisición ni de licencias.

Son productos muy escalables.


Tiene múltiples funcionalidades

Están en continuo desarrollo, ofreciendo nuevas funcionalidades cada poco tiempo y actualizaciones

para corregir fallos previos.

Disponibilidad del código fuente.

Inconvenientes

Inexistencia de soporte por parte de una empresa.

No certificado por ningún fabricante (aunque hay empresas que ofrecen soluciones comerciales

válidas certificadas por su departamento de ingeniería, como es el caso del operador de telefonía

móvil que da servicio al SES.

Configuración tediosa y difícil a base de ficheros de texto.

7.4 Instalación

7.4.1 Freeradius

Freeradius ya no está disponible en la lista de paquetes de Debian por lo que no hay disponibles archivos

binarios y tenemos que descargar el código fuente y compilarlo e instalarlo nosotros mismos.

Podemos usar la instalación por defecto o elegir los parámetros de compilación; esta opción es algo más

complicada, pero a cambio tendremos una versión compilada con las opciones preferidas por nosotros. Las

opciones que tenemos para la compilación son las siguientes:

--enable-shared[=PKGS] build shared libraries [default=yes]

--enable-static[=PKGS] build static libraries [default=yes]

--enable-fast-install[=PKGS] optimize for fast installation

[default=yes]

--with-logdir=DIR Directory for logfiles [LOCALSTATEDIR/log]

--with-radacctdir=PATH Directory for detail files [LOGDIR/radacct]

--with-raddbdir=DIR Directory for config files [SYSCONFDIR/raddb]

--with-threads Use threads, if available. (default=yes)

--with-snmp Compile in SNMP support. (default=yes)

--disable-ltdl-install Do not install libltdl

--with-experimental-modules Use experimental and unstable modules.

(default=no)

--enable-developer urns on super-duper-extra-compile-warnings when

using gcc

Como los parámetros por defecto son suficientes para nosotros, simplemente ejecutamos:

tar xvfz freeradius-VERSION.tar.gz

cd freeradius-VERSION

./configure

make

make install


32

Los tres últimos comandos llevarán bastante tiempo ya que en ellos se comprueba que el equipo tenga todo lo

necesario y se lleva a cabo la compilación.

Y eso ya nos crea los ejecutables y todos los ficheros necesarios para el funcionamiento del servidor. Para

poder ejecutar esos comandos nuestro sistema deberá poseer un compilador de C y el gestor de dependencias

‘make’. Si como es nuestro caso tenemos un sistema “limpio” (tan solo instalamos el sistema base de debian,

sin nada más) debemos instalarlo con los comandos:

apt-get install gcc make

El sistema de paquetes automáticamente nos instalará todo lo necesario para que funcione.

7.4.2 Kerberos

Para instalar Kerberos lo podemos hacer de forma similar a Freeradius descargándonos su código fuente y

compilándolo nosotros, o bien elegir el sistema de paquetes de Debian, que es la opción más rápida y sencilla,

ya que no existe compilación. Para la instalación del servidor son necesarios los siguientes paquetes: krb5-

kdc, krb5-admin-server, por lo que simplemente ejecutando

apt-get install krb5-kdc krb5-admin-server

ya tenemos en nuestro sistema todo lo que necesitamos.

7.5 Configuración

Primeramente vamos a ver como se configuraría cada servicio por separado y posteriormente veremos los

pasos a seguir para conseguir la integración entre ellos, que serán dos: Freeradius usa Kerberos para la

autenticación y éste a su vez lee la información de los usuarios del Directorio Activo.

7.5.1 Freeradius

Toda la configuración de Freeradius se hace en base a ficheros de texto, si bien hay alternativas que ofrecen

una gestión a través de una interfaz web, usando PHP en el desarrollo, pero esta posibilidad no está todavía lo

suficientemente rodada y carece de muchas de las funcionalidades posibles. Vamos a ver únicamente los

ficheros utilizados en este proyecto, aunque Freeradius tiene más ficheros que los aquí listados.

Como en otros ficheros de configuración de Unix y Linux un '#' al principio de una línea indica que esa línea

es un comentario y no se tiene en cuenta al leer el fichero. Usaremos estos comentarios en los ficheros para

explicar qué significa exactamente cada parámetro. Los ficheros originales también son bastante

autoexplicativos e incluyen comentarios para ayudar en la configuración.

La ruta por defecto de los ficheros de configuración es /usr/local/etc/raddb.

Indicar también que aunque Freeradius posee un montón de características y soporta múltiples protocolos

haremos las modificaciones necesarias en sus ficheros de configuración para que solo demos soporte a lo que

realmente utilizamos. Para ello “comentaremos” con ‘#’ las líneas que no nos interesen en lugar de borrarlo

por si en un futuro lo volviésemos a activar. Esto nos permitirá una ejecución y una depuración mucho más

rápida.

7.5.1.1 Fichero clients.conf

Este fichero contiene los equipos (no clientes “humanos”, sino máquinas, es decir los servidores de acceso a la

red, como pueda ser un switch o la controladora inalámbrica) autorizados para acceder al servidor RADIUS,

con su correspondiente IP, una clave compartida y una descripción. Por supuesto la clave compartida también

hay que configurarla en cada uno de los servidores de acceso a la red.

Por lo tanto en este fichero tendremos que añadir todos los equipos que tengan que hablar con el servidor

RADIUS, es decir todos los switches, controladora inalámbrica, etc.


El formato para añadir un nuevo equipo es el siguiente:

client pc_jose {

ipaddr = 10.165.18.175

secret = testing123

}

En este caso he dado de alta mi propio PC, que utilizo para lanzar pruebas.

7.5.1.2 Fichero users

En el servidor RADIUS original, al usuario que no estaba en el fichero users ni tenía una cuenta local en la

máquina del servidor (lo segundo y único que se miraba) se le denegaba el acceso. Solo había una entrada por

defecto permitida si no se encontraba el usuario en el fichero. En Freeradius existe la posibilidad de tener más

de una entrada por defecto, que el servidor va comprobando “saltando” de una a otra en su orden de aparición,

parando el proceso en caso de encontrar alguna coincidencia. Usando la opción Fall-Through=yes, le decimos

al servidor que continúe comprobando el resto del fichero, incluso habiendo encontrado ya una coincidencia,

permitiendo un control mucho mayor para establecer la coincidencia. El fichero users de Freeradius soporta

incluso espacios en blanco en el nombre de usuario.

En este fichero se almacenan varios datos del usuario como pueden ser su nombre de usuario, contraseña, tipo

de servicio, IP, etc. Para cada tipo de usuario hay distinta información que podemos añadir.

Nosotros usaremos este fichero para añadir manualmente los usuarios que no estén en el Directorio Activo,

como son los invitados y los usuarios que creemos para los switches y equipos de red y por otro lado

indicaremos también en este fichero que la autenticación del resto de usuarios (el 99,99% de ellos) se haga a

través de Kerberos como veremos más adelante en la integración de RADIUS y Kerberos.

7.5.1.3.1 Ejemplo general

Un ejemplo de usuario en este fichero sería:

steve Cleartext-Password := "testing"

Service-Type = Framed-User,

Framed-Protocol = PPP,

Framed-IP-Address = 172.16.3.33,

Framed-IP-Netmask = 255.255.255.0,

Framed-Routing = Broadcast-Listen,

Framed-Filter-Id = "std.ppp",

Framed-MTU = 1500,

Framed-Compression = Van-Jacobsen-TCP-IP

7.5.1.3.2 Usuario con solo autenticacio n

Si simplemente queremos una autenticación sencilla nos basta con un usuario y la primera línea:

usuario Cleartext-Password := "contraseña"

7.5.1.3.3 Usuario red mo vil

Para los usuarios móviles, tenemos otro tipo de usuarios, que se definen así:


34

Movil1 Auth-Type = Local, User-Password == "passmovil1", Calling-Station-

Id=="34123456789"



Ascend-Client-Assign-DNS = 1,

Ascend-Client-Primary-DNS = 192.168.1.100

Ascend-Client-Secondary-DNS = 192.168.1.101,


Framed-IP-Netmask = 255.255.255.0

Donde el calling-station-id nos indica el número de la línea móvil usada. Y en este caso lo que hacemos es que

si ese usuario se conecta con esa línea móvil, además de permitirle el acceso, le enviaremos la información de

red correspondiente, es decir su IP, máscara de red y servidores DNS.

7.5.1.3.4 Usuario gestio n switch

Si el usuario lo vamos a usar para gestionar un switch hay que indicarle el nivel de acceso, en el siguiente caso

se corresponde a un switch 3com, y usamos uno de los atributos específicos de fabricante:

admin_jose Auth-Type = Local, User-Password == "password"

3Com-User-Access-Level = 3Com-Administrator

7.5.1.3.5 Usuario 802.1X

En el caso de usar RADIUS para autenticación 802.1X con auto vlan hace falta también incluir la información

correspondiente, como por ejemplo el puerto donde este usuario se ha autenticado le asignaremos la vlan 5 sin

etiquetar (u de untagged):

jose.acero User-Password == "password"

Tunnel-Type = VLAN,

Tunnel-Medium-Type = 6,

Tunnel-Private-Group-Id = "5u"

7.5.1.3.6 Resto de usuarios

Una vez que ya tengamos especificadas todas las formas que puede tener un usuario para que el RADIUS lo

valide, añadimos esta línea al final del fichero:

DEFAULT Auth-Type := Reject

Y de esta forma cualquier usuario que no cumpla con ninguno de los parámetros que se especifican a lo largo

del fichero será rechazado, sin hacer ninguna otra comprobación.

7.5.1.3 Fichero ./mods-enabled/eap

En este fichero encontramos toda la configuración relacionada con el protocolo EAP (Extensible

Authentication Protocol). En versiones anteriores de Freeradius, esta configuración estaba incluida dentro del

fichero general radiusd.conf, pero por razones de modularidad se ha decidido ubicarlo en un fichero distinto.

Incluye toda la información necesaria para poder utilizar este protocolo desde qué tipo de autenticación EAP

usar hasta dónde se encuentran los certificados para poder garantizar la autenticidad de los mensajes EAP.


7.5.1.4 Fichero radiusd.conf

Este es sin duda el fichero más importante del servidor, ya que en él está la configuración básica y se hace la

llamada a otros ficheros. También en el fichero radiusd.conf se hace referencia a otros ficheros del sistema

operativo, del directorio de instalación del programa, etc.

Como ya hemos dicho antes, Freeradius es modular y a través de su API y de este fichero, el servidor pasa las

distintas opciones y comandos a los distintos módulos. Para entender mejor el funcionamiento del fichero

debemos saber que en Freeradius se usan los siguientes operadores:

Atributo=Valor especifica el valor de un atributo, pero solo si no hay otro 'item' del mismo atributo.

Atributo:=Valor especifica el valor de un atributo, sobreescribiendo el valor antiguo si lo tuviese

Atributo==Valor comprueba que exista el atributo y lo compara con el especificado

Atributo += Valor añade ese atributo a la lista de items

Atributo!=Valor comprueba que el atributo exista y no tenga el valor especificado.

Atributo>Valor comprueba que haya un atributo en la lista con un valor mayor al especificado

Atributo < Valor igual que el anterior, pero siendo menor el valor

Atributo <= Valor igual o menor

Atributo=~expresión comprueba que la petición contenga un atributo que cumpla la expresión.

Atributo!~expresión comprueba que la petición contenga un atributo que no cumpla la expresión.

Atributo=*valor comprueba que la petición tenga ese atributo, independientemente del valor que tenga.

Atributo!*valor comprueba que la petición no tenga ese atributo, independientemente del valor del mismo.

Mostramos a continuación las partes más relevantes del fichero, donde se definen los directorios a usar y

donde se hace la referencia al resto de ficheros de configuración:

prefix = /usr/local

exec_prefix = ${prefix}

sysconfdir = ${prefix}/etc

localstatedir = ${prefix}/var

sbindir = ${exec_prefix}/sbin

logdir = ${localstatedir}/log/radius

raddbdir = ${sysconfdir}/raddb

radacctdir = ${logdir}/radacct

confdir = ${raddbdir}

modconfdir = ${confdir}/mods-config

certdir = ${confdir}/certs

cadir = ${confdir}/certs

run_dir = ${localstatedir}/run/${name}

db_dir = ${raddbdir}

$INCLUDE proxy.conf

$INCLUDE clients.conf

modules {

$INCLUDE mods-enabled/


36

}

policy {

$INCLUDE policy.d/

}

$INCLUDE sites-enabled/

7.5.1.5 Fichero ./sites-enabled/default

Al igual que el fichero eap.conf, éste también estaba incluído en radiusd.conf, pero dada su importancia se hizo

un fichero adicional. En este fichero tenemos distintas secciones que se encargan de la pre-autorización, la

autenticación, el registro y otras acciones adicionales que se pueden ejecutar después de la autenticación, etc.

Vemos las secciones más importantes del fichero:

server default {

listen {

type = auth

ipaddr = *

port = 1812

} }

authorize {

filter_username

mschap

eap {

ok = return

}

Files

Pap

}

authenticate {

Auth-Type PAP {

pap

}

Auth-Type Kerberos {

krb5

}

Auth-Type CHAP {

chap

}

Auth-Type MS-CHAP {

mschap

eap


}

accounting {

detail

post-auth {} # en esta sección se ejecutarían acciones después de

autenticar

pre-proxy {} # en esta sección se ejecutarían acciones antes de reenviar

la petición a otro RADIUS

post-proxy {}

7.5.2 Kerberos

La instalación en Debian consta de instalar básicamente dos paquetes: el krb5-kdc, que es el KDC en sí, y el

krb5-admin-server que se encargará del resto. Cuando ejecutamos los comandos de instalación el sistema nos

advierte que para crear el reino de Kerberos tendremos que ejecutar el siguiente comando:

krb5_newrealm

Que nos pide una password y los nombres de reino (nombres DNS) que queremos usar y su resultado es que

ya tenemos los ficheros básicos para Kerberos creados.

También tenemos que crear el directorio donde se va a almacenar la base de datos:

mkdir -p /usr/local/var/krb5kdc/

y crearla

kdb5_util -s create

7.5.2.1 Fichero /etc/krb5.conf

En este fichero se definen los realms así como otros parámetros relativos a la configuración del servidor. En

este caso el reino Kerberos será JOSE.RTS.

[libdefaults]

default_realm = JOSE.RTS

kdc_timesync = 1

ccache_type = 4

forwardable = true

proxiable = true

[realms]

JOSE.RTS = {

kdc = kdc01.jose.rts

admin_server = kdc01.jose.rts

}

[domain_realm]

.jose.rts = JOSE.RTS

jose.rts = JOSE.RTS

7.5.2.2 Fichero /etc/krb5kdc/kdc.conf

En este fichero se especifica los parámetros relativos al KDC (Key Distribution Center)


38

[kdcdefaults]

kdc_ports = 750,88

[realms]

JOSE.RTS = {

database_name = /var/lib/krb5kdc/principal

admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab

acl_file = /etc/krb5kdc/kadm5.acl

key_stash_file = /etc/krb5kdc/stash

kdc_ports = 750,88

max_life = 10h 0m 0s

max_renewable_life = 7d 0h 0m 0s

master_key_type = des3-hmac-sha1

#supported_enctypes = aes256-cts:normal aes128-cts:normal

default_principal_flags = +preauth

}

7.5.2.3 Fichero /etc/krb5kdc/kadm5.acl

Este fichero no viene creado por defecto, lo tenemos que crear nosotros y es una lista de control de acceso

(ACL por sus siglas en inglés) que nos permitirá restringir quién puede administar el KDC.

En nuestro caso por simplicidad simplemente tiene la siguiente línea:

*/[email protected] *

que permite que cualquier usuario que se conecte como administrador pueda modificar la base de datos.

7.5.3 Integración Freeradius/Kerberos

Una vez que tenemos instalados y correctamente funcionando tanto el servidor Freeradius como el servidor

Kerberos vamos a realizar la integración entre ellos. De esta forma no tendremos que dar de alta los usuarios

en Freeradius, sino que cuando este reciba una petición se la reenviará a Kerberos que será el encargado de

hacer la autenticación, que es lo que perseguimos.

Para ello lo primero de todo en Kerberos tenemos que crear los principales para el servidor RADIUS, y

también crearemos un usuario de prueba que nos permita comprobar que todo ha sido un éxito.

kadmin.local

kadmin.local: ank -randkey radius/[email protected]

kadmin.local: ank -randkey host/[email protected]

A continuación creamos el keytab para ambos principales:

kadmin.local: ktadd -k /tmp/krb5.keytab

host/[email protected]

kadmin.local: ktadd -k /tmp/krb5.keytab

radius/[email protected]

Como ambos servidores están en la misma máquina copiamos este fichero krb5.keytab a la carpeta de

configuración de Freeradius /usr/local/etc/raddb, y le damos los permisos necesarios para que el demonio

radiusd (y nadie más) pueda abrirlo. Si el servidor Freeradius estuviese en otra máquina habría que copiar

dicho fichero a la máquina, usando scp por ejemplo.

mailto:radius/[email protected]


Y por último creamos un usuario de prueba, aunque valdría cualquiera que tuviésemos ya creado, por

supuesto:

kadmin.local: add_principal krbtesting

nos pedirá una contaseña para dicho usuario y con eso hemos finalizado la parte del servidor Kerberos.

En cuanto al servidor Freeradius tenemos que añadir la autenticación Kerberos en el fichero

/usr/local/etc/raddb/sites-enabled/default, añadiendo lo siguiente en la parte de authentication justo después del

módulo PAM:


krb5

}

También tenemos que editar el fichero /usr/local/etc/raddb/mods-enabled/krb5, para indicarle cual es nuestro

servidor Kerberos y dónde está la keytab que generamos anteriormente, para ello le añadimos lo siguiente:

keytab = /usr/local/etc/raddb

service_principal = radius/radius.jose.rts

Por último tenemos que editar el fichero users y añadir antes de la última línea que impide el paso a todos los

usuarios la siguiente línea:

DEFAULT AUTH-Type = kerberos

Si la pusiéramos al principio del fichero autenticaría todos los usuarios contra Kerberos, pero entonces todos

los usuarios que tuviésemos configurados en el fichero users no servirían para nada y no es lo que queremos.

7.5.4 Integración Kerberos/Directorio Activo

Para que el Kerberos se autentique contra el Directorio Activo tenemos que editar nuevamente el fichero

/etc/krb5.conf, añadiendo el dominio corporativo del SES en las dos secciones correspondientes:

DOMINIOSES.RTS = {

kdc = dc.dominioses.rts

admin_server = dc.dominioses.rts

}

[domain_realm]

.dominioses.rts = DOMINIOSES.RTS

dominioses.rts = DOMINIOSES.RTS

Donde dc.dominioses.rts es el servidor del controlador de dominio.

Como no tenemos ningún principal para el DOMINIOSES.RTS tenemos que crear uno para que ambos KDC

se pueda comunicar entre sí, ya que si no, cuando le llegase al KDC JOSE.RTS una petición para autenticarse

contra DOMINIOSES.RTS no sabría qué hacer con ello. Esto es lo que en Kerberos se conoce como Cross

Realm Authentication y para ello tenemos que establecer dos nuevos principales, si queremos que la

comunicación sea bidireccional en cada uno de los KDCs. Como hemos dicho habrá dos principales, uno hace

que JOSE.RTS confíe en los principales de DOMINIOSES.RTS: krbtgt/[email protected], al

que asociaremos por supuesto una contraseña que deberá ser muy fuerte ya que se utilizará para interconectar

los dos reinos. Y otro que haga lo opuesto, que DOMINIOSES.RTS confíe en los principales de JOSE.RTS y

que será el principal krbtgt/[email protected] y al que asignaremos otra contaseña distinta a la

anterior. Esto lo podemos hacer con los siguientes comandos:

root@radius:~# kadmin.local

Authenticating as principal root/[email protected] with password.


40

kadmin.local: ank -kvno 1 -e des3-hmac-sha1:normal -e aes256-cts:normal

+requires_preauth krbtgt/[email protected]

WARNING: no policy specified for krbtgt/[email protected];

defaulting to no policy

Enter password for principal "krbtgt/[email protected]":

Re-enter password for principal "krbtgt/[email protected]":

Principal "krbtgt/[email protected]" created.

kadmin.local: ank -kvno 1 -e des3-hmac-sha1:normal -e aes256-cts:normal

+requires_preauth krbtgt/[email protected]

WARNING: no policy specified for krbtgt/[email protected];

defaulting to no policy

Enter password for principal "krbtgt/[email protected]":

Re-enter password for principal "krbtgt/[email protected]":

Principal "krbtgt/[email protected]" created.

Y ahora hay que crear los mismos dos principales en el otro KDC y añadir también nuestro dominio, pero

como eso ya es el directorio activo lo hacen mis compañeros de la sección de Sistemas.

7.6 Ejecución y comprobación del funcionamiento de los servidores

En esta sección vamos a ver cómo comprobar que el servicio que hemos montado funciona correctamente.

Para ello disponemos de más herramientas además de con los propios equipos a los que estamos ofreciendo el

servicio. El método más rápido (que no el más sencillo) puede ser mirar la salida de debug y los logs del

servidor. Hay también herramientas (para Linux y Windows) que permiten la comprobación de ciertos

parámetros del servidor, aunque siempre con más limitaciones que la propia consola donde está instalado el

servicio. Además usaremos esta información para pasársela al sistema de monitorización y control del SES,

donde un grupo de operadores vigila continuamente (24 horas al día, 7 días a la semana) el estado de la red y

los servidores, dada la alta criticidad del sistema.

Todos los sistemas están configurados para que se arranquen en el inicio del sistema, por si el servidor se

reinicia por cualquier motivo.

7.6.1 Freeradius

Para arrancar el servidor simplemente ejecutaremos el comando:

radiusd

y si no hay ningún error el servidor empezará a ejecutarse en background.

Otra opción para ejecutarlo (parándolo previamente porque no puede haber varias instancias simultáneamente)

es añadir al comando la opción –X, que lo ejecuta en modo debug y así podemos ver lo que le llega y lo que

envía, lo cual viene muy bien para hacer las pruebas y comprobar que todo funciona como debe, tras mostrar

mucha más información se quedaría tal que así:

Listening on auth address * port 1812 bound to server default

Listening on acct address * port 1813 bound to server default

Listening on auth address :: port 1812 bound to server default

Listening on acct address :: port 1813 bound to server default

Listening on auth address 127.0.0.1 port 18120 bound to server


inner-tunnel

Listening on proxy address * port 41837

Listening on proxy address :: port 55833

Ready to process requests

Para asegurarnos que los usuarios funcionan correctamente podemos usar la herramienta radtest, que hace

peticiones de autenticación al servidor RADIUS

radtest radius1 radius123 localhost 0 testing123

Sent Access-Request Id 78 from 0.0.0.0:38744 to

127.0.0.1:1812 length 77

User-Name = "radius1"

User-Password = "radius123"

NAS-IP-Address = 10.165.60.6

NAS-Port = 0

Message-Authenticator = 0x00

Cleartext-Password = "radius123"

Received Access-Accept Id 78 from 127.0.0.1:1812 to 0.0.0.0:0

length 26

Service-Type = Framed-User

Podemos comprobar que hemos recibido un Access-Accept y que además nos ha asignado el Service-Type

Framed-User, tal y como está configurado en el fichero users.

7.6.2 Kerberos

En Kerberos como ya hemos visto tenemos que ejecutar dos servicios independientes, el KDC y el admin

center:

krb5kdc

kadmind

Ahora ya podríamos conectarnos al sistema de administración y por ejemplo crear usuarios:

kadmin.local

Authenticating as principal jose/[email protected] with password.

kadmin.local: ank nuevo_usuario

WARNING: no policy specified for [email protected]; defaulting to

no policy

Enter password for principal "[email protected]":

Re-enter password for principal "[email protected]":

Principal "[email protected]" created.

Con el comando kinit podemos comprobar un usuario y ver su TGT con el comando klist

root@radius:~# kinit nuevo_usuario

Password for [email protected]:

root@radius:~# klist

Ticket cache: FILE:/tmp/krb5cc_1000_Q10TLB


42

Default principal: [email protected]

Valid starting Expires Service principal

24/05/18 19:20:03 25/05/18 05:20:03

krbtgt/[email protected]

renew until 25/05/18 19:20:01

Por supuesto estos comandos los podemos ejecutar también en una máquina remota (en esa máquina no es

necesario instalar el paquete del kdc) y el resultado sería el mismo, pero el ticket viajaría por la red.

7.6.3 Comprobación integración Freeradius/Kerberos

Para probar que la integración que hicimos anteriormente funciona podemos usar el comando radtest visto

antes con el usuario de prueba que se creó en Kerberos

root@radius:~# radtest krbtesting password localhost 0 testing123

Sent Access-Request Id 15 from 0.0.0.0:37616 to 127.0.0.1:1812

length 80

User-Name = "krbtesting"

User-Password = "password"

NAS-IP-Address = 10.165.60.6

NAS-Port = 0

Message-Authenticator = 0x00

Cleartext-Password = "password"

Received Access-Accept Id 15 from 127.0.0.1:1812 to 0.0.0.0:0

length 20

Tal y como esperábamos hemos recibido un paquete Access-Accept, por lo que comprobamos que la

integración funciona correctamente.

7.6.4 Comprobación integración Kerberos/Directorio Activo

Con el commando kinit podemos comprobar que nos podemos autenticar con el dominio del SES:

root@radius:~# kinit [email protected]

Password for [email protected]:

root@radius:~#

Y comprobamos que poniendo la contraseña correspondiente al directorio

activo podemos entrar y con el klist comprobar que tenemos el ticket

correspondiente.

Ticket cache: FILE:/tmp/krb5cc_1000_vBXjCu

Default principal: [email protected]

Valid starting Expires Service principal

30/05/18 09:04:39 30/05/18 19:04:39

krbtgt/[email protected]

renew until 31/05/18 09:04:36


7.7 Alta disponibilidad

El SES dispone de una pareja de balanceadores BIG-IP de F5, y por simplicidad esta será la solución de alta

disponibilidad que usaremos. Para ello creamos dos ‘virtual servers’ y dos ‘pools’ para RADIUS y Kerberos

respectivamente. El virtual server será el encargado de recibir las conexiones, usando una IP virtual para ello y

el virtual server envía las peticiones a los dos servidores que añadiremos al pool, que tendrán idéntica

configuración, simplmente cambiando la dirección IP y el nombre del sevidor.

45

8 SEGURIDAD

N este capítulo vamos a ver como incrementar la seguridad de los servidores RADIUS y Kerberos, tanto

de las conexiones que se realizan para accederlos como de los propios servidores y clientes.

Uno de los grandes inconvenientes de los dos sistemas proviene de una de sus mayores ventajas: su gran

expansión. El descubrimiento de un fallo de seguridad en el servidor puede afectar a millones de usuarios en

todo el mundo. Pero por supuesto también habrá mucha gente tratando de resolverlo y obtener un parche de

seguridad lo antes posible, por lo que su gran expansión es ante todo su mayor virtud.

Trataremos cada uno de los sistemas por separado.

8.1 RADIUS

Hay fallos de seguridad que son inherentes al protocolo RADIUS y otros pueden ser debidos a un mal uso del

mismo. Veremos como mitigar los primeros y cómo hacer para no cometer los segundos.

Uno de los problemas es la clave compartida. Se podría atacar esta clave teniendo un sniffer (escaneador de

redes, uno de los más conocidos es el software Wireshark) que viese peticiones Access-Request válidas y sus

correspondientes respuestas. Una vez obtenidos estos dos paquetes, se podrían hacer cálculos con MD5 usando

el código, el identificador, la longitud, el “request authenticator” y los atributos. Por supuesto esto es

computacionalmente muy complicado y se puede evitar fácilmente usando claves compartidas de gran

longitud, y que no sean solo de caracteres alfanuméricos. Si solo se pueden usar caracteres de teclado, la

longitud mínima debe ser de al menos 22 caracteres y consistiendo de letras mayúsculas, minúsculas, números

y caracteres de puntuación. Si se puede configurar la clave compartida como una secuencia de dígitos

hexadecimales (no todos los servidores ni todos los clientes soportan esta opción), se deberá usar al menos una

clave de 32 dígitos hexadecimales.

El campo Request-authenticator y la clave compartida son usadas para obtener la llave con la que se cifra el

atributo User-Password y otros atributos. Si un atacante coloca un sniffer en la red y captura tráfico entre el

cliente y el servidor RADIUS, puede crear un diccionario con los request-authenticators y la correspondiente

clave para cifrar los atributos sensibles. Si el valor del request-authenticator se repite mucho porque varios

servidores de acceso distintos tienen la misma clave compartida, hacemos más fácil la tarea de averiguar la

clave compartida. Por ello otra acción que se puede tomar es definir una clave compartida distinta para cada

pareja cliente-servidor RADIUS.

Tampoco hay autenticación de los paquetes Access-Request en la RFC del protocolo. Por lo tanto usando

técnicas de spoofing (falsear la dirección IP origen de un paquete) podíamos generar falsas peticiones Access-

Request y obtener así información del servidor. Esto se puede evitar usando técnicas de anti-spoofing, que en

el SES están implementadas en el firewall. Otro modo de evitar este inconveniente es exigir el campo

Message-Authenticator en todos los mensajes Access-Request (normalmente este campo solo es requerido en

E

Seguridad

46

los mensajes para tener autenticación EAP). Recordemos que este campo es el hash MD5 del paquete Access-

Request completo usando como llave la clave compartida. Por lo tanto tenemos que asegurar que los

servidores de acceso a la red envíen los paquetes Access-Request con el correspondiente campo Message-

Authenticator y que el servidor RADIUS descarte todos aquellos paquetes que no cumplan esta condición o en

los que falle la verificación de este campo. Este descarte se hace silenciosamente, sin advertir de ello al

solicitante, puesto que no es lo mismo que un Access-Reject.

Otro de los fallos del protocolo es que los mensajes en sí no están cifrados, con lo que alguien que tenga

acceso físico a la red podría colocar un sniffer y ver los paquetes. Este riesgo se ve bastante minimizado en el

entorno del centro de proceso de datos (CPD) puesto que tiene acceso restringido, pero para clientes que estén

en otros departamentos o incluso en otros edificios sí puede suponer un problema. Para ofrecer una mayor

seguridad en este aspecto podríamos usar un túnel IPSEC entre los clientes y el servidor RADIUS, cifrando así

el contenido de todo el tráfico que circule entre los equipos. La RFC 3162 describe el uso de IPSEC con

detalle. En este proyecto, esta solución no se ha implementado, por su complejidad y su coste.

8.2 Kerberos

El protocolo Kerberos es ya de partida bastante seguro puesto que se desarrolló pensando precisamente en ello.

Su seguridad no fue algo que surgió espontáneamente, estaba en su ADN. Además ha ido evolucionando a lo

largo de muchísimos años, haciéndose cada vez más seguro. Todos sus mensajes van cifrados por lo que es

inmune a ataques con analizadores de red.

Una de las medidas de seguridad que se ha añadido es la que ya comentamos en cuando a la pre-autenticación,

por lo que es imprescindimble que esta característica esté habilitada siempre.

Otro aspecto a tener en cuenta es usar siempre la última versión del protocolo, es decir la versión 5. El servidor

también soporta la anterior versión, la 4, pero tenemos que prohibir su uso, puesto que es más inseguro.

Debido a su importancia y a que es el almacen de claves, es servidor KDC tiene que estar fuertemente

protegido, con su sistema operativo configurado convenientemente a nivel de permisos y accesos, así como

detrás de un firewall con la máxima protección posible, ya que si un atacante tuviese acceso podría emitir

tickets no válidos, borrar la base de datos, etc.

Uno de los problemas inherentes del protocolo Kerberos es la duración del ticket. No se debe especificar un

tiempo demasiado largo porque eso puede ocasionar problemas si se llega a interceptar ese ticket. Pero

tampoco demasiado corto porque en ese caso estamos obligando al usuario a que se autentique de nuevo, lo

que además va un poco en contra de la filosofía inicial de hacer que el usuario solo se autentique una vez. Por

lo tanto hay que llegar a un compromiso. Como norma general el tiempo de validez del ticket se suele

establecer en función de la jornada de trabajo, pero en determinados usos, por ejemplo si la máquina es de uso

público y para conexiones de corta duración, ese tiempo se puede bajar lo que queramos para tener más

garantías.

Otro de los problemas del uso de Kerberos en una organización no es un problema del protocolo en sí, sino de

su implementación. Si tenemos un servicio que no podemos o no queremos “kerberizar” eso supone que ese

servicio pueda tener una autenticación distinta, y por lo tanto corremos el riesgo de que sea débil. Esto nos

puede ocasionar una brecha de seguridad en ese punto. Por lo tanto no podemos obviar nunca el tema de la

seguridad, ya que es como una cadena que es tan débil o tan fuerte como lo sean sus eslabones.

Un inconveniente asociado a lo anterior es que si un usuario tiene que tener usar varias claves para diferentes

sistemas es posible que use la misma para todos, por lo que de nada nos vale que un sistema proteja

fuertemente las contraseñas si otro no lo hace y es atacado y quedan expuestas todas las claves, las del sistema

atacado y las de Kerberos por ser las mismas.

Para prevenir este tipo de problemas podemos cambiar el tipo de autenticación frente al usuario en el proceso

inicial de autenticación (recordemos que es ese el único momento en que el usuario tiene que poner su clave).

Inicialmente Kerberos se desarrolló con mecanismos de clave simétrica, que tienen el inconveniente que

ambas claves (las del usuario y las del servidor) tienen que ser almacenadas de algún modo en el servidor.

Aunque este almacenamiento sea seguro, obliga a un alta inicial del usuario en el sistema, y en ese


establecimiento inicial también se puede ver vulnerada la clave del usuario.

Pero existen extensiones del protocolo Kerberos que soportan mecanismos de clave asimétrica, como por

ejemplo los sistemas de clave pública (PKI o Public Key Infraestructure). Con este tipo de sistemas el usuario

presenta su certificado al servidor y esa es la autenticación usada, porque tanto el servidor como el usuario

pertenecen al sistema PKI y los certificados emitidos por ésta aseguran la confianza entre ambos. Además con

este tipo de sistemas logramos otro objetivo: el usuario no puede usar claves débiles debido a que directamente

no usa claves, sino tan solo su certificado. Es posible también proteger el propio certificado mediante una

clave, para asegurar que no caiga en malas manos.

En un sistema de clave pública también se puede sustituir el certificado por otro tipo de autenticación como

por ejemplo los ya muy extendidos tokens de un solo uso, smart cards, autenticación biométrica, etc.

Otra ventaja que nos ofrecen los sistemas de clave pública es que ya no hace falta un alta previa del usuario en

el sistema, tan solo que éste disponga de una credencial admitida, simplificando así el mantenimiento del

servidor sin mermar su seguridad.

Por supuesto no todo iba a ser ventajas: la implementación y mantenimiento de una infraestructura PKI es

compleja y costosa.

También debemos tener cuidado con la seguridad del sistema DNS ya que es una pieza clave del sistema. Si

un atacante logra hacerse con el DNS puede efectuar un ataque de denegación de servicio, ya que los clientes

podrían no encontar el propio servidor Kerberos y sus servicios asociados. El cambio de un nombre DNS a

otra IP que no sea la del servidor Kerberos en principio no afecta a la seguridad de éste, ya que una vez

contactado el servidor se lleva a cabo la autenticación para verificar y eso un sistema intruso fallaría, puesto

que el sistema de autenticación de Kerberos es mutuo como ya vimos anteriormente.

Por último también señalar que otro componente clave para el sistema Kerberos es el servidor de tiempo NTP,

si éste falla y los clientes no tienen la hora sincronizada, no podrán obtener sus tickets y por lo tanto fallará el

sistema. Así que también debemos tener mecanismos que nos aseguren que el servidor NTP funcione

correctamente.

49

9 CONFIGURACIÓN Y COMPROBACIÓN DEL

RESTO DE EQUIPOS

demás del sistema de autenticación en sí que hemos ido instalando y configurando también forman

parte de la solución los elementos que se conectan a dicho sistema. En este capítulo veremos cómo

configurar los distintos clientes del sistema, ya que sin esta configuración no podremos aprovechar

nada de lo que hemos realizado. Los equipos que tenemos que configurar son: switches, clientes 802.1X,

controladora inalámbrica y clientes inalámbricos.

9.1Configuración de un switch

Tenemos que configurar el switch para que la autenticación de los usuarios se haga mediante RADIUS.

Vamos a ver cómo hacerlo en un antiguo switch 3com 4400 y un más moderno Cisco 2960. En cada uno de

los switches hay que realizar dos tareas

Configurar el switch para que el acceso a la gestión del mismo sea por RADIUS.

Configurar el protocol 802.1X para que los equipos conectados al switch se autentiquen.

9.1.1 3Com 4400

9.1.1 Acceso

El switch tiene gestión vía web, a través de puerto de consola serie y también a través de telnet/SSH.

Usaremos este último por su comodidad y rapidez.

Cuando nos conectamos al switch por primera vez nos aparece la siguiente pantalla:

Login: admin

Password:

Menu options: --------------3Com SuperStack 3 Switch 4400----

bridge - Administer bridge-wide parameters

feature - Administer system features

gettingStarted - Basic device configuration

logout - Logout of the Command Line Interface

physicalInterface - Administer physical interfaces

protocol - Administer protocols

A

Configuración y comprobación del resto de equipos

50

security - Administer security

system - Administer system-level functions

trafficManagement - Administer traffic management

Type ? for help

------------------------------------SW_Pruebas (1)-----------

Select menu option:

Dentro de security->RADIUS encontramos las distintas opciones que necesitamos:

Select menu option (security): RADIUS

Menu options: --------------3Com SuperStack 3 Switch 4400----

accounting - Administer RADIUS accounting

authentication - Administer RADIUS authentication

pollTime - Set the RADIUS failure poll time

retries - Modify RADIUS retry parameters

setup - RADIUS configuration wizard

sharedSecret - Modify RADIUS security key

summary - Display summary information

Type "quit" to return to the previous menu or ? for help

------------------------------------SW_Pruebas (1)-----------

Lo primero ejecutamos con setup el configuration wizard, que nos pide la información sobre el servidor o

servidores:

Select menu option (security/radius): setup

Enter primary authentication server IP address [0.0.0.0]: 10.165.60.6

Enter primary authentication server UDP port number (?)[1812]:

Enter secondary authentication server IP address [0.0.0.0]:

Enter secondary authentication server UDP port number (?)[1812]:

Enter shared secret (?):

Enter primary accounting server IP address [0.0.0.0]: 10.165.60.6

Enter primary accounting server UDP port number (?)[1813]:

Enter secondary accounting server IP address [0.0.0.0]:

Enter secondary accounting server UDP port number (?)[1813]:

Select action on accounting failure (ignore,reject)[ignore]:

Select menu option (security/radius):

Dicha información la podemos comprobar también si queremos con el comando summary. Una vez

configurado el servidor RADIUS volvemos al menú anterior con quit, y en este menú nos aparece:

Select menu option (security/radius): quit

Menu options: --------------3Com SuperStack 3 Switch 4400----------

device - Administer device security


network - Administer network security

radius - Administer RADIUS security


Si escogemos la opción device

Menu options: --------------3Com SuperStack 3 Switch 4400----------

access - Administer access rights

authentication - Administer authentication mode

ssh - Administer SecureShell

trustedIpHost - Administer Trusted IP Host

user - Administer users


En este menú si elegimos authentication podemos elegir entre local (usuarios locales en el switch,

como está actualmente) o RADIUS, que hará que a partir de entonces la autenticación de acceso a la

administración del switch se lleve a cabo a través del servidor RADIUS, por lo tanto es la opción que

escogemos.

Select menu option (security/device/authentication): system

Select authentication mode (local,RADIUS)[local]:

9.1.2 802.1X

Volvemos de nuevo al menú anterior y escogemos esta vez la opción network, dentro de este menú solo hay

una opción que es access, por lo que usamos esa:

Menu options: --------------3Com SuperStack 3 Switch 4400---------------

access - Administer network access security


------------------------------------SW_Pruebas (1)----------------------

Select menu option (security/network): access

Menu options: --------------3Com SuperStack 3 Switch 4400---------------

detail - Display port users

localAuth - Administer local authentication database

portPrivacy - Configure port privacy

portSecurity - Configure port security

secureAddresses - Administer MAC addresses

summary - Display port security settings

systemMode - Enable/disable network security

systemSummary - Display summary information


Para habilitar los distintos modos de funcionamiento que vimos anteriormente tenemos que ejecutar el

comando portSecurity:


52

Select menu option (security/network/access): portsec

Select user ports (unit:port...,?): 1:1

Enter mode of operation (?)[noSecurity]: ?

One of the following items may be selected at this prompt:

autoLearn,continuallyLearn,learningOff,nbxNetworkLogin,noSecurity,r

ada,

radaAndNetworkLogin,radaElseNetworkLogin,radaOrNetworkLogin,

secureNetworkLogin,standardNetworkLogin

Enter mode of operation (?)[noSecurity]:

Y una vez escogido el modo que queramos hay que habilitar la seguridad en la red con el comando systemMode

Select menu option (security/network/access): systemMode

Enter system mode (enable,disable)[disable]:

Y con esto terminamos con las opciones de seguridad para un switch 3com. Vía web todo es similar solo que

lo hacemos con un navegador y va más lento y puede haber problemas con navegadores actuales, por lo que se

recomienda usar el modo texto.

9.2 Cisco 2960

9.2.1 Acceso

Los switches Cisco modelo 2960 también tienen administración vía web, pero es muy básica y no incluye

ninguna de las opciones de seguridad. Tampoco las incluye el software de gestión de Cisco llamado Cisco

Network Assistant (CNA), por lo que al igual que hicimos con 3com usaremos telnet/SSH para conectarnos al

equipo.

En los equipos Cisco no hay pantallas de configuración como en 3com, sino que ejecutan un potente sistema

operativo llamado IOS con multitud de comandos y opciones por lo que ofrecen muchas más funcionalidades,

aunque evidentemente su gestión es algo más compleja.

Para entrar a la configuración ejecutamos el comando:

SW_CISCO_PRUEBAS#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW_CISCO_PRUEBAS(config)#

Lo primero que hay que hacer para empezar activar la seguridad es configurar un nuevo modelo AAA:

SW_CISCO_PRUEBAS(config)#aaa new-model

Lo siguiente será añadir el servidor RADIUS:

SW_CISCO_PRUEBAS(config)#radius server radius_jose


SW_CISCO_PRUEBAS(config-radius-server)#?

RADIUS server sub-mode commands:

address Specify the radius server address

automate-tester Configure server automated testing.

backoff Retry backoff pattern(Default is retransmits

with constant delay)

exit Exit from RADIUS server configuration mode

key Per-server encryption key

no Negate a command or set its defaults

non-standard Attributes to be parsed that violate RADIUS

standard

pac Protected Access Credential key

retransmit Number of retries to active server (overrides

default)

timeout Time to wait (in seconds) for this radius server

to reply (overrides default)

Con la anterior instrucción simplemente le hemos dado el nombre. Ahora especificamos el resto de

parámetros:

SW_CISCO_PRUEBAS(config-radius-server)#address ipv4 10.165.60.6

auth-port 1812 acct-port 1813

Y aún nos falta por incluir la shared secret

SW_CISCO_PRUEBAS(config-radius-server)#key testing123

Para ir al menú anterior tenemos que teclear exit, ahora para configurar la autenticación de la administración

del switch a través de RADIUS tenemos que ejecutar los siguientes comandos:

Cisco(config)# aaa authentication login default group radius local

Cisco(config)#line vty 0 15

Cisco(config-line)#login authentication radius_jose

Con la primera línea habilitamos que se pueda usar el servidor RADIUS para autenticar los usuarios y al final

ponemos local para que si el servidor RADIUS no está disponible podamos acceder al switch usando un

usuario local. Las line vty del 0 al 15 son las interfaces virtuales que posee el switch para las conexiones

remotas. Con esto le estamos diciendo que en estas conexiones autentique el usuario con el servidor RADIUS.

9.2.2 802.1X

Y para hacer que el switch autentique los usuarios que se conectan por 802.1X tenemos que hacer lo siguiente

SW_CISCO_PRUEBAS(config)#aaa authentication dot1x default group radius

SW_CISCO_PRUEBAS(config)#dot1x system-auth-control

SW_CISCO_PRUEBAS(config)#interface fastEthernet 0/1

SW_CISCO_PRUEBAS(config-if)#dot1x port-control auto

SW_CISCO_PRUEBAS(config-if)#end


54

Con estos comandos especificamos que la autenticación 802.1X se lleve a cabo a través del servidor RADIUS,

lo habilitamos en el switch, y especificamos qué interfaces estarán en este modo (por supuesto se pueden poner

todas) y por último aplicamos el modo de funcionamiento, en este caso modo auto.

9.2 Configuración controladora inalámbrica

Para la controladora inalámbrica sí tenemos una interfaz de gestión gráfica vía web que hace la configuración

más sencilla.

Lo primero que hacemos es crear la red inalámbrica:

Figura 9-1. Configuración wlan

Posteriormente añadimos el servidor RADIUS:

Figura 9-2. Configuración servidor RADIUS

A continuación editamos las propiedades de seguridad de la red que hemos creado, primero en la pestaña

Layer2:


Figura 9-3. Configuración seguridad

Y posteriormente elegimos el servidor RADIUS creado en la pestaña AAA Servers:

Figura 9-4. Configuración servidor AAA

Por último en la pestaña general también le tenemos que especificar la interfaz, que ya la teníamos

previamente creada e incluye la configuración de red y DHCP:

Figura 9-5. Configuración general

Habilitamos el broadcast SSID para que los usuarios puedan ver la red.


56

9.3 Configuración clientes 802.1X

Para que un equipo que se conecta a la red pueda negociar la autenticación 802.1X con el switch es necesario

que disponga de un cliente 802.1X instalado. Por suerte para nosotros, los sistemas operativos actuales lo

tienen implementado por defecto y tan solo tenemos que configurarlo, dentro de las propiedades de la tarjeta

de red correspondiente:

Figura 9-6. Configuración 802.1X

Ahí vemos que se usa el protocol EAP Protegido. Si pulsamos en “Configuración”

Figura 9-7. Configuración 802.1X


Podemos ver las distintas opciones que tenemos. También desmarcamos la casilla “Validar un certificado del

servidor” ya que no es necesaria en nuestro caso. Y comprobamos que la autenticación que se usa es EAP-

MSCHAP v2.

De esta forma, cuando el pc se conecte al switch éste iniciará el proceso de negociación y el equipo le

solicitará las credenciales al usuario o le enviará las usadas en el inicio de sesión.

9.4 Configuración conexión inalámbrica

El SES dispone de ordenadores portátiles y dispositivos móviles que se pueden conectar a la red de forma

inalámbrica. Los tipos de dispositivos de los que dispone son ordenadores con sistema operativo Windows en

las versiones 7, 8 y 10 de dicho sistema y dispositivos móviles con sistema operativo Android e iOS, en

diferentes versiones.

Para configurar un cliente para acceso inalámbrico simplemente elegimos la red que hemos creado:

Figura 9-8. Configuración inalámbrica

Y una vez que le damos a conectar nos pedirá usuario y contraseña:


58

Figura 9-9. Configuración inalámbrica II

Si el cliente no tiene instalado el certificado SSL del servidor es possible que nos salga un aviso de seguridad

puesto que el certificado que estamos usando es autofirmado, no está firmado por una entidad certificadora de

confianza.

Figura 9-10. Configuración inalámbrica III


9.5 Comprobación acceso administración switches

9.5.1 3Com

Cuando nos conectamos al switch por telnet, éste nos pide usuario y contraseña:

Login: usuario3com

Password:

En el caso de los switches 3com es necesario añadir manualmente los usuarios que se tengan que autenticar al

fichero users del servidor RADIUS, puesto que es requisito necesario en estos switches que el RADIUS

indique en su respuesta Access-Accept el nivel de acceso, que se especifica con el atributo de fabricante

3Com-User-Access-Level, como ya vimos anteriormente.

Así, al servidor le llega la siguiente petición:

(1) Received Access-Request Id 10 from 10.165.18.27:2048 to

10.165.60.6:1812 length 108

(1) User-Name = "usuario3com"

(1) User-Password = "1234"

(1) NAS-Port-Type = Virtual

(1) NAS-IP-Address = 10.165.18.27

(1) Service-Type = Administrative-User

(1) Framed-MTU = 1024

(1) Calling-Station-Id = "10.165.18.175"

(1) Message-Authenticator = 0x0139272f18f9a3e8cf0aa8e714848fe7

Y ésta es su respuesta:

(1) pap: User authenticated successfully

(1) [pap] = ok

(1) } # Auth-Type PAP = ok

(1) Sent Access-Accept Id 10 from 10.165.60.6:1812 to 10.165.18.27:2048

length 0

(1) 3Com-User-Access-Level = 3Com-Administrator

(1) Finished request

Donde comprobamos que además de enviar el Acces-Accept le envía también el 3Com-User-Access-Level

requerido por el switch.

9.5.2 Cisco

Al intentar conectarnos al switch, éste nos pide usuario y contraseña:

User Access Verification

Username: radius1

Password:


60

Y se la envía al servidor RADIUS, por lo que en el servidor vemos lo siguiente:


10.165.60.6:1812 length 80

(0) NAS-IP-Address = 10.165.18.27

(0) NAS-Port = 1

(0) NAS-Port-Type = Virtual

(0) User-Name = "radius1"

(0) Calling-Station-Id = "10.165.18.175"

(0) User-Password = "radius123"

En este caso vemos cómo encuentra al usuario en el fichero users:

(0) files: users: Matched entry radius1 at line 87

(0) [files] = ok

(0) [pap] = updated

(0) } # authorize = updated

(0) Found Auth-Type = PAP

(0) # Executing group from file /usr/local/etc/raddb/sites-

enabled/default

(0) Auth-Type PAP {

(0) pap: Login attempt with password

(0) pap: Comparing with "known good" Cleartext-Password

(0) pap: User authenticated successfully

(0) [pap] = ok

(0) } # Auth-Type PAP = ok


length 0

(0) Service-Type = Framed-User


Y así ya hemos iniciado sesión en el switch.

9.6 Comprobación autenticación 802.1X

9.6.1 3Com

Cuando conectamos un equipo a un puerto configurado con autenticación de red 802.1X, el switch le pide la

identificación al usuario y en el sevidor RADIUS vemos lo siguiente:


10.165.60.6:1812 length 110



(2) NAS-Port = 101

(2) NAS-Port-Type = Ethernet

(2) NAS-IP-Address = 10.165.18.27



(2) Calling-Station-Id = "70-5A-B6-95-BC-0B"

(2) EAP-Message = 0x0200000c0172616469757331

(2) Message-Authenticator = 0xa440d9d1ecca94da511dfbbaab99d3d8

Y su respuesta:


length 0

(12) MS-MPPE-Recv-Key =

0x4f84853b538cf72ec007a16810c33408281008e0c93779cc93fe3c08e05b5664

(12) MS-MPPE-Send-Key =

0xa14855b2218e088fac0b5ba86095908c8ab5b186416bbe630e17084da23a5e07

(12) EAP-Message = 0x030a0004

(12) Message-Authenticator = 0x00000000000000000000000000000000



Como en este switch también se ha configurado el accounting (registro), vemos también la solicitud de

accounting que realiza el switch al servidor:

(14) Received Accounting-Request Id 22 from 10.165.18.27:2048 to

10.165.60.6:1813 length 90

(14) NAS-IP-Address = 10.165.18.27

(14) NAS-Port = 101

(14) Acct-Status-Type = Start

(14) Acct-Session-Id = "1.0.30d136"





(14) Not sending reply to client.


Esta petición no llega al cliente conectado puesto que es algo que se establece sólamente entre el switch y el

servidor RADIUS. Y la respuesta a esta petición de accounting es:

(12) } # accounting = ok

(12) Sent Accounting-Response Id 38 from 10.165.60.6:1813 to

10.165.18.27:2048 length 0


Confirmando al switch que el registro se ha llevado a cabo.


62

9.6.2 Cisco

Una vez que tenemos configurado la autenticación en el switch cuando conectamos un equipo, el switch envía

el Access-Request al servidor RADIUS y éste le responde con el Access-Accept si es un usuario válido.


10.165.60.6:1812 length 129




(24) Called-Station-Id = "00-24-50-F1-E5-82"


(24) EAP-Message = 0x0202000c0172616469757331

(24) Message-Authenticator = 0xc2c217623e038528f080217933a170b1


(24) NAS-Port = 50001

(24) NAS-IP-Address = 10.165.18.27

Y también vemos la respuesta del servidor, en este caso aceptada:


length 0


0x4e2d455b9903ce7fe9e656ffb469082f3edade252ac1343e58d6512d9eff2ec5


0x7aa0e82447f455a3ea180df185481c6a2d5ec2b52ff427cdf3e1aa308a0ee299

(34) EAP-Message = 0x030c0004



9.7 Comprobación acceso inalámbrico

Cuando un cliente se intenta conectar a la red inalámbrica, la controladora le envía la petición de acceso al

RADIUS:


10.165.60.6:1812 length 181


(6) Calling-Station-Id = "10-b1-f8-af-15-08"

(6) Called-Station-Id = "00-24-14-e8-a8-40:wlan-802"

(6) NAS-Port = 29


(6) NAS-IP-Address = 10.165.18.216

(6) NAS-Identifier = "Controller-4"

(6) Airespace-Wlan-Id = 2



(6) NAS-Port-Type = Wireless-802.11

(6) Tunnel-Type:0 = VLAN

(6) Tunnel-Medium-Type:0 = IEEE-802

(6) Tunnel-Private-Group-Id:0 = "101"

(6) EAP-Message = 0x0201000c0172616469757331

(6) Message-Authenticator = 0xa6d5412ea0743ab4c10c51581e5047e8

RADIUS responde iniciando el “challenge” para iniciar el proceso de autenticación:

(7) Sent Access-Challenge Id 249 from 10.165.60.6:1812 to

10.165.18.216:32768 length 0


(7) EAP-Message = 0x010300061920


(7) State = 0xd5576227d4547b4071e54e5924bc02a3

Entonces la controladora hace la petición de usuario y contraseña al cliente final y vuelve a mandar un access-

request al RADIUS:


10.165.60.6:1812 length 362


(8) Calling-Station-Id = "10-b1-f8-af-15-08"

(8) Called-Station-Id = "00-24-14-e8-a8-40:wlan-802"

(8) NAS-Port = 29

(8) NAS-IP-Address = 10.165.18.216

(8) NAS-Identifier = "Controller-4"

(8) Airespace-Wlan-Id = 2



(8) NAS-Port-Type = Wireless-802.11

(8) Tunnel-Type:0 = VLAN

(8) Tunnel-Medium-Type:0 = IEEE-802

(8) Tunnel-Private-Group-Id:0 = "101"

(8) EAP-Message =

0x020300af1980000000a516030100a00100009c0303ae86225477b9cf0963f17dbb23114

e9aaa50ee13659dcae08b2ff8b0c9a861a000003ec02cc030009fc02bc02f009ecca9cca8


64

c00ac024c014c0280039006bc009c023c013c02700330067c007c011009d009c0035003d0

02f003c00050004000a01

(8) State = 0xd5576227d4547b4071e54e5924bc02a3

(8) Message-Authenticator = 0x42f8762a0977157ea331f3eb1c8f445a

Ahora continúa el traspaso de mensajes necesario para el establecimiento que no incluyo por su longitud, y al

final del proceso el RADIUS envía el Access-Accept a la controladora y ésta ya puede ofrecer la conexión al

usuario:


length 0


0x4d850ea9a648ced559b2b91592a5ac642e8ffc601cc616d289deb8144d928f39


0x30726a6b4b8660bcc879e6abef269a2b17dfed541e0fb392e2f42f836e63318b

(16) EAP-Message = 0x030b0004



67

BIBLIOGRAFÍA

Para la elaboración de este proyecto se han utilizado tanto libros como búsqueda de información online.

Libros:

Implementation Guide Switch 4400. 3Com

Radius for Unix Administrators. Lucent Technologies.

Radius Administrator's Guide. Livingston Enterprises.

Radius. Jonathan Hassell. O'Reilly.

Radius Protocol Security and best practices. Microsoft.

Y las fuentes de infromación online han sido:

http://www.freeradius.org

http://web.mit.edu/kerberos

http://www.kerberos.org

http://www.cisco.com

http://www.microsoft.com

http://www.ietf.org

http://www.open1x.org

http://www.linuxjournal.com

http://sourceforge.net

http://www.openssl.org

http://www.freeradius.org/


http://www.cisco.com/


http://www.microsoft.com/


http://www.ietf.org/


http://www.open1x.org/

http://sourceforge.net/docman/display_doc.php?docid=23371&group_id=60236

http://www.openssl.org/

68

ANEXO. FICHEROS DE CONFIGURACIÓN

A.1 Freeradius

En esta sección mostraremos los archivos de configuración completos del software Freeradius. Los ficheros

están ubicados en la ruta /usr/local/etc/raddb

A.1.1 clients.conf

# -*- text -*-

##

## clients.conf -- client configuration directives

##

## $Id: 76b300d3c55f1c5c052289b76bf28ac3a370bbb2 $

#######################################################################

#

# Define RADIUS clients (usually a NAS, Access Point, etc.).

#

# Defines a RADIUS client.

#

# '127.0.0.1' is another name for 'localhost'. It is enabled by default,

# to allow testing of the server after an initial installation. If you

# are not going to be permitting RADIUS queries from localhost, we suggest

# that you delete, or comment out, this entry.

#

#

#

# Each client has a "short name" that is used to distinguish it from

# other clients.

#

# In version 1.x, the string after the word "client" was the IP

# address of the client. In 2.0, the IP address is configured via

# the "ipaddr" or "ipv6addr" fields. For compatibility, the 1.x

# format is still accepted.

#

client localhost {


# Only *one* of ipaddr, ipv4addr, ipv6addr may be specified for

# a client.

#

# ipaddr will accept IPv4 or IPv6 addresses with optional CIDR

# notation '/<mask>' to specify ranges.

#

# ipaddr will accept domain names e.g. example.org resolving

# them via DNS.

#

# If both A and AAAA records are found, A records will be

# used in preference to AAAA.

ipaddr = 127.0.0.1

# Same as ipaddr but allows v4 addresses only. Requires A

# record for domain names.

# ipv4addr = * # any. 127.0.0.1 == localhost

# Same as ipaddr but allows v6 addresses only. Requires AAAA

# record for domain names.

# ipv6addr = :: # any. ::1 == localhost

#

# A note on DNS: We STRONGLY recommend using IP addresses

# rather than host names. Using host names means that the

# server will do DNS lookups when it starts, making it

# dependent on DNS. i.e. If anything goes wrong with DNS,

# the server won't start!

#

# The server also looks up the IP address from DNS once, and

# only once, when it starts. If the DNS record is later

# updated, the server WILL NOT see that update.

#

#

# The transport protocol.

#

# If unspecified, defaults to "udp", which is the traditional

# RADIUS transport. It may also be "tcp", in which case the

# server will accept connections from this client ONLY over TCP.

#

proto = *

#

# The shared secret use to "encrypt" and "sign" packets between

Anexo. Ficheros de configuración

70

# the NAS and FreeRADIUS. You MUST change this secret from the

# default, otherwise it's not a secret any more!

#

# The secret can be any string, up to 8k characters in length.

#

# Control codes can be entered vi octal encoding,

# e.g. "\101\102" == "AB"

# Quotation marks can be entered by escaping them,

# e.g. "foo\"bar"

#

# A note on security: The security of the RADIUS protocol

# depends COMPLETELY on this secret! We recommend using a

# shared secret that is composed of:

#

# upper case letters

# lower case letters

# numbers

#

# And is at LEAST 8 characters long, preferably 16 characters in

# length. The secret MUST be random, and should not be words,

# phrase, or anything else that is recognisable.

#

# The default secret below is only for testing, and should

# not be used in any real environment.

#

secret = testing123

#

# Old-style clients do not send a Message-Authenticator

# in an Access-Request. RFC 5080 suggests that all clients

# SHOULD include it in an Access-Request. The configuration

# item below allows the server to require it. If a client

# is required to include a Message-Authenticator and it does

# not, then the packet will be silently discarded.

#

# allowed values: yes, no

require_message_authenticator = no

#

# The short name is used as an alias for the fully qualified

# domain name, or the IP address.

#

# It is accepted for compatibility with 1.x, but it is no


# longer necessary in >= 2.0

#

# shortname = localhost

#

# the following three fields are optional, but may be used by

# checkrad.pl for simultaneous use checks

#

#

# The nas_type tells 'checkrad.pl' which NAS-specific method to

# use to query the NAS for simultaneous use.

#

# Permitted NAS types are:

#

# cisco

# computone

# livingston

# juniper

# max40xx

# multitech

# netserver

# pathras

# patton

# portslave

# tc

# usrhiper

# other # for all other types

#

nas_type = other # localhost isn't usually a NAS...

#

# The following two configurations are for future use.

# The 'naspasswd' file is currently used to store the NAS

# login name and password, which is used by checkrad.pl

# when querying the NAS for simultaneous use.

#

# login = !root

# password = someadminpas

#

# As of 2.0, clients can also be tied to a virtual server.

# This is done by setting the "virtual_server" configuration


72

# item, as in the example below.

#

# virtual_server = home1

#

# A pointer to the "home_server_pool" OR a "home_server"

# section that contains the CoA configuration for this

# client. For an example of a coa home server or pool,

# see raddb/sites-available/originate-coa

# coa_server = coa

#

# Response window for proxied packets. If non-zero,

# then the lower of (home, client) response_window

# will be used.

#

# i.e. it can be used to lower the response_window

# packets from one client to a home server. It cannot

# be used to raise the response_window.

#

# response_window = 10.0

#

# Connection limiting for clients using "proto = tcp".

#

# This section is ignored for clients sending UDP traffic

#

limit {

#

# Limit the number of simultaneous TCP connections from a client

#

# The default is 16.

# Setting this to 0 means "no limit"

max_connections = 16

# The per-socket "max_requests" option does not exist.

#

# The lifetime, in seconds, of a TCP connection. After

# this lifetime, the connection will be closed.

#

# Setting this to 0 means "forever".

lifetime = 0


#

# The idle timeout, in seconds, of a TCP connection.

# If no packets have been received over the connection for

# this time, the connection will be closed.

#

# Setting this to 0 means "no timeout".

#

# We STRONGLY RECOMMEND that you set an idle timeout.

#

idle_timeout = 30

}

}

# IPv6 Client

client localhost_ipv6 {

ipv6addr = ::1

secret = testing123

}

# All IPv6 Site-local clients

#client sitelocal_ipv6 {

# ipv6addr = fe80::/16

# secret = testing123

#}

# máquinas que se conectan al radius

# Mi PC

client pc_jose {

ipaddr = 10.165.18.175

secret = testing123

}

client sw_cisco {

ipaddr = 10.165.18.27

secret = testing123

}

client sw_3com {

ipaddr = 10.165.18.27

secret = testing123

}

client controladora_wifi {

ipaddr = 10.165.18.216


74

secret = testing123

}

#client example.org {

# ipaddr = radius.example.org


#}

#

# You can now specify one secret for a network of clients.

# When a client request comes in, the BEST match is chosen.

# i.e. The entry from the smallest possible network.

#

#client private-network-1 {

# ipaddr = 192.0.2.0/24

# secret = testing123-1

#}

#client private-network-2 {

# ipaddr = 198.51.100.0/24

# secret = testing123-2

#}

#######################################################################

#

# Per-socket client lists. The configuration entries are exactly

# the same as above, but they are nested inside of a section.

#

# You can have as many per-socket client lists as you have "listen"

# sections, or you can re-use a list among multiple "listen" sections.

#

# Un-comment this section, and edit a "listen" section to add:

# "clients = per_socket_clients". That IP address/port combination

# will then accept ONLY the clients listed in this section.

#

#clients per_socket_clients {

# client socket_client {

# ipaddr = 192.0.2.4


# }


#}

A.1.2 users

#

# Configuration file for the rlm_files module.

# Please see rlm_files(5) manpage for more information.

#

# This file contains authentication security and configuration

# information for each user. Accounting requests are NOT processed

# through this file. Instead, see 'accounting', in this directory.

#

# The first field is the user's name and can be up to

# 253 characters in length. This is followed (on the same line) with

# the list of authentication requirements for that user. This can

# include password, comm server name, comm server port number, protocol

# type (perhaps set by the "hints" file), and huntgroup name (set by

# the "huntgroups" file).

#

# If you are not sure why a particular reply is being sent by the

# server, then run the server in debugging mode (radiusd -X), and

# you will see which entries in this file are matched.

#

# When an authentication request is received from the comm server,

# these values are tested. Only the first match is used unless the

# "Fall-Through" variable is set to "Yes".

#

# A special user named "DEFAULT" matches on all usernames.

# You can have several DEFAULT entries. All entries are processed

# in the order they appear in this file. The first entry that

# matches the login-request will stop processing unless you use

# the Fall-Through variable.

#

# Indented (with the tab character) lines following the first

# line indicate the configuration values to be passed back to

# the comm server to allow the initiation of a user session.

# This can include things like the PPP configuration values

# or the host to log the user onto.

#

# You can include another `users' file with `$INCLUDE users.other'

#


76

# For a list of RADIUS attributes, and links to their definitions,

# see: http://www.freeradius.org/rfc/attributes.html

#

# Entries below this point are examples included in the server for

# educational purposes. They may be deleted from the deployed

# configuration without impacting the operation of the server.

#

#

# Deny access for a specific user. Note that this entry MUST

# be before any other 'Auth-Type' attribute which results in the user

# being authenticated.

#

# Note that there is NO 'Fall-Through' attribute, so the user will not

# be given any additional resources.

#

#lameuser Auth-Type := Reject

# Reply-Message = "Your account has been disabled."

#

# Deny access for a group of users.

#

# Note that there is NO 'Fall-Through' attribute, so the user will not

# be given any additional resources.

#

#DEFAULT Group == "disabled", Auth-Type := Reject

# Reply-Message = "Your account has been disabled."

#

#

# This is a complete entry for "steve". Note that there is no Fall-Through

# entry so that no DEFAULT entry will be used, and the user will NOT

# get any attributes in addition to the ones listed here.

#

#steve Cleartext-Password := "testing"

# Service-Type = Framed-User,

# Framed-Protocol = PPP,

# Framed-IP-Address = 172.16.3.33,

# Framed-IP-Netmask = 255.255.255.0,

# Framed-Routing = Broadcast-Listen,

# Framed-Filter-Id = "std.ppp",

# Framed-MTU = 1500,

# Framed-Compression = Van-Jacobsen-TCP-IP


# usuarios locales del servidor radius

radius1 Cleartext-Password := "radius123"


radius2 Cleartext-Password := "radius123"


# usuarios para los switches 3Com

usuario3com Cleartext-Password := "1234"

3Com-User-Access-Level = 3Com-Administrator

# usuarios para los dispositivos móviles

tablet1@n4 Auth-Type = Local, User-Password == "tablet1", Calling-Station-

Id=="34690040219"




Ascend-Client-Primary-DNS = 192.168.100.1,




tablet2@n4 Auth-Type = Local, User-Password == "tablet2", Calling-Station-

Id=="34690040233"




Ascend-Client-Primary-DNS = 192.168.100.1,




#

# The canonical testing user which is in most of the

# examples.

#

#bob Cleartext-Password := "hello"

# Reply-Message := "Hello, %{User-Name}"

#

#

# This is an entry for a user with a space in their name.

# Note the double quotes surrounding the name. If you have

# users with spaces in their names, you must also change

# the "filter_username" policy to allow spaces.

#

# See raddb/policy.d/filter, filter_username {} section.

#

#"John Doe" Cleartext-Password := "hello"

# Reply-Message = "Hello, %{User-Name}"


78

#

# Dial user back and telnet to the default host for that port

#

#Deg Cleartext-Password := "ge55ged"

# Service-Type = Callback-Login-User,

# Login-IP-Host = 0.0.0.0,

# Callback-Number = "9,5551212",

# Login-Service = Telnet,

# Login-TCP-Port = Telnet

#

# Another complete entry. After the user "dialbk" has logged in, the

# connection will be broken and the user will be dialed back after which

# he will get a connection to the host "timeshare1".

#

#dialbk Cleartext-Password := "callme"

# Service-Type = Callback-Login-User,

# Login-IP-Host = timeshare1,

# Login-Service = PortMaster,

# Callback-Number = "9,1-800-555-1212"

#

# user "swilson" will only get a static IP number if he logs in with

# a framed protocol on a terminal server in Alphen (see the huntgroups file).

#

# Note that by setting "Fall-Through", other attributes will be added from

# the following DEFAULT entries

#

#swilson Service-Type == Framed-User, Huntgroup-Name == "alphen"


# Fall-Through = Yes

#

# If the user logs in as 'username.shell', then authenticate them

# using the default method, give them shell access, and stop processing

# the rest of the file.

#

#DEFAULT Suffix == ".shell"

# Service-Type = Login-User,

# Login-Service = Telnet,

# Login-IP-Host = your.shell.machine


#

# The rest of this file contains the several DEFAULT entries.

# DEFAULT entries match with all login names.

# Note that DEFAULT entries can also Fall-Through (see first entry).

# A name-value pair from a DEFAULT entry will _NEVER_ override

# an already existing name-value pair.

#

#

# Set up different IP address pools for the terminal servers.

# Note that the "+" behind the IP address means that this is the "base"

# IP address. The Port-Id (S0, S1 etc) will be added to it.

#

#DEFAULT Service-Type == Framed-User, Huntgroup-Name == "alphen"

# Framed-IP-Address = 192.0.2.32+,


#DEFAULT Service-Type == Framed-User, Huntgroup-Name == "delft"

# Framed-IP-Address = 198.51.100.32+,


#

# Sample defaults for all framed connections.

#

#DEFAULT Service-Type == Framed-User


# Framed-MTU = 576,

# Service-Type = Framed-User,


#

# Default for PPP: dynamic IP address, PPP mode, VJ-compression.

# NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected

# by the terminal server in which case there may not be a "P" suffix.

# The terminal server sends "Framed-Protocol = PPP" for auto PPP.

#

DEFAULT Framed-Protocol == PPP


Framed-Compression = Van-Jacobson-TCP-IP

#

# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.

#

DEFAULT Hint == "CSLIP"


80

Framed-Protocol = SLIP,

Framed-Compression = Van-Jacobson-TCP-IP

#

# Default for SLIP: dynamic IP address, SLIP mode.

#

DEFAULT Hint == "SLIP"

Framed-Protocol = SLIP

#

# Last default: rlogin to our main server.

#

#DEFAULT

# Service-Type = Login-User,

# Login-Service = Rlogin,

# Login-IP-Host = shellbox.ispdomain.com

# #

# # Last default: shell on the local terminal server.

# #

# DEFAULT

# Service-Type = Administrative-User

#por último hacemos que el resto de usuarios se autentiquen en Kerberos

DEFAULT AUTH-Type = kerberos

# On no match, the user is denied access.

DEFAULT AUTH-Type = reject

#########################################################

# You should add test accounts to the TOP of this file! #

# See the example user "bob" above. #

#########################################################

A.1.3 ./mods-enabled/eap

# -*- text -*-

##

## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)


##

## $Id: f67cbdbff9b6560cec9f68da1adb82b59723d2ef $

#######################################################################

#

# Whatever you do, do NOT set 'Auth-Type := EAP'. The server

# is smart enough to figure this out on its own. The most

# common side effect of setting 'Auth-Type := EAP' is that the

# users then cannot use ANY other authentication method.

#

eap {

# Invoke the default supported EAP type when

# EAP-Identity response is received.

#

# The incoming EAP messages DO NOT specify which EAP

# type they will be using, so it MUST be set here.

#

# For now, only one default EAP type may be used at a time.

#

# If the EAP-Type attribute is set by another module,

# then that EAP type takes precedence over the

# default type configured here.

default_eap_type = peap

# A list is maintained to correlate EAP-Response

# packets with EAP-Request packets. After a

# configurable length of time, entries in the list

# expire, and are deleted.

#

timer_expire = 60

# There are many EAP types, but the server has support

# for only a limited subset. If the server receives

# a request for an EAP type it does not support, then

# it normally rejects the request. By setting this

# configuration to "yes", you can tell the server to

# instead keep processing the request. Another module

# MUST then be configured to proxy the request to

# another RADIUS server which supports that EAP type.

#

# If another module is NOT configured to handle the

# request, then the request will still end up being

# rejected.


82

ignore_unknown_eap_types = no

# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given

# a User-Name attribute in an Access-Accept, it copies one

# more byte than it should.

#

# We can work around it by configurably adding an extra

# zero byte.

cisco_accounting_username_bug = no

#

# Help prevent DoS attacks by limiting the number of

# sessions that the server is tracking. For simplicity,

# this is taken from the "max_requests" directive in

# radiusd.conf.

max_sessions = ${max_requests}

# Supported EAP-types

#

# We do NOT recommend using EAP-MD5 authentication

# for wireless connections. It is insecure, and does

# not provide for dynamic WEP keys.

#

md5 {

}

#

# EAP-pwd -- secure password-based authentication

#

# pwd {

# group = 19

#

# server_id = [email protected]

# This has the same meaning as for TLS.

# fragment_size = 1020

# The virtual server which determines the

# "known good" password for the user.

# Note that unlike TLS, only the "authorize"

# section is processed. EAP-PWD requests can be


# distinguished by having a User-Name, but

# no User-Password, CHAP-Password, EAP-Message, etc.

# virtual_server = "inner-tunnel"

# }

# Cisco LEAP

#

# We do not recommend using LEAP in new deployments. See:

# http://www.securiteam.com/tools/5TP012ACKE.html

#

# Cisco LEAP uses the MS-CHAP algorithm (but not

# the MS-CHAP attributes) to perform it's authentication.

#

# As a result, LEAP *requires* access to the plain-text

# User-Password, or the NT-Password attributes.

# 'System' authentication is impossible with LEAP.

#

leap {

}

# Generic Token Card.

#

# Currently, this is only permitted inside of EAP-TTLS,

# or EAP-PEAP. The module "challenges" the user with

# text, and the response from the user is taken to be

# the User-Password.

#

# Proxying the tunneled EAP-GTC session is a bad idea,

# the users password will go over the wire in plain-text,

# for anyone to see.

#

gtc {

# The default challenge, which many clients

# ignore..

#challenge = "Password: "

# The plain-text response which comes back

# is put into a User-Password attribute,

# and passed to another module for

# authentication. This allows the EAP-GTC

# response to be checked against plain-text,

# or crypt'd passwords.

#

# If you say "Local" instead of "PAP", then


84

# the module will look for a User-Password

# configured for the request, and do the

# authentication itself.

#

auth_type = PAP

}

## Common TLS configuration for TLS-based EAP types

#

# See raddb/certs/README for additional comments

# on certificates.

#

# If OpenSSL was not found at the time the server was

# built, the "tls", "ttls", and "peap" sections will

# be ignored.

#

# If you do not currently have certificates signed by

# a trusted CA you may use the 'snakeoil' certificates.

# Included with the server in raddb/certs.

#

# If these certificates have not been auto-generated:

# cd raddb/certs

# make

#

# These test certificates SHOULD NOT be used in a normal

# deployment. They are created only to make it easier

# to install the server, and to perform some simple

# tests with EAP-TLS, TTLS, or PEAP.

#

# See also:

#

# http://www.dslreports.com/forum/remark,9286052~mode=flat

#

# Note that you should NOT use a globally known CA here!

# e.g. using a Verisign cert as a "known CA" means that

# ANYONE who has a certificate signed by them can

# authenticate via EAP-TLS! This is likely not what you want.

tls-config tls-common {

private_key_password = whatever

private_key_file = ${certdir}/server.pem

# If Private key & Certificate are located in

# the same file, then private_key_file &


# certificate_file must contain the same file

# name.

#

# If ca_file (below) is not used, then the

# certificate_file below MUST include not

# only the server certificate, but ALSO all

# of the CA certificates used to sign the

# server certificate.

certificate_file = ${certdir}/server.pem

# Trusted Root CA list

#

# ALL of the CA's in this list will be trusted

# to issue client certificates for authentication.

#

# In general, you should use self-signed

# certificates for 802.1x (EAP) authentication.

# In that case, this CA file should contain

# *one* CA certificate.

#

ca_file = ${cadir}/ca.pem

# OpenSSL will automatically create certificate chains,

# unless we tell it to not do that. The problem is that

# it sometimes gets the chains right from a certificate

# signature view, but wrong from the clients view.

#

# When setting "auto_chain = no", the server certificate

# file MUST include the full certificate chain.

# auto_chain = yes

#

# If OpenSSL supports TLS-PSK, then we can use

# a PSK identity and (hex) password. When the

# following two configuration items are specified,

# then certificate-based configuration items are

# not allowed. e.g.:

#

# private_key_password

# private_key_file

# certificate_file

# ca_file

# ca_path

#


86

# For now, the identity is fixed, and must be the

# same on the client. The passphrase must be a hex

# value, and can be up to 256 hex digits.

#

# Future versions of the server may be able to

# look up the shared key (hexphrase) based on the

# identity.

#

# psk_identity = "test"

# psk_hexphrase = "036363823"

#

# For DH cipher suites to work, you have to

# run OpenSSL to create the DH file first:

#

# openssl dhparam -out certs/dh 2048

#

dh_file = ${certdir}/dh

#

# If your system doesn't have /dev/urandom,

# you will need to create this file, and

# periodically change its contents.

#

# For security reasons, FreeRADIUS doesn't

# write to files in its configuration

# directory.

#

# random_file = /dev/urandom

#

# This can never exceed the size of a RADIUS

# packet (4096 bytes), and is preferably half

# that, to accommodate other attributes in

# RADIUS packet. On most APs the MAX packet

# length is configured between 1500 - 1600

# In these cases, fragment size should be

# 1024 or less.

#

# fragment_size = 1024

# include_length is a flag which is

# by default set to yes If set to


# yes, Total Length of the message is

# included in EVERY packet we send.

# If set to no, Total Length of the

# message is included ONLY in the

# First packet of a fragment series.

#

# include_length = yes

# Check the Certificate Revocation List

#

# 1) Copy CA certificates and CRLs to same directory.

# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.

# 'c_rehash' is OpenSSL's command.

# 3) uncomment the lines below.

# 5) Restart radiusd

# check_crl = yes

# Check if intermediate CAs have been revoked.

# check_all_crl = yes

ca_path = ${cadir}

# Accept an expired Certificate Revocation List

#

# allow_expired_crl = no

#

# If check_cert_issuer is set, the value will

# be checked against the DN of the issuer in

# the client certificate. If the values do not

# match, the certificate verification will fail,

# rejecting the user.

#

# This check can be done more generally by checking

# the value of the TLS-Client-Cert-Issuer attribute.

# This check can be done via any mechanism you

# choose.

#

# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"

#

# If check_cert_cn is set, the value will

# be xlat'ed and checked against the CN


88

# in the client certificate. If the values

# do not match, the certificate verification

# will fail rejecting the user.

#

# This check is done only if the previous

# "check_cert_issuer" is not set, or if

# the check succeeds.

#

# In 2.1.10 and later, this check can be done

# more generally by checking the value of the

# TLS-Client-Cert-CN attribute. This check

# can be done via any mechanism you choose.

#

# check_cert_cn = %{User-Name}

#

# Set this option to specify the allowed

# TLS cipher suites. The format is listed

# in "man 1 ciphers".

#

# For EAP-FAST, use "ALL:!EXPORT:!eNULL:!SSLv2"

#

cipher_list = "DEFAULT"

# If enabled, OpenSSL will use server cipher list

# (possibly defined by cipher_list option above)

# for choosing right cipher suite rather than

# using client-specified list which is OpenSSl default

# behavior. Having it set to yes is a current best practice

# for TLS

cipher_server_preference = no

#

# You can selectively disable TLS versions for

# compatability with old client devices.

#

# If your system has OpenSSL 1.1.0 or greater, do NOT

# use these. Instead, set tls_min_version and

# tls_max_version.

#

# disable_tlsv1_2 = no

# disable_tlsv1_1 = no

# disable_tlsv1 = no


#

# Set min / max TLS version. Mainly for Debian

# "trusty", which disables older versions of TLS, and

# requires the application to manually enable them.

#

# If you are running Debian trusty, you should set

# these options, otherwise older clients will not be

# able to connect.

#

# Allowed values are "1.0", "1.1", and "1.2".

#

# The values must be in quotes.

#

# tls_min_version = "1.0"

# tls_max_version = "1.2"

#

# Elliptical cryptography configuration

#

# Only for OpenSSL >= 0.9.8.f

#

ecdh_curve = "prime256v1"

#

# Session resumption / fast reauthentication

# cache.

#

# The cache contains the following information:

#

# session Id - unique identifier, managed by SSL

# User-Name - from the Access-Accept

# Stripped-User-Name - from the Access-Request

# Cached-Session-Policy - from the Access-Accept

#

# The "Cached-Session-Policy" is the name of a

# policy which should be applied to the cached

# session. This policy can be used to assign

# VLANs, IP addresses, etc. It serves as a useful

# way to re-apply the policy from the original

# Access-Accept to the subsequent Access-Accept

# for the cached session.

#

# On session resumption, these attributes are


90

# copied from the cache, and placed into the

# reply list.

#

# You probably also want "use_tunneled_reply = yes"

# when using fast session resumption.

#

cache {

#

# Enable it. The default is "no". Deleting the entire "cache"

# subsection also disables caching.

#

# As of version 3.0.14, the session cache requires the use

# of the "name" and "persist_dir" configuration items, below.

#

# The internal OpenSSL session cache has been permanently

# disabled.

#

# You can disallow resumption for a particular user by adding

the

# following attribute to the control item list:

#

# Allow-Session-Resumption = No

#

# If "enable = no" below, you CANNOT enable resumption for just

one

# user by setting the above attribute to "yes".

#

enable = no

#

# Lifetime of the cached entries, in hours. The sessions will be

# deleted/invalidated after this time.

#

lifetime = 24 # hours

#

# Internal "name" of the session cache. Used to

# distinguish which TLS context sessions belong to.

#

# The server will generate a random value if unset.

# This will change across server restart so you MUST

# set the "name" if you want to persist sessions (see

# below).

#


#name = "EAP module"

#

# Simple directory-based storage of sessions.

# Two files per session will be written, the SSL

# state and the cached VPs. This will persist session

# across server restarts.

#

# The default directory is ${logdir}, for historical

# reasons. You should ${db_dir} instead. And check

# the value of db_dir in the main radiusd.conf file.

# It should not point to ${raddb}

#

# The server will need write perms, and the directory

# should be secured from anyone else. You might want

# a script to remove old files from here periodically:

#

# find ${logdir}/tlscache -mtime +2 -exec rm -f {} \;

#

# This feature REQUIRES "name" option be set above.

#

#persist_dir = "${logdir}/tlscache"

}

#

# As of version 2.1.10, client certificates can be

# validated via an external command. This allows

# dynamic CRLs or OCSP to be used.

#

# This configuration is commented out in the

# default configuration. Uncomment it, and configure

# the correct paths below to enable it.

#

# If OCSP checking is enabled, and the OCSP checks fail,

# the verify section is not run.

#

# If OCSP checking is disabled, the verify section is

# run on successful certificate validation.

#

verify {

# If the OCSP checks succeed, the verify section

# is run to allow additional checks.

#

# If you want to skip verify on OCSP success,


92

# uncomment this configuration item, and set it

# to "yes".

# skip_if_ocsp_ok = no

# A temporary directory where the client

# certificates are stored. This directory

# MUST be owned by the UID of the server,

# and MUST not be accessible by any other

# users. When the server starts, it will do

# "chmod go-rwx" on the directory, for

# security reasons. The directory MUST

# exist when the server starts.

#

# You should also delete all of the files

# in the directory when the server starts.

# tmpdir = /tmp/radiusd

# The command used to verify the client cert.

# We recommend using the OpenSSL command-line

# tool.

#

# The ${..ca_path} text is a reference to

# the ca_path variable defined above.

#

# The %{TLS-Client-Cert-Filename} is the name

# of the temporary file containing the cert

# in PEM format. This file is automatically

# deleted by the server when the command

# returns.

# client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-

Client-Cert-Filename}"

}

#

# OCSP Configuration

# Certificates can be verified against an OCSP

# Responder. This makes it possible to immediately

# revoke certificates without the distribution of

# new Certificate Revocation Lists (CRLs).

#

ocsp {

#

# Enable it. The default is "no".

# Deleting the entire "ocsp" subsection


# also disables ocsp checking

#

enable = no

#

# The OCSP Responder URL can be automatically

# extracted from the certificate in question.

# To override the OCSP Responder URL set

# "override_cert_url = yes".

#

override_cert_url = yes

#

# If the OCSP Responder address is not extracted from

# the certificate, the URL can be defined here.

#

url = "http://127.0.0.1/ocsp/"

#

# If the OCSP Responder can not cope with nonce

# in the request, then it can be disabled here.

#

# For security reasons, disabling this option

# is not recommended as nonce protects against

# replay attacks.

#

# Note that Microsoft AD Certificate Services OCSP

# Responder does not enable nonce by default. It is

# more secure to enable nonce on the responder than

# to disable it in the query here.

# See http://technet.microsoft.com/en-

us/library/cc770413%28WS.10%29.aspx

#

# use_nonce = yes

#

# Number of seconds before giving up waiting

# for OCSP response. 0 uses system default.

#

# timeout = 0

#

# Normally an error in querying the OCSP

# responder (no response from server, server did


94

# not understand the request, etc) will result in

# a validation failure.

#

# To treat these errors as 'soft' failures and

# still accept the certificate, enable this

# option.

#

# Warning: this may enable clients with revoked

# certificates to connect if the OCSP responder

# is not available. Use with caution.

#

# softfail = no

}

}

## EAP-TLS

#

# As of Version 3.0, the TLS configuration for TLS-based

# EAP types is above in the "tls-config" section.

#

tls {

# Point to the common TLS configuration

tls = tls-common

#

# As part of checking a client certificate, the EAP-TLS

# sets some attributes such as TLS-Client-Cert-CN. This

# virtual server has access to these attributes, and can

# be used to accept or reject the request.

#

# virtual_server = check-eap-tls

}

## EAP-TTLS

#

# The TTLS module implements the EAP-TTLS protocol,

# which can be described as EAP inside of Diameter,

# inside of TLS, inside of EAP, inside of RADIUS...

#

# Surprisingly, it works quite well.

#

ttls {


# Which tls-config section the TLS negotiation parameters

# are in - see EAP-TLS above for an explanation.

#

# In the case that an old configuration from FreeRADIUS

# v2.x is being used, all the options of the tls-config

# section may also appear instead in the 'tls' section

# above. If that is done, the tls= option here (and in

# tls above) MUST be commented out.

#

tls = tls-common

# The tunneled EAP session needs a default EAP type

# which is separate from the one for the non-tunneled

# EAP module. Inside of the TTLS tunnel, we recommend

# using EAP-MD5. If the request does not contain an

# EAP conversation, then this configuration entry is

# ignored.

#

default_eap_type = md5

# The tunneled authentication request does not usually

# contain useful attributes like 'Calling-Station-Id',

# etc. These attributes are outside of the tunnel,

# and normally unavailable to the tunneled

# authentication request.

#

# By setting this configuration entry to 'yes',

# any attribute which is NOT in the tunneled

# authentication request, but which IS available

# outside of the tunnel, is copied to the tunneled

# request.

#

# allowed values: {no, yes}

#

copy_request_to_tunnel = no

#

# As of version 3.0.5, this configuration item

# is deprecated. Instead, you should use

#

# update outer.session-state {

# ...

#

# }


96

#

# This will cache attributes for the final Access-Accept.

#

# The reply attributes sent to the NAS are usually

# based on the name of the user 'outside' of the

# tunnel (usually 'anonymous'). If you want to send

# the reply attributes based on the user name inside

# of the tunnel, then set this configuration entry to

# 'yes', and the reply to the NAS will be taken from

# the reply to the tunneled request.

#


#

use_tunneled_reply = no

#

# The inner tunneled request can be sent

# through a virtual server constructed

# specifically for this purpose.

#

# If this entry is commented out, the inner

# tunneled request will be sent through

# the virtual server that processed the

# outer requests.

#

virtual_server = "inner-tunnel"

# This has the same meaning, and overwrites, the

# same field in the "tls" configuration, above.

# The default value here is "yes".

#

# include_length = yes

#

# Unlike EAP-TLS, EAP-TTLS does not require a client

# certificate. However, you can require one by setting the

# following option. You can also override this option by

# setting

#

# EAP-TLS-Require-Client-Cert = Yes

#

# in the control items for a request.

#


# Note that the majority of supplicants do not support using a

# client certificate with EAP-TTLS, so this option is unlikely

# to be usable for most people.

#

# require_client_cert = yes

}

## EAP-PEAP

#

##################################################

#

# !!!!! WARNINGS for Windows compatibility !!!!!

#

##################################################

#

# If you see the server send an Access-Challenge,

# and the client never sends another Access-Request,

# then

#

# STOP!

#

# The server certificate has to have special OID's

# in it, or else the Microsoft clients will silently

# fail. See the "scripts/xpextensions" file for

# details, and the following page:

#

# http://support.microsoft.com/kb/814394/en-us

#

# For additional Windows XP SP2 issues, see:

#

# http://support.microsoft.com/kb/885453/en-us

#

#

# If is still doesn't work, and you're using Samba,

# you may be encountering a Samba bug. See:

#

# https://bugzilla.samba.org/show_bug.cgi?id=6563

#

# Note that we do not necessarily agree with their

# explanation... but the fix does appear to work.

#

##################################################


98

#

# The tunneled EAP session needs a default EAP type

# which is separate from the one for the non-tunneled

# EAP module. Inside of the TLS/PEAP tunnel, we

# recommend using EAP-MS-CHAPv2.

#

peap {

# Which tls-config section the TLS negotiation parameters

# are in - see EAP-TLS above for an explanation.

#

# In the case that an old configuration from FreeRADIUS

# v2.x is being used, all the options of the tls-config

# section may also appear instead in the 'tls' section

# above. If that is done, the tls= option here (and in

# tls above) MUST be commented out.

#

tls = tls-common

# The tunneled EAP session needs a default

# EAP type which is separate from the one for

# the non-tunneled EAP module. Inside of the

# PEAP tunnel, we recommend using MS-CHAPv2,

# as that is the default type supported by

# Windows clients.

#

default_eap_type = mschapv2

# The PEAP module also has these configuration

# items, which are the same as for TTLS.

#

copy_request_to_tunnel = no

#

# As of version 3.0.5, this configuration item

# is deprecated. Instead, you should use

#

# update outer.session-state {

# ...

#

# }

#

# This will cache attributes for the final Access-Accept.


#

use_tunneled_reply = no

# When the tunneled session is proxied, the

# home server may not understand EAP-MSCHAP-V2.

# Set this entry to "no" to proxy the tunneled

# EAP-MSCHAP-V2 as normal MSCHAPv2.

#

# proxy_tunneled_request_as_eap = yes

#

# The inner tunneled request can be sent

# through a virtual server constructed

# specifically for this purpose.

#

# If this entry is commented out, the inner

# tunneled request will be sent through

# the virtual server that processed the

# outer requests.

#

virtual_server = "inner-tunnel"

# This option enables support for MS-SoH

# see doc/SoH.txt for more info.

# It is disabled by default.

#

# soh = yes

#

# The SoH reply will be turned into a request which

# can be sent to a specific virtual server:

#

# soh_virtual_server = "soh-server"

#

# Unlike EAP-TLS, PEAP does not require a client certificate.

# However, you can require one by setting the following

# option. You can also override this option by setting

#

# EAP-TLS-Require-Client-Cert = Yes

#

# in the control items for a request.

#

# Note that the majority of supplicants do not support using a


100

# client certificate with PEAP, so this option is unlikely to

# be usable for most people.

#

# require_client_cert = yes

}

#

# This takes no configuration.

#

# Note that it is the EAP MS-CHAPv2 sub-module, not

# the main 'mschap' module.

#

# Note also that in order for this sub-module to work,

# the main 'mschap' module MUST ALSO be configured.

#

# This module is the *Microsoft* implementation of MS-CHAPv2

# in EAP. There is another (incompatible) implementation

# of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not

# currently support.

#

mschapv2 {

# Prior to version 2.1.11, the module never

# sent the MS-CHAP-Error message to the

# client. This worked, but it had issues

# when the cached password was wrong. The

# server *should* send "E=691 R=0" to the

# client, which tells it to prompt the user

# for a new password.

#

# The default is to behave as in 2.1.10 and

# earlier, which is known to work. If you

# set "send_error = yes", then the error

# message will be sent back to the client.

# This *may* help some clients work better,

# but *may* also cause other clients to stop

# working.

#

# send_error = no

# Server identifier to send back in the challenge.

# This should generally be the host name of the

# RADIUS server. Or, some information to uniquely

# identify it.


# identity = "FreeRADIUS"

}

## EAP-FAST

#

# The FAST module implements the EAP-FAST protocol

#

# fast {

# Point to the common TLS configuration

#

# tls = tls-common

#

# If 'cipher_list' is set here, it will over-ride the

# 'cipher_list' configuration from the 'tls-common'

# configuration. The EAP-FAST module has it's own

# over-ride for 'cipher_list' because the

# specifications mandata a different set of ciphers

# than are used by the other EAP methods.

#

# cipher_list though must include "ADH" for anonymous provisioning.

# This is not as straight forward as appending "ADH" alongside

# "DEFAULT" as "DEFAULT" contains "!aNULL" so instead it is

# recommended "ALL:!EXPORT:!eNULL:!SSLv2" is used

#

# Note - for OpenSSL 1.1.0 and above you may need

# to add ":@SECLEVEL=0"

#

# cipher_list = "ALL:!EXPORT:!eNULL:!SSLv2"

# PAC lifetime in seconds (default: seven days)

#

# pac_lifetime = 604800

# Authority ID of the server

#

# if you are running a cluster of RADIUS servers, you should make

# the value chosen here (and for "pac_opaque_key") the same on all

# your RADIUS servers. This value should be unique to your

# installation. We suggest using a domain name.

#

# authority_identity = "1234"

# PAC Opaque encryption key (must be exactly 32 bytes in size)


102

#

# This value MUST be secret, and MUST be generated using

# a secure method, such as via 'openssl rand -hex 32'

#

# pac_opaque_key = "0123456789abcdef0123456789ABCDEF"

# Same as for TTLS, PEAP, etc.

#

# virtual_server = inner-tunnel

# }

}

A.1.4 radiusd.conf

# -*- text -*-

##

## radiusd.conf -- FreeRADIUS server configuration file - 3.0.17

##

## http://www.freeradius.org/

## $Id: 59e59f3ac443e75663333a5b7732664b67c5567d $

##

######################################################################

#

# Read "man radiusd" before editing this file. See the section

# titled DEBUGGING. It outlines a method where you can quickly

# obtain the configuration you want, without running into

# trouble.

#

# Run the server in debugging mode, and READ the output.

#

# $ radiusd -X

#

# We cannot emphasize this point strongly enough. The vast

# majority of problems can be solved by carefully reading the

# debugging output, which includes warnings about common issues,

# and suggestions for how they may be fixed.

#

# There may be a lot of output, but look carefully for words like:

# "warning", "error", "reject", or "failure". The messages there

# will usually be enough to guide you to a solution.


#

# If you are going to ask a question on the mailing list, then

# explain what you are trying to do, and include the output from

# debugging mode (radiusd -X). Failure to do so means that all

# of the responses to your question will be people telling you

# to "post the output of radiusd -X".

######################################################################

#

# The location of other config files and logfiles are declared

# in this file.

#

# Also general configuration for modules can be done in this

# file, it is exported through the API to modules that ask for

# it.

#

# See "man radiusd.conf" for documentation on the format of this

# file. Note that the individual configuration items are NOT

# documented in that "man" page. They are only documented here,

# in the comments.

#

# The "unlang" policy language can be used to create complex

# if / else policies. See "man unlang" for details.

#

prefix = /usr/local

exec_prefix = ${prefix}

sysconfdir = ${prefix}/etc

localstatedir = ${prefix}/var

sbindir = ${exec_prefix}/sbin

logdir = ${localstatedir}/log/radius

raddbdir = ${sysconfdir}/raddb

radacctdir = ${logdir}/radacct

#

# name of the running server. See also the "-n" command-line option.

name = radiusd

# Location of config and logfiles.

confdir = ${raddbdir}

modconfdir = ${confdir}/mods-config

certdir = ${confdir}/certs

cadir = ${confdir}/certs

run_dir = ${localstatedir}/run/${name}


104

# Should likely be ${localstatedir}/lib/radiusd

db_dir = ${raddbdir}

#

# libdir: Where to find the rlm_* modules.

#

# This should be automatically set at configuration time.

#

# If the server builds and installs, but fails at execution time

# with an 'undefined symbol' error, then you can use the libdir

# directive to work around the problem.

#

# The cause is usually that a library has been installed on your

# system in a place where the dynamic linker CANNOT find it. When

# executing as root (or another user), your personal environment MAY

# be set up to allow the dynamic linker to find the library. When

# executing as a daemon, FreeRADIUS MAY NOT have the same

# personalized configuration.

#

# To work around the problem, find out which library contains that symbol,

# and add the directory containing that library to the end of 'libdir',

# with a colon separating the directory names. NO spaces are allowed.

#

# e.g. libdir = /usr/local/lib:/opt/package/lib

#

# You can also try setting the LD_LIBRARY_PATH environment variable

# in a script which starts the server.

#

# If that does not work, then you can re-configure and re-build the

# server to NOT use shared libraries, via:

#

# ./configure --disable-shared

# make

# make install

#

libdir = ${exec_prefix}/lib

# pidfile: Where to place the PID of the RADIUS server.

#

# The server may be signalled while it's running by using this

# file.

#


# This file is written when ONLY running in daemon mode.

#

# e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid`

#

pidfile = ${run_dir}/${name}.pid

#

# correct_escapes: use correct backslash escaping

#

# Prior to version 3.0.5, the handling of backslashes was a little

# awkward, i.e. "wrong". In some cases, to get one backslash into

# a regex, you had to put 4 in the config files.

#

# Version 3.0.5 fixes that. However, for backwards compatibility,

# the new method of escaping is DISABLED BY DEFAULT. This means

# that upgrading to 3.0.5 won't break your configuration.

#

# If you don't have double backslashes (i.e. \\) in your configuration,

# this won't matter to you. If you do have them, fix that to use only

# one backslash, and then set "correct_escapes = true".

#

# You can check for this by doing:

#

# $ grep '\\\\' $(find raddb -type f -print)

#

correct_escapes = true

# panic_action: Command to execute if the server dies unexpectedly.

#

# FOR PRODUCTION SYSTEMS, ACTIONS SHOULD ALWAYS EXIT.

# AN INTERACTIVE ACTION MEANS THE SERVER IS NOT RESPONDING TO REQUESTS.

# AN INTERACTICE ACTION MEANS THE SERVER WILL NOT RESTART.

#

# THE SERVER MUST NOT BE ALLOWED EXECUTE UNTRUSTED PANIC ACTION CODE

# PATTACH CAN BE USED AS AN ATTACK VECTOR.

#

# The panic action is a command which will be executed if the server

# receives a fatal, non user generated signal, i.e. SIGSEGV, SIGBUS,

# SIGABRT or SIGFPE.

#

# This can be used to start an interactive debugging session so

# that information regarding the current state of the server can

# be acquired.

#


106

# The following string substitutions are available:

# - %e The currently executing program e.g. /sbin/radiusd

# - %p The PID of the currently executing program e.g. 12345

#

# Standard ${} substitutions are also allowed.

#

# An example panic action for opening an interactive session in GDB would be:

#

#panic_action = "gdb %e %p"

#

# Again, don't use that on a production system.

#

# An example panic action for opening an automated session in GDB would be:

#

#panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p 2>&1 | tee ${logdir}/gdb-

${name}-%p.log"

#

# That command can be used on a production system.

#

# max_request_time: The maximum time (in seconds) to handle a request.

#

# Requests which take more time than this to process may be killed, and

# a REJECT message is returned.

#

# WARNING: If you notice that requests take a long time to be handled,

# then this MAY INDICATE a bug in the server, in one of the modules

# used to handle a request, OR in your local configuration.

#

# This problem is most often seen when using an SQL database. If it takes

# more than a second or two to receive an answer from the SQL database,

# then it probably means that you haven't indexed the database. See your

# SQL server documentation for more information.

#

# Useful range of values: 5 to 120

#

max_request_time = 30

# cleanup_delay: The time to wait (in seconds) before cleaning up

# a reply which was sent to the NAS.

#

# The RADIUS request is normally cached internally for a short period

# of time, after the reply is sent to the NAS. The reply packet may be

# lost in the network, and the NAS will not see it. The NAS will then


# re-send the request, and the server will respond quickly with the

# cached reply.

#

# If this value is set too low, then duplicate requests from the NAS

# MAY NOT be detected, and will instead be handled as separate requests.

#

# If this value is set too high, then the server will cache too many

# requests, and some new requests may get blocked. (See 'max_requests'.)

#

# Useful range of values: 2 to 10

#

cleanup_delay = 5

# max_requests: The maximum number of requests which the server keeps

# track of. This should be 256 multiplied by the number of clients.

# e.g. With 4 clients, this number should be 1024.

#

# If this number is too low, then when the server becomes busy,

# it will not respond to any new requests, until the 'cleanup_delay'

# time has passed, and it has removed the old requests.

#

# If this number is set too high, then the server will use a bit more

# memory for no real benefit.

#

# If you aren't sure what it should be set to, it's better to set it

# too high than too low. Setting it to 1000 per client is probably

# the highest it should be.

#

# Useful range of values: 256 to infinity

#

max_requests = 16384

# hostname_lookups: Log the names of clients or just their IP addresses

# e.g., www.freeradius.org (on) or 206.47.27.232 (off).

#

# The default is 'off' because it would be overall better for the net

# if people had to knowingly turn this feature on, since enabling it

# means that each client request will result in AT LEAST one lookup

# request to the nameserver. Enabling hostname_lookups will also

# mean that your server may stop randomly for 30 seconds from time

# to time, if the DNS requests take too long.

#

# Turning hostname lookups off also means that the server won't block

# for 30 seconds, if it sees an IP address which has no name associated


108

# with it.

#


#

hostname_lookups = no

#

# Logging section. The various "log_*" configuration items

# will eventually be moved here.

#

log {

#

# Destination for log messages. This can be one of:

#

# files - log to "file", as defined below.

# syslog - to syslog (see also the "syslog_facility", below.

# stdout - standard output

# stderr - standard error.

#

# The command-line option "-X" over-rides this option, and forces

# logging to go to stdout.

#

destination = files

#

# Highlight important messages sent to stderr and stdout.

#

# Option will be ignored (disabled) if output if TERM is not

# an xterm or output is not to a TTY.

#

colourise = yes

#

# The logging messages for the server are appended to the

# tail of this file if destination == "files"

#

# If the server is running in debugging mode, this file is

# NOT used.

#

file = ${logdir}/radius.log

#

# Which syslog facility to use, if ${destination} == "syslog"


#

# The exact values permitted here are OS-dependent. You probably

# don't want to change this.

#

syslog_facility = daemon

# Log the full User-Name attribute, as it was found in the request.

#


#

stripped_names = no

# Log authentication requests to the log file.

#


#

auth = no

# Log passwords with the authentication requests.

# auth_badpass - logs password if it's rejected

# auth_goodpass - logs password if it's correct

#


#

auth_badpass = no

auth_goodpass = no

# Log additional text at the end of the "Login OK" messages.

# for these to work, the "auth" and "auth_goodpass" or "auth_badpass"

# configurations above have to be set to "yes".

#

# The strings below are dynamically expanded, which means that

# you can put anything you want in them. However, note that

# this expansion can be slow, and can negatively impact server

# performance.

#

# msg_goodpass = ""

# msg_badpass = ""

# The message when the user exceeds the Simultaneous-Use limit.

#

msg_denied = "You are already logged in - access denied"

}


110

# The program to execute to do concurrency checks.

checkrad = ${sbindir}/checkrad

# SECURITY CONFIGURATION

#

# There may be multiple methods of attacking on the server. This

# section holds the configuration items which minimize the impact

# of those attacks

#

security {

# chroot: directory where the server does "chroot".

#

# The chroot is done very early in the process of starting

# the server. After the chroot has been performed it

# switches to the "user" listed below (which MUST be

# specified). If "group" is specified, it switches to that

# group, too. Any other groups listed for the specified

# "user" in "/etc/group" are also added as part of this

# process.

#

# The current working directory (chdir / cd) is left

# *outside* of the chroot until all of the modules have been

# initialized. This allows the "raddb" directory to be left

# outside of the chroot. Once the modules have been

# initialized, it does a "chdir" to ${logdir}. This means

# that it should be impossible to break out of the chroot.

#

# If you are worried about security issues related to this

# use of chdir, then simply ensure that the "raddb" directory

# is inside of the chroot, end be sure to do "cd raddb"

# BEFORE starting the server.

#

# If the server is statically linked, then the only files

# that have to exist in the chroot are ${run_dir} and

# ${logdir}. If you do the "cd raddb" as discussed above,

# then the "raddb" directory has to be inside of the chroot

# directory, too.

#

# chroot = /path/to/chroot/directory

# user/group: The name (or #number) of the user/group to run radiusd as.

#

# If these are commented out, the server will run as the


# user/group that started it. In order to change to a

# different user/group, you MUST be root ( or have root

# privileges ) to start the server.

#

# We STRONGLY recommend that you run the server with as few

# permissions as possible. That is, if you're not using

# shadow passwords, the user and group items below should be

# set to radius'.

#

# NOTE that some kernels refuse to setgid(group) when the

# value of (unsigned)group is above 60000; don't use group

# "nobody" on these systems!

#

# On systems with shadow passwords, you might have to set

# 'group = shadow' for the server to be able to read the

# shadow password file. If you can authenticate users while

# in debug mode, but not in daemon mode, it may be that the

# debugging mode server is running as a user that can read

# the shadow info, and the user listed below can not.

#

# The server will also try to use "initgroups" to read

# /etc/groups. It will join all groups where "user" is a

# member. This can allow for some finer-grained access

# controls.

#

# user = radius

# group = radius

# Core dumps are a bad thing. This should only be set to

# 'yes' if you're debugging a problem with the server.

#


#

allow_core_dumps = no

#

# max_attributes: The maximum number of attributes

# permitted in a RADIUS packet. Packets which have MORE

# than this number of attributes in them will be dropped.

#

# If this number is set too low, then no RADIUS packets

# will be accepted.

#

# If this number is set too high, then an attacker may be


112

# able to send a small number of packets which will cause

# the server to use all available memory on the machine.

#

# Setting this number to 0 means "allow any number of attributes"

max_attributes = 200

#

# reject_delay: When sending an Access-Reject, it can be

# delayed for a few seconds. This may help slow down a DoS

# attack. It also helps to slow down people trying to brute-force

# crack a users password.

#

# Setting this number to 0 means "send rejects immediately"

#

# If this number is set higher than 'cleanup_delay', then the

# rejects will be sent at 'cleanup_delay' time, when the request

# is deleted from the internal cache of requests.

#

# As of Version 3.0.5, "reject_delay" has sub-second resolution.

# e.g. "reject_delay = 1.4" seconds is possible.

#

# Useful ranges: 1 to 5

reject_delay = 1

#

# status_server: Whether or not the server will respond

# to Status-Server requests.

#

# When sent a Status-Server message, the server responds with

# an Access-Accept or Accounting-Response packet.

#

# This is mainly useful for administrators who want to "ping"

# the server, without adding test users, or creating fake

# accounting packets.

#

# It's also useful when a NAS marks a RADIUS server "dead".

# The NAS can periodically "ping" the server with a Status-Server

# packet. If the server responds, it must be alive, and the

# NAS can start using it for real requests.

#

# See also raddb/sites-available/status

#

status_server = yes


#

# allow_vulnerable_openssl: Allow the server to start with

# versions of OpenSSL known to have critical vulnerabilities.

#

# This check is based on the version number reported by libssl

# and may not reflect patches applied to libssl by

# distribution maintainers.

#

allow_vulnerable_openssl = no

}

# PROXY CONFIGURATION

#

# proxy_requests: Turns proxying of RADIUS requests on or off.

#

# The server has proxying turned on by default. If your system is NOT

# set up to proxy requests to another server, then you can turn proxying

# off here. This will save a small amount of resources on the server.

#

# If you have proxying turned off, and your configuration files say

# to proxy a request, then an error message will be logged.

#

# To disable proxying, change the "yes" to "no", and comment the

# $INCLUDE line.

#


#

proxy_requests = yes

$INCLUDE proxy.conf

# CLIENTS CONFIGURATION

#

# Client configuration is defined in "clients.conf".

#

# The 'clients.conf' file contains all of the information from the old

# 'clients' and 'naslist' configuration files. We recommend that you

# do NOT use 'client's or 'naslist', although they are still

# supported.

#

# Anything listed in 'clients.conf' will take precedence over the

# information from the old-style configuration files.


114

#

$INCLUDE clients.conf

# THREAD POOL CONFIGURATION

#

# The thread pool is a long-lived group of threads which

# take turns (round-robin) handling any incoming requests.

#

# You probably want to have a few spare threads around,

# so that high-load situations can be handled immediately. If you

# don't have any spare threads, then the request handling will

# be delayed while a new thread is created, and added to the pool.

#

# You probably don't want too many spare threads around,

# otherwise they'll be sitting there taking up resources, and

# not doing anything productive.

#

# The numbers given below should be adequate for most situations.

#

thread pool {

# Number of servers to start initially --- should be a reasonable

# ballpark figure.

start_servers = 5

# Limit on the total number of servers running.

#

# If this limit is ever reached, clients will be LOCKED OUT, so it

# should NOT BE SET TOO LOW. It is intended mainly as a brake to

# keep a runaway server from taking the system with it as it spirals

# down...

#

# You may find that the server is regularly reaching the

# 'max_servers' number of threads, and that increasing

# 'max_servers' doesn't seem to make much difference.

#

# If this is the case, then the problem is MOST LIKELY that

# your back-end databases are taking too long to respond, and

# are preventing the server from responding in a timely manner.

#

# The solution is NOT do keep increasing the 'max_servers'

# value, but instead to fix the underlying cause of the

# problem: slow database, or 'hostname_lookups=yes'.


#

# For more information, see 'max_request_time', above.

#

max_servers = 32

# Server-pool size regulation. Rather than making you guess

# how many servers you need, FreeRADIUS dynamically adapts to

# the load it sees, that is, it tries to maintain enough

# servers to handle the current load, plus a few spare

# servers to handle transient load spikes.

#

# It does this by periodically checking how many servers are

# waiting for a request. If there are fewer than

# min_spare_servers, it creates a new spare. If there are

# more than max_spare_servers, some of the spares die off.

# The default values are probably OK for most sites.

#

min_spare_servers = 3

max_spare_servers = 10

# When the server receives a packet, it places it onto an

# internal queue, where the worker threads (configured above)

# pick it up for processing. The maximum size of that queue

# is given here.

#

# When the queue is full, any new packets will be silently

# discarded.

#

# The most common cause of the queue being full is that the

# server is dependent on a slow database, and it has received

# a large "spike" of traffic. When that happens, there is

# very little you can do other than make sure the server

# receives less traffic, or make sure that the database can

# handle the load.

#

# max_queue_size = 65536

# Clean up old threads periodically. For no reason other than

# it might be useful.

#

# '0' is a special value meaning 'infinity', or 'the servers never

# exit'

max_requests_per_server = 0


116

# Automatically limit the number of accounting requests.

# This configuration item tracks how many requests per second

# the server can handle. It does this by tracking the

# packets/s received by the server for processing, and

# comparing that to the packets/s handled by the child

# threads.

#

# If the received PPS is larger than the processed PPS, *and*

# the queue is more than half full, then new accounting

# requests are probabilistically discarded. This lowers the

# number of packets that the server needs to process. Over

# time, the server will "catch up" with the traffic.

#

# Throwing away accounting packets is usually safe and low

# impact. The NAS will retransmit them in a few seconds, or

# even a few minutes. Vendors should read RFC 5080 Section 2.2.1

# to see how accounting packets should be retransmitted. Using

# any other method is likely to cause network meltdowns.

#

auto_limit_acct = no

}

######################################################################

#

# SNMP notifications. Uncomment the following line to enable

# snmptraps. Note that you MUST also configure the full path

# to the "snmptrap" command in the "trigger.conf" file.

#

#$INCLUDE trigger.conf

# MODULE CONFIGURATION

#

# The names and configuration of each module is located in this section.

#

# After the modules are defined here, they may be referred to by name,

# in other sections of this configuration file.

#

modules {

#

# Each module has a configuration as follows:

#

# name [ instance ] {


# config_item = value

# ...

# }

#

# The 'name' is used to load the 'rlm_name' library

# which implements the functionality of the module.

#

# The 'instance' is optional. To have two different instances

# of a module, it first must be referred to by 'name'.

# The different copies of the module are then created by

# inventing two 'instance' names, e.g. 'instance1' and 'instance2'

#

# The instance names can then be used in later configuration

# INSTEAD of the original 'name'. See the 'radutmp' configuration

# for an example.

#

#

# As of 3.0, modules are in mods-enabled/. Files matching

# the regex /[a-zA-Z0-9_.]+/ are loaded. The modules are

# initialized ONLY if they are referenced in a processing

# section, such as authorize, authenticate, accounting,

# pre/post-proxy, etc.

#

$INCLUDE mods-enabled/

}

# Instantiation

#

# This section orders the loading of the modules. Modules

# listed here will get loaded BEFORE the later sections like

# authorize, authenticate, etc. get examined.

#

# This section is not strictly needed. When a section like

# authorize refers to a module, it's automatically loaded and

# initialized. However, some modules may not be listed in any

# of the following sections, so they can be listed here.

#

# Also, listing modules here ensures that you have control over

# the order in which they are initialized. If one module needs

# something defined by another module, you can list them in order

# here, and ensure that the configuration will be OK.

#

# After the modules listed here have been loaded, all of the modules


118

# in the "mods-enabled" directory will be loaded. Loading the

# "mods-enabled" directory means that unlike Version 2, you usually

# don't need to list modules here.

#

instantiate {

#

# We list the counter module here so that it registers

# the check_name attribute before any module which sets

# it

# daily

# subsections here can be thought of as "virtual" modules.

#

# e.g. If you have two redundant SQL servers, and you want to

# use them in the authorize and accounting sections, you could

# place a "redundant" block in each section, containing the

# exact same text. Or, you could uncomment the following

# lines, and list "redundant_sql" in the authorize and

# accounting sections.

#

# The "virtual" module defined here can also be used with

# dynamic expansions, under a few conditions:

#

# * The section is "redundant", or "load-balance", or

# "redundant-load-balance"

# * The section contains modules ONLY, and no sub-sections

# * all modules in the section are using the same rlm_

# driver, e.g. They are all sql, or all ldap, etc.

#

# When those conditions are satisfied, the server will

# automatically register a dynamic expansion, using the

# name of the "virtual" module. In the example below,

# it will be "redundant_sql". You can then use this expansion

# just like any other:

#

# update reply {

# Filter-Id := "%{redundant_sql: ... }"

# }

#

# In this example, the expansion is done via module "sql1",

# and if that expansion fails, using module "sql2".

#

# For best results, configure the "pool" subsection of the


# module so that "retry_delay" is non-zero. That will allow

# the redundant block to quickly ignore all "down" SQL

# databases. If instead we have "retry_delay = 0", then

# every time the redundant block is used, the server will try

# to open a connection to every "down" database, causing

# problems.

#

#redundant redundant_sql {

# sql1

# sql2

#}

}

######################################################################

#

# Policies are virtual modules, similar to those defined in the

# "instantiate" section above.

#

# Defining a policy in one of the policy.d files means that it can be

# referenced in multiple places as a *name*, rather than as a series of

# conditions to match, and actions to take.

#

# Policies are something like subroutines in a normal language, but

# they cannot be called recursively. They MUST be defined in order.

# If policy A calls policy B, then B MUST be defined before A.

#

######################################################################

policy {

$INCLUDE policy.d/

}

######################################################################

#

# Load virtual servers.

#

# This next $INCLUDE line loads files in the directory that

# match the regular expression: /[a-zA-Z0-9_.]+/

#

# It allows you to define new virtual servers simply by placing

# a file into the raddb/sites-enabled/ directory.

#

$INCLUDE sites-enabled/

######################################################################


120

#

# All of the other configuration sections like "authorize {}",

# "authenticate {}", "accounting {}", have been moved to the

# the file:

#

# raddb/sites-available/default

#

# This is the "default" virtual server that has the same

# configuration as in version 1.0.x and 1.1.x. The default

# installation enables this virtual server. You should

# edit it to create policies for your local site.

#

# For more documentation on virtual servers, see:

#

# raddb/sites-available/README

#

######################################################################

A.1.5 ./sites-enabled/default

######################################################################

#

# As of 2.0.0, FreeRADIUS supports virtual hosts using the

# "server" section, and configuration directives.

#

# Virtual hosts should be put into the "sites-available"

# directory. Soft links should be created in the "sites-enabled"

# directory to these files. This is done in a normal installation.

#

# If you are using 802.1X (EAP) authentication, please see also

# the "inner-tunnel" virtual server. You will likely have to edit

# that, too, for authentication to work.

#

# $Id: 3616050e7625eb6b5e2ba44782fcb737b2ae6136 $

#

######################################################################

#

# Read "man radiusd" before editing this file. See the section

# titled DEBUGGING. It outlines a method where you can quickly

# obtain the configuration you want, without running into

# trouble. See also "man unlang", which documents the format


# of this file.

#

# This configuration is designed to work in the widest possible

# set of circumstances, with the widest possible number of

# authentication methods. This means that in general, you should

# need to make very few changes to this file.

#

# The best way to configure the server for your local system

# is to CAREFULLY edit this file. Most attempts to make large

# edits to this file will BREAK THE SERVER. Any edits should

# be small, and tested by running the server with "radiusd -X".

# Once the edits have been verified to work, save a copy of these

# configuration files somewhere. (e.g. as a "tar" file). Then,

# make more edits, and test, as above.

#

# There are many "commented out" references to modules such

# as ldap, sql, etc. These references serve as place-holders.

# If you need the functionality of that module, then configure

# it in radiusd.conf, and un-comment the references to it in

# this file. In most cases, those small changes will result

# in the server being able to connect to the DB, and to

# authenticate users.

#

######################################################################

server default {

#

# If you want the server to listen on additional addresses, or on

# additional ports, you can use multiple "listen" sections.

#

# Each section make the server listen for only one type of packet,

# therefore authentication and accounting have to be configured in

# different sections.

#

# The server ignore all "listen" section if you are using '-i' and '-p'

# on the command line.

#

listen {

# Type of packets to listen for.

# Allowed values are:

# auth listen for authentication packets

# acct listen for accounting packets

# proxy IP to use for sending proxied packets

# detail Read from the detail file. For examples, see


122

# raddb/sites-available/copy-acct-to-home-server

# status listen for Status-Server packets. For examples,

# see raddb/sites-available/status

# coa listen for CoA-Request and Disconnect-Request

# packets. For examples, see the file

# raddb/sites-available/coa

#

type = auth

# Note: "type = proxy" lets you control the source IP used for

# proxying packets, with some limitations:

#

# * A proxy listener CANNOT be used in a virtual server section.

# * You should probably set "port = 0".

# * Any "clients" configuration will be ignored.

#

# See also proxy.conf, and the "src_ipaddr" configuration entry

# in the sample "home_server" section. When you specify the

# source IP address for packets sent to a home server, the

# proxy listeners are automatically created.

# ipaddr/ipv4addr/ipv6addr - IP address on which to listen.

# If multiple ones are listed, only the first one will

# be used, and the others will be ignored.

#

# The configuration options accept the following syntax:

#

# ipv4addr - IPv4 address (e.g.192.0.2.3)

# - wildcard (i.e. *)

# - hostname (radius.example.com)

# Only the A record for the host name is used.

# If there is no A record, an error is returned,

# and the server fails to start.

#

# ipv6addr - IPv6 address (e.g. 2001:db8::1)

# - wildcard (i.e. *)

# - hostname (radius.example.com)

# Only the AAAA record for the host name is used.

# If there is no AAAA record, an error is returned,

# and the server fails to start.

#

# ipaddr - IPv4 address as above

# - IPv6 address as above


# - wildcard (i.e. *), which means IPv4 wildcard.

# - hostname

# If there is only one A or AAAA record returned

# for the host name, it is used.

# If multiple A or AAAA records are returned

# for the host name, only the first one is used.

# If both A and AAAA records are returned

# for the host name, only the A record is used.

#

# ipv4addr = *

# ipv6addr = *

ipaddr = *

# Port on which to listen.

# Allowed values are:

# integer port number (1812)

# 0 means "use /etc/services for the proper port"

port = 0

# Some systems support binding to an interface, in addition

# to the IP address. This feature isn't strictly necessary,

# but for sites with many IP addresses on one interface,

# it's useful to say "listen on all addresses for eth0".

#

# If your system does not support this feature, you will

# get an error if you try to use it.

#

# interface = eth0

# Per-socket lists of clients. This is a very useful feature.

#

# The name here is a reference to a section elsewhere in

# radiusd.conf, or clients.conf. Having the name as

# a reference allows multiple sockets to use the same

# set of clients.

#

# If this configuration is used, then the global list of clients

# is IGNORED for this "listen" section. Take care configuring

# this feature, to ensure you don't accidentally disable a

# client you need.

#

# See clients.conf for the configuration of "per_socket_clients".

#

# clients = per_socket_clients


124

#

# Connection limiting for sockets with "proto = tcp".

#

# This section is ignored for other kinds of sockets.

#

limit {

#

# Limit the number of simultaneous TCP connections to the socket

#

# The default is 16.

# Setting this to 0 means "no limit"


# The per-socket "max_requests" option does not exist.

#

# The lifetime, in seconds, of a TCP connection. After

# this lifetime, the connection will be closed.

#

# Setting this to 0 means "forever".

lifetime = 0

#

# The idle timeout, in seconds, of a TCP connection.

# If no packets have been received over the connection for

# this time, the connection will be closed.

#

# Setting this to 0 means "no timeout".

#

# We STRONGLY RECOMMEND that you set an idle timeout.

#

idle_timeout = 30

}

}

#

# This second "listen" section is for listening on the accounting

# port, too.

#

listen {

ipaddr = *

# ipv6addr = ::


port = 0

type = acct

# interface = eth0


limit {

# The number of packets received can be rate limited via the

# "max_pps" configuration item. When it is set, the server

# tracks the total number of packets received in the previous

# second. If the count is greater than "max_pps", then the

# new packet is silently discarded. This helps the server

# deal with overload situations.

#

# The packets/s counter is tracked in a sliding window. This

# means that the pps calculation is done for the second

# before the current packet was received. NOT for the current

# wall-clock second, and NOT for the previous wall-clock second.

#

# Useful values are 0 (no limit), or 100 to 10000.

# Values lower than 100 will likely cause the server to ignore

# normal traffic. Few systems are capable of handling more than

# 10K packets/s.

#

# It is most useful for accounting systems. Set it to 50%

# more than the normal accounting load, and you can be sure that

# the server will never get overloaded

#

# max_pps = 0

# Only for "proto = tcp". These are ignored for "udp" sockets.

#

# idle_timeout = 0

# lifetime = 0

# max_connections = 0

}

}

# IPv6 versions of the above - read their full config to understand options

listen {

type = auth

ipv6addr = :: # any. ::1 == localhost

port = 0

# interface = eth0



126

limit {


lifetime = 0

idle_timeout = 30

}

}

listen {

ipv6addr = ::

port = 0

type = acct

# interface = eth0


limit {

# max_pps = 0

# idle_timeout = 0

# lifetime = 0

# max_connections = 0

}

}

# Authorization. First preprocess (hints and huntgroups files),

# then realms, and finally look in the "users" file.

#

# Any changes made here should also be made to the "inner-tunnel"

# virtual server.

#

# The order of the realm modules will determine the order that

# we try to find a matching realm.

#

# Make *sure* that 'preprocess' comes before any realm if you

# need to setup hints for the remote radius server

authorize {

#

# Take a User-Name, and perform some checks on it, for spaces and other

# invalid characters. If the User-Name appears invalid, reject the

# request.

#

# See policy.d/filter for the definition of the filter_username policy.

#

filter_username


#

# Some broken equipment sends passwords with embedded zeros.

# i.e. the debug output will show

#

# User-Password = "password\000\000"

#

# This policy will fix it to just be "password".

#

# filter_password

#

# The preprocess module takes care of sanitizing some bizarre

# attributes in the request, and turning them into attributes

# which are more standard.

#

# It takes care of processing the 'raddb/mods-config/preprocess/hints'

# and the 'raddb/mods-config/preprocess/huntgroups' files.

preprocess

# If you intend to use CUI and you require that the Operator-Name

# be set for CUI generation and you want to generate CUI also

# for your local clients then uncomment the operator-name

# below and set the operator-name for your clients in clients.conf

# operator-name

#

# If you want to generate CUI for some clients that do not

# send proper CUI requests, then uncomment the

# cui below and set "add_cui = yes" for these clients in clients.conf

# cui

#

# If you want to have a log of authentication requests,

# un-comment the following line.

# auth_log

#

# The chap module will set 'Auth-Type := CHAP' if we are

# handling a CHAP request and Auth-Type has not already been set

chap

#

# If the users are logging in with an MS-CHAP-Challenge

# attribute for authentication, the mschap module will find


128

# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'

# to the request, which will cause the server to then use

# the mschap module for authentication.

mschap

#

# If you have a Cisco SIP server authenticating against

# FreeRADIUS, uncomment the following line, and the 'digest'

# line in the 'authenticate' section.

digest

#

# The WiMAX specification says that the Calling-Station-Id

# is 6 octets of the MAC. This definition conflicts with

# RFC 3580, and all common RADIUS practices. Un-commenting

# the "wimax" module here means that it will fix the

# Calling-Station-Id attribute to the normal format as

# specified in RFC 3580 Section 3.21

# wimax

#

# Look for IPASS style 'realm/', and if not found, look for

# '@realm', and decide whether or not to proxy, based on

# that.

# IPASS

#

# If you are using multiple kinds of realms, you probably

# want to set "ignore_null = yes" for all of them.

# Otherwise, when the first style of realm doesn't match,

# the other styles won't be checked.

#

suffix

# ntdomain

#

# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP

# authentication.

#

# It also sets the EAP-Type attribute in the request

# attribute list to the EAP type from the packet.

#

# The EAP module returns "ok" or "updated" if it is not yet ready


# to authenticate the user. The configuration below checks for

# "ok", and stops processing the "authorize" section if so.

#

# Any LDAP and/or SQL servers will not be queried for the

# initial set of packets that go back and forth to set up

# TTLS or PEAP.

#

# The "updated" check is commented out for compatibility with

# previous versions of this configuration, but you may wish to

# uncomment it as well; this will further reduce the number of

# LDAP and/or SQL queries for TTLS or PEAP.

#

eap {

ok = return

# updated = return

}

#

# Pull crypt'd passwords from /etc/passwd or /etc/shadow,

# using the system API's to get the password. If you want

# to read /etc/passwd or /etc/shadow directly, see the

# mods-available/passwd module.

#

# unix

#

# Read the 'users' file. In v3, this is located in

# raddb/mods-config/files/authorize

files

#

# Look in an SQL database. The schema of the database

# is meant to mirror the "users" file.

#

# See "Authorization Queries" in mods-available/sql

-sql

#

# If you are using /etc/smbpasswd, and are also doing

# mschap authentication, the un-comment this line, and

# configure the 'smbpasswd' module.

# smbpasswd

#


130

# The ldap module reads passwords from the LDAP database.

-ldap

#

# Enforce daily limits on time spent logged in.

# daily

#

expiration

logintime

#

# If no other module has claimed responsibility for

# authentication, then try to use PAP. This allows the

# other modules listed above to add a "known good" password

# to the request, and to do nothing else. The PAP module

# will then see that password, and use it to do PAP

# authentication.

#

# This module should be listed last, so that the other modules

# get a chance to set Auth-Type for themselves.

#

pap

#

# If "status_server = yes", then Status-Server messages are passed

# through the following section, and ONLY the following section.

# This permits you to do DB queries, for example. If the modules

# listed here return "fail", then NO response is sent.

#

# Autz-Type Status-Server {

#

# }

}

# Authentication.

#

#

# This section lists which modules are available for authentication.

# Note that it does NOT mean 'try each module in order'. It means

# that a module from the 'authorize' section adds a configuration

# attribute 'Auth-Type := FOO'. That authentication type is then


# used to pick the appropriate module from the list below.

#

# In general, you SHOULD NOT set the Auth-Type attribute. The server

# will figure it out on its own, and will do the right thing. The

# most common side effect of erroneously setting the Auth-Type

# attribute is that one authentication method will work, but the

# others will not.

#

# The common reasons to set the Auth-Type attribute by hand

# is to either forcibly reject the user (Auth-Type := Reject),

# or to or forcibly accept the user (Auth-Type := Accept).

#

# Note that Auth-Type := Accept will NOT work with EAP.

#

# Please do not put "unlang" configurations into the "authenticate"

# section. Put them in the "post-auth" section instead. That's what

# the post-auth section is for.

#

authenticate {

#

# PAP authentication, when a back-end database listed

# in the 'authorize' section supplies a password. The

# password can be clear-text, or encrypted.

Auth-Type PAP {

pap

}


krb5

}

#

# Most people want CHAP authentication

# A back-end database listed in the 'authorize' section

# MUST supply a CLEAR TEXT password. Encrypted passwords

# won't work.

Auth-Type CHAP {

chap

}

#

# MSCHAP authentication.

Auth-Type MS-CHAP {


132

mschap

}

#

# For old names, too.

#

mschap

#

# If you have a Cisco SIP server authenticating against

# FreeRADIUS, uncomment the following line, and the 'digest'

# line in the 'authorize' section.

digest

#

# Pluggable Authentication Modules.

# pam

# Uncomment it if you want to use ldap for authentication

#

# Note that this means "check plain-text password against

# the ldap database", which means that EAP won't work,

# as it does not supply a plain-text password.

#

# We do NOT recommend using this. LDAP servers are databases.

# They are NOT authentication servers. FreeRADIUS is an

# authentication server, and knows what to do with authentication.

# LDAP servers do not.

#

# Auth-Type LDAP {

# ldap

# }

#

# Allow EAP authentication.

eap

#

# The older configurations sent a number of attributes in

# Access-Challenge packets, which wasn't strictly correct.

# If you want to filter out these attributes, uncomment

# the following lines.

#


# Auth-Type eap {

# eap {

# handled = 1

# }

# if (handled && (Response-Packet-Type == Access-Challenge)) {

# attr_filter.access_challenge.post-auth

# handled # override the "updated" code from attr_filter

# }

# }

}

#

# Pre-accounting. Decide which accounting type to use.

#

preacct {

preprocess

#

# Merge Acct-[Input|Output]-Gigawords and Acct-[Input-Output]-Octets

# into a single 64bit counter Acct-[Input|Output]-Octets64.

#

# acct_counters64

#

# Session start times are *implied* in RADIUS.

# The NAS never sends a "start time". Instead, it sends

# a start packet, *possibly* with an Acct-Delay-Time.

# The server is supposed to conclude that the start time

# was "Acct-Delay-Time" seconds in the past.

#

# The code below creates an explicit start time, which can

# then be used in other modules. It will be *mostly* correct.

# Any errors are due to the 1-second resolution of RADIUS,

# and the possibility that the time on the NAS may be off.

#

# The start time is: NOW - delay - session_length

#

# update request {

# &FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-

Time}:-0} - %{%{Acct-Delay-Time}:-0}}"

# }


134

#

# Ensure that we have a semi-unique identifier for every

# request, and many NAS boxes are broken.

acct_unique

#

# Look for IPASS-style 'realm/', and if not found, look for

# '@realm', and decide whether or not to proxy, based on

# that.

#

# Accounting requests are generally proxied to the same

# home server as authentication requests.

# IPASS

suffix

# ntdomain

#

# Read the 'acct_users' file

files

}

#

# Accounting. Log the accounting data.

#

accounting {

# Update accounting packet by adding the CUI attribute

# recorded from the corresponding Access-Accept

# use it only if your NAS boxes do not support CUI themselves

# cui

#

# Create a 'detail'ed log of the packets.

# Note that accounting requests which are proxied

# are also logged in the detail file.

detail

# daily

# Update the wtmp file

#

# If you don't use "radlast", you can delete this line.

unix

#


# For Simultaneous-Use tracking.

#

# Due to packet losses in the network, the data here

# may be incorrect. There is little we can do about it.

# radutmp

# sradutmp

# Return an address to the IP Pool when we see a stop record.

# main_pool

#

# Log traffic to an SQL database.

#

# See "Accounting queries" in mods-available/sql

-sql

#

# If you receive stop packets with zero session length,

# they will NOT be logged in the database. The SQL module

# will print a message (only in debugging mode), and will

# return "noop".

#

# You can ignore these packets by uncommenting the following

# three lines. Otherwise, the server will not respond to the

# accounting request, and the NAS will retransmit.

#

# if (noop) {

# ok

# }

# Cisco VoIP specific bulk accounting

# pgsql-voip

# For Exec-Program and Exec-Program-Wait

exec

# Filter attributes from the accounting response.

attr_filter.accounting_response

#

# See "Autz-Type Status-Server" for how this works.

#

# Acct-Type Status-Server {

#


136

# }

}

# Session database, used for checking Simultaneous-Use. Either the radutmp

# or rlm_sql module can handle this.

# The rlm_sql module is *much* faster

session {

# radutmp

#

# See "Simultaneous Use Checking Queries" in mods-available/sql

# sql

}

# Post-Authentication

# Once we KNOW that the user has been authenticated, there are

# additional steps we can take.

post-auth {

#

# If you need to have a State attribute, you can

# add it here. e.g. for later CoA-Request with

# State, and Service-Type = Authorize-Only.

#

# if (!&reply:State) {

# update reply {

# State := "0x%{randstr:16h}"

# }

# }

#

# For EAP-TTLS and PEAP, add the cached attributes to the reply.

# The "session-state" attributes are automatically cached when

# an Access-Challenge is sent, and automatically retrieved

# when an Access-Request is received.

#

# The session-state attributes are automatically deleted after

# an Access-Reject or Access-Accept is sent.

#

update {

&reply: += &session-state:

}


# Get an address from the IP Pool.

# main_pool

# Create the CUI value and add the attribute to Access-Accept.

# Uncomment the line below if *returning* the CUI.

# cui

#

# If you want to have a log of authentication replies,

# un-comment the following line, and enable the

# 'detail reply_log' module.

# reply_log

#

# After authenticating the user, do another SQL query.

#

# See "Authentication Logging Queries" in mods-available/sql

-sql

#

# Un-comment the following if you want to modify the user's object

# in LDAP after a successful login.

#

# ldap

# For Exec-Program and Exec-Program-Wait

exec

#

# Calculate the various WiMAX keys. In order for this to work,

# you will need to define the WiMAX NAI, usually via

#

# update request {

# WiMAX-MN-NAI = "%{User-Name}"

# }

#

# If you want various keys to be calculated, you will need to

# update the reply with "template" values. The module will see

# this, and replace the template values with the correct ones

# taken from the cryptographic calculations. e.g.

#

# update reply {


138

# WiMAX-FA-RK-Key = 0x00

# WiMAX-MSK = "%{EAP-MSK}"

# }

#

# You may want to delete the MS-MPPE-*-Keys from the reply,

# as some WiMAX clients behave badly when those attributes

# are included. See "raddb/modules/wimax", configuration

# entry "delete_mppe_keys" for more information.

#

# wimax

# If there is a client certificate (EAP-TLS, sometimes PEAP

# and TTLS), then some attributes are filled out after the

# certificate verification has been performed. These fields

# MAY be available during the authentication, or they may be

# available only in the "post-auth" section.

#

# The first set of attributes contains information about the

# issuing certificate which is being used. The second

# contains information about the client certificate (if

# available).

#

# update reply {

# Reply-Message += "%{TLS-Cert-Serial}"

# Reply-Message += "%{TLS-Cert-Expiration}"

# Reply-Message += "%{TLS-Cert-Subject}"

# Reply-Message += "%{TLS-Cert-Issuer}"

# Reply-Message += "%{TLS-Cert-Common-Name}"

# Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"

#

# Reply-Message += "%{TLS-Client-Cert-Serial}"

# Reply-Message += "%{TLS-Client-Cert-Expiration}"

# Reply-Message += "%{TLS-Client-Cert-Subject}"

# Reply-Message += "%{TLS-Client-Cert-Issuer}"

# Reply-Message += "%{TLS-Client-Cert-Common-Name}"

# Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"

# }

# Insert class attribute (with unique value) into response,

# aids matching auth and acct records, and protects against duplicate

# Acct-Session-Id. Note: Only works if the NAS has implemented

# RFC 2865 behaviour for the class attribute, AND if the NAS


# supports long Class attributes. Many older or cheap NASes

# only support 16-octet Class attributes.

# insert_acct_class

# MacSEC requires the use of EAP-Key-Name. However, we don't

# want to send it for all EAP sessions. Therefore, the EAP

# modules put required data into the EAP-Session-Id attribute.

# This attribute is never put into a request or reply packet.

#

# Uncomment the next few lines to copy the required data into

# the EAP-Key-Name attribute

# if (&reply:EAP-Session-Id) {

# update reply {

# EAP-Key-Name := &reply:EAP-Session-Id

# }

# }

# Remove reply message if the response contains an EAP-Message

remove_reply_message_if_eap

#

# Access-Reject packets are sent through the REJECT sub-section of the

# post-auth section.

#

# Add the ldap module name (or instance) if you have set

# 'edir_account_policy_check = yes' in the ldap module configuration

#

# The "session-state" attributes are not available here.

#

Post-Auth-Type REJECT {

# log failed authentications in SQL, too.

-sql

attr_filter.access_reject

# Insert EAP-Failure message if the request was

# rejected by policy instead of because of an

# authentication failure

eap

# Remove reply message if the response contains an EAP-Message

remove_reply_message_if_eap

}

#


140

# Filter access challenges.

#

Post-Auth-Type Challenge {

# remove_reply_message_if_eap

# attr_filter.access_challenge.post-auth

}

}

#

# When the server decides to proxy a request to a home server,

# the proxied request is first passed through the pre-proxy

# stage. This stage can re-write the request, or decide to

# cancel the proxy.

#

# Only a few modules currently have this method.

#

pre-proxy {

# Before proxing the request add an Operator-Name attribute identifying

# if the operator-name is found for this client.

# No need to uncomment this if you have already enabled this in

# the authorize section.

# operator-name

# The client requests the CUI by sending a CUI attribute

# containing one zero byte.

# Uncomment the line below if *requesting* the CUI.

# cui

# Uncomment the following line if you want to change attributes

# as defined in the preproxy_users file.

# files

# Uncomment the following line if you want to filter requests

# sent to remote servers based on the rules defined in the

# 'attrs.pre-proxy' file.

# attr_filter.pre-proxy

# If you want to have a log of packets proxied to a home

# server, un-comment the following line, and the

# 'detail pre_proxy_log' section, above.

# pre_proxy_log

}


#

# When the server receives a reply to a request it proxied

# to a home server, the request may be massaged here, in the

# post-proxy stage.

#

post-proxy {

# If you want to have a log of replies from a home server,

# un-comment the following line, and the 'detail post_proxy_log'

# section, above.

# post_proxy_log

# Uncomment the following line if you want to filter replies from

# remote proxies based on the rules defined in the 'attrs' file.

# attr_filter.post-proxy

#

# If you are proxying LEAP, you MUST configure the EAP

# module, and you MUST list it here, in the post-proxy

# stage.

#

# You MUST also use the 'nostrip' option in the 'realm'

# configuration. Otherwise, the User-Name attribute

# in the proxied request will not match the user name

# hidden inside of the EAP packet, and the end server will

# reject the EAP request.

#

eap

#

# If the server tries to proxy a request and fails, then the

# request is processed through the modules in this section.

#

# The main use of this section is to permit robust proxying

# of accounting packets. The server can be configured to

# proxy accounting packets as part of normal processing.

# Then, if the home server goes down, accounting packets can

# be logged to a local "detail" file, for processing with

# radrelay. When the home server comes back up, radrelay

# will read the detail file, and send the packets to the

# home server.

#

# With this configuration, the server always responds to


142

# Accounting-Requests from the NAS, but only writes

# accounting packets to disk if the home server is down.

#

# Post-Proxy-Type Fail-Accounting {

# detail

# }

}

}

A.2 Kerberos

En esta sección mostraremos los archivos de configuración completos del sistema Kerberos

A.2.1 /etc/krb5.conf

[libdefaults]

default_realm = JOSE.RTS

# The following krb5.conf variables are only for MIT Kerberos.

kdc_timesync = 1

ccache_type = 4

forwardable = true

proxiable = true

# The following encryption type specification will be used by MIT Kerberos

# if uncommented. In general, the defaults in the MIT Kerberos code are

# correct and overriding these specifications only serves to disable new

# encryption types as they are added, creating interoperability problems.

#

# The only time when you might need to uncomment these lines and change

# the enctypes is if you have local software that will break on ticket

# caches containing ticket encryption types it doesn't know about (such as

# old versions of Sun Java).

# default_tgs_enctypes = des3-hmac-sha1

# default_tkt_enctypes = des3-hmac-sha1

# permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.

fcc-mit-ticketflags = true

[realms]


DOMINIOSES.RTS = {

kdc = dc.dominioses.rts

admin_server = dc.dominioses.rts

}

JOSE.RTS = {

kdc = kdc01.jose.rts

admin_server = kdc01.jose.rts

}

[domain_realm]

.dominioses.rts = DOMINIOSES.RTS

dominioses.rts = DOMINIOSES.RTS

.jose.rts = JOSE.RTS

jose.rts = JOSE.RTS

A.2.2 /etc/krb5kdc/kdc.conf

[kdcdefaults]

kdc_ports = 750,88

[realms]

JOSE.RTS = {

database_name = /var/lib/krb5kdc/principal

admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab

acl_file = /etc/krb5kdc/kadm5.acl

key_stash_file = /etc/krb5kdc/stash

kdc_ports = 750,88

max_life = 10h 0m 0s

max_renewable_life = 7d 0h 0m 0s

master_key_type = des3-hmac-sha1

#supported_enctypes = aes256-cts:normal aes128-cts:normal

default_principal_flags = +preauth

}

proyecto fin de carrerabibing.us.es/proyectos/abreproy/12446/fichero/pfc-2446... · 5.1 switch 3com...

Documents