На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

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

«Анонимный» бюджет IUSR-computername должен иметь право на локальную регистрацию, что достигается заданием параметра User Right to Logon. Другие права не требуются. Пользуясь Internet Service Manager (ISM), вы можете выбрать иное имя пользователя и пароль для этого бюджета. Бюджет не обязан входить в какую-либо группу.
Права бюджета IUSR-computername должны быть ограничены
чтением и исполнением файлов и каталогов в пределах корневого ка­талога документов сервера Web (по умолчанию Полные права следует предоставлять только группе (пользователю),
ответственной за администрирование файлов сервера 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 можно считать некорректную обработку пользовательских данных. Изобре­тательный злоумышленник может воспользоваться этим и направить на сервер Web непредусмотренный ввод, в результате которого коман­ды будут исполняться по хакера. Помимо CGI серверы IIS и NT поддерживают также ISAPI (Internet Server Application Programming Interface). Как известно, ISAPI имеет большую устойчи­вость к атакам такого рода.
Другая проблема со сценариями CGI заключается в что они могут использовать такие интерпретаторы, как CMD. ЕХЕ или Perl. Эти интерпретаторы ни в коем случае нельзя размещать в каталогах со сценариями! В ранних версиях Netscape Communicator интерпретатор Perl был помещен в каталог сценариев, так что любой желающий мог выполнить команду Perl на сервере Web по своему выбору.
Фильтрация пакетов
На сервере NT в сети Intranet вы можете использовать фильтра­цию пакетов. NT поддерживает простейшую фильтрацию пакетов, на­строить которую можно посредством выбора закладки Protocols в
апплете Network, в Control Panel. Для этого вам придется дважды
щелкнуть мышью на TCP/IP, а затем выбрать кнопку Advanced в ниж­ней части диалогового окна. Панель IP Address содержит флажок для блокирования/разблокирования защиты и кнопку Configure.
Щелчок мыши на Configure открывает меню, вы можете ука­зать, какие пакеты должен пропускать фильтр пакетов. Возможности
фильтрации на редкость ограниченны: нельзя, например, открыть или закрыть для доступа некоторый диапазон портов или даже указать порт по имени. При выборе IP-протоколов нужно знать номер прото­кола, используемый в IP-заголовке и определенный в RFC 1700. Одна­ко не стоит пренебрегать и этой маломощной защитой. Обновленный
IIS4 должен обеспечить лучшую фильтрацию.
Чем надежнее фильтрация пакетов, тем лучше защита. Напри­мер, сервер Web получает запросы через порт 80. Разрешив фильтру TCP пропускать только пакеты, адресованные этому порту, админист­ратор тем самым запрещает использование всех других прикладных протоколов TCP/IP. Кроме того, он может, например, открыть порт 443 для протокола Secure Socket Layer (SSL). Теперь фильтр пакетов будет разрешать установку только соединений через порты 80 и 443. При этом исходящие соединения он никак не будет ограничивать.
(Стоит заметить, что локальные функционирую­щие в активном режиме, будут работать поскольку они должны устанавливать соединение с для передачи дан­ных через FTP-сервер. Клиент FTP в NT работает в активном режиме и непременно вызовет это затруднение. Большинство
встроенных в браузеры Web, работают в пассивном режиме.)
Необходимо также иметь в виду, что подобная фильтрация за­щищает только от атак с использованием особенностей TCP/IP. NT же поддерживает и другие протоколы, такие как NetBIOS и NetWare IPX.
Маршрутизируемый протокол NetWare может представлять опас­ность с точки зрения удаленных атак. Сервер Web задействует только TCP/IP, поэтому другие протоколы следует отключить при помощи закладки Bindings в Network. Это может затруднить аутенти-
фикацию доменов, совместное использование файлов и удаленное редактирование реестра пользователей. Однако в результате система
станет более надежной.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика