Как да открием скрито предаване на данни в мрежата? Какво представляват скрити канали в интернет? Мрежово събитие icmp skype скрит канал блокиран.

Как да открием скрито предаване на данни в мрежата?  Какво представляват скрити канали в интернет?  Мрежово събитие icmp skype скрит канал блокиран.
Как да открием скрито предаване на данни в мрежата? Какво представляват скрити канали в интернет? Мрежово събитие icmp skype скрит канал блокиран.

Уча Настройка на MikroTikможе на онлайн курсза оборудването на този производител. Авторът на курса е сертифициран обучител на MikroTik. Можете да прочетете повече в края на статията.

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

ICMP е ябълката на раздора

Много мрежови администратори смятат, че Internet Control Message Protocol (ICMP) представлява риск за сигурността и следователно винаги трябва да бъде блокиран на. Вярно е, че протоколът има някои проблеми със сигурността, свързани с него, и че някои заявки трябва да бъдат блокирани. Но това не е причина да блокирате целия ICMP трафик!

ICMP трафикът има много важни функции; някои от тях са полезни за отстраняване на проблеми, докато други са необходими за правилна работамрежи. По-долу са някои от важните части на ICMP протокола, с които трябва да сте запознати. Трябва да помислите как най-добре да ги прекарате през вашата мрежа.

Ехо заявка и ехо отговор

IPv4 - Ехо заявка (Тип8, Код0) и Ехо отговор (Тип0, Код0)
IPv6 - Echo Request (Type128, Code0) и Echo Response (Type129, Code0)

Всички знаем добре, че ping е един от първите инструменти за отстраняване на проблеми. Да, ако активирате обработка на ICMP пакети на вашия хардуер, това означава, че вашият хост вече е откриваем, но не слуша ли вашия хост вече на порт 80 и не изпраща отговори на клиентски заявки? Разбира се, блокирайте и тези заявки, ако наистина искате вашата DMZ да е на ръба на мрежата. Но блокирането на ICMP трафик във вашата мрежа не повишава сигурността, а напротив, вие ще получите система с ненужно сложен процес за отстраняване на неизправности („Моля, проверете дали шлюзът отговаря на мрежови заявки?“, „Не, но това изобщо не ме разстройва, защото няма да ми каже нищо!“).

Не забравяйте, че можете също така да позволите на заявките да отидат в определена посока; например, конфигурирайте хардуера така, че Echo заявките от вашата мрежа да отиват към интернет и Echo отговорите от интернет към вашата мрежа, но не и обратното.

Изисква се фрагментация на пакет (IPv4) / Пакетът е твърде голям (IPv6)

IPv4 - (Тип3, Код4)
IPv6 - (Тип2, Код0)

Тези компоненти на протокола ICMP са много важни, тъй като те са важен компонент в Path MTU Discovery (PMTUD), което е неразделна част от TCP протокол. Позволява на два хоста да коригират стойността на TCP максималния размер на сегмента (MSS) до стойност, която съответства на най-малкото MTU по пътя на връзката между две дестинации. Ако има възел по пътя на пакетите с по-ниска максимална единица за предаване от подателя или получателя и те нямат средствата да открият този сблъсък, тогава трафикът незабележимо ще падне. И няма да разберете какво се случва с комуникационния канал; с други думи, „ще дойдат щастливи дни за вас“.

Не фрагментирайте - ICMP няма да премине!

Предаването на IPv4 пакети със зададен бит Не фрагментирай (повечето от тях!) или IPv6 пакети (не забравяйте, че в IPv6 няма фрагментация от рутери), които са твърде големи, за да преминат през интерфейса, ще накарат рутера да изпусне пакета и да генерира отговор към източника на предаване със следните ICMP грешки: Изисква се фрагментиране ( Изисква се фрагментиране), или Твърде голям пакет ( Пакетите същоголям). Ако отговорите с тези грешки не успеят да се върнат на подателя, тогава той ще интерпретира липсата на отговори за потвърждение относно доставката на ACK пакети ( Признайте) от приемника като задръстване/загуба и източника за повторно предаване на пакети, които също ще бъдат премахнати.

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

Проучване на пътя за доставка на пакети

RFC 4821 е създаден, за да помогне на участниците в мрежата да заобиколят този проблем, като използват откриване на пътя за разпространение на пакети. (Откриване на MTU на пътя (PLPMTUD). Стандартът дава възможност за откриване максимален обемданни (Максимална предавателна единица (MTU), които могат да бъдат прехвърлени от протокола в една итерация, чрез постепенно увеличаване на максималния размер на полезния блок данни (Максимален размер на сегмента (MSS), за да намерите максималния възможен размер на пакета без фрагментация по пътя от предавателя към приемника. Тази функционалност намалява зависимостта от навременното получаване на отговори за грешка на протокола за контролни съобщения в Интернет (ICMP) и е налична за повечето стекове от мрежови устройства и клиентски операционни системи. За съжаление не е толкова ефективна, колкото директното получаване на данни за максималния възможен размер на предадените пакети. Моля, позволете на тези ICMP съобщения да се върнат към източника на предаване, става ли?

Изчакване на пакета

IPv4 - (Тип11, Код0)
IPv6 - (Тип3, Код0)

Traceroute е много полезен инструмент за отстраняване на неизправности за интернет връзкамежду два хоста, като подробно описва всяка стъпка от пътя.


Изпраща пакет с продължителността на живота на пакета данни за IP протокола (Време за живот (TTL)равен 1 за да накара първия рутер да изпрати съобщение за грешка (включително собствения си IP адрес), че пакетът е изтекъл. След това изпраща пакет с TTL 2 и т.н. Тази процедура е необходима, за да се открие всеки възел по пътя на пакетите.

NDP и SLAAC (IPv6)

Router Solicitation (RS) (Тип133, Код0)
Реклама на рутер (RA) (Тип134, Код0)
Привличане на съседи (NS) (Тип135, Код0)
Съседска реклама (NA) (Тип136, Код0)
Пренасочване (Тип137, Код0)

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

Тези пет типа ICMP съобщения не трябва да се блокират във вашата мрежа (като се игнорира външният периметър), за да функционира правилно IP протоколът за данни.

ICMP тип номериране

Протоколът за контролни съобщения в Интернет (ICMP) съдържа много съобщения, които се идентифицират чрез поле "тип".

Тип Име Спецификация
0 ехо отговор
1 неназначени
2 неназначени
3 Дестинацията е недостъпна
4 Потушаване на източника (отхвърлено)
5 Пренасочване
6 Алтернативен адрес на хост (отхвърлен)
7 неназначени
8 ехо
9 Реклама на рутер
10 Искане на рутер
11 Времето е превишено
12 Проблем с параметъра
13 Времево клеймо
14 Отговор с времево клеймо
15 Искане за информация (отхвърлено)
16 Информационен отговор (отхвърлено)
17 Заявка за адресна маска (отхвърлено)
18 Отговор с адресна маска (отхвърлено)
19 Запазено (за сигурност) Соло
20-29 Запазено (за експеримент за устойчивост) ZSu
30 Traceroute (отхвърлено)
31 Грешка при преобразуване на дейтаграма (отхвърлено)
32 Пренасочване на мобилен хост (отхвърлено) Дейвид_Джонсън
33 IPv6 Where-Are-You (Отхвърлено)
34 IPv6 I-Am-Here (отхвърлено)
35 Заявка за мобилна регистрация (отхвърлена)
36 Отговор за мобилна регистрация (отхвърлено)
37 Заявка за име на домейн (отхвърлено)
38 Отговор за име на домейн (отхвърлено)
39 ПРОПУСКАНЕ (отхвърлено)
40 Фоторис
41 ICMP съобщения, използвани от експериментални протоколи за мобилност като Seamoby
42 разширена заявка за ехо
43 Разширен ехо отговор
44-252 неназначени
253 Експеримент 1 в стил RFC3692
254 Експеримент 2 в стил RFC3692
255 Запазено

Няколко думи за ограничението на скоростта

Докато ICMP съобщения като тези в тази статия могат да бъдат много полезни, имайте предвид, че генерирането на всички тези съобщения отнема процесорно време на вашите рутери и генерира трафик. Наистина ли очаквате да получите 1000 пинга в секунда през вашата защитна стена в нормална ситуация? Ще се счита ли това за нормален трафик? Вероятно не. Лимит пропускателна способностмрежи за тези типове ICMP трафик, както сметнете за добре; тази стъпка може да ви помогне да защитите вашата мрежа.

Четете, изследвайте и разбирайте

Като се има предвид, че обсъждането на темата "блокиране или неблокиране" на ICMP пакети винаги води до объркване, спорове и разногласия, предлагам ви да продължите да изучавате тази тема сами. Цитирах много връзки на тази страница, мисля, че за по-пълно разбиране на проблема трябва да отделите време да ги прочетете. И направете информиран избор за това какво работи най-добре за вашата мрежа.

MikroTik: къде да щракнете, за да работи?
Въпреки всичките си достойнства, продуктите на MikroTik имат един недостатък - много несвързана и далеч не винаги надеждна информация за неговите настройки. Препоръчваме доверен източник на руски език, където всичко е събрано, логично и структурирано - видео курс " Настройка на хардуера на MikroTik". Курсът включва 162 видео урока, 45 бр лабораторна работа, въпроси за самопроверка и реферат. Всички материали остават при вас за неопределено време. Можете да гледате началото на курса безплатно, като оставите заявка на страницата на курса. Авторът на курса е сертифициран обучител на MikroTik.

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

Алексей Лукацки
Консултант по сигурността на Сиско

Какво е скрито предаване на данни?

Скритото мрежово предаване не е единственото приложение този метод. Терминът "скрит канал" се появява за първи път през 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 протокола, обикновено разрешен от функциите за сигурност. Програмата Локи, която беше спомената за първи път през 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), които или вече съдържат голям брой вградени правила, или могат да бъдат конфигурирани независимо след режима на обучение.


В допълнение към анализа на аномалиите, скрити канали могат да бъдат открити и чрез изследване на съдържанието в определени протоколи. Това може да стане както с традиционните решения от следващо поколение, които могат да проследяват отклоненията на трафика на протокола на приложението от RFC, така и с помощта на системи за откриване на проникване. Например, тук е подписът за откриване на скрития канал NSTX в DNS протокола за решението с отворен код Snort:
предупреждение udp $EXTERNAL_NET всяко - > $HOME_NET 53 (msg:"Потенциално NSTX DNS тунелиране"; съдържание:"|01 00|"; отместване:2; в рамките на:4; съдържание:"cT"; отместване:12; дълбочина:3; съдържание:"|00 10 00 01|"; в рамките на:255; classtype:лошо-неизвестно; sid:1000 2; )

Резюме

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

Скритите канали в мрежовия трафик са много специфичен метод, който не е универсален и има своите ограничения и обхват. Всеки скрит канал има свои характеристики, като пропускателна способност, шум, режим на предаване (двупосочен или еднопосочен), които трябва да се вземат предвид - както при използването им, така и при борбата с тях. И все пак "Война и мир" L.N. Толстой не може бързо да се предава по такива канали, а някои методи за скрито предаване имат много високо ниво на шум, което им пречи да бъдат ефективно прилагани в глобалните мрежи, в които външни фактори могат значително да повлияят на успеха на скритото предаване.

Неуниверсалността е може би основната пречка както за активното използване на тайните канали, така и за борбата с тях. Голям бройограниченията за скрито предаване на данни го правят много само насочени заплахи, разработени за конкретна задача и конкретен клиент. Същата неуниверсалност води до идеята, че няма сребърен куршум под формата на един продукт и е необходимо да се използва цял набор от инструменти и технологии за откриване и неутрализиране на скрито предаване на данни.

Тази кратка статия показва как с помощта на няколко компютъра, няколко забавни инструмента и операционна системаполучавам безжичен достъпИнтернет, където е възможно. Описах доста ясно техническата страна и дадох коментари.

1. Въведение.

Току-що получих първия си лаптоп и исках да опитам да направя някои мръсни неща с него (дори се опитах да свърша малко работа, но беше твърде уморително
:)). Wardriving беше доста забавно в началото, но се отегчих, когато разбрах, че мрежите са защитени
WEP е твърде труден за мен (тъй като нямаше интранет трафик - мрежите можеха да се считат за мъртви), а незащитените мрежи изобщо не представляват интерес. За щастие безжичната мрежа в моя кампус се оказа малко по-интересна.

Мрежата предоставя безплатно безжичен интернет, но изисква да регистрирате своя MAC адрес на свое име, преди да разрешите достъп - нерегистрираните потребители се пренасочват към страницата на доставчика (страница за регистрация). Регистрирането щеше да включва двуминутен чат с администратора, но си помислих: „Може би там
начин да получите достъп, без да се налага да комуникирате по този начин?“ Разбира се, че беше.

2. Първият метод за проникване е MAC spoofing.

Тъй като всичко се въртеше около MAC адреса, първото нещо, което ми дойде на ум беше
беше да откриете вече регистрирания MAC адрес и да се справите с него
подправяне. Разбира се, говоренето е лесно, но не изискваше почти никакви усилия, въпреки че никога преди не го бях правил.
Първото нещо, което направих, беше да стартирам kismet ("kismet -c orinoco,eth1,wifi") и да подуша мрежата. Кисмет спасява всичко надушено
информация във файл ("/var/log/kismet/*.dump" в моя случай), резултатите от смъркането могат да се видят, тъй като
постъпления. В резултат на това успях да видя цялата информация и
запишете правилния MAC адрес.

Команди, използвани за промяна на MAC адреса на мрежовата карта:

ifconfig eth1 надолу
killall dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 нагоре
dhclient eth1

Не всички команди са необходими, но са много полезни, когато се опитвате да промените множество MAC адреси един по един, което
просто ми беше от полза, т.к. MAC адресът, който се опитах да променя, не проработи веднага. Бях забранен, мрежата падна и не се включи отново, което ме накара да се занимавам с няколко досадни проблеми
във вашата система. Може би тези проблеми
се появи поради фърмуера и вероятно защото мрежата вече имаше LAN картас този MAC адрес.

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

В мрежата филтрирането по MAC адрес беше извършено на доста високо ниво. По всяко време имах достъп до мрежата, защото. когато се опитах да се присъединя, попаднах на страница с предложение за регистрация.
Естествено, в хода на мисленето за активни хостове, nmap ми дойде наум. Затова направих проверка на обхвата на IP за активни станции.

marktwain:~# nmap -sP 10.0.0.1/22
Стартиране на nmap 3.81 (http://www.insecure.org/nmap/) в 2005-05-23 12:54 EEST
Хост 10.1.0.14 изглежда работи.
MAC адрес: 00:0E:35:97:8C:A7 (Intel)
Хост 10.1.0.95 изглежда работи.

Хост 10.1.0.109 изглежда работи.
MAC адрес: 00:0D:54:A0:81:39 (3Com Европа)
... щракам ...
Хост 10.1.2.92 изглежда работи.
MAC адрес: 00:02:2D:4D:1C:CE (Agere Systems)
Хост 10.1.2.187 изглежда работи.
MAC адрес: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap завършен: 1024 IP адреса (20 хоста нагоре), сканирани за 53,980 секунди

Куп MAC адреси. Повечето от
получената таблица с адреси е (предполагам) MAC адресите на машините, които са посетили мрежата през последните няколко дни. В таблицата имаше 245 различни MAC
адреси. Не знам дали това е нормално поведение
точки за достъп, но мисля, че момчетата струват нещо
промяна в разпространението на Интернет. Какъвто и да е случаят, сега имам достатъчно MAC адреси на машини, които са посетили мрежата, но най-вероятно са напуснали преди много време. Няколко опита за спуфинг и вече плувах към neworder.box.sk...

3. Опит номер 2 - ICMP тунелиране.

Направих всичко, което исках, но все още имаше място за ровене в тази мрежа. Но какво
Можех да направя, ако тази мрежа нямаше
нито една кола не е моя собственост? Ако
няма ли nmap да се отвори и да покаже всички тези MAC адреси? И така, реших да опитам друг начин за достъп.

Това не беше споменато преди, но заобикаляйки системата
Интернет разпространението дава разрешение и DHCP, мрежата позволява ICMP съобщенията да преминават свободно. Проверката на активността на всеки интернет сайт работи добре (наистина не мога да разбера защо не са го блокирали - освен ако не са забравили), пинг
дори се появи на снифера, който работеше на моя сървър.
Планът ми беше да се опитам да създам тунел между моя лаптоп в университета и сървър у дома. И прекарайте всички връзки през него.
Търсих в интернет приложения за ICMP тунелиране, но нито едно не работеше така, както исках (а именно, исках да е просто - така че ако пусна любимия си браузър или друга програма, тя просто да работи с тунела) или поне
изглеждаше вкусно.

4. Малко кодиране.

Първоначално не планирах да кодирам нищо. Току-що изпробвах някои ICMP тунелни приложения
с packetstorm, но след това внезапно се озовах да чета изходния код на един от тях и осъзнах колко невероятно просто е и колко лесно би било да се направи нещо подобно. Името на програмата е itunnel -
обща помощна програма за ICMP тунелиране. iTunes е страхотен. Но това е просто тунел. Пускате го на една машина и накрая изглежда, че сте свързали две
мрежови карти заедно. Не беше достатъчно за това, което исках да направя.
Вече съм чувал за модула на ядрото TUN/TAP, който позволява на потребителските процеси да получават и изпращат пакети информация директно към/от ядрото.

Програмата създава виртуален мрежов интерфейс.
Той създава мрежов интерфейс, който
работи точно по същия начин
стандартен. Най-интересното е, че
потребителските програми трябва
работа като физически слойза интерфейс
тунел. Те трябва да четат пакети информация от
файл на устройството (например „/dev/net/tun0“) и ги изпратете по всякакъв начин и напишете отговорни пакети
обратно към файла.

Не можах да намеря добър ресурс
през TUN/TAP, но има програма - vtun - която използва TUN/TAP за своите тунели, така че аз
poyuzal vtun източници. След малко проучване се оказа, че има малка библиотека от функции, използвани за създаване, четене и запис на tun*
устройства. Защо трябва да пиша програмата сам, ако може да стане с поправка на няколко бита?
Кодът, който всъщност написах:

#include "driver.h" /* декларирайте библиотеката vtun */
#включи
#включи

/* леко модифициран main() от itunnel
*/
int run_icmp_tunnel(int id, int packetsize, char *desthost, int tun_fd);

/* максимална единица - максимум
размер на капсулирана торба

*/
const int mtu = 1400;

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

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

ако (tun_fd< 1) {
printf("Не може да се създаде устройство. Fatal.n");
връщане 1;
}
иначе(
printf("Създадено тунелно устройство: %sn", dev);
}

/* 7530 е полето за ICMP id,
използвани за пакети в тунела

*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);

tun_close(tun_fd, dev);
}

Ето го. И повечето от тях са коментари и проверка на грешки

Както споменах, itunnel е идеален за изграждане на тунел. Има основна функция, която
отворени файлове за вход, изход и сокет; Също
получи някои параметри за командния ред (което може да бъде полезно за моите цели). След това извика леко абстрактна функция, която по същество просто транспортира пакети информация. Без ICMP заглавка
описано в кода и може лесно да се промени на всяко друго заглавие,
вход/изход/гнездо може да се конфигурира по друга логическа схема - функцията ще работи с минимални корекции.

Повечето голяма промяна, което направих - изтриване на всички манипулации с командна линия- по същество премахване на няколко блока код. Най-важното за логиката на тунела е, че премахнах разликата между вход и изход, тъй като и двете са
висят на същия дескриптор (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. Монтаж на тунели.

Тествах тунела у дома и работи добре, но у дома нямаше защитна стена. На следващия ден в университета бях готов да го тествам в реалния живот. Случайно, седейки на маса в кафене, намерих MAC адреса с помощта на подправяне и създадох тунел.

Трудно е да си спомня всички глупави начини, които съм опитвал, и малките експерименти, които съм правил, затова се опитах да направя тази част възможно най-организирана. Всъщност не направих всичко толкова ясно.
Всичко да работи за мен
отне ми 3 часа и опитах всичко, което можах, докато душех навсякъде, където можах, и модифицирах кода, така че да скандира "Packet!" И така нататък.

Пуснах тези команди на сървъра:

tsee-diees:~# ./create_tun wifi.ttu.ee
Създадено тунелно устройство: tun0

Спрян ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 нагоре
tsee-diees:~# маршрут добавяне 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"

Мислех, че това ще проработи веднага и просто стартирах това на моя лаптоп:

marktwain:~# ./create_tun 194.204.48.52
Създадено тунелно устройство: tun0

Спряно ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 нагоре
marktwain:~# маршрут добавяне 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"

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

За щастие снифърът на лаптопа ми даде малка представа - ICMP пакетите бяха върнати отговори. Разбира се, че не го правят
бяха изпратени. Така че ние убиваме тунела, активираме itunnel на лаптопа и използваме icmp обратните отговори (променете "icmp->type = 0;" на "icmp->type = 8;"), връщаме тунела.
Системата пак не работеше, но този път пакетите
се появи на снифера на сървъра.

Какво може да не е наред? Опитах една модификация, която трябваше да извика „Пакет!“, когато пристигне следващият пакет, но възклицанията не станаха
възникна. "И защо всъщност трябва - бях изненадан - ако защитната стена е настроена да блокира всички ICMP пакети от Интернет?" След известно време разбрах, че това всъщност е така (всички ICMP пакети от интернет бяха блокирани).

Вече по-добре. Тунелът възкликва "Пакет!" , а отговорите могат да се видят на снифера на сървъра. Всъщност има два отговора за всяка заявка, само единият от които може да се види на снифера на лаптопа. И ping пак не работи.

Тъй като един от двата пакета е излишен, казах на ядрото (ядрото) да не отговаря на icmp обратни заявки:

tsee-diees:~# ехо "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

И пинговете започнаха да преминават! В този момент все още разчитах на фалшивия MAC адрес, за да получа достъп до сървъра. Тъй като идеята беше пакетите да пътуват напред-назад от нерегистриран потребител, спрях да подправям MAC адреси. В същото време тунелът продължи да работи, което беше доста приятна изненада.

Потокът от пакети беше установен и беше време да накараме „Интернет“ да работи.
Трябваше да направя някои промени в IP-то
маршрутизиране на лаптоп. път през
университетски рутер безжична мрежатрябваше да бъде заменен от адреса на тунела на сървъра (192.168.3.1 в този случай). Все още трябва да има път към сървъра, така че самият тунел да може да работи (ICMP тунелните пакети също се нуждаят от път, който да следват).
Получих някои доста добри резултати:

marktwain:~# route add 194.204.48.52 gw 10.0.0.111 # през безжичния рутер
marktwain:~# маршрут по подразбиране
marktwain:~# route add default gw 192.168.3.1 # всичко останало през тунела.

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

marktwain:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) байта данни.

Разбира се, нямаше отговори, защото това не бяха „тунелни пингове“, а отговорите от ядрото бяха
изключено.

Тъй като моят сървър вече е обучен
за споделяне на интернет връзка между няколко компютъра, всичко, което трябваше да направя на сървъра, беше да добавя две правила за
FORWARD верига в iptables за приемане на пакети от и към tun0. Когато рутинно проверявах текущите правила ("iptables -vL FORWARD"), връзката изведнъж умря. Свързах се отново и проучих този въпрос,
но скоро връзката отново прекъсна. Бях много изненадан - защо връзката е толкова нестабилна?
Като се замислих, разбрах, че всеки път сървърът изпраща голям ICMP отговор
(в края на краищата само заглавката на ping беше 1400+), беше изхвърлена
самото оборудване. Тъй като тунелът беше физически
IP слой, TCP естествено се опита да изпрати пакети отново, но размерът беше същият и те все още бяха отхвърлени. Така че промених MTU за тунела на 300 (in
най-общо казано случайно)

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

И цялата система работеше.

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

Сега го направете сами.

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

Основи на скритите канали в Интернет

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

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

Найлонов плик ASCII десетична стойност ID на IP пакет (x256)
1 71 ("аз") 18176
2 67 ("C") 17152
3 65 ("A") 16640
4 78 ("N") 19968
5 78 ("N") 19968

Получаващият компютър декодира стойността на ID полето на IP пакета, като разделя получената стойност на 256. Предаването на такива стойности не поражда никакви подозрения и тъй като IP протоколът позволява предаване на дублиращи се пакети, е малко вероятно такъв трафик да бъде открит. Ниската скорост се компенсира от секретността на предаването.

Втората техника за създаване на скрит канал включва използването на полезен товар на протокола, т.е. техническа информацияпредавани в рамките на избрания протокол. В този случай данните се добавят към ECHO заявките и отговорите - това са служебни съобщения, които се използват в протокола за контролни съобщения в Интернет или ICMP. ECHO съобщенията се използват в обща услуга пинг . Мрежови администраторичесто използват услугата ping, за да проверят дали конкретен отдалечен хост е достъпен, така че ICMP ECHO пакетният трафик обикновено се пропуска от устройства за мрежова сигурност, като например защитни стени.

Ако се интересувате да научите повече за тези техники, вижте следните статии: (Въпроси и отговори за скрити канали) и Скрити канали през ICMP (PDF, 740 KB).

По-нататък. DNS скрити канали

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

В следващата ни публикация ще проучим как скрити канали на DNS могат да се използват за извличане на данни, заобикаляне на контролите за достъп или изтегляне на зловреден софтуер.