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

## **Инфраструктура**

<center>Рисунок 1. Инфраструктура </center>

---

## **ICMP туннелирование**
> **ICMP (Internet Control Message Protocol)** — протокол управления сообщениями в Интернете, используется IP-устройствами, чтобы информировать другие IP-устройства о действиях и ошибках в сети. Без TCP IP не является надежным протоколом: он не отправляет подтверждения, не проверяет данные на ошибки (только контрольную сумму заголовка) и не повторяет передачу.

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

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

**git clone** https://github.com/friedrich/hans
<center>Рисунок 2. Установил hans</center>

<center>Рисунок 2.1. Компилирование hans</center>

<center>Рисунок 2.2. Установил net-tools</center>

Запустил hans от рута (рис. 2.3.) с помощью команды: **./hans -s 10.1.2.0 -p 123**. Так же проверил, что интерфейс tun0 поднялся.

<center>Рисунок 2.3. Запуск hans от рута</center>

Всё то же самое теперь делаю на машинке Linux vpn client.

<center>Рисунок 2.4. Установил hans</center>

Далее я создал папку hans, перешёл в неё, устанавливаем make, net-tools и g++. После этого я запустил make (рис. 2.5).
<center>Рисунок 2.5. Собрал hans</center>

Подключился к серверу с помощью команды: **./hans -c 192.168.28.137 -p 123**. Интерфейс tun1 поднялся, туннель есть. Проверил, что tun1 интерфейс пингует и я подключился по SSH к Linux VPN client. (рис. 2.6).
<center>Рисунок 2.5. Поднял tun1 интерфейс</center>

<center>Рисунок 2.6. tun1 интерфейс пингует, подключился к руту</center>

На рисунке 2.7. показан WireShark. Я зашёл в него в pfSense на внутреннем интерфейсе e1 и отфильтровал трафик по ICMP. В каждом трафик есть маркировка **hans**
<center>Рисунок 2.7. ICMP трафик</center>

Пропинговал с машинки Linux-VPN **8.8.8.8** и заметил, что в трафик ICMP в WireShark нет маркировки **hans**. Это значит, что пакет стандартный.

<center>Рисунок 2.8. ping 8.8.8.8 и ICMP трафик</center>

---

## **Простое DNS-Туннелирование**

>DNS-tunneling — техника, позволяющая передавать произвольный трафик (фактически, поднять туннель) поверх DNS-протокола. Может применяться, например, для того чтобы получить полноценный доступ к Интернет из точки, где разрешено преобразование DNS-имён. Для организации DNS-туннеля необходимо чтобы снаружи (то есть, в точке, куда направлен туннель) его кто-то принимал. Точка приёма является сервером имён для какой-то зоны. Изнутри сети делаются запросы имён по этой зоне. Так передаётся трафик изнутри <—. В качестве результата преобразования возвращаются ответные данные. Так передаётся трафик внутрь —>.
>
>DNS-туннелирование нельзя запретить простыми правилами брандмауэра, разрешив при этом остальной DNS-трафик. Это связано с тем, что трафик DNS-туннеля и легитимные DNS-запросы неразличимы. Обнаруживать DNS-туннелирование можно по интенсивности запросов (если трафик по туннелю велик), а также более сложными методами, используя системы обнаружения вторжений.
>
>DNS-туннелирование превращает систему доменных имён в оружие хакеров. DNS – это огромная телефонная книга интернета. А ещё DNS является базовым протоколом, позволяющим администраторам делать запросы в базу данных DNS-сервера. Но хитрые хакеры осознали, что можно скрытно общаться с компьютером-жертвой путём внедрения управляющих команд и данных в протокол DNS. Эта идея и лежит в основе DNS-туннелирования.

Установил утилиту iodine (рис. 3.). Эту же утилиту я поставил на Linux VPN client (рис. 3.1).
<center>Рисунок 3. Утилита iodine</center>

<center>Рисунок 3.1. Утилита iodine</center>

Запустил на Kali Linux утилиту iodine с помощью команды: **iodined -P 123 10.99.99.1/24 -c i.example.com**. После этого появился dns0 интерфейс (рис. 3.2).

<center>Рисунок 3.2. Утилита iodine</center>

Настроил Linux VPN client. Прописал в конфиге resolv.conf DNS и IP Kali машинки, с помощью команды: **nano /etc/resolv.conf**.
<center>Рисунок 3.3. resolv.conf</center>

Запустил iodine на Linux VPN client, с помощью команды: **iodine -P 123 i.example.com**.

<center>Рисунок 3.4. iodine</center>

---

## **Сложное DNS-Туннелирование**
> Создаём 2 DNS сервера, один внутренний, другой внешний. Внешний будет передавать данные фейкому DNS серверу.

### **DNS-Server internal**
<center>Рисунок 4. IP адрес для внутреннего сервера</center>

<center>Рисунок 4.1 dig DNS</center>

<center>Рисунок 4.2 Настройка DNS</center>

Всё пингуется, всё хорошо работает, dns отрабатывает. Вся настройка для внутреннего DNS сервера завершена.

<center>Рисунок 4.3. Пинг почты и впн </center>

---

### **DNS-Server external**

Перенаправляет DNS, которые он не знает на яндексовский DNS.
<center>Рисунок 5. Яндексовский DNS</center>

<center>Рисунок 5.1. resolv.conf на Kali internal</center>

<center>Рисунок 5.2. </center>

На фаерволле разрешил траффик на 53 порту.
<center>Рисунок 5.3 UDP, 53 port</center>

На этом работу с машинкой Kali internal на данный момент закончил и открыл машинку Kali-2022, вот ip a этой машинки.
<center>Рисунок 5.4. ip a</center>

Добавил DNS ZONE на DNS-External (внешний).
<center>Рисунок 5.5. DNS ZONE</center>

Создал DNS ZONE mirea.tech на DNS external.
<center>Рисунок 5.6. DNS ZONE</center>

### **Kali-2022 (external)**
Создаю новую запись, назначил ip этого же DNS сервака. Это значит, что если будет обращаться к mirea.tech будем попадать именно на него.
<center>Рисунок 5.7. Новая запись</center>

Создаю ещё одну запись и указываю в ней IP адрес Kali-2022
<center>Рисунок 5.7. Новая запись Kali-2022</center>

<center>Рисунок 5.8. delegate.mirea.tech</center>

>На рисунке 5.9 и 6 видно, что я сделал dig запрос на mirea.teсh и vk.com, DNS настроены правильно.
С внутренней Kali попал на DNS-Internal, DNS-Internal проходится до DNS-External, DNS-External видит, что у него есть зона mirea.tech и у неё есть делегация на tunnel.mirea.tech, после этого я попал на внешнюю Kali, где настроен DNS сервер.

<center>Рисунок 5.9. dig</center>

<center>Рисунок 5.9. dig NS tunnel</center>

<center>Рисунок 6. iodine</center>

### **Kali internal**

Запуск iodine с внутренней Kali Linux и пропинговал 10.99.99.1
<center>Рисунок 6.1. iodine</center>

Сделал доступ в интернет с Kali-internal, настроив ля этого на Kali-External файл /etc/sysctl.conf, для маршрутизации трафика.
<center>Рисунок 6.2. nano /etc/sysctl.conf</center>

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

<center>Рисунок 6.3. Настройка NAT</center>

Настроил роутинг, удалив дефолтный маршрут и вместо него поставил **10.99.99.1**
<center>Рисунок 6.4. Добавил маршрут 10.99.99.1</center>

Сделал доступ в интернет с внутренней Кали, даже могу зайти в одноклассники, но интернет очень долго отрабатывает.
<center>Рисунок 6.5. Есть доступ в интернет</center>

---