Модульная структура программы

Постановка и анализ задачи

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

Рассмотрим современные утилиты по DNS–туннелированию.

Dnscat – утилита для туннелирования двух произвольных узлов, использующих выбранный DNS сервер. Программа основана на сетевой утилите NetCatи имеет следующие преимущества:

— проходит почти все фаерволы в сети;

— проходит большинство локально установленных сетевых экранов;

— это возможность установки соединения и передачи информации (текстовых сообщений или файлов) между двумя произвольными хостами интернета;

— возможность через уже установленное соединение, удаленно запускать команды системной оболочки (реализуется через опцию –e), а также перенаправлять при этом вывод запускаемых команд на инициирующий соединение хост;

— не использует прокси.

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

Утилита поставляется вместе с исходниками (сразу с клиентской и серверной частью), и может быть скомпилирована под Linux, FreeBSD и Windows.

NameServerTransferProtocol (NSTX) – одна из самых известных и фундаментальных реализаций идеи DNS–туннелинга. Данный комплекс создаёт двунаправленный IP-туннель для передачи данных на базе любого легитимного транзитного DNS–трафика, что особенно удобно вобщественных Wi–Fiсетях, где доступ к определённым ресурсам может быть заблокирован.

Heyoka – это выделяющийся на фоне аналогов инструментарий, который позволяет создавать двунаправленные TCP/IP туннели на основе использования всё того же DNS–трафика.

Heyoka отличается тем, что использует довольно интересный и самобытный алгоритм упаковки, который ощутимо ускоряет транзит трафика на фоне аналогичных инструментов. Так, Heyokaспособен работать с практически неограниченным количеством принимающих трансляцию серверов. Это значит, что на стороне внешнего интернета можно создать сеть сразу из нескольких DNS–серверов, каждый из которых, принимая лишь часть данных, ретранслирует каждый полученный им пакет на некий центральный сервер, который и осуществляет сборку в «одно целое» всей этой «веерно транслируемой» информации (образуя собственную сеть из Серверов по топологии «звезда»).

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

Вторая особенность –Heyoka полностью ориентирован на ОС Windows. У этой утилиты нет конфигурационных файлов, она полностью настраивается через консоль посредством аргументов командной строки. Один и тот же головной exe–файл может быть запущен как в режиме master, равно как и slave, позволяя пробрасывать любой трафик с локального на заданный удаленный порт.

Как и все предыдущие инструменты, Iodine позволяет передавать IPv4 через DNS–трафик. Основные отличия, которые делают его без сомнения очень интересной реализацией:

— впервые используются экспериментальные NULL–пакеты (NULL RDATA format из RFC 1035), что позволяет существенно ускорить трансфер данных, доведя размер одного пакета до 1Кб полезных данных;

— iodine спроектирован очень универсально – он прекрасно работает как на Win32–системах, так и практически на всех Unix–системах. Таким образом, это даёт возможность запустить клиента, например, в среде Windows, а принимающий сервер настроить уже подFreeBSD;

— пакет содержит достаточно хорошую встроенную систему безопасности – он использует аутентификацию на базе MD5–хеша, а также принимает пакеты только с тех IP–адресов, которые сначала прошли аутентификацию, отбрасывая любые другие, какие бы команды они не содержали;

— iodine максимально автоматизирует и упрощает свою настройку. Например, он сам настраивает свой интерфейс во время инсталляции, сам тестирует и выбирает оптимальный по скорости режим передачи данных из множества доступных, к одному серверу может быть подключено одновременно до 16 пользователей–клиентов;

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

Служба должна иметь все стандартные возможности службы, а именно: запуск вручную, приостановка и остановка работы службы. Так же немало важен тот факт, что служебные приложения в операционных системах Windowsимеют специфическую установку. Поэтому необходимо, чтобы у пользователя была возможность как установить, так и удалить службу из диспетчера системных сервисов [4]. К тому же, пользователь должен иметь возможность выбирать, к пакетам каких IP адресов применять подмену портов. Для этого необходимо реализовать специальный файл–фильтр, содержащий в себе список IPадресов и подлежащий заполнению пользователем. Кроме того, необходимо чтобы пользователь имел возможность просматривать итог работы утилиты – реализация лог файла.

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

Все описанные выше возможности изображены на рисунке 1 в виде диаграмы вариантов использования.

Рисунок 1 – Диаграмма вариантов использования со стороны системы прослушки

В данной задаче наиболее важна скорость работы, т.к. служебная утилита обязана быстро отвечать на запросы от диспетчера системных сервисов, а так же не забирать ресурсы активных процессов системы. Именно поэтому в качестве средств реализации был выбран язык C\C++, так как он очень универсален и удобен в написании подобных утилит. В сравнении с его более новым С#, C\C++обеспечивает прирост в производительности на 15–20%, несмотря на более сложную и долгую разработку [1].

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

Анализ данных

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

В качестве логической структуры данных выступают заголовки IP, TCP, UDP, а так же заголовок Ethernetфрейма [3]. Для того, чтобы разобрать пришедший на сетевой интерфейс поток данных необходимо описать структуры данных в конкретном языке программирования для вышеуказанных протоколов.Подробное описание и код данных структур описаны в разделе программной реализации.

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

— каждый IP адрес должен начинаться с новой строки;

— адрес должен представлять из себязапись в виде четырёх десятичных чисел значением от 0 до 255, разделённых точками.

При отсутствии адресов в данном файле служба прекратит свою работу на этапе запуска.

Программная реализация

На данном этапе были разработаны следующие структуры данных:

— структура заголовка Ethernetфрейма, показана на рисунке 2;

— структура заголовка IP пакета, показана на рисунке 3;

— структура заголовка TCPсегмента, показана на рисунке 4;

— структура заголовка UDP сегмента, показана на рисунке 5.

Рисунок 2 – Код структуры Ethernet фрейма

Рисунок 3 – Код структуры IPпакета

Так как приложение изначально задумывалось как служба, то был разработан базовый класс службы ServiceBaseи унаследованный от него класс SampleService. Данные классы реализуют основные функции системы, присущий каждой службе Windows: запуск, приостановку, остановку работы, главную функцию сервиса (регистрирует управляющую функцию), управляющую функцию (служит для связи с диспетчером системных сервисов).

Рисунок 4 – Код структуры TCPсегмента

Рисунок 5 – Код структуры UDPсегмента

Для установки и удаления службы из диспетчера системных сервисов написан класс ServiceInstaller. Он предназначен только для установки и удаления служб. Заголовочные файлы всех вышеописанных классов можно посмотреть в приложении А.

Алгоритм подмена порта в пакете состоит в следующем: после принятия данных с сетевого интерфейса происходит проверка на совпадения с адресом из файла–фильтра, если оно имеется, то смотрится порт отправления. При несовпадении его с рабочим портом (в данном случае 53), то происходит подмена и занесение подменяемого порта в область данных пакета вместе с уникальной последовательностью из 16 бит.

Если же нет совпадения со списком IP адресов из файла–фильтра, то происходит проверка на соответствие порта назначения рабочему порту (в данном случае 53). При успехе проверяются первые 16 бит данных, если они совпадают с уникальной последовательностью, то из пакета извлекаются следующие 16 бит (первоначальный порт назначения) и данным возвращается исходное значение, как и порту назначения. Таким образом осуществляется простейшее DNS–туннелирование.

Модульная структура программы

Модульная структура программы представлена в виде диаграммы компонентов на рисунке 7, описание приведено в таблице 1.

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

Таблица 1 – Описание компонентов программы

Тестирование

Тестирование – это любая деятельность, направленная на обнаружение ошибок. На данномэтапе было выявлено и устранено множество ошибок, вот их неполный список:

— неверная работа с буферами памяти, приводящая к некоректному результату в части возвращения пакета к исходному виду;

— ошибка при установке службы – неверные параметры пользователя системы;

— ошибки, связанные с особенностями инициализации необходимых библиотек;

— неверная работа с буфером сетевых устройств.

Тестирование службы проводилось как «ручным» методом, просмотром исходного кода, так и детерминированным тестированием, путём многократного выполнения программы.

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

Техническое задание

6.1 Введение

Служба подмена порта должна связать два узла в обмене сообщений, если ранее это было невозможно из–за фаервола.

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

6.2Цели и задачи внедрения системы

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

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

6.3 Требования к функциональным характеристикамсо стороны системы прослушки сообщений

— возможность прослушивать входящие и выходящие данные с сетевого узла;

— анализ приходящих пакетов;

— отправка полученных данных как в исходном виде, так и с подмененным портом;

— запись исходного порта пакета вместе с данными;

— восстановление исходного вида пакета.

6.4 Требования к надежности

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

6.5 Требование к составу и параметрам технических средств

Программа должна работать на компьютерах со следующими характеристиками:

Минимальные требования к компьютеру пользователя:

-процессор не ниже IntelPentium 4;

— ОЗУ не менее 256 Mb;

— 20 Mb свободного дискового пространства;

— сетевая карта.

Оптимальные требования к компьютеру пользователя:

— процессор не ниже IntelCore 2 duo;

— ОЗУ не менее 512 Mb;

— 20Mb свободного дискового пространства;

— сетевая карта.

6.6 Требования к программной документации

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

Денис Цветцих. Модульная структура приложения, быть или не быть?

Похожие статьи.

• Структура и виды программ, среда разработки

• Контроль структуры программы.

• Структура простой программы и комментарий

• Структура программы на языке ассемблера.