Для владельцев веб-серверов Apache понимание и использование возможностей ModSecurity абсолютно необходимо. Этот мощный кроссплатформенный межсетевой экран веб-приложений (WAF) с открытым исходным кодом играет ключевую роль в защите ваших веб-приложений от многочисленных угроз. В этом руководстве мы сосредоточимся на ModSecurity 2, выбор которого подкреплен весомыми причинами.
Понимание выбора: ModSecurity 2 против ModSecurity 3
ModSecurity 2 обладает рядом уникальных преимуществ, которые делают его более предпочтительным выбором по сравнению с его преемником, ModSecurity 3. Давайте рассмотрим их подробнее:
- Полная совместимость с Apache: ModSecurity 2 создан с учетом особенностей веб-серверов Apache, в отличие от ModSecurity 3, который был разработан в основном для NGINX. Это приводит к более легкому и простому процессу установки и настройки Apache при использовании ModSecurity 2.
- Проверенная надежность: Учитывая, что ModSecurity 2 предшествует своему преемнику, он был подвергнут более тщательному тестированию и отладке. В результате, он является более стабильной и надежной системой для защиты ваших веб-приложений.
- Более плавная работа со старыми версиями Debian: Особенно для Debian 11 Bullseye и Debian 10 Buster, старые версии Apache могут представлять значительные трудности для ModSecurity 3. ModSecurity 2 обходит эту проблему с помощью легкодоступных PPA-репозиториев, которые специализируются на последних пакетах Apache и зависимостях.
Эти убедительные характеристики делают ModSecurity 2 лучшим выбором для тех, кто управляет веб-серверами Apache, несмотря на существование более новой версии. Совместимость, стабильность и простота установки ModSecurity 2 идеально сочетаются с надежностью и гибкостью Apache, образуя тем самым надежную защиту от таких угроз, как SQL-инъекции, межсайтовый скриптинг (XSS) и других уязвимостей веб-приложений.
Загляните в будущее!
Мы собираемся приступить к глубокому погружению в специфику установки ModSecurity 2 на Apache для Debian 12 Bookworm, Debian 11 Bullseye и Debian 10 Buster. Наш подход будет включать использование хорошо известного PPA Эрвина Хегедюса (Ervin Hegedüs), известного разработчика CRS, мейнтейнера Debian и значительного автора кода ModSecurity. Его репозиторий специализируется на последних пакетах Apache и зависимостях, обеспечивая стратегию, которая эффективно решает общие проблемы, возникающие при сборке ModSecurity 3 в основном на Debian 11 и 10 из-за их более старых версий Apache, но также охватывает все поддерживаемые версии Debian. Итак, приготовьтесь к всестороннему путешествию по повышению безопасности вашего веб-приложения с помощью ModSecurity 2.
Установка Apache
Первым шагом будет обновление системы Debian. Это позволит обновить все существующие пакеты, обеспечить оптимальную производительность и минимизировать риски безопасности. Для этого выполните следующую команду:
| 1 | sudo apt update && sudo apt upgrade |
После обновления системы проверьте, установлен ли Apache. Если нет, используйте следующую команду для его установки:
| 1 | sudo apt install apache2 |
Интеграция модуля ModSecurity с Apache
Шаг 1: Установка необходимого репозитория
Следующей задачей в нашем списке является установка модуля ModSecurity Apache. Версия, доступная в стандартных репозиториях Debian, может быть не самой последней, и её использование может привести к немедленным ошибкам. Вместо этого мы воспользуемся сторонним репозиторием для установки последней версии модуля ModSecurity для Apache. Этот сторонний репозиторий, поддерживаемый компанией Digitalwave, известен своими стабильными двоичными файлами.
Начните с установки набора необходимых пакетов:
| 1 | sudo apt install apt-transport-https lsb-release ca-certificates curl -y |
Затем переходим к импорту GPG-ключа для репозитория:
| 1 | curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null |
После получения ключа GPG добавьте репозиторий в свою систему:
| 1 2 | echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list |
Шаг 2: Определение приоритетов нового репозитория
Теперь, когда хранилище создано, необходимо настроить политику APT, чтобы сделать приоритетным это хранилище для определенных пакетов, связанных с ModSecurity. Это можно сделать с помощью следующей команды:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity Package: *nginx* Pin: origin modsecurity.digitalwave.hu Pin-Priority: 900 Package: *libapache2-mod-security2* Pin: origin modsecurity.digitalwave.hu Pin-Priority: 900 Package: *modsecurity-crs* Pin: origin modsecurity.digitalwave.hu Pin-Priority: 900 Package: *libmodsecurity* Pin: origin modsecurity.digitalwave.hu Pin-Priority: 900 EOF |
Затем запустите обновление APT, чтобы отразить новый импортированный источник:
| 1 | sudo apt update |
Кроме того, для подтверждения предпочтений вы можете подтвердить это изменение политики с помощью:
| 1 | sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3 |
Шаг 3: Установка модуля ModSecurity
Теперь, когда репозиторий готов, приступайте к установке модуля libapache2-mod-security2:
| 1 | sudo apt install libapache2-mod-security2 |
После установки необходимо включить модуль. Для этого выполните следующую команду:
| 1 | sudo a2enmod security2 |
Шаг 4: Перезапуск службы Apache
Наконец, мы перезапускаем службу Apache, чтобы убедиться, что все изменения вступили в силу и вновь добавленный модуль ModSecurity корректно интегрирован:
| 1 | sudo nano /etc/apache2/mods-enabled/security2.conf |
Активация модуля ModSecurity
Доступ к конфигурационному файлу ModSecurity
Конфигурационный файл для Apache ModSecurity находится по адресу /etc/apache2/mods-enabled/security2.conf. Получите доступ к этому файлу с помощью текстового редактора nano (или предпочитаемого вами текстового редактора), выполнив следующую команду:
| 1 | sudo nano /etc/apache2/mods-enabled/security2.conf |
Найдите строку, которая гласит:
| 1 | IncludeOptional /etc/modsecurity/*.conf |
Убедитесь, что эта строка не закомментирована, поскольку она включает другие необходимые конфигурационные файлы из каталога /etc/modsecurity. Она должна быть некомментированной по умолчанию.
Изменение конфигурации ModSecurity
Нам нужно переименовать конфигурационный файл modsecurity.conf-рекомендации в modsecurity.conf, чтобы сделать его активным. Это можно сделать с помощью следующей команды:
| 1 | sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf |
Теперь давайте откроем этот файл конфигурации с новым именем:
| 1 | sudo nano /etc/modsecurity/modsecurity.conf |
В этом файле механизм правил ModSecurity по умолчанию установлен на DetectionOnly. Это означает, что он будет выявлять и регистрировать потенциально вредоносное поведение, не блокируя его активно. Чтобы изменить это и включить блокирующие возможности ModSecurity, найдите строку SecRuleEngine (около строки 7) и замените DetectionOnly на On.
| 1 | SecRuleEngine DetectionOnly |
на
| 1 | SecRuleEngine On |
Настройка параметров журнала
Далее в конфигурационном файле вы найдете строку SecAuditLogParts (около строки 224). Настройка по умолчанию для этой строки не совсем корректна; ее нужно настроить, чтобы точно регистрировать всю информацию о транзакциях.
Изменить:
| 1 | SecAuditLogParts ABDEFHIJZ |
На:
| 1 | SecAuditLogParts ABCEFHJKZ |
Внеся эти изменения, сохраните изменения и выйдите из редактора.
Перезапуск Apache для применения изменений
Последним шагом в этом процессе является перезапуск службы Apache, чтобы наши изменения в конфигурации ModSecurity вступили в силу. Это делается с помощью следующей команды:
| 1 | sudo systemctl restart apache2 |
Внедрение набора основных правил OWASP для ModSecurity
ModSecurity сама по себе не защитит ваш веб-сервер. Для выявления потенциальных угроз и блокирования вредоносной активности необходим набор правил. OWASP (Open Web Application Security Project) Core Rule Set (CRS) - это высоко оцененный набор правил, используемый различными веб-серверами и брандмауэрами веб-приложений (WAF).
Развертывание этого набора правил обеспечивает вашему серверу надежную защиту от целого ряда угроз, возникающих в Интернете.
Прежде чем мы продолжим, необходимо убедиться, что у вас последняя версия OWASP CRS, посетив страницу OWASP Release tag. Этот шаг гарантирует, что вы загружаете и устанавливаете самые современные меры безопасности для своего сервера.
Создание родительского каталога для OWASP
Сначала создадим главный родительский каталог для OWASP с помощью команды mkdir:
| 1 | sudo mkdir /etc/apache2/modsec/ |
Загрузка архива OWASP CRS
Далее мы воспользуемся командой wget для получения архива OWASP CRS 3.3.4, который является стабильной версией на момент написания статьи. Помните, что вы должны проверить версию по ссылке, упомянутой ранее.
| 1 | wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip |
Ночная сборка может предложить более современные меры безопасности, но может вызвать проблемы из-за своего статуса разработки. Для начинающих пользователей рекомендуется использовать стабильную версию, чтобы избежать возможных осложнений.
Распаковка архива
Загрузив архив, мы можем извлечь его в созданную ранее директорию:
| 1 | sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec |
Не забудьте изменить команды в зависимости от версии OWASP CRS, которую вы скачали.
Настройка набора правил
OWASP CRS поставляется с образцом конфигурационного файла, который необходимо переименовать для использования, сохранив оригинал в качестве резервной копии. Это можно сделать с помощью команды cp:
| 1 | sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf |
Не забудьте заменить /coreruleset-3.3.4/ на точную версию OWASP CRS, которую вы выбрали.
Включение правил
Чтобы активировать правила, откройте файл /etc/apache2/mods-enabled/security2.conf:
| 1 | sudo apt install unzip -y |
Затем вставьте следующие две строки:
| 1 2 | Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf |
Опять же, убедитесь, что вы заменили /coreruleset-3.3.4/ на точную версию OWASP CRS, которую вы выбрали.
Кроме того, закомментируйте или удалите следующую строку:
| 1 | IncludeOptional /usr/share/modsecurity-crs/*.load |
После этого сохраните и выйдите из файла.
Перезапуск Apache для применения изменений
Последний шаг - перезапустить службу Apache, чтобы изменения вступили в силу:
| 1 | sudo systemctl restart apache2 |
Знакомство с набором основных правил OWASP
OWASP Core Rule Set (CRS) - это комплексный инструмент с многочисленными настраиваемыми опциями. Его конфигурация по умолчанию обеспечивает немедленное повышение безопасности большинства серверов, не оказывая влияния на реальных посетителей или ботов поисковой оптимизации (SEO). В этом разделе мы обсудим несколько важных аспектов CRS, но всегда полезно изучить конфигурационные файлы для полного понимания всех доступных опций.
Настройка конфигурации CRS
Для начала откроем файл crs-setup.conf, в котором можно изменить большинство настроек CRS:
| 1 | sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf |
Освоение системы оценки CRS
ModSecurity работает в двух различных режимах:
- Режим оценки аномалий: Рекомендуемый для большинства пользователей, этот режим присваивает "оценку аномалии" каждый раз, когда правило совпадает. После обработки входящих и исходящих правил проверяется оценка аномалии, и при необходимости запускается действие, нарушающее работу системы. Это действие часто принимает форму ошибки 403. Этот режим обеспечивает точную информацию в журнале и предлагает большую гибкость в настройке политик блокирования.
- Самостоятельный режим: В этом режиме действие применяется мгновенно при каждом совпадении правила. Хотя этот режим может снизить использование ресурсов, он обеспечивает меньшую гибкость и дает менее информативные журналы аудита. Процесс сопоставления правил останавливается, как только встречается первое правило, и выполняется указанное действие.
Понимание уровней паранойи
OWASP CRS определяет четыре уровня паранойи:
- Уровень паранойи 1: уровень по умолчанию, подходящий для большинства пользователей.
- Уровень паранойи 2: для опытных пользователей.
- Уровень паранойи 3: Для опытных пользователей.
- Уровень паранойи 4: рекомендуется только в чрезвычайных обстоятельствах.
Более высокие уровни паранойи позволяют использовать дополнительные правила и обеспечивают повышенную безопасность, но также увеличивают вероятность блокирования легитимного трафика из-за ложных срабатываний. Важно выбрать уровень паранойи, который соответствует вашему опыту и потребностям безопасности.
Тестирование OWASP CRS на вашем сервере
Чтобы убедиться, что OWASP CRS работает правильно на вашем сервере, используйте интернет-браузер для доступа к следующему URL. Не забудьте заменить "yourdomain.com" на ваш реальный домен:
https://www.yourdomain.com/index.html?exec=/bin/bash
Если вы получаете ошибку 403 Forbidden, это означает, что OWASP CRS работает так, как ожидалось. Если нет, возможно, в процессе установки произошла ошибка, требующая вашего внимания. Наиболее распространенной проблемой может быть забывание изменить DetectionOnly на On или что-то подобное.
Борьба с ложными срабатываниями и создание пользовательских правил исключения
Борьба с ложными срабатываниями при использовании ModSecurity и OWASP CRS часто является вечной задачей. Однако защита, которую эти системы обеспечивают от различных угроз, делает усилия оправданными. Для начала мы рекомендуем поддерживать низкий уровень паранойи, чтобы уменьшить количество потенциальных ложных срабатываний.
Запуск набора правил с минимальным количеством ложных срабатываний в течение нескольких недель или даже месяцев, прежде чем повышать уровень паранойи, может предотвратить чрезмерный всплеск ложных срабатываний. Этот метод позволит вам привыкнуть к предупреждениям системы и понять, как правильно реагировать на каждое из них.
Управление ложными срабатываниями в известных приложениях
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" |
Чтобы ввести белый список для таких приложений, как WordPress, phpBB и phpMyAdmin, просто откомментируйте соответствующие строки и сохраните значение (1). Для служб, которые не используются, установите значение (0), чтобы предотвратить их включение в белый список.
Обновленная конфигурация может выглядеть следующим образом:
| 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" |
В этом случае лишние опции были удалены, оставив правильный синтаксис для нужных вам конфигураций.
Создание исключений из правил до внедрения CRS
Чтобы создать пользовательские исключения, начните с изменения имени файла REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf с помощью команды cp:
| 1 | sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf |
Помните, что каждое правило исключения должно иметь уникальный id:<номер правила>, чтобы избежать ошибок во время тестирования службы Apache2.
Например, определенные REQUEST_URI могут вызывать ложные срабатывания. Следующий пример иллюстрирует два таких сценария с участием маячка Google PageSpeed и плагина WPMU DEV для WordPress:
| 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-адреса также могут быть внесены в белый список различными способами:
| 1 2 | 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" |
В первом правиле в белый список заносится один IP-адрес, а во втором правиле используется директива @ipMatch для более широкого сопоставления подсетей. Чтобы заблокировать подсеть или IP-адрес, просто замените allow на deny. Благодаря такому уровню гибкости вы можете создавать сложные черные и белые списки и даже объединять их с Fail2Ban для более комплексной стратегии безопасности.
Отключение определенных правил
Вместо белых списков всего пути, другой подход заключается в отключении определенных правил, которые постоянно вызывают ложные срабатывания. Хотя этот метод требует больше времени и тщательного тестирования, в долгосрочной перспективе он может оказаться весьма полезным.
Допустим, правила 941000 и 942999 в области /admin/ постоянно вызывают необоснованные запреты и блокировки для вашей команды. Вы можете найти ID правила в журналах ModSecurity и отключить только это конкретное ID с помощью команды RemoveByID:
| 1 | SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999" |
Мониторинг журналов и выявление закономерностей
Когда речь идет о борьбе с ложными срабатываниями с помощью Apache, ModSecurity и OWASP, постоянный мониторинг журналов является жизненно важным. Это поможет вам обнаружить закономерности, которые сигнализируют о ложных срабатываниях. После выявления таких закономерностей вы можете создать пользовательские правила для их устранения.
Например, если вы обнаружите, что определенные правила постоянно вызывают ложные срабатывания, вы можете создать правило исключения для этих отдельных случаев. Такой подход позволяет более точно и эффективно управлять потенциальными ложными срабатываниями.
Постоянное наблюдение за журналами и точная настройка системы для решения проблем по мере их возникновения позволят вам создать более безопасную и эффективную среду для ваших приложений.
Реализация ротации журналов для ModSecurity
Из-за динамичного характера веб-транзакций журналы ModSecurity могут быстро накапливаться, что требует эффективной стратегии управления журналами. Ротация журналов, которая не настроена по умолчанию в ModSecurity, служит мощным инструментом для эффективного управления этими журналами. В этом разделе мы проведем вас через процесс настройки ротации журналов для ModSecurity.
Шаг 1: Создание файла ротации ModSecurity
Во-первых, нам нужно создать новый файл специально для ротации ModSecurity. Для этого с помощью команды nano создайте и откройте новый файл с именем modsec:
| 1 | sudo nano /etc/logrotate.d/modsec |
Шаг 2: Настройка файла ротации
Во вновь созданном файле modsec введите следующую конфигурацию:
| 1 2 3 4 5 6 7 8 9 | /var/log/modsec_audit.log { rotate 31 daily missingok compress delaycompress notifempty } |
Эта конфигурация предписывает системе хранить журналы в течение 31 дня. Однако длительность хранения очень гибкая и может быть изменена в зависимости от ваших конкретных потребностей. Например, если вы хотите хранить журналы в течение более короткого периода, вы можете просто заменить 31 на желаемое количество дней, например 7 для хранения журналов в течение недели.
В данной настройке daily обеспечивает ежедневную ротацию журналов ModSecurity. Директива compress активирует сжатие старых файлов журналов для экономии места, а delaycompress откладывает сжатие до второго цикла ротации. Опция missingok предотвращает ошибку, если файл журнала отсутствует, а notifempty гарантирует отсутствие ротации, если файл журнала пуст.
Обычно рекомендуется ротировать журналы ежедневно, так как прочесывание большого файла журнала, охватывающего целую неделю, может оказаться сложной задачей.
Важность ротации журналов
Настройка ротации журналов помогает вам поддерживать чистую и управляемую среду ведения журналов ModSecurity. Она гарантирует, что старые журналы систематически сжимаются и в конечном итоге удаляются, тем самым упрощая задачу анализа журналов и устранения любых потенциальных проблем. Таким образом, ротация журналов является неотъемлемой частью эффективного управления журналами в ModSecurity.
Заключение
В заключение, установка и настройка ModSecurity 2 с Apache и OWASP Core Rule Set на Debian 10 (Buster), Debian 11 (Bullseye) или Debian 12 (Bookworm) - это процесс, требующий точности, но повышенная безопасность, которую он обеспечивает, делает усилия оправданными. От установки и начальной настройки ModSecurity до интеграции с OWASP Core Rule Set, каждый шаг повышает устойчивость вашего сервера к вредоносному веб-трафику. Мы рассмотрели стратегии минимизации ложных срабатываний, которые могут быть постоянной проблемой в такой динамичной системе, а также обратили внимание на важность эффективного управления журналами путем их ротации. Эти знания позволят вам поддерживать высокий уровень безопасности, обеспечивая при этом бесперебойную работу пользователей.