Solved: Re: SecureXL dos

Vincent_Bacher · ‎2026-02-28

Hey everyone,

I’ve been looking into SecureXL’s DoS protection features and wanted to get some input from people who’ve worked with this in production.

From what I understand, there are four possible scenarios when combining Rate Limiting and the Penalty Box:

∙ Both disabled, Monitor Mode on — no enforcement, just logging
∙ Penalty Box on, Rate Limiting off — I’m assuming the Penalty Box can still trigger from ACL or IPS drops, but I’m not fully sure how effective it is without Rate Limiting generating drops
∙ Rate Limiting on, Penalty Box off — traffic gets throttled but no IP ever gets fully blocked
∙ Both enabled, Monitor Mode on — violations are actively detected and tracked against real thresholds, but no actual blocking occurs until monitor mode is turned off

What I’m mostly curious about is real-world experience. What side effects have you run into in production? Any unexpected behavior when enabling these features on a live firewall? Lessons learned around tracking modes, threshold tuning, or internal interface enforcement?
Would love to hear from anyone who’s been through it.

Thanks

Vince

and now to something completely different - CCVS, CCAS, CCTE, CCCS, CCSM elite

Gennady · ‎2026-02-28

Good day!

A test for this feature was once requested by one of our customers. I did performance testing with Cisco Trex split traffic profile where some traffic was subjected to fwaccel dos feature.

Here is the "Accept" traffic load generated by Trex:

Here is "DoS" traffic also generated by Trex:

Here is the Rate Limiting rules.

I guess the config doesn't need an explanation. However, you need to be sure that you enable the feature on correct interfaces because there are options.

HTOP output before enabling the rate limiting:

Poor 23800 basically died under 500K pps Accept traffic + 3M pps Drop traffic. This indicates successful DoS.

HTOP output after fwaccel dos rate limiting rules were enabled:

It is very important to mention that I had to stop trex traffic to enable rate-limiting rules. It was impossible to enable the rate limiting under DoS because the command fails every time. Same goes for deny list update.

To use the feature, you need to have some kind of predefined active rate-limiting policy. The good part is that as soon as rate limiting is working, you will have very efficient drop mechanism very early in SND. You can see on the screenshot above that even SND survive good under 3M packet drop with no effect on good traffic.

The other important thing is that the feature is called "fwaccel Dos" not "fwaccel DDoS" for a reason. When all the bad traffic comes from a limited number of source addresses the rate limit triggers timely and prevent the DoS. If the bad traffic is distributed among good variety of source addresses, then rate per address may be low and still sufficient to create resource oversubscription.

There is a feature to track packet rate per source IP to prevent fails positives. When the feature is enabled the same traffic profile doesn't trigger any drops because per-Source rate is much lower. The screenshot below shows a lot of matches for the rate limit rules and 0 drops because the traffic is coming from 61K source addresses.

Same argument foes for penalty box. It works with the same efficiency as rate-limiting for DoS attack. The main thing to consider is that penalty box is triggered for drop rate originated not only from FW/IPS Policy but by other FW drops either. For example, by "First packet is not SYN". We have got a problem in the Lab during the stress test. BGP traffic starts to be dropped right before penalty box kicked in for Bad traffic. This triggered BGP to go to Penalty Box for 3 minutes. It was the end of the test iteration. It worth to include critical IPs into whitelist for penalty box and rate limiting just in case. I have requested SK112454 update because of this incident:

As you see, it was slightly updated. However, it is now not as misleading as it was.

I don't have screenshots but as far as I remember, penalty box has some time to gather statistics about dropped packets, and it triggers a critical delay because DoS starts all at once and for some seconds valid traffic may be dropped because of the attack. This may lead to this traffic to be boxed either.

View solution in original post

Gennady · ‎2026-02-28