Identificando e neutralizando servidores DHCP na sua rede com o dhcpdrop.

Já é sabido que o melhor método de configuração do CPE de seu cliente é em modo Router, é claro, pois você isola sua rede de qualquer problema que seu cliente venha a gerar. O fato é que nem sempre podemos configurar seu equipamento em modo Router. Em algum casos realmente precisamos configurá-lo em Bridge. É aí que surge um problema: tudo o que o seu cliente fizer terá impacto na sua rede.

A situação mais comum é a seguinte:

1 - Cliente não está conseguindo conexão (95% por conta de vírus, placa de rede desativada ou problemas no navegador).
2 - Não, ele não liga no suporte, vai tentar resolver sozinho.
3 - Então ele tem uma idéia genial: - vou inverter esses cabos e vai dar certo.
4 - Ele tira o cabo da Wan que vem do CPE e conecta na Lan do seu TP-LINK da vida, e começa distribuir IPs por toda a sua rede
5 - Você não sabe porque seus clientes estão pegando o IP 192.168.1.x e onde está esse DHCP server.

Esse programa que estou anexando aqui server como medida emergencial.

Testei o DHCPDROP e ele realmente cumpre o que promete. Porém sua documentação está em Russo e não é muito simples de se utilizar. Por essa razão resolvi criar um script para facilitar o uso do mesmo.

Primeiramente instale o Winpcap:

WinPcap · Download

Depois, instale o DHCPDROP anexo ao post.

Execute-o.

Vai aparecer a seguinte tela:

Anexo 32377


Observe na imagem acima que automaticamente o programa já listou suas interfaces de rede. No meu caso são muitas porque tenho máquina virtual instalada. Basta você identificar qual é a placa de rede que você quer scannear por DHCP servers e informar ao programa através do número da placa. Ele fará uma varredura e informará se existe ou não um servidor na sua rede. Cuidado, não vá dropar seu próprio servidor.

Digitei o número 6 pois nessa placa sei que tem um DHCP ativo.
Anexo 32378
Agora na imagem acima o programa identificou o MAC Adress e o IP do DHCP server na minha rede e me perguntou se eu desejo 'dropá-lo'. Vou dar y (yes)


Anexo 32379

Pronto, o programa já começou a enviar várias requisições de IP para o DHCP server até encher o pool do roteador.

Ps: No meu caso só identificou via cabo, via wireless o programa não conseguiu achar o DHCP (nem o dhcp do meu mk).

Enfim, eu apenas compilei um script para facilitar o uso da ferramenta afim de ajudar quem tem dificuldades.

Pretendo desenvolver em breve uma ferramenta em Linux para rodar em background e impedir automaticamente a atuação de outros servidores DHCP, sei que essa ferramenta original já faz, só pretendo facilitar.


Fonte:

Neutralizando servidores DHCP com o dhcdrop NetPatch -> Проекты -> Подавление DHCP серверов
Agradeço ao trober, pois li vários comentários dele sobre o assunto, o que me ajudou a entender melhor o funcionamento da coisa.

Gostou? Foi útil? Agradeça!


Sergio Nunes
Pinhais Telecom
www.pinhaisabc.com.br

:congrats::congrats: Parabéns pela iniciativa.

Sucesso!

boa dica ,boa iniciativa parabems

Citação:

---

Postado originalmente por seiskneko123

...

Pretendo desenvolver em breve uma ferramenta em Linux para rodar em background e impedir automaticamente a atuação de outros servidores DHCP, sei que essa ferramenta original já faz, só pretendo facilitar.


Fonte:

Neutralizando servidores DHCP com o dhcdrop NetPatch -> Проекты -> Подавление DHCP серверов
Agradeço ao trober, pois li vários comentários dele sobre o assunto, o que me ajudou a entender melhor o funcionamento da coisa.

---

Bom dia! :D

Em primeiro lugar, eu que agradeço! Fico feliz que minhas contribuições sejam úteis :)

Quanto ao script para rodar em GNU/Linux, a lógica é bem simples. O script abaixo considera o uso de FreeBSD, já que não uso GNU/Linux. Mas nada impede de fazer adaptações para pinguins.

Abaixo portanto, o código:

Código :

---

#!/bin/sh
INTERFACE=`grep dhcpd_ifaces /etc/rc.conf | sed 's/"//g' | cut -f 2 -d "="`
MAC=`ifconfig $INTERFACE | grep "ether " | awk '{print $2}'`
/usr/local/sbin/dhcdrop -i $INTERFACE -l $MAC -y

---

Só adicionar no cron(8), e ser feliz.

Saudações,

Trober
-
-
-
-
-

Citação:

---

Postado originalmente por trober

Bom dia! :D

Em primeiro lugar, eu que agradeço! Fico feliz que minhas contribuições sejam úteis :)

Quanto ao script para rodar em GNU/Linux, a lógica é bem simples. O script abaixo considera o uso de FreeBSD, já que não uso GNU/Linux. Mas nada impede de fazer adaptações para pinguins.

Abaixo portanto, o código:

Código :

---

#!/bin/sh
INTERFACE=`grep dhcpd_ifaces /etc/rc.conf | sed 's/"//g' | cut -f 2 -d "="`
MAC=`ifconfig $INTERFACE | grep "ether " | awk '{print $2}`
/usr/local/sbin/dhcdrop -i $INTERFACE -l $MAC -y

---

Só adicionar no cron(8), e ser feliz.

Saudações,

Trober
-
-
-
-
-

---

Muito legal, amigo. Esse script fica em background e já identifica quando entra algum DHCP server na rede?
Estava pensando em fazer algo entre o DHCP Alert do mikrotik integrando com dhcdrop numa máquina Linux... mas se esse script fizer isso, maravilha!

Att,


Sergio Nunes

Citação:

---

Postado originalmente por seiskneko123

Muito legal, amigo. Esse script fica em background e já identifica quando entra algum DHCP server na rede?
Estava pensando em fazer algo entre o DHCP Alert do mikrotik integrando com dhcdrop numa máquina Linux... mas se esse script fizer isso, maravilha!
Att,
Sergio Nunes

---

Não precisa do Server Alert do RouterOS. Esse script já detecta e já neutraliza as requisições DHCP de terceiros :)

O que você precisa fazer é adicionar o script no cron (agendador de execução da maioria dos sistemas operacionais Unix-Like), com tempo de execução a cada um minuto.

O script poderia ser mais simples. Eu fiz dessa forma, para caso fosse renomeada a interface de rede ou mudada a placa de rede (e consequentemente o endereço físico), você não terá o overhead de ter de alterar manualmente o nome da placa e endereço físico no script.

Supondo que sua placa de rede chama-se "em0" e seu MAC é 00:00:00:11:22:33, o comando fica:

Código :

---

/usr/local/sbin/dhcdrop -i em0 -l 00:00:00:11:22:33 -y

---

Entretanto, com o script completo, você não precisa se preocupar e alterar seu código ao trocar de placa de rede.

Se sua rede é wireless e roteada (não bridge) você não precisa do Server Alert do RouterOS, desde que tenha "Default Forward" desabilitado. Afinal, um cliente anunciado DHCP não será "ouvido" pelos outros clientes.

Em redes condominais roteadas e cabeadas, a história muda um pouco. Mas isso é assunto para outro momento.

Saudações,

Trober

Bom dia

Boa iniciativa...valew

Ótima explicação, trober!

Valeu mesmo!

Parabens pela iniciativa.
Todo administrador de rede tem que ter em mãos a lista de portas TCP/UDP. Segue o link Anexo:Lista de portas de protocolos – Wikipédia, a enciclopédia livre . Com isso em mãos use o firewall, para quem não trabalha com no caso Dhcp, crie regra bloqueando o trafego UDP das portas 67-68. Para quem trabalha faça a mesma regra e na mesma crie uma exceção para o seu servidor.

Amigos não seria mais fácil usar um firewall layer 2, assim vcs resolve não só problemas de dhcp mas sim todo problema de comunicação entre clientes.

Citação:

---

Postado originalmente por francisconeto

Amigos não seria mais fácil usar um firewall layer 2, assim vcs resolve não só problemas de dhcp mas sim todo problema de comunicação entre clientes.

---

Sua sugestão é bastante válida, entretanto, quando se pega projetos abandonados, ou cenários macabros[1], com orçamento enxuto, ou seja, o cliente já gastou tudo o que tinha e o que não tinha, numa implementação não planejada, não se tem muito o que fazer.

Particularmente, em redes condominais cabeadas, uso switch VLAN em cada pavimento. Mas quando a administração do condomínio já gastou todo o dinheiro com aquele "técnico" que atolou 20 hubzinhos Kaiomy (eca, eca, cusp, cusp), preso com prego ou silver tape, o jeito é "reconstruir".

Como são poucos os clientes que topam por "a casa abaixo" e começar a reconstrução, o jeito é usufruir de ferramentas como DHCDROP.

[1] https://under-linux.org/f212/bloquea...97/#post520699

Saudações,

Trober
-
-
-
-
-

Exatamente, Trober... Como citado no tópico, é mais uma solução emergencial do que um padrão de implementação.

Certo pessoal, agora peguei o ponto chave da questão, de usar o dhcpdrop.

Para quem quiser rodar essa aplicação e os scripts no ROS, deixo uma dica: Virtualizem o OpenWRT, e instalem o mesmo seguindo as dicas dos usuários trober e seiskneko123. Para virtualizar o OpenWRT são dois palitos:

Manual:Metarouter - MikroTik Wiki

MikroTik RouterOS • View topic - Metarouter images

http://www.bdibbs.com.br/wp-content/...terOpenWRT.pdf

Use Metarouter to Implement Tor Anonymity Software - MikroTik Wiki

https://forum.openwrt.org/viewtopic.php?id=22769

Downloads - Públicos - Metarouter e OpenWRT

Citação:

---

Postado originalmente por sergio

...Para quem quiser rodar essa aplicação e os scripts no ROS, deixo uma dica: Virtualizem o OpenWRT...

---

Como sempre, as impagáveis contribuições do Sergio :)

Dia 06/02 vou aí te dar um abraço e comer pão de queijo.

Saudações,

Trober

Citação:

---

Postado originalmente por sergio

Para quem quiser rodar essa aplicação e os scripts no ROS, deixo uma dica: Virtualizem o OpenWRT, e instalem o mesmo seguindo as dicas dos usuários trober e seiskneko123. Para virtualizar o OpenWRT são dois palitos:

---

Valeu, amigo. Ótima idéia!! Não deixa de ser uma opção, sem dúvidas!!

opa... blz Trober. Pão de queijo é o que não falta aqui. :D

Citação:

---

Postado originalmente por trober

Como sempre, as impagáveis contribuições do Sergio :)

Dia 06/02 vou aí te dar um abraço e comer pão de queijo.

Saudações,

Trober

---

vlw amigo ótima iniciativa

Amigos, tenho um problema que achei interessante compartilhar, acho que esse probleminha se junta a esse.
Tenho uma rede 5.8 tudo com UBIQUITI algumas antenas instaladas são para predios ou seja; cascateia nos andares e clientes nas casas instaladas direto no pc ou em roteadores wifi.
Atenção: ja descartando a possibilidade de configurar o radio discar o PPPoE por conta dos predios que existe varios clientes
O problema é que as vezes um cliente coloca um router wifi e o mesmo acaba repassando o DHCP para a rede toda.
Uso PPPoE amarrando IP+MAC+Login e senha.
Consegui achar o MAC que esta causando o conflito no Mikrotik em Tools + IP Scan colocando a Interface [CLIENTES] e o IP do Gateway [192.168.0.1] MAIS... esse MAC não esta na minha lista dos MAC cadastrados nos clientes.
Alguem saberia como amarrar no mk caso o cliente venha a colocar um router???
Estou tentando descartar um switchh gerenciavel na rede pois holvi dizer que existe como fazer pelo mikrotik

Para poder tomar uma ação com Mikrotik, ou qualquer equipamento, é necessário o conhecimento da topologia da rede.

Citação:

---

Postado originalmente por trober

Não precisa do Server Alert do RouterOS. Esse script já detecta e já neutraliza as requisições DHCP de terceiros :)

O que você precisa fazer é adicionar o script no cron (agendador de execução da maioria dos sistemas operacionais Unix-Like), com tempo de execução a cada um minuto.

O script poderia ser mais simples. Eu fiz dessa forma, para caso fosse renomeada a interface de rede ou mudada a placa de rede (e consequentemente o endereço físico), você não terá o overhead de ter de alterar manualmente o nome da placa e endereço físico no script.

Supondo que sua placa de rede chama-se "em0" e seu MAC é 00:00:00:11:22:33, o comando fica:

Código :

---

/usr/local/sbin/dhcdrop -i em0 -l 00:00:00:11:22:33 -y

---

Entretanto, com o script completo, você não precisa se preocupar e alterar seu código ao trocar de placa de rede.

Se sua rede é wireless e roteada (não bridge) você não precisa do Server Alert do RouterOS, desde que tenha "Default Forward" desabilitado. Afinal, um cliente anunciado DHCP não será "ouvido" pelos outros clientes.

Em redes condominais roteadas e cabeadas, a história muda um pouco. Mas isso é assunto para outro momento.

Saudações,

Trober

---

Amigo, o que muda em condomínio onde a rede é cabeada e com o mikrotik fazendo tudo ?

É este meu cenário, hub nos andares e o mikrotik controlando acesso, roteando, etc.