How Tractive Defends Against Vulnerability Scanners and Bots in a Cloud-Based Environment
Honeypots – You may already know about this cyber security concept. If not, you are probably thinking about a pot full of sweet honey, the kind you might eat for breakfast. And while the kind of honeypots we’re talking about are not actually linked to beekeeping or your grandma’s favorite sweetener, the underlying concept is easily explained with this metaphor.
What are honeypots?
A honeypot is a resource whose value lies in being attacked or compromised. The resource can be routers, endpoints or even entire services. However, these resources do not offer any functional value to the respective production system but behave like a regular part of it. Which means that every time the honeypot gets accessed, there is quite a high chance that the request is a scan or even an attack – as no regular visitors would access it. The resource itself is chosen in such a way that it acts as a very attractive target for attackers. This is where the honey metaphor comes in. Like the taste and smell of honey which attracts certain animals and people, the honeypot acts as a tempting target for attackers and scanners.
The goal of a honeypot is to get scanners to interact with it, which allows the honeypot resource to extract certain information about the attackers like their origin, attack patterns or their overall intentions.
Why do we use a honeypot?
Our applications are often scanned by various bots and vulnerability scanners in order to identify potential vulnerabilities. Those scans usually generate a high amount of HTTP errors within our logs. Every large scan requires a developer to manually investigate the root cause for the increased amount of errors and block the respective scanner IP address. This causes inconvenience especially on weekends, public holidays and at night. Therefore the honeypot works as an automatic service which replaces the manual work in the first place.
Strengths and weaknesses
Usually we differentiate between two types of attackers: Script Kiddies and Blackhats. Script Kiddies try to scan a lot of applications with as little effort as possible. Therefore they usually use automated scripts and scanners which are not directed towards a specific company or application. Blackhats however tend to be way more skilled and target a specific website. For our honeypot this means that it doesn’t add any additional protection against Blackhats or dedicated Script Kiddies, because it is rather easy to bypass the trap endpoints by using a VPN. Nevertheless it stops basic scans from Script Kiddies especially if they are not eager to scan our applications specifically.
One of the main strengths of the honeypot is the low level of complexity. The setup could easily be integrated into the existing cloud infrastructure.
How do we use it within our cloud infrastructure?
At Tractive we use the excellent services and infrastructure provided by Amazon Web Services (AWS) in order to host our web applications. Every request that is sent to a Tractive web application is checked by AWS WAF (Web Application Firewall), which controls the access to the applications by using specified rules. The honeypot adds a rule that manages blocked IP addresses. Each IP address which gets added to this list is no longer allowed to access Tractive web applications and receives a 403 Forbidden Error instead of the requested resource.
In order to set up the Honeypot, a Lambda function must be created, which extracts the IP address of the attacker and adds the address to the rule for blocked addresses defined in AWS WAF. Our entire traffic gets routed through AWS CloudFront which works as a CDN. In order to access requested files via CloudFront, it is necessary to create so-called origins. An origin is responsible for linking CloudFront to an S3 bucket. In contrast to an actual S3 bucket, the honeypot origin links to a self-defined endpoint which only returns a blank page. In order to lure scanners into accessing this page, we use various trap endpoints which link to the honeypot origin. Those redirects are done by CloudFront behaviors which need to be created for every trap endpoint. Every time one of the trap endpoints gets called the Lambda function gets triggered.
As shown in the image above the Lambda function also sends a message to a slack channel whenever an IP address gets blocked. This helps us to keep track of the amount of blocked addresses in WAF.
At Tractive we use AWS cloud services to create various honeypot endpoints which protect us from scanners and bots. Additionally we monitor our cloud infrastructure closely in order to keep track of any suspicious activities.
In case our cloud infrastructure excites you, check out our open software engineering positions.
Author: Andreas Pilgerstorfer