Shunning with Multiple Sensors

[crossmanj]

OK, time to revisit my shunning project. :-)

The last time I tried this, my router was smoked. Now, fortunatly, I have the Director at 2.2.3, and the sensors are at the latest release.

To allow the throttling of shun requests to my router, I have set one (mostly idle) sensor to handle the requests, and placed in its hosts file a list of all my other sensors, in the routes file the IP addresses of those sensor, and in the Authorizations file, I have given EXEC rights to all of the other sensors. On each of the other sensors, I have added the shunning sensor to hosts and routes, and configured them to use the shunning sensor. I turned on managed on all sensors.

At this time, I have nothing in the do not shun tables, as the router I am using is not the production router, but a throwawy to test the ACL creation and behavior.

When an event occurs on a sensor (not the shunning sensor) and I highlight it and select Show/Shun/Host, I receive a message that says the shun was successful. If I then telnet to the router, I see a new ACL on the correct interface in the correct direction, with only the allow anay any entry in the list - no denial entry at all.

I am unable at this time to get any detects on the shunning sensor because it is on a passive line on an active/passice communications line. (That's why I thought it to be the lowest utilized sensor and could handle the extra load of chores.)

I went back and checked all my configs and I don't see anything glaring. The one item I did notice is that under the interfaces tab of device management n the shunning sensor, I can create an entry with nothing in the pre-shun ACL and nothing in the post-shun ACL fields. However, if I select modify, then I can't save any changes due to a "white space not allowed in pre-ACL field" message.

I know the router is getting modified, the only problem is that no address is actually getting shunned. :-(

Also, which sensor's never-shun list gets used in the ACL creation? The originating sensor, or the shunning sensor?

Many thanks in advance....

[marcabal]

Are you executing Security->Show->Shun List or Security->Shun->Host??

The Security->Show->Shun List will query the sensor to find out what is currently shunned.

While Security->Shun->Host causes the source address of the attack to be shunned.

How to test manual shuns:

Highlight an alarm in OV.

Select Seucrity->Shun->Host

How to tell if the address was shunned:

Go back to main NetRanger Map

Select the sensor containing the alarm

Select Security->Show->Shun List and you should see the address being shunned

Select the shunning server sensor

Select Security->Show->Shun List and you should again see the address being shunned.

So the address should appear in the response from both of the sensors.

Then check the acls on the router to see if the address appears in the acl.

NOTE: Instead of highlighting an alarm to do the manual shun, you could also have done the following:

Select the sensor in the NetRanger Map

Select Security->Shun->Host

You will then be prompted for the ip and time to shun.

Then follow the steps from above to see if the address was shunned on both sensors.

How to test automated shuns:

Use nrConfigure to change the action for a specific signature to Shun. (Make hte change on the sensor that is doing the monitoring, the change is not necessary on the shunning server unless it is also monitoring)

Apply the changed configuration

Execute traffic to cause the signature to fire.

Then follow the steps above to see if the address was shunned.

As for Never-Shun Lists, they are not added to the acl being created. The Never Shuns simply prevent a shun request from taking place. In other word the Never Shun entries do not create permit lines, they just prevent the creation of deny lines. To have the address in a permit line you would need to have a Pre or Post ACL.

As for the "white space not allowed in the pre-ACL field" it looks like you found a bug in the nrConfigure program. I will pass it along to the nrConfigure test team.

[crossmanj]

Thanks for the info on the 'Shun List' command. It is helpful, and it allows me to give y'all additional details.

The sensor which has the alarm that I've shunned, shows the IP under 'Shunned Hosts' when I look at the Shun List. The same is true for another sensor from which I originated shunning. However, when I look at the shun list on the shunning sensor it shows "...not shunning any hosts".

Any ideas? There exists some communication between the sensor originating the shun and the shunning sensor, because the shunning sensor creates the ACL on the router. (Or did it create the initial ACL when the managed was restarted?) And obviously, there is some communication between the shunning sensor and the router, or at least enough to authenticate the telnet session to the router, add the ACL, and apply it to the interface.

So this would seem to rule out any problems existing at or below the transport layer. So either I've missed a basic step of the configuration, or I've found something annoying. I'm not doing the automated shuns yet, but that is part of the testing process. (I've got my STICK ready to flood the sensors for the test, too!) Any and all help is appreciated. I sure would like to get shunning up into production this month.

Also, regarding the Never-Shun lists, perhaps I wasn't clear. If Sensor A is a shunning sensor, and Sensor B is set to use Sensor A to shun an alarm. Which sensor's Never-Shun list is used? The one on sensor A, the one on B, a logical AND of the two, a logical OR of the two.... Which one has precedence over the other if both sensors are involved in the shun?

[marcabal]

Things to check:

Execute nrconns on the shunning clients.

You should see a line for the director and a line for the shunning server.

both lines should say that the connection is Established.

Execute nrconns on the shunning server.

You should see a line for the director and a line for each shunning client.

All lines should say that the connection is Established.

If the nrconns are not established then the communication setup needs to be checked.

On a shunning client as user netrangr execute:

nrexec 10003 1 30 ShunHost 1.1.1.1 10

Where equals the numerical hostid of the shunning server

and equals the numberical orgid of the shunning server.

Example: nrexec 10003 25 101 1 30 ShunHost 1.1.1.1 10

Then check the Show->Shun List on the server to see if 1.1.1.1 is shunned

What this tests is the permission of the client to send shun requests to the server.

If the shun request fails then it may be a auth problem.

If all of the above pass then the next thing to check is managed's configuration on the client.

The managed.conf file should have an entry:

DupDestination .

Where is the name of the shunning server sensor

and is the orgnization name for the shunning server sensor

Example:

DupDestination sensor2.companya

As for the Never Shun Lists, they are sequentially checked.

If a request goes to client1 then the address is checked by client1's never shun list.

If the address is in the list then client1 refuses the request.

If the address is not in the list it is passed to the server.

It is checked against the server's never shun list.

If the address is in the list then the server refuses the request, otherwise it adds it to it's current shun list.

NOTE: Even though the server refuses the request, a query against the client will likely still show the address in the client's list, but a check agains the acl will show it not being shunned on the router controlled by the server.

So the address is first checked on the client and then checked again by the server.

I recommend that never shun addresses be configured on the shunning server at a minimum.

Configuring the never shuns on the clients will reduce the load on the server and is encouraged, but I would still configure them on the server as well.