Как установить ModSecurity (mod_security) на Apache (на Windows)

Два нуля
Фоторобот со спины
Идём
Что земля
Мне шесть футов глубины
Со льдом

(Секвойя & ОКовцур — "Хамелеон")

Если вас интересует установка ModSecurity (mod_security) на Apache под Linux, то обратитесь к статье "Как усилить веб-сервер Apache с помощью mod_security и mod_evasive на CentOS".

Что такое ModSecurity?

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

Насколько эффективен ModSecurity?

Это важный и сложный вопрос. В статьях по анализу безопасности веб-приложений и сервисов большое количество примеров несовершенства файервол для веб-приложений, советов как обойти их фильтрацию. Более того, просто установить WAF не всегда достаточно — его ещё нужно правильно настроить. Это как с файерволом (брандмаузером) на домашнем компьютере — важен не только факт его наличия, но и правильная настройка: доверенные приложения должны иметь доступ в сеть, для их нормальной работы, а подозрительные приложения не должны. Возвращаясь с книгам и статьям по анализу безопасности веб-сайтов и веб-серверов, общий вывод, который можно сделать из них, заключается в том, что файервол для веб-приложений в любом случае значительно усложняет задачу нападающему. Ему необходимо перебирать множество вариантов, искать существующие прорехи. Т.е. WAF лучше иметь, чем не иметь. По крайней мере, его бесплатную версию.

Кому нужен ModSecurity — файервол для веб-приложений (WAF)?

Файервол для веб-приложений, ModSecurity в частности, может пригодиться в следующих случаях:

  • ваш веб-сервер является открытым и доступен другим компьютерам в сети (неважно, только в локальной или в глобальном Интернете);
  • ваш локалхост не доступен другим, но вы хотите проверить, как ваши веб-сайты будут работать за файерволом;
  • вы арендуете виртуальный сервер и самостоятельно всё настраиваете — не забудьте установить файервол для веб-приложений! Это точно не будет лишним.

Может возникнуть вопрос, зачем мне на локальном сервере, пусть даже открытом для других, нужна защита? У меня там, может, ничего и ценного-то нет. Чтобы показать, хотя бы одну из неочевидных возможностей Apache я сделал вот такой файлик. Распакуйте и положите loader.php в корневую директорию вашего сервера и перейдите по адресу http://localhost/loader.php. В открывшемся окне браузера вы увидите всего три надписи:

2

Кликайте на них и они будут делать именно то, что там написано, т. е. покажут содержимое вашего каталога C:Users:

3

Покажут содержимое каталога C:Windows:

4

И покажут корневой каталог диска C::

5

Т.е. злоумышленник, который получил доступ к Apache или сумел закачать свои скрипты или же воспользовался уязвимостью ваших сайтов сможет: смотреть, копировать, удалять, скачивать и закачивать что угодно на вашем компьютере. Лучше всё-таки обезопасить себя.

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

Предполагается, что вы устанавливали и настраивали свой веб-сервер по этой инструкции. Если это не так, то путь к папке Apache у вас будет свой.

Устанавливаем ModSecurity на Apache под Windows

В первую очередь, сделайте бэкап каталога с сервером, который расположен в C:Serverbin. На самом деле, изменения мы будет вносить только в Apache, поэтому достаточно сделать копию папки C:ServerbinApache24.

Я всегда скачиваю программы для установки только с официальных сайтов, поэтому переходим на официальный сайт ModSecurity. Переходим в раздел Get Code, там доступны скомпилированные файлы и исходный код и также команды для установки ModSecurity на Linux. Первый сюрприз, который нас ждёт, заключается в том, что нет версии для Apache. Для IIS есть, а для Apache нет!

1

В правой стороне есть ссылки на репозитории сообществ, в том числе есть ссылка на хорошо нам знакомый Apache Lounge — именно здесь мы брали сервер Apache для устновки под Windows. Переходим на страницу скачивания (это ссылка для 64-битных версий) и видим ссылку на модули для Apache 2.4 win64. Модулей много, у каждого есть краткое описание. Нас в данный момент интересует файл mod_security-2.9.0-win64.zip, скачиваем его.

Распаковываем скаченный файл mod_security-2.9.0-win64.zip, в нём есть два каталога. Первый — mlogc — содержит программу mlogc (полное название ModSecurity Log Collector), она является дополнением к ModSecurity и может быть использована для переправки логов аудита в реальном времени на удалённый сервер логгирования. Нам этот каталог не понадобиться.

Мы переходим в папку mod_security. Файл mod_security2.so копируем в каталог C:ServerbinApache24modules, а файлы yajl.dll и libcurl.dll копируем в каталог C:ServerbinApache24bin.

Открываем файл C:ServerbinApache24confhttpd.conf и дописываем туда:

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so

Для проверки работы ModSecurity дописываем ещё три строчки:

SecRuleEngine On
SecDefaultAction "deny,phase:2,status:403"
SecRule ARGS "../" "t:normalizePathWin,id:50904,severity:4,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,msg:'Drive Access'"

6

Сохраняем и закрываем этот файл, перезапускам Apache.

Помните наш проверочный файл http://localhost/loader.php? Давайте попробуем ещё раз посмотреть каталог ./../../../../../../../../../:

7

Это не получилось, т. к. ModSecurity уже работает.

Включение базовых правил ModSecurity

Но работает одно единственное правило, у нас не установлена защита ни от межсайтового скриптинга, ни от инжектов в базы данных. Чтобы установить эти правила фильтрации возвращаемся на сайт modsecurity.org и переходим в раздел Get Rules. Нам на выбор предлагаются бесплатные и платные правила. Я даже не буду рассматривать разницу между ними, т. к. увидев цену платных правил, я полностью потерял к ним интерес:

8

В бесплатных правилах нам обещают наличие:

  • защита протокола HTTP
  • защиту в реальном времени по чёрному списку
  • защиту HTTP от DdoS
  • общую защиту от веб атак
  • выявление и сокрытие ошибок

Самое важно и интересное здесь уже есть. А без разных сканеров вирусов, вебшелов и бэкдоров, репутаций IP, выявления зловредных веб приложений большинство как-нибудь обойдётся.

Чтобы получить бесплатные правила нас отправляют на сайт проекта OWASP:

9

В правой стороне ищем ссылку и скачиваем архив.

Распаковываем скаченный архив. Переходим в каталог C:ServerbinApache24conf и создаём там папку crs, заходим в эту папку и копируем туда файл modsecurity_crs_10_setup.conf.example. Теперь этот же файл переименовываем в modsecurity_crs_10_setup.conf (т. е. убираем «.example» из имени). В каталоге C:ServerbinApache24confcrs создаём ещё один каталог activated_rules. В этот каталог копируем содержимое папки base_rules.

Возвращаемся к файлу C:ServerbinApache24confhttpd.conf и удаляем строчки

SecRuleEngine On
SecDefaultAction "deny,phase:2,status:403"
SecRule ARGS "../" "t:normalizePathWin,id:50904,severity:4,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,msg:'Drive Access'"

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

Вместо них добавляем строки:

Include conf/modsecurity.conf
SecRuleEngine On

<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.conf
Include conf/crs/activated_rules/*.conf
</IfModule>

Получается:

11

Сохраняем и закрываем этот файл. 

Переходим в каталог C:ServerbinApache24logs и создаём там пустой файл modsec_audit.log

Возвращаемся к распакованному архиву с ModSecurity, ищем файл mod_security-2.9.0-win64mod_securitymod_securitymodsecurity.conf-recommended и переименовываем его в modsecurity.conf. Теперь перемещаем его в каталог C:ServerbinApache24conf. Теперь открываем этот файл любым текстовым редактором и ищем там строчку (она почти в самом конце):

SecUnicodeMapFile unicode.mapping 20127 

Закомментируем её, т.е. поставим перед ней символ #, чтобы получилось так:

#SecUnicodeMapFile unicode.mapping 20127 

Теперь ищем строчку (она чуть повыше):

SecAuditLog /var/log/modsec_audit.log

и заменяем её на:

SecAuditLog logs/modsec_audit.log

Т.е. в общей сложности должно получиться так:

12

Перезапускаем сервер, пробуем наш страшный файл http://localhost/loader.php, опять пробуем «Показать каталог ./../../../../../../../../../», если видим «Ошибка: [object Object]», значит ModSecurity работает. Посмотрите файл C:ServerbinApache24logsmodsec_audit.log там одна единственная проверка сгенерировала 1.8 килобайт информации. Для тех, кто любит изучать логи, информации достаточно.   

Дополнительные правила ModSecurity

В каталог C:ServerbinApache24confcrsactivated_rules можно копировать дополнительные правила из папок experimental_rules, optional_rules, slr_rules. Чтобы эти правила вступили в действие, нужно каждый раз перезапускать сервер. У меня не получились просто взять и скопировать все доступные правила в каталог activated_rules — чтобы работала вся защита, т. к. сервер оказывался запускаться — некоторые правила (либо их сочетания) не дают запуститься серверу.

Послесловие

1. Можно ли расслабиться и больше не думать о безопасности, если установлен ModSecurity? Нет, нет и нет! Помните наш тестовый файлик? Он по-прежнему имеет доступ к папкам C:Users: и C:Windows: на вашем компьютере (т. к. Apache запущен от имени администратора). Кроме файервола веб-приложений нужно также:

  • запускать процесс сервера не от имени администратора;
  • правильно устанавливать права и разрешения на папки и файлы;
  • своевременно обновлять компоненты сервера;
  • своевременно ставить «заплатки» для операционной системы;
  • обновлять сторонние скрипты (phpMyAdmin, CMS и пр.) — в них регулярно находят дыры и выкладывают обновлённые версии;
  • при написании собственного кода проверять/фильтровать входящие данные и пр. — т. е. не писать «дырявый» код. Нельзя надеяться только на ModSecurity — у хакеров в рукавах десятки приёмов по обходу файерволов веб-приложений.
  • проводить аудит безопасности (и сервера и скриптов на нём) с помощью сканеров уязвимости, например, Kali Linux;
  • делать бэкапы! Не так страшно всё потерять, если это всё потом можно вернуть.

2. Хотелось бы вернуться к директиве #SecUnicodeMapFile unicode.mapping 20127, если кто-то знает, что туда нужно писать для кириллицы чтобы заработало, то пишите в комментариях внизу.

3. Если кто-то исследовал, почему сервер не запускается с некоторыми дополнительными правилами, насколько эти правила интересны, что в них нужно поменять, чтобы заставить работать и т.д. — делитесь своими наблюдениями. Совместными усилиями мы сможем "выжать" максимум из ModSecurity.


Следующим шагом, после настройки и тестирования сайта на локалхосте, является выбор качественного и дешёвого интернет хостинга. Я перебрал довольно много решений и нашёл очень хороший вариант — 100 рублей в месяц! За эти деньги даётся профессиональный хостинг, с отличным аптаймом, с бесплатным доменом второго уровня в подарок (!), с 2 гигабайтами места на SSD диске, с неограниченным количеством баз данных, с возможностью подключать неограниченное количество новых доменов (платить придётся только за каждый новый домен — 139 рублей). Вообще, всего хорошего так много, что проще всего посмотреть это здесь.

Кстати, а ведь как здорово иметь собственное доменное имя! Хотя бы для того, чтобы сделать для себя красивый почтовый ящик, вместо чего-нибудь вроде [email protected] Вот здесь можно найти свой собственный домен. Например, я получил бесплатно домен codeby.net, я могу делать почтовые ящики: ad[email protected][email protected][email protected] и так далее — количество ящиков ничем не ограничено!

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

Поделитесь этой статьёй с друзьями, если хотите выхода новых статей:

15 комментариев к “Как установить ModSecurity (mod_security) на Apache (на Windows)”

  1. После добавления, указанных в статье строчек в файл httpd.conf, сервер не запускается.

    Пишет: «The requested operation has failed!».

    Ответить
    • Причем в папку C:ServerbinApache24confcrsactivated_rules добавил только файлы из папки base_rules.

      После того, как в httpd.conf добавил:

      Include conf/modsecurity.conf
      SecRuleEngine On
       
      <IfModule security2_module>
      Include conf/crs/modsecurity_crs_10_setup.conf
      Include conf/crs/activated_rules/*.conf
      </IfModule>

      Перестал запускаться сервер.

      Ответить
  2. пробую настроить мод на локалхосте. после добавления в конфиг httpd.conf строчки — SecRule ARGS "../" "t:normalizePathWin,id:50904,severity:4,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,msg:'Drive Access'"  апач перестаёт запускаться, пишет — "The requested operation has failed!"

    Ответить
  3. Друзья, всё починили — теперь всё работает!

    Инструкция чуть поправлена. Теперь, чтобы работало, нам нужен самый свежий Apache 2.4 VC14, который был скомпилирован в Windows® Visual Studio C++ 2015 RC aka VC14. Он появился только 31 мая 2015.

    Как всегда, скачиваем его здесь http://www.apachelounge.com/download/

    mod_security обновился до версии 2.9.0 и он также собран в новом компиляторе. Его скачиваем там же.

    С mod_security теперь поставляется новый бинарник — libcurl.dll, его, как и файл yajl.dll, нужно копировать в каталог Апачи bin.

    Всё остальное без изменений. Теперь снова всё работает как часы — только что проверил.

    Ответить
  4. Здраствуйте после установки и настройки ModSecurity всё вродебы зделал по инструкциисервер запускается но войти не могу,появляется вот такое сообщение.

    Forbidden

    You don't have permission to access /phpmyadmin/index.php on this server.

    как исправить падскажите

     

    Ответить
  5. Это оказалось совсем непростым вопросом. По началу, я пытался перенастроить совместную работу phpMyAdmin и ModSecurity (отключить некоторые функции phpMyAdmin, отключить некоторые правила ModSecurity и т.д.). Но потерпел в этом неудачу: нужно переписывать половину phpMyAdmin или отключать много правил ModSecurity.

    В качестве очень простого, но не очень правильного решения можно исключить весь phpMyAdmin из проверок ModSecurity.

    В каталоге C:ServerbinApache24confcrsactivated_rules создайте файл modsecurity_crs_60_custom.conf. В этот файл скопируйте строку

    SecRule REQUEST_URI ^/phpMyAdmin "phase:1,id:'981207',allow,ctl:ruleEngine=off"  

    И перезапустите сервер.

    Думаю, понятно в чём неправильность этого решения:

    • На сервере целый каталог, в котором может твориться вообще что угодно без ведома ModSecurity
    • phpMyAdmin не защищён с помощью ModSecurity

    Можно сделать более тонкую настройку, исключить из проверки ModSecurity только конкретные файлы, а также отключить правила ModSecurity, которые вызывают ложные срабатывания.

    Один из примеров такого правила в файле modsecurity_crs_50_outbound.conf (строка 39):

    SecRule RESPONSE_BODY "<%" "phase:4,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',chain,t:none,capture,ctl:auditLogParts=+E,block,msg:'ASP/JSP source code leakage',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',id:'970903',tag:'OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP',tag:'WASCTC/WASC-13',tag:'OWASP_TOP_10/A6',tag:'PCI/6.5.6',severity:'3'" 

    Называется «утечка кода ASP, JSP». Поскольку никакого кода ASP, JSP на наших серверах нет, а правило срабатывает на последовательность символов <%, то его нужно отключать и т.д.

    Ответить
  6. По вашей инструкции исключил весь phpMyAdmin из проверок ModSecurity,но проблема не исчезла,вылазит всё тоже сообщение

    Forbidden

    You don't have permission to access /phpmyadmin/index.php on this server.

    А сделать более тонкую настройку, исключить из проверки ModSecurity только конкретные файлы, а также отключить правила ModSecurity, которые вызывают ложные срабатывания у меня не получается,если можно объясните по подробней как и какие провила можно отключить и какие файлы можно исключить из проверки.

    Ответить
    • Почистите кукиз для локалхоста — всё заработает (в кукиз "SQL-bинъекция").

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

      Ответить
  7. Такая же проблема, почистил куки, получилось зайти на phpadmin, но просто на localhost пишет нет доступа, что делать?

    Ответить
    • А если просто Apache отключить, не заробит? У меня на локалхосте сайт недоделанный, если с mode_security столько проблем, можно попробовать отрубить через консоль c:\Server\bin\Apache24\bin\httpd.exe -k stop.

      Ответить
  8. Заработало! Уху. По инструкции создал папку «modsecurity_crs_60_custom.conf» в каталоге activated_rules и написал SecRule REQUEST_URI ^/ «phase:1,id:’981207′,allow,ctl:ruleEngine=off». Удалил /phpMyAdmin после REQUEST_URI и все заработало.

    Ответить

Оставьте комментарий