4

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.

1 Answer 1

4

TL;DR Scanning-Threat should not be thought of as a new feature, more of an enhancement to Threat-Detection.


I think these links could possibly help you, however considering you seem to have done the research you might've already come across them

Here is a list of what can cause a Threat-Detection trigger:

  • ACL Denial
  • Bad Packet Format
  • Exceeded Connection Limits
  • Denial of Service (DoS) Detection
  • Basic Firewall Check Failure
  • Suspicious ICMP packets Exceeded
  • Application Inspection Packet Failure
  • Interface Overload
  • Scanning Attack Detection
  • Incomplete Session Detection

A Scanning-Threat is not the same thing as Threat-Detection, you need to think of Scanning-Threat as an enhancement/addition to Threat-Detection to provide additional security capabilities. It allows you to keep track of "suspected attackers" when too many connections are created in a subnet and by default this feature is disabled.

A nice thing about Scanning-Threat is the fact that it builds a database of target IP addresses that are suspected to be an attacker. As per the Cisco documentation, below is a nice example of what Scanning-Threat can do.

When Scanning Threat Detection detects an attack, %ASA-4-733101 is logged for the attacker and/or target IPs. If the feature is configured to shun the attacker, %ASA-4-733102 is logged when Scanning Threat Detection generates a shun. %ASA-4-733103 is logged when the shun is removed. The show threat-detection scanning-threat command can be used in order to view the entire Scanning Threat database. - Cisco Scanning Threat

1
  • Thanks for this. The list of causes that you provide seems to relate to basic-threat rather than scanning-threat. Most of those can be tracked back to malformed packets or to explicit drops by ACL. scanning-threat is a subset of basic-threat (you can see Scanning Attack in your list) but allows for extra options (like shunning). May 2, 2018 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .