Answer the question
In order to leave comments, you need to log in
How to make your DHCP server the only one?
Good evening.
Recently I encountered such a situation: in a university dormitory there is one network for the entire building, clients receive internal addresses like 172.16.xx via DHCP. But there are lovers to put their own router / access point and "make yourself a Wi-Fi". Some connect an external cable to the LAN port (“this is a local network, no?”), And accordingly, you can find many DHCP servers on the network at addresses like 192.168.1.1 and others.
Actually, the question is: how to minimize the likelihood of clients picking up an address issued by someone else's router? I thought about dropping all DHCP-broadcast packets that do not belong to our network (172.16.0.0/23), but this does not completely solve the problem.
What else would you recommend in this situation?
Thanks in advance for your replies.
Answer the question
In order to leave comments, you need to log in
how to minimize the probability of clients picking up an address issued by someone else's router?
Unfortunately, it is impossible to solve this universally and with guarantee. This is the only option available.
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration information
about a given network segment is not known to be correct and is
not authoritative. This is so that if a naive user installs a DHCP
server not fully understanding how to configure it, it does not send
spurious DHCPNAK messages to clients that have obtained addresses
from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for
their networks should always write authoritative; at the top of their
configuration file to indicate that the DHCP server should send DHCP-
NAK messages to misconfigured clients. If this is not done, clients
will be unable to get a correct IP address after changing subnets
until their old lease has expired, which could take quite a long
time.
Usually, writing authoritative; at the top level of the file should
be sufficient. However, if a DHCP server is to be set up so that it
is aware of some networks for which it is authoritative and some net-
works for which it is not, it may be more appropriate to declare
authority on a per-network-segment basis.
Note that the most specific scope for which the concept of authority
makes any sense is the physical network segment—either a shared -
network statement or a subnet statement that is not contained within
a shared-network statement. It is not meaningful to specify that the
server is authoritative for some subnets within a shared network, but
not authoritative for others, nor is it meaningful to specify that
the server is authoritative for some host declarations and not others
.
In general, all sorts of home routers are sad, yes, there you will understand if it is authoritative.
if managed switches, I would ban these wifi on ports, for example. well, yes, the limit on the number of mac addresses per port.
when they come to the admin “why doesn’t the Internet work for us?” - to give on the ears and explain. what and how to set up so as not to interfere with everyone.
In extreme measures - locale - as you wish, the Internet along the radius and ppoe with minimal authorization, which thread, without encryption ...
Compiling all of the above:
1) The most correct option is a managed L2 \ L3 piece of hardware and DHCP snooping (although this is in Cisco and others like it, for example Zyxel , but in “any” D- links it’s probably called something else, they are like, for example, Port forwarding to call Virtual Server , I mean that if you decide to buy a piece of hardware and start looking cheaper, and you don’t find DHCP snooping in the “attempts” of the piece of iron, it’s not a fact that the piece of iron can’t do this)
This is the most correct option, moreover, for such a grid as a hostel, such a piece of iron will give out a bunch of profit for the admin with its presence - a very useful thing.
2) The option of attacking the DHCP servers of a “potential adversary”, of course, has the right to life, but it does not solve the problem, since they will be regularly rebooted, and almost 100% when you hack his zone with virtuals, the owner will feel some discomfort in the genitals, for example, when his phone will not be able to connect to the router - he will reboot the router accordingly ... so the script must work constantly - well ... although Exotic, and as if once again proves that “there are really three of them” (this is about the number of eggs the admin has :) )
3) And so I’ll try to say I’ll try to offer my own version, but this is so pure theory, although in part I once encountered “this”, it’s called Intercepter-NGin general, this is a popular multifunctional sniffer / scrubber, but one of its features is endowed with ultra-fast DHCP and as a body kit there is DHCP DISCOVERY, which overtakes everyone and everything in a homogeneous network, respectively, preventing legitimate DHCP from participating, and even if the client is from a legitimate DHCP received, then it forces it to initiate the request again, and so on until it seizes control of the client. You can try to use it as a countermeasure, think, try ...
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question