Sunteți pe pagina 1din 96

RADIUSRADIUS

RADIUS RADIUS ““TodoTodo elel mundomundo sabesabe queque KITTKITT nono funcionafunciona concon llaves,llaves, parapara

““TodoTodo elel mundomundo sabesabe queque KITTKITT nono funcionafunciona concon llaves,llaves, parapara arrancararrancar elel cochecoche hacehace faltafalta autenticaciónautenticación viavia RADIUSRADIUS .”.” nonr00t’snonr00t’s stufstuf

JavierJavier LozanoLozano SalinasSalinas

Teoria

Indice

IntroduccionIntroduccion

33

S ervidores

39

DefiniciónDefinición

44

Clientes

51

UsoUso dede UDPUDP

99

Kerberos

58

 

Enlaces de interes 86

FormatoFormato dede paquetespaquetes RadiusRadius

1212

TipoTipo dede paquetespaquetes RadiusRadius

2222

FuncionamientoFuncionamiento

3131

ProxyProxy RadiusRadius

3636

Practica

PreinstalacionPreinstalacion

6666

ConfiguracionConfiguracion dede FreeradiusFreeradius

6868

NasNas

7070

PortalPortal CautivoCautivo

7373

ConfiguracionConfiguracion ChillispotChillispot

7474

ConfiguracionConfiguracion Apache2Apache2

7878

ConfiguracionConfiguracion OpenldapOpenldap

8080

PracticaPractica 22 TodoTodo enen 11

8181

Introducción

En esta práctica vamos a estudiar RADIUS, un protocolo ampliamente empleado para controlar el acceso a servicios en red.

Lo primero que vamos a estudiar es la teoría asociada a este protocolo, viendo también conceptos relacionados con el mismo, como NAS.

Veremos el formato de los mensajes, el uso de cada uno, su funcionamiento y los diferentes estados en los que puede encontrarse la comunicación.

Tambien veremos la implementacion de este protocolo en diferentes servidores y clientes.

Finalmente instalaremos FreeRADIUS usando Netkit, configurando el servidor para que dé servicio a un punto de acceso.

Definición - Radius

RADIUS (Remote Authentication Dial-In User Server) es un protocolo que nos permite gestionar la “autenticación, autorización y registro” de usuarios remotos sobre un determinado recurso.

Fue originalmente especificado en 1991 para controlar accesos dial-in al NSFnet.y no fue creado inicialmente para ser un método de seguridad en redes inalambricas. RADIUS mejora el estándar de encriptación WEP, en conjunto con otros métodos de seguridad como EAP-PEAP.

Fue desarrollado por Livingston Enterprises para la serie PortMaster de sus

Servidores de Acceso a la Red(NAS), más tarde se publicó como RFC 2138 y RFC

2139.

Mucha de la informacion que expongo esta basada en el RFC 2865(autenticacion

y autorizacion) y RFC 2866(registro).

Definición - Radius

Al principio este protocolo usaba el puerto UDP numero 1645, el cual entraba en conflicto con el servicio de “datametrics”. El puerto oficial asignado es el 1812.

La “autenticación, autorización y registro” es más conocida como AAA, al ser éste su acrónimo de su denominación inglesa:

Authentication, Authorization, and Accounting”.

Aunque RADIUS es el protocolo para AAA más extendido en la actualidad, ya existe un nuevo protocolo que podria sustituir al Radius. Es el llamado DIAMETER, y proporciona manejo de errores y comunicación entre dominios.

Vamos a describir a qué se refiere cada uno de los terminos de la AAA:

Radius - Autenticacion

Hace referencia al proceso por el cual se determina si un usuario tiene permiso para acceder a un determinado servicio de ed del que quiere hacer uso.

El proceso de autenticación se realiza mediante la presentación de una identidad y unos credenciales por parte del usuario que demanda acceso. Un tipo habitual de credencial es el uso del nombre de login junto con su contraseña. Otros tipos más avanzados de credenciales son los certificados digitales.

Existen muchos métodos que implementan el proceso de la autenticación y son soportados por Radius:

- Autenticación de sistema (system authentication), típica en un sistema Unix, normalmente realizada mediante el uso del fichero /etc/passwd.

- Los protocolos PAP (Password Authentication Protocol), que son métodos de

autenticación usados por proveedores de servicios de Internet (ISPs) accesibles vía PPP.

- LDAP (Lightweight Directory Access Protocol), un protocolo que implementa un servicio de

directorio ordenado, y muy empleado como base de datos para contener nombres de usuarios y sus contraseñas.

- Kerberos, método de autenticación diseñado por el MIT. Hablaremos mas de el mas tarde.

- EAP (Extensible Authentication Protocol), que es un entorno de autenticación empleado en redes inalámbricas y conexiones punto a punto.

Radius - Autorización

Se refiere a conceder servicios específicos a un determinado usuario, basándose para ello en su propia autenticación, los servicios que está solicitando, y el estado actual del sistema.

Es posible configurar restricciones a la autorización de determinados servicios en función de aspectos como, por ejemplo, la hora del día, la localización del usuario, o incluso la posibilidad o imposibilidad de realizar múltiples “logins” de un mismo usuario.

El proceso de autorización determina la naturaleza del servicio que se concede al usuario, como son: la dirección IP que se le asigna, el tipo de calidad de servicio(QoS) que va a recibir, el uso de encriptación, o la utilización obligatoria de túneles para determinadas conexiones.

Los métodos de autorización soportados habitualmente por un servidor de RADIUS incluyen bases de datos LDAP, bases de datos SQL (como Oracle, MySQL y PostgreSQL), o incluso el uso de ficheros de configuración locales al servidor.

Radius - Registro

Se refiere a realizar un registro del consumo de recursos que realizan los usuarios. El registro suele incluir aspectos como la identidad del usuario, la naturaleza del servicio prestado, y cuándo empezó y terminó el uso de dicho servicio.

Uso de UDP

Los paquetes RADIUS son encapsulados en el campo de datos de UDP donde el campo de puerto de destino indica 1812(en decimal).

donde el campo de puerto de destino indica 1812(en decimal). Cuando es generada una respuesta, se

Cuando es generada una respuesta, se intercambian los puertos de origen y destino.

Una pregunta frecuente es porque RADIUS usa UDP en vez de TCP como protocolo de transporte. Se eligió UDP por estrictas razones tecnicas:

Uso de UDP

1.- Si la peticion para una primeta autenticacion al servidor falla, un segundo servidor tiene que ponerse de respaldo.

Para entenderlo, una copia de la peticion debe estar guardada sobre la capa de transporte para el envio a una ruta alternativa. Esto significa que los temporizadores de retransmision son necesarios.

2.- Los temporizadores de este protocolo en particular son significativamente diferentes que los proveídos por TCP.

Por un lado, RADIUS no requiere un control de flujo. El usuario no necesita una respuesta rapida, se supone que esta dispuesto a esperar unos segundos para la autenticacion.

Por otro lado, el usuario tampoco va a esperar unos minutos para la autenticacion. Por lo tanto la entrega fiable de datos TCP dos minutos más tarde no es útil.

Uso de UDP

3.- Las pocas opciones del RADIUS simplifican el uso de UDP.

Los servidores y clientes se conectan y desconectan temporalmente. Los sistemas se reinician o se mantienen en stand by. Generalmente esto causaria problemas con los temporizadores y la deteccion de segmentos TCP perdidos. UDP sin embargo elimina cualquier tipo de manejo especial sobre las comuncaciones. Cada cliente y servidor puede abrir su capa de transporte UDP una sola vez y dejarlo abierto a pesar de cualquier fallo en la red.

4.- UDP simplifica los procesos del servidor

En las ultimas implementaciones del RADIUS los servidores eran muy basicos. Llegaba una trama, se procesaba y se enviaba. Esto lo hacia poco manejable sobretodo en entornos donde los mecanismos de seguridad hacian que tardase 1 o mas segundos. Las peticiones entran en cola cuando muchos usuarios querian conectarse. La solucion obvia fue permitir la multidifusion del servidor.

Formato de los paquetes RADIUS

La siguiente imagen muestra la estructura de un paquete de datos RADIUS. Los campos son transmitidos de izquierda a derecha

datos RADIUS. Los campos son transmitidos de izquierda a derecha Vamos a describir cada uno de

Vamos a describir cada uno de los campos de un paquete.

Formato de los paquetes RADIUS:

Campo Código

Los campos de codigo ocupan 1 octeto,

#

Message

Reference

e identifican el tipo de paquete

1

Access-Request

[RFC2865]

RADIUS. Los paquetes con un codigo

2

Access-Accept

[RFC2865]

de campo invalido son descartados.

3

Access-Reject

[RFC2865]

Código – Tipo de paquete RADIUS (1

4

Accounting-Request

[RFC2865]

byte).

5

Accounting-Response

[RFC2865]

6

Accounting-Status(registro)

[RFC2882]

Veremos algunos de los codigos mas

7

Password-Request

[RFC2882]

importantes. Y mas tarde podremos ver

8

Password-Ack

[RFC2882]

los paquetes en formato Wireshark

9

Password-Reject

[RFC2882]

para que sirva de ejemplo.

10

Accounting-Message

[RFC2882]

11

Access-Challenge

[RFC2865]

Formato de los paquetes RADIUS:

Campos Identificador y Longitud

El campo identificador esta compuesto por un octeto, y es añadido en las peticiones y respuesa. El sevidor RADIUS puede detectar una peticion duplicada comparando la direccion IP de origen, el puerto UDP de origen y el identifador.

El campo de longitud esta formado por 2 octetos. Indica la longitud del paquete incluido todos los campos y atributos. Los octetos fuera de rango de la longitud se ignoran al recibirlo. Si un paquete es menor que la longitud que indica el campo éste sera descartado sin aviso. La longitud minima es de 20 bits y la maxima es de 4096 bits.

Formato de los paquetes RADIUS:

Campo autenticador

En los paquetes de peticion, el valor de este campo es un numero aleatorio comprendido entre 1 y 16 llamado autenticador de peticion. El valor debe ser secreto y unico (la contraseña que comparten entre servidor y cliente).

Aunque los protocolos como RADIUS sean incapaces de protegerse contra el robo de una sesión autenticada vía ataques de intervención de las conexiones en tiempo real, lla generacion de peticiones unicas e impredecibles pueden proteger contra una amplia gama de ataques activos contra la autenticación.

El valor del campo de tipo “access-acept”, “access-reject” y “access-challenge” son llamados autenticadores de respuesta y contienen un valor encriptado en

MD5.

Veremos los tipos de paquetes tras los atributos.

Formato de los paquetes RADIUS:

Campo de Atributos

Los atributos de RADIUS llevan informacion especifica sobre la autenticacion y la autorizacion ademas de detalles de configuracion para las peticiones y respuestas. En un mensaje, al final de los atributos se indica la longitud del paquete RADIUS.

0

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

1

2

--------------------------------------------------------

|

Type

|

Length

| Value

--------------------------------------------------------------

Se pueden incluir mas d eun atributo. Si se presentan atributos con el mismo tipo de atibuto el orden de estos debe ser inalterado por los proxies. Sin embargo el orden de los diferentes tipos de atributos no es necesario que sea preservado. Aquí se muestra un sumario del formato de un atributo. Los campos son transmitidos de izquierda a derecha.

Campo de Atributos:

TIPO

El campo tipo esta formado por un octeto. Los valores actualizados del campo tipo estan especificado en el mas reciente RFC. Los valores comprendidos entre 192 y 223 estan reservado para uso experimental, 224-240 para uso especifico de la implementacion y los valores 241-255 estan reservados y no deben ser usados.

Un servidor RADIUS y un cliente ignoraran aquellos atributos cuyo tipo sea desconocido.

Esta especificacion contiene los siguientes valores:

Campo de Atributos:

TIPO

1

User-Name

2

User-Password

3

CHAP-Password

4

NAS-IP-Address

5

NAS-Port

6

Service-Type

7

Framed-Protocol

8

Framed-IP-Address

9

Framed-IP-Netmask

10

Framed-Routing

11

Filter-Id

12

Framed-MTU

13

Framed-Compression

14

Login-IP-Host

15

Login-Service

16

Login-TCP-Port

17

(unassigned)

18

Reply-Message

19

Callback-Number

20

Callback-Id

21

(unassigned)

22

Framed-Route

23

Framed-IPX-Network

24

State

25

Class

26

Vendor-Specific

27

Session-Timeout

28

Idle-Timeout

29

Termination-Action

30

Called-Station-Id

31

Calling-Station-Id

32

NAS-Identifier

33

Proxy-State

34

Login-LAT-Service

35

Login-LAT-Node

36

Login-LAT-Group

37

Framed-AppleTalk-Link

38

Framed-AppleTalk-Network

39

Framed-AppleTalk-Zone

40

Acct-Status-Type

41

Acct-Delay-Time

42

Acct-Input-Octets

43

Acct-Output-Octets

45

Acct-Authentic

46

Acct-Session-Time

47

Acct-Input-Packets

48

Acct-Output-Packets

49

Acct-Terminate-Cause

50

Acct-Multi-Session-Id

51

Acct-Link-Count

60

CHAP-Challenge

61

NAS-Port-Type

62

Port-Limit

63

Login-LAT-Port

Campo de Atributos:

LONGITUD

El campo de longitud ocupa un octeto e indica la longitud de los atributos, incluido el tipo, la definicion de la longitud en si y el campo de valor.

S i un atributo es recibido en una peticion de aceso pero con una longitud de atributo invalida, se transmitira un access-reject por parte del servidor.

S i esto sucede en una aceptacion, rechazo o en un mensaje para poner a prueba, el cliente lo descartara.

Campo de Atributos:

VALOR

El campo de valor contiene informacion especifica del atributo y esta compuesto po 0 o mas octetos. El formato y la longitud del campo valor estan determinados en los campos anteriores de tipo y longitud.

Una nota importante es que ninguno de los tipos en RADIUS terminan con un NULL. Los tipos de texto y string en particular no deben terminar con un NULL. El texto esta codificado en UTF-8 y el string contiene datos binarios de 8bits. En las implementaciones de RADIUS usando C se recomienda no usar el strcpy() cuando use strings.

El formato del campo valor comprende 5 tipos de datos diferentes. El tipo texto si lo vemos, es un subtipo del string.

Campo de Atributos:

VALOR

Esta tabla muestra los diferentes tipos que pueden incorporarse en este campo:

TEXT

De 1 a 253 octetos usando la codificación UTF-8. El texto con longitud 0 no puede ser enviado. Si fuera así se omite el atributo entero.

S TRING

De 1 a 253 octetos usando datos binarios. Los strings de longitud 0 tampoco pueden ser enviados.

ADDRESS

Valor de 32 bit, el octeto más significativo primero.

INTEGER

Valor sin firmar de 32 bit, el octeto más significativo primero.

TIME

Valor sin firmar de 32 bit, el octeto más significativo primero. Los atributos estándar no usan este tipo de datos pero esta presentado aquí para un posible uso en el futuro.

Tipos de paquetes

Aunque los protocolos como RADIUS sean incapaces de protegerse contra el robo de una sesión autenticada vía ataques de intervención de las conexiones en tiempo real, la generacion de peticiones unicas e impredecibles pueden proteger contra una amplia gama de ataques activos contra la autenticación.

El valor del campo de tipo “access-acept”, “access-reject” y “access-challenge” son llamados autenticadores de respuesta y contienen un valor encriptado en

MD5.

Describire los tipos de paquetes mas importantes:

Tipos de paquetes:

Peticion de acceso(access-request)

Las peticiones de acceso son enviadas al servidor RADIUS y transportan la informacion determinada por el NAS especifico indicando si tienee acceso o si desea cualquier otro servicio especial para el usuario. En la practica, se debe transmitir el paquete con el valor 1 en el campo de autenticacion, que define el paquete como una peticion de acceso.

Al recibir la peticion de acceso de un cliente valido, el servidor respondera con otro paquete indicando si se le esta permitido el acceso.

Una peticion de acceso debe contener el nombre de usuario, el atributo de la direccion IP NAS o el atributo de identificador NAS, la contraseña de usuario encriptada, la direccion del puerto NAS y opcionalmente otros atributos especiales.

Tipos de paquetes:

Acceso permitido (access-accept)

Estos paquetes son enviados por el servidor RADIUS, y contienen informacion especifica sobre la ocnfiguracion para ofrecer servicios al usuario. Si todos los valores de atributo recibidos en una peticion de acceso son aceptados, RADIUS debe transmitir un paquete con el campo de codigo puesto a 2.

A la hora de recibirlo, el campo identificador es emparejado con la petición de acceso pendiente. El campo de respuesta de autenticador contiene la respuesta correcta para el paquete pendiente de “access-request”.

Tipos de paquetes:

Acceso denegado(Access-Reject)

Si alguno de los atribuos recibidos no son aceptables, el servidor enviara el paquete con el codigo 3. Puede incluir algun mensaje de respuesta para que el NAS lo muestre al usuario.

enviara el paquete con el codigo 3. Puede incluir algun mensaje de respuesta para que el

Tipos de paquetes:

Prueba de acceso(Access-Challenge)

Si el servidor lo desea puede enviar al usuario un especie de desafio que el usuario debe responder de forma correcta. Los campos de atributos deben tener 1 o mas atributos de este tipo: Reply-Message, Vendor-Specific, Idle-Timeout, Session-Timeout y Proxy-State. Solo los mencionados sirven como atributo en los mensajes de tipo Access-Challenge.

Al recibir el access-challenge el campo identificador esta marcado para una peticion de acceso. Los paquetes que no coincidan con la peticion seran descartados.

Si el NAS lo soporta y recibe un access-challenge valido, se enviara el access request. El NAS mostrara el mensja de texto al usuario y el prompt para que pueda responder. Enviara un mensaje con un nuevo ID, con la contraseña encriptada en el atributo user-password e incluyendo el estado de access- challenge.

Tipos de paquetes:

Respuesta al desafio(Challenge response)

En una autenticacion de este tipo al usuario se le ofrece un numero impredecible y desafia al usuario a encriptarlo y devolverle el resultado. Los usuarios autorizados utilizan unos dispositivos especiales como pequeñas tarjetas o programas que le permiten facilitar el calculo de la respuesta.

unos dispositivos especiales como pequeñas tarjetas o programas que le permiten facilitar el calculo de la

Tipos de paquetes:

Respuesta al desafio(Challenge response)

Los usuarios que no tengan permiso para estas medidas solo podrán hacer conjeturas.

Los paquetes contienen normalmente un mensaje de respuesta incluyendo el desafio para ser mostrado al usuario el cual contiene el numero para encriptar y que no volvera a ser repetido nunca mas. Normalmente se obtiene de un servidor externo que conoce que tipo de autentificador tienen los usuarios autorizados y puede aleatoriamente elegir uno de estos codigos.

El usuario introduce el dispositivo, calcula la respuesta que necesita para el usuario en cuestion y se envia al servidor RADIUS.

Tipos de paquetes:

Peticion de registro (Accounting-Request)

Los paquetes de peticion de registro son enviados del cliente (normalmente al NAS o a un proxy) al servidor RADIUS de registro proporciona informacion usada para que le pueda proveer registro. El cliente transmite un paquete RADIUS con el campo de codigo con el numero 4(Accounting-request).

Una vez recibido la peticion el servidor transmite un Accounting.response, respondiendo si a conseguido recoger la peticion de registro .

Cualquier atributo valido en un paquete de peticion de acceso o aceptacion es valido en un paquete de RADIUS de registro, excepto los siguientes que deben estar obligatoriamente: User-Password, CHAP-Password, Reply-Message, State. NAS-IP-Address y NAS-Identifier.

Tipos de paquetes:

Respuesta de registro (Accounting-Response)

Los paquetes de respuesta de registro son enviados por el servidor RADIUS de registro al cliente para responder a la peticion de registro que fue recibida y guardada satisfactoriamente.

Si la petcion de registro fue guardada, el servidor de registro deberá enviar el paquete con el campo de codigo puesto a 5. Al recibir este paquete, el campo de identificador queda marcado con el identificador del paquete de peticion.

El cliente comparara los identificadores de la peticion y respuesta, y si no coincide se descartara la respuesta.

FUNCIONAMIENTO:

Autorizacion y Autenticacion

Cuando un cliente tiene configurado RADIUS, cualquier usuario debe presentar informacion de autenticacion. Esta puede ser mediante un prompt personalizado donde el usuario introduce su nombre de login y la contraseña. Tambien puede usar como alternativa el uso de otro protocolo como el point-to-point (PPP) donde la autenticacion viene incorporada en los paquetes que contienen la informacion.

Una vez hecho esto si el cliente desea conectarse usando RADIUS deberá crear una peticion de acceso. Esta peticion debe contener atributos como el nombre de usuario, la contraseña y Port ID del cliente.La contaseña queda oculta en los paquetes usando el sistema RSA MD5.

La peticion de acceso se envia al servidor RADIUS por la red. Si no le llega respuesta tras un periodo de tiempo la peticion se reenvia cierto numero de veces, el cliente puede elegir un servidor alternativo.

FUNCIONAMIENTO:

Autorizacion y Autenticacion

Una vez que el servidor RADIUS recibe la peticion, este valida al cliente emisor. Si el servidor RADIUS recibio una peticion en la que no haya ninguna información secreta (como la contraseña), la peticion sera descartada.

Si el cliente es válido, el servidor RADIUS consulta la base de datos de usuarios para encontrar el usuario cuyo nombre se encuentra en la petición. La entrada de usuario de la base de datos contiene una lista de requerimientos que se necesita para ofrecerle acceso. Aquí se incluye la verificacion por contraseña, pero ademas puede especificarse el cliente y el puerto con el que el usario tiene permitido conectarse.

El servidor RADIUS puede hacer peticiones a otros servidores para comprobar la autenticidad, en cuyo caso ésta actua como cliente.

Si presenta alguna informacion de proxy en la peticion de acceso, debe incluirse en el paquete el uso del proxy. Otro tipo de atributos pueden estar incorporados antes o despues de los atributos de proxy.

FUNCIONAMIENTO:

Autorizacion y Autenticacion

Si cualquiera de la informacion fuera incorrecta el servidor RADIUS envia un “Acces-Reject” rechazando la peticion e indicando que la peticion es invalida. Si se desea el servidor puede ademas incluir un mensaje de texto en el paquete de rechazo para que le aparezca al cliente.

Si se cumplen todas las condiciones el servidor puede enviar antes de la admision una respuesta “Access-Challenge”. Esta incluira un mensaje de texto al usuario para que responda al desafio. Se entrara en detalles de este tipo de respuesta luego.

Si el cliente recibe una respuesta de desafio y soporta la recepcion de este tipo de paquetes, el mensaje de texto saltara y el cliente debera reenviar un nuevo paquete de peticion de acceso de estado “Access-Challenge”, con un nuevo identificador de peticion y donde la respuesta al desafio denuevo sera la contraseña encriptada. El servidor puede responder a esta peticion con otro rechazo, otro desafio o finalmente con una respuesta de acceso permitido.

FUNCIONAMIENTO:

Autorizacion y Autenticacion

Si todas las condiciones anteriores se cumplen en la lista de configuracion de valores del servidor para dicho usuario tendra el valor de “Acces-Accept”. Estos

valores incluyen ademas el tipo de servicio (PPP, SLIP, login de usuario

todos los valores correspondientes al servicio utilizado. Para SLIP y PPP se

incluyen ademas datos de la direccion IP, mascara de subred, MTU, compresion elegida y el filtrado de paquetes.

) y

PPP se incluyen ademas datos de la direccion IP, mascara de subred, MTU, compresion elegida y

FUNCIONAMIENTO:

Registro

Cuando el cliente esta configurado para el uso de “RADIUS Accounting”(registro) al principio generara un paquete de registro al servidor RADIUS de registro remoto, describiendo el tipo y servicio anunciando el servicio que quiere obtener y el usuario del cual procede.

Si llega al servidor éste mandara una confirmacion de que ha recibido el paquete. Para detener el servicio el cliente manda un “Accounting stop” para detener el servicio. Igualmente si llega al servidor, éste lo confirmara.

La peticion de registro(Accounting-Request) es enviado al servidor de RADIUS de registro a traves de la red. Es recomendable que el cliente continue enviando peticiones hasta que rebia la confirmacion. Si no le llega respuesta durante un periodo de tiempo, la peticion se volvera a enviar un numero limitado de veces. El cliente puede tanbien enviar peticiones a un servidor alternativo como en el caso de servidores de autorizacion y autenticacion. Un servidor alternativo puede ser usado despues de cierta cantidad de intentos desde que el primer servidor falla.

El servidor RADIUS de registro puede hacer peticiones de otros servidores de manera que pueda confirmar la peticion, en cuyo caso actuara de cliente.

PROXY RADIUS

Con un proxy RADIUS un servidor RADIUS recibe una peticion de autenticacion (o de registro) del cliente, la reenvia al servidor RADIUS remoto, recibe la respuesta del servidor y la devuelve al cliente. Asi pues lo que hace es redirigirla a otros servidores RADIUS de niveles superiores en funcion de una directiva definida.

Es muy utilizado por las ISPs.

De este modo sera posible autenticar clientes en distintos servidores radius que pertenezcan a dominios diferentes, en función de criterios como el dominio de inicio de sesión.

En este caso cuando un cliente quiere conectar con el servidor RADIUS envia su peticion al servidor de proxy, que se encargara de enviarlo al servidor RADIUS remoto. Cuando le llega al servidor RADIUS este envia la respuesta que sea al servidor proxy que se encargara de que le llege al cliente.

PROXY RADIUS

Un servidor RADIUS puede actuar como servidor remoto sobre unos dominios y de proxy para otros. Los servidores de proxy pueden ademas comuncarse entre si para crear una cadena de proxies.

En los paquetes que envian los servidores proxy con RADIUS se debe incluir siempre el atributo del “estado-proxy”. Si un servidor proxy omite este atributo sobre una peticion de acceso, tendra que adjuntarlo antes de ser enviado al cliente.

PROXY RADIUS

PROXY RADIUS

IMPLEMENTACIONES:

Servidores

Existe un gran número de servidores RADIUS principalmente para entornos UNIX, cada uno de ellos comparte muchas características similares aunque cada servidor busca explotar factores tecnológicos que le den la ventaja sobre los demás. Hay servidores comerciales como también los hay con licencia libre, siendo FreeRADIUS , Criston y Radiador los servidores más populares. Se detallara mas sobre FreeRadius antes de la practica, ya que es la implementacion que usaremos.

Los servidores que se verán a continuación son: Cistron, ICRadius, XtRADIUS, OpenRADIUS, YARD RADIUS, J Radius, Radiador, AXL RADIUS, Oyssey , Cisco Access Registrar.

Servidores de licencia libre:

Cistron

Es un servidor de autentificación y manejo de cuentas para servidores de terminal por medio del protocolo RADIUS, este se ha convertido en uno de los servidores más usados por la comunidad de software libre. Fue escrito por Miguel Van Smooreburg. Entre sus características más importantes están:

•Es libre (bajo la licencia GNU GPL). •Soporta el acceso basado en huntgropus.

•El archivo de usuarios se procesa en orden, es posible múltiples entradas por

defecto, y todas las entradas pueden

•Atrapa todos los archivos de configuración en memoria, incluyendo los archivos de usuarios. •Mantiene una lista de entrada de usuarios. •Se registra tanto en el formato de archivos “wtmp” como en los archivos detallados de registro RADIUS. •Soporta el uso simultáneo de parámetros X. •Soporta atributos especificados del vendedor, incluyendo los no estandarizados

USRs. •Soporta proxing. •Soporta el paquete “alive” •Puede replicar datos de uso de cuentas entre servidores.

ser opcionalmente "fall throught"

Servidores de licencia libre:

ICRadius

ICRadius usa bases de datos de MySQL para guardar toda la información necesaria como archivos de usuarios, archivos de directorios, y también envía información a la base de datos. Esto, en una forma alterna, permite la manipulación y extracción de datos de una manera rápida y eficiente, con la facilidad y flexibilidad ofrecida por MySql. ICRadius es completamente gratis bajo la licencia GPL. Este sistema usa un formato tabular lo cual facilita el uso de bases de datos

Servidores de licencia libre:

XtRADIUS

La diferencia más importante entre XTRadius y otros servidores RADIUS, es que permite ejecutar scripts que pueden ser modificados completamente para manejar autentificación y uso de cuentas. El beneficio que da esta característica, es que en lugar de usar el mismo archivo de usuarios RADIUS, o el sistema de archivo de contraseña para la autenticación, se puede llamar a una aplicación de scripts para preguntar a cualquier fuente (tal como una base de datos SQL), y revisar las condiciones válidas antes de permitir la entrada del usuario. A diferencia de otras soluciones, no requiere parche.

Este servidor esta basado en el servidor Radius Cistron por lo cual incluye todas sus características, como también otras mejoras. La comunicación entre el servidor XtRadius y los scripts externos se da usando parámetros de línea de comando o por variables de ambiente .

Servidores de licencia libre:

OpenRADIUS

OpenRADIUS es un servidor del RADIUS que funciona en muchos entornos Unix, y tiene varias características interesantes:

• La capacidad de conseguir secretos compartidos, información de autenticación,

políticas y perfiles de usuario de cualquier fuente de datos externa disponible. • Soporte para las bases de datos de contraseña en Unix, incluye NIS/NIS+, archivos de ASCII del estilo Livingston, directorios de LDAP y bases de datos de SQL.

• Esquemas de autentificación y políticas de seguridad completamente modificables, usando un lenguaje de reglas para negocios incorporado. Esto permite que se

especifique cómo el servidor toma sus decisiones, basado en cualquier combinación información interna y externa disponible.

• Módulo de interfaz simple, escalable y completamente documentada. Los módulos

pueden proveer datos tales como información del usuario, y pueden también almacenar datos tales como registro y uso de cuentas.

• Diccionario extremadamente flexible que puede usarse para apoyar cualquier tipo de

atributo no estándar o específico del vendedor, incluye múltiples atributos adentro del mismo VSA, atributos no estándar, IDs o archivos de tamaño, subarchivos,

y mucho más.

• Enlaces de tarjetas únicas o múltiples por direcciones IP, y capacidad de escuchar

múltiples puertos.

• Libre de usar, modificar, y redistribuir bajo los términos de la licencia pública general GNU.

Servidores de licencia libre:

YARD RADIUS

Otro servidor RADIUS para la autorización y manejo de cuentas basado en el RFC RADIUS que fue derivado del servidor original RADIUS 2.1 de la empresas Livingston . Entre las características útiles añadidas al esquema de Livingston están:

• Estado Del Desarrollo: 4 - Beta, 5 – Producción/estable. • Para ad ministradores de sistema, y la industria de las telecomunicaciones. •Licencia BSD. •Múltiples entornos operativos (BSD, Mac, Linux, Unix.). •Lenguaje de programación C. •Autenticación de directorios en la red. •Idioma Inglés. •Sin interface.

Servidores de licencia libre:

JRadius

Radius es un Cliente y Servidor RADIUS de licencia abierta. Este no es una aplicación independiente sino un módulo que soporta el lenguaje Java para FreeRadius. JRadius está licenciado bajo la combinación de la libreria GNU, y la licencia para público en general GPL, además esta certificado por la iniciativa OSI de software abierto . JRadius esta siendo desarrollado en base a las siguientes metas:

•Utilizar todas las características de los servidores RADIUS existentes. •Separación y portabilidad de la lógica de los negocios para remarcar en el servidor RADIUS. •Capitaliza la vasta cantidad de software abierto y otras fuentes existentes de java. •Despliegue de una nueva lógica sin tener que recomenzar el núcleo de servicios RADIUS. •Integración con otros sistemas y protocolos de autenticación.

Servidores comerciales:

Radiator

Radiador es un altamente configurable y flexible servidor RADIUS el cual soporta autenticación para cerca de 60 diferentes tipos de métodos de autenticación tales como archivos planos , archivos DBM, archivos de contraseña Unix, bases de datos SQL, servidores RADIUS remotos (proxying), programas externos, utilidades de administración de usuarios NT, directorios activos, LDAP, PAM, iPASS, Go Remote, NIS+, Tacas+, Web URL, Vasco Digipass, un amplio rango de paquetes ISP tales como Esmerald, Platypus , Rodopi, Hawk-i, etc, la base heredada de datos de usarios etc, etc. Entre sus características más importantes tenemos:

•Soporta RadSEC – seguridad confiable del proxying RADIUS. •Radiator ahora soporta mas métodos de autenticación 802.1X que cualquier otro servidor RADIUS dando una amplia gama para escoger clientes de red 802.1X •Incluye certificados privados para clientes y servidores para probar la autenticación

802.1X.

• Radiador incluye características que no pueden ser encontradas en ningún otro servidor como prevención de acceso doble, reescritura del nombre de usuario, atributos específicos del vendedor, bloqueo en algún tiempo del día, e interfase grafica de usuario para pruebas. • Incluye CGI’s para configuración, reportes, y utilidades de administración de bases de datos y mucho, mucho mas. •Trabaja con la mayoría de NASs, VDPN, ADSL y puntos de acceso inalámbrico. •Incluye todo el código fuente. •Radiador puede ser comprado para ser usado en un solo servidor , o como parte de alguno de los paquetes ofrecidos , para la empresa, para los profesionales , para la casa, etc. •Trabaja en la mayoría de las plataformas. Unix, Linux, Windows, Mac, VMS.

Servidores comerciales:

Servidor AXL RADIUS

AXL es un servidor RADIUS completo que puede autenticar, manejar cuentas, y Proxy. La interfase del programa permite al usuario usar métodos de autenticación y de uso de cuentas mediante cualquier método por el que Java puede acceder al mundo, bases de datos, LDAP, archivos planos, URL’s. AXL no es un servidor que regresa llaves. Este es una interfase de programa al servidor RADIUS. AXL puede realizar todas las funciones de un servidor RADIUS pero no puede configurarse por si mismo usando archivos o bases de datos, no tiene conocimiento de quien se puede conectar, y no tienen control sobre asuntos de políticas.

Se debe proporcionar la programación para leer archivos de configuración o bases de datos para poblar las tablas del cliente, y configurar el servidor por si mismo (como puertos, direcciones, y nombre del servidor). El servidor tiene métodos para aceptar esta información. Se debe proporcionar código para manejar la autenticación, sus políticas, y uso de cuentas. Existen métodos para realizar estos mecanismos: PAP, CHAP, MS-CHAP, LEAP. etc., pero se debe escribir un código para implementar las políticas del método de autenticación a usar y especificar los atributos a regresar.

Algunas características adicionales:

Servidores comerciales:

Servidor AXL RADIUS(2)

• Incluye integración con el cliente RADIUS •Se pueden empezar secuencias separadas de manejo de cuentas y autenticación. •Soporte para atributos de Vendedores Específicos. •Soporte completo para Proxy Proxy dinámico: se puede enrutar cualquier paquete en cualquier parte basándose en una política o en paquetes de atributos del RADIUS. •Construido con los métodos de autenticación PAP, CHAP, MSCHAP, MSCHAPV2, EAP-MD5, y LEAP. •Detección rápida de duplicidad de paquetes •Soporte para mensajes EAP y mensajes de autenticación. • Se puede establecer el tamaño de los paquetes dinámicamente. •Tipos de mensajes extendidos. • No es vulnerable a problemas de seguridad de sobrecarga del búfer (problemas que tienen los escritos en C/C++). •SNMP es soportado. SNMP V2 puede ser habilitad o deshabilitado. •Obedece los RFC’s 2865 (Autenticación) y 2866 (Manejo de cuentas) y otros RFC’s relacionados con RADIUS. •Trabaja con cualquier base de datos que tenga el controlador JDBC. •El código fuente está muy bien documentado

Servidores comerciales:

Servidor Odyssey

El servidor Odessey es un servidor RADIUS especialmente diseñado para manejar control de acceso y seguridad WLAN. Es una solución de seguridad WLAN completa para pequeñas empresas, y es adicionalmente perfecta para la distribución en sucursales, departamentos autónomos y sitios remotos de grandes organizaciones. En esta última opción el

servidor se comunica con la central de copiado de Funk Software’s Steel-Belted RADIUS o con otro servidor compatible RADIUS para WLAN y administración de políticas de acceso 802.1X

.

Con odyssey los administradores de red pueden:

•Establecer políticas de acceso basadas en usuarios, para incrementar la seguridad del control de acceso. •Acceder a registros de cuentas localmente, o mandarlas a la central del servidor de cuentas, para proveer aun registro comprensible de los accesos de red WLAN. •Explicación exacta para los usuarios de cuentas que se quieren conectar vía EAP- TTLS, aun si ellos quieren tomar ventaja de la habilidad para ocultar su identidad. •Autenticación de usuarios que se están conectando vía PEAP.

Servidores comerciales:

Cisco Access Registrar

Cisco CNS Access Registrar es un servidor RADIUS diseñado para soportar el envió de llamadas, ISDN, y nuevos servicios incluyendo DSL, cable con telco-return, red inalámbrica y voz sobre IP. El servidor fue diseñado de la nada hasta reunir las necesidades de las operaciones de los proveedores de servicios. Cisco CNS Access Registrar provee funcionamiento y escalabilidad de clases-portadoras como también la extensibilidad necesaria para la integración de los sistemas de gerencia de desarrollo de servicios. Cisco Access Registrar esta construido en una arquitectura multi-secuencias para tomar ventaja de los sistemas de procesadores múltiples y proveer el más alto funcionamiento AAA . Algunas de sus características más importantes son:

• Puntos extendidos: Los puntos extendidos de Cisco Access Registrar soporta funciones adicionales a la lógica del servidor RADIUS para modificar o realzar funcionalidad extra.

• Integración de directorios: Los directorios sirven como depósito central para la información del

usuario, los perfiles del servicio, los perfiles de mando de cuenta, y otra información de servicio.

Cisco Access Registrar autentica a usuarios contra un directorio de LDAP y proporciona la flexibilidad de trabajar con una variedad de configuraciones de directorios.

• Proxy AAA: Cisco Access Registrar soporta Proxy RADIUS , envés de autorizar o autenticar en base a un

directorio , el servidor selectamente usa Proxy para enviar una petición AAA a otro proveedor de servicios, a otro servidor RADIUS o a un servidor RADIUS que hace de cliente que autentica y autoriza usuarios en base a otros directorios o bases de datos.

• Administración de sesión y direcciones: Cisco Access Registrar proporciona administradores de recursos

que manejan la locación dinámica de direcciones IP o IPX, y refuerza limite de sesiones de grupo y usuarios alrededor de múltiples servidores de acceso de red.

Clientes RADIUS

Son pocas las opciones gratis disponibles, a diferencia de los servidores RADIUS en donde hay muchas opciones gratuitas, existe una tendencia por comercializar las licencias de los clientes, este es el caso de dos de los clientes MDC Aegis y Odyssey , clientes que no hace mucho tiempo se ofrecían gratis, ahora se ofrecen de manera comercial por el gran auge que han tenido las redes inalámbricas y por la necesidad creciente de buscar mecanismos para mantenerlas seguras. Los clientes que se verán son: Xsupplicant, Boingo, Aegis, Oddysey, Monarca, AXL.

Clientes de licencia libre:

Xsupplicant

Es una implementación de licencia libre basado en el protocolo IEEE 802.1x. Esta licencia ofrece soporte como autenticador y cliente. Entre sus características encontramos:

•Dirigido a los desarrolladores, usuarios finales y a administradores de sistemas. •Tiene una licencia BSD GNU Licencia publica general (GPL). •Soporta todos los sistemas operativos POSIX (Linux/BSD/sistemas basados en UNIX). •Esta programado en C.

Clientes de licencia libre:

Boingo

Un cliente de autenticación basado en 802.1x el cual ha ganado varios reconocimientos. Entre sus características más importantes encontramos las siguientes:

•Es gratis. •Es rápido. •Es fácil de usar. •Es más seguro que antes. •Es la mejor forma de administrar todas las conexiones de Internet inalámbricas.

Clientes comerciales:

MDC Aegis

El cliente AEGIS asegura varios dispositivos como computadoras portátiles, computadoras de escritorio, computadoras de bolsillo, por medio de la autenticación basada en 802.1X. MDC Aegis provee soluciones para una amplia gama de sistemas

operativos

computacionales en la empresa .

y métodos EAP para la seguridad de las plataformas

Clientes comerciales:

Odyssey Client

En palabras de sus creadores; seguridad, fácil de administrar, y compatibilidad son características que ofrece este cliente 802.1x. Si se busca construir un acceso WLAN seguro, o se esta migrando a un acceso 802.1x, o ambos, el cliente Oddysey provee seguridad sin igual al precio mas bajo en implementación y soporte [26]. Algunas de las características que ofrece este cliente son:

•Cliente 802.x de triple propósito, permite a los usuarios conectarse a la

red inalámbrica de la empresa, a la red

los aeropuertos, restaurantes, y otros lugares. •Provee una seguridad robusta sobre los enlaces inalámbricos. •Establece y refuerza una política uniforme de seguridad en empresas. •Multi plataforma, y multi vendedor. •Fácil de usar y administrar

ethernet normal, y a la red pública de

Clientes comerciales:

Monaca RADIUS

Monaca entrega una suit de estándares fáciles de usar, confiables y de alto

desempeño

la especifiobre cación RADIUS. El cliente RADIUS de Monaca se comunica a través de la red con un servidor RADIUS, que guarda los nombres de usuario, las contraseñas, y autoriza el acceso al usuario, a sistemas o aplicaciones. Características:

• RFC 2865 (RADIUS), RFC-2866 (Uso de cuentas en RADIUS), RFC-1994 (CHAP) • Zero threaring: sólo se activa cuando es llamado, usa muy pocos recursos del sistema. • Uso completo de código entrante: Una robusta arquitectura evita errores en condiciones demandantes. • Soporte de métodos de autenticación PAP, CHAP, Autenticación Múltiple de Desafío Respuesta. •Avanzadas “api’s” muy bien documentadas •Fácil de instalar y usar. • Seguridad de alto grado para empresas, sin comprometer funcionalidad de los dispositivos •Ciclo de desarrollo rápido: Te permite desarrollar sistemas para substituirlos por los componentes comerciales usados.

basados en soluciones de seguridad “embedded” que incluye

Clientes comerciales:

RADIUS AXL

Ampliamente usado para simplificar el acceso al servidor RADIUS en Java o aplicaciones Java. Este incluye un API (interfase de aplicación para programar) que te ayuda a construir un cliente RADIUS en cualquier programa Java, desde servlets hasta aplicaciones. Algunas Características:

•Soporta los métodos de autenticación PAP, CHAP, MSCHAP, MSCHAPV2, EAP- MD5, LEAP. •Extremadamente flexible en la manipulación de atributos. •Atributos específicos del vendedor soportados. •Atributos de Mensajes de Autenticación soportados. •Soporte de diccionario RADIUS. •Interoperabilidad probada. •Soporta tipos de mensajes extendidos y cualquier tipo de paquete.

Kerberos

Kerberos es un protocolo de seguridad creado por MIT que usa una criptografía de claves simétricas para validar usuarios con los servicios de red, evitando así tener que enviar contraseñas a través de la red. Al validar los usuarios para los servicios de la red por medio de Kerberos, se frustran los intentos de usuarios no autorizados que intentan interceptar contraseñas en la red.

medio de Kerberos, se frustran los intentos de usuarios no autorizados que intentan interceptar contraseñas en

Ventajas de Kerberos

Los servicios de redes más convencionales usan esquemas de autenticación basados en contraseñas. Tales esquemas requieren que cuando un usuario necesita una autenticación en un servidor de red, debe proporcionar un nombre de usuario y una contraseña. Lamentablemente, la información de autenticación para muchos servicios se transmite sin estar encriptada. Para que un esquema de este tipo sea seguro, la red tiene que estar inaccesible a usuarios externos, y todos los usuarios de la red deben ser de confianza.

Aún en este caso, una vez que la red se conecte a la Internet, ya no puede asumir que la red es segura. Cualquier intruso del sistema con acceso a la red y un analizador de paquetes puede interceptar cualquier contraseña enviada de este modo, comprometiendo las cuentas de usuarios y la integridad de toda la infraestructura de seguridad. El primer objetivo de Kerberos es el de eliminar la transmisión a través de la red de información de autenticación. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseñas en su red.

Desventajas de Kerberos

A pesar de que Kerberos elimina una amenaza de seguridad común, puede ser difícil de implementar por una variedad de razones:

La migración de contraseñas de usuarios desde una base de datos de contraseñasestándar UNIX, tal como /etc/passwd o/etc/shadow, a una base de datos de contraseñas Kerberos puede ser tediosa y no hay un mecanismo rápido para realizar esta tarea.

Kerberos presupone que cada usuario es de confianza pero que está utilizando una máquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseñas no encriptadas sean enviadas a través de la red. Sin embargo, si cualquier otro usuario aparte del usuario adecuado, tiene acceso a la máquina que emite tickets usados para la autenticación — llamado Centro de distribución de llaves (KDC) —, el sistema de autenticación de Kerberos completo está en riesgo.

Desventajas de Kerberos

Para que una aplicación use Kerberos, el código debe ser modificado para hacer las llamadas apropiadas a las librerías de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradas kerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programación, debido al tamaño de la aplicación o su diseño. Para otras aplicaciones incompatibles, los cambios se deben realizar en el modo en que el servidor de red y sus clientes se comunican; de nuevo, esto puede suponer bastante programación. En general, las aplicaciones de código cerrado que no tienen soporte de Kerberos son usualmente las más problemáticas.

Si se utiliza Kerberos en la red, hay que recordar que si se transmite cualquier contraseña a un servicio que no usa Kerberos para autenticar, se corre el riesgo de que el paquete pueda ser interceptado. Así, la red no obtendrá ningún beneficio de usar Kerberos. Para asegurar su red con Kerberos, solo debe utilizar las versiones kerberizadas (que funcionen con Kerberos) de todas las aplicaciones cliente/servidor que envien contraseñas sin encriptar o no utilizar ninguna de estas aplicaciones en la red.

Diferencias entre Kerberos y Radius

La diferencia entre los dos radica en que Kerberos esta orientado hacia la autenticación tanto de la estación de trabajo como del usuario usando un Intermediario llamado Key Distribution Center el cual es el encargado de validar las ubicaciones entre el origen y el destino, mientras que radius lo que busca es validar un usuario el cual generalmente se encuentra remotamente conectado con el servidor.

Practica 1- Simple

Practica 1- Simple

Practica 2 – Mas complejo

Configuracion Freeradius

Hacemos “apt-get install freradius” para actualizar el demonio a la version 2.04.La configuración del servidor se hace mediante el fichero “radiusd.conf” del directorio /etc/freeradius/.

Aquí podemos seleccionar aspectos relacionados con el servidor (ficheros de log, parámetros

de uso máximo, usuarios, grupos,

),

bases de datos autilizar para autenticar y autorizar

(ficheros, SQL, LDAP,

“radiusd.conf” se subdivide en varios ficheros mediante la directiva “$INCLUDE”:

),

métodos de AAA, etc

eap.conf: Se utiliza para configurar el tipo de EAP a emplear

clients.conf: Tiene la lista de clientes que están autorizados para usar los servicios de AAA proporcionados.

proxy.conf: Este fichero configura directivas relacionadas con el funcionamiento en modo proxy y la lista de realms.

dictionary: contiene el valor numérico que tiene cada atributo y valor.

users : contiene información sobre la autenticación de suplicantes, de forma que incluso podemos añadir credenciales en forma de usuario y contraseña para permitir una configuración sencilla de usuarios

• Otros ficheros como sql.conf (para configurar el acceso a bases de datos SQL), policy.conf, etc.

Vamos a ver algunas opciones de arranque del servidor: freeradius -s -X & -s : Permite ejecutar el servicio en modo de servidor simple. -X : Permite el depuramiento. &: Correr el proceso en el “background”.

Practica 1- Simple

Primero importante asegurarse de cual es el nombre de nuestro servidor. Para ello hacemos “hostname” y nos devolvera el nombre. Si no aparece nada deberemos establecerle uno. Haciendo “hostname x”, donde x es el nombre que le pondremos a nuestro servidor.

En el fichero /etc/hosts debemos asegurarnos de que la direccion loopback tiene el nombre del servidor.

En la maquina virtual del cliente configuramos este archivo tambien, añadiendo la linea siguiente:

192.168.182.1 servidor

//donde servidor es el nombre de hostname

Practica 1- Simple

Ahora mnodificaremos el fichero de configuracion de clientes en el servidor, para que pueda conectarse:

Añadimos en cualquier parte del fichero lo siguiente:

client 192.168.182.2 { netmask = 32 secret

= uno

}

require_message_authenticator = no

shortname

nastype

= da igual = other

Hay una copia de este fichero de configuracion en el gz

“Ficherosdeconf3”

Practica 1- Simple

Ahora mnodificaremos el fichero de configuracion de usuarios en el servidor, para crear un nuevo usuario.

Añadimos en cualquier parte del fichero lo siguiente:

javi

Cleartext-Password := "password”

Hay una copia de este fichero de configuracion en el gz

“Ficherosdeconf3”

Una vez hecho esto usamos una de las ventanas de consola de servidor para arrancar el demonio de radius.

freeradius -X

Si todo funciona aparecera un mensaje asi:

de consola de servidor para arrancar el demonio de radius. freeradius -X Si todo funciona aparecera

Practica 1- Simple

Ahora solo queda ejecutar el comando en cliente para testear la conexion. En la otra consola de servidor podemos usar un capturador para comprobar que clase de paquetes se intercambian. El comando para ejecutar en modo test tiene la siguiente sintaxis:

radtest [-d raddb_directory] user password radius-server nas-port-number secret [ppphint] [nasname]

En mi caso: radtest javi password servidor 1812 uno

Si os aparece un mensaje como este significara que la peticion a sido enviada y el servidor ha respondido con una aceptacion.

os aparece un mensaje como este significara que la peticion a sido enviada y el servidor

Practica 1- Capturas

Vamos a ver que clase de paquetes se comparten dependiendo de la informacion en la peticion:

Si introducimos de forma correcta todos los parametros:

Si introducimos de forma correcta todos los parametros: Wireshark reconoce los paquetes de Radius. El cliente

Wireshark reconoce los paquetes de Radius. El cliente envia la peticion de acceso con el codigo 1, Access-Request. Si hacemos un UDP stream vemos el nombre de usuario y diferentes caracteres correspondientes a la contraseña. El servidor responde con una aceptacion de la peticion. Access- Accept(2) donde 2 como hemos visto corresponde al codigo de identificacion de este paquete.

Practica 1- Capturas

Ahora hemos cambiado el parametro de contraseña del cliente, y sucede lo siguiente:

parametro de contraseña del cliente, y sucede lo siguiente: El cliente envia la peticion. El servidor

El cliente envia la peticion. El servidor compara los datos con los de sus ficheros de configuracion. Se da cuenta de que el parametro incorrecto no es del usuario sino del cliente. Luego directamente envia una denegacion, ya que todos los parametros deben ser correctos. El mensaje de rechazo tiene el identificador 3 Access-Reject. Este mensaje ademas incorpora un texto de error informando sobre el parametro equivocado.

Vemos ademas que el cliente intenta conectarse por todos los medios, reenviando la peticion.

Practica 2 – Mas complejo

Practica 2 – Mas complejo

Practica 2 – Mas complejo

El laboratorio que incorporo con la diapositiva tiene ya todas las interfaces configuradas. Los sniffer nos permitiran capturar paquetes especiales de radius. Hay dos, uno para ver los paquetes de autentificacion entre Radius y Chilli, y otro sniffer para los paquetes entre cliente y Chilli.

Cuando queramos capturar utilizaremos en el sniffer que queramos el comando:

tshark -v -r sniffer.cap

La opcion -v nos permite ver los detalles de los paquetes, y la opcion -r nos permite mostrar los datos de la captura.

Practica 2 – Mas complejo

Crearemos un servidor Radius conectado a un NAS para que le proporcione autentificacion el cual tendra. Radius proporcionara tambien un servidor Apache2 para configurar la web de inicio usando ssl y a su vez estara conectado a un servidor de Ldap para proporcionarle una base de datos con los usuarios.

Usaremos la implementacion Freeradius. Y la ultima version de netkit:

Version 2.7 del nucleo Version 5.1 del sistema de ficheros de Fedora Version 2.8 del Kernel

Usaremos:

Freeradius: encargado de realizar las funciones AAA (Autenticación, Autorización, Registro).

Chillispot: Para hacer el portal cautivo, proporcionara una interfaz para Freeradius.

Apache2: Para que el usuario pueda acceder y autenticarse con el servicio.

Openldap: Para almacenar la base de datos de los usuarios.

Practica 2 – Mas complejo

La version de Freeradius instalada en netkit es la 1.272 de 2008. La ultima version es la 2.1 que ha solucionado algunos bugs y facilitando la configuracion.

Asi que intentaremos actualizarlo. Hay 2 formas: Mediante tap(conectando la maquina virtual al anfitrion) o montando el sistema de ficheros.

Lo haremos usando tap, aunque puede haber problemas en algunos ordenadores por la aparicion de un bug. Se recomienda actualizar netkit para solucionar estos problemas o aplicar un parche.

Primero actualizaremos la lista de repositorios:

Editad el fichero /etc/resolv.conf para añadirle un servidor DNS, en este caso ponemos:

nameserver “direccionIPanfitrion”

Apt-get update

Es posible que os aparezca un error al no poder verificar la clave publica GPG.

La solucion correcta es crear nuestra clave publica con el comando “gpg –gen-key”. Este pequeño programita generara una clave RSA, pero en netkit ,esto no funciona. Porque nos aparecera un error de este tipo:

"Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 255 more bytes)"

Practica 2 – Mas complejo

Un consejo para solucionar este problema es el que aporta el generador:

"We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy."

Al parecer realizar diferentes acciones durante la generacion nos podria solucionar el problema. Estando en netkit es imposible.

La solucion es la siguiente:

gpg --keyserver subkeys.pgp.net --recv KEY gpg --export --armor KEY | apt-key add -

Donde “KEY” se sustituye por la clave incluida en el error al hacer “apr-get update”. En

concreto la que aparece despues de “

apare un mensaje de conexion abortada, probad a hacer un ping a la direccion “subkeys.pgp.net” y luego repetir la primera linea de los dos comandos. Puede ser que el servidor tenga problemas por saturacion. Si hacemos todo esto solucionaremos los problemas.

NO_PUBKEY”.

Si se queda un rato esperando y

Practica 2 – Mas complejo

NAS

Un Network Access Server (NAS) es un sistema que proporciona acceso a la red. En algunos casos también se conoce como Remote Access Server (RAS) o Terminal Server. Es un elemento que controla el acceso a un recurso protegido, que puede ser desde un sencillo teléfono para VoIP o una impresora, hasta el acceso a una red inalámbrica o a Internet (proporcionado por un ISP).

Es importante no confundir la definición de NAS que hemos dado en este apartado con el NAS como “Network-Attached Storage”, que comunmente se refiere a discos duros conectados directamente a una red. Cuando un cliente quiere hacer uso de uno de estos servicios se conecta a NAS, quien a su vez se conecta a un servidor de AAA (típicamente RADIUS) preguntando si los credenciales proporcionados por el cliente son válidos. Basándose en su respuesta, NAS le permitirá acceder o no a este recurso protegido.

Practica 2 – Mas complejo

NAS

Practica 2 – Mas complejo NAS

Practica 2 – Mas complejo

NAS

El sistema NAS no contiene ninguna información sobre los usuarios que se pueden conectar, sino que utiliza esta información para enviarla a RADIUS, y que éste le informe sobre los permisos del cliente. Si nos centramos en el proceso de AAA, el cliente sería el sistema que proporciona el acceso a la red (por ejemplo NAS), mientras que el servidor es el sistema que autoriza o no dicho acceso (por ejemplo RADIUS), al contrario de lo que se conoce como la tipica estructura Servidor-cliente.

Una ventaja del uso de RADIUS es que sus clientes tan sólo tienen que implementar el protocolo de comunicación con RADIUS, y no todas las posibilidades de AAA existentes (PAP, CHAP, LDAP, kerberos, mySQL, etc.). En el ejemplo del punto de acceso, tan sólo necesitamos implementar una solución NAS que realice las consultas a RADIUS.

Otra ventaja del protocolo RADIUS es que, en su comunicación con NAS, nunca transmite las contraseñas directamente por la red, sino que usa algoritmos para ocultar las contraseñas como MD5. Aunque es aconsejable utilizar sistemas adicionales de protección para cifrar el tráfico de RADIUS, como puede ser Ipsec.

Practica 2 - Portal Cautivo

Un portal cautivo (o captivo) es un programa o máquina de una red informática que vigila el tráfico HTTP y fuerza a los usuarios a pasar por una página especial si quieren navegar por Internet de forma normal. A veces esto se hace para pedir una autenticación válida, o para informar de las condiciones de uso de un servicio wireless (que es donde más se encuentran).

Se usan sobre todo en redes inalámbricas abiertas, donde interesa mostrar un mensaje de bienvenida a los usuarios y para informar de las condiciones del acceso (puertos permitidos, responsabilidad legal, etc.). Los administradores suelen hacerlo para que sean los propios usuarios quienes se responsabilicen de sus acciones, y así evitar problemas mayores. Se discute si esta delegación de responsabilidad es válida legalmente.

de sus acciones, y así evitar problemas mayores. Se discute si esta delegación de responsabilidad es

Practica 2 – Instalacion y configuracion Chillispot

Usaremos Chillispot para crear el portal cautivo. No está en netkit, habra que instalarlo:

En el servidor de chilli hacemos:

wget http://www.chillispot.info/download/chillispot_1.0_i386.deb //para descargar el paquete dpkg -i chillispot_1.0_i386.deb //para instalarlo

Ahora habra que configurarlo, pero todavia no tenemos creado el servidor radius si quiera. El archivo que debe ser editado para configurarlo es /etc/chilli.conf. Este archivo tiene muchos parámetros, pero sólo es necesario editar algunos para obtener una configuración básica.

Hay una copia de este fichero de configuracion en el gz “Ficheros de configuracion”

Radiusserver1 10.0.1.2

Radiusserver2 10.0.1.2 radiussecret unsecreto

dhcpif eth1

uamserver https://10.0.1.2/cgi-bin/hotspotlogin.cgi

uamallowed 192.168.0.0/16,10.0.0.0/16,www.sitiodistinto.net uamsecret ht2eb8ej6s4et3rg1ulp'' // la contraseña que comparte chillispot con la página web para poder encriptar los datos

//la direccion del servidor radius //esto serviria si tenemos un servidor alternativo como hemos visto //esta es la contraseña que comparten radius y chilli para encriptar

//la interfaz para las peticiones dhcp, usaremos ips fijas, no nos hara falta

//la ruta de la web, el mismo del radius

Practica 2 – Instalacion y configuracion Chillispot

Chillispot trae de por si un firewall iptable. Podemos configurar las Iptables directamente o editar el siguiente fichero de configuracion:

/usr/share/doc/chillispot/firewall.iptables

Podemos hacer que arranque las iptables por defecto al iniciar la consola:

cp /usr/share/doc/chillispot/firewall.iptables /etc/init.d/chilli.iptables //para copiarlo al init.d

chmod u+x /etc/init.d/chilli.iptables

ln -s /etc/init.d/chilli.iptables /etc/rcS.d/S40chilli.iptables //crea un link con el siguiente fichero

//le da permisos

Para que se hagan efectivos estos cambios hay que reiniciar:

/etc/init.d/network restart

Para comprobar que funciona podemos ejecutarlo en modo debug:

chilli --fg –debug

Practica 2 – Instalacion y configuracion Chillispot

En el servidor de Radius haremos la instalacion pero no configuraremos el fichero. Solo necesitamos el script:

Hay que copiar el script de login del chilli a la carpeta de apache2 y darle sus permisos:

cp /usr/share/doc/chillispot/hotspotlogin.cgi.gz /usr/lib/cgi-bin/ hotspot sin descomprimir gunzip /usr/lib/cgi-bin/hotspotlogin.cgi.gz //lo descomprimimos

chmod +x /usr/lib/cgi-bin/hotspotlogin.cgi //le damos los permisos

//pasamos el script de

Como el chillispot en el servidor solo lo queríamos para conseguir el cgi, lo podemos desinstalar de nuevo. Aunque no es necesario:

apt-get remove chillispot –purge Tenemos que editar el cgi e incorporar la contraseña que configuramos en el fichero del chilli:

nano /usr/lib/cgi-bin/hotspotlogin.cgi uamsecret = "ht2eb8ej6s4et3rg1ulp";

userpassword=1;

# Clave para hablar con el Web

Practica 2 – Configuracion Freeradius

Ahora vamos a configurar Freeradius. Antes pusimos una contraseña en el fichero de configuracion de Chillispot para que encriptara los paquetes entre chilli y radius. Al freeradius no le hemos dicho nada, configuremos la encriptacion:

nano etc/freeradius/clients.conf

Veremos que hay una parte en llaves donde pone Client localhost, esta configuracion se utilizara como prueba. Mas abajo encontraremos otras zonas entre llaves para clientes con Ipv6. El cliente que buscamos es que pone mas pequeña entre llaves donde pone some.host.org. Lo sustituiremos por la direccion de nuestro servidor chilli, la 192.168.1.1. En la linea donde pone “secret = testing123” es donde ponemos la contraseña que comparten estos 2 servidores, en nuestro caso unsecreto en un servidor serio utilizariamos una contraseña mas complicada. El shortname no es necesario, es solo para darle un nombre al servidor.

Este tipo de configuracion se hace con cada cliente que metamos, chilli pues actua de cliente.

Como prueba vamos a meter un usuario :

Practica 2 – Configuracion

Apache2

Apache2 ya esta instalado en netkit, tenemos que instalar el portal cautivo a ser posible con seguridad ssl.

Hay que configurar el Apache para que ejecute el portal del Chillispot. Es necesario crear un archivo en la carpeta /etc/apache2/sites-available, que contiene la información del sitio. El nombre de este archivo es unico para identificar el sitio. La configuración básica podria ser algo asi:

<VirtualHost> ServerName login

DocumentRoot /prueba //la ruta donde estan los archivos del sitio

ErrorLog /var/log/apache2/error.log

CustomLog /var/log/apache2/access.log combined ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory /usr/lib/cgi-bin/>

Options +ExecCGI

AddHandler cgi-script cgi pl </Directory>

SSLEngine on

SSLCertificateFile /etc/apache2/ssl/apache.pem </VirtualHost>

//la direccion que utilizara para acceder al sitio

//log

//log

//el directorio del script

//para que pueda ejecutar los cgi

Hay una copia de este fichero de configuracion en el gz “Ficheros de configuracion”

//para habilitar el ssl

//la ruta donde estara el certificado

Practica 2 – Configuracion

Apache2

El fichero ports.conf apache escuchara por defecto por el puerto 80. Como usamos https tendremos que cambiarlo para que acepte paquetes por el puerto https (443).

nano /etc/apache2/ports.conf,

Nos aseguramos de que contenga la linea Listen 443. De esta forma podra escuchar tambien por el puerto de ssl.

Ahora crearemos los certificados ssl:

Primero copiaremos el certificado por defecto a la carpeta de sslt. cp /etc/apache2/site-available/default-ssl /etc/apache2/site-available/hotspot_ssl Creamos el certificado y lo guardamos con ese nombre, que es el que utilizamos en los otros ficheros de coniguracion. make -ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

Asi lo creamos y lo guardaremos en la carpeta ssl con el nombre apache. Para habilitar el modulo ssl tenemos que usar el siguiente comando: “a2enmod ssl

Para alguna duda consultar la exposicion sobre Https de Daniel.

Practica 2 – Configuracion Openldap

El schema de Freeradius tenemos que pasarselo al servidor Openldap. Se supone que este fichero debe de estar en /etc/freeradius/modules, al no ser la ultima version este modulo no esta.

Adjunto con la practica este fichero, que se pasara por /hosthome/ al siguiente directorio:

/usr/local/etc/openldap/schema/radius.schema

En el fichero de configuracion slapd.conf añadimos esta linea al principio:

Include /usr/local/etc/openldap/schema/radius.schema

Y Openldap ya estaria listo para funcionar con Freeradius.

Ahora configuramos Freeradius para que pueda conectar con el servidor Ldap.

nano /etc/freeradius/radiusd.conf

Practica 2 – Configuracion Freeradius para soportar Openldap

Hacemos contrl+w para buscar ldap. Y debe de tener una pinta asi, cambiando los parametros dependiendo de la base de datos que usemos:

server = "localhost" identity = "cn=Manager,dc=matthoran,dc=com" password = secret basedn = "dc=matthoran,dc=com" password_attribute = userPassword set_auth_type = no

Hay que asegurarse de que en las secciones de authorize y authenticatio esten descomentadas las lineas desde #ldap El tipo de Autentificacion estara puesto por defecto a System, deberá estar asi:

DEFAULT Auth-Type = LDAP Fall-Through = 1

Para alguna duda sobre como manipular los fcheros de configuracion de Openldap, podemos consultar la exposicion de Rafael.

Practica 3 – Todo en 1

Practica 3 – Todo en 1

Practica 3 – Todo en 1

Usaremos un tunel tap para simular NAT en el router, de esta forma podemos acceder a internet a traves de cualquier maquina.

Para ello hemos introducido en router:

iptables -t nat -A POSTROUTING -j MASQUERADE

Y en router.startup hemos configurado las interfaces entre el router y el anfitrion

Hay que configurar el “/etc/resolv.conf” en las maquinas.

Si vamos a descargarnos algo de los repositorios, antes que nada hacemos “apt-get update”.

Practica 3 – Todo en 1 Instalar Chillispot

Usaremos Chillispot para crear el portal cautivo. No está en netkit, habra que instalarlo.

Hay una copia de este fichero de configuracion en el gz “Ficheros de configuracion”

En servidor hacemos:

dpkg -i chillispot_1.0_i386.deb //para instalarlo

O directamente pasamos el fichero de “/hosthome/” a la maquina virtual y lo instalamos. Si sale el problema de la clave publica:

gpg --keyserver subkeys.pgp.net --recv 9AA38DCD55BE302B gpg --export --armor 9AA38DCD55BE302B | apt-key add -

Y asi no saltara mas el error.

Practica 3 – Todo en 1 Configurar Chilli

Despues de instalar Chilli, configuramos

net 192.168.182.0/24

dynip 192.168.182.0/24

dns1

radiusserver1 127.0.0.1

loopback radiusserver2 127.0.0.1

radiusauthport 1812 radiusacctport 1813

radiussecret testing123

dhcpif eth1 //interfaz conectada a la red inalambrica, al Pc1 uamserver https://192.168.182.1/cgi-bin/hotspotlogin.cgi

uamhomepage http://192.168.182.1:3990/prelogin entran en un sitio no permitido

uamallowed 192.168.182.1,192.168.1.73,www.google.it uamsecret password

uamlisten 192.168.182.1 uamport 3990

Hay una copia de este fichero de configuracion en

“Ficherosdeconf2.tar.gz”

//poned la que corresponda

//como el mismo servidor ofrece el servicio de radius, pondremos la direccion de

//puerto de envio radius //puerto de recepcion

//la pagina donde seran redireccionados los usuarios si

//sitios permitidos

//por donde escuchara peticiones

cp /usr/share/doc/chillispot/hotspotlogin.cgi.gz /usr/lib/cgi-bin

gunzip /usr/lib/cgi-bin/hotspotlogin.cgi

chmod 755 /usr/lib/cgi-bin/hotspotlogin.cgi

//descomprimimos

//copiamos el script

Practica 3 – Todo en 1 Configurar Apache2

Tenemos que poner el nombre del servidor:

hostname “nombre del servidor”

Y en nano “/etc/apache2/apache2.conf” añadir lo siguiente:

ServerName 192.168.182.1

Hay una copia del certificado en

“Ficherosdeconf2.tar.gz”

Para crear el certificado hace falta descargarse, ademas del paquete “make”, los siguientes paquetes:

apt-get install openssl ssl-cert

Esta implementacion libre de ssl nos permite crear certificados.

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

Te preguntara el nombre del servidor. Finalmente creara el certificado.

a2enmod ssl

//para arrancar el modulo

Practica 3 – Todo en 1 Configurar Apache2

Vamos a crear la pagina de inicio tal y como pusimos en el fichero de chilli. Asi que hacemos:

nano -w /etc/apache2/sites-available/prelogin

Y dentro añadimos:

<a href="http://192.168.182.1:3990/prelogin">Click here to login</a> //Enlace al script

Con el siguiente comando redirigiremos todas las peticiones http a la sigiente direccion.

iptables -t nat -I PREROUTING 1 -s 192.168.182.0 -m tcp -p tcp --dport 80 -j DNAT --to 192.168.182.1:3990

Practica 3 – Todo en 1 Configurar Apache2

Ahora crearemos y habilitaremos el sitio ssl. Se puede utilizar el que adjunto en el tar.gz pero solo si va acompañado con el certificado que esta en el mismo sitio.

Para crear uno nuevo:

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/ssl

Tenemos que editar el fichero que acabamos de copiar:

nano /etc/apache2/sites-available/ssl

Hay una copia de este fichero de configuracion en el gz

“Ficherosdeconf2.tar.gz”

Como hay que cambiar muchas cosas este es necesario que copiemos desde /hosthome/

Despues nos metemos en la carpeta y ejecutamos el siguiente comando:

cd /etc/apache2/sites-available/

a2ensite ssl

Hacemos el siguiente comando para reiniciar el demonio:

/etc/init.d/apache 2 reload

Practica 3 – Todo en 1 Configurar Freeradius

nano /etc/freeradius/clients.conf

Tenemos que añadir el cliente chilli:

client 127.0.0.1 {

secret

shortname = localhost

nastype

= testing123

= other

}

Tenemos que añadir un usuario en /etc/freeradius/users.

Hay una copia de este fichero de configuracion en el gz

“Ficherosdeconf2.tar.gz”

En el siguiente fichero hay que descomentar 2 lineas(Este fichero no esta en el paquete comprimido):

nano /usr/lib/cgi-bin/hotspotlogin.cgi

$uamsecret = “password”; $userpassword=password;

Arrancamos el chilli con /etc/init.d/chilli start Arrancamos apache /etc/init.d/apache2 start

Enlaces de interes y documentación

Radius en WLAN

Paquetes Radius Informacion de Microsoft

RFC 2865

"Los protocolos en las redes de ordenadores" Antonio Salavert Casamor "RADIUS / AAA / 802.1x" Yago Fernández Hansen

Curiosidad