IPRO - PC Magazine Romania, Mai 2004
SOLUŢII PENTRU PROGRAMATORII ŞI DESIGNERII WEB

Securitatea Reţelei [8]

Maestrul deghizărilor: Imitarea IP

Alexandru Ioan Lazăr

În urmă cu foarte multe numere (de fapt, în primul număr al acestui serial), am adus vorba despre Kevin Mitnick şi, mai ales, despre cadoul de Crăciun pe care i l-a trimis lui Tsutomu Shimomura. Reţeaua specialistului japonez fusese spartă printr-o metodă complexă, numită IP spoofing (imitare IP).

Mitnick s-a folosit de un element caracteristic reţelor atacabile prin imitare IP: reţeaua era atât de mare, încât era fizic imposibil pentru un administrator să se descurce altfel decât folosind rlogin/rsh (imaginează-ţi cum e să treci pe la fiecare din cele trei sute de calculatoare, căutându-l pe cel cu IP-ul care face probleme).

Trusssst in me, jusssssst in me…

Relaţia de încredere dintre două staţii înseamnă că una din ele poate permite conexiunea de la cealaltă staţie fără a cere autentificarea prin parolă - deşi, în mod normal, ar trebui să o ceară. Nu ştii să fi setat asta pe maşina ta? Gândeşte-te din nou! Multe sisteme au încredere, implicit, cam în toată lumea☺. Există (cel puţin sub Linux) câteva moduri în care relaţiile de încredere pot să apară: fişierele .rhosts şi hosts.equiv, prin NFS (Network File System), servere X cu portul 6000 deschis şi aşa mai departe. Iar cineva poate afla maşinile cu relaţii de încredere prin rularea unor comenzi simple (shoumount -e, de exemplu, va arăta unde sunt exportate fişierele NFS).

Dintre ele, aproape toate se datorează faptului că nu există nici o metodă de a verifica, de exemplu dacă adresa IP este categoric corespunzătoare numelui asociat ei. Nu e clar acum? Hai să vedem exact cum are loc o spargere prin imitare IP.

Balada balului mascat…

Mai ştiţi că spuneam despre finger că este unul dintre cele mai periculoase instrumente de securitate? Folosind interogări finger, un cracker poate afla maşina de la care se loghează administratorul (contul root, în mod normal). De obicei, aceasta este atât de bine protejată, încât este foarte greu să fie spartă. În schimb, este foarte posibil ca ea să fie în relaţii de încredere cu alte maşini din reţea.

De aceea, cracker-ul va încerca să găsească o metodă de a "păcăli" celelalte staţii. Va trebui să le convingă că pachetele care sosesc sunt de la el, de fapt, de la acea maşină de unde se tot loghează administatorul. Cu alte cuvinte, va trebui să modifice baza de date cu numele asociate IP-urilor din reţea, astfel încât să modifice numele asociat IP-ului maşinii "imitate" în numele maşinii sale. Vei fi surprins să afli câte programe pot fi păcălite în acest fel. Versiunile Red Hat mai vechi nici nu au bănuit tehnica atunci când am încercat-o pe reţeaua mea.

Această metodă funcţionează însă numai în cazul unui software prost configurat. De multe ori verificarea nu se face pe bază de nume, ci pe bază de adresă IP. Atunci e mai complicat…

Cracker-ul va face, în mare, aceleaşi operaţiuni ca cele de mai sus. Numai că în loc să păcălească ţinta prin schimbarea numelui maşinii sale, el va imita IP-ul unei maşini în care ţinta are încredere.

Există o mare problemă în cazul reţelelor Ethernet: nu pot exista două maşini cu aceeaşi adresă! Prin urmare, el trebuie să scoată din uz maşina administratorului. Mai ţii minte atacurile DoS? Atacul syn_flooding va forţa acea maşină să se oprească.

În cele maxim câteva minute cât durează resetarea maşinii imitate, el trebuie să găsească o metodă de a falsifica pachetele trimise. Din păcate, deşi este una din cele mai interesante elemente ale spargerii de sisteme, spaţiul nu-mi permite să detaliez această falsificare (poate într-un articol viitor voi explica mai pe larg). Pot să spun însă că se bazează pe interceptarea anumitor pachete TCP şi citirea unor informaţii numite TCP Sequence numbers, care se folosesc apoi la trimiterea propriilor pachete. De fapt, cracker-ul nu îşi schimbă nici un moment IP-ul, doar pachetele pretind că vin din altă parte.

Uite un exemplu (aşa am testat tehnicile din acest articol). Priveşte figura de mai jos.

Printr-o serie de interogări host şi traceroute am ajuns la concluzia că topologia reţelei trebuie să fie cam aşa: router—-192.168.141.19—-192.168.141.18—-192.168.141.17 (m-am înşelat doar în privinţa poziţiei lui .19 şi .17, de fapt erau invers). Am ales să "dau jos" pe .19 (rulează beOS, un sistem în care nu am lucrat atât de mult, şi deci nu risc) şi să-i imit IP-ul. Pentru atacul DoS, deşi aş fi vrut să folosesc o metodă mai puţin consumatoare de trafic, a trebuit să recurg la un atac syn_flooding, pentru că experienţa mea cu beOS nu m-a ajutat deloc. Aşa că nu prea mi-am acoperit urmele. Apoi am "falsificat" pachetele, şi am reuşit să obţin acces la consola lui .18.

Ce grad de control asupra ţintei oferă imitarea IP? Asta depinde de serviciile care folosesc relaţii de încredere. De obicei, va permite accesul prin rlogin/rsh, poate chiar ca root! În orice caz însă, un atac prin imitare IP va fi lansat cu succes împotriva unei maşini cu software modern şi configurat corect doar de un hacker foarte experimentat. De aceea, fie şi obţinerea unui acces cu multe constrângeri poate însemna compromiterea reţelei tale.

La porţile Orientului

Din proprie experienţă îţi spun, o reţea mare se poate transforma foarte uşor într-un haos foarte… oriental☺. Ideea este ca, pentru maximă protecţie, să ai unele setări comune tuturor staţiilor din reţeaua ta. Renunţă la relaţiile de încredere, cere un nume de utilizator şi o parolă indiferent de serviciu. Directoarele partajate în reţea pot fi o sursă foarte serioasă de "găuri", motiv pentru care e o idee bună să consulţi documentele de securitate referitoare la ele (dacă mai ţii minte, vorbisem odată de un sit, astalavista.com). Dacă ţii neapărat la relaţiile de încredere, nu le stabili cu staţii rulând alte sisteme decât UNIX (vei vedea imediat de ce).

Firewall-urile pot oferi o oarecare protecţie, dar nu te aştepta să facă minuni (deşi am găsit o formă curioasă de "magie": în timp ce am scris articolul, am încercat tehnicile detaliate. Iniţial, am configurat o maşină-firewall cu Slackware 8.1, folosind iptables, şi atacul mi-a reuşit. Am repetat "figura" a doua zi, dar în loc de Slackware am folosit Red Hat 9, şi din motive care îmi sunt total străine atacul meu a eşuat. Am repetat încercarea cu Fedora Core I, şi a mers - apoi din nou cu RH9, dar am "schimbat" un pic tehnica - şi atacul a reuşit).

Diagnosticarea sau "Cânticlu a cucuveaulei"

La final, vreau să vorbesc un pic despre diagnosticarea unui atac prin imitare IP. "Cucuveaua" care prezice un atac prin imitare IP este lansarea unui număr mare de conexiuni finger, traceroute, host şi shoumount. Folosind rezultatele furnizate de aceste comenzi, se pot face prezumţii referitoare la topologia reţelei tale.

La prima vedere, poate fi greu să diagnostichezi un atac prim imitare IP. Cum să fii sigur că ai fost atacat în felul acesta, dacă nu lasă urme în fişierul-jurnal? Greşit! Urma cea mai evidentă este maşina scoasă din uz prin DoS.

Iată ce-mi place mie la Linux: spre deosebire de alte sisteme, logarea se face atent şi, mai ales, după fiecare restartarea nu tocmai ortodoxă, logarea activităţilor legate de restaurarea sistemului de fişiere ext3 (sistem "journaling") este consemnată.

Dacă ajungi dimineaţa la serviciu şi găseşti o maşină care îţi prezintă amabil ecranul cu login şi, după logare, observi că peste noapte a avut loc o restartarea "neortodoxă", în timp traficul în acel segment de reţea a fost anormal de mare, ghici ce concluzie se poate trage… Reţine, atacurile DoS sunt aproape întotdeauna caracterizate de traficul foarte mare. Dacă nu, examinarea unor fişiere-jurnal te poate aduce imediat la concluzia că a avut loc un atac DoS (am putut diagnostica asemenea atacuri DoS prin sendmail pe Slackware 8.1 instalat şi folosind configuraţia implicită. Setări corecte pot să te facă să ghiceşti un atac DoS fără prea mare bătaie de cap).

Dezactivează serviciile r - rlogin şi rsh, pentru că sunt principalele "găuri" legate de atacurile prin IP spoofing. Şi, cel mai important, să reduci la maximum numărul informaţiilor despre topologia reţelei care pot fi obţinute.

OK. Cam atât pentru acest număr, până data viitoare când vom încheia serialul cu analiza unui sistem spart. Până atunci, aştept mesajele tale pe [email protected]. Mult noroc!