Linux глазами хакера
Шрифт:
С помощью таких регулярных выражений удобно создавать общие правила для различных каталогов. Например, если указать в качестве директории значение
7.7. Безопасность сценариев
Как мы уже говорили, сценарии являются очень опасными для Web-сервера (см. разд. 1.1.2). Через их ошибки происходило очень много громких взломов. Мы уже знаем, что необходимо отключить все интерпретаторы, которые не используются вами, и оставить только то, что нужно. Таким образом мы усложним задачу хакера, но не решим проблему полностью.
Наиболее безопасный сайт — это тот, что использует статичные (HTML) документы и не имеет сценариев, выполняемых на сервере (PHP, ASP, Perl, Python и др.). Если вам нужен какой-то интерпретатор, то необходимо максимально ограничить его возможности.
Допустим, что ваш сайт использует сценарии PHP, и в нем есть функции, которые обращаются к системе, и если вы их неверно используете (например, не проверяются параметры, заданные пользователем), то злоумышленник имеет возможность передать такие значения, которые могут нарушить работу сервера. Мы не будем говорить о том, как правильно писать сценарии и как их делать безопасными, потому что это задача программистов. Но мы не должны надеяться на их профессионализм, потому что все мы — люди, и нам свойственно ошибаться. Мы должны сделать все, чтобы погрешности не стали фатальными.
В интерпретаторе PHP есть возможность описывать правила выполнения каких-либо действий, используя более безопасные настройки и права доступа, — это режим safe_mode. Но вы должны отдавать себе отчет в том, что некоторые скрипты могут отказаться работать в этом режиме. Многие администраторы отключают safe_mode. Это не совсем верно. Я всегда сначала проверяю, можно ли переписать сценарий, и если это нереально, то только тогда выключаю безопасный режим.
При настройке интерпретатора вы опять же должны действовать от запрета. Изначально следует закрыть все, что нужно и ненужно. А потом включать необходимые вашим сценариям опции. Лучше всего, если вы будете заниматься конфигурированием не только рабочего сервера, но и сервера, который используют программисты для разработки и отладки своих сценариев. В этом случае можно будет контролировать все установленные параметры.
Действия администратора должны быть тесно связаны с работой программиста сценариев для Web-сайта. Если разработчику нужны какие-то опции, то именно вы должны их включать на обоих серверах. О любых корректировках скриптов, влекущих за собой уменьшение (увеличение) прав доступа, разработчик должен вам сообщать, и настройки должны быть изменены.
Администратор и разработчик должны находиться в постоянном контакте, чтобы оперативно реагировать на необходимость использования каких-либо дополнительных возможностей. Некоторые администраторы избавляются от настройки интерпретаторов и переводят эти функции на разработчиков. Это не совсем правильно, потому что программист пишет код и не может достаточно хорошо разбираться в вопросах конфигурации серверов, чтобы обеспечить требуемый уровень безопасности.
Все настройки для интерпретатора PHP хранятся в файле /etc/php.ini. Мы этот файл не будем рассматривать, потому что эта тема выходит за рамки книги по Linux.
7.7.1. Основы безопасности
В
Большинство владельцев домашних сайтов — это простые пользователи, которые хотят быстро получить собственную страницу с множеством возможностей. А что именно нужно сайту? Конечно же, это гостевая книга, форум, чат, голосование и т.д. Все эти разделы нельзя сделать с помощью языка разметки HTML, и нужны знания программирования, например, на Perl или PHP. Пользователи не хотят (или не могут) вникать в тонкости программирования, поэтому используют в своих проектах уже готовые (платные или бесплатные) движки.
Как я уже говорил, любая разработка содержит ошибки, просто о них до поры до времени не известно. А распространенная программа становится лакомым кусочком для любого хакера, потому что ее взлом позволяет приникнуть в систему, на которой установлена эта программа.
Если администратор сайта устанавливает на свою страничку популярный форум, то он должен понимать, что когда-нибудь в нем найдут уязвимость, и через нее любой злоумышленник проникнет в систему. Чтобы этого не произошло, администратор сайта должен регулярно обновлять используемые Web-программы и Web-сценарии.
Если вы решили написать собственный форум для сайта, то он может оказаться более надежным, если знать хотя бы основные принципы защиты Web-приложений. В этом случае ваша работа будет безопаснее, чем при использовании любой готовой программы и, тем более, программы с открытым кодом.
Ну а если вы не знаете особенностей языка или вообще не знакомы с программированием, то лучше даже не пытаться. В этом случае даже начинающий хакер найдет уязвимость, не зная исходного кода, структуры базы данных и других параметров, упрощающих взлом Web-сценария.
Как видите, сложности есть всегда. Самый безопасный вариант — использовать на Web-сайтах наименее распространенные программы, разработанные профессиональными программистами. Лучше всего, если они будут с закрытым кодом или даже написаны на заказ. Это требует дополнительных затрат, но расходы на восстановление системы после взлома намного больше.
Если вы отвечаете за один Web-сервер, то легко сможете контролировать обновление программ. Хуже всего администраторам хостинговых компаний. На их серверах расположены сотни, а то и тысячи Web-сайтов. Проследить за всеми хозяевами сайтов нереально, поэтому нужно защитить свои владения от недобросовестных или ленивых пользователей. Для этих целей лучше всего подходит программа jail, о которой мы говорили в гл. 4. Для Web-сервиса вы должны создать его собственный виртуальный сервер, в котором он и будет работать. Если злоумышленник взломает систему через Web-программу, то сможет нарушить работу только виртуальной директории.
Во время подготовки материалов для данной книги в одном из популярных форумов была найдена уязвимость, позволяющая выполнять любые команды на удаленной системе. Для этого нужно было директиву специальным образом передать через строку URL. Эту главу я начал писать через месяц после этого страшного открытия, и почему-то вспомнив про ошибку, решил проверить серверы в Интернете. Я запустил поиск всех сайтов, содержащих уязвимый форум. Вы не поверите, но их было сотни.
Меня заинтересовала пара сайтов, расположенных на серверах крупных хостинговых компаний. На обоих я выполнил команду