 |
|
|
|
Как повысить безопасность веб-приложений
Как повысить безопасность веб-приложений Хорошая вещь швейцарский нож: есть и ножницы, пилочка, отвертка и еще много нужных предметов, но вот пользоваться им не очень удобно. В повседневной жизни лучше применять индивидуальный инструмент. В мире безопасности аналогичная ситуация. Традиционно для защиты сетевых приложений используют системы обнаружения и остановки атак, а также межсетевые экраны, работающие на третьем сетевом уровне модели 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
Последнее сообщение говорит о том, что в конфигурационный файл веб-сервера занесена строка для запуска 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. Действия, выполняемые при совпадении запроса
Правила 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
Тестируем правила Для тестирования работы 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.01, запрещен модулем mod_security, потому что совпал образец «cgi-bin».
Кстати, на основании этой записи можно уже оптимизировать правило. Вот так: SecFilterSelective REQUEST_URI "cgi-bin" Теперь журналы ModSecurity. Файл modsec_audit.log содержит всю информацию о запросе.
А в modsec_debug.log найдете информацию обо всех использованных при запросе правилах.
Выводы Только система, не подключенная к сети, может быть 100% безопасной, но веб-сервис должен быть публичным, иначе он теряет смысл. Выявить все слабые места практически не возможно. По данным компании Netcraft, отслеживающей, какое программное обеспечение используется серверами в Интернете, хакеры всё чаще эксплуатируют дыры в распространенных приложениях на основе РНР. Обычный межсетевой экран здесь не помогает. Только специализированное программное обеспечение способно остановить атаку. ModSecurity чрезвычайно функциональный, простой в конфигурировании и главное совершенно бесплатный инструмент, использование которого позволит повысить безопасность предоставляемых веб-услуг, а относительная легкость написания правил поможет быстро среагировать на угрозу. Литература, ссылки:
|
Сергей Яремчук
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
