[Nagiosplug-devel] Checking for unknown NIS servers?

[Dan Wilson]

What about using it's mac address to quarantine it?


We've done something similar in the past for virus/worm infected 
machines.  Basically we used tcpdump to capture find what we were 
looking for and that output was processed by a perl script.  When a 
computer was found it's IP address was written to a file. Every minute 
that file would be read and a tool to spoof the mac address was put into 
action.  Once running, it caught nearly all that offending machines in 
the first 5-10 minutes... and continued to catch machines as they were 
turned on.

An email alert would then be sent to the admin who could then take his 
time quarantining and fixing the machines.

In the end we found more than 70 of our 300+ machines had been infected 
with a worm...  The network was unusable until we tried the above.  In 
fact when we setup it up and started it the techs though they had fixed 
the problem when they patched and restarted a computer.... the network 
just happened to be usable again after they finished.  Boy were they 
dissapointed to find out that they still had to patch all the rest of 
the computers ;-)

John P. Rouillard wrote:
> In message <43F0BF02.6070005 at op5.se>, Andreas Ericsson writes:
>   
>> C. Bensend wrote:
>> [some other attributions lost in response]
>>     
>>>> contact the individual addresses?  my assumption was that for
>>>> NIS broadcasting you simply put some noise on the wire, and any
>>>> masters on the local network segment responded.
>>>>         
>>> Personally, I need something like:
>>>
>>> check_nis -d domain1,domain2 -x -s server1,server2
>>>
>>> ... that will return a non-OK value if any _more_ servers respond,
>>>       
>> And this is where the trouble lies. How long should we wait for any 
>> other server to respond, and how many broadcasts should we send?
>>
>>     
>>> other than server1 or server2, such as an unintentional or rogue
>>> server3 answering the broadcast.
>>>
>>> I know I can't code it, but I could certainly help test it if
>>> someone were to take a shot.  :)
>>>       
>> A much better way is to set up a daemon which listens to broadcasts and 
>> shouts out loud if it hears one from the wrong server.
>>     
>
> IIRC the client broadcasts for the server. The server replies using
> the client's IP address. So it's not a broadcast response but a
> niswatch (doesn't look like google knows of a niswatch that does this)
> type daemon (sort of like arpwatch) would work if you have a port on
> your switches than can be used to monitor all traffic looking for the
> response.
>
> You can probably cobble something together from tcpdump and nagios
> passive service results.
>
>   
>> You still have to 
>> implement the NIS protocol (partially) but you can get rid of the 
>> problem of having plugins run with elevated privileges and determining 
>> how long to wait.
>>     
>
> Well you can use regular network NIS traffic as your probe and just
> look for incorrect responses.
>
> 				-- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________________
> Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20060213/91145c22/attachment.html>