Компьютерные сети, экспертные системы и защита иформации


Наши друзья:	Основные подходы к созданию изолированной программной среды Для создания ИПС можно использовать два подхода: 1. 1. Замещение пользовательской оболочки собственной задачей, которая предлагает замкнутое меню. Этот путь достаточно тривиален и предусматривает написание простого оконного приложения и указания пути к нему в ключе Shell. 2. 2. Задание ключей реестра, позволяющих ограничить число задач в меню Пуск стандартной оболочки. В Windows NT есть возможность установить список программ, которые могут быть запущены пользователями. Для демонстрации данной возможности выполните следующие действия. 1. 1. Откройте реестр для редактирования и найдите ключ [HKEY_CUR-RENT_USER\Software\Microsoft\Windows \CurrentVersion\Policies\Explorer] 2. Установите значение параметра 'RestrictRun1 равным 'Г для использования данной функции или равной '0' для ее блокировки. Создайте этот параметр, если его не существует. 3. Определите программы, которые смогут запускать пользователи, в ключе: [HKEY_CURRENT_USER\Software \Microsoft\Windows\CurrentVersion\ Policies\Explorer\RestrictRun]. Создайте новый параметр для каждой программы, именуя их числами по возрастанию. Например: Т='Саlс.ехе' '2'='winword.exe' Рассмотренный путь имеет некоторый недостаток, связанный с тем, что необходимо редактировать ключи раздела CurretaUser. Таким образом, необходимо предварительно регистрироваться в системе в качестве пользователя, для которого устанавливается замкнутое меню. Следует учитывать - ничто не мешает пользователям переименовать любой .ехе файл в winword.exe (или любой другой, разрешенный к запуску) и обойти это ограничение. В связи с этим для реализации надежной защиты необходимо «поддержать» работу ИПС драйвером уровня ядра, который контролирует операции с исполняемыми файлами. Макет системы защиты от несанкционированного доступа При создании системы защиты информации (СЗИ) от несанкционированного доступа необходимо реализовать следующие функциональные подсистемы: - подсистему идентификации и аутентификации (ИА) пользователей, - подсистему разграничения (контроля) доступа субъектов ОС к объектам, - подсистему регистрации событий. При этом подсистему идентификации и аутентификации целесообразно ассоциировать со штатной подсистемой ИА, реализуемой MSGINA, а подсистему контроля доступа и регистрации событий - с отдельно работающим драйвером контроля доступа, связанным с подсистемой ИА. Такая связь необходима потому, что контроль доступа к объектам до входа конкретного пользователя в систему может представлять собой достаточно нетривиальную задачу, например, если для конкретного пользователя задана изолированная программная среда (т.е. фиксированный список задач, которые он может запускать), то непонятно как быть с задачами, запускаемыми до выполнения успешной процедуры ИА данного пользователя). Кроме того, связь со штатным модулем ИА может служить для передачи ключевой информации, необходимой для инициализации персональных криптографических модулей, предназначенных для шифрования трафика (см. выше) или для периодического тестирования корректности работы криптографических функций или иных механизмов обеспечения безопасности. Рассмотрим пример макета ядра СЗИ от несанкционированного доступа для Windows NT/2000. Основными компонентами этой системы защиты являются, как указано выше: · Драйвер контроля доступа, предназначенный для перехвата файловых операций на уровне ядра. · Модифицированная библиотека GINA (XGINA), построенная по принципу полного перехвата экспортируемых функций оригинальной MSGINA (Graphical Identification aNd Authentication DLL for Wiwnlogon). При входе пользователя библиотека GINA.DLL возвращает директивы приложению Winlogon, согласно которым оно либо не должно менять текущий статус процесса ИА, либо выполнить некоторые действия (например, насильственно выгрузить пользователя). В зависимости от значения параметра dwOptions в функции WlxLoggedOutSasQ библиотеки GINA.DLL, приложение Winlogon либо, не должно загружать профиль входящего пользователя, либо же должно выполнить загрузку того пользовательского профиля, информацию о котором вернула библиотека GINA.DLL. Перехват операций открытия, создания и удаления файлов Реализация драйвером перехвата файловых операций основана на недокументированном механизме перехвата системных сервисов, описанном в разделе «Реализация защиты на уровне собственного API для ОС Windows NT». Принцип функционирования драйвера основан на механизме замены адресов функций, предоставляемых «родным» API. Обработчик прерывания int 2E для вызова соответствующего системного сервиса использует таблицу распределения системных сервисов KeServiceDescriptorTable, экспортируемую ntoskrnl.exe. Во время инициализации драйвера в функции DriverEntry, после успешного создания объекта-устройства, устанавливаются собственные обработчики файловых операций. Для этого сначала надо получить адрес таблицы распределения системных сервисов: ServiceTable = KeServicepescriptorTable; Зная индексный номер функции, реализующей системный сервис, можно ио таблице определить адрес ее начала и заменить его на адрес начала собственного обработчика режима ядра. Это делается следующим образом: #define SYSCALL(_function) ServiceTable->ServiceTable[ (PULONG)((PUCHAR)_function+l)] RealCreateFile = SYSCALL( ZwCreateFile ); //RealCreateFile - оригинальный обработчик создания файла; SYSCALL( ZwCreateFile ) = (PVOID) HookCreateFile; //HookCreateFile - собственный обработчик создания файла; RealO'penFile = SYSCALL ( ZwOpenFile ); //RealOpenFile - оригинальный обработчик открытия файла; SYSCALL( ZwOpenFile ) = (PVOID) HookOpenFile; //HookOpenFile - собственный обработчик открытия файла; При перехвате функций ZwCreateFile и ZwOpenFile необходимо учитывать, что операции запуска исполняемых файлов, переименования и удаления объектов производятся именно этими функциями при установленных следующим образом флагах: . DesiredAccess & DELETE - операция удаления файла, DesiredAccess & FILE_EXECUTE) \|\| (DesiredAccess & GENERIC_EXECUTE) - запуск исполняемого файла. Отдельную задачу представляет собой различение операций с объектами типа PIPE или СОМ-порт. В ряде случаев это может быть сделано по имени, например, memcmp(AnsiString.Buffer, "\\dosdevices\\com", 15) после выполнения фрагмента кода: UnString.Length = (USHORT) ObjectAttributes->ObjectName->Length; UnString.MaximumLength = (USHORT) ObjectAttributes->ObjectName-> ., ,. MaximumLength-; . , UnString.Buffer = ObjectAttributes->ObjectName->Buffer;. RtlUnicodeStringToAnsiString .. ( SAnsiString, SUnString, TRUE ),.; Собственный обработчик создания файла и собственный обработчик открытия файла Собственный обработчик создания (открытия) файла может, например, проверить права доступа текущего процесса к создаваемому (открываемому) файлу, и если дос- туп запрещен, то вернуть статус создания (открытия) файла STATUS_ACCESS_DENIED (доступ запрещен), иначе вернуть управление оригинальному обработчику. При этом можно вести журнал как удавшихся, так и не удавшихся попыток доступа, регистрируя имя процесса, в контексте которого осуществляется попытка доступа к ресурсу, и имя создаваемого (открываемого) файла. После исполнения собственного обработчика необходимо передать управление по старому адресу, чтобы дать возможность стандартному обработчику выполнить запрошенные действия. NTSTATUS HookCreateFile (OUT PHANDLE FileHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes, OUT PIO_STATUS_BLOCK loStatusBlock, IN PLARGE_INTEGER AllocationSize, IN ULONG FileAttributes, IN ULONG ShareAccess, IN ULONG CreateDisposition, IN ULONG CreateOptions,IN PVOID EaBuffer,IN ULONG EaLength) { if (Access (ObjectAttributes) ) return RealCreateFile (FileHandle, DesiredAccess/ ObjectAttributes, loStatusBlock, AllocationSize, FileAttributes, ShareAccess, CreateDisposition, CreateOptions,EaBuf fer, EaLength) ; return STATUSACCESSDENIED; Определение имени процесса Реализация драйвером функции получения имени обращающегося к ресурсу процесса необходима для создания системы защиты от НСД не ниже 3 класса по классификации Руководящих документов Государственной технической комиссии РФ, определяющих защищенность средств вычислительной техники (СВТ) или класса 1В по классификации защищенности автоматизированных систем (АС). При этом может быть поддержана полная модель полномочного (мандатного) доступа, определяющая возможность контроля доступа обращений к ресурсу от имени конкретного процесса. Имя обращающегося к ресурсу процесса находится в структуре, описывающей объект-процесс. Чтобы получить смещение имени процесса в объекте-процессе, надо во время инициализации драйвера в функции DriverEntry (которая всегда исполняется в контексте процесса System) найти строку «System» в объекте-процессе, описывающем (процесс System: ULONG GetProces'sNameOffset () . PEPROCESS int curproc; i; curproc = PsGetCurrentProcess () ; for( i = 0; i < 3PAGE_SIZE; i++ ) { if( !strncmp( "System", (PCHAR) curproc + i, strlen ("System") )) { return i; . //имя не найдено return 0; После удачного завершения этой функции можно использовать возвращенное ею значение ProcessNameOffset для определения имени процесса: VOID GetProcess ( PCHAR Name ) { PEPROCESS curproc; char *nameptr; ULONG i; if( ProcessNameOffset ) { s curproc = PsGetCurrentProcess () ; nameptr = (PCHAR)- curproc + ProcessNameOffset; strncpy( Name, nameptr, 16 ); } else { strcpy( Name, "???"); Получив имя процесса, можно определить его конкретные полномочия по доступу к объектам. Например, далее по тексту будет использоваться возможность вызова функций драйвера только процессом Winlogon, в контексте которого работает GINA. Таким образом, можно гарантировать передачу параметров и управление драйвером только со стороны модифицированной библиотеки.

\| На главную \| Содержание \| Вперёд \| Назад \|
Последнее обновление С вопросами и предложениями можно обращаться на nicivas@bk.ru

Наши друзья:

Основные подходы к созданию изолированной программной среды

Для создания ИПС можно использовать два подхода:
1. 1. Замещение пользовательской оболочки собственной задачей, которая предлагает замкнутое меню.
Этот путь достаточно тривиален и предусматривает написание простого оконного приложения и указания пути к нему в ключе Shell.
2. 2. Задание ключей реестра, позволяющих ограничить число задач в меню Пуск стандартной оболочки.
В Windows NT есть возможность установить список программ, которые могут быть запущены пользователями. Для демонстрации данной возможности выполните следующие действия.
1. 1. Откройте реестр для редактирования и найдите ключ
[HKEY_CUR-RENT_USER\Software\Microsoft\Windows
\CurrentVersion\Policies\Explorer]
2. Установите значение параметра 'RestrictRun1 равным 'Г для использования данной функции или равной '0' для ее блокировки. Создайте этот параметр, если его не существует.
3. Определите программы, которые смогут запускать пользователи, в ключе: [HKEY_CURRENT_USER\Software
\Microsoft\Windows\CurrentVersion\ Policies\Explorer\RestrictRun].
Создайте новый параметр для каждой программы, именуя их числами по возрастанию. Например:
Т='Саlс.ехе'
'2'='winword.exe'
Рассмотренный путь имеет некоторый недостаток, связанный с тем, что необходимо редактировать ключи раздела CurretaUser. Таким образом, необходимо предварительно регистрироваться в системе в качестве пользователя, для которого устанавливается замкнутое меню.
Следует учитывать - ничто не мешает пользователям переименовать любой .ехе файл в winword.exe (или любой другой, разрешенный к запуску) и обойти это ограничение. В связи с этим для реализации надежной защиты необходимо «поддержать» работу ИПС драйвером уровня ядра, который контролирует операции с исполняемыми файлами.

Макет системы защиты от несанкционированного доступа

При создании системы защиты информации (СЗИ) от несанкционированного доступа необходимо реализовать следующие функциональные подсистемы:
- подсистему идентификации и аутентификации (ИА) пользователей,
- подсистему разграничения (контроля) доступа субъектов ОС к объектам,
- подсистему регистрации событий.
При этом подсистему идентификации и аутентификации целесообразно ассоциировать со штатной подсистемой ИА, реализуемой MSGINA, а подсистему контроля доступа и регистрации событий - с отдельно работающим драйвером контроля доступа, связанным с подсистемой ИА. Такая связь необходима потому, что контроль доступа к объектам до входа конкретного пользователя в систему может представлять собой достаточно нетривиальную задачу, например, если для конкретного пользователя задана изолированная программная среда (т.е. фиксированный список задач, которые он может запускать), то непонятно как быть с задачами, запускаемыми до выполнения успешной процедуры ИА данного пользователя). Кроме того, связь со штатным модулем ИА может служить для передачи ключевой информации, необходимой для инициализации персональных криптографических модулей, предназначенных для шифрования трафика (см. выше) или для периодического тестирования корректности работы криптографических функций или иных механизмов обеспечения безопасности.
Рассмотрим пример макета ядра СЗИ от несанкционированного доступа для Windows NT/2000. Основными компонентами этой системы защиты являются, как указано выше:
· Драйвер контроля доступа, предназначенный для перехвата файловых операций на уровне ядра.
· Модифицированная библиотека GINA (XGINA), построенная по принципу полного перехвата экспортируемых функций оригинальной MSGINA (Graphical Identification aNd Authentication DLL for Wiwnlogon). При входе пользователя библиотека GINA.DLL возвращает директивы приложению Winlogon, согласно которым оно либо не должно менять текущий статус процесса ИА, либо выполнить некоторые действия (например, насильственно выгрузить пользователя). В зависимости от значения параметра dwOptions в функции WlxLoggedOutSasQ библиотеки GINA.DLL, приложение Winlogon либо, не должно загружать профиль входящего пользователя, либо же должно выполнить загрузку того пользовательского профиля, информацию о котором вернула библиотека GINA.DLL.

Перехват операций открытия, создания и удаления файлов

Реализация драйвером перехвата файловых операций основана на недокументированном механизме перехвата системных сервисов, описанном в разделе «Реализация защиты на уровне собственного API для ОС Windows NT».
Принцип функционирования драйвера основан на механизме замены адресов функций, предоставляемых «родным» API. Обработчик прерывания int 2E для вызова соответствующего системного сервиса использует таблицу распределения системных сервисов KeServiceDescriptorTable, экспортируемую ntoskrnl.exe.
Во время инициализации драйвера в функции DriverEntry, после успешного создания объекта-устройства, устанавливаются собственные обработчики файловых операций. Для этого сначала надо получить адрес таблицы распределения системных сервисов:
ServiceTable = KeServicepescriptorTable;
Зная индексный номер функции, реализующей системный сервис, можно ио таблице определить адрес ее начала и заменить его на адрес начала собственного обработчика режима ядра.
Это делается следующим образом:
#define SYSCALL(_function)
ServiceTable->ServiceTable[ *(PULONG)((PUCHAR)_function+l)]
RealCreateFile = SYSCALL( ZwCreateFile );
//RealCreateFile - оригинальный обработчик создания файла;
SYSCALL( ZwCreateFile ) = (PVOID) HookCreateFile;
//HookCreateFile - собственный обработчик создания файла;
RealO'penFile = SYSCALL ( ZwOpenFile );
//RealOpenFile - оригинальный обработчик открытия файла;
SYSCALL( ZwOpenFile ) = (PVOID) HookOpenFile;
//HookOpenFile - собственный обработчик открытия файла;
При перехвате функций ZwCreateFile и ZwOpenFile необходимо учитывать, что операции запуска исполняемых файлов, переименования и удаления объектов производятся именно этими функциями при установленных следующим образом флагах: .
DesiredAccess & DELETE - операция удаления файла,
DesiredAccess & FILE_EXECUTE) ||
(DesiredAccess & GENERIC_EXECUTE) - запуск исполняемого файла.
Отдельную задачу представляет собой различение операций с объектами типа PIPE или СОМ-порт. В ряде случаев это может быть сделано по имени, например, memcmp(AnsiString.Buffer, "\\dosdevices\\com", 15) после выполнения фрагмента кода:
UnString.Length = (USHORT)
ObjectAttributes->ObjectName->Length;
UnString.MaximumLength = (USHORT)
ObjectAttributes->ObjectName-> ., ,.
MaximumLength-; . ,
UnString.Buffer = ObjectAttributes->ObjectName->Buffer;.
RtlUnicodeStringToAnsiString
.. ( SAnsiString, SUnString, TRUE ),.;

Собственный обработчик создания файла и собственный обработчик открытия файла

Собственный обработчик создания (открытия) файла может, например, проверить права доступа текущего процесса к создаваемому (открываемому) файлу, и если дос-
туп запрещен, то вернуть статус создания (открытия) файла STATUS_ACCESS_DENIED (доступ запрещен), иначе вернуть управление оригинальному обработчику. При этом можно вести журнал как удавшихся, так и не удавшихся попыток доступа, регистрируя имя процесса, в контексте которого осуществляется попытка доступа к ресурсу, и имя создаваемого (открываемого) файла. После исполнения собственного обработчика необходимо передать управление по старому адресу, чтобы дать возможность стандартному обработчику выполнить запрошенные действия.
NTSTATUS HookCreateFile (OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK loStatusBlock,
IN PLARGE_INTEGER AllocationSize, IN ULONG FileAttributes,
IN ULONG ShareAccess, IN ULONG CreateDisposition,
IN ULONG CreateOptions,IN PVOID EaBuffer,IN ULONG EaLength)
{
if (Access (ObjectAttributes) ) return RealCreateFile (FileHandle, DesiredAccess/ ObjectAttributes,
loStatusBlock, AllocationSize, FileAttributes, ShareAccess,
CreateDisposition, CreateOptions,EaBuf fer, EaLength) ; return STATUSACCESSDENIED;

Определение имени процесса

Реализация драйвером функции получения имени обращающегося к ресурсу процесса необходима для создания системы защиты от НСД не ниже 3 класса по классификации Руководящих документов Государственной технической комиссии РФ, определяющих защищенность средств вычислительной техники (СВТ) или класса 1В по классификации защищенности автоматизированных систем (АС). При этом может быть поддержана полная модель полномочного (мандатного) доступа, определяющая возможность контроля доступа обращений к ресурсу от имени конкретного процесса.
Имя обращающегося к ресурсу процесса находится в структуре, описывающей объект-процесс. Чтобы получить смещение имени процесса в объекте-процессе, надо во время инициализации драйвера в функции DriverEntry (которая всегда исполняется в контексте процесса System) найти строку «System» в объекте-процессе, описывающем (процесс System: ULONG GetProces'sNameOffset () .
PEPROCESS int
curproc;
i; curproc = PsGetCurrentProcess () ; for( i = 0; i < 3*PAGE_SIZE; i++ ) {
if( !strncmp( "System", (PCHAR) curproc + i, strlen ("System") )) {
return i; .
//имя не найдено return 0;
После удачного завершения этой функции можно использовать возвращенное ею значение ProcessNameOffset для определения имени процесса:
VOID GetProcess ( PCHAR Name )
{
PEPROCESS curproc;
char *nameptr;
ULONG i;
if( ProcessNameOffset ) { s
curproc = PsGetCurrentProcess () ;
nameptr = (PCHAR)- curproc + ProcessNameOffset;
strncpy( Name, nameptr, 16 ); } else {
strcpy( Name, "???");
Получив имя процесса, можно определить его конкретные полномочия по доступу к объектам. Например, далее по тексту будет использоваться возможность вызова функций драйвера только процессом Winlogon, в контексте которого работает GINA. Таким образом, можно гарантировать передачу параметров и управление драйвером только со стороны модифицированной библиотеки.

Последнее обновление

С вопросами и предложениями можно обращаться на nicivas@bk.ru