I have a lot of outside hosts trying to scan my network and would like to shun them for a certain period.
A lot of this hosts are probing (scanning a range of addresses looking for host that listens to port 23 or some other port).
I tried setting up the asa to shun those atackers but the only thing I got working was getting a host (test attacker) shun when attacking a single host inside my network using NMAP.
I see a lot of events like this
733100 [ Scanning] drop rate-1 exceeded. Current burst rate is 5 per second, max configured rate is 5; Current average rate is 2 per second, max configured rate is 5; Cumulative total count is 1712
but there are no hosts that are shun.
Here is the relevant configuration:
no threat-detection rate acl-drop rate-interval 600 average-rate 400 burst-rate 800
threat-detection rate acl-drop rate-interval 600 average-rate 400 burst-rate 5
threat-detection rate acl-drop rate-interval 3600 average-rate 320 burst-rate 640
no threat-detection rate scanning-threat rate-interval 600 average-rate 5 burst-rate 10
threat-detection rate scanning-threat rate-interval 600 average-rate 5 burst-rate 5
threat-detection rate scanning-threat rate-interval 3600 average-rate 4 burst-rate 8
no threat-detection rate syn-attack rate-interval 600 average-rate 100 burst-rate 200
threat-detection rate syn-attack rate-interval 600 average-rate 30 burst-rate 15
threat-detection rate syn-attack rate-interval 3600 average-rate 80 burst-rate 160
threat-detection scanning-threat shun except ip-address X.Y.128.128 255.255.255.224
threat-detection scanning-threat shun duration 600
no threat-detection statistics access-list
no threat-detection statistics tcp-intercept
Is there something else I need to do to enable shunning of attackers?
If you still have some questions come back to us but it's pretty clear and granular there
Thank you for taking the time to respond. I did have a look a that link even before asking the question here.
I think that my configuration is according to what is written there and I see 733100 events being logged but no host is being shun.
Shouldn't every 733100 event result in a shunned host if shunning has been enabled?
The log that you should see related to the scanning feature of ATD is the following:
Are you receiving any of those logs??
These are the ones that let you know that a shun just happened
Now can you share the following command
show threat-detection scanning-threat
You could try to adjust the Rates configured in order to detect one of this events quicker,
In my current log I have 645 times of 733100 and only 2 times 733101 and 2 times 733102.
Both of this hosts have been scanning for port 25 (smtp) on every of our ip addresses.
So it seems that the device does shun afterall but why did it only register 2 x 733101 and 2 x 733102 events when there are 645 x 733100 events?
Doesn't a 733100 automaticaly trigger a shun?
This is the output of the command you requested:
pix# show threat-detection scanning-threat
Latest Target Host & Subnet List:
Latest Attacker Host & Subnet List:
So only 2 IPs have been shunned,
Remember that for a shun to happen the traffic must reach the destination IP address
only traffic that is actually received by the target host/subnet is considered by Scanning Threat Detection
What exactly does this mean: only traffic that is actually received by the target host/subnet is considered by Scanning Threat Detection
Both hosts that have been shunned have been scanning for port 25 (SMTP) on my inside ip address range. I don't have any host listening on host 25. There are other attackers scanning for other ports but they are not shunned.
One more thing: If a traffic is being blocked by an access list that also generates 733100 but if I understand you correctly this will not get a host shunned?
Exactly. If the traffic is already being blocked by an ACL, then the ASA doesn't need to act on it, so the shun isn't issued. Remember, one of the "asp-drop" reasons that the ASA counts as a "scanning threat" is acl-drop. So many times the log messages you are receiving are simply letting you know that the ASA dropped a large amount of packets from the same host in a given interval. But since it was already being denied, an additional shun didn't need to be issued.