Foiling a DoS Attack
A recent denial-of-service attack became an opportunity to learn some things.
You're likely to find some of them interesting. A bit learned here could be crucial to alleviating a DoS attack you may experience in the future.
This DoS attack had these traits:
-
All requests were for one page at a specific URL.
-
About ⅓ to ½ of the requests were method GET. The rest were method POST.
-
The IP address of each request seemed to be unique. (IP addresses may have been spoofed or a bot net used.)
During the attack, the CPU usage on the server spiked and stayed there. The server became very slow. MySQL database connections failed.
Method GET vs Method POST
Method GET requests are the typical way a web page is requested. Data can be appended to the URL with a "?" character followed by the data.
The amount of data that can be sent to the server that way is generally about 1K, although some servers may allow up to 4K of GET request data.
Method POST, on the other hand, sends data to the server behind the scenes. It is used when lots of data needs to be sent. When you use a form, the submission is generally method POST, for instance.
The amount of data a server will accept with method POST is measured in megabytes, not in kilobytes. Limits depend on the server but generally are 8M or higher.
Method GET data is recorded in the server access logs. Method POST data is not.
It is assumed the method POST requests from the DoS operation contained huge amounts of data to slow the server down like it did.
The First Thing That Was Done to Foil the DoS Attack
Because the IP addresses seemed to be all over the place, IP blocking wasn't feasible.
Instead, the file name of the one web page being requested repeatedly was changed to make it unavailable.
The web page was not a critical one. Even if it were a critical page, it would have been a decision between removing that one page or having the entire site down.
When the web page was no longer available, the CPU usage dropped down to hover slightly above normal. The somewhat above normal usage seemed to be related to handling the huge number of 404 requests.
The Next Thing
It was assumed the POST requests were the ones that sucked up all the CPU.
To stave off that type of attack on other pages, certain directories on the server were set up to block all POST requests. It's done with the .htaccess file using these Apache rewrite rules.
# deny POST requests
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteRule .* - [F,L]
With the above, any browser or bot making a POST request gets a 403 Forbidden response.
(The code to block POST requests affects the directory where the .htaccess file is located and any of its subdirectories.)
Now, some publicly-accessible files needed to accept POST requests — form handling scripts, for instance. Those files needed to be exempted.
To exempt a file, a rewrite line is added to the above set of rewrite rules. The following exempts the FormHandling.php script:
# deny POST requests
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} !/FormHandling.php
RewriteRule .* - [F,L]
The exemption line is placed above the last line of the set, the line that begins with "RewriteRule".
To exempt other files, add a line for each. Example:
# deny POST requests
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} !/FormHandling.php
RewriteCond %{REQUEST_URI} !/another_page.php
RewriteCond %{REQUEST_URI} !/prices/data.php
RewriteRule .* - [F,L]
Entire subdirectories can be exempted by specifying the subdirectory name and omitting file names. This example adds the demonstrations subdirectory to the exemption list.
# deny POST requests
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} !/FormHandling.php
RewriteCond %{REQUEST_URI} !/another_page.php
RewriteCond %{REQUEST_URI} !/prices/data.php
RewriteCond %{REQUEST_URI} !/demonstrations
RewriteRule .* - [F,L]
For some domains it would be make sense to block POST requests at certain directories to automatically mitigate any future DoS attacks.
A Test
While the attack was going on, I decided to do a test to see how much CPU the method GET requests used.
POST requests had been blocked at this point.
The file of the web page under attack was renamed to make it publicly accessible.
Now, method GET requests were getting through. But method POST requests were not.
There seemed to be a slightly higher CPU usage when the page was made available as method GET and method POST blocked. Part of that, perhaps all of it, was the slight CPU cost of running the PHP code to repetitively produce the page under attack and responding with the page's HTML content.
The exact amount of difference is uncertain because there is software on the server that other pages launch when people are loading or interacting with them. And there are other domains on the same server, each with its own somewhat-unpredictable requests.
Because the CPU was only slightly higher, it validated my previous assumption that the POST requests were the ones sucking up the CPU.
(This article first appeared with an issue of the Possibilities newsletter.)
Will Bontrager
