I was in a forum thread with Loebas last week, who implied that webhosts might routinely firewall (e.g. via Fail2ban) IP addresses that engage in port-scanning against them. While Loebas is technically right that such a thing that can technically be done by an adaptive firewall (here's an example for Fail2ban) or e.g. in response to a honeypot hit, I'd argue that it's not a widespread practice... because this approach to security can easily do more harm than good.
Blocking based on port-scanning being "bad behaviour" is exceptionally rare amongst hosting companies because it can be exploited as a denial-of-service attack against a site's legitimate users!
But rather than ask you to take my word on it, I figured I'd demonstrate:
Protecting Bob's favourite website
By way of example, let's imagine Alice is attempting to lock Bob out of Bob's favourite website.
Bob's favourite website operates Fail2ban in a port-scanning detection mode. Performing a port-scan against the server results in an IP-ban. To make testing easier, I'll have the ban expire after 60 seconds rather than making it indefinite (which Loebas's example implied):
Here's how the setup looks:
- Bob's favourite website is hosted at
http://bobs-favourite.test/andhttps://bobs-favourite.test/.3 - The server runs
fail2ban, configured to attempt to detect port-scanning and block any IP address that engages in it. - It does this by checking for any 10 TCP connection attempts within 10 minutes to ports other than HTTP (80) and HTTPS (443).
- Alice's goal is to prevent Bob from being able to access his favourite website.
Alice's attack
After scoping out the mechanism by which the firewall works, which is easy enough with a copy of nmap and a VPN, Alice comes up with a plan.
She intends to prevent Bob from accessing his favourite website by tricking Bob's computer into looking like it's performing a port-scan!
This is pretty easy, so long as Alice can persuade, coerce or trick Bob into visiting a particular web page.4 The attack web page contains code like this:
<p>This is Alice's "Totally Innocent" Webpage</p> <img src="//bobs-favourite.test:3000/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3001/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3002/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3003/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3004/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3005/" width="1" height="1" alt=""> <img src="//bobs-favourite.test:3006/" width="1" height="1" alt=""> <!-- ...and so on... -->
When Bob visits that page, in order to try to display those images, it'll connect to the server running Bob's favourite website on a series of consecutive TCP ports, 3000 onwards. Superficially, this is indistinguishable from a port-scanner running through those ports.5
Here, I'll show you. In the video below you'll see that Bob can visit his favourite website as much as he likes... up until the moment he visits Alice's page, at which point his IP is added to its firewall and he's banned:
What's the lesson?
Fail2ban is great. There are many excellent ways to use it. Triggering it on repeated failed authentication attempts (whether to your web application or elsewhere, e.g. SSH) is a fantastic idea, as are other kinds of bad behaviour.
But triggering a firewall ban from a HTTP honeypot needs to be done with great care, especially if the honeypot can be trivially hit using GET requests from third-party domains. And certainly long-duration bans should require human attention somewhere along the way.
And that logic is why, I argue to Loebase, most webhosts don't have the kinds of dynamic firewall rules that I've demonstrated here. It's just too dangerous to have this trifecta of (a) automatic rule application, (b) long-duration bans, and (c) hairpin honeypot triggers. Their potential for abuse can make them as capable of harm as much as they are for good! Take care out there.
Footnotes
1 I don't know if the forum's honeypot blocks are automated - it sounds like they're not - but if they were then it, too would be vulnerable to a DoS attack impacting legitimate users: an attacker would simply need to trick the victim's browser into hitting a set of honeypot URLs in a mechanism similar to that described for port scans in this page.
2 These hidden traps, by the way, are 100% vulnerable to the same kind of denial-of-service attack I go on to describe below; in fact, I've even made a proof-of-concept that I'll be sharing with Loebas: a web page that, if you just look at it, gets you instantaneously permabanned from one of Loebas's websites! Honeypot links that depend on IP addresses probably ought to embed a tamper-evident copy or salted hash of the IP they were issued to so that they can't be extracted and passed-on to an unwitting victim, that's all I'm sayin'!
3 Don't try to visit those sites; they only exist on my computer. And they're not very interesting. But I've provided the source code you'd need to set up Bob's Favourite Website and Alice's "Totally Innocent" Website for yourself if you'd want to.
4 She's got a page of her own that she'll use, but she might equally try to embed the payload onto a forum post or other site that she thinks Bob might visit. A forum could easily be the vector for this kind of attack: anywhere she can load her own HTML, or JavaScript, or even CSS and reliably have its resources downloaded would suffice.
5 Thinking Bob's browser won't fall for this? You're
wrong! There are some limitations to what Bob's browser can be tricked into doing: it usually won't connect to any of a
list of specific TCP ports, for example. If you were thinking "CORS would prevent this", you'd be mistaken: hotlinking images doesn't require a preflight check, but even if it
did: the requisite OPTIONS request would, in itself, look like port-scanning!
6 Don't forget, Alice's "page" only has to be something that can embed remote URLs. It could be a CSS stylesheet. It could be an SVG image. For a sensitive-enough honeypot that triggers on a single engagement, it could even be a hyperlink, redirect, or QR code!
0 comments