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

Экран 1. Изменение вида регистрации для службы.

Чтобы в Windows 2000 настроить службу на использование своей учетной записи, отличной от System, нужно открыть Control Panel и выбрать Administrative Tools, Services. Открыв контекстное меню целевой службы, следует щелкнуть Properties и выбрать вкладку Log On. Как показано на Экране 1, по умолчанию установлен параметр Local System account. Чтобы выбрать произвольную учетную запись, требуется выбрать параметр This account и указать нужную учетную запись (это может быть локальная запись или запись в домене) и пароль. Прежде чем это сделать, проверьте, не используется ли выбранная учетная запись где-либо еще. Если хакерам известно имя учетной записи, они могут атаковать ее, что называется, «в лоб», с помощью сетевого анализатора пакетов или иного метода взлома пароля, чтобы получить возможность «легально» зарегистрироваться в системе. К сожалению, даже администраторы порой используют подобные записи для решения тех или иных текущих задач. К счастью, существуют способы снизить уровень риска. Предлагаю вниманию читателей 10 советов, которые помогут обезопасить учетные записи служб и приложений.

Совет 1: закройте «черные ходы»

Следует закрыть «черные ходы» к учетной записи, устранив все необязательные точки доступа. Перед тем как создавать служебную учетную запись, нужно определиться с ее функциями. Если какая-то конкретная функция не требуется, то не должно быть и соответствующих разрешений на доступ. Например, в качестве «черного хода» в сеть хакеры могут использовать сервер удаленного доступа. Поэтому если службе нет необходимости работать с сервером удаленного доступа, ее учетная запись не должна иметь разрешения на удаленный доступ. Как нетрудно убедиться, посмотрев на Экран 2, в Windows 2000 можно явным образом назначить или убрать разрешение на удаленный доступ в свойствах учетной записи службы (контекстное меню службы, пункт Properties). Если планируется использовать сценарии для создания учетных записей, следует убедиться, что в его коде удаленный доступ явно запрещен.

Экран 2. Запрет на использование удаленного доступа.

Обращаю внимание читателей, что на Экране 2 параметр Control access through Remote Access Policy недоступен. Эта новая настройка Windows 2000 позволяет предоставить или отобрать разрешения на удаленный доступ через RRAS. Однако если RRAS развернут и данный флажок установлен, это будет означать, что учетная запись по ошибке получает разрешение на dial-in. В целях безопасности следует установить параметр Deny access.

Помимо возможности удаленного доступа есть и другие хорошо известные «черные ходы» — это терминальный доступ и функции удаленного управления. Терминальный доступ может быть получен через вкладку Terminal Services Profile, а удаленное управление — через вкладку Remote control в свойствах службы. Следует также избегать использования возможностей доступа через Internet или применения почтовой учетной записи. И то и другое открывает перед хакером большие возможности. Например, если злоумышленники взламывают запись, имеющую доступ в Internet, они могут автоматически запустить Microsoft Internet Explorer (IE) и загрузить, скажем, «троянского коня» на все компьютеры, где данная учетная запись имеет соответствующее разрешение.

Совет 2: избегайте копирования учетных записей

Обычно рекомендуется создавать учетную запись «с нуля» с последующим назначением необходимых прав. Однако в некоторых случаях используется копирование записей. Например, иногда в крупных компаниях считают, что создавать записи одну за другой слишком накладно, и для оптимизации этого процесса используют оснастку Active Directory Users and Computers для копирования уже существующих учетных записей. При этом привилегии исходной учетной записи копируются автоматически и непреднамеренно могут быть скопированы лишние права. Поэтому лучше избегать копирования учетных записей, если роли целевой и исходной записей различны. Не следует, например, создавать учетную запись для терминального сервера, воспользовавшись процедурой копирования учетной записи сервера удаленного доступа. Когда назначения записей различны, практически всегда должны быть различны и привилегии.

Копирование облегчает труд администратора, но может открыть новый «черный ход» в систему. Небольшие дополнительные усилия со стороны администраторов способны существенно снизить риск, связанный с чрезмерными привилегиями учетных записей.

Совет 3: используйте правильные группы безопасности

В некоторых случаях учетные записи для служб включают в состав одной или нескольких встроенных групп, таких, как Administrators или Domain Admins. Использовать таким образом группы с высокими привилегиями чрезвычайно рискованно. Если, к примеру, учетная запись SQL Server принадлежит группе Administrators, любой желающий с помощью хранимой процедуры xp_cmdshell может обратиться к операционной системе и выполнить команды в контексте операционной системы. Отследить действия злоумышленника в таком случае будет очень трудно.

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

В Windows 2000 имеется четыре группы безопасности, которые могут использоваться для создания учетных записей. Каждая группа имеет различные области действия, устанавливающие рамки, в пределах которых одни группы могут входить в состав других или иметь доступ к ресурсам Active Directory (AD). Вот эти группы в порядке расширения области действия: локальные группы (ограничены рамками одного компьютера), группы локального домена, глобальные и универсальные группы. Подробнее об этом рассказано в статье Microsoft «Active Directory Users, Computers and Groups» по адресу: http:// www.microsoft.com/ windows2000/ techinfo/ howitworks/ activedirectory/ adusers.asp.

Степень влияния учетной записи на работу сети зависит от того, в состав какой группы входит эта запись. Например, можно создать учетную запись в составе домена, добавить ее в глобальную группу и включить эту группу в локальную группу на сервере. После того как локальной группе будут предоставлены права доступа к некоторому ресурсу на сервере, члены глобальной группы также унаследуют эти права. Но если учетная запись создана на уровне домена, область ее действия будет очень широкой, поскольку Windows 2000 по умолчанию включает учетную запись домена в состав группы Domain Users.

С другой стороны, можно создать служебную учетную запись на уровне сервера (локальная запись), на котором собственно и размещены нужные ресурсы, сократив тем самым область потенциального доступа. Однако локальные учетные записи требуют децентрализованного администрирования. В частности, Windows 2000 создает локальные учетные записи в SAM целевого компьютера. Следовательно, централизованно управлять такими учетными записями не удастся, в отличие от записей на уровне домена, которые Windows 2000 хранит в AD. Со временем из-за отсутствия централизации локальная учетная запись может быть попросту позабыта и использована не по назначению. Поэтому лучше все же создавать доменные записи и включать их в состав соответствующих групп. К учетным записям домена нужно относиться с большей строгостью и регулярно просматривать журнал Security Log контроллера домена.

Совет 4: запрещайте доступ явным образом

В случае атаки хакеров последний рубеж обороны — список разграничительного контроля доступа (discretionary ACL, DACL). Из-за непродуманной системы DACL служебные учетные записи могут получить доступ к большему числу ресурсов, чем это действительно необходимо. В Windows 2000 появилась новая настройка — флажок Deny, с помощью которого можно явно запретить назначение того или иного разрешения. Для служебной учетной записи следует явным образом запретить права на доступ к таким объектам, как файлы, каталоги, совместно используемые ресурсы и реестр. Поскольку Windows 2000 в первую очередь анализирует явные запреты доступа, все возможные конфликты, связанные с правами доступа, устраняются автоматически.

Создадим, например, учетную запись с именем Svc1. По умолчанию Windows 2000 включает эту запись в группу Everyone, для которой имеются разрешения Read and Execute по отношению к системным утилитам, таким, как ftp. Однако, может быть, стоит явно запретить Svc1 запускать ftp. Следует просто открыть контекстное меню соответствующего ресурса (C:winntsystem32ftp.exe), щелкнуть Properties и перейти на вкладку Security. В том случае, если такие специфические разрешения, как Write, для данного ресурса не указаны, следует установить флажок Deny для разрешения Full Control, что приведет к автоматической установке флажков Deny для всех имеющихся разрешений данного ресурса. Установка флажка Deny перекрывает любое иное разрешение, унаследованное от родительского каталога (C:winntsystem32, в данном случае), даже если есть явное указание о наследовании системы разрешений.

Совет 5: удалите необязательные права

Чаще всего служебной учетной записи нужно только право Logon as a service. Если учетная запись входит в состав встроенной группы, то она может неявным образом получить дополнительные права. Если абсолютно необходимо внести учетную запись в состав встроенных групп с высокими привилегиями (например, Administrators), нужно будет просмотреть права пользователей и удалить те, которые не являются обязательными для служебной учетной записи.

Windows 2000 предоставляет способ явного отзыва некоторых наиболее распространенных прав. Например, четыре новые настройки Windows 2000 позволяют явно запретить право регистрации. Это касается таких прав, как Deny access to this computer from the network, Deny logon as a batch job и Deny logon locally.

Для назначения прав пользователя можно задействовать локальные политики или Group Policy Object (GPO). Скажем, администратор может создать GPO, которая явным образом запрещает регистрацию по сети, локально или из программы. Поскольку Windows 2000 накладывает права пользователя на политику компьютера, нужно добавить GPO на уровень домена для применения данной GPO на всех машинах, учетные записи которых присутствуют в AD. Применение GPO на станции, принадлежащей домену Windows NT, невозможно.

В процессе удаления ненужных прав следует убедиться, что у учетной записи остались необходимые для работы права. Скажем, служебная запись Exchange Server нуждается в правах Act as Part of the Operating System, Log On as a Service и Restore Files and Directories. Если нет четкого представления о том, какие права нужны конкретной записи для работы, можно просмотреть техническую документацию или связаться с поставщиком программного обеспечения.

Совет 6: используйте параметр Logon To

Параметр Logon To ограничивает список машин, на которых может регистрироваться пользователь домена. Указанный параметр вполне эффективен для ограничения влияния учетной записи домена, особенно когда речь идет об однодоменной модели, использующей WINS. Необходимо открыть контекстное меню доменной учетной записи, перейти на вкладку Account и щелкнуть параметр Logon To. На Экране 3 показано, что в поле Computer name понадобится ввести NetBIOS-имя станции (не путать с DNS-именем).

Экран 3. Назначение компьютеров, к которым можно подсоединяться с учетной записью домена.

Совет 7: установите временные ограничения

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

Чтобы настроить параметр Logon Hours, следует открыть контекстное меню учетной записи домена, выбрать вкладку Account и щелкнуть Logon Hours. Как всегда при работе с параметрами, относящимися к управлению безопасностью в домене, неверная настройка параметров может негативно сказаться на функциональности службы. Поскольку параметр Logon Hours — это атрибут учетной записи домена (не локальной учетной записи), воспользоваться им можно только при работе с учетными записями на уровне домена.

К сказанному добавим, что при регистрации служебной учетной записи за рамками разрешенного временного интервала можно указать, что процедура регистрации должна завершиться с ошибкой. Например, со служебной записью, с которой разрешено регистрироваться с 8 ч утра до 17 ч вечера, нельзя будет зарегистрироваться в том случае, если администратор предусмотрел автоматический перезапуск сервера в 18 ч вечера. Таким образом, параметр Logon Hours больше всего подходит для служб, запуск которых осуществляется в ручном, а не в автоматическом режиме.

Совет 8: используйте параметр Set Password

Windows 2000 располагает двумя заслуживающими внимания параметрами установки пароля, которыми можно воспользоваться для повышения безопасности работы службы: User cannot change password и Account is sensitive and cannot be delegated. Установка флажка User cannot change password гарантирует, что только системные администраторы могут изменять пароль учетной записи. Учитывая, что служебная запись не является обычной учетной записью пользователя, есть несколько причин запретить смену пароля кому-либо, кроме администратора. По умолчанию нельзя установить этот флажок для служебных записей — членов группы Administrators, поскольку подразумевается, что администраторы имеют право менять свои пароли. Но, повторю еще раз, назначать учетной записи службы административные привилегии весьма нежелательно.

Чтобы настроить параметр User cannot change password, следует открыть контекстное меню учетной записи и выбрать Properties. Затем нужно перейти на вкладку Account, если это доменная учетная запись, и на вкладку General, если это локальная запись. Теперь требуется установить флажок User cannot change password.

Менять пароль служебной учетной записи необходимо всякий раз, когда сотрудник, которому был известен старый пароль, уходит из организации или его служебные обязанности меняются. Придерживаясь такой практики, легко снизить риск незаконного использования служебной записи. Перед сменой пароля следует вспомнить, что Local Security Authority (LSA) на целевой машине хранит пароли для всех служебных записей. Поэтому обязательно нужно изменить пароль и на вкладке Log On (см. Экран 1).

Настройка Account is sensitive and cannot be delegated означает, что запись нельзя делегировать. В процессе делегирования полномочий одной записи другой становится возможным подключение к локальным или удаленным станциям в контексте безопасности делегируемой записи. Это та самая техника, с помощью которой хакер может запустить вредоносную программу в контексте штатной записи и получить доступ к сети.

К счастью, только члены группы Domain Administrators имеют право управлять делегированием полномочий. Но на всякий случай желательно каждый раз устанавливать флажок Account is sensitive and cannot be delegated, если только делегирование не потребуется учетной записи явно. Параметр устанавливается на вкладке Account в поле Account is sensitive and cannot be delegated в свойствах записи. Для локальных записей параметр отсутствует.

Совет 9: используйте элементы управления безопасностью

Оснастка Security Templates в MMC позволяет описывать и применять настройки безопасности в семи областях: политике учетных записей (Account Policies), локальной политике (Local Policies), журнале регистрации (Event Log), группах ограничения доступа (Restricted Groups), системных службах (System Services), реестре (Registry) и, наконец, в файловой системе (File System). Для удобства работы можно воспользоваться специальной программой, Security Templates,

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

Шаблоны удобны в тех случаях, когда пользователи могут попытаться воспользоваться служебной записью для расширения своих привилегий. После создания шаблона безопасности служебной записи его настройки можно импортировать на другие машины сети.

Совет 10: регулярно проверяйте журнал безопасности

При реализации мер по усилению безопасности служебных учетных записей журнал Security Log в Event Viewer также может оказаться весьма полезным. Во-первых, с помощью журнала устанавливается, как отражаются меры усиления безопасности на процедуре регистрации служебной записи. Во-вторых, можно проводить мониторинг журнала на предмет выяснения причин подозрительной активности.

Для выполнения обеих задач необходимо описать политику аудита до того, как будет произведена регистрация с учетной записью службы. Политика может быть настроена как локально на целевой машине, так и через GPO в AD. Для определения локальной политики следует запустить Control Panel, Administrative Tools, Local Security Policy. Затем требуется раскрыть Local Policies и Audit Policy для просмотра и настройки списка категорий аудита.

Чтобы выяснить степень влияния усиления мер безопасности на процедуру регистрации служебной записи, необходимо активизировать настройку Audit logon events и фиксировать все попытки регистрации с этой учетной записью — как успешные, так и неуспешные. После чего следует регулярно просматривать события регистрации на целевом компьютере (Control Panel, Administrative Tools, Event Viewer). Событие с ID 528 указывает на успешную регистрацию, с ID 529 — на сбой в процессе регистрации. Во втором случае потребуется пересмотреть принятые меры усиления безопасности.

Когда возникает событие регистрации от имени учетной записи, Windows 2000 помещает в поле Logon Type некий код для обозначения типа процедуры регистрации. Регистрация для учетной записи службы обозначается как Type 5. Если иметь в виду дальнейший мониторинг журнала безопасности, обычно нет необходимости присваивать служебной учетной записи право локальной регистрации (Type 2) или же регистрации по сети (Type 3). Поэтому появление записи о локальной или сетевой регистрации служебной записи должно стать для администратора сигналом тревоги. Еще один тип регистрации, Type 4, означает регистрацию во время пакетной обработки задания (batch-job logon).

Еще одна политика аудита, которую можно активизировать, — Audit object access. Хотя аудит этой политики может занять много системных ресурсов, он полезен для установления базовых требований доступа для той или иной службы. Предположим, например, что нужно установить базовые требования доступа для утилиты cmd.exe. После активизации политики Audit object access следует открыть контекстное меню cmd.exe и выбрать Properties, Security. Затем нужно нажать кнопку Advanced. В появившемся окне требуется выбрать запись службы и установить разрешения на доступ к объекту (например, Read, Write), аудит которых необходимо выполнить. Затем следует запустить службу и приложение, чтобы установить базовые ограничения. И, наконец, необходимо просмотреть журнал Security Event Log, чтобы увидеть последовательность обращений к указанному файлу. Например, если видно, что для файла cmd.exe разрешение на чтение не использовалось, разрешение Read можно явным образом для него отменить.

Не давайте хакерам покоя

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

Джарвис Робинсон — специалист по безопасности в Allstate Insurance. Имеет сертификаты MSCE и CISSP. С ним можно связаться по адресу: Jarvis_robinson@msn.com.