90 days tested BitNinja - a boxed solution for server and website protection. We tell who, where and what attacks

When we first started providing BitNinja, the reasonable idea arose that it would be good to test it ourselves.

We divided the testing of BitNinja into three phases.

1. Passive — we simply place BitNinja on servers with different configurations and see what activities it reacts to.

2. Active — we follow the vendor's public documentation and test using attack simulations.

Important. In Russia, simulating an attack on a server is equated to cybercrime. Therefore, if you work from the Russian Federation and/or the test VPS are located in the Russian Federation, do not simulate attacks on servers with white IPs. This is a criminal offense. You can test the product in this way only in a gray network and only after notifying the hoster. If you work from another country and/or the test VPS are located in another country, study the local legislation on this issue.

3. Close to reality, — some real code is placed behind BitNinja, which pentesters try to hack.

In this article, I will talk about the results of passive testing. Based on its results, I generated several hypotheses:

✓ Even an empty server is subject to attacks.

✓ WordPress attracts more attention from attackers than Drupal.

✓ Sometimes attacks occur across the entire provider's network, without the goal of capturing a specific server.

✓ Most attacks and blocks are related to requests interacting with server ports.

Here are the details.

Infrastructure for passive testing of BitNinja

We took 3 servers with 2 cores, 4 GB RAM, and 60 GB hard disk and different operating systems: Debian 11, Ubuntu 22, and AlmaLinux 8. The user on the server in all cases was one — root. All servers are in one cluster and with one hosting provider, located in the Russian Federation.

Software on the server:

• Ispmanager lite with recommended software;

• BitNinja, installed as a stand-alone version;

• WordPress on Ubuntu 22 and Debian 11 (hereinafter WPU and WPD);

• Drupal on AlmaLinux 8 (hereinafter DA).

Sites on CMS were not created - these are just bare CMS files, even without domains. In November, we will assign domains and create sites. Let's see how the situation changes.

With similar input from the software and technical specifications, we expected the same result in terms of attacker activity. But we were wrong.

BitNinja Settings

The main task of the test is to check how many attacks BitNinja will catch with minimal settings. Therefore, there were no significant changes. The only thing is that WAF was enabled for DA and WPD, without any changes to the rules.

Since MySQL was used as the database for all CMS, Database Cleaner could also be enabled - the module checks databases for infection. But at the moment it was forgotten.

More about BitNinja in the ispmanager blog →

BitNinja Passive Testing Results

Summary
Period 17.08 - 29.10 (will update at the end of October)

• Incidents recorded — 82 thousand;

• Blocked port scanning attempts — 81 thousand;

• Connections blocked by WAF — 30;

• Viruses found — 0;

• DoS attacks recorded — 13;

• Suspicious logs analyzed — 17;

• Packets blocked. Many. The graph shows values in thousands of blocked packets.

The summary shows that there are many parsers and bots roaming the internet, probing resources for vulnerabilities. There is absolutely nothing on the servers, yet they are regularly hammered in search of holes. Even a few DoS attacks have occurred.

The summary infographic clearly shows that the main impact was on ports, some incidents were caused by captchas, the most significant among them being web captcha. The rest are within the margin of error.

Most likely, when content appears on the resources, bots will start sending requests and trying to break into forms in the admin panel or forms on the site. Then we will see an increase in WAF blocks. Whether this is the case or not, we will check over the next three months — on November 1, we linked domains to the servers and created site templates with forms on them.

The country breakdown is also not what I expected. Yes, there is India and Taiwan, but.

1. China — by a very large margin.

2. USA.

3. Russia.

I am sure that the countries from which attacks come will differ depending on where the server is located. Our test VPS are located in Moscow.

Results for individual servers

My hypothesis was that the volume of attacks would be evenly distributed among the servers. But no, I was wrong. Most of the attacks were on WPU, then WPD, and finally DA.

My new hypothesis is that the reason for this behavior was WordPress.

WordPress has a lot of modules, not all of them are safe, and it is the most popular CMS in the world — WordPress has the largest number of websites in the world. Even servers with bare WordPress without any content or sites attract more attention from bots than a server with Drupal.

The difference between WPD and WPU is that WPD has a WAF, but whether this could be the reason for such a significant difference in the number of attacks — I can't say right now. It is puzzling that the WAF itself blocked very few requests. But maybe the bots somehow detect it and don't even try to continue the requests. If you know — please tell me.

Port Honeypot

No seasonality or identical patterns were found. The servers were attacked chaotically, without obvious logic. There were strangely similar fluctuations for DA, but they only repeated once. This is not enough to draw any conclusions.

DoS Detection

Only the WPU server was subjected to DoS attacks. WAF is enabled on the others, maybe that's the reason.

WAF

The total number of attacks on DA was less than on other servers, but WAF reflected more connections. But there are few requests, so this is probably a coincidence.

The graph partially coincides, which again shows that some attacks are carried out by bots across all provider networks.

Blocked packets

Packets are a unit of traffic generated by an IP address. Each incident or request may contain a different number of packets, depending on the size of the request. In BitNinja terminology, it is HTTPS packets.

For some reason, the number of days with attacks on DA was more than on other servers. Even though the peak went to WPU. Just like in the case of blocked port connections.

What's next

From the results of our attack testing over three months, I generated several hypotheses:

✓ Even an empty server is subject to attacks.

✓ WordPress attracts more attention from attackers than Drupal.

✓ Sometimes attacks occur across the entire provider's network, without aiming to capture a specific server.

✓ Most attacks and blocks are related to requests interacting with server ports.

We plan to attach domains to the servers, set up websites with forms on them, and see how the activity of attackers changes. In parallel, we will conduct the second phase — active testing according to the vendor's documentation.