Настройка ModSecurity с Apache на системах Debian/Ubuntu

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

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

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

ModSecurity 3

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

Инсталлируйте ModSecurity для Apache на системах Debian/Ubuntu.

Модуль ModSecurity для Apache доступен в стандартных репозиториях Debian и Ubuntu. Для его установки выполните

sudo apt install libapache2-mod-security2

После этого активируйте данный модуль.

sudo a2enmod security2

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

sudo systemctl restart apache2

Конфигурируйте ModSecurity.

В конфигурационном файле /etc/apache2/mods-enabled/security2.conf расположена следующая строка.

IncludeOptional /etc/modsecurity/*.conf

sudo a2enmod security2

.» width=»701″ height=»255″ />

Это подразумевает, что Apache будет загружать все файлы с расширением *.conf из директории /etc/modsecurity/. Для того чтобы файл modsecurity.conf-recommended начал функционировать, его необходимо переименовать.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

После этого откройте данный файл в текстовом редакторе командной строки, например, в Nano.

sudo nano /etc/modsecurity/modsecurity.conf

Определите следующую последовательность.

SecRuleEngine DetectionOnly

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

SecRuleEngine On

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

SecAuditLogParts ABDEFHIJZ

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

SecAuditLogParts ABCEFHJKZ

Сохраните изменения в файле и закройте его. После этого перезапустите Apache, чтобы изменения начали действовать. (Простой перезапуск веб-сервера не подойдет.)

sudo systemctl restart apache2

Настройка набора правил OWASP Core (CRS)

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

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

При установке ModSecurity из официального репозитория Debian/Ubuntu также автоматически устанавливается пакет modsecurity-crs как зависимость. Этот пакет включает в себя набор правил ядра OWASP версии 3.x, однако он может не обновляться. Если безопасность для вас имеет значение, стоит использовать актуальную версию набора правил ядра.

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

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

Извлеките документ.

tar xvf v3.3.0.tar.gz

Организуйте каталог для размещения файлов CRS.

sudo mkdir /etc/apache2/modsecurity-crs/

Перенесите извлечённый каталог в директорию /etc/apache2/modsecurity-crs/.

sudo mv coreruleset-3.3.0/ /etc/apache2/modsecurity-crs/

Откройте этот каталог.

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.0/

Поменяйте имя файла crs-setup.conf.example.

sudo mv crs-setup.conf.example crs-setup.conf

Внесите изменения в файл /etc/apache2/mods-enabled/security2.conf.

sudo nano /etc/apache2/mods-enabled/security2.conf

Определите следующую команду, которая загружает стандартные файлы CRS.

IncludeOptional /usr/share/modsecurity-crs/*.load

Замените её на следующую, чтобы применялся самый актуальный набор правил OWASP CRS.

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/*.conf

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

sudo apache2ctl - t

Если синтаксис корректен, выполните перезапуск Apache.

sudo systemctl restart apache2

Погрузитесь в понимание функционирования OWASP CRS.

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

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf

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

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

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

• Уровень паранойи 1 (стандартный)
• Степень тревожности 2
• Степень подозрительности: 3
• Степень настороженности 4.

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

Перед использованием CRS необходимо разобраться с двумя ключевыми понятиями. Теперь можно закрыть файл. Все индивидуальные правила CRS находятся в директории /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/. Каждое подходящее правило повышает показатель аномалии.

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

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

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

При корректной работе ModSecurity ваш веб-сервер Apache должен выдавать сообщение об ошибке 403, указывающее на запрет доступа.

В журнале аудита (/var/log/apache2/modsec_audit.log) можно найти следующую запись в секции H, указывающую на то, что ModSecurity выявил и предотвратил эту SQL-инъекцию с помощью OWASP CRS v3.3.0.

Действие: Перехвачено (фаза 2)

Когда ModSecurity функционирует в режиме лишь для обнаружения, он не сможет предотвратить данную SQL-инъекцию.

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

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

• Журнал отладки: по умолчанию не активирован.
• журнал проверок: /var/log/apache2/modsec_audit.log

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

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

Существуют два вида файлов для ведения журнала.

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

События в журнале организованы по различным разделам.

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

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

sudo nano /etc/logrotate. d/modsecurity

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

/var/log/apache2/modsec_audit.log

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

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

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

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

Исключения для правил, которые относятся к конкретному приложению.

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

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf

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

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

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

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

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

sudo apache2ctl - t

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

sudo systemctl restart apache2

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

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/

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

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

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

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

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

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

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

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

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

sudo apache2ctl - t

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

sudo systemctl restart apache2

Исключения для правил, установленных пользователем.

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

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

.

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

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

.

и

.

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

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

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

sudo apache2ctl - t

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

sudo systemctl restart apache2

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

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

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

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

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

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

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

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

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

sudo apache2ctl - t

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

sudo systemctl restart apache2

Последовательность правил

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

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

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

Интеграция ModSecurity с проектом Honeypot.

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

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

Для использования Project Honeypot необходимо сначала зарегистрироваться на его сайте и создать бесплатную учетную запись. После этого зайдите в панель управления аккаунтом и выберите ссылку для получения доступа к HTTP-черному списку.

После этого внесите изменения в файл crs-setup.conf.

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf

Найдите следующие строки.

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

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

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

sudo systemctl restart apache2

Теперь ModSecurity будет обращаться к Project Honeypot для каждого HTTP-запроса. Чтобы убедиться в его работе, внесите изменения в файл crs-setup.conf.

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf

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

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

Закройте и сохраните файл. Убедитесь в правильности настроек Apache.

sudo apache2ctl - t

После этого перезапустите Apache.

sudo systemctl restart apache2

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

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

Ваш веб-сервер Apache должен выдать ответ 403 (запрещено), поскольку IP-адрес числится в базе данных Project Honeypot.

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

По умолчанию ModSecurity активирован для всех виртуальных хостов Apache. Чтобы отключить ModSecurity для определённого виртуального хоста, вам нужно внести изменения в файл виртуального хоста (/etc/apache2/sites-enabled/example.com.conf) и добавить следующую строку в соответствующий контекст...

SecRuleEngine DetectionOnly

Для применения изменений перезапустите Apache.

sudo systemctl reload apache2

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

Необходимо обновить основной набор правил с выходом новой версии. Этот процесс достаточно прост.

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

Затем проверьте настройки Apache.

sudo apache2ctl - t

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

sudo systemctl restart apache2

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

Следующий этап.

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

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

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