Vizinhos na Fiação: Dissecando a Rede de um Provedor que se Esqueceu do Isolamento de Clientes

Vizinhos na Fiação: Dissecando a Rede de um Provedor que se Esqueceu do Isolamento de Clientes

Uma análise detalhada de uma rede de provedor exposta, revelando vulnerabilidades como ARP spoofing, brute force em roteadores e injeção de rotas OSPF. O artigo explora cenários de ataque e oferece soluções para proteger sua infraestrutura.

MundiX News·15 de maio de 2026·10 min de leitura·👁 3 views

Conteúdo do artigo

Sexta à noite que não saiu como planejado Pânico, hipóteses, becos sem saída Cavando em direção ao provedor Verificando o quão ruim é O que um invasor pode fazer com isso Cenário 1. ARP spoofing - interceptando o tráfego dos vizinhos Cenário 2. Força bruta em roteadores via MAC Telnet e muito mais Cenário 3. Injeção de rotas via OSPF Cenário 4. Reconhecimento passivo via OSPF - sem uma única varredura Cenário 5. Botnet que não vai para a internet Cenário 6. Vazamento de informações sobre a infraestrutura do provedor Escrevendo para o provedor Fazendo por conta própria, já que é assim Proteção 1. Firewall na interface WAN - cortando tudo desnecessário Proteção 2. Desativando a Descoberta de Vizinhos na WAN Proteção 3. Desativando MAC Telnet e MAC Winbox na WAN Proteção 4. Removendo serviços de gerenciamento da WAN Proteção 5. Filtragem ARP O que eu tirei disso

Em uma noite normal de sexta-feira, entrei no Winbox para corrigir o NAT - e descobri em Neighbors do meu MikroTik duas dúzias de dispositivos estranhos: roteadores, NAS, pontos de acesso de empresas desconhecidas. Neste artigo, vou contar como descobri que o provedor jogou todos os clientes corporativos em um único segmento L2 sem qualquer isolamento, analisarei seis cenários de ataque - de ARP spoofing e brute force MAC Telnet a injeção de rotas via OSPF e construção de uma botnet que não vai para a internet - e mostrarei como fechar o perímetro por conta própria, já que o provedor não está interessado nisso.

Sexta à noite que não saiu como planejado

Tudo começou de forma bastante rotineira: na sexta-feira, às seis da tarde, decidi corrigir a regra NAT no nosso MikroTik do escritório, porque a contabilidade não conseguia entrar em outro portal do governo. Abri o Winbox, acidentalmente cliquei em Neighbors e fiquei um pouco viciado.

Para quem não trabalhou com MikroTik, vou explicar: na guia Neighbors, você pode ver os dispositivos detectados através dos protocolos de descoberta L2 - MNDP (proprietário MikroTik), CDP (Cisco) e LLDP (padrão IEEE 802.1AB). Todos os três funcionam na camada de link de dados e são distribuídos dentro do domínio de broadcast, ou seja, mostram apenas o que está no mesmo segmento L2 que você. Em uma situação normal, você pode ver no máximo seu switch ou o roteador do provedor.

Eu tinha cerca de vinte e cinco dispositivos estranhos lá. Com nomes estranhos, endereços MAC estranhos e IPs totalmente funcionais. Algumas LLC "Romashka", algum NAS e alguns pontos de acesso de origem desconhecida. Um zoológico completo. Se eles são visíveis em Neighbors, significa que todos esses dispositivos estão fisicamente no mesmo domínio de broadcast que eu. E isso não deveria acontecer.

Lista de vizinhos no Winbox. Expectativa: nosso roteador. Realidade: um monte de endereços e dispositivos desconhecidos

Pânico, hipóteses, becos sem saída

O primeiro pensamento foi de pânico e relacionado às realidades atuais: estamos sendo hackeados. Alguém entrou na rede, instalou seus dispositivos e está prestes a roubar os desenvolvimentos da empresa e, ao mesmo tempo, dados pessoais. Ou talvez já esteja usando nossa infraestrutura como parte de uma botnet há mais de um dia. Fui verificar: mudei a senha do roteador, vasculhei os logs de autorização, mas tudo acabou sendo limpo. As regras do firewall estão no lugar, não há conexões estranhas de dentro. Analisei o tráfego interno através do NTA (Network Traffic Analysis) do fornecedor e já manualmente através do Wireshark. Fui para o servidor, verifiquei o patch panel: parece que todos os cabos são nossos, nada extra está conectado. Um beco sem saída.

O segundo pensamento: talvez sejam vizinhos do prédio. Estamos trabalhando em um centro de negócios, quem sabe em qual porta eles conectaram o quê. Mas nossa organização está em uma linha dedicada, existem vários escritórios, e cada um tem seu próprio cabo para o provedor, sua própria tomada, e eles são combinados por roteamento através de uma rede virtual, não deve haver endereços estranhos. Além disso, duas subdivisões monitoram periodicamente a composição da rede - administradores e seguranças.

Eu até desci para o armário de montagem no primeiro andar e olhei: nosso cabo vai para uma porta separada do switch do provedor. Fisicamente, não estamos conectados a ninguém. E os dispositivos em Neighbors ainda estão pendurados. Beco sem saída número dois.

Então pensei: ok, talvez seja algum tipo de bug do Winbox? Mostra em cache, ou a descoberta pega lixo de broadcast do espaço. Reiniciei o roteador, esperei cinco minutos, abri Neighbors. Vinte e cinco dispositivos no lugar, alguns até atualizaram o tempo de atividade. Não, não é um bug.

Restou uma versão: o problema não está na nossa rede, mas no que vem para nós pelo cabo do provedor. Ou seja, o provedor em algum lugar não isolou os clientes uns dos outros e todos nós estamos sentados em um segmento L2 comum. Parecia selvagem, mas, em princípio, é fácil verificar essa hipótese.

Cavando em direção ao provedor

Liguei o Torch na interface WAN (este é um monitor de tráfego embutido no MikroTik - mostra fluxos em tempo real: endereços de origem e destino, protocolos, velocidades) e comecei a olhar o que vem do uplink.

Nos primeiros segundos - nada de especial, um fluxo normal. Mas então, nesse fluxo, o tráfego em endereços multicast característicos CDP e LLDP piscou - protocolos de descoberta de vizinhos que funcionam na camada de link de dados. O equipamento de rede fala sobre si mesmo através deles: hostname, porta, versão do firmware. Normalmente, você só os vê do seu switch ou roteador superior. E aqui dezenas de dispositivos estranhos se apresentaram uns aos outros, como em uma conferência.

Eu ainda estava tentando me convencer de que isso era apenas algum lixo de rede, mas então os pacotes OSPF Hello foram e aqui ficou completamente sem graça. Para quem não trabalhou com roteamento dinâmico, vou explicar: OSPF (Open Shortest Path First) é um protocolo com o qual os roteadores trocam automaticamente informações sobre a topologia da rede. Funciona assim: os roteadores em uma área (zona lógica) enviam pacotes Hello uns aos outros para estabelecer a vizinhança e, em seguida, trocam LSAs (Link-State Advertisements) - mensagens que descrevem todas as redes e links conhecidos por eles. A partir desses LSAs, cada roteador constrói um LSDB (Link-State Database), um mapa completo da topologia de toda a área. Completo. Cada roteador sabe sobre cada sub-rede e cada link.

Agora está claro por que OSPF Hello na minha WAN é uma catástrofe? OSPF Hello é enviado por multicast para 224.0.0.5 e, se eu os vir, significa que estou no mesmo segmento L2 com aqueles que os enviam. No próprio pacote Hello, o Area ID é especificado: a partir dele, você pode ver em qual zona os vizinhos estão trabalhando. E, portanto, posso configurar meu processo OSPF na mesma área, estabelecer adjacência e obter um mapa LSDB completo de toda a rede. Não havia mais sentido em duvidar: o provedor jogou todos em um pote comum.

Torch na WAN: CDP, LLDP, OSPF Hello. Meu roteador não iniciou nada disso

Verificando o quão ruim é

Ok, protocolos estranhos no ar - isso já não é bom. Mas uma coisa é ver pacotes de broadcast, outra é realmente alcançar dispositivos estranhos. Peguei o endereço MAC de um dos vizinhos de Neighbors e fiz um MAC Ping, um ping na camada de link de dados, que funciona sem IP, apenas por endereço MAC. Responde? Responde.

MAC Ping para um dispositivo estranho. Voo normal

Então tentei MAC Telnet - um protocolo proprietário MikroTik, inventado para a conveniência dos usuários: ele permite que você se conecte ao console de gerenciamento de qualquer dispositivo RouterOS no mesmo segmento L2, usando apenas o endereço MAC. IP não é necessário, roteamento não é necessário - basta estar no mesmo domínio de broadcast. Isso foi concebido para casos em que o roteador é novo da caixa e o IP ainda não está configurado. E em nossa situação, isso significava: posso me conectar ao console de gerenciamento de qualquer um dos vinte e cinco MikroTik vizinhos.

Conectado. Vi o convite de login do roteador de outra pessoa. Claro, não digitei senhas de outras pessoas, o próprio fato foi suficiente para mim.

MAC Telnet para o roteador de outra pessoa. Não, obrigado, eu só quero dar uma olhada

Mas isso não é tudo. Eu pinguei vários endereços IP da lista de vizinhos com um ping ICMP normal, no terceiro nível. Os dispositivos responderam. Ou seja, entre nós não há apenas um segmento L2 comum, mas também conectividade IP completa.

Ping normal para "vizinhos". Eles não estão apenas por perto, eles são roteáveis

E aqui fiquei realmente com medo. Até este ponto, era possível se consolar: bem, os dispositivos se veem, bem, se pingam, desagradável, mas não fatal. Mas decidi ver o que mais está voando nos pacotes OSPF e quais rotas estão sendo anunciadas.

Entre os prefixos de outras pessoas, foram encontrados endereços que claramente não pertenciam aos clientes, mas ao próprio provedor. Interfaces Loopback, sub-redes /30 de link entre seus roteadores. Eu pinguei alguns deles, eles responderam.

Estou sentado olhando para isso e entendendo a escala da tragédia: o provedor distribuiu conexões para clientes corporativos em um único VLAN comum. Sem segmentação, sem isolamento de porta, e ao mesmo tempo todos os clientes se veem na camada de link de dados, podem trocar tráfego, eles têm acesso aos protocolos de serviço da rede do provedor, portanto, eles podem alcançar a própria infraestrutura do operador. Vinte e tantas organizações em um segmento, como em um dormitório, onde as paredes foram desenhadas com um marcador no chão e concordaram em não cruzar.

Mapa por camadas OSI. Escala do desastre

O que um invasor pode fazer com isso

Quando o primeiro choque passou, sentei, servi café e comecei a pensar: o que alguém menos consciencioso poderia fazer com isso?

Cenário 1. ARP spoofing - interceptando o tráfego dos vizinhos

Este é o cenário mais óbvio. Em um segmento L2 comum, qualquer usuário pode enviar respostas ARP falsas (ARP gratuito) e se declarar um gateway. Todos os dispositivos no segmento atualizarão sua tabela ARP, e o tráfego destinado ao gateway fluirá através do atacante. Além disso - man-in-the-middle clássico: senhas que são transmitidas sem TLS, o conteúdo das solicitações HTTP, solicitações DNS, tokens de autenticação. Se alguém entre os vizinhos tiver um cliente de e-mail que vá para POP3 sem criptografia (e isso é comum em pequenas empresas) - este é apenas um presente para um hacker.

A ferramenta é trivial:

ettercap pode fazer ARP poisoning, interceptar tráfego e analisar senhas em tempo real;

bettercap - uma alternativa mais moderna com uma interface web e módulos para HTTPS downgrade;

arpspoof do pacote dsniff - se você quiser ser realmente simples.

Tudo isso está em Kali fora da caixa.

ARP spoofing pode pelo menos ser notado: em switches gerenciados, há Dynamic ARP Inspection, e anomalias na tabela ARP são óbvias. Mas isso é se alguém estiver assistindo. Mas então algo pior começa.

Cenário 2. Força bruta em roteadores via MAC Telnet e muito mais

MAC Telnet para roteadores de outras pessoas funciona, já descobrimos isso. E se for assim, a enumeração de senhas também funciona. Quantos desses vinte e cinco MikroTik estão com a senha admin/ admin ou admin sem senha? Na minha experiência, cerca de quarenta por cento, no mínimo. Pequenas empresas compram um roteador, conectam um cabo, configuram o NAT - e pronto, não estão mais interessadas.

Pode-se enumerar de várias maneiras. No Metasploit, há um módulo auxiliary/ scanner/ ssh/ ssh_login para enumeração via SSH. Hydra funciona com SSH, Telnet e formulários HTTP (WebFig na porta 80/443). RouterOS API (porta 8728) usa seu próprio protocolo binário - não há módulos prontos no Metasploit para ele, mas há scripts Python especializados no GitHub (por exemplo, RouterOS-API-bruteforce), bem como o script correspondente no NSE Nmap. Para o protocolo Winbox (porta 8291) - ferramentas separadas como winbox-brute.

Escolheu uma senha, e você está no console de gerenciamento do roteador de outra pessoa. De lá, toda a rede interna da organização é visível: você pode se adicionar à rota, configurar o encaminhamento, conectar-se a compartilhamentos SMB, câmeras de vigilância, impressoras. Se houver Active Directory na rede, geralmente há um ou dois hops para o controlador de domínio.

Cenário 3. Injeção de rotas via OSPF

É aqui que as coisas ficam realmente interessantes. OSPF neste segmento funciona sem autenticação. Como eu determinei isso? No cabeçalho de cada pacote OSPF, há um campo Auth Type : 0 - sem autenticação, 1 - senha de texto simples, 2 - MD5. No Hello interceptado, havia zero. OSPF suporta autenticação, mas por padrão está desativado, e neste caso ninguém o ativou. E, portanto, nada impede que você levante seu próprio processo OSPF e entre na área como um participante de pleno direito.

A continuação está disponível apenas para membros

Os materiais das últimas edições tornam-se disponíveis separadamente apenas dois meses após a publicação. Para continuar lendo, você precisa se tornar um membro da comunidade "Xakep.ru".

Junte-se à comunidade "Xakep.ru"!

A associação na comunidade durante o período especificado abrirá acesso a TODOS os materiais do "Hacker", permitirá que você baixe edições em PDF, desative a publicidade no site e aumente seu desconto acumulativo pessoal!

Mais detalhes Eu já sou membro de "Xakep.ru" ← Anterior Criminosos também reclamam do AI-slop

📤 Compartilhar & Baixar