Using PreShun ACL's

[awilliamson]

I'm using the PreShun ACL option on my sensors...seems to work great and was an awesome addition to the use to the functionality of these devices. However, I'm encountering one small issue. It may be just the manner in which I'm using this feature but wanted to see if anyone else had any thoughts.

Whenever I make changes to the preshun acl list I have to manually restart the daemons on my sensors, so that the new preshun acl is applied along with the normal shun acl. I would have thought the sensor would auto-magically re-read the preshun acl to build the normal shun list each time it needed to modify the router due to an event.

Is this correct? Is anyone else seeing this behavior?

Thanks one and all.

[stleary]

The sensor reads the router config at specified times, so that shuns can be applied as quickly

as possible. But you don't have to manually restart the sensor. Instead, disable shunning

before making the change to the router, and enable shunning after making the change.

How you perform the ShunDisable and ShunEnable depends on the tool you use to manage

the sensor. Let us know if you are not sure how to do the disable/enable (stleary@cisco.com).

In general, any time you make a configuration change to a router controlled by IDS,

shunning should be disabled while the changes are being made; problems have been

seen in our lab with some router models if the sensor is controlling a router at the

same time that the router configuration is updated.

[marcabal]

On CSPM:

Select on alarm seen by that sensor (The instructions say to do this, but I'm not familiar enough with the Event Viewer to be sure that you have to)

Actions->Advanced->Disable Future Blocks

Make your acl modifications to the router

Actions->Advanced->Enable Future Blocks

Also pushing a new configuration (even if nothing changed) will force managed to reread the configuration on the router. But I really suggest using ShunEnable ShunDisable, because otherwise the router's configuration might be corrupted. Some routers don't handle multiple users editing the configuration at speeds which managed writes the configurations.

Just so you know trying to have managed always check for changes was too much of a performance hit for managed, as well as the router, when shuns are coming in fast.

For the Unix Director:

Highlight the sensor (you may even have to high light managed in the sensor's map)

Security->Advanced->Shunning->Disable Future Shuns

Make your changes

Security->Advanced->Shunning->Enable Future Shuns

[awilliamson]

Thanks for your help...think I have a handle on it now...one last thing however...is is possible to issue some command from the director to disable/enable the shunning versus going thru the gui? this would allow me to code my scripts that update my pre_shun acl's to perform the appropriate actions.

[stleary]

To disable shunning on a sensor from a script on the director, execute this cmd:

nrset 10003 hostid orgid 1 ShunDisable

To enable shunning on a sensor from a script on the director, execute this cmd:

nrset 10003 hostid orgid 1 ShunEnable

Replace hostid, orgid with the host and org id of your sensor.

[awilliamson]

I tried doing the above...but got the following error:

>nrset 10003 2 25 1 ShunDisable

Error: nrset appid hostid orgid priority token [ identifier... ] value [ value ... ]

Can you advise? Thanks

[marcabal]

The command should have been:

nrexec 10003 2 25 1 30 ShunDisable

The nrset is only for configuration tokens (i.e. tokens in the conf files).

The ShunDisable token is a run time token that changes execution of the sensor and does not show up in conf files. So it is execute with nrexec rather than nrset.

Also note that nrexec has a timeout after the priority unlike nrset.

I recommend the timeout be set to 30 as in my example above.

Also the ShunEnable shoudl be executed the same as the ShunDisable

[awilliamson]

Thanks...works like a charm!