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

The Codeby — одна из сильнейших Red Team в RU сегменте. Команда профессионалов, специализирующаяся на аудите информационных систем и тестировании на проникновение.

Мы предлагаем: Аудит веб-сайта компании, Аудит внешнего периметра, Аудит веб-приложения, Аудит внутренней корпоративной сети, Проверка ИБ-грамотности сотрудников, Анализ кода ПО, Аудит Wi-Fi и СКУД, Выявление уязвимостей ПО серверов и рабочих станций, Пентест инфраструктуры методом черного ящика. Подробнее .

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

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

Если вас интересует установка 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. В открывшемся окне браузера вы увидите всего три надписи:

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

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

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

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

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

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

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

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

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

В правой стороне есть ссылки на репозитории сообществ, в том числе есть ссылка на хорошо нам знакомый 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 и дописываем туда:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перезапускаем сервер, пробуем наш страшный файл 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, я могу делать почтовые ящики: [email protected], [email protected], [email protected] и так далее — количество ящиков ничем не ограничено!

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

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

Установка и настройка mod_security на Apache в Debian и Ubuntu

mod_security – это свободный фаервол веб-приложений (англ. Web Application Firewall, или WAF) для Apache, Nginx и IIS, который предоставляет гибкую систему правил для выполнения операций разного уровня сложности. Кроме того, mod_security поставляется с набором базовых правил фильтрации Core Rule Set (или CRS), среди которых есть правила для защиты от инъекций SQL, межсайтового скриптинга, троянов, ботов, захватов сеанса и многих других атак и взломов. В Apache mod_security является одним из дополнительных модулей, благодаря чему его легко установить и настроить.

Примечание: для выполнения данного руководства нужно предварительно установить программный стек LAMP.

Установка mod_security

ModSecurity можно скачать из стандартных репозиториев Debian/Ubuntu:

apt-get install libapache2-modsecurity

Убедитесь, что mod_security был загружен:

apachectl -M | grep —color security

Если на экране появился модуль по имени security2_module (shared), значит, все прошло успешно.

Установка ModSecurity включает в себя конфигурационный файл, который нужно переименовать:

Затем перезапустите Apache:

service apache2 reload

В каталоге логов Apache можно найти новый лог-файл для mod_security.

# ls -l /var/log/apache2/modsec_audit.log
-rw-r—— 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log

Настройка mod_security

Для корректной работы установка mod_security «из коробки» нуждается в дополнительной настройке. Стандартный конфигурационный файл настроен на DetectionOnly, то есть, фаервол только отслеживает логи, при этом ничего не блокируя. Чтобы изменить это поведение, отредактируйте файл modsecurity.conf:

Найдите в файле строку:

И измените ее так:

Примечание: при настройке mod_security на производственном сервере рекомендуется изменить эту директиву только после тестирования всех установленных правил.

Следующая директива, которую нужно отредактировать – это SecResponseBodyAccess. Она отвечает за буферизацию тела ответа; ее рекомендуется включать, только если требуется обнаружение и предохранение от утечки данных. Включенная директива (SecResponseBodyAccess On) не только будет использовать больше ресурсов сервера, но и увеличит размер лог-файла, следовательно, ее желательно отключить. Для этого найдите:

И измените значение:

Теперь нужно ограничить максимальный объем данных, который можно передать веб-приложению. За это отвечают 2 директивы:

Директива SecRequestBodyLimit задает максимальный размер данных POST. Если клиент отправляет больше данных, сервер выдаст ошибку 413 Request Entity Too Large. Если в веб-приложении нет механизма загрузки файлов, это значение можно существенно уменьшить. В конфигурационном файле задано следующее:

Что равно 12.5 мегабайтам.

Аналогично работает и директива SecRequestBodyNoFilesLimit. Разница только в том, что данная директива ограничивает размер данных POST за вычетом размера файлов.

Примечание: данное значение рекомендуется устанавливать по принципу ALARP (англ. «as low as reasonably practicable», то есть, исходя из оценки риска и задействованных ресурсов).

По умолчанию в конфигурационном файле задано:

Что равно 128KB.

В данном файле можно найти еще один параметр, влияющий на производительность сервера – это SecRequestBodyInMemoryLimit. Этот параметр задает размер данных тела ответа, который будет помещен в RAM; остальные данные отправятся на жесткий диск (как swap). Поскольку серверы, как правило, работают на SSD, это не проблема; однако, чтобы сэкономить RAM, значение можно уменьшить.

Это стандартное значение (128KB) в конфигурационном файле.

Проверка на инъекции SQL

Прежде чем определить политику фаервола при помощи правил, нужно создать PHP-скрипт, уязвимый к инъекциям SQL (SQL injection). Обратите внимание: это базовый логин скрипт PHP без обработки сессий. Не забудьте заменить пароль MySQL в нижеприведенном скрипте своим паролем.