7.7. Безопасность сценариев

7.7. Безопасность сценариев

Как мы уже говорили, сценарии являются очень опасными для Web-сервера (см. разд. 1.1.2). Через их ошибки происходило очень много громких взломов. Мы уже знаем, что необходимо отключить все интерпретаторы, которые не используются вами, и оставить только то, что нужно. Таким образом мы усложним задачу хакера, но не решим проблему полностью.

Наиболее безопасный сайт — это тот, что использует статичные (HTML) документы и не имеет сценариев, выполняемых на сервере (PHP, ASP, Perl, Python и др.). Если вам нужен какой-то интерпретатор, то необходимо максимально ограничить его возможности.

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

В интерпретаторе PHP есть возможность описывать правила выполнения каких-либо действий, используя более безопасные настройки и права доступа, — это режим safe_mode. Но вы должны отдавать себе отчет в том, что некоторые скрипты могут отказаться работать в этом режиме. Многие администраторы отключают safe_mode. Это не совсем верно. Я всегда сначала проверяю, можно ли переписать сценарий, и если это нереально, то только тогда выключаю безопасный режим.

При настройке интерпретатора вы опять же должны действовать от запрета. Изначально следует закрыть все, что нужно и ненужно. А потом включать необходимые вашим сценариям опции. Лучше всего, если вы будете заниматься конфигурированием не только рабочего сервера, но и сервера, который используют программисты для разработки и отладки своих сценариев. В этом случае можно будет контролировать все установленные параметры.

Действия администратора должны быть тесно связаны с работой программиста сценариев для Web-сайта. Если разработчику нужны какие-то опции, то именно вы должны их включать на обоих серверах. О любых корректировках скриптов, влекущих за собой уменьшение (увеличение) прав доступа, разработчик должен вам сообщать, и настройки должны быть изменены.

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

Все настройки для интерпретатора PHP хранятся в файле /etc/php.ini. Мы этот файл не будем рассматривать, потому что эта тема выходит за рамки книги по Linux.