(Continuamos con la interrupción de las entradas de la Black Hat, en este caso para hablar de PVLANs. El lunes que viene sin falta retomamos el día 2 de la BH)
Hace unas semanas, José Luis introducía el concepto de Private VLANs (PVLANs) para la securización de las DMZ. Vamos a ver en esta entrada algunos aspectos interesantes de esta tecnología.
Como vimos, las PVLANs (Private Vlan’s) consiguen el objetivo propuesto de aislar los servidores de la DMZ unos de otros. Lo que no está claro es qué rango de direcciones IP, o mejor dicho a qué subred va a ir asociado cada servidor. Hay gente que tiene la falsa creencia de que para conseguir aislar los servidores unos de otros tenemos que gastar subredes distintas, utilizando una para cada servidor, e incluso gastando para ello las PVLAN’s. Y aquí es donde radica la ventaja de dicha tecnología: sólo necesitamos una subred para asignar direcciones IP a nuestros servidores alojados en la DMZ. Por ejemplo, si disponemos de 50 servidores en la DMZ, y no queremos que se vean unos a otros, en lugar de utilizar 50 subredes diferentes (por ejemplo, 192.168.1.x, 192.168.2.x., …, 192.168.50.x) podemos utilizar una única subred para todos ellos (por ejemplo, 192.168.1.1, 192.168.1.2, …, 192.168.1.50), y con PVLANs conseguiríamos el objetivo de aislar los servidores, dando la sensación de que cada servidor está aislado del resto.
Antes de seguir, hay que tener en cuenta que actualmente no es necesario segmentar en los tipos de redes clase A, B, y C, sino que podemos hacer uso de subnetting, para calcular el crecimiento previsto de nuestra DMZ y asignar una máscara de subred que cubra nuestras necesidades. Además, el correcto uso de subnetting nos va a facilitar las tareas administrativas de seguridad, relacionadas con la aplicación de ACL’s en las interfaces, ya que de esta manera podremos crear resúmenes de esas redes (superredes: agrupar subredes reduciendo la máscara) con lo que una sencilla ACL podría afectar a multitud de redes. Otra ventaja evidente de un correcto direccionamiento se da cuando estamos gastando protocolos de enrutamiento dinámico como pudiera ser OSPF, EIGRP (cuando todos nuestros routers son Cisco) o IS-IS, ya que los paquetes de actualizaciones de estos protocolos son mínimos. De esta manera, evitamos enviar cientos de rutas saturando los enlaces y a la par incrementamos el rendimiento y la escalabilidad de la red.
Volviendo al tema principal de este artículo, ¿cómo consigue la tecnología PVLAN aislar los equipos de la DMZ de una misma subred unos de otros? Tengamos en cuenta que cuando un equipo de una subred quiere comunicarse con otro equipo de la misma subred, el procedimiento habitual es lanzar un petición broadcast para que el destino responda proporcionando su dirección IP. Como están dentro de la misma subred, esta petición nunca llegará a un dispositivo de capa 3, un switch con capacidades de capa 3 o un router. Es aquí donde entra en acción la tecnología PVLAN implementada o configurada en el propio switch para cortar dicha solicitud de broadcast, evitando así que unos equipos se vean a otros, aún estando en la misma subred y por consiguiente alcanzando el objetivo deseado de aislar cada servidor dentro de la DMZ.
Para aprovecharnos de la ventaja que nos ofrecen las PVLANs, toda la configuración se realizaría íntegramente en el switch, sin tener que modificar la configuración de nuestro router. Como se puede apreciar, las ventajas de configurar correctamente un dispositivo de capa 2 son múltiples, y esta capa suele ser la gran olvidada en cuanto a políticas de seguridad. Mucha gente se preocupa a partir de la capa 3 (red) hasta la capa 7 (aplicación), es decir de la seguridad desde el exterior hacía el interior. Sin embargo, es muy importante que la seguridad de la red comience en la capa 2, para proteger a los equipos unos de otros incluso en nuestra red interna.
Una buena política de seguridad debería empezar por esta capa 2, para evitar entre otras las peligrosas técnicas de spoofing. No obstante, es necesario alcanzar un equilibrio entre seguridad y rendimiento, ya que el precio a pagar por este incremento en seguridad seria:
- Por un lado una configuración más compleja en el switch, que podría afectar al rendimiento de la red interna.
- Por otro el coste superior de un switch con capacidad de snooping, vlan’s, configuración remota, etc.
Como se puede apreciar, la seguridad en esta capa dos puede complicarse, por lo que antes de adquirir nuestra electrónica de red conviene asesorarse de que estamos adquiriendo y hasta dónde queremos tener control; en un artículo posterior trataremos más en profundidad errores comunes y técnicas de ataque de capa 2, sin olvidar que en todo momento hay que apoyarse en nuestras políticas de seguridad de empresa.
[…] Securizando nuestra DMZ (II) […]