Blocking Malicious Bots with IIS
In this post I'll show you how to block most malicious bots from hitting your Sitecore site with one simple IIS configuration change (hackers hate it!).
I'm a bit of a vigilante when it comes to crime, hackers, malicious bots, scams, and spam. The words of Vincent Vega from Pulp Fiction forever echo in my head:
I wish I could have caught him doin' it. I'd have given anything to catch that ***hole. It'd been worth him doing it just so I could've caught him doing it.
Professionally, I've also had the privilege (or curse) of having regularly observed bot behavior for years.
Every Sitecore site is constantly being scanned by bots. Launching a new Sitecore site? Prepare for an onslaught of bots scanning for WordPress and PHP vulnerabilities, causing noise in the Sitecore logs. I've seen this happen on every single Sitecore site I've launched. It's a rite of passage. And surprisingly, Sitecore sites are STILL being launched that are not guarded by a WAF. Even with a WAF, there is a chance that bots will hit your server if you have any public endpoints that aren't secured.
Why Even Try Blocking Bots?
Aside from the obvious security benefits, there are a handful of reasons:
- Reduce server load
- Improve performance (exception handling is expensive)
- Reduce log noise (and make it easier to find real issues)
- Reduce the risk of hitting your Application Insights log quota (if using Azure)
- Free the bots up to scan other sites (wait...)
The common error messages you're going to see are:
Potentially dangerous request. Request.Path value was detected from the client
Server cannot set status after HTTP headers have been sent
A potentially dangerous Request.RawUrl value was detected from the client
The required anti-forgery cookie "__RequestVerificationToken" is not present.
Legitimate users can still trigger these errors, but if you're seeing a lot of them, it's probably bots.
The IIS Config Change
The vast majority of malicious bots can be blocked with a simple modification to your IIS configuration. We are going to apply the change server-wide, meaning that all sites will be affected by this. Before you make this change, you should review your logs to see if there are any legitimate requests in your specific use case(s) that could be blocked by this change.
We will use the IIS URL Rewrite Module to abort requests containing paths or query strings that are known to be malicious. The list of paths and query strings is not exhaustive, but it's a good start.
The file to modify is:
Note that saving the file will cause IIS to restart, so you may want to do this during a maintenance window.
Instead of returning 403s or 404s, abort the request. Doing so returns the least amount of information possible as to why the request wasn't processed successfully. GHOST those bots! It will also prevent bot traffic from hitting your custom 404 page, which can keep analytics numbers more accurate.
The config changes can also be viewed in the IIS Manager:
If you don't have a WAF, get one. Otherwise, here are some more untested ideas from my friend ChadGBD:
Have a good day (unless you're a hacker) and keep slapping those bots.