The NGINX WAF with ModSecurity and Project Honeypot

The NGINX WAF with ModSecurity and Project Honeypot

To help fight crime, the FBI maintains a public Ten Most Wanted list, a list of the most dangerous criminals out there. Anyone who sees someone on the list can call the police, making it more difficult for these criminals to commit more crimes.

In the world of technology, there’s a similar concept called Project Honeypot. Project Honeypot maintains a list of known malicious IPs. The list is available for free to the public. ModSecurity integrates with Project HoneyPot and can automatically block IP addresses on the Project Honeypot list. This process is known as IP reputation.

In this blog post, we’ll cover how to configure ModSecurity 3.0, for both NGINX and NGINX Plus, to integrate with Project Honeypot.

Why “Project Honeypot”?

Project Honeypot is a community-driven online database of suspicious IPs. Project Honeypot tracks IP addresses which are suspected to be spammers or bots. Each IP is assigned a threat score between 0 and 255; the higher the number, the more likely the IP is to be malicious.

The Project Honeypot database is powered by a network of volunteers who set up “honeypots.” A honeypot, in this context, is a fake page on your site that shows up when a bot scans a site, but is invisible to regular people browsing a site using a web browser. When the scanner follows the honeypot link and attempts to interact with the page  – harvesting, for example, an embedded honeypot email address  – the IP address is added to the database.

For more details on how Project Honeypot works, click here.

Prerequisites

1. Install NGINX or NGINX Plus
2. Install ModSecurity 3.0 for open source NGINX (instructions here) or NGINX Plus (instructions here
3. Install and enable ModSecurity core rule set (CRS)

1. Set Up Your Honeypot

To start using Project Honeypot, first set up a honeypot on your site. Project Honeypot provides the honeypot script for you to use. To do this:

1. Sign up a for a free Project Honeypot account
2. Set up your honeypot  – Project honeypot offers the honeypot script in PHP, Python, ASP, and a few other languages.
3. Download the honeypot script

In this scenario, we’ll use PHP for the scripting language. If your preferred language is not supported by Project Honeypot, PHP is a good choice, because it’s very easy to configure NGINX to run PHP scripts using PHP-FPM.

There are plenty of tutorials online on how to install PHP-FPM. For Ubuntu 16.04 and later, you can use:

$ apt-get update

$ apt-get -y install php7.0-fpm

You can then configure the Project Honeypot PHP script using this location block:

server {

    server_name www.example.com;

    location ~ .php$ {

        modsecurity off;

        root /code;

        try_files $uri =404;

        fastcgi_split_path_info ^(.+.php)(/.+)$;

        fastcgi_pass localhost:9000;

        include fastcgi_params;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_param PATH_INFO $fastcgi_path_info;

}

Notes:

• The above code sample assumes the Project Honeypot script will be saved into /code as specified by the root directive. Please replace this with the directory you copied the script into.
• Make sure server_name matches the domain name you registered with Project Honeypot
• ModSecurity must be disabled on the honeypot script for it to function properly.

Once the script is installed, go to it in a web browser and click the activation link to activate the honeypot.

The next step is to configure NGINX to add the honeypot link to all pages. This is done using the sub_filter directive.

2. Add Honeypot Link to All Pages

To catch bots and scanners, a link to the honeypot script needs to be inserted on every page. The link will be invisible to regular people using a web browser but visible to bots and scanners. Here, we’ll use the NGINX sub_filter directive to add the link to the bottom of each page.

location / {

        proxy_set_header Host $host;

	proxy_pass http://my_upstream;

	sub_filter '</html>' '<a href="http://www.example.com/weddingobject.php"><!-- hightest --><

/a></html>';

}

In this example, the name of our PHP honeypot file is weddingobject.php. The sub_filter directive will look for the end of page </html> marker and insert the invisible link there.

3. Enable IP Reputation in the Core Rule Set

Now that our honeypot is set up, we can configure ModSecurity to query Project Honeypot on all HTTP requests.

1. Request a Project Honeypot http:BL access key
2. If you followed our instructions on setting up the core rule set, you should have a file called /usr/local/owasp-modsecurity-crs-3.0.0/crs-setup.conf. In this file, search for SecHttpBlKey.
3. Uncomment all the lines in this section and enter the API key you got in step 1 as the parameter to SecHttpBlKey. It should look like the below:

   SecHttpBlKey my_api_key
   
   SecAction "id:900500,
   
     phase:1,
   
     nolog,
   
     pass,
   
     t:none,
   
     setvar:tx.block_search_ip=0,
   
     setvar:tx.block_suspicious_ip=1,
   
     setvar:tx.block_harvester_ip=1,
   
     setvar:tx.block_spammer_ip=1"

   Note that block_search_ip is disabled in the above example, as it’s unlikely that you’ll want to block search engine crawlers.

4. Reload NGINX for the changes to take effect

   $ nginx -t && nginx -s reload

At this point, Project Honeypot is fully enabled and ModSecurity will query Project Honeypot on all HTTP requests. The results of the query are cached to minimize the performance impact, so only the first request from an IP address is sent to Project Honeypot.

4. Verify it Works

The Project Honeypot queries are based off the client source IP address. It’s not easy to spoof a source IP address, so a good way to test that the functionality is working is by setting up this custom rule:

SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'

The rule above will use the value of the IP argument, passed as part of the request, and send that to Project Honeypot. The rule can be added into /etc/nginx/modsec/main.conf. Make sure the restart NGINX for the rule to take effect: nginx -t && nginx -s reload.

We can then use curl, using an IP address from Project Honeypot’s list of known bad IPs. You should see the request being blocked with a 403.

$ curl -i -s -k -X $'GET' 'http://localhost/?IP=203.0.113.20'

HTTP/1.1 403 Forbidden

Server: nginx/1.13.4

Date: Wed, 04 Oct 2017 21:29:17 GMT

Content-Type: text/html

Transfer-Encoding: chunked

Connection: keep-alive

Note: The above example uses a standard IP address reserved for documentation. Swap it out with an IP address from the Project Honeypot list of bad IP addresses.

Summary

In this blog post, we covered the steps for configuring ModSecurity 3.0 to work with Project Honeypot. Project Honeypot is a very useful tool for automatically blocking known bad actors. It’s also free and community-driven.

ModSecurity 3.0 is available for both the open source NGINX, and as the NGINX WAF for NGINX Plus. The NGINX WAF is a precompiled dynamic module that is maintained and fully supported by NGINX, Inc. Try it free for 30 days.

The post The NGINX WAF with ModSecurity and Project Honeypot appeared first on NGINX.

Source: The NGINX WAF with ModSecurity and Project Honeypot