Разработка программного обеспечения для захвата сетевого трафика. Часть 2

1  2

---

ГЛАВА 2 ФОРМАТЫ СТРУКТУРНЫХ ЕДИНИЦ ПРОТОКОЛОВ

2.1 Форматы кадров технологии Ethernet

 

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

Таблица 3 – Формат кадра Ethernet DIX (II)

 

Первые два поля заголовка отведены под адреса:

DA (Destination Address) — МАС-адрес узла назначения;

SA (Source Address) — МАС-адрес узла отправителя. Для доставки кадра достаточно одного адреса — адреса назначения; адрес источника помещается в кадр для того, чтобы узел, получивший кадр, знал, от кого пришел кадр и кому нужно на него ответить. Принятие решения об ответе не входит в компетенцию протокола Ethernet, это дело протоколов верхних уровней. Ethernet же только выполнит такое действие, если с сетевого уровня поступит соответствующее указание.

Поле Т (Туре, или EtherType) содержит условный код протокола верхнего уровня, данные которого находятся в поле данных кадра, например шестнадцатеричное значение 08-00 соответствует протоколу IP. Это поле требуется для поддержки интерфейсных функций мультиплексирования и демультиплексирования кадров при взаимодействии с протоколами верхних уровней.

Поле данных может содержать от 46 до 1500 байт. Если длина пользовательских данных меньше 46 байт, то это поле дополняется до минимального размера байтами заполнения. Эта операция требуется для корректной работы метода доступа Ethernet (он рассматривается в следующем разделе).

Поле контрольной последовательности кадра (Frame Check Sequence, FCS) состоит из 4 байт контрольной суммы. Это значение вычисляется по алгоритму CRC-32.

Кадр Ethernet DIX (II) не отражает разделения канального уровня Ethernet на уровень MAC и уровень LLC: его поля поддерживают функции обоих уровней, например интерфейсные функции поля Г относятся к функциям уровня LLC, в то время как все остальные поля поддерживают функции уровня MAC.

Существуют еще три стандартных формата кадра Ethernet:

• кадр 802.3/LLC является стандартом комитета IEEE 802 и построен в соответствии с принятым разбиением функций канального уровня на уровень MAC и уровень LLC. Поэтому результирующий кадр является вложением кадра LLC, определяемого стандартом 802.2, в кадр MAC, определяемого стандартом 802.3;
• кадр Raw 802.3, или Novell 802.3, появился в результате усилий компании Novell по ускорению разработки своего стека протоколов в сетях Ethernet;
• кадр Ethernet SNAP стал результатом деятельности комитета 802.2 по приведениюпредыдущих форматов кадров к некоторому общему стандарту и приданию кадру необходимой гибкости для учета в будущем возможностей добавления полей или изменения их назначения.

 

2.2 Формат IP-пакета

 

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

Таблица 4 – Структура заголовка IP-пакета

Поле номера версии занимает 4 бита и идентифицирует версию протокола IP. Сейчас повсеместно используется версия 4 (IPv4), хотя все чаще встречается и новая версия (IPv6).

Значение длины заголовка IP-пакета также занимает 4 бита и измеряется в 32-битных словах. Обычно заголовок имеет длину в 20 байт (пять 32-битных слов), но при добавлении некоторой служебной информации это значение может быть увеличено за счет дополнительных байтов в поле параметров. Наибольшая длина заголовка составляет 60 байт.

Поле типа сервиса (Type of Service, ToS) имеет и другое, более современное название — байт дифференцированного обслуживания, или DS-байт. Этим двум названиям соответствуют два варианта интерпретации этого поля. В обоих случаях данное поле служит одной цели — хранению признаков, которые отражают требования к качеству обслуживания пакета. В прежнем варианте первые три бита содержат значение приоритета пакета: от самого низкого — 0 до самого высокого — 7. Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь. Следующие три бита поля ToS определяют критерий выбора маршрута. Если бит D (Delay — задержка) установлен в 1, то маршрут должен выбираться для минимизации задержки доставки данного пакета, установленный бит Т (Throughput — пропускная способность) — для максимизации пропускной способности, а бит R (Reliability — надежность) — для максимизации надежности доставки. Оставшиеся два бита имеют нулевое значение.

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

Поле общей длины занимает 2 байта и характеризует общую длину пакета с учетом заголовка и поля данных. Максимальная длина пакета ограничена разрядностью поля, определяющего эту величину, и составляет 65 535 байт, однако в большинстве компьютеров и сетей столь большие пакеты не используются. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP-пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной 1500 байт, умещающиеся в поле данных кадра Ethernet. В стандартах TCP/IP предусматривается, что все хосты должны быть готовы принимать пакеты длиной вплоть до 576 байт (независимо от того, приходят ли они целиком или фрагментами).
Идентификатор пакета занимает 2 байта и используется для распознавания пакетов, образовавшихся путем делен’ия на части (фрагментации) исходного пакета. Все части (фрагменты) одного пакета должны иметь одинаковое значение этого поля.

Флаги занимают 3 бита и содержат признаки, связанные с фрагментацией. Установленный в 1 бит DF (Do not Fragment — не фрагментировать) запрещает маршрутизатору фрагментировать данный пакет, а установленный в 1 бит MF (More Fragments — больше фрагментов) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Оставшийся бит зарезервирован.

Поле смещения фрагмента занимает 13 бит и задает смещение в байтах поля данных этого фрагмента относительно начала поля данных исходного (нефрагментированного) пакета. Используется при сборке/разборке фрагментов пакетов. Смещение должно быть кратно 8 байт.

Поле времени жизни (Time То Live, TTL) занимает один байт и используется для задания предельного срока, в течение которого пакет может перемещаться по сети. Время жизни пакета измеряется в секундах и задается источником. По истечении каждой секунды пребывания на каждом из маршрутизаторов, через которые проходит пакет во время своего «путешествия» по сети, из его текущего времени жизни вычитается единица; единица вычитается и в том случае, если время пребывания было меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно интерпретировать как максимальное число транзитных узлов, которые разрешено пройти пакету. Если значение поля времени жизни становится нулевым до того, как пакет достигает получателя, пакет уничтожается. Таким образом, время жизни является своего рода часовым механизмом самоуничтожения пакета.

Поле протокола верхнего уровня занимает один байт и содержит идентификатор, указывающий, какому протоколу верхнего уровня принадлежит информация, размещенная в поле данных пакета [14]. Значения идентификаторов для разных протоколов приводятся в документе RFC 1700.

Контрольная сумма заголовка занимает 2 байта (16 бит) и рассчитывается только по заголовку. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, поле времени жизни), контрольная сумма проверяется и повторно рассчитывается на каждом маршрутизаторе и конечном узле как дополнение к сумме всех 16-битных слов заголовка. При вычислении контрольной суммы значение самого поля контрольной суммы устанавливается в нуль. Если контрольная сумма неверна, то пакет отбрасывается, как только обнаруживается ошибка.

Поля IP-адресов источника и приемника имеют одинаковую длину — 32 бита.

Поле параметров является необязательным и используется обычно только при отладке сети. Это поле состоит из нескольких подполей одного из восьми предопределенных типов. В этих подполях можно указывать точный маршрут, регистрировать проходимые пакетом маршрутизаторы, помещать данные системы безопасности или временные отметки.
Так как число подполей в поле параметров может быть произвольным, то в конце заголовка должно быть добавлено несколько нулевых байтов для выравнивания заголовка пакета по 32-битной границе.
Далее приведена распечатка значений полей заголовка одного из реальных IP-пакетов, захваченных в сети Ethernet средствами анализатора протоколов сетевого монитора (Network Monitor, NM) компании Microsoft. В данной распечатке NM в скобках дает шестнадцате-ричные значения полей, кроме того, программа иногда представляет числовые коды полей в виде, более удобном для чтения. Например, дружественный программный интерфейс NM интерпретирует код 6 в поле протокола, помещая туда название соответствующего протокола — TCP.

IP: Version = 4 (0x4)

IP: Header Length = 20 (0x14)

IP: Service Type = 0 (0x0)

IP: Precedence = Routine

IP: .. .0____ = Normal Delay

IP: ____0… = Normal Throughput

IP: …..0.. = Normal Reliability

IP: Total Length = 54 (0x36)

IP: Identification = 31746 (0x7C02)

IP: Flags Summary = 2 (0x2)

IP: …….0 = Last fragment in datagram

IP: ……1. = Cannot fragment datagram

IP: Fragment Offset = 0 (0x0) bytes

IP: Time to Live = 128 (0x80)

IP: Protocol — TCP — Transmission Control

IP: Checksum = 0xEB86

IP: Source Address = 194.85.135.75

IP: Destination Address = 194.85.135.66

IP: Data: Number of data bytes remaining = 34 (0x0022)

В заголовке IP-пакета для хранения IP-адресов отправителя и получателя отводятся два поля, каждое имеет фиксированную длину 4 байта (32 бита). IP-адрес состоит из двух логических частей — номера сети и номера узла в сети.

Наиболее распространенной формой представления IP-адреса является запись в виде четырех чисел, представляющих значения каждого байта в десятичной форме и разделенных точками, например:

128.10.2.30.

Этот же адрес может быть представлен в двоичном формате:

10000000 00001010 00000010 00011110.

А также в шестнадцатеричном формате:

80.0A.02.1D.

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

Можно предложить несколько вариантов решения этой проблемы:

• простейший из них состоит в использовании фиксированной границы. При этом все 32-битное поле адреса заранее делится на две части не обязательно равной, но фиксированной длины, в одной из которых всегда будет размещаться номер сети, в другой — номер узла. Решение очень простое, но хорошее ли? Поскольку поле, которое отводится для хранения номера узла, имеет фиксированную длину, все сети будут иметь одинаковое максимальное число узлов. Если, например, под номер сети отвести один первый байт, то все адресное пространство распадется на сравнительно небольшое (28);
• число сетей огромного размера (224 узлов). Если границу передвинуть дальше вправо, то сетей станет больше, но все равно все они будут одинакового размера. Очевидно, что такой жесткий подход не позволяет дифференцированно удовлетворять потребности отдельных предприятий и организаций. Именно поэтому он не нашел применения, хотя и использовался на начальном этапе существования технологии TCP/IP (RFC 760);
• второй подход (RFC 950, RFC 1518) основан на использовании маски, которая позволяет максимально гибко устанавливать границу между номером сети и номером узла. При таком подходе адресное пространство можно использовать для создания множества сетей разного размера.
  Маска — это число, применяемое в паре с IP-адресом, причем двоичная запись маски содержит непрерывную последовательность единиц в тех разрядах, которые должны в IP-адресе интерпретироваться как номер сети. Граница между последовательностями единиц и нулей в маске соответствует границе между номером сети и номером узла в IP-адресе;
• последний способ, основанный на классах адресов (RFC 791). Этот способ представляет собой компромисс по отношению к двум предыдущим: размеры сетей хотя и не могут быть произвольными, как при использовании масок, но и не должны быть одинаковыми, как при установлении фиксированных границ. Вводится пять классов адресов: А, В, С, D, Е. Три из них — А, В и С — предназначены для адресации сетей, а два — D и Е — имеют специальное назначение. Для каждого класса сетевых адресов определено собственное положение границы между номером сети и номером узла.

 

2.3 Формат РРР

 

Протокол РРР (Point-to-Point Protocol — протокол двухточечной связи) является стандартным протоколом Интернета. Протокол РРР, так же как и HDLC, представляет собой целое семейство протоколов, в которое, в частности, входят:

• протокол управления линией связи (Link Control Protocol, LCP);
• протокол управления сетью (Network Control Protocol, NCP);
• многоканальный протокол РРР (Multi-Link РРР, MLPPP);
• протокол аутентификации по паролю (Password Authentication Protocol, PAP);
• протокол аутентификации по квитированию вызова (Challenge Handshake Authentication Protocol, CHAP).

При разработке протокола РРР за основу был взят формат кадров HDLC и дополнен несколькими полями. Эти дополнительные поля протокола РРР вложены в поле данных кадра HD0LC. Позже были разработаны стандарты, описывающие вложение кадра РРР в кадры Frame Relay и других протоколов глобальных сетей. Хотя протокол РРР и работает с кадром HDLC, он не поддерживает, подобно стандартной версии протокола HDLC, процедуры надежной передачи кадров и управления их потоком.

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

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

Протокол, в соответствии с которым принимаются параметры соединения, называется протоколом управления линией связи (LCP). Чтобы справиться со всеми возможными ситуациями, в протоколе РРР имеется набор стандартных параметров, действующих по умолчанию и учитывающих все стандартные конфигурации. При установлении соединения два взаимодействующих устройства для нахождения взаимопонимания пытаются сначала использовать эти параметры. Каждый конечный узел описывает свои возможности и требования. Затем на основании этой информации принимаются параметры соединения, устраивающие обе стороны. Переговорная процедура протоколов может и не завершиться соглашением о каком-нибудь параметре. Если, например, один узел предлагает в качестве MTU значение 1000 байт, а другой отвергает это предложение и в свою очередь предлагает значение 1500 байт, которое отвергается первым узлом, то по истечении тайм-аута переговорная процедура может закончиться безрезультатно.

Одним из важных параметров соединения РРР является режим аутентификации. Для целей аутентификации РРР предлагает по умолчанию протокол аутентификации по паролю (PAP), передающий пароль по линии связи в открытом виде, или протокол аутентификации по квитированию вызова (CHAP), не передающий пароль по линии связи и поэтому обеспечивающий более высокий уровень безопасности сети. Пользователям также разрешается добавлять новые алгоритмы аутентификации. Кроме того, пользователи могут влиять на выбор алгоритмов сжатия заголовка и данных.

Многопротокольная поддержка — способность протокола РРР поддерживать несколько протоколов сетевого уровня — обусловила распространение РРР как стандарта де-факто. Внутри одного соединения РРР могут передаваться потоки данных различных сетевых протоколов, включая IP, Novell IPX и многих других, сегодня уже не употребляющихся, а также данные протоколов канального уровня локальной сети.

Каждый протокол сетевого уровня конфигурируется отдельно с помощью соответствующего протокола управления сетью (NCP). Под конфигурированием понимается, во-первых, констатация того факта, что данный протокол будет использоваться в текущем сеансе РРР, а во-вторых, переговорное согласование некоторых параметров протокола. Больше всего параметров устанавливается для протокола IP, включая IP-адреса взаимодействующих узлов, IP-адреса DNS-серверов, признак компрессии заголовка IP-пакета и т. д. Для каждого протокола конфигурирования протокола верхнего уровня, помимо общего названия NCP, употребляется особое название, построенное путем добавления аббревиатуры CP (Control Protocol — протокол управления) к имени конфигурируемого протокола, например для IP — это протокол IPCP, для IPX — IPXCP и т. п.

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

 

2.4 Формат HTTP-сообщений

 

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

 

Как видно из таблицы, запросы и ответы имеют разные форматы стартовой строки. Каждая из них состоит из трех элементов, включающих поле версии протокола HTTP. И в запросе, и в ответе примера указана версия HTTP 1.1. Стартовая строка запроса включает в себя поле метода — это название операции, которая должна быть выполнена. Чаще всего в запросах используется метод GET, то есть запрос объекта. Именно он включен в наш пример запроса. Помимо этого метода в запросах протокол предусматривает и другие методы, Такие как POST, который используется клиентом, например, для отправки электронной почты или в поисковых машинах, когда клиент запрашивает у сервера не определенный объект, а объекты, содержащие ключевые слова, помещенные в теле сообщения [15].

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

В настоящее время стандарты определяют пять классов кодов состояния:

• 1хх — информация о процессе передачи;
• 2хх — информация об успешном принятии и обработки запроса клиента;
• Зхх — информация о том, что для успешного выполнения операции нужно произвести следующий запрос по-другому URL-адресу, указанному в дополнительном заголовке Locati on;
• 4хх — информация об ошибках на стороне клиента (читатель наверняка не раз сталкивался с ситуацией, когда при указании адреса несуществующей страницы браузер выводил на экран сообщение 404 Not Found);
• 5хх — информация о неуспешном выполнения операции по вине сервера (например, сообщение 505 http Version Not Supported говорит о том, что сервер не поддерживает версию HTTP, предложенную клиентом).

Среди кодов состояния имеется код 401, сопровождаемый сообщением authorization required. Если клиент получает такое сообщение в ответ на попытку доступа к странице или объекту, это означает, что доступ к данному ресурсу ограничен и требует авторизации 1 пользователя. Помимо поясняющей фразы сервер помещает в свой ответ дополнительный заголовок www-Authenticate:<…>, который сообщает клиенту, какую информацию он должен направить серверу для того, чтобы процедура авторизации могла быть выполнена. Обычно это имя и пароль. Веб-клиент с момента получения такого ответа сервера начинает добавлять во все свои запросы к ресурсам данного сервера дополнительный заголовок Authorization: <имя, пароль>, который содержит информацию, необходимую для авторизации доступа.

 

2.5 Формат UDP

 

При работе на хосте-отправителе данные от приложений поступают протоколу UDP через порт в виде сообщений (рис. 6). Протокол UDP добавляет к каждому отдельному сообщению свой 8-байтный заголовок, формируя из этих сообщений собственные протокольные единицы, называемые UDP-дейтаграммами, и передает их нижележащему протоколу IP. В этом и заключаются его функции по мультиплексированию данных.

Рисунок 6 – Схема функционирования протокола UPD

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

Заголовок UDP состоит из четырех 2-байтных полей:

• номер UDP-порта отправителя;
• номер UDP-порта получателя;
• контрольная сумма;
• длина дейтаграммы.

Далее приведен пример заголовка UDP с заполненными полями:

Source Port — 0x0035

Destination Port — 0x0411

Total length — 132 (0x84) bytes

Checksum = 0x5333

В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 — 8) байт, помещено сообщение DNS-сервера, что можно видеть по номеру порта источника (Source Port = 0—0035). В шестнадцатеричном формате это значение равно стандартному номеру порта DNS-сервера — 53.

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

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

 

2.6 Формат стека TCP/IP

 

Стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, вследствие чего, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.

Протоколы TCP/IP делятся на 4 уровня.

Самый нижний (уровень IV) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: для локальных сетей это Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальных сетей — протоколы соединений «точка-точка» SLIP и PPP, протоколы территориальных сетей с коммутацией пакетов X.25, frame relay. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции пакетов IP в ее кадры.

Следующий уровень (уровень III) — это уровень межсетевого взаимодействия, который занимается передачей пакетов с использованием различных транспортных технологий локальных сетей, территориальных сетей, линий специальной связи и т.п.

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

К уровню межсетевого взаимодействия относятся и все протоколы, связанные с составлением и модификацией таблиц маршрутизации, такие как протоколы сбора маршрутной информации RIP (Routing Internet Protocol) и OSPF (Open Shortest Path First), а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol). Последний протокол предназначен для обмена информацией об ошибках между маршрутизаторами сети и узлом — источником пакета. С помощью специальных пакетов ICMP сообщается о невозможности доставки пакета, о превышении времени жизни или продолжительности сборки пакета из фрагментов, об аномальных величинах параметров, об изменении маршрута пересылки и типа обслуживания, о состоянии системы и т.п.

Следующий уровень (уровень II) называется основным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.

Верхний уровень (уровень I) называется прикладным. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и сервисов прикладного уровня. К ним относятся такие широко используемые протоколы, как протокол копирования файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы доступа к удаленной информации, такие как WWW и многие другие.

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

TCP/IP поддерживает все популярные стандарты физического и канального уровней: для локальных сетей — это Ethernet, Token Ring, FDDI, для глобальных — протоколы работы на аналоговых и выделенных линиях SLIP, PPP, RIP, EGP, BGP, IGP, OSPF протоколы территориальных сетей X.25 и ISDN.

 

ГЛАВА 3 РАЗРАБОТКА ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ

 

3.1 Получение списка устройств

 

Как правило, первое, что делает приложение на основе SharpPcap, это получает список подключенных сетевых адаптеров. В библиотеке SharpPcap это обеспечивает класс CaptureDeviceList. Класс является одноэлементным экземпляром, который содержит кэшированный список сетевых адаптеров типа ICaptureDevice. В частности, свойства Name и Description содержат имя и описание, соответствующего устройства [16]. В данном коде C # показано, как получить список адаптеров и распечатать его на экране, напечатав ошибку, если адаптеры не найдены:

//Выводим версию SharpPcap

string ver = SharpPcap.Version.VersionString;

Console.WriteLine(«SharpPcap {0}, Example1.IfList.cs», ver);

//Получаем список устройств

CaptureDeviceList devices = CaptureDeviceList.Instance;

//Если нет устройств выводим ошибку

if (devices.Count < 1)

{

Console.WriteLine(«Нет сетевых устройств на компьютере»);

return;

}

Console.WriteLine(«\nДоступны следующие сетевые устройства:»);

Console.WriteLine(«—————————————————-\n»);

//Печатаем все доступные устройства

foreach (ICaptureDevice dev in devices)

Console.WriteLine(«{0}\n», dev.ToString());

Console.Write(«Нажмите Enter для выхода…»);

Console.ReadLine();

Рисунок 7 – Доступные сетевые устройства

 

3.2 Открытие адаптера и получение пакетов

 

Функция открывающая сетевой адаптер Open(). Она перегружена и имеет следующие аргументы:

• open();
• open(DeviceMode mode);
• open(DeviceMode mode, int read_timeout).

Последние два аргумента заслуживают детального рассмотрения.

DeviceMode в обычном режиме (DeviceMode.Normal), сетевой адаптер захватывает только те пакеты, которые адресованы непосредственно ему, обмен пакетами других хостов в сети игнорируется. Когда адаптер находится в беспорядочном режиме (DeviceMode.Promiscuous), он захватывает все пакеты, хотят они этого или нет. Это означает, что Libpcap / WinPcap сможет захватить пакеты адресованные другим хостам. Promiscuous(неразборчивый) режим используется по умолчанию для большинства приложений, так что мы также включим его в следующем примере. ПРИМЕЧАНИЕ: Использование этого режима в сети можно обнаружить, так что если захватывать в Promiscuous (беспорядочном) режиме, то действия могут быть обнаружены.
read_timeout: Задает таймаут в миллисекундах. Чтения с адаптера (например, с помощью функции GetNextPacket () всегда будет возвращаться после read_timeout миллисекунд, даже если пакеты уже доступны. read_timeout также определяет интервал между статистическими отчетами, если адаптер в работает статистическом режиме (в режиме сбора статистики).
В следующем коде показано использование OnPacketArrival для приема пакетов. Мы создаем обработчик событий, который вызывается всякий раз, когда новый пакет проходит через ICaptureDevice:

CaptureDeviceList devices = CaptureDeviceList.Instance;

if (devices.Count < 1)

{

Console.WriteLine(«Нет сетевых устройств на компьютере»);

return;

}

foreach (ICaptureDevice dev in devices)

Console.WriteLine(«{0}\n», dev.ToString());

int i = 0;

ICaptureDevice device = devices[i];

//Регистрируем событие для приёмки пакетов

device.OnPacketArrival +=

new SharpPcap.PacketArrivalEventHandler(device_OnPacketArrival);

//Открываем адаптер для получения пакетов

int readTimeoutMilliseconds = 1000;

device.Open(DeviceMode.Promiscuous, readTimeoutMilliseconds);

Console.WriteLine(«— Listening on {0}, hit ‘Enter’ to stop…»,device.Description);

//Начинаем сбор пакетов

device.StartCapture();

//Ждем нажатия Enter

Console.ReadLine();

//Прекращаем процесс сбора пакетов

device.StopCapture();

//Закрываем pcap устройство

device.Close();

После этого, адаптер открыт, захват может быть запущен с помощью StartCapture() или Capture(INT packetCount) функции. Эти две функции схожи, разница в том, что StartCapture() не блокирует основной поток программы, а запускается в новом потоке, в то время Capture(INT packetCount) блокирует основной поток, до тех пор пока packetCount пакеты не будут получены. При использовании StartCapture() мы должны вызвать StopCapture(), чтобы завершить процесс захвата. Для бесконечного(постоянного) захвата необходимо вызывать метод Capture().

Обе эти функции требуют, чтобы обработчик события для обработки пакетов был зарегистрирован(инициализирован) до их вызова. Этот обработчик событий вызывается устройством ICaptureDevice для каждого нового пакета, проходящего через сеть. Он получает отправителя объекта, который вызывает этот обработчик (т.е. ICaptureDevice объекта) и фактически полученного пакета, включая все заголовки протокола. Обратите внимание, что CRC обычно не присутствует в пакете, поскольку он удаляется сетевым адаптером после процедуры проверки пакета(целостности). Стоит также отметить, что большинство адаптеров отбрасывает пакеты с неправильной контрольной суммой CRC, в следствии чего так WinPcap (и, следовательно SharpPcap), как правило, не в состоянии захватить их.

 

3.3 Захват пакетов без обработчика событий

 

ICaptureDevice.GetNextPacket() вместо метода регистрации обработчика события. Использование события OnPacketArrival является хорошей практикой и может быть хорошим выбором, в некоторых ситуациях, например, при захвате пакетов одновременно с нескольких устройств. Однако, использование обработки обратного вызова иногда не практично — это часто делает программу более сложной, особенно в ситуациях с многопоточными приложениями. В этих случаях GetNextPacket() возвращает пакет с прямым вызовом — с помощью GetNextPacket(), пакеты принимаются только тогда, когда мы хотим их получить.

CaptureDeviceList devices = CaptureDeviceList.Instance;

if (devices.Count < 1)

{

Console.WriteLine(«Нет сетевых устройств на компьютере»);

return;

}

foreach (ICaptureDevice dev in devices)

Console.WriteLine(«{0}\n», dev.ToString());

int i = 0;

ICaptureDevice device = devices[i];

//Открываем устройство для захвата

int readTimeoutMilliseconds = 1000;

device.Open(DeviceMode.Promiscuous, readTimeoutMilliseconds);

Console.WriteLine();

Console.WriteLine(«— Listening on {0}…»,

device.Description);

Packet packet = null;

RawCapture raw = device.GetNextPacket();

while (raw != null)

{

packet = Packet.ParsePacket(raw.LinkLayerType, raw.Data);

//Выводим время и длину полученного пакета

DateTime time = raw.Timeval.Date;

int len = raw.Data.Length;

Console.WriteLine(«{0}:{1}:{2},{3} Len={4}»,

time.Hour, time.Minute, time.Second,

time.Millisecond, len);

}

//Закрываем pcap устройство

device.Close();

Console.WriteLine(» — Capture stopped, device closed.»);

Console.ReadLine();

 

3.4 Запись пакетов в файл

 

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

// Открываем файл для записи

captureFileWriter = new CaptureFileWriterDevice(device, capFile);

Теперь, когда captureFileWriter существует, при помощи класса OnPacketArrival, можно записывать захваченный пакеты на диск(в файл):

// Записываем пакет в файл

captureFileWriter.Write(e.Packet);

Console.WriteLine(«Packet dumped to file.»);

 

3.5 Считывание информации о пакетах из файла

 

Необходимо создать экземпляр CaptureFileReaderDevice(string captureFilename) и cчитывать пакеты так же, как с любого другого устройства.

// Подписываемся на событие

device.OnPacketArrival +=

new PacketArrivalEventHandler( device_OnPacketArrival );

Console.WriteLine();

Console.WriteLine

(«— Capturing from ‘{0}’, hit ‘Ctrl-C’ to exit…»,      capFile);

// Запускаем бесконечный сбор пакетов

// Этот метод вернет EOF при конце файла

device.Capture();

ЗАКЛЮЧЕНИЕ

 

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

• рассмотрены основные протоколы сети интернет;
• изучены форматы структурных единиц протоколов;
• изучены возможности библиотеки SharpPcap.
• разработано приложение для захвата сетевого трафика.

Выявлены следующие возможности библиотеки SharpPcap:

• получение списка устройств;
• открытие адаптера и получение пакетов;
• захват пакетов без обработчика событий;
• запись пакетов в файл;
• считывание информации о пакетах из файлов.

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

 

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

 

1. Бертсекас, Д. Сети передачи данных / Д. Бертсекас, Р. Галлагер. – М., Мир, 1989. – 542с.
2. Блэк, Ю. Сети ЭВМ: протоколы, стандарты, интерфейсы / Ю. Блэк. – М., Мир, 1990. – 452 с.
3. Бройдо, В. Л. Вычислительные системы, сети и телекоммуникации / В. Л. Бройдо. – Спб., Питер, 2002. – 688 с.
4. Гук, М. Аппаратные средства локальных сетей / М. Гук. – СПБ., Питер, 2000. – 576 с.
5. Гук, М. Аппаратные средства PC. Энциклопедия / – М., Мир, 2003. – 366 с.
6. Челлис, Дж Основы построения сетей / Дж. Челлис, Ч. Перкинс, М. Стриб. – М., Лори, 1997. – 205 с.
7. Дженнигс, Ф. Практическая передача данных: Модемы, сети и протоколы. / Ф. Дженнигс. – М., Мир, 1989. – 305 с.
8. Золотов, С. Протоколы Internet / С. Золотов. – Киев, BHV, 1998. – 340 с.
9. Хант, К Персональные компьютеры в сетях TCP/IP / К. Хант. – Киев, BHV, 1997. – 210 с.
10. Марк, А. Высокопроизводительные сети. Энциклопедия пользователя / А. Марк. – Киев, ДиаСофт, 1998. – 154 с.
11. Олифер, В. Г. Компьютерные сети / В. Г. Олифер, Н. А. Олифер. – СПб., Питер, 2000. – 672с.
12. Олифер, В. Г. Сетевые операционные системы / В. Г. Олифер, Н.А. Олифер – СПб., Питер, 2001. – 110 с.
13. Пасько, В. П. Энциклопедия ПК. Аппаратура. Программы. Интернет / В. П. Пасько. – Киев, BHV; 2004. – 800с.
14. Попов, И.И., Компьютерные сети: Учебное пособие / И. И. Попов, Н. В. Максимов. – М., ФОРУМ: ИНФРА-М, 2004. – 623 с.
15. Стек протоколов TCP/IP [Электронный ресурс] / Компьютерные сети. – 2017. – Режим доступа: http://iptcp.net/stek-protokolov-tcpip.html. – Дата доступа: 25. 12. 2018.
16. SharpPcap – A Packet Capture Fraemework for .NET [Electronic resource] / Code Project. – 2014. – Mode of access: https://www.codeproject.com/Articles/12458/SharpPcap-A-Packet-Capture-Framework-for-NET#dumpTCP. – Date of access: 25. 12. 2018.

---

1  2