Использование ModSecurity в Nginx — практика защиты проекта на WordPress18.06.2024 11:45

849cb2e2d67b5690634cb2514a91e1eb.png

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

  • Завершение настроек безопасности, использование белых списков

© Habrahabr.ru