Linux глазами хакера - Михаил Флёнов
Шрифт:
Интервал:
Закладка:
Если вы решили написать собственный форум для сайта, то он может оказаться более надежным, если знать хотя бы основные принципы защиты Web-приложений. В этом случае ваша работа будет безопаснее, чем при использовании любой готовой программы и, тем более, программы с открытым кодом.
Ну а если вы не знаете особенностей языка или вообще не знакомы с программированием, то лучше даже не пытаться. В этом случае даже начинающий хакер найдет уязвимость, не зная исходного кода, структуры базы данных и других параметров, упрощающих взлом Web-сценария.
Как видите, сложности есть всегда. Самый безопасный вариант — использовать на Web-сайтах наименее распространенные программы, разработанные профессиональными программистами. Лучше всего, если они будут с закрытым кодом или даже написаны на заказ. Это требует дополнительных затрат, но расходы на восстановление системы после взлома намного больше.
Если вы отвечаете за один Web-сервер, то легко сможете контролировать обновление программ. Хуже всего администраторам хостинговых компаний. На их серверах расположены сотни, а то и тысячи Web-сайтов. Проследить за всеми хозяевами сайтов нереально, поэтому нужно защитить свои владения от недобросовестных или ленивых пользователей. Для этих целей лучше всего подходит программа jail, о которой мы говорили в гл. 4. Для Web-сервиса вы должны создать его собственный виртуальный сервер, в котором он и будет работать. Если злоумышленник взломает систему через Web-программу, то сможет нарушить работу только виртуальной директории.
Во время подготовки материалов для данной книги в одном из популярных форумов была найдена уязвимость, позволяющая выполнять любые команды на удаленной системе. Для этого нужно было директиву специальным образом передать через строку URL. Эту главу я начал писать через месяц после этого страшного открытия, и почему-то вспомнив про ошибку, решил проверить серверы в Интернете. Я запустил поиск всех сайтов, содержащих уязвимый форум. Вы не поверите, но их было сотни.
Меня заинтересовала пара сайтов, расположенных на серверах крупных хостинговых компаний. На обоих я выполнил команду ls -a /etc. Результат не заставил себя ждать. Я увидел всю директорию /etc, и моих прав хватало даже на удаление файлов. Конечно же, делать этого я не стал даже в тестовых целях. Для доказательства прав я переименовал по одному файлу на каждой системе и сообщил об уязвимости администраторам.
Внимание!Не советую вам повторять подобные действия. Взлом даже с добрыми намерениями не всеми администраторами воспринимается положительно. Некоторые могут сообщить о ваших действиях в правоохранительные органы, и тогда вам не избежать судебных тяжб. Благие побуждения могут быть восприняты неверно. Если я нахожу какую-либо дыру, то всегда сообщаю администраторам, но для этого отправляется анонимное письмо.
Конечно же, переместив 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);
□ SecFilter xxx redirect:http://www.webkreator.com — обеспечивает переадресацию. Если правила соблюдены, то пользователя отправляют на сайт http://www.webkreator.com;
□ SecFilter yyy log,exec:/home/apache/report-attack.pl — запускает сценарий. Если фильтр срабатывает, то будет выполнен скрипт /home/apache/report-attack.pl;
□ SecFilter /etc/password — устанавливает запрет на использование в запросе пользователя обращения к файлу /etc/passwd. Таким же образом нужно добавить ограничение на файл /etc/shadow;
□ SecFilter /bin/ls — отказ пользователям в обращении к директивам. В данном случае запрещается команда ls, которая может позволить хакеру увидеть содержимое каталогов, если в сценарии есть ошибка. Необходимо предотвратить обращение к таким командам, как cat, rm, cp, ftp и др.;
□ SecFilter "../" — классическая атака, когда в URL указываются символы точек. Их не должно там быть;
□ SecFilter "delete[[:space:]]+from" — запрет текста delete ... from, который чаще всего используется в SQL-запросах для удаления данных. Такая строка очень часто используется в атаках типа SQL injection. Помимо этого, рекомендуется установить следующие три фильтра:
• SecFilter "insert[[:space:]]+into" — используется в SQL-запросах для добавления данных;
• SecFilter "select.+from" — используется в SQL-запросах для чтения данных из таблицы базы данных;
• SecFilter "<(.|n)+>" и SecFilter "<[[:space:]]*script" — позволяют защититься от XSS-атак (Cross-Site Scripting, межсайтовое выполнение сценариев).
Мы рассмотрели основные методы, использование которых может повысить безопасность вашего Web-сервера. Таким образом, можно защищать даже сети из серверов. Дополнительную информацию можно получить с сайта разработчиков.
7.7.3. Секреты и советы
Как бы аккуратно программист не писал сценарии, как бы вы их не защищали с помощью специальных модулей, неплохо предпринять дополнительные меры безопасности. Есть еще ряд параметров, которыми можно воспользоваться для этих целей. В данном разделе я собрал небольшие рекомендации, которые вам помогут сделать необходимые настройки.
