Ako zistiť skrytý prenos dát v sieti? Čo sú skryté kanály na internete? Sieťová udalosť zablokovala skrytý kanál icmp skype.

Učte sa nastavenie MikroTiku možné pri online kurz podľa výbavy tohto výrobcu. Autorom kurzu je certifikovaný tréner MikroTik. Viac si môžete prečítať na konci článku.

Článok odpovedá na otázku, aké nebezpečné je blokovanie ICMP prevádzky.

ICMP – jablko sváru

Mnohí správcovia siete sa domnievajú, že protokol ICMP (Internet Control Message Protocol) predstavuje bezpečnostné riziko, a preto by mal byť vždy zablokovaný. Je pravda, že s protokolom sú spojené určité bezpečnostné problémy a že niektoré požiadavky by mali byť zablokované zablokovať všetku komunikáciu ICMP!

ICMP prevádzka má mnoho dôležitých funkcií; niektoré z nich sú užitočné pri riešení problémov, zatiaľ čo iné sú potrebné správna prevádzka siete. Nižšie sú uvedené niektoré dôležité časti protokolu ICMP, o ktorých by ste mali vedieť. Mali by ste zvážiť, ako ich najlepšie nasmerovať cez vašu sieť.

Echo požiadavka a a Echo odpoveď

IPv4 – Echo požiadavka (Typ8, Code0) a Echo odpoveď (Type0, Code0)
IPv6 – Echo požiadavka (Type128, Code0) a Echo response (Type129, Code0)

Všetci dobre vieme, že ping je jedným z prvých nástrojov na riešenie problémov. Áno, ak na svojom hardvéri povolíte spracovanie paketov ICMP, znamená to, že váš hostiteľ je teraz zistiteľný, ale ten váš už nepočúva na porte 80 a neposiela odpovede na požiadavky klientov? Samozrejme, zablokujte aj tieto požiadavky, ak naozaj chcete svoje DMZ na okraji siete. Ale blokovaním ICMP prevádzky v rámci vašej siete neposilníte svoju bezpečnosť, naopak, skončíte so systémom so zbytočne zložitým procesom odstraňovania problémov („Skontrolujte, či brána reaguje na požiadavky siete?“, „Nie, ale toto ma vôbec nerozčuľuje, pretože mi je to jedno.“

Pamätajte, že môžete tiež povoliť, aby žiadosti smerovali určitým smerom; napríklad nakonfigurujte zariadenie tak, aby požiadavky Echo z vašej siete smerovali do internetu a Echo odpovede z internetu do vašej siete, ale nie naopak.

Vyžaduje sa fragmentácia paketu (IPv4) / Paket je príliš veľký (IPv6)

IPv4 – (Typ3, Kód4)
IPv6 – (Typ2, Kód0)

Tieto komponenty protokolu ICMP sú veľmi dôležité, pretože sú dôležitou súčasťou zisťovania cesty MTU (PMTUD), ktorá je neoddeliteľnou súčasťou TCP protokol. Umožňuje dvom hostiteľom upraviť hodnotu maximálnej veľkosti segmentu TCP (MSS) na hodnotu, ktorá sa zhoduje s najmenšou MTU pozdĺž komunikačnej cesty medzi týmito dvoma cieľmi. Ak sa pozdĺž cesty paketov nachádza uzol s menšou maximálnou prenosovou jednotkou ako odosielateľ alebo príjemca a títo nemajú prostriedky na zistenie tejto kolízie, potom bude prevádzka potichu vyradená. A nebudete rozumieť tomu, čo sa deje s komunikačným kanálom; inými slovami, „prídu pre teba veselé dni“.

Nefragmentujte – ICMP neprejde!

Prenos paketov IPv4 s nastaveným bitom Nefragmentovať (väčšina z nich!) alebo paketov IPv6 (nezabudnite, že v IPv6 nedochádza k žiadnej fragmentácii smerovačmi), ktoré sú príliš veľké na prenos cez rozhranie, spôsobí, že smerovač paket zahodí. a vygenerovať odpoveď na zdroj prenosu s nasledujúcimi chybami ICMP: Vyžaduje sa fragmentácia ( Vyžaduje sa fragmentácia), alebo Príliš veľký balík ( Aj balík Veľký). Ak sa odpovede s týmito chybami nedajú vrátiť odosielateľovi, bude to interpretovať absenciu potvrdzovacích odpovedí o doručení ACK paketov ( Poďakovanie) z prijímača ako preťaženie/strata a zdroj pre opakovaný prenos paketov, ktoré budú tiež zahodené.

Je ťažké identifikovať príčinu takéhoto problému a rýchlo ho vyriešiť Proces TCP handshake funguje dobre, pretože zahŕňa malé pakety, ale akonáhle dôjde k hromadnému prenosu dát, prenosová relácia zamrzne, pretože zdroj prenosu nie je. prijímať chybové hlásenia.

Skúmanie cesty doručovania paketov

RFC 4821 bol navrhnutý tak, aby pomohol účastníkom sieťovej prevádzky vyriešiť tento problém pomocou skúmania cesty paketov (Zisťovanie cesty MTU (PLPMTUD). Norma vám umožňuje odhaliť maximálna hlasitosťúdajov (Maximálna prenosová jednotka (MTU), ktoré je možné preniesť protokolom v jednej iterácii, postupným zvyšovaním maximálnej veľkosti bloku užitočných údajov (Maximálna veľkosť segmentu (MSS) s cieľom nájsť maximálnu možnú veľkosť paketu bez jeho fragmentácie pozdĺž cesty od vysielača k prijímaču. Táto funkcionalita znižuje závislosť na včasnom prijatí chybových odpovedí prostredníctvom protokolu ICMP (Internet Control Message Protocol) a je dostupná vo väčšine zásobníkov sieťových zariadení a klientskych operačných systémov, žiaľ, nie je taká efektívna ako priame získavanie údajov o maximálnej možnej veľkosti Povoľte, aby sa tieto správy ICMP vrátili do zdroja prenosu, dobre?

Čas prenosu paketu bol prekročený

IPv4 – (Typ11, Kód0)
IPv6 – (Typ3, Kód0)

Traceroute je veľmi užitočný nástroj na riešenie problémov sieťové pripojenia medzi dvoma hostiteľmi s podrobným popisom každého kroku cesty.

Odošle paket s životnosťou dátového paketu pre protokol IP (Čas žiť (TTL) rovný 1 aby prvý smerovač odoslal chybové hlásenie (vrátane svojej vlastnej IP adresy), že paket prekročil čas životnosti. Potom odošle paket s TTL 2 a tak ďalej. Tento postup je potrebný na zistenie každého uzla pozdĺž cesty paketu.

NDP a SLAAC (IPv6)

Router Solicitation (RS) (Typ133, Code0)
Reklama smerovača (RA) (Typ134, Kód0)
Neighbor Solicitation (NS) (Typ135, Code0)
Neighbour Advertisement (NA) (Typ136, Code0)
Presmerovanie (Typ137, Kód0)

Zatiaľ čo IPv4 používal Address Resolution Protocol (ARP) na mapovanie vrstvy 2 a vrstvy 3 sieťový model OSI, IPv6 má iný prístup vo forme protokolu NDP (Neighbor Discovery Protocol). NDP poskytuje mnoho funkcií vrátane zisťovania smerovača, zisťovania predpony, rozlíšenia adries a ďalších. Okrem NDP vám funkcia StateLess Address AutoConfiguration (SLAAC) umožňuje dynamicky konfigurovať hostiteľa v sieti, podobne ako koncept protokolu DHCP (Dynamic Host Configuration Protocol) (hoci DHCPv6 je určený na podrobnejšie riadenie).

Týchto päť typov správ ICMP nesmie byť vo vašej sieti blokovaných (ignorujte vonkajší obvod), aby protokol prenosu údajov IP správne fungoval.

Číslovanie typov ICMP

Protokol ICMP (Internet Control Message Protocol) obsahuje veľa správ, ktoré sú identifikované poľom „typ“.

Pár slov o rýchlostných limitoch

Aj keď správy ICMP, ako sú správy opísané v tomto článku, môžu byť veľmi užitočné, nezabudnite, že generovanie všetkých týchto správ zaberá čas procesora na vašich smerovačoch a generuje prenos. Naozaj očakávate, že v bežnej situácii dostanete cez firewall 1000 pingov za sekundu? Bude sa to považovať za bežnú premávku? Pravdepodobne nie. Limit priepustnosť siete pre tieto typy prevádzky ICMP, ako uznáte za vhodné; tento krok vám môže pomôcť zabezpečiť vašu sieť.

Čítajte, skúmajte a pochopte

Vzhľadom na to, že diskusia na tému „blokovať alebo neblokovať“ pakety ICMP vždy vedie k zmätku, sporom a nezhodám, navrhujem pokračovať v štúdiu tejto témy samostatne. Na tejto stránke som uviedol veľa odkazov. Domnievam sa, že pre úplnejšie pochopenie problémov by ste ich mali stráviť čítaním. A urobte informované rozhodnutia o tom, čo najlepšie funguje pre vašu sieť.

MikroTik: kde kliknúť, aby to fungovalo?
Napriek všetkým výhodám majú produkty MikroTik jednu nevýhodu - existuje veľa rozptýlených a nie vždy spoľahlivých informácií o ich konfigurácii. Odporúčame dôveryhodný zdroj v ruštine, kde je všetko zhromaždené, logicky a štruktúrované - video kurz “ Nastavenie zariadenia MikroTik" Kurz obsahuje 162 video lekcií, 45 laboratórne práce, samotestovacie otázky a poznámky. Všetky materiály zostávajú u vás na dobu neurčitú. Začiatok kurzu môžete sledovať zadarmo zanechaním požiadavky na stránke kurzu. Autorom kurzu je certifikovaný tréner MikroTik.

Skryté kanály sú jednou z metód v informačná bezpečnosť, ktorý je možné použiť ako so znamienkom plus (na zabezpečenie anonymity a dôvernosti), tak aj so znamienkom mínus (na organizáciu úniku dát). Zamyslime sa nad druhou zložkou – detekciou skrytého prenosu dát, alebo prenosu dát skrytými kanálmi, čo je v praxi jeden z najťažšie riešiteľných problémov informačnej bezpečnosti. Aby som nezväčšil veľkosť článku, budem zámerne ignorovať také mechanizmy skrývania údajov, ako je šifrovanie a steganografia.

Alexey Lukatsky
Bezpečnostný konzultant spoločnosti Cisco

Čo je skrytý prenos údajov?

Skrytý prenos dát cez sieť nie je jedinou aplikáciou túto metódu. Termín „skrytý kanál“ sa prvýkrát objavil v roku 1973 a používal sa pre výpočtové systémy, ktoré nemajú tradičný sieťové pripojenie. Napríklad párna hodnota trvania procesu môže znamenať jednotku a nepárna hodnota môže znamenať nulu. Manipuláciou s trvaním procesu teda môžeme vytvoriť postupnosť 0 a 1, ktorou môžeme čokoľvek opísať (toto je takzvaný časový kanál). Ďalším príkladom skrytého procesu vo výpočtových systémoch je, keď proces spustí určitú úlohu a dokončí ju v určitom čase, čo možno interpretovať ako jednotku; a nula, ak úloha nie je dokončená v určený čas.

Ako je možné realizovať skrytý prenos?

Ak hovoríme o skrytom sieťovom prenose dát, tak jednou z najpopulárnejších a relatívne jednoducho implementovateľných metód je zapuzdrenie, ktoré spočíva v zahrnutí chránených informácií, ktoré musia byť prenášané externe, alebo príkazu, ktorý musí byť prijatý externe, do autorizovaného protokolu.

V tomto prípade je možné použiť úplne iné možnosti zapuzdrenia:

V roku 1987 bola navrhnutá myšlienka skrytého sieťového prenosu a od tej chvíle sa začal seriózny výskum tejto metódy zabezpečenia dôvernosti alebo úniku údajov (v závislosti od toho, na ktorú stranu plotu sa pozeráte). Najmä v roku 1989 bolo prvýkrát navrhnuté manipulovať s nepoužitými bitmi ethernetových rámcov a množstvom iných kanálových protokolov. Je zrejmé, že skryté kanály v lokálna sieť nie je také zaujímavé študovať, na rozdiel od skrývania údajov globálne siete. Za prelom (aspoň verejný) možno považovať rok 1996, kedy bola publikovaná štúdia, ktorá demonštrovala skutočný prenos a príjem dát cez skrytý TCP/IP kanál; alebo skôr v jednotlivých poliach jeho hlavičky.

• Na úrovni HTTP, ktorá sa už dávno stala de facto štandardom pre budovanie ďalších aplikačných protokolov na jej základe. Napríklad anonymná sieť JAP používa HTTP na prenos dát, a to aj pomocou ťažko ovládateľného Sieť Tor. V HTTP je možné na prenos dát použiť príkazy GET a POST a ak sa HTTP používa na prenos video a audio streamingu, tak sa schopnosť útočníkov prenášať veľké množstvo dát stáva takmer neobmedzenou.
• Na úrovni DNS, keď sú informácie skryté vo vnútri DNS dotazov a odpovedí na ne. Ľudia prvýkrát začali hovoriť o tejto metóde začiatkom roku 2000, keď sa objavil nástroj DeNiSe na tunelovanie protokolu TCP do DNS. Neskôr sa objavila štúdia Dana Kaminského ukazujúca možnosť zapuzdrenia SSH cez DNS a prezentovaná na konferencii Defcon v roku 2005. A potom sa táto téma začala získavať na popularite - objavili sa dns2tcp, DNScapy, DNScat, Heyoka, jód, squeeza atď.
• Na úrovni ICMP, keď sú údaje zapuzdrené v rámci bežne zabezpečeného protokolu ICMP. Na tomto princípe fungoval program Loki, prvýkrát spomenutý v roku 1996 v časopise Phrack. Po ňom nasledoval pokročilejší Loki2. Existuje aj nástroj s názvom icm-pchat, ktorý vám umožňuje komunikovať so šifrovanými správami cez ICMP.
• Na úrovni TCP/UDP/IP, keď sa jednotlivé polia hlavičky paketu používajú na skrytie únikov alebo prijímanie príkazov zvonku. V závislosti od použitého protokolu sa veľkosť prenášaných údajov bude líšiť od 2 do 12 a 38 bajtov v protokoloch IP, UDP a TCP. Veľmi zaujímavý nástroj, ktorý využíva úpravu hlavičky TCP, sa nazýva Nushu. Jeho zvláštnosťou je, že sám o sebe nevytvára žiadnu prevádzku, ale iba upravuje tú, ktorá je už odoslaná z uzla nejakou aplikáciou alebo procesom. Inými slovami, upravená prevádzka sa posiela tam, kde má byť, a útočník ju jednoducho zachytí cez sieť a takto uniknuté dáta zbiera.
• V bezdrôtových sieťach, keď sú dáta maskované v prenášanej prevádzke distribuovanej vysielaním. Mimochodom, v tomto prípade nie je ľahké odhaliť prijímaciu stranu, ktorá môže fungovať v pasívnom režime - iba prijímať dáta. Na tomto princípe je postavený nástroj HICCUPS.

Ako sa dá odhaliť skrytý prenos?

Keď vidíte takú rozmanitosť metód, ktoré skryté kanály používajú, a protokoly, v ktorých sa nachádzajú, môžete pochopiť, prečo existuje toľko rôznych metód na detekciu skrytých prenosov. Hlavnou je kontrola anomálií, ktorá pozostáva z kontroly nasledujúce parametre(neúplný zoznam):

• Veľkosť požiadavky a odpovede. Napríklad je známe, že priemerná dĺžka požiadavky DNS nie je väčšia ako 40–60 bajtov. Preto zvýšenie počtu DNS dotazov so zvýšenou dĺžkou paketov môže naznačovať, že funguje skrytý kanál. Podobnú prax možno navrhnúť aj pre iné protokoly – ICMP, SIP atď.
• Objem žiadostí. Typicky je objem prevádzky pre určité typy protokolov, ak nie je pevná hodnota, potom sa zriedka mení v rámci niekoľkých zlomkov percent. Preto náhly nárast prevádzky protokolu služby alebo počtu požiadaviek DNS alebo ich veľkosti môže naznačovať anomáliu a potrebu vyšetrovania. Okrem toho môže byť dopravný profil v tomto prípade vyhodnotený pre uzol odosielateľa aj pre uzol príjemcu.
• Počet alebo geografická poloha prístupov môže slúžiť aj ako charakteristika skrytých kanálov. Napríklad, ak máte interný server DNS, trvalé volania do externého uzla DNS môžu tiež naznačovať anomáliu.
• Na detekciu skrytých kanálov sú užitočné aj iné typy štatistických analýz. Môžete napríklad analyzovať úroveň entropie v názvoch hostiteľov pre DNS. Ak DNS požaduje prenos skryté informácie, potom sa rozloženie použitých symbolov bude líšiť od tradičného.

Nástroj, ktorý vám umožní sledovať takéto anomálie v sieťová prevádzka, sú systémy triedy NBAD (Network-based Anomaly Detection), ktoré buď už obsahujú veľké množstvo vstavaných pravidiel, alebo môžu byť konfigurované samostatne po tréningovom režime.

Okrem analýzy anomálií možno skryté kanály odhaliť aj štúdiom obsahu v určitých protokoloch. Dá sa to dosiahnuť pomocou tradičných riešení triedy Next Generation, ktoré dokážu monitorovať odchýlky prevádzky aplikačného protokolu od RFC, ako aj pomocou systémov detekcie narušenia. Napríklad takto vyzerá podpis na detekciu skrytého kanála NSTX v protokole DNS pre open source riešenie Snort:
alert udp $EXTERNAL_NET any - > $HOME_NET 53 (msg:"Potenciálne NSTX DNS Tunneling"; obsah:"|01 00|"; offset:2; v rámci:4; content:"cT"; offset:12; hĺbka:3 ; obsah:"|00 10 00 01|";

Zhrnutie

Nedostatok univerzálnosti je možno hlavnou prekážkou aktívneho využívania skrytých kanálov a boja proti nim.

Skryté kanály v sieťovej prevádzke sú veľmi špecifickou metódou, ktorá nie je univerzálna a má svoje obmedzenia a rozsah. Každý skrytý kanál má svoje vlastné charakteristiky, ako je šírka pásma, šum, režim prenosu (obojsmerný alebo jednosmerný), ktoré je potrebné vziať do úvahy - pri ich používaní aj pri boji s nimi. Napriek tomu „Vojna a mier“ od L.N. Tolstého nie je možné rýchlo prenášať takýmito kanálmi a niektoré spôsoby skrytého prenosu majú veľmi vysokú hladinu hluku, čo bráni ich efektívnemu použitiu v globálnych sieťach, v ktorých môžu vonkajšie faktory výrazne ovplyvniť úspešnosť skrytého prenosu.

Nedostatok univerzálnosti je možno hlavnou prekážkou aktívneho využívania skrytých kanálov a boja proti nim. Veľké množstvo obmedzenia skrytého prenosu dát z neho robia doménu len cielených hrozieb vyvinutých pre konkrétnu úlohu a konkrétneho zákazníka. Rovnaký nedostatok univerzálnosti vedie k myšlienke, že ani teraz neexistuje strieborná guľka v podobe jedného produktu a na detekciu a neutralizáciu skrytého prenosu dát je potrebné použiť celý rad nástrojov a technológií.

Tento krátky článok vám ukáže, ako s niekoľkými počítačmi, niekoľkými zábavnými nástrojmi a operačný systém dostať bezdrôtový prístup na internet všade, kde je to možné. Technickú stránku som popísal celkom jasne a uviedol komentáre.

1. Úvod.

Práve som dostal svoj prvý notebook a chcel som s ním urobiť niečo nezbedné (dokonca som sa pokúsil urobiť nejakú prácu, ale bolo to príliš únavné
:)). Wardriving bola spočiatku celkom zábavná činnosť, ale trochu som sa nudil, keď som si uvedomil, že siete chránia
WEP je pre mňa príliš náročný (keďže neexistovala intranetová prevádzka - siete by sa dali považovať za mŕtve) a nechránené siete ma vôbec nezaujímajú. Našťastie bola bezdrôtová sieť na mojom univerzitnom kampuse o niečo zaujímavejšia.

Sieť poskytuje zadarmo bezdrôtový internet, ale pred povolením prístupu vyžaduje registráciu MAC adresy na vaše meno - neregistrovaní používatelia sú presmerovaní na stránku poskytovateľa (registračná stránka). Registrácia by vyžadovala dvojminútový rozhovor s administrátorom, ale pomyslel som si: „Možno
spôsob, ako získať prístup bez takejto komunikácie? Samozrejme, že bol.

2. Prvým spôsobom prieniku je MAC spoofing.

Keďže sa všetko točilo okolo MAC adresy, prvé čo ma napadlo bolo
bolo zistiť už zaregistrovanú MAC adresu a vysporiadať sa s ňou
spoofing. Samozrejme, je ľahké hovoriť, ale nevyžadovalo si to takmer žiadne úsilie, aj keď som to nikdy predtým nerobil.
Ako prvé som spustil kismet ("kismet -c orinoco,eth1,wifi") a pričuchol k sieťke. Kismet uloží všetko, čo ste si stiahli
informácie do súboru (v mojom prípade „/var/log/kismet/*.dump“), výsledky sniffovania je možné zobraziť tak, ako sú
potvrdenky. V dôsledku toho som mohol zobraziť všetky informácie a
zapíšte si príslušnú MAC adresu.

Príkazy používané na zmenu MAC adresy sieťovej karty:

ifconfig eth1 dole
killall dhclient
ifconfig hw éter 00:11:22:33:44:55
ifconfig eth1 up
dhclient eth1

Nie všetky príkazy sú potrebné, ale sú veľmi užitočné, keď sa pokúšate zmeniť niekoľko MAC adries za sebou, čo
Bolo to pre mňa užitočné, pretože... MAC adresa, ktorú som sa pokúšal zmeniť, nefungovala hneď. Dostal som ban, sieť vypadla a nechcela sa znova zapnúť, čo spôsobilo, že som sa vysporiadal s niektorými trochu nepríjemnými chybami
vo vašom systéme. Možno tieto problémy
sa objavil kvôli chybnému firmvéru alebo možno preto, že už existoval a LAN karta s rovnakou MAC adresou.

Nie všetky pracovné stanice boli aktívne a používanie kismetu na zobrazenie výsledkov tak, ako prichádzali, bolo neúčinné, tak som skúsil inú metódu.

V sieti bolo filtrovanie MAC adries vykonávané na pomerne vysokej úrovni. Do siete som mohol pristupovať kedykoľvek, pretože... Keď som sa pokúsil pripojiť, dostal som sa na stránku so žiadosťou o registráciu.
Prirodzene, keď som premýšľal o aktívnych hostiteľoch, prišiel na myseľ nmap. Začal som teda kontrolovať rozsah IP pre aktívne stanice.

marktwain:~# nmap -sP 10.0.0.1/22
Spúšťa sa nmap 3.81 (http://www.insecure.org/nmap/) 23.05.2005 12:54 EEST
Zdá sa, že hostiteľ 10.1.0.14 je aktívny.
Adresa MAC: 00:0E:35:97:8C:A7 (Intel)
Zdá sa, že hostiteľ 10.1.0.95 je aktívny.

Zdá sa, že hostiteľ 10.1.0.109 je aktívny.
Adresa MAC: 00:0D:54:A0:81:39 (3Com Europe)
...strihať...
Zdá sa, že hostiteľ 10.1.2.92 je aktívny.
Adresa MAC: 00:02:2D:4D:1C:CE (Agere Systems)
Zdá sa, že hostiteľ 10.1.2.187 je aktívny.
Adresa MAC: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap dokončený: 1024 IP adries (až 20 hostiteľov) naskenovaných za 53,980 sekúnd

Množstvo MAC adries. Väčšina z
Výsledná tabuľka adries (ako predpokladám) sú MAC adresy strojov, ktoré navštívili sieť za posledných pár dní. V tabuľke bolo 245 rôznych MAS
adresy. Neviem, či je to normálne správanie
prístupové body, ale myslím, že chalani niečo potrebujú
zmena v distribúcii internetu. Každopádne, teraz mám dosť MAC adries strojov, ktoré sieť navštívili, ale s najväčšou pravdepodobnosťou už dávno odišli. Pár pokusov o spoofing a už som smeroval na neworder.box.sk...

3. Pokus číslo 2 - ICMP tunelovanie.

Splnil som všetko, čo som chcel, ale stále bolo v tejto sieti priestor na kopanie. Ale čo
Mohol by som to urobiť, keby táto sieť nemala
nemal by mi ani jedno auto? Ak
Neotvoril by sa nmap a neukázal všetky tieto MAC adresy? Tak či tak som sa rozhodol vyskúšať iný spôsob získania prístupu.

Predtým to nebolo spomenuté, ale obíďte systém
Internetová distribúcia dávajúca povolenie a DHCP, sieť umožňovala voľný prechod správ ICMP. Kontrola aktivity akejkoľvek internetovej stránky fungovala perfektne (naozaj nechápem, prečo ju nezablokovali – pokiaľ nezabudli), ping
bol detekovaný aj na sniffer, ktorý bežal na mojom serveri.
Mojím plánom bolo pokúsiť sa vytvoriť tunel medzi mojím notebookom na univerzite a serverom doma. A prejdite cez ňu všetky spojenia.
Hľadal som na internete aplikácie na tunelovanie ICMP, ale žiadna nefungovala tak, ako som chcel (konkrétne som chcel, aby to bolo jednoduché - aby keď spustím svoj obľúbený prehliadač alebo akýkoľvek iný program, fungovalo to iba s tunelom) alebo aspoň
vyzerala stráviteľne.

4. Trochu kódovania.

Najprv som neplánoval nič kódovať. Vyskúšal som niekoľko aplikácií tunela ICMP
s packetstormom, no zrazu som sa pristihol, že čítam zdrojový kód jedného z nich a uvedomujem si, aké je to úžasne jednoduché a aké ľahké by bolo niečo také urobiť. Názov programu – itunnel –
Bežný nástroj na tunelovanie ICMP. Itunnel je úžasný. Ale je to len tunel. Spustíte to na jednom stroji a nakoniec to vyzerá, že ste spojili dva
sieťové karty spolu. Na to, čo som chcel robiť, to nestačilo.
Už som počul o module jadra TUN/TAP, ktorý umožňuje užívateľským procesom prijímať a odosielať pakety informácií priamo do/z jadra.

Program vytvorí virtuálne sieťové rozhranie.
Vytvára sieťové rozhranie, ktoré
funguje presne rovnako
štandardná Najzaujímavejšie je, že
užívateľské programy musia
pracovať ako fyzická vrstva pre rozhranie
tunel. Musia čítať pakety informácií z
súbor zariadenia (napríklad "/dev/net/tun0") a posielať ich akýmkoľvek spôsobom a zapisovať pakety odpovedí
späť do súboru.

Nenašiel som žiadny dobrý zdroj
pomocou TUN/TAP, ale existuje program - vtun - ktorý používal TUN/TAP pre svoje tunely, takže
Použil som zdroje vtun. Po malom prieskume sa ukázalo, že existuje malá knižnica funkcií používaných na vytváranie, čítanie a zápis do tun*
zariadení. Prečo by som mal písať program sám, ak to môžem urobiť opravou niekoľkých bitov?
Kód, ktorý som skutočne napísal:

#include "driver.h" /* vyhlásiť knižnicu vtun */
#include
#include

/* mierne upravený main() z itunnel
*/
int run_icmp_tunnel (int id, int packets size, char *desthost, int tun_fd);

/* maximálna jednotka – maximum
veľkosť zapuzdreného balenia
*/
const int mtu = 1400;

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

/* vytvorenie tunelového zariadenia */
dev = (char *) malloc(16);
if (dev == NULL) (
printf("ak ste nikdy nemali problémy s
pridelením 16 bajtov\"
"pamäť je tvoja prvá. Fatal.n");
návrat 1;
}
dev = 0;
/* pekná knižničná funkcia
z vtun akceptuje prázdny reťazec ako*
* argument, vytvorí zariadenie tunX a
odovzdá to *dev */
tun_fd = tun_open (dev);

if (tun_fd< 1) {
printf("Nie je možné vytvoriť zariadenie. Fatal.n");
návrat 1;
}
inak(
printf("Vytvorené tunelovacie zariadenie: %sn", dev);
}

/* 7530 je pole ICMP id,
používané pre pakety v tuneli
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);

tun_close(tun_fd, dev);
}

Tu je. A väčšina z nich sú komentáre a kontrola chýb

Ako som už spomínal, itunnel je ideálny na stavbu tunelov. Má hlavnú funkciu, ktorou je
otvorené súbory pre vstup, výstup a zásuvku; Tiež
Dostal som nejaké parametre pre príkazový riadok (ktoré by mohli byť užitočné pre moje účely). Ďalej nazval mierne abstraktnú funkciu, ktorá v podstate iba prenášala balíky informácií. ICMP hlavička zadarmo
je popísaná v kóde a dá sa ľahko zmeniť na akúkoľvek inú hlavičku,
vstup/výstup/zásuvku je možné nakonfigurovať podľa nejakého iného logického obvodu – funkcia bude fungovať s minimálnymi úpravami.

Najviac veľká zmena, čo som urobil - odstránenie všetkých manipulácií s príkazový riadok– v podstate odstránenie niekoľkých blokov kódu. Najdôležitejšie pre logiku tunela je, že som odstránil rozdiel medzi vstupom a výstupom, pretože sú oboje
visieť na rovnakom deskriptore (zariadenie tunX) –
dalo mi to namiesto toho, aby som sa správala
netcat a preposlať stdin do ICMP soketu a ICMP soket do stdout,
posiela odchádzajúci signál do zariadenia tunX (ako http žiadosti z prehliadača) na ICMP
soket a výstup soketu ICMP (ako keby HTTP
požiadavky zo servera boli odoslané späť
cez tunel) do zariadenia tunX (do
sa vráti späť do prehliadača). Keďže posledná veta je veľmi dlhá a spletitá, na ilustráciu uvádzam malý diagram:

Odozva pakety informácií sledujú rovnakú cestu, ale
iným spôsobom.

V jednom momente som sa už dosť zbláznil a skutočne som písal Nový riadok kód. Vyzerá to takto:

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

Jeho funkciou je začať posielať všetky pakety informácií na miesto, kam dorazil posledný paket. môžem
spustite ho na mojom serveri a pripojte sa
odkiaľkoľvek poslať paket cez tunel
a okamžite zmení IP príjemcu na IP
môj laptop.

Výsledok si môžete prevziať tu:

5. Montáž tunelov.

Tunel som testoval doma a fungoval dobre, ale doma nebol firewall. Nasledujúci deň na univerzite som bol pripravený otestovať to v reálnom živote. Náhodou, keď som sedel pri stole v kaviarni, som pomocou spoofingu našiel MAC adresu a založil tunel.

Je ťažké zapamätať si všetky tie hlúpe triky, ktoré som skúšal, a malé experimenty, ktoré som robil, a tak som sa snažil urobiť túto časť čo najorganizovanejšie. V skutočnosti som nerobil všetko tak jasne.
Aby mi všetko fungovalo
Trvalo to 3 hodiny a skúšal som všetko, čo sa dalo, zatiaľ čo som čuchal všade, kde sa dalo, a upravil kód tak, aby pri prijatí paketu informácií skandoval „Paket“ a pri odoslaní vlastného paketu niečo otravovalo. A tak ďalej.

Na serveri som spustil tieto príkazy:

tsee-diees:~# ./create_tun wifi.ttu.ee
Vytvorené tunelové zariadenie: tun0

Zastavená ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 vyššie
tsee-diees:~# pridať trasu 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"

Myslel som, že to bude fungovať okamžite a spustil som to na svojom notebooku:

marktwain:~# ./create_tun 194.204.48.52
Vytvorené tunelové zariadenie: tun0

Zastavená ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 vyššie
marktwain:~# pridať trasu 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"

Čo som potreboval urobiť, bolo vytvoriť
sieť s dvoma hostiteľmi – serverom 192.168.3.1 a notebookom 192.168.3.2. Jednoduchá normálna LAN, len jej fyzická vrstva bude ICMP tunel. Asi ako ty
pochopené zo zvyšného textu v článku
metóda naozaj nefungovala. Spustil som ping ("ping 192.168.3.1"), ale pakety stále neprechádzali.

Našťastie, sniffer na notebooku mi dal malú stopu - ICMP pakety boli spätné odpovede. Samozrejme, že nie
odchádzame. Takže zabijeme tunel, povolíme itunnel na notebooku a použijeme icmp return responses (zmeňte “icmp->type = 0;” na “icmp->type = 8;”), vrátime tunel.
Systém stále nefungoval, tentoraz však balíčky
sa objavil na sniffer na serveri.

Čo môže byť zlé? Skúsil som jednu modifikáciu, ktorá mala pri príchode ďalšieho paketu kričať „Packet!“, ale výkričníky nie
vznikol. "Prečo vlastne," uvažoval som, "ak je nainštalovaný firewall, mal by blokovať všetky ICMP pakety z internetu?" Po nejakom čase som si uvedomil, že to tak v skutočnosti bolo (všetky ICMP pakety z internetu boli zablokované).

Už lepšie. Tunel kričí "Paket!" a odpovede je možné vidieť na sniffer na serveri. V skutočnosti existujú dve odpovede na každú požiadavku, z ktorých iba jedna je vidieť na sniffer na notebooku. A ping stále nefunguje.

Keďže jeden z dvoch paketov je nadbytočný, povedal som jadru, aby nereagovalo na spätné odoslanie icmp:

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

A pingy začali prechádzať! V tomto bode som sa stále spoliehal na sfalšovanú MAC adresu, aby som získal prístup k serveru. Keďže myšlienkou bolo, aby pakety putovali oboma smermi od neregistrovaného používateľa, prestal som falšovať MAC adresy. Tunel zároveň pokračoval v prevádzke, čo bolo pomerne príjemným prekvapením.

Tok paketov bol stanovený a nastal čas, aby „internet“ fungoval.
Potrebné vykonať nejaké zmeny v IP
smerovanie na notebooku. Cesta cez
univerzitný smerovač bezdrôtová sieť mala byť nahradená adresou tunela servera (v tomto prípade 192.168.3.1). Stále musí existovať cesta k serveru, aby samotný tunel mohol fungovať (pakety tunela ICMP tiež potrebujú cestu, ktorú majú nasledovať).
Mám dobré výsledky:

marktwain:~# pridanie trasy 194.204.48.52 gw 10.0.0.111 # cez bezdrôtový smerovač
marktwain:~# predvolená trasa
marktwain:~# route add default gw 192.168.3.1 # všetko ostatné cez tunel.

A keďže som nejaký múdry, myslel som si, že medzi tým môže byť nesúlad
počet paketov odoslaných na server a zo servera. Spustil som ping
v pozadí sledovať situáciu:.

marktwain:~# ping 194.204.48.52 -i 0,2
PING 194.204.48.52 (194.204.48.52) 56 (84) bajtov dát.

Samozrejme, neprišli žiadne odpovede, pretože to neboli „tunelové pingy“ a odpovede z jadra boli
vypnutý.

Keďže môj server už bol vyškolený
zdieľať internetové pripojenie medzi viacerými počítačmi, všetko, čo som na serveri musel urobiť, bolo pridať dve pravidlá pre
FORWARD reťazec v iptables na prijímanie paketov z a do tun0. Keď som rutinne kontroloval aktuálne pravidlá ("iptables -vL FORWARD"), spojenie náhle prestalo fungovať. Znovu som sa pripojil a preskúmal tento problém,
ale čoskoro spojenie opäť umrelo. Bol som naozaj prekvapený - prečo je spojenie také nestabilné?
Po premýšľaní som si uvedomil, že zakaždým, keď server odoslal veľkú odpoveď ICMP
(predsa len hlavička pingu bola 1400+), bola zamietnutá
samotné vybavenie. Keďže tunel bol fyzický
na úrovni IP sa TCP prirodzene pokúsil odoslať pakety znova, ale veľkosť bola stále rovnaká a stále boli vyradené. Tak som zmenil MTU pre tunel na 300 (in
všeobecne povedané náhodou)

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

A celý systém fungoval.

6. Záver.

Teraz to urob sám.

Skryté kanály je jednou z metód utajovania akcií alebo vykonávania útokov, ktorá sa používa na utajený, neoprávnený alebo nezákonný prenos informácií. Pomocou skrytých kanálov môže dôjsť k úniku informácií alebo naopak k zavedeniu informácií do organizácie. Skrytý kanál na internete možno prirovnať k tajnej priehradke v kufríku, v ktorej sa môže útočník pokúsiť ukryť tajné dokumenty aby ich preniesli cez vchod do citlivého zariadenia. Na internete môžu útočníci použiť na prenos skryté kanály tajné materiály, pričom zostávajú nepovšimnuté - v tomto prípade mechanizmy na zaistenie bezpečnosti siete fungujú ako vstupný bod bezpečnostného zariadenia. Rovnako ako špión môže ukryť zbraň v tom istom tajnom priestore, aby ju skryl pred bezpečnosťou a preniknúť spolu s ním do zariadenia na internete môžu útočníci použiť skryté kanály na tajný prenos kybernetických zbraní, napríklad na stiahnutie škodlivého softvéru z externého servera do uzla v súkromnej sieti organizácie.

Pochopenie skrytých kanálov na internete

Skryté kanály na internete môžu byť založené na nekonvenčnom používaní známych internetových protokolov. Koncové body samostatného kanála – infikovaný počítač a veliteľské centrum útočníkov – musia používať špeciálny softvér schopný rozpoznať a spracovať takéto nekonvenčné techniky na útok alebo skrytie akcií. Takýto softvér si môže nainštalovať samotný používateľ alebo škodlivý softvér, prípadne útočníci pomocou nástrojov vzdialená správa(POTKAN). Internetové skryté kanály sa líšia od šifrovaných tunelov. Informácie prostredníctvom nich sa môžu prenášať nešifrovane (často sa to stáva), ale tieto kanály samotné sú skryté pred cudzincami. Použite šifrovanie resp kryptografické kľúče v tomto prípade to nie je potrebné, ale niekedy sa stále používajú skryté kanály rôznymi spôsobmišifrovanie alebo zahmlievanie údajov.

Pozrime sa na dva príklady. Prvou technikou je skrytý prenos informácií jeden znak po druhom do poľa identifikátora (ID) hlavičky paketu internetového protokolu (IP). V bežných implementáciách tejto techniky sa kódy ASCII znakov vynásobia 256, aby sa vytvorili 16-bitové hodnoty, ktoré sú nahradené v poli identifikátora. Na prenos skratky ICANN by bolo potrebné preniesť 5 IP paketov s nasledujúcimi hodnotami polí identifikátora:

Prijímajúci počítač dešifruje hodnotu poľa IP paketu ID vydelením výslednej hodnoty číslom 256. Prenos takýchto hodnôt nevyvoláva žiadne podozrenie a keďže IP protokol umožňuje prenos duplicitných paketov, pravdepodobnosť takéhoto zisťovaná premávka je nízka. Nízka rýchlosť je kompenzovaná nenápadnosťou prevodovky.

Druhá technika na vytvorenie skrytého kanála zahŕňa použitie užitočného zaťaženia protokolu, t.j. technická informácia prenášané v rámci zvoleného protokolu. V tomto prípade sa do požiadaviek a odpovedí ECHO pridávajú údaje – ide o servisné správy, ktoré sa používajú v protokole Internet Control Message Protocol alebo ICMP. ECHO správy sa používajú v spoločnej službe ping . Správcovia sietečasto používajú službu ping na kontrolu, či je konkrétny vzdialený hostiteľ dosiahnuteľný, takže paketová prevádzka ICMP ECHO je zvyčajne povolená prostredníctvom nástrojov zabezpečenia siete, ako sú brány firewall.

Ak máte záujem dozvedieť sa viac o týchto technikách, prečítajte si nasledujúce články: Skryté kanály – otázky a odpovede a Skryté kanály cez ICMP (PDF, 740 KB).

Ďalej. Skryté kanály DNS

Protokol DNS (Domain Name System) má množstvo charakteristík, ktoré umožňujú pohodlné používanie skrytých kanálov. Prevádzka DNS je povolená cez brány firewall v oboch smeroch. Nebezpečenstvo Použitie DNS vytváranie skrytých kanálov je často prehliadané alebo podceňované, a preto organizácie alebo poskytovatelia internetových služieb nie vždy kontrolujú prenos DNS na známky útokov. Niekedy DNS prevádzka unikne do širšieho internetu, aby sa vyriešili mená pred vykonaním funkcií autorizácie alebo autentifikácie používateľov, čo umožňuje použitie skrytých kanálov DNS na obídenie takýchto kontrol prístupu.

V našom ďalšom príspevku sa budeme zaoberať tým, ako možno skryté kanály DNS použiť na extrahovanie údajov, obídenie kontroly prístupu alebo stiahnutie škodlivého softvéru.