Введение

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

По статистике компании “Positive Technologies” за 2006 год уязвимыми оказались  80% исследованных Web-сайтов.

Защита уязвимых Web-приложений может осуществляться либо путем устранения уязвимостей в Web-приложении либо с использованием специализированных средств защиты Web-приложений WAF.

Специализированные средства защиты WAF (Web Application Firewall) - это межсетевые экраны, работающие  на прикладном уровне и осуществляющие фильтрацию трафика Web-приложений. Эти средства не требуют изменений в исходном коде Web-приложения и, как правило, защищают Web-сервисы гораздо лучше обычных межсетевых экранов и средств обнаружения вторжений.

На рынке существует большое количество межсетевых экранов для Web-приложений, в связи, с чем сообщество Web Application Security Consortium даже выпустило методику для их тестирования . Одним из таких средств защиты является модуль ModSecurity для Web-сервера Apache.  

Описание ModSecurity

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

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

• установка модуля непосредственно на Web-сервер
• установка в качестве обратного прокси-сервера (Reverse Proxy)

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

Сравним, чем отличается установка ModSecurity на Web-сервер от установки в качестве обратного прокси.

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

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

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

Установка ModSecurity2

Мы рассмотрим универсальный вариант использования ModSecurity в качестве Reverse Proxy. Для этого нужен сервер (подойдет и рабочая станция – все зависит от планируемой нагрузки) с двумя сетевыми интерфейсами. Один из сетевых интерфейсов должен быть настроен на внешнюю сеть (Интернет). Второй настроен на внутреннюю сеть или сегмент с Web-серверами. Устанавливаем на сервер любую версию Linux или Unix. Для статьи в качестве ОС был выбран дистрибутив Fedora Core 6.

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

• 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 в виде исходных кодов для Unix систем с сайта.

Копируем полученный файл (в нашем случае httpd-2.2.4.tar.gz) на прокси-сервер в папку /tmp.

В консоли Linux выполняем следующие действия:

# cd /tmp

# gunzip httpd-2.2.4.tar.gz

# tar -xvf httpd-2.2.4.tar      

# cd httpd-2.2.4

# ./configure --with-pcre --enable-so --enable-mods-shared=’unique_id proxy proxy_http proxy_balancer’

# make

# make install

По умолчанию сервер Apache будет установлен в папку “/usr/local/apache2”.

Дополнительно необходимо установить последнюю версию библиотеки libxml2 и модуль mod_proxy_html. Libxml2 можно скачать с сайта. Mod_proxy_html расположен на сайте http://apache.webthing.com/mod_proxy_html.Установка mod_proxy_html:

# apxs -c -I/usr/include/libxml2 -i mod_proxy_html.c

Сервер Apache желательно запускать из-под непривилегированной учетной записи. Создадим специальную группу пользователей и учетную запись для запуска Web-сервисов:

# groupadd apache2

# useradd apache2 -p asdfgh -g apache2

# chown apache2:apache2 -R /usr/local/apache2/

После установки Apache и создания специально учетной записи  необходимо настроить его на работу в качестве Reverse Proxy. Создаем  c помощью любого редактора новый файл httpd.conf ( /usr/local/apache2/conf/ ) и добавляем в него следующие строки:

User apache2

Group apache2

ServerRoot "/usr/local/apache2"

Listen 80

LoadFile /usr/lib/libxml2.so.2

LoadModule unique_id_module modules/mod_unique_id.so

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

LoadModule proxy_html_module modules/mod_proxy_html.so

ProxyRequests Off

ProxyPass           / http://192.168.1.31/

ProxyPassReverse    / http://192.168.1.31/

ServerName 192.168.1.36:80

ErrorLog logs/error_log

LogLevel warn

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

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

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

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

Теперь можно попробовать запустить наш прокси-сервер:

# /usr/local/apache2/bin/apachectl start

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

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

Далее распаковываем полученный архив modsecurity-apache_2.1.0.tar.gz:

# gunzip  modsecurity-apache_2.1.0.tar.gz

# tar –xvf modsecurity-apache_2.1.0.tar

# cd modsecurity-apache_2.1.0/apache2/

Открываем файл Makefile и исправляем следующую строку:

top_dir = /usr/local/apache2 (путь где установлен Apache сервер)

Перед установкой ModSecurity необходимо остановить Web-сервер:

# /usr/local/apache2/bin/apachectl stop

Затем выполняем следующие команды:

# make

# make install

Таким образом, получили установленный модуль mod_security2.so, расположенный в папке /usr/local/apache2/modules/.Для работы модуля необходимо добавить следующую строку в конфигурационный файл /usr/local/apache2/httpd.conf:

LoadModule security2_module modules/mod_security2.so

Настройка ModSecurity2

Необходимые файлы для базовой настройки ModSecurity расположены в папке rules в архиве modsecurity-apache_2.1.0.tar.gz. Переписываем папку rules в /usr/local/apache2/conf/. Затем меняем владельца файлов на пользователя apache2:

# chown apache2:apache2 -R /usr/local/apache2/conf/

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

Include conf/rules/*.conf

Можно запустить сервер Apache:

# /usr/local/apache2/bin/apachectl start

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

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

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

В папке /usr/local/apache2/conf/rules/  находится конфигурационный файл modsecurity_crs_10_config.conf с базовыми настройками модуля ModSecurity. Данные настройки достаточно подробно описываются в руководстве по работе с ModSecurity (Modsecurity Reference Manual), поэтому мы не будем останавливаться на их описании.

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

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

• Защита HTTP – обнаружение аномалий в протоколе HTTP.
• Защита от основных типов атак, направленных на Web-приложения (XSS,OS Commanding, SQL Injection и др.).
• Обнаружение и блокирование автоматизированных средств анализа защищенности Web-приложений.
• Обработка сообщений об ошибках, генерируемых сервером.

По умолчанию базовые правила защиты от основных типов атак только обнаруживают атаки, но не предотвращают их. Для изменения реагирования ModSecurity при обнаружении атаки необходимо изменить директиву SecDefaultAction в файле  /usr/local/apache2/conf/rules/modsecurity_crs_40_generic_attacks.conf.

Первоначально директива SecDefaultAction имеет вид:

SecDefaultAction "log,pass,phase:2,status:500,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase"

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

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

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

В процессе написания статьи оказалось, что базовые правила фильтрации ModSecurity не осуществляют фильтрацию специальных символов перевода строки %0a и %0d , что позволяет злоумышленнику в общем случае осуществить атаку типа HTTP Response Splitting, а в данном случае позволило осуществить атаку типа Cross Site Scripting в обход существующих правил фильтрации.

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

http://192.168.1.36/xss.asp?str=<img src=”http%0d://www.xss.narod.ru/xss.js”></img>

Существующие правила блокируют запрос клиента, если он содержит выражение “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|\n|\r)" \

        "capture,ctl:auditLogParts=+E,log,auditlog,msg:'HTTP Response Splitting.Matched signature <%{TX.0}>',id:'950800',severity:'2'"

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

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

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

• Link Utility (http://www.netpromoter.ru/linkutility/ );
• Fast Link Checker (http://www.webtweaktools.net/downloads.html ).

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

Установка ModSecurity Console

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

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

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

На момент написания статьи на сайте  доступна версия  ModSecurity Console v1.0.2.

ModSecurity Console - это коммерческое ПО с системой лицензирования по количеству подключаемых сенсоров. В течение ограниченного периода времени можно  бесплатно получить пожизненную лицензию (ModSecurity Console Free Community Licence) на 3 сенсора. Для этого необходимо зарегистрироваться на сайте BSN и зайти по ссылке.

ModSecurity Console доступно для установки в виде RPM пакета для Linux, установочного файла  для Windows, файла установки UNIX/Linux Shell Script (.sh) и открытых исходных кодов. Все перечисленные пакеты доступны по ссылке. 

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

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

Дальнейшая установка консоли стандартна:

Настройка ModSecurity Console

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

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

 

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

Для отправки событий с сенсора на консоль необходимо, чтобы на сенсоре был установлен Perl не ниже версии 5.6 (http://www.perl.org/ ) с библиотекой MIME-Base64.pm. Установка вышеперечисленного ПО хорошо описана в документации на сайте Perl и в документации к самому модулю.

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

SecAuditEngine RelevantOnly

SecAuditLogType Concurrent

SecAuditLogParts ABCDEFGHZ

SecAuditLogStorageDir /path/to/auditlog/data/

SecAuditLog "|/usr/local/apache/bin/modsec-auditlog-collector /usr/local/apache/bin/auditlog/data/ /usr/local/apache/bin/auditlog/index"

После настройки файла конфигурации необходимо в папку /usr/local/apache2/bin/ на сенсоре перенести  специальный Perl скрипт,  выполняющий работу по передаче событий на консоль. Этот скрипт расположен на сервере с ModSecurity Console (C:\Program Files\ModSecurityConsole\templates\com.thinkingstone.console.ConsoleComponent\htdocs\static\ modsec-auditlog-collector).

Для корректной работы необходимо сменить права на скрипт (chmod 755) и его владельца  (chown) на пользователя, от имени которого запускается сервер Apache.  

В самом файле modsec-auditlog-collector необходимо ввести данные для подключения сенсора к консоли ModSecurity:

$CONSOLE_HOST – IP адрес сервера с установленным ModSecurity Console

$CONSOLE_PORT – порт Web-интерфейса ModSecurity Console, по умолчанию “8886”

$CONSOLE_USERNAME – Имя сенсора, в нашем случае “Proxy”

$CONSOLE_PASSWORD – Пароль для подключения сенсора к консоли, в нашем случае “123456”

Содержимое части файла modsec-auditlog-collector:

. . . . .

my $CONSOLE_URI = "/rpc/auditLogReceiver";

my $CONSOLE_HOST = "IP адрес ModSecurity Console ";

my $CONSOLE_PORT = "8886";

my $CONSOLE_USERNAME = "Proxy";

my $CONSOLE_PASSWORD = "123456";

. . . . .

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

В случае использования модуля ModSecurity, портированного под платформу Microsoft Windows, возникает вопрос об отправке событий на ModSecurity Console. Проблема в том, что портированный модуль может записывать события только в лог-файл  и не позволяет использовать  pipe-каналы для передачи данных  сценарию modsec-auditlog-collector. Поэтому данный сценарий был доработан следующим образом:

1. модуль ModSecurity сохраняет данные в логфайл
2. сценарий modsec-auditlog-collector.pl раз в минуту считывает данные из файла и перенаправляет их в ModSecurity Console.

Модифицированный сценарий можно скачать по ссылке: http://www.securitylab.ru/software/293877.php.

Для запуска сценария используется служба Task Scheduler. Пример создания задачи c помощью SHTASKS:

SCHTASKS /Create /S Proxy /U modsecure /P 123456 /SC MINUTE /MO 1 /TN ModSecurityLogCollector /TR "perl C:\Apache2\bin\modsec-auditlog-collector.pl C:\Apache2\logs\auditlog C:\Apache2\logs\auditlog\index C:\Apache2\logs\collector.log"

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

Отчеты ModSecurity Console

ModSecurity Console позволяет формировать отчеты по событиям, полученным от сенсоров ModSecurity. Отчеты хорошо структурированы и развернуты, с одним “но”: в отчете события не группируются автоматически по типам атак. То есть необходимо вручную определять, к какому типу атак относится каждое новое событие, что практически невозможно при большом количестве событий. Остается ждать, когда разработчики ModSecurity Console добавят функцию автоматического категорирования поступающих событий.

Пример отчета по одному сенсору

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

Резюме 

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

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

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

В качестве дополнительных информационных ресурсов по продукту можно предложить:

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

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

Официальный сайт русскоязычного сервера Apache
http://apache.rediska.ru/httpd/binaries/win 32/

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

Perl под Windows
http://www.activestate.com