O Nível de Enlace Sob a Ótica do Atacante: ARP Spoofing, Saltos de VLAN e Jogos com o Switch

Na primeira parte deste ciclo, discutimos o nível físico do modelo OSI e como um atacante pode obter acesso à infraestrutura sem explorar vulnerabilidades de software, através de taps passivos, dropboxes de rede, dispositivos BadUSB e outras técnicas baseadas em acesso físico ao hardware. Suponhamos que esta etapa já foi superada. O cabo está conectado, o link está ativo e o dispositivo se tornou um participante pleno do segmento de rede local. À primeira vista, pode parecer que um obstáculo sério aguarda o atacante. A era dos hubs Ethernet acabou há muito tempo: switches modernos entregam tráfego pontualmente, em vez de duplicá-lo para todas as portas indiscriminadamente. VLANs permitem a segmentação lógica da infraestrutura em redes separadas, e mecanismos como NAC e 802.1X devem restringir a conexão de dispositivos não autorizados. A lógica parece bastante convincente. Se o switch não envia mais todo o tráfego para cada porta, parece que o problema de escuta de rede ficou no passado. Se os dispositivos estão em VLANs diferentes, eles estão isolados uns dos outros. Se o controle de acesso à rede está implementado, um dispositivo estranho não deve obter acesso pleno à infraestrutura. Na prática, tudo é um pouco mais complicado. A maioria dos mecanismos de nível de enlace foi criada principalmente para garantir conectividade, escalabilidade e facilidade de administração de rede. A segurança raramente foi o objetivo principal de seu desenvolvimento. Portanto, muitos protocolos e mecanismos dentro do segmento Ethernet ainda se baseiam na confiança entre os dispositivos. E onde há confiança, quase sempre surgem maneiras de abusar dela. Nesta parte, examinaremos o nível de enlace sob a ótica do atacante e analisaremos por que a presença de um switch ainda não torna a rede segura, como funcionam os ataques à infraestrutura Ethernet e quais características dos protocolos de rede permitem que um atacante influencie a troca de rede, intercepte dados ou obtenha acesso adicional dentro do segmento de rede. A maioria das técnicas descritas abaixo raramente é encontrada em redes corporativas bem administradas, mas continua sendo regularmente descoberta durante auditorias, pentests e análises de infraestrutura legada.

Mito 1. O Switch Protege Contra Interceptação de Tráfego Na época do uso de hubs comuns (concentradores), a rede era um único domínio de colisão. O hub operava no nível físico: recebia um quadro em uma porta e o duplicava cegamente para todas as outras. Para interceptar o tráfego, bastava ao atacante colocar a interface de rede em modo promíscuo (Promiscuous mode) e iniciar um analisador – toda a troca de rede do segmento ficava exposta. Switches mudaram fundamentalmente essa lógica. Um switch realiza a entrega direcionada de tráfego unicast conhecido. Ele se baseia na tabela CAM (Content Addressable Memory), onde os pares de endereços MAC de hardware dos nós e as portas físicas do dispositivo são registrados dinamicamente. Devido a isso, surgiu a crença persistente de que é impossível interceptar sessões de terceiros dentro do mesmo segmento. Uma forma clássica de contornar essa limitação é o ataque MAC Flooding. Ele é geralmente implementado usando a velha utilidade macof ou o framework Yersinia. A essência é inundar o switch com muitos quadros com endereços MAC de remetente falsos e aleatórios, esgotando completamente a capacidade da tabela CAM. Uma nuance importante: a afirmação comum de que, ao encher a tabela, "o switch se transforma em um hub" é tecnicamente incorreta. A lógica de hardware não é desativada. No entanto, quando entradas legítimas são substituídas por tráfego lixo, o switch não consegue encontrar os endereços MAC de destino na memória. Tais quadros são processados como Unknown Unicast. Para não interromper a conectividade, o dispositivo é forçado a transmitir esse tráfego para todas as portas dentro de um VLAN específico. Ao mesmo tempo, entradas legítimas que conseguem se atualizar continuam sendo comutadas pontualmente. Ou seja, a degradação é seletiva e não é equivalente ao comportamento de um hub clássico. Em redes corporativas modernas, o mac flooding em sua forma pura é ineficaz. O volume de memória dos chips ASIC modernos é grande, e a configuração básica da função Port Security (limitando o número de endereços MAC por porta) permite que a interface seja automaticamente colocada no estado err-disable nos primeiros sinais de anomalia. Por essa razão, o vetor mudou de tentar sobrecarregar os elementos de comutação no Data Plane para explorar as características arquitetônicas das pilhas de rede dos hosts finais. O switch, neste cenário, permanece um retransmissor passivo, e o ataque é direcionado à lógica de resolução dinâmica de endereços no nível do host. A tarefa do atacante é fazer com que os próprios nós finais alterem suas tabelas de correspondência e direcionem o tráfego para sua interface de rede.

Anatomia da Confiança: ARP Spoofing O protocolo ARP (Address Resolution Protocol) atua como um elo de ligação entre os endereços IP lógicos de nível de rede (L3) e os endereços MAC físicos de nível de enlace (L2). Quando um host precisa enviar um pacote, por exemplo, para o gateway padrão (192.168.1.1), sua pilha de rede gera uma solicitação de broadcast: "Quem tem o IP 192.168.1.1? Responda com seu MAC". Ao receber uma resposta ARP (ARP Reply), o host armazena essa correspondência em sua tabela local de vizinhos (neighbor table). A vulnerabilidade fundamental do ARP é a completa ausência de mecanismos integrados de autenticação e verificação de estado de sessão nos hosts. A maioria das implementações de pilhas de rede de sistemas operacionais modernos aceita e armazena respostas não solicitadas (unsolicited/unrequested ARP replies) por padrão, sem uma solicitação prévia. O sistema confia em tudo que chega à interface, mesmo que o próprio nó não tenha perguntado nada. O atacante usa essa propriedade para realizar o ataque ARP Spoofing (também conhecido como ARP Poisoning). Estando no mesmo domínio de broadcast, ele envia repetidamente respostas ARP falsificadas para dois alvos: para a vítima: afirmando que o endereço IP do gateway 192.168.1.1 agora corresponde ao [MAC_do_atacante]. Para o gateway: afirmando que o endereço IP da vítima 192.168.1.15 agora corresponde ao [MAC_do_atacante]. O switch continua funcionando normalmente, encaminhando quadros sem erros de acordo com sua tabela CAM, pois para ele este é um tráfego padrão do Data Plane. No entanto, devido à comprometimento do cache ARP nos pontos finais, o tráfego é redirecionado e fisicamente passa pelo nó do invasor no nível de enlace. Para organizar a interceptação, o atacante ativa o encaminhamento de pacotes no nível do kernel (sysctl -w net.ipv4.ip_forward=1), tornando-se um Man-in-the-Middle (MITM). A interceptação passiva e a manipulação ativa são realizadas com ferramentas como arpspoof, bettercap ou ettercap. Mesmo com a criptografia generalizada do tráfego web (TLS/HTTPS), a posição de MITM dentro do segmento permanece extremamente perigosa. A interceptação e a manipulação ativa permitem implementar os seguintes vetores: Interceptação de tráfego de serviço: Ainda no ambiente corporativo, um conjunto crítico de dados é transmitido em texto claro – desde consultas DNS e autenticação em texto claro em bancos de dados ou versões legadas de LDAP até tráfego de impressoras de rede, VoIP (SIP) e IoT. Interceptação de autenticação (SMB Relay): Um vetor chave em infraestruturas Windows. Assumindo a posição de MITM, o atacante intercepta o tráfego de autenticação unicast legítimo entre a estação de trabalho e o servidor (por exemplo, ao acessar compartilhamentos de rede). Usando utilitários como ntlmrelayx, essas solicitações são retransmitidas (Relay) para recursos adjacentes para execução de comandos. Nota para o pentester: Em redes modernas, este ataque é severamente limitado por mecanismos de proteção da Microsoft. Se a assinatura de pacotes (SMB Signing Required) estiver habilitada e solicitada no servidor de destino, ou se o Channel Binding (Enhanced Protection for Authentication – EPA / Channel Binding) estiver ativado, um Relay puro resultará em erro de autenticação. Manipulação de DNS: Interceptação de consultas UDP clássicas não criptografadas para o servidor DNS e vencendo a corrida de respostas (race condition) com o servidor legítimo para envenenamento local do cache (DNS cache poisoning). Certamente, em sistemas operacionais modernos, o ataque é complicado por mecanismos de randomização de TXID e porta de origem UDP, mas a posição de um MITM completo permite ao atacante ver esses parâmetros em tempo real e contornar essa proteção. A implementação de DNSSEC nos hosts poderia minimizar esse risco, mas no cenário corporativo interno real, sua validação nas estações de trabalho finais é extremamente rara. Em redes onde o IPv6 está implantado, o protocolo ARP não é usado – suas funções são desempenhadas pelo NDP (Neighbor Discovery Protocol). No entanto, a lógica de "confiança" permaneceu a mesma: um atacante pode realizar ataques análogos da classe NDP Poisoning (através de Neighbor Advertisement falsos) ou Rogue RA (Router Advertisement), interceptando o tráfego IPv6 dos hosts. O DAI básico é impotente contra isso – para proteger o segmento IPv6 nos switches, é necessário configurar funções separadas da classe IPv6 First-Hop Security (IPv6 RA Guard, IPv6 Neighbor Discovery Inspection). Ao mesmo tempo, vale lembrar que mesmo o IPv6 RA Guard, em algumas implementações, possui técnicas públicas de contorno através da fragmentação de pacotes IPv6, o que exige atenção redobrada do administrador à atualidade dos firmwares do equipamento.

Como se defender: Mecanismos de nível de Host e de Rede A proteção contra ARP Spoofing pode ser construída tanto no nível dos hosts finais quanto no nível de hardware do equipamento de rede. Nível de Host (Host-level): Tabelas estáticas (Static ARP): Fixação rígida do par IP-MAC no sistema operacional (arp -s). O método exclui localmente os riscos de ARP Spoofing bem-sucedido, mas é absolutamente inescalável no ambiente corporativo, quebra mecanismos de alta disponibilidade de gateways (por exemplo, durante a migração de IPs virtuais em failover VRRP/HSRP) e inevitavelmente leva à deriva operacional das configurações. Monitoramento (OS-level detection): Uso de daemons de monitoramento como arpwatch ou software especializado (XArp), que analisam o tráfego de rede do host e sinalizam alterações anômalas de endereços MAC para IPs críticos (por exemplo, o gateway). Nível de Rede (Network-level): O principal mecanismo de hardware de proteção no nível do switch é a implementação da tecnologia DAI (Dynamic ARP Inspection) em conjunto com IP Source Guard (IPSG). DAI (Dynamic ARP Inspection): A função intercepta todos os quadros ARP nas portas de acesso e valida os pares IP e MAC especificados neles antes de encaminhá-los. Dependendo da arquitetura do ASIC e das configurações do sistema operacional do fornecedor, esse processo de inspeção pode levar ao envio de pacotes para processamento pela CPU do switch (CPU punt), o que impõe limitações de rate-limit para tais quadros para evitar DoS no próprio switch. Como banco de dados de referência, o DAI utiliza a tabela dinâmica DHCP Snooping Binding Table. Uma tentativa do atacante de enviar uma resposta ARP falsa com um IP incorreto é imediatamente descartada pelo switch. Para servidores com endereçamento estático, o administrador cria regras de validação permanentes manualmente – ARP ACL. IPSG (IP Source Guard): Um mecanismo que protege o Data Plane dos hosts. Enquanto o DAI verifica exclusivamente quadros ARP (lógica de Control-plane dos hosts), o IPSG inspeciona o IP de Origem no cabeçalho de cada pacote IP que sai da porta do cliente. Importante notar: este mecanismo funciona exclusivamente em portas de acesso (Access) e tecnologicamente não é aplicado em interfaces de trunk de backbone ou roteadores L3 uplink puros. Sem IPSG, o atacante, bloqueado no nível ARP, ainda poderia enviar pacotes com um endereço IP de origem falsificado (IP Spoofing) – por exemplo, para realizar ataques UDP destrutivos.

Mito 2. O Switch Valida Fontes de Protocolos de Serviço Existe um equívoco de que os protocolos de gerenciamento de topologia de rede possuem mecanismos integrados de autenticação de fontes. Na prática, o switch não opera com abstrações como "confiança" ou "legitimidade" – seu comportamento é determinado por uma máquina de estados finitos determinística orientada a eventos (FSM), executada como um processo de Control-plane. O principal mecanismo para garantir a alta disponibilidade em redes Ethernet é a família STP (Spanning Tree Protocol). Os padrões 802.1D, 802.1w (RSTP) e 802.1s (MSTP) resolvem o problema de eliminar loops na topologia bloqueando logicamente links redundantes. Para coordenar a árvore, os switches calculam o Root Bridge. A troca de informações topológicas ocorre através de quadros BPDU, que são alimentados no processo STP do Control-plane sem qualquer ligação criptográfica com a fonte. A essência da vulnerabilidade: Manipulação de STP (Root Bridge Takeover). A eleição do Root Bridge é baseada no parâmetro Bridge ID (prioridade + endereço MAC). O nó com o menor valor de Bridge ID vence. O protocolo não distingue entre "invasor" e "engenheiro de rede" – ele reage exclusivamente à estrutura da mensagem e suas métricas de acordo com o algoritmo de seleção. Estando atrás de uma porta de acesso, o atacante pode iniciar uma mudança na topologia: Ferramenta (por exemplo, o mesmo Yersinia) gera um BPDU de configuração com a prioridade mínima (0) e seu endereço MAC. Ao receber tal quadro, o switch o encaminha para o processo STP do Control-plane, onde ele passa pela validação e transições de estado da máquina de estados STP dependente do papel (role-dependent STP state machine). O switch recalcula a topologia spanning-tree, determinando novas funções de Root Port e Designated Port, e depois transmite seus próprios BPDUs com informações atualizadas. Se no antigo 802.1D a reconstrução da árvore levava até 50 segundos, nos RSTP modernos (em topologias típicas com portas de borda corretamente marcadas e caminhos alternativos) a convergência, graças ao mecanismo Proposal/Agreement, ocorre em milissegundos. Dependendo da topologia, isso pode permitir que o atacante influencie o tráfego ou cause uma interrupção em larga escala da rede. Outro vetor de ataque é a geração de quadros TCN (Topology Change Notification). Recebê-los inicia o mecanismo de propagação de mudança de topologia: o root bridge define o flag TC no BPDU, que se propaga pela rede. No 802.1D, isso leva a uma redução temporária do tempo de envelhecimento MAC para o valor de Forward Delay. No 802.1w (RSTP), o recebimento de um BPDU com o flag TC definido inicia o mecanismo de limpeza de entradas na tabela CAM em portas não raiz (non-edge). A geração contínua de tais quadros causa uma limpeza constante de endereços MAC, um aumento do tráfego Unknown Unicast e uma severa degradação do desempenho da rede.

Como se defender: Engenharia de Portas (BPDU Guard e Root Guard) A proteção da topologia é construída com base na restrição de hardware das funções das interfaces, excluindo portas de cliente do cálculo FSM. BPDU Guard (em conjunto com PortFast / Edge Port): A função spanning-tree portfast move a porta do cliente para o estado de encaminhamento (Forwarding), pulando as fases padrão de escuta/aprendizagem do STP. Ao mesmo tempo, a porta continua a receber BPDUs, mas é excluída do cálculo da topologia (como uma porta de borda). Acima disso, a tecnologia BPDU Guard deve ser aplicada. Ao detectar um BPDU de entrada em tal interface, a porta é preventivamente movida para err-disable. Nuance de design: Em ambientes de virtualização (ESXi, KVM), um BPDU Guard rígido pode levar ao isolamento do servidor. Nesses casos, usa-se o BPDU Filter (ignora BPDUs de entrada). Em cenários legados ou de provedor de borda específicos, este método é aceitável, mas em um ambiente corporativo típico requer controle rigoroso do domínio L2. Root Guard: Aplica-se em interfaces de downlink de infraestrutura de switches de agregação. Se um BPDU com um Root ID mais preferencial do que o atual chegar através de tal interface, o switch bloqueia a mudança de topologia. Ele move a interface para o estado root-inconsistent (ou um status de bloqueio análogo, dependendo do fornecedor). O bloqueio persiste enquanto a chegada do BPDU superior não cessar.

Mito 3. VLAN Garante Isolamento Absoluto Após conhecer os ataques a ARP e protocolos de serviço, muitos chegam à seguinte conclusão lógica: se os usuários forem divididos em VLANs diferentes, o problema desaparecerá. À primeira vista, isso parece razoável. Dispositivos da VLAN 10 não recebem tráfego de broadcast da VLAN 20, possuem sub-redes IP isoladas e não podem interagir diretamente no nível de enlace. É por isso que a tecnologia VLAN (IEEE 802.1Q) é frequentemente percebida erroneamente como um mecanismo de segurança completo. Na prática, VLANs fornecem segmentação lógica de domínios de broadcast. A comutação de quadros e o aprendizado de endereços MAC são geralmente executados independentemente para cada VLAN (modelo Independent VLAN Learning, IVL), o que evita a sobreposição de tabelas de comutação entre domínios de broadcast. A segurança aqui é apenas um efeito colateral de uma arquitetura correta. Erros de configuração de máquinas de estado de porta ou características de processamento de tráfego com tag podem destruir completamente o isolamento pretendido.

Como funciona VLAN no nível ASIC O padrão IEEE 802.1Q define a encapsulação de um quadro Ethernet com uma tag especial de 4 bytes contendo o identificador VLAN (VID). Os switches usam este identificador para restringir o encaminhamento do quadro aos limites do domínio de broadcast correspondente. Do ponto de vista da lógica de processamento, as portas são divididas em dois tipos básicos: Access Port (Porta de Acesso): Destinada à conexão de dispositivos finais e logicamente associada a um VLAN específico (PVID). A pertencimento VLAN do quadro é mantido nos metadados internos do ASIC. Na fase de saída (Egress), o tráfego sai da porta sem tag. Trunk Port (Porta de Trunk): Capaz de multiplexar tráfego de vários VLANs simultaneamente. Os quadros são transmitidos com a adição explícita de tags 802.1Q. Usado para conectar nós de infraestrutura (switches, roteadores, hipervisores). A interação entre as regras de entrada (Ingress) das portas de acesso e as regras de saída (Egress) das portas de trunk historicamente gerou uma classe de ataques VLAN Hopping. Dois vetores fundamentais são conhecidos: Switch Spoofing e Double Tagging. Em redes corporativas modernas, o primeiro é praticamente sempre bloqueado por configurações de segurança básicas, enquanto o segundo ainda aparece regularmente em auditorias devido a erros de projeto do Native VLAN.

Vetor 1. Switch Spoofing (Exploração de DTP) Versões anteriores de equipamentos Cisco (e de alguns outros fornecedores) usavam o protocolo DTP (Dynamic Trunking Protocol) para negociar automaticamente conexões de trunk. Se um switch anunciava sua disposição em formar um trunk (estados Dynamic Desirable ou Dynamic Auto), a interface vizinha adaptava automaticamente sua função. O atacante conecta um host a uma porta de cliente e gera quadros DTP com o status Desirable. O DTP FSM inicia a formação de uma conexão de trunk, movendo a interface para o modo Trunk se a configuração do lado oposto for compatível. O atacante obtém um link de trunk. Ao configurar sub-interfaces 802.1Q em seu sistema operacional, ele obtém acesso a todos os VLANs permitidos no trunk formado (o que, em redes mal configuradas, frequentemente significa a maioria dos VLANs da infraestrutura). Por que isso é raro hoje: Em redes modernas, portas de trunk e de cliente geralmente são configuradas explicitamente, sem negociação automática: Fixação explícita da função da porta do cliente (switchport mode access); Desativação completa do DTP através da diretiva switchport nonegotiate; Proibição da formação dinâmica de trunks em interfaces de usuário. Portanto, o ataque Switch Spoofing hoje é relevante principalmente para infraestruturas legadas ou segmentos com graves erros de configuração.

Vetor 2. Double Tagging (Tags Aninhadas) O Double Tagging é interessante porque não requer erros na implementação do protocolo. O ataque explora o mecanismo padrão de Native VLAN, previsto pelo padrão 802.1Q. Para realizar a injeção, o atacante forma um quadro customizado com dois tags VLAN imediatamente: Tag externa (Outer VLAN): corresponde ao Native VLAN do link de trunk (por exemplo, VLAN 10). Tag interna (Inner VLAN): corresponde ao segmento VLAN de destino (por exemplo, VLAN 20). A mecânica de passagem do quadro pela fábrica da rede é a seguinte: O quadro chega à porta de acesso do primeiro switch. A tag externa corresponde ao VLAN atribuído a esta porta. Para um ataque bem-sucedido, é necessário que o primeiro switch não descarte o quadro especialmente formado com tags aninhadas na fase de entrada (plataformas modernas frequentemente descartam tais quadros já na entrada, mas algumas configurações permitem tal processamento). Ao transmitir pelo trunk, o switch detecta que o quadro pertence ao VLAN 10. Como no modelo clássico 802.1Q o Native VLAN é transmitido pelo trunk sem tag, o switch remove legitimamente (strip) a tag externa. Ao realizar a operação de remoção da tag do Native VLAN, a segunda tag não é considerada como um nível separado de classificação VLAN e permanece parte do quadro. O segundo switch recebe o quadro do trunk. Como a tag externa foi removida pelo switch anterior, na fase de entrada, o ASIC lê o primeiro cabeçalho disponível – a tag interna restante (VLAN 20). Para o segundo switch, tal quadro já parece um quadro 802.1Q normal do VLAN 20, após o que a comutação padrão dentro deste segmento é realizada, direcionando o pacote para a vítima.

Restrições Arquitetônicas do Double Tagging Na apresentação popular, frequentemente se afirma que o Double Tagging permite contornar completamente o isolamento VLAN. Isso é tecnicamente incorreto devido a várias restrições rígidas: Dependência do Native VLAN: O atacante deve estar fisicamente no mesmo VLAN que é usado como Native VLAN no trunk entre os switches. Sem isso, o switch não realizará o procedimento de remoção da tag externa na fase de saída da porta de trunk. Estrita Unidirecionalidade (Unidirectional): A variante clássica do Double Tagging é predominantemente unidirecional e, por si só, não garante uma troca bidirecional completa (Full TCP Handshake). Os pacotes de resposta da vítima são formados legitimamente, não possuem tag dupla e são roteados pelas regras L3 padrão, não retornando ao invasor no L2. O valor prático do ataque se resume à entrega de quadros únicos para outro VLAN, contornando políticas ACL específicas, injetando tráfego UDP/ICMP e cenários limitados de DoS em serviços de infraestrutura que não exigem troca bidirecional completa.

Como se defender: Native VLAN e controle de trunks A proteção do domínio L2 é construída não em torno do próprio mecanismo VLAN, mas em torno do controle rigoroso de tráfego com tag e parâmetros de interface: Desativação do DTP: Todas as interfaces de usuário devem ser explicitamente configuradas como portas de acesso. A negociação dinâmica de trunks deve ser desativada (switchport nonegotiate). Isso elimina completamente a classe de ataques Switch Spoofing. Abandono do uso do VLAN 1: O VLAN 1 é tradicionalmente usado por muitos fornecedores como VLAN de serviço padrão e está intimamente ligado ao processamento de vários protocolos de infraestrutura (por exemplo, CDP, VTP, PAgP em plataformas Cisco). Colocar dispositivos de usuário ou Native VLAN no VLAN 1 é considerada uma prática de projeto indesejável e uma violação das recomendações de segurança comuns. Native VLAN Dedicado (Parking Lot): Para trunks, recomenda-se usar um VLAN separado, isolado e não utilizado (por exemplo, VLAN 999). Tal VLAN não deve conter dispositivos de usuário, servidores ou gateways L3. Isso elimina o cenário clássico de Double Tagging, pois o atacante perde a capacidade de estar no VLAN usado como Native VLAN da магистраль. Forçar a tag do Native VLAN (Tag Native): Muitas plataformas modernas permitem forçar a tag do Native VLAN no trunk (por exemplo, diretiva vlan dot1q tag native). Neste caso, o abandono do tráfego Native VLAN sem tag muda a lógica: o segundo switch não verá mais a situação em que a tag interna se torna o primeiro cabeçalho VLAN do quadro após a remoção da tag do Native VLAN, portanto, o esquema clássico de Double Tagging deixa de funcionar. Restrição da lista de VLANs em trunks (Trunk Pruning): Deve-se especificar explicitamente a lista de VLANs permitidos (switchport trunk allowed vlan), em vez de usar as configurações padrão (all). O quadro será descartado na primeira interface de trunk onde este VLAN não estiver na lista de permitidos. VLAN é um mecanismo de segmentação, não um mecanismo de controle de acesso. A segurança é alcançada não pelo fato da divisão em VLANs, mas pela configuração correta de trunks, Native VLANs, ACLs, roteamento inter-VLAN e mecanismos de proteção do switch. Um erro de configuração pode transformar a fronteira entre VLANs em uma convenção administrativa, e não em uma barreira de segurança real.

Mito 4. DHCP Apenas Distribui Endereços O protocolo DHCP (Dynamic Host Configuration Protocol) é tradicionalmente percebido como um serviço isolado de camada de aplicação (L7), cujo papel se limita à automação da distribuição de endereços IP. No contexto da segurança de redes comutadas, vale uma axioma básica: o DHCP não participa do plano de dados (Data Plane) e não afeta diretamente o estado CAM/forwarding. O DHCP se torna a principal fonte de informação para construir a tabela de correspondência de endereços IP, endereços MAC e portas do switch. Vetor 1. Rogue DHCP Server O ataque explora a natureza broadcast da entrega de mensagens em um segmento L2. Como as solicitações DHCP Discover são enviadas para o endereço broadcast FF:FF: