Protect your Apache server from DoS attacks
Encontrei no meu PC um artigo que já tinha encontrado na net á algum tempo e pode ser que tenha interesse para assunto em questão.
Suppose you own a carryout restaurant. Your competitor across the street is determined to bring you down. You're used to doing a brisk evening business, but one night your phones ring off the hook. Order after order pours in. Your drivers are busy all evening, taking orders to addresses that don't exist. Meanwhile, dozens of regular customers trying to phone in their orders can't get through. Your competitor is more than happy to take care of your untended customers—who throw away your phone number and scribble down your competitor's. A few nights of this and you're out of business, while the perpetrator enjoys a rush of new business.
If you do business on the Web, you're vulnerable to exactly this sort of malicious assault in a Denial of Service (DoS) attack, and any server running Web sites, ftp, or mail hosting on the Internet is, to some degree, vulnerable.
The idea is simple: a competitor, a mischievous hacker, or a disgruntled former employee wants to do the company harm. The chosen method is to take the company's Web site or other server-based public service offline, or at least slow it down to the point of being unusable. This is usually done in one of several ways, involving the bombardment of the server with meaningless user requests to use up all available bandwidth or to push the server past its resource limits.
The assault can be made on the server itself, the server's network, or the server's operating system. There are also distributed attacks, involving the viral distribution of an assault program to unwitting, randomly distributed servers throughout the Internet, timed to begin simultaneously pummeling the target site in a sustained, coordinated attack.
How can you protect your Apache server from such attacks? First, let's look at the mechanics of these attacks to understand how they affect your server.
Packet flooding
One way to disrupt a server or its local network is with packet flooding, usually of Internet Control Message Protocol (ICMP) packets or UDP packets. In simplest form, these attacks are all about overloading the amount of traffic a server or network can handle, presupposing that the attacker has a faster network connection than the target. The advantage of using UDP is that nothing comes back to the attacker's machine. The advantage of ICMP is that the attacker can make the attack more sophisticated, sending flawed packets that can confuse and even lock up the victim's network. In a very stylish variation, it is possible to fool a target server into believing that it is receiving a massive flood of messages from itself.
Disk attacks
A more brutal style of attack centers not just on the victim's communications, but on its hardware. False user requests assault the hard drive of the target machine with write commands, pushing it past its limits and forcing a shutdown. This is more than mischief; serious harm can befall the victim because information is not simply temporarily inaccessible, it can be lost altogether.
Routing to nowhere
Often, a DoS attack centers on a network's routers, with the attacker seizing control and steering traffic past the target machine (so that too little information, rather than too much, is reaching it). When the attacker is able to change the routing tables of a router, entire networks (let alone a target server) can be rendered inaccessible. This style of attack is particularly insidious because it is often baffling when it first manifests. After all, it's easy to see that your server is getting pinged to death, but when no one seems to be visiting, many possible causes must be sifted through.
The huge disadvantage with Apache is that its popularity makes its foibles and exploitable weaknesses well known. Apache servers throughout the Internet come under DoS attack all the time.
Apache's vulnerabilities
The attacks described above, made against servers running Apache, exploit characteristics of the kernel and/or the daemons. One of these is the functional assumption of the kernel that TCP/IP packets are authentic, or they wouldn't have gotten all the way in. But bogus TCP/IP packets are now easier to generate and more commonly used in server attacks. The frightening thing about this bug is that nothing has to be running on the target machine for the attack to succeed.
Another vulnerability in the server code is that the memory allocation features assume benevolent requests for service, a staple of client functionality and efficiency. An Apache server can be vulnerable to inbound allocation traps that permit host-to-host crashes by burning up RAM artificially.
Here are ways you can protect yourself.
System admin host-to-host attack prevention
An inbound header will alert an Apache server to allocate memory to accommodate whatever the header is attached to. Since this allocation is doled out according to a default minimum, a cascade of header-only requests will cause a non-linear consumption of available memory, eventually resulting in a crash. This style of attack is actually a standard, and has been around awhile.
If you're running a version of Apache above v1.3.2, you have a defense. And it's simple: Consider that for a host-to-host attack as described above to succeed, a huge number of header-only requests would need to bombard the system, on the order of tens of thousands. Your solution is the MaxClients directive, which your system administrator can set to a desired maximum, causing a host-to-host attack to abort long before memory is exhausted.
Defending Apache against self-propagating attacks
One of the toughest forms of attack to defend against is the Distributed DoS (DDoS) attack. When multiple machines are infected with an attack program targeting your Apache system, you're in a world of hurt. Self-propagating attacks are the worst, because the attacking program spreads to source machines without human intervention.
Apache servers are particularly vulnerable, both to DDoS attacks and exploitation as unwitting attack sources. Why? Because Apache is everywhere. There are countless Apache servers on the Web, so an Apache-specific virus (the SSL Worm, in particular) has many potential hosts; bandwidth is now available by the bargeload, so there's plenty of room for an attacker to maneuver, and Apache systems tend to be stable, requiring infrequent upgrades, so routing out such a problem is cumbersome.
The attacking worm installs itself on an Apache server specifically through a flaw in the server code during the SSL handshake. The attacker has set up a bogus key that Apache responds to with a buffer overflow (this is specific to servers running versions of OpenSSL older than 0.9.6e). The attacker can then execute malicious code on the infected machine, and, in many such viruses, the next event is a DDoS attack against a specific target. With such a worm propagating autonomously and infecting any Apache server it happens on, a huge peer-to-peer assault network can form, all with the intent of taking down a particular target server or network (maybe yours).
What can you do? Upgrade your OpenSSL! Go to version 0.9.6e or higher; the bogus key that starts this whole mess won't work, and your machines can't be used as part of such a system, nor can they be penetrated with this mechanism. Some antivirus programs can spot and stop the SSL Worm, but don't count on this: The worm's fingerprint can change, causing the antivirus program to miss it. Note that rebooting Apache will kill such a worm, but won't do anything to prevent a subsequent infection.
Firewalls are still well worth building
In the case of network attacks, a firewall will go far in protecting you. Just keep in mind what it will and won't do. A firewall will aid you in preventing a conventional DoS attack, with inauthentic users making inauthentic requests, which a firewall can mitigate. But a firewall isn't going to help you when the DoS attack is one that uses legitimate services against you, so don't make the mistake of considering it a blanket fix.
When the DoS attack is a network attack, a firewall is great to have. That style of attack is about the contents of the packets that are flooding the network, and firewalls do the essential job of examining those packets and screening out those that are suspect. In addition, your firewall can do the even more important job of scrutinizing remote users entering your network.
How to detect attacks
As you might guess, it's easier to detect a DoS attack at the network level than at the server level. Network attacks are about screwing up communications and routing, and these things are out in the open where they can be monitored. You can learn the details about software specifically for this purpose at linuxsecurity.com.
DoS server attacks are harder to detect, because at the server level it's harder to parse out the legitimate user requests from the bogus ones. The main thing you can do is know when the pattern of use in a server on your network is deviating from the norm, so you'll know early on when you're being hit. Some great software is available for this purpose. Check out Tripwire, Nagios, and SNIPS (System/Network Integrated Polling System).
DoS evasive maneuvers
Starting with Apache 1.3, a new module called mod_dosevasive is at your disposal. It means "DoS evasive maneuvers" and its function is to reject bogus requests. It keeps an eye on bandwidth and resource usage. It can't help you in the event of a distributed attack (almost nothing will) but is very effective against more conventional attacks and well worth investigating.
