What Is a DDoS Attack?
A distributed denial-of-service (DDoS) attack is a coordinated strike, distributed among different computers, that aims to prevent the authorized use of one or more systems.
These Web server DDoS attacks have become a weapon of choice for malicious actors to conduct cyberattacks. They are used by different types of attackers, from experienced cybercriminals to the bored teenager.
One of the assets that’s most often targeted by attackers is the public Web server of a victim. Although these servers might (and should) not hold that much sensitive or critical information, they are a target of choice because of their immediate public visibility and, consequently, the potential financial impact of an attack.
This article lists a number of protection mechanisms to defend against Web server DDoS attacks, more specifically those against Apache Web servers.
Types of DDoS Attacks
There are three types of DDoS attacks:
- A volumetric attack, completed by overflowing the available bandwidth;
- A traffic attack, done by abusing the available system resources;
- An application attack, executed by exhausting the available system resources.
Sometimes attackers will combine the different types of attack into one campaign.
One of the most observed attack types is a volumetric attack, especially one that is amplification-based. In an amplification attack, packets with a spoofed source address are sent to a vulnerable service. This service will then reply with a much larger reply toward the spoofed address (the victim).
Motivation for the Attacks
Why do people conduct DDoS attacks? This can be for various reasons, but essentially, whatever bothers the attacker can be enough to trigger an incident.
The motivation can be political or ideological protest, blackmail, a smoke screen to hide other attacks, showing off technical skills or maybe just because someone is bored.
Be Ready for Web Server DDoS Attacks
There are a number of preventive measures you can take to be prepared for an attack, but you must realize that there is not always a proper defense against some large-scale strikes. Sometimes you just have to wait until the attacker loses interest and moves on to the next target.
What can you do to be prepared for a DDoS attack? It starts with a few best practices:
- Understand your environment and prioritize your assets.
- Apply best practices for the configuration of network devices, systems and services.
- Monitor and log your networks, systems and services.
- Have an incident response plan.
- Have a crisis communication and business continuity plan.
When you design your incident response plan, you should also take into account how you have to interact with your ISP, service providers, CERTs and law enforcement agencies in the event of an attack. Setting up these communication channels and information exchange methods in advance allows you to focus on the core of the problem during an incident: incident handling.
Attackers can start a volumetric attack against a website but can also issue an application or traffic attack. When dealing with the volumetric attack, the mitigation is most often done on a network level, whereas the application and traffic types have some mitigation on the Web-service level.
Service Protection for Apache
For one of the most popular Web servers, Apache, there are a few mitigation solutions available.
ModSecurity is an open-source Web application firewall. It allows real-time application security monitoring and access control. The different sets of protection rules allow you to inspect the HTTP traffic and reliably block unwanted traffic. It allows you to fix session management issues and block SQL injection attempts. Most importantly, it’s an open architecture, so you can enable only the features that you consider necessary.
One of the biggest strengths of ModSecurity is virtual patching. You are protected against application vulnerabilities for which you are not yet able to patch.
With ModSecurity, you can protect and harden your website against unwanted malicious traffic and reduce the size of the possible attack vector.
Another item that you can add to your protection arsenal is mod_evasive. It is a module for Apache that provides evasive action in the event of an HTTP DoS or DDoS attack or brute-force attack.
The module tracks HTTP connections and verifies how many requests for a page are done within a given time frame. If the number of concurrent requests exceeds a specified threshold then the request is blocked. This blocking is done on an application level. The requester gets a forbidden answer to the request.
The configuration and setup (on Ubuntu) is fairly easy. The module is available as a package:
sudo apt-get install libapache2-mod-evasive
You then have to create the log directory. (Note: Make sure the directory is owned by the Web user; in most cases, this is www-data.)
sudo mkdir /var/log/mod_evasive
Then enable the module for the Apache Web server.
sudo a2enmod evasive
The default configuration file /etc/apache2/mods-available/evasive.conf will get you very far. You might want to add your management and proxy networks to the DOSWhitelist setting so that you do not block your own network. Also make sure you change DOSEmailNotify to a working email address, otherwise you won’t get notifications from mod_evasive.
If you’re not sure about the correct configuration options, test your setup with a Perl script that’s part of the installed package. The script performs a number of concurrent HTTP queries, which should trigger the module.
The third method for protecting your Web server is Fail2ban. Fail2ban scans log files and bans IPs that show malicious signs. It is most often used to block SSH knock attempts, but you can also use it to block repeated requests to your Web resources.
Fail2ban uses a list of regular expressions and checks these expressions against a set of log files. If there are matches that go beyond a certain threshold, then the source IP of the request is blocked. The IP is blocked on a network level.
Similar to mod_evasive, the installation on Ubuntu is easy.
sudo apt-get install fail2ban
After installing the package, you have to copy the default configuration file to a working configuration file.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Add your own management and proxy networks to ignoreip and set a proper destemail email address for block notifications. I also advise you to set usedns to no.
Fail2ban uses jails to describe services that have to be protected. By default, Fail2ban enables the SSH jail. If you don’t want this, then disable the SSH jail. You can then add this apache-ddos jail to hold the custom configuration settings for protecting your Web server. Note that you can use pattern matching in the logpath (e.g., /var/log/apache*/*access.log).
This will start a jail with the filter apache-ddos. The filters are defined in /etc/fail2ban/filter.d/. Add the file apache-ddos.conf to this location.
The above code will block IPs that do repeated request for HEAD or IPs that do repeated POST requests to xmlrpc.php. If you are not sure about the exact configuration or regular expressions, then have a look at the provided examples (e.g., apache-badbots, apache-noscript, etc).
The list of blocked IPs can be viewed if you list the active firewall rules (iptables -L -n). You can remove a blocked IP with:
fail2ban-client set apache-ddos unbanip 220.127.116.11
The fail2ban-client command is a useful command-line utility to get the status of the current jails, reload configuration, add individual IPs to the jail or stop and restart the service.
DDoS attacks are very hard to fight, especially if you are facing a volumetric attack. There are a couple of solutions for Apache Web servers that can limit the harm done by excess traffic and application attacks. Some of these, such as ModSecurity, will filter malicious traffic, whereas other solutions will block traffic on a network level (Fail2ban) or application level (mod_evasive).
The key to all this is having multiple lines of defense and adjusting the configuration of the different solutions to work together and provide an integrated solution.
Koen Van Impe is a security analyst who worked at the Belgian national
CSIRT and is now an independent security researcher.
He has a twitter feed (@cudes...