2

Is there an application that goes through the nginx logs and blocks IPs that made requests for common webapp vulnerabilities?

I have an nginx web server that serves only static content. I routinely get requests for GET /db/websql/main.php or GET /db/phpMyAdmin2/main.php. Those are clear signs of somebody scanning for vulnerabilities. Is there an application that can go through the nginx logs, recognize these attempts to exploit common vulnerabilities and block the offending IPs? My idea is that, even if I am not vulnerable to those exploits, the same IPs could engage in other kinds of attacks on the same box or other boxes on my network: SMTP, SSH, other web servers with web applications. Blocking them while caught with their hands in the cookie jar seems a good approach to me.

Fail2ban does something similar for SSH and for HTTP authentication attempts. Maybe it could be used with a configuration that includes a list of well-known addresses used for vulnerabilities. Is there such a configuration available?

gioele
  • 194
  • 2
  • 10

4 Answers4

2

From the gotroot.com forums:

You can use nginx with our rules by putting a reverse proxy apache with mod_security in front of nginx. Thats actually very lightweight and something we will be adding post 3.0 as an option for sites running alternative web servers like nginx, etc. As Scott said, nginx does not have any WAF module or capability, so theres no way you can do anything like modsecurity inside nginx.

People have requested the nginx team add a WAF, and I know lightspeed is working on full modsec support, but so far I havent seen anything for nginx. So if you use nginx, and you want a WAF to protect it, you will need to put a WAF in front of it.

And as I said, this works great so I highly recommend you do that. We've got a bunch of customers running all sorts of non-apache webservers with apache reverse proxies and mod_security in front of them. And as I mentioned, we will be adding this into ASL post 3.0 release as an option for non-Apache web servers.

(Gotroot.com is well-known for their mod_security rules list they provide.)

Another thing you can try is naxsi which is a Web Application Firewall module for Nginx, although it's still in alpha version. More

George Tasioulis
  • 2,019
  • 2
  • 17
  • 17
  • If use an alternative webserver like nginx is probably because I don't want to use Apache. – Giovanni Toraldo Sep 30 '11 at 10:17
  • Who said you should run Apache as a webserver? You're just using it as a reverse proxy in front of nginx to handle the lack of mod_security on the latter. Anyway another solution might be Naxsi http://code.google.com/p/naxsi/ which is a Web Application Firewall module for Nginx. Have a look at it and see if it fits your needs. – George Tasioulis Sep 30 '11 at 10:38
2

Yes, you can use fail2ban for blocking IPs sending bad requests and scanning your server:

  • There is a pre-built filter in fail2ban called nginx-botsearch that might already do what you are looking for. Just take care that bad requests get logged by nginx so fail2ban can find them in the nginx logs.

  • I like the new fail2ban v11 (even if it's not meant to be used in production, yet, as devs say. But working very well already for me.). It has a feature called bantime.increment where fail2ban stores banned IPs in it' own database and can then automatically grow bantime by a givn formula for each ban of a known bad IP. This means you can have really low initial ban times and fail2ban takes care of the rest.

  • Also banning IPv6 IPs is finally possible with fail2ban since v10. (Use iptables banaction as UFW banaction still has problems banning IPv6 IPs.)

Additionally you could:

  • Install UFW what has some nice default settings, like dropping invalid packets.

  • Regularly (maybe once daily) download a blocklist with known bad IPs and block those IPs directly in iptables. Good starting point could be a script like this script. (Scroll down on that page to get the improved version using ipset.)

Bob
  • 452
  • 2
  • 5
0

How are you spotting these illegal requests... if you can see them then fail2ban can see them. Its just a case of adding rules in the jail.conf to spot these and then ban these users.

Create a copy of the apache-httpd code in fail2ban and have a play with it. You basically need to figure out the regex to match each error that you get, and then tell fail2ban what to do about it.

  • I agree with you, fail2ban could do that. As I said, what I need is «a configuration that includes a list of well-known addresses used for vulnerabilities». I know some, but I am not an expert and I have the resources and the knowledge necessary to keep it updated. Do you know any of these lists available as fail2ban configuration file? – gioele Sep 30 '11 at 12:07
  • 1
    Fail2ban doesn't use a list - it looks for errors. These common pages don't exist on your server, so it causes a 404 error in your logs. Enough of these 404s show someone is trying something untowards, so you ban them. – djsmiley2kStaysInside Oct 10 '11 at 14:22
0

I set traps for them. One common one attack is appending ?author=1 to see the WordPress admin user name. If my home page detects that, it bans that IP address. Another trick is to create a directory that your web site isn't using such as /admin. Don't put any links to it. Put a rule in your robots.txt telling google.com not to index it. Put a web page in that folder that runs a program to ban their IP address if they visit that page. For the pages you mentioned, put real web pages in those locations that will add their IP address to the iptables banned firewall.

This works on my Raspberry Pi running a version of linux and php.

To run iptables from php, add the following to /etc/sudoers

www-data ALL=(ALL) NOPASSWD: /sbin/iptables

Some people don't like giving www-data access to iptables. They say it's a security risk. But I think it's ok because they just got banned. Here's the code I use:

<?php
// Get the ip address of the client.
$remote_addr = $_SERVER['REMOTE_ADDR'];
// Ban them.
if (is_ip($remote_addr)) {
    ban_ip($remote_addr);
    // Save the banned IP address.
    $logfile = '/run/shm/banned.txt';
    file_put_contents($logfile,$remote_addr."\n",FILE_APPEND);
}
// Returns true if $ip is a valid ip address.
function is_ip($ip)
{
    $count = strlen($ip);
    $valid = '0123456789.:';
    for($loop=0;$loop<$count;$loop++) {
        if (strpos($valid,substr($ip,$loop,1))===false) {
            return false;
        }
    }
    return true;
}
// Bans an ip address.
function ban_ip($ip)
{
    $cmd = 'sudo /sbin/iptables -A INPUT -s ' . $ip . ' -j DROP';
    exec($cmd);
    return;
}
?>
  • Giving www-data access to iptables IS a SERIOUS security risk! – eKKiM Feb 13 '18 at 08:13
  • If they already got in so far that they can run iptables from their own php script they put up on your box, iptables won't matter at that point. – Russell Hankins Feb 13 '18 at 20:11
  • There sure is a point. This gives an attacker much more possibilities. For example: An attacker could edit the iptables to redirect all traffic through a malicious host. – eKKiM Feb 13 '18 at 20:24