<div>class "thugs" {</div><div> match if substring(hardware, 1, 6) = 08:10:74:2f:21:83;</div><div>}</div><div><br></div><div>then later</div><div><br></div><div><div> subnet x.y.z.0 netmask 255.255.255.0 {</div>
<div> option routers x.y.z.1;</div><div> pool {</div><div> range x.y.z.2 x.y.z.254;</div><div> deny members of "thugs";</div><div> deny dynamic bootp clients;</div><div> }</div><div> }</div>
</div><div><br></div><br><div class="gmail_quote">On Tue, Apr 5, 2011 at 2:07 PM, Paul Keck <span dir="ltr"><<a href="mailto:pkeck@uga.edu">pkeck@uga.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello, we're using Internet Systems Consortium DHCP Server V3.0.5-RedHat in<br>
a campus environment.<br>
<br>
The other day one machine in a random building started pounding the heck out<br>
of the DHCP server, to the extent that our monitoring system was unable to<br>
obtain a lease. So, even though we could see that many leases were being<br>
fulfilled, I know some must not have been.<br>
<br>
Breakdown per minute of log lines:<br>
<br>
feta.cc# cat dhcpd.7 |grep '00:1a:a0:71:2a:72'|cut -c-12|uniq -c<br>
4 Mar 29 14:46<br>
171 Mar 29 14:47<br>
2697 Mar 29 14:48<br>
2718 Mar 29 14:49<br>
2520 Mar 29 14:50<br>
2746 Mar 29 14:51<br>
2677 Mar 29 14:52<br>
2712 Mar 29 14:53<br>
2690 Mar 29 14:54<br>
2512 Mar 29 14:55<br>
2684 Mar 29 14:56<br>
2703 Mar 29 14:57<br>
2694 Mar 29 14:58<br>
2681 Mar 29 14:59<br>
2478 Mar 29 15:00<br>
2753 Mar 29 15:01<br>
2717 Mar 29 15:02<br>
2750 Mar 29 15:03<br>
2688 Mar 29 15:04<br>
2572 Mar 29 15:05<br>
2666 Mar 29 15:06<br>
2761 Mar 29 15:07<br>
1402 Mar 29 15:08<br>
8 Mar 29 15:09<br>
8 Mar 29 15:18<br>
2 Mar 29 15:22<br>
6 Mar 29 15:23<br>
4 Mar 29 15:28<br>
4 Mar 29 15:29<br>
5 Mar 29 15:44<br>
1 Mar 29 15:46<br>
2 Mar 29 15:48<br>
<br>
Luckily it stopped on its own, but unluckily I was at lunch and didn't catch<br>
it in the act. It was just one machine that would either take the OFFER and<br>
then DISCOVER again, or not bother taking the OFFER and then DISCOVER again.<br>
<br>
This has happened a few times over the years and causes consternation. What<br>
do you folks do to mitigate this threat? I trolled the archive and see that<br>
some people get their networking equipment to throttle requests. I'll<br>
pursue that with our Foundry/Brocade gear but if that doesn't pan out, what<br>
else? I can see setting up something to look for this situation in the logs<br>
and block any requesting IP with more DISCOVERs than I like, but in this<br>
case it would blackhole an entire building since the router is forwarding<br>
the requests. Has anyone done that? Any better ideas?<br>
<br>
Also, to the programmers- is DHCPDISCOVER the thing to watch? What is the<br>
best metric for the "damage" a noisy client is causing? OFFERs? ACKs?<br>
<br>
Also, my management has taken us over relatively recently and is all about<br>
off-the-shelf solutions and outsourcing. Do any of the appliances that use<br>
ISC DHCPD (or others for that matter) have a good solution to this problem?<br>
<br>
Thanks!<br>
<br>
--<br>
<font color="#888888">Paul Keck <a href="mailto:pkeck@uga.edu">pkeck@uga.edu</a><br>
University of Georgia<br>
EITS Network Operations mailto:<a href="mailto:pkeck@ediacara.org">pkeck@ediacara.org</a><br>
--Opinions mine.-- Go fighting anomalocaridids!!!<br>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</font></blockquote></div><br>