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 solo una solución segura para conexiones Wireless, también es un elemento importante en la autenticación de conexiones VPN, 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 todos las empresas.
Si la implantación del servidor RADIUS es algo para pocos usuarios o no se desea implantar un servidor dedicado, se puede adquirir fácilmente Routers y/o Access Points Wireless 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 esta 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 que contemos con 2 o más Access Point 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). Este es que en Windows 2000 Server se proveía como una descarga aparte pero 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. Este es un componente de red por lo que habría que seleccionar IAS dentro de estos.
Imagen 1: Instalación componente IAS
Una vez instalado hay que registrar el servidor RADIUS en el Directorio Activo de nuestra organización, y para ello tres opciones, la fácil: desde la consola de administración MMC de IAS, seleccionamos nuestro servidor IAS y elegimos la opción “Regristrar en Directorio Activo” (figura 2); la artesana: Al final, al hacerlo mediante la consola solo se está añadiendo la cuenta de máquina a ciertos grupos privilegiados, por lo que podemos 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; y por comandos: también se puede realizar el mismo proceso utilizando el comando netsh desde el interfaz de comandos.
Imagen 2: Registrar IAS en Directorio Activo
Una vez registrado ya podemos proceder a configurar nuestro servidor IAS. Tres sencillos pasos a seguir. Primero configurar el registro de conexiones, tanto las correctas como las fallidas para tener una idea de lo que esta sucediendo con nuestra red. Esta es una sencilla operación para detectar los intentos de intrusión o las conexiones “no habituales” de los clientes.
En segundo lugar configurar una Política de Acceso Remoto, es decir, quienes van a poder conectarse remotamente, o lo que es lo mismo en nuestro entorno, quienes van a poder realizar una conexión Wireless. Para terminar la configuración del servidor deberemos establecer cuales 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 vamos a poder 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:
Imagen 3: Creación de una Política de Acceso Remoto
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 Wireless e incluso para conexiones ethernet, que se utilizarán en NAP. Seleccionamos la opción de Wireless, lógicamente, y continuamos hacia delante.
Imagen 4: Selección de tipo de Política de Acceso Remoto
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 llamado “Malos”, (perdón por el chiste), que serán los usuarios que vamos a autorizar con 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.
Imagen 5: Selección de clientes autorizados por esta política
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.
Imagen 6: Selección de método de autenticación de clientes
Con estas opciones hemos terminado de crear la Política de Acceso Remoto para nuestro ejemplo. Hay que notar 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, etc … a necesidad de la infraestructura.
Imagen 7: Propiedades de la Política de Conexión
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, etc… para afinar más las opciones de la política.
Política de Petición de Conexión
Vale, ya hemos creado la política para nuestros clientes Wireless, los que serán 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, cual es el orden de validación de las conexiones en el caso de que tengamos una infraestructura compleja.
La política por defecto que viene creada determina que se autentique en el servidor RADIUS a conexiones que vienen directamente o mediante una conexión VPN utilizando la base de datos del Directorio Activo. Si la autenticación la diera otro servidor RADIUS o si las peticiones vinieran a través de un ISP o se desea comprobar cualquier otro parámetro de la conexión, como por ejemplo, los números de teléfono en una conexión Dial-up o el fabricante de las tarjetas Wireless podemos crear nuevas políticas de conexión. Para nuestro ejemplo, con la política por defecto es perfecto.
Alta de Clientes RADIUS
Ya tenemos definida la Política de Acceso Remoto y la Política de Petición de Conexión, hemos configurado el Registro de Accesos y tenemos el servidor IAS registrado en el Directorio Activo, ¿Qué nos queda? Pues únicamente dar de alta a los puntos de Aceso y/o Routers Wireless que pueden realizar peticiones a nuestro servidor para autenticar clientes. Para ello en la parte de Clientes RADIUS creamos uno nuevo.
Imagen 8: Alta de Clientes RADIUS
Lo primero que se nos solicita es el nombre que le vamos a dar al punto de acceso y cual es la dirección IP o nombre DNS desde la que es accesible para nuestro servidor IAS. En segundo lugar debemos elegir el tipo de cliente RADIUS que es pues a pesar de que existe un estándar, muchos fabricantes han realizado pequeñas variaciones sobre el mismo en la forma de la comunicación.
Imagen 9: Elección de tipo de cliente RADIUS
Por último, lo más importante, el secreto compartido entre nuestro Servidor RADIUS y el cliente. Es la forma de autenticación mutua que se utiliza. Podríamos pensar que es una forma insegura, pues la clave compartida no es la mejor de las formas de autenticar las conexiones, pero se supone, que la conexión física entre el Cliente y el Servidor RADIUS es por una línea privada y securizada.
Imagen 10: Configuración de Secreto Compartido para Cliente RADIUS
Al acabar este asistente ya tendremos dado de alta como Cliente RADIUS a nuestro AP, pero este la comunicación no estará funcionando hasta que de forma simétrica demos de alta al servidor RADIUS en nuestro Punto de Acceso o Router Wireless.
Imagen 11: Lista de Clientes RADIUS en IAS
Para dar de alta al servidor RADIUS debemos entrar en la herramienta de administración de nuestro Punto de Acceso Wireless y configurar la dirección IP del servidor RADIUS, el puerto, que por defecto es el 1812 y el secreto compartido. Y ya estaría.
Imagen 12: Configuración del Servidor RADIUS en el AP
Configuración del cliente
Para terminar la conexión en esta infraestructura debemos crear la conexión desde el cliente, para ello entramos en las opciones de la tarjeta de red y damos de alta una nueva red Wireless. Damos de alta el SSID de la misma, seleccionamos la opción de autenticación WPA y de cifrado TKIP. Pasamos en segundo lugar a la parte de Autenticación donde podremos seleccionar “PEAP” o “Certificado Digital o Smartcard”.
Imagen 13: Configuración de Cliente WPA
Hay que darse cuenta, que en el caso de usar PEAP podremos autenticarnos usando contraseña con MS Chap v2 o con certificado digital o smartcard, mientras que si utilizamos certificado digital o smartcard no podremos utilizar la contraseña. En ambos casos deberemos elegir la entidad certificadora que estamos utilizando para validar todos los certificados digitales, los de servidor y los de cliente, así se puede ver en las propiedades de ambas configuraciones.
Imagen 14: Configuración de Propiedades de Autenticación
A la izquierda se ve que hemos utilizado Certificado Digital o Smartcard y como debemos seleccionar cual va a ser nuestro certificado y quien es la entidad certificadora que valida los mismos. A la derecha se ve como usamos una entidad para validar el certificado del servidor para crear el tunel TLS y como después, podemos elegir la forma de autenticarnos, con EAP-MSChap v2 o con EAP-TLS.
802.11i y WPA2 (Wi-Fi Protected Access 2)
WPA había nacido sin un estándar que lo apoyara en sus orígenes, pero sí teniendo muy en cuenta lo que iba a ser el estándar 802.11i que vendría a mejorar las soluciones basadas en WEP. Para ello se utilizaron los borradores y la información que se iba obteniendo para ir evolucionando WPA. Cuando ya se tuvo una idea clara de lo que iba a ser 802.11i apareció WPA2. ¿Qué diferencias hay entre WPA y WPA2? La respuesta que se debe decir es que poca y mucha. Mucha en tanto en cuanto está basado en el estándar 802.11i y eso si es un cambio y poca si tenemos en cuenta que WPA estaba ya enfocado hacia ese destino. La principal novedad es el sistema de cifrado que incluye AES.
AES (Advanced Encryption Standard)
AES nació como iniciativa del gobierno americano para sustituir a DES como sistema de cifrado. AES tuvo nombre antes que algoritmo y se estuvo buscando a través de un “mega concurso” mundial cual debía ser el algoritmo a utilizar. Al final se seleccionó Rijndael que tiene ese nombre tan curioso debido a la mezcla de los nombres de los dos creadores. Desde el punto de vista técnico, AES es la opción que debemos utilizar de cifrado con WPA2, pero la utilización de AES implica el uso de varios algoritmos de cifrado por debajo. Realmente, el algoritmo del estándar 802.11i se llama RSN (Robust Security Network) y es un sistema que negocia el algoritmo de cifrado y autenticación entre las opciones soportadas y configuradas en cliente y servidor. El uso de RSN permite que se pueda negociar con compatibilidad hacia atrás en el caso de ser necesario hacer convivir dispositivos que no soportan AES y usan TKIP o WEP como móviles, PDAs, o sistemas operativos antiguos. RSN soporta WEP, WEP-104, TKIP, WRAP y CCMP que son las implementaciones AES para cifrado de bloque y cifrado de flujo. ¿A que es todo muy sencillito?
La infraestructura empresarial
Para montar una solución de estas características no nos podemos quedar en el montaje manual que hemos utilizado en estos ejemplos sino que deberemos apoyarnos en las utilidades que nos ofrece el Directorio Activo. En primer lugar, para la realización de esta infraestructura hemos supuesto que teníamos realizado un despliegue de certificados de usuario y máquinas dentro de nuestra organización. Es decir, que la infraestructura PKI está subyacente. En segundo lugar hemos realizado las configuraciones de las conexiones de los clientes de forma individual, pero esto se puede automatizar con las políticas.
Imagen 15: Creación de una Política Wireless en el Directorio Activo
Para ello creamos una nueva política en la unidad organizativa de las máquinas que queramos configurar para uso de conexiones Wireless y dentro de las opciones de configuración a nivel de máquina creamos una nueva Política de Conexión Wireless. Una vez creada entramos en las propiedades para establecer cuales son las opciones de la conexión Wireless que deseamos crear dentro de los clientes. Allí tendremos que configurar las mismas opciones que hemos visto en la creación de una conexión desde el cliente: SSID, Autenticación, Cifrado, y después las opciones de autenticación.
Imagen 16: Opciones de Autenticación para la Política Wireless
Otras Opciones de Securizar una red Wireless
Sí, existen otras opciones para securizar las redes Wireless y las empresas han estado utilizando básicamente dos aproximaciones basadas en lo mismo: Autenticar las conexiones.
Para autenticar las conexiones podemos utilizar un punto de entrada distinto al dispositivo wireless, es decir, en lugar de autenticar en el Access Point, se puede dejar que se conecte el que desee pero después del AP nos encontraremos con la red de la empresa que no permitirá conexiones que no vengan desde un cliente autenticado. ¿Y como autenticamos los clientes válidos?
Opción 1: Con conexiones VPN. Los clientes se conectan al AP y a partir de esa conexión se autentican en el servidor VPN. Una vez que el servidor VPN haya establecido que es un cliente válido ya podrá establecerse en la red.
Opción 2: Mediante certificados digitales e IPSec. Si la red de la organización está desplegada con comunicaciones IPSec, sólo podrá conectarse comunicarse por la red aquel cliente que tenga un certificado digital. Esta opción es menos recomendable debido a que las comunicaciones no cifradas si que pueden ser capturadas por un intruso y puede llegar a obtener información que no fuera deseable.
Despedida y Cierre
Han sido tres meses hablando de cómo proteger una red Wireless y porque hay que hacerlo, así que ya no tienes excusa. Securiza tu red por tres razones.
1) Hay tecnología para hacerlo.
2) No es difícil y sabes hacerlo.
3) Siempre hay alguien aburrido pensando en como “divertirse”.
Autor:Chema Alonso. Microsoft MVP Windows Security
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 solo una solución segura para conexiones Wireless, también es un elemento importante en la autenticación de conexiones VPN, 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 todos las empresas.
Si la implantación del servidor RADIUS es algo para pocos usuarios o no se desea implantar un servidor dedicado, se puede adquirir fácilmente Routers y/o Access Points Wireless 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 esta 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 que contemos con 2 o más Access Point 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). Este es que en Windows 2000 Server se proveía como una descarga aparte pero 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. Este es un componente de red por lo que habría que seleccionar IAS dentro de estos.
Una vez instalado hay que registrar el servidor RADIUS en el Directorio Activo de nuestra organización, y para ello tres opciones, la fácil: desde la consola de administración MMC de IAS, seleccionamos nuestro servidor IAS y elegimos la opción “Regristrar en Directorio Activo” (figura 2); la artesana: Al final, al hacerlo mediante la consola solo se está añadiendo la cuenta de máquina a ciertos grupos privilegiados, por lo que podemos 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; y por comandos: también se puede realizar el mismo proceso utilizando el comando netsh desde el interfaz de comandos.
Una vez registrado ya podemos proceder a configurar nuestro servidor IAS. Tres sencillos pasos a seguir. Primero configurar el registro de conexiones, tanto las correctas como las fallidas para tener una idea de lo que esta sucediendo con nuestra red. Esta es una sencilla operación para detectar los intentos de intrusión o las conexiones “no habituales” de los clientes.
En segundo lugar configurar una Política de Acceso Remoto, es decir, quienes van a poder conectarse remotamente, o lo que es lo mismo en nuestro entorno, quienes van a poder realizar una conexión Wireless. Para terminar la configuración del servidor deberemos establecer cuales 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 vamos a poder 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 Wireless 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 llamado “Malos”, (perdón por el chiste), que serán los usuarios que vamos a autorizar con 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. Hay que notar 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, etc … 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, etc… para afinar más las opciones de la política.
Política de Petición de Conexión
Vale, ya hemos creado la política para nuestros clientes Wireless, los que serán 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, cual es el orden de validación de las conexiones en el caso de que tengamos una infraestructura compleja.
La política por defecto que viene creada determina que se autentique en el servidor RADIUS a conexiones que vienen directamente o mediante una conexión VPN utilizando la base de datos del Directorio Activo. Si la autenticación la diera otro servidor RADIUS o si las peticiones vinieran a través de un ISP o se desea comprobar cualquier otro parámetro de la conexión, como por ejemplo, los números de teléfono en una conexión Dial-up o el fabricante de las tarjetas Wireless podemos crear nuevas políticas de conexión. Para nuestro ejemplo, con la política por defecto es perfecto.
Alta de Clientes RADIUS
Ya tenemos definida la Política de Acceso Remoto y la Política de Petición de Conexión, hemos configurado el Registro de Accesos y tenemos el servidor IAS registrado en el Directorio Activo, ¿Qué nos queda? Pues únicamente dar de alta a los puntos de Aceso y/o Routers Wireless que pueden realizar peticiones a nuestro servidor para autenticar clientes. Para ello en la parte de Clientes RADIUS creamos uno nuevo.
Lo primero que se nos solicita es el nombre que le vamos a dar al punto de acceso y cual es la dirección IP o nombre DNS desde la que es accesible para nuestro servidor IAS. En segundo lugar debemos elegir el tipo de cliente RADIUS que es pues a pesar de que existe un estándar, muchos fabricantes han realizado pequeñas variaciones sobre el mismo en la forma de la comunicación.
Por último, lo más importante, el secreto compartido entre nuestro Servidor RADIUS y el cliente. Es la forma de autenticación mutua que se utiliza. Podríamos pensar que es una forma insegura, pues la clave compartida no es la mejor de las formas de autenticar las conexiones, pero se supone, que la conexión física entre el Cliente y el Servidor RADIUS es por una línea privada y securizada.
Al acabar este asistente ya tendremos dado de alta como Cliente RADIUS a nuestro AP, pero este la comunicación no estará funcionando hasta que de forma simétrica demos de alta al servidor RADIUS en nuestro Punto de Acceso o Router Wireless.
Para dar de alta al servidor RADIUS debemos entrar en la herramienta de administración de nuestro Punto de Acceso Wireless y configurar la dirección IP del servidor RADIUS, el puerto, que por defecto es el 1812 y el secreto compartido. Y ya estaría.
Configuración del cliente
Para terminar la conexión en esta infraestructura debemos crear la conexión desde el cliente, para ello entramos en las opciones de la tarjeta de red y damos de alta una nueva red Wireless. Damos de alta el SSID de la misma, seleccionamos la opción de autenticación WPA y de cifrado TKIP. Pasamos en segundo lugar a la parte de Autenticación donde podremos seleccionar “PEAP” o “Certificado Digital o Smartcard”.
Hay que darse cuenta, que en el caso de usar PEAP podremos autenticarnos usando contraseña con MS Chap v2 o con certificado digital o smartcard, mientras que si utilizamos certificado digital o smartcard no podremos utilizar la contraseña. En ambos casos deberemos elegir la entidad certificadora que estamos utilizando para validar todos los certificados digitales, los de servidor y los de cliente, así se puede ver en las propiedades de ambas configuraciones.
A la izquierda se ve que hemos utilizado Certificado Digital o Smartcard y como debemos seleccionar cual va a ser nuestro certificado y quien es la entidad certificadora que valida los mismos. A la derecha se ve como usamos una entidad para validar el certificado del servidor para crear el tunel TLS y como después, podemos elegir la forma de autenticarnos, con EAP-MSChap v2 o con EAP-TLS.
802.11i y WPA2 (Wi-Fi Protected Access 2)
WPA había nacido sin un estándar que lo apoyara en sus orígenes, pero sí teniendo muy en cuenta lo que iba a ser el estándar 802.11i que vendría a mejorar las soluciones basadas en WEP. Para ello se utilizaron los borradores y la información que se iba obteniendo para ir evolucionando WPA. Cuando ya se tuvo una idea clara de lo que iba a ser 802.11i apareció WPA2. ¿Qué diferencias hay entre WPA y WPA2? La respuesta que se debe decir es que poca y mucha. Mucha en tanto en cuanto está basado en el estándar 802.11i y eso si es un cambio y poca si tenemos en cuenta que WPA estaba ya enfocado hacia ese destino. La principal novedad es el sistema de cifrado que incluye AES.
AES (Advanced Encryption Standard)
AES nació como iniciativa del gobierno americano para sustituir a DES como sistema de cifrado. AES tuvo nombre antes que algoritmo y se estuvo buscando a través de un “mega concurso” mundial cual debía ser el algoritmo a utilizar. Al final se seleccionó Rijndael que tiene ese nombre tan curioso debido a la mezcla de los nombres de los dos creadores. Desde el punto de vista técnico, AES es la opción que debemos utilizar de cifrado con WPA2, pero la utilización de AES implica el uso de varios algoritmos de cifrado por debajo. Realmente, el algoritmo del estándar 802.11i se llama RSN (Robust Security Network) y es un sistema que negocia el algoritmo de cifrado y autenticación entre las opciones soportadas y configuradas en cliente y servidor. El uso de RSN permite que se pueda negociar con compatibilidad hacia atrás en el caso de ser necesario hacer convivir dispositivos que no soportan AES y usan TKIP o WEP como móviles, PDAs, o sistemas operativos antiguos. RSN soporta WEP, WEP-104, TKIP, WRAP y CCMP que son las implementaciones AES para cifrado de bloque y cifrado de flujo. ¿A que es todo muy sencillito?
La infraestructura empresarial
Para montar una solución de estas características no nos podemos quedar en el montaje manual que hemos utilizado en estos ejemplos sino que deberemos apoyarnos en las utilidades que nos ofrece el Directorio Activo. En primer lugar, para la realización de esta infraestructura hemos supuesto que teníamos realizado un despliegue de certificados de usuario y máquinas dentro de nuestra organización. Es decir, que la infraestructura PKI está subyacente. En segundo lugar hemos realizado las configuraciones de las conexiones de los clientes de forma individual, pero esto se puede automatizar con las políticas.
Para ello creamos una nueva política en la unidad organizativa de las máquinas que queramos configurar para uso de conexiones Wireless y dentro de las opciones de configuración a nivel de máquina creamos una nueva Política de Conexión Wireless. Una vez creada entramos en las propiedades para establecer cuales son las opciones de la conexión Wireless que deseamos crear dentro de los clientes. Allí tendremos que configurar las mismas opciones que hemos visto en la creación de una conexión desde el cliente: SSID, Autenticación, Cifrado, y después las opciones de autenticación.
Otras Opciones de Securizar una red Wireless
Sí, existen otras opciones para securizar las redes Wireless y las empresas han estado utilizando básicamente dos aproximaciones basadas en lo mismo: Autenticar las conexiones.
Para autenticar las conexiones podemos utilizar un punto de entrada distinto al dispositivo wireless, es decir, en lugar de autenticar en el Access Point, se puede dejar que se conecte el que desee pero después del AP nos encontraremos con la red de la empresa que no permitirá conexiones que no vengan desde un cliente autenticado. ¿Y como autenticamos los clientes válidos?
Opción 1: Con conexiones VPN. Los clientes se conectan al AP y a partir de esa conexión se autentican en el servidor VPN. Una vez que el servidor VPN haya establecido que es un cliente válido ya podrá establecerse en la red.
Opción 2: Mediante certificados digitales e IPSec. Si la red de la organización está desplegada con comunicaciones IPSec, sólo podrá conectarse comunicarse por la red aquel cliente que tenga un certificado digital. Esta opción es menos recomendable debido a que las comunicaciones no cifradas si que pueden ser capturadas por un intruso y puede llegar a obtener información que no fuera deseable.
Despedida y Cierre
Han sido tres meses hablando de cómo proteger una red Wireless y porque hay que hacerlo, así que ya no tienes excusa. Securiza tu red por tres razones.
1) Hay tecnología para hacerlo.
2) No es difícil y sabes hacerlo.
3) Siempre hay alguien aburrido pensando en como “divertirse”.
Autor:Chema Alonso. Microsoft MVP Windows Security
No hay comentarios:
Publicar un comentario