4.3.5. Простий захист від ботів (брутфорсу адмін-панелі) за допомогою nginx
Захистити сайт від злому брутфорсом (підбором пароля до адмін-панелі сайту) і знизити навантаження, створюване ботами-зломщиками, можна за допомогою nginx, встановленого фронтендом на сервері, модифікувавши його конфігураційний файл (найчастіше він міститься в /etc/nginx/nginx.conf
) таким чином — відразу після рядка http {
додайте:
# антибот limit_req_zone $binary_remote_addr zone=antibot:16m rate=6r/m; limit_req_log_level warn; limit_req_status 403;
Далі знайдіть блок, що описує конкретний сайт, який захищається. Він починається з server {
і містить директиву server_name
з адресою сайту. Щось на кшталт:
server { server_name example.com www.example.com; listen xxx.xxx.xxx.xxx; # і далі низка location, що описують правила обробки запитів до server
В server
додайте location
з таким вмістом:
location = /wp-login.php { limit_req zone=antibot burst=2 nodelay; proxy_pass http://127.0.0.1:81; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; }
Где:
/wp-login.php
— шлях до сторінки, що захищається. Для OpenCart його потрібно замінити на/admin
, для Joomla! — на/administrator
.127.0.0.1:81
— замініть на IP-адресу: порт веб-сервера, на якому розміщений сайт (можна підглянути в сусідніх директивахlocation
).
Збережіть внесені зміни і перевірте правильність конфігураційного файлу, виконавши в консолі сервера команду:
nginx -t
Якщо результат перевірки «syntax is ok», то запустіть nginx:
service nginx restart
Принцип роботи
Цей конфігураційний файл задає зону розділюваної пам’яті з назвою antibot, об’ємом 16 МБ і швидкістю обробки запитів 6 запитів/хвилину або 1 звернення до /wp-login.php
на 10 секунд (ще можна вказувати цей параметр у запитах/секунду — r/s). Якщо кількість запитів, що надходять, більша, ніж значення rate, їхнє опрацювання відкладається доти, доки їхня кількість не перевищить значення, задане в limit_req...burst
(у нашому випадку — 2), після чого всі наступні запити отримуватимуть у відповідь помилку 403 (можна задати будь-який інший код помилки в рядку limit_req_status
, наприклад 423, як більш точний для визначення ситуації), що віддається nginx, що значно економніше в плані споживаних сервером ресурсів, ніж вилов тієї самої ситуації і блокування на рівні Apache.
Більш детальну інформацію про налаштування модуля ngx_http_limit_req_module
можна знайти в офіційній документації nginx.
Перевірка роботи системи
За допомогою утиліти ab (apache benchmark) можна створити HTTP-флуд на певну сторінку, наприклад /wp-login.php
, і подивитися при цьому Error-лог nginx:
ab -n 100 -c 1 http://example.com/wp-login.php