Блог

Я использую Ubuntu 20.04 и Fail2ban, но подобные ошибки не фильтруются. Эта ошибка появляется в /var/log/nginx/error.log . Как мне сделать настройки в Fail2ban, чтобы блокировать подобных ботов?

2020/12/31 18:02:34 [ошибка] 674 # 674: * 1003 FastCGI отправлено в stderr: «Основной сценарий неизвестен» при чтении заголовка ответа из восходящего потока, клиент: xxx.xxx.xxx.xxx, сервер: mydomain.com , запрос: «ПОЛУЧИТЬ /wp-content/plugins/eshop-magic/download.php?file=../../../../wp-config.php HTTP/ 1.1», восходящий поток: «fastcgi://unix:/var/run/php/php7.4-fpm.sock:», хост: «www.mydomain.com »

Примечание: я хочу заблокировать все IP-адреса, пытающиеся получить доступ к несуществующим веб-страницам, используя fail2ban. У меня возникли проблемы с созданием правильного регулярного выражения для filter.d

Добавьте раздел [nginx-badbots] в свой jail.local

 [nginx-badbots]

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

Создайте файл фильтра, вызываемый nginx-badbots.conf внутри filter.d

 [Definition]

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

ignoreregex =
 

Перезапустите fail2ban

 service fail2ban restart
 

Проверьте свою nginx-badbots тюрьму

 fail2ban-client status nginx-badbots
 

Поскольку вы упомянули блокировку доступа скриптов к wp-content PHP-скриптам…

Было бы вполне обоснованным утверждением, что большинство хороших плагинов будут выполняться только через front controller ( /index.php ) WordPress и иметь хорошие SEO-URL.

Хороший плагин не разрешил бы его выполнение по ссылкам сортировки /wp-content/plugins/<foo>/<foo|bar|blah>.php . Те, которые это делают, являются «плохими» или плохо закодированными :-).

Поэтому, если вы содержите свою базу плагинов в чистоте, у вас нет таких плагинов, и вы можете посчитать любые запросы /wp-content/*.php вредоносными.

Их блокировку можно выполнить автоматически, но Fail2Ban не будет здесь хорошим выбором, потому что сначала ему нужно просмотреть журналы. Вместо этого, почему бы не направлять такие вредоносные запросы непосредственно в скрипт, который автоматически запрещает такие IP-адреса в брандмауэре. Нет сканирования журнала, немедленная блокировка.

Я описал этот подход в разделе блокировка honeypot и в последних абзацах безопасной конфигурации NGINX для WordPress:

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

К сожалению, статья honeypot предназначена для FirewallD, но вы можете легко адаптировать ее к любым другим брандмауэрам в других дистрибутивах.