Чтение онлайн

□ 

— использовать модифицированный Apache алгоритм MD5 для паролей. Это позволит переносить созданный файл на любую другую платформу (Windows, Unix, BeOS и т.д.), где работает Web-сервер Apache. Такой ключ удобен, если у вас разнородная сеть, и один файл с паролями используется на разных серверах;

□ 

— для шифрования будет применяться системная функция ;

□ 

— применить SHA-шифрование (на базе алгоритма хэширования), которое используется на платформе Netscape;

□ 

— не шифровать пароли. Я не рекомендую устанавливать этот флаг, потому что он небезопасен;

□ 

— не вносить никаких изменений, а только вывести результат на экран.

Для добавления нового пользователя можно выполнить команду без указания ключей, а передать в качестве параметров только имена файла и пользователя:

У команды htpasswd есть два ограничения: в имени пользователя не должно быть символа двоеточия, и пароль не может превышать 255 символов. Оба условия достаточно демократичны и с ними можно смириться. Из моих знакомых такой длинный пароль пока еще никто не захотел устанавливать, а задавать имя пользователя с двоеточием редко кому приходит на ум.

Авторизация — это слишком простой способ обеспечения безопасности. При передаче пароли шифруются простым кодированием Base64. Если хакер сможет перехватить пакет, содержащий имя пользователя и пароль, то он прочитает эту информацию через пять секунд. Для расшифровки Base64 не нужно подбирать пароль, достаточно выполнить одну функцию, которая декодирует практически моментально.

Для создания реально безопасного соединения необходимо сначала зашифровать весь трафик. Для этого может использоваться stunnel или уже готовый протокол HTTPS, который использует SSL. О нем мы еще поговорим в разд. 10.9.

HTML-файлы могут обрабатываться прямо на сервере (так же, как выполняются файлы PHP). С одной стороны, это удобно, потому что код PHP можно будет вставлять в файлы с расширением htm, с другой стороны, HTML-файлы далеко небезопасны, и если хакер сможет их изменять, то сервер окажется под угрозой.

Чтобы разрешить серверу выполнять файлы с определенными расширениями, используется директива

. В конфигурационном файле httpd.conf можно найти следующие строки с этой командой:

Если у вас не установлен интерпретатор языка Perl, то первую строку следует закомментировать, чтобы она даже не смущала. Вторая строка безобидна, а вот если таким же образом разрешить серверу работать с НТМ- или HTML-файлами, то это уже станет небезопасным. Следующей строки не должно быть в вашем конфигурационном файле:

Если где-то действительно есть необходимость подключения HTML-документа, то пропишите это в файле .htaccess. В остальных директориях я рекомендую в явном виде запретить обработку HTML-файлов сервером. Для этого добавьте следующую строку в конфигурационный файл httpd.conf или в файл .htaccess каждой директории:

Таким образом, мы запретим выполнение файла на сервере, но не отменим SSI-инструкции. Например, следующий код в SHTML-файле будет выполнен:

Если вы не используете SSI и, соответственно, SHTML-файлы, то закомментируйте следующую строку (по умолчанию она доступна):

Процесс конфигурирования должен быть максимально удобным. Если все настройки будут нагромождены в одном файле /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: