ModSecurity, жемчужина брандмауэров веб-приложений (WAF), усилил свою игру, выпустив третью версию ModSecurity 3. Будучи широко распространенным проектом с открытым исходным кодом, он оснащает пользователей необходимыми инструментами для защиты приложений от различных угроз безопасности. Обнаружение и предотвращение вторжений являются его основными достоинствами, при этом он может работать как отдельный инструмент или встроенный плагин.
ModSecurity 3: раскрытие мощи
ModSecurity 3, являющийся переломным в своей лиге, включает в себя несколько улучшений по сравнению со своими предшественниками:
Повышенная производительность и масштабируемость благодаря полной переработке на языке C.
Оптимизированная интеграция с веб-серверами, обеспечивающая совместимость не только с Apache, но и с NGINX и IIS.
Повышенная модульность, позволяющая функционировать как отдельная программа или как библиотека, встроенная в другое программное обеспечение.
Расширенный набор функциональных возможностей для противодействия сложным киберугрозам.
NGINX Connector: Бесшовный мост
Соединение ModSecurity 3 и NGINX стало возможным благодаря коннектору NGINX, который легко интегрирует эти две технологии. Являясь частью ModSecurity, он обеспечивает безопасную, высокопроизводительную веб-среду. Вот почему он незаменим:
- Он действует как посредник, облегчая коммуникацию между NGINX и ModSecurity.
- Он предоставляет ModSecurity доступ к HTTP-трафику, обрабатываемому NGINX.
- Он позволяет пользователям использовать возможности безопасности ModSecurity в среде NGINX.
OWASP Core Rule Set (CRS): План безопасности
Являясь маяком кибербезопасности, проект Open Web Application Security Project (OWASP) Core Rule Set (CRS) предоставляет механизм защиты широкого спектра от атак на веб-приложения. Это набор общих правил обнаружения атак, которые ModSecurity использует для защиты приложений:
- Он обеспечивает защиту от основных рисков безопасности веб-приложений, описанных в OWASP Top 10.
- Он обеспечивает механизмы обнаружения SQL Injection (SQLi), Cross-Site Scripting (XSS), Local File Inclusion (LFI) и др.
- Он поощряет проактивный подход к кибербезопасности, облегчая выявление и устранение уязвимостей.
Учитывая различные роли и возможности ModSecurity 3, NGINX Connector и OWASP CRS, интеграция этих компонентов может значительно повысить уровень безопасности ваших веб-приложений. Оставайтесь с нами, поскольку мы погрузимся в подробное руководство, которое продемонстрирует, как установить ModSecurity 3, коннектор NGINX для него и NGINX. Затем мы проведём вас через конфигурацию и установку набора правил OWASP Core Rule Set на Debian 12 Bookworm, Debian 11 Bullseye или Debian 10 Buster.
Подготовка сервера
Прежде чем приступить к установке ModSecurity, необходимо должным образом подготовить наш сервер. Это включает в себя обновление системы и обеспечение работы с последней версией NGINX, высокопроизводительного веб-сервера и обратного прокси-сервера. Эти предварительные действия создают благоприятную среду для беспроблемного процесса установки, значительно уменьшая потенциальные проблемы совместимости и устраняя уязвимости безопасности.
Шаг 1: Обновление Debian
Путь к безопасному и эффективному серверу лежит через его регулярное обновление. Регулярные обновления гарантируют, что все пакеты программного обеспечения имеют последние исправления безопасности и улучшения производительности. Чтобы поддерживать вашу систему в актуальном состоянии, выполните следующую команду:
| 1 | sudo apt update && sudo apt upgrade |
Эта команда сначала обновляет список пакетов для обновлений, гарантируя, что ваша система знает обо всех новых обновлениях (sudo apt update).
Шаг 2: Устранение существующей установки NGINX
Если у вас уже установлена NGINX, мы рекомендуем удалить ее, чтобы подготовить место для последней версии из пользовательского PPA, поддерживаемого Ондржеем Суры. Эта версия может похвастаться дополнительными динамическими модулями, такими как модуль Brotli, и обещает улучшенную компрессию.
Чтобы добиться этого, сначала остановите текущую службу NGINX с помощью:
| 1 | sudo systemctl stop nginx |
Затем удалите существующую установку NGINX с помощью:
| 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, выполните следующую команду:
| 1 | curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x |
Шаг 4: Обновление индекса пакетов
После включения нужного репозитория обновление списка источников APT становится необходимым. Этот шаг гарантирует, что система распознает новые пакеты в добавленном хранилище. Обновите список источников с помощью:
| 1 | sudo apt update |
После установки обновлений перейдите к установке NGINX, выполнив следующие действия:
| 1 | sudo apt install nginx-core nginx-common nginx |
Во время установки вы можете столкнуться с запросом на сохранение или замену существующего файла конфигурации /etc/nginx/nginx.conf. Чтобы избежать непредвиденных сбоев, рекомендуется сохранить текущий конфигурационный файл, нажав n.
Шаг 5: Интеграция исходного кода NGINX в репозиторий
По умолчанию исходный код NGINX не включается при установке из PPA. Однако для компиляции ModSecurity в последующих шагах этого руководства вам необходимо включить эту функцию, чтобы загрузить исходный код NGINX вручную.
Начните этот процесс, открыв конфигурационный файл, расположенный в /etc/apt/sources.list.d:
| 1 | sudo nano /etc/apt/sources.list.d/nginx-mainline.list |
Примечание: Это будет другое имя файла, если вы установили или имеете другой сторонний источник для вашей установки Nginx.
Теперь добавьте следующую строку непосредственно под строкой исходного кода:
| 1 | deb-src [signed-by=/usr/share/keyrings/deb.sury.org-nginx-mainline.gpg] https://packages.sury.org/nginx-mainline/ bookworm main |
После завершения работы сохраните изменения, нажав CTRL+O, а затем выйдите из редактора, нажав CTRL+X.
Чтобы завершить этот этап, обновите список репозиториев с помощью:
| 1 | sudo apt update |
Эта команда гарантирует, что ваша система распознает включение исходного кода NGINX в репозиторий, делая его доступным для последующих операций.
Получение исходного кода Nginx
Для того чтобы установить тесную интеграцию между ModSecurity и Nginx, нам необходимо скомпилировать динамический модуль ModSecurity, используя исходный код Nginx. Для этого нам необходимо получить и сохранить исходный код Nginx в определенном каталоге (для наших целей он будет обозначен как /usr/local/src/nginx). В этом разделе мы шаг за шагом проведем вас через процесс создания необходимых каталогов, установки зависимостей, получения исходного кода и, наконец, проверки того, что полученная версия исходного кода соответствует версии Nginx, установленной в вашей системе.
Шаг 1: Настройка структуры каталогов
Первоначально необходимо создать каталог, в котором мы будем получать и хранить исходный код Nginx. Для создания каталога и последующего перехода в него используется следующая команда:
| 1 | sudo mkdir /usr/local/src/nginx && cd /usr/local/src/nginx |
Эта команда выполняет двойную функцию - сначала формирует каталог /usr/local/src/nginx, а затем изменяет текущий рабочий каталог на этот свежесозданный каталог.
Шаг 2: Установка зависимостей и получение исходного кода
Перед загрузкой исходного кода нам необходимо установить пакет dpkg-dev. Этот пакет включает в себя множество инструментов разработки, которые необходимы для распаковки, конструирования и загрузки исходных пакетов Debian. Его можно установить с помощью команды:
| 1 | sudo apt install dpkg-dev -y |
Установив необходимые инструменты, мы теперь готовы получить исходный код Nginx. Его можно получить с помощью команды:
| 1 | sudo apt source nginx |
Если при выполнении этой команды вы встретите какое-либо сообщение об ошибке, не волнуйтесь; сообщение об ошибке можно смело игнорировать.
Шаг 3: Проверка исходной версии
После загрузки исходного кода крайне важно убедиться, что загруженная версия исходного кода синхронизирована с версией Nginx, установленной в вашей системе. Любое расхождение между этими версиями может вызвать проблемы совместимости, поэтому этот шаг проверки является обязательным.
Для начала перечислите файлы в текущем каталоге, чтобы убедиться, что исходный код был загружен:
| 1 | ls |
В результате должно появиться несколько файлов и каталогов, относящихся к Nginx.
Затем убедитесь, что версия исходного пакета совпадает с версией Nginx, установленной в вашей системе Debian. Установленную версию Nginx можно проверить с помощью команды:
| 1 | nginx -v |
В результате вы получите проект установленной версии Nginx. Очень важно убедиться, что эта версия соответствует исходной версии, которую вы загрузили. Если они не совпадают, вам нужно будет получить правильную версию исходного кода Nginx.
Настройка libmodsecurity3 для ModSecurity
ModSecurity функционирует как надежный брандмауэр для веб-приложений, а libmodsecurity3 выступает в качестве его центрального компонента для облегчения фильтрации HTTP. Эта часть руководства посвящена помощи в приобретении и настройке этого важного программного пакета.
Шаг 1: Получение репозитория ModSecurity
Для начала работы необходимо получить исходный код libmodsecurity3 из его репозитория на GitHub. Для этого мы будем использовать Git, широко распространенную систему контроля версий. Если Git еще не установлен в вашей системе, для его установки можно воспользоваться следующей командой:
| 1 | sudo apt install git |
Прежде чем приступить к клонированию репозитория, рекомендуется изменить права собственности на каталог, чтобы избежать необходимости использования привилегий root (sudo) для большинства команд:
| 1 | sudo chown -R $USER:$USER /usr/local/src/ |
Эта команда рекурсивно изменяет право собственности на каталог /usr/local/src/ на текущего пользователя.
Следующий шаг включает клонирование репозитория libmodsecurity3. Мы выполним неглубокое клонирование (-depth 1) для экономии пропускной способности и памяти, подразумевая, что мы получим только последнюю ревизию ветки v3/master:
| 1 | git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/ |
После клонирования репозитория переключите свой рабочий каталог на новый клонированный репозиторий:
| 1 | cd /usr/local/src/ModSecurity/ |
Шаг 2: Установка зависимостей libmodsecurity3
Процесс компиляции libmodsecurity3 требует наличия нескольких зависимостей. Их можно установить, выполнив следующие действия:
| 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 libpcre2-16-0 libpcre2-dev libpcre2-posix3 -y |
Эти зависимости необходимы для успешной компиляции Nginx с ModSecurity, начиная с версии 1.21.4 и выше. Сообщалось, что в некоторых случаях этот шаг вызывает проблемы, но установка правильных зависимостей должна исправить ситуацию в большинстве случаев.
После этого инициализируйте и обновите подмодули Git с помощью следующих команд:
| 1 2 | git submodule init git submodule update |
Шаг 3: Создание среды ModSecurity
Подготовив рабочее пространство, мы можем приступить к созданию среды ModSecurity. Сначала выполните сценарий сборки:
| 1 | ./build.sh |
Затем настройте окружение:
| 1 | ./configure |
Во время этого процесса может возникнуть ошибка "fatal: No names found, cannot describe anything". Однако это сообщение об ошибке можно смело игнорировать.
Шаг 4: Компиляция исходного кода ModSecurity
Когда окружение для libmodsecurity3 создано и настроено, мы готовы к его компиляции. Для этого выполните следующую команду:
| 1 | make |
Для тех, кто работает на высокопроизводительных серверах, процесс компиляции можно ускорить, выполнив make с опцией -j, за которой следует число ядер процессора, которым обладает ваш сервер. Например, если ваш сервер оснащен шестью процессорными ядрами, команда будет выглядеть следующим образом:
| 1 | make -j 4 |
Шаг 5: Установка скомпилированного кода
Скомпилировав исходный код, мы переходим к последнему шагу, который включает в себя установку скомпилированного кода:
| 1 | sudo make install |
Эта команда установит libmodsecurity3 в каталог /usr/local/modsecurity/. Это будет каталог, на который будут ссылаться в последующих частях данного руководства.
Настройка коннектора ModSecurity-nginx
Успешная установка ModSecurity-nginx, жизненно важного посредника между широко используемым веб-сервером Nginx и ModSecurity, может значительно повысить безопасность ваших веб-приложений. В этом разделе мы проведём вас через тщательные шаги по настройке этого коннектора на вашем сервере Debian.
Шаг 1: Получение исходного кода коннектора ModSecurity-nginx
Наше путешествие начинается с получения исходного кода коннектора ModSecurity-nginx. Репозиторий GitHub предоставляет этот исходный код. Если это звучит знакомо, то это потому, что метод очень похож на предыдущий процесс, когда мы получали исходный код libmodsecurity3. Используйте следующую команду для клонирования репозитория ModSecurity-nginx:
| 1 | git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/ |
Эта команда выполняет неглубокое клонирование хранилища, забирая только последнюю ревизию. Такое эффективное клонирование позволяет сэкономить на пропускной способности и потреблении памяти.
Шаг 2: Удовлетворение зависимостей коннектора ModSecurity-nginx
После успешного извлечения исходного кода нам необходимо перейти в каталог исходных текстов Nginx. Для этого выполним команду cd следующим образом:
| 1 | cd /usr/local/src/nginx/nginx-1.*.* |
Как только мы окажемся в исходном каталоге Nginx, следующим шагом будет установка зависимостей, необходимых для коннектора ModSecurity-nginx. Следующая команда не только найдет необходимые зависимости, но и установит их:
| 1 | sudo apt build-dep nginx && sudo apt install uuid-dev |
Шаг 3: Создание коннектора ModSecurity-nginx
Когда все зависимости установлены, мы готовы к компиляции коннектора ModSecurity-nginx. Для этого нужно выполнить команду configure с флагом --with-compat и опцией --add-dynamic-module:
| 1 | ./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx |
Флаг --with-compat обеспечивает совместимость с различными системами, а опция --add-dynamic-module определяет расположение коннектора ModSecurity-nginx.
После того как окружение настроено, мы готовы к генерации динамических модулей. Для этого мы выполняем команду make следующим образом:
| 1 | make modules |
Шаг 4: Развертывание динамического модуля
Последний шаг в этом процессе установки заключается в перемещении динамического модуля в подходящую директорию. Команда make modules создает динамический модуль в каталоге objs/ngx_http_modsecurity_module.so. Очень важно переместить этот модуль в каталог /etc/nginx/modules/, что можно сделать с помощью следующей команды:
| 1 | sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/ |
Помните, что у вас есть возможность хранить динамический модуль в любом месте, при условии, что вы укажете полный путь в процессе загрузки.
В зависимости от источника установки вашего Nginx, папка может не существовать, поэтому быстро создайте ее, если вы не можете ее переместить:
| 1 | sudo mkdir /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:
| 1 | sudo nano /etc/nginx/nginx.conf |
В начале файла включите следующую строку:
| 1 | load_module modules/ngx_http_modsecurity_module.so; |
Эта директива указывает Nginx загрузить модуль ModSecurity. Если вы разместили модуль в другом месте, не забудьте указать полный путь в этой директиве.
Затем добавьте следующие директивы в блок http {}:
| 1 2 | modsecurity on; modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf; |
Приведенные выше директивы активируют ModSecurity и определяют расположение файла правил ModSecurity. Сохраните изменения (Ctrl+O), а затем закройте файл (Ctrl+X).
Шаг 2: Создание каталогов и файлов ModSecurity
Для размещения конфигурационных файлов и будущих правил необходимо создать специальный каталог. Команда ниже создаст каталог /etc/nginx/modsec:
| 1 | sudo mkdir /etc/nginx/modsec/ |
Затем скопируйте пример конфигурационного файла ModSecurity из клонированной директории Git в только что созданную директорию:
| 1 | sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf |
Теперь давайте изменим файл modsecurity.conf. По умолчанию механизм правил ModSecurity работает в режиме DetectionOnly, который идентифицирует вредоносное поведение, но воздерживается от его блокирования. Чтобы настроить это поведение, откройте файл modsecurity.conf:
| 1 | sudo nano /etc/nginx/modsec/modsecurity.conf |
Найдите строку SecRuleEngine DetectionOnly и измените ее на:
| 1 | SecRuleEngine On |
Затем найдите строку SecAuditLogParts:
| 1 2 | # Записывать в журнал все, что мы знаем о транзакции. SecAuditLogParts ABIJDEFHZ |
Текущая конфигурация неточна. Настройте строку следующим образом:
| 1 | SecAuditLogParts ABCEFHJKZ |
Теперь сохраните (Ctrl+O) и закройте (Ctrl+X) файл.
Шаг 3: Создание файла modsec-config.conf
Далее нам необходимо создать файл modsec-config.conf. Этот файл будет инкапсулировать файл modsecurity.conf и другие наборы правил, такие как OWASP CRS, на более позднем этапе. Чтобы создать и открыть файл, выполните эту команду:
| 1 | sudo nano /etc/nginx/modsec/modsec-config.conf |
После того как файл будет открыт, включите в него следующую строку:
| 1 | Include /etc/nginx/modsec/modsecurity.conf |
Сохраните (Ctrl+O) и закройте (Ctrl+X) файл.
Наконец, продублируйте файл unicode.mapping в ModSecurity с помощью команды cp:
| 1 | sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/ |
Шаг 4: Подтверждение конфигурации
Прежде чем продолжить, необходимо проверить конфигурацию. Выполните следующую команду, чтобы провести пробный запуск службы Nginx:
| 1 | sudo nginx -t |
Если все конфигурации настроены правильно, вы должны увидеть следующее сообщение:
| 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:
| 1 | sudo systemctl restart nginx |
Эта команда предписывает вашей системе остановить службу Nginx, а затем немедленно запустить ее снова. Следовательно, ваша служба Nginx теперь должна быть оснащена активированным и работающим ModSecurity WAF.
Включение набора основных правил OWASP в ModSecurity
В этом сегменте вы пройдете через процесс усиления безопасности вашего веб-сервера путем внедрения набора основных правил OWASP (CRS) для ModSecurity. Хотя ModSecurity является мощным инструментом, он не обеспечивает защиту сам по себе. Для его эффективного функционирования необходим набор правил.
OWASP CRS - это известный и надежный набор правил для брандмауэров веб-приложений (WAF). Действуя в качестве надежного защитного барьера против большинства современных угроз в Интернете, эти правила умело выявляют потенциальные атаки и предотвращают их. Этот фундаментальный ресурс является основой для многих подобных систем, и, взяв его на вооружение, вы уже начинаете путь к обеспечению безопасности своего сервера.
Шаг 1: Возвращение в каталог ModSecurity
В качестве первого шага мы вернемся к директории ModSecurity, которая была создана в предыдущих шагах. Выполните приведенную ниже команду:
| 1 | cd /etc/nginx/modsec |
Чтобы обойти необходимость использования команды sudo для последующих шагов, вы можете изменить права собственности на этот каталог на вашего текущего пользователя с помощью этой команды:
| 1 | sudo chown -R $USER:$USER /etc/nginx/modsec/ |
Шаг 2: Получение архива OWASP CRS
После этого мы получим архив OWASP CRS с помощью команды wget. Обратите внимание, что на момент написания статьи последней стабильной версией является 3.3.4, однако рекомендуется проверять актуальную версию на странице тегов OWASP Release.
| 1 | wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.tar.gz |
Если вы предпочитаете оставаться в курсе последних изменений, можно получить версию ночной сборки. Эта версия включает в себя самые последние изменения и улучшения, но может быть менее стабильной и требовать частых обновлений. Необходимо отметить, что эта версия идеально подходит для опытных пользователей:
| 1 | wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.tar.gz |
Примечание: Вам нужно будет постоянно загружать их почти ежедневно! Не забывайте об этом, если вы используете ночные правила.
Шаг 3: Распаковка архива CRS
После завершения загрузки используйте команду tar для распаковки архива:
| 1 | tar -xvf v3.3.4.tar.gz |
Убедитесь, что вы заменили v3.3.4.tar.gz на имя файла, который вы скачали, если вы используете другую версию.
Шаг 4: Настройка CRS
OWASP CRS, подобно конфигурации ModSecurity, с которой мы работали ранее, поставляется с образцом конфигурационного файла. Нам нужно переименовать этот файл. С помощью команды cp мы продублируем этот файл, сохранив оригинал для резервного копирования:
| 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:
| 1 | sudo nano /etc/nginx/modsec/modsec-config.conf |
В этом файле включите следующие две строки, чтобы включить конфигурацию и правила CRS:
| 1 2 | Include /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf Include /etc/nginx/modsec/coreruleset-3.3.4/rules/*.conf |
После этого сохраните файл (CTRL+O) и выйдите (CTRL+X).
Не забудьте заменить coreruleset-3.3.4 на версию, которую вы скачали, если она отличается.
Сохраните изменения (Ctrl+O) и выйдите из текстового редактора (Ctrl+X).
Шаг 6: Проверка конфигурации и перезагрузка Nginx
После внесения таких существенных изменений в конфигурацию Nginx, крайне важно убедиться, что все сделано правильно и не содержит синтаксических ошибок или неправильной конфигурации. Этот этап проверки служит в качестве подготовительного для фактического запуска обновленной службы.
Чтобы выполнить этот "сухой запуск", введите следующую команду:
| 1 | sudo nginx -t |
Если синтаксис конфигурационного файла правильный, вы должны увидеть следующее сообщение:
| 1 2 | nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful |
Это подтверждает, что наша конфигурация верна и что наши изменения не нарушат работу сервиса. Тем не менее, если вы встретите какие-либо сообщения об ошибках, внимательно изучите их в поисках подсказок о потенциальных проблемах. Сообщения об ошибках обычно достаточно описательны и могут направить вас к проблемному сегменту ваших конфигурационных файлов.
После успешного выполнения пробного запуска мы готовы запустить эти изменения в работу. Чтобы новая конфигурация вступила в силу, необходимо перезапустить службу Nginx:
| 1 | sudo systemctl restart nginx |
Глубокое погружение в набор основных правил OWASP
После успешной установки и настройки ModSecurity и OWASP Core Rule Set (CRS) на вашем веб-сервере Debian, пришло время углубиться во внутреннюю работу и нюансы CRS. С множеством настраиваемых опций под рукой, понимание этих функций позволит вам персонализировать защиту вашего сервера за пределами широкого спектра безопасности, предлагаемого настройками по умолчанию.
Изучение конфигурации набора основных правил
Начните это исследование с открытия файла конфигурации CRS. Здесь вы найдете множество параметров, которые можно настроить в соответствии с конкретными потребностями вашего сервера. Чтобы получить доступ к этому файлу, выполните команду:
| 1 | sudo nano /etc/nginx/modsec/coreruleset-3.3.4/crs-setup.conf |
В этом конфигурационном файле вы найдете множество настроек, каждая из которых снабжена подробными поясняющими комментариями. Этот файл - настоящий кладезь знаний. Потратить время на понимание этих параметров очень важно, чтобы получить представление о работе CRS и настроить ее в соответствии с вашими требованиями.
Понимание режимов подсчета баллов в CRS
CRS использует систему подсчета баллов для своей работы, в основном имеющую два режима:
Режим скоринга аномалий
| 1 | # -- [[ Anomaly Scoring Mode (default) ]] -- |
Этот режим, используемый по умолчанию и настоятельно рекомендуемый, использует "оценку аномалий". Каждое правило, соответствующее запросу или ответу, вносит свой вклад в этот показатель. После оценки всех входящих и исходящих правил общий показатель аномалий сравнивается с заданным порогом. Если этот показатель превышает пороговое значение, запускается деструктивное действие, обычно возвращающее ошибку HTTP 403. Этот режим обеспечивает гибкость в настройке политик блокировки и генерирует полные журналы аудита.
Самодостаточный режим
| 1 | # -- [[ Self-Contained Mode ]] -- |
В этом режиме любое совпадение правил приводит к немедленному действию, останавливая дальнейшую оценку. Этот метод может минимизировать использование ресурсов, но он обеспечивает меньшую гибкость политик блокирования и менее информативные журналы аудита. В журнал записывается только первая обнаруженная угроза, как во многих системах обнаружения вторжений (IDS).
В целом, режим оценки аномалий предпочтительнее из-за его гибкости и информативности.
Использование уровней паранойи: Баланс между безопасностью и удобством использования
Одним из уникальных аспектов CRS является концепция уровней паранойи. Эти уровни позволяют вам контролировать количество проверок правил, которые вносят вклад в оценку аномалий, по сути, настраивая чувствительность CRS.
Существует четыре уровня паранойи:
- Уровень паранойи 1: Уровень по умолчанию, наиболее подходящий для большинства пользователей. Он включает большинство основных правил и минимизирует риск ложных срабатываний, т.е. легитимные запросы ошибочно идентифицируются как вредоносные.
- Уровень паранойи 2: Этот уровень, предназначенный для опытных пользователей, включает дополнительные правила, такие как защита от SQL- и XSS-инъекций на основе regex. Этот уровень может вызвать несколько ложных срабатываний.
- Уровень паранойи 3: Этот уровень предназначен для опытных пользователей, он активирует еще больше правил и накладывает ограничения на использование специальных символов. Будьте готовы к тому, что на этом уровне будет больше ложных срабатываний.
- Уровень паранойи 4: Этот уровень рекомендуется использовать только в чрезвычайных обстоятельствах. Он еще больше ограничивает использование специальных символов и, скорее всего, приведет к значительному количеству ложных срабатываний.
Очень важно найти баланс между безопасностью и удобством использования. Хотя более высокие уровни паранойи могут обеспечить более полную безопасность, они могут мешать законному трафику, вызывая ненужные тревоги. Поэтому, если вы решите повысить уровень паранойи, вы должны быть готовы добавить правила исключения для определенных запросов и приложений, чтобы минимизировать ложные срабатывания.
Приспособление правил OWASP CRS к вашим потребностям
Универсальность OWASP CRS заключается в его способности настраивать и создавать правила в соответствии с вашими уникальными требованиями. Давайте рассмотрим, как этого можно достичь.
Доступ к файлам правил
Правила CRS находятся в каталоге rules в директории coreruleset-3.3.4. Эти файлы содержат наборы правил, используемых CRS для проверки входящего и исходящего HTTP-трафика. Чтобы просмотреть эти файлы и добавить свои собственные правила, выполните следующую команду:
| 1 | sudo nano /etc/nginx/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf |
Эта команда открывает файл, содержащий правила исключения, которые обрабатываются до правил CRS.
Расшифровка структуры правил
Каждое правило в ModSecurity имеет уникальную структуру. Вот взгляд на то, как может выглядеть типичное правило:
| 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 на наличие подозрительной строки и при обнаружении запрещать запрос:
| 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 (Core Rule Set) на вашем сервере Debian, следующим важным шагом будет обеспечение его правильной реализации и функциональности. Эта процедура позволяет нам убедиться, что правила безопасности, которые мы развернули, эффективно защищают нашу систему. Это очень важный процесс проверки, который дает нам возможность исправить любые ошибки или проблемы, которые могли возникнуть в процессе установки.
Шаг 1: Проведение тестового запроса
Для проверки эффективности нашей недавно внедренной OWASP CRS мы будем использовать специально разработанный URL, предназначенный для запуска оповещения при нарушении правил. Этот URL содержит строку запроса, которая пытается выполнить определенную команду - действие, прямо противоречащее нашим правилам безопасности.
Вот пример такого URL или IP-адреса, в зависимости от настроек вашего сервера:
| 1 | https://www.yourdomain.com/index.html?exec=/bin/bash |
или
| 1 | http://your-ip-address |
В этом URL обязательно замените yourdomain.com на ваше реальное доменное имя. Цель здесь - попытаться передать команду /bin/bash через параметр exec, встроенный в строку запроса. Если наши меры безопасности работают правильно, это действие должно быть поймано и заблокировано.
Понимание ответа сервера
Если OWASP CRS правильно настроен и работает на вашем сервере, он должен успешно перехватить этот вредоносный запрос и вернуть ошибку 403 Forbidden. Ошибка 403 Forbidden означает, что сервер понял запрос, но сознательно отказывается его авторизовать. В данном сценарии отказ связан с нарушением правила ModSecurity.
Изображение выше служит наглядным примером ожидаемого результата, а именно страницы ошибки 403 Forbidden. Если вы столкнулись с этой ошибкой при тестировании, это служит подтверждением того, что ModSecurity и OWASP CRS правильно настроены и активно защищают ваш сервер от вредоносных запросов.
Устранение неполадок
Неполучение ошибки 403 Forbidden после отправки тестового запроса - явный признак проблемы. Одна из наиболее часто встречающихся проблем - забыв переключить ModSecurity из режима DetectionOnly в On. В режиме DetectionOnly ModSecurity будет регистрировать угрозы, но не будет активно блокировать их, что создает впечатление, что наш набор правил работает некорректно.
Убедитесь, что вы переключили ModSecurity в режим On, как упоминалось ранее в этом руководстве. Эта настройка необходима для активации всех защитных возможностей ModSecurity и OWASP CRS, обеспечивая активный перехват и блокировку любых запросов, нарушающих установленные правила. Внимательно выполнив эти шаги, вы можете быть уверены, что ваш сервер надежно защищен от широкого спектра веб-атак.
Контроль ложных срабатываний и настройка исключений из пользовательских правил
При установке OWASP CRS и ModSecurity в качестве мер кибербезопасности в среде Debian, иногда можно столкнуться с ложными срабатываниями. Борьба с этими ложными срабатываниями может потребовать значительного количества вашего времени. Хотя это может показаться сложным, защита, которую она обеспечивает, часто оправдывает потраченное время.
Борьба с ложными срабатываниями
Соблюдение баланса между безопасностью и удобством использования может быть непростой задачей. Если уровень паранойи в правилах ModSecurity будет чрезмерно повышен, это может привести к всплеску ложных срабатываний. Поэтому рекомендуется инициировать работу на более низком уровне паранойи. Оставьте эту настройку на пару недель или месяцев, в течение которых вы можете столкнуться с минимальным количеством ложных срабатываний. Этот этап очень важен для лучшего понимания предупреждений и поведения системы. Когда вы освоитесь с результатами работы системы, вы сможете постепенно повышать уровень паранойи, чтобы избежать одновременного захлестывания ложными срабатываниями.
Предотвращение распространенных ложных срабатываний
ModSecurity предлагает механизм создания списка исключений для обычных действий, которые часто приводят к ложным срабатываниям. Эта функция особенно полезна для приложений, которые регулярно взаимодействуют с вашим сервером. Ниже приведен пример стандартного правила, которое формулирует такие исключения:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #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, команда будет выглядеть следующим образом:
| 1 2 3 4 5 6 7 8 9 | 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:
| 1 | sudo cp /etc/nginx/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf |
Важно отметить, что каждое правило исключения должно иметь уникальный идентификатор. Дублирование идентификатора правила приведет к ошибке на этапе тестирования службы Nginx, что может нарушить ваш рабочий процесс.
Белые списки определенных путей и IP-адресов
В некоторых сценариях определенные пути, связанные с некоторыми приложениями, могут постоянно вызывать ложные срабатывания. В таких случаях вы можете внести эти пути в белый список, чтобы предотвратить ненужные предупреждения. Вот как этого можно добиться:
| 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 предоставляет для этого соответствующие опции:
| 1 2 3 | SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off" ## или ### SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off" |
В этих примерах директива @ipMatch может быть использована для составления белых списков целых подсетей, что добавляет универсальности вашему подходу к составлению белых списков. Если вам нужно внести в черный список определенный IP-адрес или подсеть, просто замените allow на deny.
Совершенствование исключений из правил
Хотя белый список целых путей или IP-адресов может быть эффективен для снижения количества ложных срабатываний, он может непреднамеренно разрешить потенциально опасные запросы. Более тонкий подход заключается в отключении конкретных правил, вызывающих ложные срабатывания, вместо включения в белый список целых путей. Этот подход, хотя и требует больше времени и тестирования, часто оказывается более точным.
Например, если правила с идентификаторами 941000 и 942999 постоянно вызывают ложные срабатывания для вашей области /admin/, вы можете отключить эти конкретные правила, используя директиву ruleRemoveById следующим образом:
| 1 | SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999" |
В этой конфигурации только определенные правила будут отключены для пути /admin/, таким образом сохраняя высокую степень защиты для остальной части вашего приложения.
Настройка ротации журналов для ModSecurity
Правильное управление брандмауэром веб-приложений, таким как ModSecurity, подразумевает постоянное наблюдение за журналами. Со временем эти журналы могут увеличиться в размере, занимая ценное место на вашем сервере и усложняя процесс определения конкретных записей для устранения неполадок или анализа безопасности. Чтобы справиться с этой проблемой, мы настроим механизм, известный как ротация журналов.
Шаг 1: Создание файла ротации журналов ModSecurity
Первым шагом в настройке ротации журналов является создание конфигурационного файла. Этот файл будет задавать параметры ротации журналов. Он должен находиться в каталоге /etc/logrotate.d/ - именно там утилита logrotate ищет свои конфигурационные файлы.
Вы можете использовать приведенную ниже команду для создания и редактирования нового файла под названием modsec:
| 1 | sudo nano /etc/logrotate.d/modsec |
Команда nano запускает текстовый редактор терминала, позволяя мгновенно создать и изменить файл.
Шаг 2: Размещаем параметры ротации журнала
В этом файле мы собираемся установить основные правила для ротации журналов ModSecurity. Вставьте в файл следующий блок кода:
| 1 2 3 4 5 6 7 8 9 | /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". Когда мы помечаем пакет "hold", это означает, что он удерживается, то есть не будет подвергаться обновлениям.
Применение APT-HOLD к Nginx
Чтобы поставить Nginx на удержание, тем самым прекратив его автоматическое обновление, мы можем применить команду apt-mark, как показано ниже:
| 1 | sudo apt-mark hold nginx |
После выполнения этой команды система будет подавлять любые обновления для пакета Nginx до тех пор, пока вы лично не измените эту настройку. Это гарантирует, что ваша конфигурация останется неповрежденной и не будет затронута никакими автоматическими обновлениями системы.
Отмена APT-HOLD
В будущем вам может понадобиться обновить Nginx, возможно, для использования новых функций или установки исправлений безопасности. Чтобы снова разрешить обновления Nginx, вы можете снять блокировку с помощью опции unhold:
| 1 | sudo apt-mark unhold nginx |
Это действие возвращает пакет в его обычный статус, где он будет обновлен во время следующего обновления пакетов в вашей системе, когда вы будете готовы управлять потенциальными осложнениями между Nginx и ModSecurity, такими как перекомпиляция.
Заключение
В данном руководстве мы успешно справились с техническим и сложным процессом установки ModSecurity 3 и OWASP CRS на Nginx в дистрибутиве Debian. Это позволило нам существенно повысить безопасность нашего веб-сервера, обеспечив его надежными механизмами защиты от широкого спектра уязвимостей и вредоносных действий. Мы изучили такие важные аспекты, как конфигурация, настройка, протоколирование, ротация журналов и экспертная обработка обновлений пакетов для защиты наших уникальных установок. Важно понимать, что это руководство - не конец, а скорее ступенька на пути к постоянному обучению и совершенствованию навыков управления сервером.
