Структура стека захвата пакетов

Тюменский Государственный Университет
Институт Математики и Компьютерных Наук
Компьютерная Безопасность
Курсовая работа
«Сниффер, анализатор пакетов»
Выполнил: студент 367гр.
Сироткин А. М.
Научный руководитель:
к.т.н., доцент кафедры
Информационной безопасности
Широких А. В.
________________________
________________________
Тюмень, 2009 г.
Оглавление
Введение ....................................................................................................................... 3
Теория взаимодействия драйвера захвата пакетов ................................................... 4
Основная концепция архитектуры WinPCAP ........................................................ 4
Структура стека захвата пакетов ............................................................................. 4
Взаимодействие с NDIS ........................................................................................... 6
Драйверы протоколов верхнего уровня .................................................................. 6
Драйверы протоколов промежуточного уровня .................................................... 7
Промежуточные драйверы ndistapi.sys и ndiswan.sys ........................................... 8
Драйверы сетевых карт ............................................................................................ 8
Делегаты ..................................................................................................................... 12
Виды методов .......................................................................................................... 13
Теория сетей ............................................................................................................... 15
Стек протоколов TCP/IP ......................................................................................... 15
История и перспективы стека TCP/IP ................................................................ 15
Структура стека TCP/IP. Краткая характеристика протоколов ....................... 16
Протокол доставки пользовательских дейтаграмм UDP ................................. 20
Зарезервированные и доступные порты UDP ................................................... 21
Мультиплексирование и демультиплексирование прикладных протоколов с
помощью протокола UDP ................................................................................... 22
Формат сообщений UDP ..................................................................................... 23
Протокол надежной доставки сообщений TCP ................................................ 24
Концепция квитирования .................................................................................... 26
Порт (TCP/IP) ....................................................................................................... 32
Заключение ................................................................................................................. 35
Планы на будущее .................................................................................................. 37
Литература.................................................................................................................. 38
Приложение ................................................................................................................ 39
2
Введение
Зачастую возникает необходимость в том, чтобы посмотреть, какой
информацией ваш компьютер обменивается по сети. Такая необходимость
может возникнуть, например, если Вы занимаетесь отладкой какого-либо
сетевого приложения, изучаете протокол обмена информацией, либо в целях
безопасности. Функцию сбора информации выполняют СНИФФЕРЫ. Однако
нашей целью является создание комплексного программного продукта,
совмещающего
в
себе
функции
сниффера
и
анализатора
собранной
информации.
Цель: создать программный пакет для перехвата и анализа сетевого
трафика.
Задачи:
1. Выбор подходящей IDE (Integrated Development Environment).
2. Использование подходящего драйвера для перехвата сетевых данных.
3. Написание модуля для вывода статистики сетевой деятельности.
4. Написание модуля для сохранения данных и их последующего анализа.
5. Написание интерфейса.
3
Теория взаимодействия драйвера захвата пакетов
Основная концепция архитектуры WinPCAP
Архитектура WinPCAP дополняет стандартные функции операционных
систем семейства Win32 возможностью принимать и передавать данные по
сети, минуя стек протоколов операционной системы и взаимодействуя
непосредственно
предоставляет
с
сетевым
приложениям
адаптером
API
компьютера.
высокого
уровня
Более
для
того,
она
управления
низкоуровневыми процессами. WinPCAP состоит из трех компонентов: драйвер
устройства
захвата
пакетов
(paсket.vxd),
низкоуровневая
динамическая
библиотека (packet.dll) и статическая библиотека высокого уровня (libpcap).
Данная архитектура может быть использована как для создания программ
обработки пакетов для ОС Windows, так и для переноса аналогичных программ,
написанных для ОС UNIX, и полностью совместима с архитектурой BPF –
libpcap.
Структура стека захвата пакетов
Для перехвата пакетов, передаваемых по сети, приложению необходимо
взаимодействовать непосредственно с сетевым оборудованием. По этой
причине операционная система должна предоставлять несколько примитивных
функций для приема и передачи данных непосредственно через сетевой
адаптер. Назначение этих функций состоит в том, чтобы принять входящий
пакет и передать его в стек протоколов операционной системы для дальнейшей
обработки. Приложение получает пакет без заголовков канального, сетевого и
транспортного уровней, интерпретирует и обрабатывает его и предоставляет в
удобном для пользователя виде.
На рис. 1 приведена структура стека захвата пакетов от сетевого адаптера до
приложения верхнего уровня.
4
Рисунок 1: структура стека захвата пакетов
На нижнем уровне находится сетевой адаптер, принимающий все пакеты,
передаваемые по сети. Драйвер захвата пакетов (pcap-драйвер) packet.vxd
является программным модулем низкого уровня. Он работает на уровне ядра
ОС и взаимодействует непосредственно с драйвером сетевого адаптера. Pcapдрайвер предоставляет набор функций низкого уровня, обеспечивающих прием
и передачу данных на канальном уровне через NDIS, который является частью
сетевой подсистемы Win32. NDIS отвечает за управление различными типами
адаптеров и обеспечивает связь адаптера с программным обеспечением,
отвечающим за формирование пакетов различной структуры.
Динамическая библиотека packet.dll «изолирует» программу пользователя от
драйвера и предоставляет приложению независимый от вида ОС (семейства
Win32) интерфейс. Это позволяет приложению работать на различных
Windows-платформах без перекомпиляции. Библиотека packet.dll работает на
уровне пользователя, но отдельно от приложения.
Статическая
пользователя,
библиотека
libpcap
обеспечивающей
используется
перехват
и
частью
фильтрацию
программы
пакетов.
Она
задействует функции, предоставляемые библиотекой packet.dll, и обеспечивает
5
программе пользователя управление процессами приема и фильтрации данных
на высоком уровне. Библиотека libpcap статически связана с программой
пользователя и является ее частью.
Программа пользователя – высший уровень структуры стека захвата пакетов.
Она обеспечивает обработку принятых пакетов и отображение результатов в
удобном для пользователя виде.
Взаимодействие с NDIS
Спецификация NDIS определяет три типа сетевых драйверов:

драйверы протоколов верхнего уровня (upper level protocol drivers);

драйверы протоколов промежуточного уровня (intermediate protocol
drivers);

драйверы сетевых карт (NIC drivers), сюда входят драйверы сетевых карт
локальных сетей (NDIS LAN Miniport NIC drivers) и драйверы сетевых
карт глобальных сетей (NDIS WAN Miniport NIC drivers).
Драйверы протоколов верхнего уровня
Драйвер протокола верхнего уровня в своей верхней части предоставляет
TDI-интерфейс или, возможно, другой интерфейс, необходимый пользователям
сети. Подобные драйверы выделяют ресурсы для пакетов, копируют данные
приложения в пакеты и передают их драйверам более низкого уровня
посредством вызова NDIS. В своей нижней части этот тип драйверов
обеспечивает интерфейс для получения пакетов от нижележащего драйвера и
передает полученные данные TDI-клиенту или приложению, для которого они
предназначены.
К драйверам протоколов верхнего уровня относится и драйвер транспорта,
реализующий стек сетевых протоколов, такой как IPX/SPX или TCP/IP.
Транспортный драйвер Windows NT реализует TDI-интерфейс в своей верхней
6
части и использует NDIS библиотеку для взаимодействия с драйверами сетевых
карт в своей нижней части.
Драйверы протоколов промежуточного уровня
NDIS драйверы протоколов промежуточного уровня взаимодействуют
сверху с драйверами протоколов верхнего уровня (такими как драйверы
транспортов), а снизу с NDIS драйверами сетевых карт локальных и
глобальных сетей. Ниже NDIS драйвера промежуточного уровня может быть
драйвер,
не
поддерживающий
промежуточного
фильтрацию
и
уровня
могут
шифрование
интерфейс
служить
пакетов,
NDIS.
NDIS
различным
реализацию
целям,
драйверы
включая
специализированных
протоколов и тому подобные функции.
Для драйвера протокола верхнего уровня промежуточный драйвер выглядит
как драйвер виртуальной сетевой карты. Для драйвера реальной сетевой карты
— как драйвер протокола. Промежуточные драйверы могут выстраиваться в
цепочку, хотя такое расположение может оказывать негативное влияние на
производительность системы. Типичный случай разработки и применения
промежуточного драйвера - чтобы выполнять преобразование пакетов для
среды передачи, неизвестной драйверу транспорта, но поддерживаемой
драйвером сетевой карты. Например, может осуществляться преобразование
между протоколом локальной сети и ATM протоколом.
NDIS драйвер промежуточного уровня обычно экспортирует MiniportXxx
функции на своем верхнем уровне и ProtocolXxx функции на своем нижнем
уровне. Реже промежуточный драйвер может экспортировать MiniportXxx
функции на своем верхнем уровне, а в своей нижней части предоставлять
закрытый интерфейс посредством использования пакетов IRP, нижнему
драйверу, не являющемуся NDIS драйвером. Например, промежуточный
драйвер может управлять сетевыми запросами ввода/вывода для устройства,
соединенного с последовательным портом.
7
Промежуточные драйверы ndistapi.sys и ndiswan.sys
Часть интерфейса TAPI располагается в режиме ядра и реализуется
драйвером ndistapi.sys, который взаимодействует с драйвером ndiswan.sys.
Драйвер ndiswan.sys -NDIS драйвер промежуточного уровня, обеспечивающий
РРР форматирование, аутентификацию, сжатие и шифрование для драйверов
сетевых карт глобальных сетей. Он преобразует пакет формата NDIS_PACKET,
получаемый от драйвера транспорта, в пакет формата NDIS_WAN_PACKET, и
передает этот переформатированный пакет нижележащим драйверам сетевых
карт глобальных сетей.
Ndiswan.sys предоставляет интерфейс стандарта 802.3 верхним драйверам
протоколов и выступает в роли драйвера протокола для нижележащих
драйверов сетевых карт глобальных сетей. Ndiswan.sys имеет закрытый
интерфейс с драйвером ndistapi.sys для динамической установки и обрыва TAPI
связей.
Ndiswan.sys преобразует формат отправляемого пакета из LAN в РРР.
Большая часть разбивки фреймов, специфичной для среды передачи, должна
выполняться в драйвере сетевой карты глобальной сети.
Драйверы сетевых карт
NDIS LAN Miniport NIC драйверы поддерживают сетевые карты локальных
сетей. NDIS WAN Miniport NIC драйверы имеют дополнительные требования и
предоставляют приложениям доступ к глобальным сетям, таким как, ISDN,
Frame Relay, Switched 56.
Драйверы сетевых карт в своей нижней части взаимодействуют с
оборудованием, а в верхней части предоставляют интерфейс, позволяющий
верхним уровням посылать пакеты в сеть, сбрасывать и останавливать сетевую
карту, а также осуществлять опрос и установку параметров драйвера сетевой
карты.
8
Существует два типа NDIS драйверов сетевых карт:

Miniport NIC драйвер выполняет специфичные для конкретной сетевой
карты операции, включая отправление и получение данных. Операции
общие для всех драйверов сетевых карт, такие как синхронизация, обычно
обеспечиваются NDIS. Miniport драйвер не вызывает напрямую
обслуживание операционной системы, он взаимодействует с
операционной системой через NDIS.

Full NIC legasy драйверы в настоящее время устарели и используются для
совместимости, они выполняют одновременно специфичные для сетевой
карты операции, а также всю работу по синхронизации, обслуживанию
очередей, обычно выполняемые NDIS. Full NIC драйвер, например,
поддерживает свою собственную информацию о привязках к
вышележащим драйверам для индикации полученных данных. Miniport
драйвер, напротив, не хранит информацию о привязках, он просто
передает пакеты наверх интерфейсу NDIS, а тот уже гарантирует, что
пакеты будут переданы соответствующим драйверам протоколов.
Общий вид структуры NDIS с двумя стеками захвата пакетов, привязанных к
одному сетевому адаптеру, представлен на рис. 2. Один из них состоит из
драйвера NIC и драйвера протокола, другой – из драйвера NIC, промежуточного
драйвера и драйвера протокола.
9
Рисунок 2: структура NDIS
Для
нормальной
работы
драйверу
захвата
пакетов
необходимо
взаимодействовать как с драйвером сетевого устройства (для передачи и приема
данных), так и с приложением пользователя (для получения от него данных или
передачи ему принятых от сетевого устройства пакетов). Поэтому драйвер
захвата пакетов разработан как драйвер протокола в структуре NDIS (рис. 3).
Рисунок 3: положение драйвера захвата пакетов в структуре NDIS
Это
позволяет
ему
работать
со
всеми
сетевыми
устройствами,
поддерживаемыми ОС Windows (адаптерами Ethernet и т. д.). Тем не менее, на
10
данный момент драйвер работает только с адаптерами Ethernet, loopbackадаптерами и поддерживает подключение к глобальной сети через Ethernetадаптер. Пакет протоколов PPP NCP-LCP «прозрачен» для драйверов
протоколов, поскольку PPP-соединения устанавливаются виртуально. Поэтому
драйвер захвата пакетов не может работать с такого рода соединениями.
11
Делегаты
В процессе написания моей программы возникла проблема с обращением к
компонентам формы из другого потока, отличного от того, в котором
происходит захват пакетов.
Для решения данной проблемы был использован метод BeginInvoke
соответствующих компонентов. Данный метод используется для обращения к
компонентам из другого потока. Он является асинхронным, что позволяет
использовать его без зависания самого приложения. В качестве параметров ему
передается делегат и параметры делегата.
Делегаты являются ссылками на методы, инкапсулирующими настоящие
указатели и предоставляющими удобные сервисы для работы с ними. Ссылки
представляют собой объекты соответствующего типа. Все делегаты являются
объектами типа System.Delegate или System.MulticastDelegate, который является
производным от первого.
Уже к окончанию разработки среды исполнения, ее архитекторы пришли к
выводу, что целесообразно использовать только класс MulticastDelegate, а класс
Delegate является избыточным. Но, опасаясь серьезных архитектурных
нестыковок, разработчики были вынуждены оставить класс Delegate в составе
общей библиотеки классов.
Различие между этими классами заключается в том, что экземпляры первого
(делегаты) могут хранить лишь одну ссылку на метод, а экземпляры второго
могут содержать сразу несколько ссылок на методы. Благодаря этому, можно
подсоединять к одному делегату несколько методов, каждый из которых при
единственном обращении к делегату будет вызваться по цепочке. Таким
образом, из программы будет виден лишь один делегат, за которым скрывается
несколько методов (рисунок 4).
Эта возможность очень удобна для поддержки событий, поскольку
позволяет без использования дополнительных механизмов присоединить к
12
событию несколько функций обработчиков. Фактически, делегат представляет
собой объект — черный ящик, скрывающий в своих недрах указатели на
функции. Важно понять, что делегаты, по сути дела, ничем не отличаются от
обычных пользовательских объектов. Главная их особенность состоит лишь в
том, что они имеют поддержку со стороны среды исполнения. Об их свойствах,
в отличие от обычных объектов, знают даже компиляторы, предоставляющие
удобные специальные сервисы для работы с ними.
Рисунок 4. Делегат может ссылаться на несколько методов или функций.
Виды методов
Все методы в среде .NET можно разделить на две группы: статические
(static) и экземплярные (instance).
Если делегат ссылается на статический метод, то все действительно просто.
Так как в этом случае есть вся необходимая для вызова метода информация:
адрес метода и параметры. Если же делегат ссылается на экземплярный метод,
то задача усложняется. Чтобы вызвать экземплярный метод, делегату
необходимо знать ссылку на объект, к которому привязан данный конкретный
метод. Оказывается, что эта ссылка хранится в самом объекте делегата и
указывается при его создании. На протяжении всей жизни объекта делегата
данная ссылка не изменяет своего значения, она всегда постоянна и может быть
13
задана только при его создании. Таким образом, вне зависимости от того,
ссылается ли делегат на статическую функцию или на экземплярный метод,
обращение к нему извне ничем отличаться не будет. Всю необходимую
функциональность обеспечивает сам делегат, вкупе со средой исполнения. Это
очень удобно, поскольку множество разных делегатов можно привязывать к
одному событию.
14
Теория сетей
Стек протоколов TCP/IP
История и перспективы стека TCP/IP
Transmission
Control
Protocol/Internet
Protocol
(TCP/IP)
-
это
промышленный стандарт стека протоколов, разработанный для глобальных
сетей.
Стандарты TCP/IP опубликованы в серии документов, названных Request for
Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet.
Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в
то время как другие обобщают условия применения. Стандарты TCP/IP всегда
публикуются в виде документов RFC, но не все RFC определяют стандарты.
Стек был разработан по инициативе Министерства обороны США
(Department of Defence, DoD) более 20 лет назад для связи экспериментальной
сети ARPAnet с другими сателлитными сетями как набор общих протоколов
для
разнородной
вычислительной
среды.
Сеть
ARPA
поддерживала
разработчиков и исследователей в военных областях. В сети ARPA связь между
двумя компьютерами осуществлялась с использованием протокола Internet
Protocol (IP), который и по сей день является одним из основных в стеке TCP/IP
и фигурирует в названии стека.
Большой вклад в развитие стека TCP/IP внес университет Беркли, реализовав
протоколы стека в своей версии ОС UNIX. Широкое распространение ОС
UNIX привело и к широкому распространению протокола IP и других
протоколов стека. На этом же стеке работает всемирная информационная сеть
Internet, чье подразделение Internet Engineering Task Force (IETF) вносит
основной вклад в совершенствование стандартов стека, публикуемых в форме
спецификаций RFC.
Если в настоящее время стек TCP/IP распространен в основном в сетях с ОС
UNIX, то реализация его в последних версиях сетевых операционных систем
15
для персональных компьютеров (Windows NT 3.5, NetWare 4.1, Windows 95)
является хорошей предпосылкой для быстрого роста числа установок стека
TCP/IP.
Итак, лидирующая роль стека TCP/IP объясняется следующими его
свойствами:

Это наиболее завершенный стандартный и в то же время популярный стек
сетевых протоколов, имеющий многолетнюю историю.

Почти все большие сети передают основную часть своего трафика с
помощью протокола TCP/IP.

Это метод получения доступа к сети Internet.

Этот стек служит основой для создания intranet- корпоративной сети,
использующей
транспортные
услуги
Internet
и
гипертекстовую
технологию WWW, разработанную в Internet.

Все современные операционные системы поддерживают стек TCP/IP.

Это гибкая технология для соединения разнородных систем как на уровне
транспортных подсистем, так и на уровне прикладных сервисов.

Это
устойчивая
масштабируемая
межплатформенная
среда
для
приложений клиент-сервер.
Структура стека TCP/IP. Краткая характеристика протоколов
Так как стек TCP/IP был разработан до появления модели взаимодействия
открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру,
соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.
Структура протоколов TCP/IP приведена на рисунке 5. Протоколы TCP/IP
делятся на 4 уровня.
16
Рис. 5. Стек TCP/IP
Самый нижний (уровень IV) соответствует физическому и канальному
уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется,
но поддерживает все популярные стандарты физического и канального уровня:
для локальных сетей это Ethernet, Token Ring, FDDI, Fast Ethernet, 100VGAnyLAN, для глобальных сетей - протоколы соединений "точка-точка" SLIP и
PPP, протоколы территориальных сетей с коммутацией пакетов X.25, frame
relay.
Разработана
также
специальная
спецификация,
определяющая
использование технологии ATM в качестве транспорта канального уровня.
Обычно при появлении новой технологии локальных или глобальных сетей она
быстро включается в стек TCP/IP за счет разработки соответствующего RFC,
определяющего метод инкапсуляции пакетов IP в ее кадры.
Следующий
уровень
(уровень
III)
-
это
уровень
межсетевого
взаимодействия, который занимается передачей пакетов с использованием
различных транспортных технологий локальных сетей, территориальных сетей,
линий специальной связи и т. п.
В качестве основного протокола сетевого уровня (в терминах модели OSI) в
стеке используется протокол IP, который изначально проектировался как
протокол передачи пакетов в составных сетях, состоящих из большого
17
количества
локальных
сетей,
объединенных
как
локальными,
так
и
глобальными связями. Поэтому протокол 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 накопил
большое количество протоколов и сервисов прикладного уровня. К ним
18
относятся такие широко используемые протоколы, как протокол копирования
файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP,
используемый в электронной почте сети Internet, гипертекстовые сервисы
доступа к удаленной информации, такие как WWW и многие другие.
Остановимся несколько подробнее на некоторых из них.
Протокол пересылки файлов FTP (File Transfer Protocol) реализует
удаленный доступ к файлу. Для того, чтобы обеспечить надежную передачу,
FTP использует в качестве транспорта протокол с установлением соединений TCP. Кроме пересылки файлов протокол FTP предлагает и другие услуги. Так,
пользователю
предоставляется
возможность
интерактивной
работы
с
удаленной машиной, например, он может распечатать содержимое ее
каталогов. Наконец, FTP выполняет аутентификацию пользователей. Прежде,
чем получить доступ к файлу, в соответствии с протоколом пользователи
должны сообщить свое имя и пароль. Для доступа к публичным каталогам FTPархивов Internet парольная аутентификация не требуется, и ее обходят за счет
использования для такого доступа предопределенного имени пользователя
Anonymous.
В стеке TCP/IP протокол FTP предлагает наиболее широкий набор услуг для
работы
с
файлами,
однако
он
является
и
самым
сложным
для
программирования. Приложения, которым не требуются все возможности FTP,
могут использовать другой, более экономичный протокол - простейший
протокол пересылки файлов TFTP (Trivial File Transfer Protocol). Этот протокол
реализует только передачу файлов, причем в качестве транспорта используется
более простой, чем TCP, протокол без установления соединения - UDP.
Протокол telnet обеспечивает передачу потока байтов между процессами, а
также между процессом и терминалом. Наиболее часто этот протокол
используется
для
эмуляции
терминала
удаленного
компьютера.
При
использовании сервиса telnet пользователь фактически управляет удаленным
компьютером так же, как и локальный пользователь, поэтому такой вид доступа
19
требует хорошей защиты. Поэтому серверы telnet всегда используют как
минимум аутентификацию по паролю, а иногда и более мощные средства
защиты, например, систему Kerberos.
Протокол SNMP (Simple Network Management Protocol) используется для
организации сетевого управления. Изначально протокол SNMP был разработан
для удаленного контроля и управления маршрутизаторами Internet, которые
традиционно часто называют также шлюзами. С ростом популярности
протокол SNMP стали применять и для управления любым коммуникационным
оборудованием - концентраторами, мостами, сетевыми адаптерами и т.д. и т.п.
Проблема управления в протоколе SNMP разделяется на две задачи.
Первая задача связана с передачей информации. Протоколы передачи
управляющей информации определяют процедуру взаимодействия SNMPагента, работающего в управляемом оборудовании, и SNMP-монитора,
работающего на компьютере администратора, который часто называют также
консолью управления. Протоколы передачи определяют форматы сообщений,
которыми обмениваются агенты и монитор.
Вторая
задача
характеризующими
связана
состояние
с
контролируемыми
управляемого
устройства.
переменными,
Стандарты
регламентируют, какие данные должны сохраняться и накапливаться в
устройствах, имена этих данных и синтаксис этих имен. В стандарте SNMP
определена спецификация информационной базы данных управления сетью.
Эта спецификация, известная как база данных MIB (Management Information
Base), определяет те элементы данных, которые управляемое устройство
должно сохранять, и допустимые операции над ними.
Протокол доставки пользовательских дейтаграмм UDP
Задачей протокола транспортного уровня UDP (User Datagram Protocol)
является передача данных между прикладными процессами без гарантий
20
доставки, поэтому его пакеты могут быть потеряны, продублированы или
прийти не в том порядке, в котором они были отправлены.
Зарезервированные и доступные порты UDP
В то время, как задачей сетевого уровня является передача данных между
произвольными узлами сети, задача транспортного уровня заключается в
передаче данных между любыми прикладными процессами, выполняющимися
на любых узлах сети. Действительно, после того, как пакет средствами
протокола IP доставлен в компьютер-получатель, данные необходимо
направить конкретному процессу-получателю. Каждый компьютер может
выполнять несколько процессов, более того, прикладной процесс тоже может
иметь несколько точек входа, выступающих в качестве адреса назначения для
пакетов данных.
Пакеты,
поступающие
на
транспортный
уровень,
организуются
операционной системой в виде множества очередей к точкам входа различных
прикладных процессов. В терминологии TCP/IP такие системные очереди
называются
портами.
Таким
образом,
адресом
назначения,
который
используется на транспортном уровне, является идентификатор (номер) порта
прикладного сервиса. Номер порта, задаваемый транспортным уровнем, в
совокупности с номером сети и номером компьютера, задаваемыми сетевым
уровнем, однозначно определяют прикладной процесс в сети.
Назначение номеров портов прикладным процессам осуществляется либо
централизовано,
если
эти
процессы
представляют
собой
популярные
общедоступные сервисы, типа сервиса удаленного доступа к файлам TFTP
(Trivial FTP) или сервиса удаленного управления telnet, либо локально для тех
сервисов, которые еще не стали столь распространенными, чтобы за ними
закреплять стандартные (зарезервированные) номера.
Централизованное присвоение сервисам номеров портов выполняется
организацией
Internet
Assigned
Numbers
Authority.
Эти
номера
затем
21
закрепляются
и
опубликовываются
в
стандартах
Internet.
Например,
упомянутому выше сервису удаленного доступа к файлам TFTP присвоен
стандартный номер порта 69.
Локальное присвоение номера порта заключается в том, что разработчик
некоторого
приложения
просто
связывает
с
ним
любой
доступный,
произвольно выбранный числовой идентификатор, обращая внимание на то,
чтобы он не входил в число зарезервированных номеров портов. В дальнейшем
все удаленные запросы к данному приложению от других приложений должны
адресоваться с указанием назначенного ему номера порта.
Мультиплексирование и демультиплексирование прикладных протоколов
с помощью протокола UDP
Протокол UDP ведет для каждого порта две очереди: очередь пакетов,
поступающих в данный порт из сети, и очередь пакетов, отправляемых данным
портом в сеть.
Процедура обслуживания протоколом UDP запросов, поступающих от
нескольких
различных
прикладных
сервисов,
называется
мультиплексированием.
Распределение протоколом UDP поступающих от сетевого уровня пакетов
между набором высокоуровневых сервисов, идентифицированных номерами
портов, называется демультиплексированием (рисунок 6).
Рис. 6.
22
Хотя к услугам протокола UDP может обратиться любое приложение,
многие из них предпочитают иметь дело с другим, более сложным протоколом
транспортного уровня TCP. Дело в том, что протокол UDP выступает простым
посредником между сетевым уровнем и прикладными сервисами, и, в отличие
от TCP, не берет на себя никаких функций по обеспечению надежности
передачи. UDP является дейтаграммным протоколом, то есть он не
устанавливает логического соединения, не нумерует и не упорядочивает пакеты
данных.
С другой стороны, функциональная простота протокола UDP обуславливает
простоту его алгоритма, компактность и высокое быстродействие. Поэтому те
приложения, в которых реализован собственный, достаточно надежный,
механизм обмена сообщениями, основанный на установлении соединения,
предпочитают для непосредственной передачи данных по сети использовать
менее надежные, но более быстрые средства транспортировки, в качестве
которых по отношению к протоколу TCP и выступает протокол UDP. Протокол
UDP может быть использован и в том случае, когда хорошее качество каналов
связи обеспечивает достаточный уровень надежности и без применения
дополнительных приемов типа установления логического соединения и
квитирования передаваемых пакетов.
Формат сообщений UDP
Единица
данных
протокола
UDP
называется
UDP-пакетом
или
пользовательской дейтаграммой (user datagram). UDP-пакет состоит из
заголовка и поля данных, в котором размещается пакет прикладного уровня.
Заголовок имеет простой формат и состоит из четырех двухбайтовых полей:

UDP source port - номер порта процесса-отправителя,

UDP destination port - номер порта процесса-получателя,

UDP message length - длина UDP-пакета в байтах,
23

UDP checksum - контрольная сумма UDP-пакета
Не все поля UDP-пакета обязательно должны быть заполнены. Если
посылаемая дейтаграмма не предполагает ответа, то на месте адреса
отправителя могут помещаться нули. Можно отказаться и от подсчета
контрольной суммы, однако следует учесть, что протокол IP подсчитывает
контрольную сумму только для заголовка IP-пакета, игнорируя поле данных.
Протокол надежной доставки сообщений TCP
В стеке протоколов TCP/IP протокол TCP (Transmission Control Protocol)
работает так же, как и протокол UDP, на транспортном уровне. Он
обеспечивает
надежную
транспортировку
данных
между
прикладными
процессами путем установления логического соединения.
Единицей
данных
Сегменты TCP
протокола TCP является
сегмент.
Информация,
поступающая к протоколу TCP в рамках логического соединения от протоколов
более
высокого
уровня,
рассматривается
протоколом
TCP
как
неструктурированный поток байт. Поступающие данные буферизуются
средствами TCP. Для передачи на сетевой уровень из буфера "вырезается"
некоторая непрерывная часть данных, называемая сегментом.
В протоколе TCP предусмотрен случай, когда приложение обращается с
запросом о срочной передаче данных (бит PSH в запросе установлен в 1). В
этом случае протокол TCP, не ожидая заполнения буфера до уровня размера
сегмента, немедленно передает указанные данные в сеть. О таких данных
говорят, что они передаются вне потока - out of band.
Не все сегменты, посланные через соединение, будут одного и того же
размера,
однако
оба
участника
соединения
должны
договориться
о
максимальном размере сегмента, который они будут использовать. Этот размер
выбирается таким образом, чтобы при упаковке сегмента в IP-пакет он
помещался туда целиком, то есть максимальный размер сегмента не должен
24
превосходить максимального размера поля данных IP-пакета. В противном
случае пришлось бы выполнять фрагментацию, то есть делить сегмент на
несколько частей, для того, чтобы он вместился в IP-пакет.
Аналогичные проблемы решаются и на сетевом уровне. Для того, чтобы
избежать фрагментации, должен быть выбран соответствующий максимальный
размер IP-пакета. Однако при этом должны быть приняты во внимание
максимальные размеры поля данных кадров (MTU) всех протоколов канального
уровня, используемых в сети. Максимальный размер сегмента не должен
превышать минимальное значение на множестве всех MTU составной сети.
Порты и установление TCP-соединений
В протоколе TCP также, как и в UDP, для связи с прикладными процессами
используются порты. Номера портам присваиваются аналогичным образом:
имеются стандартные, зарезервированные номера (например, номер 21
закреплен за сервисом FTP, 23 - за telnet), а менее известные приложения
пользуются произвольно выбранными локальными номерами.
Однако в протоколе TCP порты используются несколько иным способом.
Для организации надежной передачи данных предусматривается установление
логического соединения между двумя прикладными процессами. В рамках
соединения осуществляется обязательное подтверждение правильности приема
для всех переданных сообщений, и при необходимости выполняется повторная
передача. Соединение в TCP позволяет вести передачу данных одновременно в
обе стороны, то есть полнодуплексную передачу.
Соединение в протоколе TCP идентифицируется парой полных адресов
обоих взаимодействующих процессов (оконечных точек). Адрес каждой из
оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер
порта. Одна оконечная точка может участвовать в нескольких соединениях.
Установление соединения выполняется в следующей последовательности:

При установлении соединения одна из сторон является инициатором. Она
25
посылает запрос к протоколу TCP на открытие порта для передачи (active
open).

После открытия порта протокол TCP на стороне процесса-инициатора
посылает запрос процессу, с которым требуется установить соединение.

Протокол TCP на приемной стороне открывает порт для приема данных
(passive open) и возвращает квитанцию, подтверждающую прием запроса.

Для того чтобы передача могла вестись в обе стороны, протокол на
приемной стороне также открывает порт для передачи (active port) и
также передает запрос к противоположной стороне.

Сторона-инициатор открывает порт для приема и возвращает квитанцию.
Соединение считается установленным. Далее происходит обмен данными
в рамках данного соединения.
Концепция квитирования
В рамках соединения правильность передачи каждого сегмента должна
подтверждаться квитанцией получателя. Квитирование - это один из
традиционных методов обеспечения надежной связи. Идея квитирования
состоит в следующем.
Для того, чтобы можно было организовать повторную передачу искаженных
данных отправитель нумерует отправляемые единицы передаваемых данных
(далее для простоты называемые кадрами). Для каждого кадра отправитель
ожидает от приемника так называемую положительную квитанцию - служебное
сообщение, извещающее о том, что исходный кадр был получен и данные в нем
оказались корректными. Время этого ожидания ограничено - при отправке
каждого кадра передатчик запускает таймер, и если по его истечению
положительная квитанция на получена, то кадр считается утерянным. В
некоторых протоколах приемник, в случае получения кадра с искаженными
26
данными должен отправить отрицательную квитанцию - явное указание того,
что данный кадр нужно передать повторно.
Существуют два подхода к организации процесса обмена положительными и
отрицательными квитанциями: с простоями и с организацией "окна".
Метод с простоями требует, чтобы источник, пославший кадр, ожидал
получения квитанции (положительной или отрицательной) от приемника и
только после этого посылал следующий кадр (или повторял искаженный). Из
рисунка 7 видно, что в этом случае производительность обмена данными
существенно снижается - хотя передатчик и мог бы послать следующий кадр
сразу же после отправки предыдущего, он обязан ждать прихода квитанции.
Снижение производительности для этого метода коррекции особенно заметно
на низкоскоростных каналах связи, то есть в территориальных сетях.
Рис. 7. Метод подтверждения корректности передачи кадров с простоем
источника
Во втором методе для повышения коэффициента использования линии
источнику разрешается передать некоторое количество кадров в непрерывном
режиме, то есть в максимально возможном для источника темпе, без получения
на эти кадры ответных квитанций. Количество кадров, которые разрешается
передавать таким образом, называется размером окна. Рисунок 8 иллюстрирует
данный метод для размера окна в W кадров. Обычно кадры при обмене
нумеруются циклически, от 1 до W. При отправке кадра с номером 1 источнику
разрешается передать еще W-1 кадров до получения квитанции на кадр 1. Если
же за это время квитанция на кадр 1 так и не пришла, то процесс передачи
27
приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается
утерянным (или квитанция на него утеряна) и он передается снова.
Рис. 8 Метод "окна" - непрерывная отправка пакетов
Если же поток квитанций поступает более-менее регулярно, в пределах
допуска в W кадров, то скорость обмена достигает максимально возможной
величины для данного канала и принятого протокола.
Этот алгоритм называют алгоритмом скользящего окна. Действительно, при
каждом получении квитанции окно перемещается (скользит), захватывая новые
данные, которые разрешается передавать без подтверждения.
Реализация скользящего окна в протоколе TCP
В протоколе TCP реализована разновидность алгоритма квитирования с
использованием окна. Особенность этого алгоритма состоит в том, что, хотя
единицей передаваемых данных является сегмент, окно определено на
множестве
нумерованных
байт
неструктурированного
потока
данных,
поступающих с верхнего уровня и буферизуемых протоколом TCP.
Квитанция посылается только в случае правильного приема данных,
отрицательные квитанции не посылаются. Таким образом, отсутствие
квитанции означает либо прием искаженного сегмента, либо потерю сегмента,
либо потерю квитанции.
В качестве квитанции получатель сегмента отсылает ответное сообщение
(сегмент), в которое помещает число, на единицу превышающее максимальный
28
номер байта в полученном сегменте. Если размер окна равен W, а последняя
квитанция содержала значение N, то отправитель может посылать новые
сегменты до тех пор, пока в очередной сегмент не попадет байт с номером
N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае
необходимо приостановить до прихода следующей квитанции.
Выбор тайм-аута
Выбор времени ожидания (тайм-аута) очередной квитанции является важной
задачей, результат решения которой влияет на производительность протокола
TCP.
Тайм-аут не должен быть слишком коротким, чтобы по возможности
исключить избыточные повторные передачи, которые снижают полезную
пропускную способность системы. Но он не должен быть и слишком большим,
чтобы
избежать
длительных
простоев,
связанных
с
ожиданием
несуществующей или "заблудившейся" квитанции.
При выборе величины тайм-аута должны учитываться скорость и
надежность физических линий связи, их протяженность и многие другие
подобные факторы. В протоколе TCP тайм-аут определяется с помощью
достаточно сложного адаптивного алгоритма, идея которого состоит в
следующем. При каждой передаче засекается время от момента отправки
сегмента до прихода квитанции о его приеме (время оборота). Получаемые
значения
времен
оборота
усредняются
с
весовыми
коэффициентами,
возрастающими от предыдущего замера к последующему. Это делается с тем,
чтобы усилить влияние последних замеров. В качестве тайм-аута выбирается
среднее время оборота, умноженное на некоторый коэффициент. Практика
показывает, что значение этого коэффициента должно превышать 2. В сетях с
большим разбросом времени оборота при выборе тайм-аута учитывается и
дисперсия этой величины.
29
Реакция на перегрузку сети
Варьируя величину окна, можно повлиять на загрузку сети. Чем больше
окно, тем большую порцию неподтвержденных данных можно послать в сеть.
Если сеть не справляется с нагрузкой, то возникают очереди в промежуточных
узлах-маршрутизаторах и в конечных узлах-компьютерах.
При переполнении приемного буфера конечного узла "перегруженный"
протокол TCP, отправляя квитанцию, помещает в нее новый, уменьшенный
размер окна. Если он совсем отказывается от приема, то в квитанции
указывается окно нулевого размера. Однако даже после этого приложение
может послать сообщение на отказавшийся от приема порт. Для этого,
сообщение должно сопровождаться пометкой "срочно" (бит URG в запросе
установлен в 1). В такой ситуации порт обязан принять сегмент, даже если для
этого придется вытеснить из буфера уже находящиеся там данные.
После приема квитанции с нулевым значением окна протокол-отправитель
время от времени делает контрольные попытки продолжить обмен данными.
Если протокол-приемник уже готов принимать информацию, то в ответ на
контрольный запрос он посылает квитанцию с указанием ненулевого размера
окна.
Другим проявлением перегрузки сети является переполнение буферов в
маршрутизаторах. В таких случаях они могут централизовано изменить размер
окна, посылая управляющие сообщения некоторым конечным узлам, что
позволяет им дифференцировано управлять интенсивностью потока данных в
разных частях сети.
Формат сообщений TCP
Сообщения протокола TCP называются сегментами и состоят из заголовка и
блока данных. Заголовок сегмента имеет следующие поля:

Порт источника (SOURS PORT) занимает 2 байта, идентифицирует
процесс-отправитель;
30

Порт
назначения
(DESTINATION
PORT)
занимает
2
байта,
идентифицирует процесс-получатель;

Последовательный номер (SEQUENCE NUMBER) занимает 4 байта,
указывает номер байта, который определяет смещение сегмента
относительно потока отправляемых данных;

Подтвержденный номер (ACKNOWLEDGEMENT NUMBER) занимает 4
байта, содержит максимальный номер байта в полученном сегменте,
увеличенный на единицу; именно это значение используется в качестве
квитанции;

Длина заголовка (HLEN) занимает 4 бита, указывает длину заголовка
сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не
фиксирована
и
может
изменяться
в
зависимости
от
значений,
устанавливаемых в поле Опции;

Резерв (RESERVED) занимает 6 битов, поле зарезервировано для
последующего использования;

Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную
информацию о типе данного сегмента, задаваемую установкой в единицу
соответствующих бит этого поля:

URG - срочное сообщение;

ACK - квитанция на принятый сегмент;

PSH - запрос на отправку сообщения без ожидания заполнения буфера;

RST - запрос на восстановление соединения;

SYN
-
сообщение
используемое
для
синхронизации
счетчиков
переданных данных при установлении соединения;

FIN - признак достижения передающей стороной последнего байта в
31
потоке передаваемых данных.

Окно (WINDOW) занимает 2 байта, содержит объявляемое значение
размера окна в байтах;

Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по
сегменту;

Указатель
срочности
(URGENT
POINTER)
занимает
2
байта,
используется совместно с кодовым битом URG, указывает на конец
данных, которые необходимо срочно принять, несмотря на переполнение
буфера;

Опции (OPTIONS) - это поле имеет переменную длину и может вообще
отсутствовать, максимальная величина поля 3 байта; используется для
решения вспомогательных задач, например, при выборе максимального
размера сегмента;

Заполнитель (PADDING) может иметь переменную длину, представляет
собой фиктивное поле, используемое для доведения размера заголовка до
целого числа 32-битовых слов.
Порт (TCP/IP)
Сетевой порт — параметр протоколов TCP и UDP, определяющий
назначение пакетов данных в формате IP, передаваемых на хост по сети.
Это условное число от 1 до 65535, позволяющие различным программам,
выполняемым на одном хосте, получать данные независимо друг от друга
(предоставляют так называемые сетевые сервисы). Каждая программа
обрабатывает данные, поступающие на определённый порт (иногда говорят,
что программа «слушает» этот номер порта).
Обычно
за
некоторыми
распространёнными
сетевыми
протоколами
закреплены стандартные номера портов (например, веб-серверы обычно
32
принимают данные по протоколу HTTP на TCP-порт 80), хотя в большинстве
случаев программа может использовать любой порт.
Номера портов
Порты TCP не пересекаются с портами UDP. То есть, порт 1234 протокола
TCP не будет мешать обмену по UDP через порт 1234.
Ряд
номеров
портов
стандартизован.
Список
поддерживается
некоммерческой организацией IANA.
В большинстве операционных систем прослушивание портов с номерами
1—1023 (почти все из которых зарегистрированы) требует особых привилегий.
Каждый из остальных портов может быть захвачен первым запросившим его
процессом. Однако, зарегистрировано номеров намного больше, чем 1023.
Краткий список номеров портов
Подразумевается использование протокола TCP там, где не оговорено иное.

FTP: 21 для команд, 20 для данных

SSH: 22 (remote access)

telnet: 23 (remote access)

SMTP: 25

DNS: 53 (обычно UDP)

DHCP: 67/68

TFTP: 69/UDP

HTTP: 80, 8080

POP3: 110

NTP: 123 (time server)

IMAP: 143
33

HTTPS: 443

ICQ: 5190

XMPP: 5222/5223 - клиент-сервер, 5269 - сервер-сервер

BitTorrent: 6969, 6881—6889
Порты отправителя и получателя
На самом деле, TCP- или UDP-пакеты всегда содержат два поля номера
порта:
отправителя
и
получателя.
Тип
обслуживающей
программы
определяется портом получателя поступающих запросов, и этот же номер
является портом отправителя ответов. «Обратный» порт (порт отправителя
запросов, он же порт получателя ответов) при подключении по TCP
определяется клиентом произвольно (хотя номера меньше 1024 и уже занятых
портов не назначаются), и для пользователя интереса не представляет.
Использование обратных номеров портов в UDP зависит от реализации.
34
Заключение
Выполнены следующие задачи:
1) Найден подходящий драйвер
2) Изучена структура взаимодействия драйвера в NDIS
3) Драйвер подключен к С# приложению посредством wrapper’а, выполненного
виде DLL
4) В приложении реализован сбор подробной информации о доступных сетевых
адаптерах
35
5) Реализован захват пакетов, фильтрация TCP пакетов, отображение
информации из заголовка пакетов. Информация из пакетов отображается
согласно ASCII таблице.
36
6) Отображается список сетевых соединений, информация по ним, имя и PID
процессов
Таким образом все поставленные цели и задачи достигнуты.
Планы на будущее
1. Вывод подробной статистики использования приложениями сетевых
соединений.
2. Запрет определенных соединений путем добавления функций файервола.
3. Анализ исходящих пакетов на предмет содержания в них важной
информации (пароли, важные файлы).
4. Более подробный вывод содержимого пакетов, фильтрация.
37
Литература
1. Х.М. Дейтэл, C# в подлиннике, «БХВ-Петербург» 2006
2. Кристиан Нейгел, C# 2005 и платформа .NET 3.0, "Диалектика", 2008
38
Приложение
В данной таблице представлены наиболее часто используемые системные и
троянские порты
Системный
порт /
TCP UDP
Троянский
порт
0
20
*
21 / 21
22
23 / 23
25 / 25
42
53
67
68
69
79
80 / 80
88
110
Название порта
Не используется
FTP Data
FTP /
ADM worm, Back Construction, Blade Runner, BlueFire,
Bmail, Cattivik FTP Server, CC Invader, Dark FTP, Doly
*/*
Trojan, FreddyK, Invisible FTP, KWM, MscanWorm,
NerTe, NokNok, Pinochet, Ramen, Reverse Trojan, RTB
666, The Flu, WinCrash, Voyager Alpha Force
*
SSH
Telnet /
ADM worm, Aphex's Remote Packet Sniffer , AutoSpY,
*/*
ButtMan, Fire HacKer, My Very Own trojan, Pest, RTB
666, Tiny Telnet Server - TTS, Truva Atl
SMTP /
Antigen, Email Password Sender, Haebu Coceda, Shtrilitz
*/*
Stealth, Terminator, WinPC, WinSpy, Kuang2, ProMail
Trojan
*
*
WINS
*
*
DNS
*
BOOTPS (DHCP)
*
BOOTPC (DHCP)
*
TFTP
*
Finger
HTTP /
711 trojan (Seven Eleven), AckCmd, BlueFire, Cafeini,
Duddie, Executor, God Message, Intruzzo , Latinus,
*/*
Lithium, MscanWorm, NerTe, Nimda, Noob, Optix Lite,
Optix Pro, Power, Ramen, Remote Shell , Reverse WWW
Tunnel Backdoor, RingZero, RTB 666, Scalper, Screen
Cutter, Seeker, Slapper, Web Server CT , WebDownloader
*
*
Kerberos v5
*
POP 3
39
113 / 113
*/*
119
123
135
*
*
*
*
*
137 / 137
*
*
138
*
139 / 139
*/*
143
161
162
389
443
445
500
515
554
555
563
593
*
666
*
803
993
995
*
*
*
1001
*
1024-65535
1025
1025-1035
*
*
1026
*
1028
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Authentication Service/Identification Protocol /
Invisible Identd Deamon, Kazimas
NNTP
NTP
RPC
NetBIOS Name Resolution /
Chode, Nimda
NetBIOS Datagram service
NetBIOS Session Service /
Chode, God Message worm, Msinit, Netlog, Network,
Qaz, Sadmind, SMB Relay
IMAP
SNMP Service
SNMP Trap service
LDAP
HTTPS
SMB
ISAKMP
LDP
Windows Media Services (RTSP)
Ini-Killer, Phase Zero, Stealth Spy
NNTP over SSL
RPC over HTTP
Satanz Backdoor, Attack FTP, Back Construction, BLA
trojan, NokNok, Reverse Trojan, Shadow
Outpost Firewall
IMAP over SSL
POP3 over SSL
Silencer, WebEx, Der Späher / Der Spaeher, GOTHIC
Intruder, Lula, One Windows Trojan, Theef
Assigned by system on request for outgoing connection
Fraggle Rock, md5 Backdoor, NetSpy, Remote Storm
Dynamic RPC
BDDT, Dark IRC, DataSpy Network X, Delta Remote
Access , Dosh, Duddie, IRC Contact, Remote Explorer
2000, RUX The TIc.K
ICKiller, DataSpy Network X, Dosh, Gibbon, KiLo,
40
1080
1243
1283
1433
1434
1494
1720
1721
1723
1755
1900
*
*
*
*
2000
*
2701-2704
2460
*
2869
*
3128
3306
3389
4661, 4671
4671
4672
4899
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
5000 / 5000 * / *
5004
5005
5050, 5101
5190
5679
5900, 5906
*
*
*
*
*
*
6667
*
KWM, Litmus, Paltalk, SubSARI
SOCKS Proxy
Ultors Trojan, BackDoor-G, SubSeven , Tiles
Skype default port
MS SQL (SQL over TCP)
MS SQL (SQL Probe)
ICA
H.323
L2TP (VPN)
PPTP (VPN)
Windows Media Services - MMS
SSDP
Remote Explorer 2000, Last 2000, Insane Network, Der
Späher / Der Spaeher, Senna Spy Trojan Generator,
ATrojan, InsaneNetwork
SMS Remote Control Agent
Windows Media Services - MS Theater
SSDP event notification, Universal Plug and Play Device
Host
HTTP proxy
MySQL
RDP protocol: Remote desktop / Terminal services
P2P Edonkey2000 server default port
P2P Edonkey2000 client default port
P2P Edonkey2000 client default port
Remote Administrator
SSDP legacy event notification /
Sockets de Troie, Bubbel, Back Door Setup
Windows Media Services - RTP
Windows Media Services - RTCP
Yahoo pager
ICQ
MS Activesync
VNC
Dark FTP, EGO, Maniac rootkit, Moses, ScheduleAgent,
SubSeven, The Thing (modified), Trinity, WinSatan
41
6670
*
6711
*
6969
*
7000
*
8080 / 8080 * / *
12345
12346
21554
22222
24554
26000
27000-27030
*
*
*
*
*
27374
*
29559
*
*
31337
31338
*
*
*
*
*
BackWeb Server, Deep Throat, Foreplay, WinNuke
eXtreame
BackDoor-G, SubSeven, SubSARI, VP Killer, DeepThroat,
Noknok
2000 Cracks, BlitzNet, Dark IRC, GateCrasher, Kid
Terror, Laphex, Net Controller, SpArTa, Vagr Nocker,
Priority
Aladino, Gunsan, Remote Grab, SubSeven , SubSeven 2.1
Gold, Theef
HTTP Alternate or proxy / Brown Orifice, Generic
backdoor, RemoConChubo, Reverse WWW Tunnel
Backdoor, RingZero
GabanBus, NetBus, Pie Bill Gates, X-bill
GabanBus, NetBus, X-bill
Exploiter, Schwindler, Kid Terror, FreddyK, Winsp00fer
Donald Dick, G.R.O.B., Prosiak, Ruler, RUX The TIc.K
BinkP
Quake
Half-Life
Bad Blood, Fake SubSeven, li0n, Ramen, Seeker,
SubSeven , SubSeven 2.1 Gold, Subseven 2.1.4 DefCon 8,
SubSeven 2.2, SubSeven Muie, The Saint
DuckToy, Katux, Latinus, Pest
Back Orifice Client, Baron Night, B02, Bo Facil
BackFire, Back Orifice, DeepBO
Back Orifice, Butt Funnel, NetSpy (DK)
Back Orifice, DeepBO
42