Packet capturing on ids

[jodr]

Hi,

We need to enable the 'capture packet' parameter on all attack signatures on an idsm-2 V4.1.4 and sensor 4210 V4.1.4. We use CiscoWorks VMS for configuring all sensors, but there seems to be no way to enable this parameter for a selection of signatures all at once. Apparently this is a different setting than ip logging (for which we do can select a lot of signatures to be configured at once). It seems to me that the only way to change this parameter is to go into the configuration of each seperate signature and change the value there. But this is almost not doable. Any other possibility ?

[smalkeric]

The following URL might give you some idea,

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_b/vpnman/vms_2_2/index.htm

[darin.marais]

I am really not sure that the posted URL does any justice when to answering this question effectively. I totally agree with the very well stated “request for change” and would really love to see better methods for enabling efficiently the audit trails within the Cisco product. Capture packet and IP logging should be enabled by default. IMHO, I am not sure how good analysis can be conducted without this sort of information readily available. I wish there was a “SensorApp –b”

-b = Log packets in tcpdump format (much faster!) but there is not,,

[marcabal]

IP Logging can affect sensor performance, and there is a limited number of IP Logs that can be created at a time.

Capture Packet will double, even triple or more the size of the alarms. This causes less alarms to be abel to stored on the sensor, and more data that a management station would have to pull down from the sensor.

Because of the negative performance aspects of these actions it was decided to not have these features enabled by default.

In version 4.1 each feature has to be enabled on each signature where it is desired.

With that said we have heard the request to be able to globally enable these actions for all signatures, or for a group of signatures.

We will still not be changing the default behaviour of the signatures.

But we will be adding the ability to globally enable the actions on all signatures, and adding the ability in IDM to select multiple signatures and adding the action.

These changes are in the works for a future sensor version.

[jodr]

Thanks for this clarification ! Meanwhile is there any workaround to get the job done within as little time as possible ?

[ktimm]

When will the ability to set capture = true be added ? Can we increase the eventstore without negative side effects ? Could it be added to context based sigs only ?

[marcabal]

The eventstore can not be increased.

We did see some issues with larger eventstores during early testing of version 4.0 sensors when trying to determine what eventstore size to use.

As for the adding of the capture trigger packet to multiple signatures; I can only say that we will be addressing the issue in a future version. We will have to wait until that future version and the new features have been officially announced before I can discuss them on an open forum such as this.

[jodr]

I had found some workaround to change the CapturePacket parameter for lots of signatures by changing directly into the config file of the ids device. However now that we have installed the newest version of VMS MC V2.0.1, this workaround is not working anymore because there is a new feature in VMS MC, the Parameter Source, that apparently has to be set to override the defaults as to avoid overriding our CapturePacket setting at next signature update. So now I feel completely blocked, as the previous signature updates now have overridden all of my work and I can start all over again changing some 1000 signatures, but now apparently one after the other. This will cost me lots of time !! Any suggestion ?

Moreover, there is one other nasty thing about configuring ids devices via VMS MC. In VMS MC we can add names to filtersn, but this is not supported in the ids software itself. So everytime we have to re-import the ids config into VMS MC, we loose this information again. Will these filter naming be supported in future ids software release ??

Best regards,

Johan.

[marcabal · Accepted solution]

Now that IPS Version 5.0 has been officially announced (being released early next month), I can tell you about some of the new features that may help in this area.

The new IDM (Intrusion Detection Device Manager) that is the sensor's web based configuration tool will allow you to select multiple signatures (holding down the control key as you select each signature), right click to bring up an event action window, and assign event actions (like Capture Packet which has been renamed to ProduceVersboseAlert in 5.0) to all of the signatures with a few simple mouse clicks.

So you won't need to manually edit the sensor's XML file to do the same edit to a large number of signatures.

NOTE: I work on the sensor team, and so do not have the expertise on the IDS MC (VMS) product. I am not sure if IDS MC in VMS is providing this same capability. But IDS MC should at a minimum be able to import the changes made through IDM.

Some other new features are what we call Risk Rating, and Event Action OverRides. WIth Risk Rating will now have a calculated Risk Rating between 1 and 100. The Risk Rating is calculated based on the Severity of the Signature, the Fidelity of the Signature (how well it detects that attack), and the Target Value (how important the target address is to you).

Primarily the Risk Rating is a method for better sorting the order of importance of the alarms, but can also be used with the new Event Action Over Rides feature.

Each type of action (like ProduceVerboseAlert) can be assigned a specific Risk Rating range (say 80-100). Any alert that has the Risk Rating will have that action done in addition to the action previously specific per signature. (So any alert with a Risk Rating of 80-100 would have ProduceVerboseAlert action added to that alert if it had not already been configured on the individual signature).

The filters have also changed quite a bit.

You can now name each filter on the sensor itself.

And even add a description in a new user-comments field.

The filters also now allow filtering out specific actions (in 4.x all actions were filtered, but in 5.x you can filter out the Block actions for example and still allow the alarm to be generated.)

[darin.marais]

On Jan 26, 2005, royw wrote, “IDSMC 2.0 adds hierarchical inheritance for signatures. You can now tune the signatures at the group level and let all of the group's children (either other groups or sensors) inherit the signature tunings. This is intended to reduce the need to copy signatures.”

I would like to point out a fact that I noticed and may just have been overlooked in the suggestion below:

>Marcabal wrote, “I am not sure if IDS MC in VMS is providing this same capability. But IDS MC should at a minimum be able to import the changes made through IDM.”

Yes, IDSMC can import the signature changes made by IDM but this is certainly not with out a small cost. Once you have imported the sensor device to VMS, the signature parameters will no longer be owned by the ROOT group to which they have been imported but instead will owned by the sensor itself. This would mean that if a change is made at group level to some parameter in some signature, that was originally imported, that change will not be carried through to the child so whilst there is a workaround to resolve the issue of modifying the “capture packet parameter” for a large volume of signatures, you will still have to edit each signature to recommit it to the global signature process and put it back in the control of the inherit group model.

This may or may not be an issue but is worth mentioning before you go out and discover it for yourself.

[jodr]

I am almost certain now that there is an issue with IDS MC V2.0.1 in configuring parameter settings for signatures. When I configure for example capture packet setting for all attack signatures, implement it on the sensor, make sure parameter source setting in VMS MC is set to the sensor, then I have a problem at next signature update. Because for certain signatures - I really don't see why - the update overwrites my changes and resets the parameter source to IDS 4 defaults. And I can restart all over again...

[marcabal]

I think this may be a problem in the signature update script itself on the sensor.

We have seen this happen with Event Action settings on signature 4701:

CSCeg74511

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeg74511&Submit=Search

That bug was corrected in signature update S137.

What signature update did you install and see this happen?

If it was prior to S137 then do the following:

Go ahead and configure the parameters you are concerned about in IDS MC, and push the config to the sensor.

On the sensor:

1) Login as user cisco and execute "show conf", and save the output. (Or use the copy command to copy the current-config to an ftp server).

2) Create a service account if you don't already have one.

3) Login as the service account and ftp the /usr/cids/idsRoot/etc/VS-Config/virtualSensor.xml file to an ftp server.

4) Now install the S137 update.

5) Now repeat steps 1 and 3 to get the current-config and virtualSensor.xml files.

If the problem happens then email the before and after current-config, and the before and after virtualSensor.xml.

You can either email me directly (marcabal@cisco.com) or open a TAC case and provide those files to the TAC (the TAC can then forward the files on to myself and the development team).

Marco

[jodr]

I was implementing sig update S147 on ids V4.1(4). I will now continue tests as to find a workaround for this issue. However I even don't find any explanation about the new features 'parameter source' and 'properties source'.

[jodr]

Thanks for your answer. These new features should resolve the configuration issues on signatures and filters we are having. We look forward to this new version !

Best regards,

Johan.

[jodr]

We have enabled Capture Packet on some 1100 signatures on our idsm-2 blade on a core Cisco6500 switch and apparently the blade can't handle this extra load. But the effect on the blade performance is rather peculiar. Instead of the cpu load getting out of hand and instead of getting missed packets, we see the cpu load being dropped to a few % and we are getting bad octets in the statistics. As a consequence the number of alerts being sent to EventStore has dropped down ; so I'm pretty sure we are missing alerts. Are there any guidelines as to what load we can expose both blades and sensors ? Or is this just trial and error ?