STP y uso compartido de Vlans con infraestructura de cliente

[Translator]

Tengo una pregunta sobre STP Vlan Root.

Trabajo en un Call Center (CC), esta organización utiliza Cisco SWs para administrar su infraestructura L2; algunos clientes usan una topología híbrida (utiliza Call Center L2 SW para conectar a los usuarios finales, pero realizó una conexión a su L3 SW y FW para llegar a sus servicios de red).

El CC utiliza como administrador el Vlan 10, con STP Root Bridge se colocó como predeterminado (la administración más baja de SW Mac Add).

Al hacer un poco de trazado de Root Bridge, descubrí que Vlan 10 llega a otro Sw de la compañía:

Ejemplo:

Switch_Core#sh raíz de árbol de expansión

!

Vlan Root ID Costo Tiempo Antigüedad Dly Puerto raíz

VLAN0010 32768 0026.995a.fb00 42 2 20 15 Gi0/48

!

!

Switch_Dist#sh | de raíz de árbol de expansión i VLAN0010

VLAN0010 32768 0026.995a.fb00 38 2 20 15 Gi0/8

!

Este puente raíz de Vlan como siguiente paso Switch llega a un Switch cliente (al que no se puede acceder) con un Coste de 38.

Mi pregunta es si este CC puede estar expuesto a algún ataque ya que Admin Vlan Root Bridge (Vlan 10) está bajo otra topología de Switch.

No creo esta topología, pero encontré estos errores de configuración y el rediseño del árbol de expansión para la reorganización del puente raíz para proporcionar el valor más alto para el núcleo del conmutador y la actualización a RSTP que propuse se aprobó recientemente. Pero me pregunto qué consecuencias producirá que Admin Vlan haya estado expuesto durante tanto tiempo.

Por favor, no califique mi pregunta como spam (ayer publiqué esta pregunta y alguien marcó como SPAM), me tomó meses entender cómo funciona STP a nivel CCNA, pero el libro no proporciona explicación sobre el intercambio de Root Vlans y STP con otras topologías de clientes. Si Cisco cree que estoy rompiendo alguna regla, por favor dígamelo.

Más allá de que se aprobó una gestión de cambios STP, quiero entender mejor qué consecuencias podría tener la topología de ese cliente al tener este Admin Vlan Root (los servidores del Call Center se ejecutan en esta vlan).

Gracias.

[Translator]

Hola @patramirezort ,

Al cambiar bajo su control el que debería ser el puente raíz que puede usar

(Supongo que aquí está utilizando PVST o Rapid PVST, puede verificar esto con el resumen del árbol de spannig)

conf t

spanning-tree vlan 10 prioridad 0

Wanring: esto causará un recálculo STP en VLAN 10, pero hará que su cambio sea el Root Bridge como debe ser.

Hazlo fuera del horario comercial, pero tomará un minuto

Eventualmente, en un segundo interruptor bajo su control que le gustaría ser la copia de seguridad del puente raíz primario, puede usar:

conf t

spanning-tree vlan 10 prioridad 4096

Espero ayudar

Joseph

[Translator]

Hola, bueno mi pregunta va con las posibles consecuencias de que un tercero (infraestructura cliente) haya sido propiedad del Call Center Admin Root Vlan durante tanto tiempo y para saber si Call Center ha estado expuesto a algún tipo de ataque ya que el dominio Call Center VTP no tiene contraseña habilitada.

Se aprobó una gestión de cambios STP (pero con fecha pendiente de implementación) para modificar el puente raíz y proporcionar al núcleo del conmutador la gestión del puente raíz Vlan como debería ser.

Gracias

[Translator]

Por favor, por favor, alguien mencione cuáles sonlas posibles consecuencias de que un tercero (infraestructura del cliente) haya sido propiedad del Call Center Admin Root Vlan durante tanto tiempo y para saber si Call Center ha estado expuesto a algún tipo de ataque ya que el dominio Call Center VTP no tiene contraseña habilitada.

Ya se aprobó una gestión de cambios STP para reorganizar la gestión de Root Bridge para redirigir a Core Switch (con la actualización a RSTP), pero mientras tanto me interesa saber si la red de Call Center ha estado expuesta a algún tipo de ataque.

Gracias.

[Translator · Accepted solution]

Hola

En cuanto al dominio VTP sin contraseña, VTP y STP son independientes. Su VTP podría haber sido atacado independientemente de quién sea el conmutador raíz. Dicho esto, creo que si alguien intentara hacer algo malo a su VTP, ya lo habría notado porque un ataque a VTP daría lugar a la creación de nuevas VLAN o a la eliminación de VLAN existentes. Tales cambios son relativamente fáciles de detectar.

En cuanto a que el conmutador raíz se encuentre en una red de 3ª parte, bueno... La colocación del conmutador raíz no tiene ningún impacto en la accesibilidad de los hosts finales o de los propios conmutadores. Independientemente de quién sea el conmutador raíz en una red, la topología sin bucle resultante sigue contiendo todos los conmutadores y todos los hosts finales conectados a la red, y proporciona conectividad entre cualquier par de dispositivos. Desde este punto de vista, con solo tener el conmutador raíz ubicado en una red de 3ª parte, un atacante no habría obtenido ningún acceso adicional a los dispositivos además de lo que ya estaba disponible. Sin embargo, según cómo se vea la topología sin bucle resultante y cuáles son los patrones de tráfico en la red, un atacante podría haber obtenido acceso a flujos de tráfico a los que no habría tenido acceso antes, es decir, porque para algunos pares de dispositivos, su flujo de tráfico puede necesitar pasar por el conmutador raíz de 3rd party, lo que no sucedería si el switch root fuera otra persona. Sin embargo, si tal escucha ocurriera, sería casi imposible de probar.

Saludos
Pedro

[Translator]

Gracias por sus comentarios.

[Translator]

Hola @patramirezort ,

usind una contraseña para la protección del dominio VTP si el uso de VTP versión 2 es algo que sugeriría y que se puede agregar.

El cambio para agregar una contraseña requerirá una ventana de mantenimiento, pero no hay un impacto real durante la implementación

Al final puedes comprobar que todos los switches están de nuevo en el mismo dominio VP pero con un hash ( 16 bytes si mal no recuerdo ).

A largo plazo, pasar a la versión 3 de VTP es la mejor opción para la seguridad, ya que elimina el problema del conmutador no fiable con un mayor número de revisiones que puede cambiar la base de datos de VTP.

De coiurse antes de pasar a VTP versión 3 debe comprobar usando

mostrar el estado de vtp

que todos los switches son compatibles con VTP versión 3.

Este sería un cambio mayor, pero es un movimiento sabio a largo plazo.

Espero ayudar

Joseph

[Translator]

Joseph

También estoy de acuerdo en que si @patramirezort está utilizando activamente VTP en su red, sería mejor protegerlo con una contraseña. Al mismo tiempo, conociendo las deficiencias de VTP, personalmente recomiendo considerar alejarse de VTP por completo. Si el tamaño de la red es pequeño (solo un puñado de conmutadores), y si las VLAN se agregan o eliminan con poca frecuencia, ejecutar VTP trae poca o ninguna ventaja. En tal caso, sería más seguro simplemente deshabilitar VTP por completo (o al menos moverlo al modo transparente).

En cuanto a la necesidad de una ventana de mantenimiento para configurar una contraseña VTP, respetuosamente no estoy de acuerdo allí. La configuración de la contraseña de VTP es una operación no disruptiva. Una falta de coincidencia de contraseña de VTP significa que el conmutador no aceptará un cambio en la base de datos de VLAN con una contraseña de VTP diferente, pero las VLAN existentes no desaparecerán, sino que permanecerán en su lugar. El único riesgo real es con la poda VTP. Si VTP Pruning está activada, una falta de coincidencia de contraseña podría resultar en un blackholing del tráfico broadcast / desconocido unicast / multicast (BUM).

Saludos
Pedro

[Translator]

Hola Pedro,

>> En cuanto a la necesidad de una ventana de mantenimiento para configurar una contraseña VTP, respetuosamente no estoy de acuerdo allí.

Sí, desde un punto de vista técnico no debería haber ningún impacto en la implementación de una contraseña VTP.

Expresé mis pensamientos de una manera equivocada que debería haber escrito:

"El cambio para agregar una contraseña no requeriría una ventana de mantenimiento porque no hay un impacto real durante la implementación. Sin embargo, dependiendo de cómo ocurra la gestión del cambio en su empresa (políticas de ITIL, por ejemplo), usted (= el póster original) puede sentirse más cómodo al pedir uno".

Con respecto a pasar al modo transparente VTP es un posible consejo y puede ser un buen movimiento si la red es pequeña con un conjunto estable de VLAN o incluso en un entorno grande con la necesidad de crear y eliminar VLAN si la automatización de la red es utilizada por cosas de TI.

No sabemos cuántos interruptores están bajo el control administrativo del póster original. Podemos suponer que el conjunto de Vlans es estable siendo un contact center que atiende a múltiples clientes podemos pensar que se añaden nuevas VLAN para nuevos clientes.

Sin embargo, es difícil decir más.

Espero ayudar

Joseph

[Translator]

Solo quería agregar, hace algunos años, que me encontré con un problema de producción con la poda VTP. Tenía parte de una red de producción donde una VLAN funcionaría durante unos minutos, y luego dejaría de funcionar. Encontré el problema y lo resolví.

No recuerde los detalles completos, pero se debió a VTP y poda. Cisco estaba funcionando bien, es decir, no era un error, pero de alguna manera estaba relacionado con varios temporizadores de cuánto tiempo tardaría VTP en podar realmente la información frente a la VLAN. Creo que (?) tiene algo que ver con un switch, al ser transversado, que no estaba ejecutando VTP (como cliente [o servidor]).

Personalmente, me gusta VTP, pero he visto las VLAN de toda una red de producción caídas por el clásico (y descuidado) agregando un conmutador de laboratorio previo a la red de producción. (Por cierto, al menos para ese, no fui yo).

VTP, para mí, es como "partidos". Puede ser muy útil, pero si eres descuidado, te quemarás.

No lo he usado, pero mi lectura de VTPv3, aborda la mayoría, si no todos, de los "accidentes" "clásicos" que pueden ocurrir con versiones anteriores de VTP.

Oh, no lo recuerdo con certeza, pero VTP v1 o v2, las contraseñas pueden pasarse en texto sin cifrar. Es decir, si es así, no es una opción de seguridad súper fuerte, pero también recomiendo usarla, ya que era otra "salvaguarda" para ayudar a asegurar una operación segura de VTP (junto con la definición de un dominio VTP real). Configure ambos para ayudar a evitar "accidentes".

[Translator]

Hola @Joseph W. Doherty ,

Probé en un laboratorio el posible accidente de agregar un switch con un número de revisión higer para evitar reconstruir el laboratorio acabamos de demostrar que fue capaz de actualizar la base de datos VLAN agregando una nueva VLAN.

>> no lo recuerdo con certeza, pero VTP v1 o v2, las contraseñas pueden pasarse en texto sin cifrar.

Tengo entendido que la contraseña se utiliza para crear un hash MD5 al menos en VTP versión 2.

Hoy en día MD5 se considera rompible, pero al menos las contraseñas no se envían en texto sin cifrar.

VTPv3 es realmente una gran mejora y se puede combinar con MST y utilizando una base de datos adicional puede anunciar VLANS a MST instancias asignaciones haciendo la vida más fácil en caso de un cambio.

En VTPv3 solo el servidor principal puede realizar cambios en la base de datos VLAN y esto resuelve todos los problemas de las versiones anteriores.

Espero ayudar

Joseph

[Translator]

Hola

Gracias de nuevo por sus recomendaciones de mejores prácticas.

Saludos

Patricia

[Translator]

Buen día Giuseppe,

Gracias por sus recomendaciones de prácticas recomendadas de VTP.

Patricia

[Translator]

Hola

Gracias a todos por sus recomendaciones de VTP.