Введение
Операционная система, также называемая ОС, представляет собой набор системных программ, инструментов и утилит, которые управляют аппаратными ресурсами компьютера и предлагают общие службы для клиентского прикладного программного обеспечения.
Операционная система — это первая программа, которая запускается при загрузке компьютера, и, таким образом, считается наиболее важным типом системного программного обеспечения.
Операционная система запускает прикладные программы пользователей и предоставляет им подходящий интерфейс для взаимодействия с компьютерным оборудованием. Он дополнительно отвечает за выполнение других задач, включая порождение процесса, создание потоков, выделение основной памяти различным приложениям, управление хранилищем данных, управление периферийными устройствами ввода-вывода, размещение драйверов устройств и предоставление многоуровневой платформы безопасного выполнения. Корпорация Microsoft Windows и Linux — две наиболее известные операционные ь системы, которые широко используются во всех областях, связанных с компьютерами.
Microsoft Windows — это проприетарная операционная система, ориентированная на архитектуры ПК на базе Intel. На данный момент Windows является наиболее известной операционной системой на рынке, привлекающей пользователей по всему миру.
Linux — это семейство операционных систем (ОС), работающих на основе одноименного ядра. Нет одной операционной системы Linux, как, например, Windows или MacOS. Есть множество дистрибутивов (набор файлов, необходимых для установки ПО), выполняющих конкретные задачи. Кратчайшая история создания Linux. Линус Торвальдс — первый разработчик и создатель Linux. Именно в честь него и была названа ОС.
В данной статье я проведу сравнительный анализ данных операционных систем с точки зрения безопасности.
-
Модели безопасности.
Windows
Модель безопасности Windows представляет собой набор процессов пользовательского режима и режима ядра, которые обеспечивают, отслеживают и управляют различными компонентами безопасности операционной системы, а также координируют их работу. На рисунке 1 изображена модель безопасности Windows вместе с ее компонентами.
Рис. 1. Модель безопасности ОС Windows
1. Монитор обращений (SRM).
SRM — это компонент, работающий в режиме ядра, который применяет политику безопасности (c:\windows\system32\Ntoskrnl.exe) на локальном компьютере. Он защищает различные ресурсы операционной системы, выполняя защиту объектов во время выполнения, а также манипулируя привилегиями безопасности, часто известными как права пользователя.
2. Сервис проверки подлинности локальной системы безопасности (Lsass)
Lsass — это процесс в пользовательском режиме (c:\Windows \System32\Lsass.exe), который отвечает за политику безопасности локальной системы, аутентификацию пользователя и отправку сообщений аудита безопасности в журнал событий. На самом деле, Lsass реализует большинство своих функциональных возможностей в библиотеке динамических ссылок (c:\Windows\System32\Lsasrv.dll).
3. База LSA
Это база данных, содержащая параметры политики безопасности локальной системы. Эта база данных хранится в реестре под HKLM\ SECURITY. Он включает в себя следующую информацию: каким доменам доверена проверка подлинности попыток входа в систему, у кого есть разрешение на доступ к системе и каким образом (интерактивный, сетевой и служебный входы), кому какие привилегии назначены и какой аудит безопасности может быть выполнен.
4. База SAM
SAM — это комбинация сервиса и базы данных. Служба SAM представляет собой набор подпрограмм, ответственных за управление базой данных, содержащей имена пользователей и группы, определенные на локальном компьютере. Она реализована в виде библиотеки динамических ссылок (\Windows\System32\Samsrv.dll), и выполняется в процессе Lsass. С другой стороны, база данных SAM используется в системах, не функционирующих в качестве контроллеров домена, и содержит определенных локальных пользователей и группы, а также их пароли и другие атрибуты. База данных SAM хранится в реестре в разделе HKLM\SAM.
5. Active Directory
Это служба каталогов, которая содержит базу данных для хранения информации об объектах в домене. Домен — это набор компьютеров и связанных с ними групп безопасности, которые управляются как единое целое. Active Directory хранит информацию об объектах в домене, включая пользователей, группы, компьютеры, пароли и привилегии. То Сервер Active Directory реализован как \Windows\System32\Ntdsa.dll, и выполняется в процессе Lsass.
6. Служба входа в сеть (Netlogon)
Это служба Windows (\Windows\System32\Netlogon.dll) который поддерживает аутентификацию событий входа в учетную запись в домене. Он дополнительно проверяет запросы на вход в систему, а также регистрирует, аутентифицирует и обнаруживает контроллеры домена.
7. Пакеты аутентификации
Они представляют собой библиотеки динамических ссылок (DLL), которые выполняются в контексте процесса Lsass и реализуют политику проверки подлинности Windows. Библиотека DLL аутентификации отвечает за проверку соответствия данного имени пользователя и пароля, и если соответствие есть, то возвращает в Lsass информацию, детализирующую идентификационные данные безопасности пользователя. Пакеты проверки подлинности Windows включают Kerberos и MSV1_0.
8. Процесс входа в систему (Winlogon)
Это процесс в пользовательском режиме (\Windows \System32\ Winlogon.exe), который отвечает за реагирование на Lsass и за управление интерактивными сеансами входа в систему. Winlogon создает Процесс оболочки пользователя с графическим интерфейсом при входе пользователя в систему.
9. Графическая идентификация и аутентификация (GINA)
Это библиотека DLL пользовательского режима, которая запускается в процессе Winlogon и которую Winlogon использует для получения имени пользователя и пароля или PIN-кода смарт-карты. Стандартная библиотека GINA находится по адресу \Winnt\System32\Msgina.dll.
Linux
Модель безопасности Linux представляет собой набор из нескольких активных процессов, служб и библиотек, которые обеспечивают безопасную среду для работы ядра Linux. На рисунке 2 изображена модель безопасности Linux вместе с ее различными модулями.
Рис. 2. Модель безопасности Linux
1. Библиотека PAM
Библиотека подключаемых модулей аутентификации (PAM) предоставляет необходимый интерфейс и функции для разработки приложений, поддерживающих PAM. Библиотека PAM необходима для обеспечения аутентификации пользователей в операционной системе Linux.
2. Файл конфигурации PAM
Это текстовый файл, в котором системный администратор может указать, какая схема аутентификации используется для конкретного приложения. В системе Linux эта информация о конфигурации может храниться либо в файле в каталоге /etc/pam каталоге или в виде строки в файле конфигурации /etc/conf. При инициализации библиотеки PAM файл конфигурации PAM считывается таким образом, чтобы загрузить соответствующие модули аутентификации.
3. Модуль аутентификации
Это модуль, содержащий несколько процедур аутентификации, используемых для создания учетных данных аутентификации, аутентификации пользователей и предоставления привилегий аутентифицированным пользователям.
4. Модуль управления учетными записями
Он управляет учетными записями пользователей и устанавливает, разрешено ли аутентифицированному пользователю получать доступ к системе. Он создает сеанс входа в систему после успешной аутентификации и отвечает за проверку срока действия имени пользователя и / или пароля.
5. Модуль управления паролями
Он обрабатывает пароли пользователей и управляет ими, включая установку, сброс и изменение паролей. Другими словами, он устанавливает или изменяет данные пользователя.
6. Модуль управления сеансом
Он управляет началом и окончанием сеанса входа в систему. Оно также занимается созданием соответствующих записей журнала для каждого инициализированного сеанса.
-
Идентификация
Идентификатор — это метод уникальной идентификации объектов, которые выполняют действия в системе. Объектами могут быть пользователи, ресурсы, процессы, домены, локальная сеть и т. д.
Windows
SID — это числовое значение переменной длины, состоящее из номера редакции структуры SID, 48-разрядного идентификатора полномочий и переменного числа 32-разрядных вспомогательных полномочий, которые составляют фактический уникальный идентификатор объекта и относительный идентификатор (RID). На рисунке 3 показан образец SID.
Рис. 3. Схема SID Windows
Идентификатор SID состоит из следующих элементов:
— Строка SID
— Номер редакции
— Идентификатор полномочий: это номер, который указывает, кто создал или предоставил эту сторону.
— Фактический идентификатор: это уникальный идентификатор фактического объекта.
— RID: это относительный идентификатор, индекс или идентификатор для SID. 1128 RID означает, что в системе 1128SIDS уже созданы.
Каждый пользователь, группа и сетевое устройство, а также сеанс входа в систему имеют уникальный SID. Процесс Winlogon отвечает за создание уникального SID для каждого сеанса интерактивного входа в систему. SID для сеанса входа в систему обычно равен S-1–5-5–0, со случайно сгенерированным номером для RID.
Linux
Идентификация происходит по имени пользователя, которое присваивается при входе пользователя в систему. Далее пользователь идентифицируется с идентификационным номером пользователя (UID), представляющим собой числовое значение, выбранное системным администратором при создании учетной записи. Сопоставление имени пользователя с UID хранится в файле /etc/passwd и централизованно управляется NIS. Суперпользователь, также известный как root, имеет UID, равный 0. Каждый пользователь принадлежит к одной или нескольким группам. Группа отождествляется с группой идентификационного номера или сокращенно GID.
Краткие итоги проведенного сравнения.
Несмотря на разницу в именовании, обе операционные системы применяют
концепцию идентификатора для уникальной идентификации объекта с точки зрения контекста безопасности. Обе системы генерируют идентификаторы для сеанса входа в систему, пользователей и групп. Основное различие заключается в том, где каждая система хранит свои идентификаторы. В Windows SID хранятся в реестре в разделе HKLM\Security; тогда как в Linux они хранятся в файле /etc/passwd.
-
Маркеры доступа
Маркер доступа — это структура данных, которая идентифицирует контекст безопасности процесса или потока.
Windows
В операционной системе Windows информация в токене включает SID, SID групп, привилегии и DACL по умолчанию учетной записи пользователя, связанной с процессом или потоком. Когда пользователь успешно входит в систему, процесс Winlogon создает начальный токен, представляющий пользователя, и присоединяет токен к начальным процессам, которые он запускает, по умолчанию Userinit.exe процесс. Поскольку дочерние процессы по умолчанию наследуют копию токена доступа от своего создателя, все процессы в сеансе пользователя выполняются под одним и тем же токеном. Другими словами, копия токена доступа прикрепляется к каждому процесс и поток, который выполняется от имени пользователя. На рисунке 4 изображена структура данных маркера доступа в операционной системе Windows.
Рис. 4. Структура данных маркера доступа в ОС Windows
Маркер доступа Windows содержит следующие элементы:
— Идентификатор безопасности (SID) для учетной записи пользователя;
— SIDS для групп, членом которых является пользователь;
— SID аутентификации, который идентифицирует текущий сеанс входа в систему;
— Список привилегий, которыми обладает пользователь или группы пользователей;
— SID для основной группы;
— DACL по умолчанию, который система использует, когда пользователь создает защищаемый объект без указания дескриптора безопасности;
— Источник токена доступа;
— Является ли токен основным или маркером доступа;
— Необязательный список ограничивающих SIDS;
— Другая статистика.
Linux
В операционной системе Linux маркеры доступа — это объекты данных, хранящиеся в памяти и подключаемые всякий раз, когда создается новый процесс. Компонент управления сеансом обрабатывает создание и прикрепление маркера доступа при создании нового процесса или потока. На рисунке 5 представлены элементов маркера доступа в системах на базе Linux.
Рис. 5. Маркеры доступа Linux
Маркер доступа Linux содержит следующие элементы:
— его идентификатор для учетной записи пользователя;
— идентификаторы UID групп, членом которых является пользователь;
— список привилегий и прав пользователя;
— идентификатор пользователя для основной группы;
— DACL содержит записи, которые определяют, кому разрешен доступ.
Краткие итоги проведенного сравнения
Как Windows, так и Linux используют концепцию маркера доступа, но у каждого из них свой подход к ее реализации. Явное отличие заключается в том, что в отличие от Windows, которая хранит ограничения в маркере доступа, Linux использует DAC и MAC для наложения ограничений на определенный процесс. Маркер доступа Linux не имеет никаких ограничений, как в случае с Windows. Более того, Linux не хранит тип маркера доступа внутри самого маркера; скорее, в соответствии с UID система может определить, является ли этот маркер первичным или олицетворяющим типом.
-
Имперсонализация
Имперсонализация — это концепт безопасности, присущий только Windows NT, что позволяет серверному приложению временно «быть» клиентом для доступа к охраняемому объекту.
Windows
Windows использует имперсонализацию в своей модели программирования клиент/сервер. Например, серверное приложение может экспортировать ресурсы, такие как файлы, принтеры или базы данных. Клиенты, желающие получить доступ к ресурсу, отправляют запрос на сервер. Когда сервер получает запрос, он должен убедиться, что у клиента есть разрешение на выполнение желаемых операций с ресурсом. Например, если пользователь на удаленном компьютере пытается удалить файл на общем ресурсе NTFS, сервер, экспортирующий общий ресурс, должен определить, разрешено ли пользователю удалять файл. Имперсонализация позволяет серверу уведомлять SRM о том, что сервер временно принимает профиль безопасности клиента, отправляющего запрос на ресурс. Затем сервер может получать доступ к ресурсам от имени клиента, а SRM может выполнять проверки доступа. Рисунок 6 иллюстрирует механизм имперсонализации в Windows. Первый клиент 1 имеет право на доступ к файлу x. Следовательно, сервер при получении запроса от клиента 1 выдает себя за клиента 1 (заменяя токен доступа сервера токеном доступа клиента 1). Теперь сервер через свой токен доступа может распознать, что клиент 1 имеет право на доступ к файлу x, и, таким образом, разрешение предоставлено, и сервер получает доступ к файлу x.
Рис. 6. Механизм имперсонализации Windows
Linux
Два отдельных, но похожих механизма обрабатывают имперсонализацию в Linux, так называемые механизмы setUID (SUID) и setGID (SGID). Фактически, каждый исполняемый файл может быть помечен для выполнения SUID/SGID. Затем он выполняется с разрешениями владельца/группы файла, а не текущего пользователя. Как правило, определенные службы, требующие привилегий суперпользователя, заключены в программу SUID-superuser, и пользователям системы предоставляется разрешение на выполнение этой программы. Если программу можно заставить выполнить какое-либо действие, для выполнения которого она изначально не предназначалась, это может привести к серьезным нарушениям безопасности
Краткие выводы
Вид имперсонализации в обеих системах совершенно разный. В Windows сервер может заменить свой собственный доступ, полученный с помощью маркера доступа клиента, затем сервер может решить, имеет ли клиент право на доступ к определенному файлу или нет. Однако в Linux клиент выполняется в контексте безопасности сервера независимо от того, имеет ли этот клиент право выполнять данную операцию. Поэтому, если клиент в Linux не имеет права доступа к диску и подключен к серверу, который обладает полными привилегиями, клиент может легко получить доступ диск через сервер, и это может привести к серьезным нарушениям безопасности.
-
Список контроля доступа
ACL, что расшифровывается как список контроля доступа, — это список разрешений, прикрепленных к объекту, который определяет, кто к чему может получить доступ, и уровень этого доступа, который более известен как авторизация.
Windows
В Windows существует два типа списков управления доступом: Списки управления доступом DACLs и SACLs. DACL (Discretionary Access Control List)— это список разрешенных и запрещенных ACE (Access Control Entries), тогда как SACL (System Access Control List) определяет, какие операции должны регистрироваться в журнале аудита безопасности. На рисунке 7 представлено представление DACL, прикрепленное к файловому объекту.
Рис. 7. DACL
В DACL каждая запись ACE содержит SID и маску доступа. В DACL могут присутствовать четыре типа записей ACE: доступ разрешен, доступ запрещен, разрешенный объект и запрещенный объект. ACE с разрешенным доступом предоставляет доступ пользователю, а ACE с отказом в доступе отказывает в правах доступа, указанных в доступе. маска. Напротив, SACL содержит два типа ACE: System аудит ACE и доступ к объекту аудита системы. Эти ACE указать, какие операции выполняются над объектом конкретными пользователи или группы должны быть проверены. Аудиторская информация хранится в журнале аудита системы. И удачные, и неудачные попытки могут быть проверены. Рисунок 8 является примером проверки доступа. Очевидно, что пользовательскому устройству разрешено читать и записывать объект, в то время как групповым авторам запрещено чтение и запись подобных объектов.
Рис. 8. Windows DACL
Linux
Управление доступом в Linux реализовано через файл систему. Каждый файл или каталог имеет ряд атрибутов, включая имя файла, биты разрешения, UID и GID. UID файла указывает его владельца. Биты разрешения используется для указания разрешений на чтение (r), запись (w) и выполнить (x) файл для пользователя, для членов пользовательского группы и для всех остальных пользователей в системе. Например, разрешение, такое как «rwxr-x-x», указывает, что владелец может читать, записывать и выполнять действие с файлом; при этом членам группы разрешено только читать и выполнять действия, а все остальные могут только выполнять действия с файлом. Прочерк «-» в наборе разрешений указывает, что доступ запрещен. Большинство Linux современные системы также поддерживают некоторые формы схем ACL. Кроме того, каждый процесс в Linux имеет UID, а также GID. Всякий раз, когда кто-то пытается получить доступ к файлу, ядро будет использовать UID и GID процесса для сравнения их с UID и GID, связанными с файлом, чтобы решить, удовлетворять запрос или нет. В Linux есть два типа ACL: DAC и MAC. DAC, сокращенно от Discretionary Access. Владелец объекта, который обычно также и создатель объекта, имеет власть над тем, кто просто имеет доступ к объекту. Другими словами, права доступа определяются владельцем. Напротив, MAC включает в себя несколько аспектов, которые пользователь не может контролировать. Объекты помечаются метками, представляющими информацию, содержащуюся внутри.
Краткие выводы
И в Windows, и в Linux реализована концепция Access. Windows использует привилегии и ограничения для обеспечения соблюдения системных политик, таких как отказ пользователю от удаления или чтение системного файла; тогда как Linux использует обязательное управление доступом или MAC для ограничения доступа к системным объектам. Точно так же Windows использует то, что она называет System Access Control List или SACL, чтобы указать, какая операция над данный объект должна быть проверена или зарегистрирована; тогда как это концепция не реализована в Linux. Вход в Linux осуществляется самостоятельным отдельным компонентом.
-
Привилегии и
права пользователя
Привилегия — это право на выполнение операции, которое влияет на весь компьютер, а не на конкретный объект. Права пользователя, также известные как привилегии, назначают администраторов отдельными пользователями или группой в рамках настройки безопасности операционной системы.
Windows
В Windows привилегия — это право учетной записи выполнять конкретные операция, связанные с системой, например, выключение компьютера, изменение системного времени или доступ к реестру. Право учетной записи предоставляется или запрещается учетной записью, которой оно назначено. Права пользователя всегда проверяются в ответ на запросы входа в систему. С этой целью Local Security Authority (LSA) извлекает права учетной записи, назначенные данного пользователя из базы данных политик LSA вовремя, пользователь пытается войти в систему. На рис. 9 показано назначение прав пользователя в редакторе локальной политики безопасности (secpol.msc), который отображает полный список привилегий и права учетной записи, доступные для конкретной учетной записи пользователя.
Рис. 9
В Windows существует еще одна форма привилегий, она называется политикой ограниченного использования программ, которые позволяют администраторам контролировать, управлять и отключать функции установленных приложений в своих системах. На рис. 10 показано программное обеспечение редактора политики ограничений (gpedit.msc).
Рис. 10. Редактор политики ограничений программного обеспечения Windows
Linux
Linux использует обязательный контроль доступа (MAC) для принудительной привилегии. MAC включает в себя аспекты, которые пользователь не может контролировать или обычно ему не разрешается их контролировать. Объекты отмечены метками, представляющими конфиденциальность информации.
Краткие выводы
Операционная система Linux не реализует концепцию привилегии в отдельном процессе, как в Windows с использованием LSA; скорее, она использует обязательный контроль доступа или MAC для ограничения доступа к объектам системы. Кроме того, Linux не предоставляет концепцию программных ограничений; скорее, он использует отдельный демон (приложение, работающее в фоновом режиме) для выполнения конфигурации безопасности для указанного приложения.
-
Заключение
Таким образом, в данной статье были затронуты различные аспекты безопасности двух наиболее успешных коммерческих операционных систем, Microsoft Windows и Linux. Различные функции безопасности, конструкции и компоненты двух ОС были широко освещены, показывая ключевые сходства и различия между ними. На самом деле, обе ОС имеют много общих концепций и механизмов безопасности, однако зачастую они по-разному реализуются, например, объект идентификации, аутентификации пользователя, маркер доступа, контрольные списки и другие. Каждая ОС имеет свои плюсы и минусы, такие как шифрование файловой системы и программное обеспечение привилегии, которые есть у Windows и нет у Linux, и теневой пароль, который есть в Linux, а в Windows нет. Из проведенного анализа очевидно, что ОС Windows включает больше своих компонентов безопасности в ядро; в то время как Linux больше рассчитывает на процессы пользовательского режима. Кроме того, Windows использует сложные функции, такие как аудит; в то время как Linux использует менее сложные, но эффективные файлы журналов с шифрованием. В целом, обе операционные системы обеспечивают сравнительно адекватные многоуровневые технологии безопасности что делает их сертифицированными операционными системами, которые могут справиться с ситуациями подрыва безопасности, а также обеспечить безопасную среду для пользователей компьютеров.
Литература:
- Tom Carpenter, Microsoft Windows Operating System Essentials, Sybex, 2012.
- What Is Linux: An Overview of the Linux Operating System, Linux Foundation, 2009, [online] http://www.linux.com/learn/resource-center/376-linuxis-everywhere-an-overview-of-the-linux-operatingsystem.
- Chou, J. Yang, B. Chelf, S. Hallem, and D. Engler, “An empirical study of operating system errors”, In Proc. 18th ACM Symposium on Operating Systems Principles, 2001.
- William Stallings, Operating Systems: Internals and Design Principles, 7th ed, Prentice Hall, 2011.
- Moshe Bar, Linux Internals, Osborne Publishing, 2000.
- Daniel Bovet, Marco Cesati, Understanding the Linux Kernel, O’Reilly Media, 3rd ed, 2005.
Основные термины (генерируются автоматически): SID, UID, DACL, ACE, MAC, PAM, система, операционная система, пользователь, GID.
МИНИСТЕРСТВО ПО НАУКЕ И ОБРАЗОВАНИЮ РФ
ВОЛЖСКИЙ ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ (филиал) ГОУ ВПО ВОЛГО-
ГРАДСКОГО ГОСУДАРСТВЕННОГО ТЕХНИЧЕСКОГО УНИВЕРСИТЕТА
КАФЕДРА «ИНФОРМАТИКА И ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ»
Модель безопасности ОС Windows
Методические указания к лабораторным работам по
курсу «Защита информации»
Волгоград 2011
УДК 004.056
Рецензент: к.т.н., доцент каф. ВАЭ и ВТ ВПИ (филиал) ВолгГТУ Капля В.И.
МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ЛАБОРАТОРНЫМ РАБОТАМ: Модель безопас-
ности ОС Windows/ Сост. Лясин Д.Н., Саньков С.Г.; Волгоград. гос. техн. ун-т. -
Волгоград, 2011, – 24 с.
Содержатся сведения, необходимые для изучения средств обеспечения ин-
формационной безопасности в одной из самых популярных на сегодняшний день
операционных систем - Windows. Рассмотрены принципы построения архитектур
подсистемы безопасности ОС Windows, приведено описание работы систем аутен-
тификации, авторизации, аудита системы, шифрования данных с использованием
EFS. Рассмотрены различные интерфейсы работы с подсистемой безопасности:
оконный графический, консольные команды, API-функции. Задания к лабораторной
направлены на освоение обучающимися средств обеспечения безопасности ОС
Windows на практических примерах.
Предназначены для студентов, обучающихся по направлению 230100 "Ин-
форматика и вычислительная техника" и направлению 231000 "Программная инже-
нерия" всех форм обучения в рамках курса «Защита информации»
Ил. 12. Библиогр.: - 6 назв.
Издается по решению редакционно-издательского совета Волгоградского го-
сударственного технического университета
© Волгоградский государственный
технический университет, 2011
© Волжский политехнический институт, 2011
2
Лабораторная работа №6
Средства обеспечения безопасности ОС Windows
Цель: изучить модель безопасности операционной системы Windows, получить
навыки практического использования ее средств обеспечения безопасности.
1. Основные сведения
1.1. Классификация защиты семейства ОС Windows
Защита конфиденциальных данных от несанкционированного доступа является
важнейшим фактором успешного функционирования любой многопользователь-
ской системы. ОС Windows не является исключением и требования к защите объ-
ектов файловой системы, памяти, объектов ядра операционной системы внесли
существенный вклад в процесс ее проектирования и реализации.
Так, например, версии Windows NT/2000 были сертифицированы по классу С2
критериев TSSEC («Оранжевая книга»). Требования к операционной системе, за-
щищенной по классу С2, включают:
- обязательную идентификацию и аутентификацию всех пользователей опера-
ционной системы. Под этим понимается способность операционной системы иден-
тифицировать всех пользователей, которые получают санкционированный доступ к
системе, и предоставление доступа к ресурсам только этим пользователям;
- разграничительный контроль доступа — предоставление пользователям воз-
можности защиты принадлежащих им данных;
- системный аудит — способность системы вести подробный аудит всех дейст-
вий, выполняемых пользователями и самой операционной системой;
- защита объектов от повторного использования — способность системы пре-
дотвратить доступ пользователя к информации ресурсов, с которыми до этого ра-
ботал другой пользователь.
ОС Microsoft Windows XP Professional (SP2/SP3) имеет действующие сертифи-
каты ФСТЭК России и может использоваться в составе автоматизированных сис-
тем до класса защищенности 1Г включительно в соответствии с требованиями ру-
ководящего документа "Автоматизированные системы. Защита от несанкциониро-
ванного доступа к информации. Классификация автоматизированных систем и тре-
бований по защите информации" (Гостехкомиссия России, 1992).
1.2. Идентификация пользователей
Для защиты данных Windows использует следующие основные механизмы:
аутентификация и авторизация пользователей, аудит событий в системе, шифрова-
ние данных, поддержка инфраструктуры открытых ключей, встроенные средства
сетевой защиты. Эти механизмы поддерживаются такими подсистемами Windows
как LSASS (Local Security Authority Subsystem Service, подсистема локальной ау-
тентификации), SAM (Security Account Manager, диспетчер локальных записей
безопасности), SRM (Security reference Monitor, монитор состояния защиты), Active
Directory (служба каталогов), EFS (Encrypting File System, шифрующая файловая
система) и др.
3
Защита объектов и аудит действий с ними в ОС Windows организованы на
основе избирательного (дискреционного) доступа, когда права доступа (чтение, за-
пись, удаление, изменение атрибутов) субъекта к объекту задается явно в специ-
альной матрице доступа. Для укрупнения матрицы пользователи могут объеди-
няться в группы. При попытке субъекта (одного из потоков процесса, запущенного
от его имени) получить доступ к объекту указываются, какие операции пользова-
тель собирается выполнять с объектом. Если подобный тип доступа разрешен, по-
ток получает описатель (дескриптор) объекта и все потоки процесса могут выпол-
нять операции с ним. Подобная схема доступа, очевидно, требует аутентификации
каждого пользователя, получающего доступ к ресурсам и его надежную идентифи-
кацию в системе, а также механизмов описания прав пользователей и групп поль-
зователей в системе, описания и проверки дискреционных прав доступа пользова-
телей к объектам. Рассмотрим, как в ОС Windows организована аутентификация и
авторизация пользователей.
Все действующие в системе объекты (пользователи, группы, локальные ком-
пьютеры, домены) идентифицируются в Windows не по именам, уникальность ко-
торых не всегда удается достичь, а по идентификаторам защиты (Security Identi-
fiers, SID). SID представляет собой числовое значение переменной длины:
S – R – I – S0 - S1 - … - Sn – RID
S - неизменный идентификатор строкового представления SID;
R – уровень ревизии (версия). На сегодня 1.
I - (identifier-authority) идентификатор полномочий . Представляет собой 48-
битную строку, идентифицирующую компьютер или сеть, который(ая) выдал SID
объекту. Возможные значения:
- 0 (SECURITY_NULL_SID_AUTHORITY) — используются для сравнений,
когда неизвестны полномочия идентификатора;
- 1 (SECURITY_WORLD_SID_AUTHORITY) — применяются для конст-
руирования идентификаторов SID, которые представляют всех пользовате-
лей. Например, идентификатор SID для группы Everyone (Все пользовате-
ли) — это S-1-1-0;
- 2 (SECURITY_LOCAL_SID_AUTHORITY) — используются для построе-
ния идентификаторов SID, представляющих пользователей, которые вхо-
дят на локальный терминал;
- 5 (SECURITY_NT_AUTHORITY) — сама операционная система. То есть,
данный идентификатор выпущен компьютером или доменом.
Sn – 32-битные коды (колчеством 0 и более) субагентов, которым было пере-
дано право выдать SID. Значение первых подчиненных полномочий общеизвестно.
Они могут иметь значение:
- 5 — идентификаторы SID присваиваются сеансам регистрации для выдачи
прав любому приложению, запускаемому во время определенного сеанса
регистрации. У таких идентификаторов SID первые подчиненные полно-
мочия установлены как 5 и принимают форму S-1-5-5-x-y;
- 6 —когда процесс регистрируется как служба, он получает специальный
идентификатор SID в свой маркер для обозначения данного действия. Этот
4
идентификатор SID имеет подчиненные полномочия 6 и всегда будет S-1-
5-6;
- 21 (SECURITY_NT_NON_UNIQUE) — обозначают идентификатор SID
пользователя и идентификатор SID компьютера, которые не являются уни-
кальными в глобальном масштабе;
- 32 (SECURITY_BUILTIN_DOMAIN_RID) — обозначают встроенные
идентификаторы SID. Например, известный идентификатор SID для встро-
енной группы администраторов S-1-5-32-544;
- 80 (SECURITY_SERVICE_ID_BASE_RID) — обозначают идентификатор
SID, который принадлежит службе.
Остальные подчиненные полномочия идентификатора совместно обозначают
домен или компьютер, который издал идентификатор SID.
RID – 32-битный относительный идентификатор. Он является является иден-
тификатором уникального объекта безопасности в области, для которой был опре-
делен SID. Например, 500 — обозначает встроенную учетную запись Administrator,
501 — обозначает встроенную учетную запись Guest, а 502 — RID для билета на
получение билетов протокола Kerberos .
При генерации SID Windows использует генератор случайных чисел, чтобы
обеспечить уникальность SID для каждого пользователя. Для некоторого произ-
вольного пользователя SID может выглядеть так:
S-1-5-21-789336058-484763869-725345543-1003
Предопределенным пользователям и группам Windows выдает характерные
SID, состоящие из SID компьютера или домена и предопределенного RID. В таб-
лице 1 приведен перечень некоторых общеизвестных SID.
Таблица 1. Общеизвестные SID Windows
SID Название Описание
S-1-1-0 Все Группа, в которую входят все пользователи
S-1-5-2 Сеть Группа, в которую входят все пользовате-
ли, зарегистрировавшиеся в системе из се-
ти
S-1-5-7 Анонимный вход Группа, в которую входят все пользовате-
ли, вошедшие в систему анонимно
S-1-5-домен-500 Администратор Учетная запись администратора системы.
По умолчанию только эта запись обеспечи-
вает полный контроль системы
S-1-5-домен-501 Гость Учетная запись пользователя-гостя
Полный список общеизвестных SID можно посмотреть в документации
Platform SDK. Узнать SID конкретного пользователя в системе, а также SID групп,
в которые он включен, можно, используя консольную команду whoami:
whoami /user /sid
Соответствие имени пользователя и его SID можно отследить также в ключе
реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList.
5
После аутентификации пользователя процессом Winlogon, все процессы, за-
пущенные от имени этого пользователя будут идентифицироваться специальным
объектом, называемым маркером доступа (access token). Если процесс пользова-
теля запускает дочерний процесс, то его маркер наследуются, поэтому маркер дос-
тупа олицетворяет пользователя для системы в каждом запущенном от его имени
процессе. Основные элементы маркера представлены на рис. 1.
SID пользо- SID1 … SIDn DACL по Привилегии Прочие па-
вателя Идентификаторы умолчанию раметры
групп пользователя
Рисунок 1. Обобщенная структура маркера доступа.
Маркер доступа содержит идентификатор доступа самого пользователя и
всех групп, в которые он включен. В маркер включен также DACL по умолчанию -
первоначальный список прав доступа, который присоединяется к создаваемым
пользователем объектам. Еще одна важная для определения прав пользователя в
системе часть маркера – список его привилегий. Привилегии - это права доверен-
ного объекта на совершение каких-либо действий по отношению ко всей системе.
В таблице 2 перечислены некоторые привилегии, которые могут быть предостав-
лены пользователю.
Таблица 2. Привилегии, которыми могут быть наделены пользователи
Имя и идентифика- Описание привилегии
тор привилегии
Увеличение приоритета Пользователь, обладающий данной привилегией может изменять
диспетчирования приоритет диспетчирования процесса с помощью интерфейса Дис-
SeIncreaseBasePriorityPrivilege петчера задач
Закрепление страниц в Процесс получает возможность хранить данные в физической па-
памяти мяти, не прибегая к кэшированию данных в виртуальной памяти на
SeLockMemoryPrivilege диске.
Управление аудитом и Пользователь получает возможность указывать параметры аудита
журналом безопасности доступа к объекту для отдельных ресурсов, таких как файлы, объ-
SeAuditPrivilege екты Active Directory и разделы реестра.
Овладение файлами или Пользователь получает возможность становиться владельцем лю-
иными объектами бых объектов безопасности системы, включая объекты Active
SeTakeOwnershipPrivilege Directory, файлы и папки NTFS, принтеры, разделы реестра, служ-
бы, процессы и потоки
Завершение работы сис- Пользователь получает возможность завершать работу операцион-
темы ной системы на локальном компьютере
SeShutdownPrivilege
Обход перекрестной Используется для обхода проверки разрешений для промежуточ-
проверки ных каталогов при проходе многоуровневых каталогов
SeChangeNotifyPrivilege
Управление привилегиями пользователей осуществляется в оснастке
«Групповая политика», раздел Конфигурация Windows/Локальные полити-
ки/Назначение прав пользователя.
6
Чтобы посмотреть привилегии пользователя, можно также использовать
команду
whoami /all
Остальные параметры маркера носят информационный характер и опреде-
ляют, например, какая подсистема создала маркер, уникальный идентификатор
маркера, время его действия. Необходимо также отметить возможность создания
ограниченных маркеров (restricted token), которые отличаются от обычных тем, что
из них удаляются некоторые привилегии и его SID-идетификаторы проверяются
только на запрещающие правила. Создать ограниченный маркер можно программ-
но, используя API-функцию CreateRestrictedToken, а можно запустить процесс с
ограниченным маркером, используя пункт контекстного меню Windows “Запуск
от имени…” и отметив пункт “Защитить компьютер от несанкционированных
действий этой программы” (рис.2).
Рисунок 2. Запуск процесса с ограниченным маркером
Ограниченные маркеры используются для процессов, подменяющих клиен-
та и выполняющих небезопасный код.
Маркер доступа может быть создан не только при первоначальном входе
пользователя в систему. Windows предоставляет возможность запуска процессов от
имени других пользователей, создавая для этих процессов соответствующий мар-
кер. Для этих целей можно использовать:
- API-функции CreateProcessAsUser, CreateProcessWithLogon;
- оконный интерфейс (рис.2), инициализирующийся при выборе пункта кон-
текстного меню “Запуск от имени…”;
- консольную команду runas:
runas /user:имя_пользователя program ,
где имя_пользователя - имя учетной записи пользователя, которая будет использо-
вана для запуска программы в формате пользователь@домен или домен\пользова-
тель;
program – команда или программа, которая будет запущена с помощью учетной
записи, указанной в параметре /user.
7
В любом варианте запуска процесса от имени другой учетной записи необхо-
димо задать ее пароль.
1.3. Защита объектов системы.
Маркер доступа идентифицирует субъектов-пользователей системы. С другой
стороны, каждый объект системы, требующий защиты, содержит описание прав
доступа к нему пользователей. Для этих целей используется дескриптор безопас-
ности (Security Descriptor, SD). Каждому объекту системы, включая файлы, прин-
теры, сетевые службы, контейнеры Active Directory и другие, присваивается деск-
риптор безопасности, который определяет права доступа к объекту и содержит сле-
дующие основные атрибуты (рис.3):
- SID владельца, идентифицирующий учетную запись пользователя-владельца
объекта;
- пользовательский список управления доступом (Discretionary Access Control
List, DACL), который позволяет отслеживать права и ограничения, установленные
владельцем данного объекта. DACL может быть изменен пользователем, который
указан как текущий владелец объекта.
- системный список управления доступом (System Access Control List, SACL),
определяющий перечень действий над объектом, подлежащих аудиту;
- флаги, задающие атрибуты объекта.
Авторизация Windows основана на сопоставлении маркера доступа субъекта с
дескриптором безопасности объекта. Управляя свойствами объекта, администрато-
ры могут устанавливать разрешения, назначать право владения и отслеживать дос-
туп пользователей.
Версия SD
ACL
SID владельца
размер редакция
число записей SID группы
ACE [1] DACL
ACE […]
SACL
ACE [n]
Флаги Объект
ACE
Идентификатор Права Тип Механизм
безопасности доступа записи наследования
Рисунок 3. Структура дескриптора безопасности объекта Windows
Список управления доступом содержит набор элементов (Access Control En-
tries, ACE). В DACL каждый ACE состоит из четырех частей: в первой указывают-
ся пользователи или группы, к которым относится данная запись, во второй – права
доступа, а третья информирует о том, предоставляются эти права или отбираются.
Четвертая часть представляет собой набор флагов, определяющих, как данная за-
8
пись будет наследоваться вложенными объектами (актуально, например, для папок
файловой системы, разделов реестра).
Если список ACE в DACL пуст, к нему нет доступа ни у одного пользователя
(только у владельца на изменение DACL). Если отсутствует сам DACL в SD объек-
та – полный доступ к нему имеют все пользователи.
Если какой-либо поток запросил доступ к объекту, подсистема SRM осущест-
вляет проверку прав пользователя, запустившего поток, на данный объект, про-
сматривая его список DACL. Проверка осуществляется до появления разрешаю-
щих прав на все запрошенные операции. Если встретится запрещающее правило
хотя бы на одну запрошенную операцию, доступ не будет предоставлен.
Рассмотрим пример на рис.4. Процесс пытается получить доступ к объекту с
заданным DACL. В маркере процесса указаны SID запустившего его пользователя,
а также SID групп, в которые он входит. В списке DACL объекта присутствуют
разрешающие правила на чтение для пользователя с SID=100, и на запись для
группы с SID=205. Однако, в доступе пользователю будет отказано, поскольку
раньше встречается запрещающее запись правило для группы с SID=201.
запрос
Объект
R/W
Маркер
доступа SRM DACL
SID 78 W Deny
SID 100
SID 201 WX Deny
SID 201
Груп-
SID 79 RW Allow
SID 202
пы SID 100 R Allow
SID 205
SID 205 W Allow
Запрос от-
Процесс клонен!
Рисунок 4. Проверка прав доступа пользователя к объекту
Необходимо отметить, что запрещающее правило помещено в списке DACL
на рисунке не случайно. Запрещающие правила всегда размещаются перед разре-
шающими, то есть являются доминирующими при проверке прав доступа.
Для определения и просмотра прав доступа пользователей к ресурсам можно
использовать как графические средства контроля, так и консольные команды.
Стандартное окно свойств объекта файловой системы (диска, папки, файла) на
вкладке Безопасность (рис. 5) позволяет просмотреть текущие разрешения для
пользователей и групп пользователей, редактировать их, создавать новые или уда-
лять существующие.
9
Запрещающие ACE
Разрещающие ACE
Рисунок 5. GUI-интерфейс Windows для изменения прав доступа к объектам
При определении прав доступа к объектам можно задать правила их наследо-
вания в дочерних контейнерах. В окне дополнительных параметров безопасности
на вкладке Разрешения при выборе опции «Наследовать от родительского объ-
екта применимых к дочерним объектам разрешения, добавляя их к явно за-
данным в этом окне» (рис. 6) можно унаследовать разрешения и ограничения, за-
данные для родительского контейнера, текущему объекту.
При выборе опции «Заменить разрешения для всех дочерних объектов за-
данными здесь разрешениями, применимыми к дочерним объектам» разреша-
ется передача определенных для объекта-контейнера правил доступа его дочерним
Унаследовать права от
родителя
Передать права дочер-
ним объектам
Рисунок 6. Определение параметров наследования прав доступа к объектам
объектам.
В этом же окне на вкладке Владелец допустимо узнать владельца объекта и
заменить его. Владелец объекта имеет право на изменение списка его DACL, даже
если к нему запрещен любой тип доступа. Администратор имеет право становиться
владельцем любого объекта.
10
С учетом возможности вхождения пользователя в различные группы и неза-
висимости определения прав доступа к объектам для групп и пользователей, зачас-
тую бывает сложно определить конечные права пользователя на доступ к объекту:
требуется просмотреть запрещающие правила, определенные для самого объекта,
для всех групп, в которые он включен, затем то же проделать для разрешающих
правил. Автоматизировать процесс определения разрешенных пользователю видов
доступа к объекту можно с использованием вкладки «Действующие разрешения»
окна дополнительных параметров безопасности объекта (рис. 7).
Имя пользователя или
группы
Разрешения на доступ к
объекту для выбранного
пользователя или группы
Рисунок 7. Определение эффективных прав доступа пользователя (группы) к
объекту
Для просмотра и изменения прав доступа к объектам в режиме командной
строки предназначена команда cacls (icacls в Windows Vista и Widows 7).
cacls имя_файла [/t] [/e] [/c] [/g пользователь:разрешение] [/r пользователь [...]]
[/p пользователь:разрешение [...]] [/d пользователь [...]]
Назначения параметров команды приведены в таблице 3.
Таблица 3. Параметры команды cacls
Задаёт файл или папку, права доступа к которой необхо-
димо просмотреть/изменить (допустимо использовать
шаблоны с символами * и ?).
/t Изменение избирательных таблиц контроля доступа
(DACL) указанных файлов в текущем каталоге и всех под-
каталогах
/e Редактирование избирательной таблицы управления дос-
тупом (DACL) вместо ее замены
/c Заставляет команду продолжить изменение прав доступа
при возникновении ошибки, связанной с нарушениями
прав доступа
/g
/r
11
/p
/d группе
Для указания добавляемых или отнимаемых прав используются следующие
значения:
F- полный доступ;
C- изменение (запись);
W- запись;
R- чтение;
N- нет доступа.
Рассмотрим несколько примеров.
cacls d:\test
Выдаст список DACL для папки test.
cacls d:\test /d ИмяКомпьютера\ИмяПользователя /e
Запретит доступ к объекту для указанного пользователя.
cacls d:\test /p ИмяКомпьютера\ИмяГруппы:f /e /t
Предоставит полный доступ к папке d:\test и ее подпапках всем для членов
указанной группы.
Для программного просмотра и изменения списков DACL можно использо-
вать API-функции AddAccessAllowedAce, AddAccessDeniedAce, SetSecurityInfo.
Подробнее с этими функциями и примерами их использования можно ознакомить-
ся в [пособие].
1.4. Подсистема аудита.
Важный элемент политики безопасности – аудит событий в системе. ОС
Windows ведет аудит событий по 9 категориям:
1. Аудит событий входа в систему.
2. Аудит управления учетными записями.
3. Аудит доступа к службе каталогов.
4. Аудит входа в систему.
5. Аудит доступа к объектам.
6. Аудит изменения политики.
7. Аудит использования привилегий.
8. Аудит отслеживания процессов.
9. Аудит системных событий.
Рассмотрим более подробно, какие события отслеживает каждая из катего-
рий.
Аудит событий входа в систему
Аудит попыток пользователя войти в систему с другого компьютера или
выйти из нее, при условии, что этот компьютер используется для проверки под-
линности учетной записи.
12
Аудит управления учетными записями
Аудит событий, связанных с управлением учетными записями на компьюте-
ре: создание, изменение или удаление учетной записи пользователя или группы;
переименование, отключение или включение учетной записи пользователя; задание
или изменение пароля.
Аудит доступа к службе каталогов
Аудит событий доступа пользователя к объекту каталога Active Directory, для
которого задана собственная системная таблица управления доступом (SACL).
Аудит входа в систему
Аудит попыток пользователя войти в систему с компьютера или выйти из
нее.
Аудит доступа к объектам
Аудит событий доступа пользователя к объекту – например, к файлу, папке,
разделу реестра, принтеру и т. п., - для которого задана собственная системная таб-
лица управления доступом (SACL).
Аудит изменения политики
Аудит фактов изменения политик назначения прав пользователей, политик
аудита или политик доверительных отношений.
Аудит использования привилегий
Аудит попыток пользователя воспользоваться предоставленным ему правом.
Аудит отслеживания процессов
Аудиту таких событий, как активизация программы, завершение процесса,
повторение дескрипторов и косвенный доступ к объекту.
Аудит системных событий
Аудит событий перезагрузки или отключения компьютера, а также событий,
влияющих на системную безопасность или на журнал безопасности.
Решения об аудите конкретного типа событий безопасности принимаются в
соответствии с политикой аудита локальной системы. Политика аудита, также на-
зываемая локальной политикой безопасности (local security policy), является частью
политики безопасности, поддерживаемой LSASS в локальной системе, и настраи-
вается с помощью редактора локальной политики безопасности (Оснастка
gpedit.msc, Конфигурация компьютера - Конфигурация Windows – Параметры
безопасности – Локальные политики – Политика аудита, рис. 8).
13
Рисунок 8. Конфигурация политики аудита редактора локальной политики
безопасности
Для каждого объекта в SD содержится список SACL, состоящий из записей
ACE, регламентирующих запись в журнал аудита удачных или неудачных попыток
доступа к объекту. Эти АСЕ определяют, какие операции, выполняемые над объек-
тами конкретными пользователями или группами, подлежат аудиту. Информация
аудита хранится в системном журнале аудита. Аудиту могут подлежать как успеш-
ные, так и неудачные операции. Подобно записям ACE DACL, правила аудита объ-
ектов могут наследоваться дочерними объектами. Процедура наследования опре-
деляются набором флагов, являющихся частью структуры ACE.
Настройка списка SACL может быть осуществлена в окне дополнительных
свойств объекта (пункт “Дополнительно”, закладка “Аудит”, рис. 9).
записи ACE списка
SACL объекта
параметры наследования
ACE (аналогично DACL)
Рисунок 9. Интерфейс редактирования правил аудита для объекта
Для программного просмотра и изменения списков SACL можно
использовать API-функции GetSecutityInfo и SetSecutityInfo.
14
При инициализации системы и изменении политики LSASS посылает SRM
сообщения, информирующие его о текущей политике аудита. LSASS отвечает за
прием записей аудита, генерируемых на основе событий аудита от SRM, их редак-
тирование и передачу Event Logger (регистратору событий). SRM посылает записи
аудита LSASS через свое LPC-соединение. После этого Event Logger заносит запи-
си в журнал безопасности.
События аудита записываются в журналы следующих типов:
1. Журнал приложений. В журнале приложений содержатся данные, относя-
щиеся к работе приложений и программ.
2. Журнал безопасности. Журнал безопасности содержит записи о таких со-
бытиях, как успешные и безуспешные попытки доступа в систему, а также о собы-
тиях, относящихся к использованию ресурсов.
3. Журнал системы. В журнале системы содержатся события системных ком-
понентов Windows. Например, в журнале системы регистрируются сбои при за-
грузке драйвера или других системных компонентов при запуске системы.
4. Журнал службы каталогов. В журнале службы каталогов содержатся со-
бытия, заносимые службой каталогов Windows (на контроллере домена AD).
5. Журнал службы репликации. В журнале службы репликации файлов со-
держатся события, заносимые службой репликации файлов Windows (на контрол-
лере домена AD).
Просмотр журнала безопасности осуществляется в оснастке «Просмотр со-
бытий» (eventvwr.msc, рис. 10). Сами журналы хранятся в файлах SysEvent.evt,
SecEvent.evt, AppEvent.evt в папке %WinDir%\system32\config.
Предупреждающее
сообщение
Сообщение об
ошибке
Информационное
сообщение
Рисунок 10. Оснастка Windows «Просмотр событий»
В журнал записываются события 3 основных видов:
1. Информационные сообщения о событиях.
Описывают успешное выполнение операций, таких как запуск или некоторое
действие системной службы.
2. Предупреждающие сообщения о событиях.
Описывают неожиданные действия, означающие проблему, или указывают
на проблему, которая возникнет в будущем, если не будет устранена сейчас .
3. Сообщения о событиях ошибок.
15
Описывают ошибки, возникшие из-за неудачного выполнения задач.
1.5. Шифрующая файловая система.
Начиная с версии Windows 2000, в операционных системах семейства
Windows NT поддерживается шифрование данных на разделах файловой системы
NTFS с использованием шифрующей файловой системы (Encrypted File System,
EFS). Основное ее достоинст во заключается в обеспечении конфиденциальности
данных на дисках компьютера за счет использования надежных симметричных ал-
горитмов для шифрования данных в реальном режиме времени.
Для шифрации данных EFS использует симметричный алгоритм шифрования
(AES или DESX) со случайным ключом для каждого файла (File Encryption Key,
FEK). По умолчанию данные шифруются в Windows 2000 и Windows XP по алго-
ритму DESX, а в Windows XP с Service Pack 1 (или выше) и Windows Server 2003
— по алгоритму AES. В версиях Windows, разрешенных к экспорту за пределы
США, драйвер EFS реализует 56-битный ключ шифрования DESX, тогда как в вер-
сии, подлежащей использованию только в США, и в версиях с пакетом для 128-
битного шифрования длина ключа DESX равна 128 битам. Алгоритм AES в
Windows использует 256-битные ключи.
При этом для обеспечения секретности самого ключа FEK шифруется асим-
метричным алгоритмом RSA открытым ключом пользователя, результат шифрации
FEK – Data Decryption Field, DDF – добавляется в заголовок зашифрованного
файла (рис. 11). Такой подход обеспечивает надежное шифрование без потери эф-
фективности процесса шифрования: данные шифруются быстрым симметричным
алгоритмом, а для гарантии секретности симметричного ключа используется асим-
метричный алгоритм шифрования.
Файл, зашифро-
Открытый ключ ванный EFS
пользователя (RSA) FEK
DDF
Зашифрован-
ный файл
Шифрование данных
(DESX или AES)
Файл на диске
FEK
DRF
Открытый ключ аген-
та восстановления
RSA)
Рисунок 11. Схема шифрации файла в EFS
16
Для шифрации файлов с использованием EFS можно использовать графиче-
ский интерфейс или команду cipher.
Графический интерфейс доступен в стандартном окне свойств объекта по
нажатию кнопки «Дополнительно» (рис. 12). Зашифрованные объекты в стан-
дартном интерфейсе Windows Explorer отображаются зеленым цветом.
Рисунок 12. Графический интерфейс шифрования файла с использованием EFS
Необходимо отметить, что EFS позволяет разделять зашифрованный файл
между несколькими пользователями. В этом случае FEK шифруется открытыми
ключами всех пользователей, которым разрешен доступ к файлу, и каждый резуль-
тат шифрации добавляется в DDF.
Шифрование файла с использованием EFS защищает файл комплексно: поль-
зователю, не имеющему права на дешифрацию файла, недопустимы, в том числе,
такие операции, как удаление, переименование и копирование файла. Необходимо
помнить, что EFS является частью файловой системы NTFS, и в случае копирова-
ния защищенного файла авторизованным пользователем на другой том с файловой
системой, на поддерживающей EFS (например, FAT32), он будет дешифрован и
сохранен на целевом томе в открытом виде.
Консольная команда cipher может быть использована для шифра-
ции/дешифрации файлов из командной строки или в bat-сценарии.
cipher [{/e|/d}] [/s:каталог] [/a] [/i] [/f] [/q] [/h] [/k] [/u[/n]] [путь [...]] |
[/r:имя_файла_без_расширения]
Назначения параметров команды приведены в таблице 4.
Таблица 4. Параметры команды cipher
/e Шифрует указанные папки. Папки помечаются таким образом, что-
бы файлы, которые будут добавляться в папку позже, также шифро-
вались.
/d Расшифровывает указанные папки. Папки помечаются таким обра-
зом, чтобы файлы, которые будут добавляться в папку позже, не бу-
дут шифроваться
/s: каталог Выполняет выбранную операцию над указанной папкой и всеми
подпапками в ней.
/a Выполняет операцию над файлами и каталогами
/i Продолжение выполнения указанной операции даже после возник-
17
новения ошибок. По умолчанию выполнение cipher прекращается
после возникновения ошибки
/f Выполнение повторного шифрования или расшифровывания ука-
занных объектов. По умолчанию уже зашифрованные или расшиф-
рованные файлы пропускаются командой cipher
/k Создание ключа шифрования файла для пользователя, выполнивше-
го команду cipher. Если используется данный параметр, все осталь-
ные параметры команды cipher не учитываются.
/u Обновление ключа шифрования файла пользователя или ключа
агента восстановления на текущие ключи во всех зашифрованных
файлах на локальном диске (если эти ключи были изменены). Этот
параметр используется только вместе с параметром /n.
/n Запрещение обновления ключей. Данный параметр служит для по-
иска всех зашифрованных файлов на локальных дисках. Этот пара-
метр используется только вместе с параметром /u.
путь Указывает шаблон, файл или папку.
/r: имя_файла Создание нового сертификата агента восстановления и закрытого
ключа с последующей их записью в файлах с именем, указанным в
параметре имя_файла (без расширения). Если используется данный
параметр, все остальные параметры команды cipher не учитывают-
ся.
Например, чтобы определить, зашифрована ли какая-либо папка, необходимо
использовать команду:
cipher путь\имя_папки
Команда cipher без параметров выводит статус (зашифрован или нет) для
всех объектов текущей папки.
Для шифрации файла необходимо использовать команду
cipher /e /a путь\имя_файла
Для дешифрации файла, соответственно, используется команда
cipher /d /a путь\имя_файла
Допустима шифрация/дешифрация группы файлов по шаблону:
cipher /e /a d:\work\*.doc
Пара открытый и закрытый ключ для шифрации FEK создаются для пользо-
вателя автоматически при первой шифрации файла с использованием EFS.
Если некоторый пользователь или группа пользователей зашифровали файл с
использованием EFS, то его содержимое доступно только им. Это приводит к рис-
кам утери доступа к данным в зашифрованных файлах в случае утраты пароля дан-
ным пользователем (работник забыл пароль, уволился и т.п.). Для предотвращения
подобных проблем администратор может определить некоторые учетные записи в
качестве агентов восстановления.
Агенты восстановления (Recovery Agents) определяются в политике безо-
пасности Encrypted Data Recovery Agents (Агенты восстановления шифрован-
18
ных данных) на локальном компьютере или в домене. Эта политика доступна че-
рез оснастку Групповая политика (gpedit.msc) раздел «Параметры безопасно-
сти»-> «Политика открытого ключа»-> «Файловая система EFS». Пункт меню
«Действие»-> «Добавить агент восстановления данных» открывает мастер до-
бавления нового агента.
Добавляя агентов восстановления можно указать, какие криптографические
пары (обозначенные их сертификатами) могут использовать эти агенты для восста-
новления шифрованных данных (рис. 13). Сертификаты для агентов восстановле-
ния создаются командой cipher с ключом /r (см. табл. 4). Для пользователя, кото-
рый будет агентом восстановления, необходимо импортировать закрытый ключ
агента восстановления из сертификата, созданного командой cipher. Это можно
сделать в маcтере импорта сертификатов, который автоматически загружается при
двойном щелчке по файлу *.pfx.
Рисунок 13. Добавление нового агента восстановления EFS
EFS создает – DRF (Data Recovery Field)-элементы ключей для каждого
агента восстановления, используя провайдер криптографических сервисов, зареги-
стрированный для EFS-восстановления. DRF добавляется в зашифрованный файл и
может быть использован как альтернативное средство извлечения FEK для дешиф-
рации содержимого файла.
Windows хранит закрытые ключи в подкаталоге Application Data\Micro-
soft\Crypto\RSA каталога профиля пользователя. Для защиты закрытых ключей
Windows шифрует все файлы в папке RSA на основе симметричного ключа, гене-
рируемого случайным образом; такой ключ называется мастер-ключом пользова-
теля. Мастер-ключ имеет длину в 64 байта и создается стойким генератором слу-
чайных чисел. Мастер-ключ также хранится в профиле пользователя в каталоге
Application Data\Microsoft\Protect и зашифровывается по алгоритму 3DES с помо-
щью ключа, который отчасти основан на пароле пользователя. Когда пользователь
19
меняет свой пароль, мастер-ключи автоматически расшифровываются, а затем за-
ново зашифровываются с учетом нового пароля.
Для расшифровки FEK EFS использует функции Microsoft CryptoAPl (CAPI).
CryptoAPI состоит из DLL провайдеров криптографических сервисов (cryptographic
service providers, CSP), которые обеспечивают приложениям доступ к различным
криптографическим сервисам (шифрованию, дешифрованию и хэшированию). EFS
опирается на алгоритмы шифрования RSA, предоставляемые провайдером
Microsoft Enhanced Cryptographic Provider (\Windows\ System32\Rsaenh.dll).
Шифрацию и дешифрацию файлов можно осуществлять программно, ис-
пользуя API-функции EncryptFile и DecryptFile.
2. Порядок выполнения работы.
2.1. Ознакомьтесь с теоретическими основами защиты информации в ОС се-
мейства Windows в настоящих указаниях и конспектах лекций.
2.2. Выполните задания 2.2.1-2.2.8
2.2.1. Запустите в программе Oracle VM Virtualbox виртуальную ма-
шину WinXP. Войдите в систему под учетной записью администратора, пароль уз-
найте у преподавателя. Все действия в пп 2.2.1-2.2.8 выполняйте в системе, рабо-
тающей на виртуальной машине.
2.2.2. Создайте учетную запись нового пользователя testUser в оснаст-
ке «Управление компьютером» (compmgmt.msc). При создании новой учетной
записи запретите пользователю смену пароля и снимите ограничение на срок дей-
ствия его пароля. Создайте новую группу ”testGroup” и включите в нее нового
пользователя. Удалите пользователя из других групп. Создайте на диске С: папку
forTesting. Создайте или скопируйте в эту папку несколько текстовых файлов
(*.txt).
2.2.3. С помощью команды runas запустите сеанс командной строки
(cmd.exe) от имени вновь созданного пользователя. Командой whoami посмотрите
SID пользователя и всех его групп, а также текущие привилегии пользователя.
Строку запуска и результат работы этой и всех следующих консольных команд
копируйте в файл протокола лабораторной работы.
2.2.4. Убедитесь в соответствии имени пользователя и полученного SID
в реестре Windows. Найдите в реестре, какому пользователю в системе присвоен
SID S-1-5-21-1957994488-492894223-170857768-1004 (Используйте ключ реестра
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList).
2.2.5. Командой whoami определите перечень текущих привилегий
пользователя testUser. В сеансе командной строки пользователя попробуйте изме-
нить системное время командой time. Чтобы предоставить пользователю подобную
привилегию, запустите оснастку «Локальные параметры безопасности»
(secpol.msc). Добавьте пользователя в список параметров политики «Изменение
системного времени» раздела Локальные политики -> Назначение прав поль-
зователя. После этого перезапустите сеанс командной строки от имени пользова-
20
теля, убедитесь, что в списке привилегий добавилась SeSystemtimePriviege. По-
пробуйте изменить системное время командой time.
Убедитесь, что привилегия «Завершение работы системы»
(SeShutdownPrivilege) предоставлена пользователю testUser . После этого попро-
буйте завершить работу системы из сеанса командной строки пользователя коман-
дой shutdown –s. Добавть ему привелегию «Принудительное удаленное завер-
шение» (SeRemoteShutdownPrivilege). Попробуйте завершить работу консольной
командой еще раз (отменить команду завершения до ее непосредственного выпол-
нения можно командой shutdown –a).
2.2.6. Ознакомьтесь с справкой по консольной команде cacls. Используя эту
команду, просмотрите разрешения на папку c:\forTesting. Объясните все обозначе-
ния в описаниях прав пользователей и групп в выдаче команды.
а) Разрешите пользователю testUser запись в папку forTesting, но запретите
запись для группы testGroup. Попробуйте записать файлы или папки в forTesting
от имени пользователя testUser. Объясните результат. Посмотрите эффективные
разрешения пользователя testUser к папке forTesting в окне свойств папки.
б) Используя стандартное окно свойств папки, задайте для пользователя
testUser такие права доступа к папке, чтобы он мог записывать информацию в пап-
ку forTesting, но не мог просматривать ее содержимое. Проверьте, что папка
forTesting является теперь для пользователя testUser “слепой”, запустив, напри-
мер, от его имени файловый менеджер и попробовав записать файлы в папку, про-
смотреть ее содержимое, удалить файл из папки.
в) Для вложенной папки forTesting\Docs отмените наследование ACL от
родителя и разрешите пользователю просмотр, чтение и запись в папку. Проверьте,
что для пользователя папка forTesting\Docs перестала быть “слепой” (например,
сделайте ее текущей в сеансе работы файлового менеджера от имени пользователя
и создайте в ней новый файл).
г) Снимите запрет на чтение папки forTesting для пользователя testUser.
Используя команду cacls запретите этому пользователю доступ к файлам с расши-
рением txt в папке forTesting. Убедитесь в недоступности файлов для пользовате-
ля.
д) Командой cacls запретите пользователю все права на доступ к папке
forTesting и разреште полный доступ к вложенной папке forTesting\Docs. Убеди-
тесь в доступности папки forTesting\Docs для пользователя. Удалите у пользовате-
ля testUser привилегию SeChangeNotifyPrivilege. Попробуйте получить доступ к
папке forTesting\Docs. Объясните результат.
е) Запустите файловый менеджер от имени пользователя testUser и создайте
в нем папку newFolder на диске C. Для папки newFolder очистите весь список
ACL командой cacls. Попробуйте теперь получить доступ к папке от имени адми-
нистратора и от имени пользователя. Кто и как теперь может вернуть доступ к пап-
ке? Верните полный доступ к папке для всех пользователей.
ж) Создайте в разделе HKLM\Software реестра раздел testKey. Запретите
пользователю testUser создание новых разделов в этом разделе реестра. Создайте
для раздела HKLM\Software\testKey SACL, позволяющий протоколировать отка-
зы при создании новых подразделов, а также успехи при перечислении подразде-
лов и запросе значений (предварительно проверьте, что в локальной политике
21
безопасности соответствующий тип аудита включен). Попробуйте от имени поль-
зователя testUser запустить regedit.exe и создать раздел в HKLM\Software. Убеди-
тесь, что записи аудита были размещены в журнале безопасности (eventvwr.msc).
2.2.7. Шифрование файлов и папок средствами EFS.
а) От имени пользователя testUser зашифруйте какой-нибудь файл на диске.
Убедитесь, что после этого был создан сертификат пользователя, запустив оснаст-
ку certmgr.msc от имени пользователя (раздел Личные). Просмотрите основные
параметры сертификата открытого ключа пользователя testUser (срок действия,
используемые алгоритмы). Установите доверие к этому сертификату в вашей сис-
теме.
б) Создайте в папке forTesting новую папку Encrypt. В папке Encrypt соз-
дайте или скопируйте в нее текстовый файл. Зашифруйте папку Encrypt и все ее
содержимое из меню свойств папки от имени администратора. Попробуйте про-
смотреть или скопировать какой-нибудь файл этой папки от имени пользователя
testUser. Объясните результат. Скопируйте зашифрованный файл в незашифро-
ванную папку (например, forTesting). Убедитесь что он остался зашифрованным.
Добавьте пользователя testUser в список имеющих доступа к файлу пользователей
в окне свойств шифрования файла. Повторите попытку получить доступ к файлу от
имени пользователя testUser.
в) Создайте учетную запись нового пользователя agentUser, сделайте его
членом группы Администраторы. Определите для пользователя agentUser роль
агента восстановления EFS. Создайте в папке forTesting новый текстовый файл с
произвольным содержимым. Зашифруйте этот файл от имени пользователя
testUser. Убедитесь в окне подробностей шифрования файла, что пользователь
agentUser является агентом восстановления для данного файла. Попробуйте про-
читать содержимое файла от имени администратора и от имени пользователя
agentUser. Объясните результат.
г) Зашифруйте все текстовые файлы папки forTesting с использованием кон-
сольной команды шифрования cipher от имени пользователя testUser (предвари-
тельно снимите запрет на доступ к этим файлам, установленный в задании 2.2.6г).
д) Убедитесь, что при копировании зашифрованных файлов на том с файло-
вой системой, не поддерживающей EFS (например, FAT32 на флеш-накопителе),
содержимое файла дешифруется.
2.2.8. После демонстрации результатов работы преподавателю восстановите
исходное состояние системы: удалите созданные папки и файлы, разделы реестра,
удалите учетную запись созданного пользователя и его группы, снимите с пользо-
вателя agentUser роль агента восстановления.
2.2.9. Представьте отчёт по лабораторной работе преподавателю и отчитайте
работу.
2.3. Содержание отчета
Отчет по лабораторной работе должен содержать следующие сведения:
- название и цель работы;
- протокол выполнения лабораторной работы, содержащий список кон-
сольных команд, составленных при выполнении работы, и результаты их
выполнения.
22
3. Контрольные вопросы
1. К какому классу безопасности относится ОС Windows по различным
критериям оценки?
2. Каким образом пользователи идентифицируются в ОС Windows?
3. Что такое списки DACL и SACL?
4. Перечислите, каким образом можно запустить процесс от имени друго-
го пользователя.
5. Как происходит проверка прав доступа пользователя к ресурсам в ОС
Windows?
6. Что такое маркер безопасности, и какова его роль в модели безопасно-
сти Windows?
7. Как с использованием команды cacls добавить права на запись для всех
файлов заданной папки?
8. Какие события подлежат аудиту в ОС Windows?
9. Каким образом шифруются файлы в файловой системе EFS? Что такое
FEK? DDF? DDR?
10. Какие алгоритмы шифрования используются в EFS?
4. Л и т е р а т у р а
1. Соломон, Руссинович. Внутреннее устройство Microsoft Windows: Windows
Server 2003, Windows XP и Windows 2000. 4-е издание, СПб.: Питер, 2008., 992 с.
2. А. Чекмарев, А. Вишневский, О. Кокорева Microsoft Windows Server 2003.
Русская версия. Наиболее полное руководство. , СПб.: БХВ-Петербург, 2008 г.,
1120 с.
3. Лясин Д.Н., Саньков С.Г. Методы и средства защиты компьютерной ин-
формации (учебное пособие). – Волгоград, Издательство ВолгГТУ РПК "Политех-
ник”, 2005г.
4. У. Р. Станек. Командная строка Microsoft Windows. Справочник админист-
ратора. М.: Русская редакция, 2009., 480с.
5. Безопасность Windows Server 2003 в библиотеке Microsoft TechNet.
http://technet.microsoft.com/ru-ru/library/dd548350%28WS.10%29.aspx
23
Дмитрий Николаевич Лясин
Сергей Геннадиевич Саньков
Модель безопасности ОС Windows. Методические указания к лабораторным рабо-
там по курсу «Защита информации».
План выпуска электронных изданий 2011г., поз. N___
Подписано “На выпуск в свет ______”. Уч. -изд.л.
На магнитном носителе.
Волгоградский государственный технический университет.
400131 Волгоград , пр. Ленина , 28.
24
Введение
Спросите любого эксперта, занимающегося анализом вредоносного кода под Windows, с какими системными привилегиями работает и к каким стремится вредоносное ПО? Он ответит, не задумываясь, – права Администратора. Существуют ли исследования, способные это подтвердить? К сожалению, мне не удалось найти какой-либо внятной аналитики по данному вопросу, однако, никогда не поздно побыть в роли Капитана Очевидность и предоставить факты на суд общественности.
Я не ставил своей целью сделать обзор техник повышения привилегий в системе, таких статей полно в сети. Каждый год находятся новые механизмы, и каждая техника заслуживает отдельного обзора. В этот раз мне захотелось взглянуть на картину в целом, на всём многообразии линейки ОС Windows начиная с Windows Vista и без разбиения на конкретные операционные системы.
Небольшой экскурс в историю
Модель безопасности операционной системы Windows XP существенно отличается от модели безопасности операционной системы Windows Vista и выше. В Windows XP существуют две учётные записи пользователей: стандартная и учётная запись администратора. Подавляющее большинство пользователей работали с правами администратора, даже несмотря на то, что для решения повседневных задач эти права им не требовались. Они заражались вредоносным ПО, которое получало права текущего пользователя и, чаще всего, это были именно права администратора системы. Таким образом, у вредоносного ПО не было серьёзных проблем с получением повышенных привилегий в системе под управлением Windows XP.
Такой механизм существовал вплоть до появления семейства Windows Vista в котором Microsoft представила новую модель безопасности – механизм целостности Windows.
Integrity Level в Windows 10
Грубо говоря, в новом механизме также существуют две вышеперечисленные учётные записи пользователей, однако, теперь операционная система работает в режиме одобрения администратором. Да-да, это тот самый всеми «любимый» UAC (User Access Control). Как только требуются повышенные привилегии, возникает диалог UAC, спрашивающий у пользователя разрешения на совершение определённого действия.
Человеческий фактор – одна из основных проблем безопасности, поэтому возложение ответственности на пользователя, не обладающего минимально базовыми знаниями компьютерной безопасности, – это как минимум спорное решение. Сама компания Microsoft говорит по этому поводу следующее: «One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed». Интересующимся позицией Microsoft я рекомендую ознакомиться со следующими материалами: User Account Control, User Account Control (UAC) – quick update, Update on UAC.
Механизм целостности Windows
Новый механизм целостности Windows является основным компонентом защиты архитектуры безопасности Windows. Он ограничивает права доступа для приложений, работающих под управлением той же учётной записи, но при это являющимися менее надёжными. Проще говоря, этот механизм присваивает уровень целостности процессам, а также другим защищаемым объектам в ОС Windows. Уровень целостности ограничивает или предоставляет права доступа одних объектов к другим.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// // Mandatory Label Authority. // #define SECURITY_MANDATORY_LABEL_AUTHORITY {0,0,0,0,0,16} #define SECURITY_MANDATORY_UNTRUSTED_RID (0x00000000L) #define SECURITY_MANDATORY_LOW_RID (0x00001000L) #define SECURITY_MANDATORY_MEDIUM_RID (0x00002000L) #define SECURITY_MANDATORY_MEDIUM_PLUS_RID (SECURITY_MANDATORY_MEDIUM_RID + 0x100) #define SECURITY_MANDATORY_HIGH_RID (0x00003000L) #define SECURITY_MANDATORY_SYSTEM_RID (0x00004000L) #define SECURITY_MANDATORY_PROTECTED_PROCESS_RID (0x00005000L) // // SECURITY_MANDATORY_MAXIMUM_USER_RID is the highest RID that // can be set by a usermode caller. // #define SECURITY_MANDATORY_MAXIMUM_USER_RID SECURITY_MANDATORY_SYSTEM_RID |
Не буду вдаваться в детали работы механизма целостности. Для упрощения трактовки собранной статистики нам понадобится всего лишь одна таблица — это таблица связи уровня целостности с идентификатором безопасности SID (см. таблицу 7), который идентифицирует учётную запись пользователя, группы, домена или компьютера в Windows.
| SID в маркере доступа | Присвоенный уровень целостности |
| LocalSystem | System |
| LocalService | System |
| NetworkService | System |
| Administrators | High |
| Backup Operators | High |
| Network Configuration Operators | High |
| Cryptographic Operators | High |
| Authenticated Users | Medium |
| Everyone (World) | Low |
| Anonymous | Untrusted |
Большинство приложений, запущенных стандартным пользователем, получают средний уровень целостности. Администраторы – высокий (high), сервисы и ядро – системный (system). Низкий (low) уровень доступа будет, например, у приложения-контейнера – с таким уровнем целостности обычно работают современные браузеры, защищая операционную систему от возможного проникновения вредоносного кода со стороны вредоносных сайтов.
Одним словом, high и выше – это тот уровень привилегий к которому стремится вредоносное ПО.
Ложь, наглая ложь и статистика
Современные антивирусные продукты реализуют комплексный подход к безопасности. Поэтому в них используются десятки компонент, предотвращающих попадание вредоносного кода в систему на различных этапах. Это и веб-антивирусы, и эмуляторы скриптов, и облачные сигнатуры, и детекторы эксплойтов, и многое другое. Данные, попадающие в систему, проходят через многочисленные проверки различными компонентами антивирусного продукта. В результате гигантское количество вредоносного ПО не доходит до стадии исполнения и детектируется «на взлёте». Меня же интересовало то, которое всё-таки дошло до исполнения в системе. При этом современный антивирусный продукт продолжает следить за потенциально вредоносным объектом, ведь даже в случае его исполнения могут сработать поведенческие сигнатуры (BSS) компонента Kaspersky System Watcher.
Поэтому я попросил нашу команду Эвристического Детектирования помочь мне собрать статистику об уровне системных привилегий, с которыми исполняется активное вредоносное ПО, детектируемое с помощью поведенческих сигнатур.
С помощью Kaspersky Security Network за 15 дней работы мне удалось собрать данные о примерно полутора миллионах срабатываний. В эту статистику попала вся линейка ОС Windows, начиная с Vista и заканчивая Windows 10. Отфильтровав часть событий, оставив лишь уникальные, а также не содержащие наших тестовых сигнатур, я получил около 976 тысяч срабатываний. Давайте посмотрим на распределение уровней целостности среди активного вредоносного ПО за это время.
Распределение уровней целостности
Сложив Untrusted, Low и Medium, а также High и System можно получить процентное соотношение, которое я назвал «Нормально к Очень плохо». Хотя, как мне кажется, авторы вредоносного кода не сочли бы такое соотношение плохим.
Соотношение «Нормально к Очень плохо»
Выводы
В чём же причина такой ужасающей статистики? Честно говоря, сказать точно пока нельзя, необходимо более глубокое исследование. Конечно же, вирусописатели используют различные способы повышения привилегий: автоэлевация и обход механизма UAC, уязвимости в Windows и стороннем ПО, социальная инженерия и так далее. Существует ненулевая вероятность того, что у многих пользователей и вовсе отключён UAC, который их раздражает. Однако очевидно то, что у создателей вредоносного ПО не возникает проблем с получением повышенных привилегий в Windows, а соответственно защита от угроз должна создаваться с учётом этой проблемы.
Из продуктов
Microsoft более защищенными являются ОС
Windows NT, Windows 2000 Server и Windows 2003 Server. Большие
возможности для гибкой настройки защиты
имеются во FreeBSD и Linux.
В
сетевой операционной системе Windows
существует единая система для
идентификации, проверки подлинности
(аутентификации), контроля (разграничения)
доступа и записи информации о событиях
(аудита), связанных с безопасностью. В
рамках данной архитектуры все объекты
и все процессы подчиняются требованиям
системы безопасности, включающей в себя
несколько основных компонентов (рис.
5.5.).
Структурная схема
системы безопасности Windows
1я слева стрелка
– правило безопасности
2 стрелка(правая)
– записи аудита
Процессы
входа в систему
обрабатывают запросы пользователей о
входе в систему. Сюда включается начальный
интерактивный
вход в систему
через диалоговое окно входа пользователя
и процессы удаленного
входа,
открывающие доступ к серверу Windows
с удаленных компьютеров. Вход в систему
обязателен для работы с сервером или
рабочей станцией Windows
2000/2003.
Центральная
часть системы безопасности Windows
— Локальный
администратор безопасности
(Local
Security
Authority,
LSA)
— проверяет, есть ли у пользователя
необходимые полномочия для входа в
систему. Этот компонент создает маркеры
доступа, управляет локальными правилами
безопасности,
обеспечивает службы интерактивной
проверки подлинности, а также контролирует
правила аудита и записывает в журнал
аудита сообщения, полученные от
Монитора безопасности.
Диспетчер
учетных
записей
(Security
Account
Manager,
SAM)
поддерживает базу
данных учетных записей.
В ней хранятся все учетные записи
пользователей и групп. Эта база является
частью реестра операционной системы и
недоступна обычным пользователям в
ходе нормальной работы, обеспечивает
службы подтверждения подлинности
пользователя, используемые администратором
локальной безопасности.
Монитор
безопасности
(Security
Reference
Monitor,
SRM)
проверяет, имеет ли пользователь
достаточные права для доступа к объекту.
Он работает в режиме ядра. Компоненты
ядра и пользовательские процессы
обращаются к Монитору безопасности,
чтобы выяснить, имеют ли право пользователи
и процессы получить доступ к объекту.
SRM
хранит в себе весь код, ответственный
за подтверждение доступа, и это
единственная копия данного кода для
любой системы Windows.
Благодаря этому все проверки выполняются
одинаково для всех объектов в системе.
Журнал
аудита
(Security
log)
содержит записи о событиях, связанных
с работой системы безопасности. Сюда
заноситься информация о входах
пользователей, изменениях в базе учетных
записи и системной политике, событиях
доступа пользователей к секретам файлам.
Пакет
проверки подлинности
(Authentication
package)
проверяет
подлинность
пользователя. Windows
по умолчанию использует текст проверки
подлинности MSV1_0,
но эта операционная система может
поддерживать несколько таких пакетов,
выполненных как динамические библиотеки
DLL.
Таким образом независимые поставщики
программного обеспечения могут включать
в Windows
свои модули проверки подлинности.
В
рамках архитектуры системы безопасности
Windows
реализованы новые подходы к проверке
подлинности пользователя и защиты
данных:
1 полное
интегрирование с активным каталогом
Windows
— для обеспечения масштабируемого
управления учетными записями в больших
доменах с гибким контролем доступа и
распределением административных
полномочий;
2
протокол проверки подлинности Kerberos
версии 5 —стандарт безопасности для
Internet,
реализуемый как основной протокол
проверки подлинности сетевого входа;
3 усиленная проверка
подлинности с применением сертификатов,
основанных на открытых ключах;
4
безопасные сетевые каналы, основанные
на стандарте SSL;
5 файловая система
с шифрованием.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Модель безопасности ОС Windows
Лабораторная работа № ___
Средства обеспечения безопасности ОС Windows
Цель: изучить модель безопасности операционной системы Windows, получить навыки практического использования ее средств обеспечения безопасности.
- Основные сведения
- Классификация защиты семейства ОС Windows
Защита конфиденциальных данных от несанкционированного доступа является важнейшим фактором успешного функционирования любой многопользовательской системы. ОС Windows не является исключением и требования к защите объектов файловой системы, памяти, объектов ядра операционной системы внесли существенный вклад в процесс ее проектирования и реализации.
Так, например, версии Windows NT/2000 были сертифицированы по классу С2 критериев TSSEC («Оранжевая книга»). Требования к операционной системе, защищенной по классу С2, включают:
— обязательную идентификацию и аутентификацию всех пользователей операционной системы. Под этим понимается способность операционной системы идентифицировать всех пользователей, которые получают санкционированный доступ к системе, и предоставление доступа к ресурсам только этим пользователям;
— разграничительный контроль доступа — предоставление пользователям возможности защиты принадлежащих им данных;
— системный аудит — способность системы вести подробный аудит всех действий, выполняемых пользователями и самой операционной системой;
— защита объектов от повторного использования — способность системы предотвратить доступ пользователя к информации ресурсов, с которыми до этого работал другой пользователь.
ОС Microsoft Windows XP Professional (SP2/SP3) имеет действующие сертификаты ФСТЭК России и может использоваться в составе автоматизированных систем до класса защищенности 1Г включительно в соответствии с требованиями руководящего документа «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требований по защите информации» (Гостехкомиссия России, 1992).
1.2. Идентификация пользователей
Для защиты данных Windows использует следующие основные механизмы: аутентификация и авторизация пользователей, аудит событий в системе, шифрование данных, поддержка инфраструктуры открытых ключей, встроенные средства сетевой защиты. Эти механизмы поддерживаются такими подсистемами Windows как LSASS (Local Security Authority Subsystem Service, подсистема локальной аутентификации), SAM (Security Account Manager, диспетчер локальных записей безопасности), SRM (Security reference Monitor, монитор состояния защиты), Active Directory (служба каталогов), EFS (Encrypting File System, шифрующая файловая система) и др.
Защита объектов и аудит действий с ними в ОС Windows организованы на основе избирательного (дискреционного) доступа, когда права доступа (чтение, запись, удаление, изменение атрибутов) субъекта к объекту задается явно в специальной матрице доступа. Для укрупнения матрицы пользователи могут объединяться в группы. При попытке субъекта (одного из потоков процесса, запущенного от его имени) получить доступ к объекту указываются, какие операции пользователь собирается выполнять с объектом. Если подобный тип доступа разрешен, поток получает описатель (дескриптор) объекта и все потоки процесса могут выполнять операции с ним. Подобная схема доступа, очевидно, требует аутентификации каждого пользователя, получающего доступ к ресурсам и его надежную идентификацию в системе, а также механизмов описания прав пользователей и групп пользователей в системе, описания и проверки дискреционных прав доступа пользователей к объектам. Рассмотрим, как в ОС Windows организована аутентификация и авторизация пользователей.
В
S – R – I – S0 — S1 — … — Sn – RID
се действующие в системе объекты (пользователи, группы, локальные компьютеры, домены) идентифицируются в Windows не по именам, уникальность которых не всегда удается достичь, а по идентификаторам защиты (Security Identifiers, SID). SID представляет собой числовое значение переменной длины:
S — неизменный идентификатор строкового представления SID;
R – уровень ревизии (версия). На сегодня 1.
I — (identifier-authority) идентификатор полномочий . Представляет собой 48-битную строку, идентифицирующую компьютер или сеть, который(ая) выдал SID объекту. Возможные значения:
- 0 (SECURITY_NULL_SID_AUTHORITY) — используются для сравнений, когда неизвестны полномочия идентификатора;
- 1 (SECURITY_WORLD_SID_AUTHORITY) — применяются для конструирования идентификаторов SID, которые представляют всех пользователей. Например, идентификатор SID для группы Everyone (Все пользователи) — это S-1-1-0;
- 2 (SECURITY_LOCAL_SID_AUTHORITY) — используются для построения идентификаторов SID, представляющих пользователей, которые входят на локальный терминал;
- 5 (SECURITY_NT_AUTHORITY) — сама операционная система. То есть, данный идентификатор выпущен компьютером или доменом.
Sn – 32-битные коды (колчеством 0 и более) субагентов, которым было передано право выдать SID. Значение первых подчиненных полномочий общеизвестно. Они могут иметь значение:
- 5 — идентификаторы SID присваиваются сеансам регистрации для выдачи прав любому приложению, запускаемому во время определенного сеанса регистрации. У таких идентификаторов SID первые подчиненные полномочия установлены как 5 и принимают форму S-1-5-5-x-y;
- 6 —когда процесс регистрируется как служба, он получает специальный идентификатор SID в свой маркер для обозначения данного действия. Этот идентификатор SID имеет подчиненные полномочия 6 и всегда будет S-1-5-6;
- 21 (SECURITY_NT_NON_UNIQUE) — обозначают идентификатор SID пользователя и идентификатор SID компьютера, которые не являются уникальными в глобальном масштабе;
- 32 (SECURITY_BUILTIN_DOMAIN_RID) — обозначают встроенные идентификаторы SID. Например, известный идентификатор SID для встроенной группы администраторов S-1-5-32-544;
- 80 (SECURITY_SERVICE_ID_BASE_RID) — обозначают идентификатор SID, который принадлежит службе.
Остальные подчиненные полномочия идентификатора совместно обозначают домен или компьютер, который издал идентификатор SID.
RID – 32-битный относительный идентификатор. Он является является идентификатором уникального объекта безопасности в области, для которой был определен SID. Например, 500 — обозначает встроенную учетную запись Administrator, 501 — обозначает встроенную учетную запись Guest, а 502 — RID для билета на получение билетов протокола Kerberos .
При генерации SID Windows использует генератор случайных чисел, чтобы обеспечить уникальность SID для каждого пользователя. Для некоторого произвольного пользователя SID может выглядеть так:
S-1-5-21-789336058-484763869-725345543-1003
Предопределенным пользователям и группам Windows выдает характерные SID, состоящие из SID компьютера или домена и предопределенного RID. В таблице 1 приведен перечень некоторых общеизвестных SID.
Таблица 1. Общеизвестные SID Windows
| SID | Название | Описание |
| S-1-1-0 | Все | Группа, в которую входят все пользователи |
| S-1-5-2 | Сеть | Группа, в которую входят все пользователи, зарегистрировавшиеся в системе из сети |
| S-1-5-7 | Анонимный вход | Группа, в которую входят все пользователи, вошедшие в систему анонимно |
| S-1-5-домен-500 | Администратор | Учетная запись администратора системы. По умолчанию только эта запись обеспечивает полный контроль системы |
| S-1-5-домен-501 | Гость | Учетная запись пользователя-гостя |
Полный список общеизвестных SID можно посмотреть в документации Platform SDK. Узнать SID конкретного пользователя в системе, а также SID групп, в которые он включен, можно, используя консольную команду whoami:
whoami /user /sid
Соответствие имени пользователя и его SID можно отследить также в ключе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList.
После аутентификации пользователя процессом Winlogon, все процессы, запущенные от имени этого пользователя будут идентифицироваться специальным объектом, называемым маркером доступа (access token). Если процесс пользователя запускает дочерний процесс, то его маркер наследуются, поэтому маркер доступа олицетворяет пользователя для системы в каждом запущенном от его имени процессе. Основные элементы маркера представлены на рис. 1.
| SID пользователя | SID1 … SIDn
Идентификаторы групп пользователя |
DACL по умолчанию | Привилегии | Прочие параметры |
Рисунок 1. Обобщенная структура маркера доступа.
Маркер доступа содержит идентификатор доступа самого пользователя и всех групп, в которые он включен. В маркер включен также DACL по умолчанию — первоначальный список прав доступа, который присоединяется к создаваемым пользователем объектам. Еще одна важная для определения прав пользователя в системе часть маркера – список его привилегий. Привилегии — это права доверенного объекта на совершение каких-либо действий по отношению ко всей системе. В таблице 2 перечислены некоторые привилегии, которые могут быть предоставлены пользователю.
Таблица 2. Привилегии, которыми могут быть наделены пользователи
| Имя и идентификатор привилегии | Описание привилегии |
| Увеличение приоритета диспетчирования
SeIncreaseBasePriorityPrivilege |
Пользователь, обладающий данной привилегией может изменять приоритет диспетчирования процесса с помощью интерфейса Диспетчера задач |
| Закрепление страниц в памяти SeLockMemoryPrivilege | Процесс получает возможность хранить данные в физической памяти, не прибегая к кэшированию данных в виртуальной памяти на диске. |
| Управление аудитом и журналом безопасности SeAuditPrivilege | Пользователь получает возможность указывать параметры аудита доступа к объекту для отдельных ресурсов, таких как файлы, объекты Active Directory и разделы реестра. |
| Овладение файлами или иными объектами SeTakeOwnershipPrivilege | Пользователь получает возможность становиться владельцем любых объектов безопасности системы, включая объекты Active Directory, файлы и папки NTFS, принтеры, разделы реестра, службы, процессы и потоки |
| Завершение работы системы
SeShutdownPrivilege |
Пользователь получает возможность завершать работу операционной системы на локальном компьютере |
| Обход перекрестной проверки
SeChangeNotifyPrivilege |
Используется для обхода проверки разрешений для промежуточных каталогов при проходе многоуровневых каталогов |
Управление привилегиями пользователей осуществляется в оснастке «Групповая политика», раздел Конфигурация Windows/Локальные политики/Назначение прав пользователя.
Чтобы посмотреть привилегии пользователя, можно также использовать команду
whoami /all
Остальные параметры маркера носят информационный характер и определяют, например, какая подсистема создала маркер, уникальный идентификатор маркера, время его действия. Необходимо также отметить возможность создания ограниченных маркеров (restricted token), которые отличаются от обычных тем, что из них удаляются некоторые привилегии и его SID-идетификаторы проверяются только на запрещающие правила. Создать ограниченный маркер можно программно, используя API-функцию CreateRestrictedToken, а можно запустить процесс с ограниченным маркером, используя пункт контекстного меню Windows “Запуск от имени…” и отметив пункт “Защитить компьютер от несанкционированных действий этой программы” (рис.2).
Рисунок 2. Запуск процесса с ограниченным маркером
Ограниченные маркеры используются для процессов, подменяющих клиента и выполняющих небезопасный код.
Маркер доступа может быть создан не только при первоначальном входе пользователя в систему. Windows предоставляет возможность запуска процессов от имени других пользователей, создавая для этих процессов соответствующий маркер. Для этих целей можно использовать:
— API-функции CreateProcessAsUser, CreateProcessWithLogon;
— оконный интерфейс (рис.2), инициализирующийся при выборе пункта контекстного меню “Запуск от имени…”;
— консольную команду runas:
runas /user:имя_пользователя program ,
где имя_пользователя — имя учетной записи пользователя, которая будет использована для запуска программы в формате пользователь@домен или домен\пользова-тель;
program – команда или программа, которая будет запущена с помощью учетной записи, указанной в параметре /user.
В любом варианте запуска процесса от имени другой учетной записи необходимо задать ее пароль.
1.3. Защита объектов системы.
Маркер доступа идентифицирует субъектов-пользователей системы. С другой стороны, каждый объект системы, требующий защиты, содержит описание прав доступа к нему пользователей. Для этих целей используется дескриптор безопасности (