Подтверждение полномочий пользователей

"Анонимный" бюджет IUSR-computername должен иметь право на локальную регистрацию, что достигается заданием параметра User Right to Logon. Другие права не требуются. Пользуясь Internet Service Manager (ISM), вы можете выбрать иное имя пользователя и пароль для этого бюджета. Бюджет не обязан входить в какую-либо группу.

Права бюджета IUSR-computername должны быть ограничены чтением и исполнением файлов и каталогов в пределах корневого каталога документов сервера Web (по умолчанию \InetPub\wwwroot\). Полные права следует предоставлять только группе (пользователю), ответственной за администрирование файлов сервера Web.

Для того чтобы настроить ACL для файлов Web, вы должны запустить Windows NT Explorer и войти через каталог \InetPub в каталог \wwwroot. Щелкните правой клавишей мыши на \wwwroot, выберите команду Properties и откройте закладку Security. Кнопка Permissions на закладке Security позволяет изменить права доступа. В большинстве систем NT в конфигурации по умолчанию пользовательской группе Everyone даются права Full Control. Эти установки можно заменить на Read, либо (например, в том случае, если планируется только анонимный доступ) отменить все права доступа для данной пользовательской группы.

Второй метод идентификации доступа - базовая регистрация открытым текстом. Эта стратегия не обеспечивает защиты. Она предполагает пересылку имени пользователя и пароля по сети в незашифрованном виде. Следовательно, такую информацию легко перехватить, особенно в сетях Intranet (да, впрочем, и в Internet тоже).

Windows NT предлагает и третий метод проверки прав доступа: процедуру "запрос-ответ". Ее преимущество состоит в более безопасной передаче имен пользователей и их паролей по сети. Кроме того, такой метод позволяет определять для файлов и каталогов на сервере Web, какие из них может видеть клиент Web. Система автоматически переходит к проверке прав доступа по методу "запрос-ответ", если анонимный пользовательский бюджет запрашивает ресурс, на который он не имеет прав.

Очевидный недостаток этого метода заключается в том, что каждый проходящий аутентификацию пользователь должен либо иметь бюджет на сервере Web, либо быть идентифицирован в домене. Однако далеко не всегда желательно, чтобы посторонние пользователи имели бюджеты в том или ином домене. Метод "запрос-ответ" хорошо подходит для серверов Web на базе Windows NT в сети Intranet, поскольку все пользователи, имеющие доступ к ресурсам Web, принадлежат к тому же домену, что и сервер Web.

МЕТОД ФОРТ-ХОСТА

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

Принцип форт-хоста предполагает также отказ от сетевых пользовательских бюджетов. Все бюджеты должны быть локальными: они предназначаются для администрирования Web. Решение об открытии сетевых бюджетов для администраторов Web на Web-сервере Intranet зависит исключительно от важности хранимой на нем информации.

Следующий важный вопрос: какие сервисы будет разрешено предоставлять серверу Web? Как правило, NT предоставляет много сервисов по умолчанию, большинство которых не нужно, когда NT используется в качестве сервера Web.

Все эти сервисы, в особенности сервисы файлов и печати, следует отключить на серверах Web, доступ к которым открыт из Internet. Совместное же использование файлов на серверах Web в корпоративной сети Intranet следует разрешить исходя из важности хранящихся в общих каталогах данных. Помимо этого, NT имеет много других сервисов по умолчанию. Блокировать следует Simple Services, а также такие сервисы TCP/IP, как Echo и Character Generator, которые используются при отладке настроек TCP/IP.

Хотя от многих дополнительных сервисов следует отказаться, серверу Web может потребоваться выполнять и многие иные функции помимо простого обслуживания файлов Web. Например, серверы Web могут принимать и обрабатывать информацию от клиентов Web - как правило, собираемую с помощью форм. Один из методов обработки форм предполагает использование CGI. Этот интерфейс открывает лазейку для проникновения на серверы Web - не из-за недостатков интерфейса, а из-за того, что сценарии обработки вводимых пользовательских данных могут иметь ошибки в программировании. Организация, известная как CERT (Computer Emergency Response Team), только в 1997 году выпустила четыре предупреждения относительно безопасности Web и CGI (см. врезку "Ресурсы Internet").

Наиболее распространенной ошибкой в сценариях CGI можно считать некорректную обработку пользовательских данных. Изобретательный злоумышленник может воспользоваться этим и направить на сервер Web непредусмотренный ввод, в результате которого команды будут исполняться по "указке" хакера. Помимо CGI серверы IIS и NT поддерживают также ISAPI (Internet Server Application Programming Interface). Как известно, ISAPI имеет большую устойчивость к атакам такого рода.

Другая проблема со сценариями CGI заключается в том, что они могут использовать такие интерпретаторы, как CMD.EXE или Perl. Эти интерпретаторы ни в коем случае нельзя размещать в каталогах со сценариями! В ранних версиях Netscape Communicator интерпретатор Perl был помещен в каталог сценариев, так что любой желающий мог выполнить команду Perl на сервере Web по своему выбору.

ФИЛЬТРАЦИЯ ПАКЕТОВ

На сервере NT в сети Intranet вы можете использовать фильтрацию пакетов. NT поддерживает простейшую фильтрацию пакетов, настроить которую можно посредством выбора закладки Protocols в апплете Network, в Control Panel. Для этого вам придется дважды щелкнуть мышью на TCP/IP, а затем выбрать кнопку Advanced в нижней части диалогового окна. Панель IP Address содержит флажок для блокирования/разблокирования защиты и кнопку Configure.

Щелчок мыши на Configure открывает меню, где вы можете указать, какие пакеты должен пропускать фильтр пакетов. Возможности фильтрации на редкость ограниченны: нельзя, например, открыть или закрыть для доступа некоторый диапазон портов или даже указать порт по имени. При выборе IP-протоколов нужно знать номер протокола, используемый в IP-заголовке и определенный в RFC1700. Однако не стоит пренебрегать и этой маломощной защитой. Обновленный IIS4 должен обеспечить лучшую фильтрацию.

Чем надежнее фильтрация пакетов, тем лучше защита. Например, сервер Web получает запросы через порт 80. Разрешив фильтру TCP пропускать только пакеты, адресованные этому порту, администратор тем самым запрещает использование всех других прикладных протоколов TCP/IP. Кроме того, он может, например, открыть порт 443 для протокола Secure Socket Layer (SSL). Теперь фильтр пакетов будет разрешать установку только соединений через порты 80 и 443. При этом исходящие соединения он никак не будет ограничивать.

(Стоит заметить, что локальные FTP-клиенты, функционирующие в активном режиме, будут работать некорректно, поскольку они должны устанавливать соединение с IIS-сервером для передачи данных через FTP-сервер. Клиент FTP в NT работает в

активном режиме и непременно вызовет это затруднение. Большинство FTP-клиентов, встроенных в браузеры Web, работают в пассивном режиме.)

Необходимо также иметь в виду, что подобная фильтрация защищает только от атак с использованием особенностей TCP/IP. NT же поддерживает и другие протоколы, такие как NetBIOS и Net-

Ware IPX. Маршрутизируемый протокол NetWare может представлять опасность с точки зрения удаленных атак. Сервер Web задействует только TCP/IP, поэтому другие протоколы следует отключить при помощи закладки Bindings в апплете Network. Это может затруднить аутентификацию доменов, совместное использование файлов и удаленное редактирование реестра пользователей. Однако в результате система станет более надежной.