How to use fail2ban for Nginx error “Primary script unknown”

0
votes

I use Ubuntu 20.04 and Fail2ban, but errors like this are not filtered. This error appears in /var/log/nginx/error.log. How do I make settings in Fail2ban to block bots like this?

2020/12/31 18:02:34 [error] 674#674: *1003 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: mydomain.com, request: "GET /wp-content/plugins/eshop-magic/download.php?file=../../../../wp-config.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "www.mydomain.com"

Note: I want to block all IP addressed trying to access non-existent web pages, using fail2ban. I'm having trouble building a proper regex on filter.d

2
nginxfail2banufw
Are you sure you want to block this? See here - AndroidX
Yes. But block them using fail2ban, not nginx. - Mawan

2 Answers

2
votes

Add the section [nginx-badbots] in your jail.local

[nginx-badbots]

enabled  = true
port     = http,https
filter   = nginx-badbots
logpath  = /var/log/nginx/error.log
maxretry = 2

Create a filter file called nginx-badbots.conf inside filter.d

[Definition]

failregex = FastCGI sent in stderr: "Primary script unknown" .*, client: <HOST>

ignoreregex =

Restart fail2ban

service fail2ban restart

Check your nginx-badbots jail

fail2ban-client status nginx-badbots
1
votes

Since you mention blocking access of scripts to wp-content's PHP scripts...

It would be quite a valid statement that the majority of good plugins will execute only through WordPress's front controller (/index.php) and have nice SEO URLs.

A good plugin would not allow its execution from links of sort /wp-content/plugins/<foo>/<foo|bar|blah>.php. The ones that do, are "bad", or badly coded :-).

So if you keep your plugin base clean, you don't have such plugins and can deem any requests to /wp-content/*.php malicious.

Blocking those can be done automatically, but Fail2Ban won't be quite a good choice there because it needs to scan through the logs first. Instead, why not route such malicious requests directly to a script which automatically bans such IPs in the firewall. No log scanning, immediate blocking.

I have covered this approach in honeypot blocking and last paragraphs of secure NGINX configuration for WordPress:

    location /wp-content/ { 
        # other PHP files cause automatic ban:
        location ~ \.php$ {
            include includes/honeypot.conf;
        }
    }

Unfortunately, the honeypot article is for FirewallD but you can easily adopt it to whatever other firewalls there in other distros.