Беспроводная сеть на ладони или ICMP туннель в действии. Как выявить скрытую передачу данных в сети? Как может быть обнаружена скрытая передача

Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.

Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.

ICMP - яблоко раздора

Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на . Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!

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

Echo запрос и and Echo ответ

IPv4 – Echo запрос (Type8, Code0) и Echo ответ (Type0, Code0)
IPv6 – Echo запрос (Type128, Code0) and Echo ответ (Type129, Code0)

Мы все хорошо знаем, что ping, - один из первых инструментов для поиска и устранения неполадок. Да, если вы включите на своем оборудование обработку ICMP-пакетов, то это значит, что ваш хост теперь доступен для обнаружения, но разве ваш уже не слушает порт 80, и не отправляет ответы на клиентские запросы? Конечно, заблокируйте ещё и эти запросы, если вы действительно хотите, чтобы на границе сети была ваша DMZ. Но блокируя ICMP трафик внутри вашей сети, не усилите защиту, напротив получите систему с излишне сложным процессом поиска и устранения неполадок («Проверьте пожалуйста отзывается ли шлюз на сетевые запросы?», «Нет, но это меня ничуть не расстраивает, потому что мне это ничего не скажет! »).

Помните, также можете разрешить прохождение запросов в определенном направлении; например, настроить оборудование так, чтобы Echo запросы из вашей сети проходили в сеть Интернет и Echo ответы из Интернета в вашу сеть, но не наоборот.

Необходима фрагментация пакета (IPv4) / Пакет слишком большой (IPv6)

IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)

Данные компоненты протокола ICMP очень важны, так как являются важным компонентом в Path MTU Discovery (PMTUD), который является неотъемлемой частью протокола TCP. Позволяет двум хостам корректировать значение максимального размера сегмента TCP (MSS) до значения, которое будет соответствовать наименьшему MTU по пути связей между двумя адресатами. Если на пути следования пакетов будет узел с меньшим Maximum Transmission Unit, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».

Don’t Fragment – ICMP не пройдет!

Передача IPv4-пакетов с установленным битом Don’t Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required ), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge ) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.

Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена TCP-рукопожатиями (TCP-handshake) работает нормально, поскольку в нем задействованы небольшие пакеты, но как только происходит массовая передача данных сеанс передачи зависает, так как источник передачи не получает сообщения об ошибках.

Исследование пути доставки пакетов

RFC 4821 был разработан для того, чтобы помочь участникам передачи трафика в сети обойти эту проблему, используя исследование пути распространения пакетов (Path MTU Discovery (PLPMTUD) . Стандарт позволяет обнаружить максимальный объём данных (Maximum Transmission Unit (MTU) , который может быть передан протоколом за одну итерацию, путем постепенного увеличения максимального размера полезного блока данных (Maximum Segment Size (MSS) , для того чтобы найти максимально возможную величину пакета без его фрагментации на пути следования от передатчика к приемнику. Данный функционал уменьшает зависимость от своевременного получения ответов с ошибками по протоколу межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) и доступен в большинстве сетевых стеков устройств и клиентских операционных систем. К сожалению, он не так эффективен, как непосредственное получение данных о максимальном возможном размере передаваемых пакетов. Пожалуйста, позвольте этим сообщениям протокола ICMP возвращаться к источнику передачи, хорошо?

Превышение времени передачи пакетов

IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)

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

Отправляет пакет с временем жизни пакета данных для протокола IP (Time to live (TTL) равным 1 , чтобы первый маршрутизатор отправил сообщение с ошибкой (включая собственный IP-адрес) о превышении времени жизни пакета. Затем отправляет пакет с TTL 2 и так далее. Данная процедура необходима для того, чтобы обнаружить каждый узел на пути следования пакетов.

NDP and SLAAC (IPv6)

Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)

В то время как IPv4 использовал протокол разрешения адресов (ARP) для сопоставления 2 и 3 уровней сетевой модели OSI, IPv6 использует другой подход в виде протокола обнаружения соседей (NDP). NDP предоставляет множество функций, включая обнаружение маршрутизатора, обнаружение префикса, разрешение адреса и многое другое. В дополнение к NDP, Автоконфигурация (StateLess Address AutoConfiguration (SLAAC) позволяет динамически настраивать хост в сети, аналогично концепции протокола динамической настройки узла (Dynamic Host Configuration Protocol (DHCP) (хотя DHCPv6 предназначается для более тонкого управления).

Эти пять типов ICMP сообщений не должны блокироваться внутри вашей сети (не учитываем внешний периметр), чтобы протокол передачи данных IP функционировал правильно.

Нумерация типов ICMP

Протокол межсетевых управляющих сообщений (ICMP) содержит много сообщений, которые идентифицируются полем «тип».

Тип	Наименование	Спецификация
0	Echo Reply
1	Unassigned
2	Unassigned
3	Destination Unreachable
4	Source Quench (Deprecated)
5	Redirect
6	Alternate Host Address (Deprecated)
7	Unassigned
8	Echo
9	Router Advertisement
10	Router Solicitation
11	Time Exceeded
12	Parameter Problem
13	Timestamp
14	Timestamp Reply
15	Information Request (Deprecated)
16	Information Reply (Deprecated)
17	Address Mask Request (Deprecated)
18	Address Mask Reply (Deprecated)
19	Reserved (for Security)	Solo
20-29	Reserved (for Robustness Experiment)	ZSu
30	Traceroute (Deprecated)
31	Datagram Conversion Error (Deprecated)
32	Mobile Host Redirect (Deprecated)	David_Johnson
33	IPv6 Where-Are-You (Deprecated)
34	IPv6 I-Am-Here (Deprecated)
35	Mobile Registration Request (Deprecated)
36	Mobile Registration Reply (Deprecated)
37	Domain Name Request (Deprecated)
38	Domain Name Reply (Deprecated)
39	SKIP (Deprecated)
40	Photuris
41	ICMP messages utilized by experimental mobility protocols such as Seamoby
42	Extended Echo Request
43	Extended Echo Reply
44-252	Unassigned
253	RFC3692-style Experiment 1
254	RFC3692-style Experiment 2
255	Reserved

Пара слов об ограничении скорости

Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.

Читать, исследовать и понимать

Учитывая, что обсуждение темы «блокировать или не блокировать» ICMP-пакетов, всегда приводит к путанице, спорам и разногласиям, предлагаю продолжить изучать эту тему самостоятельно. На этой странице привел много ссылок, считаю для более полного понимания проблематики следует потратить время на их чтение. И сделать осознанный выбор того, что лучше всего подходит для вашей сети.

MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс «Настройка оборудования MikroTik ». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.

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

1. Введение.

У меня только появился мой первый ноутбук, и я хотел попробовать и сделать что-нибудь непотребное с его помощью (даже пробовал сделать какую-то работу, но это было слишком утомительно
:)). Wardriving по началу был довольно увлекательным занятием, но мне стало скучновато когда я понял, что сети, защищенные
WEP`ом, мне не по зубам (так как внутрисетевого трафика не было – сети можно было считать умершими), а незащищенные сетки вообще не представляют никакого интереса. К счастью, беспроводная сетка в моем студенческом городке оказалась немного более интересной.

Сеть предоставляет бесплатный беспроводной Интернет, но требует регистрации твоего MAC адреса на свое имя перед разрешением доступа – незарегистрированные пользователи переадресовываются на страницу провайдера (на страницу регистрации). Регистрация повлекла бы двухминутное общение с администратором, но я подумал: «Может есть
способ получить доступ избежав подобного общения?» Разумеется, он был.

2.Первый способ проникновения – МАС spoofing.

Поскольку все крутилось вокруг МАС адреса, первое, что пришло на ум,
было узнать уже зарегистрированный МАС адрес и заняться его
спуфингом. Разумеется, говорить легко, но это не требовало почти никаких усилий даже учитывая то, что раньше я этим никогда не занимался.
Первое что я сделал, это запустил kismet ("kismet -c orinoco,eth1,wifi") и поснифал сетку. Kismet сохраняет все поснифанную
информацию в файл ("/var/log/kismet/*.dump" в моем случае), результаты снифинга можно смотреть по мере их
поступления. В результате я смог просмотреть всю информацию и
записать подходящий МАС адрес.

Команды, используемые для смены МАС адреса сетевой карты:

ifconfig eth1 down
killall dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 up
dhclient eth1

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

Не все рабочие станции были активны, и использование kismet с просмотром результатов по мере поступления было неэффективно, так что я попробовал другой метод.

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

marktwain:~# nmap -sP 10.0.0.1/22
Starting nmap 3.81 (http://www.insecure.org/nmap/) at 2005-05-23 12:54 EEST
Host 10.1.0.14 appears to be up.
MAC Address: 00:0E:35:97:8C:A7 (Intel)
Host 10.1.0.95 appears to be up.

Host 10.1.0.109 appears to be up.
MAC Address: 00:0D:54:A0:81:39 (3Com Europe)
... snip ...
Host 10.1.2.92 appears to be up.
MAC Address: 00:02:2D:4D:1C:CE (Agere Systems)
Host 10.1.2.187 appears to be up.
MAC Address: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap finished: 1024 IP addresses (20 hosts up) scanned in 53.980 seconds

Куча МАС адресов. Большая часть
получившейся таблицы адресов (как я предполагаю) – МАС-адреса машин, посетивших сеть за последние несколько дней. В таблице было 245 различных МАС
адреса. Я не знаю, нормальное ли это поведение для
точки доступа, но думаю ребятам стоит что-либо
изменить в раздаче Интернета. Как бы там ни было, сейчас у меня есть достаточно МАС-адресов машин, которые посетили сетку, но, вероятнее всего, давно ушли. Пара попыток спуфинга, и я уже плыл к neworder.box.sk...

3. Попытка номер 2 - ICMP-туннелинг.

Я выполнил все, что хотел, но в этой сети еще было где покопаться. Но что
я мог бы сделать, если бы в этой сети не было
бы ни одной машины, принадлежащей мне? Если
бы nmap не открыл и не показал все эти МАС адреса? Так что как бы то ни было, я решил попробовать другой путь получения доступа.

Это не упоминалось ранее, но в обход системы
раздачи Интернета, дающей разрешение, и DHCP, сетка разрешала ICMP сообщениям проходить свободно. Проверка активности любого Интернет сайта работала отлично (действительно не могу понять, почему они ее не заблокировали – разве что забыли), ping
обнаруживался даже на сниффере, который работал на моем сервере.
Мой план был попытаться создать туннель между моим ноутбуком в университете и сервером дома. И пропустить все соединения через него.
Я поискал приложения ICMP туннелинга в Интернете, но ни одно не работало так, как мне бы хотелось (а именно, мне хотелось, чтобы оно было простым – таким, что если я запущу мой любимый браузер или любую другую программу, она будет просто работать с туннелем) или хотя бы
выглядело удобоваримым.

4. Немного кодинга.

Сначала я не планировал что-либо кодить. Просто пробовал некоторые приложения ICMP туннелей
с packetstorm, но тут неожиданно обнаружил, что читаю исходник одного из них, и осознаю, насколько это изумительно просто, и насколько легко будет сделать что-то наподобие. Название программы – itunnel -
обычная утилита для ICMP- туннелинга. Itunnel потрясающий. Но это всего лишь туннель. Вы запускаете ее на одной машине, и в итоге это выглядит так, как будто вы соединили две
сетевых карты вместе. Этого было недостаточно для того, что я хотел сделать.
Я уже слышал о модуле kernel module TUN/TAP, который позволяет процессам пользователя получать и отправлять пакеты информации прямо в/из ядра.

Программа создает виртуальный сетевой интерфейс.
Она создает сетевой интерфейс, который
работает совершенно аналогично
стандартному. Самое интересное то, что
пользовательские программы должны
работать как физический уровень для интерфейса
туннеля. Они должна читать пакеты информации из
файла устройства (например, "/dev/net/tun0") и пересылать их любыми средствами и писать ответные пакеты
обратно в файл.

Я не смог найти ни одного хорошего ресурса
по TUN/TAP, но существует программа – vtun – которая использовала TUN/TAP для своих туннелей, так что я
поюзал исходники vtun. После небольшого исследования выяснилось, что там была крошечная библиотека функций, используемых, чтобы создавать, читать из и писать в tun*
устройства. Зачем мне писать программу самому, если ее можно сделать, исправив пару бит?
Код, который я фактически написал:

#include "driver.h" /* декларируем библиотеку vtun */
#include
#include

/* немного модифицированный main() из itunnel
*/
int run_icmp_tunnel (int id, int packetsize, char *desthost, int tun_fd);

/* максимальный unit – максимальный
размер капсулированного пакета
*/
const int mtu = 1400;

int main(int argc, char **argv) {
char *dev;
int tun_fd = 0;

/* создание tunnel-устройства */
dev = (char *) malloc(16);
if (dev == NULL) {
printf("если у вас никогда не было проблем с
выделением 16 bytes\"
"памяти – это ваш первый раз. Fatal.n");
return 1;
}
dev = 0;
/* неплохая библиотечная функция
из vtun принимает пустую строку как *
* аргумент, создает tunX девайс и
передает его *dev */
tun_fd = tun_open(dev);

if (tun_fd < 1) {
printf("Не удается создать устройство. Fatal.n");
return 1;
}
else {
printf("Создано тунелинг устройство: %sn", dev);
}

/* 7530 - это ICMP id поле,
используемое для пакетов в туннеле
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);

tun_close(tun_fd, dev);
}

Вот он. И большая его часть – комментарии и проверка ошибок

Как я уже упоминал, itunnel идеальна для строительства туннеля. У нее есть главная функция, которая
открывала файлы для ввода, вывода и socket; так же
получала какие-то параметры для командной строки (что могло пригодиться для моих целей). Далее она вызывала немного абстрактную функцию, которая по существу просто транспортировала пакеты информации. ICMP заголовок свободно
описан в коде и может быть легко изменен на любой другой заголовок,
ввод/вывод/socket может быть настроен по какой-то другой логической схемой – функция будет работать с минимальными корректировками.

Самая большое изменение, которое я сделал – удаление всех манипуляций с командной строкой – по существу удаление нескольких блоков кода. Что наиболее важно для логической схемы туннеля, я удалил различие между вводом и выводом, так как они оба
висят на одном и том же дескрипторе (tunX девайс) –
это дало мне то, что вместо того, чтобы вести себя как
netcat и форвардить stdin в ICMP сокет и ICMP сокет в stdout,
он посылает исходящий сигнал в tunX девайс (как http запросы с браузера) к ICMP
сокет и ICMP сокет вывод (как если бы HTTP
запросы от сервера посылались обратно
через туннель) в tunX девайс (чтобы
возвратится обратно к браузеру). Так как последнее предложение очень длинное и витиеватое, я предоставляю небольшую схему, чтобы показать наглядно:

Ответные пакеты информации идут по той же дорожке, но
обратным путем.

В одном месте я уже достаточно свихнулся и фактически написал новую строку кода. Она выглядит так:

memcpy(&(target->sin_addr.s_addr), &(from.sin_addr.s_addr), 4);

Ее функция – начать отсылать все пакеты информации туда, откуда прибыл последний пакет. Я могу
запустить ее на моем сервере и соединившись
из любого места отослать пакет через туннель
и она мгновенно изменяет IP получателя на IP
моего ноутбука.

То, что получилось в результате, вы можете взять отсюда:

5. Установка туннелей.

Я испытал туннель дома и он работал отлично, но дома не было firewall`a. На следующий день в университете я был готов проверить его в реальной жизни. Случайно, сидя за столиком в кафе, я с помощью спуфинга нашел МАС адрес и установил туннель.

Сложно запомнить все глупые способы, которые я пробовал, и небольшие эксперименты, которые я провел, так что я постарался сделать эту часть как можно более систематизированной. На самом деле я не делал все так четко.
На то, что бы заставить все работать у меня
ушло 3 часа, и я попробовал все, что можно пока занимался сниффингом везде, где только можно, и модифицировал код так, чтобы он скандировал "Pаcket!", когда получает пакет информации, и что-нибудь раздражающее, когда отправляет свой пакет. И так далее.

Я запустил эти команды на сервере:

tsee-diees:~# ./create_tun wifi.ttu.ee
Created tunnel device: tun0

Stopped ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 up
tsee-diees:~# route add 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"

Я подумал, что это будет работать немедленно, и просто запустил это на своем ноутбуке:

marktwain:~# ./create_tun 194.204.48.52
Created tunnel device: tun0

Stopped ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 up
marktwain:~# route add 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"

То, что мне нужно было сделать – это создать
сеть с двумя хостами на нем – сервер как 192.168.3.1 и ноутбук как 192.168.3.2. Простой нормальный LAN, только его физический слой будет ICMP туннелем. Как вы наверное
поняли из оставшегося текста в статье
способ не особо сработал. Я запустил пинг ("ping 192.168.3.1"), но пакеты все равно не проходили.

К счастью сниффер на ноутбуке дал мне небольшой ключ – пакеты ICMP были обратными ответами. Разумеется, они не
отправлялись. Так что убиваем туннель, включаем itunnel на ноуте и используем обратные ответы icmp (меняем "icmp->type = 0;" на "icmp->type = 8;"), возвращаем туннель.
Система все еще не заработала, но на этот раз пакеты
появились на сниффере на сервере.

Что может быть не так? Я попробовал одну модификацию, которая должна была кричать "Pаcket!", когда очередной пакет приходил, но восклицания не
возникало. «А почему, собственно, должно – удивился я, - если firewall установлен блокировать все ICMP пакеты из Интернета?» Через некоторое время я понял, что так и есть на самом деле (все ICMP пакеты из Интернета блокировались).

Уже лучше. Туннель восклицает "Pаcket!" , и ответы можно увидеть на сниффере на сервере. На самом деле, там два ответа на каждый запрос, только один из которых можно увидеть на сниффере на ноутбуке. А пинг до сих пор не работает.

Так как один из двух пакетов избыточный, я указал ядру (kernel) не отвечать на обратные запросы icmp:

tsee-diees:~# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

И пинги начали проходить! В этот момент я все еще полагался на полученный в ходе спуфинга МАС-адрес, чтобы получить доступ на сервер. Так как идея была получить перемещающиеся в обоих направлениях пакеты со стороны незарегистрированного пользователя, я прекратил спуфить МАС-адреса. При этом туннель продолжил работать, что было довольно приятным сюрпризом.

Поток пакетов удалось наладить, и наступило время заставить «интернет» работать.
Нужно было внести некоторые изменения в IP
роутинг на ноутбуке. Путь через
университетский маршрутизатор беспроводной сети должен был быть заменен туннельным адресом сервера (192.168.3.1 в данном случае). Здесь все еще должен быть путь к серверу, такой, чтобы туннель сам по себе мог работать (туннельным ICMP пакетам тоже нужен путь, чтобы по нему следовать).
Я получил неплохие результаты:

marktwain:~# route add 194.204.48.52 gw 10.0.0.111 # through the wireless router
marktwain:~# route del default
marktwain:~# route add default gw 192.168.3.1 # everything else through the tunnel.

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

marktwain:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) bytes of data.

Разумеется, никаких ответов не было, потому что это не были «туннельные пинги», а ответы с ядра были
выключены.

Так как мой сервер уже был научен
разделять Интернет соединение между несколькими компьютерами, все, что мне надо было сделать на сервере – это добавить два правила для
FORWARD chain в iptables чтобы принимать пакеты из и к tun0. Когда я в плановом порядке проверял текущие правила ("iptables -vL FORWARD"), соединение внезапно умерло. Я повторно соединился и исследовал этот вопрос,
но вскоре соединение снова умерло. Я был действительно удивлен – почему соединение такое неустойчивое?
Подумав я понял, что каждый раз, когда сервер посылал большой ICMP ответ
(ведь только заголовок пинга составлял 1400+), его отбрасывало
само оборудование. Так как туннель был физическим
уровнем IP, TCP естественно пыталось послать пакеты снова, но размер был все тот же, и их все так же отбрасывало. Так что я поменял MTU для туннеля на 300 (в
общем говоря случайно)

marktwain:~# ifconfig tun0 mtu 300
tsee-diees:~# ifconfig tun0 mtu 300

И вся система заработала.

6. Заключение.

А теперь сделай это сам.

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

Основные сведения о скрытых каналах в Интернете

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

Давайте рассмотрим два примера. Первая методика заключается в скрытой передаче информации по одному символу за раз в поле идентификатора (ID) заголовка пакета интернет-протокола (IP). В распространенных вариантах реализации такой методики ASCII-коды символов умножаются на 256 для создания 16-разрядных значений, которые подставляются в поле идентификатора. Для передачи аббревиатуры ICANN понадобилось бы передать 5 IP-пакетов со следующими значениями поля идентификатора:

Пакет	Десятичное значение ASCII	Идентификатор IP-пакета (x256)
1	71 ("I")	18176
2	67 ("C")	17152
3	65 ("A")	16640
4	78 ("N")	19968
5	78 ("N")	19968

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

Вторая методика создания скрытого канала подразумевает использование полезной нагрузки протокола, то есть технической информации, передаваемой в рамках выбранного протокола. В данном случае данные добавляются к запросам ECHO и ответам на них - это служебные сообщения, которые используются в протоколе Internet Control Message Protocol, или ICMP. Сообщения ECHO используются в распространенной службе ping . Сетевые администраторы часто используют службу ping для проверки того, доступен ли тот или иной удаленный узел, поэтому трафик пакетов ECHO протокола ICMP обычно пропускается средствами защиты сетей, такими как брандмауэры.

Если вам интересно узнать больше об этих методиках, ознакомьтесь со следующими статьями: (Вопросы и ответы о скрытых каналах) и Covert Channels over ICMP (Скрытые каналы по протоколу ICMP, PDF, 740 КБ].

Далее. Скрытые каналы DNS

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

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

Скрытые каналы (covert channels) – это один из методов в информационной безопасности, который может применяться как со знаком плюс (для обеспечения анонимности и конфиденциальности), так и со знаком минус (для организации утечек данных). Рассмотрим именно вторую составляющую – обнаружение скрытой передачи данных, или передачи данных по скрытым каналам, что является одной из самых труднорешаемых на практике задач информационной безопасности. Чтобы не увеличивать размер статьи, я сознательно обойду вниманием такие механизмы скрытия данных, как шифрование и стеганография.

Алексей Лукацкий
Консультант по безопасности Cisco

Что такое скрытая передача данных?

Скрытая передача данных по сети – это не единственное применение данного метода. Впервые термин "скрытый канал" появился в 1973 г. и применялся для вычислительных систем, не имеющих традиционного сетевого подключения. Например, четное значение длительности процесса может означать единицу, а нечетное – ноль. Таким образом, манипулируя длительностью процесса, мы можем формировать последовательность из 0 и 1, которыми можем описать все, что угодно (это так называемый временной канал). Другой пример скрытого процесса в вычислительных системах – запуск процессом той или иной задачи и ее завершение в определенное время, которое может трактоваться как единица; и ноль, если задача не завершена в указанное время.

Как может быть реализована скрытая передача?

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

При этом могут быть использованы совершенно различные варианты инкапсуляции:

В 1987 г. была предложена идея скрытой передачи по сети, и с этого момента начались серьезные исследования данного метода обеспечения конфиденциальности или утечек данных (зависит от того, с какой стороны баррикад смотреть). В частности, в 1989 г. впервые было предложено манипулировать неиспользуемыми битами фреймов Ethernet и ряда других канальных протоколов. Очевидно, что скрытые каналы в локальной сети не так интересны для изучения, в отличие от скрытия данных в глобальных сетях. Прорывом (по крайней мере, публичным) можно считать 1996 г., когда было опубликовано исследование, в котором демонстрировалась реальная передача и прием данных по скрытому в TCP/IP-каналу; а точнее, в отдельных полях его заголовка.

• На уровне HTTP, который уже давно стал стандартом де-факто для построения на его базе других прикладных протоколов. Например, анонимная сеть JAP использует HTTP для передачи данных, задействуя еще и сложноконтролируемую сеть Tor. В HTTP возможно использовать команды GET и POST для передачи данных, а если HTTP применяется для передачи потокового видео и аудио, то возможности злоумышленников по передаче больших объемов данных становятся практически безграничными.
• На уровне DNS, когда информация скрывается внутри DNS-запросов и ответов на них. Впервые про этот метод начали говорить в начале 2000-х гг., когда появился инструмент DeNiSe для туннелирования протокола TCP в DNS. Позже было исследование Дэна Камински, показывающее возможность инкапсуляции SSH через DNS и представленное на конференции Defcon в 2005 г. А затем эта тема стала набирать популярность – появились dns2tcp, DNScapy, DNScat, Heyoka, iodine, squeeza и т.п.
• На уровне ICMP, когда данные инкапсулируются внутрь обычно разрешенного средствами защиты протокола ICMP. По такому принципу в свое время действовала программа Loki, впервые упомянутая в 1996 г. в журнале Phrack. За ней последовала более продвинутая Loki2. Также есть такой инструмент, как icm-pchat, который позволяет общаться зашифрованными сообщениями через ICMP.
• На уровне TCP/UDP/IP, когда для скрытия утечки или получения команд извне применяются отдельные поля заголовка пакета. В зависимости от используемого протокола размер передаваемых данных будет варьироваться от 2 до 12 и 38 байт соответственно в IP-, UDP-и TCP-протоколах. Очень интересный инструмент, использующий модификацию TCP-заголовка, называется Nushu. Его особенность в том, что он сам не создает никакого трафика, а только модифицирует тот, который уже отправляется с узла каким-либо приложением или процессом. Иными словами, измененный трафик направляется, куда должен, а злоумышленник просто перехватывает его по сети, собирая утекшие таким образом данные.
• В беспроводных сетях, когда данные маскируются в передаваемом трафике, распространяемом широковещательно. Кстати, в этом случае непросто обнаружить принимающую сторону, которая может работать в пассивном режиме – только для приема данных. По такому принципу построен инструмент HICCUPS.

Как может быть обнаружена скрытая передача?

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

• Размер запроса и ответа. Например, известно, что средняя длина DNS-запроса составляет не более 40–60 байт. Поэтому увеличение числа запросов DNS с увеличенными длинами пакетов может означать работу скрытого канала. Аналогичная практика может быть предложена и для других протоколов – ICMP, SIP и т.п.
• Объем запросов. Обычно объем трафика по определенным типам протоколов является если величиной и не фиксированной, то редко меняющейся в пределах нескольких долей процента. Поэтому внезапное возрастание трафика служебных протоколов или числа DNS-запросов или их размера может говорить об аномалии и необходимости разобраться. При этом профиль трафика в этом случае может оцениваться и для узла отправителя, и для узла получателя.
• Число или география обращений также может служить характеристикой скрытых каналов. Например, при наличии внутреннего DNS-сервера постоянное обращение к внешнему DNS-узлу также может служить признаком аномалии.
• Другие виды статистического анализа также полезны для обнаружения скрытых каналов. Например, можно анализировать уровень энтропии в именах узлов для DNS. Если в DNS-запросах будет передаваться скрытая информация, то распределение используемых символов будет отличаться от традиционного.

Инструментом, который позволяет отслеживать такие аномалии в сетевом трафике, являются системы класса NBAD (Network-based Anomaly Detection), которые либо уже содержат большое количество встроенных правил, либо могут быть настроены самостоятельно после проведенного режима обучения.

Помимо анализа аномалий скрытые каналы могут быть обнаружены и с помощью изучения содержимого в тех или иных протоколах. Это может быть сделано как с помощью традиционных решений класса Next Generation, которые могут отслеживать отклонения трафика прикладных протоколов от RFC, так и с помощью систем обнаружения вторжений. Например, вот так выглядит сигнатура для обнаружения скрытого канала NSTX в протоколе DNS для open source-решения Snort:
alert udp $EXTERNAL_NET any - > $HOME_NET 53 (msg:"Potential NSTX DNS Tunneling"; content:"|01 00|"; offset:2; within:4; content:"cT"; offset:12; depth:3; content:"|00 10 00 01|"; within:255; classtype:bad-unknown; sid:1000 2;)

Резюме

Неуниверсальность – вот, пожалуй, основное препятствие и для активного использования скрытых каналов, и для борьбы с ними.

Скрытые каналы в сетевом трафике – это очень специфический метод, который не является универсальным и имеет свои ограничения и область применения. Каждый скрытый канал имеет свои характеристики, например пропускную способность, шум, режим передачи (двусторонний или односторонний), которые надо учитывать – как при их использовании, так и при борьбе с ними. Все-таки "Войну и мир" Л.Н. Толстого через такие каналы оперативно не передать, а у некоторых способов скрытой передачи очень высок уровень шума, что мешает им быть эффективно примененными в глобальных сетях, в которых внешние факторы могут сильно влиять на успешность скрытой передачи.

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