Защита информации от несанкционированного доступа 3 страница

Встроенная подсистема поддержки NT:

Необходимые пояснения:

Client – сетевое приложение, работающее в пользовательском режиме и взаимодействующее с удаленной станцией.

NET BIOS EMULATOR – эмулятор команд проколов NET BIOS, доступное для приложений работающих в пользова­тельском режиме.

SOCKETS EMULATOR – библиотека функций SOCKETS, позволяющая приложениям обмениваться через сеть.

KERNEL MODE TPI client – системный драйвер, редиректор или сервер, получающий запросы на прием и передачу ин­формации от приложений.

Transport Driver Interface – программный интерфейс низкого уровня для сетевых драйверов, являющийся верхним слоем уровня транспортных драйверов.

TPI – не является отдельным драйвером, а является набором правил, по которым выполняется обмен информации между транспортными драйверами и драйверами редиректора или сервиса.

NT Streams Wrapper – оболочка для поддержки драйверов транспортных протоколов, использующих потоковую идеоло­гию построения системы управления потоком информации, принятую в ОС UNIX. Состоит из двух частей: TPI и DLPI.

TPI – transport provider interface (интерфейс между верхним слоем потоков драйверов и DLPI).

DLPI – data link provider interface (интерфейс между низким слове потоковых драйверов и интерфейсом NDIS).

TDI transport driver – драйвер транспортного протокола, поддерживающий соглашения DTI интерфейса для драйверов верхнего уровня и NTC низкого уровня.

NDIS – Network driver interface specification.

NTIS Interface Library – библиотека функций, реализующая специфический интерфейс сетевых драйверов как для драй­веров транспортного протокола, так и для драйверов сетевых адаптеров.

NIC Driver – драйвер интерфейсной карты сетевого адаптера.

Interface CARD – интерфейсная карта.

Разработанная архитектура сетевой подсистемы позволяет создавать гибкую транспортную многопротокольную среду, независящей от применяемой сетевой аппаратуры. Это достигается введением промежуточных интерфейсов, таких как NTIS и TDI. Специфичность TDI интерфейса позволяет вышестоящему слою драйверов сервера и редиректора функционировать независимо от типа протока транспортного уровня. Каждый транспортный протокол экспортирует известный набор универсальных функций, при помощи которых обеспечивает выполнение сетевых операций сервером или редиректором. Любой сетевой интерфейс может быть реализован при помощи набора примитивов TDI стандарта. NTIS – это системный драйвер, при помощи которого реализован ин­терфейс между одним или более драйверами сетевых адаптеров и, возможно, несколькими сетевыми картами, а также транспорт­ным протоколом и NIC драйверами. NTIS обеспечивает взаимодействие между выше названными драйверами и системой. При по­мощи набора функций, которые экспортирует NTIS, возможно осуществление следующих действий:

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

2. NIC драйвер способен принимать сетевые пакеты от одного или нескольких сетевых адаптеров и передавать их одному или нескольким драйверам транспортных протоколов.

3. Транспортный драйвер может задавать параметры конфигураций для NIC драйверов.

4. Транспортный драйвер может запрашивать необходимые конфигурации или статистику работы любого NIC драй­вера.

5. NIC драйвер может через NT информировать драйвер транспортного протокола о внештатных ситуациях в про­цессе работы.

Драйвер NT имеет следующую архитектуру:

LAN PROTOCOLS – транспортный протокол поддержки локальной сети.

LAN MEDIUM TYPE – типы сетевых интерфейсов, которые могут поддерживать транспортный протокол.

NTIS INTERHEATE – так называемый промежуточный драйвер NTIS, встраиваемый между драйвером транспортных протоколов и NIC драйвером, позволяющим проводить………………..

…………………….тип транспортного протокола, непосредственно взаимодействующим с оригинальным сетевым интер­фейсом NIC, которые могут отличаться от стандартных.

NATUVE MEDIUM TYPE – оригинальные сетевые интерфейсы, которые экспортируют в NIC – драйвер. Эти интер­фейсы могут быть отличны от трех, которые поддерживают транспортные драйверы. При помощи слоя промежуточных драйверов эти интерфейсы могут быть скрыты от слоя транспортных протоколов. Вместо них промежуточный драйвер иммулируют стандарт­ные типы сетевых протоколов.

NPIS MINIPORT – NIC драйвер, поддерживающий стандартный минипорт (обеспечивает более легкую обработку, биб­лиотеку).

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

Включает:

· Функцию взаимодействия транспорта с протоколом.

· Регистрацию обработки прерывания

· Передача информации через порты ввода- вывода и т.д.

2 технологии:

1 Технология встраивания промежуточных драйверов, встраивание дополнительных функций (система защиты). Промежуточ­ный сетевой драйвер встраивается между слоем транспортного протокола и слоем NIC драйверов. Возможно послойное встраивание промежуточных сетевых драйверов. Промежуточный драйвер будет иммулировать для слоя транспортных протоколов объекты адаптера NIC драйвера; для NIC драйвера – объект транспортных протоколов. Недос­татки: энергоемкость достаточно большая у промежуточного сетевого драйвера (1 драйвер – 2 лишних объекта); трудоем­кость встраивания промежуточного драйвера в подсистему удаленного доступа.

2 Встраивание подсистемы защиты основано на встраивании подсистемы в оболочку NTIS. Применение данного подхода имеет следующие преимущества:

§ Внедрение собственного кода в структуру привязок сетевых компонентов не приносит снижения быстродействия.

§ Отсутствует переключение контекстов.

§ Отсутствие необходимости иммуляции объектов сетевых адаптеров и объектов транспортного протокола.

§ Возможен жесткий контроль сетевой конфигурации при старте системы.

§ Поддержка удаленного доступа не отличается от поддержки локальной сети (см. полную таблицу с добавлением)

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

Например:

1. Send Complete Handier (функция завершения посылки сетевого пакета)

2. Wan Send Complete Handier (функция завершения через глобальную сеть)

3. Transfer Data Complete Handier (функция завершения получения сетевого пакета от драйвера сетевого адаптера)

4. Функция завершения обработки запроса драйвера сетевого протокола в драйвер сетевого адаптера и т.д.

Вопрос 40: Аудит в Windows NT.

Журнал аудита

Расположен по адресу:

/ System 32/ Config/ SecEvent.evt

Формат файла не документирован, информация в открытом виде, защита журнала организовывается сред­ствами системы организации доступа.

Для просмотра существуют утилиты. По умолчанию, позволяет читать журнал аудита администратору и аудиторам.

Все пользователи, которые могут читать, могут очищать его. Факт очистки журнала фиксируется сразу.

Максимальный размер 512 КБ. Может быть меньше. Шаг 64 КБ.

При переполнении журнала система может поступить следующим образом:

1. старые события стираются по мере необходимости.

2. если самое старое событие в журнале зафиксировано более n дней назад (n задается администрато­ром), одно или несколько самых старых событий стираются. В противном случае новые события не будут регистрироваться (т.е. n дней не прошло, а журнал переполнен).

3. Если значение в реестре, записывается в реестр:

/ Registry/ Machine/ System/ Current Countable/ Control/ OSA/ Crash ON Audit FALE = 1

Если значение равно 1, при переполнении журнала это значение становится равным 2, после чего происхо­дит крах ОС. При следующей загрузке в ОС, вход возможен только с правами администратора, который принуди­тельно очищает журнал, возвращает значение в 1 и перезагружает компьютер.

Для обновления записи журнал аудита……………. Win 32 API вводятся следующие функции:

Object Open Audit Alarm

Object Close Audit Alarm

Object Privilege Audit Alarm

Privileged Service Audit Alarm

Access Check And Audit Alarm

Политика аудита

NT позволяет регистрировать в журнале событий:

Ø Вход \ выход пользователя в ОС

Ø Доступ субъекта к объекту

Ø Изменение в списке пользователя

Ø Изменения в политике безопасности

Ø Системное событие

Ø Запуск и завершение процессов

Ø Использование субъектами доступа опасных привилегий

Для каждого класса событий могут регистрироваться только успешные события, только неуспешные собы­тия, и те, и те, или никакие события.

Для NT опасными считаются следующие привилегии:

· Получение оповещения от файловой системы

· Добавление записи в журнал аудита

· Создание МД

· Назначение МД процессам

· Отладка программ

· Создание резервной копии информации и восстановление

Стандартное программное обеспечение регистрирует события в журнале аудита 52 типов.

Требования:

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

2. желательно регистрировать:

§ вход- выход пользователя (успешные и неуспешные попытки)

§ доступ субъекта к объекту (целесообразно регистрировать, если есть по­дозрение злоупотребления использования объекта)

§ успешные попытки изменения списка пользователей должны регистриро­ваться всегда

§ изменения в политике безопасности должны регистрироваться всегда

§ системные события нецелесообразно регистрировать (их слишком много)

§ запуск и завершение процесса регистрировать целесообразно, если есть подозрение на вирус или вражескую программу

Достоинства:

Возможность аудита.

Недостатки:

1) Журнал защищен от несанкционированного доступа только средствами разграничения доступа.

2) Отсутствие удобных и эффективных средств для отделения пользователей аудитора от пользовате­лей администратора.

3) Количество категорий событий аудита недостаточно.

4) Многие важные с точки зрения безопасности системы события не могут быть зарегистрированы в журнале.

5) Многие объекты ОС, …….посредством стандартных утилит администрирования, по умолчанию имеют системный ACL, что приводит к регистрированию в журналу множество малоинтересных событий.

6) Реальный порядок регистрации некоторых событий противоречат перечисленным (описанным) в до­кументации.

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

Угроза безопасности конфиденциальности информации

1 Атака, реализуемая через воздействие на подсистему аутоидентификации.

Действия:

1 Возможность получения прямого доступа к разделам SAM и SECURITY……………..

2 Возможность перехвата и анализа сетевых пакетов.

2 Незаконный захват привилегий:

§ Отсутствует проверка наличия привилегий отлаживать системные процессы в некоторых функциях ОС.

§ Возможность подмены нарушения системных именованных каналов.

§ Внедрение в ОС дополнительных модулей или закладок.

Вопрос 41: Угрозы безопасности Windows NT и методы защиты.

Безопасность ОС

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

- Уязвимость

- Угроза

- Последствия (атака)

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

Угроза – это возможная опасность, потенциальная или реально существующая, в содержании какого–либо деяния (действия или бездействия), направленное против объекта защиты, проявившегося в опасности искажения или потери информации.

Последствие (атака) – возможное следствие реализации угрозы через имеющуюся уязвимость.

Угрозы безопасности информации – хищение, модификация, уничтожение, нарушение доступности, отрицание подлинности и навязывание ложности.

Источник угрозы безопасности как субъекты, так и объекты. Источники угроз как внутри защищенного объ­екта, так и вне его.

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

Классификация угроз безопасности ОС:

1. по цели реализации:

несанкционированное чтение информации

несанкционированное изменение информации

несанкционированное удаление информации

полное или частичное разрушение ОС (разрушение – это комплекс воздействий от кратковременного вы­вода отдельных модулей из строя до физических стираний системных файлов)

2. по принципу воздействия

§ использование известных каналов получения информации (несанкционированное чтение файлов, дос­туп к которым запрещен)

§ использование скрытых каналов получение информации (использование недокументированных функ­ций)

§ создание новых каналов получения информации (при разработке системы (какие-либо закладки))

3. по характеру воздействия на ОС

активное воздействие

пассивное воздействие (наблюдение за процессами)

4. по типу использования слабой защиты

ü использование неадекватной политики безопасности, в том числе ошибки администратора

ü использование ошибок и недокументированных возможностей программного обеспечения (служеб­ные закладки)

5. по способу воздействия на объект атаки

непосредственное воздействие

превышение пользователя своих полномочий

работа от имени другого пользователя

использование результатов работы другого пользователя

6. по способу действия злоумышленника

· можно работать в интерактивном режиме (пошагово, вручную)

· либо в пакетном режиме

7. по объекту атаки

ОС в целом

Объект ОС (пользователи, процессы, запущенные от их имени)

Каналы передачи данных

8. по использованным средствам атаки

штатные средства ОС без использования дополнительного программного обеспечения

программное обеспечение третьих фирм

специально разработанное программное обеспечение

9. по состоянию атакуемого объекта на момент состояния (хранение, передача, обработка информации)

ОС называется защищенной, если она предусматривает средства защиты от основных классов угроз (см. выше).

ОС частично-защищенная, если предусматриваются не все средства защиты.

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

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

Адекватная политика безопасности – это такая политика безопасности, которая обеспечивает достаточный уро­вень безопасности ОС. Адекватная политика безопасности – это необязательно та политика безопасности, при которой достигается максимальный уровень защищенности ОС.

Два подхода к созданию защищенной ОС:

3. комплексный (механизм защиты внедряется на стадии разработки ОС; на момент создания системы должна быть продумана линия зашиты)

4. фрагментальный (простота, но система не гарантирует защиты от комплексных угроз). Преимуще­ства: защиты организуется одним модулей, относительная дешевизна.

Стандарт защищенности (оранжевая книга):

5) отсутствие криптографических средств защиты информации

6) отсутствие вопросов защиты типа «отказ в обслуживании»

7) отсутствие защиты от программных закладок

8) недостаточно рассматриваются вопросы взаимодействия нескольких экземпляров защищенных систем в ло­кальной или глобальной сети

Документы:

3. средства вычислительной техники (СВТ) (защита от MSD информации, показатели защищенности от MSD информации). Рассматриваются требования к обеспечению защищенности отдельных программно-аппа­ратных компонентов (элементов) и защищенных комплексных систем. Под СВЧ понимаются не только аппаратные средства, но и совокупность программ и технических элементов систем обработки данных, способных функционировать самостоятельно либо в составе других систем. Для СВЧ 7 классов защищен­ности.

4. автоматическая система (АС) (защита от MSD информации, классификация АС и требования по защите ин­формации). Все АС делятся на 3 группы. В каждой существует своя иерархия.

Группа 3 – однопользовательские системы.

Делятся на 2 класса.

Класс 3Б – осуществляется проверка подлинности доступа при входе в систему, регистрация входа и выхода, учет используемых носителей (диски и т.д.)

Класс 3А – выполняются все требования класса 3Б + регистрация распечатки документов и физическая очистка очищаемой аппаратной области и внешней памяти.

Группа 2:

Класс 2В – многопользовательские системы, в которых пользователи имеют равные права.

Класс 2Б – проверка подлинности пользователей, регистрация и т.д. (как в 3Б).

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

Группа 1 – многопользовательские системы, в которых пользователи имеют различные полномочия доступа информации.

Класс 1Д – должна проверяться подлинность пользователя, регистрация входа и выхода, учет внешних носите­лей информации.

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

Класс 1В – предыдущие + полномочные разграничения доступа, усилены требования для поддержания опас­ных для поддержания защищенности системы, интерактивное оповещение администратора системы о попытках несанк­ционированного доступа.

Класс 1Б – предыдущие + наличие подсистемы шифрования конфиденциальной информации и использование сертифицированных алгоритмов.

Класс 1А – предыдущие + различные субъекты доступа используют различные ключи.

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

Сертификация ОС по некоторому классу защиты, как правило, сопровождается составлением требований к адекватной политике безопасности при неукоснительном выполнении которой защищенность ОС будет соответствовать требованиям защищенности класса защиты.

UNIX:

Для выполнения требования С2 необходимо:

запретить вход в систему без ввода пароля;

использовать только файловую систему NTFS;

запрещать использовать пароль из символов менее 6 символов;

запрещать иммуляцию приложений OS/2 и POSIX;

запрещать анонимный и гостевой доступ;

запрещать доступ любых отладчиков;

тумблер питания и перезагрузка недоступна пользователю;

запрещать завершение работы ОС без входа пользователя в систему;

политика безопасности в отношении журнала аудита таким образом, что при переполнении журнала безопас­ности ОС перестанет работать. Восстановление работы только с именем и правами администра­тора;

запрещено разделение между пользователями ресурсов сменных носителей информации;

запись в системный каталог и файлы инициализации разрешена только администратору и системным процес­сам.

Вопрос 42: ОС Windows NT. Основные функции Win32 API.

Windows API (англ. application programming interfaces) — общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Windows и Windows NT корпорации «Майкрософт». Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, «Майкрософт» выпускает SDK, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств.
Вопрос 43: ОС Windows NT. Распределение процессорного времени между пото­ками.

Распределение процессорного времени между потоками

Win 32 поддерживает 4 класса приоритета:

Уровни

IDLE (простаивания) 4

NORMAL (нормальное) 8

HIGH (высокое) 12

REALTIME (реальное время) 24

Уровни от 0 до 31.

Если не указать при создании типа приоритет, то присваивается NORMAL. Любой поток в этом случае полу­чает уровень приоритета 8.

Пусть есть 10 приложений:

10 приложениям выделяют по 15 мс для выполнения. Если максимальное ускорение у приложения первого плана, то 45 мс (у NT).

Функция:

SET PRIORITY CLASS (HANDLE hPROCESS

DWORD fdw PROIRITY)

Меняет класс приоритета процесса.

Функция:

SETThread Priority (HANDLE Thread

INT PRIORITY)

Для изменения приоритета процесса.

В эту функцию можем вернуть:

THREAD_PRIORITY_LOWEST – *

THREAD_PRIORITY_BELOW NORMAL – **

THREAD_PRIORITY_NORMAL – ***

THREAD_PRIORITY_ABOVE NORMAL – ****

THREAD_PRIORITY_HIGHEST – *****

* приоритет процесса должен быть на 2 единицы ниже процесса

** на 1 ниже

*** соответствовать

**** на 1 выше

***** на 2 выше

THREAD_PRIORITY IDLE – устанавливает уровень приоритета потока, равным 1 при классе приоритете про­цесса IDLE, NORMAL или HIGH. Если REAL TIME, уровень приоритета потока 16.

THREAD_PRIORITY _TIME_CRITICAL – устанавливает уровень приоритета потока, равным 15 при классе приоритете процесса IDLE, NORMAL или HIGH. Если REAL TIME, уровень приоритета потока 31.

Таблица

Название	IDLE	NORMAL	HIGH	REAL TIME
TIME_CRITICAL
HIGHEST
ABOVE NORMAL
NORMAL
BELOW NORMAL
LOWEST
IDLE

Вопрос 44: История развития и общая характеристика семейства ОС UNIX. Ос­новные сведения о системе.

UNIX имеет долгую и интересную историю. Начавшись как несерьезный и почти "игрушечный" проект молодых ис­следователей, UNIX стал многомиллионной индустрией, включив в свою орбиту университеты, многонациональные корпора­ции, правительства и международные организации стандартизации.

UNIX зародился в лаборатории Bell Labs фирмы AT&T более 20 лет назад. В то время Bell Labs занималась разработ­кой многопользовательской системы разделения времени MULTICS (Multiplexed Information and Computing Service) совместно с MIT и General Electric, но эта система потерпела неудачу, отчасти из-за слишком амбициозных целей, не соответствовавших уровню компьютеров того времени, а отчасти и из-за того, что она разрабатывалась на языке PL/1, а компилятор PL/1 задержи­вался и вообще плохо работал после своего запоздалого появления. Поэтому Bell Labs вообще отказалась от участия в проекте MULTICS, что дало возможность одному из ее исследователей, Кену Томпсону, заняться поисковой работой в направлении улучшения операционной среды Bell Labs. Томпсон, а также сотрудник Bell Labs Денис Ритчи и некоторые другие разрабаты­вали новую файловую систему, многие черты которой вели свое происхождение от MULTICS. Для проверки новой файловой системы Томпсон написал ядро ОС и некоторые программы для компьютера GE-645, который работал под управлением муль­типрограммной системы разделения времени GECOS. У Кена Томпсона была написанная им еще во времена работы над MULTICS игра "Space Travel" - "Космическое путешествие". Он запускал ее на компьютере GE-645, но она работала на нем не очень хорошо из-за невысокой эффективности разделения времени. Кроме этого, машинное время GE-645 стоило слишком дорого. В результате Томпсон и Ритчи решили перенести игру на стоящую в углу без дела машину PDP-7 фирмы DEC, имею­щую 4096 18-битных слов, телетайп и хороший графический дисплей. Но у PDP-7 было неважное программное обеспечение, и, закончив перенос игры, Томпсон решил реализовать на PDP-7 ту файловую систему, над который он работал на GE-645. Из этой работы и возникла первая версия UNIX, хотя она и не имела в то время никакого названия. Но она уже включала харак­терную для UNIX файловую систему, основанную на индексных дескрипторах inode, имела подсистему управления процес­сами и памятью, а также позволяла двум пользователям работать в режиме разделения времени. Система была написана на ассемблере. Имя UNIX (Uniplex Information and Computing Services) было дано ей еще одним сотрудником Bell Labs, Брайаном Керниганом, который первоначально назвал ее UNICS, подчеркивая ее отличие от многопользовательской MULTICS. Вскоре UNICS начали называть UNIX.