This is on the ASA, not on an IPS unit. The whole point is to leverage the ASA as a first line of defense, by blocking obvious/agressive port scanning. The IPS should only see packets that have been permitted by an ACL on the ASA, and is therefore no use (IMHO) for generic scanning and reconnaissance attacks.

I've had a case open with TAC for a little over two weeks, but they haven't gotten back to me yet. I'll update this thread once they do.

Did you find an answer to this? I have a client who just had a penetration test run and the scanning company reported the same thing. We already had 'threat-detect scanning-threat shun' enabled.

It works, but only if average-rate or burst-rate is set to 0 (meaning - always trigger). I typed "threat-detection rate scanning-threat rate-interval 600 average-rate 4 burst-rate 0" and NMAP "attacker" finally shows up in Shunned Host List.

I hope I didn't miss anything, but my conclusion is that bad guys with NMAP can use intense NMAP scans on all ports and will not be shunned if default settings (average/burst rates) are used on firewall. So, what's the point in having Threat Detection enabled, if it doesn't block the most popular port-scanning application?

Does that setting of "threat-detection rate scanning-threat rate-interval 600 average-rate 4 burst-rate 0" actually work in production for

you?  I find that it's triggering ALL THE TIME for me....basically, it never shuts up.  I can't seem to find anything that only alerts when there is an attack going on....I'm still trying but so far, this seems oddly malfunctional.

The first paragraph was posted on the 13, the next paragraph, the 14th.

I've done some additional testing and actually got a hit early this morning.  According to the logs, there were a lot of connections to port 25 from a single host and that triggered a message, " %ASA-4-733101: Host nnn.nnn.nnn.nnn is attacking.",  I have not been able to duplicate this.  Some of the packets from nnn.nnn.nnn.nnn were ACK packets, some FIN ACK and some FIN ACK PSH.  All were destined for port 25 with a variety of source ports.  The teardown normally was within the same second with 37-43 bytes recieved, a few were 80 bytes and a few with 0 bytes and one of 117 bytes.  This definitely looks like some type of attack traffic.  This "attack" lasted 7 minutes and 600 packets were denied from the attacker in that time period.  I then tried to duplicate the "attack" primarily using nmap and hping and I have been unable to trigger the 733101 event although the traffic has been logged and I sent WAY more than 600.

If anybody is sucesfully using the threat-detection feature, I'd love to hear how you have it set up and what you're doing to test.

You should never use burst value 0 because this means you will filter every hit (syn, acl-drop etc).

I'll give you a sample example here that I use in production:

no threat-detection rate syn-attack rate-interval 600 average-rate 100 burst-rate 200     "This line will disable the default ASA threat-detection for syn"
threat-detection rate syn-attack rate-interval 600 average-rate 30 burst-rate 45     "This means, I will shun if one host keeps sending 30 syn's per second for 600 seconds, and the burst rate means, if one host make 45 tcp syn in 1 second I will shun him right away"

So the average rate means unless a host keeps sending 30 syn per sec for 5 minutes, he will not get shunned.

if you set the burst rate 2, then that means any host that sends 2 syn packets per second will get shunned (without the 5 minutes monitoring period).

Hope this helps.

Mohammed Khair