Hi all,
I run anomaly DoS detection between a students network and our campus lan. Thresholds are still default values. Problem is our campus dns server.
I get many udp_dst_session, udp_flood, ip_dst_session just because of legitim (?) dns requests. 99% of all triggered anomalies are: clients -> dnsserver:53/udp.
Sure, I could adopt thresholds but this would affect all udp traffic. Better would be to whitelist udp traffic to this dns server. Is this possible?
anomaly: ip_dst_session, 7735 > threshold 5000, repeats 1312 times since last log
BTW: how are thresholds counted? udp is ip traffic, so does a 53/udp packet count for all three categories (udp_dst_session, udp_flood, ip_dst_session). And is this threshold for one client to server or all clients to server? Encylopedia says "the number of concurrent UDP sessions to an IP address is above specified threshold level", so I would assume latter.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hey FloToHu,
regarding the thresholds, I have no idea, sorry, and I couldn't find any documentation on this as yet.
Regarding whitelisting:
You can create a second DoS policy on top with a specific source address (the one you want to whitelist) and set action to 'Disable' for the appropriate anomalies; that should exempt the IP in question from DoS. If you set 'Monitor' instead, traffic would be allowed but some anomaly logs would be generated.
Hope that helps!
Hey FloToHu,
regarding the thresholds, I have no idea, sorry, and I couldn't find any documentation on this as yet.
Regarding whitelisting:
You can create a second DoS policy on top with a specific source address (the one you want to whitelist) and set action to 'Disable' for the appropriate anomalies; that should exempt the IP in question from DoS. If you set 'Monitor' instead, traffic would be allowed but some anomaly logs would be generated.
Hope that helps!
Hi @Debbie_FTNT ,
your solution is even better than whitelisting. I created a second rule above the triggering one which I restricted to this single dnsserver and port 53/udp. There I could set greater threshold values and now my logs get cleaner again. Works perfect.
What I still wonder is whether all traffic over all clients is cumulated to trigger a threshold or it is really the traffic of one single client. It is hard to believe that a regular client should trigger a rule with 12.000 udp packets (~ 12.000 dns requests) per minute. And when I monitor the server itself it is more the amount of traffic all clients create - not a single one. But assuming I would replace my monitoring rule by a blocking one. Then I would block an arbitrary client that triggers the rule, while requests of other clients count towards the threshold. In case of a DDoS this would be ok, but not with regular clients. Is there a best practise?
If I ever switch this rule to blocking I would have to calculate like this:
max. requests per client per minute * max. clients per subnet
BINDs response rate limiting examples are 5-10 requests/second, thus it would be 300-600 requests/min * ~180 clients = 54.000 - 108.000 requests/min. Assume 1 request = 1 packet, then my threshold would have to be at least ~ 54.000 to prevent clients from being blocked by accident. Right?
Hey FloToHu,
from what I found, whether single clients or all clients together trigger a DoS policy depends on the specific anomaly.
For example:
'udp_scan' -> If the UDP sessions setup rate originating from one source IP address exceeds the configured threshold value, the action is executed.
Found here: https://docs.fortinet.com/document/fortigate/6.2.9/cookbook/771644/dos-protection
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.