Сетевая архитектура Windows NT

Информатика
Общая архитектура Windows
Сетевая архитектура Windows
Компьютерная сеть
Передача дискретных данных по линиям связи
Общая характеристика протоколов локальных сетей
Построение локальных сетей на базе коммутаторов
Маршрутизация в локальных сетях
Глобальные сети
Глобальные сети с коммутацией пакетов
Структура ЛС
Накопители на магнитной ленте
Компьютерная алгебра
Электротехника
Расчет электрических цепей
Лабораторные работы
Физика
Решение контрольной
Энергетика
Ядерная энергетика
Математика
Линейная алгебра
Компьютерная алгебра
Математический анализ
Линии второй степени
Пределы
Неопределенный интеграл
Определенный интеграл
Основные правила интегрирования
Множества и отображения
Геометрические преобразования
Тройные интегралы примеры решений
Двойные интегралы примеры решений
Теоретическая механика
Решение задач
Техническое черчение
Примеры выполнения заданий

Эта глава посвящена рассмотрению сетевой архитектуры ОС Windows NT. Рассматривается соответствие сетевой архитектуры модели OSI, описаны сетевые интерфейсы, сетевые компоненты, их предназначение и взаимосвязи. Чтобы помочь производителям в стандартизации и интегрировании их сетевого программного обеспечения, Международная организация по стандартизации (ISO) определила программную модель пересылки сообщений между компьютерами - модель соединения открытых систем (Open System Interconnection reference model, OSI). Windows NT реализует несколько сетевых API для обеспечения поддержки сетевых приложений и совместимости с промышленными стандартами. Приложения получают доступ к удаленным файлам, используя стандартные Win32-функции ввода/вывода (открытия, закрытия, чтения, записи и т. п) Windows NT обеспечивает множество независимых от сети WNet-функций, которые позволяют работать через провайдеров разных сетей.

Это прикладной программный интерфейс, позволяющий обмениваться запросами ввода/вывода с удаленным компьютером. Именованные каналы обеспечивают надежное двунаправленное взаимодействие между двумя процессами, независимо от того, является ли принимающая сторона локальной или удаленной. Этот API реализует 16 и 32-разрядные сокеты - стандартный сетевой интерфейс, используемый UNIX. Winsock поддерживает надежное, ориентированное на соединение, а также ненадежное, не ориентированное на соединение взаимодействия. Средство удаленного вызова процедур позволяет создавать распределенные приложения, вызывающие функции, реализованные как локально, так и на удаленных компьютерах. Network DDE используется для установления и поддержания сетевых соединений, необходимых для динамического обмена данными между приложениями, выполняющимися на разных компьютерах в сети.

Сервер Windows NT поддерживает удаленный доступ (RAS) для создания временных соединений с системами, которые не находятся в локальной сети, обычно это соединения через телефонные линии. Интерфейс TAPI - множество функций, позволяющих запрограммировать устройства, передающие данные по телефонным линиям, не зависящим от конкретного устройства образом, предоставляя пользователям возможность взаимодействия по телефону. В Windows NT приложения могут использовать интерфейс DLC, обращаясь к библиотеке dlcapi.dll. Cтандартный протокол Internet для обмена управляющей информацией между консолями управления, такими как HP Openview, Novell NMS, IBM NetView, Sun Net Manager, и набором управляемых устройств, такими как маршрутизаторы, мосты, концентраторы. COM API фирмы Microsoft позволяет приложениям состоять из разных компонентов, где каждый компонент является заменяемым самостоятельным модулем.

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

Маршрутизатор многосетевого доступа (Multiple Provider Router, MPR) - это библиотека DLL, предоставляющая приложениям интерфейс API WNet, и определяющая к какой сети следует обратиться, когда приложение использует этот интерфейс для просмотра удаленной файловой системы. Многосетевой UNC (Multiple UNC Provider, MUP) - драйвер, определяющий, к какой сети следует обратиться, когда приложение использует стандартный Win32 API ввода/вывода для открытия удаленных файлов. Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI). Транспортный протокол NetBEUI STREAMS, основанная на UNIX STREAMS, является средой для существующих STREAMS-совместимых транспортных драйверов, которая обеспечивает переносимость этим драйверам в ОС Windows NT из других ОС с незначительными модификациями или вовсе без изменений.

В 1989 г Microsoft и 3Com совместно разработали спецификацию интерфейса взаимодействия между подуровнем MAC канального уровня модели OSI и драйверами протоколов, располагающихся на вышележащих уровнях. Стандарт получил название Network Driver Interface Specification (NDIS - спецификация интерфейса сетевых драйверов). Драйвер протокола верхнего уровня в своей верхней части предоставляет TDI-интерфейс или, возможно, другой интерфейс, необходимый пользователям сети. Обобщенная схема сетевой архитектуры Windows NT Связь между сетевыми программными компонентами

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

Реализация защиты на уровне системных DLL, предоставляющих приложениям различные сетевые интерфейсы Почти все сетевые сервисы, такие как сервис рабочей станции (LanMan Workstation), сервис сервера (LanMan Server), сервис оповещений (alerter), сервис сообщений (messenger), обозреватель сети (Computer Browser), DHCP client содержатся в одном ЕХЕ-файле с именем services. Один из способов обеспечения прозрачной защиты связан с заменой механизма предоставления функций «родного» API. С этого момента начинается анализ сетевых компонент, исполняющихся в привилегированном режиме - режиме ядра, и являющихся драйверами. Система ввода/вывода Windows NT является расширяемой. Один из методов расширения возможностей системы ввода/вывода - разработка и применение драйверов-фильтров.

Как уже отмечалось ранее, драйвер mup.sys вовлекается при попытке достижения удаленных разделяемых ресурсов, используя UNC имена Драйвер файловой системы обеспечивает пользователям механизм хранения и получения информации, реализуя возможности по созданию, модификации, удалению, разделению файлов и идентификации файлов по их символическим/логическим именам. Транспортные драйверы являются, фактически, стандартными драйверами промежуточного уровня и реализуют в своей верхней части стандартный интерфейс, со-тветствующий TDI спецификации. Реализация защиты с помощью перехвата функций NDIS - библиотеки Разработка NDIS драйверов промежуточного уровня - это один из хорошо документированных механизмов расширения возможностей системы ввода/вывода ОС Windows NT.

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

Драйвер протокола выделяет ресурсы под NDIS-пакеты, заполняет их данными и посылает вниз следующему NDIS-драйверу. Множество функций интерфейса верхнего уровня драйвера сетевой карты и функций интерфейса нижнего уровня драйвера протокола разработаны для поддержки асинхронных операций. Промежуточный NDIS-драйвер обычно экспортирует функции MiniportXxx на своем верхнем уровне и функции ProtocolXxx на своем нижнем уровне Точка входа DriverEntry Возможные обязательные и необязательные функции протокольной части промежуточного драйвера перечислены ниже Возможные обязательные и необязательные функции минипортовой части промежуточного драйвера перечислены ниже Пример реализации драйвера шифрования сетевых пакетов

Механизм идентификации и аутентификации в ОС Windows NT Основные сведения о процессе Winlogon Протокол взаимодействия процесса Winlogon и библиотеки GINA В ОС Windows NT для идентификации используется имя пользователя, а для подтверждения введенного имени - процедура аутентификации, использующая символьный пароль пользователя. Сетевая аутентификация пользователя осуществляется в процессе его подключения к серверу с целью получения доступа к сетевым ресурсам (например, к сетевому диску) Основные подходы к созданию изолированной программной среды При создании системы защиты информации (СЗИ) от несанкционированного доступа необходимо реализовать следующие функциональные подсистемы Реализация драйвером перехвата файловых операций основана на недокументированном механизме перехвата системных сервисов, описанном в разделе «Реализация защиты на уровне собственного API для ОС Windows NT». Собственный обработчик создания (открытия) файла может, например, проверить права доступа текущего процесса к создаваемому (открываемому) файлу Реализация драйвером функции получения имени обращающегося к ресурсу процесса необходима для создания системы защиты от НСД не ниже 3 класса по классификации Руководящих документов Государственной технической комиссии РФ Вывод сообщений на «синий» экран Процедура распределения IRP_MJ_DEVICE_CONTROL драйвера контроля доступа Модифицированная библиотека Gina

Сетевая архитектура Windows