Как повысить безопасность веб-приложений

Сергей Яремчук

Как повысить безопасность веб-приложений

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

Традиционно для защиты сетевых приложений используют системы обнаружения и остановки атак, а также межсетевые экраны, работающие на третьем сетевом уровне модели OSI. В то же время такой подход имеет и недостатки. Так, при включении в разрыв необходим IP-адрес, при этом IPS (Intrusion Prevention Systems) легко обнаруживается и система сама может подвергнуться нападению. Выходом из такой ситуации является переход на более низкий, т.е. канальный уровень OSI, что с успехом и применяется в такой IPS, как hogwash [1]. Но увеличение потоков данных привело к тому, что такие системы требуют серьезной аппаратной поддержки, иначе они просто не успевают обрабатывать информацию. С другой стороны IPS, как правило, не знает, что конкретно она защищает (хотя это можно настроить, убрав лишние правила), поэтому ресурсы системы расходуются зря. Но зато она точно не владеет информацией о событиях, происходящих в конкретных приложениях. Кроме того, такие системы позволяют защитить только наиболее часто используемые приложения. Поэтому они смогут обеспечить только некий минимальный базовый уровень защиты, а учитывая, что на сегодняшний день увеличилось количество нападений на прикладном уровне, этого явно недостаточно. Для выполнения более широкого набора проверок, контроля трафика и реагирования на нападение в реальном времени, требуется поместить IPS и firewall поближе к приложению, т.е. на седьмой уровень.

Firewall веб-приложений

Судя по статистике, именно веб-сервисы привлекают сегодня нападающего. Это, впрочем, не удивительно, так как веб-технологии ориентированы в первую очередь на публичный доступ 24 часа в сутки 7 дней в неделю. Поэтому его невозможно спрятать за межсетевым экраном. Каждая из атак, направленных на этот сервис, представляет собой специально составленные запросы, которые выглядят как обычный трафик, поэтому он беспрепятственно проходит через него. Один из возможных путей решения проблемы описан в [2], но такие мероприятия можно отнести скорее к упреждающим. Для остановки атаки необходимо использовать персональные IPS – firewall веб-приложений (Web Application Firewall – WAF). Они действуют по принципу обратного прокси-сервера, стоящего между сервером и клиентами. Один такой прокси может одновременно обслуживать несколько веб-серверов, что упрощает администрирование, позволяет централизованно управлять доступом, увеличивая производительность, кэшируя запросы, сжимая информацию. Кроме того, такой подход скрывает топологию сети. Поскольку модуль расположен между клиентом и сервером, то в случае, когда он обнаружит запрос, содержащий злонамеренные данные, он вполне может отклонить, преобразовать запрос или выполнить любое другое действие. К слову сказать, на сегодняшний день нет единой устоявшейся терминологии, каждый производитель называет продукт по-своему. Поэтому в Интернете следует искать информацию в различных сочетаниях. Например, Adaptive Firewall (Proxy, Gateway), Application (level или -layer) Firewall, Web IPS или Deep Packet Inspection Firewalls и другие. Имеются как аппаратные решения, так и программные. К первым относятся такие, как TrafficShield Application Firewall [3], в котором применена так называемая положительная модель безопасности, запрещающая все, что явно не разрешено, или NetContinuum NC-2000 AG Secure Application Gateways [4], который является гибридным устройством, объединяющим в себе функции firewall веб-приложений и коммутатора седьмого уровня. Или подобный гибрид от компании Imperva Inc. SecureSphere Web Application Firewall [5], имеющий фирменную технологию Dynamic Profiling, которая формирует модель нормального поведения приложения. Такие гибридные устройства имеют подробное представление о защищаемом веб-сервере и о конкретных приложениях. Они обладают достаточной функциональностью, позволяющей надежно защитить веб-сервис, но и стоят дорого. Среди программных решений особо хотелось бы выделить основанный на OpenBSD мощный и легкий в управлении firewall веб-приложений датский продукт Profense [6], стоящий отдельного обзора. А также бесплатные Open Source продукты: написанные на Java и ориентированные на все серверы, работающие по протоколу HTTP/HTTPS Guardian@JUMPERZ.NET [8] и mod_security [9], о котором пойдет речь далее.

Проект ModSecurity

ModSecurity создан Иваном Ристиком (Ivan Ristic) в 2003 году и представляет собой firewall веб-приложений, который может использоваться как модуль веб-сервера Apache, либо работать в автономном режиме и позволяющий защитить веб-приложения как от известных, так и неизвестных атак. Его использование прозрачно, как установка, так и удаление не требует изменения настройки сервисов и сетевой топологии. Кроме того, при обнаружении уязвимого места теперь не обязательно впопыхах изменять исходный код, делая новые ошибки, достаточно на первых порах добавить новое правило, запрещающее вредную комбинацию. Modsecurity может защищать одновременно несколько веб-серверов, в том числе и отличных от Apache (рис. 1).

Рисунок 1. ModSecurity может быть установлен как отдельно, так и защищать группу разнородных веб-серверов

Кроме обычных соединений может контролировать и защищенный SSL-трафик. Гибкозадаваемые правила журналирования позволяют записать любые данные сеанса, позволяя в будущем полностью разобрать запросы, предшествующие взлому. Понимание протокола HTTP позволяет очень тонко выполнить фильтрацию, поддерживается как GET, так и POST-методы, запросы к динамическим ресурсам. Для борьбы с различными методами уклонения (ссылки на внешние сайты, закодированные URL, использование нескольких слэшей, нулевые байты и пр.) пути и параметры нормализуются. В новой версии 1.9, вышедшей в ноябре 2005 года, возможно наследование правил, используется новый формат контрольного журнала, позволяющий производить аудит в реальном времени (старый формат оставлен, но может быть удален в версии 2.0). Кроме того, в этой версии введен новый механизм, названный guardian, задачей которого является контроль запросов, производимых с одного адреса, что позволяет защититься от DOS-атак, настраивая правила iptables. Интеграция с Open Source антивирусом ClamAV дает возможность сканировать загружаемые файлы на наличие вирусов. В версии добавлена поддержка PCRE, которую теперь можно использовать вместо библиотеки regex для Apache 1.3. Количество кода по сравнению с предыдущей версией выросло на 40%. Распространяется ModSecurity под двойной лицензией: GNU GPL, как свободное Open Source приложение, также доступно несколько вариантов end-user и OEM коммерческих лицензий.

Установка ModSecurity

На момент написания статьи актуальной была версия 1.9.2, имеющая незначительные исправления. Для упрощения будем рассматривать использование ModSecurity для веб-сервера, установленного на том же компьютере, описание остальных настроек вы найдете в документации проекта. При установке из исходных текстов возможны два варианта: компиляция как динамической библиотеки и компиляция в качестве модуля веб-сервера. В первом случае распаковываем архив и заходим внутрь каталога соответствующего версии веб-сервера Apache.

$ wget –c http://www.modsecurity.org/download/modsecurity-apache-1.9.2.tar.gz

$ tar –xzvf modsecurity-apache-1.9.2.tar.gz

$ cd modsecurity-apache-1.9.2/apache2

Для сборки используется apxs – APache eXtenSion tool. Если Apache устанавливался вместе с дистрибутивом, убедитесь в наличии заголовочных файлов и утилиты apxs. В ALTLinux заголовочные файлы находятся в /usr/include/apache2. Если в вашем дистрибутиве их нет, то доустановите соответствующий devel-пакет (например, httpd-devel), в некоторых дистрибутивах в него включен и apxs. В ALTLinux Master, в котором может быть установлена любая из двух версий Apache 1.3 и 2.0, скрипт apxs используется при компиляции динамических библиотек для версии 1.3. При использовании второй версии сервера библиотеки необходимо применять apxs2.

# /usr/sbin/apxs2 -cia mod_security.c

… /usr/lib/apache2/modules /usr/share/apr/build/libtool --mode=install cp mod_security.la /usr/lib/apache2/modules/ cp .libs/mod_security.so /usr/lib/apache2/modules/mod_security.so cp .libs/mod_security.lai /usr/lib/apache2/modules/mod_security.la cp .libs/mod_security.a /usr/lib/apache2/modules/mod_security.a ranlib /usr/lib/apache2/modules/mod_security.a chmod 644 /usr/lib/apache2/modules/mod_security.a PATH="$PATH:/sbin" ldconfig -n /usr/lib/apache2/modules ---------------------------------------------------------------------- Libraries have been installed in:    /usr/lib/apache2/modules ---------------------------------------------------------------------- chmod 755 /usr/lib/apache2/modules/mod_security.so [activating module `security" in /etc/httpd2/conf/httpd2.conf]

Последнее сообщение говорит о том, что в конфигурационный файл веб-сервера занесена строка для запуска Dynamic Shared Object (DSO): «LoadModule /usr/lib/apache2/modules/mod_security.so».

Проверьте ее наличие. При установке в качестве модуля Apache необходимо скопировать файл mod_security.c в подкаталог httpd-2.0.xx/modules/proxy и сконфигурировать со следующими опциями.

$ ./configure -enable-security --with-module=proxy:mod_security.c

$ make

# make install

Прежде чем перезапускать веб-сервер, необходимо отредактировать конфигурационный файл, в котором подключить библиотеки и настроить правила фильтрации. Архив с исходными текстами содержит пример httpd.conf.example-minimal, копируем его на место:

# cp httpd.conf.example-minimal /etc/httpd2/conf/mod_security.conf

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

Include /etc/httpd2/conf/mod_security.conf

Конфигурационный файл ModSecurity

Рассмотрим основные параметры:

<IfModule mod_security.c>

# Включение проверок ModSecurity, возможны три варианта:

# Off – проверки не производятся, On – проверяется все

# и DynamicOnly – только динамически сгенерированные запросы

# (позволяет сэкономить ресурсы процессора)

SecFilterEngine On

# При совпадении правил могут быть произведены одно

# или более действий, каждый фильтр может иметь

# индивидуальный список действий, этим параметром

# определяются действия по умолчанию.

# Среди основных действий – deny, pass и redirect.

# Среди второстепенных – exec, к действиям, изменяющим

# прохождение цепочек, относится chain и skip. Действия

# описаны в таблице 1. После действий можно указать

# параметры, например статус

SecFilterDefaultAction "deny,log,status:430"

# Включение декодирования POST-запросов, поддерживается

# два типа (application/x-www-form-urlencoded

# и multipart/form-data)

SecFilterScanPOST On

SecFilterCheckURLEncoding On

SecFilterCheckUnicodeEncoding Off

# Можно определить диапазон разрешенных символов

# (эта директива не распространяется на POST

# с multipart/form-data)

SecFilterForceByteRange 0 255

# Можно замаскировать сервер, указав здесь другие данные.

# Некоторые эксплоиты перед началом работы проверяют банер

# (ответ сервера), а нападающий будет сбит с толку, правда,

# на некоторое время, т.к. на Linux IIS не ставится.

# SecServerSignature "Microsoft-IIS/5.0"

# Параметры хранения временных файлов и скрипт для проверки

# ClamAV (найдете в каталоге util архива)

SecUploadDir /tmp

SecUploadApproveScript  /usr/bin/modsec_clamscan.pl

SecUploadKeepFiles Off

# Защита от DOS-атак, при превышении (по умолчанию)

# 120 запросов в минуту и 360 за 5 минут адрес блокируется

# при помощи iptables, требует скрипт blacklist.

# Скрипт httpd-guardian и blacklist найдете в архиве [13]

SecGuardianLog | /usr/bin/httpd-guardian

# Ведение журнала аудита и отладки

SecAuditEngine RelevantOnly

# SecAuditLogRelevantStatus ^5

SecAuditLog logs/modsec_audit.log

# Либо можно подключить экспериментальный скрипт

# modsec-auditlog-collector.pl, контролирующий журналы

# и отсылающий информацию на http-сервер.

# SecAuditLog | /path/to/modsec-auditlog-collector.pl logs/modsec_audit.log logs/index

SecFilterDebugLevel 0

SecFilterDebugLog logs/modsec_debug.log

# Просмотр выходной информации (работает только в версии

# для Apache 2) необходим для параметра OUTPUT

# (примеры см. далее по тексту)

SecFilterScanOutput On

# Кроме общих правил, можно задавать правила для отдельных

# каталогов веб-сервера

<Location /axis/modsec.jws>

….

</Location>

# Далее при помощи директив SecFilter или  SecFilterSelective

# указываются правила

</IfModule>

Таблица 1. Действия, выполняемые при совпадении запроса

Действие	Описание	Пример
pass	Действие, полезное в том случае, когда необходимо зарегистрировать событие, и далее продолжить прохождение по цепочке правил	SecFilter KEYWORD "log,pass"
allow	Действие разрешает запрос без прохождения по остальным цепочкам	SecFilterSelective REMOTE_ADDR "^192.168.1.99$" allow
deny	Запрет запроса (по умолчанию используется статус 500)
status	Код HTTP-статуса при запрете запроса. Активизируется  директива Apache ErrorDocument и выводится соответствующая страница	SecFilter KEYWORD "deny,status:404"
redirect	Пользователь перенаправляется на указанный адрес (не должен содержать запятую). Переопределяет status и deny	SecFilter KEYWORD "redirect:http://www.example.com"
proxy	Запрос перенаправляется на внутренний обратный прокси (mod_proxy)	SecFilter KEYWORD "proxy:http://www.example.com"
exec	Выполнение внешней команды (без параметров), которая получит все переменные CGI среды (по окончании команда должна что-то вывести в stdin, иначе ModSecurity решит, что выполнение завершилось с ошибкой)	SecFilter KEYWORD "exec:/usr/bin/report-attack"
log	Регистрация события в журнал ошибок
nolog	Не регистрировать событие в журналах ошибок и аудита
skipnext	Пропуск одного (по умолчанию) или нескольких следующих правил	SecFilterSelective ARG_p value1 skipnext:2
chain	Подключение нескольких правил в единый тест. Действие будет разрешено только в том случае, когда будут выполнены все правила. Например, администратора только с указаного IP-адреса	SecFilterSelective ARG_username admin chain SecFilterSelective REMOTE_ADDR "^192.168.1.99$"
pause	Задержка в миллисекундах перед ответом на запрос (может быть полезна при борьбе со сканерами)
auditlog	Регистрация в журнал аудита
noauditlog	Не регистрировать событие в журнале аудита
id rev msg severity	Эти действия предназначены для вывода параметров в журнале ModSecurity, помогает собрать больше информации и классифицировать ошибки	Id – уникальный ID правила (для собственных правил используйте диапазон 1 – 99999) rev – версия правила msg – текстовое сообщение severity – цифровое значение (2-5) или название в syslog
mandatory	Наследование правил
setenv setnote	Установка или сброс переменных среды и Apache	SecFilter KEYWORD setenv:name=value Например, при помощи MODSEC_ENABLE можно на лету переопределять значение директивы SecFilterEngine

Правила ModSecurity

Отбор запросов ModSecurity осуществляет на основе правил. Ключевое слово в правиле может быть не только простым текстом, но и записываться в виде регулярного выражения. Например, используя следующее правило, можно отсеять все запросы, не содержащие слово php (действие deny используется по умолчанию, но для наглядности его лучше прописывать явно):

SecFilter !php

или так:

SecFilter !php deny

или, например:

SecFilter /etc/passwd

а лучше:

SecFilter "/(etc|bin|sbin|kernel|dev|tmp|var|opt)/"

Но такое правило хотя и пишется легко, но будет работать медленно, так как будет искать эту строку во всех параметрах. Поэтому на практике чаще всего используется директива SecFilterSelective. В общем случае правило, составленное с ее помощью, будет иметь такой вид:

SecFilterSelective LOCATION KEYWORD [ACTIONS]

Параметры KEYWORD и ACTIONS аналогичны SecFilter, LOCATION определяет местонахождение искомой строки. Здесь может быть использовано регулярное выражение, IP-адрес, имя, идентификаторы, включая CGI-переменные (полный список приведен в «ModSecurity for Apache User Guide», который найдете в подкаталоге doc-архива). Например:

# Прием только тех запросов, которыми может оперировать ModSecurity

SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain

SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"

# Запрет GET или HEAD с ненулевым телом

SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain

SecFilterSelective HTTP_Content-Length "!^$"

# То же для каждого POST-запроса

SecFilterSelective REQUEST_METHOD "^POST$" chain

SecFilterSelective HTTP_Content-Length "^$"

# Чтобы избежать атак, направленных на переполнение буфера, используем

SecFilterSelective THE_ REQUEST "!^[\x0a\x0d\x20-\x7f]+ $"

# Запрет вывода, содержащего опасное словосочетание

SecFilterSelective OUTPUT "credit card numbers"

# Или вывода команды ls –l

SecFilterSelective OUTPUT "total [[:digit:]]+"

# Также полезно запретить вывод пользователю ошибок сценариев

SecFilterSelective OUTPUT "Fatal error:"

Команда разработчиков во главе с Иваном Ристиком основной упор делает на усовершенствование кода ModSecurity, оставляя создание правил пользователям, поэтому оригинальный конфигурационный файл имеет всего несколько правил. Недавно был официально анонсирован субпроект, цель которого создание и тестирование правил [11]. Для их использования необходимо скачать и подключить требуемый файл правил в конфигурационном файле ModSecurity директивой Include. Некоторые из правил требуют редактирования, кроме того, следует учитывать особенности rexeс и PCRE, поэтому правила, созданные для Apache 2.x, могут неправильно работать с первой версией сервера (о том, как собрать первую версию с поддержкой PCRE, рассказано в документации). Кроме того, в подкаталоге util найдете скрипт snort2modsec.pl, преобразующий правила IDS Snort в правила ModSecurity (и готовый файл snortmodsec-rules.txt, содержащий преобразованные таким образом правила, актуальные на момент выхода дистрибутива).

Получить их самому очень просто.

$ tar zxvf snortrules-snapshot-CURRENT.tar.gz

$ cat README.first > snortmodsec-rules.txt

$ ./snort2modsec.pl rules/* >> snortmodsec-rules.txt

Аналогичную роль играет скрипт nessus2modsec.pl, предназначенный для преобразования NASL правил сканера безопасности Nessus/GNessUs. Формат запуска такой же.

Теперь, когда правила составлены, перезапускаем веб-сервер и тестируем.

# /etc/init.d/httpd2 restart

Stopping httpd2 service:                                 [ DONE ] Checking configuration sanity for httpd2:  Syntax OK     [ DONE ] Starting httpd2 service:                                 [ DONE ]

Тестируем правила

Для тестирования работы ModSecurity можно использовать любой из сканеров безопасности, умеющий проверять уязвимости веб-сервисов [2]. Кроме того, в комплект дистрибутива входит скрипт run-test.pl, предназначенный для посылок тестовых запросов. Попробуем создать простейшее правило, запрещающее доступ к каталогу скриптов cgi-bin, и отследить в журналах реакцию системы на его нарушение. Вот это правило:

SecFilter cgi-bin

Запускаем веб-сервер сначала без поддержки ModSecurity и убеждаемся, что запрос к http://localhost/cgi-bin/printenv выполняется успешно. Затем подключаем ModSecurity, результат на (рис. 2), как видите, запрос не прошел с кодом ошибки 403. Смотрим, что написано в журналах (в ALTLinux /var/log/httpd2).

Рисунок 2. Запрос, запрещенный правилами, не прошел

Журнал регистрации запросов access_log содержит следующую запись.

127.0.0.1 - - [06/Feb/2006:15:16:25 +0000] "GET /cgi-bin/printenv HTTP/1.1" 403 299

Журнал ошибок поясняет, что доступ клиенту, пришедшему с адреса 127.0.01, запрещен модулем mod_security, потому что совпал образец «cgi-bin».

[Mon Feb 06 15:16:25 2006] [error] [client 127.0.0.1] mod_security: Access denied with code 403. Pattern match "cgi-bin" at REQUEST_URI [hostname "localhost"] [uri "/cgi-bin/printenv"] [unique_id "vwk-VsCoABQAAA7tBpoAAAAA"]

Кстати, на основании этой записи можно уже оптимизировать правило. Вот так:

SecFilterSelective REQUEST_URI  "cgi-bin"

Теперь журналы ModSecurity. Файл modsec_audit.log содержит всю информацию о запросе.

==83d74643============================== Request: localhost 127.0.0.1 - - [06/Feb/2006:15:16:25 +0000] "GET /cgi-bin/printenv HTTP/1.1" 403 299 "-" "Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)" vwk-VsCoABQAAA7tBpoAAAAA "-" Handler: cgi-script ---------------------------------------- GET /cgi-bin/printenv HTTP/1.1 Connection: Keep-Alive User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko) Accept: text/html, image/jpeg, image/png, text/*, image/*, */* Accept-Encoding: x-gzip, x-deflate, gzip, deflate Accept-Charset: windows-1251, utf-8;q=0.5, *;q=0.5 Accept-Language: ru, en Host: localhost mod_security-action: 403 mod_security-message: Access denied with code 403. Pattern match "cgi-bin" at REQUEST_URI   HTTP/1.1 403 Forbidden Content-Length: 299 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 --83d74643--

А в modsec_debug.log найдете информацию обо всех использованных при запросе правилах.

[06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Detection phase starting (request 8182958): "GET /cgi-bin/printenv HTTP/1.1" [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Parsing arguments... [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][3] Content-Type is not available [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "!^(GET|HEAD)$" at REQUEST_METHOD [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "^(GET|HEAD)$" at REQUEST_METHOD [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][3] Warning (chained rule). Pattern match "^(GET|HEAD)$" at REQUEST_METHOD [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "!^$" at HEADER(Content-Length) [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "^POST$" at REQUEST_METHOD [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "!^$" at HEADER(Transfer-Encoding) [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Checking signature "cgi-bin" at THE_REQUEST [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][1] Access denied with code 403. Pattern match "cgi-bin" at REQUEST_URI [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] Logging phase starting [06/Feb/2006:15:16:25 +0000] [localhost/sid#80a8e90][rid#8182958][/cgi-bin/printenv][2] sec_audit_logger_serial: start

Выводы

Только система, не подключенная к сети, может быть 100% безопасной, но веб-сервис должен быть публичным, иначе он теряет смысл. Выявить все слабые места практически не возможно. По данным компании Netcraft, отслеживающей, какое программное обеспечение используется серверами в Интернете, хакеры всё чаще эксплуатируют дыры в распространенных приложениях на основе РНР. Обычный межсетевой экран здесь не помогает. Только специализированное программное обеспечение способно остановить атаку. ModSecurity чрезвычайно функциональный, простой в конфигурировании и главное совершенно бесплатный инструмент, использование которого позволит повысить безопасность предоставляемых веб-услуг, а относительная легкость написания правил поможет быстро среагировать на угрозу.

Литература, ссылки:

1. Яремчук С. Все в одном, или Hogwash как пример Gateway-IDS. – Журнал «Системный администратор», №1, 2005 г. – 50-55 с (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=01.2005;a=11).
2. Яремчук С. Определяем уязвимости веб-сервиса с помощью Acunetix Web Vulnerability Scanner. – Журнал «Системный администратор», №9, 2005 г. – 68-69 с (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2005;a=12).
3. Сайт F5 Networks, Inc. – http://www.f5.com/products.
4. Сайт NetContinuum – http://www.netcontinuum.com.
5. Сайт Imperva Inc. – http://www.imperva.com/products/securesphere/web_application_firewall.html.
6. Проект Profense – http://www.armorlogic.com.
7. Списки некоторых Web Application Firewall – http://www.bitpipe.com/rlist/term/Web-Application-Security.html.
8. Проект Guardian@JUMPERZ.NET – http://guardian.jumperz.net.
9. Проект mod_security – http://www.modsecurity.org.
10. Проект WASC (Web Application Security Consortium), здесь найдете документы, показывающие проблемы защиты веб-приложений и их возможные решения – http://www.webappsec.org.
11. Субпроект ModSecurity Rules – http://www.modsecurity.org/projects/rules/index.html.
12. Ссылка на текущие правила для ModSecurity – http://www.modsecurity.org/download/modsecurity-rules-current.tar.gz.
13. Архив инструментов для Apache – http://www.apachesecurity.net/download/snapshot/apache_tools-snapshot.tar.gz.