Apache Security - Ivan Ristic [72]
The mod_dosevasive module is not as good as it could be because it does not use shared memory to keep information about previous requests persistent. Instead, the information is kept with each child. Other children know nothing about abuse against one of them. When a child serves the maximum number of requests and dies, the information goes with it.
Blacklisting IP addresses can be dangerous. An attempt to prevent DoS attacks can become a self-inflicted DoS attack because users in general do not have unique IP addresses. Many users browse through proxies or are hidden behind a network address translation (NAT) system. Blacklisting a proxy will cause all users behind it to be blacklisted. If you really must use one of the traffic-shaping techniques that uses the IP address of the client for that purpose, do the following:
Know your users (before you start the blacklist operation).
See how many are coming to your web site through a proxy, and never blacklist its IP address.
In the blacklisting code, detect HTTP headers that indicate the request came through a proxy (HTTP_FORWARDED, HTTP_X_FORWARDED, HTTP_VIA) and do not blacklist those.
Monitor and verify each violation.
DoS Defense Strategy
With some exceptions (such as with vulnerabilities that can be easily fixed) DoS attacks are very difficult to defend against. The main problem remains being able to distinguish legitimate requests from requests belonging to an attack.
The chapter concludes with a strategy for handling DoS attacks:
Treat DoS attacks as one of many possible risks. Your assessment about the risk will influence the way you prepare your defense.
Learn about the content hosted on the server. It may be possible to improve software characteristics (and make it less susceptible to DoS attacks) in advance.
Determine what you will do when various types of attacks occur. For example, have the contact details of your upstream provider ready.
Monitor server operation to detect attacks as soon as possible.
Act promptly when attacked.
If attacks increase, install automated tools for defense.
Chapter 6. Sharing Servers
The remainder of this book describes methods for preventing people from compromising the Apache installation. In this chapter, I will discuss how to retain control and achieve reasonable security in spite of giving your potential adversaries access to the server. Rarely will you be able to keep the server to yourself. Even in the case of having your own private server, there will always be at least one friend who is in need of a web site. In most cases, you will share servers with fellow administrators, developers, and other users.
You can share server resources in many different ways:
Among a limited number of selected users (e.g., developers)
Among a large number of users (e.g., students)
Massive shared hosting, or sharing among a very large number of users
Though each of these cases has unique requirements, the problems and aims are always the same:
You cannot always trust other people.
You must protect system resources from users.
You must protect users from each other.
As the number of users increases, keeping the server secure becomes more difficult. There are three factors that are a cause for worry: error, malice, and incompetence. Anyone, including you and me, can make a mistake. The only approach that makes sense is to assume we will and to design our systems to fail gracefully.
Sharing Problems
Many problems can arise when resources are shared among a group of users:
File permission problems
Dynamic-content problems
Resource-sharing problems on the server
Domain name-sharing problems (which affect cookies and authentication)
Information leaks on execution boundaries
File Permission Problems
When