using Nagios to detect rogue DHCP servers?

Hari Sekhon hpsekhon at googlemail.com
Wed Jul 11 14:49:29 CEST 2007


a few lines of my own bash to call check_dhcp.

I call my script instead of check_dhcp, it gives me the check_dhcp 
result but changes it if extra dhcp offers were received.

It was a quick fix that has served me well. Could be better if written 
into check_dhcp and it doesn't take mac addresses into account, just the 
number of offers, but it works well enough for me.

If check_dhcp isn't improved within the next few months I may have a 
bash at writing the functionality into it (especially the mac 
functionality which would be nice) if I get time (big IF there)

-h

Hari Sekhon



Lars Stavholm wrote:
> Hari Sekhon wrote:
>   
>> err, that is not at all nagios or automatic or anything.
>>
>> I am not personally going to __manually__ check for rogue dhcp servers, 
>> don't have the time for that.
>>
>> I check my dhcp servers anyway, if I get an extra offer, an alarm is raised.
>>
>> This is automatic, has no extra overhead as I check my dhcp servers 
>> anyway as part of my monitoring.
>>
>> I have never seen a dhcpoffer being missed, but at the very least I run 
>> the check every 3 minutes so you're not going to get away with it here 
>> for more than that.
>>
>>
>> I think the wrapper to check_dhcp is quick and effective with no overhead.
>>     
>
> What wrapper would that be, If one might ask?
> /Lars
>
>   
>> The best solution would be to extend the check_dhcp plugin, get into the 
>> C and add the functionality.
>> Maybe if it's not done in the future I will come back and do it.
>>
>> Until then, the wrapper does exactly what I need.
>>
>> -h
>>
>> Hari Sekhon
>>
>>
>>
>> Brian A. Seklecki wrote:
>>     
>>>> What about writing a custom plugin that uses this GPL prog to return the
>>>> warning/critical/ok/pending values?
>>>>         
>>> That sounds very reasonable; there's always the possibility that you 
>>> won't see, within your run time threshold, offers from a rouge server 
>>> due to race conditions or other crud (slow networks, etc.).
>>>
>>> Of course, then you have a lot of proactive bogus DHCP Client activity 
>>> coming from your Nagios system.
>>>
>>> The best solution of course, but not always the most feasible, is a 
>>> SPAN port in your core:
>>>
>>> Simply:
>>>
>>> $ sudo tcpdump -n -e -vvv 'src port bootps && !ether src 
>>> 0:50:da:28:37:62'
>>>
>>> Replace the MAC with your know DHCP server.  Matches are rouge.  If 
>>> you see them, get out the jumper cables.
>>>
>>> ~BAS
>>>
>>>
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Nagios-users mailing list
>> Nagios-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nagios-users
>> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
>> ::: Messages without supporting info will risk being sent to /dev/null
>>
>>     
>
>
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list