Как установить ModSecurity 3, Nginx, OWASP CRS в Ubuntu 22.04

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

Table of Contents

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

Последняя версия, ModSecurity 3, была разработана специально для улучшения совместимости и упрощения интеграции с различными веб-серверами, включая NGINX.

Зачем использовать ModSecurity 3 с NGINX на сервере Ubuntu?

Интеграция ModSecurity 3 с NGINX на сервере Ubuntu дает массу преимуществ:

Расширенная защита: ModSecurity 3 защищает ваши веб-приложения от широкого спектра атак, включая SQL-инъекции, межсайтовый скриптинг (XSS), локальное включение файлов (LFI) и многое другое. Он обеспечивает надежную защиту от 10 лучших рисков безопасности веб-приложений по версии OWASP.
Улучшенная совместимость: ModSecurity 3 создан для бесшовной интеграции с NGINX, что повышает его возможности безопасности без снижения производительности.
Поддержка пользовательских правил: ModSecurity позволяет создавать пользовательские наборы правил, что дает возможность адаптировать систему безопасности к специфическим потребностям ваших веб-приложений.
Подробное протоколирование и мониторинг: ModSecurity предоставляет полные журналы всех HTTP-транзакций, что облегчает мониторинг трафика и выявление потенциальных угроз безопасности.
Открытый исходный код и поддержка сообщества: ModSecurity - это проект с открытым исходным кодом и активным сообществом, обеспечивающим регулярные обновления, новые функции и постоянную поддержку. Это позволяет создавать экономически эффективные, прозрачные и адаптируемые решения безопасности.

Поскольку Ubuntu является одним из самых популярных вариантов веб-серверов благодаря своей стабильности, безопасности и удобству использования, неудивительно, что многие предпочитают интегрировать ModSecurity 3 с NGINX на сервере Ubuntu.

Преимущества выходят за рамки отдельных компонентов и включают в себя:

Стабильность и безопасность: Серверы Ubuntu известны своей стабильностью и безопасной архитектурой, что делает их идеальным выбором для размещения веб-приложений.
Простота использования: Удобный дизайн Ubuntu и обширные онлайн-ресурсы упрощают управление и обслуживание сервера.
Обширная поддержка: Ubuntu имеет большое, активное сообщество и долгосрочные релизы поддержки, что гарантирует вам доступ к помощи и обновлениям, когда они вам нужны.

Этапы предустановки

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

Шаг 1: Обновление Ubuntu

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

sudo apt update && sudo apt upgrade

1	sudo apt update && sudo apt upgrade

Эта команда сначала обновляет списки пакетов для обновлений (sudo apt update).

Шаг 2: Удаление ранее существовавшей установки Nginx

Если у вас уже установлена Nginx, мы рекомендуем удалить ее и установить последнюю версию из пользовательского PPA, поддерживаемого Ондржеем Суры. Эта версия поставляется с дополнительными динамическими модулями, такими как модуль Brotli, для улучшения сжатия.

Сначала остановите текущую службу Nginx, выполнив следующие действия:

sudo systemctl stop nginx

1	sudo systemctl stop nginx

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

sudo apt purge nginx -y && sudo apt autoremove nginx -y

1	sudo apt purge nginx -y && sudo apt autoremove nginx -y

Здесь опция purge полностью удаляет пакет Nginx и его конфигурационные файлы. Команда autoremove удаляет все пакеты, которые были автоматически установлены для удовлетворения зависимостей Nginx, но теперь больше не нужны.

Шаг 3: Добавление последней версии Nginx PPA

После удаления старой службы Nginx пришло время добавить новый, актуальный PPA (Personal Package Archive) для Nginx. Вы можете выбрать стабильную или основную версию. Обычно рекомендуется основная версия, так как она включает в себя последние функции и улучшения.

Чтобы добавить стабильную PPA, выполните:

sudo add-apt-repository ppa:ondrej/nginx-stable -y

1	sudo add-apt-repository ppa:ondrej/nginx-stable -y

Или для основного PPA, используйте:

sudo add-apt-repository ppa:ondrej/nginx-mainline -y

1	sudo add-apt-repository ppa:ondrej/nginx-mainline -y

Шаг 4: Обновление индекса пакетов

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

sudo apt update

1	sudo apt update

Теперь установите Nginx с помощью следующей команды:

sudo apt install nginx

1	sudo apt install nginx

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

Шаг 5: Добавление исходного кода Nginx в репозиторий

По умолчанию исходный код Nginx не включается при установке из PPA. Чтобы скомпилировать Modsecurity далее в этом руководстве, вам нужно будет включить эту функцию, чтобы загрузить исходный код Nginx вручную.

Откройте файл конфигурации, расположенный в /etc/apt/sources.list.d:

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

1	sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

Найдите строку, которая начинается с #

Подводя итог, можно сказать, что использование ModSecurity 3 с NGINX на сервере Ubuntu обеспечивает эффективное, настраиваемое и комплексное решение безопасности для ваших веб-приложений. Это руководство продемонстрирует, как установить ModSecurity 3 с набором правил OWASP Core Rule Set на Ubuntu 22.04 Jammy Jellyfish или Ubuntu 20.04 Focal Fossa, заложив прочный фундамент для вас

Установка Nginx из исходных кодов

Чтобы без проблем интегрировать ModSecurity с Nginx, нам потребуется скомпилировать динамический модуль ModSecurity с исходным кодом Nginx. Для этого сначала нужно загрузить и сохранить исходный код Nginx в определенном каталоге (/usr/local/src/nginx). В этом разделе мы рассмотрим создание необходимых каталогов, установку зависимостей, загрузку исходного кода и проверку соответствия версии исходного кода установленной версии Nginx.

Шаг 1: Настройка структуры каталогов

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

sudo mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

1	sudo mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Эта команда создает каталог /usr/local/src/nginx и затем изменяет текущий каталог на этот вновь созданный каталог.

Шаг 2: Установка зависимостей и загрузка исходного кода

Прежде чем загружать исходный код, нам необходимо установить пакет dpkg-dev. Этот пакет предоставляет несколько инструментов разработки, необходимых для распаковки, сборки и загрузки исходных пакетов Debian. Установите его с помощью следующей команды:

sudo apt install dpkg-dev -y

1	sudo apt install dpkg-dev -y

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

sudo apt source nginx

1	sudo apt source nginx

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

Шаг 3: Проверка исходной версии

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

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

ls

В выводе вы должны увидеть несколько файлов и каталогов, связанных с Nginx.

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

nginx -v

nginx -v

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

Установка libmodsecurity3 для ModSecurity

ModSecurity - это эффективный брандмауэр для веб-приложений, а libmodsecurity3 - его основной компонент, который занимается фильтрацией HTTP. В этом разделе мы расскажем вам, как получить и установить этот важный пакет программного обеспечения.

Шаг 1: Клонирование репозитория ModSecurity

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

sudo apt install git

1	sudo apt install git

Прежде чем клонировать репозиторий, рекомендуется настроить права собственности на каталог, чтобы избежать необходимости использования привилегий root (sudo) для большинства команд:

sudo chown -R $user:$user /usr/local/src/

1	sudo chown -R $user:$user /usr/local/src/

эта команда рекурсивно изменяет право собственности на каталог /usr/local/src/ на текущего пользователя.

Далее, давайте клонируем репозиторий libmodsecurity3. Мы будем использовать неглубокое клонирование (--depth 1) для экономии пропускной способности и хранения. Это означает, что мы получим только последнюю ревизию ветки v3/master:

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

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

После клонирования репозитория измените свой рабочий каталог на новый клонированный репозиторий:

cd /usr/local/src/ModSecurity/

1	cd /usr/local/src/ModSecurity/

Шаг 2: Установка зависимостей libmodsecurity3

Для компиляции libmodsecurity3 требуется несколько зависимостей. Установите их с помощью следующей команды:

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

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

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

Далее инициализируйте и обновите подмодули Git с помощью следующих команд:

git submodule init
git submodule update

1 2	git submodule init git submodule update

Шаг 3: Создание среды ModSecurity

Теперь, когда мы подготовили наше рабочее пространство, пришло время создать среду ModSecurity. Сначала запустите сценарий сборки:

./build.sh

1	./build.sh

Затем настройте окружение:

./configure

1	./configure

Во время этого процесса вы можете столкнуться с ошибкой fatal: No names found, cannot describe anything. Не волнуйтесь, это сообщение об ошибке можно смело игнорировать.

Шаг 4: Компиляция исходного кода ModSecurity

Собрав и настроив окружение для libmodsecurity3, мы готовы скомпилировать его. Вот команда для этого:

make

make

Для тех, кто работает на высокопроизводительных серверах, вы можете ускорить процесс компиляции, запустив make с опцией -j, за которой следует число ядер процессора вашего сервера. Например, если ваш сервер имеет шесть процессорных ядер, вы можете использовать:

make -j 4

make -j 4

Шаг 5: Установка скомпилированного кода

После компиляции исходного кода последним шагом будет его установка:

sudo make install

1	sudo make install

Эта команда устанавливает libmodsecurity3 в каталог /usr/local/modsecurity/, на который вы будете ссылаться далее в этом руководстве.

Установка коннектора ModSecurity-nginx

В этом разделе мы проведем вас через процесс установки коннектора ModSecurity-nginx. Этот важный компонент служит связующим звеном между Nginx, популярным веб-сервером, и ModSecurity, обеспечивая бесперебойную связь между ними.

Шаг 1: Клонирование репозитория ModSecurity-nginx

Прежде всего, нам необходимо получить исходный код коннектора ModSecurity-nginx. Для этого мы клонируем репозиторий с GitHub. Аналогично предыдущему шагу клонирования репозитория libmodsecurity3, используйте следующую команду для клонирования репозитория ModSecurity-nginx:

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

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

Эта команда получает только последнюю ревизию репозитория ModSecurity-nginx, что позволяет экономить пропускную способность и дисковое пространство.

Шаг 2: Установка зависимостей ModSecurity-nginx

Далее нам нужно перейти в исходный каталог Nginx. Это можно сделать, выполнив следующую команду cd:

cd /usr/local/src/nginx/nginx-1.*.*

1	cd /usr/local/src/nginx/nginx-1..

В исходном каталоге Nginx мы установим зависимости, необходимые для коннектора ModSecurity-nginx. Выполните эту команду для получения и установки необходимых зависимостей:

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

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

Шаг 3: Компиляция коннектора ModSecurity-nginx

Когда все зависимости установлены, мы можем приступить к компиляции коннектора ModSecurity-nginx. Для этого нам нужно выполнить команду configure с флагом --with-compat и опцией --add-dynamic-module:

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

1	./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Флаг --with-compat обеспечивает совместимость с различными системами, а опция --add-dynamic-module определяет расположение коннектора ModSecurity-nginx.

После настройки среды создайте динамические модули, выполнив команду make:

make modules

1	make modules

Шаг 4: Перемещение динамического модуля

Последним шагом в этом процессе является перемещение динамического модуля в соответствующую директорию. Команда make modules создает динамический модуль в каталоге objs/ngx_http_modsecurity_module.so. Вам необходимо переместить этот модуль в каталог /etc/nginx/modules/. Для этого выполните следующую команду:

sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

1	sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

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

Настройка коннектора ModSecurity-nginx в Nginx

После успешной установки коннектора ModSecurity-nginx следующим шагом будет его загрузка в Nginx и соответствующая настройка. Для этого необходимо отредактировать конфигурационный файл Nginx, расположенный по адресу /etc/nginx/nginx.conf, что обеспечит работу ModSecurity с вашим веб-сервером Nginx.

Шаг 1: Включение ModSecurity в nginx.conf

Для начала вам необходимо указать расположение модуля ModSecurity в файле nginx.conf. Для этого откройте файл nginx.conf с помощью текстового редактора. Для этого примера мы будем использовать nano:

sudo nano /etc/nginx/nginx.conf

1	sudo nano /etc/nginx/nginx.conf

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

load_module modules/ngx_http_modsecurity_module.so;

1	load_module modules/ngx_http_modsecurity_module.so;

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

Далее добавьте следующий код в раздел http {}:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

1 2	modsecurity on; modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

Приведенные выше команды включают ModSecurity и указывают расположение файла правил ModSecurity. Сохраните изменения (Ctrl+O) и выйдите из файла (Ctrl+X).

Шаг 2: Создание и настройка каталога и файлов для ModSecurity

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

sudo mkdir /etc/nginx/modsec/

1	sudo mkdir /etc/nginx/modsec/

Затем скопируйте пример конфигурационного файла ModSecurity из клонированной директории Git в только что созданную директорию:

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

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

Теперь давайте изменим файл modsecurity.conf. По умолчанию механизм правил ModSecurity работает в режиме DetectionOnly, который обнаруживает вредоносное поведение, но не блокирует его. Чтобы изменить это поведение, откройте файл modsecurity.conf:

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

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

Найдите строку SecRuleEngine DetectionOnly и измените ее на:

SecRuleEngine On

1	SecRuleEngine On

Далее найдите строку SecAuditLogParts:

# Записывать в журнал все, что мы знаем о транзакции.
SecAuditLogParts ABIJDEFHZ

1 2	# Записывать в журнал все, что мы знаем о транзакции. SecAuditLogParts ABIJDEFHZ

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

SecAuditLogParts ABCEFHJKZ

1	SecAuditLogParts ABCEFHJKZ

Теперь сохраните (Ctrl+O) и выйдите (Ctrl+X) из файла.

Шаг 3: Создание файла modsec-config.conf

Следующим шагом будет создание файла modsec-config.conf. Этот файл будет включать файл modsecurity.conf и другие наборы правил, такие как OWASP CRS, позже. Создайте и откройте файл с помощью этой команды:

sudo nano /etc/nginx/modsec/modsec-config.conf

1	sudo nano /etc/nginx/modsec/modsec-config.conf

Находясь внутри файла, добавьте следующую строку:

Include /etc/nginx/modsec/modsecurity.conf

1	Include /etc/nginx/modsec/modsecurity.conf

Сохраните (Ctrl+O) и выйдите (Ctrl+X) из файла.

Наконец, скопируйте файл modSecurity unicode.mapping с помощью команды cp:

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

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

Шаг 4: Проверка конфигурации

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

sudo nginx -t

1	sudo nginx -t

Если все настроено правильно, вы должны увидеть следующее сообщение:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

1 2	nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

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

Шаг 5: Применение изменений конфигурации

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

Используйте команду systemctl для перезапуска службы Nginx:

sudo systemctl restart nginx

1	sudo systemctl restart nginx

Эта команда предписывает вашей системе остановить, а затем немедленно запустить службу Nginx. После этого в службе Nginx должен быть включен и работать WAF ModSecurity.

Развертывание набора основных правил OWASP для ModSecurity

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

OWASP CRS - это широко признанный и уважаемый набор правил для брандмауэров веб-приложений (WAF). Эти правила действуют как надежный защитный барьер против большинства возникающих угроз в Интернете, выявляя потенциальные атаки и блокируя их. Это фундаментальный ресурс, на котором основывают свои правила многие аналогичные системы, и, приняв его, вы уже находитесь на верном пути к защите своего сервера.

Шаг 1: Доступ к каталогу ModSecurity

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

cd /etc/nginx/modsec

1	cd /etc/nginx/modsec

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

sudo chown -R $USER:$USER /etc/nginx/modsec/

1	sudo chown -R $USER:$USER /etc/nginx/modsec/

Шаг 2: Загрузка архива OWASP CRS

Далее мы загрузим архив OWASP CRS с помощью команды wget. На момент написания статьи последней стабильной версией является 3.3.5, но вы должны проверить последнюю версию на странице OWASP Release tag.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.zip

1	wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.zip

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

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.tar.gz

1	wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.tar.gz

Шаг 3: Распаковка архива CRS

После завершения загрузки распакуйте архив с помощью команды tar:

tar -xvf v3.3.4.tar.gz

1	tar -xvf v3.3.4.tar.gz

Не забудьте заменить v3.3.4.tar.gz на имя файла, который вы скачали, если вы используете другую версию.

Шаг 4: Настройка CRS

Как и конфигурация ModSecurity, с которой мы имели дело ранее, OWASP CRS поставляется с образцом конфигурационного файла, который нам нужно переименовать. Используя команду cp, мы создадим копию этого файла, сохранив оригинал в качестве резервной копии:

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

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

Шаг 5: Включение правил OWASP CRS

Чтобы включить правила OWASP CRS, нам нужно изменить файл modsec-config.conf:

sudo nano /etc/nginx/modsec/modsec-config.conf

1	sudo nano /etc/nginx/modsec/modsec-config.conf

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

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

1 2	Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.conf

Сохраните файл (CTRL+O) и выйдите (CTRL+T).

Не забудьте заменить coreruleset-3.3.4 на версию, которую вы скачали, если она отличается.

Сохраните изменения (Ctrl+O) и выйдите из текстового редактора (Ctrl+X).

sudo nginx -t

1	sudo nginx -t

Шаг 6: Проверка конфигурации и перезапуск Nginx

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

Чтобы выполнить этот "пробный запуск", используйте следующую команду:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

1 2	nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

Это сообщение говорит нам о том, что наша конфигурация верна и что наши изменения не нарушат работу сервиса.

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

После успешного пробного запуска мы готовы к внедрению этих изменений. Чтобы новая конфигурация вступила в силу, нам нужно перезапустить службу Nginx:

sudo systemctl restart nginx

1	sudo systemctl restart nginx

Понимание и использование набора основных правил OWASP

После установки и настройки ModSecurity и набора основных правил OWASP (CRS) на вашем веб-сервере Nginx пришло время углубиться в понимание и использование CRS. CRS богат опциями, и, хотя настройки по умолчанию обеспечивают немедленную защиту широкого спектра для большинства серверов, тщательное изучение его возможностей поможет вам настроить его функциональность в соответствии с вашими конкретными потребностями.

Навигация по конфигурации CRS

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

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

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

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

Режимы подсчета баллов в OWASP CRS

CRS работает с использованием системы оценок. Существует два основных режима работы:

Режим оценки аномалий (Anomaly Scoring Mode)

# -- [[ Anomaly Scoring Mode (default) ]] --

1	# -- [[ Anomaly Scoring Mode (default) ]] --

Это режим по умолчанию и рекомендуемый режим. В этом режиме каждое правило, соответствующее запросу или ответу, увеличивает "балл аномалии". После того, как все входящие и исходящие правила будут оценены, общий балл аномалий сверяется с пороговым значением. Если показатель превышает пороговое значение, предпринимается разрушительное действие (по умолчанию возвращается ошибка HTTP 403). Этот режим обеспечивает большую гибкость в настройке политик блокирования и создает высокоинформативные журналы аудита.

Самодостаточный режим

# -- [[ Self-Contained Mode ]] --

1	# -- [[ Self-Contained Mode ]] --

В этом режиме соответствующее правило приводит к немедленному действию, прекращая дальнейшую оценку. Хотя этот режим может снизить использование ресурсов, он предлагает меньшую гибкость в политике блокирования и менее информативные журналы аудита. В журнал записывается только первая обнаруженная угроза, как во многих системах обнаружения вторжений (IDS).

В целом, режим оценки аномалий рекомендуется для большинства пользователей из-за его гибкости и информативности.

Уровни паранойи: Баланс между безопасностью и удобством использования

Уникальной особенностью CRS являются уровни паранойи. Эти уровни позволяют вам контролировать, сколько проверок правил вносят вклад в оценку аномалий, позволяя, по сути, настраивать чувствительность CRS.

Существует четыре уровня паранойи:

Уровень паранойи 1: Это уровень по умолчанию, рекомендуемый для большинства пользователей. Он включает большинство основных правил и должен редко вызывать ложные срабатывания (FPs), или легитимные запросы ошибочно идентифицируются как вредоносные.
Уровень паранойи 2: Этот уровень предназначен для опытных пользователей и включает дополнительные правила, такие как защита от SQL- и XSS-инъекций на основе регекса. На этом уровне возможны некоторые ложные срабатывания.
Уровень паранойи 3: Для опытных пользователей этот уровень включает еще больше правил и ограничений на использование специальных символов. На этом уровне ожидается больше ложных срабатываний.
Уровень паранойи 4: Рекомендуется только в исключительных случаях. Этот уровень еще больше ограничивает специальные символы и, скорее всего, приведет к большому количеству ложных срабатываний.

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

Настройка правил OWASP CRS (дополнительное обучение)

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

Открытие файлов правил

Файлы правил расположены в каталоге rules в каталоге coreruleset-3.3.4. Эти файлы содержат наборы правил, которые CRS использует для проверки входящего и исходящего HTTP-трафика. Вы можете открыть эти файлы, чтобы просмотреть существующие правила и добавить свои собственные правила.

sudo nano /etc/nginx/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

1	sudo nano /etc/nginx/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Это откроет файл, содержащий правила исключения, которые обрабатываются перед правилами CRS.

Понимание структуры правил

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

SecRule ARGS "@rx attack" "id:1234,phase:2,t:none,log,deny,msg:'Attempted attack'"

1	SecRule ARGS "@rx attack" "id:1234,phase:2,t:none,log,deny,msg:'Attempted attack'"

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

SecRule: Директива, с которой начинается правило.
ARGS: Переменная, которую нужно проверить. ARGS относится ко всем аргументам, включая GET, POST и cookies.
"@rx attack": Оператор и его аргумент. @rx - это регулярное выражение, а attack - шаблон для проверки.
"id:1234,phase:2,t:none,log,deny,msg:'Attempted attack'": Список действий правила. Он включает в себя уникальный идентификатор правила, фазу, в которой действует правило, преобразования, которые нужно применить (t:none означает отсутствие преобразований), действие, которое нужно предпринять, если правило соответствует (в данном случае зарегистрировать событие и отклонить запрос), и сообщение, которое нужно записать в журнал, если правило соответствует.

Создание пользовательских правил

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

SecRule REQUEST_HEADERS:User-Agent "@rx suspicious-user-agent" "id:1235,phase:1,t:none,log,deny,msg:'Suspicious User-Agent Detected'"

1	SecRule REQUEST_HEADERS:User-Agent "@rx suspicious-user-agent" "id:1235,phase:1,t:none,log,deny,msg:'Suspicious User-Agent Detected'"

Это правило будет блокировать любой запрос, включающий строку 'suspicious-user-agent' в заголовке user-agent.

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

Проверка внедрения OWASP CRS

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

Выполнение тестового запроса

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

https://www.yourdomain.com/index.html?exec=/bin/bash

Замените yourdomain.com на ваше реальное доменное имя. Этот URL пытается передать команду /bin/bash через параметр exec в строке запроса.

Интерпретация ответа

Если OWASP CRS правильно настроен и работает, он должен определить этот вредоносный запрос и ответить ошибкой 403 Forbidden. Эта ошибка означает, что сервер понял запрос, но отказывается его авторизовать, что в данном случае является результатом нарушения правила ModSecurity.

Если вы получаете эту ошибку, это означает, что ModSecurity и OWASP CRS правильно настроены и активно защищают ваш сервер от вредоносных запросов.

Устранение неполадок

Если вы не получаете ошибку 403 Forbidden, это указывает на то, что что-то не так. Самая распространенная проблема - забыть переключить ModSecurity из режима DetectionOnly в On. Режим DetectionOnly регистрирует угрозы, но не блокирует их. Убедитесь, что вы сделали это изменение, как указано ранее в руководстве.

Управление ложными срабатываниями и исключениями пользовательских правил

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

Борьба с ложными срабатываниями

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

Исключение распространенных ложных срабатываний

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

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

#SecAction \

# "id:900130,\

# phase:1,\

# nolog,\

# pass,\

# t:none,\

# setvar:tx.crs_exclusions_cpanel=1,\

# setvar:tx.crs_exclusions_dokuwiki=1,\

# setvar:tx.crs_exclusions_drupal=1,\

# setvar:tx.crs_exclusions_nextcloud=1,\

# setvar:tx.crs_exclusions_phpbb=1,\

# setvar:tx.crs_exclusions_phpmyadmin=1,\

# setvar:tx.crs_exclusions_wordpress=1,\

# setvar:tx.crs_exclusions_xenforo=1"

Чтобы внести определенные приложения в белый список, откомментируйте соответствующие строки и оставьте номер (1) нетронутым. Для служб, которые вы не используете, например, Xenforo, измените (1) на (0). Это действие гарантирует, что вы не включите в белый список ненужные правила.

Упрощение синтаксиса

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

SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1"

SecAction \

"id:900130,\

phase:1,\

nolog,\

pass,\

t:none,\

setvar:tx.crs_exclusions_phpbb=1,\

setvar:tx.crs_exclusions_phpmyadmin=1,\

setvar:tx.crs_exclusions_wordpress=1"

Такой упрощенный синтаксис облегчает чтение и поддержку.

Работа с пользовательскими исключениями

Для работы с пользовательскими исключениями необходимо активировать специальный файл. Этот шаг включает переименование файла REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf с помощью команды cp:

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

1	sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

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

Белые списки определенных путей и IP-адресов

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

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off
SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

1 2	SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

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

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

SecRule REMOTE_ADDR "^192\.123\.4\.5" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

1	SecRule REMOTE_ADDR "^192\.123\.4\.5" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

## или ###

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 193.123.4.0/24, 10.11.12.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

1	SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 193.123.4.0/24, 10.11.12.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

В этих примерах директива @ipMatch может использоваться для составления белых списков целых подсетей, что увеличивает универсальность вашей стратегии составления белых списков. Если вам нужно внести в черный список определенный IP-адрес или подсеть, просто замените allow на deny.

Уточнение исключений из правил

Хотя белый список целых путей или IP-адресов может быть эффективен для снижения количества ложных срабатываний, он также может непреднамеренно разрешать потенциально опасные запросы. Более точный подход заключается в отключении конкретных правил, вызывающих ложные срабатывания, а не белых списков целых путей. Однако такой подход требует больше времени и тестирования для точной настройки.

Например, допустим, правила с идентификаторами 941000 и 942999 продолжают вызывать ложные срабатывания для вашей области /admin/. Вы можете отключить эти конкретные правила с помощью директивы ruleRemoveById, как показано ниже:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

1	SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

При такой конфигурации только указанные правила будут отключены для пути /admin/, сохраняя высокий уровень защиты для остальной части вашего приложения.

Реализация ротации журналов для ModSecurity

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

Создание файла ротации журналов ModSecurity

Для начала давайте создадим конфигурационный файл для процесса ротации журналов. Этот файл будет определять, как и когда происходит ротация журналов. Мы можем поместить этот файл в каталог /etc/logrotate.d/, где утилита logrotate ищет свои конфигурационные файлы.

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

sudo nano /etc/logrotate.d/modsec

1	sudo nano /etc/logrotate.d/modsec

Команда nano запускает текстовый редактор в терминале, позволяя вам напрямую создавать и редактировать файл.

Определение правил ротации журналов

Внутри этого файла мы определим правила ротации журналов ModSecurity. Скопируйте и вставьте в файл следующий блок кода:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

/var/log/modsec_audit.log

{

rotate 31

daily

missingok

compress

delaycompress

notifempty

}

Давайте разберем, что делает каждая строка в этом блоке кода:

/var/log/modsec_audit.log: Это файл, который мы хотим обработать. В нем находится журнал аудита ModSecurity.
rotate 31: Эта директива означает, что logrotate должен сохранить 31 ротируемый файл журнала, прежде чем отбрасывать самые старые.
daily: Это указание logrotate ротировать файл журнала один раз в день.
missingok: Если файл журнала отсутствует, logrotate не будет выдавать сообщение об ошибке.
compress: Эта директива указывает logrotate сжимать повернутые файлы журнала для экономии места.
delaycompress: Откладывает сжатие предыдущего файла журнала до следующего цикла ротации. Это может быть полезно, если некоторые программы все еще пишут в файл.
notifempty: Если файл журнала пуст, logrotate не будет его обрабатывать.

С этими настройками журналы ModSecurity будут ротироваться ежедневно, и вы сохраните месячный запас журналов. Однако вы можете изменить эти настройки, чтобы они лучше соответствовали вашим потребностям. Например, если вы предпочитаете хранить только недельные журналы, вы можете изменить параметр rotate 31 на rotate 7. Но имейте в виду, что для ModSecurity рекомендуется ежедневная ротация из-за потенциально большого размера журналов, а недельный файл журнала может быть довольно громоздким для управления и анализа.

Предотвращение обновлений Nginx с помощью APT-HOLD

Продвигаясь в сложном мире управления веб-серверами, важно понимать, что автоматические обновления системы, хотя в целом и полезны, иногда могут нарушить наши тщательно настроенные параметры. Это особенно верно, когда у нас есть настраиваемые или очень специфические конфигурации, как в случае с Nginx с ModSecurity. В таких случаях автоматические обновления Nginx могут потенциально перезаписать наши конфигурации или создать проблемы совместимости с текущей установкой. Следовательно, может быть полезно предотвратить автоматическое обновление Nginx. Мы можем добиться этого, используя функцию системы управления пакетами APT, известную как "APT-HOLD".

Понимание APT-HOLD

Команда apt-mark - это утилита, которая позволяет нам манипулировать статусом пакетов в системе управления пакетами APT. Одной из ее функций является опция "hold", которая может быть использована для пометки пакета как удерживаемого, что означает, что он не будет обновляться.

Применение APT-HOLD к Nginx

Чтобы поставить Nginx на удержание и тем самым предотвратить его автоматическое обновление, мы можем использовать команду apt-mark следующим образом:

sudo apt-mark hold nginx

1	sudo apt-mark hold nginx

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

Отмена APT-HOLD

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

sudo apt-mark unhold nginx

1	sudo apt-mark unhold nginx

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

Заключение

В ходе нашего совместного путешествия мы успешно установили ModSecurity 3, интегрировали его с Nginx и приняли OWASP CRS на систему Ubuntu Linux. Мы убедились, что наш веб-сервер теперь может похвастаться надежным брандмауэром с открытым исходным кодом, обеспечивающим надежную линию защиты от различных веб-атак. Это начинание, хотя и сложное, добавляет значительный уровень безопасности нашим веб-приложениям, защищая наши операции и данные.

Каждый шаг - от создания предварительных условий и установки ModSecurity до настройки Nginx и внедрения OWASP CRS - был важным элементом общей головоломки безопасности. Затем мы научились обрабатывать журналы, генерируемые ModSecurity, и управлять их размерами для оптимизации производительности. Наконец, мы нашли способ защитить нашу конкретную конфигурацию Nginx, отключив автоматические обновления. Весь этот процесс, несмотря на его подробность и тщательность, был необходим для обеспечения максимально возможной безопасности нашей конфигурации.