Testing BitNinja - an out-of-the-box solution for server and site security. Here’s who and what is getting attacked, and from where

BitNinja is an analog of Dr.Web or Immunify, but unlike them, in addition to catching viruses, it also specializes in filtering incoming traffic. Its antivirus is powered by AI, and you can manage the security of all your servers from a single window. 

We’ve divided BitNinja testing into three phases.

1. Passive - simply putting BitNinja on servers with different configurations and seeing what kinds of activity it responds to.

2. Active - relying on the vendor's public documentation, we test it through simulated attacks. 

3. Close to reality - some real code is placed behind BitNinja, which pen-testers try to crack.

In this article, we will describe the results of our passive testing. From it, we developed several hypotheses:

• Even a bare-metal server can come under attack.
• WordPress attracts more attacks than Drupal.
• Sometimes, attacks are carried out across an ISP's entire network, without the goal of taking over any particular server.
• Requests communicating with server ports are most commonly attacked and blocked.

Infrastructure for passively testing BitNinja

For passive testing, we used 3 servers with 2 cores, 4 GB RAM, a 60 GB hard disk, and various operating systems: Debian 11, Ubuntu 22, and AlmaLinux 8. The user on the server in all cases was the same, root. All servers are located in the same cluster and at the same hosting provider within Russia.

Software on the server:

• Ispmanager lite with the recommended software;
• BitNinja, installed as a stand-alone version;
• WordPress on Ubuntu 22 and Debian 11 (hereafter WPU and WPD);
• Drupal on AlmaLinux 8 (hereafter DA).

We did not create sites in the CMS - these are just bare CMS files, without even domains. We will set the domains and create the sites later. Let's see how the situation changes.

With similar inputs in terms of software and specifications, we expected the same results in terms of attacker activity. But we were wrong.

BitNinja settings

The main goal of the test is to check how many attacks BitNinja will catch with minimal configuration. Therefore, no significant changes were made. Only that WAF was enabled for DA and WPD without any changes to its rules.

Since all the CMSs used MySQL as a database, you could also enable Database Cleaner, which checks the databases for infections. But we haven’t done it yet =)

Read more about our BitNinja appliance on the ispmanager blog →

Status of the BitNinja modules

Results of passively testing BitNinja

Summary 

Period 17.08 - 29.10

• 82,000 incidents recorded;
• 81,000 blocked attempts to "open" ports;
• 30 blocked connections with WAF;
• 0 viruses found;
• 13 DoS attacks recorded;
• 17 Suspicious logs analyzed;
• Very many blocked packets. The graph below shows how many thousands of packets were blocked.

The results show that there are a lot of parsers and bots out there on the Internet, probing resources in search of vulnerabilities. There is absolutely nothing on the servers, but they are being probed with considerable regularity in search of gaps. Even a few DoS attacks have taken place.

The infographic above highlights that the ports felt the brunt of the impact. Some of the incidents were caused by captchas, mainly web captchas. The rest are within the margin of error.

Most likely, when content gets added to the resources, bots will start sending requests and trying to break through the admin and site forms. Then we will see an increase in blocking from WAFs. We will find out whether this is accurate after three months with the help of domains now bound to the servers and dummy sites with forms on them.

Country breakdown:

• China by a very wide margin.
• U.S.A.
• RF.

The countries from which attacks come will differ depending on where the server is located. Our test VPS is located in Moscow.

Results for individual servers

The hypothesis was that the volume of attacks would be evenly distributed among the servers. This turned out to be wrong. WPU suffered the most attacks, followed by WPD, and finally DA.

Our new hypothesis is that WordPress was the cause of this discrepancy. 

WordPress has tons of plugins, not all of them are safe and it's the world's most popular CMS; it accounts for the largest number of websites in the world. Even the servers with bare WordPress without any content or sites attract more attention from bots than the server with Drupal. 

The difference between WPD and WPU is that WPD is running WAF, but whether this could be the reason for such a significant difference in the number of attacks we can't yet say. What confused us was that WAF blocked very few requests. But maybe the bots somehow detect it and don't even try to continue making requests. If you know anything about this, please share in our LinkedIn community →

Port Honeypot

No seasonality or similar patterns were detected. The servers were attacked randomly, with no obvious logic. There were strangely similar fluctuations for DA, but they only happened once. That's not enough to draw any conclusions.

DoS Detection

Only the WPU server was hit by DoS attacks, maybe because WAF is enabled on the other servers.

WAF

The total number of attacks on DA was less than the other servers, but WAF experienced more connections. But there were few requests so this was probably a fluke. The graphs overlap with each other, which again shows that some bots conduct attacks across all ISP networks.

Blocked packets

A packet is a unit of measurement for the traffic that is generated by an IP address. Each incident or request can contain a different number of packets, depending on the size of the request. For BitNinja, we are talking about HTTPS packets.

For some reason, DA had more days with attacks than the other servers even though WPU got the most, as with the blocked connections to the ports.

What's next

Several hypotheses were generated from the three months of attack testing:

• Even a bare-metal server can come under attack.
• WordPress attracts more attention from attackers than Drupal.
• Sometimes attacks are carried out across an ISP's entire network, without the goal of taking over any particular server.
• Requests communicating with server ports are the most attacked and blocked.

We plan to add domains to the servers, launch sites with forms on them, and see how the attacker activity changes. At the same time, we will conduct the second phase - active testing as per the vendor's documentation.

We will record a video or stream the results of the second and third phases of testing when we finish them. If you like, subscribe to our Linkedin, we will post our progress there →

Try BitNinja