#  > Geral >  > Tutoriais >  >  Identificando e neutralizando servidores DHCP na sua rede com o dhcpdrop.

## seiskneko123

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:




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.

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)




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

_

----------


## Leonardo

:Congrats:  :Congrats:  Parabéns pela iniciativa.

Sucesso!

----------


## naldo864

boa dica ,boa iniciativa parabems

----------


## trober

> ...
> 
> 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!  :Big Grin: 

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

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:



```
#!/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
-
-
-
-
-

----------


## seiskneko123

> Bom dia! 
> 
> 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:
> 
> 
> ...


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

----------


## 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


Não precisa do _Server Alert_ do _RouterOS_. Esse _script_ já detecta e já neutraliza as requisições DHCP de terceiros  :Smile: 

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:



```
/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

----------


## leonardolinux

Bom dia

Boa iniciativa...valew

----------


## seiskneko123

Ótima explicação, trober!

Valeu mesmo!

----------


## interhome

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.

----------


## 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.

----------


## trober

> 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
-
-
-
-
-

----------


## seiskneko123

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

----------


## francisconeto

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

----------


## 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:

Manual:Metarouter - MikroTik Wiki

MikroTik RouterOS &bull; 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

----------


## trober

> ...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  :Smile: 

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

Saudações,

Trober

----------


## seiskneko123

> 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!!

----------


## sergio

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






> 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

----------


## iorijanete

vlw amigo ótima iniciativa

----------


## unibraz

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 gerenciave_l na rede pois holvi dizer que existe como fazer pelo mikrotik_

----------


## interhome

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

----------


## jardelalmeida

> 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:
> 
> 
> ...


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.

----------

