R ADIUS

Todo el mundo sabe que KITT no funciona con llaves, para arrancar el coche hace falta autenticacin via RA DIUS . nonr00ts stuf

Javier Lozano S alinas

Indice
Teoria

Practica
3 4 9
S ervidores C lientes K erberos 39 51 58

Introduccion Definicin Uso de UDP

Preinstalacion

66 68 70 73 74 78 80 81

Configuracion de Freeradius Nas Portal Cautivo Configuracion Chillispot Configuracion Apache2 Configuracion Openldap Practica 2 Todo en 1

E nlaces de interes 86

Formato de paquetes Radius 12 Tipo de paquetes Radius Funcionamiento Proxy R adius 22 31 36

Introduccin
En esta prctica vamos a estudiar RADIUS, un protocolo ampliamente empleado para controlar el acceso a servicios en red. Lo primero que vamos a estudiar es la teora asociada a este protocolo, viendo tambin 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 comunicacin. 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.

Definicin - Radius
RADIUS (Remote Authentication Dial-In User Server) es un protocolo que nos permite gestionar la autenticacin, autorizacin 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 mtodo de seguridad en redes inalambricas. RADIUS mejora el estndar de encriptacin WEP, en conjunto con otros mtodos de seguridad como EAP-PEAP. Fue desarrollado por Livingston Enterprises para la serie PortMaster de sus Servidores de Acceso a la Red(NAS), ms 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).

Definicin - 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 autenticacin, autorizacin y registro es ms conocida como AAA, al ser ste su acrnimo de su denominacin inglesa: Authentication, Authorization, and Accounting. Aunque RADIUS es el protocolo para AAA ms extendido en la actualidad, ya existe un nuevo protocolo que podria sustituir al Radius. Es el llamado DIAMETER, y proporciona manejo de errores y comunicacin 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 autenticacin se realiza mediante la presentacin 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 contrasea. Otros tipos ms avanzados de credenciales son los certificados digitales. Existen muchos mtodos que implementan el proceso de la autenticacin y son soportados por Radius: - Autenticacin de sistema (system authentication), tpica en un sistema Unix, normalmente realizada mediante el uso del fichero /etc/passwd. - Los protocolos PAP (Password Authentication Protocol), que son mtodos de autenticacin usados por proveedores de servicios de Internet (ISPs) accesibles va 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 contraseas. - Kerberos, mtodo de autenticacin diseado por el MIT. Hablaremos mas de el mas tarde. - EAP (Extensible Authentication Protocol), que es un entorno de autenticacin empleado en redes inalmbricas y conexiones punto a punto.

Radius - Autorizacin
Se refiere a conceder servicios especficos a un determinado usuario, basndose para ello en su propia autenticacin, los servicios que est solicitando, y el estado actual del sistema. Es posible configurar restricciones a la autorizacin de determinados servicios en funcin de aspectos como, por ejemplo, la hora del da, la localizacin del usuario, o incluso la posibilidad o imposibilidad de realizar mltiples logins de un mismo usuario. El proceso de autorizacin determina la naturaleza del servicio que se concede al usuario, como son: la direccin IP que se le asigna, el tipo de calidad de servicio(QoS) que va a recibir, el uso de encriptacin, o la utilizacin obligatoria de tneles para determinadas conexiones. Los mtodos de autorizacin 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 configuracin 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 cundo 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).

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 provedos 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 ms 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

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

Formato de los paquetes RADIUS: Campo Cdigo

Los campos de codigo ocupan 1 octeto, e identifican el tipo de paquete RADIUS. Los paquetes con un codigo de campo invalido son descartados. Cdigo Tipo de paquete RADIUS (1 byte). Veremos algunos de los codigos mas importantes. Y mas tarde podremos ver los paquetes en formato Wireshark para que sirva de ejemplo. # 1 2 3 4 5 6 7 8 9 10 11 Message Access-Request Access-Accept Access-Reject Accounting-Request Accounting-Response Accounting-Status(registro) Password-Request Password-Ack Password-Reject Accounting-Message Access-Challenge Reference [RFC2865] [RFC2865] [RFC2865] [RFC2865] [RFC2865] [RFC2882] [RFC2882] [RFC2882] [RFC2882] [RFC2882] [RFC2865]

Formato de los paquetes RADIUS:

Campos Identificador y Longitud

El campo identificador esta compuesto por un octeto, y es aadido 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 contrasea que comparten entre servidor y cliente). Aunque los protocolos como RADIUS sean incapaces de protegerse contra el robo de una sesin autenticada va ataques de intervencin de las conexiones en tiempo real, lla generacion de peticiones unicas e impredecibles pueden proteger contra una amplia gama de ataques activos contra la autenticacin. 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 1 2 012345678901234567890 -------------------------------------------------------| 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 User-Name User-Password CHAP-Password NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Login-IP-Host Login-Service Login-TCP-Port (unassigned) Reply-Message Callback-Number Callback-Id 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 (unassigned) Framed-Route Framed-IPX-Network State Class Vendor-Specific Session-Timeout Idle-Timeout Termination-Action Called-Station-Id Calling-Station-Id NAS-Identifier Proxy-State Login-LAT-Service Login-LAT-Node Login-LAT-Group Framed-AppleTalk-Link Framed-AppleTalk-Network Framed-AppleTalk-Zone 40 41 42 43 45 46 47 48 49 50 51 60 61 62 63 Acct-Status-Type Acct-Delay-Time Acct-Input-Octets Acct-Output-Octets Acct-Authentic Acct-Session-Time Acct-Input-Packets Acct-Output-Packets Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count CHAP-Challenge NAS-Port-Type Port-Limit Login-LAT-Port

Campo de Atributos: LONGITUD

E l campo de long itud ocupa un octeto e indica la long itud de los atributos , incluido el tipo, la definicion de la long itud en s i y el campo de valor. S i un atributo es recibido en una peticion de aces o pero con una long itud de atributo invalida, s e trans mitira un acces s -reject por parte del s ervidor. S i es to s ucede en una aceptacion, rechazo o en un mens aje para poner a prueba, el cliente lo des cartara.

Campo de Atributos: VALOR

E l campo de valor contiene informacion es pecifica del atributo y es ta compues to po 0 o mas octetos . El formato y la long itud del campo valor es tan determinados en los campos anteriores de tipo y long itud. Una nota importante es que ning uno de los tipos en R ADIUS terminan con un NULL. Los tipos de texto y s tring en particular no deben terminar con un NULL. E l texto es ta codificado en UTF-8 y el s tring contiene datos binarios de 8bits . E n las implementaciones de R ADIUS us ando C s e recomienda no us ar el s trcpy() cuando us e s tring s . E l formato del campo valor comprende 5 tipos de datos diferentes . E l tipo texto s i lo vemos , es un s ubtipo del s tring .

Campo de Atributos: VALOR

E s ta tabla mues tra los diferentes tipos que pueden incorporars e en es te campo:
De 1 a 253 octetos usando la codificacin UTF-8. El texto con longitud 0 no puede ser enviado. Si fuera as se omite el atributo entero. De 1 a 253 octetos usando datos binarios. Los strings de longitud 0 tampoco pueden ser enviados. Valor de 32 bit, el octeto ms significativo primero.

TEXT

S TR ING

ADDR E S S

INTEGER TIME

Valor sin firmar de 32 bit, el octeto ms significativo primero.

Valor sin firmar de 32 bit, el octeto ms significativo primero. Los atributos estndar 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 sesin autenticada va ataques de intervencin de las conexiones en tiempo real, la generacion de peticiones unicas e impredecibles pueden proteger contra una amplia gama de ataques activos contra la autenticacin. 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 contrasea 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 peticin 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.

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 contrasea encriptada en el atributo user-password e incluyendo el estado de accesschallenge.

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 pequeas tarjetas o programas que le permiten facilitar el calculo de la respuesta.

Tipos de paquetes:
Respuesta al desafio(Challenge response)
Los usuarios que no tengan permiso para estas medidas solo podrn 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.

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.

Tipos de paquetes:

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 contrasea. 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 contrasea y Port ID del cliente.La contasea 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 informacin secreta (como la contrasea), la peticion sera descartada. Si el cliente es vlido, el servidor RADIUS consulta la base de datos de usuarios para encontrar el usuario cuyo nombre se encuentra en la peticin. 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 contrasea, 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 contrasea 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...) y 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.

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 funcin de criterios como el dominio de inicio de sesin. 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

IMPLEMENTACIONES: Servidores

Existe un gran nmero de servidores RADIUS principalmente para entornos UNIX, cada uno de ellos comparte muchas caractersticas similares aunque cada servidor busca explotar factores tecnolgicos que le den la ventaja sobre los dems. Hay servidores comerciales como tambin los hay con licencia libre, siendo FreeRADIUS , Criston y Radiador los servidores ms populares. Se detallara mas sobre FreeRadius antes de la practica, ya que es la implementacion que usaremos. Los servidores que se vern a continuacin son: Cistron, ICRadius, XtRADIUS, OpenRADIUS, YARD RADIUS, J Radius, Radiador, AXL RADIUS, Oyssey , Cisco Acces s R egis trar.

Servidores de licencia libre: Cistron

Es un servidor de autentificacin y manejo de cuentas para servidores de terminal por medio del protocolo RADIUS, este se ha convertido en uno de los servidores ms usados por la comunidad de software libre. Fue escrito por Miguel Van Smooreburg. Entre sus caractersticas ms importantes estn:

Es libre (bajo la licencia GNU GPL). Soporta el acceso basado en huntgropus. El archivo de usuarios se procesa en orden, es posible mltiples entradas por defecto, y todas las entradas pueden ser opcionalmente "fall throught" Atrapa todos los archivos de configuracin 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 simultneo de parmetros 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.

Servidores de licencia libre: ICRadius

ICRadius usa bases de datos de MySQL para guardar toda la informacin necesaria como archivos de usuarios, archivos de directorios, y tambin enva informacin a la base de datos. Esto, en una forma alterna, permite la manipulacin y extraccin de datos de una manera rpida 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 ms importante entre XTRadius y otros servidores RADIUS, es que permite ejecutar scripts que pueden ser modificados completamente para manejar autentificacin y uso de cuentas. El beneficio que da esta caracterstica, es que en lugar de usar el mismo archivo de usuarios RADIUS, o el sistema de archivo de contrasea para la autenticacin, se puede llamar a una aplicacin de scripts para preguntar a cualquier fuente (tal como una base de datos SQL), y revisar las condiciones vlidas 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 caractersticas, como tambin otras mejoras. La comunicacin entre el servidor XtRadius y los scripts externos se da usando parmetros de lnea 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 caractersticas interesantes:
La capacidad de conseguir secretos compartidos, informacin de autenticacin, polticas y perfiles de usuario de cualquier fuente de datos externa disponible. Soporte para las bases de datos de contrasea en Unix, incluye NIS/NIS+, archivos de ASCII del estilo Livingston, directorios de LDAP y bases de datos de SQL. Esquemas de autentificacin y polticas de seguridad completamente modificables, usando un lenguaje de reglas para negocios incorporado. Esto permite que se especifique cmo el servidor toma sus decisiones, basado en cualquier combinacin informacin interna y externa disponible. Mdulo de interfaz simple, escalable y completamente documentada. Los mdulos pueden proveer datos tales como informacin del usuario, y pueden tambin almacenar datos tales como registro y uso de cuentas. Diccionario extremadamente flexible que puede usarse para apoyar cualquier tipo de atributo no estndar o especfico del vendedor, incluye mltiples atributos adentro del mismo VSA, atributos no estndar, IDs o archivos de tamao, subarchivos, y mucho ms. Enlaces de tarjetas nicas o mltiples por direcciones IP, y capacidad de escuchar mltiples puertos. Libre de usar, modificar, y redistribuir bajo los trminos de la licencia pblica general GNU.

Servidores de licencia libre: YARD RADIUS

Otro servidor RADIUS para la autorizacin y manejo de cuentas basado en el RFC RADIUS que fue derivado del servidor original RADIUS 2.1 de la empresas Livingston . Entre las caractersticas tiles aadidas al esquema de Livingston estn:
Estado Del Desarrollo: 4 - Beta, 5 Produccin/estable. Para ad ministradores de sistema, y la industria de las telecomunicaciones. Licencia BSD. Mltiples entornos operativos (BSD, Mac, Linux, Unix.). Lenguaje de programacin C. Autenticacin de directorios en la red. Idioma Ingls. Sin interface.

Servidores de licencia libre: JRadius

Radius es un Cliente y Servidor RADIUS de licencia abierta. Este no es una aplicacin independiente sino un mdulo que soporta el lenguaje Java para FreeRadius. JRadius est licenciado bajo la combinacin de la libreria GNU, y la licencia para pblico en general GPL, adems esta certificado por la iniciativa OSI de software abierto . JRadius esta siendo desarrollado en base a las siguientes metas:
Utilizar todas las caractersticas de los servidores RADIUS existentes. Separacin y portabilidad de la lgica 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 lgica sin tener que recomenzar el ncleo de servicios RADIUS. Integracin con otros sistemas y protocolos de autenticacin.

Servidores comerciales: Radiator

Radiador es un altamente configurable y flexible servidor RADIUS el cual soporta autenticacin para cerca de 60 diferentes tipos de mtodos de autenticacin tales como archivos planos , archivos DBM, archivos de contrasea Unix, bases de datos SQL, servidores RADIUS remotos (proxying), programas externos, utilidades de administracin 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 caractersticas ms importantes tenemos:

Soporta RadSEC seguridad confiable del proxying RADIUS. Radiator ahora soporta mas mtodos de autenticacin 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 autenticacin 802.1X. Radiador incluye caractersticas que no pueden ser encontradas en ningn otro servidor como prevencin de acceso doble, reescritura del nombre de usuario, atributos especficos del vendedor, bloqueo en algn tiempo del da, e interfase grafica de usuario para pruebas. Incluye CGIs para configuracin, reportes, y utilidades de administracin de bases de datos y mucho, mucho mas. Trabaja con la mayora de NASs, VDPN, ADSL y puntos de acceso inalmbrico. Incluye todo el cdigo 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 mayora 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 mtodos de autenticacin y de uso de cuentas mediante cualquier mtodo por el que Java puede acceder al mundo, bases de datos, LDAP, archivos planos, URLs. 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 polticas. Se debe proporcionar la programacin para leer archivos de configuracin 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 mtodos para aceptar esta informacin. Se debe proporcionar cdigo para manejar la autenticacin, sus polticas, y uso de cuentas. Existen mtodos para realizar estos mecanismos: PAP, CHAP, MS-CHAP, LEAP. etc., pero se debe escribir un cdigo para implementar las polticas del mtodo de autenticacin a usar y especificar los atributos a regresar. Algunas caractersticas adicionales:

Servidores comerciales: Servidor AXL RADIUS(2)

Incluye integracin con el cliente RADIUS Se pueden empezar secuencias separadas de manejo de cuentas y autenticacin. Soporte para atributos de Vendedores Especficos. Soporte completo para P roxy P roxy dinmico: se puede enrutar cualquier paquete en cualquier parte basndose en una poltica o en paquetes de atributos del RADIUS. Construido con los mtodos de autenticacin PAP, CHAP, MSCHAP, MSCHAPV2, EAP-MD5, y LEAP. Deteccin rpida de duplicidad de paquetes Soporte para mensajes EAP y mensajes de autenticacin. Se puede establecer el tamao de los paquetes dinmicamente. Tipos de mensajes extendidos. No es vulnerable a problemas de seguridad de sobrecarga del bfer (problemas que tienen los escritos en C/C+ ). + SNMP es soportado. SNMP V2 puede ser habilitad o deshabilitado. Obedece los RFCs 2865 (Autenticacin) y 2866 (Manejo de cuentas) y otros RFCs relacionados con RADIUS. Trabaja con cualquier base de datos que tenga el controlador JDBC. El cdigo fuente est muy bien documentado

Servidores comerciales: Servidor Odyssey

El servidor Odessey es un servidor RADIUS especialmente diseado para manejar control de acceso y seguridad WLAN. Es una solucin de seguridad WLAN completa para pequeas empresas, y es adicionalmente perfecta para la distribucin en sucursales, departamentos autnomos y sitios remotos de grandes organizaciones. En esta ltima opcin el servidor se comunica con la central de copiado de Funk Softwares Steel-Belted RADIUS o con otro servidor compatible RADIUS para WLAN y administracin de polticas de acceso 802.1X . Con odyssey los administradores de red pueden:

Establecer polticas 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. Explicacin exacta para los usuarios de cuentas que se quieren conectar va EAPTTLS, aun si ellos quieren tomar ventaja de la habilidad para ocultar su identidad. Autenticacin de usuarios que se estn conectando va PEAP.

Servidores comerciales: Cisco Access Registrar

Cisco CNS Access Registrar es un servidor RADIUS diseado para soportar el envi de llamadas, ISDN, y nuevos servicios incluyendo DSL, cable con telco-return, red inalmbrica y voz sobre IP. El servidor fue diseado 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 tambin la extensibilidad necesaria para la integracin 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 mltiples y proveer el ms alto funcionamiento AAA . Algunas de sus caractersticas ms importantes son:

Puntos extendidos: Los puntos extendidos de Cisco Acces s R egistrar soporta funciones adicionales a la lgica del servidor RADIUS para modificar o realzar funcionalidad extra. Integracin de directorios: Los directorios sirven como depsito central para la informacin del usuario, los perfiles del servicio, los perfiles de mando de cuenta, y otra informacin de servicio. Cisco Access R egistrar 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 R egistrar soporta Proxy RADIUS , envs de autorizar o autenticar en base a un directorio , el servidor selectamente usa Proxy para enviar una peticin 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. Administracin de sesin y direcciones: Cisco Access R egistrar proporciona administradores de recursos que manejan la locacin dinmica de direcciones IP o IPX, y refuerza limite de sesiones de grupo y usuarios alrededor de mltiples servidores de acceso de red.

C lientes R ADIUS

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 ofrecan gratis, ahora se ofrecen de manera comercial por el gran auge que han tenido las redes inalmbricas y por la necesidad creciente de buscar mecanismos para mantenerlas seguras. Los clientes que se vern son: Xsupplicant, Boingo, Aegis, Oddysey, Monarca, AXL.

Clientes de licencia libre: Xsupplicant

Es una implementacin de licencia libre basado en el protocolo IEEE 802.1x. Esta licencia ofrece soporte como autenticador y cliente. Entre sus caractersticas 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 autenticacin basado en 802.1x el cual ha ganado varios reconocimientos. Entre sus caractersticas ms importantes encontramos las siguientes: Es gratis. Es rpido. Es fcil de usar. Es ms seguro que antes. Es la mejor forma de administrar todas las conexiones de Internet inalmbricas.

Clientes comerciales: MDC Aegis

El cliente AEGIS asegura varios dispositivos como computadoras porttiles, computadoras de escritorio, computadoras de bolsillo, por medio de la autenticacin basada en 802.1X. MDC Aegis provee soluciones para una amplia gama de sistemas operativos y mtodos EAP para la seguridad de las plataformas computacionales en la empresa .

Clientes comerciales: Odyssey Client

En palabras de sus creadores; seguridad, fcil de administrar, y compatibilidad son caractersticas 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 implementacin y soporte [26]. Algunas de las caractersticas que ofrece este cliente son: Cliente 802.x de triple propsito, permite a los usuarios conectarse a la red inalmbrica de la empresa, a la red ethernet normal, y a la red pblica de los aeropuertos, restaurantes, y otros lugares. Provee una seguridad robusta sobre los enlaces inalmbricos. Establece y refuerza una poltica uniforme de seguridad en empresas. Multi plataforma, y multi vendedor. Fcil de usar y administrar

Clientes comerciales:
Monaca RADIUS
Monaca entrega una suit de estndares fciles de usar, confiables y de alto desempeo basados en soluciones de seguridad embedded que incluye la especifiobre cacin RADIUS. El cliente RADIUS de Monaca se comunica a travs de la red con un servidor RADIUS, que guarda los nombres de usuario, las contraseas, y autoriza el acceso al usuario, a sistemas o aplicaciones. Caractersticas:
RFC 2865 (RADIUS), RFC-2866 (Uso de cuentas en RADIUS), RFC-1994 (CHAP) Zero threaring: slo se activa cuando es llamado, usa muy pocos recursos del sistema. Uso completo de cdigo entrante: Una robusta arquitectura evita errores en condiciones demandantes. Soporte de mtodos de autenticacin PAP, CHAP, Autenticacin Mltiple de Desafo Respuesta. Avanzadas apis muy bien documentadas Fcil de instalar y usar. Seguridad de alto grado para empresas, sin comprometer funcionalidad de los dispositivos Ciclo de desarrollo rpido: Te permite desarrollar sistemas para substituirlos por los componentes comerciales usados.

Clientes comerciales: RADIUS AXL

Ampliamente usado para simplificar el acceso al servidor RADIUS en Java o aplicaciones Java. Este incluye un API (interfase de aplicacin para programar) que te ayuda a construir un cliente RADIUS en cualquier programa Java, desde s ervlets hasta aplicaciones. Algunas Caractersticas: Soporta los mtodos de autenticacin PAP, CHAP, MSCHAP, MSCHAPV2, EAPMD5, LEAP. Extremadamente flexible en la manipulacin de atributos. Atributos especficos del vendedor soportados. Atributos de Mensajes de Autenticacin 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 criptografa de claves simtricas para validar usuarios con los servicios de red, evitando as tener que enviar contraseas a travs 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 contraseas en la red.

Ventajas de Kerberos
Los servicios de redes ms convencionales usan esquemas de autenticacin basados en contraseas. Tales esquemas requieren que cuando un usuario necesita una autenticacin en un servidor de red, debe proporcionar un nombre de usuario y una contrasea. Lamentablemente, la informacin de autenticacin 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. An 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 contrasea 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 transmisin a travs de la red de informacin de autenticacin. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseas en su red.

Desventajas de Kerberos
A pesar de que Kerberos elimina una amenaza de seguridad comn, puede ser difcil de implementar por una variedad de razones: La migracin de contraseas de usuarios desde una base de datos de contraseasestndar UNIX, tal como /etc/passwd o/etc/shadow, a una base de datos de contraseas Kerberos puede ser tediosa y no hay un mecanismo rpido para realizar esta tarea.

Kerberos presupone que cada usuario es de confianza pero que est utilizando una mquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseas no encriptadas sean enviadas a travs de la red. Sin embargo, si cualquier otro usuario aparte del usuario adecuado, tiene acceso a la mquina que emite tickets usados para la autenticacin llamadoCentro de distribucin de llaves(KDC) , el sistema de autenticacin de Kerberos completo est en riesgo.

Desventajas de Kerberos
Para que una aplicacin use Kerberos, el cdigo debe ser modificado para hacer las llamadas apropiadas a las libreras de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradaskerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programacin, debido al tamao de la aplicacin o su diseo. 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 programacin. En general, las aplicaciones de cdigo cerrado que no tienen soporte de Kerberos son usualmente las ms problemticas.

Si se utiliza Kerberos en la red, hay que recordar que si se transmite cualquier contrasea 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 ningn beneficio de usar Kerberos. Para asegurar su red con Kerberos, solo debe utilizar las versioneskerberizadas(que funcionen con Kerberos) detodaslas aplicaciones cliente/servidor que envien contraseas sin encriptar o no utilizarningunade estas aplicaciones en la red.

Diferencias entre Kerberos y Radius

La diferencia entre los dos radica en que Kerberos esta orientado hacia la autenticacin tanto de la estacin 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 2 Mas complejo

Configuracion Freeradius
Hacemos apt-get install freradius para actualizar el demonio a la version 2.04.La configuracin del servidor se hace mediante el fichero radiusd.conf del directorio /etc/freeradius/. Aqu podemos seleccionar aspectos relacionados con el servidor (ficheros de log, parmetros de uso mximo, usuarios, grupos, ...), bases de datos autilizar para autenticar y autorizar (ficheros, SQL, LDAP, ...), mtodos de AAA, etc... radiusd.conf se subdivide en varios ficheros mediante la directiva $INCLUDE: eap.conf: Se utiliza para configurar el tipo de EAP a emplear clients .conf: Tiene la lista de clientes que estn 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 numrico que tiene cada atributo y valor. us ers : contiene informacin sobre la autenticacin de suplicantes, de forma que incluso podemos aadir credenciales en forma de usuario y contrasea para permitir una configuracin 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, aadiendo 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: Aadimos en cualquier parte del fichero lo siguiente: client 192.168.182.2 { netmask = 32 secret = uno require_message_authenticator = no shortname = da igual nastype = other }
Hay una copia de es te fichero de config uracion en el g z Ficheros deconf3

Ahora mnodificaremos el fichero de configuracion de usuarios en el servidor, para crear un nuevo usuario. Aadimos en cualquier parte del fichero lo siguiente: javi Cleartext-Password := "password
Hay una copia de es te fichero de config uracion en el g z Ficheros deconf3

Practica 1- Simple

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:

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.

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:

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 contrasea. 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 contrasea del cliente, y sucede lo siguiente:

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

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 (Autenticacin, Autorizacin, 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 aadirle 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 pequeo 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 ...NO_PUBKEY. Si se queda un rato esperando y 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.

Practica 2 Mas complejo

NAS
Un Network Access Server (NAS) es un sistema que proporciona acceso a la red. En algunos casos tambin 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 telfono para VoIP o una impresora, hasta el acceso a una red inalmbrica o a Internet (proporcionado por un ISP). Es importante no confundir la definicin 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 (tpicamente RADIUS) preguntando si los credenciales proporcionados por el cliente son vlidos. Basndose en su respuesta, NAS le permitir acceder o no a este recurso protegido.

Practica 2 Mas complejo

NAS

Practica 2 Mas complejo

NAS
El sistema NAS no contiene ninguna informacin sobre los usuarios que se pueden conectar, sino que utiliza esta informacin para enviarla a RADIUS, y que ste le informe sobre los permisos del cliente. Si nos centramos en el proceso de AAA, el cliente sera 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 slo tienen que implementar el protocolo de comunicacin con RADIUS, y no todas las posibilidades de AAA existentes (PAP, CHAP, LDAP, kerberos, mySQL, etc.). En el ejemplo del punto de acceso, tan slo necesitamos implementar una solucin NAS que realice las consultas a RADIUS. Otra ventaja del protocolo RADIUS es que, en su comunicacin con NAS, nunca transmite las contraseas directamente por la red, sino que usa algoritmos para ocultar las contraseas como MD5. Aunque es aconsejable utilizar sistemas adicionales de proteccin para cifrar el trfico de RADIUS, como puede ser Ipsec.

Practica 2 - Portal Cautivo

Un portal cautivo (o captivo) es un programa o mquina de una red informtica que vigila el trfico HTTP y fuerza a los usuarios a pasar por una pgina especial si quieren navegar por Internet de forma normal. A veces esto se hace para pedir una autenticacin vlida, o para informar de las condiciones de uso de un servicio wireless (que es donde ms se encuentran). Se usan sobre todo en redes inalmbricas 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 delegacin de responsabilidad es vlida legalmente.

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 parmetros, pero slo es necesario editar algunos para obtener una configuracin bsica.
Hay una copia de es te fichero de config uracion en el g z Ficheros de config uracion
Radiusserver1 10.0.1.2 //la direccion del servidor radius Radiusserver2 10.0.1.2 //esto serviria si tenemos un servidor alternativo como hemos visto radiussecret unsecreto //esta es la contrasea que comparten radius y chilli para encriptar dhcpif eth1 //la interfaz para las peticiones dhcp, usaremos ips fijas, no nos hara falta uamserver https://10.0.1.2/cgi-bin/hotspotlogin.cgi //la ruta de la web, el mismo del radius uamallowed 192.168.0.0/16,10.0.0.0/16,www.sitiodistinto.net uamsecret ht2eb8ej6s4et3rg1ulp'' // la contrasea que comparte chillispot con la pgina web para poder encriptar los datos

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 //le da permisos ln -s /etc/init.d/chilli.iptables /etc/rcS.d/S40chilli.iptables //crea un link con el siguiente fichero 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/ //pasamos el script de 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 Como el chillispot en el servidor solo lo queramos 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 contrasea 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 contrasea 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 pequea 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 contrasea que comparten estos 2 servidores, en nuestro caso unsecreto en un servidor serio utilizariamos una contrasea 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 : nano /etc/freeradius/users

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 informacin del sitio. El nombre de este archivo es unico para identificar el sitio. La configuracin bsica podria ser algo asi: <VirtualHost> ServerName login //la direccion que utilizara para acceder al sitio DocumentRoot /prueba //la ruta donde estan los archivos del sitio ErrorLog /var/log/apache2/error.log //log Hay una copia de es te fichero de CustomLog /var/log/apache2/access.log combined //log config uracion en el g z Ficheros ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ de config uracion <Directory /usr/lib/cgi-bin/> //el directorio del script Options +ExecCGI //para que pueda ejecutar los cgi AddHandler cgi-script cgi pl </Directory> SSLEngine on //para habilitar el ssl SSLCertificateFile /etc/apache2/ssl/apache.pem //la ruta donde estara el certificado </VirtualHost>

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 aadimos 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
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

Hay una copia de es te fichero de config uracion en el g z Ficheros de config uracion

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

En servidor 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 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 Hay una copia de es te fichero de dns1 //poned la que corresponda config uracion en radiusserver1 127.0.0.1 //como el mismo servidor ofrece el servicio de radius, pondremos la direccion de Ficheros deconf2.tar.g z loopback radiusserver2 127.0.0.1 radiusauthport 1812 //puerto de envio radius radiusacctport 1813 //puerto de recepcion 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 //la pagina donde seran redireccionados los usuarios si entran en un sitio no permitido uamallowed 192.168.182.1,192.168.1.73,www.google.it //sitios permitidos uamsecret password uamlisten 192.168.182.1 //por donde escuchara peticiones uamport 3990 cp /usr/share/doc/chillispot/hotspotlogin.cgi.gz /usr/lib/cgi-bin //copiamos el script gunzip /usr/lib/cgi-bin/hotspotlogin.cgi //descomprimimos chmod 755 /usr/lib/cgi-bin/hotspotlogin.cgi

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 aadir lo siguiente: ServerName 192.168.182.1

Hay una copia del certificado en Ficheros deconf2.tar.g z

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 aadimos: <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 acompaado 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 es te fichero de config uracion en el g z Ficheros deconf2.tar.g z

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 aadir el cliente chilli: client 127.0.0.1 { secret = testing123 shortname = localhost nastype = other } Tenemos que aadir un usuario en /etc/freeradius/users. 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

Hay una copia de es te fichero de config uracion en el g z Ficheros deconf2.tar.g z

Enlaces de interes y documentacin

http://www.wi-fiplanet.com/tutorials/article.php/10724_3114511_2 Radius en WLAN http://www.interlinknetworks.com/features.htm Especificaciones http://www.untruth.org/~josh/security/radius/radius-auth.html Paquetes Radius http://technet.microsoft.com/es-es/library/cc781821(WS.10).aspx Informacion de Microsoft http://www.ietf.org/rfc/rfc2866.txt RFC 2865 http://www.faqs.org/rfcs/rfc2866.html RFC2866 "Los protocolos en las redes de ordenadores" Antonio Salavert Casamor "RADIUS / AAA / 802.1x" Yago Fernndez Hansen

Curiosidad http://nonroot.blogspot.com/2009/08/how-to-pass-wargame-cp-2009-networking.html