Сегодня уже невозможно представить себе Internet без интерактивного Web-содержимого, размещенного на различных информационных порталах, форумах, в онлайн-играх и других проектах. Большинство онлайн-проектов строится на основе динамических Web-приложений, которые постоянно совершенствуются, обрастают новыми функциями и становятся все более сложными в поддержке и разработке.

Современное развитие технологии Web-служб страдает от несовершенства стандартов безопасного программирования Web-приложений, что приводит к ошибкам в разработке программного обеспечения и появлению уязвимых мест в Web-службах, использующих эти приложения. Ситуация осложняется тем, что доступ к Web-службам, как правило, разрешен для любого пользователя Internet, а Web-приложение может быть легко скомпрометировано без привлечения специализированных средств, с помощью одного только браузера. По статистике компании Positive Technologies за 2006 г., слабо защищенными оказались 80% исследованных Web-сайтов (см. http://www.ptsecurity.ru/webstat2006.asp).  

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

Защита уязвимых Web-приложений может осуществляться либо путем устранения уязвимых мест в Web-приложении, либо с помощью специализированных средств защиты Web-приложений. Слабые места Web-приложения можно устранить посредством тщательного анализа исходного кода приложения на предмет ошибок либо периодически выполняя тесты на проникновение. Как правило, эти способы защиты оказываются очень трудоемкими и дорогостоящими.

Специализированные средства защиты Web Application Firewall (WAF) — это межсетевые экраны, работающие на прикладном уровне и осуществляющие фильтрацию трафика Web-приложений. Такие средства не требуют изменений в исходном коде Web-приложения и, как правило, защищают Web-службы гораздо лучше обычных межсетевых экранов и средств обнаружения вторжений. Сообщество Web Application Security Consortium даже выпустило методику тестирования средств защиты, использующих технологии WAF (http://www.webappsec.org/projects/wafec/). Одним из таких средств защиты является модуль ModSecurity для Web-сервера Apache, о котором и пойдет речь в данной статье.

Описание ModSecurity

Программа ModSecurity — это межсетевой экран с открытым исходным кодом Web-приложений. Продукт защищает от ряда атак, направленных на Web-приложения, позволяет осуществлять мониторинг HTTP-трафика и выполнять анализ событий в реальном времени.

Существует два типовых варианта установки ModSecurity:

  • установка непосредственно на Web-сервер (рис. 1);
  • установка в качестве обратного proxy-сервера Reverse Proxy (рис. 2).

Рисунок 1. Установка ModSecurity на Web-сервер

Рисунок 2. Установка ModSecurity в качестве Reverse Proxy

Надо сказать, что ModSecurity используется только с Web-серверами Apache, желательно версий 2.x. Сервер Apache может работать как под Linux/UNIX, так и под Windows (http://httpd.apache.org). Mодуль ModSecurity изначально создавался под Linux/UNIX (http://www.modsecurity.org), но благодаря работе Стефана Лэнда был успешно портирован под Microsoft Windows (http://www.apachelounge.com). Сравним, чем отличается установка ModSecurity непосредственно на Web-сервер от установки в качестве обратного proxy.

В первом случае ModSecurity перехватывает все запросы к Web-серверу, на котором он установлен: запрос от клиента сначала сравнивается с правилами фильтрации модуля ModSecurity, а затем передается на дальнейшую обработку Web-серверу. ModSecurity также может контролировать ответы Web-сервера, т.е. после формирования страницы ответ обрабатывается модулем и в соответствии с правилами блокирует или разрешает прохождение ответа Web-сервера. Последний вариант можно использовать для замены страниц с ошибками Web-приложений, возникающими в результате обработки Web-сервером запросов от клиента, на стандартные страницы (например, страницы с ошибкой 404). Это позволит уменьшить объем передаваемой клиенту критичной информации о работе приложения и усложнит задачу потенциального злоумышленника.

Данный вариант установки ограничен применением Apache в качестве Web-сервера и не может использоваться для защиты других Web-серверов (рис. 1).

Установка Apache c модулем ModSecurity в качестве обратного proxy-сервера позволяет перехватывать запросы клиентов к Web-серверам, развернутым на любой платформе (IIS, Apache, WebSphere и т.д.). Принцип работы обратного proxy-сервера заключается в том, что сервер переадресует все запросы от клиентов Web-серверу и при получении ответа перенаправляет его клиенту. Клиенты «видят» только внешний интерфейс proxy-сервера и «не видят» расположенных за ним Web-серверов (см. рис. 2). В данном случае недостатками являются необходимость закупки дополнительного оборудования под proxy-сервер и наличие единой точки отказа для одного или нескольких Web-серверов. Однако сам proxy-сервер может выполнять и дополнительные полезные функции, например кэширование статических запросов и балансировку нагрузки на группу Web-серверов.

Установка ModSecurity

Мы рассмотрим универсальный вариант использования ModSecurity в качестве Reverse Proxy. Для этого желательно задействовать сервер с двумя сетевыми интерфейсами (хотя для настройки Reverse Proxy можно использовать и один интерфейс). Один из сетевых интерфейсов должен быть настроен на Internet. Второй настроен на внутреннюю сеть или сегмент с Web-серверами (рис. 2). В статье рассматривается установка Apache на базе Microsoft Windows 2003 Server Standard Edition.

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

  • mod_so (входит в состав Apache);
  • mod_unique_id (входит в состав Apache);
  • mod_proxy (входит в состав Apache);
  • mod_proxy_http (входит в состав Apache);
  • mod_proxy_balancer (входит в состав Apache);
  • mod_proxy_html (не входит в состав Apache).

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

Загружаем архив с последней версией сервера Apache 2.2 для Microsoft Windows по ссылке (http://www.apachelounge.com/download/binaries/httpd-2.2.4-win32-x86-ssl.zip). Дополнительно нам понадобится Visual C++ 2005 Redistributable Package SP1, его можно скачать с сайта компании Microsoft (www.microsoft.com) либо по ссылке (http://www.apachelounge.com/download/vcredist_x86-sp1.exe).

Устанавливаем Visual C++ 2005 Redistributable Package SP1. Для этого запускаем vcredist_x86-sp1.exe и следуем указаниям мастера установки.

Далее распаковываем файл httpd-2.2.4-win32-x86-ssl.zip в папку C:Apache2 (см. экран 1)

Экран 1. Папка с установленным Web-сервером Apache

Устанавливаем сервер Apache в качестве службы операционной системы. Для этого в командной строке набираем:

C:Apache2inhttpd.exe -k install

Запускаем ApacheMonitor (C:Apache2inApacheMonitor.exe).

Дополнительно необходимо установить последнюю версию библиотеки libxml2.dll и модуль mod_proxy_html. Эти файлы можно найти, пройдя по ссылке (http://www.apachelounge.com/download/mods/mod_proxy_html-2.5.2-w32.zip). Установка mod_proxy_html заключается в распаковке архива в папку C:Apache2modules.

После установки Apache необходимо настроить его на работу в качестве обратного proxy-сервера. Для этого отредактируем файл конфигурации C:Apache2confhttpd.conf в соответствии с  Листингом 1.

В файле конфигурации нас интересует следующее:

  • Listen 80 — порт, который будет использоваться Web-службой для приема HTTP-запросов от клиентов;
  • ProxyRequests Off — отключение режима обычного proxy;
  • ProxyPass и ProxyPassReverse, предназначенные для перенаправления запросов на другой Web-сервер.

В общем виде директивы ProxyPass и ProxyPassReverse имеют следующий синтаксис:

ProxyPass <относительный адрес на proxy-сервере>
<адрес Web-сервера для перенаправления>.

Теперь можно попробовать запустить наш proxy-сервер: открываем ApacheMonitor и нажимаем Start (см. экран 2).

Экран 2. ApacheMonitor

Если proxy-сервер был запущен успешно, то при обращении к нему по HTTP должна отобразиться Web-страница защищаемого Web-сервера. После настройки и проверки работоспособности proxy-сервера займемся установкой непосредственно ModSecurity. Сначала остановим запущенную службу Apache (через ApacheMonitor). Затем загружаем дистрибутив ModSecurity 2.1.0 для Microsoft Windows (http://www.apachelounge.com/download/mods/mod_security-2.1.0-win32.zip).

Из полученного архива mod_security-2.1.0-win32.zip в папку C:Apache2modules распаковываем файл mod_security2.so (см. экран 3).

Экран 3. Установленные модули Web-сервера Apache

Для работы с модулем ModSecurity в конфигурационный файл Apache необходимо внести некоторые изменения, а именно добавить следующие строки:

LoadModule security2_module modules/mod_security2.so

Настройка ModSecurity

Необходимые файлы для базовой настройки ModSecurity находятся в архиве mod_security-2.1.0-win32.zip в папке rules. Переписываем всю папку rules из архива в C:Apache2conf.

Добавляем в файл httpd.conf следующую строку:

include C:Apache2conf ules*.conf

Теперь можно запустить сервер Apache. В итоге мы получили рабочий proxy-сервер, позволяющий защитить выбранный Web-сервер от ряда атак.

Настройки модуля ModSecurity можно разделить на два типа:

  • глобальные настройки модуля;
  • правила фильтрации (SecFilter).

В папке C:Apache2conf ules находится конфигурационный файл modsecurity_crs_10_config.conf с базовыми настройками модуля ModSecurity. Настройки модуля достаточно подробно описываются в руководстве ModSecurity Reference Manual (http://modsecurity.org/documentation/index.html), поэтому мы не будем останавливаться на их описании.

Наибольший интерес представляют правила фильтрации ModSecurity для обнаружения и предотвращения атак, направленных на уязвимые Web-приложения.

В архив с программным обеспечением входит набор базовых правил фильтрации Core Rule Set. Этот набор правил использует следующие способы защиты Web-приложений:

  • защита HTTP — обнаружение аномалий в протоколе HTTP;
  • защита от основных типов атак, направленных на Web-приложения (основные типы атак описаны на сайте Web Application Security Consortium — http://www.webappsec.org/projects/threat/);
  • обнаружение и блокирование автоматизированных средств анализа защищенности Web-приложений;
  • обработка сообщений об ошибках, генерируемых сервером.

По умолчанию базовые правила только обнаруживают атаки, но не предотвращают их. Для изменения порядка реагирования ModSecurity при обнаружении атаки необходимо изменить значение директивы SecDefaultAction в файле C:Apache2conf ulesmodsecurity_crs_40_generic_attacks.conf следующим образом:

SecDefaultAction ‘log,deny,phase:2,status:500,t:urlDecodeUni,
t:htmlEntityDecode,t:lowercase»

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

В качестве примера можно привести отсутствие в базовых правилах фильтрации специальных символов перевода строки %0a и %0d, что позволяет злоумышленнику в общем случае осуществить атаку типа «расщепление HTTP-запроса». В некоторых случаях с помощью этих символов можно осуществить атаку типа «кросс-сайтовый сценарий» в обход базовых правил фильтрации.

Пример использования специальных символов для XSS-атаки:

http://192.168.1.36/xss.asp?str=

Существующие базовые правила блокируют запрос клиента, если он содержит выражение http:, но не блокируют http%0d:, что позволяет их обойти и осуществить атаку.

Рекомендуется добавить новое правило в файл modsecurity_crs_40_generic_attacks.conf, фильтрующее специальные символы %0a и %0d:

SecDefaultAction «log,deny,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase»
# HTTP Response Splitting
SecRule ARGS|ARGS_NAMES «(?:%0a|%0d| | )»
«capture,ctl:auditLogParts=+E,log,auditlog,msg:’HTTP Response Splitting.Matched signature <%{TX.0}>’,id:’950800’,severity:’2’»

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

http://127.0.0.1,

то запрос блокируется, а если так:

http://localhost,

то пропускается. Данное правило расположено в файле C:Apache2conf ulesmodsecurity_crs_21_protocol_anomalies.conf, и выглядит оно следующим образом:

# Check that the host header is not an IP address
#
SecRule REQUEST_HEADERS:Host «^[d.]+$»
«deny,log,auditlog,status:400,msg:’Host header is a numeric IP address’,
severity:’2’,id:’960017’»

Для отключения правила необходимо поставить знак комментария # перед директивой SecRule и перезапустить сервер Apache.

Проверка функциональности сайта

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

Для проведения проверок можно воспользоваться автоматизированными средствами проверки ссылочной целостности сайта:

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

Установка ModSecurity Console

Программное обеспечение ModSecurity Console, разработанное на платформе JDK/JRE 1.4, предназначено для хранения и отображения событий, поступающих от Web-серверов Apache с модулем ModSecurity. Такие серверы в терминах ModSecurity Console называются сенсорами.

Продукт включает в себя встроенный Web-сервер для администрирования и отображения событий и базу данных для хранения информации, поступающей от сенсоров.

В функции программы также входит оповещение администратора о возникающих событиях, протоколирование активности сенсоров, формирование отчетов в формате PDF с возможностью автоматической отправки по e-mail. На момент написания статьи на сайте http://bsn.breach.com  доступна версия ModSecurity Console v1.0.2.

Продукт ModSecurity Console — это коммерческое программное обеспечение с системой лицензирования по количеству подключаемых сенсоров. В ModSecurity Console уже включена лицензия на три сенсора сроком действия до июля 2007 г. В течение ограниченного периода времени можно бесплатно получить пожизненную лицензию (ModSecurity Console Free Community Licence) на три сенсора. Для этого необходимо зарегистрироваться на сайте BSN и пройти по ссылке (https://bsn.breach.com/licensing/request_free_licence.php).  

Программное обеспечение доступно для установки в виде RPM-пакета для Linux, установочного файла для Windows, файла установки UNIX/Linux Shell Script (.sh) и открытых исходных кодов. Все перечисленные пакеты доступны по ссылке (https://bsn.breach.com/downloads/modsecurity-console).  

Установка консоли под Microsoft Windows

Перед установкой ModSecurity Console необходимо обеспечить поддержку языка Java: JRE (Java Runtime Environment) версии 6. Данная среда исполнения доступна на сайте Sun Microsystems (http://java.sun.com/javase/downloads/index.jsp).

Дальнейшая установка консоли выполняется стандартно: администратору предлагается выбрать установочную папку и режим запуска (ручной или при старте Windows).

Настройка ModSecurity Console

Работа с консолью осуществляется через Web-интерфейс. При первоначальной настройке сервис ModSecurity Console доступен через Web-браузер по адресу http://127.0.0.1:8886.  Учетная запись и пароль при подключении admin/admin. Естественно, первым делом необходимо сменить пароль на доступ к консоли. Для настройки сенсоров нужно в разделе Sensors нажать кнопку Add Sensor. Каждый сенсор идентифицируется по уникальному имени (User Name) и паролю. В интерфейсе настройки новых сенсоров есть поле IP Address, означающее, что консоль будет получать данные о событиях только от сенсора с этим IP-адресом.

В процессе тестирования работоспособности консоли необходимо настроить получение событий от нашего proxy-сервера. Для этого в настройках консоли создадим новый сенсор с именем (UserName) Proxy и паролем 123456. Эти данные нужно сохранить или запомнить — они еще пригодятся при настройке самого сенсора.

Отправка событий на ModSecurity Console

Для отправки событий с сенсора на консоль необходимо, чтобы на сенсоре был установлен Perl не ниже версии 5.6 (http://www.activestate.com/store/activeperl/download/).  

Для установки Perl необходимо распаковать архив (в данном случае ActivePerl-5.8.8.820-MSWin32-x86-274739.zip) и запустить installer.bat. В процессе установки будет задано несколько вопросов (см. экран 4).

Экран 4. Процедура установки консоли ModSecurity Console

После окончания установки Perl необходимо перезапустить операционную систему.

Для отправки событий на консоль требуется изменить файл конфигурации ModSecurity modsecurity_crs_10_config.conf (листинг 2) и перезагрузить Web-сервер Apache.

После настройки файла конфигурации в папку C:Apache2in необходимо перенести специальный сценарий на языке Perl, выполняющий работу по передаче событий на консоль. Этот сценарий можно загрузить, пройдя по ссылке http://www.securitylab.ru/software/293877.php.  В самом файле сценария modsec-auditlog-collector.pl (листинг 3) необходимо ввести данные для подключения сенсора к консоли ModSecurity:

$CONSOLE_HOST — IP-адрес сервера с установленным ModSecurity Console;
$CONSOLE_PORT — порт Web-интерфейса ModSecurity Console, по умолчанию 8886;
$CONSOLE_USERNAME — имя сенсора, в нашем случае — Proxy;
$CONSOLE_PASSWORD — пароль для подключения сенсора к консоли, в нашем случае «123456».

Данный сценарий предназначен для считывания событий из файла журнала модуля ModSecurity и их передачи ModSecurity Console по протоколу HTTP. Настроим запуск этого сценария по расписанию:

  1. Запускаем службу Task Scheduler (net start schedule).
  2. Создаем новую учетную запись (например, modsecure с паролем «123456») и включаем ее в группу локальных администраторов.
  3. Добавляем новое расписание с помощью команды schtasks (см. экран 5).

Экран 5. Создание расписания

Параметры /S /U /P соответственно определяют имя компьютера, имя пользователя, пароль. Для проверки работоспособности сценария можно смоделировать атаку на защищаемый сайт и убедиться в наличии в ModSecurity Console данного события.

Отчеты ModSecurity Console

Программное обеспечение ModSecurity Console позволяет формировать отчеты о событиях, сообщения о которых получены от сенсоров ModSecurity. Отчеты хорошо структурированы и развернуты (рис. 3), однако есть одно «но»: в отчете события не группируются автоматически по типам атак. То есть необходимо вручную определять, к какому типу атак относится каждое новое событие, что практически невозможно при большом их количестве (см. экран 6). Остается только ждать, когда разработчики ModSecurity Console добавят функцию автоматического категорирования поступающих событий.

Экран 6. Пример добавления события в определенную категорию

Рисунок 3. Пример отчета ModSecurity Console по одному сенсору

Резюме

ModSecurity является удобным и гибким в настройке средством защиты Web-приложений от различных типов атак. Сегодня его успешно используют для защиты Web-серверов во всем мире.

При внедрении ModSecurity необходимо придерживаться следующих правил:

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

Алексей Юдин - Эксперт по информационной безопасности компании Positive Technologies (www.ptsecurity.ru),  занимается вопросами безопасности Web-приложений, безопасности баз данных и компьютерных сетей. aleksei-yudin@yandex.ru

Дополнительные ресурсы

http://www.modsecurity.org/blog/  — блог по продукту ModSecurity, поддерживается одним из разработчиков модуля.

http://sourceforge.net/projects/mod-security/  — информационные рассылки по продукту ModSecurity.

http://apache.rediska.ru/httpd/binaries/win32/  — официальный сайт сервера Apache.

http://www.apachelounge.com/download/mods/  — сайт Стефана Лэнда с модулями Apache, портированными под Microsoft Windows.

http://www.activestate.com/  — язык программирования Perl под Windows.