Best practices for detecting DOS (denial of servic

问题:

I am looking for best practices for detecting and preventing DOS in the service implementation (not external network monitoring). The service handles queries for user, group and attribute information.

What is your favorite source of information on dealing with DOS?

回答1:

This is a technique I found very useful..

Prevent Denial of Service (DOS) attacks in your web application

回答2:

Whatever you do against DoS-Attacks, think if what you do may actually increase the the load required to handle malicious or unwanted requests!

If you are using Linux then you should read this article:
Rule-based DoS attacks prevention shell script (from Linux Gazette) It has the following topics:

• How to detect DoS attacks from /var/log/secure file
• How to reduce redundant detected IPs from the temporary file
• How to activate /sbin/iptables
• How to install the proposed shell script

Applying this without properly restricting the number of blocked IPs in iptables may intro a DoS-Vulnerability by increasing the requiered resources to handel unsolicited requests. To reduces that risk use ipset to match IP-Addresses in iptables.

Also, read about ssh dictionary attack prevention using iptables. (enabling iptables with stateful firewalling as suggested here does not protect against most DoS-Attacks against but may actually ease DoS-Attacks that pollute your RAM with useless state info.)

New to Linux? read the Windows-to-Linux roadmap: Part 5. Linux logging of IBM.

Good Luck!

回答3:

My first attempt to solve the DoS vulnerability used the approach suggested by Gulzar, which is basically to limit the number of calls allowed from the same IP address. I think it's a good approach, but, unfortunately, it caused my code to fail a performance test.

Since I was unable to get the performance test group to change their test (a political problem, not a technical one), I changed to limiting the number of calls allowed during a configurable interval. I made both the maximum number of calls and the time interval configurable. I also allowed setting a value of 0 or a negative number which disables the limits.

The code that needed to be protected is used internally by several products. So, I had each product group run their QA and performance test suites and came up with default values that were as small as possible to limit a real DoS attack but still passed all the tests.

FWIW, the time interval was 30 seconds and the maximum number of calls was 100. This is not a completely satisfactory approach, but it is simple and practical and was approved by the corporate security team (another political consideration).