Iis настройка доступа к файлам
В этом разделе приведены рекомендации по настройке безопасной удаленной публикации. Здесь рассказывается о том, как защитить сервер и содержимое, управляя различными аспектами безопасности как единым целым. В число этих аспектов безопасности входят:
Добавление модуля ipimanager_isapi.dll¶
У вас уже должен быть установлен пакет IIS для Windows!
Описание¶
Здесь и дальше употребляются следующие псевдо-термины:
: папка с профилем, который Вы должны были создать ранее (например, C:ipimy_profile).
: аккаунт, под которым будет запускаться Windows-служба IPI.Manager.
: аккаунт, под которым будет запускаться пул приложения IPI.Manager в IIS
Принцип связи с IIS следующий: с одной стороны запускается сервис с IPI.Manager, который слушает соединения на каком-либо порту (на любом =)). Информация о созданном сервисе (включая порт) сохраняется в /share/settings.yaml и используется как для запуска сервиса, так и для соединения к нему модуля ISAPI. Затем с другой стороны в IIS вставляется модуль ipimanager_isapi.dll и docroot сайта ставится в /share/htdocs . Наш ISAPI модуль смотрит на docroot и ищет /share/settings.yaml . Когда находит - видит, что сервис IPI.Manager запущен на порту NNNN и пытается соединится с ним.
Таким образом, краткий порядок действий для настройки таков (ниже эти шаги будут расписаны более подробно):
- Настроить права доступа к файлам
- Настроить и запустить сервис IPI.Manager
- (опционально) Создать новый сайт в IIS
- Установить docroot сайта в IIS на /share/htdocs
- Добавить в IIS модуль ipimanager_isapi.dll
Настройка и запуск сервиса IPI.Manager¶
Нужно перейти в папку профиля в консоли ( cmd.exe ) и выполнить:
Порт можно выбрать любой. Но как правило, это порты выше 10000-го и те, которые не заняты ничем другим. Консоль после этого можно закрыть - сервис будет работать самостоятельно.
Сервис будет создан со следующими параметрами:
пользователь: локальный системный аккаунт
запуск: автоматический (при старте Windows)
действия при исключениях: ничего не делать
С умолчательными параметрами всё будет работать тоже, но для тонкой и правильной настройки любой уважающий себя администратор захочет ещё кое-что изменить. Это все изменяемо стандартными средствами Windows. Для изменения нужно открыть свойства сервиса (My computer (Мой компьютер)-> Правый клик -> Manage (Управление) -> Services and Applications -> Services). Там в списке сервисов найти IPI.Manager Command runfcgi -> правый клик -> Properties (свойства).
Во-первых целесообразно изменить действия операционной системе при сбое сервиса. Во всех случаях - перезапуск:
Во-вторых хорошо бы запускать сервис не от имени системного пользователя, а от имени какого-либо другого. Мы советуем создать специального пользователя.
После любых изменений сервис нужно перезапускать. Это можно делать как средствами Windows (либо в диалоговом окне свойств, либо через sc.exe ), либо средствами комманды ipi-admin :
Правила управления доступом
Можно уменьшить вероятность того, что сервер будет подвержен угрозам безопасности, с помощью следующих правил. Эти правила позволяют создать надежную конфигурацию системы безопасности при реализации разумной политики контроля за доступом и правильной настройке средств защиты.
Примечание. Для приложений, требующих особую степень защиты, таких как финансовые или банковские, рекомендуется обращаться к услугам специалистов по безопасности. Ряд консультационных фирм оказывает услуги по настройке и реализации систем безопасности.
Для того чтобы правильно организовать защиту содержимого веб-сервера, придерживайтесь следующих правил:
Ограничения доступа для IP-адресов
Веб-сервер может быть сконфигурирован таким образом, чтобы запрещать доступ к содержимому веб-узла со стороны определенных компьютеров, групп компьютеров и целых сетей. Когда пользователь делает первую попытку получить доступ к содержимому веб-сервера, сервер сравнивает IP-адрес компьютера пользователя со списком ограничений IP-адресов. Дополнительные сведения см. в разделе Предоставление и запрет доступа для компьютеров.
IIS 6¶
- Windows XP 64bit
- Windows Server 2003 32/64bit
Откройте менеджер настроек IIS (Пуск -> Выполнить -> inetmgr).
Создайте новый веб-сайт:
Затем создайте новый пул приложений. Назовите его IPI.Manager App Pool.
Вы можете так же изменить учётную запись пула (по-умолчанию это будет NETWORK_SERVICE, то есть процесс IPI.Manager ISAPI будет запускаться от имени этого пользователя). При этом нужно обязательно добавить эту учётную запись в группу IIS_WPG, иначе ничего работать не будет. Если всё сделаете правильно, и процесс ipimanager_service.exe и w3wp.exe (это процесс IIS) будут запущены от имени одного пользователя:
Затем откройте свойства сайта. На вкладке Home Directory сначала удалите приложение, а затем создайте заново (кликнуть на Remove, затем на Create). В качестве пула приложений для только чт созданного приложения выберите созданный вами ранее пул IPI.Manager App Pool. Название приложения укажите как IPI.Manager ISAPI Handler. Нажмите Применить и потом зайдите в настройки приложения (кнопка Configuration там же, рядом).
В блоке Wildcard application maps нажмите Insert. В появившемся диалоговом окне выберите файл C:Program FilesIPIIPI.Manageripimanager_isapi.dll. Уберите галочку Verify that file exists и попрбуйте сохранить. Если диалоговое окно недовольно скажет, что имена файлов с пробелами нужно обрамлять кавычками - сделайте это (т.е. получится что-то вроде "C:\Program Files\IPI\IPI.Manager\ipimanager_isapi.dll" ). Сохраните всё.
В старых версиях IPI.Manager использовался хендлер fcgiext.dll. Если он есть в списке Wildcard application maps, нужно его оттуда удалить.
Затем в диалоговом окне управления IIS (Пуск -> Выполнить -> inetmgr) кликните правой кнопкой по Web Service Extensions и выберите Add new Web service extension. . В появившемся окне задайте любое имя расширению (например, IPI.Manager ISAPI Handler), в качестве требуемых файлов добавьте C:\Program Files\IPI\IPI.Manager\ipimanager_isapi.dll и статус расширения выберите как Allowed (Разрешённое).
Теперь не забудьте запустить сам веб-сайт
Возможные ошибки будут такими же как и для IIS7 / IIS7.5, о них смотрите в разделе ниже.
Управление доступом с помощью списка доступа к каталогу
При размещении каталога WebDAV на диске с файловой системой NTFS Windows 2000 Server по умолчанию предоставляет всем пользователям полный доступ к нему. Измените разрешения так, чтобы все пользователи получили только разрешение на чтение. Затем дайте разрешения на запись отдельным пользователям или группам.
Дополнительные сведения о разрешениях NTFS см. в разделе Разрешения NTFS.
Ограничения
Копирование в каталог WebDAV больших файлов может привести к переполнению жесткого диска. Чтобы ограничить этот объем, можно установить квоту на использование дискового пространства. Сведения о квотах на использование дискового пространства см. в документации по Windows 2000 Server.
The access control list (ACL) is a list of permissions associated with an object. Each of these permission entries is called an access control entry (ACE); an ACE contains permissions associated with a particular object for a particular identity. For example, for file system objects, you can set ACLs on files/directories on an NTFS file system.
You can use graphical user interface (GUI) tools (such as My Computer or Windows® Explorer) to set or edit ACLs. Simply right-click any file or folder resource from one of these tools, select Properties, and then click the Security tab to see a graphical representation of the ACL on the resource you chose. From this dialog box, you can apply or remove group or user permissions to system resources such as files and folders. You can also use a command-line utility Cacl.exe to display or modify file ACLs.
Настройка прав доступа к файлам¶
В дальнейшем у вас будет запускаться два процесса - один будет сервисом Windows, другой будет запускать IIS при создании пула приложения IPI.Manager. По умолчанию IIS запускает приложения от имени NETWORK_SERVICE, а сервис Windows запускает от имени System Logon Account. Если вы не особо заботитесь о безопасности - Вас это волновать не должно, но лучше создать отдельного пользователя, скажем, IPI.Manager User и прописать его в обоих местах.
В любом случае права на доступ к файлам должны быть следующими:
Пользователь, под которым запускается сервис:
чтение и запись в папку профиля ( , см. врезку выше)
только чтение в папку с системными файлами IPI.Manager ( C:\Program Files\IPI\IPI.Manager\ )
Пользователь, под которым IIS создаёт пул приложений
только чтение в папку профиля ( , см. врезку выше)
только чтение в папку с системными файлами IPI.Manager ( C:\Program Files\IPI\IPI.Manager\ )
Если же у вас всё запускаться планируется под 1 пользователем - значит он должен иметь права на чтение и запись в папку профиля и только чтение в папку C:\Program Files\IPI\IPI.Manager\
В случае, если отдельного пользователя не создавать, это означает что пользователю NETWORK_SERVICE нужно дать права на чтение и в папку C:\Program Files\IPI\IPI.Manager\ и в папку .
Common IIS Permissions
The most common permissions of interest in ACE are read, write, execute, and list folder contents.
Защита исходных текстов сценариев
Если в каталоге для публикации имеются файлы сценариев, к которым клиенты не должны иметь доступ, можно легко запретить доступ к ним, отменив разрешение Доступ к тексту сценария. Сценарии включают файлы с расширениями, которые присутствуют в списке сопоставления приложений. Все остальные исполняемые файлы, включая файлы с расширением .exe, будут рассматриваться как файлы статического HTML, пока для каталога не будет задано разрешение Сценарии и исполняемые файлы.
Чтобы запретить загрузку и просмотр .exe-файлов как HTML-файлов, но одновременно разрешить их запуск, в окне свойств Виртуальный каталог каталога публикации установите разрешение на запуск Сценарии и исполняемые файлы. Этот уровень разрешений позволит настроить поведение всех исполняемых файлов в соответствии с правом доступа Доступ к тексту сценария. Другими словами, если право доступа Доступ к тексту сценария выбрано, то клиенты, имеющие разрешение «Чтение», смогут видеть все исполняемые файлы, а клиенты с разрешением «Запись» — редактировать и изменять их.
Имея следующие разрешения, клиенты смогут выполнять запись в исполняемые файлы, которые не указаны в списке сопоставления приложений:
- Разрешение «Запись».
- Разрешение на запуск Только сценарии.
Имея следующие разрешения, клиенты смогут также выполнять запись в исполняемый файл:
- Право доступа Доступ к тексту сценария.
- Разрешение на запуск Сценарии и исполняемые файлы.
ACL Basics
It is useful to start with some ACL basics.
Разрешения веб-сервера
Уровни веб-разрешений включают:
- Чтение (выбирается по умолчанию) Пользователи могут просматривать содержимое файла и его свойства.
- Запись Пользователи могут изменять содержимое файла и его свойства.
- Доступ к тексту сценария Пользователи получают доступ к исходным файлам. Если выбрано разрешение «Чтение», исходный текст может быть прочитан. Если установлено разрешение «Запись», можно производить запись и в исходные тексты. «Доступ к тексту сценария» разрешает доступ к исходным текстам для файлов, например сценариям в приложении ASP. Эта возможность доступна только при установленных разрешениях «Чтение» или «Запись».
- Обзор каталогов Пользователи могут просматривать списки и семейства файлов.
- Запись в журнал Запись в журнал делается для каждого посещения узла веб.
- Индексация каталога Позволяет службе индексации создать индекс для ресурса.
Задание веб-разрешений
Ниже приведены несколько рекомендуемых способов настройки веб-разрешений в зависимости от предназначения публикуемого материала.
- Разрешены чтение, запись и обзор каталогов Такая конфигурация разрешений позволяет клиентам просматривать список ресурсов, изменять ресурсы (за исключением тех, которые не имеют разрешения на запись), публиковать свои собственные ресурсы и выполнять операции с файлами.
- Запись разрешена, чтение и обзор каталогов запрещены Если нужно позволить клиентам опубликовывать в каталоге конфиденциальные сведения, и в то же время запретить остальным пользователям просматривать опубликованные материалы, установите разрешение на запись, но не устанавливайте разрешения на чтение и просмотр каталогов. Эта конфигурация прекрасно подходит для случаев, когда клиенты участвуют в тайном голосовании или заполняют опросные анкеты.
- Чтение и запись разрешены, обзор каталогов запрещен Эту конфигурацию можно использовать, если в качестве средства безопасности служат трудные для подбора и угадывания имена файлов. Однако следует иметь в виду, что такая защита не очень надежна, так как взломщик может рано или поздно подобрать или угадать имя файла.
- Индексация каталога включена Если нужно разрешить клиентам выполнять поиск в каталогах, включите службу индексирования.
Дополнительные сведения о веб-разрешениях см. в разделе Задание разрешений для веб-сервера.
Как работает управление доступом
Для того чтобы управлять доступом пользователей к содержимому веб-сервера, следует задать правильную конфигурацию средств безопасности Windows и веб-сервера. Когда пользователь пытается получить доступ к веб-серверу, сервер выполняет ряд операций по проверке пользователя и определению разрешенного уровня доступа.
Ниже приведена структура процесса:
Разрешения NTFS
IIS зависит от разрешений NTFS при обеспечении безопасности отдельных файлов и каталогов от несанкционированного доступа. В отличие от разрешений веб-сервера, которые применяются ко всем пользователям, разрешения NTFS позволяют точно указать, какие пользователи могут получать доступ к содержимому и как эти пользователи могут обрабатывать содержимое.
Уровни разрешений NTFS включают:
- Полный доступ Пользователи могут изменять, добавлять, перемещать и удалять файлы, свойства, связанные с ними, и каталоги. Кроме этого, можно изменить разрешения для всех файлов и подкаталогов.
- Изменение Пользователи могут просматривать и изменять файлы и их свойства, включая удаление и добавление файлов в каталог или свойств файла к файлу.
- Чтение и выполнение Пользователи могут запускать выполняемые файлы, включая сценарии.
- Список содержимого папки Пользователи могут просматривать список содержимого папки.
- Чтение Пользователи могут просматривать файлы и их свойства.
- Запись Пользователи могут записывать файл.
- Нет доступа Когда ни один из флажков не установлен, пользователи не имеют никакого доступа к ресурсу, даже если пользователь имеет доступ к каталогу более высокого уровня.
Важно ! Установка разрешения «Нет доступа» к ресурсу для учетной записи IUSR_ИмяКомпьютера приведет к запрету доступа анонимных пользователей к этому ресурсу.
Определяется список разрешений для отдельных файлов и каталогов, который также называют таблицей управления доступом (DACL). При определении этого списка следует выбрать учетную запись пользователя или группы Windows и указать конкретные разрешения.
Приведенная ниже таблица иллюстрирует содержимое списка разрешений для воображаемого документа Microsoft Word MYSERVER:\Administration\Accounts.doc:
Кроме членов группы администраторов разрешение на изменение этого файла предоставлено только учетной записи с именем JeffSmith. Для обычных пользователей, которые входят как члены группы гостей Windows, доступ к этому файлу запрещен в явном виде.
После задания разрешений NTFS необходимо указать для веб-сервера способ проверки идентификации или подлинности пользователей перед предоставлением им доступа к файлам с ограниченным доступом. Имеется возможность задать в настройке веб-сервера необходимость проверки подлинности пользователей, при которой от пользователей для подключения требуется допустимое имя учетной записи Windows и пароль. Дополнительные сведения см. в разделе О проверке подлинности.
Примечание. Обеспечение безопасности сервера предполагает удаление ненужных пользователей и групп или групп, которые являются слишком распространенными. Однако удаление группы «Все» из списка управления доступом для веб-ресурсов без дальнейших изменений вызовет запрет даже неанонимного доступа. Чтобы неанонимный доступ работал правильно, в дополнение к определенным пользователям или группам должны быть установлены следующие разрешения:
- Administrator [полный контроль]
- Creator/Owner [полный контроль]
- System [полный контроль]
Строгая политика учетных записей
В служебной программе групповой политики Windows задайте политику прав пользователей для групп пользователей Windows. Политика прав пользователей определяет административные действия на веб-сервере, которые могут выполнять пользователи. Например, имеется возможность задать политику, которая гарантирует, что обычные пользователи не имеют права на удаленное отключение веб-сервера. Как правило, пытайтесь установить ограничительную политику прав пользователей. Избегайте случайного предоставления пользователям возможности изменения веб-сервера и его ресурсов. Дополнительные сведения см. в документации Windows или в пакете Microsoft Windows 2000 Server Resource Kit.
Дополнительные сведения о безопасности веб-сервера, см. том IIS Resource Guide пакета Microsoft Windows 2000 Server Resource Kit.
Для того чтобы управлять доступом пользователей к каталогам и файлам веб-сервера, можно установить разрешения файловой системы NTFS. Разрешения файловой системы NTFS позволяют определить уровень доступа к файлам и каталогам, предоставляемого конкретным пользователям и группам, имеющим действительные учетные записи Windows. Правильная конфигурация разрешений на файлы и каталоги является основным элементом системы предотвращения несанкционированного доступа. Дополнительные сведения см. в разделе Об управлении доступом или в документации Windows.
Если установлен общий доступ к каталогу или файлу, NTFS по умолчанию предоставляет разрешение Полный доступ группе Все, включающей всех пользователей. Это означает, что все пользователи имеют разрешения на изменение, перемещение и удаление файлов и каталогов и на изменение разрешений NTFS. Эти стандартные установки могут быть целесообразны не для всех каталогов и файлов.
Обеспечение безопасности сервера предполагает удаление ненужных пользователей и групп или групп, которые являются слишком распространенными. Однако удаление группы «Все» из списка управления доступом для веб-ресурсов без дальнейших изменений вызовет запрет даже неанонимного доступа. Чтобы неанонимный доступ работал правильно, в дополнение к определенным пользователям или группам должны быть установлены следующие разрешения:
- «Администратор» [полный доступ]
- «Создатель-Владелец» [полный доступ]
- «Система» [полный доступ]
Примечание. Если вкладка Безопасность не отображается в окне свойств накопителя, каталога или файла, то файловая система сервера не настроена как NTFS. Чтобы преобразовать файловую систему в NTFS, см. документацию Windows.
- Раскройте папку Мой компьютер, выберите диск, каталог или файл, который должен быть защищен и откройте окно его свойств.
- На вкладке Безопасность выберите учетную запись, для которой будут изменяться разрешения.
- В группе Разрешения выберите тип доступа для указанного пользователя или группы. Используйте флажки столбца Разрешить для присваивания нужного разрешения, а флажки столбца Запретить – для отмены данного разрешения. Чтобы получить другие возможности выбора, нажмите кнопку Дополнительно. Для получения информации о различных разрешениях см. документацию Windows.
Важно! Соблюдайте осторожность при использовании флажков Запретить. Флажок Запретить имеет приоритет перед столбцом Разрешить. Применение флажка Запретить к группе «Все» может закрыть ресурс для этого уровня доступа для любого, включая администратора.
Примечание. Если имеются противоречия между разрешениями NTFS и разрешениями веб-сервера, то действует наиболее ограничивающее разрешение. Это означает, что разрешение, в явном виде запрещающее доступ, всегда будет иметь преимущество над разрешениями, предоставляющими доступ.
Select an Identity
Figuring out the right accounts to grant permissions depends on the profile and critical resources of your application. The main considerations are which permissions to grant and whether or not you are authenticated.
- Granting the Proper Permissions. Dynamic content such as that in PHP and ASP.NET applications needs IIS script permission and read access. If you need to run executables, they need to have the IIS execute permission and they need to be properly configured in the CGI Restriction List. Anything that is not user-uploaded needs only read access on the file system.
Content that is going to be uploaded by a user should reside in a separate folder to which you assign write access. It is important not to give this folder IIS execute or script permissions so users can't upload and execute malicious code.
In general, the WPI should have read access to all content for your application to work correctly. - Applications That Require Authentication. For applications that require authentication, lock down all resources to a group containing all authenticated users. If you have different categories of users (admin and non-admin), create separate groups, and give access accordingly. For example, if your application has an admin directory that contains administration scripts, give permissions to read this directory only to the admin group. If your application is impersonating, then the handler identity is the authenticated user; otherwise, it is your WPI. If you have set fcgi.impersonate to "true" in your Php.ini file, then your fcgi processes identity is the authenticated user identity; otherwise, it is the WPI. With this information, an administrator can determine the right set of ACLs to place on the content.
- Applications That Run Anonymously. It is important to note that running anonymously on IIS means that you are authenticated as the anonymous user identity. In this case, lock down resources to either the application pool identity or your custom configured anonymous identity, and give access to the application pool identity over the anonymous identity. If you give IIS_IUSRS group access to your content, the applications running in any application pool have access to your content. If you allow anonymous users to upload files, your application should ensure further checks on the types of content these users can upload in order to keep the server secure.
Common IIS Identities
You can either allow or deny permissions to particular identities through ACLs to secure your content. There are two types of identities: process identities (those that the IIS worker process is launched with) and the request handler identities (those from authentication of the request).
- Worker Process Identity (WPI). The IIS worker process runs as the WPI, which is configurable through the Application Pool configuration settings in IIS. IIS 6.0 on Windows Server® 2003 and IIS 7 and above on Windows Server® 2008 have the "Network Service" identity as the default WPI. Windows Server® 2008 R2 however uses the application pool identity as the default WPI. If your application authenticates and impersonates, your request hander identity is the authenticated user identity.
If your Php.ini has fcgi.impersonate set to "true" (recommended for IIS), then your PHP processes are running as the authenticated user. It is important to note that in the case of anonymous authentication, the authenticated user would be the configured anonymous user. - IIS_IUSRS. This is a built-in identity group that is a container of all worker process identities (WPIs) on the server. IIS automatically includes all WPIs in this group (no need to add them manually).
On IIS 6.0 on Windows Server 2003, this group is called IIS_WPG. This is an overarching group that contains all WPIs, and is therefore not a good candidate for isolating content. Any application running in any application pool would be running as an identity that falls into this group, so giving this group read access means that all applications are able to read your content. - IUSR / Anonymous User Identity. The built-in IUSR account is the default used to denote the user identity of anyone using anonymous authentication. The anonymous user identity is configurable and can be set to an identity besides this built-in default.
In practice, you should configure a custom account for the anonymous user account and never use the built-in account. It is important to understand that in IIS, the anonymous user is not the lack of an authenticated user. Rather, anonymous requests should be considered as requests where the authenticated user is the anonymous user identity. - Application Pool Identity. This is a virtual identity associated with a particular application pool. Whenever a user creates an application pool, a virtual identity (security identifier or SID) is created with it; this identity is injected into the IIS worker process so that the worker process running under this application pool has access to content with permissions locked to this virtual identity. In Windows Server 2008 Service Pack 2 (SP2), the administrator can create their worker processes with this virtual identity. This is configurable in the IIS application pool configuration settings as the "Application Pool Identity" type and is the default WPI identity type for Windows Server 2008 R2. (Identity is unique to the application pool that created it and can therefore be used to isolate content on the server to application pools more effectively.)
- Authenticated User Identity. If your application uses any form of authentication (including anonymous authentication), then this is the identity of the authenticated user. In the anonymous authentication case, this identity would be your configured anonymous user identity.
IIS Execution Pipeline
To understand which identities are applicable at which stages, it is helpful to understand the basics of the IIS execution pipeline. The two parts of the pipeline that are most applicable are authentication and handler mapping.
Authentication. Before authentication, the authenticated user context is unknown and all IIS worker processes are running as the WPI. If you have a PHP request that is trying to access content before the request is authenticated, then the WPI needs access to the content. This scenario comes into play when using the Global rules for URL Rewriter that run in the global pre-begin request phase of the IIS pipeline, which occurs before authentication. The URL Rewriter has the ability to process rules differently based on whether the resource being accessed is a file or a directory. For this to be evaluated, a filesystem access needs to occur, and due to its position in the execution pipeline, this access request occurs as the WPI.
Post authentication, the authenticated user context is set, but you are not necessarily impersonating until your request gets mapped to a handler. For phases between authentication and handler mapping, you are most likely to be running as WPI.
Handler Mapping. In this phase of the execution pipeline, your request gets mapped to a handler; for example, requests to *.php get mapped to the FastCGI handler. After this mapping occurs and you have impersonation enabled, the handler identity is the Authenticated User, and all resource access in this phase occurs using the authenticated user identity.
Проверка подлинности клиентов
IIS обеспечивает следующие уровни проверки подлинности:
- Анонимная
- Обычная
- Встроенная Windows
- Краткая
То, какой способ настройки каталога WebDAV является лучшим, зависит от типа публикации. При создании виртуального каталога в IIS 5.0 будут включены анонимная и встроенная проверка подлинности. Хотя эта стандартная конфигурация хорошо подходит для клиентов, подключающихся к серверу, считывающих содержимое веб-страницы и запускающих сценарии, она не очень пригодна для клиентов, выполняющих публикацию данных в каталог и оперирующих содержащимися в нем файлами.
Анонимный доступ предоставляет доступ к каталогу всем пользователям, поэтому для каталога WebDAV его нужно отключить. Если контроль доступа к каталогу отсутствует, то его содержимое смогут испортить клиенты, оставшиеся неизвестными. Дополнительные сведения см. в разделе Анонимная проверка подлинности.
Обычная проверка подлинности пересылает по соединению пароли обычным текстом. Так как простой текст легко перехватить и прочитать, обычную проверку подлинности следует использовать только в случае, когда пароли защищаются с помощью Secure Sockets Layer (SSL). Дополнительные сведения см. в разделах Обычная проверка подлинности и Установка SSL на сервере.
Встроенная проверка подлинности лучше всего подходит при размещении каталога WebDAV в интрасети. Дополнительные сведения см. в разделе Встроенная проверка подлинности.
Краткая проверка подлинности является лучшим вариантом для опубликования информации на сервере по Интернету и через брандмауэры. Дополнительные сведения см. в разделе Краткая проверка подлинности.
Ограничение привилегий доступа для администраторов веб-сервера
Ограничивайте доступ для группы Administrators веб-сервера. Члены группы администраторов могут получить полный контроль над всем веб-сервером и его средствами безопасности. Придерживайтесь следующих правил при определении членства в группе администраторов:
- Предоставляйте привилегии администратора только доверенным лицам.
- Используйте учетную запись администратора только для администрирования сетевого домена. Для просмотра Интернета используйте другую учетную запись пользователя с привилегиями, аналогичными гостю. Это ограничит процессы на компьютере, представленном в Интернете.
- При создании новых групп не предоставляйте им разрешение «Полный доступ», позволяющее пользователям свободно распоряжаться содержимым.
- Регулярно изменяйте пароль учетной записи администратора.
- Никогда не выполняйте непроверенные программы, если вы вошли в систему как администратор.
- При администрировании веб-сервера через удаленный доступ используйте возможности безопасности SSL.
IIS7 / IIS7.5¶
- Windows Vista 32/64bit
- Windows Server 2008 32/64bit
- Windows 7 32/64bit
- Windows Server 2008 R2 32/64bit
Откройте менеджер настроек IIS (Пуск -> Выполнить -> inetmgr).
Создайте новый веб-сайт:
Откройте расширенные опции и разрешите запуск 32-битных приложений
Откройте Handler Mappings
Добавьте Wildcard script map
В старых версиях IPI.Manager использовался хендлер fcgiext.dll . Если он есть в списке Handler Mappings, нужно его оттуда удалить.
На вопрос - создавать ли исключение для ISAPI/CGI, ответье Yes (Да):
Правильное управление доступом к содержимому веб- и FTP-узлов является основным элементом организации защищенного веб-сервера. Используя возможности Windows и системы безопасности IIS, можно эффективно управлять доступом пользователей к содержимому веб- и FTP-узлов. Управление доступом может быть организовано на нескольких уровнях, от всего веб- или FTP-узла до отдельных файлов.
Анонимный доступ
Анонимный доступ, который является наиболее широко используемым методом доступа к веб-узлам, позволяет любому пользователю посетить общие области на веб-узле, но предотвращает несанкционированный доступ к важным средствам администрирования веб-сервера и частным сведениям.
Например, если сравнить веб-сервер с музеем, то разрешение анонимного доступа аналогично приглашению посещать общие галереи и экспозиции музея. Однако некоторые комнаты должны быть закрыты, например служебные помещения и лаборатории, которые не должны посещаться посторонними. Аналогично этому, при настройке анонимного доступа к веб-серверу следует задать разрешения NTFS, запрещающие обычным пользователям доступ к личным файлам и каталогам. Дополнительные сведения о разрешениях NTFS см. ниже в разделе Разрешения NTFS.
Для входа всех пользователей на веб-сервер по умолчанию используется анонимная учетная запись. При установке сервера создается специальная учетная запись анонимного пользователя с именем IUSR_имяКомпьютера. Например, для компьютера с именем SalesDept1 учетная запись анонимного пользователя получит имя IUSR_SalesDept1. Каждый веб-узел на сервере может использовать для входа анонимных пользователей либо одну и ту же, либо разные учетные записи. Диспетчер локальных пользователей и групп Windows позволяет создать новую учетную запись для анонимного доступа. Дополнительные сведения см. в разделе О проверке подлинности.
Управление доступом
В этой части рассказывается об управлении доступом к каталогу WebDAV путем согласования разрешений IIS 5.0 и Windows 2000, а также о том, как можно защитить файлы сценариев.
Политика строгих паролей
Пользователи, укравшие или разгадавшие пароли учетных записей пользователей, могут получить незаконный доступ к содержимому веб-сервера. Необходимо обеспечить, чтобы все пароли, в особенности защищающие привилегии администраторов, были трудными для разгадывания. Чтобы выбирать строгие пароли, придерживайтесь следующих правил:
- Не выбирайте в качестве паролей обычные слова. Компьютерный взломщик, пытающийся нарушить вашу систему защиты, может использовать для перебора паролей специальную программу подстановки по словарям.
- Требуйте, чтобы пароли имели длину не менее восьми символов и содержали как строчные, так и прописные буквы. Кроме того, пароли должны содержать цифры и, по возможности, нестандартные символы.
- Требуйте от пользователей регулярной смены паролей.
Протокол Distributed Authoring and Versioning (WebDAV)
Можно установить разрешения WebDAV для:
- Поиска каталогов и файлов и их свойств.
- Создания, изменения, удаления и просмотра каталогов и файлов и их свойств.
- Хранения и извлечения настраиваемых свойств файлов и каталогов.
- Блокировки файлов в общих рабочих средах.
Установка IIS7¶
Если IIS ещё не установлен, его нужно установить. Для этого достаточно добавить роль веб-сервера с нужными параметрами.
Далее обязательно нужно выбрать сервис ISAPI Extensions:
How to Set ACLs
There are several ways to set your ACLs through the shell, including command-line tools such as Icacls.exe. This article focuses on the Web Deployment Tool manifest (XML) mechanism that can be used to set ACLs. This is used when installing an application through the Web Deployment Tool or the Web Platform Installer.
To give Read, Execute, and Write permissions to MyApp file system directory for user Foo, add the following line to the Manifest.xml file:
To set the ACL on the path MyApp/Upload to allow anonymous users to upload content, add the following line to your Manifest.xml file:
Note that anonymousAuthenticationUser is a special token that will resolve to your configured anonymous authentication identity.
To grant Read access to the MyApp\Data folder for the application pool identity, add the following line to the Manifest.xml file:
Note that the setAclUse r is not used here (the default value for this is Application Pool Identity).
В версии 8.3.0 способ связки с IIS (всех версий старше 5.1) претерпел разительные изменения. Теперь вместо соединения IIS IPI.Manager на основе FastCGI используется наш собственный ISAPI модуль. Это позволило сделать настройку намного проще, саму работу IPI.Manager гибче и стабильнее.
Версии IIS выходили вместе с разными версиями Windows по следующей схеме:
Версия IIS | Версии Windows | Поддержка IPI.Manager |
---|---|---|
IIS 5.1 | Windows XP 32bit | не поддерживается |
IIS 6.0 | Windows XP 64bit Windows Server 2003 (32/64bit) | поддерживается |
IIS 7.0 | Windows Vista 32/64bit Windows Server 2008 (32/64bit) | поддерживается |
IIS 7.5 | Windows 7 32/64bit Windows Server 2008 R2 (32/64bit) | поддерживается |
Таким образом IPI.Manager может работать в паре с IIS всех версий, начиная с IIS 6.0.
Для работы IPI.Manager под Windows XP 32bit можно использовать либо встроенный веб-сервер, либо Apache 2.
Читайте также: