Сегодня обеспечить защиту серверов Windows гораздо проще, чем несколько лет назад. Компания Microsoft добилась заметных успехов в защите серверов Windows, уровень безопасности которых достаточно высок, если своевременно устанавливать заплаты и использовать брандмауэр. Но многие другие компании не приложили усилий к тому, чтобы обеспечить защиту приложений в стандартной конфигурации, и даже не документируют способы повышения безопасности своих программ. Часто встречаются серверные программы Web, FTP, электронной почты и обмена сообщениями, нарушающие безопасность в остальном надежной среды из-за неудачной стандартной конфигурации.
Самая распространенная ошибка заключается в том, что многие службы функционируют в контексте встроенной учетной записи System, хотя им редко бывает нужен столь высокий уровень доступа. После удачной атаки на приложение взломщику предоставляется полный системный доступ, чтобы довершить разгром. Другие типичные ошибки - установка приложений с непродуманными разрешениями NTFS и недостаточное внимание к защите конфиденциальных данных. Например, данные о конфигурации и даже пароли учетных записей многих приложений от независимых поставщиков хранятся в реестре или локальном файле конфигурации. При этом в разрешения не внесены соответствующие поправки, чтобы помешать обычным пользователям прочитать файлы. Если в программе не используется надежное шифрование или другие методы защиты конфиденциальных данных, то в конечном итоге эти сведения могут попасть в руки злоумышленников.
Можно обратиться к поставщику с вопросом о специальных мерах обеспечения дополнительной безопасности продукта. К сожалению, многие компании не дают таких рекомендаций. Часто обязанность защиты сторонних служебных приложений ложится на администраторов. Сделать это проще, чем может показаться на первый взгляд, если действовать в соответствии с планом, представленным в данной статье.
Следует помнить, что предлагаемые меры применимы не ко всем приложениям, так как продукты иногда используются способом, не полностью протестированным разработчиком. Кроме того, процесс подготовки приложения к работе может оказаться слишком трудоемким. Тем не менее, многие приложения успешно функционируют лишь с небольшими изменениями, а потраченные усилия окупаются благодаря повышенной безопасности. Среди преимуществ - существенное уменьшение поверхности атаки, которое значительно сокращает список возможных действий взломщика, овладевшего программой.
Установка программ
Первый шаг - установить программу в качестве администратора с использованием стандартной конфигурации. Важно, чтобы программу установил администратор, так как при первом запуске многие приложения создают файлы конфигурации или элементы реестра; эту задачу проще выполнить тому, кто обладает повышенными полномочиями учетной записи System или Administrator.
При установке необходимо тщательно продумать, куда записать файлы приложения в каталоге Program Files на компьютере. Большинство приложений связаны с разнообразными типами файлов, таких как выполняемые файлы, вспомогательные библиотеки, справочные материалы, файлы конфигурации, журналов и данных пользователя. В некоторых приложениях все эти файлы собраны в одном каталоге, а в других можно выбрать папки для файлов каждого типа. Если в приложении предусмотрена возможность выбора места хранения, то следует обдумать влияние местоположения файлов и поместить файлы каждого типа в отдельный каталог. Например, файлы журналов часто содержат конфиденциальную информацию и могут представлять интерес для взломщика, поэтому их удобно собрать в одном месте и архивировать с помощью сценариев на другом компьютере.
Иногда лучший выход - поместить файлы, доступные пользователям (но не самому приложению), в изолированный раздел диска. Обычно я изолирую общедоступные серверы (например, Web- и FTP-серверы), которые открывают часть файловой системы. Такая изоляция не позволяет хакерам использовать будущие уязвимые места для доступа к файлам вне границ приложения, в частности, системным и конфиденциальным файлам.
Недавно мне пришлось решать задачу защиты стороннего почтового сервера для одного из заказчиков. Я установил программу в каталоге Program Files сервера, но поскольку она обеспечивала доступ из Web к почтовым файлам, файлы почтовых ящиков были размещены отдельно. При этом упростилось и управление файлами. При настройке программы выяснилось, что можно указать место хранения файлов журналов, поэтому они были помещены в центральное хранилище вместе с другими системными файлами журналов клиента. В результате заказчику стало проще архивировать собранные в одном месте журналы.
При установке прикладной программы также необходимо принять во внимание компоненты, которые предстоит установить. Если необходимости в определенной функции нет, но она может возникнуть в будущем, не стоит устанавливать ее заранее. Это всегда можно будет сделать, когда потребуется. На производственном сервере не следует устанавливать образцовые файлы и документацию.
Послеустановочные задачи
Сразу после установки приложения нужно исследовать файлы в его каталоге Program Files. Часто при этом обнаруживаются лишние файлы, которые не нужны для функционирования программы: readme, .doc, расширения, журналы установки и временные файлы. Загроможденные каталоги - угроза безопасности, поэтому следует удалить и переместить как можно больше файлов.
Последний этап - назначение паролей приложения. Пользователи и администраторы многих серверных приложений должны пройти процедуру входа. Приложения часто формируют учетные записи со стандартными или пустыми паролями, которые могут создать опасность для сервера. Необходимо назначить надежный пароль. Если в программе можно изменить имя пользователя, то следует избегать типовых и легко угадываемых имен, таких как administrator, postmaster, root и admin. И, наконец, не забудьте удалить все стандартные пользовательские и демонстрационные учетные записи в приложении.
Минимальные полномочия
Самый надежный способ обезопасить приложение - дать ему только необходимые полномочия для выполнения соответствующей роли. Следует ограничить доступ к файловой системе и реестру и запретить доступ к определенным системным правам и полномочиям, таким как возможность входа через сеть. Администраторы имеют полный доступ к любому компьютеру Windows, поэтому важно настроить служебные приложения для работы с неадминистративными учетными записями.
К сожалению, многие разработчики не принимают во внимание возможность запуска их программ пользователями, не имеющими административных полномочий. Многие служебные приложения устанавливаются с использованием стандартной учетной записи System, и разработчики не всегда тщательно тестируют приложение при работе с пониженными полномочиями. Если служба настроена на выполнение в контексте учетной записи обычного пользователя, то ее не всегда удается запустить с первой попытки. Но после небольшого исследования и мониторинга часто выясняется, что большинство приложений успешно функционирует без полного административного доступа.
Программе необходимы определенные ресурсы. Для выполнения задачи ей могут потребоваться программные файлы, общие ресурсы Windows, разделы реестра и системные полномочия. Если доступ к любому из этих элементов блокирован, то приложение может сообщить об ошибке или просто прекратить выполнение. Ключ к подготовке программы для работы с минимальными полномочиями - определить элементы, к которым требуется доступ, а затем создать для службы учетную запись пользователя (служебную учетную запись) именно с такими (но не более широкими) правами и полномочиями.
Чтобы сформировать служебную учетную запись, следует создать на сервере или в домене учетную запись пользователя и назначить ей надежный пароль. Вводить пароль придется редко, поэтому рекомендуется выбрать фразу длиной не менее 30 символов. Установите флажки User cannot change password и Password never expires. Использование пароля с неограниченным сроком действия противоречит большинству политик безопасности, но нельзя рисковать службой из-за просроченного пароля. В данном случае придется вручную регулярно менять пароли.
И, наконец, на вкладке Terminal Services Profile нужно установить флажок Deny this user permissions to log on to any Terminal Server. Если на сервере работает несколько служб и требуется создать учетную запись для каждой из них, можно создать служебную группу и впоследствии с ее помощью упростить процесс назначения прав и полномочий, таких как запрет доступа к определенным частям файловой системы для всех служебных учетных записей.
Доступ к файлам
Главный ресурс, в котором нуждается каждое приложение - доступ к файловой системе, чтобы можно было считывать и выполнять файлы в собственном каталоге программы. Иногда приложению необходимо создать или изменить собственные файлы. Многие программы помещают файлы конфигурации в общие каталоги, такие как каталог Windows. Некоторые приложения скрывают определенные файлы, относящиеся к лицензированию, в дальних папках файловой системы, чтобы пользователи не могли обойти лицензионные ограничения. Необходимо обнаружить все эти файлы, чтобы обеспечить доступ к ним служебной учетной записи.
Чтобы идентифицировать файлы, необходимые служебной учетной записи, нужно настроить Windows на аудит доступа к файлам. Это связано с существенными изменениями в политике аудита, отменить которые трудно, поэтому данную задачу лучше выполнять на тестовом компьютере или виртуальной машине (VM).
Для аудита доступа к файлам следует открыть проводник Windows и выбрать свойства безопасности для первого жесткого диска. Щелкните на кнопке Advanced и выберите вкладку Auditing. Щелкните на кнопке Add и введите Everyone в качестве пользователя. Затем нужно щелкнуть на кнопке OK и установить флажки Full Control в столбцах Successful и Failed. При этом будут установлены все флажки, как показано на Экране 1. Щелчком на кнопке OK сохраните данные, а затем установите флажок Replace auditing entries on all objects with entries shown here that apply to child objects. Щелкните на кнопке OK, чтобы применить параметры безопасности ко всему диску. При необходимости следует повторить процесс в любых других разделах диска.
После того, как будут установлены параметры аудита, необходимо настроить политику безопасности для записи результатов аудита. Из Administrative Tools следует открыть оснастку Local Security Policy консоли Microsoft Management Console (MMC). Разверните узел Local Policies и выберите папку Audit Policy. Audit object access и Audit privilege use policies нужно настроить на аудит как успешных, так и неудачных событий. Записи, сделанные в результате применения этих параметров, быстро переполняют журналы событий, поэтому после окончания тестирования полезно восстановить исходные значения.
Доступ к реестру
Большинство программ используют реестр не только для хранения данных о конфигурации, но и для поиска общесистемных настроек. Чтобы выполнить аудит этого процесса, следует открыть regedit.exe и щелкнуть правой кнопкой мыши на кусте реестра HKEY_LOCAL_MACHINE. Выберите пункт Permissions и назначьте аудит для Everyone, точно так же, как для файловой системы.
Назначив параметры аудита, следует очистить все журналы событий и выполнить как можно больше задач. Завершив работу, остановите службу или приложение.
Подготовка списков доступа
Windows создает запись в журнале событий при каждом обращении программы к проверяемому файлу или разделу реестра. В данном случае это вся файловая система и весь куст реестра HKEY_LOCAL_MACHINE. Использование реестра Windows таким способом может привести к появлению тысяч записей в журнале событий, поэтому предпочтительно использовать бесплатный инструмент Log Parser компании Microsoft (см. http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&DisplayLang=en), чтобы собрать необходимые сведения.
С помощью следующей команды можно генерировать список файлов и разделов реестра, используемых приложением:
logparser "SELECT DISTINCT
EXTRACT_TOKEN(strings,1,'|')
AS Type, EXTRACT_TOKEN
(strings,2,'|') AS Name USING
EXTRACT_TOKEN(strings,7,'|')
AS Executable FROM Security
WHERE EventID=560 AND
Executable LIKE '%Application>%' ORDER BY
Type, Name" -i:evt
где YourApplication - имя приложения или пути.
В результате этого запроса Log Parser выдает список всех обращений к файлам и реестру. Этот список можно использовать для корректировки полномочий каждого файла и раздела реестра. Например, для разделяемых объектов, таких как файлы в каталоге Windows, предоставить служебной учетной записи необходимые полномочия, сохранив все существующие настройки. Для частных файлов в каталоге программы отменить все существующие полномочия, в том числе унаследованные, предоставить администраторам полный доступ, а созданной служебной учетной записи - по крайней мере, доступ Read и Execute, хотя такой учетной записи часто требуется создавать и изменять файлы, в зависимости от приложения.
Вместо того чтобы индивидуально назначать каждое полномочие с помощью проводника Windows, можно составить сценарий для каждого изменения с использованием такого инструмента, как CACLS или FILEACL (см. http://www.microsoft.com/downloads/details.aspx?FamilyID=723f64ea-34f0-4e6d-9a72-004d35de4e64&DisplayLang=en). Такой подход позволит избежать повторения всего процесса, если потребуется организовать другой сервер или переустановить данный сервер.
При просмотре списка следует обращать внимание на недокументированные параметры реестра, которые можно использовать для дальнейшего повышения безопасности продукта. Например, можно отметить параметры для отмены неиспользуемых функций, чтобы еще более сократить поверхность атаки приложения. В программе также может быть недокументированный параметр, который определяет место хранения файлов журналов.
Права пользователя
Для работы некоторых приложений требуются специальные права пользователей. Например, Web- или FTP-серверу иногда требуется олицетворять другие пользовательские учетные записи. Чтобы назначить право пользователя, следует открыть оснастку Local Security Policy консоли MMC (или политику домена, если это доменная учетная запись) и выбрать пункт User Rights Assignment из Local Policies.
Как минимум, созданной учетной записи потребуется право Log on as a service. Могут потребоваться и другие права, такие как Generate security audits, Log on as a batch job или Replace a process level token. По умолчанию Windows назначает некоторые права встроенной группе Service, охватывающей всех пользователей, которые регистрируются в качестве службы. Пройдя процедуру входа в качестве службы, учетная запись пользователя автоматически становится частью этой группы.
Чтобы затруднить злоупотребления служебной учетной записью, можно специально отменить некоторые права этой учетной записи, например Deny access to this computer from the network, Deny log on as a batch job, Deny log on locally и Deny log on through Terminal Services.
Финишная прямая
После того, как будут настроены полномочия и права, следует запустить приложение в контексте созданной служебной учетной записи. Остановите службу и назначьте ее свойства, чтобы зарегистрироваться с новой учетной записью пользователя. Запустите службу и подождите, не возникнет ли ошибка. Если служба не запускается, то выясните природу ошибки в журнале событий системы или приложения. Возможно, придется повторить упомянутые ранее запросы Log Parser, чтобы определить причину неполадки. Большинство приложений успешно запускается после незначительной настройки разрешений доступа к файлам и реестру, если только в приложении не предполагается широкого использования административных полномочий.
Если при запуске службы все же возникают ошибки, можно попытаться диагностировать неполадки с использованием инструментов, перечисленных в Таблице 1. После того, как будет налажена корректная работа службы, следует записать изменения, которые потребовались, чтобы привести службу в рабочее состояние. Пошлите свой список автору программы или опубликуйте в соответствующих форумах, чтобы другие администраторы могли воспользоваться плодами вашего труда.
И все же некоторые приложения не удается запустить ни с какими полномочиями, кроме административных. В таком случае уведомите разработчика программы об угрозе безопасности и попросите изменить требования к выполнению. Благодаря совместным усилиям, возможно, нам удастся переломить ситуацию в сфере безопасности.
Марк Барнетт (mburnett@xato.net) - независимый консультант по безопасности и автор, специализирующийся на безопасности Windows. Обладатель сертификата IIS MVP и автор нескольких книг, в том числе Perfect Passwords and Hacking the Code (издательство Syngress).
Экран 1. Вкладка аудита с флажками полного управления.