STP e compartilhamento de Vlans com infraestrutura de clientes

[Translator]

Tenho uma pergunta sobre o STP Vlan Root.

Eu trabalho em um Call Center (CC), esta organização usa SWs Cisco para gerenciar sua infraestrutura L2; alguns clientes usam uma topologia híbrida (usa o Call Center L2 SW para conectar usuários finais, mas fez uma conexão com seus L3 SW e FW para chegar aos seus serviços de rede).

O CC usa como administrador o Vlan 10, com STP Root Bridge foi colocado como padrão (o menor gerenciamento SW Mac Add).

Ao fazer alguns rastreamentos da Ponte Raiz, descobri que Vlan 10 alcança outro Sw da empresa:

Exemplo:

Switch_Core#sh raiz de árvore de abrangência

!

Vlan Root ID Custo Tempo Idade Dly Raiz Porta

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

!

!

Switch_Dist#sh | raiz de árvore de abrangência i VLAN0010

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

!

Esta ponte raiz Vlan como próximo passo Switch atinge um Switch cliente (que não pode acessar) com um custo de 38.

Minha pergunta é se este CC pode ser exposto a algum ataque, já que a Ponte Raiz Admin Vlan (Vlan 10) está sob outra topologia do Switch?

Eu não crio esta topologia, mas encontrei esses erros de configurações e o redesign da Árvore de Abrangência para o rearranjo da Ponte Raiz para fornecer o maior valor para o switch core e upgrade para RSTP que eu propus foi aprovado recentemente. Mas pergunto-me que consequências produzirão que o administrador Vlan foi exposto por tanto tempo.

Por favor, não classifique minha pergunta como um SPAM (ontem eu postei esta pergunta e alguém marcado como um SPAM), levei meses para entender como o STP funciona como nível CCNA, mas o livro não fornece explicação sobre compartilhar Root Vlans e STP com outros clientes topologias. Se cisco acredita que estou abordendo alguma regra gentilmente, por favor me diga.

Além de que um gerenciamento de mudança stp foi aprovado, quero entender melhor quais as consequências que a topologia do cliente tem este Admin Vlan Root (servidores do Call Center estão sendo executados neste vlan).

Obrigado.

[Translator]

Olá @patramirezort,

no interruptor sob o seu controle o que deve ser a Ponte Raiz que você pode usar

( Estou assumindo aqui que você está usando PVST ou PvST rápido você pode verificar isso com o resumo show spannig-tree)

conf t

abrangência-árvore vlan 10 prioridade 0

Wanring: isso causará um recálculo STP em VLAN 10, mas fará com que a ponte raiz como deveria ser.

Faça isso fora do horário comercial, mas vai levar um minuto

Eventualmente, em um segundo switch sob o seu controle, você gostaria de ser o backup da ponte raiz primária que você pode usar:

conf t

abrangência vlan 10 prioridade 4096

Espero ajudar

Joseph

[Translator]

Oi, bem, minha pergunta vai com as possíveis consequências de um terceiro (infraestrutura do cliente) é propriedade do Call Center Admin Root Vlan por tanto tempo e saber se Call Center foi exposto a algum tipo de ataque, já que o domínio VTP do Call Center não tem nenhuma senha habilitada.

Um gerenciamento de mudança STP foi aprovado (mas com data pendente para implementar) para modificar a ponte Root e fornecer ao núcleo switch o gerenciamento da Ponte Raiz Vlan como deveria ser.

Obrigado

[Translator]

Por favor, alguém mencionou quais sãoas possíveis consequências de um terceiro (infraestrutura do cliente) ter sido possuído pelo Call Center Admin Root Vlan por tanto tempo e saber se o Call Center foi exposto a algum tipo de ataque, já que o domínio VTP do Call Center não tem habilitação para senha.

Um gerenciamento de mudança stp já foi aprovado para reorganizar o gerenciamento root bridge para redirecionar para Core Switch (com a atualização para RSTP), mas enquanto isso eu sou interessante saber se a rede Call Center foi exposta a algum tipo de ataque.

Obrigado.

[Translator · Accepted solution]

Olá

Quanto ao domínio VTP sem senha, VTP e STP são independentes. Seu VTP pode ter sido atacado independentemente de quem seja o interruptor raiz. Dito isto, acho que se alguém tentasse fazer algo ruim ao seu VTP, você já teria notado porque um ataque ao VTP resultaria em novas VLANs sendo criadas ou VLANs existentes sendo excluídas. Tais mudanças são relativamente fáceis de detectar.

Quanto ao interruptor raiz estar localizado em uma rede de terceiros, bem... A colocação do switch raiz não tem impacto na capacidade de alcance dos hosts finais ou dos próprios switches. Independentemente de quem seja o switch raiz em uma rede, a topologia sem loop resultante ainda contém todos os switches e todos os hosts finais conectados à rede, e fornece conectividade entre qualquer par de dispositivos. Deste ponto de vista, apenas por ter o switch raiz localizado em uma rede de terceiros, um invasor não teria obtido acesso adicional a dispositivos em cima do que já estava disponível. No entanto, com base em como a topologia sem loop resultante se parece, e quais são os padrões de tráfego na rede, um invasor poderia ter tido acesso a fluxos de tráfego que ele não teria tido acesso antes - isso porque para alguns pares de dispositivos, seu fluxo de tráfego pode precisar passar pelo switch raiz de terceiros que não aconteceria se o switch raiz fosse outra pessoa. No entanto, se tal escuta acontecesse, seria quase impossível provar.

Atenciosamente
Pedro

[Translator]

Obrigado pelo seu feedback.

[Translator]

Olá @patramirezort,

usind uma senha para proteção do domínio VTP se o uso da versão VTP 2 é algo que eu sugeriria e que pode ser adicionado.

A alteração para adicionar uma senha exigirá uma janela de manutenção, mas não há impacto real durante a implantação

No final você pode verificar se todos os switches estão novamente no mesmo domínio VP, mas com um hash ( 16 bytes, se bem me lembro).

No longo prazo, mudar-se para vtp versão 3 é a melhor escolha para a segurança, pois elimina o problema do switch desonesto com um número de revisão maior que pode alterar o banco de dados VTP.

De enrolar antes de mudar para VTP versão 3 você deve verificar usando

mostrar status vtp

que todos os seus switches suportam vtp versão 3.

Esta seria uma mudança maior, mas é um movimento sábio a longo prazo.

Espero ajudar

Joseph

[Translator]

Joseph

Também concordo que se @patramirezort estiver usando ativamente VTP em sua rede, seria melhor protegê-lo com uma senha. Ao mesmo tempo, conhecendo as deficiências de VTP, recomendo pessoalmente considerar migrar para longe do VTP completamente. Se o tamanho da rede for pequeno (apenas um punhado de switches), e se as VLANs forem adicionadas ou removidas com pouca frequente, a execução de VTP lá traz pouca ou nenhuma vantagem. Nesse caso, seria mais seguro apenas desativar o VTP completamente (ou pelo menos movê-lo para o modo transparente).

Quanto à necessidade de uma janela de manutenção para configurar uma senha VTP, respeitosamente discordo lá. Configurar senha VTP é uma operação sem interrupções. Uma incompatibilidade de senha VTP significa que uma alteração no banco de dados VLAN não será aceita pelo switch com uma senha VTP diferente, mas as VLANs existentes não desaparecerão - elas permanecerão no lugar. O único risco real é com vtp podando. Se o VTP Pruning estiver ligado, uma incompatibilidade de senha pode potencialmente resultar em blackholing do tráfego de transmissão / unicast / multicast (BUM) desconhecido.

Atenciosamente
Pedro

[Translator]

Olá Peter,

>> Quanto à necessidade de uma janela de manutenção para configurar uma senha VTP, respeitosamente discordo lá

Sim, do ponto de vista técnico não deve haver impacto na implantação de uma senha VTP .

Eu expressei meus pensamentos de uma maneira errada que eu deveria ter escrito:

"A mudança para adicionar uma senha não exigiria uma janela de manutenção porque não há impacto real durante a implantação. No entanto, dependendo de como a gestão de mudanças acontece em sua empresa ( políticas ITIL, por exemplo) você ( = o pôster original) pode se sentir mais confortável para pedir um."

Em relação à mudança para o modo transparente VTP é um conselho possível e pode ser uma boa jogada se a rede for pequena com conjunto estável de VLANs ou mesmo em um ambiente grande com a necessidade de criar e excluir VLANs se a automação de rede for usada por material de TI.

Não sabemos quantos interruptores estão sob o controle administrativo do pôster original. Podemos assumir que o conjunto de Vlans é estável sendo um contact center atendendo vários clientes, podemos pensar que novas VLANs são adicionadas para novos clientes.

No entanto, é difícil dizer mais.

Espero ajudar

Joseph

[Translator]

Eu só queria acrescentar, alguns anos atrás, teve um problema de produção com poda VTP. Tinha parte de uma rede de produção onde um VLAN trabalharia por alguns minutos, e depois pararia de trabalhar. Eu encontrei o problema, e resolvi isso.

Não se lembre dos detalhes completos, mas foi devido a VTP e poda. A Cisco estava funcionando bem, ou seja, não era um bug, mas de alguma forma estava relacionada com vários temporizadores de quanto tempo levaria VTP para realmente podar vs. informações VLAN. Eu acho que (?) ele tem algo a ser devido com um switch, sendo transversal, que não estava executando VTP (como cliente [ou servidor]).

Pessoalmente, eu gosto de VTP, mas vi todas as VLANs de uma rede de produção serem descartadas pelo clássico (e descuidado) adicionando um switch de laboratório anterior à rede de produção. (BTW, pelo menos para esse, não fui eu.)

VTP, para mim, é como "fósforos". Pode ser muito útil, mas se você for descuidado, você vai se queimar.

Eu não usei, mas minha leitura de VTPv3, aborda a maioria, se não todos, dos "clássicos" "acidentes" que podem acontecer com versões VTP anteriores.

Oh, eu não me lembro com certeza, mas VTP v1 ou v2, senhas podem ser passadas em texto claro. Ou seja, se assim for, não é uma opção de segurança super forte, mas também recomendo usá-la, pois era outra "salvaguarda" para ajudar a garantir a operação VTP segura (juntamente com a definição de um domínio VTP real). Configure ambos para ajudar a evitar "acidentes".

[Translator]

Olá @Joseph W. Doherty,

Testei em um laboratório o possível acidente de adicionar um switch com um número de revisão higer para evitar reconstruir o laboratório, apenas demonstramos que ele foi capaz de atualizar o VLAN DB adicionando um novo VLAN.

>> não me lembro com certeza, mas VTP v1 ou v2, senhas podem ser passadas em texto claro.

Meu entendimento é que a senha é usada para criar um hash MD5 pelo menos na versão VTP 2.

Nowdays MD5 é considerado quebrável, mas pelo menos senhas não são enviadas em texto claro.

O VTPv3 é realmente uma grande melhoria e pode ser combinado com o MST e usando um banco de dados adicional ele pode anúncios vlans para mapeamentos de instâncias MST facilitando a vida em caso de mudança.

No VTPv3 apenas o servidor principal pode fazer alterações no banco de dados VLAN e isso resolve todos os problemas das versões mais antigas.

Espero ajudar

Joseph

[Translator]

Oi

Obrigado novamente por suas recomendações de boas práticas.

Relação

Patricia

[Translator]

Bom dia Giuseppe,

Obrigado por suas recomendações de práticas recomendadas de VTP.

Patricia

[Translator]

Oi

Obrigado a todos por suas recomendações de VTP.