Установка и настройка ModSecurity с Nginx на Debian/Ubuntu

Данное руководство объяснит, как настроить и применять ModSecurity с Nginx на серверах Debian/Ubuntu. ModSecurity — это популярный open-source веб-фаервол (WAF), который обеспечивает всестороннюю защиту веб-приложений (например, WordPress, Nextcloud, Ghost и других) от множества атак уровня 7 (HTTP), включая SQL-инъекции, межсайтовый скриптинг и локальное включение файлов.

Этот учебник совместим со всеми актуальными версиями Debian и Ubuntu, включая Debian 11, Ubuntu 18.04, Ubuntu 20.04 и Ubuntu 22.04.

Веб-приложения по своей природе подвержены рискам. Если вы администратор WordPress, вам, вероятно, время от времени придется сталкиваться с сообщениями о хакерах, эксплуатирующих уязвимости в плагинах и темах WordPress. Для защиты важно установить WAF на ваш веб-сервер, особенно если используются старые приложения, которые больше не обновляются. ModSecurity был разработан Иваном Ристичем в 2002 году и в настоящее время поддерживается компанией Trustwave SpiderLabs. Этот WAF является одним из самых популярных в мире, защищая более миллиона сайтов. cPanel, самая популярная панель управления хостингом, включает ModSecurity в качестве своего основного WAF.

Возможно, вы уже знакомы с другими файрволами на уровне хоста, такими как iptables, UFW, Firewalld и другие. Однако их особенность заключается в том, что они функционируют на 3 и 4 уровнях модели OSI, принимая решения на основе IP-адресов и номеров портов. В то же время ModSecurity и другие веб-приложенческие файрволы ориентированы на обработку HTTP-трафика (7 уровень модели OSI), принимая решения, исходя из содержимого HTTP-запросов и ответов.

ModSecurity версия 3

ModSecurity был изначально создан для веб-сервера Apache. До выхода версии 3.0 он мог использоваться с Nginx, но сталкивался с проблемами производительности. В 2017 году была выпущена версия 3.0 (также известная как libmodsecurity), что стало значимым событием, особенно для пользователей Nginx, так как это первая версия с полноценной поддержкой этого сервера. Однако, несмотря на прогресс, ModSecurity 3 пока не обладает всеми возможностями, доступными в предыдущей версии (2.9), хотя с каждым обновлением добавляются новые функции.

Первый шаг: Установка Nginx на Debian или Ubuntu.

sudo apt install nginx

ModSecurity подключается к Nginx в качестве динамического модуля, что даёт возможность собирать модули по отдельности без необходимости пересборки самого Nginx.

Для обеспечения бинарной совместимости динамических модулей с вашим текущим бинарным файлом Nginx, он должен быть скомпилирован с параметром —with-compat. Однако бинарные файлы Nginx, доступные в стандартных репозиториях Debian/Ubuntu, не всегда включают этот параметр.

Используйте следующую команду для проверки аргументов конфигурации Nginx:

sudo nginx - V

Все бинарные файлы Nginx в PPA были собраны с использованием аргумента —with-compat.

Теперь необходимо активировать репозиторий с исходным кодом, чтобы мы могли загрузить исходники Nginx.

Ubuntu

sudo apt install software-properties-common sudo apt-add-repository - ss sudo apt update

Дебиан 11

Вставьте указанные строки в файл /etc/apt/sources. list.

deb-src http://deb. debian. org/debian/ bullseye main deb-src http://security. debian. org/debian-security bullseye/updates main

Сохраните файл и закройте его. После этого обновите индекс вашего репозитория.

sudo apt update

Загрузите исходные файлы Nginx.

Несмотря на то что компилировать сам Nginx не требуется, нам потребуется его пакет исходного кода для сборки динамического модуля ModSecurity. Используйте следующую команду, чтобы создать каталог nginx в /usr/local/src/, который будет служить для хранения пакета исходного кода Nginx. Не забудьте заменить username на ваше настоящее имя пользователя.

sudo chown username:username /usr/local/src/ - R mkdir - p /usr/local/src/nginx

Откройте папку с исходным кодом Nginx.

cd /usr/local/src/nginx/

Загрузите пакет исходного кода Nginx, воспользовавшись следующими командами:

sudo apt install dpkg-dev apt source nginx

Если вы наткнетесь на данное предупреждение, его можно не обращать внимания.

W: Download is performed unsandboxed as root as file 'nginx_1.19.5.orig. tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Пожалуйста, просмотрите загруженные файлы с исходным кодом.

nginx-1.19.5 nginx_1.19.5-3+ubuntu20.04.1+deb. sury. org+1.debian. tar. xz nginx_1.19.5-3+ubuntu20.04.1+deb. sury. org+1.dsc nginx_1.19.5.orig. tar.gz

Проверьте, чтобы версия исходного кода соответствовала версии вашего бинарного файла Nginx (sudo nginx — v).

Установите libmodsecurity3.

libmodsecurity — это библиотека ModSecurity, предназначенная для фильтрации HTTP-запросов в веб-приложениях. На системах Debian 10 и Ubuntu 20.04, 22.04 можно установить её с помощью команды sudo apt install libmodsecurity3, однако лучше всего будет скомпилировать последнюю стабильную версию из исходников.

Сначала необходимо клонировать исходный код libmodsecurity с GitHub, прежде чем приступать к компиляции.

sudo apt install git git clone --depth 1 - b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/ cd /usr/local/src/ModSecurity/

Подключите необходимые библиотеки для компиляции.

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libpcre2-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen

Подключите все требуемые подмодули.

git submodule init git submodule update

Настройте окружение для компиляции.

./build. sh ./configure

Если вы столкнетесь с этой ошибкой, можете не обращать на нее внимания.

fatal: No names found, cannot describe anything.

Соберите исходный код, выполнив следующую команду. По умолчанию утилита make использует только одно ядро процессора. У меня на сервере 4 ядра, поэтому я указываю 4 задачи (-j4) для make, чтобы ускорить процесс сборки. Замените 4 на количество ядер вашего процессора.

make - j4

По окончании успешного выполнения команды make без ошибок произведите установку бинарного файла.

sudo make install

Он будет размещён в папке /usr/local/modsecurity/.

Исправление ошибок при компиляции.

Ошибка номер один.

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

g++: internal compiler error: Killed (program cc1plus)

В файле /var/log/syslog содержатся строки, которые свидетельствуют о нехватке памяти на сервере, поэтому рекомендуется рассмотреть возможность улучшения его параметров.

В качестве решения проблемы нехватки оперативной памяти вы можете настроить swap-пространство. Тем не менее, это следует рассматривать лишь как временную опцию. Использование swap-пространства на серверах с SSD может привести к ухудшению производительности системы.

Ошибка номер два.

Если при компиляции ModSecurity вы сталкиваетесь с данной ошибкой,

utils/geo_lookup. cc: In member function ‘bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function&)>) const’: utils/geo_lookup. cc:124:32: error: invalid conversion from ‘const MMDB_s*’ to ‘MMDB_s*’ [-fpermissive] r = MMDB_lookup_string(&mmdb, target. c_str(), &gai_error, &mmdb_error);

Скорее всего, это связано с тем, что у вас установлена старая версия libmaxminddb-dev. Вы можете удалить этот пакет.

sudo apt remove libmaxminddb-dev

Установите libgeoip-dev, который служит заменой для libmaxminddb-dev.

sudo apt install libgeoip-dev

После этого выполните перекомпиляцию ModSecurity.

make clean ./configure make - j4

Установите исполняемый файл.

sudo make install

Загрузите и соберите исходный код модуля ModSecurity v3 для Nginx.

Модуль ModSecurity для Nginx интегрирует libmodsecurity с веб-сервером Nginx. Скопируйте репозиторий соединителя ModSecurity v3 из Git.

git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx. git /usr/local/src/ModSecurity-nginx/

Проверьте, что вы находитесь в папке с исходными файлами Nginx.

cd /usr/local/src/nginx/nginx-1.19.5/

Установите необходимые пакеты для компиляции Nginx.

sudo apt build-dep nginx sudo apt install uuid-dev

После этого настройте окружение, используя следующую команду. Мы не будем собирать сам Nginx, а лишь модуль соединителя ModSecurity для Nginx. Параметр —with-compat обеспечит бинарную совместимость модуля с уже установленным бинарным файлом Nginx.

sudo ./configure --with-compat --with-openssl=/usr/include/openssl/ --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Скомпилируйте модуль соединителя ModSecurity для Nginx.

sudo make modules

Модуль будет размещен под именем objs/ngx_http_modsecurity_module. so. Переместите его в папку /usr/share/nginx/modules/.

sudo cp objs/ngx_http_modsecurity_module. so /usr/share/nginx/modules/

Установите модуль соединителя ModSecurity v3 для Nginx.

Измените главный файл конфигурации Nginx.

sudo nano /etc/nginx/nginx.conf

Вставьте следующую строку в верхнюю часть файла.

load_module modules/ngx_http_modsecurity_module. so;

Также включите следующие две строки в секции http, чтобы активировать ModSecurity для всех виртуальных хостов Nginx.

modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf;

Сохраните файл и закройте его. Затем создайте директорию /etc/nginx/modsec/, в которой будет размещена конфигурация ModSecurity.

sudo mkdir /etc/nginx/modsec/

После этого скопируйте файл настройки ModSecurity.

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

sudo nano /etc/nginx/modsec/modsecurity.conf

Определите последующую строку.

SecRuleEngine DetectionOnly

Эта конфигурация позволяет ModSecurity записывать журналы HTTP-транзакций, однако не предпринимает никаких мер в случае выявления атаки. Измените её на следующую, чтобы ModSecurity могла обнаруживать и блокировать веб-угрозы.

SecRuleEngine On

После этого откройте строку 224, где указано, какую информацию ModSecurity должен записывать в журнал аудита.

SecAuditLogParts ABIJDEFHZ

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

SecAuditLogParts ABCEFHJKZ

Если у вас есть сайт с кодом, возможно, стоит отключить проверку тела ответа, иначе при загрузке веб-страницы с большим объемом кода вы рискуете столкнуться с ошибками 403.

SecResponseBodyAccess Off

Сохраните файл и закройте его. Затем создайте файл /etc/nginx/modsec/main.conf.

sudo nano /etc/nginx/modsec/main.conf

Вставьте следующую строку для активации файла /etc/nginx/modsec/modsecurity.conf.

Include /etc/nginx/modsec/modsecurity.conf

Сохраните изменения и закройте документ. Кроме того, необходимо скопировать файл соответствия Unicode.

sudo cp /usr/local/src/ModSecurity/unicode. mapping /etc/nginx/modsec/

После этого проверьте настройки Nginx.

sudo nginx - t

После успешного завершения теста перезапустите Nginx.

sudo systemctl restart nginx

Активация Core Rule Set от OWASP.

Для эффективной защиты ваших веб-приложений с помощью ModSecurity необходимо настроить правила, которые помогут выявлять и предотвращать атаки. Начинающим рекомендуется установить готовые наборы правил, что позволит быстро приступить к работе, а затем изучить нюансы. Существует несколько бесплатных наборов правил для ModSecurity, среди которых стандартный набор Core Rule Set (CRS) от OWASP.

• Он является бесплатным, поддерживается сообществом и представляет собой наиболее распространённый набор правил, который предлагает надёжную стандартную конфигурацию для ModSecurity.
• Он включает в себя рекомендации по защите от распространённых угроз, таких как SQL-инъекции (SQLi), межсайтовый скриптинг (XSS) и другие.
• Он способен быть встроенным в проект Honeypot.
• Он включает в себя положения для выявления ботов и сканеров.
• Он был разработан с акцентом на широкое применение, чтобы снизить количество ложных срабатываний.

Загрузите актуальную версию OWASP CRS с платформы GitHub.

wget https://github.com/coreruleset/coreruleset/archive/v3.3.4.tar.gz

Распакуйте файл.

tar xvf v3.3.4.tar.gz

Перенесите каталог в директорию /etc/nginx/modsec/.

sudo mv coreruleset-3.3.4/ /etc/nginx/modsec/

Переименуйте файл crs-setup.conf.example на новый.

sudo mv /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf

После этого внесите изменения в основной файл конфигурации.

sudo nano /etc/nginx/modsec/main.conf

Добавьте следующие две строки, которые позволят Nginx загрузить файл конфигурации CRS и активировать отдельные правила.

Include /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf Include /etc/nginx/modsec/coreruleset-3.3.4/rules/*.conf

Закройте и сохраните файл, после чего проверьте конфигурацию Nginx.

sudo nginx - t

После успешного завершения теста, выполните перезапуск Nginx.

sudo systemctl restart nginx

Изучите принципы работы OWASP CRS

Давайте обратим внимание на конфигурационный файл CRS, который содержит отличную документацию о принципах работы CRS.

sudo nano /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf

OWASP CRS может функционировать в двух режимах, как вы можете заметить.

• Автономный режим работы. Этот режим является стандартным для версии CRS 2.x. В случае совпадения HTTP-запроса с правилом, ModSecurity сразу же блокирует запрос и прекращает дальнейшую обработку правил.
• Режим обнаружения аномалий является стандартным в CRS версии 3.x. В этом режиме ModSecurity анализирует HTTP-запросы, применяя все установленные правила и присваивая оценку каждому совпадению. Если суммарная оценка превышает заданный порог, запрос классифицируется как атака и блокируется. Для входящих запросов пороговое значение по умолчанию составляет 5, а для исходящих ответов — 4.

При активации режима оценки аномалий предусмотрено четыре уровня паранойи.

• Степень паранойи 1 (стандартная настройка)
• Степень паранойи 2
• Степень паранойи 3.
• Степень паранойи 4

С увеличением уровня паранойи CRS активирует дополнительные меры, направленные на повышение безопасности. Тем не менее, более строгие уровни паранойи могут привести к большему количеству блокировок законного трафика из-за ложных срабатываний.

Существуют два ключевых термина, которые следует усвоить перед началом работы с CRS. Теперь можно закрыть файл. Индивидуальные настройки CRS находятся в папке /etc/nginx/modsec/coreruleset-3.3.0/rules/. Каждое срабатывающее правило повышает уровень аномалии.

Проведение тестирования

Для проверки работоспособности ModSecurity можно провести простую атаку SQL-инъекции на своем собственном сайте. (Важно отметить, что тестирование безопасности на чужих сайтах без согласия является незаконным.) Введите следующий URL в адресной строке вашего веб-браузера.

https://yourdomain.com/?id=3 or 'a'='a'

Если ModSecurity функционирует корректно, ваш веб-сервер Nginx должен выдавать сообщение об ошибке 403 Запрещено.

В браузере Firefox может отсутствовать уведомление об ошибке 403. Чтобы это исправить, нажмите комбинацию клавиш Ctrl+Shift+I для открытия инструментов разработчика и перейдите на вкладку «Сеть». Затем обновите веб-страницу, нажав F5. После этого вы должны увидеть код ошибки 403 в Firefox.

Если ModSecurity функционирует в режиме только для обнаружения, он не сможет предотвратить эту атаку SQL-инъекцией.

Изучение журналов ModSecurity

Анализировать логи ModSecurity необходимо для выявления атак на ваши веб-приложения и разработки более эффективных методов защиты от хакеров. В ModSecurity различают два основных типа логов:

• Лог отладки: изначально отключен.
• журнал аудита: /var/log/modsec_audit.log

Для анализа аудиторских логов ModSecurity важно ознакомиться с пятью этапами обработки, которые включает этот инструмент:

• Этап 1: Анализ заголовков запросов.
• Этап 2: Анализ содержимого запроса
• Этап 3: Анализ заголовков ответа
• Этап 4: Анализ содержимого ответа
• Этап 5: Реакция (регистрация/блокировка злонамеренных запросов)

Существует два вида лог-файлов.

• Последовательный: все логи хранятся в одном файле. Этот режим является значением по умолчанию.
• Конкурентный режим: использование нескольких файлов для ведения логов. Это может улучшить скорость записи. Если вы заметите снижение производительности веб-страниц после активации ModSecurity, стоит рассмотреть возможность выбора конкурентного типа логирования.

Записи в журнале разделяются на несколько категорий.

• Раздел A: заголовок журнала аудита
• Раздел B: тема обращения
• Раздел C: содержание запроса.
• Раздел D: выделен под резервирование.
• Раздел E: промежуточная часть ответа.
• раздел F: окончательные заголовки ответа
• раздел G: отведён для резервирования
• раздел H: видеоролик о журнале аудита
• Раздел I: сжатая альтернативная версия запроса, не включающая файлы.
• Раздел J: сведения о загруженных документах.
• раздел K: все правила, соответствующие событию, упорядоченные по мере их соответствия.
• Раздел Z: предельная черта.

При наличии сайта с высокой нагрузкой аудиторский лог ModSecurity может быстро увеличиться в объеме. Поэтому важно настроить ротацию логов для этого аудиторского лога. Для этого следует создать конфигурационный файл logrotate для ModSecurity.

sudo nano /etc/logrotate. d/modsecurity

Включите указанные строки в данный файл.

/var/log/modsec_audit.log

Это будет обновлять файл лога ежедневно.dailyСжимая предыдущие версии.compressБудет производиться сохранение предыдущих 14 файлов журналов.повернуть на 14 градусовРотация не будет выполняться, если файл окажется пустым.notifemptyСохраните файл и закройте его.

Если в вашем логе ModSecurity нет записей, возможно, следует перезапустить Nginx.

sudo systemctl restart nginx

Работа с ложными тревогами

ModSecurity представляет собой многофункциональный брандмауэр для веб-приложений, не предназначенный для работы с определенным приложением. Базовый набор правил OWASP также является универсальным и не адаптирован к конкретным задачам, поэтому после активации ModSecurity и OWASP CRS вы, вероятно, столкнетесь с ложными срабатываниями. Увеличение уровня паранойи в CRS приведет к дальнейшему росту числа таких ложных тревог.

К примеру, в стандартных настройках CRS блокируются инъекции Unix-команд, включая использование sudo на веб-сайте, что нередко упоминается в моем блоге. Для уменьшения ложных срабатываний необходимо внести исключения в правила CRS.

Исключения из правил для определённых приложений.

В OWASP CRS предусмотрены определенные преднастройки исключений для отдельных приложений. Необходимо внести изменения в файл crs-setup.conf.

sudo nano /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf

Откройте раздел Исключения правил для определённых приложений и обнаружьте следующие записи.

#SecAction \ # "id:900130,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx. crs_exclusions_cpanel=1,\ # setvar:tx. crs_exclusions_drupal=1,\ # setvar:tx. crs_exclusions_dokuwiki=1,\ # setvar:tx. crs_exclusions_nextcloud=1,\ # setvar:tx. crs_exclusions_wordpress=1,\ # setvar:tx. crs_exclusions_xenforo=1"

Если, к примеру, необходимо добавить исключения для WordPress, строки выше следует отредактировать следующим образом. Обратите внимание на правильность синтаксиса. Между t

SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx. crs_exclusions_wordpress=1" # setvar:tx. crs_exclusions_cpanel=1,\ # setvar:tx. crs_exclusions_drupal=1,\ # setvar:tx. crs_exclusions_dokuwiki=1,\ # setvar:tx. crs_exclusions_nextcloud=1,\ # setvar:tx. crs_exclusions_xenforo=1"

Сохраните файл и закройте его. После этого проверьте настройки Nginx.

sudo nginx - t

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

sudo systemctl reload nginx

Имейте в виду, что если на одном сервере размещено несколько приложений, например, WordPress, Nextcloud или Drupal, то указанные исключения будут действовать на все из них. Чтобы уменьшить риски безопасности, рекомендуется добавлять исключения правил только для одного конкретного приложения. Для этого нужно перейти в директорию /etc/nginx/modsec/coreruleset-3.3.0/rules/.

cd /etc/nginx/modsec/coreruleset-3.3.4/rules

Измените название файла REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.

sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

После этого внесите изменения в данный файл.

sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Вставьте эту строку в конец файла. Если ваш WordPress функционирует на поддомене blog. yourdomain.com и заголовок запроса, получаемый браузером пользователя, включает этот поддомен, ModSecurity будет применять исключения к правилам для WordPress.

SecRule REQUEST_HEADERS:Host "@streq blog. yourdomain.com" "id:1000,phase:1,setvar:tx. crs_exclusions_wordpress=1"

Если Nextcloud размещен на том же сервере, стоит добавить в этот файл следующую строку, чтобы при доступе к поддомену Nextcloud ModSecurity игнорировал некоторые правила.

SecRule REQUEST_HEADERS:Host "@streq nextcloud. yourdomain.com" "id:1001,phase:1,setvar:tx. crs_exclusions_nextcloud=1"

Сохраните файл и закройте его. После этого проверьте настройки Nginx.

sudo nginx - t

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

Индивидуальные отступления от норм.

Активация заранее подготовленных исключений для определённых приложений может не решить все проблемы с ложными срабатываниями. В этой ситуации нужно изучить журнал аудита ModSecurity (/var/log/modsec_audit.log), чтобы определить, какое именно правило вызвало ложное срабатывание, и внести индивидуальные исключения в файл REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.

Раздел H в аудиторском журнале показывает, какое правило было применено. К примеру, если я попытаюсь воспользоваться HTML-кодом.

.

Мой комментарий был заблокирован ModSecurity. В журнале указано, что HTTP-запрос сработал по правилу из файла REQUEST-941-APPLICATION-ATTACK-XSS.conf (строка 527). Идентификатор данного правила — 941310, а URI запроса — /wp-comments-post.php.

В кодировке была выявлена ошибка, указывающая на возможную атаку типа XSS. Однако я хочу, чтобы пользователи имели возможность применять теги.

.

и

.

в виде комментариев, поэтому я решил сделать исключение для данного правила. Пожалуйста, добавьте следующую строку в конец файла REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.

SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"

Данная строка указывает ModSecurity, что в случае, если URI запроса совпадает с /wp-comments-post.php, правило с идентификатором 941310 не будет применяться. После этого сохраните изменения и закройте файл. Затем проведите тестирование конфигурации Nginx.

sudo nginx - t

Если тест завершился успешно, перезапустите Nginx.

sudo systemctl reload nginx

В случае, если ложное срабатывание соответствует нескольким идентификаторам правил, вы можете указать исключения для правил в одной строке следующим образом:

SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1, ctl:ruleRemoveById=941160 , ctl:ruleRemoveById=941310 , ctl:ruleRemoveById=942100 "

Обратите внимание: отключение большого количества правил первого уровня в OWASP CRS может существенно повысить риск взлома вашего сайта. Выключайте правила только если у вас есть полное понимание последствий.

Список разрешённых IP-адресов

Чтобы деактивировать ModSecurity для вашего IP-адреса, сохранив его активным для всех остальных, внесите следующее пользовательское правило в файл REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.Не забудьте заменить 12.34.56.78 на ваш фактический IP-адрес.

SecRule REMOTE_ADDR "@ipMatch 12.34.56.78" "id:1004,phase:1,allow, ctl:ruleEngine=off"

Для добавления подсети в белый список примените следующий синтаксис, который позволит включить сеть 10.10.10.0/24.

SecRule REMOTE_ADDR "@ipMatch 10.10.10.0/24" "id:1005,phase:1,allow, ctl:ruleEngine=off"

Сохраните файл и закройте его. После этого проверьте настройки Nginx.

sudo nginx - t

После успешного прохождения теста, необходимо перезапустить Nginx, чтобы изменения начали действовать.

sudo systemctl restart nginx

Система правил

Если в вашем Nginx настроено несколько виртуальных хостов, вы можете добавить свой IP-адрес в список разрешённых для конкретного хоста. Для этого необходимо объединить два правила следующим образом:

SecRule REMOTE_ADDR "@ipMatch 12.34.56.78"id:1004, фаза:1, разрешить, ctlnextcloud. yourdomain.com" "t:none"

В конце первого правила слово «chain» означает, что команда ruleEngine=off будет активирована лишь при выполнении условия следующего правила.

Интеграция ModSecurity с Project Honeypot (по желанию).

Project Honeypot предоставляет открытый доступ к списку известных вредоносных IP-адресов. ModSecurity имеет возможность интеграции с Project Honeypot и может блокировать IP-адреса, содержащиеся в этом списке.

Учтите, что интеграция Project Honeypot может снизить скорость загрузки вашего сайта для новых пользователей. Это связано с тем, что перед тем как предоставить ответ новому посетителю, ваш веб-сервер должен выполнить запрос к Project Honeypot. Тем не менее, после кэширования информации о репутации IP на вашем веб-сервере, влияние на производительность станет незначительным.

Для начала работы с Project Honeypot необходимо зарегистрироваться, создав бесплатную учетную запись на официальном сайте. После этого зайдите в панель управления вашей учетной записью и нажмите на ссылку «get one», чтобы получить ключ доступа для HTTP-черного списка.

Затем внесите изменения в файл crs-setup.conf.

sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf

Найдите указанные строки.

#SecHttpBlKey XXXXXXXXXXXXXXXXX #SecAction "id:900500,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx. block_search_ip=1,\ # setvar:tx. block_suspicious_ip=1,\ # setvar:tx. block_harvester_ip=1,\ # setvar:tx. block_spammer_ip=1"

Удалите символы # в начале строк, чтобы активировать их, и вставьте свой API ключ HTTPBL, который вы получили из Project Honeypot.

Учтите, что параметр block_search_ip следует установить в 0 (выключен), поскольку мы не намерены блокировать поисковых ботов. После этого сохраните изменения в файле и закройте его. Затем перезапустите Nginx.

sudo systemctl reload nginx

Теперь ModSecurity будет осуществлять запросы к Project Honeypot для всех HTTP-запросов. Для проверки его работы необходимо внести изменения в файл /etc/nginx/modsec/main.conf.

sudo nano /etc/nginx/modsec/main.conf

Вставьте следующую строку в конец данного файла. Это даст возможность передавать IP-адрес в URL. (После успешного тестирования вы сможете убрать эту строку из файла.)

SecRule ARGS:IP "@rbl dnsbl. httpbl. org" "phase:1,id:171,t:none, deny, nolog, auditlog, msg:'RBL Match for SPAM Source'

Сохраните изменения и закройте документ. Убедитесь, что настройки Nginx правильные.

sudo nginx - t

После этого выполните перезагрузку Nginx.

sudo systemctl reload nginx

Посетите сайт Project Honeypot и обнаружьте вредоносный IP-адрес, например 134.119.218.243. Затем выполните следующую команду для проверки HTTP-черного списка.

curl - i - s - k - X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'

Ваш веб-сервер должен ответить кодом 403, так как IP-адрес занесён в базу данных Project Honeypot.

Использование Brotli с ModSecurity в Nginx.

Веб-страницы обычно сжимаются с использованием GZIP, что позволяет ускорить их загрузку. Однако Brotli, разработанный Google, представляет собой новый алгоритм сжатия, который предлагает более высокий коэффициент сжатия. Этот алгоритм поддерживается всеми популярными веб-браузерами. Для активации Brotli в Nginx необходимо сначала установить модуль Brotli Nginx из репозитория PPA ondrej/nginx-mainline.

sudo apt install libnginx-mod-brotli

После этого откройте главный файл конфигурации Nginx.

sudo nano /etc/nginx/nginx.conf

Включите следующие строки в контекст http.<. >.

brotli on; brotli_comp_level 6; brotli_static on; brotli_types application/atom+xml application/javascript application/json application/rss+xml application/vnd. ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd. microsoft. icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;

Сохраните файл и закройте его, после чего проверьте настройки Nginx.

sudo nginx - t

В случае успешного прохождения теста выполните перезагрузку Nginx.

sudo systemctl restart nginx

Откройте главную страницу вашего сайта, затем включите инструменты разработчика в браузере (например, в Firefox это можно сделать, нажав Ctrl+Alt+I). Перейдите на вкладку «Сеть» и обновите страницу, нажав F5. После этого выберите основной HTML-документ.

Посмотрите на заголовок ответа в правой боковой панели. Если параметр content-encoding имеет значение br, это означает, что сжатие Brotli в Nginx успешно активировано.

Если в кодировке содержимого используется gzip, то ваш веб-сервер Nginx все еще применяет GZIP.

Обновление Nginx

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

Если в репозитории появилась обновленная версия Nginx, выполнение команды sudo apt upgrade позволит обновить Nginx. Однако новая версия Nginx не будет работать с ранее собранным модулем ModSecurity. После обновления Nginx с помощью команды sudo apt upgrade он не сможет перезапуститься, как видно на представленном ниже скриншоте.

Если вы введете команду sudo nginx — t, то получите уведомление о том, что Nginx ожидает обновлённую версию модуля ModSecurity.

Рекомендую остановить автоматическое обновление Nginx при выполнении команды sudo apt upgrade. Для этого используйте следующую команду:

sudo apt-mark hold nginx

Если вы выполните команду sudo apt update; sudo apt upgrade, и менеджер пакетов уведомит вас о том, что пакет nginx заблокирован для обновления, это указывает на то, что в репозитории появилась новая версия nginx.

Скачайте свежую версию исходного пакета Nginx и повторно скомпилируйте модуль ModSecurity. Затем переместите заново собранный модуль ModSecurity в папку /usr/share/nginx/modules/. Это подразумевает удаление содержимого директории /usr/local/src/ (sudo rm /usr/local/src/* — rf) и повторное выполнение шагов 2 и 4.

После этого уберите блокировку с Nginx.

sudo apt-mark unhold nginx

Обновите Nginx до последней версии.

sudo apt upgrade nginx

После окончания обновления снова удержите Nginx.

sudo apt-mark hold nginx

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

apt-mark showhold

Nginx Plus

Если вы используете коммерческую версию веб-сервера Nginx Plus, то ModSecurity уже встроен в его бинарный файл. Этот компонент также называется NGINX WAF.

Если вы хотите избежать повторной компиляции исходного кода ModSecurity, стоит рассмотреть возможность приобретения Nginx Plus, так как в его бинарной версии модуль ModSecurity уже интегрирован. Вот преимущества использования ModSecurity 3.0 с NGINX Plus:

• Вам не придется самостоятельно собирать динамический модуль ModSecurity, так как компания NGINX, Inc. предлагает уже готовый к использованию модуль, что позволяет сэкономить ваше время и силы.
• Компания NGINX, Inc. провела обширное тестирование динамического модуля, поэтому вы можете быть уверены в его надежности для применения в производственных условиях.
• Компания NGINX, Inc. непрерывно мониторит изменения и обновляет модуль при каждом значительном обновлении или обнаружении уязвимости, что избавляет вас от необходимости делать это самостоятельно.
• Каждый новый релиз NGINX Plus приносит с собой обновлённую версию динамического модуля, что позволяет обновлять его без необходимости перекомпиляции ModSecurity.
• Вы можете рассчитывать на круглосуточную помощь в установке ModSecurity и настройке правил OWASP Core, а также в диагностике и решении проблем.

Как деактивировать ModSecurity для виртуального хоста.

В данном руководстве я включил следующую строку в контекст http.<. >.

modsecurity on;

Это обеспечит активацию ModSecurity для всех серверных блоков Nginx (или виртуальных хостов). Чтобы отключить ModSecurity для определенного блока сервера, необходимо изменить файл этого блока ( /etc/nginx/conf.d/example.com.conf ) и вставить следующую строку в контекст сервера.<. >.

modsecurity off;

Перезапустите Nginx, чтобы новые настройки начали действовать.

sudo systemctl reload nginx

Часто задаваемые вопросы и ответы

Сравнение статического и динамического модуля в Nginx.

• Статический модуль необходимо собрать вместе с Nginx, чтобы интегрировать его в единый исполняемый файл. Выгрузка его из Nginx невозможна.
• Динамический модуль представляет собой самостоятельный компонент, отделенный от главного бинарного файла Nginx. Он может быть загружен или выгружен в Nginx по необходимости.

Что подразумевается под бинарной совместимостью?

• Если динамический модуль не обладает бинарной совместимостью, то его нужно компилировать совместно с Nginx. В случае, если у вас уже имеется установленный бинарник Nginx из репозитория, используя apt-get, его следует удалить. Затем необходимо установить скомпилированный бинарный файл Nginx для корректного функционирования динамического модуля.
• Если динамический модуль обладает бинарной совместимостью, его можно компилировать отдельно от Nginx. Такой модуль сможет работать с вашим уже установленным бинарным файлом Nginx, загруженным из программного репозитория. Тем не менее, это решение не является оптимальным.

Неважно, является ли модуль статическим или динамическим, а также бинарно совместимым или нет. Если вы в будущем обновите бинарный файл Nginx, потребуется повторная компиляция модуля.

Модернизация RAM сервера

ModSecurity может потреблять много оперативной памяти. Если в журнале ошибок Nginx (/var/log/nginx/error.log) вы заметили следующую ошибку, это свидетельствует о нехватке оперативной памяти на вашем сервере.

fork() failed while spawning "worker process" (12: Cannot allocate memory) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor)

Необходимо перезапустить Nginx и увеличить объем оперативной памяти сервера, чтобы устранить упомянутую ошибку.

Способы обновления OWASP CRS.

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

• Повторите шаг 6, чтобы обновить основную версию набора правил.
• После этого перейдите к шагу 10. Перенесите ваши пользовательские правила в файлы crs-setup.conf и REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.

После этого проверьте настройки Nginx.

sudo nginx - t

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

sudo systemctl reload nginx

Чтобы проверить, работает ли новая версия, выполните простую SQL-инъекционную атаку, как указано в шаге 8, и просмотрите логи сервера. В логах будет отображена версия CRS, которая блокирует эту атаку.

Заключение

Надеюсь, данный руководство помогло вам настроить ModSecurity с Nginx на Debian/Ubuntu. Вы также можете изучить другие руководства по вопросам безопасности.

• Как настроить и использовать фаервол UFW в системах Debian, Ubuntu и Linux Mint
• Автоматическая настройка обновления системы безопасности (Unattended-Upgrade) в Ubuntu
• Сервис Canonical Livepatch: обновление Linux-ядра на Ubuntu без необходимости перезагрузки
• Два простых шага для настройки беспарольного входа по SSH на Ubuntu.
• 5 действенных рекомендаций для повышения безопасности SSH-сервера в Ubuntu

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