Содержание статьи
Веб сегодня популярен настолько, что разработкой приложений под него
занимаются практически все, кому не лень - от фрилансеров до больших софтовых
компаний. Причем безопасности продукта обе эти категории граждан (и их
сообществ) порой уделяют не самое пристальное внимание. Но даже проверка при
помощи сканера не может гарантировать отсутствие проблем. Проекты, живущие не
один год, и те подчас содержат уязвимости. Специальные файеры седьмого уровня
позволяют защититься, абстрагировавшись от конкретного приложения.
Защита СУБД с GreenSQL-FW
Классическое веб-приложение любого назначения для своей работы использует
собственно веб-сервер с активным модулем интерпретатора языка и базу данных, в
которой хранятся данные. Все известные на сегодня атаки (XSS, SQL-injection,
XPath-injections, CSRF/XSRF, HTTP Response Splitting, Include-атаки и другие) в
той или иной мере используют недоработки программистов, позволяющие в итоге
получить доступ к закрытой информации. Обнаружить и устранить все возможные
ошибки просто нереально, и веб-приложения здесь - не исключение. Впрочем, приемы
атакующих хорошо известны. Этот факт используют в специальных средствах,
разработчики которых отслеживают все потенциально опасные, да и просто
запрещенные администратором запросы, и пытаются их блокировать или изменить. На
страницах журнала уже рассматривались такие приложения, как
AppArmor, SELinux и TOMOYO
Linux (][ от
08.2010), которые также подходят под наши цели и способны противостоять
многим атакам.
Сегодня рассмотрим некоторые другие решения. Обзор начнется с проекта
GreenSQL-FW), который, работая
как прокси-сервер между веб-приложением и SQL-сервером, анализирует SQL-команды
на предмет аномальных запросов и команды администрирования SQL-сервера, которые
часто используются взломщиками (DROP, CREATE и т.д.). Используя GreenSQL, админ
может определить список допустимых и запрещенных масок для операций DELETE,
UPDATE и INSERT, а также блокировать запросы, содержащие ID администратора. При
обнаружении атак кроме "опасных" команд используется "степень риска", которая
вычисляется для каждого запроса к СУБД. В числе факторов, влияющих на
коэффициент риска, могут выступать самые популярные приемы хакеров: обращение к
служебным таблицам и конфиденциальным данным, запросы, всегда возвращающие TRUE,
попытка обнулить поля с паролем, использование в запросе OR, сравнение констант
и другие. При превышении уровня риска установленного порога запрос блокируется,
а приложению отправляются пустые данные.
GreenSQL поддерживает несколько режимов работы:
- Simulation Mode - пассивная система обнаружения атак (IDS), только
протоколирующая SQL-запросы и выдающая предупреждения на консоль управления; - Blocking Suspicious Commands - атаки не только обнаруживаются, но и
блокируются (IPS) в соответствии с установленными правилами, указывающими на
аномальность запроса; - Active protection from unknown queries - блокирование всех неизвестных
запросов (db firewall); - Learning mode предназначен для прогона и настройки правил в "чистой"
среде, что позволяет сформировать белый список для предотвращения ложных
срабатываний впоследствии.
Сразу после установки разработчики рекомендуют включить "Learning mode", а
после сбора данных перевести GreenSQL в режим "Active protection".
На сайте проекта доступны три версии файера: Community, Light и Pro. Первая -
бесплатная (по лицензии GNU GPL) и предоставляет основные возможности,
поддерживая СУБД MySQL и PostgreSQL (появилась в версии 1.2) и установку в Linux.
Коммерческие версии, кроме этого, умеют защищать MS SQL Server и работают еще и
на Win2k3/2k8.
Само защищаемое приложение роли не играет - это может быть портал, CMS и
вообще все, что угодно. GreenSQL обычно устанавливается на том же сервере, что и
SQL-база, хотя это необязательно. По умолчанию GreenSQL слушает локальный порт
127.0.0.1:3305, после анализа перенаправляя SQL-запросы на стандартный порт
MySQL - 127.0.0.1:3306. При необходимости эти параметры легко изменить в
консоли.
Управление программой и просмотр статистики запросов и блокировок
производится через консоль или веб-интерфейс. При помощи одной консоли можно
управлять защитой нескольких СУБД.
Кратко разберем настройку GreenSQL Community. На сайте проекта доступны
исходные тексты и пакеты для Ubuntu, RHEL/CentOS 5, Fedora, Debian, SLE/openSUSE
и Mandriva. Установка в Ubuntu проста: скачиваем deb-пакет, затем устанавливаем
из него, как обычно:
$ sudo dpkg -i greensql-fw_1.2.2_amd64.deb
После этого в появившемся окне нужно выбрать тип СУБД, которую будет защищать
GreenSQL, IP-адрес или имя сервера, порт, данные root, название базы данных, в
которой будут храниться настройки. Дальше скрипт предложит создать новую учетную
запись для подключения к БД. В случае, если в дальнейшем понадобится изменить
эти установки, можно поступить просто:
$ sudo dpkg-reconfigure greensql-fw
Как вариант, можно запустить скрипт "greensql-create-db". Конфигурационные
файлы GreenSQL находятся в каталоге /etc/greensq. Основной файл называется
greensql.conf и содержит настройки подключения к БД, журналирования и рисков.
Установки рисков по умолчанию подходят для большинства случаев и ничего трогать
внутри обычно не нужно, хотя при необходимости можно поиграться цифрами рисков,
просматривая журнал (/var/log/greensql.log) и подгоняя под свои условия. Все
поля комментированы, поэтому их назначение должно быть понятным.
Проверить, работает ли GreenSQL, очень просто: подключаемся к 3305 порту, нас
должны перебросить на 3306, на котором скучает MySQL.
$ mysql -h 127.0.0.1 -P 3305 -u root -p
Все как обычно, но, например, на запрос "show databases" мы получим пустой
список. Осталось переправить настройки всех клиентов, работающих с БД, на новый
порт 3305, хотя проще поступить наоборот, заставив GreenSQL слушать порт 3306, а
мускул перестроить на тот же 3305. Тогда трогать клиентские приложения не
понадобится. Для управления разработчики предлагают веб-интерфейс. Чтобы его
настроить, подключаем файл /etc/greensql/greensql-apache.conf в конфиге апача:
Include /etc/greensql/greensql-apache.conf
В greensql-apache.conf также нужно произвести некоторые настройки:
# снимаем комментарии с этих строк
<IfModule mod_alias.c>
Alias /greensql "/usr/share/greensql-fw"
</IfModule>
Разрешаем всем запись в подкаталог templates_c:
$ sudo chmod 0777 /usr/share/greensql-fw/templates_c
В файле config.php устанавливаем корректные данные для доступа к БД:
$db_type = "mysql";
$db_host = "localhost";
$dbport=3306
$db_name = "greendb";
$db_user = "green";
$db_pass = "pwd";
Включаем mod_alias и перезапускаем веб-сервер:
$ sudo a2enmod alias
$ sudo service apache2 restart
Теперь регистрируемся через веб-интерфейс, использовав для входа учетную
запись "admin" с паролем "pwd".
Файер для апача - ModSecurity
Основой для всех веб-приложений является, естественно, веб-сервер. Поэтому
неудивительно, что попыток остановить атаку на этом уровне предпринимается
достаточно много. Усилиями разных организаций создан консорциум WASC (Web
Application Security Consortium) - некоммерческая организация, состоящая из
экспертов, задача которой - сбор и обмен информацией по безопасности
веб-приложений, разработка рекомендаций и критериев. Плюс ко всему, WASC
поддерживает несколько десятков проектов, связанных с безопасностью в веб.
Файерволы веб-приложений
ModSecurity и WebDefend являются,
наверное, самыми известными из них. По сути, они разрабатываются одной и той же
группой. Первый (стартовал в 2003 году) распространяется по OpenSource-лицензии,
второй является полностью коммерческим продуктом.
Реализован ModSecurity в виде модуля к веб-серверу Apache 2.0/2.2, его
использование прозрачно и не требует изменений в настройке сервисов. Настройка
работы производится благодаря правилам, которые описываются при помощи гибкого
языка. В случае обнаружения проблемного места зачастую проще создать новое
правило, блокирующее уязвимость, а затем уже не спеша разобраться с приложением,
не останавливая его работу. Именно поэтому ModSecurity идеально подходит для
защиты веб-сервисов от известных и неизвестных атак. Правила, по сути,
определяют возможности текущей установки ModSecurity. Сами разработчики
занимаются исключительно разработкой ModSecurity и добавлением новых функций, а
правила создаются сторонними организациями.
Так, под руководством OWASP разрабатываются Сore Rule Set (CRS),
находящиеся в свободном доступе и предлагающие общую защиту веб-сервисов от всех
известных и неизвестных (0-day) атак и их разновидностей. Правила CRS
обеспечивают контроль HTTPзаголовков, выявляя аномальность и соответствие
требованиям, обнаруживают попытки сканирования, детектор атак и обращения к
бэкдорам. Правила периодически можно обновлять через сервис Rules Subscription
Service. Возможна проверка файлов при помощи ClamAV. Кроме этого реализованы
расширенные (но не бесплатные) рулесеты, Enhanced Rule Set (ERS), обеспечивающие
защиту коммерческих приложений (IIS, Outlook Web Access и др.), поддержку
стандарта PCI DSS (Payment Card Industry Data Security Standard), проверку
сложности пароля и прочее.
На сегодня актуальной является версия ModSecurity 2.5.12, в которой
использован более быстрый механизм поиска соответствий, кэширования
промежуточных значений для каждого запроса, вставки произвольного текста в
HTML-контент (Content Injection), анализ запроса на наличие номеров кредитных
карточек (оператор @verifyCC), универсальная защита от XSS через локальные
ссылки в PDF-файлах. Язык получил новые директивы: skipAfter, SecMarker,
ctl:ruleRemoveById (динамическое удаление правил), переменную GEO для привязки
правил к географической принадлежности посетителя, директиву SecRuleScript,
которая позволяет подключать сценарии на языке Lua. Добавлен новый скрипт,
rules-updater.pl, позволяющий автоматически обновлять правила из внешнего
репозитория.
Пакет с ModSecurity доступен в репозиториях всех основных дистрибутивов.
Смотрим актуальность пакета в репозитории Ubuntu:
$ sudo apt-cache search libapache-mod-security | grep -i version
Version: 2.5.11-1
В принципе, не самый последний релиз, но можно ставить:
$ sudo apt-get install libapache-mod-security
Кроме исходных текстов, на сайте можно найти ссылки на репозитории сторонних
разработчиков, предлагающих сборки под Debian, RHEL/CentOS, Fedora, Gentoo,
FreeBSD, Apache под Windows и другие. Правда, на поверку оказывается, что
некоторые версии в них еще более поздние.
Самостоятельная сборка модуля при помощи исходных текстов не сложна, хотя ее
порядок чуть меняется от версии к версии. Все зависимости вытянуть просто:
$ sudo apt-get build-dep libapache-modsecurity
Для работы ModSecurity понадобится модуль unique-id, в Ubuntu просто включаем
его:
$ sudo a2enmod unique_id
При самостоятельной сборке Apache необходимо сконфигурировать веб-сервер с
параметрами "--enable-uniqueid" и "--with-pcre". Распаковываем архив:
$ tar tar xzvf modsecurity-apache_2.5.12.tar.gz
$ cd modsecurity-apache_2.5.12/apache2
$ ./configure
Для сборки используется apxs (APache eXtenSion tool), который устанавливается
из зависимостей:
$ make
$ make test
All tests passed (576).
Опционально можно собрать коллектор журналов ModSecurity Log Collector, введя
"make mlogc". Ставим:
$ sudo make install
После чего следует изменить права доступа к собранному модулю:
$ sudo chmod 644 /usr/lib/apache2/modules/mod_security2.so
Редактируем конфиг веб-сервера, чтобы загружать нужные библиотеки и модули:
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
LoadModule security2_module modules/mod_
security2.so
Осталось отредактировать конфигурационный файл ModSecurity. При установке с
помощью пакетов он скопируется автоматически, а вот если ты использовал
исходники, то придется сделать это вручную:
$ sudo cp modsecurity-apache_2.5.12/modsecurity.conf-minimal /etc/apache2/mod_security.conf
Синтаксис и список параметров в конфиге в последних версиях изменился.
Настроек стало больше, но на первых порах можно использовать дефолтные. Все
подробности можно просмотреть в
документации ModSecurity. Вместе с ModSecurity поставляются правила CRS,
новую версию которых всегда можно скачать на OWASP (текущая версия 2.0.8, есть и
доступ к CVS). Например, в архиве с исходными текстами лежат два конфига,
настраивающих работу CRS и подкаталога с правилами base_rules и optional_rules.
Создадим для правил подкаталог /etc/apache2/modsecurity и скопируем в него
файлы:
$ sudo mkdir /etc/apache2/modsecurity
$ tar xzvf modsecurity-crs_2.0.8.tar.gz
$ sudo mv -v modsecurity-crs_2.0.8/* /etc/apache2/modsecurity/
Теперь все файлы следует подключить в конфиге апача:
<IfModule security2_module>
Include modsecurity/*.conf
Include modsecurity/base_rules/*.conf
# и если требуются опциональные правила
Include modsecurity/optional_rules/*.conf
</IfModule>
В конфиге modsecurity_crs_10_config.conf, описывающем работу правил
ModSecurity, указаны общие установки; изменяя значение некоторых параметров,
можно сделать их более лояльными или наоборот, установить параноидальный режим.
В каждых конкретных условиях лучше разбираться постепенно.
Теперь можно перезапускать апач:
$ sudo service apache2 start
И наслаждаться защищенными сервисами. Всю информацию по работе MosSecurity
можно получить, анализируя журналы, и в случае необходимости корректировать
настройки и правила.
Файервол уровня приложений Zorp
Разработчик популярного Syslog-NG, венгр Балазс Шайдлер , является также
автором еще одного проекта - Zorp. Его задача - защита приложений от
направленных атак. Являясь расширением к Netfilter/iptables, Zorp
представляет собой прозрачный прокси, который различает протоколы верхнего
уровня, "знает" их особенности и на основании настроек может принять решение
о необходимости продолжения текущего соединения. Версия
Zorp GPL доступна по
лицензии GNU GPL.
Suhosin - щит для PHP
Судя по результатам разных опросов, язык PHP является основным при разработке
веб-приложений, ему отдают предпочтение как минимум половина программистов. Но
не все они обладают опытом, достаточным для того, чтобы предусмотреть все
проблемы, в результате которых наскоро написанные сайты легко подвергаются
взлому. На сегодня известны несколько проектов, позволяющих повысить
защищенность: suPHP, htscanner и Suhosin. Проект
suPHP предлагает модуль для
Apache (mod_suphp) и оболочку для PHP, сочетание которых позволяет выполнять
PHP-скрипты с правами их владельца. В
htscanner
пошли еще дальше, позволив настраивать доступ к скриптам в стиле htaccess.
И, наконец, Suhosin,
задача которого куда серьезнее - низкоуровневая защита данных против атак на
переполнение буфера, уязвимостей форматной строки, различных реализаций include
(от ошибок в реализации функции realpath и экспериментальной поддержки защиты
SQL до фильтрации некоторого контента и многого другого). Полный список приведен
на сайте проекта в
Feature List.
Функционально Suhosin разделен на два компонента, которые могут
использоваться вместе или независимо друг от друга. Первая часть реализована в
виде патча к ядру PHP, обеспечивает низкоуровневую защиту (Engine Protection).
Некоторые приложения не особо дружат с Suhosin-патчами, поэтому не всегда в
дистрибутивах он идет в штатной поставке PHP.
Проверить наличие патча в своей сборке PHP очень просто. В Ubuntu 10.04:
$ sudo apt-get install php5-cli
$ php -v
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built:Sep 17 2010 13:49:46)
Вывод показывает, что PHP уже собран с патчем Suhosin. Вторая,
высокоуровневая часть реализована в виде модуля PHP suhosin.so, который легко
установить в любую систему без пересборки самого PHP. По сравнению с патчем,
модуль обеспечивает большее количество функций. Кроме различного рода блокировок
переменных, отсылки кода ответа и перенаправления браузера предусмотрена запись
событий в журнал или передача во внешний скрипт/программу. В Ubuntu он по
умолчанию не устанавливается.
$ sudo apt-get install php5-suhosin
Кроме собственно модуля устанавливается конфигурационный файл /etc/php5/conf.d/suhosin.ini.
Переменных внутри много, все они, кроме разрешающего загрузку модуля,
закомментированы. Описание параметров можно найти в man-странице и на сайте
проекта в документе
Configuration.
Заключение
Защитить веб-приложение, даже не зная всех его особенностей, вполне реально.
Тем не менее, любое из рассмотренных решений требует подгонки под конкретные
условия, чтобы работать с максимальной эффективностью!
