Managing multiple sensors using CLI - filtering suggestions?

genewolfe · ‎07-15-2008

VMS Management Center won't import from sensors running 5.1-8-E2 and until we purchase something newer we monitor with VMS Monitoring Center and manage/configure using CLI or IDM. We have more than a dozen sensors so it's usually faster to use the CLI to make changes to all of them.

What is the best way using CLI or IDM to maintain identical event-action-rules and signature-definitions on multiple IPS sensors instead of copying and pasting them line by line on each sensor in the CLI? I haven't seen a way to do this but is it possible to remove all the event-action-rules and replace them all?

mhellman · ‎07-22-2008

Well, this might create support issues but...

First, make sure you have the same policy names. Then, once you make the changes to one sensor, you can copy the "delta" file over to the other sensors. The "delta" file can be found here:

/usr/cids/idsRoot/etc/config/eventActionRules/instances/rules0.xml

The filename above assumes the default policy name. If the policy was named DMZ, the file would be named DMZ.xml.

Now restart the cids processes (or reboot sensor) for the changes to take effect.

genewolfe · ‎07-24-2008

Thanks. Very cool.

This procedure worked very well. It looks like after I replace the xml file and stop and start cids the sensor considers all the filters inactive.

After I replaced the xml file and stop and start cids I saw alerts in VMS Security Monitor which should have been filtered so I logged into the sensor IDM and looked around in the Event Action Filters and noticed all the filters were inactive. After making the filters active the sensor filtered the alerts as expected.

Is there a way in the CLI to activate all the filters with a single command instead of one filter at a time?

mhellman · ‎07-25-2008

hmm... Are you sure they were active before you copied them? My understanding is that filters are by default both active and enabled. What this means is that you will find no setting in either the default.xml or the .xml that refers to those settings. Only when the .xml has an entry that specifically inactivates or disables the filter should that happen. Well, that's my theory anyway. Check both the default.xml and the .xml file to see if you can can get a hint as to what is causing this.

What we do is create a "dummy" policy first by cloning rules0. We then assign that new policy to a virtual sensor. When we copy the xml file over, and restart the processes, there is no need to activate/enable the filters as long as they are active/enabled in the xml file.