Honeypotting is an art form and there are many different types of honeypots an organization can create. Regardless of the type of honeypot, they are designed to give bad actors a target within a controlled environment so that we can better understand their tactics and improve our own security. There should never be legitimate users accessing the honeypot, instead they lay dormant until a bad actor stumbles on it typically when performing a scan.
Honeypots should not be linked or accessible via a users normal flow. It’s with this basic understanding that we’ve built a new feature for all websites – the ability to create your own virtual honeypot. Via this method we can more easily identify bad actors, or suspected bad actors, and immediately apply defensive controls against the offending user.
Read more to understand what and how this works.
Creating a Web Honeypot
Most web attacks are automated through the use of scanning tools, they scan existing and non-existing URLs alike. Examples of known directories and files might be something like /administrator (for Joomla!) and /wp-admin (for WordPress). Both other common ones includes things like /cgi-bin/, timthumb and slew of other examples. Positive responses to these queries gives the bad actor the insights they require to determine how to best attack the web property. These directories, files, and pages (i.e., URLs) are typically susceptible vectors bad actors can abuse.
Understanding this tactic / technique presents an opportunity to introduce the idea of Honeypots. With honeypots we can create rules that allow us to identify what a real user should never access then use anything that triggers that rule with specific actions (e.g., block access to the site).
For instance, consider a website that is not built on WordPress, Joomla!, Drupal or any of the many known CMS applications. Seeing requests to URL’s that exist only with those known applications is a great indicator that someone is trying to fingerprint your site, in the process giving them insights into what may or may not exist and what could be exploited. This is where ideas like Honeypots can be extremely helpful in helping website owners get proactive with their defenses.
Creating Honeypots with NOC
At NOC you can now create a simple honeypot rules to stop these type of scans by bad actors. This is specifically available via our API and open to all customers. Via this feature you can create rules that identify what a real user should never have access to.
On a side note, our Custom Rules have a number of other options available as well:
| Rule | Description |
|---|---|
| Max Requests | Specifies the maximum allow of requests per IP per minute to that URL. Default to 50 if value is not specified. |
| Redirect To | Specifies a 301 redirection page for the specified URL. |
| Country Block | Specifies a set of countries to block to the provided URL (use / to block to the whole site). |
This article, however, we will focus on the honeypot specifically.
| Rule | Description |
|---|---|
| Honeypot | Useful to create a honeypot of URLs that should never be visited. Any IP that visits it will be blocked for the time specified (default to 600 seconds). |
Honeypot Example with NOC
Let’s say you have a non-WordPress site, you could create a honeypot that focuses on WordPress specific queries like: /xmlrpc, /wp-login, /wp-admin, /wp-includes, etc… You’re building a ruleset that says no user should ever be querying WP specific content on my site.
Using the NOC custom rules you’d create the rule like this:
$ curl -D - https://my.noc.org/api?apikey=YOURAPIKEY&action=cdn/customrules/add&website=YOURSITE&rule_type=honeypot&url=/administrator /xmlrpc /wp-login&value=3600With this rule, Any IP that visits one of these URL strings will automatically be blocked via our WAF for 1 hour. This will render any additional scans useless, stopping their reconnaissance of your web property reducing the likelihood, and risk, of someone identifying a weakness in your asset.
Going Stealth Mode with Honeypots
Another option you can do is make your honeypot stealthy.
For example, in the API you can specify the block response. By default it will throw a 403 (forbidden) explaining the block. However, for a honeypot, you might want to hide that information.
To do that, you can run the same command, but add a “block_response” option. You can make it stealthy_404 (a generic 404 error), stealthy_503 (to act like a server error) and a few other options. In our case, we can do a stealthy_404:
$ curl -D - https://my.noc.org/api?apikey=YOURAPIKEY&action=cdn/customrules/add&website=YOURSITE&rule_type=honeypot&url=/administrator /xmlrpc /wp-login&value=3600&block_response=stealthy_404In this example the stealthy_404 would tell the user the page is not found, allowing them to continue to try and never knowing they have been blocked. 🙂
Honeypots Are Extremely Effective Security Controls
While Honeypots have been around for a long time, you don’t often see them in the world of website security. They should be though, they allow the creation of controlled, safe environments that help us keep a pulse on the latest TTP’s being employed by bad actors.
Here at NOC we’ve been using them for years to build our research at Sucuri and GoDaddy and now we’re releasing it publicly for everyone to enjoy and take a more proactive approach to the continuous barrage of scans they get to their websites.