IDS Heartbeat

csmeriglio · ‎10-28-2003

Has anyone come up with a way to detect if a sensor is functioning(ie. heartbeat)? In the absence of generating any alarms over some period of time, looking to determine if a sensor is down or just not firing alarms.

lwierenga · ‎10-29-2003

Telnet to the Sensor and log in as netrangr, then issue the nrstatus, nrconns commands, or fire up nmap and scan a host monitored by the IDS.

emad.mohamed · ‎10-30-2003

what you could do also is login as root then run this command (snoop -d iprb0) to be able to check if the sniffing interface capturing traffic, if you don't see any traffic then check the interface connection cabl and also check if you spam the right port on the switch..... let me knwo if it's working

thank you

csmeriglio · ‎10-30-2003

I should have been clearer in my original description. I am looking to automate this this process, not have to go to individual sensors manually and issue commands, as that is burdensome, and reactive vs. proactive. Does anyone know of/have implemented a proactive process for this type of monitoring.

msmitha · ‎10-30-2003

I'm looking for the same thing here - I don't have an answer for you yet but I'm thinking of two options right now:

1. It may be possible to tweak the 994/995 signatures such that they fire once in 30 minutes or an hour. This way, we know that CSIDS is working.

2. Write a custom signature which looks for any IP traffic in the time interval of 30minutes or an hour, makes use of the alarmthrottle feature and fires just once in the desired time interval.

I'm thinking I'll probably go with option 2 above. If anyone has done something similar or have suggestions, please feel free.

ktimm · ‎10-30-2003

Create a custom signature searching for a certain payload. Create something to send it. Create a way to monitor for absence of the signature. Ideally the sign should not be targeted at the host but actually go by it's sniffing interface.

msmitha · ‎11-24-2003

Can someone help with this? We have several CiscoIDS sensors and need to pro-actively find out health of the device. Currently, we are using ping to check device up/down status, scripts which check the sensing interface for number of packets seen in x amount of time. We still need the sensor to send out a heartbeat like event to let us know that it's functioning normally.

dblairii · ‎11-26-2003

I too would like to see a moderator (Cisco) respond to this thread.

Thanks,

Don

travis-dennis_2 · ‎11-26-2003

In swoops the voice of dissention amongst the ranks. I am not the oft-requested moderator but thought that I might chime in on this thread. It would appear that there is a good deal of interest in getting the IDS to send a heartbeat signal to confirm that the sensor is up. This in itself is a great idea but allow me to point out an issue. The sensor itself is physically limited in capacity and therefore in capability. There are a lot of fantastic ideas out there such as this one that would make the Cisco IDS line an even better product than it already is. The problem is that the sensor by itself can only do but so much. If you keep adding feature after feature you start to take away from the ability of the box to do what it was intended to do. Detect attacks. Cisco has already started to disable older signatures that they feel should no longer be a real threat because the boxes, especially the 4210 series, are getting a little long in the tooth and it is a strain on the resources to watch for the older signatures. Do we really want to get the box jammed packed with features and loose sight of the original purpose? There are plenty of monitoring packages out there that will get this done. Cisco even makes a few. I use What’s Up Gold and VMS to do this and more. You can even write a simple script to do this. We need to be careful about the “Throw everything in including the kitchen sink” in mentality. Microsoft does this and we all know how secure their products are. I would rather have a box with very basic built-in management that was up to the task it was made for than having a super-user-friendly box that was dropping packets all over the place. Think about it. Write a script if the budget doesn’t allow for the management software and let the box do what it was intended to do.

As always, if this is something you feel strongly about then please contact your local Cisco sales account manager and submit a product enhancement request.

Well there it is. My opinion. It may not be popular but like my wife, it’s the only one I have and there is not much I can do about it.

Please feel free to rate this post if you agree or disagree.

marcabal · ‎12-01-2003

With version 3.1 of the sensors there were the Route Down, Daemon Down, OverSubscription and No Traffic alarms (look at the 993-999 alarms) to let you know when things were going wrong.

In version 4.x the sensors still have the OverSubscriptions and No Traffic alarms. The Route Down alarm on the sensor was no longer possible because of the new architecture in version 4.x where the sensor is a server and the management tools act as clients.

The Daemon Down was also not implemented because of changes in the architecture.

We are in the process of implementing additional methods for monitoring the state of the sensor for future sensor versions.

In the mean time many customers have implemented their own custom signature. They configure a custom signature on the sensor which will alarm on some activity that they can create in an automated fashion. For example seeing "sensor-test" as a web request to their web servers. They execute the activity and verify that the sensor fires the alarm and is seen on the management station.

This can be done as an automated script.

Create the custom signature on each sensor thorugh IDS MC.

Figure out how to automatically generate the activity that will trigger the alarm.

Configure the Security Monitor to execute a logging script every time that the alarm for the custom signature is seen. That script should write a log entry to a file.

Now you can create a script that will execute the activity to trigger the alarm, and then have it sleep for several seconds. Then have the script check to read in the contents of the log file generated by your logging script (that Security Monitor executes when the alarm is seen).

If the alarm shows up in the log file, then everything is working fine.

If the alarm does not show up, then have your script send you an email message or pager message.

And you will need to login and determine why the activity did not generate the alarm.

This method will let you know if there is a problem on the sensor preventing you from getting alarms, BUT will also let you know if your sensor is seeing the correct traffic.

One of the big issues we have seen is where the sensors are controlled by the Security group and the switches are controlled by the Networking group. The Security group is concerned that the Networking group has disabled their span session to the sensor.

This is not something that we can have the sensor detect on it's own. But using a custom script like the one I describe above, will let you know not only when there is a sensor problem, but also if the Span session was disabled because the sensor would then not see the packets.

sundog68 · ‎12-09-2003

Hi, I just posted on this subject, please see my note about IDS Informer

Colin

sundog68 · ‎12-09-2003

A collegue of mine had this problem working in a bank where they had a large number of sensors with some going off line. They got a solution by using IDS Informer from Blade Software and getting it to run through the command line to hit each of their sensors hourly to prove that they were still up. As far as I am aware this is the only purpose built product and it works really well, I deliver IDS testing around it.

Colin

dlac455 · ‎12-09-2003

Write a TCL/expect script to login to a sensor and issue a "show status". Have the stdout of that script pipe to a log file. Write another script or use SWATCH to monitor the log file and email you if the services you are looking for are ever missing.