лекция№10 (1088440), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

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

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

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

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

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

Маркер доступа пользователя.

В Windows NT каждый пользователь (в том числе и каждый псевдопользователь), работающий в системе, имеет свой маркер доступа. Маркер доступа (access token) - это объект специального вида, содержащий следующую информацию:

- идентификатор пользователя;

- идентификаторы групп и специальных групп, в которые входит пользователь;

- привилегии пользователя;

- идентификатор сеанса работы пользователя, к которому относится маркер доступа;

- атрибуты защиты, которые назначаются по умолчанию новым объектам операционной системы, созданным данным пользователем в текущем сеансе работы;

- имя и идентификатор подсистемы, выдавшей маркер доступа (Advapi, если пользователь вошел в систему локально, NtLogon, если пользователь вошел в систему по сети через SMB-сервер, и т.д.);

- некоторую служебную информацию.

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

Дескриптор защиты.

Атрибуты защиты объекта Windows NT описываются специальной структурой данных, называемой дескриптором защиты (security descriptor). Любой объект Windows NT может иметь дескриптор защиты. Дескриптор защиты содержит следующую информацию:

- идентификатор владельца объекта;

- идентификатор первичной группы владельца объекта;

- список избирательного контроля доступа (discretionary access control list, DACL) - список, полностью описывающий права различных субъектов на объект;

- системный список контроля доступа (system access control list, SACL) -используется при генерации сообщений аудита.

Если объект не имеет дескриптора защиты, при обращениях субъектов к нему права доступа не проверяются. В этом случае любой субъект имеет абсолютные права на данный объект.

Управление аутентификацией и доступом в W-2000 (пример):

Администрирование

Локальная политика безопасности

Параметры безопасности

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

-Политики паролей (max и min сроки действия,min длина, сложность, неповторяемость....)

-Политика блокировки учетной записи (на время, после кол-ва ошибок...)

Назначение прав пользователя (архивирование, восстановление, доступ из сети, завершение работы, загрузка-выгрузка драйверов, изменение параметров среды, отладка программ, управление аудитом, увеличение приоритета, ...).

Политики открытого ключа

Политики безопасности IP (сервер, клиент)

Пользователи и пароли

-Управление пользователями (задание имени, пароля, отключение учетной записи...

-Управление группами (создание-удаление, включение-исключение участников..)

Управление безопасностью на уровне домена NT.

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

Один из серверов сети должен быть сконфигурирован в качестве основного контроллера домена (PDC). В базе данных SAM этого сервера создаются учетные записи для всех пользователей сети. Остальные серверы должны выполнить специальную процедуру присоединения к домену, чтобы иметь возможность пользоваться его учетными записями. В результате каждая локальная система безопасности на серверах, являющихся членами домена, присоединяет логически учетные записи, созданные на основном контроллере домена. Соответственно, отпадает необходимость создавать локальные учетные записи для пользователей на каждом сервере (рабочей станции) в отдельности. База данных SAM основного контроллера домена (PDC) - это SAM всего домена, а программа User Manager for Domains, запущенная с любой станции домена, открывает SAM на PDC и записывает туда изменения. Через короткое время PDC реплицирует эти изменения на резервные контроллеры - IBDC.

Когда станция или сервер становятся членами домена, не теряется ни одна из специфичных локальных настроек безопасности. Станция - член домена - "доверяет" выполнение процедуры аутентификации пользователей домена контроллерам домена. При этом пользователь может регистрироваться на рабочей станции как с помощью локальной учетной записи, так и с помощью записи в домене. Для станции, которая является членом домена, в списках ACL для файлов и других объектов могут присутствовать пользователи и группы домена. NT автоматически добавляет группу Domain Admins в состав локальной группы Administrators (поэтому члены Domain Admins имеют административные полномочия на всех станциях - членах домена).

Аудит в Windows NT.

Управление аудитом.

Политика аудита (Audit policy) в NT отвечает за выбор типов событий безопасности, регистрируемых системой в локальном журнале безопасности (Security log), а также способов и условий их регистрации. NT поддерживает семь категорий аудита:

-аудит сеансов работы пользователей;

-аудит доступа к объектам ОС;

-аудит выполнения задач;

-аудит изменения политики безопасности;

-аудит изменения настроек учетных записей.

Систему аудита можно настроить на запись событий об успешном или неудачном завершении проверки для каждой категории. Можно также настроить максимальный размер журнала и действия системы при достижении им этого размера. Система может:

-переписывать самые старые записи журнала;

-перезаписывать записи, устаревшие на указанное число дней (если журнал заполнен, то до истечения этого срока события не регистрируются, пока не будут выполнены условия устаревания записей);

-не перезаписывать журнал (в этом случае необходимо периодически его очищать администратору).

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

Каждый объект NT может иметь список управления аудитом (Audit control lists), описывающий тип событий, которые система регистрирует в журнале при обращении к данному объекту. Для каждого типа доступа (Read, Write, Delete) можно указать, следует ли регистрировать успешные и неуспешные события. Например, для регистрации случаев обращения пользователя к конфиденциальному документу, который пользователь не имеет право просматривать, достаточно включить для этого документа аудит с тем, чтобы NT фиксировала попытки неуспешного запроса на чтение (разрешение Read) членов группы Everyone. Для отслеживания изменений в документе включается аудит использования разрешения Write. Для использования возможностей отслеживать обращения к любым объектам, включая каталоги, файлы, принтеры и ключи реестра, необходимо также включить опцию регистрации доступа к объектам в меню настройки аудита системы, а также указать все объекты, доступ к которым требуется регистрировать. Аудит доступа к объектам ведется также в журнале безопасности.

Аудит выполняющихся задач - process tracking в программе User Manager (в документации по Windows NT и в программе Event Viewer используется термин "детальный аудит" - detailed tracking). Данная категория позволяет проследить за тем, какие именно программы были запущены на рабочей станции и какие программы выполнялись на сервере. Аудит выполняющихся задач может оказаться очень полезным на рабочих станциях, в особенности при изучении активности тех или иных пользователей. Если при этом задействовать аудит доступа к объектам на серверах, то можно построить довольно четкую картину работы пользователей.

Аудит сеансов работы пользователей, аудит доступа к объектам системы и аудит выполняющихся задач являются тремя важнейшими категориями в журнале безопасности Windows NT. Можно связать сеансы работы пользователей, процессы и доступ к объектам и построить точную картину деятельности пользователей. При настройке аудита для этих трех категорий нужно знать, какие компьютеры (рабочие станции, серверы, контроллеры домена) в какие журналы будут записывать те или иные события. Следует помнить, что аудит доступа к объектам системы и аудит выполняющихся задач могут существенно понизить быстродействие системы.

Фиксация событий в журнале безопасности

1) События, связанные с понятием сеанса работы пользователя (входа в систему и выхода из нее).

Событие успешной регистрации пользователя в системе имеет идентификатор (ID) 528. Событие завершения сеанса работы пользователя имеет ID=538. Связать эти события позволяет номер сеанса пользователя Logon ID - уникальный в рамках домена код, присваиваемый любому активному сеансу.

В событии входа в систему также содержится информация о типе входа пользователя (Logon Type):

-тип 2 соответствует интерактивному входу с консоли локального ПК;

-тип 3 соответствует подключению к сетевому ресурсу;

-тип 5 соответствует запуску службы (с указанием учетной записи пользователя);

-тип 7 соответствует разблокированию рабочей станции.

Неудачные попытки входа в систему (Logon Failure) фиксируются в журнале в соответствии с породившей их причиной:

-отказ в регистрации по причине неверного имени пользователя или пароля имееет ID=529;

-по причине недоступности учетной записи - ID=531;

-по причине блокирования учетной записи - ID=539;

-по причине недозволенного времени или дня недели – ID=530;

-по причине просроченной учетной записи – ID=532;

-по причине устаревания пароля - ID=535;

-по причине входа с запрещенного ПК - ID=533;

-по причине входа на запрещенный ПК - ID=534;

-по неизвестной причине – ID=537.

При использовании доменной модели для аутентификации пользователя применяется учетная запись домена. При этом рабочая станция лишь посылает сведения о пользователе на контроллер домена по протоколу NTLM (NT LAN Manager), контроллер домена проверяет правильность пароля и сразу же забывает о пользователе, а записи в журнал о сеансе работы пользователя ведет рабочая станция, с которой он вошел в сеть.

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

2). События, связанные с доступом к объектам NT.

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

-открытие объекта (object opened) - ID=560;

-закрытие объекта (handle closed) - ID=562;

-удаление объекта (object deleted) - ID=564.

При записи в журнал события с ID=560 фиксируются:

-данные об открытом объекте;

-имя пользователя;

-название приложения, которое воспользовалось объектом;

-тип доступа к объекту (чтение, запись, добавление);

-дескриптор Handle ID (уникальный код для контроля NT за каждым объектом);

-номер сессии пользователя (Logon ID).

При записи в журнал события с ID=564 фиксируются только дескриптор и номер процесса. Чтобы разобраться, какой именно объект и каким пользователем был удален, необходимо отыскать по значению Handle ID соответствующее событие 560 открытия объекта.

Характеристики

Список файлов лекций