ASASM failing caused by DoS from single PC

[Florian Pressler]

Hi,

I recently had the case at one of my customers that the ASA Service Module in their coreswitch was making trouble. The symptoms were massive packet-loss for valid connections and also problems with high-availablity (the failover-cluster fell apart multiple times, with both modules being in the same chassis).

During troubleshooting, we found one (one!) PC in a segment which had a perl-script running. The script sent loads of small UDP-packets, as much as the PC could generate. This host was located inside and tried to send to internet - those packets were denied and also generated lots of syslog-messages (because of the deny).

As soon as the host was removed from the network, the problems disappeared.

I want to ask:

• Is this normal, expected behaviour? A single PC can knock out the ASASM?
• What methods can you think of the mitigate this beforehand?

I searched the configuration-guide of ASASM and only found log rate-limiting, which I'd like to try out (I don't know yet if the logging was the reason for the problems at all, but I guess at the moment). Any other ideas?

Thanks,

Florian

[Julio Carvajal]

Hello,

One host, thats awful.

I think we should have a detailed picture of the network enviroment before answering that but I would say no.

In regards of how to prevent that you can use the DoS prevention techniques (TCP normalization stuff, Connection Limits and of course the Shunn feature)

Read on those and then determine what action should be taken,

Regards,

Jcarvaja

[Florian Pressler]

Hi jcarvaja,

thanks for your comment.

Regarding your suggestions: TCP normalization stuff and connection limits are both not applicable. This is because the specific connection which triggered the failure was denied by the ASASM in the first place. So these techniques wouldn't come into action, because they only apply to allowed connections.

The shun feature might prevent the excessive logging (i didn't try it out). But I would still prefer a solution where i wouldn't have to run into the problem first, before I can place the counter-measure. In other words: I would like to configure the ASASM in a way which prevents it from being knocked out by a single  host.

Regards,

Florian