Recientemente hemos mejorado la seguridad de la red wifi del CIFP Tartanga LHII mediante la segmentación por VLAN de las cuatro redes wifi existentes y la autenticación mediante un servidor RADIUS, el cual evita el uso de contraseñas compartidas por un elevado número de usuarios, como son los más de 1000 alumnos y cerca de 150 profesores. El servidor RADIUS se ha implementado mediante el servicio NPS en el controlador de dominio del instituto, que actualmente se ejecuta sobre una máquina virtual con Windows Server 2019. Puesto que uno de los requisitos de la configuración y puesta en marcha de la nueva red wifi era interrumpir el servicio el mínimo tiempo posible, se han mantenido en funcionamiento en todo momento los SSID utilizados hasta ahora en la red wifi del instituto y se han añadido cuatro nuevos SSID con nombres similares a los anteriores pero con la letra “R” como sufijo, a fin de diferenciar estas nuevas redes wifi de las anteriores. Una vez finalizada la configuración y comprobado el correcto funcionamiento, las redes wifi anteriores con seguridad WPA2 y sin segmentación mediante VLAN se han eliminado y únicamente han quedado en servicio las nuevas redes wifi con segmentación VLAN y con seguridad WPA2 Enterprise en dos de ellas y WPA2 en las otras dos.
Redes wifi existentes y nuevas redes wifi creadas
En la captura de pantalla anterior se observan los 4 SSID existentes hasta la fecha, Tartanga-Free, Tartanga-Irakasleak, Tartanga-Ordenagailuak y Tartanga-IoT, todos ellos correspondientes a redes wifi con autenticación WPA2 y sin ningún tipo de segmentación mediante VLAN. En la misma captura de pantalla se observan los cuatro nuevos SSID creados, que son:
- Tartanga-Irakasleak-R: red wifi con autenticación RADIUS contra la rama de profesores del active directory del centro. Solo los profesores en activo del instituto pueden conectarse a esta wifi y para ello deberán introducir su usuario y contraseña, siendo asignados a continuación a la VLAN31, con un direccionamiento IP propio.
- Tartanga-Ikasleak-R: red wifi con autenticación RADIUS para los alumnos del centro. Al igual que en el caso anterior, los alumnos deberán introducir su usuario y contraseña para conectarse a la red wifi y todo el tráfico será asignado a la VLAN31, también con un direccionamiento propio.
- Tartanga-Free-R: red wifi con autenticación WPA2 disponible para visitantes del centro, cuyo tráfico es asignado a la VLAN33 y únicamente con permisos de navegación hacia la web, estando prohibido el acceso a cualquier otro recurso del centro.
- Tartanga-IoT-R: red wifi con autenticación WPA2 disponible para los equipos IoT del centro. En este caso el acceso es únicamente por contraseña y todo el tráfico de dicha red wifi se asigna a la VLAN30.
Como se ha indicado anteriormente, una vez finalizada la configuración de la nueva red wifi y la comprobación de su correcto funcionamiento, se han eliminado las redes wifi que hasta ahora habían dado servicio al instituto y han quedado activas únicamente las cuatro nuevas redes wifi creadas, ya sin el sufijo “R” en su nombre.
Redes wifi definitivas, todas ellas con segmentación VLAN
El proceso de configuración ha constado de los siguientes pasos:
1.- Creación de VLAN en el Fortinet
VLAN en el interfaz 11 del Fortinet
En la captura de pantalla anterior se observan las cuatro VLAN creadas en el interfaz 11 del Fortinet. Para cada una de las VLAN se ha establecido su identificador de VLAN (30, 31, 32 y 33), la dirección de Gateway y la máscara de red, que delimita el tamaño de la VLAN. De la misma manera, para cada una de las VLAN se ha activado un servidor DHCP dentro del propio Fortinet.
Configuración de la VLAN 30 en el Fortinet
Ejemplo de servidor DHCP para la VLAN30
2.- Creación de redes virtuales en Unifi Controller y asignación de VLAN
Redes virtuales en Unifi Controller con asignación de VLAN ID
Configuración de VLAN ID en una de las redes virtuales creadas
3.- Creación de las nuevas redes wifi en Unifi Controller y asignación de la red virtual correspondiente
Nuevas redes wifi con asignación de red virtual (VLAN)
Como se observa en la imagen anterior, dos de las nuevas redes wifi creadas, Tartanga-Ikasleak y Tartanga-Irakasleak, son de tipo WPA2 Enterprise y en ellas la autenticación se realiza mediante el protocolo RADIUS que corre como servicio en el controlador de dominio del centro (NPS). Las otras dos redes wifi, Tartanga-IoT y Tartanga-Free son de tipo WPA2, ya que la primera de ellas está prevista para equipos IoT del centro, algunos de los cuales no soportan autenticación RADIUS y la otra, Tartanga-Free, está destinada para su uso por invitados al centro, los cuales, evidentemente, no tienen un usuario creado en el active directory.
4.- Instalación de switches PoE gestionables
Para que funcione la segmentación por VLAN en las nuevas redes wifi del centro es necesario que los puntos de acceso estén conectados a switches PoE gestionables, con soporte del protocolo 802.1Q. En nuestro caso se ha optado por sustituir los switches Dlink DGS-1008 MP existentes por nuevos switches Dlink modelo DGS-1100-26MVP2.
Nuevos switches PoE gestionables DGS-1100-26MVP2
Switches PoE gestionables DGS-1100-26MVP2 en el rack principal del instituto
Switch PoE gestionable junto a los anteriores switches no gestionables en un rack secundario del centro
La configuración de estos nuevos switches PoE gestionables ha sido la misma en todos ellos. En primer lugar, en todos los switches se han creado las VLAN necesarias, las VLAN30, 31, 32 y 33.
VLAN en uno de los switches PoE gestionables
Los puntos de acceso (APs) se han conectado a puertos del switch configurados en modo trunk, con VID 30, que es el valor de VLAN que se coloca a las tramas no etiquetadas que acceden al puerto trunk. Se debe de tener en cuenta que, en función del SSID al que se conecta el cliente, el AP etiqueta las tramas con una VLAN u otra, pero las propias tramas del AP en su comunicación con el Unifi Controller van sin etiquetar, por lo que es necesario asignarles una etiqueta para el acceso a través de un puerto de tipo trunk.
Configuración de puerto para conexión de los APs
El Unifi Controller, que es una máquina virtual sobre Ubuntu 24.04, se conecta a uno de los puertos del switch PoE gestionable principal configurado en modo Access, con acceso de tramas únicamente de tipo Untagged y con VID 30. Esto es así porque el Unifi Controller es un dispositivo final que no crea tramas etiquetadas. De esta manera, todas las tramas que introduce el Unifi Controller por este puerto reciben la etiqueta de VLAN30 y pueden acceder a los puntos de acceso y, al mismo tiempo, a todas las tramas que se reciben por este puerto se les retira la etiqueta de VLAN30 para que puedan ser aceptadas por Unifi Controller.
Configuración de puerto para el Unifi Controller
Finalmente, todos los switches PoE gestionables, situados en distintos rack repartidos por el instituto, se conectan con el switch PoE gestionable principal mediante un enlace de tipo Trunk y con VID 1. Además, este switch PoE principal se conecta con el port 11 del Fortinet también mediante un enlace de tipo Trunk con VID 1. El Trunk está configurado para aceptar todas las tramas, así que las tramas de las VLAN30, 31, 32 y 33 circularán sin problemas hacia el Fortinet y viceversa.
Trunk entre el switch PoE principal y el port 11 del Fortinet
5.- Configuración en las directivas de red de RADIUS (NPS) de las nuevas condiciones de acceso
En la configuración de las directivas de red realizadas anteriormente, cuando se configuró y se puso en marcha el servidor RADIUS (NPS) como servicio del controlador de dominio del instituto, tan solo se puso una condición de acceso basada en el horario, no llevando a cabo ninguna comprobación del SSID desde el cual se realizaba la petición de autenticación. Con esta condición, todos los usuarios del dominio que introducían un nombre de usuario y una contraseña válidos, recibían autorización para el acceso a la red wifi. Puesto que ahora se quiere diferenciar si el usuario que se conecta es un alumno o un profesor, a fin de asignar el tráfico de dicho usuario a una VLAN u otra, es necesario diferenciar entre ambos usuarios y por ello se han configurado dos directivas de acceso diferentes, una para los profesores y otra para los alumnos. En ambas se comprueba que el usuario pertenece al grupo del Active Directory adecuado, autorizándose el acceso si los valores de usuario y contraseña introducidos son correctos.
Condiciones de acceso para el SSID Tartanga-Irakasleak
En la captura de pantalla anterior se observa que, para el SSID Tartanga-Irakasleak, que corresponde al SSID que deben utilizar los profesores del centro, se comprueba el usuario y contraseña dentro del grupo de Windows TartangaLH\irDenak, donde están todos los profesores en activo del instituto, y también en el grupo TartangaLH\Admins del dominio, esto último para permitir la conexión a la red wifi de Tartanga-Irakasleak a los usuarios admin del dominio, los cuales no se encuentran en el grupo irDenak. De la misma manera, si fuera necesario, se podrían añadir otros grupos de windows y otros tipos de condiciones de acceso que permite RADIUS en Windows Server (NPS).
Condiciones de acceso para el SSID Tartanga-Ikasleak
6.- Configuración de las Firewall Policy en el Fortinet
Toda la configuración anterior no tendría ningún sentido si no se realiza finalmente una correcta configuración de las Firewall Policy en el Fortinet, delimitando claramente a donde pueden acceder los usuarios y que accesos están denegados, en función del SSID al que se han conectado. Puesto que en la nueva red wifi existen 4 nuevos SSID cada uno de ellos asignado a una VLAN diferente (VLAN30, 31, 32 y 33), es necesario configurar permisos y restricciones para cada una de esas VLAN y el resto de VLAN y redes del instituto, todas ellas conectadas a los diferentes puertos del Fortinet.
Firewall Policy para las VLAN30 (Tartanga-IoT) y VLAN31 (Tartanga-Irakasleak)
Así por ejemplo, con esta nueva red wifi los alumnos del instituto tan solo pueden conectarse a la red wifi con SSID Tartanga-Ikasleak y, en ese caso, tan solo pueden acceder al servidor donde se encuentra el Active Directory para el proceso de inicio de sesión y consulta de DNS, y a los dos servidores que están a su disposición con las carpetas de red correspondientes, mediante el protocolo SMB (Server Ikasleak y Server Ikasleak IyS, que es un servidor especial para los alumnos de Imagen y Sonido, dado el elevado volumen de almacenamiento que necesitan para guardar sus trabajos)
Firewall Policy para la VLAN32 (Tartanga-Ikasleak) respecto a los servidores del centro
Puesto que no se ha establecido ninguna Firewall Policy para el acceso desde la wifi de alumnos a los equipos de la LAN de GESTION del centro, donde se encuentran los PCs de profesores en despachos, PCs de administración y PCs de dirección, no es posible la conexión por SSH o RDP desde esta red wifi con ninguno de estos ordenadores de la LAN de GESTION. Esto supone una mejora importante en la ciberseguridad del instituto, máxime teniendo en cuenta que en el centro se imparte un curso de especialización de Ciberseguridad donde los alumnos, únicamente con fines didácticos, prueban diferentes herramientas de ataque.
Intento de conexión RDP desde la wifi de alumnos a un PC de la LAN de GESTION
Conexión RDP rechazada desde la wifi de alumnos a un PC de la LAN de GESTION
Una situación parecida sucede respecto de los servidores situados en la DMZ. En este caso, desde la wifi de alumnos se permite la conexión http y https a determinados servidores de esta DMZ pero se impide por completo el acceso mediante RDP o SSH.
Conexión SSH rechazada desde la wifi de alumnos a un servidor de la DMZ
De la misma manera, con esta nueva configuración de la red wifi, los profesores del centro que se conectan a la red wifi mediante el SSID Tartanga-Irakasleak (VLAN31) pueden acceder a los servidores que necesitan para su labor docente pero no pueden acceder por SSH o RDP a ninguno de dichos servidores, lo mismo que sucede cuando dichos profesores se conectan a la red cableada del centro.
Firewall Policy para la VLAN31 (Tartanga-Irakasleak) respecto a los servidores
Por último, mediante las Firewall Policy se ha limitado al máximo lo que pueden hacer los usuarios invitados al centro que se conectan a la red wifi del mismo, ya que se han configurado dichas Firewall Policy para que tan solo puedan navegar hacia internet y acceder a los recursos mínimos imprescindibles situados en la DMZ, como es por ejemplo el servidor de Moodle.
Prohibición de conexiones SSH y RDP a máquinas de la DMZ desde la wifi de invitados