Диссертация

Долгополов А.

Фотогалерея

Разработчик

Долгополов Александр Геннадиевич

dolgopolov@maus.dn.ua

Группа

ПО-99а

Тема магистерской работы

«Исследование методов анализа пакетов в компьютерных сетях»

Руководитель

доцент, к.т.н

Ладыженский Юрий Валентинович

Автореферат магистерской выпускной работы

Введение

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

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

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

Архитектура winpcap

Winpcap – архитектура, которая добавляет к операционным системам класса Win32 возможность захватывать данные из сети, используя сетевой адаптер компьютера. Кроме того, она предоставляет программам API высоко уровня, который делает простым использование её низкоуровневой функциональности. Она объединяет в себе 3 компоненты: драйвер захвата пакетов, низкоуровневую динамическую библиотеку, статическую библиотеку высокого уровня.

Система захвата

1. Общая структура

Чтобы захватывать пакеты, идущие по сети, программа захвата должна взаимодействовать непосредственно с сетевым оборудованием. По этой причине ОС должна предоставлять набор действий по коммуникации и получению данных от сетевого адаптера. Задача этих примитивов – захват пакетов из сети и передача их запросившим программам. Здесь существует большая системная зависимость, поэтому реализация подобных действий различна на разных ОС. Захват пакетов должен быть быстр и рационален, поскольку эти действия, например, в высокоскоростной LAN с большой загруженностью траффика, должны минимизировать потери пакетов и использовать минимум системных ресурсов.

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

WinDump.exe – верхний уровень структуры захвата, который состоит из модуля, исполняющегося в режиме ядра, и модуля, исполняющегося в пользовательском режиме.

Эти модули имеют разное предназначение, независимы и изолированы друг от друга. Первый исполняется в 0-м кольце на архитектуре Intel, в то время как 2-ой в 3-ем кольце как обычная программа Windows. Структура системы захвата пакетов через сетевой адаптер программой WinDump показана на следующей

схеме:

Рис. 1 Структура системы захвата

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

Драйвер захвата пакетов – низший программный уровень иерархии захвата. Эта часть работает в «режиме ядра» системы и взаимодействует с сетевым адаптером для получения пакетов. Он предоставляет программным приложениям набор функций для чтения и записи данных адаптера.

PACKET.DLL – работает в пользовательском режиме, но отдельно от приложений захвата. Это динамически подключаемая библиотека, которая изолирует приложения захвата от драйвера, обеспечивая системо-независмость для захвата.Она тем самым позволяет WinDump исполнятся на различных Windows системах без перекомпиляции.

PCAP библиотека или libpcap – статически присоединяемая библиотека, которая является частью приложения захвата пакетов. Она использует сервисы экспортируемые PACKET.DLL, предоставляя приложениям мощный высокого уровня интерфейс захвата.

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

2. Взаимодействие с NDIS

NDIS – это набор функций, которые устанавливают взаимодействие драйверов сетевых карт и драйверов протоколов (IP, IPX,...). Главное предназначение NDIS – действовать в качестве упаковщика, который позволяет драйверам протоколов посылать и получать пакеты из сети(WAN, LAN) вне зависимости от конкретного адаптера или данной Win32 ОС.

NDIS поддерживает 3 типа сетевых драйверов :

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

Промежуточный драйвер общается с одной стороны с драйверами верхнего уровня, такими как драйвера транспорта, с другой с минипортами. Для минипорта промежуточный драйвер выглядит как драйвер протокола. Промежуточный драйвер может общаться с приложением, но только вместе с другими NDIS драйверами.

Транспортный драйвер или драйвер протокола. Драйвер протокола составляет сетевой стек протоколов, таких как IPX/SPX, TCP/IP. Транспортный драйвер обслуживает программы пользовательского режима , на своём верхнем уровне и соединяется с одним и более NIС драйвером или промежуточным NDIS-драйвером на нижнем уровне.

Следующая схема демонстрирует NDIS структуру с двумя схемами захвата:

Одна с NIC драйвером и драйвером протокола, другая с NIC драйвером, драйвером протокола и промежуточным драйвером.

Рис. 2 NDIS структура с двумя схемами захвата

Драйвер захвата пакетов должен быть связан с сетевым драйвером, чтобы получать данные из сети и с пользовательским приложением для того, чтобы предоставлять ему пакеты данных. Таким образом, он внедрён в NDIS структуру как драйвер протокола. Это позволяет ему быть независимым от сетевой аппаратной архитектуры, но, тем не менее, работать под всеми интерфейсами, поддерживаемыми Windows.Однако, следует помнить, что данный драйвер работает только на Ethernet адаптерах и в некоторых WAN соединениях в связи с ограничениями, налагаемыми архитектурой драйверов и фильтров. Также, надо учитывать, что WAN соединение понимается драйвером протокола как Ethernet NIC и каждый полученный пакет имеет искусственный Ethernet заголовок, созданный NDIS. Это позволяет драйверам протоколов работать на WAN соединениях без разницы, но предполагает также, что специфические пакеты, такие как PPP NCP-LCP не видны для драйвера протокола, поскольку PPP –соединение – виртуально. Это означает, что драйвер не сможет перехватывать пакеты данных такого типа.

Следующий рисунок показывает местоположение драйвера захвата пакетов данных в сетевой архитектуре Windows.

Рис. 3 Сетевая архитектура Windows

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

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

Есть несколько существенных различий в работе драйвера протокола и драйвера захвата :

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

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

3. Структура драйвера

Рис.4 Базовая структура драйвера

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

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

WinDump и libpcap не посылают пакетов в сеть, однако используют путь снизу вверх. Драйвер, однако, не ограничивается использованием исключительно WinDuno’ом. Поэтому была включена возможность передачи пакетов в сеть, которая может быть реализована использованием PACKET.DLL.

Процесс фильтрации пакетов

1. Причины фильтрации

Для каждого подключения между адаптером и программой сбора данных, драйвер создает фильтр и буфер. Один сетевой интерфейс может использоваться более чем одним приложением одновременно. Например пользователь, который хочет фиксировать IP и UDP траффик в сети и сохранять их в двух отдельных файлах, может запустить два сеанса WinDump на том же самом адаптере (но с различными фильтрами) одновременно. Первый сеанс поставит фильтр для пакетов IP (и буфер будет хранить их), а второй фильтровать UDP пакеты. В Windows NT это также возможно для одного приложения, чтобы получить пакеты от более чем одного интерфейса, открывая сеанс на каждом сетевом адаптере.

Механизм фильтрации, который присутствует в драйвере захвата пакетов, наследован из фильтра драйвера BPF, используемого в UNIX.

2. BPF фильтр

Фильтр решает должен ли данный пакет быть скопирован в буфер приложения. Большинство приложений, использующих BPF, отвергают значительно больше пакетов, нежели принимают. Фильтр пакетов – это функция с «булевым» значением, вычисляемая по каждому пакету. Если возвращаемое значение «истина», то драйвер копирует данные в

приложение, иначе – пакет игнорируется. Этот фильтр определяет также не

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

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

3. Фильтрация в драйвере захвата пакетов

Приложение, которому нужно установить фильтр на поступающие пакеты, может создать стандартный BPF фильтр(например через вызов функции pcap_compile библиотеки libpcap) и направить его драйверу, тогда процесс фильтрации будет исполняться в «режиме ядра». BPF - код направляется в драйвер через IOCTL вызов с управляющим кодом pBIOCSETF. Важным моментом является то, что драйверу необходимо иметь возможность проверять код фильтра, направленного приложением. Фактически, BPF псевдо-машины могут исполнять арифметические операции. Поэтому деление на ноль, обращение к памяти по «невалидному»

указателю неминуемо приведёт к «синему экрану». Так как это может быть использовано злоумышленником для того, чтобы привести систему к краху, то каждый фильтр, поступающий от приложения, проверяется bpf_validate функцией драйвера прежде чем быть принятым. Если фильтр принят, то драйвер его запоимает и потом исполняет каждый раз, когда поступает новый пакет данных, отбрасывая те, которые не удовлетворяют условиям фильтра. Если пакет удовлетворяет этим условиям, он отправляется приложению или буферизуется драйвером, если приложение не готово принимать пакеты. Если никакого фильтра не установлено, то драйвер обрабатывает все пакеты. Фильтр устанавливается для пакета когда тот ещё находится в памяти NIC драйвера без копирования его в драйвер захвата пакетов. Наиболее интересная черта, наследуемая драйвером захвата пакетов от BPF фильтра – возможность фильтровать не только пакеты, но и сами данные пакета.

Наиболее интересные функции фильтра:

bpf_filter: она устанавливает обработчик, который будет выполнять код фильтра; она получает два буфера: один содержит пакет, другой – BPF программу. Возвращает длину порции пакета для дальнейшей обработки, ноль, если пакет должен быть отброшен.

bpf_filter_with_2_buffers: эта функция похожа на bpf_filter, но она позволяет обрабатывать пакеты, образованные двумя буферами, первый содержит заголовок, второй – данные. Функция получает их в качестве аргументовв, а также третий с BPF-программой. Эта функция медленнее, но более общая нежели bpf_filter.

bpf_validate: функция проверяет код фильтра и возвращает «истина» в случае валидности программы. Эта функция проверяет чтобы программные переходы были только внутри блока кода фильтра, чтобы в операциях с памятью использовались валидные адреса и чтобы не присутствовало константного деления на ноль.

Процессы чтения и буферизации

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

Приложение может устанавливать таймаут через IOCTL с кодом pBIOCSRTIMEOUT. Если таймаут отличен от 0, то каждый вызов функции чтения будет возвращать управление по истечении таймаута, даже если не было получено никаких пакетов.

После получения пакета, драйвер может оказаться в одной из двух ситуаций:

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

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

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

Поступающие пакеты игнорируются драйвером, когда недостаточно места в его буфере.

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

Буфер в «режиме ядра»

Буфер состоит из двух блоков памяти, размером в 4 KB. Главные недостатки такой архитектуры:

Стандартный размер буфера драйвера – 8 KB, а максимальный размер – 32 KB. Эти размеры слишком малы в сравнении с объёмом опреативной памяти, доступной в современных компьютерах.

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

Чтобы преодолеть эти ограничения, в драйвере завата используется обычный динамический циклический буфер(по умолчанию – 1MB).

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

3 БИБЛИОТЕКА PACKET.DLL

Общее описание библиотеки

PACKET.DLL - динамически связываемая библиотека, которая использует интерфейс драйвера захвата пакета NDIS с пользовательскими приложениями. DLL представляет собой набор функций, которые делают связь с драйвером более простой, позволяя избежать использования системных вызовов или IOCTL’s в программах. DLL содержит функции обеспечивающие, обработку сетевых адаптеров, чтение и запись пакетов в сети, установку буфера и фильтра драйвера, и так далее. Имеются две версии packet.dll: первая для работы в Windows 95/98, вторая в Windows NT. Эти две версии экспортируют тот же самый интерфейс программирования, упрощая для программиста написание системно-независимых приложений. Фактически, при использовании PACKET.DLL API, то же самое приложение сбора данных может выполняться в Windows 95 и Windows NT без любой модификации. Эта особенность позволяет писать единственную версию libpcap (и, следовательно, WinDump) для различных семейств операционных систем Windows. В этой главе мы опишем, как использовать PACKET.DLL и NDIS драйвер в приложении и детали API, экспортируемого DLL.

Литература

1. S. McCanne and V. Jacobson, The BSD Packet Filter: A New Architecture for User-level Packet Capture

Proceedings of the 1993 Winter USENIX Technical Con-ference (San Diego, CA, Jan. 1993), USENIX.

2. Microsoft Software Development Kit and Driver Development Kit Examples, Mi-crosoft

Corporation.

3. Microsoft MSDN Library, Microsoft Corporation 2003.

4. Development of an Architecture for Packet Capture and Network Traffic Analysis. Loris Degioanni. March, 2000.

5. An Architecture for High Performance Network Analysis , Fulvio Risso, Loris Degioanni. July 2001.

6. Exploiting Global Data-flow Optimization in a Generalized Packet Filter Architecture , A. Begel, S. McCanne, S.L.Graham. Proceedings of ACM SIGCOMM '99, pages 123-134, Conference on Applications, technologies, architectures, and protocols for computer communications, August 30 - September 3, 1999, Cambridge, USA

7. Introducing Network Analysis Статья о сетевом анализе.

8. "Computer Networks 3/e", Andrew S. Tanenbaum. Prentice Hall PTR, 1996.

9. Gary R. Wright, W. Richard Stevens, TCP-IP illustrated Volume 2, chapter 31. Addison-Wesley professional computing series.

10. V. Jacobson, C. Leres and S. McCanne, TCPdump, Lawrence Berkeley Laboratory, Berkeley, CA, June 1989.

11. Marcus J. Ranum, Kent Landfield, Mike Stolarchuk, Mark Sienkiewicz, Andrew Lambeth, and Eric Wall (Network Flight Recorder, Inc.), Implementing a Generalized Tool for NetworkMonitoring, LISA 97, San Diego, CA, October 26-31, 1997.

Магистры ДонНТУ

ДонНТУ