The first thing you should do to test Signal Sciences is to run attack tooling against your site to verify that attack data is being captured and blocking is working correctly.
Running the scan
While you can use any attack tooling for testing, we recommend using Nikto which tests a wide variety of vulnerabilities. While Nikto is running, our agents will identify any malicious or anomalous requests and send relevant metadata to our backend, after redacting any sensitive information.
The next sections cover getting set up with Nikto and running a few scan scenarios.
Nikto is a common open source tool used for running security tests against web servers. It can run on Linux, OS X, and Windows platforms.
- Nikto requires Perl to be installed, which can be verified by running
perl -v. If Perl is not found on your system see http://learn.perl.org/installing/ for installation guides.
- Download the latest version of Nikto from https://github.com/sullo/nikto/archive/master.zip. For more information about Nikto see https://cirt.net/Nikto2
- At the command prompt use the command
unzip nikto-master.zipto unzip the file. Then change directories to the program directory with the command
- To verify you are able to run Nikto run
./nikto.pland it will display the default help message. If you receive a permission denied error message, this can be resolved by running
chmod +x nikto.plto make the script executable, then run
Scenario 1 - Detecting Attacks (Attack Tooling)
As the first test scenario, Nikto will be used to demonstrate Signal Sciences’ attack tooling detection capability. For this scenario ensure the agent mode is set to “not blocking”. To verify, log in to the Signal Sciences console (https://dashboard.signalsciences.net/) and confirm the top menu label displays “Not blocking”.
To initiate the first Nikto scan of your site run the following command:
./nikto.pl -h http://www.your-site.com
While the scan is running, attacks and anomalies will begin to appear within 30 seconds on the console. Example:
Note: You can modify the time period on the graph to limit or expand the amount of malicious traffic to display. For this scenario click the time menu selector on the top right corner of the Overview page and select 1 HOUR AGO.
Note: The IP address you are running the scan from may briefly appear on the Suspicious IPs list, but it will ultimately appear on the Events list.
Common Question: What is the difference between the Suspicious IPs list and the Events list?
Answer: The Suspicious IPs list represents IP addresses that are the origin of requests containing attack payloads, but the volume of attack traffic from that IP address has not exceeded the decision threshold. Once the threshold is met or exceeded, the IP address will be flagged and added to the Events list. If the agent mode is set to “blocking” then all malicious requests from flagged IPs are blocked (without blocking legitimate traffic).
Once the IP address appears on the Events list click on View or the time status to open the Events page for that IP address.
The Events page explains that the IP address was flagged because the agent tagged X number of requests with the Attack Tooling signal within a certain time based threshold. In the example screenshot below it states “51 requests tagged from this IP with Attack Tooling within 1 minute”. Additional information about time based thresholds can be found here.
Notice you may browse other events from this page as well. In addition, you can use the buttons on this page to allow the IP, block the IP, or remove the flag.
Common Question: Why was this IP address flagged only with the Attack Tooling signal and not other signals like XSS, or SQLi?
Answer: Many attack tools perform numerous requests to fingerprint the server being targeted before launching actual attacks. This is done to select payloads that may be more specific to that server’s technology. This initial fingerprinting traffic won’t contain malicious payloads but the agent still detects the tool based on certain characteristics of the traffic. A common characteristic is the User-Agent string, which in the case of Nikto will contain “Nikto”. As a result, the amount of fingerprinting traffic Nikto generates was enough to cause the IP address to be flagged with the single Attack Tool signal. However, if you view the requests you can see the other signals that were also applied to each request. Referring to the events page screenshot above, you would click the link text 51 requests tagged to view all related requests and the associated signals.
In this test scenario you learned the following:
- How to run Nikto to generate attacks and anomalies against your web application.
- How to modify the graph time period for attacks and anomalies.
- How to identify suspicious IPs and flagged IPs on the console.
- How to drill down into event details and review why an IP was flagged.
- How to navigate to details of all requests associated with an event.
Scenario 2 - Detecting Attacks
In this second scenario we’ll modify our Nikto scan to demonstrate an IP address being flagged due to injection attacks, rather than just attack tooling. With Nikto this can be done by modifying the User-Agent string that is sent with each request.
Make sure the scanner’s host IP address has been removed from the flagged list. To remove an IP address from the flagged list, navigate to the Events page by clicking View for the IP address in the Events list. Next, click the Remove flag now button and a dialog will prompt you for confirmation. Click the Remove flag button in the dialog to confirm removal.
To initiate the scan with a modified User-Agent string use the following command:
./nikto.pl -useragent “MyAgent (Demo/1.0)” -h http://www.your-site.com
As before, the attacks and anomalies begin to populate on the console. Notice this time however that the majority of signals are due to various attacks and not attack tooling. This means modifying the User-Agent string worked and the IP address will eventually be flagged based on the various attacks.
In this test scenario you learned the following:
- How to remove an IP address from the flagged list.
- How to modify Nikto’s User-Agent string to avoid immediate detection as an attack tool.
Scenario 3 - Blocking Attacks Without Impacting Legitimate Traffic
For the third scenario you will run another scan, but this time with blocking mode enabled. With blocking mode enabled this scenario will demonstrate how Signal Sciences will allow legitimate traffic to continue accessing the site while malicious traffic from the same IP address is blocked. To perform this test you will need to use a web browser that is on the same system you are running the scan from. Before continuing, make sure to remove the scanning IP address from the flagged list.
Change the agent’s mode to blocking. Click the top menu label Non-blocking to open the Agent Mode dialog.
Next, arrange your windows so the command shell window is side-by-side with a web browser window. This will allow you to view responses from the Nikto scan while navigating your site as a normal user would.
You are now ready to initiate a scan. However, this time add the following additional command line arguments to the Nikto command:
-D Vfor verbose output, this will let you see when requests are blocked by Signal Sciences with an HTTP 406 response code.
-T 9to tune the scan so it only tests for SQL Injection.
To initiate the with the additional arguments use the following command:
./nikto.pl -useragent “MyAgent (Demo/1.0)” -D V -T 9 -h http://www.your-site.com
While the scan is running use the browser window to navigate the site as a normal user would. You can observe from the command shell window that requests containing attacks are being blocked with a 406 response code. Since the scan is tuned with the
-T argument it may complete quicker than previous scans. Repeat the scan as many times as desired and continue browsing the site to confirm legitimate user traffic is not blocked.
Common Question: Why is an HTTP 406 response code used for blocking attacks?
Answer: An HTTP 406 is used so as to not trigger operational alarms as a 500 or 404 would. Additionally, by using a unique code like 406, customers can customize the error message that is returned by the server however they would like.
In this scenario you learned the following:
- How to enable blocking mode.
- How to arrange your command shell window and browser window to observe Signal Sciences' blocking capability.
- When in blocking mode Signal Sciences only blocks malicious requests and not legitimate user requests, even when these request are coming from the same IP address.
Through this series of quick test scenarios, you have been able to prove both the detection capabilities of Signal Sciences, as well as the ability to use Signal Sciences in blocking mode to stop attacks without blocking legitimate traffic.