Як виявити приховану передачу даних у мережі? Що таке приховані канали в Інтернеті? Основні відомості про приховані канали в Інтернеті

Навчитися налаштування 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) та 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)), Щоб знайти максимально можливу величину пакета без його фрагментації на шляху прямування від передавача до приймача. Цей функціонал зменшує залежність від своєчасного отримання відповідей з помилками протоколу міжмережевих керуючих повідомлень (ICMP) і доступний у більшості мережевих стеків пристроїв і клієнтських операційних систем, на жаль, він не такий ефективний, як безпосереднє отримання даних про максимальне можливе Будь ласка, дозвольте цим повідомленням протоколу ICMP повертатися до джерела передачі, добре?

Перевищення часу передачі пакетів

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

Traceroute - дуже корисний інструмент для усунення несправностей мережевих з'єднанняхміж двома хостами, що докладно описує кожен крок шляху.

Відправляє пакет із часом життя пакету даних для протоколу IP (Time to live (TTL)рівним 1 , щоб перший маршрутизатор надіслав повідомлення з помилкою (включно з власною IP-адресою) про перевищення часу життя пакета. Потім відправляє пакет з TTL 2 і так далі. Ця процедура необхідна для того, щоб виявити кожен вузол на шляху проходження пакетів.

NDP та 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) містить багато повідомлень, що ідентифікуються полем "тип".

Пара слів про обмеження швидкості

Хоча ICMP-повідомлення, подібні до тих, які описані в статті, можуть бути дуже корисними, пам'ятайте, що генерація всіх цих повідомлень займає процесорний час на ваших маршрутизаторах і генерує трафік. Ви дійсно очікуєте, що ви отримаєте 1000 пінгів на секунду через ваш брандмауер у звичайній ситуації? Чи вважатиметься це нормальним трафіком? Мабуть, ні. Обмежуйте пропускну спроможністьмережі для цих типів ICMP трафіку, як ви вважаєте за потрібне; цей крок може допомогти вам у захисті вашої мережі.

Читати, досліджувати та розуміти

Враховуючи, що обговорення теми «блокувати чи не блокувати» ICMP-пакетів, завжди призводить до плутанини, суперечок та розбіжностей, пропоную продовжити вивчати цю тему самостійно. На цій сторінці навів багато посилань, вважаю для більш повного розуміння проблематики слід витрачати час на їх читання. І зробити усвідомлений вибір того, що найкраще підходить для вашої мережі.

MikroTik: куди натиснути, щоб запрацювало?
За всіх своїх переваг, є у продукції компанії MikroTik один мінус - багато роз'єднаної і далеко не завжди достовірної інформації про її налаштування. Рекомендуємо перевірене джерело російською мовою, де все зібрано, логічно та структуровано – відеокурс « Налаштування обладнання MikroTik ». До курсу входить 162 відеоуроки, 45 лабораторних робіт, питання для самоперевірки та конспект. Усі матеріали залишаються у вас безстроково. Початок курсу можна переглянути безкоштовно, залишивши заявку на сторінці курсу. Автор курсу є сертифікованим тренером MikroTik.

Приховані канали (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;)

Резюме

Неуніверсальність - ось, мабуть, основна перешкода і для активного використання прихованих каналів, і для боротьби з ними.

Приховані канали в мережевому трафіку – це дуже специфічний метод, який не є універсальним і має свої обмеження та сферу застосування. Кожен прихований канал має свої характеристики, наприклад пропускну спроможність, шум, режим передачі (двосторонній або односторонній), які треба враховувати - як при їх використанні, так і при боротьбі з ними. Все-таки "Війну та мир" Л.М. Толстого через такі канали оперативно не передати, а в деяких способів прихованої передачі дуже високий рівень шуму, що заважає їм бути ефективно застосованими в глобальних мережах, в яких зовнішні фактори можуть впливати на успішність прихованої передачі.

Неуніверсальність - ось, мабуть, основна перешкода і для активного використання прихованих каналів, і для боротьби з ними. Велика кількість обмежень для прихованої передачі даних робить її долею лише цілеспрямованих загроз, що розробляються під конкретне завдання та конкретного замовника. Ця ж неуніверсальність призводить до думки, що і срібної кулі у вигляді одного продукту зараз теж немає, і необхідно використовувати цілий комплекс засобів та технологій для виявлення та нейтралізації прихованої передачі даних.

У цій невеликій статті розповідається, як за допомогою пари комп'ютерів, кількох забавних інструментів та операційної системиотримати бездротовий доступв Інтернеті скрізь, де це можливо. Технічну сторону я описав цілком зрозуміло та оснастив коментарями.

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 завершено: 1024 IP адреси (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 години, і я спробував все, що можна поки що займався сніффінгом скрізь, де тільки можна, і модифікував код так, щоб він скандував "Packet!", Коли отримує пакет інформації, і що-небудь дратівливе, коли відправляє свій пакет. І так далі.

Я запустив ці команди на сервері:

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 з Інтернету блокувалися).

Вже краще. Тунель вигукує "Packet!" , і відповіді можна побачити на сніфер на сервері. Насправді, там дві відповіді на кожен запит, тільки одну з яких можна побачити на сніфер на ноутбуці. А пінг досі не працює.

Так як один із двох пакетів надлишковий, я вказав ядру (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. Висновок.

А тепер зроби це сам.