Какие учетные записи имеются по умолчанию в windows 2000

После
завершения установки Windows
2000/XP
создаются несколько встро­енных
пользовательских учетных записей,
которым назначены определенные
при­вилегии
и ограничения:

• Администратор
  (Administrator).
  Данная учетная запись предоставляет
  полный набор
  прав доступа для всего компьютера.
  Являясь постоянным членом группы
  Administrators,
  эта учетная запись позволяет реализовать
  неограниченный дос­туп
  ко всем файлам и ключам системного
  реестра. Учетная запись Administrator
  может
  создавать другие учетные записи
  пользователей.

• Гость
  (Guest).
  Учетная запись Guest
  предназначена для случайных пользова­телей
  или же тех, кто обращается к данной
  системе однократно. Заданные по умолчанию
  привилегии для этой учетной записи
  довольно ограниченны. Поль­зователи-гости
  могут только выполнять программы и
  сохранять документы, управлять ресурсами
  ЭВМ они не имеют права.

• HelpAssistant.
  Учетная запись HelpAssistant,
  используемая для сеансов Remote
  Assistance,
  по умолчанию отключена (и защищена
  строгим паролем). Она уста­навливается
  на компьютере начинающего пользователя
  и предназначена для регистрации
  удаленного эксперта.

• SUPPORT_xxxxxxxx.
  Windows
  XP
  может содержать одну или несколько
  учетных
  записей, которые предназначены для
  реализации интерактивной поддержки
  и обслуживания поставщиками, например
  компанией Microsoft
  либо
  производителем вашего компьютера.
  Здесь ххххххххх представляет но­мер,
  определяемый поставщиком.

2.1.3. Группы безопасности

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

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

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

2.1.4.Типы учетных записей

Для
Windows
XP
характерен термин тип
учетной записи.
Обычно этот термин имеет значение при
обращении к инструменту User
Accounts
(Пользова­тельские
учетные записи) в панели управления.
Тип учетной записи позволяет описать
членство в группе безопасности. И хотя
допускается
произвольное количество групп
безопасности, Windows
XP
относит каждую пользовательскую
учетную запись к одному из четырех
указанных типов:

• Computer
  administrator
  (администраторы компьютера). Члены
  указанной груп­пы Administrators
  (Администраторы) классифицируются в
  качестве учетных записей
  администраторов компьютера.

• Limited
  (ограничения). Члены группы Users
  (Пользователи) классифициру­ются
  с помощью учетных записей с ограничениями.

• Guest
  (Гости). Члены группы Guests
  (Гости) ассоциируются с гостевыми
  учет­ными
  записями.

• Unknown
  (неизвестные). Учетная пользовательская
  запись, не включенная в
  группы Administrators,
  Users
  или Guests,
  относится к категории неизвестных
  учетных
  записей. Поскольку учетные записи,
  создаваемые с помощью утилиты User
  Accounts
  из панели управления, присваиваются
  группе Administrators
  или группе
  Users,
  неизвестные учетные записи встречаются
  только при обновлении ранних
  версий Windows,
  а также при
  обраще­нии
  к, консоли Local
  Users
  And
  Groups
  или к команде Net
  Localgroup
  при контроле членства в группах.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Изменение настроек по умолчанию для учетных записей пользователей

Учетные записи по умолчанию, устанавливаемые при инсталляции Windows 2000 и IIS, следует проверить на соответствие политике безопасности и адаптировать при необходимости. Ниже приведены соответствующие рекомендации.

Отключение и игнорирование прав и разрешений учетной записи Guest Windows 2000

Windows 2000 всегда устанавливает учетную запись Guest (Гость) по умолчанию. При правильной установке IIS учетная запись Guest должна быть отключена. Убедитесь, что это так, если вы обновили систему с Windows NT или преобразовали имевшийся сервер Windows 2000 в веб-сервер.

Для проверки состояния учетной записи Guest выполните следующие шаги.

1. В консоли Computer Management (Управление компьютером) найдите папку Local Users and Groups (Локальные пользователи и группы) в дереве ресурсов. Откройте ее, затем откройте папку Users (Пользователи) для отображения имен всех учетных записей пользователей в правом окне.
2. Если гостевая учетная запись отключена, то на ее значке будет изображен красный крестик.
3. Если учетная запись Guest не отключена, щелкните на ней правой кнопкой мыши и выберите пункт Properties (Свойства). Откроется диалоговое окно, показанное ниже. Отметьте опцию Account Is Disabled (Учетная запись отключена), после чего нажмите на OK для сохранения изменений и закрытия окна.

   

Обеспечение безопасности группы Guest в Windows 2000

Группа Guest (Гость) по умолчанию устанавливается и в Windows 2000. Следует внимательно следить за настройками гостевых учетных записей. Учетная запись Windows 2000 Guest всегда входит в группу Guest, как и некоторые другие учетные записи по умолчанию.

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

Высокоэффективная защита против атак через учетную запись Guest заключается в ее удалении из группы Guest. Но не удаляйте ее сразу. Учетная запись Internet Guest (IUSR_ %имя компьютера% ) необходима для реализации анонимного входа. Вместо удаления ее следует переименовать и переместить. Перед тем как предпринимать дальнейшие действия, прочтите два следующих раздела.

Обеспечение безопасности учетной записи Internet Guest для анонимного входа в систему

На большей части сайтов в интернете, используемых для маркетинга и распространения информации, не нужна аутентификация пользователей, так как все посетители считаются легальными. Вместо аутентификации используется анонимный вход, о котором вкратце говорилось в
«Подготовка и укрепление веб-сервера»
. Анонимный вход представляет собой автоматическую аутентификацию пользователей при помощи общей учетной записи с именем IUSR. (В списке ACL сервера она значится как IUSR_ %имя компьютера%.) Эту учетную запись называют гостевой записью интернета.

Важно. При использовании анонимного входа (например, если веб-сайт находится во внутренней сети, и нужна аутентификация всех пользователей без исключения) убедитесь, что учетная запись AnonymousGuest (Анонимный гость) не выбрана на вкладке IIS Directory Service (Служба каталогов IIS), и отключите ее.

Учетная запись Internet Guest (Гостевая учетная запись интернета) имеет ограниченные разрешения, которыми можно смело наделять всех посетителей сайта. Для обеспечения максимальной безопасности учетные записи должны содержать только разрешение Read (Чтение) в некоторых каталогах веб-сайта.

Рекомендуется создать новую учетную запись Internet Guest. Во-первых, уменьшается опасность использования учетной записи по умолчанию при попытке атаки. Во-вторых, на данном этапе при перезагрузке Windows 2000/IIS сбрасываются некоторые настройки, о которых вы узнаете далее. В случае изменения учетной записи Internet Guest внесенные изменения сбрасываться не будут.

Для создания новой учетной записи Internet Guest выполните следующее.

1. Создайте новую группу, которой будет принадлежать учетная запись. Откройте консоль MMC Computer Management (Управление компьютером).
2. Найдите папку Local Users and Groups (Локальные пользователи и группы) в дереве ресурсов и откройте ее, чтобы развернуть вложенный список. Щелкните правой кнопкой мыши на папке Groups (Группы) и выберите New Group (Создать группу).
3. В диалоговом окне New Group присвойте группе название. Укажите любое желаемое имя. Имя «Siteguests» будет достаточно информативным. Нажмите на кнопку Create (Создать) для сохранения новых настроек группы.
4. Переименуйте учетную запись IUSR. Вернитесь в консоль MMC Computer Management, щелкните на папке Users (Пользователи) и найдите учетную запись IUSR в правом окне консоли. Щелкните на ней правой кнопкой мыши и выберите команду Rename (Переименовать). Присвойте учетной записи имя, например, SiteIUSR_ %имя сервера%.
5. Настройте параметры учетной записи и включите ее в только что созданную группы Guest. Щелкните правой кнопкой мыши на учетной записи и выберите команду Properties.
6. Убедитесь, что на вкладке General (Общие) диалогового окна Properties отмечены следующие опции: User Cannot Change Password (Пользователь не может сменить пароль) и Password Never Expires (Срок действия пароля не ограничен) (см. рисунок).

   

7. Откройте вкладку Member Of (Член группы) и удалите учетную запись из группы Guests. Затем добавьте ее в новую группу «Siteguests». Не допускайте, чтобы эта учетная запись являлась членом какой-либо другой группы.
   

   Совет. При необходимости можно удалить группу Web Anonymous (Анонимные пользователи интернета). Специалисты в области информационной безопасности, как правило, оставляют ее в качестве обманного маневра (убедитесь, что отключены все разрешения для данной группы).

8. Нажмите на OK, чтобы сохранить изменения и закрыть диалоговое окно.

Главная / Безопасность /
Безопасность сетей / Тест 15

Основными средствами управления AD являются:

Средствами управления AD не являются:

Сколько уровней аутентификации в LAN Manager?

Для выполнения каких действий могут использоваться групповые политики (GP)?

Какие порты в дополнение к стандартным используются в Windows 2000?

Для выполнения каких действий не могут использоваться групповые политики (GP).

В службе терминалов Windows 2003 Server шифрование с 56-битным ключом соответствует уровню:

В службе терминалов Windows 2003 Server шифрование с ключом максимальной длины, поддерживаемого клиентом соответствует уровню:

В службе терминалов Windows 2003 Server шифрование в соответствии со стандартом Federal Information Processing Standard 140-1 соответствует уровню:

Основными возможностями утилиты secedit.exe являются:

На что указывает ключ /overwrite при использовании утилиты secedit.exe?

На что указывает ключ /DB при использовании утилиты secedit.exe?

Какие события в системе рекомендуется фиксировать в большинстве случаев?

Как должна настраиваться политика аудита?

В каком формате могут сохраняться файлы журналов?

В какой папке располагаются файлы журнала в windows 2000?

Кому разрешен доступ к файлу журнала?

Может ли информация в журнале служить доказательством противоправных действий конкретного пользователя?

В Windows 2003 в групповую политику добавлены два отдельных элемента, какие?

Сколько областей в утилите Group Policies?

Какие области существуют в утилите Group Policies?

Каков порядок шагов автоматически выполняемые системой Windows при оценке/применении Group Policy?

Каков порядок шагов автоматически выполняемые системой Windows 2003 при входе пользователя?

Какие средства управления групповой политикой предоставляет Windows?

Какие учетные записи имеются по умолчанию в Windows 2000?

Каковы требования фильтра паролей по умолчанию?

На какую учетную запись не распространяется политика блокировки?

Какие пользователи имеют доступ к файлам зашифрованными с помощью файловой системы EFS?

Какой основной недостаток файловой системы NTFS?

Что произойдет с зашифрованным файлом при копировании его на диск с файловой системой отличной от NTFS 5.0?

Какой признак будет указывать на попытку взлома системы?

Какие признаки говорят о взломе системы?

О чем может говорить наличие запущенных в системе неизвестных процессов?

Что из ниже перечисленного является ключевым компонентами AD и их функциями?

Домен – это...

На каких уровнях могут применяться групповые политики?

Учетные записи пользователей позволяют Microsoft Windows 2000 отслеживать информацию о пользователях и управлять их правами доступа и привилегиями. При создании учетных записей пользователя, основными средствами управления учетными записями, которые Вы используете, являются:

Автор Уильям Р. Станек (William R. Stanek).

Автор: Александр Кузьменко aka Kthulhu
Иcточник: (переведено с англ.) Microsoft Technet
Взято с oszone.ru

Оцените статью: Голосов

Учетные записи пользователей

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

Эффективная работа с паролями

NTFS и права человека

Реестр

Союз ИТ Профессионалов

Создание учетных записей пользователей

Введение

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

Учетные записи
пользователей позволяют Microsoft Windows 2000 отслеживать информацию о
пользователях и управлять их правами доступа и привилегиями. При создании
учетных записей пользователя, основными средствами управления учетными
записями, которые Вы используете, являются:

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

Предварительная
настройка и организация учетной записи пользователя

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

Политики
присвоения имен учетных записей

Основной политикой,
которую Вам необходимо будет установить, является схема именования для учетных
записей. Учетным записям пользователя присваиваются отображаемые имена и имена
входа. Отображаемое имя (или полное имя) – это выводимое имя пользователя,
используемое в пользовательских сеансах. Имя входа используется для входа в
домен. Имена входа были коротко рассмотрены в разделе Главы 7 «Имена для
входа, Пароли и Открытые сертификаты». 

Правила
для отображаемых имен

В Windows 2000
отображаемое имя обычно является объединением имени и фамилии пользователя, но
Вы можете установить для него любое строковое значение. Отображаемые имена
должны соответствовать следующим правилам:

Правила
для имен входа

Имена входа должны
соответствовать следующим правилам:

Примечание. Хотя Windows 2000 хранит имена
пользователей в том же регистре, что был использован при вводе, они не являются
чувствительными к регистру. Например, Вы можете получить доступ к учетной
записи «Администратор», используя имя пользователя «Администратор» или
«администратор». Таким образом, имена пользователей не чувствительны к
регистру, хотя строчные и заглавные буквы в них поддерживаются.

Схемы
именования

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

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

Политики
паролей и учетных записей

Учетные записи Windows
2000 используют пароли и открытые сертификаты, чтобы удостоверять доступ к
сетевым ресурсам. Данный раздел посвящен паролям.

Безопасные
пароли

Пароль – это чувствительная
к регистру строка, которая содержит до 104 символов в Службе каталога Active
Directory и до 14 символов в Диспетчере безопасности Windows NT (Windows NT
Security Manager). Допустимыми символами для паролей являются буквы, цифры и
специальные символы.

После установки пароля
для учетной записи, Windows 2000 сохраняет его в зашифрованном формате в базе
данных учетных записей.

Недостаточно просто иметь
пароль. Чтобы избежать неавторизованного доступа к сетевым ресурсам, нужно
использовать безопасные пароли. Разница между обычным и безопасным
паролем заключается в том, что безопасный пароль трудно угадать и взломать.
Трудными для взлома пароли делает комбинация всех возможных типов символов –
включая строчные и заглавные буквы, цифры и специальные символы. Например,
вместо использования happydays в качестве пароля, используйте haPPy2Days&,
Ha**y!dayS, или даже h*PPY%d*ys

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

Установка
Политик для управления учетными записями

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

Как только Вы начали
работать с нужным контейнером групповой политики, Вы можете настроить политики,
выполнив следующие шаги:

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

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

Просмотр
действующих политик

Во время работы с
политиками учетных записей и присвоением прав пользователей Вам часто бывает
необходимо просмотреть политику, действующую на локальную систему. Действующей
является применённая на данный момент политика и, как описано в Главе 4 «Управление
Групповой политикой», она зависит от последовательности, в которой политики
были применены.

Выполните следующие шаги,
чтобы просмотреть политику, действующую на локальную систему:

Настройка
политик учетных записей

Как Вы узнали из
предыдущего раздела, существует три типа политик для управления учетными
записями: политики паролей, политики блокировки учетных записей и политики
Kerberos. Следующий раздел описывает настройку каждой из этих политик. 

Рисунок 8-4. Локальные
политики отображают как действующие параметры, так и локальные параметры.

Настройка
политик паролей

Политики паролей
контролируют безопасность паролей и они включают:

Использование этих
политик описано в следующих разделах.

Требовать
неповторяемости паролей

Политика «Требовать
неповторяемости паролей» определяет, как часто старые пароли могут быть
использованы повторно. С помощью этой политики Вы можете побудить пользователей
к выбору паролей, не входящих в общеизвестный набор. Windows 2000 может хранить
до 24 паролей для каждого пользователя, но по умолчанию хранит в истории
паролей только один.

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

Примечание. Вы не должны разрешать пользователям
менять пароли немедленно, чтобы они не смогли обойти политику «Требовать
неповторяемости паролей». Это помешает пользователям изменять свои пароли
несколько раз подряд, чтобы вернуться к старым паролям.

Максимальный
срок действия паролей

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

Срок действия пароля по
умолчанию составляет 42 дня, но Вы можете присвоить ему любое значение от 0 до
999. Значение 0 означает, что срок действия пароля никогда не истекает.
Несмотря на то, что, возможно, Вы хотели бы установить неистекающий срок
действия пароля, пользователи должны менять пароль регулярно для поддержания
безопасности сети. Если требования к безопасности высоки, подойдут значения 30,
60 или 90 дней. Если безопасность не очень важна, то подойдут значения 120, 150
или 180 дней.

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

Минимальный
срок действия паролей

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

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

Минимальная
длина пароля

Политика «Минимальная
длина пароля» устанавливает минимальное количество символов для пароля. Если Вы
не меняли параметры, установленные по умолчанию, Вам придется это сделать очень
скоро. По умолчанию разрешены пустые пароли (пароли, в которых нет символов),
что определенно не является правильным подходом.

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

Пароль
должен отвечать требованиям сложности

Помимо основных политик
для управления паролями и учетными записями, Windows 2000 включает средства для
создания дополнительных элементов управления паролями. Эти возможности доступны
в фильтрах паролей, которые могут быть установлены на контроллер домена. Если
Вы установили фильтр пароля, разрешите политику «Пароль должен отвечать
требованиям сложности». В этом случае все пароли должны будут соответствовать
требованиям безопасности фильтра.

Например, стандартный
фильтр Windows NT (PASSFILT.DLL) требует использования безопасных паролей,
которые соответствуют следующим рекомендациям:

Хранить
пароли, используя обратимое шифрование

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

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

Эти политики:

Пороговое
значение блокировки

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

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

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

Вы можете установить для
порога блокировки любое значение от 0 до 999. Значение порога блокировки по
умолчанию установлено равным 0, это значит, что учетная запись не будет
блокироваться из-за неправильных попыток входа. Любое другое значение
устанавливает определенный порог блокировки. Помните, что чем выше значение
порога блокировки, тем выше риск, что хакер сможет получить доступ к вашей системе.
Приемлемые значения для этого порога находятся между 7 и 15. Это достаточно
много, чтобы исключить ошибку пользователя и достаточно мало, чтобы отпугнуть
хакеров.

Длительность
блокировки учетной записи

При превышении порога
блокировки, политика «Блокировка учетной записи» устанавливает её длительность.
Вы можете установить соответствующее значение, используя величину от 1 до
99,999 минут, или на неограниченное время, путем установки этого параметра
равным 0.

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

Совет. Если учетная запись заблокирована,
обратитесь к диалоговому окну Свойства для данной учетной записи в оснастке
Active Directory – Пользователи и компьютеры. Щелкните по вкладке Учетная
запись и снимите флажок «Учетная запись заблокирована». Это разблокирует
учетную запись.

Сброс
счетчика блокировки через

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

По умолчанию, установлено
сохранение порога в течение одной минуты, но Вы можете установить любое
значение от 1 до 99,999 минут. Как и с Порогом блокировки учетной записи,
необходимо выбрать значение, которое находится в равновесии между нуждами безопасности
и нуждами пользователей. Подходящее значение находится в диапазоне от одного до
двух часов. Этот период ожидания должен быть достаточно большим, чтобы
заставить взломщиков ждать дольше, чем им хотелось бы, перед новой попыткой
получить доступ к учетной записи.

Примечание. Неудачные попытки входа на рабочую
станцию через заставку защищенную паролем не увеличивают значение порога
блокировки. Также, если Вы блокируете сервер или рабочую станцию используя
Ctrl+Alt+Delete, неудачные попытки входа через окно Снятие блокировки
компьютера не будут учитываться.

Настройка
политик Kerberos

Kerberos версии 5
является основным механизмом проверки подлинности, используемым в домене Active
Directory. Kerberos использует билеты службы и билеты пользователя для идентификации
пользователей и сетевых служб. Как Вы догадываетесь, билеты службы используются
служебными процессами Windows 2000, а билеты пользователя пользовательскими
процессами. Билеты содержат зашифрованные данные, подтверждающие подлинность
пользователя или службы.

Вы можете контролировать
длительность билета, его возобновление и применение, используя следующие
политики:

Эти политики описаны в
следующем разделе.

Внимание. Только администраторы, полностью
понимающие пакет безопасности Kerberos, должны менять эти политики. Установка
неправильных параметров для данных политик может повлечь серьезные проблемы в
сети. В большинстве случаев параметры политики Kerberos, установленные по
умолчанию, работают как надо.

Принудительные
ограничения входа пользователей

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

Максимальный
срок жизни

Политики «Максимальный
срок жизни билета службы» и «Максимальный срок жизни билета пользователя»
устанавливают максимальный срок, в течение которого билет службы или
пользователя имеет силу. По умолчанию, билеты службы имеют максимальную
длительность 41,760 минут, а билеты пользователя – 720 часов.

Вы можете изменить
длительность билетов. Для билетов службы эффективные значения находятся в
диапазоне от 0 до 99,999 минут. Для билетов пользователя – от 0 до 99,999
часов. Нулевое значение выключает истечение срока жизни. Любые другие значения
устанавливают определенный срок жизни билета.

Билет с истекшим сроком
жизни может быть возобновлен. Для возобновленного билета устанавливается срок
жизни в соответствии с политикой «Максимальный срок жизни для возобновления
билета пользователя». По умолчанию период возобновления билета составляет 60
дней. Вы можете установить период возобновления от 0 до 99,999 дней. Нулевое
значение выключает максимальный период обновления, а любые другие значения
устанавливают его определенный срок. 

Максимальная
погрешность

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

Если у Вас есть удаленные
пользователи, которые входят в домен без синхронизации их часов с сетевым
сервером времени, Вам может понадобиться установить этот параметр. Его диапазон
— от 0 до 99,999

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

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

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

Аннотация

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

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

В рамках
инициативы корпорации Майкрософт «Защищенные компьютерные системы» используемые
в Microsoft® Windows Server™ 2003 параметры по умолчанию рассчитаны на
обеспечение защиты службы каталогов Active Directory® от различных угроз.
Однако уровень безопасности учетных записей администраторов корпоративной сети
среднего размера можно усилить еще больше, изменив некоторые их параметры.
Кроме того, службы, не входящие в состав операционной системы
Windows Server 2003 и устанавливаемые другими приложениями, также
необходимо защитить. В данном документе описываются способы обеспечения
безопасности этих учетных записей и служб, а также содержатся рекомендации по
контролю над использованием и управлением административными полномочиями.

Существует большое число приложений, которые по умолчанию запускаются в контексте учетной записи 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.