Почти за месяц до официального представления Windows 2000, 26 января 2000 г., Microsoft выпустила бюллетень Security Bulletin MS00-006 (Patch Available for «Malformed Hit-Highlighting Argument» Vulnerability), в котором сообщалось, что из-за ошибки в Microsoft IIS взломщик может увидеть на сервере исходный текст файлов, в том числе сценариев Active Server Pages (ASP). Опасность заключается в том, что код ASP часто содержит конфиденциальную информацию, в том числе интересующие взломщиков пароли и операторы SQL.

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

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

Контекст пользователя

В каждый момент времени на типичной системе Windows 2000 выполняется множество процессов. Открыв Task Manager и выбрав закладку Processes, можно увидеть список одновременно выполняемых процессов. Дополнительную информацию о каждом процессе можно получить, открыв меню View и выбрав пункт Columns. Установив флажок User Name и щелкнув на кнопке OK, можно увидеть список, аналогичный приведенному на Экране 1, где перечислены владельцы каждого процесса.

Экран 1. Активные процессы, рассортированные по именам запустивших их пользователей.

Процесс выполняется в контексте безопасности запустившего его пользователя. Дочерний процесс, запущенный этим процессом, остается в том же контексте пользователя, что и родитель. Если процесс обращается к тому NTFS, то доступ к файлу всегда будет осуществляться в контексте пользователя данного процесса.

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

Учетная запись System

Встроенная учетная запись System, иногда именуемая LocalSystem, используется операционной системой в основном для запуска служб Windows. Учетная запись System отсутствует в списке Local Users and Groups, и ее нельзя удалить из базы безопасности машины. Учетную запись, входящую в группу Administrators, нельзя присоединить ни к одной другой группе. Ей можно назначить разрешения NTFS, но не права пользователей.

Возможности учетной записи System очень велики. Ее нельзя лишить права изменять разрешения. Другими словами, если администратор попытается ограничить права учетной записи System, то она вернется к стандартным настройкам. Таким образом, обеспечивается корректное функционирование операционной системы. Если Windows 2000 установлена в режиме, заданном по умолчанию, то учетная запись System имеет полный доступ к каждому файлу на томе NTFS. Если взломщик овладеет службой Windows, работающей с учетной записью System, он сможет запускать другие процессы и обращаться к файлам в контексте System. Именно поэтому учетная запись System и стала излюбленной мишенью взломщиков.

Обычно разработчики Microsoft не рекомендуют снимать с файла разрешения для учетной записи System, но в некоторых случаях такой прием мешает взломщикам запускать процессы в контексте System. Один из примеров — переполнение буфера .Printer, упоминаемое в бюллетене Microsoft Security Bulletin MS01-023 (Unchecked Buffer in ISAPI Extension Could Enable Compromise of IIS 5.0 Server). Поэтому иногда полезно ограничить число файлов, к которым можно обращаться из учетной записи System.

Учетная запись Administrator

Administrator — еще одна привилегированная встроенная учетная запись, требующая надежной защиты. Поскольку администраторы неохотно накладывают на эту учетную запись ограничения на доступ к файлам, следует избегать запуска служб в контексте Administrator и ограничить доступ к браузеру и электронной почте для пользователей, зарегистрировавшихся под этой учетной записью. Учетная запись Administrator является членом встроенных групп Everyone, Administrators, Authenticated Users и Users. Если пользователь зарегистрировался с консоли, то учетная запись становится еще и членом встроенной группы Interactive.

Учетные записи IWAM и IUSR

IWAM и IUSR — специальные учетные записи, обрабатывающие запросы от анонимных пользователей Web. IUSR принимает анонимные запросы на ресурсы Web, поэтому права доступа определяются разрешениями NTFS. Например, если учетной записи IUSR запрещено обращаться к index.html, то анонимные пользователи Web не получат доступа к этому файлу. Любые компоненты COM или процессы, заключенные в программном коде ASP, также выполняются в данном пользовательском контексте. Учетная запись IWAM обслуживает экземпляры Web-приложений со средним или высоким уровнем защиты. С ней работают и внепроцессные приложения, такие, как приложения COM+.

IWAM и IUSR — учетные записи с низким уровнем привилегий. Подразумевается, что они принадлежат к группе Guest, но они входят и во встроенные группы Users и Authenticated Users. Инструмент IIS Lockdown формирует группу Web Anonymous Users, содержащую учетные записи IWAM и IUSR, поэтому, назначая права доступа к файлам, следует использовать данную группу, а не конкретные учетные записи пользователей. Применяя этот метод, значительно проще явно запретить доступ анонимных пользователей Web к определенным файлам. Поскольку специалисты настоятельно рекомендуют этот метод, в данной статье речь пойдет о группе Anonymous Users, а не об учетных записях IWAM и IUSR по отдельности.

Другие учетные записи

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

Защита каталога Webroot

Файлы каталога Webroot могут быть самыми уязвимыми на Web-сервере. Они общедоступны и часто содержат конфиденциальный код, с помощью которого взломщики могут собрать информацию и нанести вред Web-серверу. Например, серверный код может содержать информацию о связи с базой данных, в том числе пароли. В программном коде могут встречаться полезные взломщику ссылки на файлы и каталоги. Когда доступ к исходному тексту предоставляется кому-либо через слабо защищенные процедуры просмотра файлов, сервер подвергается большой опасности.

Назначать права чтения, записи и просмотра каталогов для Web-приложений можно с помощью Internet Services Manager (ISM), но эти права отличаются от разрешений NTFS. Разрешения Web-приложений определяют, как IIS обслуживает запросы, поступающие от пользователей Web; разрешения NTFS обеспечивают более высокий уровень управления и определяют ресурсы, доступные IIS. Если ISM обнаруживает ошибку, в результате которой IIS открывает доступ к исходному тексту, то разрешения NTFS получают приоритет и блокируют доступ к файлу. В данной статье рассматриваются разрешения NTFS, но следует внимательно выбирать и разрешения, назначаемые в ISM.

Чтобы обезопасить корневой каталог Web, следует сначала отменить наследование прав. Щелкнув правой кнопкой мыши на каталоге Webroot, следует выбрать пункт Properties, а затем перейти к закладке Security и сбросить флажок Allow inheritable permissions from parent to propagate to this object. Система спросит, как поступить с существующими разрешениями. В ответ следует щелкнуть на кнопке Remove. Таким образом, можно быть уверенным, что каталоги Web случайно не унаследуют лишних разрешений от родительских каталогов.

Затем следует ограничить разрешения группы Web Anonymous Users; этой группе нельзя предоставлять право записи в любой Web-каталог. Как правило, нежелательно, чтобы пользователи группы Web Anonymous Users могли выполнять запись в файловую систему. Если приложению нужно право Write, то следует предоставить его только для тех каталогов, где оно действительно требуется. То же относится и к разрешениям Execute; данную операцию следует запретить во всех каталогах Web-сервера, за исключением тех случаев, когда она строго необходима какому-нибудь приложению. Если на сервере существуют каталоги, содержащие DLL- или исполняемые файлы, то приложения будут выполняться корректно только при наличии у анонимных пользователей разрешений Execute. Для сценариев, таких, как файлы ASP, право NTFS Execute не требуется.

Большинство специалистов советуют помещать файлы для записи и исполняемые файлы в собственные каталоги, отдельно от файлов других типов. Например, можно поместить все исполняемые файлы в каталоги с именами CGI или BIN, а затем назначить каталогу разрешения Execute, но в этом случае анонимные пользователи смогут исполнять любые программы, помещенные в данный каталог. Поэтому вместо того, чтобы назначать для каталога разрешения Execute, можно предоставить Web-приложению право исполнять только определенные файлы. Таким образом, любые новые файлы, помещаемые в каталог, не будут автоматически наследовать разрешения Execute.

В ходе многих атак на Web-сервер загружается программа, которая открывает взломщику расширенный доступ к системе. Например, «червь» CodeRed загружает в каталог Scripts пораженного Web-узла файл root.exe. Назначая разрешения Execute исключительно на файловом уровне, можно предотвратить превращение любых новых файлов в исполняемые, просто записывая их в нужный каталог. Одного этого достаточно, чтобы значительно снизить вред, наносимый «червем» CodeRed и его разновидностями.

Следует также ограничить доступ учетной записи System к каталогам Web. IIS уязвим в случае нескольких типов атак с переполнением буфера, в ходе которых взломщики получают доступ на системном уровне. Похожие проблемы могут возникать и в будущем. Ограничение круга действий, которые учетная запись System может выполнить в корневом каталоге Web, значительно повысит устойчивость к таким нападениям. Владелец учетной записи System может изменить разрешения NTFS, назначенные любому файлу, но сделать это сложнее. Необходимо помнить, что при использовании службы Indexing Service учетная запись System должна иметь возможность читать корневой каталог Web, чтобы построить индекс.

Размещая файлы в Web-каталогах, необходимо понимать, каким образом изменяются разрешения при копировании и перемещении файлов. Копируемые файлы всегда наследуют разрешения целевого каталога. Но при перемещении файла в другой каталог на том же томе NTFS разрешения не изменяются. Файл, перемещенный на другой том NTFS, наследует разрешения целевой папки. Поэтому при публикации материалов в Web необходимо тщательно перепроверить разрешения для файлов.

Следует упомянуть и о возможности сделать Web-файлы доступными только для чтения, хотя этот прием не имеет прямого отношения к разрешениям. Любой пользователь может изменить атрибуты, но задача взломщика в таком случае усложняется. Например, если взломщики могут записывать файлы, но не исполнять программы, то они не смогут изменить атрибуты read-only, чтобы перезаписать или изменить существующие файлы.

Из-за уязвимости Webroot необходимо досконально проверять изменения в этих файлах и каталогах. Следует контролировать все неудачные попытки доступа и успешные операции, за исключением чтения. В результате может увеличиться объем журналов событий, но подробные записи об активности могут очень пригодиться. Недавно я собирал сведения для клиента, во внутреннюю базу данных которого проник взломщик, получив доступ к конфиденциальной информации о потребителях. Я обнаружил, что взломщик поместил в Web-каталоги моего клиента определенные файлы, а затем удалил их. Если бы клиент настроил аудит Web-каталогов, я смог бы точно определить, когда взломщик создал и удалил файлы, а также имена файлов и учетную запись, использованные взломщиком.

Каталог System Root

По умолчанию, любой пользователь имеет полный контроль над корневым каталогом системного раздела. Отчасти это объясняется тем, что в данном каталоге создается страничный файл Windows. Если зарегистрировавшийся пользователь не имеет права полного доступа к каталогу, то это приведет к ошибкам в операциях с виртуальной памятью. Поскольку члены группы Web Anonymous Users никогда не регистрируются с локальной консоли, то им не нужны столь широкие полномочия в этом каталоге. Данной группе следует предоставить право чтения корневого каталога.

Исполняемые системные файлы

Анализ последствий ограничения прав доступа к тысячам файлов в каталоге winnt — необъятная задача, поэтому я расскажу о запрете на доступ к конкретным, наиболее уязвимым, файлам. Многие исполняемые системные файлы, обычно используемые для текущих задач, могут стать средством нападения на Web-сервер. Такие программы, как cmd.exe, tftp.exe и telnet.exe, в руках злоумышленника очень опасны. Например, в некоторых случаях cmd.exe используется для запуска команд на сервере, а другие взломщики пользуются программой tftp.exe для загрузки файлов на Web-сервер. По умолчанию, на исполнение этих программ серьезных ограничений не накладывается.

Чтобы защитить эти файлы, следует снять все права доступа к ним и предоставить разрешения только определенным пользователям. Например, можно предоставить полный контроль над файлами только учетной записи Administrator и полностью запретить доступ всем остальным пользователям. Нужно специально указать пользователя Administrator, а не группу Administrators; учетная запись System — член группы Administrators, поэтому она унаследует разрешения группы.

Каталог Program Files

Многие приложения в каталоге Program Files предназначены только для локальных пользователей и администраторов и должны быть соответствующим образом защищены. Серверные приложения, такие, как серверы почты и баз данных, и административные программы, например программы резервного копирования, требуют особого внимания. По умолчанию, группа Users имеет разрешения Read и Execute во всех каталогах Program Files. Членам группы Web Anonymous Users следует запретить доступ ко всем каталогам приложений, за исключением Common Files, где содержатся системные компоненты, которые могут понадобиться Web-приложениям, и прикладным программам Web, использующим компоненты COM (в частности, почтовой программе SMTP).

Файлы журналов

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

Защитить файлы журналов непросто. Желательно, чтобы учетная запись System — пользовательский контекст IIS — могла создавать журналы Web, добавлять к ним данные и создавать каталоги для журналов при появлении новых Web-узлов. System — единственная учетная запись, которой необходимо предоставить право Write для этих каталогов, и только Administrator или пользователь, ответственный за управление файлами журналов, и программа анализа статистики должны иметь право читать Web-журналы.

Учетной записи System следует предоставить право создавать файлы и каталоги, но не изменять существующие файлы. Для этого нужно установить два параметра ACL для каталога Log-Files — один для подкаталогов (контейнеров) и один для файлов (объектов).

Сначала необходимо щелкнуть правой кнопкой мыши на каталоге, содержащем файлы журналов, выбрать пункт Properties, а затем закладку Security. Сбросив флажок Allow inheritable permissions from parent to propagate to this object («Разрешить данному объекту наследование разрешений от родителя»), следует щелкнуть на кнопке Remove, чтобы начать работу с чистого листа. Затем нужно последовательно щелкнуть на кнопках Advanced, Add и выбрать из списка учетную запись System. На экране появится диалоговое окно для указания разрешений. Из раскрывающегося списка Apply onto следует выбрать пункт Files Only, а затем установить флажки для следующих разрешений (см. Экран 2): Read Attributes, Create Folders /Append Data, Write Attributes и Read Permissions.

Экран 2. Назначение разрешений на доступ к файлам журналов.

Щелкнув на кнопках OK и Add, нужно вновь выбрать учетную запись System и нажать OK. Из раскрывающегося списка Apply onto в диалоговом окне разрешений нужно выбрать пункт This folder and subfolders и назначить следующие разрешения: List Folder, Read Attribute, Create Files/Write Data, Create Folders/Append Data, Write Attributes, and Read Permissions.

После повторных щелчков на кнопках OK и Add следует выбрать учетную запись Administrator (но не группу Administrators). В списке This folder, subfolders and files необходимо выбрать следующие разрешения: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, Delete Subfolders and Files, Delete и Read Permissions.

Если файлами журналов будет управлять несколько человек, то описанные выше действия следует повторить для каждого пользователя. Завершив работу, нужно установить флажок Reset permissions on all child objects and enable propagation of inheritable permissions («Сбросить разрешения на всех дочерних объектах и разрешить распространение наследуемых полномочий»).

Учетная запись System с такими правами может создавать файлы журналов и каталоги, но не изменять существующие данные. Читать и перемещать файлы журналов могут только администратор или уполномоченные пользователи. Однако им не следует предоставлять право изменять журналы.

Владельцы учетных записей System и Administrators могут изменять разрешения, поэтому следует тщательно проверять права доступа к каталогу. Чтобы отыскать следы взломщика, необходимо убедиться, что он не изменял файлов и разрешений. Щелкнув правой кнопкой мыши на каталоге, нужно выбрать пункт Properties и закладку Security. Затем следует щелкнуть на кнопке Advanced и выбрать закладку Auditing. Группу Everyone нужно дополнить политикой аудита. Следует проверять успешные попытки использования следующих разрешений: Create Files/Write Data, Delete Subfolders and Files, Delete, Change Permissions и Take Ownership.

Для более полного контроля использования этих файлов нужно выявить неудачные попытки применения разрешений Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, Delete и Change Permissions. Если подобные разрешения и параметры аудита неизменны, то можно с уверенностью сказать, что файлы журналов не изменялись и содержат полные данные для аудита.

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

Поделитесь материалом с коллегами и друзьями