Linux глазами хакера

Внимание!

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

Конечно же, переместив Apache в виртуальное пространство, вы обезопасите только свою систему, но все сайты, которые работают в этом пространстве, остаются уязвимыми. Здесь уже нужно искать другие методы защиты, например, через права доступа, запуск нескольких копий Apache (каждый работает в своем пространстве), выделенные серверы для каждого сайта, запрет на выполнение опасных функций в интерпретаторе PHP и т.д.

Выбрать какой-либо определенный метод защиты множества виртуальных серверов достаточно сложно, а иногда просто невозможно. Например, один сайт требует для своей работы интерпретатор Perl, а другой — PHP. Приходится включать обе возможности.

Из собственного опыта могу посоветовать использовать несколько физических серверов для разделения хранимых сайтов в соответствии с их потребностями:

□ используется интерпретатор PHP в защищенном режиме;

□ нужен интерпретатор PHP с полными правами;

□ применяется интерпретатор Perl.

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

Особо важные сайты должны располагаться на выделенном сервере и находиться под пристальным присмотром. Например, нельзя размещать на одном

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

7.7.2. mod_security

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

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

Правила определяют, что может быть в запросе, а что нет. Там обычно содержится URL-адрес, с которого необходимо взять документ или файл. Как можно сформулировать правило для модуля с точки зрения безопасности системы? Рассмотрим простейший пример — для сервера опасно незаконное обращение к файлу /etc/passwd, а значит, его не должно быть в строке URL.

Таким образом, сетевой экран проверяет на основе заданных фильтров адрес URL, и если он нарушает правила, то запрос отклоняется.

Итак, модуль mod security находится на сайте http://www.modsecurity.org, После его установки в файле httpd.conf можно будет использовать дополнительные директивы, фильтрации запросов. Рассмотрим наиболее интересные из них:

□ SecFilterEngine On

— включить режим фильтрации запросов;

□ SecFilterCheckURLEncoding On — проверять кодировку URL (URL encoding is valid);

□ SecFilterForceByteRange 32 126 — использовать символы только из указанного диапазона. Существует достаточное количество служебных символов (например, перевод каретки, конец строки), коды которых менее 32. Большинство из них невидимы, но требуют обработки нажатия соответствующих клавиш. Но как же тогда хакер может ввести такой символ в URL? Только через их код. Например, чтобы применить символ "конец строки", необходимо указать в URL-адресе "%13". В данном случае коды символов менее 32 и более 126 являются недопустимыми для адреса, поэтому вполне логично такие пакеты не пропускать к Web-сервер;

□ SecAuditLog logs/audit_log — определяет файл журнала, в котором будет сохраняться информация об аудите;

□ SecFilterDefaultAction "deny,log,status:406" — задает действие по умолчанию. В данном случае указан запрет (deny);