ASA-5520 Monitoring Attacks

[sadik.bash]

Hello ASA experts,

If you caught a syn flooding attacks against your ASA, what is the best approach to mitigate/prevent that from occuring? Also, what is the best method to monitor such attacks?

Best, ~sK            

[steven fitzpatrick · Accepted solution]

The first alarm that I normally see if the connections count rasing quite high.   I would look at limiting the max embrionic connections on the ASA to reduce the ammout of hal fopen connections permitted.  When we see similar attacks like this we normally shun the host providing that its just a single host taking part in the attack.

We monitor our ASA's via snmp so get alerted when the connection count gets obove a certain threshold which allows us to jump on the ASA and begin to monitor the traffic normally via the real time logging

[sadik.bash]

Thanks for the response!  That's exactaly what we did; however, we enabled the scanning thread detection and implemented a threat-detection policy to shun any suspecious attacker.

We use Whatsup Gold and do have all of our ASAs monitored but don't have an snmp for the connection count. Can you please share the snmp active monitor used to monitor the connection count?

Much appreciated..

Best, ~sK

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080bd3913.shtml

Scanning Threat Detection

Scanning Threat Detection is used in order to keep track of suspected attackers who create connections too many hosts in a subnet, or many ports on a host/subnet. Scanning Threat Detection is disabled by default.

Scanning Threat Detection builds on the concept of Basic Threat Detection, which already defines a threat category for a scanning attack. Therefore, the rate-interval, average rate (ARI), and burst rate (BRI) settings are shared between Basic and Scanning Threat Detection. The difference between the 2 features is that while Basic Threat Detection only indicates that the average or burst rate thresholds were crossed, Scanning Threat Detection maintains a database of attacker and target IP addresses that can help provide more context around the hosts involved in the scan. Additionally, only traffic that is actually received by the target host/subnet is considered by Scanning Threat Detection. Basic Threat Detection can still trigger a Scanning threat even if the traffic is dropped by an ACL.

Scanning Threat Detection can optionally react to an attack by shunning the attacker IP. This makes Scanning Threat Detection the only subset of the Threat Detection feature that can actively affect connections through the ASA.

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.

[steven fitzpatrick]

for the connections see snmp details below

CISCO-FIREWALL-MIB

.1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.&translate=Translate&submitValue=SUBMIT&submitClicked=true

We use Caccti to graph this as well and poll it.

We played around with the automatic shun of suspicious behavour but have had  a few faule positives which cause some issues for us where we are providing multi tenant internet access.

from the above we average between 1-6k total connections for our environment so as soon as this hits the 15-20k mark our threshold kicks in and alerts us.

This worked well for us in the last week alone with alerting as one of our hosts was being vigourously scanned and another was being syn flooded.