Установка на сервер под управлением ModSecurity

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

ModSecurity (ака mod_security или mod_sec)

ModSecurity — это файерволл веб-приложений с открытым исходным кодом, который работает как модуль сервера Apache. Он реализует комплексный набор правил, которые реализуют основные методы защиты, тем самым помогая закрыть общие вопросы безопасности веб-приложений. Он устанавливает внешний уровень безопасности, который повышает уровень защиты, обнаруживает и предотвращает атаки до того, как они дойдут до веб-приложения. Он обычно доступен в системах cPanel, как EasyApache модуль. Это зарекомендовавший себя защитный модуль, который действительно может помочь защитить ваш сайт от общих атак.

Мы обсудим ModSecurity здесь, потому что проблема множественных запросов в админке MODX Revolution может касаться правил mod_security.

Тихий убийца

Менеджер MODX может просто спокойно сломаться, если одно из его действий заблокировал mod_security. Знай свой сервер! Проверьте логи ошибок Apache! Ваше здравомыслие поставлено на карту!

Как мне узнать, установлен ли у меня ModSecurity?

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

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

Проверим на WHM сервере

Многие VPS включают WHM/cPanel панели администрирования. Относительно легко увидеть, работает ли mod_security на WHM сервере.

  1. Войдите в свою панель WHM (как правило https://yousite.com:2087/)
  2. Найдите раздел "Плагины" в левом меню
  3. Если ModSecurity установлен, вы увидите Mod Security в списке ваших плагинов

Удобный cPanel/WHM mod_security модуль доступен для визуального редактирования правил: http://configserver.com/

Проверка с помощью командной строки

Если у вас есть SSH доступ к серверу, вы можете проверить, какие модули Apache загружаются при загрузке системы. Чтобы вывести, какие модули загружаются в Apache, вы можете использовать утилиту apachectl на *NIX системах, например:

apachectl -t -D DUMP_MODULES

Или, если вашей команды apachectl нет в ьекущем $PATH, то вам, возможно, потребуется указать полный путь к утилите. Чтобы найти путь можно использовать команду find:

find / -name apachectl

Затем, как только вы нашли полный путь к программе, вы можете выполнить команду с полным путем, например:

/usr/local/apache/bin/apachectl -t -D DUMP_MODULES

Выведется что-то вроде этого:

Loaded Modules:
  core_module (static)
  rewrite_module (static)
  so_module (static)
  suphp_module (shared)
  security2_module (shared)  # <--- это и есть ModSecurity
 mod_security модуль в списке как security2_module

Другие способы

Если у вас нет утилиты apachectl или вы не можете ее найти, вы можете вручную проверить файлы конфигурации Apache. Он может быть сконфигурирован по-разному на разных серверах, но в целом, Apache так устроен, что загружает основной файл конфигурации, затем сканирует дополнительные каталоги для включения дополнительных файлов конфигурации.

  1. Проверьте главный файл Apache (часто внутри /etc/httpd, т.е. /etc/httpd/conf/httpd.conf)
  2. Проверьте дополнительные директории с конфигурациями (часто внутри вложенных директорий в директории с основной конфигурацией)

Файлы логов

После того, как вы убедились в том, что ModSecurity работает, вы вероятно захотите проверить ваши логи, чтобы увидеть, что для действий админки MODX на самом деле отключена "сигнализация". Лучше всего это делать с помощью командной строки: используйте SSH для входа на сервер и убедитесь, что у вас есть соответствующий доступ (например, привилегии супервользователя - root) для просмотра файлов логов.

Главный лог, который вы хотите проверить - это лог ошибок сервера Apache. Точное расположение настраивается в файле конфигруации Apache, но часто он находится внутри /usr/local/apache/logs/error_log Лучше всего для просмотра файла использовать утилиту tail. Вы можете следить за файлом в реальном времени используя флаг -f, например:

tail -f /usr/local/apache/logs/error_log

Держите это окно октрытым пока вы ходите по админке MODX и ловите ошибки, если они появятся в этом файле. (Нажмите Ctrl+C чтобы закрыть программу)

Вы также можете посмотреть содержимое лога mod_security. Опять же, расположение настраивается, но часто он хранится в /usr/local/apache/logs/modsec_audit.log

Пример ошибки

Если вы увидели, что ошибки были записаны в логе ошибок Apache при попытке выполнить определенные действия в админке MODX, очень высока вероятность, что это ModSecurity помешал вам работать в админке.

Вот пример ошибки в логе ошибок Apache:

[Sat Nov 19 19:16:32 2011] [error] [client 123.123.123.123] ModSecurity: Access denied with code 500 (phase 2).
Pattern match "(insert+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk+
insert|union.+select|convert.+(.*from)" at ARGS:els. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "359"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "yoursite.com"] [uri "/connectors/element/tv.php"] [unique_id "TshG4EWntHMAAAfIFmUAAAAI"]

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

[id "300016"]
[hostname "yoursite.com"]
[uri "/connectors/element/tv.php"]

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

Белый список правил для домена

Белый список правил для конкретного домена создается путем включения файла (include) в основной конфиг. Это займет несколько шагов, чтобы сделать все осторожно.

Пересборка (rebuild) конфигруации Apache

Первое, что нужно сделать, это создать резервную копию и пересобрать httpd.conf, чтобы убедиться, что ошибок нет. (выполнить следующие команды по одному разу каждую)

cd /usr/local/apache/conf
cp -p httpd.conf httpd.conf.backup

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

/scripts/rebuildhttpdconf

 Здесь цель - перед тем, как пытаться что-то изменить, убедиться, что существующая конфигурация Apache забекаплена и работает.

Редактирование файлов виртуальных хостов

Многие панели (включая cPanel) не хотят, чтобы вы писали напрямую в основной файл конфигурации Apache. Вместо этого вы будете редактировать файл виртуального хоста для заданного домена. Посмотрите в файл основной конфигурации Apache (httpd.conf) и поищите по вашему доменному имени и вы увидите, где берется файл настроек для вашего домена. Вы должны найти пути к нему внутри секции VirtualHost.

<VirtualHost 123.123.123.123>
  ServerName yoursite.com
  ServerAlias www.yoursite.com
  DocumentRoot /home/youruser/public_html
  # ... more stuff here ...
  Include "/usr/local/apache/conf/userdata/std/2/yoursite/*.conf"
  Include "/usr/local/apache/conf/userdata/std/2/yoursite/yoursite.com/*.conf"
</VirtualHost>

Основываясь на этом определении виртуального хоста (VirtualHost) мы можем найти ссылки на 2 директории:

  • /usr/local/apache/conf/userdata/std/2/yoursite/
  • /usr/local/apache/conf/userdata/std/2/yoursite/yoursite.com/

Вы так же можете вставить расширеные правила для сервера в файл:

  • /usr/local/apache/conf/modsec2/whitelist.conf

Вот где Apache будет искать дополнительные настройки. Если вы это знаете, вам не нужно беспокоиться о дополнительных файлах конфигурации и вы можете перейти к следующему разделу и просто добавить правила в белый список. Если вы работаете на сервере с cPanel или используете другой тип панели, где вы либо не можете либо не должны редактировать основной файл httpd.conf напрямую, то вы должны поместить свои правила в отдельный файл конфигурации. Вам может понадобиться создать каталоги, перечисленные выше или возможно вам придется немного больше покопаться в документации, чтобы выяснить, где Apache будет искать дополнительные файлы конфигурации.

Добавление правил в белый список

Общий пример

В общем виде правило белого списка выглядит так:

<LocationMatch "/path/to/URI">
  <IfModule mod_security2.c>
    SecRuleRemoveById (Rule number)
    SecRuleRemoveById (Rule number, if more for this domain
    SecRuleRemoveById (etc)
    SecRuleRemoveById (etc)
  </IfModule>
</LocationMatch>

Вы можете изменить этот список и добавить его в свое значение директвы VirtualHosts (как в основной файл httpd.conf, так и внутрь внешних файлов vhosts.conf). Во время загрузки Apache белый список правил будет зарегистрирован.

Конкретный пример

Давайте рассмотрим наш прошлый пример сообщения об ошибке:

[id "300016"]
[hostname "yoursite.com"]
[uri "/connectors/element/tv.php"]

Нам следовало бы пойти и отредактровать директиву VirtualHosts для yoursite.com, добавив правило вроде следующего:

<LocationMatch "/connectors/element/tv.php">
  <IfModule mod_security2.c>
    SecRuleRemoveById 300016
  </IfModule>
</LocationMatch>

Обратите внимание, что правило ссылается на MODX коннекторы по их путям и при этом ссылается на ModSecurity правила по их идентификаторам.

Остерегайтесь переноса своего сайта

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

Расширение примера

Это может сводить с ума - прокликивать все функции админки MODX каждый раз. Что говорить уже, если у нас целый набор каталогов. Рассмотрим переименование директории "connectors" (смотри Hardening MODX Revolution)

<LocationMatch "/manager/index.php">
  SecRuleRemoveById 300016
</LocationMatch>

<LocationMatch "/connectors/resource/index.php">
  SecRuleRemoveById 300013 300014 300015 300016
</LocationMatch>

<LocationMatch "/connectors/element/tv.php">
  SecRuleRemoveById 300013 300016
</LocationMatch>

Перезапуск Apache

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

cPanel: пересборка (rebild) файла конфигурации

Если у вас нет cPanel на сервере, пропустите этот шаг и просто перезапустите Apache.
Включите cPanel сервер, если вы хотите повторно запустить утилиту rebuildhttpdconf:

cd /usr/local/apache/conf
/scripts/rebuildhttpdconf

Затем вы можете проверить все, чтобы убедиться, что внесенные изменения в ваших внешних файлах были включены в основной файл (опять же, это только при установленно cPanel: cPanel собирает внешние конфигурации в главной файле httpd.conf). Попробуйте просмотреть файл, чтобы увидеть, что то, что вы написали во внешнием файле теперь включено в основной.

Перезапуск Apache

Как только правки были сделаны, перезапустите процесс Apache:

/etc/init.d/httpd restart

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

Статические ресурсы

 ModSecurity может повлиять на ваши статически ресурсы в MODX (или любые другие скрипты, которые читаются для загрузки пользователями). Что может произойти, если ваш файл слишком велик? Загрузка будет прервана раньше времени и в итоге вы получите поврежденный файл. Часто размер загруженного файла ограничивается 64Кб, хотя исходный файл может быть значительно больше. Если вы столкнулись с таким, есть большая вероятность, что мешает ModSecurity. Записей в логах может не быть (!), так что может быть трудно отследить такое поведение ModSeciruty!

В WHM вы можете изменить настройки конфигурации ModSecurity, нажав на кнопку-ссылку плагина "Mod Security" (на картинке выше на этой странице) и нажать кнопку "Редактировать конфиг" (Edit Config).

Детали конфигурации, которые могут повлиять на ваши загрузки:

  • SecRequestBodyAccess
  • SecRequestBodyLimit
  • SecRequestBodyInMemoryLimit

Простое решение заключается в обходе ModSecurity, исключив правила для загрузки. Как-т так:

SecRequestBodyAccess Off

Смотрите http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/modsecurity2-apache-reference.html более подробную информацию о различных параметрах конфигурации.

Еще одной причиной загадочного симптома может быть конфликт между веб-серверами: например, у вас есть Apache и NGINX, установленные на том же сервере. Убедитесь, что они оба не используют GZIP сжатие - результат очень похож на вмешательство ModSecurity! Если NGINX сжимает большие статические ресурсы, а затем Apache так же пытается сжать их, усилия будут безрезультатными и файл закачается с обрезкой до 64Кб.

  • Реклама

  • Недавние публикации

  • Недавние комментарии

© 2011 — 2014 MODX Беларусь
По всем вопросам обращаться в компанию Alroniks Experts