Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Proteger una red Wireless (III de III)
***************************************************************************************************
Artículo publicado en PCWorld
- Proteger una red Wireless (I de III)
- Proteger una red Wireless (II de III)
- Proteger una red Wireless (III de III)
***************************************************************************************************
Llegamos al final de este camino de 3 meses de duración sobre la seguridad en las redes Wireless y como 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, que aún nos queda camino, lo primero, configurar el servidor RADIUS.
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”.
Saludos Malignos!
***************************************************************************************************
Artículo publicado en PCWorld
- Proteger una red Wireless (I de III)
- Proteger una red Wireless (II de III)
- Proteger una red Wireless (III de III)
***************************************************************************************************
Artículo publicado en PCWorld
- Proteger una red Wireless (I de III)
- Proteger una red Wireless (II de III)
- Proteger una red Wireless (III de III)
***************************************************************************************************
Llegamos al final de este camino de 3 meses de duración sobre la seguridad en las redes Wireless y como 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, que aún nos queda camino, lo primero, configurar el servidor RADIUS.
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.
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”.
Saludos Malignos!
***************************************************************************************************
Artículo publicado en PCWorld
- Proteger una red Wireless (I de III)
- Proteger una red Wireless (II de III)
- Proteger una red Wireless (III de III)
***************************************************************************************************
28 comentarios:
Que pasa trons? Soy un ex-i64, a ver si adivinas quién...
El caso, que ahora que tengo algo más de tiempo libre, ¿me podrías decir donde están los artículos I y II del tema este de Wireless?
Thank you very much.
Los artículos I y II los tienes linkados al principio de este compañero!!
ponte un nick pájaro!
Jajajaja.... Suelen decir que los informáticos somos despistados y eso...¿por qué será? ;) Ya me vale... tanto usar mi mente en i64 y tanto leer, leer, y leer documentación técnica, se ve que quizás haya informatizado mi mente demasiado, y provocado que a veces lea el mundo con 0 y 1, lo leo, no lo leo, valor booleano, salto directamente 5 líneas más abajo y me dejo los vínculos (ya me vale, una vez más), o no.
Luego cosas mazo más complicadas como las que me ha tocado hacer en i64 esas sí, las saco adelante sin problemas, pero buscar dos puñeteros vínculos, no sé hacerlo...:S En fin...
Un abrazo, y suerte!!
http://elmundodejavi.blogspot.com
AHORA YA SABES QUIÉN SOY? MI BLOG MOLA MÁS TÍO, ES MAS VARIADO, NO SÓLO DE SEGURIDAD... JEJEJE...
Tas chalao!! :P
Muy interesante,
CONTOSO? jejeje
Veo que haces lo mismo que M$ metiendo las imagenes en JPG para que se enguarren bien enguarradas y ocupen más.
PD: Siguen haciendo lo mismo con los certificados de asistencia.
Hola Netvicious, se llama Virtual Labs. ;)
Hola , recien estoy iniciandome en esto del wireless , mi pregunta ( de novato ) es si puede hacerse el descubrimientos de clientes y AP etc , con un placa ethernet comun conectada un bridge wireless. muchas gracias.
Hola anónimo, si tu bridge está conectado a la red sí. Si no está conectado y quieres descubrir equipos para conocer información de la red necesitarás un sw que monitorice el bridge y yo no lo conozco.
Gracias por la respuesta , la conexion es la siguiente , la placa ethernet esta conectada directamente al bridge y el bridge es el que hace conexion con el AP del isp
alguna ayuda de problemas d eautenticacion, y de certificafdos digitales yo tengo implementado un radius con w2003 server y un AP de cisco la cuestion es que me manda a mi cliente en XP la ntoficacion que no me puede autenticar agradecere cualquier ayuda
Hola Raymundo, puede ser por muchas cosas! Te dejo más información sobre como hacer justo esa configuración Radius IAS, AP Cisco y Autenticación con EAP-TLS en la siguiente guía.
Te doy mas detalles, tengo un AP cisco aironet 1420 de cisco, tengo clientes en xp, y un servidor con windows 2003 server con IAS, IIS y el CA en el mismo servidor, ya puse el server el AP y una lap(con un sniffer) en un mismo hub, al parecer el dialecto RADIUS se habkla sin problema entre el AP y el servidor, a parte tengo un suplicante con una tarjeta cisco de las que si estan soportando 802.1x, sin embargo cuando aparece el icono de red enla esquina inferior derecha en principio detecta la red y todo, pero despues sucede que no obtiene ip del DHCP de la red, si no estoy diciendo blasfemias, el AP que es mi fuerte los prioductos cisco, no tengo dificultad para tomar las credenciales del suplicante y llevarselas a validar o autenticar al radius, la cuetion que me atañe cual roña a un perro es que no me autentica, ya genere un certificado en la maquina mediante el mmc para la CA, ya descargue un certificado para el suplicante desde la pagina que se habilita para tales motivos que es el http:/servidor/certsrv, y no me da autenticacion, no encunentro que es estoy haciedno mal o que me falta por hacer, digo esto es a manera de pruebla ya que si nuevamente no digo blasfemias he podido crear una politica en un servidor de dominio para que se bloquee el usb, con esto puedo crear los setting por cuenta o por maquina de acuerdo al grupo dentro del AD, es decir pues que ya se como automatizarlo mediante politicas de dominio para un pc o para un usuario que es la parte final de mi trabajo, sin embargo estoy atorado con que no me autentifico con el servidor radius, no se si tenga que ver la cuenta que utilizo ya ue donde estoy no soy controlador de dominio, y cuando descargo el certificado lo hago firmado con mi cuenta de usuario y no con superpodere de administrador, by the way ya me chute toda la documentacion que me sugieres, salvo que fue antes de hacer nada, ya la volvi a reeleer por si algo habia perdido pero digamos que no me da ninguna pista,te agradecere cualquier respuesta y si quieres te envio mi procedimiento por mail para que le heches un ojo tanto a mi configuracion del AP y del servidor.
P.D. espero no aburrir con tanto rollo
Hola Raymundo,
algún detalle en la configuración se te está escapando. Durante el año pasado fuimos montando justo ese entorno. En este webcast de 1 hora tienes todos los pasos explicados uno a uno. Revisalos, a ver si encuentras el fallo.
Webcast Wireless Seguras
Saludos!
Saludos schema Alonso, soy nuevo en esto de server 2003 y estoy trabajando en el cuento de configurar una red inalambrica segura, cosa que por cierto es algo complicado, pero en cuestion de el servidor radius aún siguiendo los pasos expuestos por tu tutorial al pie de la letra y despues de sacarme canas verdes con radius los clientes llegan hasta el punto de pedir autenticacion pero no lo logran, }¿que usuario, que contraseña y que dominio son los que introduce el usuario y como los configuro en radius?
te agradeceria si me pudieras responder o citar un link que me ayude.
@anónimo,
toda la información detallada paso por paso lo tienes en esta guía http://www.microsoft.com/technet/security/prodtech/windowsserver2003/pkiwire/swlan.mspx ahí tienes los pasos. Además, después de la gira David Cervigón grabó un Webcast con la demo y la tienes en esta URL: Seguridad en Redes Wireless
Saludos!
Saludos a todo el mundo, ya con mas experiencia de nuevo montare desde cero el RADIUS de windows, cualquier duda estare por aca dando lata con mis dudas....
Hola, me he estado leyendo tus artíuclos sobre seguridad wireless y, aparte de darte las gracias por facilitarnos una información de puta madre, tenía una preguntilla:
Suponiendo que haya sido tan gilipollas, por ignorancia, de conectar mi wireless por primera vez con una clave WEP por defecto por la compañia (que de forma muy inteligente se basa en la direccion MAC de mi router) y que alguien la haya averiguado, ¿tengo alguna opción de cambiar la encriptacion a WAP2 y realizar otro tipo de maniobras para evitar que personas ajenas se conecten a mi red, o una vez el "hacker" sepa mi direccion MAC (que venía implicita en la clave WEP) no tengo nada que hacer?
Un saludo y gracias.
@mirlo, puedes cambiarla. Conectate a tu router y configuralo con WPA2-PSK, añade filtrado MAC y oculta el ESSID (Esto sólamente por tocarle un poco los cojones más). Ponle un buen chorizo de clave y listo. Si te han mangado la password del router entonces resetea el router y empieza de cero.
Escribimos sobre esto en La Wifi de mi casa es particular
Saludos!
Muy buenas Maligno. Tengo que felicitarte por tu web. Tengo un problema con mi Radius que he montado. Mi jefe ha decidido que la authenticacion Ms-Chap no es segura y lo he cambiado todo a una authenticacion por certificados. Todo me ha funcionado bien, pero tengo problemas cuando revoco los certificados. ¿Las listas CRL se cachean en el servidor Radius? Como puedo hacer para que al publicar una lista CRL manual, el servidor Radius refresque su crl cacheada? Muchas gracias por todo
Que tal Maligno Soy Raymundo y necesito un poco de orientacion profesional, es solo cuestiones de que camino seguir, en fir por favor dimo como te contacto.
Saludos
P.D.te has convertido en mi Guro y pues nada ahora ya lo sabes.
Chido caon!
@Jhonny... usa google ;)
Hola chema tengo una duda.
- El cifrado WPA utiliza como protocolo TKIP y AES (o solo TKIP)
- El cifrado WPA2 utiliza como protocolo TKIP y AES (o solo AES).
* No me que muy claro...me hago un lio en eso.
Salu2 malo malisimo
@Lois,
WPA -> TKIP
WPA2 -> TKIP o AES
Saludos!
Hola,
estoy deseperado he configurado paso a paso tal y como indicas y no acabo de ver lo que estoy haciendo mal, estos son los EVENT ID que me da el servidor IAS Windows 2003:
EVENT ID 3
Access request for user ALTRAN_ES\jordi.rojas was discarded.
Fully-Qualified-User-Name = altran.es/Altran Spain/Alt BCN/Jordi Rojas Montoliu
NAS-IP-Address = 192.168.0.3
NAS-Identifier =
Called-Station-Identifier = 00-1F-1F-86-94-E8
Calling-Station-Identifier = 0C-EE-E6-9E-3F-DC
Client-Friendly-Name = INTELLINET_AP
Client-IP-Address = 192.168.0.3
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 0
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server =
Reason-Code = 23
Reason = Unexpected error. Possible error in server or client configuration.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
EVENT ID 20168
Could not retrieve the Remote Access Server's certificate due to the following error: Cannot find object or property.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
EVENT ID 20190
Because no certificate has been configured for clients dialing in with EAP-TLS, a default certificate is being sent to user altran_es\jordi.rojas. Please go to the user's Remote Access Policy and configure the Extensible Authentication Protocol (EAP).
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
a ver si me puedes ayudar
MIL GRACIAS
Jordi
Muy bueno.
Un Saludo.
pregunta:
¿como podria sacar la contraseña de una red wpa2 auentificacion de usurios, teniendo acceso a computadores que estan conectados a dicha red?
Publicar un comentario