Взлом и защита веб-сервера — на каждый яд есть свое противоядие

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

Все тесты проводились на сервере следующей конфигурации ОС: FreeBSD 6.0; Apache 2.0.x, PHP-5.2.x.

***

Согласно официальной статистике количество веб-сайтов, которые могут быть взломаны, составляет примерно 1/3. “Неужели хостинг-компании не способны обеспечить должный уровень защищенности веб-сайтов?” – спросят многие.

“Способны”, – отвечу я вам, вот только вопрос, какими усилиями.

Можно считать, что безопасность веб-сервера держится на двух китах. Первый из них - это непосредственно безопасность кода веб-приложения (этот вопрос мы оставим для программистов, слава Богу, статей на тему написания безопасного кода предостаточно). Второй - это тонкое конфигурирование сервера силами системного администратора или специалиста ИБ-шника, привлеченного со стороны. О втором “ките” мы как раз и поговорим.

Яды

На сегодняшний день в арсенале взломщиков имеется более десятка проверенных техник взлома веб-приложений. С полным перечнем вариантов взлома можно ознакомиться, изучив «Классификацию угроз безопасности веб-приложений» (согласно Web Application Security Consortium//www.webappsec.org). Популярнейшими из атак являются всего три. Кратко рассмотрим их.

1) SQL-injection (SQL-инъекция). На сегодняшний день является одним из самых популярных и опасных способов взлома сайтов. Атака основана на внедрении в запрос произвольного SQL-кода с целью получения критичной информации из баз данных (логины и хеши паролей пользователей). Технически подобная атака возможна из-за недостаточной фильтрации входящих данных, используемых в SQL-запросах. Взлом также возможен и по причине некорректно настроенной серверной ОС и ее приложений (Apache, PHP, MySQL).

2) PHP-including (внедрение PHP-кода). В отличие от XSS (где код выполнялся в браузере клиента; о XSS мы поговорим ниже) PHP-include позволяет выполнить произвольный код на стороне сервера. Различают два типа PHP-include:
- локальный PHP-include (LFI) — подразумевает выполнение PHP-кода, находящегося в пределах файловой системы сервера;
- глобальный PHP-include(RFI) — подразумевает выполнение PHP-кода путем подключения файлов извне.

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

Рис.1. Чтение системного файла /etc/passwd посредством локального PHP-include

В любом из случаев взломщик постарается выжать из обнаруженной уязвимости максимум. Как вариант – предварительно залив на сервер простейший веб-шелл (используя технику apache log file injection, к примеру), у хакера появится возможность выполнять произвольные команды от имени веб- сервера:

[pic]
Рис.2. Выполнение произвольных команд на стороне сервера

Даже если вы не используете php, и сайт создан исключительно на html – это еще не говорит о том, что его нельзя взломать. Почему так? Да все просто. Чаще всего на сервере хостится не один, а несколько веб-проектов (если это, конечно, не Dedicated или VPS-сервер с одним сайтом на борту). Достаточно взломать соседний, чтобы получить доступ к вашему. Да, существуют технологии, ограничивающие действия взломщиков в соседних каталогах в случае успешного взлома (как пример, suEXEC), но как оно всегда и бывает, внедрению подобных технологий препятствует сложность настройки, а порой и просто незнание.

3) XSS* (cross site scripting, межсайтовый скриптинг). Суть данной атаки заключается в том, чтобы внедрить в веб-страницу произвольный код, который впоследствии выполнится на стороне клиента (в браузере жертвы). Условно XSS делятся на активные и пассивные:

- активные XSS: вредоносный скрипт срабатывает в браузере жертвы, при открытии какой-либо страницы зараженного сайта; XSS подобного типа может иметь место при условии слабой фильтрации полей ввода. Как правило, подобный тип атаки может быть осуществлен с использованием некорректной фильтрации в полях профиля пользователя, комментариях и т.п.;

- пассивные XSS: данный тип XSS подразумевает некое дополнительное действие со стороны клиента, обычно это переход по специально
сформированной ссылке.

Чаще всего XSS используется для хищения cookies пользователя и как следствие - паролей и логинов.

*В контексте данной статьи мы не будем заострять внимание на защите от XSS, оставив эту задачу разработчикам ПО (большинство из XSS можно отнести к категории недоработок программного кода) и клиентам (в отличие от PHP-инклудинга и SQL-инъекций, которые выполняются на стороне сервера, XSS, как это уже было сказано выше, выполняется в браузере клиента). Резонными мерами защиты от XSS может быть использование плагина NoScript и прочих аналогичных модулей/надстроек браузера, на лету фильтрующих подозрительное содержание веб-страниц.

Противоядия

Начнем, пожалуй. Рассмотрим создание многоуровневой системы защиты пошагово.

Рис. 3. SNORT: Зафиксирована попытка использования exploit’а

Ставим IDS (Intrusion Detection System - система обнаружения вторжений), как хороший пример – SNORT. Принцип работы IDS основан на обнаружении сигнатур возможных атак. IDS позволит нам оперативно анализировать попытки взлома и принимать эффективные решения для защиты сервера. Также следует отметить и то, что альтернативой IDS может стать IPS (Intrusion Prevention System - система предотвращения атак), и это в большей степени зависит от предназначения и загрузки сервера.

После запуска SNORT все нехорошие запросы будут записываться в лог-файл:

Рис. 4. SNORT: Зафиксирована попытка атаки «webroot directory traversal»

Как видите, теперь у нашего сервера есть первый рубеж обороны – SNORT, способный проинформировать администратора сервера о подозрительной активности извне.

Едем дальше.

Помещаем Apache и MySQL в chroot. Напомню нашим читателям, что chroot представляет собой ограниченную для доступа наружу (к реальной файловой системе) среду, позволяющую минимизировать последствия в случае успешного взлома. Методология создания chroot-среды хорошо отработана и документирована, и фактически сводится к созданию в файловой системе автономной зоны со своим набором файлов и папок.

Рис.5. Запуск MySQL в chroot-окружении

Теперь, даже в случае успешного взлома, взломщик не получит доступа к реальной файловой системе со всеми вытекающими отсюда последствиями.
Подключаем Mod_rewrite и Mod_security. Mod_rewrite позволяет эффективно манипулировать реальными путями и именами файлов, усложняя тем самым попытки взлома.

Mod_security очень часто называют веб-антивирусом, и это отчасти верно. Именно благодаря mod_security становится возможным предотвращение большинства типов атак – таких, например, как SQL-injection и PHP-Including.
Рассмотрим на реальном примере результат работы mod-security. При попытке прочитать системные файлы в лог-файлах вашего сервера вы увидите примерно следующее:

Рис.6. Mod_security: предотвращена попытка удаленного просмотра системных файлов

Ответ веб-браузера при попытке просмотра системного файла при включенном mod_security выдаст вам “Method Not Implemented”:

Рис.7

Мы уже прошли большой путь, установив SNORT, поместив Apache и MySQL в chroot, подключив модули mod_security и mod_rewrite, но это еще не все :).
Следующим шагом на пути создания многоуровневой защиты нашего веб-сервера станет непосредственно конфигурирование Apache и PHP.

Делаем Apache менее разговорчивым

Подробную инструкцию по конфигурированию Apache можно найти на официальном сайте www.apache.org, здесь же мы ограничимся минимумом. Подразумевается, что ваш веб-сервер уже настроен и не содержит таких досадных ошибок администрирования, как, к примеру, доступные для индексирования директории с конфиденциальными данными и права rwxrwxrwx на файл «.htaccess». Основным файлом настроек для апача является httpd.conf.

Наш минимум сделать апач менее разговорчивым с «незнакомыми» посредством добавления (изменения) следующих строк:
ServerTokens Prod и Server Signature Off.

Делаем выполнение PHP-кода более безопасным

Настройка безопасности PHP имеет свои подводные камни, и это связано с тем, что часто приходится выбирать: либо безопасность, либо производительность и функциональность. В данном случае наиболее резонно будет придержаться золотой середины.

Первым делом нам необходимо установить Suhosin Patch (в последних версиях PHP Suhosin устанавливается вместе с PHP по умолчанию). Напомню нашим читателям, что данный пакет позволяет эффективно контролировать выполнение потенциально опасного PHP-кода.

Изменяем настройки PHP, для этого нам надо отредактировать его главный файл настроек php.ini (в Unix-подобных системах конфигурационный файл может быть размещен, к примеру, здесь: /usr/local/etc/php.ini для Free BSD или здесь: /etc/php.ini для Linux систем).

. register_globals=Off – отключаем глобализацию переменных. Значение в On – пожалуй, самая известная ошибка конфигурирования PHP;
. safe_mode=On - включаем жесткий режим ограничений (с этой настройкой следует быть аккуратным);
. open_basedir= /www – ограничиваем место выполнения PHP-кода;
. magic_quotes=On - включаем «магические кавычки» для GET/POST/COOKIE - препятствует SQL-inj;
. mysql.trace_mode=Off - отключаем показ ошибок Mysql;
. allow_url_fopen=Off - отключаем удаленное открытие файлов файловыми функциями (препятствует удаленному PHP-инклуду);
. allow_url_include=Off - отключаем удаленное подключение файлов (препятствует удаленному PHP-инклуду);
. error_reporting=Off - отключаем показ всех ошибок (действительно, зачем посвящать взламывающего во все тонкости работы сервера:)); . disable_functions= exec, system, passthru – задаем ограничение на использование потенциально опасных функций.

Итак, давайте теперь посмотрим, как отреагирует наш веб-сервер на попытку использования запрещенной функции (мы неслучайно отключили exec, system и passthru – эти функции активно используются при написании самодельных веб-шеллов!):

Рис. 8. Ограничение на использование потенциально опасных функций

Взломщик получит предупреждение о невозможности использования данной функции на сервере.

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

Все что остается - регулярно анализировать содержимое log-файлов, следить за bug-треками и при необходимости обновлять ваше серверное ПО. Если у вас возникли вопросы, касающиеся обеспечения безопасности веб-сервера, или вам интересны технические детали установки обсуждаемых в статье пакетов и модулей - будем рады видеть вас на нашем форуме по адресу: www.mega-admin.com.

Олег Бойцев