Чтобы разрешить серверу выполнять файлы с определенными расширениями, используется директива AddHandler. В конфигурационном файле httpd.conf можно найти следующие строки с этой командой:
AddHandler cgi-script .cgi
AddHandler server-parsed .shtml
Если у вас не установлен интерпретатор языка Perl, то первую строку следует закомментировать, чтобы она даже не смущала. Вторая строка безобидна, а вот если таким же образом разрешить серверу работать с НТМ- или HTML-файлами, то это уже станет небезопасным. Следующей строки не должно быть в вашем конфигурационном файле:
AddHandler server-parsed .html
Если где-то действительно есть необходимость подключения HTML-документа, то пропишите это в файле .htaccess. В остальных директориях я рекомендую в явном виде запретить обработку HTML-файлов сервером. Для этого добавьте следующую строку в конфигурационный файл httpd.conf или в файл .htaccess каждой директории:
RemoveHandler .html .htm
Таким образом, мы запретим выполнение файла на сервере, но не отменим SSI-инструкции. Например, следующий код в SHTML-файле будет выполнен:
<!-- #include virtual="filename.shtml" -->
Если вы не используете SSI и, соответственно, SHTML-файлы, то закомментируйте следующую строку (по умолчанию она доступна):
AddHandler server-parsed .shtml
7.6. Проще, удобнее, быстрее
Процесс конфигурирования должен быть максимально удобным. Если все настройки будут нагромождены в одном файле /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:
<Directory /home/* >
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
С помощью таких регулярных выражений удобно создавать общие правила для различных каталогов. Например, если указать в качестве директории значение /home/*/public_html, то все каталоги public_html в директории /home будут иметь указанные права, если нет явного переопределения для отдельных папок.
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. Основы безопасности
В настоящее время большинство взломов в Интернете совершается с помощью или благодаря ошибкам в сценариях Web-страниц. Давайте попробуем разобраться, почему это происходит.
Большинство владельцев домашних сайтов — это простые пользователи, которые хотят быстро получить собственную страницу с множеством возможностей. А что именно нужно сайту? Конечно же, это гостевая книга, форум, чат, голосование и т.д. Все эти разделы нельзя сделать с помощью языка разметки HTML, и нужны знания программирования, например, на Perl или PHP. Пользователи не хотят (или не могут) вникать в тонкости программирования, поэтому используют в своих проектах уже готовые (платные или бесплатные) движки.
Как я уже говорил, любая разработка содержит ошибки, просто о них до поры до времени не известно. А распространенная программа становится лакомым кусочком для любого хакера, потому что ее взлом позволяет приникнуть в систему, на которой установлена эта программа.
Если администратор сайта устанавливает на свою страничку популярный форум, то он должен понимать, что когда-нибудь в нем найдут уязвимость, и через нее любой злоумышленник проникнет в систему. Чтобы этого не произошло, администратор сайта должен регулярно обновлять используемые Web-программы и Web-сценарии.
