¿Dónde puedo leer sobre vulnerabilidades conocidas en las características de ‘VLAN privada’ (conmutadores ethernet)?

Las VLAN privadas han existido durante bastante tiempo (por supuesto, recuerdo haber visto algunas implementaciones a fines de los 90, por ejemplo) y el caso de uso que está describiendo suena muy adecuado.

De todos modos, como se mencionó en el artículo de Wikipedia que mencionó, una PVLAN determinada está compuesta de una VLAN primaria y una cantidad de VLAN auxiliares asociadas. Hay tres tipos de puertos PVLAN:

1.) Promiscuo: el tráfico recibido de un host en un puerto promiscuo se asigna directamente a la VLAN primaria y se transmite directamente a los puertos (aplicables) de todos los tipos en la VLAN. Entonces, por ejemplo, todos los demás hosts en la VLAN verán una transmisión proveniente de un host conectado a un puerto promiscuo, ya sea aislado, promiscuo o comunitario.

2.) Aislado: el tráfico recibido de un host en una VLAN aislada se asigna a una VLAN auxiliar. El tráfico aplicable en esta VLAN auxiliar se transmite (si corresponde) puertos promiscuos como si procediera de la VLAN primaria. Siguiendo el ejemplo anterior, una transmisión desde un host conectado a un puerto aislado se mapearía en la VLAN auxiliar y luego se enviaría fuera de los puertos promiscuos. Este tráfico no se asignaría a ningún otro puerto aislado o comunitario y, por lo tanto, no se vería en absoluto.

3.) Comunidad: los puertos comunitarios son puertos aislados que en realidad se asignan a varias VLAN auxiliares, tanto el auxiliar principal mencionado anteriormente (… que se asignará a puertos promiscuos) como a uno o más auxiliares adicionales que se asignarán a otros miembros del misma comunidad Nuevamente siguiendo el mismo ejemplo: un host conectado a un puerto comunitario PVLAN envía una transmisión. Esta trama se transmitirá tanto a los puertos promiscuos como a otros miembros de la misma comunidad (nuevamente, apareciendo en los hosts receptores como una trama más dentro de la VLAN). Dependiendo de la implementación específica, un puerto determinado podría pertenecer a múltiples comunidades y, de manera similar, podría existir una gran cantidad de comunidades dentro de una PVLAN. En realidad, este es un mecanismo utilizado en algunos IXP (puntos de intercambio de Internet) en los que se puede configurar una subred común que contenga un grupo de enrutadores de varios operadores para permitir la comunicación donde sea necesaria y bloquear por completo toda la visibilidad L2 / L3 como condición predeterminada.

En términos de seguridad, el aislamiento es, en sí mismo, bastante fuerte. En resumen, un paquete que ingresa en un puerto aislado literalmente no puede transmitirse a nada más que a un puerto promiscuo. Ahora, dicho esto, la vulnerabilidad obvia aquí es lo que esté conectado a puertos promiscuos. Tomemos su caso como ejemplo si ha tenido mucho cuidado de mantener todos los puertos IPMI en puertos aislados y luego ha colocado un host mal asegurado en un puerto promiscuo y si ese host está comprometido, su atacante ahora puede transmitir libremente el tráfico a todo en la red.

Hay un par de topologías típicas en las que se implementan PVLAN.

1.) La gran subred compartida: este es el caso de la red de respaldo mencionado en el artículo de Wikipedia (… y, por cierto, el caso de uso más común que he visto en los últimos años). En este caso, se proporciona una subred plana muy grande que contiene cientos (o miles) de interfaces de red dedicadas de servidores que sirven solo para enviar y recibir tráfico de respaldo hacia / desde uno o más servidores de medios en la misma subred. Los clientes de respaldo son puertos aislados y los servidores de medios son promiscuos. Vale la pena señalar que generalmente no hay un enrutador en la subred. El tráfico puede moverse libremente entre los clientes y los servidores de medios, pero los clientes no pueden comunicarse entre sí. Como una gran ventaja adicional, los clientes no necesitan rutas estáticas especiales para llegar a los servidores de medios (… esto puede ser una gran victoria) y como efecto secundario del mecanismo PVLAN muchos de los problemas tradicionales con grandes subredes compartidas (difusión / tormentas de multidifusión, inundaciones ARP, etc.) se eliminan principalmente.

2.) La red enrutada: en este caso, los diversos hosts (conexiones IPMI en su caso) están conectados a puertos aislados. La puerta de enlace predeterminada para la subred (probablemente un enrutador o un firewall) está conectada a un puerto promiscuo. Este dispositivo de puerta de enlace generalmente se configuraría con reglas de control de acceso muy restrictivas en la interfaz conectada que explícitamente no permitía el reenvío dentro de la subred y solo permitía tráfico muy específico desde fuera de la subred a los hosts. En su caso, sería una ACL que permite el acceso desde las estaciones de administración apropiadas a los servidores IPMI. La victoria aquí es que las interfaces IPMI estarían absolutamente aisladas unas de otras y la política aplicada en la puerta de enlace permitiría un control estricto.

Obviamente, hay muchas otras topologías y casos de uso (… como la configuración de PVLAN de la comunidad IXP que mencioné anteriormente) pero estas son las topologías más comunes que he visto para PVLAN a lo largo de los años. A su pregunta, estas son las principales advertencias y vulnerabilidades por las que me preocuparía:

1.) Como se mencionó anteriormente, los hosts en el puerto promiscuo pueden ser absolutamente un enlace débil. La misma lógica se aplica a los puertos de la comunidad, donde si un puerto dado es miembro de múltiples comunidades, un host mal configurado o comprometido podría ser un vector para romper el aislamiento. Si sus puertos promiscuos son enrutadores o firewalls bien protegidos, entonces esto no es una gran preocupación. En el caso de la red de respaldo, la seguridad de los servidores de medios se vuelve potencialmente más importante.

2.) Hay muchos detalles específicos de implementación sobre cómo / dónde se implementan las PVLAN. Todos los conmutadores que admiten la PVLAN deben configurarse de manera equivalente y debe prestarse especial atención a cómo, y si, cosas como los puertos aislados pueden ser troncales (enlaces con tramas etiquetadas 802.1q) y cómo podría comportarse el tráfico VLAN nativo (… sin etiquetar) marcos en enlaces que de otro modo admitirían etiquetado Esto va a variar tanto entre proveedores como incluso dentro de varias líneas de productos. Puede volverse aún más complejo al calcular el comportamiento de la conmutación virtual en hipervisores y cómo las cosas podrían mapearse al extenderse a través de la infraestructura extranjera (servicios administrados por operadores, puentes entre sitios, etc.). Es probable que la mayoría de esto no sea un problema para el caso que está describiendo (conexión directa de hardware al puerto IPMI, etc.), pero es el tipo de cosas que pueden ser dolorosas a escala en entornos complejos.

2a.) Si bien este es un conjunto bastante antiguo de características (… y el diseño básico / casos de uso bien aceptados en la industria), las diversas implementaciones pueden ser más nuevas. Revisar la base de datos de errores del proveedor y leer las notas de la versión de todo el firmware del conmutador asociado son medidas que siempre se recomiendan para cualquier característica recientemente implementada en su red.

3.) La consistencia de la configuración es realmente crucial. El simple hecho de no asignar un rol a un puerto físico dentro de una PVLAN (es decir, hacer que sea una conexión de host normal) también romperá el modelo de seguridad, ya que dicho puerto podría enviar cualquier cosa en la VLAN pero solo podría recibir tráfico enviado en los puertos promiscuos (… u otros puertos igualmente mal configurados).

Espero que esto sea útil.