Laborator 3
Tematica laboratorului
- Scurta recapitulare legata de functionarea protocoalelor de transport
- Exemple de atacuri asupra TCP bazate pe ICMP
Scurta recapitulare legata de functionarea protocoalelor de transport
TCP - Transmission Control Protocol
TCP (RFC 793) este un protocol de transport orientat conexiune ce asigura transmiterea sigura si in ordine a datelor, utilizat de majoritatea protocoalelor de nivel aplicatie ce necesita aceste facilitati si alte servicii precum controlul fluxului, controlul congestiei, etc (exemple de protocoale de nivel aplicatie: HTTP, FTP, POP, IMAP, etc). Functionarea protocolului TCP este formalizata prin intermediul unui automat specificat dupa cum urmeaza in cadrul standardului:
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
si care poate de asemeni fi vizualizat la urmatoarea adresa:
Automat TCP
Reproducem mai jos si structura unui header TCP (data si in cadrul laboratorului anterior) pentru o mai mare claritate a explicatiilor ce urmeaza:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initierea unei conexiuni TCP este realizata in trei pasi (three way handshake) dupa cum urmeaza:
A ----- SYN ----> B A <---SYN/ACK---- B A ----- ACK ----> B
In primul pas, A - initiatorul conexiunii (clientul) va trimite un pachet TCP ce va include un numar de secventa ales aleator ce va avea bitul SYN setat. Pasul al doilea consta in raspunsul lui B (serverul) ce va trimite catre A un pachet ce include ca numar de confirmare numarul de secventa primit incrementat cu 1, si ca numar de secventa propriu de asemeni un numar ales aleator. In ultimul pas A va trimite ca numar de confirmare catre B, similar pasului 2, numarul de secventa primit incrementat cu 1. Bitul ACK va fi setat intotdeauna pe durata conexiunii stabilite in pachetele ce au rol de confirmare. Cu exceptia precizarilor facute pentru acesti pasi, numarul de secventa in cadrul comunicatiei ce urmeaza va contine valoarea cumulata de la primul numar de secventa a numarului de octeti transmisi, iar numarul de confirmare va contine in mod normal ca valoare numarul de secventa ce se asteapta la urmatorul mesaj din partea opusa (care practic confirma numarul de octeti primiti cu succes de la ultimul numar de secventa).
Cea mai sintetica descriere pentru campul "Window" ar fi valoarea utilizata de TCP in controlul fluxului. Numarul respectiv impune o limita asupra numarului de octeti transmis in retea fara a primi confirmare din partea destinatiei. Stabilirea acestui numar tine de o metoda asa numita "a ferestrei glisante". Aceasta metoda este bazata in principal pe variatia a doua valori: dimensiunea ferestrei exprimata de destinatie si dimensiunea asa numitei ferestre de congestie. Dimensiunea ferestrei exprimata de catre destinatie, in pachetele de confirmare, exprima dimensiunea maxima a bufferului setat pentru primirea datelor de catre destinatie (si practic limita superioara a fluxului de octeti ce poate fi trimis de sursa fara a astepta confirmarea). Fereastra de congestie se constituie intr-un mecanism intern TCP ce mentine o limita prin care este controlat numarul de octeti transmis de un punct de comunicatie prezent in flux in cadrul retelei la un anumit moment dat. Pe baza acestui mecanism, in esenta fiind bazat pe pierderile de date, dimensiunea maxima a datelor transmise fara confirmare poate fi redusa pentru evitarea congestiei.
Atacurile asupra TCP sunt focalizate pe mai multe directii. In particular insa, datorita caracterului orientat conexiune, exista atacuri ce se focalizeaza efectiv asupra acestui aspect, cum ar fi deturnarea conexiunii, resetarea conexiunii, etc.
O prezentare mai detaliata a protocolului TCP e disponibila aici.
UDP - User Datagram Protocol
UDP (RFC 768) este un protocol de transport neorientat conexiune ce nu confera siguranta transmiterii datelor. Este un protocol ce e utilizat in special de protocoale de nivel aplicatie ce sunt sensibile la nivel de factor temporal in ceea ce priveste transmisia datelor, intarzierile nefiind permise, iar pierderile neavand un impact major. Una din principalele categorii de astfel de protocoale o constituie transmisiile media - VoIP si IPTV. Una din caracteristicile specifice UDP (care e de altfel intalnita si in astfel de scenarii de streaming media) e constituita de posibilitatea de broadcast si multicast (trimitere catre un anumit grup de utilizatori format pe baza de adeziune la o adresa comuna de grup) la nivel de protocol de transport. O categorie de atacuri ce e predominant intalnita in cazul transmisiilor neorientate conexiune consta in atacurile de interceptie a traficului, iar in particular, pentru cazurile de protocoale aplicatie ce privesc transmisiile media - exista o serie specifica de mecanisme de protectie a traficului focalizate pe mentinerea unui factor de timp si a unui overhead (latime de banda neocupata de streamul efectiv) rezonabile in ceea ce priveste transmiterea datelor.
Exemple de atacuri asupra TCP bazate pe ICMP
ICMP reprezinta un protocol de control utilizat in mare parte pentru diagnosticare si raportare a erorilor aparute in functionarea IP.
In anumite cazuri pentru conexiuni TCP, implementarea TCP va lua de asemeni decizii in cazul aparitiei de erori la nivelul IP.
Fiecare pachet ICMP cauzat de o eroare/conditie in traficul pe retea include in partea de date:
- headerul IP al pachetului ce a generat eroarea
- 64 de biti din portiunea de payload/date a pachetului ce a generat eroarea
(aceasta structura nu se aplica in cazul in care e vorba de un pachet ICMP trimis la cerere cum ar fi de exemplu "Echo Request" la ping).
In cazul unei erori generate de TCP cei 64 de biti vor contine porturile sursa si destinatie si numarul de secventa din pachetul ce a generat eroarea.
Pe langa aceste informatii pachetul ICMP va contine si headerul IP deci si adresa IP sursa si destinatie.
Pe baza acestui 4-uplu: (IP sursa, IP destinatie, port sursa, port destinatie) o implementare a TCP poate determina la primirea unui pachet ICMP carei conexiuni ii corespunde eroarea primita si asupra careia va lua anumite masuri in consecinta.
Standardizarea TCP nu specifica insa nici o conditie de validare a in afara de cea implicita de identificare a conexiunii pentru un pachet ICMP.
Acest fapt poate fi exploatat in atacuri ce se bazeaza pe falsificarea de pachete ICMP, pentru a afecta o anume conexiune.
Un astfel de atac este posibil in special pentru un atacator ce are acces la mediul de retea, deci poate intercepta pachete din respectiva conexiune pentru a obtine datele din 4-uplul mentionat mai sus, dar de asemeni e realizabil si in mod "orb" de un atacator din afara retelei ce cunoaste doar partial respectivele date.
De obicei sunt considerate cunoscute cele doua adrese IP, si portul serverului, multe din serviciile TCP folosind un asa numit port well-known standard, portul asociat clientului fiind de regula ales aleator.
Astfel atacatorul ar avea de incercat un maxim de 65535 de valori pentru portul clientului ca sa formeze un 4-uplu ce identifica o conexiune, numar de valori ce in mod normal este mai mic, din el fiind scazute porturile well-known rezervate pentru servicii, si aplicate eventual diverse alte filtrari.
O idee de protectie ar fi autentificarea pachetului ICMP primit pe baza utilizarii unei solutii dedicate ca IPSec. Aceasta ar presupune insa asocieri pentru realizarea respectivei autentificari cu fiecare hop, deoarece pachetul ICMP nu e obligatoriu generat de o eroare la destinatie ci poate fi cauzat si de o problema pe parcursul rutei. Cum hopurile dintr-o ruta se pot modifica dinamic, aceasta solutie nu e in general una acceptabila.
O alta masura generala de combatere consta in verificarea numarului de secventa, reprodus in cei 64 de biti inclusi in pachetul ICMP. Daca acest numar de secventa nu se afla in intervalul dat de ultimul numar de secventa trimis si de numarul de confirmare asteptat (adica mesajul ICMP nu a fost generat pe baza unui pachet TCP inca neconfirmat), pachetul ICMP este ignorat. Probabilitatea ca un atacator sa ghiceasca un astfel de numar de secventa este asadar la nr-de-pachete-neconfirmate/2^32, reducand semnificativ posibilitatile unui atac de forta bruta, unde ar fi necesara spre exemplu si ghicirea portului clientului.
Resetarea conexiunii - ICMP Connection Reset
Erorile raportate de ICMP sunt clasificate in erori "hard" si "soft" conform RFC 1122. In cazul erorilor "soft", la nivelul transport al protocolului TCP, comportamentul definit de standarde este de a retine aparitia erorii in scop informativ si de a continua conexiunea prin reincercarea transmiterii datelor, pana la primirea confirmarii sau atingerea unei valori de timeout. Daca eroarea raportata e clasificata ca una "hard", conexiunea va fi intrerupta. In cazul raportarilor ICMP de erori "hard" sunt incluse urmatoarele:
- tip 3 "Destination Unreachable" - cod 2 "Protocol Unreachable"
- tip 3 "Destination Unreachable" - cod 3 "Port Unreachable"
- tip 3 "Destination Unreachable" - cod 4 "Fragmentation needed and DF bit set"
Atacul consta evident in falsificarea de pachete ICMP de tipul celor de mai sus, incluzand adresele IP si porturile implicate in conexiunea TCP si trimiterea spre unul din cele doua capete, rezultand in terminarea conexiunii.
Una din modalitatile de protectie cele mai prezente in implementari consta in tratarea erorilor ICMP "hard" ca erori ICMP "soft", in cazul in care acestea survin dupa stabilirea conexiunii (in cadrul automatului TCP starea ESTABLISHED, sau starile ce tin de secventa de inchidere a conexiunii). Rationamentul din spatele acestui mod de tratare este bazat - in special - pe probabilitatea scazuta ca respectivele erori sa apara la destinatie dupa initierea si stabilirea unei conexiuni, iar in ceea ce priveste hopurile intermediare se presupune ca la nivelul rutarii exista suficiente mecanisme pentru restabilirea unei rute alternative spre destinatie.
Ingreunarea traficului - Source Quench
Conform RFC 1122 - Host requirements la primirea unui pachet ICMP Source Quench - tip 4, cod 0, capatul de conexiune trebuie sa scada rata de transmisie a pachetelor. Efectul la nivel TCP are loc in cadrul mecanismului de mentinere a ferestrei de congestie, in rezumat, impactul unui atac bazat pe transmiterea de pachete Source Quench falsificate constand in scaderea ratei de transmisie a victimei. Avand in vedere ca TCP-ul (ca standard in sine printr-o serie de standarde aditionale - RFC 2581) ofera mecanisme proprii de detectie si control a congestiei ce nu depind de notificarea pe baza ICMP Source Quench, majoritatea implementarilor sunt imune la acest atac, prin ignorarea respectivelor pachete ICMP.