Флёнов Михаил Евгеньевич
Шрифт:
Процесс конфигурирования должен быть максимально удобным. Если все настройки будут нагромождены в одном файле /etc/httpd/conf/httpd.conf, то разобраться в них станет очень сложно. А чем больше параметров, тем выше вероятность, что вы что-либо прозеваете. Чтобы упростить поддержку вашего Web-сервера, могу посоветовать придерживаться следующих рекомендаций:
□ для удобства администрирования все описания прав доступа можно перенести в конфигурационный файл /etc/httpd/conf/access.conf. По умолчанию этот файл пустой, а все используют только /etc/httpd/conf/httpd.conf. Выделение части разрешений в отдельный файл действительно может помочь в управлении, потому что права будут видны, как на ладони;
□ основные настройки сервера, которые редко изменяются, можно перенести в конфигурационный файл /etc/httpd/conf/access.conf;
□ комментируйте все ваши действия. Многие настройки не изменяются годами, и уже через пару месяцев трудно вспомнить, зачем вы установили определенную директиву. Например, вы запретили доступ для всех пользователей к какой-либо директории, которая временно использовалась для тестирования сценариев. Через какое-то время вы можете забыть это и случайно откроете доступ к сценариям, которые отлажены не полностью и могут стать причиной взлома и крушения системы.
Чем удобнее управлять безопасностью сервера, тем меньше ошибок вы совершите, потому что все параметры правильно сгруппированы, и подробные комментарии напоминают вам о назначении сделанных настроек. Такой подход к администрированию также помогает оперативно решать возникающие проблемы. А как известно, в войне администраторов и хакеров побеждает тот, кто больше знает, имеет больше опыта и быстрее реагирует. Последнее очень важно.
Централизованное хранение прав доступа в конфигурационных файлах Web-сервера приемлемо только на небольших сайтах. Когда работает сотня виртуальных серверов, то такие описания становятся слишком громоздкими. Даже если все права выделить в отдельный файл /etc/httpd/conf/access.conf, его размер будет слишком велик, чтобы найти в нем что-то нужное.
Для больших сайтов я рекомендую описывать в конфигурационных файлах сервера только общие правила, которые затрагивают сразу несколько директорий. Это возможно, потому что при указании пути к каталогу можно использовать регулярные выражения. Приведу пример, который определяет правила для всего, что находится в директории /home:
С помощью таких регулярных выражений удобно создавать общие правила для различных каталогов. Например, если указать в качестве директории значение
7.7. Безопасность сценариев
Как мы уже говорили, сценарии являются очень опасными для Web-сервера (см. разд. 1.1.2). Через их ошибки происходило очень много громких взломов. Мы уже знаем, что необходимо отключить все интерпретаторы, которые не используются вами, и оставить только то, что нужно. Таким образом мы усложним задачу хакера, но не решим проблему полностью.
Наиболее безопасный сайт — это тот, что использует статичные (HTML) документы и не имеет сценариев, выполняемых на сервере (PHP, ASP, Perl, Python и др.). Если вам нужен какой-то интерпретатор, то необходимо максимально ограничить его возможности.
Допустим, что ваш сайт использует сценарии PHP, и в нем есть функции, которые обращаются к системе, и если вы их неверно используете (например, не проверяются параметры, заданные пользователем), то злоумышленник имеет возможность передать такие значения, которые могут нарушить работу сервера. Мы не будем говорить о том, как правильно писать сценарии и как их делать безопасными, потому что это задача программистов. Но мы не должны надеяться на их профессионализм, потому что все мы — люди, и нам свойственно ошибаться. Мы должны сделать все, чтобы погрешности не стали фатальными.
В интерпретаторе PHP есть возможность описывать правила выполнения каких-либо действий, используя более безопасные настройки и права доступа, — это режим safe_mode. Но вы должны отдавать себе отчет в том, что некоторые скрипты могут отказаться работать в этом режиме. Многие администраторы отключают safe_mode. Это не совсем верно. Я всегда сначала проверяю, можно ли переписать сценарий, и если это нереально, то только тогда выключаю безопасный режим.
При настройке интерпретатора вы опять же должны действовать от запрета. Изначально следует закрыть все, что нужно и ненужно. А потом включать необходимые вашим сценариям опции. Лучше всего, если вы будете заниматься конфигурированием не только рабочего сервера, но и сервера, который используют программисты для разработки и отладки своих сценариев. В этом случае можно будет контролировать все установленные параметры.