Безопасность -> Интернет -> Вопросы и ответы по безопасности данных в WWW

	Наверх, к Содержание
Назад, к Вопрсы общего порядка		Вперед, к Защита конфиденциальных документов

4. Поддержка Безопасного Сервера

В9: Как следует устанавливать права доступа к файлам в корневых директориях сервера и дерева документов?

Вам необходимо защитить сервер от нежелательных взглядов как внутренних, так и внешних пользователей. Простейший способ достижения этой цели - создание пользователя "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/

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 за эту информацию.

В10: Я использую сервер, предоставляющий кучу дополнительных возможностей. Являются ли какие-либо из них дополнительными рисками?

Автоматическое получение списков файлов

Знание - сила, и чем больше внешний хакер знает о вашей системе, тем больше у него возможностей найти в ней лазейку. Возможность автоматического просмотра директориев, предоставляемая серверами CERN, NCSA, Netscape, Apache и другими, безусловно удобна, но может позволить хакеру получить доступ к важной информации. Такую информацию могут содержать: резервные копии файлов Emacs с исходными текстами скриптов CGI; файлы поддержки программных проектов; ссылки (ярлыки), однажды вами созданные для удобства, которые вы забыли удалить; директории с временными файлами и т.п.

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

Отслеживание ссылок (ярлыков)

Некоторые серверы позволяют расширять дерево документов посредством символических ссылок. Это удобно, но таит опасность в случае случайного создания кем-нибудь ссылки на важную системную область, например - директорий /etc. Более безопасный способ расширения дерева документов - явное включение соответствующей директивы в файл настроек сервера (включая директиву PathAlias в серверах семейства NCSA и инструкцию Pass в сервере CERN).

Серверы NCSA и Apache позволяют полностью отключить отслеживание ссылок. Дополнительно существует возможность позволять следовать ссылке только в том случае, если она принадлежит тому же пользователю, которому принадлежит то, на что она указывает. Вы можете таким образом нарушить безопасность только той части дерева документов, которой владеете, но не чужой.

Вставки на сервере

Выполняемые ("exec") вставки на сервере являются одним из основных типов лазеек. Их использование должно быть либо выключено полностью, либо позволено только очень надежным пользователям. В серверах NCSA и Apache можно выключить выполняемые вставки для директория, включив следующую инструкцию в соответствующий директорию раздел файла access.conf:

      Options IncludesNoExec

Директории, контролируемые пользователями

Разрешать любому пользователю в системе добавлять документы к вашему серверу очень демократично. Однако, вы должны быть уверены, что пользователи не откроют лазейку на вашем сервере. Пользователи могут опубликовать документ, содержащий важную информацию о системе, или создать скрипт CGI, вставку на сервере или ссылку, открывающую лазейку в системе безопасности. Если возможно, то лучше избегать подобных решений. Если пользователю надо создать собственную страницу, то лучше предоставить ему область в дереве документов для работы и удостовериться, что он понимает, что делает. Где бы ни хранились документы домашней страницы пользователя - в его домашнем каталоге или в части дерева документов сервера - лучше запретить включения на сервере и скрипты CGI в этой области файловой системы.

В11: Я слышал, что запуск сервера с правами пользователя root -плохая практика. Так ли это?

Когда говорят об "опасности запуска сервера с правами пользователя root", то подразумевают другую схему. Опасность состоит в настройке сервера для запуска _дочерних процессов_ с правами root (т.е. в директиве "User root" в конфигурационном файле сервера). Это действительно большой риск, так как любой скрипт CGI, запущенный с правами root, имеет доступ во все щели и углы вашей системы.

Некоторые считают, что лучше вообще не запускать сервер с правами root, поскольку мы не знаем, какие ошибки могут содержаться в той части программы, которая работает между запуском сервера и моментом запуска дочернего процесса. Это действительно так, хотя исходные тексты программ всех свободно распространяемых серверов открыты для публичного доступа, и в них, _похоже_, не содержится ошибок в этих частях программы. Запуск сервера с правами обычного непривилегированного пользователя может быть безопаснее. Многие серверы запускаются как nobody, daemon или www. Однако следует учитывать две потенциальные сложности, связанные с таким подходом:

1. Сервер не сможет открыть порт 80 (по крайней мере, в системах семейства Unix). Вам придется настроить сервер на использование другого порта, например - 8000 или 8080.
2. Придется сделать файлы конфигурации доступными для чтения тому же пользователю, с правами которого запущен сервер. Этим предоставляется возможность чтения файлов конфигурации при помощи CGI скрипта. Придется также разрешить тому же пользователю чтение и запись файлов трассировки, что делает возможным их редактирование при помощи взломанного сервера или скрипта. См. выше обсуждение прав доступа к файлам.

В12: Я хочу использовать одно и то же дерево документов для моих серверов ftp и Web. Существуют ли здесь какие-либо проблемы?

Рассмотрим сервер WWW, настроенный на запуск любого файла с расширением .cgi. Хакер, используя доступ через FTP, сохраняет на сервере файл с программой на языке perl и присваивает ему расширение .cgi. После этого он запрашивает этот файл через браузер, обращаясь к вашему Web серверу. Вот, собственно, и все - хакер выполнил на вашей машине любые команды, какие ему пришли в голову.

Вы можете объединять области доступа ftp и www, но при этом ограничте пространство, доступное для сохранения файлов через ftp, директорием "incoming", и не предоставляйте пользователю nobody прав на чтение из этого директория.

В13: Могу ли я полностью обезопасить мой сервер запуская его в среде "chroot"?

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

   chroot /путь/к/новому/корню /путь_к_серверу/httpd

Учтите также, что chroot защищает только файлы, не являясь при этом панацеей. Chroot не помешает хакерам проникнуть в вашу систему другими путями, например - получая системные карты через сервер NIS, или проводя эксперименты с NFS.

В14: Моя локальная сеть защищена брандмауэром. Могу ли я использовать это для повышения безопасности сервера Web?

          другой компьютер

                         \

          сервер <-----> БРАНДМАУЭР <------> ВНЕШНИЙ МИР

                         /

           еще компьютер

Однако, если вы хотите сделать сервер доступным для внешнего мира, то вам придется поместить его за пределами брандмауэра. С точки зрения безопасности вашей организации как целого, лучше всего вообще вынести сервер за пределы локальной сети:

          компьютер

                    \

   компьютер  <----> БРАНДМАУЭР <---> сервер <----> ВНЕШ.МИР

                    /

          компьютер

Такая конфигурация называется "жертвенный ягненок". Сервер может быть взломан, но, по крайней мере, в этом случае не нарушается защита всей сети.

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

Существует ряд вариаций приведенной базовой конфигурации, включая установку пары - внутреннего и внешнего - серверов, для предоставления внешнего доступа к публичной информации и внутреннего - к внутренней. См. книгу автора для получения подробной информации.

В15: Моя локальная сеть защищена брандмауэром. Могу ли я разрешить доступ к моему серверу через брандмауэр?

1. Если у вас имеется тип брандмауэра "экранированный хост" (screened host), вы можете избирательно разрешить прохождение запросов к порту 80, идущих на или с WWW сервера. Тем самым вы проделываете маленькое отверстие, через которое внешний мир может посылать запросы к серверу.
2. Если вы используете "dual homed gateway", вам нужно будет установить "представителя" (proxy) на машине с брандмауэром. Proxy - это небольшая программа, которая может видеть обе стороны брандмауэра. Она перехватывает внешние обращения и пересылает их серверу, а ответы передает клиенту. Небольшую и надежную HTTP proxy можно получить у TIS systems, по адресу:

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.

В16: Как я могу обнаружить, что мой сервер был взломан?

ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/

Вы должны также периодически проверять файлы трассировки доступа и ошибок на предмет подозрительной активности. Ищите запросы, использующие такие системные команды, как rm, login, /bin/sh и perl, или очень длинные строки в обращениях к URL (первое свидетельствует о попытках заставить CGI скрипт выполнить системную команду, второе - о попытках вызвать переполнение буфера ввода программы). Следите также за повторяющимися неудачными попытками доступа к документу, защищенному паролем. Это свидетельствует о чьих-то попытках найти пароль для доступа.

	Наверх, к Содержание
Назад, к Вопросы общего порядка		Вперед, к Защита конфиденциальных документов