| Russian LinkExchange Member |
| Наверх, к Содержание |
||
| Назад, к Вопрсы общего
порядка |
Вперед, к Защита
конфиденциальных документов |
Для максимальной безопасности важно соблюдать политику "необходимости знания" как в отношении корневого директория дерева документов (та часть диска, где хранятся документы HTML), так и в отношении корневого директория сервера (где хранятся файлы настроек и трассировки). Очень важно правильно регулировать права доступа к директорию сервера, поскольку именно здесь хранятся скрипты CGI и файлы с важной информацией о настройках и трассировке.
Вам необходимо защитить сервер от нежелательных взглядов как внутренних, так и внешних пользователей. Простейший способ достижения этой цели - создание пользователя "www" для администратора WWW-сервера и группы пользователей "www" для всех пользователей вашей системы, которые должны создавать HTML документы. В системах семейства Unix отредактируйте файл /etc/passwd так, чтобы сделать корневой директорий сервера домашним директорием пользователя www. Отредактируйте файл /etc/group так, чтобы добавить всех разработчиков к группе www.
Корневой директорий сервера должен быть организован так, чтобы только пользователь www имел право записи в директории, содержащие конфигурационные файлы и файлы трассировки. По вашему желанию можно разрешить доступ для чтения к этим директориям для пользователей группы www. Эти директории _не должны_ быть общедоступны для чтения. Директорий cgi-bin и его содержимое должны быть общедоступны для чтения и выполнения, но не для записи (если вы доверяете вашим разработчикам, входящим в группу www, то вы можете разрешить им запись в этот директорий). Ниже приведен пример установки прав доступа к каталогам сервера:
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/ drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/ -rwx------ 1 www www 109674 May 8 23:58 httpd drwxrwxr-x 2 www www 1024 Aug 8 00:01 htdocs/ drwxrwxr-x 2 www www 1024 Jun 3 21:15 icons/ drwxr-x--- 2 www www 1024 May 4 22:23 logs/
Иные требования относятся к корневому директорию дерева документов. Все файлы, которые вы хотите предоставлять пользователям Internet, должны быть доступны для чтения сервером в то время, когда он работает с правами пользователя "nobody". Возможно вы захотите также дать вашим разработчикам документов возможность свободно добавлять файлы к дереву документов. Поэтому вам следует сделать корневой директорий дерева документов и его подкаталоги принадлежащими пользователю и группе "www", общедоступными для чтения и доступными для записи пользователями группы www:
drwxrwxr-x 3 www www 1024 Jul 1 03:54 contents drwxrwxr-x 10 www www 1024 Aug 23 19:32 examples -rw-rw-r-- 1 www www 1488 Jun 13 23:30 index.html -rw-rw-r-- 1 lstein www 39294 Jun 11 23:00 resource_guide.html
Многие серверы позволяют открывать доступ к частям дерева документов только для браузеров с определенными IP адресами или для внешних пользователей, предоставляющих правильный пароль (см. ниже). Однако, в некоторых случаях администраторы системы могут хотеть закрыть доступ к некоторым HTML документам для _внутренних_ пользователей, не имеющих для этого права. Это является проблемой в случае, если корневой директорий дерева документов общедоступен для чтения.
Одно из решений этой проблемы состоит в том, чтобы запускать сервер не с правами пользователя nobody, а как другого непривилегированного пользователя, принадлежащего группе www. В этом случае можно сделать защищенные документы доступными для чтения группой www, но не всеми пользователями (в этом случае, если вы не хотите, чтобы сервер имел возможность изменять свои документы, не давайте группе www прав записи в директории дерева документов!). Теперь документы защищены от нежелательных взглядов как внутренних, так и внешних глаз. Не забудте установить правильные права доступа также для всех скриптов CGI.
Сервер CERN развивает эти возможности, позволяя запускать сервер с разными правами пользователя и группы для различных частей дерева документов. Информация о том, как этого достичь, содержится в документации сервера.
В том случае, когда ваш сервер запускается с правами пользователя root, но в процессе работы пользуется правами доступа другого пользователя (смотри В11), особенно важно запретить запись в директорий, содержащий файлы трассировки, для того пользователя, правами которого располагает сервер при работе. Например, серверы Netscape FastTrack и SuiteSpot при установке разрешают запись в директорий с файлами трассировки для пользователя, с правами которого работает сервер (пользователь "nobody" в том случае, если вы выбрали настройки по умолчанию). Это может приводить к тому, что некоторые ошибки в скриптах CGI станут гораздо более опасными, чем в иных ситуациях. Напимер, если ошибка в скрипте позволяет удаленному пользователю выполнять произвольные команды на сервере, то пользователь может получить права доступа пользователя root (системного администратора), заменив файл трассировки ссылкой на файл /etc/passwd. При перезапуске сервера ссылка приведет к тому, что владельцем файла /etc/passwd станет пользователь nobody. Теперь удаленный пользователь может использовать ошибку в скрипте для редактирования файла /etc/passwd и добавления в систему нового пользователя. Предлагаемый способ борьбы с проблемой состоит в том, чтобы изменить права доступа к директорию с файлами трассировки сервера так, чтобы запретить запись для пользователя, с правами которого работает сервер, после чего создать пустые файлы трассировки (log) и идентификатора процесса (pid), принадлежащие этому пользователю (сервер не будет запускаться в случае, если не сможет открыть эти файлы). Хотя это не лучшее решение, поскольку оно позволяет хакерам редактировать файлы трассировки, такая конфигурация все-таки лучше той, которая используется по умолчанию. Эта лазейка может присутствовать также в других коммерческих серверах. Спасибо Laura Pearlman за эту информацию.
Да. Многие возможности, увеличивающие удобство установки и поддержания сервера, увеличивают также вероятность взлома. Ниже приведен список потенциально опасных возможностей. Если вы не испытываете абсолютной необходимости в их использовании - выключите их.
Конечно, выключив возможность автоматического просмотра директориев, вы не помешаете пользователям получить доступ к файлам, имена которых они узнали другим образом. Имена файлов могут быть также случайно включены в индексы, порождаемые программой автоматического поиска по ключевым словам. Для полной безопасности необходимо полностью удалять из вашего дерева документов все файлы, которые вы хотите защитить.
Серверы NCSA и Apache позволяют полностью отключить отслеживание ссылок. Дополнительно существует возможность позволять следовать ссылке только в том случае, если она принадлежит тому же пользователю, которому принадлежит то, на что она указывает. Вы можете таким образом нарушить безопасность только той части дерева документов, которой владеете, но не чужой.
Options IncludesNoExec
В Сети наблюдалось некоторое недопонимание и несогласие в этом вопросе. Большинство серверов запускаются с правами пользователя root, что позволяет им открывать порт 80 (стандартный порт для протокола http) и производить запись в файлы трассировки. Затем сервер ждет запросов к порту 80. Когда приходит внешний запрос, сервер запускает дочерний процесс для обработки запроса и возвращается к режиму ожидания. Дочерний процесс изменяет идентификатор пользователя, правами которого он пользуется, на пользователя "nobody", после чего продолжает обработку внешнего запроса. Все действия, совершаемые в ответ на пришедший запрос - выполнение скриптов CGI или обработка вставок на сервере - выполняются с правами непривилегированного пользователя nobody.
Когда говорят об "опасности запуска сервера с правами пользователя root", то подразумевают другую схему. Опасность состоит в настройке сервера для запуска _дочерних процессов_ с правами root (т.е. в директиве "User root" в конфигурационном файле сервера). Это действительно большой риск, так как любой скрипт CGI, запущенный с правами root, имеет доступ во все щели и углы вашей системы.
Некоторые считают, что лучше вообще не запускать сервер с правами root, поскольку мы не знаем, какие ошибки могут содержаться в той части программы, которая работает между запуском сервера и моментом запуска дочернего процесса. Это действительно так, хотя исходные тексты программ всех свободно распространяемых серверов открыты для публичного доступа, и в них, _похоже_, не содержится ошибок в этих частях программы. Запуск сервера с правами обычного непривилегированного пользователя может быть безопаснее. Многие серверы запускаются как nobody, daemon или www. Однако следует учитывать две потенциальные сложности, связанные с таким подходом:
Многие узлы предпочитают использовать одни и те же директории для демонов FTP и Web. Это безопасно в том случае, если для внешнего пользователя FTP закрыта возможность записи на сервере файла, который может быть затем запущен демоном Web.
Рассмотрим сервер WWW, настроенный на запуск любого файла с расширением .cgi. Хакер, используя доступ через FTP, сохраняет на сервере файл с программой на языке perl и присваивает ему расширение .cgi. После этого он запрашивает этот файл через браузер, обращаясь к вашему Web серверу. Вот, собственно, и все - хакер выполнил на вашей машине любые команды, какие ему пришли в голову.
Вы можете объединять области доступа ftp и www, но при этом ограничте пространство, доступное для сохранения файлов через ftp, директорием "incoming", и не предоставляйте пользователю nobody прав на чтение из этого директория.
Вы не можете полностью обезопасить свой сервер, но можете значительно повысить его защищенность в системах семейства Unix, если будете запускать его в среде chroot. Системная команда chroot помещает сервер в "скорлупу" таким образом, что он не может видеть системных областей за пределами того места, которое ему выделено. Выбранный вами директорий становится системным корневым директорием ("/") для сервера. Все, что находится выше него, становится недоступным.
Для запуска сервера в среде chroot вы должны создать миниатюрную копию системного дерева подкаталогов и поместить туда все, что необходимо для работы сервера, включая специальные файлы устройств и загружаемые библиотеки. Вам придется также отредактировать все пути доступа к файлам в файлах настройки сервера с тем, чтобы привести их в соответствие с новым корневым директорием сервера. Для запуска сервера в такой среде, создайте системный командный файл, выполняющий команду chroot следующим образом:
chroot /путь/к/новому/корню /путь_к_серверу/httpd
Настройка нового корневого директория может
быть достаточно сложной, ее обсуждение выходит
за рамки рассмотрения настоящего документа. За
деталями можно обратиться к книге автора (см.
выше). Следует иметь в виду, что среда chroot
наиболее эффективна в том случае, если новый
корневой каталог содержит как можно меньше
вещей. Там не должно быть никаких
интерпретаторов, оболочек или конфигурационных
файлов (включая /etc/passwd!). К сожалению, это
значит, что скрипты CGI, использующие язык perl, не
смогут работать в такой среде. Вы можете
поместить туда интерпретатор perl, но вы теряете
при этом некоторые преимущества среды chroot.
Учтите также, что chroot защищает только файлы, не являясь при этом панацеей. Chroot не помешает хакерам проникнуть в вашу систему другими путями, например - получая системные карты через сервер NIS, или проводя эксперименты с NFS.
Вы можете использовать брандмауэр для повышения безопасности на вашем сервере различными способами. Наиболее простой путь - создание "внутреннего сервера", который доступен только для компьютеров в вашей локальной сети. Если это то, что вам нужно, то вы просто должны поместить сервер за брандмауэром:
другой компьютер
\
сервер <-----> БРАНДМАУЭР <------> ВНЕШНИЙ МИР
/
еще компьютер
Однако, если вы хотите сделать сервер доступным для внешнего мира, то вам придется поместить его за пределами брандмауэра. С точки зрения безопасности вашей организации как целого, лучше всего вообще вынести сервер за пределы локальной сети:
компьютер
\
компьютер <----> БРАНДМАУЭР <---> сервер <----> ВНЕШ.МИР
/
компьютер
Такая конфигурация называется "жертвенный ягненок". Сервер может быть взломан, но, по крайней мере, в этом случае не нарушается защита всей сети.
Запуск сервера на той же машине, на которой стоит брандмауэр, не является хорошей практикой. В этом случае любая ошибка в конфигурации сервера нарушает безопасность всей организации.
Существует ряд вариаций приведенной базовой конфигурации, включая установку пары - внутреннего и внешнего - серверов, для предоставления внешнего доступа к публичной информации и внутреннего - к внутренней. См. книгу автора для получения подробной информации.
Можете, но тем самым вы открываете лазейку в вашем брандмауэре. Гораздо лучше вынести сервер за пределы брандмауэра, как было описано выше. Однако, в некоторых случаях архитектура брандмауэра не позволяет вынести сервер за его пределы. В этом случае у вас нет иного выбора. Существует две возможности:
ftp://ftp.tis.com/pub/firewalls/toolkit/
Сервер CERN также может быть настроен для работы как представитель. Однако, мне не хотелось бы рекомендовать его в этом качестве, так как сервер - большая и сложная программа, которая может содержать лазейки в системе защиты.
Дополнительную информацию о брандмауэрах можно получить из книг: Firewalls and Internet Security by William Cheswick and Steven Bellovin и Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky.
В системах семейства Unix программа tripwire периодически просматривает вашу систему и фиксирует изменения в системных файлах и программах. Программа доступна по следующему адресу:
ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/
Вы должны также периодически проверять файлы трассировки доступа и ошибок на предмет подозрительной активности. Ищите запросы, использующие такие системные команды, как rm, login, /bin/sh и perl, или очень длинные строки в обращениях к URL (первое свидетельствует о попытках заставить CGI скрипт выполнить системную команду, второе - о попытках вызвать переполнение буфера ввода программы). Следите также за повторяющимися неудачными попытками доступа к документу, защищенному паролем. Это свидетельствует о чьих-то попытках найти пароль для доступа.
| Наверх, к Содержание |
||
| Назад, к Вопросы общего
порядка |
Вперед, к Защита
конфиденциальных документов |
Перевод - Дмитрий Громов
Last modified: Thu Apr 16 10:39:59 EST 1998