Использование ModSecurity в Nginx — практика защиты проекта на WordPress

ModSecurity, одно из наиболее популярных веб-приложений файрволов (WAF) в мире, помогает предотвращать различные виды атак на веб-приложения. Например, SQL-инъекции, кросс-сайтовый скриптинг (XSS), фальсификацию межсайтовых запросов (CSRF). Инструмент работает как модуль для таких серверов, как Apache, Nginx и IIS.

Альтернатива ModSecurity — многоуровневая система безопасности для блокировки атак на Linux-серверы BitNinja. Среди модулей платформы — WAF и AI-сканер. Специализируется на защите от SQL-инъекций, XSS, вирусов, Dos и использования форм сайта для спам-атак. BitNinja пригодится, если OpenSource-решение по какой-то причине не подходит. Подробнее о BitNinja в ispmanager расскажем в следующей статье.

В этой статье рассмотрим:
1. Отключение ModSecurity в административной части сайта
2. Безопасные настройки php.ini
3. Защита PHPMyAdmin
4. Защита RoundCube
5. Защита WordPress

Пример конфигурации для включения ModSecurity на виртуальном хосте:

server {     # Включаем ModSecurity     modsecurity on;      location / {         # Включаем движок правил ModSecurity         modsecurity_rules 'SecRuleEngine On';          # Обработка PHP файлов         location ~ [^/]\.ph(p\d*|tml)$ {             try_files /does_not_exist @php;         }     } }

В этом примере ModSecurity активируется на уровне сервера, а движок правил включается для корневой директории. Также предусмотрена обработка PHP-файлов с помощью блока location. Убедитесь, что у вас настроен обработчик для @php, который будет обрабатывать PHP-файлы.

Чтобы в процессе работы в административной части сайта не было ошибок, IP администратора необходимо добавить в белый список ModSecurity. Это поможет избежать возможных ошибок, связанных с ограничениями безопасности.

Вот какое правило можно использовать:

SecRule REMOTE_ADDR "@ipMatch 1.2.3.4" "phase:1,id:200000001,log,allow"

Замените 1.2.3.4 на реальный IP-адрес администратора.

Отключение ModSecurity в административной части сайта

location ~* ^/(wp-admin/|wp-login\.php) {         modsecurity off;         modsecurity_rules 'SecRuleEngine Off';         allow 1.2.3.4;         deny all;         try_files $uri $uri/ /index.php?$args;     location ~ \.php$ {         fastcgi_pass unix:/var/www/php-fpm/1.sock;         fastcgi_index index.php;         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;         fastcgi_param SCRIPT_NAME $fastcgi_script_name;         include /etc/nginx/fastcgi_params;     }     }

В этом конфигурационном блоке Nginx выполняются следующие действия:

Отключение ModSecurity. Для путей, соответствующих /wp-admin/ или wp-login.php, ModSecurity отключается. Это делается для того, чтобы избежать возможных конфликтов или ложных срабатываний, которые могут мешать работе административной части WordPress.

Ограничение доступа. Доступ к указанным путям разрешается только с IP-адреса 1.2.3.4. Все остальные запросы будут отклонены. Это помогает защитить административный интерфейс сайта от неавторизованного доступа.

Обработка PHP-файлов. Для файлов, заканчивающихся на .php, настраивается передача запросов на обработку FastCGI-процессу, который слушает сокет /var/www/php-fpm/1.sock. Это необходимо для корректной обработки PHP-скриптов административной части WordPress.

Параметры FastCGI. Устанавливаются дополнительные параметры FastCGI—SCRIPT_FILENAME и SCRIPT_NAME, для корректного определения путей к скриптам и их обработки.

Этот конфигурационный блок помогает обеспечить безопасность и корректную работу административной части WordPress на сервере Nginx.

Я не стал подробно описывать процесс компиляции и настройки ModSecurity, поскольку это достаточно обширная тема, заслуживающая отдельного рассмотрения. Если есть вопросы — задавайте в комментариях.

Безопасные настройки php.ini

Безопасные настройки файла php.ini помогают улучшить безопасность PHP-приложений, включая сайты на WordPress.

Вот несколько важных настроек:

display_errors = Off. Отключает вывод ошибок PHP на экран. Это предотвращает утечку чувствительной информации.

expose_php = Off . Скрывает информацию о версии PHP в заголовках HTTP-ответа.

allow_url_fopen = Off. Запрещает открывать файлы через URL, что снижает риск удаленных атак.

allow_url_include = Off. Запрещает использование URL-адресов в директивах include и require, что предотвращает включение удаленных файлов.

disable_functions. Ограничивает использование опасных функций PHP, например: eval, system, shell_exec, passthru, proc_open, popen, expect_popen, pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wifcontinued, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_signal_get_handler, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, exec, pcntl_exec, pcntl_getpriority, pcntl_setpriority, pcntl_async_signals, pcntl_unshare.

open_basedir. Ограничивает доступ PHP к файловой системе, задавая директории, в которых скрипты могут работать.

session.cookie_httponly = 1. Делает куки сессии недоступными для скриптов на стороне клиента, что помогает предотвратить атаки XSS.

session.cookie_secure = 1. Гарантирует, что куки сессии передаются только через защищенные соединения (HTTPS).

Эти настройки минимизируют риск атак на PHP-приложения.

Эффективная настройка Nginx может значительно уменьшить риски безопасности, связанные с веб-серверами и приложениями. Ниже рассмотрим основные методы, как усилить безопасность с помощью настроек Nginx и ограничить доступ, чтобы предотвратить распространение атак.

Защита phpMyAdmin

Ограничим доступ к phpMyAdmin — так мы предотвратим эксплуатацию уже обнаруженных уязвимостей и тех, о которых пока неизвестно.

Разработчики ispmanager создали уникальный URL, чтобы защитить phpMyAdmin. Для дополнительной уверенности в безопасности рекомендуется внести дополнительные настройки.

Пример конфигурации для усиления защиты:

cat /etc/nginx/vhosts-includes/phpmyadmin-nginx.conf location /W4ZP4D9tFnuvZ3g3/phpmyadmin { allow 1.2.3.4; deny all;         alias /usr/share/phpmyadmin;         index index.php; } location ~* ^/W4ZP4D9tFnuvZ3g3/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {         alias /usr/share/phpmyadmin/$1;         error_page 404 @apache; } location ~ ^/W4ZP4D9tFnuvZ3g3/phpmyadmin/(.+\.php)$ { allow 1.2.3.4; deny all;         alias /usr/share/phpmyadmin/$1;         fastcgi_pass unix:/var/run/php-fpm.www-data.sock;         fastcgi_index index.php;         fastcgi_param SCRIPT_FILENAME $request_filename;         include fastcgi_params;         error_page 502 = @apache;         error_page 404 = @apache; } location @apache {         error_log /dev/null crit;         proxy_pass http://127.0.0.1:8080;         proxy_redirect http://127.0.0.1:8080 /;         proxy_set_header Host $host:$server_port;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme; } location ^~ /W4ZP4D9tFnuvZ3g3/phpmyadmin/setup {         deny all; }

Эта конфигурация Nginx предназначена для усиления защиты phpMyAdmin:

Ограничение доступа по IP-адресу. Доступ к phpMyAdmin разрешен только с IP-адреса 1.2.3.4. Все остальные запросы будут отклонены. Это уменьшает риск несанкционированного доступа.

Настройка пути. phpMyAdmin доступен по уникальному URL-пути /W4ZP4D9tFnuvZ3g3/phpmyadmin. Это усложняет задачу потенциальным атакующим, пытающимся найти и эксплуатировать phpMyAdmin.

Защита страницы настройки. Доступ к странице настройки phpMyAdmin /W4ZP4D9tFnuvZ3g3/phpmyadmin/setup полностью запрещен, что предотвращает возможность использовать ее для атак.

Эта конфигурация — пример защиты phpMyAdmin с помощью Nginx. Конфигурацию можно адаптировать под конкретные требования безопасности и инфраструктуру сервера.

Защита Roundcube

Ограничим доступ к веб-почтовому клиенту Roundcube, чтобы минимизировать риски, связанные с возможными уязвимостями.

Пример конфигурации:

cat /etc/nginx/vhosts-includes/roundcube-nginx.conf location /roundcube { allow 1.2.3.4; deny all;         alias /var/lib/roundcube;         index index.php; } location ~* ^/roundcube/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {         alias /var/lib/roundcube/$1;         error_page 404 @apache; } location ~ ^/roundcube/(.+\.php)$ { allow 1.2.3.4; deny all;         alias /var/lib/roundcube/$1;         fastcgi_pass unix:/var/run/php-fpm.www-data.sock;         fastcgi_index index.php;         fastcgi_param SCRIPT_FILENAME $request_filename;         fastcgi_param PHP_VALUE "display_errors=off \n display_startup_errors=off";         include fastcgi_params;         error_page 502 = @apache;         error_page 404 = @apache; } location @apache {         error_log /dev/null crit;         proxy_pass http://127.0.0.1:8080;         proxy_redirect http://127.0.0.1:8080 /;         proxy_set_header Host $host;         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;         proxy_set_header X-Forwarded-Proto $scheme; }

Доступ к Roundcube разрешен только с IP-адреса 1.2.3.4. Все остальные запросы будут отклонены.

Эта конфигурация снижает риск несанкционированного доступа к Roundcube, ограничивая доступ к веб-почтовому клиенту и предотвращая распространенные уязвимости.

Защита WordPress

Поделюсь настройками, которые помогут значительно повысить уровень безопасности вашего сайта на WordPress.

Эти заголовки HTTP настроены для улучшения безопасности WordPress сайта:

Referrer-Policy. Задаёт политику отсылки информации о реферере. В данном случае, для кросс-доменных запросов будет отправляться только домен, а не полный URL.

X-Content-Type-Options. Предотвращает «MIME sniffing», заставляя браузер придерживаться заданного типа содержимого.

X-Frame-Options. Защищает от кликджекинга, не позволяя загружать сайт во фрейме на других сайтах, кроме тех, которые находятся в том же домене.

X-XSS-Protection. Включает встроенный в браузеры фильтр для защиты от межсайтового скриптинга (XSS).

Content-Security-Policy (CSP). Ограничивает источники, с которых можно загружать ресурсы, и помогает предотвращать многие атаки — например, XSS и инъекции данных.

Strict-Transport-Security. Заставляет браузер использовать защищенное соединение (HTTPS) для всех будущих запросов в течение заданного времени — в нашем примере это год.

Пример настроек:

server { … add_header Referrer-Policy "origin-when-cross-origin" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Xss-Protection "1; mode=block" always; add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval';" always; add_header Strict-Transport-Security "max-age=31536000;"; … # Этот файл содержит правила для защиты сайта WordPress include /etc/nginx/wp-deny.conf;

Содержимое файла:

cat /etc/nginx/wp-deny.conf     location ~ /(robots.txt|ads.txt) {allow all;}     location ~ /*\.(json|ini|log|md|txt|sql)|LICENSE {         deny all;     }     location ~ /\. {         deny all;     }      location ~* /(?:uploads|wflogs|w3tc-config|files)/.*\.php$ {         deny all;         access_log off;         log_not_found off;     }      location ~* /wp-includes/.*.php$ { deny all; access_log off; log_not_found off;     }      location ~* /wp-content/.*.php$ { deny all; access_log off; log_not_found off;     }      location ~* /themes/.*.php$ { deny all; access_log off; log_not_found off;     }      location ~* /plugins/.*.php$ { deny all; access_log off; log_not_found off;     }     location = /xmlrpc.php { deny all; access_log off; log_not_found off;     } location = /wp-config.php { deny all; access_log off; log_not_found off;     }

Эти блоки конфигурации Nginx предназначены для улучшения безопасности сайта на WordPress, ограничивая доступ к определенным файлам и директориям:

Доступ к robots.txt и ads.txt. Разрешает доступ ко всем запросам к файлам robots.txt и ads.txt.

Ограничение доступа к чувствительным файлам. Запрещает доступ к файлам с расширениями .json, .ini, .log, .md, .txt, .sql, а также к файлу LICENSE.

Запрет доступа к скрытым файлам и директориям. Запрещает доступ ко всем файлам и директориям, начинающимся с точки. Например, .htaccess, .git.

Защита директорий от выполнения PHP-файлов. Запрещает выполнение PHP-файлов в директориях uploads, wflogs, w3tc-config, files, wp-includes, wp-content, themes, и plugins. Это предотвращает возможность выполнения зловредных PHP-скриптов, загруженных в эти директории.

Отключение XML-RPC. Запрещает доступ к файлу xmlrpc.php, который используется для работы с XML-RPC в WordPress. Отключение XML-RPC может помочь предотвратить некоторые виды атак.

Запрет доступа. Доступ к файлу wp-config.php запрещен для всех. Это предотвращает возможность чтения содержимого файла через веб-браузер, что может привести к утечке конфиденциальной информации.

Эти настройки ограничат доступ к потенциально опасным файлам и директориям и защитят ваш сайт на WordPress.

Главное

Рассмотрели способы создать многоуровневую систему защиты для веб-приложений, работающих на Nginx, и минимизировать риски взлома сайта на WordPress.

6 главных действий:

Включение ModSecurity. Пример конфигурации, как включить ModSecurity на уровне сервера и активировать движок правил для корневой директории.

Отключение ModSecurity в административной части сайта. В статье пример конфигурации, как отключить ModSecurity для административной части WordPress, чтобы избежать конфликтов и ложных срабатываний.

Защита phpMyAdmin. В статье привел пример конфигурации, которая ограничивает доступ к PHPMyAdmin по IP-адресу и использует уникальный URL для защиты.

Защита Roundcube. В статье пример конфигурации, как ограничить доступ к веб-почтовому клиенту RoundCube.

Защита WordPress. В статье пример настройки Nginx и примеры заголовков HTTP для улучшения безопасности сайта на WordPress, а также правила для ограничения доступа к чувствительным файлам и директориям.

Безопасные настройки php.ini. В статье пример настроек файла php.ini для отключения опасных функций и ограничения доступа к файловой системе, чтобы уменьшить риск атак на PHP-приложения.

Это третья часть из цикла статей «Как защитить сайт на WordPress с Linux Debian и ispmanager 6».

Предыдущие статьи:

В следующих статьях:

Настройка BitNinja
Настройка системы согласно аудиту Lynis
Завершение настроек безопасности, использование белых списков

ссылка на оригинал статьи https://habr.com/ru/articles/822381/