Ce este un exploit de canal secret. Rețea wireless în palmă sau tunel ICMP în acțiune. Explorarea căii de livrare a pachetelor
Învăţa configurarea MikroTik Puteți urma un curs online despre echipamente de la acest producător. Autorul cursului este un trainer certificat MikroTik. Puteți citi mai multe la sfârșitul articolului.
Articolul răspunde la întrebarea cât de periculos este blocarea traficului ICMP.
ICMP este un element al disputei
Mulți administratori de rețea cred că Protocolul de mesaje de control al Internetului (ICMP) este un risc de securitate și, prin urmare, ar trebui să fie întotdeauna blocat. Este adevărat că protocolul are anumite probleme de securitate și că unele solicitări ar trebui să fie blocate pentru a bloca tot traficul ICMP!
Traficul ICMP are multe funcții importante; unele dintre ele sunt utile pentru depanare, în timp ce altele sunt necesare pentru funcționare corectă retelelor. Mai jos sunt câteva părți importante ale protocolului ICMP despre care ar trebui să le cunoașteți. Ar trebui să luați în considerare cum să le direcționați cel mai bine prin rețeaua dvs.
Solicitare eco și răspuns eco
IPv4 – Cerere ecou (Tip8, Code0) și răspuns ecou (Tip0, Code0)
IPv6 – Solicitare ecou (Tip128, Code0) și răspuns ecou (Tip129, Code0)
Știm cu toții bine că ping-ul este unul dintre primele instrumente de depanare. Da, dacă activați procesarea pachetelor ICMP pe hardware-ul dvs., aceasta înseamnă că gazda dvs. este acum descoperită, dar a dvs. nu ascultă deja pe portul 80 și trimite răspunsuri la solicitările clientului? Desigur, blocați și aceste solicitări dacă doriți cu adevărat DMZ-ul dvs. la marginea rețelei. Dar blocând traficul ICMP în rețeaua dvs., nu vă veți consolida securitatea, dimpotrivă, veți ajunge la un sistem cu un proces de depanare inutil de complex („Vă rugăm să verificați dacă gateway-ul răspunde la solicitările rețelei?”, „Nu, dar asta nu mă supără deloc, pentru că nu-mi pasă.”
Amintiți-vă, puteți, de asemenea, să permiteți cererilor să meargă într-o anumită direcție; de exemplu, configurați echipamentul astfel încât solicitările Echo din rețeaua dvs. să ajungă la Internet și răspunsurile Echo de la Internet către rețeaua dvs., dar nu invers.
Fragmentarea pachetului este necesară (IPv4) / Pachetul prea mare (IPv6)
IPv4 – (Tip3, Cod4)
IPv6 – (Tip2, Cod0)
Aceste componente ale protocolului ICMP sunt foarte importante, deoarece sunt o componentă importantă în Path MTU Discovery (PMTUD), care este o parte integrantă a Protocolul TCP. Permite două gazde să ajusteze valoarea maximă a dimensiunii Segmentul TCP(MSS) la o valoare care va corespunde celui mai mic MTU de-a lungul căii de comunicație între două destinații. Dacă de-a lungul căii pachetelor există un nod cu o unitate de transmisie maximă mai mică decât expeditorul sau destinatarul și nu au mijloacele pentru a detecta această coliziune, atunci traficul va fi eliminat în liniște. Și nu veți înțelege ce se întâmplă cu canalul de comunicare; cu alte cuvinte, „vor veni zile vesele pentru tine”.
Nu fragmentați – ICMP nu va trece!
Transmiterea pachetelor IPv4 cu setul de biți Don't Fragment (majoritatea dintre ele!) sau pachete IPv6 (rețineți că nu există fragmentare de către routere în IPv6) care sunt prea mari pentru a fi transmise prin interfață va determina routerul să renunțe la pachet. și generați răspuns la sursa de transmisie cu următoarele erori ICMP: Fragmentare necesară ( Fragmentarea necesară), sau Pachet prea mare ( Pachetul de asemenea Mare). Dacă răspunsurile cu aceste erori nu pot fi returnate expeditorului, atunci acesta va interpreta absența răspunsurilor de confirmare cu privire la livrarea pachetelor ACK ( Confirmare) de la receptor ca congestie/pierdere și sursa de retransmitere a pachetelor care vor fi, de asemenea, aruncate.
Este dificil să identifici cauza unei astfel de probleme și să o rezolvi rapid, procesul de strângere de mână TCP funcționează bine, deoarece implică pachete mici, dar de îndată ce are loc un transfer de date în bloc, sesiunea de transfer se blochează, deoarece sursa transferului nu se îngheață; primi mesaje de eroare.
Explorarea căii de livrare a pachetelor
RFC 4821 a fost conceput pentru a ajuta participanții la traficul de rețea să rezolve această problemă utilizând sondarea căilor de pachete (Descoperire MTU cale (PLPMTUD). Standardul vă permite să detectați cantitatea maximă de date (Unitate de transmisie maximă (MTU), care poate fi transmis prin protocol într-o singură iterație, prin creșterea treptată a dimensiunii maxime a blocului de date util (Dimensiunea maximă a segmentului (MSS), pentru a găsi dimensiunea maximă posibilă a unui pachet fără a-l fragmenta pe traseul de la emițător la receptor. Această funcționalitate reduce dependența de primirea în timp util a răspunsurilor de eroare prin Internet Control Message Protocol (ICMP) și este disponibilă în majoritatea stivelor de dispozitive de rețea și a sistemelor de operare client. Din păcate, nu este la fel de eficientă ca obținerea directă a datelor despre dimensiunea maximă posibilă a pachetelor transmise. Vă rugăm să permiteți acestor mesaje ICMP să revină la sursa de transmisie, bine?
Timpul de transmisie a pachetului a fost depășit
IPv4 – (Tip11, Cod0)
IPv6 – (Tip3, Cod0)
Traceroute este un instrument foarte util pentru depanare conexiuni de rețeaîntre două gazde, detaliind fiecare pas al căii.
Trimite un pachet cu durata de viață a pachetului de date pentru protocolul IP (Timp de trăit (TTL) egal 1 pentru ca primul router să trimită un mesaj de eroare (inclusiv propria sa adresă IP) că pachetul și-a depășit timpul de viață. Apoi trimite un pachet cu TTL 2 și așa mai departe. Această procedură este necesar pentru a detecta fiecare nod de-a lungul căii pachetului.
NDP și SLAAC (IPv6)
Solicitare router (RS) (Tip133, Cod0)
Publicitate pentru router (RA) (Tip134, Cod0)
Solicitare vecină (NS) (Tip135, Cod0)
Anunț pentru vecini (NA) (Tip136, Cod0)
Redirecționare (Tip137, Cod0)
În timp ce IPv4 a folosit Address Resolution Protocol (ARP) pentru a mapa straturile 2 și 3 ale modelului de rețea OSI, IPv6 utilizează o abordare diferită sub forma Neighbor Discovery Protocol (NDP). NDP oferă multe funcții, inclusiv descoperirea routerului, descoperirea prefixelor, rezoluția adreselor și multe altele. Pe lângă NDP, StateLess Address AutoConfiguration (SLAAC) vă permite să configurați dinamic o gazdă într-o rețea, similar conceptului Dynamic Host Configuration Protocol (DHCP) (deși DHCPv6 este destinat unui control mai granular).
Aceste cinci tipuri de mesaje ICMP nu trebuie blocate în rețeaua dumneavoastră (ignorând perimetrul exterior) pentru ca protocolul de transfer de date IP să funcționeze corect.
Numerotarea tipului ICMP
Internet Control Message Protocol (ICMP) conține multe mesaje care sunt identificate prin câmpul „tip”.
| Tip | Nume | Caietul de sarcini |
|---|---|---|
| 0 | Echo Răspuns | |
| 1 | Nealocat | |
| 2 | Nealocat | |
| 3 | Destinație indisponibilă | |
| 4 | stingere sursă (învechit) | |
| 5 | Redirecţiona | |
| 6 | Adresă de gazdă alternativă (învechit) | |
| 7 | Nealocat | |
| 8 | Ecou | |
| 9 | Publicitate la router | |
| 10 | Solicitare router | |
| 11 | Timp depășit | |
| 12 | Problema parametrilor | |
| 13 | Marca temporală | |
| 14 | Răspuns marcaj temporal | |
| 15 | Solicitare de informații (învechit) | |
| 16 | Răspuns la informații (învechit) | |
| 17 | Solicitare de mască de adresă (învechit) | |
| 18 | Adresă Mască răspuns (învechit) | |
| 19 | Rezervat (pentru securitate) | Solo |
| 20-29 | Rezervat (pentru experimentul de robustețe) | ZSu |
| 30 | Traceroute (învechit) | |
| 31 | Eroare de conversie a datagramei (învechit) | |
| 32 | Redirecționare gazdă mobilă (învechit) | David_Johnson |
| 33 | IPv6 Unde ești (învechit) | |
| 34 | IPv6 Sunt aici (învechit) | |
| 35 | Solicitare de înregistrare mobilă (învechit) | |
| 36 | Răspuns de înregistrare mobil (învechit) | |
| 37 | Solicitare nume de domeniu (învechit) | |
| 38 | Răspuns nume de domeniu (învechit) | |
| 39 | SKIP (învechit) | |
| 40 | Photoris | |
| 41 | Mesaje ICMP utilizate de protocoale experimentale de mobilitate, cum ar fi Seamoby | |
| 42 | Solicitare Echo extinsă | |
| 43 | Răspuns Echo extins | |
| 44-252 | Nealocat | |
| 253 | Experimentul 1 în stil RFC3692 | |
| 254 | Experimentul 2 în stil RFC3692 | |
| 255 | Rezervat |
Câteva cuvinte despre limitele de viteză
În timp ce mesajele ICMP precum cele descrise în acest articol pot fi foarte utile, rețineți că generarea tuturor acestor mesaje ocupă timp CPU pe routerele dvs. și generează trafic. Chiar vă așteptați să obțineți 1000 de ping-uri pe secundă prin firewall într-o situație normală? Va fi considerat trafic normal? Probabil că nu. Limită debitului rețele pentru aceste tipuri Trafic ICMP după cum credeți de cuviință; acest pas vă poate ajuta să vă securizați rețeaua.
Citiți, cercetați și înțelegeți
Având în vedere că discutarea subiectului „a bloca sau a nu bloca” pachetele ICMP duce întotdeauna la confuzie, dispute și dezacorduri, vă sugerez să continuați să studiați acest subiect pe cont propriu. Am oferit multe link-uri pe această pagină, cred că pentru o înțelegere mai completă a problemelor, ar trebui să petreceți timp citindu-le. Și faceți alegeri informate cu privire la ceea ce funcționează cel mai bine pentru rețeaua dvs.
MikroTik: unde să dai clic pentru a-l face să funcționeze?
Cu toate avantajele sale, produsele MikroTik au un dezavantaj - sunt foarte deconectate și nu întotdeauna informaţii de încredere despre configurarea ei. Vă recomandăm o sursă de încredere în limba rusă, unde totul este adunat, logic și structurat - curs video „ Configurarea echipamentului MikroTik" Cursul include 162 de lecții video, 45 munca de laborator, întrebări și note de autotest. Toate materialele rămân la tine pe termen nelimitat. Puteți urmări gratuit începutul cursului lăsând o solicitare pe pagina cursului. Autorul cursului este un trainer certificat MikroTik.
Canale ascunse este una dintre metodele de disimulare a acțiunilor sau de a efectua atacuri, care este folosită pentru transferul secret, neautorizat sau ilegal de informații. Cu ajutorul canalelor ascunse, informațiile pot fi scurse sau, dimpotrivă, informațiile pot fi introduse în organizație. Un canal ascuns pe Internet poate fi comparat cu un compartiment secret dintr-o servietă în care un atacator poate încerca să se ascundă documente secrete pentru a le transporta prin intrarea unei instalații sensibile. Pe Internet, canalele ascunse pot fi folosite de atacatori pentru a transmite materiale secrete, rămânând nedetectate - în acest caz, mecanismele de securitate a rețelei acționează ca o poartă de securitate. Așa cum un spion ar putea ascunde o armă în același compartiment secret pentru a o ascunde de securitate și pătrundeîmpreună cu acesta către instalație, pe Internet, atacatorii pot folosi canale ascunse pentru a transfera în secret arme cibernetice, de exemplu, pentru a descărca într-un nod din rețea privată organizarea de programe malware de pe un server extern.
Înțelegerea canalelor secrete de pe Internet
Canalele ascunse de pe Internet se pot baza pe utilizarea neconvențională a protocoalelor de Internet familiare. Punctele finale ale unui canal separat - computerul infectat și centrul de comandă al atacatorilor - trebuie să utilizeze software special capabil să recunoască și să proceseze astfel de tehnici neconvenționale pentru a ataca sau a ascunde acțiuni. Un astfel de software poate fi instalat de către utilizator însuși sau de către software rău intenționat, sau de către atacatori care folosesc instrumente administrare la distanță(ŞOBOLAN). Canalele secrete de internet sunt diferite de tunelurile criptate. Informațiile prin intermediul lor pot fi transmise necriptate (acest lucru se întâmplă adesea), dar aceste canale în sine sunt ascunse de străini. Nu este nevoie să folosiți chei de criptare sau criptografice în acest caz, dar uneori canalele ascunse folosesc în continuare diverse metode de criptare sau de ofucare a datelor.
Să ne uităm la două exemple. Prima tehnică este transferul ascuns de informații, câte un caracter, în câmpul de identificare (ID) al antetului pachetului de protocol Internet (IP). În implementările comune ale acestei tehnici, codurile ASCII ale caracterelor sunt înmulțite cu 256 pentru a crea valori de 16 biți care sunt înlocuite în câmpul de identificare. Pentru a transmite acronimul ICANN, ar fi necesar să se transmită 5 pachete IP cu următoarele valori ale câmpului de identificare:
| Pungă de plastic | Valoare ASCII zecimală | ID pachet IP (x256) |
| 1 | 71 ("I") | 18176 |
| 2 | 67 ("C") | 17152 |
| 3 | 65 ("A") | 16640 |
| 4 | 78 ("N") | 19968 |
| 5 | 78 ("N") | 19968 |
Calculatorul receptor decriptează valoarea câmpului ID pachet IP împărțind valoarea rezultată la 256. Transmiterea unor astfel de valori nu ridică nicio suspiciune și, deoarece protocolul IP permite transmiterea de pachete duplicate, probabilitatea unui astfel de traficul detectat este scăzut. Viteza redusă este compensată de furtivitatea transmisiei.
A doua tehnică pentru crearea unui canal secret implică utilizarea încărcăturii utile de protocol, adică informatii tehnice transmis în cadrul protocolului selectat. În acest caz, datele sunt adăugate la solicitările ECHO și răspunsurile la acestea - acestea sunt mesaje de serviciu care sunt utilizate în protocol de internet Control Message Protocol sau ICMP. Mesajele ECHO sunt utilizate într-un serviciu comun ping . Administratorii de rețea folosiți adesea serviciul ping pentru a verifica dacă o anumită gazdă la distanță este accesibilă, astfel încât traficul de pachete ICMP ECHO este de obicei permis prin instrumente de securitate a rețelei, cum ar fi firewall-urile.
Dacă sunteți interesat să aflați mai multe despre aceste tehnici, consultați următoarele articole: Întrebări și răspunsuri privind canalele secrete și Canalele secrete prin ICMP (PDF, 740 KB).
Următorul. Canale secrete DNS
Protocolul Domain Name System (DNS) are o serie de caracteristici care fac convenabil utilizarea canalelor ascunse. Traficul DNS este permis prin firewall-uri în ambele direcții. Pericolele utilizării DNS pentru a crea canale ascunse sunt adesea trecute cu vederea sau subestimate, motiv pentru care organizațiile sau furnizorii de servicii de internet nu verifică întotdeauna traficul DNS pentru semne de atacuri. Uneori, traficul DNS este scurs afară către internet mare, pentru a rezolva numele înainte ca funcțiile de autorizare sau de autentificare a utilizatorului să fie efectuate, permițând ca canalele secrete DNS să fie folosite pentru a ocoli astfel de controale de acces.
În următoarea noastră postare, vom aborda modul în care canalele secrete DNS pot fi folosite pentru a extrage date, a ocoli controalele de acces sau a descărca programe malware.
Acest scurt articol vă va arăta cum, cu câteva computere, câteva instrumente distractive și sistem de operare obţine acces wireless pe internet ori de câte ori este posibil. Am descris partea tehnică destul de clar și am oferit comentarii.
1. Introducere.
Tocmai mi-am luat primul laptop și am vrut să încerc să fac ceva obraznic cu el (am încercat chiar să lucrez, dar a fost prea obositor
:)). Wardriving a fost o activitate destul de distractivă la început, dar m-am plictisit puțin când mi-am dat seama că rețelele protejate
WEP este prea dur pentru mine (din moment ce nu a existat trafic intranet - rețelele puteau fi considerate moarte), iar rețelele neprotejate nu prezintă deloc interes. Din fericire, rețeaua wireless din campusul meu a fost puțin mai interesantă.
Rețeaua oferă gratuit internet wireless, dar necesită înregistrarea adresei dvs. MAC în numele dvs. înainte de a permite accesul - utilizatorii neînregistrați sunt redirecționați către pagina furnizorului (pagina de înregistrare). Înregistrarea ar fi implicat o conversație de două minute cu administratorul, dar m-am gândit: „Poate
o modalitate de a obține acces fără o astfel de comunicare? Bineînțeles că era.
2. Prima metodă de penetrare este falsificarea MAC.
Deoarece totul se învârtea în jurul adresei MAC, primul lucru care mi-a venit în minte a fost
a fost să aflu adresa MAC deja înregistrată și să o rezolv
falsificarea. Desigur, este ușor să vorbești, dar nu a necesitat aproape nici un efort, chiar și având în vedere că nu am mai făcut asta până acum.
Primul lucru pe care l-am făcut a fost să alerg kismet ("kismet -c orinoco,eth1,wifi") și să adulmec plasa. Kismet salvează tot ce ați descărcat
informații într-un fișier ("/var/log/kismet/*.dump" în cazul meu), rezultatele sniffing-ului pot fi vizualizate așa cum sunt
chitanțe. Ca urmare, am putut vedea toate informațiile și
notează adresa MAC corespunzătoare.
Comenzi folosite pentru a schimba adresa MAC a unei plăci de rețea:
ifconfig eth1 jos
ucide dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 sus
dhclient eth1
Nu toate comenzile sunt necesare, dar sunt foarte utile atunci când încercați să schimbați mai multe adrese MAC una după alta, ceea ce
Mi-a fost doar util, pentru că... Adresa MAC pe care am încercat să o schimb nu a funcționat imediat. Am fost interzis, rețeaua s-a oprit și nu s-a mai pornit, făcându-mă să fac față unor erori ușor enervante
în sistemul dumneavoastră. Poate aceste probleme
a apărut din cauza firmware-ului cu erori sau poate pentru că exista deja un placa de retea cu aceeași adresă MAC.
Nu toate stațiile de lucru erau active și utilizarea kismet pentru a vedea rezultatele pe măsură ce au venit a fost ineficientă, așa că am încercat o altă metodă.
În rețea, filtrarea după adresa MAC a fost efectuată destul de mult nivel înalt. Pot accesa rețeaua oricând, pentru că... Când am încercat să mă înscriu, am fost dus la o pagină care mi-a cerut să mă înregistrez.
Desigur, în timp ce mă gândeam la gazdele active, mi-a venit în minte nmap. Așa că am început să verific intervalul IP pentru stațiile active.
marktwain:~# nmap -sP 10.0.0.1/22
Începând cu nmap 3.81 (http://www.insecure.org/nmap/) la 2005-05-23 12:54 EEST
Gazda 10.1.0.14 pare să fie activată.
Adresă MAC: 00:0E:35:97:8C:A7 (Intel)
Gazda 10.1.0.95 pare să fie activată.
Gazda 10.1.0.109 pare să fie activată.
Adresa MAC: 00:0D:54:A0:81:39 (3Com Europa)
...croitor...
Gazda 10.1.2.92 pare să fie activată.
Adresă MAC: 00:02:2D:4D:1C:CE (Agere Systems)
Gazda 10.1.2.187 pare să fie activată.
Adresa MAC: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap terminat: 1024 de adrese IP (20 de gazde în sus) scanate în 53.980 de secunde
O grămadă de adrese MAC. Cele mai multe
Tabelul de adrese rezultat (după cum presupun) este adresele MAC ale mașinilor care au vizitat rețeaua în ultimele zile. Au fost 245 de MAS diferite în tabel
adrese. Nu știu dacă acesta este un comportament normal pentru
puncte de acces, dar cred că băieții au nevoie de ceva
schimbarea distribuției pe Internet. Oricum, acum am destule adrese MAC ale mașinilor care au vizitat rețeaua, dar cel mai probabil au plecat cu mult timp în urmă. Câteva încercări de falsificare și mă îndreptam deja către neworder.box.sk...
3. Încercarea numărul 2 - Tunnel ICMP.
Am realizat tot ce mi-am dorit, dar mai era loc de săpat în această rețea. Dar ce
Aș putea să o fac dacă această rețea nu ar avea
nu ar avea o singură mașină care să-mi aparțină? Dacă
Nmap nu s-ar deschide și nu ar afișa toate aceste adrese MAC? Deci, oricum, am decis să încerc un alt mod de a obține acces.
Acest lucru nu a fost menționat anterior, dar ocolește sistemul
Distribuția pe Internet dând permisiunea și DHCP, rețeaua a permis mesajelor ICMP să treacă liber. Verificarea activității oricărui site de internet a funcționat perfect (chiar nu înțeleg de ce nu l-au blocat - dacă nu au uitat), ping
a fost detectat chiar și pe sniffer-ul care rula pe serverul meu.
Planul meu a fost să încerc să creez un tunel între laptopul meu de la universitate și serverul de acasă. Și treceți toate conexiunile prin el.
Am căutat aplicații de tunel ICMP pe Internet, dar niciuna nu a funcționat așa cum mi-am dorit (și anume, am vrut să fie simplu - astfel încât dacă aș rula browserul meu preferat sau orice alt program, ar funcționa doar cu tunnel) sau cel puțin
părea digerabil.
4. Puțină codare.
La început nu am plănuit să codific nimic. Tocmai am încercat câteva aplicații de tunel ICMP
cu packetstorm, dar deodată m-am trezit citind codul sursă al unuia dintre ei și realizând cât de uimitor de simplu este și cât de ușor ar fi să fac așa ceva. Nume program - itunnel -
Un utilitar comun pentru tunelul ICMP. Itunnel este minunat. Dar este doar un tunel. Îl rulezi pe o singură mașină și, în cele din urmă, se pare că ai conectat două
plăcile de rețea împreună. Nu a fost suficient pentru ceea ce am vrut să fac.
Am auzit deja despre modulul kernel TUN/TAP, care permite proceselor utilizatorului să primească și să trimită pachete de informații direct către/de la kernel.
Programul creează o interfață de rețea virtuală.
Acesta creează o interfață de rețea care
functioneaza exact la fel
standard Cel mai interesant lucru este că
programele utilizator trebuie
acționează ca un strat fizic pentru interfață
tunel. Ei trebuie să citească pachete de informații din
dispozitiv (de exemplu, „/dev/net/tun0”) și transmiteți-le prin orice mijloace și scrieți pachete de răspuns
înapoi la dosar.
Nu am găsit nicio resursă bună
de TUN/TAP, dar există un program - vtun - care a folosit TUN/TAP pentru tunelurile sale, așa că am
Am folosit surse vtun. După câteva cercetări, s-a dovedit că există o bibliotecă mică de funcții folosite pentru a crea, a citi și a scrie în tun*
dispozitive. De ce ar trebui să scriu eu un program dacă o pot face reparând câțiva biți?
Codul pe care l-am scris de fapt:
#include „driver.h” /* declara biblioteca vtun */
#include
#include
/* ușor modificat main() din itunnel
*/
int run_icmp_tunnel (int id, int packetsize, char *desthost, int tun_fd);
/* unitate maximă – maximă
dimensiunea pachetului încapsulat
*/
const int mtu = 1400;
int main(int argc, char **argv) (
char *dev;
int tun_fd = 0;
/* crearea unui dispozitiv tunel */
dev = (char *) malloc(16);
dacă (dev == NULL) (
printf("daca nu ati avut niciodata probleme cu
alocarea a 16 octeți\"
„memoria este prima dată. Fatal.n”);
întoarcere 1;
}
dev = 0;
/*
funcție de bibliotecă frumoasă
de la vtun acceptă șirul gol ca*
*
argument, creează un dispozitiv tunX și
îl transmite la *dev */
tun_fd = tun_open(dev);
dacă (tun_fd< 1) {
printf("Nu se poate crea dispozitivul. Fatal.n");
întoarcere 1;
}
altfel(
printf("Dispozitiv de tunel creat: %sn", dev);
}
/* 7530 este câmpul ID ICMP,
folosit pentru pachetele din tunel
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);
tun_close(tun_fd, dev);
}
Iată-l. Și cea mai mare parte sunt comentarii și verificarea erorilor
După cum am menționat deja, itunnel este ideal pentru construcția de tuneluri. Are o funcție principală care este
fișiere deschise pentru intrare, ieșire și socket; Asemenea
Am primit niște parametri pentru linia de comandă (care ar putea fi utile pentru scopurile mele). Apoi, a numit o funcție ușor abstractă care, în esență, doar transporta pachete de informații. Antet ICMP gratuit
este descris în cod și poate fi schimbat cu ușurință în orice alt antet,
intrare/ieșire/soclu poate fi configurat în funcție de alt circuit logic - funcția va funcționa cu ajustări minime.
Cea mai mare schimbare pe care am făcut-o a fost eliminarea tuturor manipulărilor linie de comandă– în esență eliminarea mai multor blocuri de cod. Cel mai important pentru logica tunelului, am eliminat distincția dintre intrare și ieșire, deoarece sunt ambele
agățați de același descriptor (dispozitiv tunX) –
mi-a dat asta în loc să mă comport ca
netcat și trimite stdin la soclul ICMP și soclul ICMP la stdout,
trimite semnal de ieșire către dispozitivul tunX (cum ar fi solicitările http din browser) către ICMP
socket și ieșire socket ICMP (ca și cum HTTP
cererile de la server au fost trimise înapoi
prin tunel) la dispozitivul tunX (la
va reveni înapoi la browser). Deoarece ultima propoziție este foarte lungă și complicată, vă ofer o mică diagramă pentru a ilustra:
Pachetele de răspuns de informații urmează aceeași cale, dar
în sens invers.
La un moment dat deja am luat-o razna si chiar am scris linie nouă cod. Arata cam asa:
memcpy(&(target->sin_addr.s_addr), &(from.sin_addr.s_addr), 4);
Funcția sa este de a începe să trimită toate pachetele de informații la locul unde a sosit ultimul pachet. pot
rulează-l pe serverul meu și conectează-te
de oriunde trimite un pachet prin tunel
și schimbă instantaneu IP-ul destinatarului în IP
laptopul meu.
Puteți lua rezultatul de aici:
5. Instalarea tunelurilor.
Am testat tunelul acasă și a funcționat bine, dar nu exista firewall acasă. A doua zi la universitate eram gata să-l testez viata reala. Din întâmplare, în timp ce stăteam la o masă într-o cafenea, am găsit o adresă MAC folosind spoofing și am stabilit un tunel.
Mi-e greu să-mi amintesc toate trucurile stupide pe care le-am încercat și micile experimente pe care le-am făcut, așa că am încercat să fac această parte cât mai organizată. De fapt, nu am făcut totul atât de clar.
Pentru a face totul să funcționeze pentru mine
A durat 3 ore și am încercat tot ce am putut în timp ce am adulmecat peste tot și am modificat codul, astfel încât să scaneze „Pachet atunci când a primit un pachet de informații și ceva enervant când și-a trimis propriul pachet!”. Și așa mai departe.
Am rulat aceste comenzi pe server:
tsee-diees:~# ./create_tun wifi.ttu.ee
Dispozitiv tunel creat: tun0
S-a oprit ./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"
M-am gândit că va funcționa imediat și am rulat asta pe laptopul meu:
marktwain:~# ./create_tun 194.204.48.52
Dispozitiv tunel creat: tun0
Oprit ./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"
Ceea ce trebuia să fac era să creez
rețea cu două gazde pe ea - un server ca 192.168.3.1 și un laptop ca 192.168.3.2. Un simplu LAN normal, doar stratul său fizic va fi un tunel ICMP. Ca și tu, probabil
înțeles din textul rămas din articol
metoda nu prea a funcționat. Am început să pun ping ("ping 192.168.3.1"), dar pachetele încă nu ajungeau.
Din fericire, snifferul de pe laptop mi-a dat un mic indiciu - pachetele ICMP erau răspunsuri returnate. Bineînțeles că nu
plecau. Deci omorâm tunelul, activăm itunnel pe laptop și folosim răspunsurile de returnare icmp (schimbam „icmp->type = 0;” în „icmp->type = 8;”), returnăm tunelul.
Sistemul tot nu a funcționat, dar de data aceasta pachetele
a apărut pe sniffer-ul de pe server.
Ce ar putea fi în neregulă? Am încercat o modificare care trebuia să strige „Pachet!” când a sosit următorul pachet, dar exclamațiile nu au făcut-o
a apărut. „De ce, de fapt”, m-am întrebat, „dacă firewall-ul este instalat, ar trebui să blocheze toate pachetele ICMP de pe Internet?” După ceva timp, mi-am dat seama că acesta a fost de fapt cazul (toate pachetele ICMP de pe Internet au fost blocate).
Deja mai bine. Tunelul exclamă „Pachet!” , iar răspunsurile pot fi văzute pe sniffer-ul de pe server. De fapt, există două răspunsuri la fiecare cerere, dintre care doar unul poate fi văzut pe snifferul de pe laptop. Și ping-ul încă nu funcționează.
Deoarece unul dintre cele două pachete este redundant, i-am spus nucleului să nu răspundă la postback-urile icmp:
tsee-diees:~# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
Și ping-urile au început să treacă! În acest moment, încă mă bazam pe adresa MAC falsificată pentru a avea acces la server. Deoarece ideea a fost de a obține pachete care călătoresc în ambele direcții de la un utilizator neînregistrat, am încetat să falsific adresele MAC. În același timp, tunelul a continuat să funcționeze, ceea ce a fost o surpriză destul de plăcută.
Fluxul de pachete a fost stabilit și era timpul să facă „Internetul” să funcționeze.
Este necesar să se facă unele modificări la IP
rutare pe un laptop. Drum prin
routerul wireless al universității a trebuit înlocuit cu adresa de tunel a serverului (192.168.3.1 în acest caz). Mai trebuie să existe o cale către server, astfel încât tunelul în sine să poată funcționa (pachetele de tunel ICMP au nevoie și de o cale de urmat).
Am obtinut niste rezultate bune:
marktwain:~# route add 194.204.48.52 gw 10.0.0.111 # prin routerul wireless
marktwain:~# route del default
marktwain:~# route add default gw 192.168.3.1 # orice altceva prin tunel.
Și din moment ce sunt oarecum deștept, m-am gândit că ar putea exista o nepotrivire între
numărul de pachete trimise către și de la server. Am început să pun ping
în fundal pentru a urmări situația:.
marktwain:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) octeți de date.
Desigur, nu au existat răspunsuri, deoarece acestea nu au fost „ping-uri de tunel”, iar răspunsurile din nucleu au fost
oprit.
Din moment ce serverul meu era deja antrenat
partajez conexiunea la Internet între mai multe computere, tot ce trebuia să fac pe server era să adaug două reguli pentru
Lanț FORWARD în iptables pentru a accepta pachete de la și către tun0. Când am verificat în mod obișnuit regulile actuale ("iptables -vL FORWARD"), conexiunea a încetat brusc. M-am reconectat și am cercetat această problemă,
dar în curând legătura a murit din nou. Am fost cu adevărat surprins - de ce este conexiunea atât de instabilă?
După ce m-am gândit, mi-am dat seama că de fiecare dată serverul trimitea un răspuns ICMP mare
(la urma urmei, doar antetul ping era 1400+), a fost respins
echipamentul în sine. Din moment ce tunelul era fizic
la nivel de IP, TCP a încercat în mod natural să trimită pachetele din nou, dar dimensiunea a fost încă aceeași și au fost încă aruncate. Așa că am schimbat MTU pentru tunel la 300 (in
în general vorbind întâmplător)
marktwain:~# ifconfig tun0 mtu 300
tsee-diees:~# ifconfig tun0 mtu 300
Și întregul sistem a funcționat.
6. Concluzie.
Acum fă-o singur.