SecureXL dos feature adjustment and information collection

[Christoph_Hornu]

Hello Community,

I've encountered a special challenge with SecurexL.

I've also opend  a SR.

He're the case.

We had false-positive dos drops, so we had to enable the monitor mode with 'fwaccel dos config set --enable-monitor'  as described in sk112454.

We've also added rate limit rule like

fwaccel dos rate add -a d -l r -n "comment 1 " service 6/53 source cidr:<NET1> destination cidr:<NET4> new-conn-rate 200 track source
fwaccel dos rate add -a d -l r -n "comment 2" service 6/53 source cidr:<NET2> destination cidr:<NET4> new-conn-rate 200 track source
fwaccel dos rate add -a d -l r -n "comment 3" service 6/53 source cidr:<NET3> destination cidr:<NET4> new-conn-rate 200 track source
fwaccel dos rate add -a d -l r -n "comment 4 " service 17/53 source cidr:<NET1> destination cidr:<NET4> new-conn-rate 200 track source
fwaccel dos rate add -a d -l r -n "comment 5" service 17/53 source cidr:<NET2> destination cidr:<NET4> new-conn-rate 200 track source
fwaccel dos rate add -a d -l r -n "comment 6" service 17/53 source cidr:<NET3> destination cidr:<NET4> new-conn-rate 200 track source

'fwaccel dos rate get' shows the correct output like
operation=add uid=<624fcac1,00000000,f96a15ac,00000ffe> target=all timeout=none action=drop log=regular name=<> service=6/53 source=cidr:<NET1> destination=cidr:<NET4> new-conn-rate=200 track=source
operation=add uid=<624fff4a,00000000,f96a15ac,0000583d> target=all timeout=none action=drop log=regular name=<> service=17/53 source=cidr:<NET2> destination=cidr:<NET4> new-conn-rate=200 track=source
operation=add uid=<624fff53,00000000,f96a15ac,00005856> target=all timeout=none action=drop log=regular name=<> service=17/53 source=cidr:<NET1> destination=cidr:<NET4> new-conn-rate=200 track=source
operation=add uid=<624fcac5,00000000,f96a15ac,0000100c> target=all timeout=none action=drop log=regular name=<> service=6/53 source=cidr:<NET3> destination=cidr:<NET4> new-conn-rate=200 track=source
operation=add uid=<624fcc20,00000000,f96a15ac,00001d20> target=all timeout=none action=drop log=regular name=Catch All source=any destination=any new-conn-rate=20 track=source service=any
operation=add uid=<624fff58,00000000,f96a15ac,00005867> target=all timeout=none action=drop log=regular name=<> service=17/53 source=cidr:<NET3> destination=cidr:<NET4> new-conn-rate=200 track=source
operation=add uid=<624fcab8,00000000,f96a15ac,00000fd9> target=all timeout=none action=drop log=regular name=<> service=6/53 source=cidr:<NET2> destination=cidr:<NET4> new-conn-rate=200 track=source

Now the connections got still detected (due monitoring mode), but the logs shows int the SecureXL message:

'The packet violated the DOS module's rate limiting rulebase (SecureXL device 0) (policy: 22) (total rules: 1)'

In the comment section it shows : '<624fcc20,00000000,f96a15ac,00001d20>' which refers to the default rule.

SO, tl;dr

Why the custom rules not working, and why the SecureXL message show only total rules:1?

Follow UP question: Does anyone have a good oneline to show the numer ob new connections to an ip with/without serice: i.e. all new dns requests to 8.8.8.8? The fwaccel dos stats get if not really detailed.

Best Regards

Christoph Hornung

[Timothy_Hall]

I believe your "Catch All" rule is taking precedence because it is the most stringent (i.e. enforcing the lowest new-conn-rate and also matching any/any), which is how Threat Prevention policies in general work.  What happens if you set the new-conn-rate to 200 or 201 in your Catch All rule?

[Christoph_Hornu]

Thanks, that would explain the behaviour. I will try if we can set up this for testing.