Home » Blog
date 16.Feb.2020

■ Block certain IP addresses from accessing file downloads using .htaccess


Imagine you own a shop, and all of a sudden a flash mob of 1000 people shows up at the door, and start loitering in the aisles without buying anything, preventing real customers from buying your produce. This type of website-coronavirus is quite easy to orchestrate electronically, where you send a number of your own (or p0wned) PCs to visit a website and request large files continuously, without any intent of business. This is known as a Distributed Denial Of Service (DDOS) attack, and happened to us here at zabkat.com recently.

Why would anyone want to launch a DDOS at a small outfit like zabkat is beyond me, but they actually did, and the daily download bandwidth use shot up from 2 to 300GB/day! They probably thought that I pay for bandwidth by the gigabyte, and considered putting a hole in my bank account as their amusement. Some disgruntled customer? A competitor? Who knows? Everybody knows xplorer² is easily pirated, so why the extra pain?

Never mind the rhetoric questions though, I had to put a stop to this attack or risk eviction by my webhost. These hacker chaps used a simple method of downloading all 4 xplorer² installers every 10 seconds, from a number of IP addresses (mostly in France and Russia, go figure). Thankfully they were small time, so the IP addresses were only 10 or so. There were 2 options to consider:

For websites hosted on Linux (Apache server) one controls access using a hidden file called .htaccess. Stopping direct downloads for everyone requires a block as such (also used for blocking image hotlinking)

# no direct downloads
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?zabkat.com [NC]
RewriteRule \.(zip|exe|7z)$ - [NC,F,L]

This means that if a large file with extensions zip/exe/7z is accessed directly by URL (e.g. http://zabkat.com/installer.exe), without going through the website download buttons, it should be denied access. The problem with HTTP_REFERER is that it is easily spoofed by hackers, and missing from some privacy-conscious legitimate customers (e.g. wiped out by your firewall or AV). So this method wouldn't stop the determined hacker and would hurt some of the paying customers. Not good.

So I went for plan #2, to block the attackers IP addresses from accessing the installer download folder. The website access logs have rich information that I normally view with AWStats, but this time it sufficed to load the logs in Excel and sort by IP address to see those that were abusing the system. A typical log line looks like this:

163.172.55.0 - - [10/Feb/2020:18:21:28 +0100] "GET /xplorer2_setup64.exe HTTP/1.1" 200 2581152 zabkat.com "-"
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36" "-"
So the IP address that needs blocking is 163.172.55.0 ... or is it? It turns out that my webhost in a GDPR-related lunacy, anonymize the log IP addresses masking the last digit of the IP (.0 is not the real number of the attacker). So I blocked the entire range of IP addresses as such:

# .htaccess for downloads folder, blocking IPs
order deny,allow
Deny from 163.172.55. 185.9.186. 213.111.

Once this was in place, instead of large file downloads, our hackers are served with 403/404 error pages, which again consume some bandwidth but not as bad as originally. This DDOS episode is over, whatever next now? Our small-time "friends" may move to different IP addresses and continue this cat and mouse game, but really guys, what's the deal? If you have a problem with xplorer² just write to me about it. Otherwise you're just being silly <g>

Post a comment on this topic »

Share |

©2002-2020 ZABKAT LTD, all rights reserved | Privacy policy | Sitemap