TL;DR - Can anyone describe exactly what constitutes a scanning-threat hit, when using threat-detection
on a Cisco ASA?
I have a client who connects to my network via a VPN to reach a hosted application, and has recently fallen foul of the configured firewall policy and swears that they are not doing anything different from usual.
The ASA is configured to temporarily block (shun) network addresses that exceed any of a series of rates.
threat-detection rate scanning-threat rate-interval 600 average-rate 5 burst-rate 10
threat-detection rate scanning-threat rate-interval 3600 average-rate 4 burst-rate 8
threat-detection scanning-threat shun except object-group SCAN_WHITELIST
threat-detection scanning-threat shun duration 900
Business demands have required me to whitelist them for now, and this will likely continue unless I can explain better what they appear to be doing wrong. I presume the client not to be a bad actor since it's not in their interest to block themselves from the service we give them. I'm not looking to catch them out, nor accuse them of anything underhand.
My other alternative is to re-evaluate the rates (we are simply using the defaults), but that also requires that I understand what I'm permitting.
All documentation I've found so far describes scanning-threat
in terms of 'when the ASA detects a scanning threat...', but I can't find anything that explains what constitutes a scanning threat, i.e. what event(s) cause the scanning-threat counter to increment?
I could guess that it might be a series of connections with an incrementing target TCP port and that may be the case, but it doesn't seem likely for good-faith end-users, who have been told exactly what time their problems started.
I could guess that it might be a series of connections with an incrementing source TCP port, but surely many PAT-based traffic managers would fall foul of this (without adequate source-port randomisation)?
Since this is unfiltered VPN traffic (and sysopt connection permit-vpn
applies), this traffic does not fall foul of a particular access-list, otherwise I might see the explicit dropped traffic in the log.
The client, themselves pre-NAT their traffic behind a single address prior to traversing the VPN, so all traffic appears to come from the same source address -- so, when it is shunned, all access to the hosted application is lost for a number of minutes. The subsequent shunned packets are logged, and appear to be normal for the application -- pings and tcp/443.