ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN

Transcripción

1 ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN Titulación : INGENIERO DE TELECOMUNICACIÓN Título del proyecto: SERVIDOR AVANZADO DE AUTENTICACIÓN Y GESTIÓN DE REDES INALÁMBRICAS Santi Baztan Ancin TUTOR: Eduardo Magaña Lizarrondo Pamplona, 24 de Septiembre de 2004

2 Quiero dar las gracias que me han apoyado en la realización de este proyecto. Especialmente a Eduardo, colegas del garito interior, Ainhoa, Iokin, Mariaje y Mikel. Ainhoa, Mariaje, Iokin eta Mikel: Mila esker nire alboan egoteagatik. Zuen laguntza itzela izan da.

3 Índice 1 Introducción Objetivos Origen del sistema Nuevas funcionalidades Redes inalámbricas Introducción a IEEE Topologías de red Algunos mecanismos de seguridad IEEE 802.1X IEEE 802.1X en LANs WI-FI RADIUS EAP Métodos de autenticación Sistema AWNAS Introducción Descripción y funcionamiento del sistema AWNAS Comunicación entre componentes Funcionamiento a alto nivel Material y componentes utilizados AWNAS Configuración de red del Sistema AWNAS Código del AWNAS Punto de acceso Openssl Openldap Freeradius - Proxy Freeradius - Auth DHCP (Dynamic Host Configuration Protocol) Apache FireWall - Iptables Control de tráfico tc Pcap Clientes del Sistema Windows XP Xsupplicant Wire1x Pruebas del Sistema AWNAS

4 3.1 iperf Monitorización de las pruebas Tráfico UDP Ancho de banda de la red Inalámbrica Efecto del tráfico en la red inalámbrica en el retardo Dos clientes: 1 profesor y 1 cliente Cuatro clientes: todos del mismo perfil Tráfico TCP Tráfico TCP con un único cliente Tráfico TCP con varios clientes Tráfico TCP desde una máquina remota y lejana Conclusiones y líneas futuras...88 Bibliografía...90 Anexos...92 ANEXO I. WEP: Wired Equivalent Privacy...92 ANEXO II. Extensible Authentication Protocol (EAP)...94 ANEXO III. Punto de Acceso ANEXO IV. Configuración de Windows XP como cliente

5 1 Introducción En la actualidad, la popularidad de las redes inalámbricas está aumentando enormemente. Así mismo, cada vez es más habitual que las empresas implementen redes inalámbricas en sus empresas en lugar de tender las tradicionales redes cableadas, más costosas y menos versátiles que las inalámbricas. Las redes inalámbricas aportan grandes mejoras con respecto a las redes cableadas, como puede ser la movilidad de los puntos de trabajo. Es obvio que es beneficioso tener la posibilidad de mover un punto de trabajo a voluntad siempre que el punto se encuentre con cobertura. En definitiva, los problemas de dotar de infraestructura de red se reducen notablemente si la red es inalámbrica. Aún así, y como casi todo en esta vida, las redes inalámbricas tienen sus inconvenientes. Para empezar, hoy por hoy ofrecen un ancho de banda notablemente menor que las redes cableadas, y esto es bastante importante si tenemos en cuenta que las aplicaciones actuales cada vez necesitan un mayor ancho de banda. Pese a esto, el mayor problema que tienen las redes inalámbricas, es el de la Seguridad. El medio de transmisión de las redes inalámbricas es el aire, y en principio, este medio es público, por lo que cualquiera que se encuentra en un punto con cobertura, es susceptible de interactuar en la comunicación de un usuario de la red inalámbrica. En las redes cableadas, este fenómeno está dificultado por la necesidad de pinchar el cable para interactuar en alguna comunicación. Por lo tanto, un posible atacante tiene bastantes más facilidades para atacar una red inalámbrica que para atacar una cableada, aunque esto no quiere decir que las redes cableadas sean seguras. Los ataques pueden ser de muchos tipos, desde una escucha simple de la comunicación, hasta cosas como hacerse pasar por el punto de acceso original, o introducirse en la red haciéndose pasar por un cliente legítimo IEEE 802.1X]. Por tanto se hace necesario introducir mayor inteligencia en la red que permita dar mayor seguridad a este tipo de redes. Otro apartado no menos importante es el de la gestión de las redes inalámbricas. Una vez tendida la red inalámbrica, la red debe gestionarse para poder obtener el mayor rendimiento del sistema. Para ello es necesario implementar una herramienta que gestione la red de acuerdo a los intereses del propietario de la red. Así, es muy interesante que la red sea capaz de dar diferentes recursos a los clientes en función del tipo de. Esto significa que en función del perfil del usuario, se permite el acceso a unas redes o a otras, se asigna un mayor o menor ancho de banda, y en definitiva, se tiene un mayor o menor privilegio. Un ejemplo de esto último puede ser el caso que aborda este proyecto, en el cual se implementa una herramienta para el uso de ella en la. En esta red, los profesores tienen mayores privilegios que los alumnos. Pueden acceder a direcciones de red a las que no pueden acceder los alumnos y además tienen un mayor ancho de banda asignado. Lógicamente, la monitorización de la red tiene una gran importancia para reaccionar ante los problemas y para verificar el funcionamiento de la red y realizar el control de la misma. Todos estos asuntos son los que son abordados a lo largo de este proyecto. 3

6 1.1 Objetivos Planteado el problema de la seguridad de las redes inalámbricas, el principal objetivo de este proyecto es el desarrollo de un sistema que permita dar cierta seguridad a este tipo de redes de una manera relativamente sencilla para el usuario inalámbrico. Sin embargo, para la realización de este sistema, y viendo la necesidad de facilitar la gestión de estas redes, se ha planteado como objetivo secundario el incorporar al sistema herramientas que permitan gestionar y monitorizar la red desde un interfaz WEB. De esta forma se obtendrá una herramienta que permita una conexión sencilla a los usuarios inalámbricos, así como una gestión de la misma segura y sencilla para los administradores de la red inalámbrica en cuestión. Como último objetivo, se pretende desarrollar una plataforma de pruebas que permita estudiar el comportamiento del sistema, con el fin de resolver los posibles problemas que pueda tener Origen del sistema Este prototipo parte de un proyecto previo que abordó el problema de la seguridad de las redes inalámbricas a finales del año Este proyecto fue realizado por Eduardo Magaña Lizarrondo. La idea básica de este prototipo era la de introducir IEEE 802.1X para aportar seguridad en la red inalámbrica, introduciendo métodos de autenticación seguros, como es el caso de EAP-TLS (ver ) y la asignación dinámica de claves WEP. Con el objetivo de crear una herramienta completa y flexible, se eligió una arquitectura que permitiera alojar la mayor parte de los servidores en cualquier ISP. El sistema original consta de: Servidor de autenticación: Es el que se encarga de realizar la autenticación de los usuarios. Este servidor puede colocarse en cualquier punto, ya que se comunica de una manera segura con el servidor Freeradiusproxy, que es el que debe estar junto al punto de acceso. Es este servidor el que debe estar correctamente configurado para realizar el proceso de autenticación con el usuario inalámbrico. Servidor Freeradius-proxy: La necesidad de tener un servidor Freeradius-proxy es debida a que es posible que en algún caso interese tener más de un servidor de autenticación. Esto es posible si se pone un servidor que redireccione el tráfico de autenticación al servidor de autenticación oportuno en función de algún parámetro. Base de datos: Esta base de datos se utiliza para almacenar los datos necesarios para el funcionamiento del sistema, como son las características de los puntos de acceso, perfiles de usuario, usuarios, etc. Debido a las características del sistema se optó por utilizar LDAP (ver 2.3.5). Servidor WWW + apache: En este servidor se aloja la herramienta de Gestión Web que permite gestionar y monitorizar la red inalámbrica. 4

7 En definitiva, este primer prototipo integra un sistema de autenticación de clientes Windows XP mediante el método de autenticación EAP-TLS (ver ) y permite una gestión y monitorización de la red inalámbrica Nuevas funcionalidades El diseño del sistema se ha mantenido intacto, y lo que se ha hecho ha sido incorporar nuevas funcionalidades al sistema. Se han realizado así mismo algunas pruebas del sistema para comprobar el funcionamiento de la red inalámbrica. Actualización de software y servidores: se han actualizado todos los servidores y paquetes necesarios para el sistema. Así, se han incorporado nuevas versiones de Openssl, Openldap, Apache, Php y Freeradius. Depuración del software original: se ha dotado de nuevas funcionalidades al sistema para realizar ciertas operaciones. Una de las mejoras más importantes ha sido el desarrollo de funciones que permiten que el sistema realice la búsqueda de la dirección IP de los clientes mediante la captura del primer paquete que los usuarios envían a la red. Esto le da flexibilidad al sistema ya que independiza el sistema del modelo de punto de acceso. También se ha variado la manera en la que se introducen las reglas de Firewall. Ahora se realiza un filtrado MAC para introducir las reglas del tráfico proveniente del cliente inalámbrico, con lo que se consigue que el primer paquete recibido del cliente no sea desechado por tener denegado el acceso. Una vez capturado el primer paquete y conseguida la dirección IP del cliente, se introducen el resto de las reglas Firewall a nivel IP. Mejora del interfaz Web: se han realizado algunos cambios en el interfaz Web que controla el sistema. Incorporación de Xsupplicant al sistema: Xsupplicant es el programa cliente que permite que clientes Linux se conecten a la red mediante cualquier método de autenticación. Esto es de gran importancia, ya que permite que se conecten a la red tanto clientes con sistema operativo Windows XP, como clientes que utilizan Linux. Servidor DHCP: Se ha introducido DHCP al sistema con el objetivo de automatizar la asignación de los parámetros de red a los clientes conectados. De esta manera se evita la operación de tener que configurar el cliente manualmente. Cuando un cliente se autentica, el sistema le asigna dinámicamente todos los parámetros necesarios (IP, máscara, router por defecto, etc). Plataforma de pruebas: se ha incorporado una herramienta para poder realizar pruebas con el objetivo de ver el comportamiento del sistema. 5

8 1.2 Redes inalámbricas Las redes inalámbricas han evolucionado hacia varios tipos de tecnologías en función de los requerimientos de las diferentes redes. En el caso de las redes inalámbricas de área local WLAN, coexisten tecnologías como hiperlan o IEEE , aunque es esta última la que está más extendida actualmente Introducción a IEEE Es un estándar de IEEE desarrollado en 1997, que en su versión original ofrecía un ancho de banda de 2 Mbps, velocidad bastante reducida para dar cobertura a un número elevado de clientes. Con el tiempo han ido surgiendo variantes de este primer estándar que han dado solución a diversos problemas de las redes inalámbricas. Estándar a b e f g h i Descripción Estándar WLAN original. Soporta de 1 a 2 Mbps. Estándar WLAN de alta velocidad en la banda de los 5 GHz. Soporta hasta 54 Mbps. Estándar WLAN para la banda de 2.4 GHz. Soporta 11 Mbps. Está dirigido a los requerimientos de calidad de servicio para todas las interfaces IEEE WLAN de radio. Define la comunicación entre puntos de acceso para facilitar redes WLAN de diferentes proveedores. Establece una técnica de modulación adicional para la banda de los 2.4 GHz. Dirigido a proporcionar velocidades de hasta 54 Mbps. Define la administración del espectro de la banda de los 5 GHz para su uso en Europa y en Asia Pacífico. Está dirigido a superar la vulnerabilidad actual en la seguridad para protocolos de autenticación y de codificación. El estándar abarca los protocolos 802.1X, TKIP (Protocolo de Llaves Integras Seguras Temporales), y AES (Estándar de Encriptación Avanzado). Es un estándar que aún está en proceso de desarrollo, pero parece que el futuro de las WLAN pasa por IEEE i Tabla 1: Estándares IEEE En la Tabla 1, se muestran los diferentes estándares existentes dentro del complejo IEEE

9 La especificación b fue ratificada por el IEEE en julio de 1999, y opera en un ancho de banda que abarca las frecuencias dentro del rango de 2.4 a GHz del espectro de radio. IEEE b permite una velocidad máxima de 11 Mbps. Las redes de área local inalámbricas utilizan esta especificación de una manera mayoritaria. Este es el tipo de red inalámbrica con el que se ha trabajado Topologías de red Existen dos topologías de red diferentes Red ad-hoc Una red ad hoc (peer to peer) es una red de área local independiente que no está conectada a una infraestructura cableada y donde todas las estaciones se encuentran conectadas directamente unas con otras (en una topología mallada). La configuración de una red de área local inalámbrica en modo ad hoc, se utiliza para establecer una red donde no existe la infraestructura inalámbrica o donde no se requieran servicios avanzados de valor añadido. Figura 1: Red ad-hoc Red de infraestructura En una red de infraestructura, los clientes WLAN se conectan a una red corporativa a través de un punto de acceso inalámbrico. La mayoría de las redes de área local inalámbricas corporativas opera en modo de infraestructura. El sistema desarrollado utiliza una topología de red de este tipo. 7

10 Figura 2: Topología en modo Infraestructura Algunos mecanismos de seguridad En los inicios de la tecnología inalámbrica, los procedimientos y mecanismos de seguridad eran tan débiles que se podía acceder con gran facilidad a redes de este tipo sin tener permiso para ello. Existe el término wardriving, que se refiere a la acción de recorrer una ciudad para buscar la existencia de redes y conectarse a ellas. Existen sin embargo, algunos mecanismos que aportan diferentes grados de seguridad a las redes inalámbricas. A continuación se muestran algunos de ellos: SSID (Identificador de servicio) Es una contraseña simple que identifica la WLAN. Los clientes deben tener configurado el SSID correcto para acceder a la red inalámbrica. El uso del SSID como método único de control de acceso a la infraestructura es peligroso, porque típicamente no está bien asegurado. De hecho, comúnmente el punto de acceso está configurado para distribuir este parámetro en su señal guía (beacon) Filtrado con dirección MAC (Control de acceso al medio): Restringe el acceso a computadoras cuya dirección MAC de su adaptador está presente en una lista creada para cada punto de acceso en la WLAN. Este esquema de seguridad se rompe cuando se comparte o cuando se cambia la MAC de un interfaz WEP (Privacidad equivalente a cable) Es un esquema de encriptación que protege los datos transmitidos entre clientes y puntos de acceso como se especifica en el estándar Aunque el soporte para WEP es opcional, la certificación Wi-Fi exige WEP con llaves de 40 bits (ver 4). Existen herramientas capaces de descifrar estas claves en un tiempo reducido, por lo que no es un método seguro por si solo. En el prototipo propuesto, se utilizan claves WEP de 128 bits que son asignadas dinámicamente, aumentando notablemente la seguridad de la red. 1.3 IEEE 802.1X A la vista de la falta de seguridad de las redes, IEEE decidió desarrollar un estándar que consiguiera aportar mecanismos de seguridad de una manera integral, naciendo de esta manera el estándar IEEE 802.1X. En un principio, IEEE 802.1X no se desarrolló para su utilización en redes inalámbricas, sino para redes cableadas convencionales. Su propósito era controlar el acceso a la red en un entorno en el que el medio físico es compartido. Este medio compartido se refería a redes locales tradicionales en las que el medio es compartido, pero perfectamente aplicable a entornos inalámbricos, ya que el entorno inalámbrico se puede asemejar a una red tradicional en el que todo el tráfico pasa por el 8

11 mismo cable. De esta manera, IEEE 802.1X ha encontrado su entorno de aplicación más importante en este tipo de redes, las inalámbricas. Para realizar el control de acceso, IEEE 802.1X separa el sistema en 3 elementos: - Suplicante: que es el cliente que pretende conectarse a la red. Punto de acceso o autenticador: es el que realiza el control de acceso propiamente dicho. Servidor de autenticación: es el que se encarga de tomar las decisiones de autenticación y autorización. Al punto al que se conecta el cliente se le denomina puerto. La red puede tener varios puertos. En una LAN ethernet por ejemplo, cada conector de un switch es un posible puerto. Figura 3: Modelo IEEE 802.1X según el Estándar IEEE. El esquema del funcionamiento de IEEE 802.1X es el que se puede observar en la Figura IEEE 802.1X en LANs WI-FI 9

12 Figura 4: Esquema de autenticación Funcionamiento Cuando un nuevo cliente se intenta conectar a la red inalámbrica, solo se le permite intercambiar información de autenticación (ver Figura 4). Este tráfico de autenticación lo reenvía el punto de acceso al servidor de autenticación vía RADIUS. En este servidor de autenticación, muchas veces denominado servidor RADIUS, es donde se realiza la autenticación propiamente dicha. La autenticación se realiza extremo a extremo (ver Figura 5) entre el servidor de autenticación y el cliente inalámbrico mediante el protocolo de autenticación EAP (Protocolo de Autenticación Extensible), con el que se puede utilizar cualquier método de autenticación compatible con EAP. Figura 5: Capas en IEEE 802.1X 10

13 Una vez efectuada la autenticación entre cliente y servidor de autenticación, y en caso de que esta haya sido satisfactoria, el servidor de autenticación envía un mensaje de Autenticación exitosa al punto de acceso o autenticador, que procede a permitir el acceso a los servicios de la red al usuario correctamente autenticado. Otro problema que intenta solucionar IEEE 802.1X es el de la confidencialidad e integridad de la información. Para ello posibilita la asignación de claves WEP de una manera dinámica. Esto aporta un nivel importante de seguridad a la red inalámbrica, ya que, aunque es posible descifrar las claves WEP, no será de gran utilidad si para cuando se consigue descifrar una clave, esta ya ha cambiado. En el 4 se describe el proceso seguido para que los dos extremos conozcan las claves a utilizar en la comunicación. Está muy extendida la idea de que IEEE 802.1X solo es necesario para grandes redes, las cuales tienen servidores de autenticación dedicados. Sin embargo, un servidor de autenticación puede ser un pequeño proceso dentro del punto de acceso (una simple lista de usuarios y passwords por ejemplo). En consecuencia, también puede ser adecuada la implementación de IEEE 802.1X en pequeñas redes como puede ser una red doméstica, en la que no es necesaria la utilización de RADIUS, ya que el autenticador y el servidor de autenticación no tienen que entablar un diálogo a través de la red. Están en la misma caja que es el punto de acceso RADIUS RADIUS o Remote Authentication Dial In User Service. Especificar exactamente qué es RADIUS suele llevar a confusión en muchas ocasiones. Pero a lo que nos solemos referir cuando se habla de RADIUS es al protocolo que se utiliza para que el Punto de Acceso se comunique con el Servidor de Autenticación. Lo que hace RADIUS es definir una serie de funcionalidades muy comunes en los servidores de autenticación y define un protocolo que permite acceder a esas funcionalidades. RADIUS fue especificado por la IETF y fue diseñado para ser utilizado en redes TCP/IP. RADIUS fue diseñado para realizar la comunicación entre el servidor de autenticación y puntos de acceso que solían ser modems dial-in. Un ISP pretende dar servicio al mayor número de clientes posible dando servicio dial-up, pero para poder dar ese acceso a un precio razonable, los modems se deben colocar razonablemente cerca. Estos modems se colocan en estaciones locales. Para dar el acceso a la red se debe realizar una serie de operaciones como la autenticación. RADIUS viene a dar solución al problema de la gestión de la autenticación permitiendo crear un servidor central de autenticación que gestiona todo lo concerniente a la autenticación. A este servidor de autenticación se le suele denominar servidor RADIUS. Esta misma estrategia es válida para las redes inalámbricas. RADIUS fue diseñado pensando en dos escenarios distintos de autenticación PPP, que eran PAP y CHAP (ver ), los dos bastante inseguros por cierto. Es necesario ampliar los escenarios de autenticación, ya que se quieren implementar distintos tipos de 11

14 autenticación mediante EAP. Para poder soportar EAP, RADIUS utiliza los mensajes access-challenge para enviar los mensajes EAP, tanto los request como los responses. RADIUS es lo suficientemente flexible como para poder realizar estas adaptaciones. Aunque solo hay cuatro mensajes distintos, el significado de los mismos puede variar ostensiblemente gracias a unos parámetros de los mensajes Servidor RADIUS El servidor RADIUS es un servidor de AAA (authentication, autorisation and accounting). Es el servidor de autenticación que como su nombre indica, realiza las labores de autenticación de usuarios cuando el punto de acceso le envía una petición de autenticación. Además de autenticar, puede realizar otras operaciones en función del método de autenticación que esté utilizando. Estor servidores se comunican con el access point mediante el protocolo RADIUS Freeradius El servidor Freeradius es un servidor RADIUS de libre distribución. Es el servidor de autenticación que se va a utilizar en el desarrollo de este proyecto. Este servidor también puede realizar las labores de proxy del tráfico IEEE 802.1X. Esto es muy interesante ya que permite colocar el servidor de autenticación-proxy, que reenvíe el tráfico de autenticación a uno, o a varios servidores de autenticación EAP El Protocolo de Autenticación Extensible (EAP) es el protocolo que se utiliza para realizar el proceso de autenticación entre el servidor de autenticación y el cliente inalámbrico. Normalmente, el servidor de autenticación será un servidor RADIUS, o Freeradius en el caso del prototipo que aquí se desarrolla (ver 4). Básicamente, EAP es un protocolo que inicia y cierra el proceso de autenticación, dejando entre medio que los métodos de autenticación específicos realicen la autenticación. Estos métodos utilizan mensajes EAP para realizar sus funciones. Esta característica es la que hace que se denomine extensible, pues es posible implementar cualquier método de autenticación, siempre que sea compatible con EAP. La forma en la que deben ser enviados los mensajes EAP no está especificada. Para remediar esto, los mensajes EAP se transportan utilizando EAPol (EAP over LAN) entre el cliente y el punto de acceso, y utilizando RADIUS entre el punto de acceso y el servidor de autenticación RADIUS Métodos de autenticación En este apartado se realiza una descripción de los métodos específicos de autenticación más extendidos. Estos métodos de autenticación se utilizan junto con EAP. Los métodos se suelen denominar como EAP-método específico (EAP-TLS, EAP-TTLS, EAP-MD5...). 12

15 Estos métodos son los que utiliza el protocolo EAP para realizar la autenticación. Como se explica en el 4, EAP es un protocolo que permite la utilización por encima de cualquier método de autenticación (Cualquiera de nosotros puede diseñar un método de autenticación para EAP). Por eso se denomina extensible EAP-MD5 Este método consiste en realizar un hash con el login y la password en el cual, el nombre se transmite sin protección. Este método sólo sirve para autenticar al cliente ante el servidor, pero no para autenticar al sistema frente al cliente. No soporta asignación de clave WEP dinámica. Esto es un grave problema ya que actualmente hay herramientas que descifran estas claves en muy poco tiempo, por lo que si esta no varía, es una medida bastante deficiente para aportar seguridad a la red. Es un método de autenticación no aporta seguridad. Es susceptible de ser atacado de una manera bastante sencilla. Por lo tanto, es un método de autenticación no recomendable y bastante desfasado. Sin embargo, puede ser una buena alternativa para realizar la segunda fase de la autenticación en el método EAP-TTLS. El nombre se envía sin protección. Sujeto a ataques de diccionario, man-in-themidle CHAP Este método es muy similar al anterior. Se basa también en login y password, y aunque no es un método bueno por sí solo, es interesante su utilización como segunda fase de autenticación del método EAP-TTLS. Este es el método utilizado en este prototipo para realizar la segunda fase de la autenticación EAP-TTLS LEAP Es un protocolo propiedad de Cisco que se basa en el envío de un nombre de usuario y contraseña por parte del cliente PEAP De las siglas en inglés Protected EAP. Se planteó como una alternativa a EAP-TLS, aunque realmente es más parecido a EAP-TTLS. Es un método desarrollado por Microsoft y Cisco. Soporta asignación de claves WEP dinámicas y proporciona autenticación mutua entre sistema y cliente, pero solo necesita certificado del servidor, ya que para la autenticación del cliente se utiliza MS-CHAP v2 que es la versión de miscrosoft del método CHAP EAP-TLS Desarrollada por Microsoft. Es el método que más se esta utilizando en estos últimos tiempos debido a que Windows utiliza este método en gran cantidad de ocasiones. Este método realiza la autenticación mediante certificados creados por una Autoridad de Certificación de confianza. La autenticación es mutua, es decir, se autentica tanto el cliente como el servidor. Además, permite la asignación dinámica de claves WEP, aumentando enormemente la seguridad. 13

16 Otra característica de este método, es que no es necesario acceder a bases de datos. Esto puede suponer un problema en algunos casos en los que interese tener un control de acceso basado en bases de datos. Este es uno de los métodos con los que se trabajará en este proyecto EAP-TTLS Se basa en el método anterior EAP-TLS. En este caso, solo es necesario el certificado del sistema o del servidor. Una vez realizada la autenticación del servidor, se realiza un túnel TLS por donde se realiza el resto de la autenticación, que consiste en una autenticación de segundo orden que se utiliza para autenticar al cliente. En esta segunda fase de la autenticación se puede utilizar un amplio abanico de métodos de autenticación, que utilicen login y password, como pueden ser md5, chap, ms-chap, etc. El hecho de utilizar una autenticación del cliente basada en login y password, permite utilizar este método con las infraestructuras de bases de datos existentes actualmente. Además, simplifica el proceso ya que no hay que obtener certificados para el cliente, por lo que no es necesario que haya un servidor de certificados. Soporta también asignación dinámica de claves WEP. En conclusión, es un método bastante seguro que a su vez, permite la autenticación basada en login y password de una manera bastante sencilla. Este método también se ha implementado en este proyecto, aunque únicamente para clientes con sistema operativo Linux. Windows XP por si solo no soporta este método de autenticación Comparativa de los métodos de autenticación Después de ver el funcionamiento de los métodos específicos de autenticación, se puede concluir que los métodos más convenientes para aportar seguridad a la red, son aquellos que aportan autenticación mutua (cliente servidor), por lo que los métodos a priori más interesantes son EAP-TLS, EAP-TTLS y PEAP. A partir de aquí, la elección del método vendrá determinada por el tipo de credenciales cliente. Si se quiere realizar una autenticación utilizando certificado cliente, se utilizará EAP-TLS. Sin embargo, si se quiere utilizar login y password, se deberá utilizar alguno de los otros dos, que a su vez, utilizan otro método secundario. Desde aquí se aconseja la utilización de EAP-TTLS. En este prototipo se utilizan los métodos EAP-TLS, y EAP-TTLS con CHAP como método secundario. Solución de seguridad CertificadosCliente CertificadosServidor Seguridad 14 EAP-MD5 LEAP EAP-TLS EAP-TTLS EAP-PEAP Estándar Propietario Estándar Estándar Estándar No - Si No (opcional) No (opcional) No - Si Si Si Ninguna Deficiente Buena Buena Buena

17 Autenticación por base de datos Intercambio de llaves WEP dinámico Autenticación mutua Si Si No Si Si No Si Si Si Si No Si Si Si Si Tabla 2: Comparativa de métodos de Autenticación EAP. 2 Sistema AWNAS 2.1 Introducción El sistema AWNAS que se desarrolla en este proyecto es un sistema que se basa en IEEE 802.1X para realizar la autenticación mediante EAP y utilizando un método específico de autenticación seguro. Este método de autenticación permite la asignación dinámica de claves WEP, por lo que la seguridad será bastante elevada, tanto a la hora de realizar la autenticación, como a la hora de mantener la privacidad de los datos enviados por la red, una vez efectuada la autenticación. El sistema también incorpora una serie de herramientas que permiten una gestión eficiente de la red, permitiendo la asignación de recursos a los clientes en función del tipo de cliente. A lo largo de este capítulo se analiza el sistema AWNAS en su globalidad. El capítulo se separa en dos partes, que son las dos partes diferenciadas del sistema completo. Primero se estudia el sistema AWNAS, y posteriormente se hace lo mismo con los clientes de este sistema. Durante el capítulo se exponen las herramientas utilizadas, sus instalaciones, configuraciones y funcionamiento del prototipo desarrollado. 2.2 Descripción y funcionamiento AWNAS del sistema El sistema AWNAS consta de varias partes que forman dicho sistema. En la siguiente figura se puede observar un esquema del sistema AWNAS y del escenario con el que se va a trabajar. 15

18 Figura 6: Esquema del sistema AWNAS. El sistema propiamente dicho, es el que se puede observar dentro del recuadro externo, y está compuesto por un servidor LDAP, un servidor de Autenticación Freeradius, un servidor Freeradius-Proxy, un servidor DHCP y el AWNAS. En este prototipo, todos estos servidores están instalados en el mismo PC, pero podrían estar en cualquier otro punto de la red, o en un ISP. El escenario se completa con un punto de acceso y con un conjunto de clientes inalámbricos que pueden ser tanto clientes Linux como Windows XP. Como se ha comentado en la introducción, esta es una de las novedades más importantes de este prototipo Comunicación entre componentes Tan importante como conocer la estructura del prototipo, es conocer la manera en la que se comunican estos componentes. Esto es lo que se puede observar en la siguiente figura. Figura 7: Comunicación entre los diversos componentes del sistema. 16

19 El servidor LDAP o mejor dicho, el servidor Openldap (ver 2.3.5), se comunica mediante LDAP con todos los componentes que necesitan acceder a la información almacenada en el directorio LDAP, que es la información de todos los puntos de acceso, ISPs, perfiles y usuarios. A excepción del servidor DHCP, todos los demás se comunican con este servidor. El servidor de autenticación accede a LDAP para obtener los nombres de usuario y contraseñas para realizar la autenticación de un usuario. AWNAS accede al directorio LDAP para configurar el sistema, y el servidor WWW accede a LDAP ya que los datos almacenados en este directorio se manipulan desde la herramienta de gestión WEB. La comunicación de autenticación se realiza de dos maneras diferentes. Del cliente inalámbrico al punto de acceso se realiza en modo EAPol (ver anexo II), y desde el punto de acceso al Freeradius-Proxy, y de este al servidor de autenticación Freeradius-auth en modo Radius-EAP (ver anexo II). DHCP se comunica directamente con el cliente una vez realizada la autenticación Funcionamiento a alto nivel Cuando se inicia el sistema, se deniega todo el tráfico a excepción del tráfico IEEE 802.1X que es redireccionado por el punto de acceso al servidor Freeradius-Proxy. Cuando un cliente se incorpora a la red inalámbrica y pretende conectarse a ella, realiza la petición al punto de acceso, y este a su vez, lo reenvía al Freeradius-Proxy, ya que es tráfico IEEE 802.1X. Freeradius-Proxy captura la identidad del cliente, y contrasta el dominio de esta identidad con los dominios que tiene en el archivo proxy.conf (ver 2.3.6). Si la identidad coincide con alguna entrada, este tráfico es redireccionado a la dirección IP y puerto adecuado donde se encuentra el servidor de autenticación Freeradius-auth. Este es el que se encargará de realizar la autenticación del cliente. El servidor de autenticación efectúa la autenticación con el cliente, y si es necesario, consulta los datos del directorio LDAP, donde se almacenan los datos del sistema y de los clientes. En el caso de utilizar el método de autenticación EAP-TLS, no será necesaria ninguna consulta. Si se utiliza EAP-TTLS sin embargo, sí que habrá que consultar el login y password del cliente para realizar la autenticación. Una vez realizada la autenticación, y si esta ha sido satisfactoria, se le permite la conexión al cliente y se realiza la configuración de la conexión en función de los datos almacenados en el directorio LDAP para este usuario. Así, el usuario quedará conectado a la red, pero estará limitado por un firewall, el cual le permitirá únicamente acceder a aquellas direcciones para las que tenga permiso, y por un controlador de tráfico que le asignará más o menos ancho de banda en función de los permisos del cliente. Por lo que, una vez autenticado, esta será la estructura de red para el cliente inalámbrico recién autenticado. 17

20 Figura 8: Esquema del sistema una vez realizada la autenticación Material y componentes utilizados El diseño del sistema está pensado tal y como se ve en la Figura 6, para que cada servidor pueda estar en un lugar físico de la red cualquiera, es decir, los servidores pueden situarse en cualquier ISP. De hecho, en muchos casos será conveniente que esto sea así. Sin embargo, para realizar el proyecto, se ha instalado todo en un mismo PC, debido a que la infraestructura para realizar esta implementación del sistema es menos costosa. A continuación se detalla el material utilizado para el desarrollo de este proyecto: PC con sistema operativo Linux Red Hat 7.2. Este es el PC que se ha utilizado para albergar a todo el sistema. Este PC está dentro de la red del laboratorio de Telemática, mostrada en parte en la Figura 9. Figura 9: Esquema de la red en la que se encuentra el sistema AWNAS. Punto de Acceso Aironet 350 series (véase 4) [0]. Este es el punto de acceso que da cobertura de la red inalámbrica. 18

21 Cliente Windows XP. Se ha trabajado con un cliente Windows XP. Clientes Linux Red Hat 9.0. Se ha trabajado con cuatro clientes con sistema operativo Linux. Tarjetas Wireless Compaq WL110. Se han utilizado cuatro tarjetas en la realización del prototipo con adaptadores PCMCIA a PCI [ 0]. Figura 10: Tarjeta Wireless utilizada. Posteriormente se explica de manera exhaustiva la manera en la que se han configurado todos estos componentes para que el sistema funcione correctamente. 2.3 AWNAS En este punto se expone todo el proceso de instalación, configuración y funcionamiento de todas las herramientas utilizadas para implementar el AWNAS. Todo el sistema se ha instalado en la dirección /Dir_Base/open1x, pero esto puede cambiarse en función de las necesidades o intereses del instalador Configuración de red del Sistema AWNAS La máquina en la que esta alojado todo el sistema debe enrutar el tráfico entre la red inalámbrica y la red cableada, por lo que habrá que configurar esta máquina con el fin de que se comporte como un router Interfaces Como se ha comentado en el apartado 2.2.3, el sistema está colocado en un único PC. Este PC tiene dos interfaces de red, uno el que está conectado a la red del laboratorio (eth1), y otro el que está conectado con el punto de acceso (eth0). 19

22 Figura 11: Interfaces de red del sistema. eth0: access point IP Máscara eth1: red del laboratorio Tabla 3: Configuración IP de los interfaces de red Router Esta máquina, es decir, el PC donde está instalado todo el sistema se debe comportar como un router, por lo que es necesario habilitar el enrutado en esta máquina. Para conseguir esto, se ejecuta el siguiente script. Reglas-router #!/bin/bash #script que activa la máquina Linux como router echo 1 > /proa/sys/net/ipv4/ip_forward iptables --policy FORWARD ACCEPT Una vez ejecutado este script, esta máquina enrutará el tráfico entre la red del laboratorio y la red inalámbrica. Sin embargo, debido a los dominios de red elegidos para ambas redes, las máquinas del laboratorio y de fuera del laboratorio no sabrán llegar hasta los clientes. Por lo tanto, a la hora de realizar las pruebas, se deberá tener en cuenta que se deben configurar las rutas del PC en el que se va a colocar el servidor iperf (ver 3.1) que se va a utilizar. Si se quiere realizar conexiones con el exterior desde los equipos móviles, se debe habilitar el NAT, permitiendo así conectarse a otras máquinas como si lo estuviera haciendo pfc05 que es el nombre del PC que alberga al sistema. Para habilitar el NAT, y a modo de prueba se ha utilizado el siguiente script, aunque el que se ha utilizado es el que se ha puesto en primer lugar. Reglas-router-NAT: #!/bin/bash #script que activa la máquina Linux como NAT echo 1 > /proa/sys/net/ipv4/ip_forward iptables --flush iptables --table nat --append POSTROUTING --out-interface eth1 j MASQUERADE iptables --append FORWARD --in-interface eth0 j ACCEPT Código del AWNAS El programa AWNAS es el encargado de gestionar todo el sistema. Es el que se encarga de comunicarse con los servidores Freeradius y Openldap, y de realizar la configuración del sistema. En este punto se expone el funcionamiento de este programa, así como sus funcionalidades y prestaciones. 20

23 Este nas, que es el programa principal del AWNAS, utiliza varias librerías secundarias para realizar todas las tareas que tiene que realizar, que van desde la comunicación con los servidores Freeradius, hasta realizar consultas al directorio LDAP para realizar la configuración del Firewall y del controlador de tráfico. No menos importante es la labor que realiza para monitorizar el sistema Programa principal Nas Este es el programa principal del AWNAS. Básicamente, lo que hace este programa es realizar la configuración inicial del sistema en función de las características almacenadas en el archivo de configuración y el directorio LDAP, para luego dedicarse a realizar pequeñas configuraciones en función de los mensajes recibidos y generar los datos de la monitorización. En el Esquema 1 se puede ver las diferentes tareas que realiza el programa y que se detallan a continuación. Esquema 1: Estructura del programa principal nas Carga del archivo de configuración Consiste en cargar algunas variables de acuerdo con el archivo de configuración nas.conf. A continuación se presenta un ejemplo de este archivo: nas.conf: 21

24 # nas.conf - NAS configuration file # LDAP server IP address LDAP_IP # LDAP login user LDAP_LOGIN_USER cn=root,dc=tlm,dc=com # LDAP login password LDAP_LOGIN_PASSWORD tlm # ldapsearch executable path LDAP_LDAPSEARCH_PATH ldapsearch # snmpget executable path SNMPGET_PATH snmpget # iptables executable path IPTABLES_PATH /sbin/iptables # tc executable path TC_PATH /sbin/tc # Clients side interface, interface in the NAS server connected to the access points (downlink) CLIENTS_INTERFACE eth0 # Bits per second of that interface CLIENTS_INTERFACE_RATE # Interface connected to internet (uplink) INTERNET_INTERFACE eth1 # Bits per second of that uplink interface INTERNET_INTERFACE_RATE # Directory where all monitoring information is stored NASMONITORINGDATAPATH /root/open1x/prueba2/data Aquí se le indican cosas como los interfaces de red que debe utilizar el sistema y sus anchos de banda, parámetros para realizar las conexiones con el directorio LDAP, lugar de almacenamiento de los datos de monitorización, e incluso el lugar donde se encuentran las herramientas iptables y tc. Estos parámetros son utilizados por el programa principal para configurar el sistema Carga de puntos de acceso y perfiles de usuario Después de cargar el archivo de configuración, el programa carga en memoria los puntos de acceso y perfiles de usuario almacenados en el directorio LDAP. Para realizarlo, utiliza funciones de la librería libldap (ver ) Inicialización del firewall y control de tráfico Una vez cargados estos datos, se inicializa el firewall (ver ) y el control de tráfico (ver ) del sistema. Esto consiste en denegar el enrutamiento del tráfico de todas las direcciones IP menos las de los puntos de acceso, y en crear la estructura base del árbol de control de tráfico en los dos interfaces de red (ver ) Bucle Una vez realizado esto, el sistema queda configurado correctamente y entra en el bucle principal, donde permanecerá hasta que el sistema sea finalizado. En este bucle, el sistema espera posibles llegadas de mensajes cliente, en los que por ejemplo se puede anunciar la reciente autenticación de un cliente, buscar posibles cambios 22

25 de las direcciones IP de los clientes conectados a la red y realizar el procesado de las estadísticas de monitorización Funciones del programa principal En este mismo programa principal se encuentran varias funciones de interés que se comentan a continuación Función SearchNewIPs Esta función es la encargada de buscar las direcciones IP de los usuarios inalámbricos conectados a la red inalámbrica. Esta función realiza un recorrido sobre todos los clientes de todos los puntos de acceso. En caso de que no tenga en memoria su dirección IP, intenta averiguarla, y si lo consigue procede a configurar la conexión del cliente mediante la función ConfigureProfile. Es importante comentar, que no solo intenta averiguar la dirección IP de aquellos usuarios de los que no tenga esa información, sino que también intenta detectar posibles cambios de IP que se hayan producido en el transcurso de la conexión. Está funcionalidad fue añadida debido a que al realizar las pruebas del sistema, había clientes que se conectaban y desconectaban con mucha rapidez, y en algún caso, el servidor DHCP les asignaba una dirección IP distinta en cada conexión. Esto era un problema porque el sistema no se había percatado aún de la desconexión del usuario y tenía almacenada una dirección IP que ya había variado. El sistema no era capaz de actualizar la dirección IP (ver ). 23

26 Esquema 2: Estructura por bloques de la función SearchNewIps Función ConfigureProfile Esta función realiza la configuración de la conexión de cada cliente inalámbrico que se conecta a la red. Después de cargar el perfil del usuario a configurar, la función procede a la configuración del Firewall y del Control de Tráfico. Una característica importante de esta función es que separa los casos en los que el usuario dispone de dirección IP de los que no. En cada caso realiza acciones diferentes. En el caso de que no se conozca la dirección IP del usuario inalámbrico, únicamente se configuran las reglas de Firewall a nivel ethernet, es decir, las reglas que se ponen con iptables solo son las pertenecientes al tráfico proveniente de la dirección MAC origen del cliente inalámbrico. Se leen las direcciones de las redes a las que puede y a las que no puede acceder el cliente y se ejecuta la regla pertinente. En cuanto al control de tráfico, no se configura de momento ya que aún no se dispone de la dirección IP (ver ). En el caso de conocer la dirección IP del cliente inalámbrico, se introduce el resto de reglas del Firewall y todas las reglas de control de tráfico. 24

27 Esquema 3: Estructura por bloques de la función ConfigureProfile Función ReceiveClientMessages Esta es la función que se ejecuta cuando en programa nas recibe un mensaje. Esquema 4: Estructura por bloques de la función ReceiveClientMessages Existen 4 tipos de mensaje: 25

28 El primero se utiliza cuando se desconecta un cliente. Cuando sucede esto, se elimina el usuario de la memoria y se desconfigura el perfil (iptables y tc). Luego están los mensajes de listado. Uno realiza un listado de los puntos de acceso configurados en el sistema, y el otro realiza un listado de los usuarios. Por último está el mensaje de autenticación, que es el mensaje que se recibe cuando se realiza una nueva autenticación. Esto puede ser por varios motivos, el primero es que un nuevo usuario se acabe de conectar a la red inalámbrica, en cuyo caso se debe proceder a añadir este usuario en la lista de usuarios conectados y a introducir las reglas Firewall del tráfico ascendente. Si el usuario ya estaba en memoria, puede ser que haya cambiado de dirección IP o MAC. Si ha cambiado de MAC, también se deberá realizar la configuración del firewall del tráfico ascendente. En cualquier caso, se deberá intentar hallar la dirección IP y se deberá proceder a configurar el firewall del tráfico descendente y el control de tráfico Librería global Librería en la que se definen variables, constantes y estructuras que se utilizan en el resto de librerías y programa principal. A continuación se detallan algunas de las estructuras utilizadas: typedef struct tap Tap; typedef struct tuser Tuser; typedef struct tnetwork Tnetwork; typedef struct tprofile Tprofile; typedef struct tmonitoring Tmonitoring; Estructura tmonitoring struct tmonitoring { struct timeval timestamp; //tiempo de monitorización unsigned long long bytes_in_accept; //B aceptados en enlace descendente unsigned long long bytes_in_drop; //B desechados en enlace descendente unsigned long long bytes_out_accept; //B aceptados en enlace ascendente unsigned long long bytes_out_drop; //B desechados en enlace ascendente }; Es la estructura utilizada para guardar datos de monitorización. Estructura tap struct tap { in_addr_t apip; char apcommunityname[apcommunitysize]; //nombre de comunidad SNMP int apmodel; //tipo de punto de acceso Tlist users; //lista de usuarios conectados al punto de acceso Tmonitoring monitoring; // Información del tráfico enrutado y del desechado }; Es la estructura utilizada para los puntos de acceso. 26

29 Estructura tuser struct tuser { int apport; char username[usernamesize]; //nombre de usuario unsigned char usermac[macsize]; //dirección MAC in_addr_t userip; //dirección IP Tprofile *profile; //perfil del usuario int subclassid; // Id o subclasse del usuario( TC QoS) time_t logintime; // Tiempo de inicio de conexión Tmonitoring iptablesmonitoring; // Monitorización Firewall Tmonitoring tcmonitoring; // Monitorización del control de tráfico QoS pcap_t *pcap; //descriptor de conexión pcap. Permite saber si se está intentando averiguar la dirección IP del ususario. }; Es la estructura usuario. Con ella se gestionan todos los parámetros necesarios concernientes a los usuarios inalámbricos. Estructura tnetwork struct tnetwork { in_addr_t net; //dirección IP de la red in_addr_t netmask; //máscara de la red int allow; //1 si el tráfico está permitido, 0 si está denegado }; Con esta estructura se manipulan las redes a las que se permite o a las que no se permite acceder. Estructura tprofile struct tprofile { char uprofile[uprofilesize]; int minbw; // Mínimo BW garantizado (encolamiento final CBQ) int maxbw; // Máximo BW permitido (Limitador) int priority; // Prioridad de la clase del perfil (CBQ) int reservedpercentage; // BW reservado de la clase (CBQ) Tlist networks; // List of networks allowed or not to the user int classid; // Id de la clase utilizada por tc en el control de tráfico int maxusersubclassid; // Keeps count of the subclassid assigned to users }; Esta es la estructura que se utiliza para trabajar con los diferentes perfiles de usuario que hay en el sistema Librería libcom En esta librería se encuentran todas las funciones necesarias para realizar la comunicación entre los servidores Freeradius, el AWNAS y el punto de acceso Librería libap En esta librería están todas las funciones relacionada con crear y borrar usuarios, puntos de acceso, estructuras network, etc. También se pueden encontrar funciones para 27

30 comparar, copiar o pasar direcciones MAC de un formato a otro. Pero la función más importante de esta librería es la de buscar la dirección IP de un cliente inalámbrico Función AP_IPfromMac Esta función busca la dirección de un cliente inalámbrico realizando la captura del primer paquete que el cliente envía a la red. Para ello, se ha utilizado la librería pcap, sus utilidades y funciones (ver ). Esquema 5: Estructura por bloques de la función AP_IPfromMac. Esta función realiza la captura del primer paquete proveniente de la dirección MAC del usuario que se le introduce como parámetro de entrada a la función. Para hacer esto y utilizando la librería pcap, se obtiene el primer paquete que proviene de esa dirección MAC y que no tenga la dirección IP origen Es necesario esto último debido a que siempre aparece un primer paquete enviado en el proceso de obtención de los parámetros de red por DHCP. La captura del tráfico se realiza en modo no bloqueante para que no quede el proceso bloqueado debido a que no aparezca ningún paquete. No es un problema que no se encuentre la dirección IP la primera vez que se ejecuta esta función, ya que se ejecuta periódicamente hasta que el primer paquete con la dirección correcta es capturado. El desarrollo de este método de obtención de la dirección IP de los clientes inalámbricos es bastante importante. Hasta ahora, esto se realizaba mediante SNMP y era necesaria una función específica para cada tipo de punto de acceso, ya que estos mensajes varían de uno a otro. Con esta nueva función, el sistema obtendrá las direcciones IP de los clientes correctamente, con independencia del punto de acceso que se utilice, dando así, mayor flexibilidad al sistema. El problema de este método radicaba en que las reglas Firewall se introducían una vez que el paquete era capturado, por lo que este primer paquete era desechado. Esto también ha sido arreglado al introducir las reglas Firewall en dos pasos (ver y ). En primer lugar, se introducen las reglas del tráfico ascendente o procedente de los clientes inalámbricos a nivel MAC, y posteriormente se introduce el resto tras conocerse la dirección IP del cliente. Así se evita la pérdida del primer paquete enviado por el cliente inalámbrico una vez autenticado. 28

31 Librería libfirewallqos Esta librería contiene todas las funciones relacionadas con el Firewall y control de tráfico. También se pueden encontrar las funciones que generan los datos de monitorización y datos estadísticos Función FirewallMachineOpen Esta es la función que introduce las reglas Firewall al iniciarse el sistema. Esto consiste en denegar el tráfico que no provenga del punto de acceso. Al autenticarse los clientes se introducirán otras reglas que permitirán que el tráfico a las redes que tengan acceso permitido sea habilitado Función FirewallMachineRule Esta es la función que se utilizaba antes de diseñar las dos funciones siguientes. Esta función se encarga de introducir todas las reglas de Firewall cuando se conecta un cliente inalámbrico a la red. Para esto, es necesario conocer la dirección IP del cliente. En el sistema actual, las reglas de Firewall del tráfico proveniente de los clientes se ponen a nivel MAC antes de conocer siquiera la dirección IP del cliente, y una vez conocida la dirección IP, se introducen el resto de las reglas Firewall a nivel IP. Así se soluciona el problema de pérdida del primer paquete procedente de los clientes. Antes, cuando se implementó la función de obtención de la dirección IP mediante la captura del primer paquete del cliente, todas las reglas se introducías tras obtener la dirección IP, por lo que el primer paquete, del cual se obtenía la dirección IP, era desechado. Por esta razón se ha separado en dos funciones diferentes Función FirewallMachineRule_mac Esta función simplemente pone reglas Firewall del tráfico ascendente o proveniente de los clientes inalámbricos a nivel MAC. Así, ningún paquete proveniente de estos clientes podrá alcanzar las redes a las que tiene el acceso denegado aunque no se conozca su dirección IP. Pero cuando el cliente intente acceder a una red permitida, tendrá el acceso permitido Función FirewallMachineRule_ip Introduce las reglas Firewall una vez que se conoce la dirección IP del cliente inalámbrico. Estas reglas se introducen a nivel IP Función QoSGlobalInit Introduce las reglas tc de calidad de servicio o control de tráfico iniciales, que consisten en reservar un ancho de banda para cada perfil, y dar una prioridad determinada a cada perfil Función QoSMachineRule Introduce las reglas de control de tráfico cuando se conecta el cliente inalámbrico. Crea la subclase del usuario y limita el máximo ancho de banda del cliente mediante police rate. 29

32 Función ProcessStatisticsIptables Es la función que se encarga de contabilizar los bytes que atraviesan el Firewall y los que son desechados por este. Para esto, la función lee los datos almacenados en el archivo iptables.tmp que es donde iptables almacena los datos de los paquetes que pasan por este Firewall. Uno de los parámetros que se guardan es si el paquete es desechado, o no Función ProcessStatisticsTc Esta función se encarga de contabilizar los bytes que atraviesan y los que no el filtro de control de tráfico, o QoS. Estos datos se leen del archivo tc.tmp para cada interfaz Función ProcessStatistics Se puede decir que es la función principal que se encarga de procesar las estadísticas del sistema. Primeramente realiza un filtrado de los datos provenientes tanto de iptables como de tc y los envía a sendos ficheros temporales de los que posteriormente obtiene los datos de monitorización del sistema. Cada vez que se ejecuta esta función, se realiza un recorrido sobre todos los clientes inalámbricos conectados a la red inalámbrica y se procesan sus datos de Firewall y los datos de control de tráfico sobre los dos interfaces. En los dos casos se contabilizan los bytes aceptados y los desechados y son procesados. Esquema 6: Estructura por bloques de la función processstatistics. 30

33 Librería libldap Esta librería contiene todas las funciones relacionadas con LDAP. Todas las consultas al directorio LDAP se realizan con funciones de esta librería Función LDAPListAPs Carga en memoria todos los puntos de acceso con sus características asociadas Función LDAPListProfiles Carga en memoria los perfiles almacenados en el directorio LDAP con todas sus características Punto de acceso El punto de acceso debe estar correctamente configurado para que funcione como se desea en este prototipo. La configuración del punto de acceso se realiza de forma muy sencilla desde el interfaz WEB que tiene habilitado a tal efecto (ver 4). A continuación se muestra la configuración del punto de acceso utilizada. Dirección IP: Máscara: Autenticación 802.1X-2001 o Servidor de Autenticación: Dirección IP: Puerto: En este puerto es en el que está escuchando el servidor Freeradius-proxy (ver ). Encriptación de los datos: o Se puede trabajar tanto con encriptación opcional, como con encriptación obligatoria. En principio se ha configurado como Full Encryption o encriptación obligatoria. o Se deben habilitar las casillas de tipo de autenticación open y la de Network-EAP para que el punto de acceso sepa que las claves son proporcionadas por la red, y más concretamente por el servidor de autenticación. Configuración Radio: o ssid: tlm.unavarra.com o Se deshabilita la publicación del ssid para aportar un mayor grado de seguridad a la red inalámbrica. Una vez realizado esto, el punto de acceso estará configurado adecuadamente. 31

34 2.3.4 Openssl Introducción Esta es la herramienta que proporciona las herramientas necesarias para crear los certificados y claves que aportan seguridad al sistema IEEE 802.1X]. Estos certificados y claves son utilizados para realizar la autenticación de los clientes inalámbricos, pero también se utiliza para aportar seguridad a los servidores Openldap y Apache Instalación Se ha conseguido la última versión disponible de openssl que es openssl-0.9.7c [ 0]. La instalación es bastante sencilla. A continuación se muestra la instalación que se ha utilizado: [root@pfc05 open1x]#./config --prefix=/dir_base/open1x/openssl --shared [root@pfc05 open1x]# make clean [root@pfc05 open1x]# make [root@pfc05 open1x]# make install En la versión anterior de este sistema eran necesarias tres versiones diferentes de openssl, pero ahora es suficiente con instalar esta única versión Generación de Certificados y conversiones Se deben generar varios certificados para poner en funcionamiento el sistema. Estos certificados se utilizan fundamentalmente en algunos métodos de autenticación como pueden ser EAP-TLS y EAP-TTLS. A continuación se muestra como se pueden generar certificados de una manera sencilla: Petición de Generación de Certificado: [root@pfc05 open1x]# openssl req -new -outform pem -out certificado -req.pem -newkey rsa:1024 -keyout certificado -key.pem -keyform pem -passin pass: contraseña -passout pass: contraseña Generación de certificado: [root@pfc05 open1x]# openssl x509 -req -in certificado -req.pem -out certificado cert.pem -outform pem -days 365 -CA ca-cert-pem -extfile /../openssl.cnf -extensions usr_cert -CAkey ca-key.pem Conversión de PEM a p12 (formato de Windows): [root@pfc05 open1x]# openssl pkcs12 -export -out certificado -cert.p12 -inkey certificado -key.pem -in certificado -cert.pem Conversión de DER a PEM: [root@pfc05 open1x] # openssl x509 -inform DER -outform PEM -in certificado.der -out certificado.pem 32

35 Conversión de PEM a DER: [root@pfc05 open1x]# openssl x509 -inform PEM -outform DER -in certificado.pem -out certificado.der Conversión de p12 a PEM: [root@pfc05 open1x]# openssl pkcs12 -des3 in certificado.p12 out certificado.pem Para observar los campos de un certificado: [root@pfc05 open1x]# openssl x509 -in certificado.pem -text Certificados en AWNAS El funcionamiento de los sistemas de autenticación utilizados en este prototipo, como es el caso de EAP-TLS, requieren generar certificados para la autenticación, tanto del cliente inalámbrico como del servidor. Estos certificados deben estar firmados por una Autoridad de Certificación. A continuación se muestra el proceso de creación de la Autoridad de Certificación y los certificados necesarios en el proceso de autenticación Generación de la Autoridad de Certificación El siguiente script es el encargando de crear una Autoridad de Certificación. Esta Autoridad es la que posteriormente se encargará de firmar los certificados de los clientes y el del servidor de autenticación. CA.root #!/bin/sh../ca.common export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} export LD_LIBRARY_PATH=${SSL}/lib rm -rf democa #borra el directorio donde podía estar otra autoridad de certificación echo "*********************************************************************************" echo "Creating self-signed private key and certificate" echo "When prompted override the default value for the Common Name field" echo "*********************************************************************************" # Generate a new self-signed certificate. # After invocation, newreq.pem will contain a private key and certificate # newreq.pem will be used in the next step openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 365 -passin pass: $PASSWORD -passout pass:$password echo "*********************************************************************************" echo "Creating a new CA hierarchy (used later by the "ca" command) with the certificate" echo "and private key created in the last step" echo "*********************************************************************************" echo echo "newreq.pem" CA.pl -newca >/dev/null echo "*********************************************************************************" echo "Creating ROOT CA" echo "*********************************************************************************" echo # Create a PKCS#12 file, using the previously created CA certificate/key 33

36 # The certificate in democa/cacert.pem is the same as in newreq.pem. Instead of # using "-in democa/cacert.pem" we could have used "-in newreq.pem" and then omitted # the "-inkey newreq.pem" because newreq.pem contains both the private key and certificate openssl pkcs12 -export -in democa/cacert.pem -inkey newreq.pem -out root.p12 -cacerts -passin pass:$password -passout pass:$password # parse the PKCS#12 file just created and produce a PEM format certificate and key in root.pem openssl pkcs12 -in root.p12 -out root.pem -passin pass:$password -passout pass: $PASSWORD # Convert root certificate from PEM format to DER format openssl x509 -inform PEM -outform DER -in root.pem -out root.der #Clean Up rm -rf newreq.pem chmod 777 democa chmod 777 democa/* Este script genera, como se ha comentado previamente, una Autoridad de Certificación. Primero borra el directorio en el que pudiera haber otra Autoridad de Certificación anterior. Posteriormente crea un certificado auto firmado con el que se genera la Autoridad de Certificación. Finalmente crea los certificados root en los formatos der, pem y p12. El certificado root es necesario tanto para el servidor de autenticación, como para los clientes inalámbricos. CA.common #!/bin/sh SSL=/Dir_Base/openssl PASSWORD=client En este archivo se guardan la dirección en la que está instalado el paquete openssl, así como la contraseña que se utiliza a modo de ejemplo en la creación de los certificados Generación del certificado del servidor de autenticación El servidor de autenticación necesita un certificado firmado por la Autoridad de certificación para realizar la autenticación. Este es el certificado que se enviará a los clientes para que puedan autenticar al servidor. CA.srv #!/bin/sh../ca.common export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} export LD_LIBRARY_PATH=${SSL}/lib openssl req -new -keyout newreq.pem -out newreq.pem -passin pass:$password -passout pass:$password # Sign the certificate request. The policy is defined in the openssl.cnf file. # The request generated in the previous step is specified with the -infiles option and # the output is in newcert.pem 34

37 # The -extensions option is necessary to add the OID for the extended key for server authentication openssl ca -policy policy_anything -out newcert.pem -passin pass:$password -key $PASSWORD -extensions xpserver_ext -extfile xpextensions -infiles newreq.pem openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 -clcerts -passin pass:$password -passout pass:$password openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:$password -passout pass: $PASSWORD openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der openssl pkcs12 -des3 -in $1.p12 -out $1-key.pem -passin pass:$password -passout pass:$password # Clean Up rm -rf newcert.pem newreq.pem Este script crea los certificados der, pem y p12 del servidor cuyo nombre será introducido por línea de la siguiente manera: CA.srv <nombre_servidor> Generación de los certificados de los clientes inalámbricos Los certificados de los clientes inalámbricos sólo son necesarios en caso de conectarse utilizando el método de autenticación EAP-TLS, que necesita la posesión de certificados por las dos partes involucradas en la autenticación. Si se utiliza EAP-TTLS sin embargo, no será necesaria la creación de certificados cliente. En cualquier caso, el siguiente script es el que se utiliza para generar los certificados cliente. CA.clt #!/bin/sh../ca.common export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} export LD_LIBRARY_PATH=${SSL}/lib echo "*********************************************************************************" echo "Creating client private key and certificate" echo "When prompted enter the client name in the Common Name field. This is the same" echo " used as the Username in FreeRADIUS" # Request a new PKCS#10 certificate. # First, newreq.pem will be overwritten with the new certificate request openssl req -new -keyout newreq.pem -out newreq.pem -passin pass:$password -passout pass:$password # Sign the certificate request. The policy is defined in the openssl.cnf file. # The request generated in the previous step is specified with the -infiles option and # the output is in newcert.pem # The -extensions option is necessary to add the OID for the extended key for client authentication openssl ca -policy policy_anything -out newcert.pem -passin pass:$password -key $PASSWORD -extensions xpclient_ext -extfile xpextensions -infiles newreq.pem openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 -clcerts -passin pass:$password -passout pass:$password 35

38 openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:$password -passout pass: $PASSWORD openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der openssl pkcs12 -des3 -in $1.p12 -out $1-key.pem -passin pass:$password -passout pass:$password # clean up rm -rf newcert.pem newreq.pem Al igual que en el caso de CA.srv, el nombre del certificado se introduce por línea de comando: CA.clt <nombre_certificado_cliente> Para poder generar los certificados cliente desde el interfaz WEB, se utiliza otro script similar a este. Así, mediante el interfaz WEB se crea el certificado cliente y la cuenta de usuario en el directorio LDAP simultáneamente Formatos de los certificados Existen varios formatos de certificado. En este prototipo se utilizan 3 formatos que son der, pem y p12. En equipos con sistemas operativos Linux se utiliza el formato pem. De hecho, tanto el servidor de autenticación del sistema, como los clientes inalámbricos Linux utilizan este formato. Sin embargo, los clientes inalámbricos Windows XP utilizan el formato der para el certificado de la Autoridad de certificación (root.der), y p12 para el certificado cliente. Por esta razón, cada vez que se debe generar un certificado, se crean los tres tipos de certificado Openldap Introducción El Protocolo de Acceso Ligero a Directorio, más conocido como LDAP es un protocolo que permite acceder a un directorio de información, muchas veces denominado directorio LDAP. Las características más importantes de LDAP son: Soporta TCP/IP. Muy importante para poder acceder desde cualquier punto, como por ejemplo Internet. Basado en estándares. Funciona bajo cualquier plataforma de computación. Estos directorios están optimizados para procedimientos de lectura y no tanto para los de escritura, por lo que habrá que tenerlo en cuenta a la hora de tomar la decisión de implantar este protocolo, o no. Almacenamiento de datos jerárquico. Estructuras en árbol. 36

39 En este prototipo se ha utilizado LDAP para acceder al directorio de información LDAP, que es donde se almacenan todos los datos necesarios para la configuración del sistema, como pueden ser los puntos de acceso, usuarios, perfiles, ISPs, etc. Todos estos datos son actualizados en reducidas ocasiones, pero el número de veces en que son consultados es elevado, por lo que la utilización de LDAP en este caso parece ser bastante conveniente. Concretamente, en este proyecto se utiliza Openldap, que es servidor LDAP libre [ 0]. A continuación se detalla la instalación, configuración y arquitectura del directorio LDAP utilizada en este prototipo Instalación de Openldap Se ha conseguido la última versión estable de Openldap [ 0]. Esta última versión es openldap-stable tgz. En el proceso de instalación se tuvieron algunos problemas porque era necesaria alguna actualización de varias librerías, concretamente de la librería BerkeleyDB o DB. Así que se ha conseguido la última versión disponible de esta librería, que es db tar.gz [ 0], y se ha instalado antes de instalar openldap. El proceso de instalación ha sido el siguiente: [root@pfc05 open1x]# tar zxvf db tar.gz [root@pfc05 open1x]# cd db /build_unix [root@pfc05 open1x]#../dist/configure --prefix=/dir_base/open1x/berkeleydb [root@pfc05 open1x]# make [root@pfc05 open1x]# make install Aquí apareció otro problema. Openldap no era capaz de saber el lugar donde tenía que buscar la librería db.h, es decir, el configure no da la opción de buscar la librería db.h en un directorio concreto. Para conseguirlo había dos opciones, una era hacer un link a la dirección de la librería, y otra posibilidad era la de realizar un configure en el que se le informa a openldap de donde tiene que buscar las librerías necesarias. Para conseguir esto se ha utilizado CPPFLAGS y LDFLAGS. Esta es la opción que se ha utilizado finalmente. [root@pfc05 open1x]# tar zxvf openldap-stable tgz [root@pfc05 open1x]# cd openldap [root@pfc05 open1x]# env CPPFLAGS=-I/Dir_Base/open1x/openssl/include -I/Dir_Base/open1x/berkeleyDB/include LDFLAGS=-L/Dir_Base/open1x/openssl/lib -L/Dir_Base/open1x/berkeleyDB/lib./configure --prefix=/dir_base/open1x/openldap --with-tls --enable-slurpd --enable-ldbm [root@pfc05 open1x]# make depend [root@pfc05 open1x]# make [root@pfc05 open1x]# make install Certificado: [root@pfc05 open1x]# cd /usr/share/ssl/certs [root@pfc05 open1x]# make slapd.pem [root@pfc05 open1x]# cp usr/share/ssl/certs/slapd.pem /Dir_Base/open1x/openldap/ 37

40 Configuración de Openldap Es necesario configurar LDAP adecuadamente para obtener el comportamiento deseado. Para ello, se deben modificar los archivos de configuración que se muestran a continuación: slapd.conf Este archivo se encuentra en /Dir_Base/openldap/etc/openldap/slapd.conf. Se debe añadir lo siguiente: slapd.conf include /Dir_Base/open1x/openldap/etc/openldap/schema/cosine.schema include /Dir_Base/open1x/openldap/etc/openldap/schema/nis.schema include /Dir_Base/open1x/openldap/etc/openldap/schema/RADIUS-LDAPv3.schema include /Dir_Base/open1x/openldap/etc/openldap/schema/tlm.schema # tlm.schema es el que se utiliza para introducir nuestro schema. # Permisos de lectura y escritura access to * by self write by dn= uid=root,ou=users,dc=tlm,dc=com write by * auth\par\par # Directorio LDAP database ldbm suffix dc=tlm,dc=com rootdn cn=root,dc=tlm,dc=com directory /Dir_Base/open1x/openldap/var/openldap-data En este último directorio es donde se creará la base de datos automáticamente ldap.conf: Se encuentra en el mismo directorio que el anterior. ldap.conf HOST BASE dc=tlm,dc=com URI ldap:// En este archivo se le indica la dirección IP en la que estará escuchando el servidor Openldap y la base del dominio del directorio. En este caso, el Openldap está en , pero podría estar en cualquier otro sitio. Finalmente, se ha creado un script para ejecutar el servidor LDAP que se ha llamado run-ldap: run-ldap #!bin/sh echo "IMPORTANT: " echo " Run as ROOT " echo " " 38

41 OPENLDAP=/Dir_Base/open1x/openldap export PATH= $ {OPENLDAP }/bin: $ {OPENLDAP }/sbin: $ {OPENLDAP}/libexec:$PATH export LD_LIBRARY_PATH=/Dir_Base/open1x/openssl/lib ${OPENLDAP}/libexec/slapd -d 1 Ahora, el servidor ya está configurado y se puede proceder a insertar los datos que se quiera en la base de datos. Para esto se utilizan archivos.ldif, en los que se introduce los datos Ejemplos de funciones LDAP ldapadd Función para agregar datos al directorio LDAP. -v: modo verboso. -W: petición de contraseña. -D: usuario que ejecuta la función. -f: fichero -x: openldap/bin/ldapadd -x -D cn=root, dc=tlm,dc=com f../data.ldif -v W ldapsearch Esta función permite realizar búsquedas en el directorio LDAP. ldapsearch -x D cn=root, dc=tlm,dc=com u b ou=users,dc=tlm,dc=com 'cn=*' cn uprofile v -W Este ejemplo devolvería el campo cn y el campo perfil de todos los usuarios almacenados en el directorio LDAP ldapdel Permite eliminar entradas del directorio LDAP. openldap/bin/ldapadd -x -D cn=root, dc=tlm,dc=com ipaddress= ,ou=aps, dc=tlm,dc=com -v W Este ejemplo eliminaría el punto de acceso con IP del directorio LDAP ldapmodify Esta función se utiliza en caso de querer modificar una entrada del directorio LDAP. La siguiente es una de las maneras en las que se puede utilizar esta función. Se crea un fichero del tipo siguiente: 39

42 Fichero_cambio dn: changetype: modify replace: mail mail: add: title title: Grand Poobah add: jpegphoto jpegphoto: /tmp/modme.jpeg delete: description La orden: ldapmodify -x -D cn=root, dc=tlm,dc=com -b -r -f Fichero_cambio v -W Esto cambiaría el mail del usuario student1, le añadiría la foto y eliminaría la descripción de la entrada del directorio LDAP. En realidad, el mayor número de accesos al directorio LDAP, se realizan desde el interfaz WEB. Por lo tanto, se utilizan las funciones de las que dispone php para realizar estas operaciones. Estas funciones simplifican enormemente la interactuación con el servidor LDAP Arquitectura del directorio LDAP utilizado Los datos almacenados en el directorio LDAP son los correspondientes a los puntos de acceso, usuarios, perfiles de usuario e ISPs. Como se ha comentado en el apartado de introducción, los datos del directorio se organizan en forma de árbol de una manera jerárquica, característica muy recomendable para el tipo de datos que se deben almacenar en este caso. En la Figura 12 se se muestra la arquitectura del directorio LDAP que se ha utilizado en este prototipo para almacenar todos los datos necesarios para el funcionamiento de todo el sistema. De la raíz del árbol parten cuatro ramas que son los puntos de acceso, perfiles de usuario, ISPs y usuarios. De ellos parten las propiedades almacenadas de cada uno de ellos. En algún caso se ha utilizado alguna propiedad o característica más, pero no se ha introducido en la figura porque reducía la claridad de la misma. 40

43 Figura 12:Estructura en forma de árbol del directorio LDAP tlm.schema Este archivo se utiliza para agregar al servidor Openldap las características de los nuevos atributos de los datos que van a ser almacenados en el directorio. tlm.schema ############ Nuevos Atributos Definidos attributetype ( NAME 'uprofile' DESC 'Profile identifier, for example, student' EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'minbw' DESC 'Minimum bandwidth guaranteed in bps' EQUALITY integermatch SYNTAX SINGLE-VALUE ) attributetype ( NAME 'maxbw' DESC 'Maximum bandwidth limited in bps' EQUALITY integermatch SYNTAX SINGLE-VALUE ) attributetype ( NAME 'priority' DESC 'Prority assigned: 1 best, 7 worst. Delay control?' EQUALITY integermatch SYNTAX SINGLE-VALUE ) 41

44 attributetype ( NAME 'reservedpercentage' DESC 'Percentage of bandwidth to reserve to this profile' EQUALITY integermatch SYNTAX SINGLE-VALUE ) attributetype ( NAME 'networkallowed' DESC 'IP network as a dotted decimal, eg / Indicates allowed networks for these user.' EQUALITY caseignoreia5match SYNTAX {128} ) attributetype ( NAME 'networkdenied' DESC 'IP network as a dotted decimal, eg / Indicates denied networks for these user.' EQUALITY caseignoreia5match SYNTAX {128} ) attributetype ( NAME 'ipaddress' DESC 'IP address as a dotted decimal, eg , omitting leading zeros' EQUALITY caseignoreia5match SYNTAX {128} SINGLE-VALUE ) attributetype ( NAME 'snmpcommunityname' DESC 'Community name for accesing the access point using SNMP' EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'apmodel' DESC 'Access Point model (eg. Aironet350)' EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'realm' DESC 'Domain this ISP is serving (ex. tlm.unavarra.com)' EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'url' DESC 'URL where this ISP has its Certification Authoritie (ex. EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'correo' DESC ' (ex. eecs@berkeley.edu)' EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX {256} SINGLE-VALUE ) attributetype ( NAME 'telephone' DESC 'telephone number (ex )' EQUALITY caseignoreia5match 42

45 SYNTAX {128} SINGLE-VALUE ) ############ NEW OBJECTS DEFINED # USERS: # uid= user identifier # gidnumber= group id (type of profile) # Optional attributes: # cn= common name # userpassword= for MD5 authentication # usercertificate= for EAP/TLS authentication # # telephone # description objectclass ( NAME 'user' SUP top STRUCTURAL MUST ( uid $ uprofile ) MAY ( cn $ description $ userpassword $ usercertificate ) ) # PROFILES objectclass ( NAME 'profile' SUP top STRUCTURAL MUST ( uprofile $ minbw $ maxbw $ priority $ reservedpercentage) MAY ( cn $ description $ networkallowed $ networkdenied ) ) # ACESS POINTS objectclass ( NAME 'ap' SUP top STRUCTURAL MUST ( ipaddress $ apmodel $ snmpcommunityname) MAY ( cn $ description ) ) # ISPs objectclass ( NAME 'isp' SUP top STRUCTURAL MUST ( realm $ url) MAY ( cn $ description ) ) Con este archivo, se introducen los nuevos atributos y clases de objeto que se utilizarán en el prototipo. Al introducir una nueva clase de objeto, como son los puntos de acceso, los ISPs, los perfiles y los usuarios, se le indica a LDAP que atributos deben contener obligatoriamente y cuales son opcionales. En el caso de los ISPs por ejemplo, serán obligatorios los atributos de realm y url, siendo opcional el atributo de cn data.ldif En este archivo se guardan los datos que se quieren introducir al directorio LDAP por línea de comandos. Estos datos se pueden introducir de esta manera, aunque posteriormente se introducirán o modificarán utilizando el interfaz Web. data.ldif # Creación del nodo raíz del directorio LDAP dn: dc=tlm,dc=com objectclass: organization objectclass: dcobject o: Root structure 43

46 dc: tlm ########### Creación de nodos secundarios # Usuarios dn: ou=users,dc=tlm,dc=com objectclass: organizationalunit ou: users description: Users List # Perfiles de usuario dn: ou=profiles,dc=tlm,dc=com objectclass: organizationalunit ou: profiles description: Profiles List # Puntos de acceso dn: ou=aps,dc=tlm,dc=com objectclass: organizationalunit ou: aps description: Access Points List # ISPs dn: ou=isps,dc=tlm,dc=com objectclass: organizationalunit ou: isps description: Providers List ########### Perfiles dn: uprofile=professors,ou=profiles,dc=tlm,dc=com objectclass: profile uprofile: professors cn: professor's profile description: professor's profile - description minbw: maxbw: priority: 1 reservedpercentage: 60 networkallowed: / dn: uprofile=students,ou=profiles,dc=tlm,dc=com objectclass: profile uprofile: students cn: student's profile description: student's profile - description minbw: maxbw: priority: 3 reservedpercentage: 40 networkdenied: / networkallowed: / ########### Usuarios dn: uid=client@tlm.unavarra.com,ou=users,dc=tlm,dc=com 44

47 objectclass: user uid: client uprofile: students cn: student1 userpassword: client description: client student testing dn: objectclass: user uid: uprofile: students cn: Cuenta de prueba **1** userpassword: prueba description: client student testing ########### Puntos de acceso dn: ipaddress= ,ou=aps,dc=tlm,dc=com objectclass: ap ipaddress: apmodel: Aironet350 snmpcommunityname: test cn: Aironet 350 description: Lab ########## ISPs dn: realm=tlm.unavarra.com,ou=isps,dc=tlm,dc=com objectclass: isp realm: tlm.unavarra.com url: cn: Test ISP Una vez preparado este archivo, se añade al directorio LDAP mediante el comando comentado anteriormente: open1x]#./dir_base/openldap/bin/ldapadd -x -D cn=root, dc=tlm,dc=com f data.ldif -v W Freeradius - Proxy Este servidor realiza las labores de proxy del tráfico de autenticación de la red. Reenvía el tráfico 802.1X proveniente del punto de acceso al servidor de autenticación Freeradius-auth y viceversa. Tanto la comunicación entre los servidores Freeradius, como la comunicación con el punto de acceso se realiza mediante RADIUS. La configuración de este servidor será bastante sencilla, al no tener que configurar la parte de autenticación que es la más complicada de realizar. 45

48 Instalación El proceso de instalación del servidor Freeradius es algo más elaborado que el que se acaba de describir. Para empezar, debe ser instalado por duplicado, ya que uno actuará como proxy, y el otro como autenticador. Como en el caso de openssl, se ha conseguido la versión más nueva de Freeradius disponible. [root@pfc05 open1x]# configure --prefix=/dir_base/open1x/freeradius-proxy --with-opensslincludes=/dir_base/open1x/openssl/include --with-openssllibraries=/dir_base/open1x/openssl/lib [root@pfc05 open1x]# make clean [root@pfc05 open1x]# make [root@pfc05 open1x]# make install Para comprobar el correcto proxy/sbin/radiusd X. funcionamiento, se puede ejecutar./radius Configuración Los archivos de configuración del servidor Freeradius-Proxy están en el directorio /Dir_Base/open1x/freeradius-proxy/etc/raddb clients.conf Cambio del SECRET: secret = test Esta es la palabra secreta que se utilizará para encriptar la comunicación con el cliente, que en este caso será el punto de acceso. A continuación, se introduce el cliente con el que se conectará el servidor, es decir, el punto de acceso: client { secret = test shortname = ap1 } radiusd.conf En principio, como este servidor no va a efectuar más que labores de proxy, no es necesario realizar ninguna modificación en este archivo proxy.conf Con este archivo se configura el comportamiento del servidor freeradius para actuar como proxy. En este caso, lo que se pretende es que todos los paquetes de tráfico IEEE 46

49 802.1X que provengan del punto de acceso y con un dominio tlm.unavarra.com, sean redireccionados al servidor de autenticación. Para esto, se introducen las siguientes líneas en este archivo: proxy.conf realm tlm.unavarra.com { type = radius authhost = :1912 accthost = :1913 secret = test nostrip } Así, todos los paquetes con este dominio, se reenviarán a estas direcciones, que es donde estará escuchando el servidor de autenticación Freeradius-Auth. En este caso, la contraseña permite encriptar la comunicación con el servidor de autenticación. En el archivo clients.conf del servidor Freeradius-auth o servidor de autenticación, deberá estar almacenada la misma contraseña para poder realizar la comunicación correctamente Freeradius - Auth Este es el servidor Freeradius que actuará como Servidor de Autenticación. Este servidor se comunica con el servidor Freeradius-proxy y con el servidor Openldap para realizar la autenticación de los clientes que se conectan al sistema inalámbrico. La comunicación con el servidor Freeradius-proxy se realiza mediante el protocolo RADIUS, sobre el que va la comunicación de autenticación, para lo cual se utiliza el protocolo de autenticación extensible EAP (ver 4). El funcionamiento de este servidor, consiste en recibir un mensaje de petición de autenticación por parte del Freeradius-proxy, realizar el proceso de autenticación EAP con el cliente (si es necesario, acceder al servidor LDAP), y enviar un mensaje de autenticación exitosa o fallida al Freeradius-proxy al concluir el proceso de autenticación. Para que el sistema funciones correctamente, habrá que indicarle al servidor de autenticación donde están los servidores con los que se va a comunicar, qué métodos EAP de autenticación va a utilizar, etc. En fin, se debe configurar correctamente Instalación En lo que a la instalación se refiere, lo único que cambia con respecto a la anterior es el directorio de instalación: [root@pfc05 open1x]# configure --prefix=/dir_base/open1x/freeradius-auth --with-opensslincludes=/dir_base/open1x/openssl/include --with-openssllibraries=/dir_base/open1x/openssl/lib [root@pfc05 open1x]# make clean [root@pfc05 open1x]# make [root@pfc05 open1x]# make install 47

50 Configuración Ahora, los archivos de configuración /Dir_Base/open1x/freeradius-auth/etc/raddb se encuentran en el directorio clients.conf El cliente de este servidor es el servidor freeradius-proxy: clients.conf client secret = test radiusd.conf Ahora sí que se debe modificar este archivo para que el autenticador se comporte como nosotros queremos. Para comenzar, se debe cambiar el puerto, que en este caso será el port = 1912 Se va a utilizar LDAP para la autorización y la autenticación, por lo que se debe descomentar la opción de ldap tanto en la parte de authorize como en la de authenticate: authorize { eap ldap } authenticate { Auth-Type LDAP { ldap } eap } Ahora se deben introducir los datos de LDAP en el apartado de LDAP de radiusd.conf: Ldap { server = " " identity = "cn=root,dc=tlm,dc=com" password = tlm basedn = "dc=tlm,dc=com" } 48

51 En principio, no es necesario modificar nada más de este erchivo eap.conf Este archivo no existía como tal en versiones anteriores de freeradius, sino que se encontraba dentro del archivo radius.conf. En este archivo se configura la parte concerniente a EAP. En principio, se pondrá por defecto el modo de autenticación eap-tls, pero más adelante se puede cambiarlo en función de lo que nos pueda interesar: default_eap_type = tls En este prototipo solo se van a utilizar los tipos md5, tls y ttls, así que únicamente se tendrá que modificar estos si es que es necesario. En el caso de md5 no hay que modificar nada. A continuación se introduce la parte del archivo eap.conf perteneciente a tls y ttls. md5 { } tls { private_key_password = client private_key_file = ${raddbdir}/certs/server.pem certificate_file = ${raddbdir}/certs/server.pem CA_file = ${raddbdir}/certs/root.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 include_length = yes } ttls { default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no } proxy.conf Freeradius-auth no va a actuar como proxy, por lo que no es necesario cambiar nada de este archivo. 49

52 2.3.8 DHCP (Dynamic Host Configuration Protocol) Este protocolo se utiliza para asignar a los clientes DHCP todos los parámetros de red necesarios en una conexión. Esta asignación se realiza dinámicamente. Es muy útil ya que evita la configuración manual de red cada vez que se acceder a una red. Y esto es muy interesante porque además de más rápido y sencillo, se supera el problema que puede surgir por no conocer esos parámetros como pueden ser la dirección IP, máscara, router por defecto, etc Se ha instalado el rpm adecuado para la versión de Linux con la que se ha trabajado que es Red Hat 7.2. [root@pfc05 open1x]# rpm -i dhcp-2.0p15-8.i386.rpm Arrancar el Servidor DHCP: [root@pfc05 open1x]# dhcpd eth0 Parar el Servidor DHCP: [root@pfc05 open1x]# /etc/rc.d/init.d/dhcpd stop Archivo de configuración del servidor DHCP Es preciso especificar el comportamiento del servidor DHCP. Esto se realiza mediante el archivo de configuración /etc/dhcpd.conf. El archivo de configuración que se puede observar bajo estas líneas es el archivo que se ha utilizado para configurar el servidor DHCP que se ha utilizado en el sistema AWNAS. Pese a que la configuración del servidor se realiza con las primeras siete líneas del archivo, se ha optado por dejar las siguientes (aunque comentadas) para servir a modo de ejemplo en otras posibles configuraciones del servidor. /etc/dhcpd.conf: # option option-128 code 128 = string; # option option-129 code 129 = text; subnet netmask { option subnet-mask ; option broadcast-address ; option routers ; option domain-name-servers , ; option domain-name "tlm.unavarra.com"; range dynamic-bootp ; #option vendor-class-identifier "PXEClient"; # group { # host bomarzo { # next-server bomarzo.tlm.unavarra.com; 50

53 # # # # # # # # # # # } hardware ethernet 00:10:4B:D2:17:4C; fixed-address ; } host clon { option host-name "clon.tlm.unavarra.com"; hardware ethernet 00:C0:4F:8A:7B:A0; option option-128 e4:45:74:68:00:00; option option-129 "NIC=3c509 IO=0x300"; fixed-address ; } } Con este archivo de configuración, se le informa al servidor DHCP de las siguientes características en su funcionamiento: La subred con la que va a funcionar y su máscara de red. Dirección de broadcast. Router por defecto. Los clientes DHCP tendrán el router por defecto que se especifique en este campo. En el caso de este proyecto, el router por defecto de los clientes inalámbricos debe ser el interfaz eth0 del pfc05, es decir, (ver Figura 11). Servidores de nombre DNS. En este caso se han puesto las direcciones de los servidores de nombre de la red del laboratorio. Rango de direcciones a asignar. Es el conjunto de direcciones IP que podrán ser asignadas por el servidor DHCP a los clientes Apache Se ha instalado el servidor WWW+php para albergar el interfaz WEB que se ha desarrollado basado en html y php. La última versión del servidor http Apache se ha obtenido de y el paquete obtenido es http tar.gz. El proceso de instalación de este paquete ha sido el siguiente: [root@pfc05 open1x]# tar zxvf httpd tar.gz [root@pfc05 open1x]# cd httpd [root@pfc05 open1x]# env CPPFLAGS= -I/Dir_Base/open1x/openssl/include -I/Dir_Base/open1x/berkeleyDB/include LDFLAGS= "-L/Dir_Base/open1x/openssl/lib -L/Dir_Base/open1x/berkeleyDB/lib./configure --prefix=/dir_base/open1x/apache2 --enable-mods-shared=most --enable-so --enable-ssl=static --withssl=/dir_base/open1x/openssl [root@pfc05 open1x]# make depend [root@pfc05 open1x]# make [root@pfc05 open1x]# make install El archivo de configuración de Apache es httpd.conf. Lo único que se ha cambiado en este archivo es el nombre de servidor, el grupo y el usuario. 51

54 user santi group users nameserver tlm.unavarra.com Han surgido bastantes problemas a la hora de instalar el módulo ssl. El problema radicaba en que no le indicaba que cargara el módulo de una manera estática, por lo que lo intentaba hacer dinámicamente y nos daba el siguiente error: mod_ssl: undefined symbol: X509_free De todas maneras, esto puede no ser necesario ya que posteriormente se instaló nuevamente openssl con la opción shared, que parece que arregla este problema Php Para trabajar con PHP, la forma más recomendable de hacerlo es teniendo como ayuda la página Web oficial de php [ 0]. De ahí se pueden obtener los paquetes necesarios para instalar PHP, pero también tiene una ayuda online muy buena. De ahí se ha obtenido la versión php tar.gz. El proceso de instalación ha sido el siguiente: Instalación [root@pfc05 open1x]# tar zxvf php tar.gz [root@pfc05 open1x]# cd php [root@pfc05 open1x]#./configure --prefix=/dir_base/open1x/php --withapxs2=/dir_base/open1x/apache2/bin/apxs --with-openssl=/dir_base/open1x/opoenssl --with-ldap=/dir_base/open1x/openldap --with-config-file-path=/dir_base/open1x/conf1 [root@pfc05 open1x]# make [root@pfc05 open1x]# make install [root@pfc05 open1x]# cp php.ini-dist /Dir_Base/open1x/conf1/php.ini Volviendo al fichero de configuración de Apache httpd.conf, se añade: AddType application/x-httpd-php.php Como se puede apreciar, se le indica dónde tiene el módulo ldap y donde tiene el archivo de configuración que posteriormente se graba en dicho lugar. Uno de los problemas que posteriormente se debe arreglar, es que se ha instalado la versión 3 de ldap (LDAPv3), y esta versión que se ha instalado de php trabaja por defecto con la versión 2 de ldap. Por lo tanto, se deberá modificar la configuración para que php pueda trabajar con la versión 3. Otra alternativa, que es por la que se ha optado finalmente, es la de introducir una función con la que se le avisa a php de que la versión de LDAP que se está utilizando es LDAPv3. Para esto, basta con añadir la siguiente línea justo después de realizar la conexión con el servidor LDAP. $connect_result = ldap_connect( $LDAP_IP, 389 ); ldap_set_option($connect_result, LDAP_OPT_PROTOCOL_VERSION, 3); 52

55 Interfaz Web Se ha desarrollado una herramienta Web para gestionar el sistema AWNAS. Con esta herramienta se puede gestionar y monitorizar el sistema de una manera cómoda y sencilla. A continuación se puede ver el diseño y funcionamiento de esta herramienta. El desarrollo de esta herramienta se ha hecho utilizando php y html. Home: es la página de inicio, en la que simplemente se puede observar el menú que nos permite navegar por la herramienta y un mensaje de bienvenida al sistema. Figura 13: Interfaz Web (Home). Status: información de los interfaces de red: nombre, ancho de banda y dirección IP. También se puede ver el archivo principal de configuración del sistema. Figura 14 y 15: Interfaz Web (Status y archivo de configuración). APs o Puntos de Acceso: lista de puntos de acceso del sistema y sus características principales. Es posible realizar un test de conectividad y acceder a la página del punto de acceso. Figura 16: Interfaz Web (AP). 53

56 Figura 17 y 18: Interfaz Web (ISPs y Autoridad Certificadora). ISPs: lista de ISPs del sistema. Se puede visitar la Autoridad Certificadora y crear los certificados necesarios. Al crear un certificado, el sistema crea la cuenta de usuario en la base de datos automáticamente. Desde aquí se pueden crear los certificados para los clientes necesarios si el método de autenticación utilizado es EAP-TLS. Figura 19: Interfaz Web (Generación de Certificados). Users o Usuarios: listado de los usuarios conectados actualmente al sistema. Al igual que en el caso de los puntos de acceso, se listan las características más importantes de los usuarios. También es posible realizar un test de conectividad o monitorizar un usuario concreto. Figura 20: Interfaz Web (Users). 54

57 Figura 21 y 22: Interfaz Web (LDAP). LDAP: es el editor de la base de datos del sistema. Desde aquí, se pueden hacer consultas a la base de datos e introducir o borrar datos y entradas de la base de datos. Desde aquí se modifican los parámetros de los diferentes perfiles, propiedades de los clientes, puntos de acceso e ISPs. Figura 23 y 24: Interfaz Web (Monitoring). Monitoring: monitorización del sistema AWNAS. Se listan todos los usuarios y puntos de acceso del sistema. De aquí se puede acceder a todas las conexiones realizadas por dichos usuarios y puntos de acceso y monitorizar el tráfico cursado y el tráfico filtrado por el sistema. Este tráfico puede ser filtrado por iptables o tc. También hay un apartado diseñado para monitorizar las pruebas y testeos del sistema FireWall - Iptables Todas las reglas Firewall se introducen utilizando la herramienta iptables. Esta herramienta viene incorporada en las últimas versiones de las distribuciones de Linux y es parte del kernel. Permite introducir reglas Firewall de una manera bastante sencilla y viene a sustituir a la herramienta ipchains que se utilizaba antes. 55

58 El funcionamiento básico de iptables es el siguiente: cuando llega un paquete, se mira si el paquete está destinado a la propia maquina o si va a otra. Para los paquetes (o datagramas, según el protocolo) que van a la propia maquina se aplican las reglas INPUT y OUTPUT, y para filtrar paquetes que van a otras redes o maquinas se aplican simplemente reglas FORWARD. Así, se determina que es lo que se debe hacer con el paquete. Permitirle o denegarle el paso, enrutarlo, etc. INPUT,OUTPUT y FORWARD son los tres tipos de reglas de filtrado. Pero antes de aplicar esas reglas es posible aplicar reglas de NAT: estas se usan para hacer redirecciones de puertos o cambios en las IPs de origen y destino. Incluso antes de las reglas de NAT se pueden meter reglas de tipo MANGLE, destinadas a modificar los paquetes; estas últimas son reglas poco conocidas y no se suelen utilizar. Figura 25: Esquema de funcionamiento de las reglas firewall iptables. Órdenes básicas iptables F : efectivamente, flush de reglas iptables L : listado de reglas que se estan aplicando iptables A : append, añadir regla iptables D : borrar una reglas. Ejemplo de regla: #Regla que acepta conexiones al puerto 80 iptables -A INPUT -i eth0 -s /0 -p TCP --dport www -j ACCEPT Opciones -s : dirección IP origen. Ej: -s /24 -d : destino. Ej: -d p : tipo de protocolo(tcp,udp,icmp). Ej: -p TCP --sport : puerto de origen --dport: puerto de destino -i = in-interface : el interfaz de entrada (eth0,eth1, ppp0, ) -o = --out-interface: el interfaz por de salida (eth0,eth1, ppp0, ) -i se usa con reglas INPUT y FORWARD -o se usa con reglas FORWARD y OUTPUT -INPUT OUTPUT: paquete entrante o saliente. -j ACCEPT: destino del paquete (se acepta, podría ser DROP, LOG, REJECT,..) 56

59 Esta herramienta se utiliza a la hora de configurar el AWNAS como router y como NAT si es necesario (ver ), y al introducir las reglas de Firewall que se introducen para controlar el acceso de los usuarios al sistema (ver ) Control de tráfico tc Un requisito muy importante para cualquier red a la que acceden clientes diversos, es poder repartir los recursos de la red de una manera conveniente. Es decir, interesa tener la capacidad de limitar el ancho de banda de los diferentes clientes. Para ellos, y al igual que se hace para introducir las reglas Firewall, los usuarios se separan por clases o tipos de clientes. En este prototipo, interesa que los clientes que tienen el perfil de profesor tengan reservado un porcentaje dado del ancho de banda para este perfil, y además tienen un máximo y un mínimo ancho de banda por cliente. La herramienta tc o traffic control, permite realizar el control de tráfico y por tanto, introducir estas reglas de QoS para poder utilizar los recursos disponibles de la red en función de las necesidades e intereses. Para ello, la herramienta tc [ 0] permite la creación de clases, colas y filtros que permiten tratar el tráfico o recursos de la red a conveniencia. Existen diferentes tipos de colas, pero en este prototipo se ha utilizado el tipo CBQ, el cual permite trabajar con prioridades. La estructura del árbol de control de tráfico utilizado en este prototipo es la siguiente: Figura 26 y Figura 27: Estructura del árbol de clases del control de tráfico El sistema introduce las reglas de calidad de servicio utilizando las funciones diseñadas a tal efecto (ver ). A continuación se muestran los comandos ejecutados, tanto al iniciar el sistema, como al autenticarse un cliente inalámbrico. 57

60 Reglas iniciales Al iniciarse el sistema, se inicializa el control de tráfico introduciendo las reglas generales de control de tráfico, que son las reglas que permiten que un porcentaje del ancho de banda se reserve para un perfil, y el resto para el otro perfil. Reglas introducidas al iniciarse el sistema # Primero se borra toda posible estructura existente previamente tc qdisc del dev eth0 root # se crea la disciplina de cola cbq tc qdisc add dev eth1 root handle 1: cbq bandwidth allot 1514 cell 8 avpkt 1000 mpu 64 # clase 1:1 tc class add dev eth1 parent 1: classid 1:1 cbq bandwidth rate allot 1514 cell 8 weight prio 7 maxburst 20 avpkt 1000 # clase 1:3 # Es la clase del perfil estudiante, que en este caso tiene asignado el 20% del ancho de banda total. Tiene asignada una prioridad 3. tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth rate allot 1514 cell 8 weight prio 3 maxburst 20 avpkt 1000 {bounded isolated} # Disciplina de cola cbq 3: tc qdisc add dev eth1 parent 1:3 handle 3: cbq bandwidth allot 1514 cell 8 avpkt 1000 mpu 64 # clase 3:1 tc class add dev eth1 parent 3:0 classid 3:1 cbq bandwidth rate allot 1514 cell 8 weight prio 3 maxburst 20 avpkt 1000 # clase 1:2 # Es la clase del perfil profesor, que en este caso tiene asignado el 80% del ancho de banda total. Tiene asignada una prioridad 1. tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth rate allot 1514 cell 8 weight prio 1 maxburst 20 avpkt 1000 {bounded isolated} # Disciplina de cola cbq 2: tc qdisc add dev eth1 parent 1:2 handle 2: cbq bandwidth allot 1514 cell 8 avpkt 1000 mpu 64 # clase 2:1 tc class add dev eth1 parent 2:0 classid 2:1 cbq bandwidth rate allot 1514 cell 8 weight prio 1 maxburst 20 avpkt 1000 Con estos comandos se crea la estructura de control de tráfico que se muestra en la Figura

61 Este mismo esquema se utiliza para configurar el control de tráfico del interfaz eth0, cambiando el bandwith por el de este interfaz Reglas para cada usuario Al autenticarse un cliente, se introducen otras reglas de control de tráfico, que sirven para limitar el ancho de banda del cliente en particular, e indicar al sistema la rama por la que debe introducir el tráfico de ese cliente. Reglas introducidas al conectarse un cliente # este filtro limita el ancho de banda ascendente del cliente, que es de perfil profesor a un máximo de bps. tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip src /32 police rate burst mtu 1514 drop classid 1:2 # clase 2:2 tc class add dev eth1 parent 2:1 classid 2:2 cbq bandwith rate allot 1514 cell 8 weight prio 1 maxburst 20 avpkt 1000 # introduce el tráfico procedente la dirección del cliente en la rama 2:2 tc filter add dev eth1 parent 2:0 protocol ip prio1 u32 mantch ip src /32 flowid 2:2 Esto habrá que repetirlo para el interfaz eth Pcap Introducción Esta es la librería que se utiliza para realizar la captura de los paquetes en varias funciones que se utilizan a lo largo del proyecto. Esta librería es la que utiliza la famosa herramienta tcpdump. Es una librería muy flexible y con muchas utilidades para realizar diferentes tipos de capturas. Para ello, y al igual que en tcpdump se le debe indicar el tipo de filtro que debe utilizar a la hora de realizar la captura de los paquetes. Pcap trabaja a más bajo nivel, por lo que incorpora una función que compila y traduce los filtros que son inteligibles por las personas a un código cercano a ensamblador, que es un tanto más difícil de comprender. Así, el tipo de filtros que se pueden introducir son del mismo tipo que los que se pueden introducir a tcpdump Instalación Esta librería suele estar incorporada en las últimas versiones de Linux, pero en este caso se ha tenido que instalar. Además, es preferible, ya que como se ha hecho con casi todas las herramientas de este sistema, se ha procurado instalar todo en un directorio base. Se ha conseguido el paquete libpcap tar.gz [ 0]. [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# tar zxvf libpcap tar.gz configure --prefix=/dir_base/libpcap make make install 59

62 Una vez instalada la librería, podrá ser utilizada por los programas que la necesiten añadiéndola a la hora de compilar dichos programas Funciones de interés A continuación se detallan algunas de las funciones más interesantes que aporta la librería pcap. Antes de esto, es necesario saber que casi todos los programas de captura de paquetes que utilizan esta herramienta siguen un patrón parecido. Primero se especifica el interfaz del que se va a capturar el tráfico y se obtienen sus datos de red, ya sea manualmente o utilizando las funciones que pcap tiene para ello. Luego se abre un descriptor de sesión pcap. Una vez hecho esto, se debe introducir el filtro de tráfico que se quiere utilizar, pero como se acaba de mencionar, debe ser compilado previamente. A partir de este punto, se realizará la captura de paquetes de la manera que más convenga Pcap_lookupnet Esta función se encarga se obtener los parámetros de red del interfaz que se le introduce en la entrada Pcap_open_live Abre un descriptor de sesión pcap con el que se trabaja. Este descriptor será la entrada de todas las funciones siguientes Pcap_compile Compila y traduce el filtro a introducir en la captura de paquetes. Se le introduce un string de entrada con un filtro inteligible y lo traduce Pcap_setfilter Esta función es la que introduce realmente el filtro previamente compilado Pcap_next Captura y retorna un paquete. Viene a ser como la fnción pcap_dispatch con el número de paquetes a capturar igual a 1. No trabaja en modo no bloqueante Pcap_setnonblock Fuerza a que las funciones pcap trabajen en modo no bloqueante. Esto es de mucha utilidad en una de las herramientas que se implementan en este proyecto para capturar el primer paquete de un cliente inalámbrico, ya que nos interesa que la ausencia de un paquete no bloquee todo el sistema Pcap_dispatch Sirve para capturar un número determinado de paquetes. Cuando se recibe ese número de paquetes, se ejecuta una función cuyo nombre también se introduce como parámetro de entrada. Esta función puede llamar a esta función sin necesidad de tener en el buffer el número de paquetes establecido a la entrada. Esta función puede funcionar en modo no bloqueante. 60

63 Pcap_loop Esta función y la anterior son muy similares. La diferencia básica radica en que esta función no puede llamar a la función que se introduce como parámetro de entrad hasta que captura el número de paquetes especificado a la entrada. Al igual que pcap_next, no trabaja en modo no-bloqueante. 2.4 Clientes del Sistema Es necesario que los clientes que desean conectarse a la red inalámbrica incluyan mecanismos o herramientas para poder realizar la autenticación basada en IEEE 802.1X, que permita la autenticación mediante EAP y asigne claves WEP de una manera dinámica. En este proyecto se han utilizado dos Clientes distintos: uno para equipos móviles con sistema operativo Windows XP, y otro para equipos que utilicen Linux como sistema operativo Windows XP El propio Windows XP incorpora las herramientas necesarias para poder realizar una conexión inalámbrica utilizando IEEE 802.1X, incluyendo la posibilidad de Autenticar utilizando EAP-MD5 o EAP-TLS. Es decir, se puede autenticar mediante login-password (md5), o mediante certificados (tls). Tiene como inconveniente que no soporta el método de autenticación EAP-TTLS por si mismo. En este caso, lo único que se debe hacer, es configurar la conexión inalámbrica e instalar los certificados. Este proceso es bastante sencillo. De todas formas, en uno de los anexos se detalla todo este proceso de una manera más detallada (ver 4) Xsupplicant Xsupplicant es el cliente de este sistema para Linux basado en el proyecto open1x. Es un cliente que actualmente se encuentra en desarrollo, por lo que la documentación es escasa y su configuración bastante complicada. Soporta una gran cantidad de métodos de autenticación (EAP-MD5, EAP-TLS, EAPTTLS, CHAP, LEAP ). Se han utilizado varias versiones de esta herramienta con las que han surgido una gran cantidad de problemas. Finalmente, y cuando se estaba trabajando con la versión CVS, publicaron una nueva versión estable con una documentación bastante detallada. De todas formas, a continuación se indica la manera en la que se puede obtener la versión cvs: cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/open1x co xsupplicant 61

64 Si en algún momento se pide el password, se presiona enter. Así se obtiene el archivo xsupplicant.tgz, que es la versión CVS de este paquete. Antes de instalar la versión que se ha utilizado finalmente, se estuvo trabajando con la versión CVS, y aunque daba más problemas, se descubrió que el driver de la tarjeta inalámbrica no soportaba la asignación de claves WEP de una manera dimámica, por lo que era necesario parchear este driver. Finalmente se han utilizado dos parches diferentes, uno para posibilitar que la tarjeta pueda trabajar con WEP dinámicas, y el otro para deshabilitar el modo promiscuo de la tarjeta [ 0]. El día 15 de junio, se colgó de la página la nueva versión de Xsupplicant, junto con una documentación bastante interesante. Se decidió entonces instalar está nueva versión de Xsupplicant que funciona correctamente. A continuación se detalla el proceso que se ha seguido para instalar, tanto los parches necesarios, como la nueva versión de Xsupplicant: Instalación de Xsupplicant El directorio de instalación será: /Dir_base_cliente/open1x donde Dir_base_cliente puede ser sustituido por lo que al instalador le convenga. [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# tar zxvf xsupplicant-1.0.tar.gz configure --prefix=/dir_base_cliente/open1x make make install Como se ha comentado, es necesario poner dos parches al driver Orinoco que utiliza la tarjeta inalámbrica que se utiliza en este prototipo: [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# [root@pfc05 open1x]# tar zxvf orinoco-0.13e.tar.gz patch -p0 < /xsupplicant/drivers/linux/ rekey_patch_orinoco-0.13e cd orinoco-0.13e patch -p0 < orinoco-no-promisc-patch En este punto, si se ejecuta el make sin tener instaladas las fuentes del kernel, aparecerá un mensaje de error. Así que es necesario instalar las fuentes del kernel que se pueden encontrar en los discos de la versión de Linux que se esté utilizando. Se está utilizando red hat 9 para el cliente. En este caso, las fuentes se encuentran en el disco número 2. [root@pfc05 open1x]# rpm -i kernel-source.rpm Se han instalado los tres rpm-s referentes al kernel, pero con instalar el arriba indicado es suficiente. Ahora, no debe dar ningún problema. [root@pfc05 open1x]# make [root@pfc05 open1x]# make install 62

65 Configuración En los archivos de configuración de Xsupplicant se especifica el funcionamiento de Xsupplicant. Se especifica la red a la que se debe conectar, el tipo de esta red, si esta es alámbrica o inalámbrica, etc. También se configura el método de autenticación que se va a utilizar en el proceso de autenticación. Para configurar el interfaz inalámbrico y ejecutar Xsupplicant se utiliza el siguiente script. run-tls #!/bin/bash # Configuración del interfaz inalámbrico y lanzamiento de Xsupplicant ifconfig eth1 up # ifconfig eth iwconfig eth1 essid tlm.unavarra.com iwconfig eth1 key # Xsupplicant /Dir_base_cliente/open1x/xsupplicant/sbin/xsupplicant c tls.conf i eth1 d 6 El primer comando activa el interfaz eth1 que es el que se va a utilizar para realizar la conexión inalámbrica. El segundo le pone una dirección IP al interfaz, pero aparece comentado porque se desea que la dirección IP sea asignada dinámicamente por el sistema mediante DHCP. En cualquier caso, se ha puesto una dirección cualquiera dentro del intervalo que nos interesaba para hacer las pruebas pertinentes.. La tercera línea le indica al interfaz inalámbrico el essid de la red inalámbrica a la que se desea acceder. Finalmente, se le pone una key al interfaz con el único propósito de activar el cifrado de la transmisión de datos inalámbrica.. El proceso de autenticación se encarga posteriormente de poner las llaves adecuadas. Una vez configurado el interfaz inalámbrico, se ejecuta el comando necesario para activar el cliente Xsupplicant, indicándole el fichero de configuración, el interfaz inalámbrico que debe utilizar y el nivel de debug Archivos de configuración de Xsupplicant A continuación, se pueden observar los diferentes tipos de archivos de configuración que se han utilizado. El archivo será diferente en función del tipo de autenticación que se utilice EAP-MD5 Este primer archivo de configuración es el que se utiliza en caso de realizar la autenticación denominada EAP-md5. md5.conf: # This is an example configuration file for xsupplicant versions after 0.8b. ### GLOBAL SECTION # network_list: defines all of the networks in this file which # should be kept in memory and used.comma delimited list or "all" # for keeping all defined configurations in memory. For efficiency, 63

66 # # # # keep only the networks you might roam to in memory. To avoid errors, make sure your default network is always in the network_list. In general, you will want to leave this set to "all". network_list = tlm.unavarra.com #network_list = default, test1, test2 # default_netname: some users may actually have a network named "default". # since "default" is a keyword in the network section below, you can # change which is to be used as the replacement for this keyword default_netname = tlm.unavarra.com #default_netname = my_defaults # In the startup_command, first_auth_command, and reauth_command you can # use "%i" to have xsupplicant fill in the interface that is being used. # This allows a single network profile to work across different wireless # cards. # startup_command: the command to run when xsupplicant is first started. # this command can do things such as configure the card to associate with # the network properly. startup_command = <BEGIN_COMMAND>echo "Xsupplicant en modo md5 en ejecución..."<end_command> # first_auth_command: the command to run when xsupplicant authenticates to # a wireless network for the first time. This will usually be used to # start a DHCP client process. first_auth_command = <BEGIN_COMMAND>dhclient %i<end_command> # reauth_command: the command to run when xsupplicant reauthenticates to a # wireless network. This may be used to have the dhcp client rerequest # it's IP address. reauth_command = <BEGIN_COMMAND>echo "authenticated user %i"<end_command> # When running in daemon, or non-foreground mode, you may want to have the # output of the program. So, define a log file here. Each time XSupplicant # is started, this file will be replaced. So, there is no need to roll the # log file. logfile = /root/client/xsupplicant.log # The auth_period, held_period, and max_starts modify the timers in the state # machine. (Please reference the 802.1X spec for info on how they are used.) # For most people, there is no reason to define these values, as the defaults # should work. #auth_period = 30 #held_period = 30 #max_starts = 3 # Defining an interface in "allow_interfaces" will bypass the rules that # xsupplicant uses to determine if an interface is valid. For most people # this setting shouldn't be needed. It is useful for having xsupplicant # attempt to authenticate on interfaces that don't appear to be true # physical interfaces. (i.e. Virtual interfaces such as eth0:1) 64

67 #allow_interfaces = eth0, wlan0 # Defining an interface in "deny_interfaces" will prevent xsupplicant from # attempting to authenticate on a given interface. This is useful if you # know that you will never do 802.1X on a specific interface. However, # allows will take priority over denies, so defining the same interface in # the allow_interfaces, and deny_interfaces will result in the interface # being used. #deny_interfaces = eth1 ### NETWORK SECTION # The general format of the network section is a network name followed # by a group of variables. # Network names may contain the following characters: a-z, A-Z, 0-9, '-', # '_', '\', '/' # Those interested in having an SSID with ANY character in it can use # the ssid tag within the network clause. Otherwise, your ssid will # be the name of the network. ## The default network is not a network itself. These values are ## the default used for any network parameters not overridden ## in another section. If it's not in your network configuration ## and not in your default, it won't work!! tlm.unavarra.com { # type: the type of this network. wired or wireless, if this value is not # set, xsupplicant will attempt to determine if the interface is wired or # wireless. In general, you should only need to define this when # xsupplicant incorrectly identifies your network interface. type = wireless # wireless_control: If this profile is forced to wired, this will not do # anything. However, if the interface is forced, or detected to be wireless # XSupplicant will take control of re/setting WEP keys when the machine # first starts, and when it jumps to a different AP. In general, you won't # need to define, or set this value. wireless_control = yes # allow_types: describes which EAP types this network will allow. The # first type listed will be requested if the server tries to use something # not in this list. # allow_types = eap_tls, eap_md5, eap_gtc, eap-otp allow_types = eap_md5 # identity: what to respond with when presented with an EAP Id Request # Typically, this is the username for this network. Since this can # be an arbitrary string, enclose within <BEGIN_ID> and <END_ID> identity = <BEGIN_ID>student1@tlm.unavarra.com<END_ID> # Force xsupplicant to send it's packets to this destination MAC address. # In most cases, this isn't needed, and shouldn't be defined. #dest_mac = 00:aA:bB:cC:dD:eE eap-md5 { username = <BEGIN_UNAME>@tlm.unavarra.com <END_UNAME> 65

68 password = <BEGIN_PASS>client<END_PASS> } } Este primer archivo de configuración está entero, tal y como viene en el paquete de Xsupplicant. Lo único que se ha hecho ha sido realizar los cambios necesarios para que funcione en nuestro sistema. En los siguientes archivos se han eliminado las partes redundantes que están comentadas EAP-TLS Este archivo es el que se ha utilizado en el caso de la autenticación EAP-TLS. tls.conf: network_list = tlm.unavarra.com default_netname = tlm.unavarra.com startup_command = <BEGIN_COMMAND>echo "Xsupplicant en modo TLS en ejecucion..."<end_command> first_auth_command = <BEGIN_COMMAND>dhclient %i<end_command> reauth_command = <BEGIN_COMMAND>echo "authenticated user %i"<end_command> logfile = /root/open1x/cliente/xsupplicant.log ### NETWORK SECTION tlm.unavarra.com { type = wireless wireless_control = yes identity = <BEGIN_ID>student1@tlm.unavarra.com<END_ID> allow_types = eap_tls eap_tls { user_cert = /Base_dir1certs/student1.pem user_key = /Base_dir1certs/ student1-key.pem user_key_pass = <BEGIN_PASS>client<END_PASS> root_cert = /Base_dir1certs/root.pem crl_dir = /Base_dir1certs/crl chunk_size = 1398 random_file = /Base_dir1certs/random session_resume = yes # esto permite retomar una conexión sin la necesidad de tener que realizar nuevamente todo el proceso de autenticación. Así, todo resulta más eficiente y rápido. Ver anexo4. } } En este caso, no se le indica a Xsupplicant ningún login ni contraseña, ya que en este caso en el que se utiliza TLS, la autenticación se realiza mediante certificados. Por lo tanto, lo que se le indica a Xsupplicant es la localización de los dos certificados que necesita para 66

69 la autenticación EAP-TLS, que son root.pem y el certificado cliente, que en este caso y a modo de ejemplo se ha denominado student EAP-TTLS Archivo de configuración de Xsupplicant para autenticación EAP-TTLS. ttls.conf: network_list = tlm.unavarra.com default_netname = tlm.unavarra.com startup_command = <BEGIN_COMMAND>echo "Xsupplicant TTLS en ejecucion..."<end_command> first_auth_command = <BEGIN_COMMAND>dhclient %i<end_command> reauth_command = <BEGIN_COMMAND>echo "authenticated user %i"<end_command> logfile = /root/client/xsupplicant.log ### NETWORK SECTION tlm.unavarra.com { type = wireless wireless_control = yes allow_types = eap_tls identity = <BEGIN_ID>student1@tlm.unavarra.com<END_ID> eap-ttls { # As in tls, define either a root certificate or a directory # containing root certificates. root_cert = /root/client-fuentes/root.pem #root_dir = /path/to/root/certificate/dir crl_dir = /root/client-fuentes/crl chunk_size = 1398 random_file = /root/client-fuentes/random cncheck = <cn of root.pem> # Verify the server certificate # has this value in it's CN field. cnexact = yes session_resume = yes # phase2_type defines which phase2 to actually DO. You # MUST define one of these. phase2_type = chap ## These are definitions for the different methods you might ## do at phase2. only the one specified above will be used ## but it is valid to leave more than one here for convenience chap { username = <BEGIN_UNAME>studen1@tlm.unavarra.com<END_UNAME> password = <BEGIN_PASS>client<END_PASS> } } } 67

70 En este caso, no se utiliza un certificado cliente, así que únicamente es necesario especificar la dirección donde se encuentra el certificado root.pem. Este certificado se utiliza para autenticar al punto de acceso y crear un túnel TLS mediante el que se realiza una autenticación de segundo nivel. Es por esto que se le debe indicar el tipo de autenticación de segundo nivel o fase. En este caso se ha utilizado CHAP, la cual requiere la especificación de login y password, pero puede utilizarse cualquier otra compatible. También es necesario indicarle el cn del certificado root.pem Wire1x Wire1x es un cliente que se supone, es compatible tanto con Linux como con diferentes versiones de windows y está basado en open1x al igual que Xsupplicant. De todas formas, se ha intentado trabajar con esta herramienta bajo Windows XP para poder realizar la autenticación utilizando EAP-TTLS pero no se ha conseguido que funcionara correctamente. Finalmente se ha optado por quedarnos con los dos clientes anteriores. Esta es la apariencia de la ventana principal del interfaz de usuario de Wire 1x para Windows XP. Aquí se elige el tipo de autenticación EAP que se va a utilizar. A modo de ejemplo, se ha puesto la ventana concerniente a EAP-TTLS, en la que se puede observar que pide los mismos parámetros que los que anteriormente se han tenido que configurar mediante los archivos de configuración de Xsupplicant. Sería interesante de cara a futuro, seguir la evolución de esta herramienta. Figura 28 y 29: Wire 1X. Interfaz de Usuario. 68

71 3 Pruebas del Sistema AWNAS Una vez instalado todo el sistema AWNAS correctamente, es deseable comprobar su correcto funcionamiento. Para esto, se han realizado una serie de pruebas con el objetivo de monitorizar el comportamiento del sistema AWNAS, así como para monitorizar el comportamiento de la red. El escenario con el que se han llevado las pruebas se compone de: El sistema AWNAS. Conjunto de clientes Xsupplicant con perfil de profesor. Conjunto de clientes Xsupplicant con perfil de estudiante. Un generador de tráfico iperf en una máquina colocada en la red en la que el sistema AWNAS tiene un interfaz.. La máquina con la que se van a realizar las pruebas, es la máquina pfc06 y su IP es Como se ha comentado en el apartado 2.3.1, esta máquina no puede llegar hasta nuestros clientes wíreless, a menos que se le ponga una ruta específica para el dominio de la red inalámbrica. Esto es lo que se ha realizado. Se le ha introducido una ruta por defecto que apunta al interfaz que tiene el sistema AWNAS en la red del laboratorio(figura 9). Así, sí que podrá comunicarse con los clientes inalámbricos y se pueden realizar las pruebas. route add default gw No se ha colocado clientes Windows para realizar las pruebas de tráfico porque las herramientas de generación de tráfico que se han utilizado corren bajo Linux, aunque esta misma herramienta está también disponible para Windows. Las pruebas han consistido en generar diferentes tipos y velocidades de tráfico para monitorizar los parámetros que eran interesantes realizando una captura del tráfico en la sección inalámbrica y otra en la sección de salida o cableada. Figura 30: Captura del tráfico utilizado para realizar las pruebas. 69

72 3.1 iperf Es el generador de tráfico que se ha empleado para realizar las pruebas [ 0]. La versión con la que se ha trabajado es iperf Se ha utilizado un paquete binario que funciona correctamente tras un $ tar zxvf iperf linux-2.1.tar.gz. Opciones más interesantes: $./iperf [-s - c host] {options} Se le debe indicar a iperf si actúa como servidor (-s), o si lo hace como cliente (-c host), en cuyo caso se le debe indicar el host al que le debe mandar el tráfico que va a generar. -s: modo servidor. -c: modo cliente. -u: tráfico UDP. -t: tiempo de generación de tráfico. -b: velocidad de transmisión o ancho de banda Servidor iperf: $./iperf s para tráfico TCP $./iperf s u para tráfico UDP Cliente iperf: $./iperf c t <tiempo> para tráfico TCP $./iperf c u t <tiempo> -b velocidad para tráfico UDP 3.2 Monitorización de las pruebas Era necesario realizar una buena monitorización de las pruebas con el objetivo de poder observar fidedignamente el comportamiento de la red inalámbrica. Aunque de sobra es conocido que existen herramientas muy potentes para realizar estas operaciones, como puede ser Ethereal, se ha optado por desarrollar las herramientas necesarias para realizar estas funciones. Por lo tanto, se ha desarrollado un capturador de tráfico que introduce los datos de los paquetes que captura en un archivo, y una herramienta que, con los archivos de las capturas de los dos interfaces de red, realiza un procesado para finalmente mostrar una gráfica con un zoom o detalle también introducido como parámetro de entrada. Como en el caso de las funciones que utiliza el sistema para capturar el primer paquete de un cliente para obtener su dirección IP, el capturador de tráfico utiliza la librería pcap para realizar este trabajo, pero en este caso el proceso trabaja en modo bloqueante, ya que lo único que interesa en este caso es que capture paquetes. La herramienta de monitorización de las pruebas se ha incorporado a la interfaz WEB del sistema como un apartado más de la monitorización. Como se hace en la monitorización del sistema, las gráficas se realizan utilizando la herramienta gnuplot [ 0]. 70

73 3.3 Tráfico UDP Primeramente se han realizado una serie de pruebas que tienen como objetivo ver el comportamiento de la red ante tráfico UDP Ancho de banda de la red Inalámbrica El objetivo de esta prueba es determinar la velocidad máxima de transmisión que soporta la red inalámbrica. Para ello, se ha utilizado el esquema que se puede observar en la Figura 31. Se ha colocado un único cliente que genera tráfico UDP a la máxima velocidad posible. Así, será la propia red inalámbrica la que imponga la máxima velocidad de transmisión o ancho de banda. Se han desactivado todas las limitaciones que el sistema puede imponer parar que no altere el comportamiento de la red. Figura 31: Prueba para determinar al máximo ancho de banda de la red inalámbrica. El cliente ha generado tráfico UDP a la máxima velocidad posible durante 200 segundos. Los resultados han sido los siguientes: BW medio = 6,294 Mbps Bytes perdidos = 0 Gráfico 1: Ancho de banda de la red inalámbrica. 71

74 Se puede afirmar que el ancho de banda máximo que alcanza esta red inalámbrica en las condiciones en las que se está trabajando es de 6,3 Mbps. Como se podrá comprobar en pruebas posteriores, este ancho de banda depende del tipo de tráfico y del número de clientes que haya conectados en la red inalámbrica. Así, en ocasiones se puede superar este ancho de banda, aunque de manera no muy significativa. Se dará por bueno este valor máximo calculado Efecto del tráfico en la red inalámbrica en el retardo En ocasiones, tan importante como el ancho de banda es el jitter y retardo del tráfico. Por esta razón, se ha realizado una prueba que trata de observar el efecto que tiene el tráfico de la red inalámbrica en el retardo y jitter de los paquetes. Para realizar la prueba se ha utilizado el famoso ping. Se han enviado paquetes ICMP haciendo ping para medir el retardo y el jitter. La prueba ha consistido en realizar un ping de 50 paquetes para diferentes niveles de congestión de la red inalámbrica. Con este propósito, un cliente se ha encargado de generar el tráfico, y otro se ha encargado de generar los ping. Tráfico de la red inalámbrica (Mbps) Retardo medio del ping (ms) Jitter (ms) 0 0,8 1,6 2,4 3,2 4 4,8 5,6 6,4 2,796 3,074 3,386 3,675 5,201 4,394 5,297 6,76 6,307 0,094 0,545 0,723 0,711 1,627 0,912 2,954 4,298 2,079 Tabla 4: Retardo y jitter del ping. tiempo (ms) Retardo del ping tráfico en la red inalám brica (Mbps) Gráfico 2: Retardo del ping

75 Varianza del retardo del ping tiempo (ms) Tráfico de la red inalám brica (Mbps) Gráfico 3: Varianza del retardo o jitter del ping. Como se puede observar, el retardo de los paquetes aumenta conforme aumenta el tráfico en la red inalámbrica. Esto es lógico, ya que conforme aumenta el tráfico en la red, el número de colisiones entre paquetes es mayor, por lo que el retardo de estos tiende a elevarse. Así mismo, también se ve un aumento en el jitter, aunque la variabilidad de los datos obtenidos ha sido bastante elevada. Esta variabilidad puede ser debida a la falta de precisión de reloj de Linux, que da problemas para precisiones inferiores a 10 ms, que es el rango en el que se mueven los datos obtenidos. Una buena opción para realizar un estudio más detallado sería aumentar la precisión de este reloj Dos clientes: 1 profesor y 1 cliente En este segundo escenario se utilizan dos clientes inalámbricos para generar tráfico. Figura 32: Esquema de prueba de Tráfico UDP con dos clientes Máxima velocidad posible sin limitaciones Poniendo los dos clientes a generar el máximo tráfico posible sin ninguna limitación por parte del sistema, se obtiene un máximo ancho de banda de 6,480 MB, que supera un poco la medida del ancho de banda máximo que se ha obtenido en la prueba anterior. 73

76 Limitación del ancho de banda por perfiles En este caso, se trata de comprobar el funcionamiento de la limitación que se impone desde el sistema de máximo ancho de banda por usuario de cada perfil. Para esto, se pone el máximo ancho de banda del primer perfil, es decir, el de los profesores a 512 kbps, y el del segundo perfil, o estudiantes a 128 kbps. En las siguientes gráficas se puede observar que realmente se ajusta el tráfico saliente a estas limitaciones. Como se está trabajando con tráfico UDP, el exceso de tráfico se elimina. Gráfico 4: Tráfico del primer perfil. Gráfico 5: Tráfico del segundo perfil. Como se puede observar, los dos filtros actúan correctamente, impidiendo que ninguno de los dos clientes supere su máximo ancho de banda asignado por el sistema AWNAS Cuatro clientes: todos del mismo perfil En esta prueba, se ha trabajado con cuatro clientes del mismo perfil. Se han realizado varias pruebas distintas en este escenario. Todo el tráfico ha sido generado por los clientes. Como se puede observar en las diferentes gráficas que aparecen a continuación, los clientes han ido generando el tráfico uno detrás de otro y dejando un tiempo suficiente para poder observar el comportamiento de la red con cada número de clientes. Servidor iperf: IP : /iperf s u Clientes: Tráfico UDP a 2 Mbps BW max/clt: 512 kbps 74

77 Red: La gráfica que puede observar a continuación muestra el tráfico total que hay en cada extremo de la red. Out se refiere a la red externa o cableada, e in se refiere a la inalámbrica. Gráfico 6: Tráfico de la red. Cliente 1: IP: /iperf c u t 1000 b 2000k Gráfico 7: Tráfico del primer cliente. Cliente 2: IP: /iperf c u t 1000 b 2000k Gráfico 8: Tráfico del segundo cliente. 75

78 Cliente 3: IP: /iperf c u t 1000 b 2000k Gráfico 9: Tráfico del tercer cliente. Cliente 4: IP: /iperf c u t 1000 b 2000k Gráfico 10: Tráfico del cuarto cliente. El tráfico de cada cliente es filtrado adecuadamente de acuerdo con la regla de máximo ancho de banda por cliente que está establecido en 512 kbps. Todos los clientes tienen esa tasa de salida. En cuanto al tráfico interno de la red inalámbrica, se mantiene de acuerdo al tráfico generado por los clientes hasta que alcanza su máximo ancho de banda. A partir de este punto, el tráfico interno queda limitado por ese máximo y cada cliente deja se tener sus 2 Mbps que enviaba en un principio. Se pierde la linealidad del tráfico interno o inalámbrico. Con tanto tráfico, la tasa de colisiones tiene que ser bastante alta. En el segundo ensayo, se ha elevado el ancho de banda máximo por cliente para observar el comportamiento de la red cuando el máximo ancho de la red inalámbrica se alcanza antes de alcanzar el máximo ancho de banda por cliente en todos los clientes. Servidor iperf: IP : /iperf s u Clientes: Tráfico UDP a 2 Mbps BW max/prof: 2,5 Mbps BW max/prof: 2 Mbps 76

79 Red: Gráfico 11: Tráfico la red inalámbrica. Cliente 1: IP: /iperf c u t 1000 b 2000k Gráfico 12: Tráfico del primer cliente. Cliente 2: IP: /iperf c u t 1000 b 2000k Gráfico 13: Tráfico del segundo cliente. 77

80 Cliente 3: IP: /iperf c u t 1000 b 2000k Gráfico 14: Tráfico del tercer cliente. Cliente 4: IP: /iperf c u t 1000 b 2000k Gráfico 15: Tráfico del cuarto cliente. En este caso, el tráfico filtrado en un principio es nulo ya que el primer cliente tiene un máximo ancho de banda de 2,5 Mbps, el cual es inferior al tráfico que está cursando. Sin embargo, cuando se conecta el segundo cliente, el sistema comienza a desechar algo de tráfico. Esto sucede debido a que el segundo cliente genera un tráfico de 2 Mbps, pero se debe tener en cuenta que la herramienta iperf genera 2 Mbps de UDP, por lo que la tasa en la capa de enlace o ethernet será superior. Esta cantidad de más es la que hace que se superen los 2 Mbps, que al superar el máximo ancho de banda por cliente de este segundo perfil, es filtrada. Cuando entra en juego el cuarto cliente, se supera el ancho de banda de la red inalámbrica y el tráfico de cada cliente baja, repartiéndose entre todos los clientes. A partir de este momento, como se puede observar en el Gráfico 11, no hay ningún tipo de filtrado por parte del sistema ya que no se alcanza ningún máximo. La limitación está impuesta exclusivamente por el ancho de banda de la red inalámbrica. 78

81 3.4 Tráfico TCP Hasta aquí, todas las pruebas han sido realizadas utilizando tráfico UDP. En esta se utiliza tráfico TCP para observar el comportamiento de la red bajo estas condiciones. TCP es un protocolo de transporte, que al contrario que UDP, controla el flujo de datos adaptándose a los posibles cuellos de botella que se puedan encontrar en el recorrido de dicho tráfico. Así, el tráfico filtrado o desechado por saturación de algún cuello de botella se minimiza Tráfico TCP con un único cliente Se ha utilizado el escenario ya utilizado anteriormente en la primera prueba que se ha realizado anteriormente con UDP. Se ha utilizado un único cliente y un servidor iperf. Figura 33 Esquema de la prueba TCP con un único cliente. El objetivo de esta prueba es observar el comportamiento del sistema ante tráfico TCP. Para conseguirlo, se han realizado capturas del tráfico para diferentes máximos anchos de banda por cliente. BWmax-perfil = 128 kbps Gráfico 16: Tráfico TCP. 79

82 BWmax-perfil = 256 kbps Gráfico 17: Tráfico TCP. BWmax-perfil = 512 kbps Gráfico 18: Tráfico TCP. BWmax-perfil = 1024 kbps Gráfico 19: Tráfico TCP. 80

83 BWmax-perfil = 2048 kbps Gráfico 20: Tráfico TCP. BWmax-perfil = sin limitación Gráfico 21: Tráfico TCP Se observa como TCP se intenta adaptar al ancho de banda de la red, pero no termina de conseguirlo, ya que se puede observar que el tráfico desechado se mantiene más o menos constante a lo largo del tiempo. Esto puede ser debido a que la conexión TCP se realiza entre máquinas colocadas muy cerca una de la otra, por lo que los tiempos de retransmisión de los paquetes no se calculan de manera correcta, retransmitiéndose constantemente paquetes que son desechados por el filtro del sistema. Con valores de máximo ancho de banda pequeños, como son los dos primeros casos, el tráfico TCP se mantiene en torno al máximo ancho de banda impuesto por el sistema, pero a medida que este ancho de banda va aumentando, el tráfico de salida aumenta, pero no en la misma medida. De hecho, el ancho de banda baja hasta la mitad del máximo ancho de banda máximo permitido. Esto, sin embargo, no ocurre en el caso en el que no hay límite ninguno por parte del sistema. En este último caso, el tráfico se acerca bastante al máximo ancho de banda de la red inalámbrica. Se ve como TCP tiene un tráfico de retorno o respuesta. TCP va mandando ACKs y paquetes que van informando al servidor de parámetros distintos concernientes a la conexión TCP (ACK, tamaño de la ventana, ). Por lo tanto, y al contrario que en UDP, existe un tráfico que en principio no sirve para enviar datos. 81

84 3.4.2 Tráfico TCP con varios clientes Primero se ha colocado el servidor iperf en la máquina y se han realizado varias pruebas con tres y cuatro clientes simultáneamente Tráfico TCP desde servidor hacia clientes inalámbricos Figura 34: Tráfico TCP desde los clientes. Gráfico 22: Tráfico por perfiles con los clientes como destino. Gráfico 23: Tráfico total en la red. En este caso, el máximo ancho de banda del primer perfil es de 2,5 Mbps, mientras que el del segundo perfil es de 2 Mbps. Como se observa en el Gráfico 23, el tráfico TCP se adapta bastante bien a la limitación impuesta por la red, desechándose muy poco tráfico. 82

85 Tráfico TCP desde clientes inalámbricos hacia En este caso, el tráfico es generado por la máquina colocada en el laboratorio con dirección IP Figura 35: Tráfico TCP desde Gráfico 24: Tráfico por perfiles con los clientes como origen. Gráfico 25: Tráfico total en la red. Los máximos anchos de banda se han mantenido iguales que en el caso anterior. Sin embargo, en este caso se puede apreciar mucho mejor los instantes en los que se incorpora cada cliente a la transmisión TCP. Primero comienza la transmisión un único cliente del primer perfil, que como se puede observar en el Gráfico 25, pierde algo de tráfico. Posteriormente, se suma un segundo cliente del segundo perfil. Finalmente se incorporan otros dos clientes, uno de cada perfil. Es en este momento cuando menos tráfico se pierde. 83

86 3.4.3 Tráfico TCP desde una máquina remota y lejana Para poder observar como se adapta TCP a los posibles cuellos de botella, es interesante realizar una prueba en la que haya tráfico TCP entre dos puntos no demasiado cercanos entre sí, ya que el estar demasiado cerca puede provocar que no se haga una buena estimación de tiempos de retrasmisión de paquetes, evitando así que el tráfico se adapte de una manera adecuada al ancho de banda mínimo. Para realizar esta prueba, se ha tenido que variar notablemente la configuración del sistema AWNAS. El sistema está colocado dentro del laboratorio de telemática y las conexiones a Internet se realizan a través de un proxy, por lo que si se quere realizar una conexión TCP a larga distancia, es necesario conectar es sistema a una dirección IP pública. Al cambiar las direcciones IP del sistema, se deben adaptar también algunos archivos de configuración. A continuación se detallan los cambios que se han realizado en el sistema para realizar esta prueba Configuración del sistema con IP pública A continuación se muestran las direcciones IP que se han utilizado en el desrrollo de esta prueba: IPeth1: IPeth0: IPAP: IPcliente: Proxy-ARP Es necesario que eth1 haga de proxy ARP. Así, eth1 estará comunicando a los demás de que se puede llegar a la dirección a través de él. echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp Actualización de interfaces de red la configuración [ ]# ifconfig eth netmask [ ]# ifconfig eth netmask [ ]# route add default gw <router_unavarra.> dev eth Actualización de la tabla de rutas Rutas directas a los host que están en la parte interna de la red: [ ]# route add host dev eth0 84 de los

87 [ ]# route add host dev eth Adaptación de los servidores DNS /etc/resolv.conf: Nameserver <dns_primario> Nameserver <dns_secundario> Nameserver <dns_terciario> Cambios en la configuración de AWNAS: Es necesario cambiar el archivo client.conf del servidor freeradius-proxy, ya que el cliente pasa a ser , que es la nueva dirección del access point. Por la misma razón se debe cambiar la IP del AP en la base de datos donde se guardan los datos del AP Cambios en la configuración del punto de acceso Se debe cambiar la dirección IP del punto de acceso, la dirección IP del servidor de autenticación y router por defecto, que pasa de a Cambios en la configuración del cliente Como se pretende trabajar con IP asignadas estáticamente, se para el servidor DHCP en el sistema y se comenta la línea del archivo de configuración de Xsupplicant referente a dhcpclient. También es necesario que el router por defecto del cliente sea Una vez configurado el sistema, se puede proceder a realizar la prueba. Esta consiste en bajar un archivo de gran tamaño desde un servidor para realizar el estudio del tráfico utilizando diferentes limitaciones del máximo ancho de banda por usuario. Cada prueba consiste en bajar el archivo StarOffice-7.0.iso de la dirección En la siguiente figura se muestra un esquema del escenario sobre el que se han realizado las pruebas: 85

88 Figura 36: Tráfico TCP desde una máquina remota. El resultado de las pruebas realizadas es el que sigue a continuación. Para cada ancho de banda se muestra la gráfica en la que se monitoriza el tráfico descendente. La diferencia entre las 2 líneas es el número de bps desechados por el sistema al superar el máximo ancho de banda permitido por este. BWmax-perfil = 128 kbps troughputmedio-descendente = 110 kbps Gráfico 26: Tráfico TCP. BWmax-perfil = 256 kbps 86 troughputmedio-descendente = 163 kbps

89 Gráfico 27 Tráfico TCP. BWmax-perfil = 512 kbps troughputmedio-descendente = 205 kbps Gráfico 28 Tráfico TCP. BWmax-perfil = 1024 kbps troughputmedio-descendente = 393 kbps Gráfico 29 Tráfico TCP. BWmax-perfil = 6 Mbps troughputmedio-descendente = 1,193 Mbps Gráfico 30 Tráfico TCP. Se observa muy claramente que el tráfico se adapta al máximo ancho de banda permitido, aunque se sigue perdiendo algo de tráfico. El ancho de banda entrante al sistema AWNAS varía de un caso a otro debido a que TCP controla el flujo de tráfico y evita que 87

90 la red se sature o congestione debido a un exceso de tráfico que va a ser desechado. En este caso, TCP sí tiene tiempo para realizar una buena estimación de los tiempos de retransmisión, por lo que la adaptación mejora notablemente. Al igual que ocurría en la prueba 3.4.1, el tráfico no sigue exactamente la misma dinámica que el máximo ancho de banda por usuario impuesto por el sistema. Es decir, si el máximo ancho de banda por usuario se dobla, el tráfico de la red aumenta, pero no se dobla. Esto puede deberse a diveras razones, como pueden ser la falta de precisión del reloj de Linux, o el desechado de los paquetes por ráfagas en lugar de desechar un paquete de cada n. En cualquier caso, requeriría un estudio más detallado. En el caso de UDP, para todos los valores del ancho de banda máximo por usuario, el tráfico entrante al AWNAS habría sido similar, con lo que el tráfico perdido habría sido mucho mayor al igual que la congestión de la red. Una de las contrapartidas que se observa de TCP, es que el tráfico ascendente es muy superior al caso de UDP. 4 Conclusiones y líneas futuras Se ha desarrollado un sistema integrado que permite una Gestión de la red inalámbrica de una manera sencilla y segura. El sistema realiza la autenticación basado en IEEE 802.1X y los métodos de autenticación utilizados han sido EAP-TLS y EAP-TTLS. Se ha comprobado el correcto funcionamiento de ambos para clientes Linux, pero para clientes Windows XP el sistema sólo funciona correctamente con el método EAP-TLS. El sistema asigna claves WEP de una manera dinámica, por lo que la privacidad de la comunicación mejora notablemente. Se han realizado pruebas para verificar que las claves varían con el tiempo. Se ha implementado un nuevo mecanismo que permite conocer la dirección IP de un usuario mediante la captura del primer paquete IP que el cliente envía a la red. Esto, evita tener que realizar esta tarea utilizando un método que depende del tipo de punto de acceso utilizado, por lo que el sistema deja de depender del tipo de punto de acceso para funcionar correctamente. Esto le da flexibilidad al prototipo desarrollado. Se ha conseguido un sistema compatible con clientes Windows XP y Linux, lo que da flexibilidad al sistema, ya que en la actualidad, una gran mayoría de los potenciales clientes de este tipo de sistemas utilizan estos sistemas operativos. La herramienta desarrollada puede resultar muy interesante a nivel comercial debido a que permite controlar el acceso a la red mediante métodos robustos y sencillos de utilizar para el cliente, además de poder asignar recursos a los clientes en función de los permisos de que disponga este cliente. Estas características son muy aconsejables en toda red inalámbrica dedicada a ofrecer servicio a cambio de una retribución. 88

91 Siguiendo con el caso de destinar el sistema a gestionar una red inalámbrica para conseguir beneficio económico, sería muy aconsejable evolucionar el interfaz, consiguiendo un interfaz todavía más cómodo y completo. Sería de gran utilidad incorporar una herramienta de tarificación para facilitar el cobro a los usuarios del sistema. En lo que al desarrollo tecnológico del sistema se refiere, hay varias vías que se pueden seguir para mejorar la herramienta. Una línea de investigación, puede ser la realización de nuevas pruebas al sistema para optimizar su funcionamiento. Sería conveniente realizar las pruebas necesarias para comprobar el correcto funcionamiento del control de tráfico, y si es necesario, cambiar el diseño de las reglas de este control de tráfico. En este proyecto se ha comprobado el correcto comportamiento de las reglas de máximo ancho de banda para cada usuario, en el caso de UDP, pero las pruebas realizadas con tráfico TCP necesitan realizarse con mayor precisión. Además, no se han realizado las pruebas de la respuesta del sistema ante las reglas de reserva de un cierto ancho de banda para cada perfil. Es decir, no se ha verificado si el sistema es capaz de reservar un ancho determinado para un perfil de una manera eficaz. Sería interesante aumentar la precisión de reloj de Linux para conseguir unos resultados al realizara las pruebas más precisos. Esta línea consiste básicamente en perfeccionar el sistema actual para que tenga un funcionamiento más fino. Otra vía puede ser el realizar un estudio más extenso de la herramienta Wire1X, que actualmente no se ha podido utilizar. Se recuerda que esta herramienta está en desarrollo y que actualmente da bastantes problemas. Sin embargo, cuando funcione correctamente permitirá, según sus creadores, utilizar el sistema independientemente del tipo de sistema operativo del cliente. Wire1X funciona tanto para Linux, como para todas las últimas versiones de Windows. Si no se puede introducir Wire1X, sería de gran interés desarrollar una herramienta que facilitara la conexión de los clientes Linux. En la actualidad, toda la configuración y ejecución del programa cliente Suplicante se realiza desde línea de comandos, lo que es un impedimento para gente que no tenga cierto dominio de Linux. Teniendo en cuenta la evolución que están teniendo las redes inalámbricas, es necesario estar al corriente de las nuevas estrategias que se van desarrollando para aportar seguridad a las redes inalámbricas. Actualmente, parece que el futuro de las redes inalámbricas se dirige hacia la implantación de IEEE i que es un estándar que introduce una capa entera dedicada a la seguridad. Este estándar se basa en IEEE 802.1X y en versiones actualizadas de encriptación que son una evolución de la actual encriptación WEP, por lo que podría interesar realizar un estudio de la posible implantación de esta especificación en un futuro cercano. 89

92 Bibliografía IEEE 802.1X [ 0] Real Security WI-FI Protected Access and Jon Edney and William A. Arbaugh. Ed Addison-Wesley. Este libro, es un libro que aborda el problema de la seguridad en redes inalámbricas en toda su globalidad. Es muy interesante para prácticamente todos los puntos de este proyecto. WIFI [ 0] Punto de Acceso [ 0] [ 0] 47c.html En esta dirección se pueden ver las especificaciones del punto de acceso Aironet 350 Series de Cisco. [ 0] Tarjeta inalámbrica [ 0] RADIUS [ 0] Es la página oficial de Freeradius. Aquí se puede obtener todo lo necesario para utilizar Freeradius: paquete Freeradius, documentación, etc EAP [ 0] 90

93 [ 0] [ 0] [ 0] rbirri.9online.fr/howto/freeradius_+_ttls.html LDAP [ 0] Es la página oficial de Openldap. Aquí se pueden obtener los paquetes necesarios para la instalación de Openldap, y la documentación necesaria. [ 0] [ 0] inter14.unsl.edu.ar/wiki/soporte/ldap Openssl [ 0] Aquí se puede encontrar todo lo necesario para utilizar Openssl. Se puede bajar el paquete openssl que se necesite, ya sea estable, cvs, etc También hay bastante documentación. [ 0] Documentación en la que se hace una introducción a la generación de certificados. PHP [ 0] Es la página más completa sobre php. Aquí se puede obtener cualquier versión de php. Además hay una documentación muy extensa que incluye un manual de programación en php muy completo y sencillo de utilizar. Apache [ 0] Es la página oficial de Apache. Se puede obtener tanto documentación como versiones de Apache. Xsupplicant [ 0] Es la página oficial de Xsupplicant. Aquí se puede adquirir la versión de Xsupplicant necesaria y una documentación bastante completa y reciente. [ 0] Ejemplos de archivos de configuración de Xsupplicant, aunque con la documentación más reciente de esta se ha quedado desfasada. [ 0] En esta dirección se pueden obtener uno de los parches necesarios para el driver Orinoco. También expone las razones por las que es necesario parchear este driver. Windows XP [ 0] DHCP [ 0] pacodebian.iespana.es/pacodebian/dhcp.html Iptables-Routing [ 0] Tutorial de iptables en castellano y bastante sencillo de entender. Pcap [ 0] 91

94 [ 0] tc [ 0] Tutorial de la herramienta tc. Iperf [ 0] dast.nlanr.net/projects/iperf/iperfdocs_1.7.0.html#tuningudp Gnuplot [ 0] [ 0]The RC4 encryption algorithm. RSA Data Security, inc Anexos ANEXO I. I.i. WEP: Wired Equivalent Privacy Introducción Durante los primeros 5 años de vida, IEEE solo tuvo un método definido para dar seguridad. Este se denomina WEP, Privacidad Equivalente a Cable. Conforme fueron adquiriendo popularidad, las redes inalámbricas fueron llamando la atención de la comunidad que se dedica a la criptografía, que rápidamente detecto los problemas de la técnica WEP. Así, a finales de 2001 era fácil encontrar herramientas en Internet con las que romper esta técnica de seguridad en poco tiempo. En todo caso, es mejor utilizar esta técnica que no utilizar ninguna, y en algunos casos será suficiente para evitar cierto tipo de ataques. La seguridad de WEP se basa en confiar en que no se pueda obtener la clave secreta (key) de una manera sencilla. La dificultad de que un atacante obtenga la llave privada depende de la longitud de esta llave y de la frecuencia de renovación de esta clave. WEP se auto sincroniza para cada mensaje. Cada paquete que se envía debe ser encriptado independientemente a los demás. Esto significa que obteniendo el paquete y la clave se obtiene toda la información necesaria. Actualmente, se utilizan claves de 128 bits, aunque fuera del estándar. En el estándar aparecen dos partes diferenciadas en lo que seguridad WEP se refiere. La primera es la de autenticación, y la segunda es la de encriptación. En cualquier caso, la 92

95 autenticación que ofrece WEP es muy básica y muy fácil de corromper. Para autenticar, lo que se hace es lo siguiente: el equipo móvil realiza una petición de autenticación al punto de acceso (AP), y este le contesta con un desafío de autenticación. El cliente o equipo móvil manda un nuevo mensaje probando que conoce la clave secreta. El punto de acceso verifica esto, y en caso de ser correcto manda otro mensaje de autenticación exitosa. I.ii. Privacidad La privacidad es el objetivo máximo de WEP. La privacidad es solo una componente más de la seguridad, y puede que no sea necesaria, pero en el caso de las redes WI-FI es un atributo muy deseable. I.iii. Encriptación El algoritmo de cifrado WEP se utiliza tanto para dar privacidad como integridad de datos mediante un algoritmo de encriptación basado en RC4 [ 0]. Figura 37: Esquema de Encriptación WEP. En la Figura 37, se muestra el esquema de la encriptación WEP. El algoritmo de integridad únicamente consiste en un CRC de 32 bits que se añade al final de la trama MAC. Para el proceso de encriptación se utiliza como clave un secreto compartido por los extremos y un vector de inicialización (IV) que se concatena con esta clave compartida. El resultado de esta operación se utiliza como semilla para el generador de números pseudoaleatorios (PRNG), que genera una secuencia de bits de la misma longitud que la trama MAC + CRC. El cifrado es simplemente un XOR entre las dos cadenas de bits que se realiza bit a bit. I.iv. Desencriptación El proceso inverso que se realiza para obtener la secuencia de datos original a partir de los datos encriptados se muestra en la Figura

96 Figura 38: Esquema del Descifrado y revisión de integridad WEP. En el receptor, el vector de inicialización (IV) se concatena nuevamente con la clave compartida, que es la misma clave que posee el emisor, obteniendo así la misma secuencia pseudoaleatoria. Con esta secuencia se obtiene nuevamente los datos, que si al realizar nuevamente el CRC de estos datos obtenidos, concuerda con el CRC recibido, se podrá tener la certeza de que los datos son los emitidos originalmente. Este esquema de encriptación es muy sencillo y no requiere una gran capacidad computacional, pero tiene el inconveniente, que se comenta en la introducción de que no aporta demasiada seguridad, ya que la clave compartida es fácilmente descifrable. Los sistemas actuales, como es el caso del sistema que se desarrolla en este proyecto, utilizan claves WEP, pero estas cambian periódicamente, por lo que el nivel de seguridad mejora notablemente. ANEXO II. Extensible Authentication Protocol (EAP) Protocolo de autenticación extensible. II.i. Introducción EAP es el protocolo de autenticación que utiliza IEEE 802.1X para realizar la autenticación. En algunos aspectos, se puede decir que EAP funciona como un representante de actores o actrices de cine. El agente es quien presenta al director de la película y al actor o actriz. Posteriormente se queda aparte para que las dos partes puedan hablar, y finalmente vuelve a tomar la palabra para cerrar la reunión. EAP tiene una lista de mensajes que son usados para realizar las introducciones y para cerrar los diálogos. Estos mensajes son utilizados por los diferentes métodos de autenticación específicos. EAP no se encarga de la autenticación propiamente dicha, sino que habilita la comunicación de una manera estándar. Los mensajes de los métodos específicos de autenticación, los cuales pueden ser propietarios o abiertos, se suelen denominar mensajes intermedios, ya que se envían después de la introducción y antes del cierre. La razón por la que se denomina extensible a este protocolo es que sobre este protocolo se puede implementar cualquier método de autenticación. Se puede utilizar md5, tls, ttls, peap, o cualquier otro que pueda ir sobre EAP. Incluso nosotros podríamos crear un método propio para utilizar sobre EAP. EAP define unas normas estándar para realizar 94

97 la comunicación de autenticación y posibilita que los métodos específicos realicen su labor. Para ello EAP especifica 4 tipos de mensaje. 0 8 Tipo 16 Identificador Datos 32 Longitud Figura 39: Formato de mensaje EAP. II.ii. Mensajes EAP Valor Nombre 1 Request 2 Response 3 Success Lo manda el autenticador para indicar que el acceso ha sido aceptado. Failure Lo manda el autenticador para indicar que el acceso ha sido rechazado. 4 Descripción Se utiliza para mandar mensajes desde el autenticador al suplicante Se utiliza para mandar mensajes desde el suplicante al autenticador. Tabla 5: Mensajes EAP Es el servidor de autenticación el que genera el request, success, o failure, y el punto de acceso reenvía únicamente el mensaje al suplicante. Los mensajes Request y Response se subdividen mediante el campo de Tipo EAP. El campo de Tipo indica que información es transportada por el mensaje EAP. Los 6 primeros tipos están definidos en el estándar, y todos los demás están reservados para los métodos específicos de autenticación. El tipo predefinido más importante es el de Identificación (tipo=1). Típicamente es utilizado como parte de la introducción de EAP. El servidor de autenticación manda el mensaje EAP-Request/Identity al nuevo suplicante, y este responde con el mensaje EAP-Response/Identity con la identidad y otros posibles identificadores. Los mensajes de Success y Failure, son mensajes cortos que no contienen datos. Uno de estos dos mensajes es el que se envía al final como señal de acceso concedido o rechazado. Al ser estos mensajes más cortos, los puntos de acceso pueden detectar el momento en el que se completa la autenticación sin necesidad de conocer los detalles del método de autenticación. El punto de acceso debe esperar el mensaje de aceptación proveniente de RADIUS o servidor de autenticación. Esta característica permite que los métodos de autenticación sean transparentes para el punto de acceso. En la parte de datos es donde va toda la información de autenticación. Como se acaba de comentar, los tipos mayores que 6 están reservados para los métodos específicos de autenticación. En el caso de EAP-TLS, el campo de Tipo vale 13, lo que significa que los mensajes EAP que tengan el campo de Tipo con este valor, transportan información del método de autenticación TLS. 95

98 En la mayor parte de los casos, el campo de tipo indica el método de autenticación, pero en algunos casos se utiliza para otros fines: Mensaje de notificación (tipo=2): este mensaje se utiliza para enviar textos del tipo, Por favor, introduce la contraseña. NAK (tipo =3): este se utiliza para indicar que el request que se ha recibido contenía un campo de Tipo con un valor asociado a un método de autenticación no soportado. Es decir, si el suplicante solo soporta EAP-TLS y recibe un Request con el Tipo de EAP-TTLS, mandará un NAK diciendo que no entiende ese método. Identity (tipo=1): este tipo puede ser considerado como mensaje de propósito especial, o como un método muy simple de autenticación: o EAP-Identity Request (desde el servidor de autenticación). o EAP-Identity Respnse (desde el suplicante). o EAP-Success (desde el servidor de autenticación). Obviamente, este no es un buen método de autenticación debido a que solo se basa en la comparación de un login con las listas de usuarios permitidos, pero puede ser utilizado en pequeñas redes domésticas que no requieran seguridad, o por redes que utilicen claves secretas pre-establecidas. Al ser tomado Identity como método completo de autenticación, cuando Identity es utilizado por cualquier otro método de autenticación, se están utilizando dos métodos de autenticación en secuencia. A esto se le denomina autenticación en serie y significa que se pueden utilizar varios métodos de autenticación en cadena. Esta característica es muy interesante, y permite cosas como la autenticación de la red por parte del suplicante antes de revelar su propia identidad. II.iii. Diálogo EAP Todos los diálogos EAP tienen la misma estructura básica. 96

99 Figura 40: Diálogo EAP Todos los diálogos tienen la estructura que se muestra en la Figura 40. Cuando un cliente quiere conectarse a la red, envía un EAP-start que inicia el diálogo. Entonces el servidor de autenticación le pide la identidad, a lo que el cliente le responde con un mensaje en el que le envía la identidad. A partir de este punto, se deja la conversación en manos del método específico de autenticación que se encargará de realizar las operaciones necesarias para realizar la autenticación. Este proceso se realiza mediante mensajes Request y Response. Finalmente, el servidor de autenticación envía el Success si la autenticación ha sido exitosa, y un Failure si ha resultado negativa. II.iv. EAPOL La RFC de EAP no especifica como se deben enviar los mensajes, de hecho, no se especifica como se debe transportar los mensajes a través de Internet usando IP. Se puede decir que EAP no es un protocolo LAN en su totalidad. Esto puede ser debido a que originalmente, EAP fue diseñado para autenticar usando modem (dial-up). Luego es necesario encapsular los mensajes EAP de alguna manera para poder transportarlos por nuestra red. Para esto, IEEE 802.1X define un protocolo llamado EAP Over Lan (EAPOL), que nos permite transportar los mensajes EAP entre el autenticador y el suplicante. IEEE 802.1X describe EAPOL para LAN Ethernet (IEEE 802.3) y Token-Ring, pero no para IEEE , así que si se quiere mandar un mensaje EAP, se tendrá que ponerle una cabecera MAC Ethernet y mandarlo por la red. EAPOL sirve para encapsular los mensajes EAP, pero todos los mensajes no transportan mensajes EAP. Algunos mensajes EAPOL se utilizan para realizar tareas administrativas. A continuación se muestran los tipos de mensajes existentes. Mensajes EAPOL 97

100 EAPOL-Start: Cuando un suplicante se conecta a la LAN, no conoce la dirección MAC del autenticador. De hecho, no sabe si hay algún autenticador para atenderle. Para solucionarlo, IEEE 802.1X define el mensaje EAPOLStart. El suplicante envía este mensaje a una dirección MAC multicast reservada para autenticadores IEEE 802.1X con el fin de saber si hay algún autenticador y para darse a conocer. En muchas ocasiones, el autenticador es notificado previamente de la existencia del suplicante mediante métodos hardware. Esto también pasa en los hub, los cuales saben si hay algún cable conectado antes de que el equipo conectado envíe ningún dato. Posteriormente, el autenticador manda un EAP-Request Identity usando un EAPOL-Packet. EAPOL-Key: El autenticador manda las llaves de encriptación al suplicante una vez que ha decidido admitirlo en la red. Lógicamente, es necesario encriptar las llaves antes de enviarlas, pero IEEE 802.1X no especifica la forma de hacerlo. EAPOL-Packet: Este tipo sirve para encapsular los mensajes EAP. Simplemente hace las labores de contenedor para poder transportar los mensajes EAP a través de la red, que es el objetivo original de EAPOL. EAPOL-Logoff: Indica que el suplicante desea desconectarse de la red. La versión de protocolo siempre vale 1. Esto puede cambiar en el futuro. El Tipo de Paquete indica el tipo de mensaje EAPOL: start, key... En algunos casos, no es necesario enviar nada en el campo de datos. Por lo tanto, el campo de length se pone a cero y se omite el campo de datos. Secuencia de Autenticación Cuando el suplicante quiere conectarse, intenta llamar la atención del autenticador. En la mayoría de los casos, el autenticador es alertado por el proceso de conexión. En el caso inalámbrico, suele ser suficiente con la asociación con el punto de acceso. Si no, se puede utilizar un mensaje de EAPOL-Start. El autenticador responde con un EAP-Request/Identity message. Este mensaje es equivalente a preguntar, Quién anda ahí? El punto de acceso está capacitado para saltar este paso si previamente ya ha obtenido identidad del suplicante utilizando algún otro método. El suplicante responde con EAP-Response/Identity. En este punto, es interesante comentar que el suplicante no ha autenticado al punto de acceso, luego no sabe si se está conectando a un punto seguro. Por esta razón, el suplicante puede utilizar un seudónimo, evitando de esta manera dar la identidad a un posible atacante. En este punto es donde entra en juego la figura del servidor de autenticación. Una vez que el suplicante le envía ese mensaje de identidad, el autenticador (punto de acceso en nuestro caso) empieza a actuar como un mero intermediario entre el suplicante y el servidor de autenticación. Así se intercambiarán los mensajes necesarios para realizar la autenticación con el método que se haya elegido y sin la necesidad de que el autenticador entienda dichos mensajes. 98

101 El autenticador hace las labores de intermediario de los mensajes EAP que no entiende hasta que recibe un EAP-Success o EAP-Failure. Estos mensajes sí que los entiende. Entonces, permite o deniega el acceso al suplicante. II.v. EAP sobre RADIUS: RADIUS dispone de dos mensajes para realizar autenticación, que son AccessRequest para enviar datos del punto de acceso al servidor RADIUS, y Access-Challenge para enviar datos del servidor RADIUS al punto de acceso. Este último mensaje tiene un propósito bastante particular, pero con el fin de adaptarlo a EAP, en la RFC 2869 se estableció que este mensaje era más general y que se utilizaría para enviar datos del servidor al NAS. Por lo tanto, los mensajes EAP son enviados al servidor RADIUS en mensajes Access-Request, y al NAS en mensajes Access-Challenge. En ocasiones, un mensaje EAP puede transportar más de un atributo. Puede ser necesario copiar algún atributo del mensaje EAP en algún otro campo del mensaje RADIUS. Un ejemplo puede ser la identidad de los usuarios; esta información va en los mensajes EAP-Response/Identity. El mensaje EAP será transportado íntegramente, pero la identidad será copiada también en el atributo Name (tipo=1) para que RADIUS funcione correctamente. EAPOL utiliza un paquete EAPOL-Start para indicar que un nuevo equipo quiere conectarse. En este mensaje se incluye el valor 79 en el campo de tipo indicando que hay atributo EAP. Figura 41: Proceso de autenticación. En la Figura 41 se observa que los mensajes se transportan entre el punto de acceso y el cliente encapsulados en paquetes EAPOL, y encapsulados en paquetes o mensajes RADIUS entre el punto de acceso y el servidor de Autenticación RADIUS. Esta es la idea más importante que nos debe quedar de este apartado. 99

102 Ahora bien, nos queda por comentar un detalle bastante importante. En las redes que utilizan modems dial-up para conectar los clientes a la red, basta con realizar la autenticación al iniciarse la sesión, pero se supone que a partir de ahí la seguridad está casi garantizada. Sin embargo, esto no sucede así en las redes inalámbricas, que es nuestro caso. Una vez realizada la autenticación, es muy sencillo atacar el sistema sin más que suplantar la dirección MAC del cliente legal de la sesión. Es necesaria pues, una mayor seguridad e integridad de los datos transmitidos. Para esto, el servidor manda al punto de acceso una Llave Maestra. Para mandar información relacionada con la llave maestra, Microsoft introdujo un atributo denominado MS-MPPE-Recv-Key. II.vi. Transport Layer Security (TLS) Netscape, que en los inicios de Internet era el navegador dominante, desarrollo SSL con el objetivo de dar seguridad a la red de redes. SSL se basa en la utilización de certificados. Proporciona una manera de autentificar tanto un extremo, como los dos extremos involucrados en la comunicación, y además permite abrir una comunicación privada mediante encriptación. Pese a que SSL es una solución propietaria, finalmente se convirtió en estándar. Este fue el nacimiento de TLS, que no es más que la versión estandarizada de SSL. Su descripción completa se encuentra en IETF RFC TLS es un protocolo de la capa de transporte y está construido sobre TCP/IP. Funciones de TLS TLS proporciona más servicios que los estrictamente necesarios para realizar Autenticación. Provee servicios de autenticación, encriptación e incluso compresión de datos. Es un método muy conveniente para utilizarlo en el modelo EAP/IEEE 802.1X. TLS está dividido en dos capas: record protocol y handshake protocol. Record protocol es el responsable de intercambiar los datos de los dos extremos finales del enlace utilizando los parámetros adecuados vía protocolo handshake. Los datos procedentes de la aplicación llegan a la capa de record protocol, donde son encriptados y comprimidos (si es el caso) adecuadamente antes de ser enviados al otro extremo. Suponiendo que el otro extremo es válido, descomprimirá y desencriptará los datos sin problemas. 100

103 Application Application TLS Handshake ProtocolTLS Record ProtocolTCP/IPNetwork Hardware TLS Handshake ProtocolTLS Record ProtocolTCP/IPNetwork Hardware Figura 42: Tls handshake y record protocol. El protocolo handshake utiliza al protocolo record para realizar su trabajo, que consiste en establecer las condiciones o parámetros necesarios para realizar la comunicación. En un principio, el record protocol manda los datos sin encriptación ni compresión alguna. El record protocol opera de acuerdo a un grupo parámetros llamado Estado de la conexión o Connection State. Así se intercambia información del tipo de cual es el algoritmo de encriptación, cuales son las llaves de encriptación, etc. El record protocol puede guardar cuatro estados de conexión, dos estados de conexión para cada dirección de la comunicación. Dos estados son los que se utilizan, y los otros dos están pendientes. La diferencia entre el actual y pendiente es que el actual se refiere a los ajustes o parámetros que se están utilizando actualmente, y los pendientes se refieren a los que están preparados para utilizar cuando se den las condiciones adecuadas. Cuando el pendiente pasa a actual, se crea un nuevo estado pendiente. Cuando se inicializa una conexión, el estado actual tiene el valor de NULL. No hay llaves o claves, no hay métodos de encriptación ni compresión. El handshake protocol se encarga de establecer los parámetros de seguridad en el estado pendiente. En el momento en el que todo está preparado, este estado pendiente pasa a estado actual y en ese momento se ponen en marcha las medidas de seguridad, como es la encriptación. TLS utiliza certificados para realizar la autenticación. Normalmente es el servidor el que entrega el certificado al cliente para que este lo verifique y se asegure de que el servidor es de confianza, aunque hay ocasiones en las que el cliente también debe entregar el certificado para que el servidor pueda también hacer la verificación. Los certificados se basan en criptografía de clave pública. Está técnica tiene un gasto computacional bastante grande comparándolo con el método de llave simétrica. En consecuencia, el handshake utiliza la técnica de encriptación de llave pública en la fase de autenticación y también se utiliza para establecer las llaves de la sesión, las cuales serán utilizadas por el record protocol para encriptar los datos en el transcurso de la sesión. Así, la carga computacional se reduce notablemente. 101

104 Fase Handshake Es la fase en la que se establecen las condiciones que van a regir el transcurso de la comunicación, métodos de encriptación, llaves, etc. Este proceso se realiza mediante una serie de mensajes que se envían las dos partes con un orden establecido. Para iniciar el handshake, las dos partes deben mandar un hola. TLS no es simétrico, por lo que un extremo deberá actuar como servidor y el otro como cliente. Normalmente, es el cliente quien inicia este diálogo enviando su hola (client Hello). Figura 43: Esquema de la fase Handshake Client Hello El Hola del cliente es más que un saludo de cortesía, contiene una lista de datos necesarios para la comunicación como son los métodos de compresión soportados por el cliente, el tipo de certificados, método de encriptación, método de chequeo de integridad, además de contener la identidad del cliente. Este mensaje también contiene un número aleatorio (ClientHello.random) que posteriormente será utilizado para dificultar la tarea de posibles atacantes que se encuentren grabando los datos transmitidos. Server Hello Cuando el servidor recibe el Client Hello, se asegura de que soporta los métodos soportados por el cliente y envía su hola. El Server Hello contiene un número aleatorio (ServerHello.random) distinto al enviado por el cliente y un identificador de sesión denominado Session ID, que será utilizado tanto por el cliente como por el servidor. Server Certificate Este mensaje no es necesario en caso de que la sesión este siendo retomada. El servidor le manda su certificado al cliente. Este certificado contiene el nombre del servidor y la llave pública de este. Esto sirve para encriptar los datos que se quieran enviar posteriormente al servidor y para validar los mensajes procedentes del servidor. El certificado está firmado por una Autoridad de Certificación, garantizando así, la 102

105 autenticidad del certificado. El cliente valida el certificado usando la llave pública del certificado de la Autoridad de Certificación que él posee. Una vez hecho esto, guarda la llave pública del servidor para encriptar los datos que envíe al servidor. Es posible que uno se haga pasar por el servidor copiando y enviando posteriormente el certificado del servidor, pero aun así, no podrá desencriptar los datos enviados por el cliente ya que no dispone de la llave privada. Es necesario conocer el par llave pública/privada para poder desencriptar los datos. Client Certificate No ha sido muy utilizado hasta ahora, ya que normalmente se utilizaba en entornos en los que un servidor ofrecía una página WEB o un servicio a un cliente, y era este el que tenía que autenticar al servidor, pero el cliente no debía ser autenticado. Esto está cambiando en la actualidad, debido a la necesidad de controlar el acceso de clientes a las redes corporativas, ya sean redes empresariales, redes inalámbricas, etc. Por esto, existe la posibilidad de que el servidor le pida al cliente que le envíe el certificado. Client Key Exchange (client server) Ahora se debe crear una llave secreta entre el cliente y el servidor llamada Master Secret. Está llave es generada utilizando el número aleatorio incluido en el mensaje hola (Hello message) y un valor secreto creado dinámicamente y que solo es conocido por las dos partes. El número aleatorio incluido en el mensaje de hola no va encriptado, por lo que cualquiera que este escuchando puede obtener dicho número. Por el contrario, el valor aleatorio creado en esta fase, conocido como pre-master secret, es secreto y es utilizado para generar la llave master key. La manera más sencilla para generar la llave pre-master secret y conseguir enviarla tanto al cliente como al servidor, es utilizar el certificado del servidor. El cliente genera un número aleatorio (48 bytes), encripta este número utilizando la llave pública del servidor, y se lo envía al servidor mediante un mensaje client key exchange. El servidor desencripta utilizando su llave privada y obtiene la llave pre-master secret, estando los dos en posesión de dicha llave. Client Certificate Verification Una vez que el cliente ha enviado su certificado, debe demostrar que es el verdadero propietario de ese certificado. Para probarlo, realiza un hashing o una mezcla con los mensajes enviados y recibidos hasta este momento y los firma con la llave secreta de su certificado. Cuando el servidor recibe este mensaje, chequea la firma utilizando la llave pública del cliente. Si tanto la firma como el hashing es correcto, el servidor puede estar seguro de que el cliente es el propietario legal del certificado. Nota: Cuando se habla de Hashing, se refiere a realizar una serie de operaciones con unos mensajes determinados, de tal forma que se obtiene como resultado otro mensaje con el que no es posible obtener los mensajes anteriores. Al enviar este hashing firmado con la llave secreta del certificado del cliente, el servidor puede verificar la firma, y además puede verificar si el hashing es el correcto, ya que el dispone de los mismos mensaje con los que el cliente ha hecho este hashing. Si verifica las dos cosas, sabe que el cliente es legal. 103

106 El método de Hashing es muy utilizado en criptografía. Se basa en obtener un valor resultante de dos o más fuentes de tal manera que no sea posible obtener uno de los valores originales sabiendo los demás valores originales y el resultado del hashing. Es decir, se trata de hacer una operación que no sea invertible. Se suele utilizar para proteger claves, como por ejemplo la llave maestra (master key) o para obtener un método de integridad de datos. En el caso de la llave maestra, se realiza un hashing entre la llave maestra y la hora actual, obteniendo una llave c. Si un atacante obtiene la hora y la llave c, no era capaz de obtener la llave maestra. Una vez realizada la verificación del certificado del cliente, se puede proseguir con el proceso de autenticación. Ahora, los dos extremos contienen la misma información para poder obtener la llave maestra: Pre-master secret. Client random number. Server random number. Los dos combinan estos valores criptográficamente realizando un hashing para obtener una Llave Maestra de 48 bytes. Los dos extremos del enlace de comunicación están ya en posesión de la misma llave maestra. Cambio del estado de la conexión El objetivo del handshake es autenticar y crear estado de la conexión pendiente preparado para conmutar cuando las claves y demás requerimientos sean satisfechos. Cuando se pasa de pendiente a estado actual, cada extremo debe mandar un mensaje en el que se indica que se ha realizado esta conmutación en el estado de la conexión mediante un change connection state. Finished Es el mensaje que se envía para cerrar la fase de handshake. Este mensaje está encriptado con la llave maestra (master key). En este mensaje se manda un hashing de llave maestra y de todos los mensajes enviados en la fase de handshake a excepción del de Finished. Cuando el otro extremo recibe este mensaje y lo verifica, todo está preparado para que se empiecen a transmitir datos utilizando la llave maestra. Si la sesión TLS está siendo retomada, el cliente y el servidor pasan directamente del Hello al mensaje de Finished, estableciendo una nueva llave maestra utilizando los nuevos valores aleatorios (Hello message). Este proceso evita toda la fase de autenticación mediante certificados realizada previamente, pero mantiene la seguridad, ya que la llave pre-master solo es conocida por los dos extremos autenticados originalmente. II.vii. TLS sobre EAP Aunque TLS fue diseñado para ser utilizado sobre TCP/IP, fue definido de una manera más general, de manera que es posible utilizarlo también sobre EAP. 104

107 La utilización de EAP permite que no sea necesaria una dirección IP y de está manera poder realizar el proceso de handshake antes incluso de tener una dirección IP. Esto es muy interesante para equipos móviles que se quieren conectar a una red inalámbrica. Es importante comentar que es necesaria otra herramienta para pasar los mensajes EAP del punto de acceso al servidor de autenticación. Esta herramienta es el protocolo RADIUS. 105

108 ANEXO III. Punto de Acceso En este anexo es una pequeña introducción al punto de acceso utilizado en este proyecto. Básicamente, es un recorrido por interfaz Web que se utiliza para la configuración del punto de acceso. Figura 44: Punto de Acceso: Aironet 350 Series (Cisco) Herramienta de Gestión y Administración del Punto de Acceso Para acceder a la página del punto de acceso que es la dirección que se ha utilizado para el punto de acceso en este proyecto. Home: Es la página de inicio del punto de acceso. En ella se pueden ver los últimos logs y algún que otro parámetro del punto de acceso como la dirección IP del mismo 106 Network: Da información del punto de acceso.

109 107

110 108

111 109

112 Associations: Listado de equipos conectados al punto de acceso. Se puede observar el estado de cada equipo asociado, e incluso se puede realizar un test de conectividad Setup: Es el menú desde el cual se controla el punto de acceso. Desde aquí se accede a todas las propiedades y características del punto de acceso que es necesario configurar para un correcto funcionamiento del punto de acceso. Security: Desde este apartado se accede User Information, a Authentication Server y a Radio Data Encryption. User information: Información de los privilegios que tiene cada usuario del punto de acceso. Authentication Server: Aquí se le indica al punto de acceso que debe utilizar IEEE 802.1X y también el tipo de servidor de autenticación (RADIUS), la dirección IP de dicho servidor, el puerto en el que está escuchando y la Shared Secret. En el caso de este proyecto, el servidor de autenticación del punto de acceso es el freeradius proxy. 110 AP radio data Encryption (WEP): Tipo de encriptación que debe utilizar el punto de acceso.

113 Ethernet Identification: Dirección IP y máscara del punto de acceso AP Radio Hardware: Características de la parte radio del punto de acceso: ssid, potencia de transmisión, canal radio, frecuencia, modo de funcionamiento de la antena La herramienta es bastante más extensa, pero lo más importante a la hora de utilizar el punto de acceso es lo que aquí se ha expuesto. ANEXO IV. Configuración de Windows XP como cliente Con este anexo se pretende facilitar la labor de configuración de Windows XP como cliente del sistema que ha sido desarrollado en este proyecto. Esta instalación es bastante sencilla, por lo si se siguen los pasos abajo expuestos, windows estará configurado en pocos minutos. Antes de comenzar con el proceso de configuración, se debe comentar que hay importantes diferencias en el comportamiento de Windows XP dependiendo del tipo de actualización de este. Así, con la versión de Windows XP original, no es posible realizar una conexión con encriptación WEP si el punto de acceso está configurado en modo OPTIONAL ENCRYPTION. Así que, en caso de disponer de esta versión, se deberá poner 111

114 el punto de acceso en FULL ENCRYPTION [ 0]. Esto ocurre porque Windows no puede asociarse al punto de acceso. Esto se soluciona simplemente con la instalación del Service Pack 1a. En este proyecto se ha trabajado con la versión actualizada con este pack. Instalación de certificados en Windows XP: Primeramente, tenemos que abrir una consola, por lo que vamos a Inicio Ejecutar y ejecutamos el comando mmc como se puede observar en la figura. Figura 45: mmc Figura 46 y 47: Consola. Archivo Agregar o quitar complemento. Después Pinchamos Agregar. 112

115 Pinchamos en Agregar y posteriormente en Finalizar Figura 48 y 49 Ahora tenemos que instalar los certificados. Primero instalaremos root.der. Hacemos doble clic sobre root.der y windows nos guiará de una manera fácil y sencilla para instalar este certificado correctamente. Instalar certificado. Seleccionamos la segunda pestaña y le indicamos que debe instalar el certificado como Entidad Emisora de confianza. Figura 50 y 51 Finalizar. Ahora instalaremos el certificado del cliente, que es <nombre-certificado>.p12. Hacemos doble clic sobre él. Introducimos la contraseña de la clave privada y seleccionamos Siguiente. 113

116 Figura 52 y 53 En este caso seleccionamos la primera pestaña. Para terminar pinchamos en Finalizar. Figura 54 Configuración del interfaz inalámbrico en Windows XP: Ahora se va a procedes a configurar la conexión de red inalámbrica, para ello, se deben seguir los siguientes pasos: Inicio Panel de Control Conexiones de red. Pinchamos en la conexión inalámbrica con el botón derecho y pinchamos en Propiedades. Figura 55 Vamos a Protocolo Internet [TCP/IP]. Como queremos que el sistema nos asigne direcciones IP dinámicamente, indicaremos que el sistema nos indique la configuración IP del interfaz inalámbrico pinchando en Obtener una dirección IP automáticamente y en Obtener la dirección del servidor DNS automáticamente. 114

117 Figura 56 Ahora vamos a la pestaña de Redes Inalámbricas. Aquí, seleccionamos la red a la que nos queremos conectar y pinchamos en Propiedades. Si no aparece el essid que queremos, pinchamos en agregar y ahí indicamos el essid de la red inalámbrica a la que nos queremos conectar. Posteriormente la seleccionamos y pinchamos en Propiedades. Seleccionaremos las casillas Cifrado de datos (WEP habilitado) e Índice de clave (avanzado). A continuación seleccionamos la pestaña de Autenticación. Figura 57 En este punto debemos hacer un par de aclaraciones. Estamos utilizando Windows XP con la actualización Service Pack 1a. Con esta actualización cambia un poco la organización de de esta parte de la configuración. Para empezar, en la versión actualizada, 115

118 la pestaña de Autenticación está junto con la de Asociación. En la versión sin actualizar, sin embargo, esta pestaña está junto a Redes inalámbricas. Otra diferencia es que en la versión actualizada no puede haber control de acceso mediante 802.1X a no ser que se habilite la encriptación de datos WEP, En la versión original sí que se podía realizar el control de acceso mediante IEEE 802.1X sin encriptación WEP. Seleccionamos la primera casilla para realizar el control de acceso mediante IEEE 802.1X y las otras dos casillas. Como tipo de EAP seleccionamos Tarjeta inteligente u otro certificado. Pinchamos en Propiedades e indicamos el nombre de la Autoridad de Certificación que queremos utilizar. Figura 58 Finalmente aceptamos y ya está configurado el interfaz inalámbrico. Ahora no nos queda más que activarlo pinchando con el botón izquierdo encima del interfaz inalámbrico y pinchando Activar. Si tenemos instalado más de un certificado, nos saldrá una ventana preguntándonos cual queremos utilizar. Elegimos el adecuado. Concluido esto, Windows XP ya esta correctamente configurado para conectarse al sistema inalámbrico que se ha desarrollado a lo largo de este proyecto. 116