Усиление защиты Web-сервера
По умолчанию IIS 7 устанавливается в несколько ограниченной форме. Если вы не обеспечите поддержку любой технологии сервера приложений, например ASP.NET или класической платформы ASP, то IIS 7 сможет обслуживать лишь статические файлы в стандартной конфигурации. Нужно определить типы разрешенного активного содержимого, контексты защиты, в которых вы будите запускать свои приложения, и ресурсы, к которым они должны иметь доступ.
Пулы приложения
Пул приложения представляетрабочий процесс в IIS 7. Для каждого пула приложения вы получаете экземпляр рабочего процесса w3wp.exe, который позже будет управлять CLR, ASP.NET и вашими приложениями. Можно конфигурировать несколько аспеутов рабочего процесса, например настройки рециркуляции и мониторинг состояния.
ВНИМАНИЕ! Настройки рециркуляции по умолчанию каждые 29 часов закрывают рабо-
чий процесс для получения последеней копии данных. При ререциркуляции рабочего процесса
вы теряете все хранящиеся в процессе данные, в частночти внутрипроцессные сеансы
или кеш. В производственной среде эту настройку обычно изменяют на управляемую
рециркуляцию с использованием схемы.
Наиболее вожное значение для защиты имеет вкладка Удосторверение. В ней вы можете определить, под какой учетной записью должен запускаться пул приложения. По умолчанию используется учетная запись Network Service (Сетевая служба), однако можно применить и собственную учетную запись (рис. 1).
Рис. 1. Конфигурирование контекста защиты в пуле приложения
Необходимо учитывать следующие аспекты.
- При закрытии рабочего процесса (неважно, по какойто причине) закрываются все запущенные в нем приложения. Для надежности распределяйте важные приложения по разным рабочим процессам.
- Все приложения, запущенные в одном рабочем процессе, совместно используют контекст защиты. Идентификатор рабочего процесса обычно применяются для получения доступа к ресурсам, например файлам или базам данных. С точки зрения ОС нельзя различить два приложения, запущенные в одном рабочем процессе. Групируйте приложения, в котором требуется одни и те же настройки защиты (скажем, списки ACL файловой системы NTFS или доступ к базе данным). Если же вам необходима раздельная защита, распределяйте приложения по различным процессам (и контекстам защиты). Такой подход позволяет задавать отдельные списки ACL.
- Запросы ASP.NET обслуживаются из пула потока. этот пул обслуживает один процесс и содержит 25 потоков на каждый CPU. Запуск множества приложений в одном процессе влияет на расширяемость, поскольку приложения должны совместно использовать потоки.
- Если вы зхотите применять в прилложении делегирование, запускайте рабочий процесс под учетной записью домена и зарегистрируйте имя принципа службы (SPN) для этой учетной записи.
- Все учетные записи, используемыее для рабочих процессов, нужно добавить в локальную группу IIS_IUSRS. Таким образом будут потверждены некоторые привилегии, требуемые для запуска рабочих процессов IIS.
- Можно загружать в процесс только одну версию CLR. Если на вашем сервере есть приложения ASP.NET 2.0 и 1.1, их нужно разделить по разным рабочим процессам.
После настройки пулов приложения вы можете конфигурировать каждые приложение для запуска в назначенном пуле в диалоговом окне Дополнительные параметры (рис. 2).
Рис. 2. Настройка пула для каждого приложения
Расширение Web-служб
Расширение Web-служб определяют, какие активное содержимое вы разрешаете использовать на своем сервере. По существу это глобальный список расширений ISAPI и шлюзов CGI, разрешенных для вызова. Применять можно только те серверные технологии, которые действительно нужны, то есть следовать минимального ПО. Обычно используется ASP.NET 2.0 (и 1.1 если нужно поддерживать множество версий структуры).
Злоумышленники, управляя копированием исполняемого файла (например, CGI в Web-приложении), не смогут выполнять его через браузер, пока этот двоичный код не зарегистрирован в списке разрешений Web-служб (рис. 3).
Рис. 3. Конфигурирование разрешенноо активного содержимого
Содержимое Web
Удалите все лишнее содержимое на Web-сервере, в частности образцы приложений, документацию продукта или неиспользуемые приложения. Чем больше исполняемого кода на вашем сервере, тем вероятнее, что он будет взломан. Образцы приложений имеют больше всего слабых мест.
Кроме того, переместите папку Web-прирожения из раздела, в котором находятся ОС. Это обеспечит защиту против всех типов атак отслеживания
Заголовки HTTP
Удалите все ненужные заголовки HTTP, которые можно конфигурировать в IIS, например X-Powered из ASP.NET. Вы можете найти эту настройку в IIS MMC на вкладке Заголовки HTTP диалогового окна Начальная страница Default Web Site.
Вход в систему
Регистрацию IIS можно конфигурировать для каждого сайта (в диалоговом окне Начальная страница Default Web Site). По умолчанию записи в поле Reference (ссылка) не вносятся. Чтобы знать, кто ссылается на ваш сайт, заполните это поле вручную. Рассмотрите возможность помещения записей в отдельный раздел и их регулярного резервного копирования.
Для анализа файлов регистрации вы можете использовать инструмент LogParser (http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx). Кроме того, что вы сможете запрашивать такую стандартную информацию, как количество обращений, этот инструмент позволит вам осуществлять поиск специфических шаблонов атак (http://www.securityfocus.com/infocus/1712). Инструмент LogParser использует язык запросов SQL. Далее представлен пример запроса, который возвращает пользовательские имена, вызвавшие сбой аутентификации IIS (путем просмотра кодов состояния ошибок 401 и 403)
SQL
SELECT cs-username, sc-status, COUNT(*) AS Total
FROM ex*.log WHERE cs-username IS NOT NULL AND sc-status > 400 AND sc-status < 404
GROUP BY cs-username, sc-status
ORDER BY Total DESC
Фильтр URLScan
URLScan представляет собой фильтр ISAPI, который позволяет проверять входящие запросы. Используя технологию белых или черных списков, можно определить несколько правил проверки. Например, вы можете разрешать или запрещать расширения, команды, последовательности URL и заголовки. Кроме того, можно задать максимальные значения длины строк запросов и заголовков, а также удалить заголовок сервера из списка реагирования HTTP.
Во многих документах указано, что большинство функций URLScan необходимо переместить в файл HTTP.SYS, однако это не совсем так. Инструмент URLScan представляет больше возможностей и является эффективным средством глубинной защиты. Интересно, что во время написания этой статьи два изъяна ASP.NET (MS06-33 и MS05-004) можно было устранить именно посредством установления данного инструмента. Посмотрите основную документацию по URLScan (http://www.microsoft.com/technet/security/tools/urlscan.mspx) и статью из базы знаний Microsoft, где описано, как ограничивать функциональность приложения ASP.NET с помощью URLScan (http://support.microsoft.com/kb/815155)
Контрольные списки доступа
В перспективе ASP.NET-списки ACL следует настраивать (или защищать) в трех различных каталогах. Посредством ключа -ga команды Aspnet regiis можно автоматизировать большую их часть, однако я рекомендую выполнить это вручную. чтобы придерживаться принципа минимальных привилегий.
ВНИМАНИЕ! Помимо указания всех необходимых списков ACL для работы приложения
всегда следует продумывать уровень разделения между запущенными на сервере при-
ложениями. Если вы не разделите соответствующим образом приложения, вам придется
полностью доверять каждому из них (а также всем разработчикам этих приложений).
Частичное доверие - самый эффективный способ реального разделения,
однако списки ACL всегда должны применяться независимо.
Файлы Web-приложения
Длалее речь пойдет о папке, в которой расположены файлы вашего приложения (например, страницы или графика). Точно определите, какие учетные записи должны иметь специфические типы доступа к этой папке. В перспективе ASP.NET-доступ Read, Read and Execute и List Folder Contents к этим файлам требуется только контексту защиты, в котором запущено приложение (рис. 4).
Применяя в приложении аутентификацию Windows, помните, что модуль FileAuthorizationModule дополнительно проверяет ресурс, запрашиваемый для доступа Read. Для этого он использует индентификатор из RequestLogonUserIdentity. Это может быть либо атентифицированный пользователь, либо анонимная учетная запись Интернета. Чтобы использовать эту конфигурацию, акажите для таких учетных записей доступ Read. Кроме того, помните, что статичные файлы обслуживаются IIS с применением тех же правил безопастности - аутентифицированного пользользователя или анонимной учетной записи.
Если вы меняете идентификатор приложения с помощью элемента <identity> файла web.config, присвойте этому идентификатору соответствующий тип доступа.
Рис. 4 Списки ACL для приложений
Временная папка сборок
Особого внимания заслуживает папка, в которую копируется сборки для компилированных страниц, элементов управления и компонентов. По умолчанию она размещена по адресу Windows\Microsoft.NET\Framework\version\Temporary ASP.NET\Assemblies.
Идентификатор рабочего процесса и учетная запись олицетворения приложения требует доступа Modify к этому каталогу и его папкам. Помните, что по существу данный каталог содержит весь код вашего приложения (правда, в двоичном виде), поэтому возможность считывания и записи в папку должно иметь только соответствующее приложение. По умолчанию эта папка защищена списком ACL, подтверждающим доступ Modify для группы IIS_WPG, которая содержит все учетные записи рабочего процесса. Чтобы достичь более четкого разделения, следует изменить место временных сборок для сайта или приложения с помощью атрибута tempDirectory элемента <compilation> в файле web.config. Это позволит защищать папки по отдельности с помощью списков ACL, в которых использован идентификатор соответствующего приложения.
ВНИМАНИЕ! Описанный подход особенно важен тогда, когда множество сторон
совместно используют сервер. Вряд ли вы захотите, чтобы другие приложения
на сервере имели доступ к сборкам компилированных страниц.
Папка Temp
В некоторых ситуациях CLR компилирует временный код "на лету". В качестве распространненых примеров можно привести XML Serializer и скомпилированные регулярныевыражения. Эти временные сборки вкладываются в папку системы Windows, которая называется temp и хранится по адресу Windows\Temp. Идентификаторам рабочего процесса или цчетной записи олицетворения также требуется доступ Modify. Если вы используете собственные учетные записи, то лучше всего предоставить доступ к папке для группы IIS_WPG. Папка Temp является машинной и не может быть задана на основе приложения.
Включение SSL
Если в приложении вы имеете дело с уязвимыми данным, всегда включайте и используйте SSL. Это дает вам два преимущества. Во-первых, SSL позволяет выполнять аутентификацию сервера и гарантирует пользователям, что они подключились к правильному серверу, прежде чем они введут такие уязвимые данные, как пароли. Во-вторых, после аутентификации сервера все передаваемые данные шифруются с обеспечением защиты целовтности. Чтобы включить SSL, нужен сертификат сервера. Кго можно получить несколькими способами:
- приобрести в центре сертификации (Certificate Authority, CA), например VeriSign;
- запросить из внутреннего CA;
- создать собственный сертификат для тестирования
Методы аутентификации
Всегда точно определяйте настройки аутентификации. В папке диагностики IIS есть средство диагностики процесса проверки подлинности AuthDiag, которое позволяет определить методы аутентификации, списки ACL и привилегии процессов. В частности, оно указывает различные способы получения доступа к вашему сайту, и вы можете использовать его для определения всех нежелательных метоов аутентификации, разрешенных вашим приложением (http://www.microsoft.com/downloads/details.aspx?FamilyID=e90fe777-4a21-4066-bd22-b931f7572e9a&DisplayLang=en)
От себя: если вознинут вопросы как получить SSL Сертификак под IIS 7 то обращайтесь объясню, по возможности. Также рекомендую использовать данные утилиты:
