Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
FortiAdam
Contributor II

DoS Policy - Setting Correct Threshold

I have been working with DoS policy for a while now to try and pick up on anomaly traffic.  In my IPS logs I get this message: "anomaly: udp_flood, 12647 > threshold 7500, repeats 98780 times".  Can I use that information to tweak my threshold? I read that as only telling me that I exceeded the threshold but not necessarily by how much.  

 

 

1 Solution
ede_pfau
SuperUser
SuperUser

I think that's impossible to tell from the logs. It reached 12k once, and a zillion times more than 7500.

I'd set the threshold higher than say, 20.000, and watch the logs. Surely there is a theoretical upper limit, given the speed of that port and the size of an IP packet (~ 1500 bytes).

To make it more practical I suggest you split up the (expected) traffic across several policies and only protect the one service which you think is worth it. For instance, DNS with 10 MBps surely is uncommon and probably due to tunneling. (But there's AppControl for this...)


Ede


"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
6 REPLIES 6
ede_pfau
SuperUser
SuperUser

Well, you will get one message for each packet that arrives during the period in which the rate exceeds the threshold, here 7500 packets per second. If the same messages repeats more than 10 times you will only get a count of this.

 

IMHO such a low threshold for UDP traffic does not make any sense as it may well occur during 'regular' data streams. OK, 7500 packets @ 1500 bytes (roughly) make 10 MB per second which might be much for a WAN port but not for a LAN port.

 

This is what DoS prevention makes tedious: to get a correct baseline during regular traffic phases. Maybe you could have a look at the kind of traffic you get (i.e. the port) so that you can narrow it down a bit.


Ede


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
FortiAdam
Contributor II

Does that message indicate what the highest value was?  I understand setting DOS sensor thresholds is tedious but I'm looking for something to clue me in as to what my threshold should be.

 

For this specific event, if I changed my threshold to something higher than 12647, would I have avoided the alert?

ede_pfau
SuperUser
SuperUser

You've got the config. The sensor threshold should read '7500'. Only the first time it was exceeded it reached 12000+.


Ede


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
FortiAdam
Contributor II

Thanks for the helpful replies as always ede!  

 

I understand how my current threshold is set, but what I'm really looking for is what the max achieved UDP sessions per second was during this event. Can we conclusively say that 12647 was the max or is it safe to assume the UDP session per second achieved could have been much higher than that?

ede_pfau
SuperUser
SuperUser

I think that's impossible to tell from the logs. It reached 12k once, and a zillion times more than 7500.

I'd set the threshold higher than say, 20.000, and watch the logs. Surely there is a theoretical upper limit, given the speed of that port and the size of an IP packet (~ 1500 bytes).

To make it more practical I suggest you split up the (expected) traffic across several policies and only protect the one service which you think is worth it. For instance, DNS with 10 MBps surely is uncommon and probably due to tunneling. (But there's AppControl for this...)


Ede


"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
FortiAdam
Contributor II

A partner of mine is working on his NSE 4 and a question came up regarding "diag ips anomaly list".  It appears as though the output of this command will give you some sort of an idea of the counter measurements to better help determine an acceptable threshold.  If anyone else has experience using this diag command please share your findings!

Labels
Top Kudoed Authors