Skip to main content

Testing BitNinja

This section helps you to test your BitNinja installation and protection.

General considerations​

You can watch a webinar recording with George Egri, CEO of BitNinja presenting all these test on our YouTube channel here: https://www.youtube.com/bitninjaio

tip

Before you start testing the BitNinja protection, please consider these notes about the system:

  1. BitNinja is designed not to tolerate testing the protection as that's what bad guys do before an attack. There is a specific module AntiFlood responsible for collecting incidents form other modules and block listing the IP if there are too many incidents. To bypass this protection you have to disable the AntiFlood module using the following command: bitninjacli module=AntiFlood stop

  2. To avoid allow listing issues the BitNinja cloud doesn't accept any incidents after a successful IP delist via the captchahttp for 1 minute.

  3. BitNinja agent is sending incidenst in batches, not one by one to avoid making things even worse in case of a distributed attack. This may cause lag between raising an incident with a test attack and seeing it on the dashboard.

To run the test attacks we usually use a vagrant ubuntu 16 linux box.

Here is a minimal vagrant file you can use:

    Vagrant.configure(2) do |config|
      config.vm.box = "bento/ubuntu16.04"
      config.vm.provider "virtualbox" do |v|
        v.memory = 2000
        v.cpus = 2
        v.customize ["modifyvm", :id, "ostype", "Ubuntu_64"]
      end

      config.vm.hostname = "attacker"
    end

You can use the https://admin.bitninja.io management interface to see the incidents. Also you can see the logs in /var/log/bitninja. It is important to know that when BitNinja challenge lists an IP it closes all real services. So if you use your own IP address to simulate the attack and you login via ssh from the same IP, your ssh session will be terminated because the IP has been challenge listed.

You can keep track of the availability and health of the BitNinja home page, dashboard, API, Reseller API, package repository, and documentation site on the https://status.bitninja.io page. Additionally, there is an option to subscribe to status changes the menu is located at the top right corner of the page. It is a convenient way to stay up-to-date with any changes.

Testing the DoS protection​

The Dos detection module is on by default.

To prepare your attacker machine install the siege package on it.

apt-get install siege

Now you can start the portscan to simulate the attack vector.

siege c200 http://[your server]

Additionally you can also test the Dos detection module by creating a PHP file that simulates a website's load and target that file with siege.

To do that create a file on your server on the domain you wish to test the DOS detection module on. Let's name this file 'attackme.php', the contetn should be this:

<?php
// Simulate website load
sleep(1);

After file is saved you can test the Dos detection module on the file with the siege comamnd as shown below:

siege -c 200 http://example.com/attackme.php

Testing Malware Detection​

The MalwareDetection module is enabled by default and it will quarantine every file that matches a published malware signature. You can disable the quarantine option from the config.ini file of the module. Then you can place malware in the /tmp directory (or in any other enabled directory). The Malware Detection module will immediately quarantine the malware. You can find the quarantined malwares in /var/lib/bitninja/quarantine or on the https://admin.bitninja.io admin panel under the Files menu.

To create a malware for testing purposes, copy and paste the following code into a file in the /tmp directory, and save it.

    <?php $kntol = "LY7LCsMgEFL3+QqRQEUaZ9/SYgkqzlUoxo4Pol9f03M13HvgnhmVYv7Fojakc578W5h5OFv4aee35zDGRYlo3s+aCNegFZJPmKeMdeAhpfWbVQWz2x2QvbgIuslJT0TJK5A7HR90cvOAceVymc59Z7XAKdh5Tm/za/7Dlp+38xiqBvq3PQ5f";eval(str_rot13(gzinflate(str_rot13(base64_decode(($kntol))))));?>

Testing the Port Scan protection​

To prepare your server, make sure, that the PortHoneypot module is enabled. It is enabled by default.

You can check if the module is running with the bitninjacli --module=porthoneypot --status command or use the netstat -lntp command to check if you see entries that look like bitninja [PortHoneypot].

To prepare your attacker machine install nmap first:

apt get install nmap

Now you can start the portscan to simulate the attack vector.

nmap -sV [IP of your server]

If the connection to the port honeypot is coming from an external non allow listed IP i.e. outside of the internal network of the server then the IP address will be challenge listed on the account. You can check if the public IP of the attacker IP is in the main.log file, or paste the IP to the Dashboard's search bar to check the incident logs there.

Testing the Web honeypot module​

To test this module, first you need to make a web honeypot. Please see that guide on that at WebHoneypot page of the documentation.

Testing SenseLog​

The SenseLog module is active by default. To prepare your server for the test you should create a file called plugin_googlemap2_proxy.php or if you have any Joomla sites hosted on your server with this extension, you can use that for testing the log analyzer. Open the URL from a browser several times. It will soon trigger the loganalyzer and challenge list the IP.

http://[your domain]/plugin_googlemap2_proxy.php

Testing the Web Application Firewall​

If the WAF module is enabled from the Dashboard then it can be triggered from any web browser. Add info.php?file=/etc/passwd after one of your domains' URL in your browser as shown below.

http://[domain of any sites]/info.php?file=/etc/passwd

It should block the request and then retry connection, and this time as your IP has been challenge listed the CAPTCHA page will appear.