The only surefire way to effectively protect against a Denial of Service attack is to cancel or suspend the service, which is the very purpose of the attack. You remain vulnerable simply by trying to continue providing service to your customers or business associates.
Are you completely helpless, though? No. There are several ways to help protect against a DDoS attack and mitigate—with varying degrees of efficacy—the effects of an attack once it takes place.
The most typical victims of DDoS attacks are websites and by extension, the web and system admins to whom we present these potentially crucial tips when trying to bring a service back to normal in a very short time. You may have to perform these tips all while having your boss on the line, your coworkers pointing fingers, and your customers impatiently pressing the refresh button, so let’s see what can be done, shall we?
Distributed Denial of Service is simply the overloading of a service with requests, rendering the service incapable of responding to legitimate requests in time or at all.
This attack is typically activated through a botnet (zombie army) of hundreds or even thousands of compromised computers flooding the target service with malicious transmissions. The attacker orchestrates and puppeteers the handlers that then use compromised computers to carry out the attack.
There are several types of DDoS attacks; here, we will focus on the most common and—arguably—the most effective ones.
The examples below assume an Apache web server running on AWS infrastructure; AWS ELB and Ubuntu EC2.
Detecting a DDoS ^
- Web server fails to respond to HTTP requests; website has very slow response¸ or none at all.
- Access logs quickly fill up, with several hundred or thousand IPs flooding the logs with HTTP GET or POST requests.
- Number of connections spike in AWS ELB monitors.
- netstat -s on servers show a significant flood of packets (check for SYN large increments—this could indicate a SYN flood).
SYN Flood ^
In the TCP/IP protocol, a three-way handshake takes place as a connection to a service is established. First, a SYN packet from the client is responded to by the service with a SYN-ACK. The client then responds to that SYN-ACK; this is considered to be when a connection is established.
A SYN flood attack is when the client does not respond to the service's SYN-ACK and continues to send SYN packets, thereby tying up the service until the handshake times out. The source address of the client is typically forged, and as long as the SYN packets are sent faster than the timeout rate of the service host's TCP stack, the service will be unable to establish any new connections.
Prevent a SYN Flood ^
- Enable SYN cookies
Append this line to the end of /etc/sysctl.conf, apply changes with command:1sysctl -p ipv4.tcp_syncookies = 1
- Restrict SYN retries
Append this line to the end of /etc/sysctl.conf, apply changes with command:1sysctl -p ipv4.tcp_synack_retries = 3
- Reduce SYN timeout
Append this line to the end of /etc/sysctl.conf, apply changes with command:1sysctl -p ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45
ICMP Flood (Nuke/Ping of Death):
In an ICMP flood, the target receives a large ICMP ping in fragments and starts reassembling the packet. However, due to the size of the packet once it is reassembled, it is too big for the buffer and causes an overflow. This attack yields unpredictable results, such as reboots or system freezes.
Most systems do not allow for ICMP communications, but those that do allow it, for either health check purposes or simply by merit of sloppy security design, could suffer serious disruptions.
Prevent ICMP Floods ^
Block ICMP on your AWS access list on the AWS CLI:
aws ec2 create-network-acl-entry --network-acl-id acl-5fb85d36 --ingress --rule-number 100 --protocol icmp --cidr-block 0.0.0.0/0 --rule-action deny
Web server application-level attacks ^
These attacks are legitimate POST/GET requests in excessive numbers, typically with content-lengths field and a very slow data transfer rate. The aim of such requests is to hog your server resources and render your Apache web server incapable of serving legitimate traffic.
Prevent web-server application level attacks ^
If your website serves a customer base that is predominantly European, for example, go immediately to your R53 dashboard, choose your hosted zone, and navigate to your website’s record set. Change Routing Policy to Geolocation and restrict it to Europe.
As DDoS attacks are staged from thousands of compromised computers around the world, this simple change may limit the attack’s scale by 70% or more.
- Open your terminal window.
- Issue the command sudo apt-get -y install libapache2-mod-evasive.
- Issue the command sudo mkdir -p /var/log/apache2/evasive.
- Issue the command sudo chown -R www-data:root /var/log/apache2/evasive.
- Open the /etc/apache2/mods-available/mod_evasive.conf file (using sudo and your favorite text editor) and append the following to the bottom of that file (this is one configuration per line):123456789101112DOSHashTableSize 2048# maximum number of requests for the same pageDOSPageCount 20# total number of requests for any object by the same client IP on the same listenerDOSSiteCount 300# interval for the page count thresholdDOSPageInterval 1.0# interval for the site count thresholdDOSSiteInterval 1.0# time for which a client IP will be blockedDOSBlockingPeriod 10.0DOSLogDir "/var/lock/mod_evasive"
- Save the file and restart Apache.
While potential DDoS attacks and prevention mechanisms are numerous, the above serves as a quick guide for the most common attacks. Several services that help mitigate against DDoS attacks will also be reviewed in the near future.