Introduction.
One of the important things for a vendor to do in their cyber threat Intelligence program is to build a honeypot for each of their products, and Vercara is no different. Our UltraWAF honeypot setup helps us accomplish several goals:
- Identify authentic attacks without any false positives or affecting production user traffic. This drives product features and design.
- Train our Professional Services, Sales Engineering, Security Operations, and other internal groups. This helps us to build a better, smarter team.
- Determine best practices for configuring and augmenting a security policy based on attacker TTPs and threat observations. This helps us to set intelligent defaults to detect and block most behaviors “out of the box”. We use these defaults as the new policy for any customer site that we onboard, including our new corporate website that we rolled out in April.
- Feed our Cyber Threat Intelligence data lake.
Building Honeypot sites.
Building a WAF honeypot was relatively straightforward. We built a simple 5-page website, hosted it on a low-power cloud server instance and allowed access to it for the UltraWAF IP ranges. You can look at the website and see that it is not real. However, it has a handful of forms that are good targets for vulnerability scanners, scraper bots, and other automated programs to attack.
To get traffic going through UltraWAF, we then created 4 web proxy assets, each with a separate VIP address. A proxy asset consists of an automatically-assigned VIP address, one or more back-end IP addresses or Fully-Qualified Domain Names (FQDN is best practice), a set of front-end TCP service ports, and a corresponding TCP port on the back end. To get diversity of attacks across multiple services, we set up HTTP front ends for each asset on TCP ports 80, 443, 502, 8080, and 8443. We didn’t bother with TLS and setting up a certificate for TLS because that would expose the hostname in the certificate details, or it would generate errors because the certificate would mismatch the hostname.
Each proxy back-end hostname and TCP port combination must be unique. We wanted to use the same application server for all the assets, so we registered a domain and set up a wildcard record for it. We were then able to add descriptive hostnames into the asset settings and they all resolve to our honeypot webserver. For example, backend<number>-honeypot<TCP port>.<domain>.
My assets ended up looking like the following:
Honeypot DNS records.
We also wanted to collect a lot of random vulnerability scanning traffic. Over the last 6 months, our team has done a lot of research on DNS enumeration tools like dnsenum (https://github.com/fwaeytens/dnsenum). They all work in roughly the same way. Given a list of words that are typical hostnames like “www”, “smtp”, or “vpn”, the tool prepends those to the target domain, and tries to resolve that hostname with a DNS query. This also means that we can take some of our public domains, pick some of the unused words on a tool’s list, and add A records to capture all the vulnerability scanning against those domains. Most companies own a lot of extra domains for typo mistakes, country-specific domains, marketing campaigns, etc.
To catch domain scanners, we first set up 4 A records for a single hostname, one for each honeypot asset front-end VIP address. That set up round-robin DNS load balancing to take requests to one of my honeypot assets. My records ended up looking like this:
lb.mikeshoneypot.net. 300 IN A 156.154.XXX.XXX
lb.mikeshoneypot.net. 300 IN A 156.154.XXX.XXX
lb.mikeshoneypot.net. 300 IN A 156.154.XXX.XXX
lb.mikeshoneypot.net. 300 IN A 156.154.XXX.XXX
Then we took a handful of unique words from each tool’s word list and made a CNAME record to our load balancer hostname.
admin.targethoneypotdomain.net. 300 IN CNAME lb.mikeshoneypot.net.
vpn.targethoneypotdomain.net. 300 IN CNAME lb.mikeshoneypot.net.
For some of our unused domains, we set up wildcard records.
*.unusedhoneypotdomain.net. 300 IN CNAME lb.mikeshoneypot.net.
We also registered accounts with several public dynamic DNS providers such as DuckDNS (https://www.duckdns.org/) that allow you to set up zone records on domains that they own. We set up hostnames using either the load-balancer CNAME or individual A records using a random VIP address from our honeypot assets.
Building a WAF policy.
We were then ready to build a WAF policy. To do this, we turned on almost every countermeasure available but in log-only mode. This means that a single HTTP request can very easily trigger multiple violations because no violations are being blocked. For example, a SQL Injection violation in conjunction with a Cross-Site Request Forgery violation is incredibly common.
We also added Relaxation Rules to match the standard default policy that we deploy for customers. This removes most of the expected false positives.
We enabled Signatures for Log4Shell and Shellshock exploits and for any Common Vulnerabilities and Exposures (CVE) released in 2023. And as you might have guessed, all of these are in log-only mode.
Adding Bot management.
Similarly, we set up a set up a Bot Management policy in log-only mode and enabled a small set of countermeasures.
We enabled a Bot Trap on the index page. This adds hidden links to the page and detects bots that follow them.
We also enabled IP reputation for Botnets, Denial of Service, Proxies, and Vulnerability Scanners.
We set up a sitewide rate control to log a violation for any endpoint that sent 60 HTTP requests in 10000 milliseconds (10 seconds).
Catching Traffic
As soon as we created the honeypot assets, they started to receive attack traffic. As anybody inside Security Operations knows, there are vulnerability scanner farms that are constantly scanning every IP address on the Internet, and it doesn’t take long for them to find new services and websites.
After collecting more than 90 days’ worth of attack traffic, you can see that we received around 40,000 web attacks on our honeypot infrastructure. That’s almost 450 violations per day. And as we add more domain entries over time, that traffic will increase.
It is also not a surprise that most of the attack traffic is coming from sources in the US, Russia, India, and China.
Honeypots: A Valuable Tool
As a vendor, we remain a firm believer in running honeypots because of the practical information that it gives us about our tools and attacks that we receive. It also helps us to train our technology staff on how to analyze WAF violations. In a future blog post, we’ll discuss some of the attacks and attackers that we have seen.
Ready to enhance your protection against attacks and create your own WAF honeypot? Discover how Vercara’s UltraWAF solution can help protect your web applications.
