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?
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.
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
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.
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?
Then check the Show->Shun List on the server to see if 22.214.171.124 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:
Where is the name of the shunning server sensor
and is the orgnization name for the shunning server sensor
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...