Принципы построения Firewalls в операционных системах Windows NT и Linux

Размещено на http://www.allbest.ru

14

Размещено на http://www.allbest.ru

Введение

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

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

Механизмы для пропускания или блокировки трафика могут быть простыми фильтрами пакетов (packet filter), принимающими решение на основе анализа заголовка пакета, или более сложными proxy-серверами (application proxy), которые расположены между клиентом и внешним миром и служат в качестве посредника для некоторых сетевых служб.

Название «брандмауэр», казалось бы, относится к одному устройству или одной программе. Но во всех случаях, за исключением простейших, лучше представлять его как систему компонентов, предназначенных для управления доступом к вашей и внешним сетям на основе определенной политики безопасности. Термин «межсетевой экран» был принят для обозначения совокупности компонентов, которые находятся между сетью и внешним миром и образуют защитный барьер так же, как брандмауэр в здании создает преграду, предотвращающую распространение огня.

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

- кэширование (caching). Это свойство особенно характерно для сетей, содержащих Web-серверы с большим объемом информации, доступной из Internet.

- трансляция адреса (address translation). Настроенный соответствующим образом брандмауэр позволяет применять для внутренней сети любые IP-адреса. При этом снаружи виден только адрес брандмауэра;

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

- переадресация (address vectoring). Эта функция предоставляет брандмауэру возможность изменять, например, запросы HTTP так, чтобы они направлялись серверу не с указанным в пакете запроса IP-адресом, а с другим. Таким способом удастся распределять нагрузку между несколькими серверами, которые для внешнего пользователя выглядят как одиночный сервер.

В данной работе описываются основные методы реализации межсетевых экранов, как в Windows системах, так и в Linux. За основу взяты уже готовые программные продукты. В связи с тем, что многие межсетевые экраны являются коммерческим продуктами, то и получить их исходные достаточно не просто. Поэтому для Windows будет рассмотрен такой программный продукт с исходными кодами, как tdi_fw. А для Linux будет подробно описана архитектура модуля Netfilter и будет приведен механизм написания своего собственного брандмауэра, что затронет все основные принципы реализации его в данной операционной системе. Данные программные продукты достаточно функциональны и методы их реализации во многом схожи с коммерческими продуктами.

1. Принципы реализации Firewalls в Windows

1.1 Общая структура драйвера

Выполнением драйверов устройств управляет система ввода-вывода. Драйвер устройство состоит из набора процедур, вызываемых на различных этапах обработки запроса ввода-вывода. Основные процедуры драйвера показаны на рисунке 1.1.

Рис. 1.1 - Основные процедуры драйвера.

Инициализирующая процедура - выполняется при загрузке драйвера (DriverEntry).

Процедура добавления устройства - выполняя эту процедуру, драйвер обычно создает объект «устройство», представляющий аппаратное устройство.

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

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

Процедура обслуживания прерываний(ISR) - когда устройство генерирует прерывание, диспетчер прерываний ядра передает управление этой процедуре. Для выполнения остальной части обработки прерываний ISR ставит их в очередь DPC. ISR имеется лишь в драйверах устройств, управляемых прерываниями.

DPC-процедура - выполняет основную часть обработки прерываний, оставшуюся после выполнения ISR.

Хотелось бы заметить, что процедуры обслуживания прерываний и DPC-процедуры не используются при разработке Firewalls.

Объект «драйвер»

Размещено на http://www.allbest.ru

14

Размещено на http://www.allbest.ru

Рис. 1.2 - Объект драйвер.

На рисунке 1.2 показано как объект «устройство» ссылается на свой объект «драйвер».

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

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

С объектом «драйвер» нередко сопоставляются несколько объектов «устройство»

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

Открытие объекта «файл»

Размещено на http://www.allbest.ru

14

Размещено на http://www.allbest.ru

Рис. 1.3 - Открытие объекта «файл»

Объекты «файл» являются структурами режима ядра, которые точно соответствуют определению объектов в Windows: это системные ресурсы, доступные для совместного использования двум или нескольким процессам, у них могут быть имена, их безопасность обеспечивается моделью защиты объектов, и они поддерживают синхронизацию. Хотя большинство разделяемых ресурсов в Windows базируется в памяти, основная часть ресурсов, с которыми имеет дело подсистема ввода-вывода, размещается на физических устройствах или представляет их. Несмотря на эту разницу, операции над совместно используемыми ресурсами подсистемы ввода-вывода осуществляются как над объектами.

Объекты «файл» - представление ресурсов в памяти, которое обеспечивает чтение и запись данных в эти ресурсы.

На рисунке 1.3 иллюстрируется, что происходит при открытии файла:

Программа (1) вызывает из стандартной библиотеки функцию open, которая в свою очередь вызывает Windows-функцию Create-File (2). Далее DLL подсистемы Windows (в данном случае -- Kernel32.dll) вызывает функцию NtCreateFile из Ntdll.dll (3). Эта функция в Ntdll.dll содержит соответствующие команды, вызывающие переход в режим ядра в диспетчер системных сервисов, который и обращается к настоящей функции NtCreateFile (4) из Ntoskrnl.exe

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

1.2 Стек протоколов в операционной системе Windows

1.2.1Уровни OSI

Существует разделение протоколов на уровни. Задача каждого уровня в том, чтобы предоставлять сервисы более высоким уровням и скрывать от них конкретную реализацию этих сервисов. Дадим их краткое описание.

1) Физический уровень (physical layer). Передает биты по сетевому кабелю или другой физической несущей среде.

2) Канальный уровень (data-link layer). Пересылает низкоуровневые кадры данных, ждет подтверждений об их приеме и повторяет передачу кадров, потерянных в ненадежных линиях связи.

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

4) Транспортный уровень (transport layer). На передающей стороне разбивает сообщения на пакеты и присваивает им порядковые номера, гарантирующие прием пакетов в должном порядке. Кроме того, изолирует сеансовый уровень от влияния изменений в составе оборудования.

5) Сеансовый уровень (session layer). Управляет соединением взаимодействующих приложений, включая высокоуровневую синхронизацию и контроль за тем, какое из них «говорит», а какое «слушает».

6) Презентационный уровень (presentation layer). Отвечает за форматирование данных, в том числе решает, должны ли строки заканчиваться парой символов «возврат каретки/перевод строки» (CR/LF) или только символом «возврат каретки» (CR), надо ли сжимать данные, кодировать и т. д.

7) Прикладной уровень (application layer). Обрабатывает передачу данных между двумя сетевыми приложениями, включая проверку прав доступа, идентификацию взаимодействующих машин и инициацию обмена данными.

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

1.2.2 Сетевые компоненты Windows 2000

На рис. 1.1 представлена общая схема сетевых компонентов Windows 2000, их соответствие уровням модели OSI, а также протоколы, используемые различными уровнями. Можно заметить, что между уровнями OSI и реальными сетевыми компонентами нет точного соответствия. Некоторые компоненты охватывают несколько уровней. Ниже приводится список сетевых компонентов с кратким описанием.

- Сетевые API. Обеспечивают независимое от протоколов взаимодействие приложений через сеть. Сетевые API реализуются либо в режиме ядра и пользовательском режиме, либо только в пользовательском режиме. Некоторые сетевые API являются оболочками других API и реализуют специфическую модель программирования или предоставляют дополнительные сервисы. (Термином «сетевые API» обозначаются любые программные интерфейсы, предоставляемые сетевым программным обеспечением.)

- Клиенты TDI (Transport Driver Interface). Драйверы устройств режима ядра, обычно реализующие ту часть сетевого API, которая работает в режиме ядра. Клиенты TDI называются так из-за того, что пакеты запросов ввода-вывода (IRP), которые они посылают драйверам протоколов, форматируются по стандарту Transport Driver Interface (документированному в DDK). Этот стандарт определяет общий интерфейс программирования драйверов устройств режима ядра.

- Транспорты TDI. Представляют собой драйверы протоколов режима ядра и часто называются транспортами, NDIS-драйверами протоколов или драйверами протоколов. Они принимают IRP от клиентов TDI и обрабатывают запросы, представленные этими IRP. Обработка запросов может потребовать взаимодействия через сеть с другим равноправным компьютером; в таком случае транспорт TDI добавляет к данным IRP заголовки, специфичные для конкретного протокола (TCP, UDP, IPX), и взаимодействует с драйверами адаптеров через функции NDIS (также документированные в DDK). В общем, транспорты TDI связывают приложения через сеть, выполняя такие операции, как сегментация сообщений, их восстановление, упорядочение, подтверждение и повторная передача.

- Библиотека NDIS (Ndis.sys). Инкапсулирует функциональность для драйверов адаптеров, скрывая от них специфику среды Windows 2000, работающей в режиме ядра. Библиотека NDIS экспортирует функции для транспортов TDI, a также функции поддержки для драйверов адаптеров.

- Минипорт-драйверы NDIS. Драйверы режима ядра, отвечающие за организацию интерфейсов между транспортами TDI и конкретными сетевыми адаптерами. Минипорт-драйверы NDIS пишутся так, чтобы они были заключены в оболочку библиотеки NDIS. Такая инкапсуляция обеспечивает межплатформенную совместимость с потребительскими версиями Microsoft Windows. Минипорт-драйверы NDIS не обрабатывают IRP, а регистрируют интерфейс таблицы вызовов библиотеки NDIS, которая содержит указатели на функции, соответствующие функциям, экспортируемым библиотекой NDIS для транспортов TDI. Минипорт-драйверы NDIS взаимодействуют с сетевыми адаптерами, используя функции библиотеки NDIS, которые вызывают соответствующие функции HAL.

Фактически четыре нижних сетевых уровня часто обозначают собирательным термином «транспорт», а компоненты, расположенные на трех верхних уровнях, - термином «пользователи транспорта».



Рис. 1.4 - Модель OSI и сетевые компоненты Windows 2000

1.3 Технологии сетевой фильтрации трафика в Windows

Можно сразу заметить, что хоть Windows 9x/ME и Windows NT/XP и предусматривают похожий сокетный интерфейс и NDIS архитектуру, и даже реализуют двоичные совместимые miniport драйвера для сетевых интерфейсов, их внутренняя сетевая подсистема значительно разнится. Но все-таки мы можем подразделить их обе на некоторые общие части:

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

- Сетевой протокол драйверов. Сетевой протокол драйверов (например, TCPIP) на его нижней границе использует библиотечную функцию NDIS для сетевого доступа и может обеспечивать Transfer Driver Interface (TDI) на верхней границе. Экспортируемый TDI интерфейс может быть использован большим количеством TDI-клиентов, например, частью сокетной разработки afd.sys (NT/2000/XP). Использование TDI имеет много общего с сокетным интерфейсом, например, следующая последовательность запросов устанавливает соединение с удаленной системой(специфика NT):

1. TDI-клиент формирует пакет TDIIRP типа address open для размещения адреса. TDI-транспорт возвращает файловый объект, известный как объект-адрес, представляющий адрес. Этот шаг эквивалентен использованию функции bind в Winsocket.

2. TDI-клиент размещает и формирует пакет TDI IRP типа connection open, и TDI-транспорт возвращает файловый объект, известный как объект-соединение, представляющий соединение. Этот шаг эквивалентен использованию функции socket в Winsocket.

3. TDI-клиент ассоциирует объект-соединение с объектом-адресом с помощью пакета TDI IRP типа associate address.

4. TDI-клиент, принимающий удаленное соединение, выпускает TDI IRP пакет типа listen, определяющий число соединений, поддерживаемых для объекта-соединения, и затем выпускает пакет TDI IRP типа accept, который завершается, когда удаленная система установит соединение. Эта операция эквивалентна использованию функций listen и accept в Winsocket.

5. TDI-клиент, который хочет установить соединение с удаленным сервером, выпускает TDI IRP пакет типа connect, определяя объект-соединение, который TDI-транспорт завершает, когда установится соединение. Выпуск TDI IRP пакета типа connect эквивалентно использованию функции connect в Winsocket.

- DLL пользовательского режима, которые образуют Windows Socket интерфейс. К ним относятся ws2_32.dll, msafd.dll, wshtcpip.dll и т.п.

Поподробнее остановимcя на интерфейсе TDI.

1.4 TDI

Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI).

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

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

Так как TDI является относительно новым сетевым интерфейсом, и большинство приложений разработаны для использования других существующих стандартных интерфейсов, таких как NetBIOS и WinSockets, то Windows NT включает эмуляторы для этих двух популярных интерфейсов. Части уровня ядра этих эмуляторов, являющиеся драйверами файловых систем, отображают родные функции с соответствующими параметрами в одну или несколько TDI-функций, а затем вызывают соответствующие драйверы транспортов через TDI.

Интерфейс TDI включает следующее:

1. Множество стандартных диспетчерских точек входа, обеспечиваемых транспортным драйвером, к которому TDI-клиент может обратиться с запросом ввода/вывода.

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

3. Параметры, структуры, IOCTLs и правила, ассоциированные с процедурами транспорта и его клиента.

4. Множество функций вида TdiXxx, которые транспорт и его клиент могут вызывать для взаимодействия друг с другом.

5. Множество макросов и функций вида TdiBuildXxx, которые TDI-клиент может использовать, чтобы обеспечить принятие запросов нижележащим транспортом.

1.5 NDIS

firewalls windows linux трафик

1.5.1 Описание NDIS

NDIS включает стандарты для драйверов сетевых карт локальных и глобальных сетей (LAN NIC driver и WAN NIC driver), и стандарты для промежуточных драйверов (intermediate driver), располагающихся между драйверами протоколов и драйверами сетевых карт.

Вместо того чтобы писать несколько транспортно-зависимых драйверов, производители сетевого оборудования реализуют интерфейс NDIS на самом верхнем уровне одного драйвера сетевой карты. Это позволяет любому драйверу протокола работать с данной сетевой картой, вызывая функции этого интерфейса. Таким образом, пользователь может работать и по протоколу TCP/IP, и по протоколу NetBEUI, при помощи одной сетевой карты и одного драйвера этой сетевой карты. Библиотека NDIS является драйвером, реализующим взаимодействие между компонентами, которые обращаются к ней, такими как: драйверы транспортов, NDIS драйверы промежуточного уровня, драйвер ndiswan.sys, драйвер ndistapi.sys, NDIS драйверы сетевых карт локальных и глобальных сетей. Интерфейс, реализуемый NDIS библиотекой, является «call and return» интерфейсом (асинхронным интерфейсом). Драйверы вызывают функции, расположенные в NDIS библиотеке, a NDIS библиотека может в свою очередь вызывать функции из других драйверов, чтобы выполнить операцию. Пакеты запроса ввода/вывода (IRP) не используются в NDIS спецификации.

Так как NDIS драйверы существуют в среде, созданной NDIS библиотекой, то структура и интерфейс, используемые этими драйверами, определяются NDIS библиотекой. Это позволяет NDIS драйверам быть переносимыми между различными операционными системами, поддерживающими данную спецификацию.

Цели NDIS библиотеки следующие:

· Изолировать NDIS драйверы сетевых карт и промежуточные драйверы от операционной системы. NDIS библиотека экспортирует множество стандартных функций и макросов, которые скрывают детали операционной системы, и используются всеми NDIS драйверами. NDIS драйверы могут вызывать только те функции, которые обеспечивает NDIS библиотека. Например, создание таймера для целей синхронизации, или создание связанного списка осуществляется через NDIS. Требование к разработчикам применять вызовы NDIS функций позволяет сделать код переносимым между операционными системами фирмы Microsoft, которые поддерживают NDIS.

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

· Обеспечивать добавление заголовков к данным пользователя без необходимости их перекопирования, во время передачи данных по стеку сетевых драйверов. Во время перемещения сетевого сообщения по стеку драйверов сверху вниз, на каждом уровне к первоначальному сообщению может быть добавлен свой заголовок (реже хвост). NDIS спецификация делает возможным добавление подобных структур спереди или сзади без необходимости перекопирования первоначального сообщения. Эта возможность построения сетевого сообщения без перекопирований данных позволяет достигать высокой производительности при передаче данных.

NDIS-библиотека получает IRP-пакеты от TDI-транспортов и транслирует их в вызовы функций NDIS-драйверов. Для передачи данных между NDIS-драйверами пакеты IRP не используются. Вместо них используются, например, NDIS-пакеты.

1.5.2 Структура NDIS-пакетов

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

Описатель NDIS-пакета является структурой NDIS_PACKET, содержащей, помимо прочих, следующие поля (см. рис. 1.2):

1. закрытые области данных для драйвера минипорта и драйвера протокола;

2. флаги;

3. число физических страниц, содержащих пакет;

4. полную длину пакета;

5. указатели на описатели первого и последнего буфера пакета.

Описатель буфера является структурой NDIS_BUFFER (в действительности, NDIS_BUFFER определяется как тип MDL), содержащей, помимо всего прочего, следующее:

1. начальный виртуальный адрес буфера;

2. смещение буфера относительно страницы;

3. длину буфера в байтах;

4. указатель на описатель следующего буфера (или NULL, если его нет).

Основные функции для работы с NDIS-пакетами и NDIS-буферами:

1. NdisAllocatePacketPool - размещает и инициализирует пространство для пула описателей пакетов;

2. NdisAllocatePacket - размещает и инициализирует описатель пакета;

3. NdisReinitializePacket - удаляет все присоединенные буфера из пакета и инициализирует его для повторного использования;

4. NdisCopyFromPacketToPacket;

5. NdisQueryPacket - возвращает информацию о пакете;

6. NdisFreePacket;

7. NdisAllocateBufferPool - возвращает указатель, с помощью которого затем можно разместить описатели буферов, вызвав NdisAllocateBufFer;

8. NdisAllocateBuffer-создает описатель буфера;

9. NdisChainBufferAtBack (NdisChainBufferAtFront) - присоединяет описатель буфера в хвост (в начало) цепи описателей буферов, присоединенных к пакету;

10. NdisCopyBuffer;

11. NdisFreeBuffer;

12. NdisGetFirstBufferFromPacket - возвращает указатель на буфер первый в цепи буферов пакета;

13. NdisUnchainBufferAtBack, NdisUnchainBufferAtFront.

Рис. 1.5 - Структура NDIS-пакета и NDIS-буфера

1.5.3 Завершающие функции

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

Асинхронный ввод/вывод поддерживается с помощью использования завершающих функций. Когда драйвер протокола вызывает NDIS, чтобы отправить пакет (что приводит в результате к вызову функции MiniportSend в драйвере сетевой карты), драйвер сетевой карты может попытаться завершить эту передачу немедленно и вернуть в качестве результата соответствующее значение статуса операции. Для синхронных операций вероятным значением статуса могут быть NDIS_STATUS_SUCCESS (если операция завершилась успешно) и NDIS_STATUS_RESOURCES или NDIS_STATUS_FAILURE в случае неудачи. А может, тут же вернуть управление со значением статуса операции NDIS_STATUS_PENDING.

Но операция отправки пакета в сеть может потребовать некоторого времени для ее завершения. За это время драйвер сетевой карты (или NDIS) поставит пакет в очередь, и будет ожидать до тех пор, пока сетевая карта не просигнализирует результат операции отправки. Функция MiniportSend драйвера сетевой карты может управлять этой операцией отправки асинхронно, путем возвращения значения статуса NDIS_STATUS_PENDING. Когда драйвер сетевой карты завершит отправку, он вызовет завершающую функцию NdisMSendComplete, передав в эту функцию указатель на отосланный NDIS-пакет. Эта информация передается драйверу протокола, сигнализируя завершение операции отправки.

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

1.5.4 Точки входа промежуточного NDIS-драйвера

Промежуточный NDIS-драйвер обычно экспортирует функции MiniportXxx на своем верхнем уровне и функции ProtocolXxx на своем нижнем уровне (см. рис. 1.6).

Реже промежуточный драйвер может экспортировать MiniportXxx функции на своем верхнем уровне, а в своей нижней части предоставлять частный закрытый интерфейс нижележащему драйверу, не являющемуся NDIS-драйвером. Например, промежуточный драйвер может управлять сетевыми запросами ввода/вывода для устройства, соединенного с последовательным портом. Подобный промежуточный драйвер будет экспортировать ряд функций MiniportXxx, чтобы взаимодействовать с NDIS в своей верхней части, а в своей нижней части использовать стандартные пакеты запроса ввода/вывода (IRP), чтобы взаимодействовать с драйвером последовательного устройства.

Если реализуемый промежуточный драйвер должен поддерживать ориентированный на соединение (Connection-Oriented) интерфейс нижнего уровня, либо поддерживать работу с NDISWAN, то необходимо реализовать как ряд дополнительных точек входа, так и изменить некоторые из описанных в этом разделе точек входа.

Рис. 1.6 - Расположение промежуточных NDIS-драйверов

1.5.5 Точка входа DriverEntry

Точка входа DriverEntry промежуточного драйвера должна по крайней мере:

1. вызвать NdisMInitializeWrapper и сохранить возвращенный описатель NdisWrapperHandle.

2. вызвать функцию NdisIMRegisterLayeredMiniport, чтобы зарегистрировать свои точки входа MiniportXxx;

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

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

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

1.5.6 Точки входа ProtocolXxx

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

1. ProtocolBindAdapter - обязательная функция, вызываемая NDIS, чтобы попросить промежуточный драйвер привязаться к нижележащей реальной или виртуальной сетевой карте, чье имя передано в качестве параметра этой функции.

2. ProtocolUnbindAdapter - обязательная функция, вызываемая NDIS, чтобы закрыть соединение с нижележащей реальной или виртуальной сетевой картой, чье имя передано в качестве параметра этой функции.

3. ProtocolOpenAdapterComplete - обязательная функция. Если вызов функции NdisOpenAdapter промежуточным драйвером привел к возврату статуса NDIS_STATUS_PENDING, то в последствии будет вызвана функция ProtocolOpenAdapterComplete, чтобы завершить присоединение.

4. ProtocolCIoseAdapterComplete - обязательная функция. Если вызов функции NdisCloseAdapter промежуточным драйвером привел к возврату статуса NDIS_STATUS_PENDING, то в последствии будет вызвана функция ProtocolCloseAdapterComplete, чтобы завершить отсоединение.

5. ProtocolReceive - обязательная функция. ProtocolReceive вызывается с указателем на буфер lookahead, содержащий данные, полученные из сети. Если этот буфер содержит не весь сетевой пакет, то ProtocolReceive вызывает NdisTransferData с описателем пакета для того, чтобы получить оставшуюся часть сетевого пакета. Если нижележащий драйвер вызвал NdisMIndicateReceive Packet для указания о получение сетевого пакета, то буфер lookahead, переданный ProtocolReceive, всегда будет содержать весь сетевой пакет.

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

7. ProtocolReceiveComplete - это обязательная функция. Она вызывается, если обработка какого-либо из пакетов, попавших перед этим в ProtocolReceive, была отложена.

8. ProtocolTransferDataComplete - это обязательная функция, если ProtocolReceive когда-либо вызывает NdisTransferData. Если предыдущий вызов NdisTransferData с просьбой скопировать оставшуюся часть полученного пакета вернул статус NDIS_STATUS_PENDING, то ProtocoITransferDataCompIete вызовется, когда операция передачи оставшейся части будет завершена.

9. ProtocolResetComplete - это обязательная функция. Она вызывается, если операция сброса, начатая с помощью вызова функции NdisReset, вернувшей статус NDIS_STATUS_PENDING, была завершена. Обычно промежуточные драйверы не вызывают NdisReset, но драйверы выше их могут вызвать эту функцию, таким образом, промежуточный драйвер должен суметь передать такой запрос нижележащим NDIS-драйверам.

10. ProtocolRequestComplete - это обязательная функция. Она вызывается по завершении операции получения/установки параметров, начатой с помощью вызова функции NdisRequest, вернувшей статус NDIS_STATUS_PENDING.

11. ProtocolSendComplete - обязательная функция. Она вызывается для каждого пакета, переданного с помощью вызова функции NdisSend, вернувшей статус операции отправки NDIS_STATUS_PENDING. Если был отослан сразу массив пакетов путем вызова NdisSendPackets, то ProtocolSendComplete будет вызвана для каждого пакета из массива. Промежуточный драйвер может определить окончательный статус операции отправки только из параметра статуса у функции ProtocolSendComplete.

12. ProtocoIStatus - обязательная функция. Она вызывается библиотекой NDIS для сообщения об изменении статуса, инициированного нижележащим драйвером сетевой карты.

13. ProtocoIStatusComplete - обязательная функция. Она вызывается библиотекой NDIS, чтобы сигнализировать, что изменение статуса, о котором перед этим сообщалось в ProtocoIStatus, теперь завершилось.

14. ProtocolPnPEvent - это обязательная функция. NDIS вызывает ProtocolPnPEvent, чтобы сигнализировать о событии Plug and Play или о событии управления питанием.

15. ProtocolUnload - это необязательная функция. NDIS вызывает ProtocolUnload в ответ на требование пользователя удалить промежуточный драйвер. ProtocolUnload выполняет определенные драйвером операции удаления.

1.5.7 Точки входа MiniportXxx

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

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

2. Miniportlnitialize - эта функция вызывается в результате вызова промежуточным драйвером функции NdisIMInitializeDeviceInstance, чтобы инициализировать минипортовые операции для инициализируемой виртуальной сетевой карты.

3. MiniportQuerylnformation - эта функция получает запросы вида ОID_ХХХ, организованные (или просто передаваемые далее) вышележащим драйвером, вызвавшем NdisRequest с типом запроса NdisRequestQuerylnformation.

4. MiniportReset. NDIS может вызвать эту функцию промежуточного драйвера по приказу вышележащего драйвера протокола, вызвавшего NdisReset. Обычно, однако, драйвер протокола не инициирует сброс. NDIS, главным образом, инициирует сброс нижележащего драйвера сетевой карты и вызывает функции промежуточного драйвера ProtocolStatus и ProtocolStatusComplete, для того, чтобы информировать промежуточный драйвер о том, что нижележащий минипорт сбрасывает свою сетевую карту.

5. MiniportSetlnformation. Эта функция обрабатывает запросы вида OID_ХХХ, сделанные (или просто передаваемые далее) вышележащим драйвером, который вызвал NdisRequest с типом запроса NdisRequestSet Information.

6. MiniportSend. NDIS вызывает эту функцию для передачи одного пакета для нижележащего драйвера сетевой карты (или драйвера устройства). Функция MiniportSend (или функция MiniportWanSend) требуется, если промежуточный драйвер не обеспечил функцию MiniportSendPackets. Но лучше, чтобы всегда обеспечивалась функция MiniportSendPackets, чем функция MiniportSend (если только промежуточный драйвер не располагается всегда между драйверами, передающими по одному пакету за раз, или, если он не привязывается к нижележащему WAN NIC драйверу).

7. MiniportSendPackets. Эта функция получает массив из одного или более указателей на описатели пакетов для передачи в сеть. Лучше, чтобы каждый промежуточный драйвер обеспечивал функцию MiniportSendPackets, чем MiniportSend, если только он не привязывается к нижележащему WAN NIC драйверу, и должен при этом обеспечить функцию MiniportWanSend. Функция MiniportSendPackets обеспечивает лучшую производительность в независимости от того, располагается ли промежуточный драйвер над драйвером сетевой карты, который может передавать по несколько пакетов за раз, или только по одному пакету. И вне зависимости от того, располагается ли промежуточный драйвер под драйвером протокола, отправляющим по несколько пакетов за раз, или только по одному пакету.

8. MiniportTransferData. Эта функция вызывается, чтобы передать оставшуюся часть полученного из сети пакета, ранее представленного в буфере lookahead, переданном промежуточным драйвером в функцию NdisMXxxIndicate Receive. Этот пакет может быть конвертированным пакетом, полученным перед этим в

9. функции промежуточного драйвера ProtocolReceive или ProtocolReceivePacket. Функция MiniportTransferData требуется, если промежуточный драйвер представляет вышележащим драйверам полученные из сети пакеты путем вызова любой зависимой от среды функции NdisMXxxIndicate Receive, кроме NdisMWan IndicateReceive. Если промежуточный драйвер всегда представляет пакеты путем вызова NdisMIndicateReceivePacket, то ему не нужно обеспечивать функцию MiniportTransferData.

10. MiniportReturnPacket. Эта функция получает возвращенный описатель пакета, который перед этим был представлен вышележащему драйверу путем вызова NdisMIndicateReceivePacket, тем самым возвращается контроль над ресурсами, представленными вышележащему драйверу. После того как каждое такое представление было обработано вышележащим драйвером, описатель пакета, размещенный промежуточным драйвером, и ресурсы, которые он описывает, будут возвращены функции MiniportReturnPacket, Функция Miniport ReturnPacket не нужна, если промежуточный драйвер всегда представляет пакеты наверх путем вызова зависящей от среды функции NdisMA3cdndicate Receive, или, если он всегда устанавливает статус в блоке данных ООВ, ассоциированном с каждым описателем пакета, в NDIS_STATUS_RESOURCES, прежде чем вызвать NdisMIndicateReceivePacket.

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

1.6 Пользовательский режим фильтрации трафика

1) Winsock Layered Service Provider (LSP). Этот метод хорошо задокументирован в MSDN. К преимуществам стоит отнести то, что позволяет отследить процесс сделавший вызов к библиотеке Windows Sockets. Это может быть использовано для таких задач, как QOS (Quality Of Service), шифрование потоков данных и т.п. Однако не стоит забывать, что TCPIP.SYS может быть вызван, минуя Windows Sockets через TDI (так что метод фактически бесполезен для защиты от вирусов и тому подобного). Так же этот метод абсолютно бесполезен для фильтрации пакетов на маршрутизаторе, так как маршрутизация пакетов осуществляется драйвером протокола TCP/IP (TCPIP.SYS) и не доходит до сокетов.

2) Windows 2000 Packet Filtering Interface. Windows 2000 предоставляет API, используя который приложение пользовательского режима может быть установлено как «фильтрующий дескриптор», который будет использован TCPIP для фильтрации пакетов. Однако правила фильтрации сильно ограничены (pass/drop на основе IP адресов и портов(диапазонов портов)). Данный подход может быть использован только на машинах с Windows 2000 и выше.

3) Substitution of Winsock DLL. Этот метод упомянут главным образом в силу исторических причин. Использовать его в настоящее время конечно возможно, но пожалуй неразумно.

4) Global hook of all “dangerous” functions (starting from Windows sockets, DeviceIoControl and etc). Данный подход достаточно непрост в реализации и требует внимательной реализации, так как может привести к существенным нарушениям в стабильности и безопасности системы.

1.7 Фильтрация трафика на уровне ядра

1) Kernel-mode sockets filter. Эта технология применима к Windows NT/2000. Она основывается на перехвате вызовов от msafd.dll (нижнего уровня пользовательского режима Windows Sockets DLL) к модулю afd.sys режима ядра (TDI-клиент, уровень ядра часть Windows Sockets). Этот метод интересен, но его возможности не намного шире, чем у LSP.

2) TDI-filter driver. Эта технология применима как к Windows 9x/ME так и к Windows NT/2000, хотя конкретная реализация значительно отличается. Применительно к Windows NT/2000, в случае TCP/IP фильтрации необходимо перехватывать (используя IoAttachDevice) все вызовы, адресованные устройствам (devices), созданным модулем tcpip.sys (DeviceRawIp, DeviceUdp, DeviceTcp). Существует ряд утилит, например Device Filter utility, которые показывают все запросы к транспорту. Это технология применяется и в ряде коммерческих продуктов (например, в Outpost Firewall).

3) NDIS Intermediate Driver (NDIS Драйвер промежуточного уровня). Microsoft ввел этот класс драйверов как раз для нужд подобных нашим, однако их функциональность в операционных системах Windows 98/ME/NT оставляет желать лучшего, а в Windows 95 отсутствует вовсе. В частности они очень неудобны в инсталляции и для конечного пользователя.

4) Windows 2000 Filter-Hook Driver. Применим только в Windows 2000 и выше. Данный метод хорошо описан в документации DDK. Проблема данного метода в том, что Filter-Hook Driver стартует достаточно высоко в сетевом стеке и не рекомендуют его использовать, так как возможны конфликты с операциями Internet Connection Sharing (ICS) и другими персональными firewalls.

5) NDIS Hooking Filter Driver. Техника данного метода основана на перехвате некоторого подмножества NDIS функций, которые в дальнейшем позволяют пошагово наблюдать регистрацию всех инсталлированных протоколов и открытие ими сетевых интерфейсов. Среди преимуществ данного метода следует упомянуть простоту установки и прозрачность поддержки Dial-Up интерфейсов, которые в случае intermediate драйвера требуют дополнительных ухищрений.

Более подробно остановимся на TDI-filter драйвере.

1.8 Реализация защиты на уровне транспортного драйвера (TDI-filter driver)

Транспортные драйверы являются, фактически, стандартными драйверами промежуточного уровня и реализуют в своей верхней части стандартный интерфейс, соответствующий TDI спецификации. Этот интерфейс в основном базируется на получении и обработке пакетов IRP_MJ_INTERNAL_DEVICE_CONTROL, содержащих различные значения контрольных кодов TDI_XXX, определяемых TDI спецификаций. В своей нижней части TDI драйвер взаимодействует с NDIS библиотекой.

Рис. 1.7 - Реализация защиты на уровне транспортного драйвера

Можно реализовать драйвер-фильтр, который будет присоединяться к объектам-устройствам, создаваемым драйвером транспорта. Например, к объектам-устройствам \Device\Tcp и \Device\Udp, создаваемым драйвером транспорта TCP/IP.

В связи с тем, что драйвер транспорта должен предоставлять единый, хорошо документированный интерфейс, облегчается задача его разработки. Вместе с тем, TDI-интерфейс является расширяемым интерфейсом, так как:

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

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

· TDI определяет механизм, с помощью которого драйвер транспорта может сигнализировать клиенту об интересующих клиента событиях, произошедших в сети (без предварительного запроса от клиента). Это происходит с помощью вызова драйвером транспорта функций, указатели на которые передаются TDI-клиентом драйверу транспорта в самом начале сетевых операций в пакете IRP_MJ_INTERNAL_DEVICE_CONTROL с контрольным кодом TDI_SET_EVENT_HANDLER, и регистрируются драйвером транспорта. TDI-клиент даже может использовать подобный механизм функций обратного вызова в качестве альтернативы обычным пакетам запросов к транспорту с контрольными кодами TDI_XXX. Когда драйвер транспорта вызывает подобную функцию, он может передать TDI-клиенту в качестве параметров некоторое ограниченное количество данных. При этом, если существует драйвер-фильтр, присоединенный к драйверу транспорта, то он не получит возможности проконтролировать эти данные.

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

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

1.9 NDIS Hooking Filter Driver в Windows NT/2000

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

1.9.1 Перехват основных функций

Реализация NDIS в Windows 9x/ME и NT/2000 различная. В нашем случае (NT/2000) достаточным будет перехват 4 функций:

- NdisRegisterProtocol

- NdisDeregisterProtocol

- NdisOpenAdapter

- NdisCloseAdapter

Перехват NdisSend уже не будет иметь смысла. Так если посмотреть в ndis.h, можно увидеть, что в нашем случае данная функция определена как макрос. Однако эти 4 функции должны быть перехвачены каким-либо образом. Для их перехвата желательно иметь представление о PE-формате. Сущность технологии сводится к тому, что необходимо найти в памяти заголовок образа ndis.sys и подкорректировать его таблицу экспорта, изменяя адреса наших четырех функций. Все необходимые структуры для операций с PE-образом находятся в файле winnt.h из DDK. В Windows NT 4.0 этот способ будет работать хорошо, однако, запустив этот драйвер под Windows 2000 или XP мы увидим «синий экран». Проблема заключается в том, что Windows 2000 защищает образ ядра от возможных модификаций. Существует два способа решения этой проблемы:

1) Отключить защиту образа ядра через реестр. Для этого необходимо создать в ветке HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\ MemoryManagement ключевой параметр REG_DWORD с именем EnforceWriteProtection и значением 0.

2) Сбросить биты Защиты от Записи в регистре CR0, перед обновлением таблицы экспорта. Это можно выполнить, например, таким способом:

mov ebx, cr0; для получения текущего состояния Cr0

push ebx; для сохранения его

and ebx, ~0x10000; для сброса WP бит

mov cr0, ebx; для отключения защиты от записи

Здесь мы модифицируем таблицу экспорта....

pop ebx;

mov cr0, ebx; для воостановления предыдущего состояния процессора

Daniel Lanciany в его варианте перехвата NDIS драйвера пошел по другому пути. Он обновлял начало функций, вставляя в них переход к его коду. В его обработчике он восстанавливал тело перехватываемой функции, осуществляя необходимые операции в обработке вызовов, вызывал восстанавливаемые функции, и после возвращения из него снова модифицировал начало. Так как вызов этих четырех функций не очень част, то и метод не значительно хуже, чем модификация таблицы экспорта. Но есть значительный недостаток. Так же как и в случае с перехватом DLL функций (hooking DLL functions) в пользовательском режиме, это может вызвать проблемы на SMP платформах.

1.9.2 Дальнейшие действия в реализации NDIS Hooking Filter Driver

Обработчик NdisRegisterProtocol подвергается воздействию входящим трафиком (обычно необходимо изменять не только ReceiveHandle, но и особый TransferDataCompleteHandler). Следует обратить внимание на то, что если драйвер TCP/IP для 9x/ME ("MSTCP") регистрирует один протокол и этот протокол непосредственно открывает оба Ethernet адаптера и PPPMAC (эмуляцию Ethernet поверх Dial-up), то в случае NT/2000/XP TCP/IP фактически состоит из двух драйверов TCPIP.SYS ("TCPIP") и WANARP.SYS ("TCPIP_WANARP" в 2000/XP, "RASARP" в NT 4.0) и этот второй протокол открывает эмуляцию \DEVICE\NDISWANIP (эмулируя верхний Ethernet интерфейс в промежуточном NDISWAN драйвере).

Дальнейшая операция, соблюдаемая многими, очень похожа на написание драйвера сетевого протокола. Достаточно затронуть момент относительно нового обработчика для NdisOpenAdapter. Одним из возвращаемых параметров этой функции (NdisBindingHandle) обычно является указатель на структуру NDIS_OPEN_BLOCK. Эта структура описана в ndis.h файле, но, к сожалению не задокументирована. Это является важным, так как предоставляет доступ к исходящему из протокола трафику (поля SendHandler, SendPacketsHandler, and TransferDataHandler). Очевидно, теперь необходимо транспортировать в протокол наш вариант NDIS_OPEN_BLOCK, предварительно сохранив первоначальный. Следующий фрагмент кода берется из нового обработчика NdisOpenAdapter:

// после вызова первоначального NdisOpenAdapter

NdisAcquireSpinLock (&g_OpenAdapterLock);

if ((*Status == NDIS_STATUS_SUCCESS)||

(*Status == NDIS_STATUS_PENDING)

)

{

// Сохранение старого связанного дескриптора и выбор среднего адаптера.

pAdapter -> m_NdisBindingHandle = *NdisBindingHandle;

pAdapter -> m_Medium = MediumArray[*SelectedMediumIndex];

// поддержка адаптеров ethernet и \DEVICE\NDISWANIP

if (!((pAdapter -> m_Medium == NdisMediumDix) ||

(pAdapter -> m_Medium == NdisMedium802_3)||

(pAdapter -> m_Medium == NdisMediumWan)))

{

// Освобождение уже размещенных ресурсов

AF_FreeAdapterEntry (pAdapter);

NdisReleaseSpinLock (&g_OpenAdapterLock);

return;

}

// Копирование Real Open Block в наше месторасположение

NdisMoveMemory (

&pAdapter -> m_OpenBlock,

*NdisBindingHandle,

sizeof(NDIS_OPEN_BLOCK)

);

// Замена NDIS_OPEN_BOCK

*NdisBindingHandle = &pAdapter->m_OpenBlock;

// Главная работа для окончания инициализации адаптера

if ((*Status == NDIS_STATUS_PENDING)&&

(pAdapter->m_dwAdapterState == ADAPTER_STATE_COMPLETE_FAILED)

)

{

AF_FreeAdapterEntry (pAdapter);

NdisReleaseSpinLock (&g_OpenAdapterLock);

return;

}

// Указатели на наш OPEN_BLOCK

pOpenBlock = (PNDIS_OPEN_BLOCK)*NdisBindingHandle;

pAdapter->m_MacBindingHandle = pOpenBlock->MacBindingHandle;

// Замена некоторых реальных обработчиков на свои

pAdapter->m_SendHandler = pOpenBlock->SendHandler;

pOpenBlock->SendHandler = OBF_SendHandler;

pAdapter->m_SendPacketsHandler = pOpenBlock->SendPacketsHandler;

pOpenBlock->SendPacketsHandler = OBF_SendPacketsHandler;

pAdapter->m_RequestHandler = pOpenBlock->RequestHandler;

pOpenBlock->RequestHandler = OBF_RequestHandler;

pAdapter->m_TransferDataHandler = pOpenBlock->TransferDataHandler;

...

1.9.3 Выводы по поводу организации NDIS Hooking Filter Driver в Windows NT/2000

Таким образом, драйвер с минимальной функциональностью получается достаточно небольшим и не сложным в реализации. Инсталляция его тоже не вызывает проблем, поскольку как и в случае с драйвером для Windows 9x/ME требует добавления всего нескольких ключей в реестр.

Помимо описанного статического способа перехвата сервисов библиотеки NDIS, который требует загрузки драйвера на этапе старта операционной системы и как таковой этот драйвер не может быть выгружен из памяти, существует еще один динамический подход. Этот метод работает и под Windows 9x/ME и под NT/2k/XP, и хотя в первом случае придется писать VxD, а во втором kernel-mode драйвер, принцип одинаков. Среди существующих на рынке продуктов он применяется (помимо контроля TDI и всех запускающихся процессов в системе) в довольно известном firewall'е ZoneAlarm (с широко разрекламированной технологией TrueVector). Суть подхода в том, что мы регистрируем пустой протокол (вызовом NdisRegisterProtocol), т.е. протокол хендлеры которого ничего не делают, самым сложным из них может быть ProtocolReceive, который возвращает NDIS_STATUS_NOT_ACCEPTED. Этот протокол служит одной простой цели, получить NdisProtocolHandle. В действительности, это указатель на внутреннюю структуру NDIS NDIS_PROTOCOL_BLOCK, которая, к сожалению, отличается от одной версии NDIS к другой и не всегда встречается в ndis.h. Так вот помимо всего прочего, эта структура содержит в себе NDIS_PROTOCOL_CHARACTERISTICS с адресами всех ProtocolXXX функций, список NDIS_OPEN_BLOCK (эта структура в свою очередь содержит обработчики Send/SendPackets/Request) всех сетевых интерфейсов открытых данным протоколом и указатель на следующую структуру NDIS_PROTOCOL_BLOCK. Дальнейшее практически очевидно, двигаясь по списку зарегистрированных протоколов, мы подставляем свои обработчики там, где это необходимо. Однако, несмотря на кажущуюся простоту, метод этот совсем не такой простой и требует большой осторожности, так как мы вмешиваемся в функциональность уже работающей системы.