| Artículos | 01 DIC 2006

Proteger una red Wireless (y III)

Tags: Histórico
Chema Alonso.
Llegamos al final de este camino de 3 meses de duración sobre la seguridad en las redes wireless y cómo protegerlas. En el número anterior repasamos en profundidad el sistema WPA (Wi-fi Protected Access) y los protocolos que se incluyen en su uso: TKIP, 802.1x, EAPOL y el sistema de autenticación RADIUS. Durante el presente, vamos a continuar hacia delante, empezando por configurar el servidor RADIUS. Más detalles de cómo configurar este servidor pueden encontrarlos en la sección de comunicaciones de este mes.

IAS (Internet Authentication Service)
Vamos a terminar de montar la infraestructura WPA, para lo cual vamos a empezar por poner en marcha nuestro servidor RADIUS. Para una organización, contar con un servidor RADIUS no es sólo una solución segura para conexiones inalámbricas, también es un elemento importante en la autenticación de conexiones VPN (redes privadas virtuales), tanto entre sitios remotos como para clientes, o para las soluciones que se nos vienen encima NAP (Network Access Protection) y que en breve estarán implantadas en todas las empresas.
Si la implantación del servidor RADIUS es algo para pocos usuarios o no se desea implantar un servidor dedicado, se pueden adquirir fácilmente routers y/o puntos de acceso inalámbricos, que incluyen dentro de su firmware pequeños servidores RADIUS con sistema de autenticación EAP-MD5 (en la mayoría de los casos). Lógicamente, ésta es una solución poco escalable ya que, en primer lugar, nos obliga a replicar la base de datos de usuarios dentro del firmware, y además, en el caso de que contemos con 2 o más puntos de acceso, vamos a tener que duplicar estos usuarios en todos los AP, o bien pensar en enlazarlos.
Nosotros vamos a implantar como servidor RADIUS la solución de Microsoft, Internet Authentication Service (IAS). Aunque en Windows 2000 Server se proveía como una descarga adicional, es un servicio que viene de serie en Windows Server 2003, y se instala, como cualquier otro, con la opción del panel de control de Agregar o Quitar Programas. Éste es un componente de red, por lo que habría que seleccionar IAS dentro de este menú (ver captura).
Una vez instalado hay que registrar el servidor RADIUS en el Directorio Activo de nuestra organización, y para ello tenemos tres opciones. La más sencilla se hace desde la consola de administración MMC de IAS; seleccionamos nuestro servidor IAS y elegimos la opción “Regristrar en Directorio Activo” (imagen 2). La artesana es hacerlo manualmente, y añadir la cuenta de máquina de nuestro servidor IAS a los grupos de seguridad IAS y RAS en el Directorio Activo. Por último, podemos hacerlo por comandos (utilizando netsh desde el interfaz DOS del sistema).
Una vez registrado ya podemos proceder a configurar nuestro servidor IAS. Para ellos tenemos tres sencillos pasos a seguir; primero habremos de configurar el registro de conexiones, tanto las correctas como las fallidas, para tener una idea de lo que esta sucediendo con nuestra red. Ésta es una sencilla operación para detectar los intentos de intrusión o las conexiones no habituales de los clientes.
En segundo lugar hay que configurar una Política de Acceso Remoto, es decir, quiénes van a poder conectarse remotamente, o lo que es lo mismo en nuestro entorno, quiénes van a poder realizar una conexión inalámbrica. Para terminar la configuración del servidor, deberemos establecer cuáles van a ser las opciones de conexión, es decir, que mecanismos exigimos para autenticar a los usuarios.

Política de Acceso de Remoto
Con IAS podemos crear políticas de acceso remoto para todo tipo de conexiones: para clientes VPN, para clientes wireless, e incluso para clientes de red, que es en lo que se basa NAP. En este caso vamos a crear una Política de Acceso Remoto para nuestros clientes wireless y vamos a crearla siguiendo el asistente. Seleccionamos la opción de Política de Acceso Remoto y empezamos:
Una vez introducido el nombre de la política llegamos al cuadro de dialogo donde se nos solicita el tipo de Política de Acceso Remoto que estamos creando, como se puede ver en la imagen, tenemos políticas para conexiones VPN, para llamadas de marcado Dial-Up de líneas de telefonía punto a punto, para conexiones inalámbricas, e incluso para conexiones ethernet, que se utilizarán en NAP. Seleccionamos la opción de wireless, lógicamente, y continuamos hacia delante.
Como nosotros deseamos integrar la seguridad de las conexiones dentro de la infraestructura de nuestra empresa, vamos a crearnos dentro de nuestro Directorio Activo un grupo de usuarios, en este caso los llamamos “Malos”, (perdón por el chiste), que serán los usuarios a los que va a afectar esta Política de Acceso Remoto. Es necesario que los usuarios tengan el permiso de marcado, igual que para las conexiones de VPN o Dial-Up, ya que es el permiso que se utiliza para las conexiones remotas. Como esto es un poco engorroso, el seleccionar todos los usuarios y darles ese permiso, se puede utilizar una opción (una vez creada la política con el asistente), en las propiedades, que permite ignorar ese permiso y directamente conceder desde IAS el permiso de marcado, si cumple la Política de Acceso Remoto.
La autorización puede realizarse tanto a nivel de usuarios como a nivel de máquinas, por lo que podríamos realizar una autenticación doble, es decir, usuarios autorizados y máquinas autorizadas.
Una vez elegido el grupo de usuarios deberemos elegir el sistema de autenticación. Las opciones a elegir son dos:
Opción 1: PEAP (Protected EAP), que como vimos el mes pasado, utiliza un canal TLS generado con el Certificado del servidor, en este caso el del servidor IAS. Después elegimos un método de autenticación del cliente que será, o bien contraseña, enviada mediante el protocolo MS-Chap v2, o bien se utilizará directamente un certificado digital del mismo que tendemos en la máquina cliente o una smartcard.
Opción 2: No tenemos canal TLS antes de la autenticación EAP, por lo que utilizamos una autenticación basada en tarjeta inteligente o certificado digital instalado en la máquina cliente.
Con estas opciones hemos terminado de crear la Política de Acceso Remoto para nuestro ejemplo. Es importante tener en cuenta que se pueden crear tantas políticas de acceso remoto como deseemos. Estas políticas se van a evaluar igual que los firewalls (de menor número de orden a mayor), y se aplicará la primera que concuerde. Así, podremos tener conexiones autenticadas desde máquinas, o conexiones válidas desde cualquier máquina para algunos usuarios, o conexiones autenticadas con contraseñas porque son dispositivos que no soportan smartcard, o similares, a necesidad de la infraestructura.
Una vez creada la política podemos, entrando en sus propiedades, definir algunos valores específicos de la misma, como si hay rangos horarios para la conexión, límites de tiempo, la asignación de direcciones IP… para afinar más las opciones de la política.

Política de Petición de Conexión
Ya hemos creado la política para nuestros clientes inalámbricos para que sean (o no), autenticados con nuestro servidor RADIUS. Ahora tenemos que configurar la estructura de autenticación de las peticiones dentro de nuestros servidores RADIUS. Para ello creamos una Política de Petición de Conexión, es decir, cuál es el orden de validación de las conexiones (

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información