Крадіжка трафіку: туннелінг

Автор: [Privacy]
[email protected]
Дата: 20.12.2002

——————————————————————————–

Здрастуй, мій маленький любитель халяви! Сьогодні ми поговоримо з тобою про крадіжку трафіку. Ми обговоримо один з найцікавіших (і, разом з тим, тужних) способів відносно чесного відбирання трафіку у провайдера, про туннелировании через безкоштовно доступні сервіси. Ця стаття буде особливо цікава користувачам, підключеним до Інтернету будинковими та корпоративними мережами, хоча, возможо, діалап-користувачі теж зможуть почерпнути в ній щось для себе небезкорисного.

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

Наведена принципова схема наочно ілюструє цей підхід.

Технологія досить проста і очевидна:

1) Клієнтська проксі-програма на локалхосте злісного хакера виконує функції мережевого стека для користувача програм. Вона «схоплює» і проксюет IPv4-трафік потрібних програм, «пакуючи» вихідний трафік і «розпаковуючи» вхідний (ми використовували сукупність програм SocksCap і спеціально написаного для цих цілей socks-сервер).

2) Серверна проксі-програма на стороні-приймачі виконує зворотні описаним в [1] функції.

3) Трафік між [1] і [2] йде по дозволеному, цілком легальним з точки зору політики провайдера, тунелю. При необхідності, зв’язок між [1] і [2] можна прикривати SOCKS – і HTTP-проксями, щоб адміни ґвалтованого провайдера (у разі виявлення крадіжки трафіку) не змогли відшукати місцезнаходження сервера проксі-програми.

За великим рахунком, у цьому підході немає нічого нового і оригінального. Тунелювання і інкапсуляція використовуються досить активно і повсюдно: часом, це єдиний спосіб обійти природні та об’єктивні топологічні обмеження. Але, тим не менш, я жодного разу ще не зустрічав людей, які використовують тунелювання з метою крадіжки трафіку (хоча я неодноразово чув про успіхи таких діячів =))

ЧОМУ?

Що стосується технічних питань реалізації туннелінга, то инкапсулировать можна практично що завгодно і практично куди завгодно =)) щось тунелювати простіше, щось- складніше. Наприклад, mirc-туннелінг мені вдався куди простіше, ніж DNS-туннелінг, незважаючи на те, що у мене була програма LOKI з журналу phrack (issue 51, volume 7), яка виконує схожі функції. І я впевнений, що технічні труднощі реалізації не відлякають тебе, друже мій, а, навпаки, зацікавлять!

І КУДИ?

Є ще одна об’єктивна складність, яка відлякає багатьох дельфистов: необхідність мати якийсь зовнішній ресурс, який можна було б навантажити серверною частиною… Я бачу лише два варіанти: 1) злом і захоплення яких-небудь безгоспних віддалених машин (число яких — легіон =))) або 2) придбання у Буржандии легального хостингу, ціна якого навряд чи де-небудь перевищує півтора-двох баксів за гігабайт.

БЕЗКОШТОВНІ СЕРВІСИ

Багато (якщо не всі) будинкові мережі, про яких, в основному, йде мова, володіють деяким числом безкоштовно доступних сервісів. Під «безкоштовно доступними сервісами» можна розуміти ті сервіси, оплата за використання яких не стягується зовсім, або вона вже включена в оплату за користування локальною мережею. Це може бути що завгодно: ігрові сервіси з виходом у світ, ICMP-трафік (пінги), DNS-трафік, irc-сервер…

В мережі, де проводили випробування ми, до цих сервісів відносяться email, DNS-резолвинг довільних імен і mirc-сервер з виходом у світ. Саме про грамотне використання цих сервісів я і розповім сьогодні. Я дам тобі необхідну кількість практичних рад за максимально ефективного обходу підводних каменів в цій області хакерської (хоча, швидше хэкерской) діяльності =)))

ЕЛЕКТРОННА ПОШТА

Використання email а для тунелювання трафіку в реальному часі (наприклад, для серфінгу по сайтах) — ідейка досить-таки премерзкая. Можеш уявити собі, скільки часу займе навіть найменша транзакція по email у туди-назад, особливо якщо для отримання листів POP необхідна SMTP авторизація. Тому, єдиний, на мій погляд, адекватний спосіб застосування email-туннелінга — це відкладений замовлення файлів по ftp і http.

Наскільки я знаю, ще кілька років тому такі безкоштовні і публічні сервіси існували і були повсюдно поширені: потрібно було лише відправити на якийсь email список потрібних url’ов і чекати, поки ці файли не прийдуть на твою адресу. У деяких випадках (коли локальна мережа мала лише email-доступ в Інтернет), це була єдина можливість отримувати файли =))) Тепер таких сервісів вже не залишилося. Стало бути, потрібно організовувати власний. Отже, серверна частина повинна вміти:

1) завантажувати файли і фрагменти файлів по http і ftp;
2) ділити великі файли на шматки, бажані юзером;
3) упаковувати файли в ту кодування, яку «з’їсть» насилуемый mail-сервак.

Якщо не займатися хэкерством, тобто якщо не писати весь сервер з нуля на бейсіку або на асемблері, то реалізувати таку програму можна зв’язкою bash+sendmail+netcat+wget+whatever+you+want. Як ти бачиш, це — найпростіший у реалізації та використанні спосіб скачування файлів нахаляву. Але, разом з тим, найбільш легко виявляється.

Крім того, з цим методом досить просто боротися. Адміну достатньо лише ввести квоту на кількість мегабайт пошти у добу для кожного пересічного користувача.

MIRC-ТУННЕЛІНГ

Цей спосіб набагато витонченіше і гнучкіше попереднього: тут вже цілком реально тунелювання трафіку в реальному часі. Навіть при зв’язку серверного баунсера з irc-серваком через один SOCKS-проксі, ми мали середній «пінг» близько 400 мілісекунд. Цей спосіб (особливо при досить міцною завантаженні irc-сервака) важче виявити. Крім того, стандартний адмін навряд чи зможе з пів-стусана придумати адекватну захист від мігс-туннелінга, хіба що нещадно вчинивши своєму irc-серваку жорстокий шейпінг і квотування (викликавши тим самим хвилі невдоволення серед чесних і мирних користувачів =))).

Отже, хакерський клієнтський компонент, в даному випадку, оснащений irc-клієнтом, а серверна частина має irc-bouncer’ом з одним або декількома акаунтами до насилуемому irc-серваку. Баунсер може виходити на зв’язок з irc-сервера через один або кілька проксі.

Плюси цього способу очевидні, і якщо серверні nick ‘ і не виводити в які-небудь irc-канали, можна залишатися непоміченим як завгодно довго. А ось мінуси цього способу слід обговорити окремо:

1) На тому серваці й, де проводили тестування ми, при перевищенні швидкості в 2 kb/sec, ми стабільно отримували Excess Flood на приймаючій стороні. Стало бути, потрібно або дотримуватися цього обмеження, або вводити кілька «ніків»-прінімателя і працювати з ними паралельно.

2) Слід уникати сталих сигнатур протоколу інкапсуляції воровського трафіку. Це відноситься до будь-якого з можливих варіантів пакетного тунелювання: будь-яка IDS-система (навіть примітивна начебто snort-based) може бути налаштована відловлювати або стійкі послідовності байт, або стійкі розміри дейтаграм, або і те, і інше одночасно.

Взагалі кажучи, протокол інкапсуляції слід проектувати з особливою ретельністю, не перевантажуючи його надлишковою інформацією, необхідність в якій сумнівна. Іншими словами, тобі не слід переписувати TCPv4 під власні потреби. Достатньо лише реалізувати деякі його основні функції:

1) Якщо мова йде про mirc-туннелинге (або про туннелировании через будь-який інший tcp-based-сервіс), то досить обійтися лише нумерацією чергової пачки даних.

2) Якщо ти займаєшся протоколом пакетної інкапсуляції (поверх, наприклад, udp або icmp), тобі необхідно додати забезпечення цілісності потоків переданих даних додаткової контрольною сумою. Протокол непогано б оснастити можливістю договору між клієнтом і сервером про бажаної швидкості і насиченості трафіку один між одним.

3) Динамічне стиснення і шифрування даних цілком можуть мати своє законне місце в протоколі інкапсуляції. Ти можеш використовувати відкриті і дуже зручні бібліотеки libbzip2 і rsaeuro, для стиснення і шифрування потоків даних, відповідно. До речі, незабаром я опублікую на цьому сайті невеликі хавту по програмуванню з використанням цих бібліотек.

Отже, mirc-туннелінг — штука цікава і романтична.

DNS-ТУННЕЛІНГ

Це — найскладніший і грубий з освоєних нами способів =)) Отже, якщо ти маєш можливість контролювати який-небудь name server у Великому Інтернеті (в ідеалі — dns-сервер, який стоїть безпосередньо вище dns-серверів ґвалтованого тобою провайдера), то цей спосіб — для тебе.

Сенс його полягає в тому, що хакерський клієнтський компонент «упаковує» злодійський IPv4-трафік в dns-запити на дозвіл адреси по імені (або які-небудь інші запити та відправляє їх dns-сервера провайдера. Провайдерский сервак, не знайшовши відповіді на ці питання, форвардит їх далі, вищестоящому dns-сервера. Таким чином, ці запити досягають серверного компонента (власника запитуваної домену). Серверна частина відправляє осмислені відповіді (зміст яких зрозумілий лише злобному хакеру =)), які, в кінцевому рахунку, досягають клієнтського компонента.

Плюси цього методу очевидні: пріоритет у dns-запитів настільки високий, що ти зможеш завантажити весь канал провайдера по максимуму. Крім того, спуфінга UDP трафіку — справа вкрай просте і необтяжливе, і ти зможеш легко і не напружуючись підставляти будь-яку пару MAC/IP з твого сегмента, відправляючи з них запити та випадку приходять до них відповіді сниффером.

До мінусів можна, безумовно, віднести труднощі реалізації цього методу, а також вельми неприємні обмеження, пов’язані з протоколом DNS/UDP: я не рекомендував би тобі формувати запити з більш ніж 8 слів розміром більш ніж по 25 символів кожен. Необхідно дотримуватися унікальність кожного наступного запиту, так як велика ймовірність того, що dns-сервера будуть досить-таки многомегабайтно кешувати твої запити. Крім того, є ймовірність того, що один з насилуемых dns-серверів (провайдерский або будь-передавальний) можуть банально впасти, якщо його кеш-база не сквотирована на фіксований розмір.

Серед способів можливої боротьби з dns-туннелингом можна виділити подушне квотування dns-трафіку. Адмін того провайдера, де ми проводили випробування, просто обрубував dns-трафік на наш сегмент і банил на роутерах ті MAC/IP-адреси, які ми спуфили.

Як ти бачиш, DNS-туннелінг — спосіб грубий, трудноконтролируемый, і при дуже активному використанні він може призвести до непередбачуваних наслідків. В локальних мережах краще використовувати більш м’які і ніжні способи крадіжок трафіку, а ось для диалапщиков які хочуть абузить гостьові телефонні входи це, мабуть, єдиний варіант… Якщо ти все ж зважився вивчити і реалізувати цей спосіб, звернися до бібліотеки libbind. Прочитай також сьому статтю 51-го phrack’а.

ПІНГИ

ICMP-туннелінг і розмови про нього старі як Інтернет =) Я вважав за потрібне про нього не забути, але розповідати ньому я не стану.

ПРО РЕАЛІЗАЦІЮ

Я, напевно, просто не вмію користуватися пошуковими системами… Але мені так і не вдалося знайти жодної публічної реалізації тих видів туннелінга трафіку реального часу, про яких я розповідав. І це дає мені підстави вважати, що таких реалізацій просто немає. Тому, багато тобі доведеться робити самому. Бери libbind, libbzip2, rsaeuro, rfc 791, 792, 793, 768, 1122, 1034, 1035, а також ті, які регламентують протоколи доступних тобі безкоштовних сервісів та… бажаю удачі! =)))

З повагою, [Privacy]