Using server security scanners besides BitNinja: consequences, solutions
József Pálfi

Using server security scanners besides BitNinja: consequences, solutions

There are tons of paid/free cloud-based solutions or standalone applications available over the internet that allow the user to check a system’s security level. Depending on the need, people can choose from simple nmap through “blackbox” security assessment tools to a wide range of heavy-weight penetration testing tools.

Our approach

Here at BitNinja we think that security testing is the given organization’s responsibility. They should create a security-testing strategy and keep it up to date (often with help of an external partner, but it is very important that this is with the responsible person’s or department’s authorization from the organization involved). In this game, there is no place for those whose goal is unknown with their self-appointed security scanning randomly over the web.

Unfortunately, several scanners are available for free for uninvited attackers as well, causing huge headache with these tools for sysadmins every day. BitNinja generally doesn’t distinguish good or bad scanners by design. Our goal is not just to defend servers but to eliminate each incident’s root. In order to make the internet a safer place, we inform the owner of the IP with an incident report when we have detected an attack coming from the IP. But of course, we know that there are some cases when security scanners are not a threat:

  • Security researchers, who are working for a university or a cybersecurity company.
  • Testing BitNinja protection to compare your server’s defence line with and without using our software.

In these cases, of course, there’s a solution for not getting blocked and receiving incident reports from us. But before we tell you how that’s possible, let’s see why the security scanners become blocked at all.

What happens if you are using a security scanner besides BitNinja?

Customers who take the BitNinja trial often begin by scanning one or more sites in their infrastructure against various vulnerabilities while BitNinja agent is running. They want to know whether BitNinja is strong enough to protect their servers against various malicious attempts.  However, BitNinja can sometimes block the scanner.

A tool can be blocked by BitNinja for various purposes. The common case is when you are looking for open ports in order to test whether there are any applications to them, then identifying vulnerabilities in the application listening on the port. You can perform a port status check, for example with MxToolBox. What happens in this situation? If PortHoneypot module is enabled and the port isn’t whitelisted by it, a trap service on a forgotten open port captures the request and blocks the remote IP. The behaviour is the same of the other detection modules (e.g. WAF and SenseLog are very sensitive to path traversal attacks amongst many other attack types).  First a malicious attempt is blocked, then the scanner cannot reach your server in the expected layer. 

Avoid blocking

If it’s possible we highly recommend whitelisting the IP ranges of the scanner before you start scanning your system via the BitNinja Dashboard while the scanning is in progress.

For those who are operating SaaS security solutions, it is recommended to make your scanner’s IPs publicly available like Tenable does, or in a simple textual list.

In this case, customers can allow/deny them on their firewall and on the BitNinja Dashboard. Moreover, we also can periodically check the ranges and we won’t send any incident report belonging to those IPs. Feel free to contact us if we have somehow missed your service from our exclude list.

But how do you determine whether an IP belongs to a trusted security scanner if you don’t find it in any of publicly-available security scanner IP ranges? Of course, you can issue a DNS lookup for the IP, perhaps looking for information in whois (https://www.whois.net/). In several situations, this doesn’t really help, for example, because the IP belongs to a huge cloud provider. In the case of HTTP requests, the “User-Agent” header can help you. Everybody knows that it is easily spoofable, but if it contains a company name and/or a URL about the scanner’s description, it can be a good starting point to inquire whether the IP belongs to the proper security provider or not. Generally speaking, known security services provide more or less information about themselves.

Example (User-Agent Header Sent by Intruder Vulnerability Assessment)

Mozilla/5.0 (X11; Intruder; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Global whitelisted tools

Some final thoughts about monitoring tools: BitNinja does not interfere with the most traditional availability and performance monitoring services like Pingdom or Uptimerobot, but a few tools are not on our whitelist for the reasons above. You can find more info about them on doc.bitninja.io.



Have questions? Need assistance? Please don’t hesitate to ask for our help at info@bitninja.io.

Share your ideas with us about this article

Previous posts

How to protect your web hosting business during the holiday season attack wave
For devops in the web hosting business, holiday season is not exactly the most wonderful time of the year. If you’ve ever sneaked out from Christmas dinner to check on your servers’ status, or been woken up by attack alerts when only Santa Claus is supposed to be awake, you know what I mean. The Rise of Holiday Hacking Holiday season is peak period for cyber attacks, and we’ve written about it several times. But we’re not the only ones analyzing historical data and finding any indication of what’s to come. Just taking a look at last year, The SSL Store predicted over 50 millio...
The Most Famous Vulnerabilities: Cross-Site Request Forgery (CSRF)
Before I begin to explain CSRFs we need to understand some facts. First of all, we have to see how websites usually work when they have a login. Most pages use username/email and password for authentication. In today's world, it's not uncommon for newer sites to support two-step authentication. Normally we use a login once on a website because it generates on the server side a session which reminds our browser that we are already logged in. Generally, the session has an expiration time and when it expires we have to login again. After we login, the browser receives some cookies which...