Laborator 6

Tematica laboratorului

Denial of service - SYN flood

Un atac de tipul SYN flood consta in trimiterea in mod repetat de pachete SYN (incepere a unei conexiuni) catre un server (pentru un anumit serviciu - deci la un anume port), fara a incheia cei trei pasi necesari stabilirii unei conexiuni. Efectul atacului la nivelul serverului consta in alocarea in mod repetat de resurse pentru respectivele conexiuni initiate, ceea ce duce de la un punct la imposibilitatea de a accepta noi conexiuni, atacatorul obtinand ceea ce este denumit in mod generic DoS - Denial of Service.
Exista doua moduri principale de atac: fie prin lipsa trimiterii ultimului mesaj ACK din cei trei pasi de initiere, fie prin trimiterea pachetului SYN initial falsificat din partea unei alte adrese IP (caz in care evident victima tot nu va primi ca raspuns final ultimul mesaj ACK). A doua metoda este in general cea utilizata deoarece in primul caz o solutionare simpla ar consta in limitarea numarului de conexiuni initiate pentru o anume adresa IP.
Sistemul de operare mentine o coada a initierilor de conexiuni prin pachete SYN, care ajungand la dimensiunea maxima cauzeaza un efect de tip Denial-of-Service (DoS), negand posibilitatea crearii de conexiuni legitime. Serverul va trimite un raspuns SYN/ACK pentru fiecare initiere de conexiune. Acest raspuns va rezulta natural intr-un timeout in cazul initierilor de conexiune false dintr-un SYN flood, ulterior serverul eliminand intrarea respectiva din coada de conexiuni, existand deci o posibila fereastra pentru conexiuni legitime. Daca frecventa atacului este insa suficient de crescuta pozitiile libere vor fi ocupate tot de noi initieri false. In plus, chiar si in situatia de timeout, in functie de configurarile sistemului, serverului poate reincerca de mai multe ori trimiterea raspunsului SYN/ACK.
Una din metodele de contraatac pentru acest atac se bazeaza pe filtrarea traficului (RFC 2827). O alta metoda, mai frecvent intalnita, se bazeaza pe utilizarea asa numitului mecanism de SYN Cookies. Utilizarea SYN Cookies implica eliminarea initierilor de conexiuni din aceasta coada si refacerea informatiei din pachetul initial SYN pe baza pasilor urmatori in cazul unei incercari de conexiune ce nu reprezinta un atac. Pentru a reface structura de informatii mecanismul se foloseste de numarul de secventa initial al serverului, transmis in mesajul SYN/ACK (pasul 2) ce nu mai este generat aleator, ci compus din urmatoarele valori:

  • t - 5 biti: timestamp avand crestere lenta (timpul curent shiftat cu 6 pozitii la dreapta mod 32)
  • m - 3 biti: o codificare a dimensiunii maxime a segmentului
  • s - 24 biti: aplicarea unei functii criptografice asupra adresei IP si portului serverului, adresei IP si portului clientului, si valoarea t

Raspunsul ACK primit in al treilea pas al initierii conexiunii, va contine numarul de secventa trimis de server in pasul 2 incrementat cu 1 ca numar de confirmare. Serverul va verifica raspunsul primit pentru refacerea informatiilor in modul urmator:

  • valoarea de timp t (primii 5 biti) primita fata de timpul curent pentru a vedea daca nu a expirat un timeout de conectare
  • recalcularea functiei criptografice asupra adreselor IP, a porturilor (care sunt continute explicit in pachetul primit) si a valorii t, pentru a verifica ca respectivul numar de secventa e intr-adevar un SYN cookie
  • decodarea m pentru a afla dimensiunea maxima a segmentului stabilita pentru conexiunea respectiva

Doua din limitarile aduse de utilizarea SYN cookies constau in posibilitatea de utilizare a maxim 8 valori pentru dimensiunea maxima a segmentului, si imposibilitatea de a specifica optiuni extinse in stabilirea conexiunii TCP (aceste informatii fiind necesar a fi retinute in coada SYN).

Rezistenta la un atac de tip SYN flood depinde in concluzie de urmatorii factori:
a) Activarea mecanismului de SYN cookies. Uzual in distributiile Linux aceasta se face prin setarea optiunii:

	sudo sysctl -w net.ipv4.tcp_syncookies=[1-activ, 0-inactiv]

b) Dimensiunea cozii ce retine informatiile despre initierea conexiunilor. In distributiile Linux modificarea acesteia se poate realiza prin setarea optiunii:

	sudo sysctl -w net.ipv4.tcp_max_syn_backlog=[nr. conexiuni]

c) Numarul de reincercari de trimitere a raspunsului SYN/ACK la pachetele SYN primite pentru o noua conexiune. In mod obisnuit nu este recomandata reducerea acestei valori la zero pentru a permite totusi o toleranta pentru situatiile legitime cand trimiterea SYN/ACK esueaza, dar si o valoare foarte mare poate creste impactul atacului. Modificarea setarii corespunzatoare in Linux se face prin setarea optiunii: 

	sudo sysctl -w net.ipv4.tcp_synack_retries=[nr. reincercari]

d) Incepand cu versiunile mai noi de kernel in Linux, sistemul de operare include o masura suplimentara in care o parte din coada de conexiuni (in mod obisnuit un sfert) este rezervata pentru reluarea de conexiuni similare cu cele ce au mai existat. In concluzie, portiunea respectiva nu va putea fi ocupata de conexiunile initiate de un SYN flood si cel putin clientii anteriori ai serverului nu vor fi afectati de atac. Acest istoric al conexiunilor precedente poate fi observat, respectiv curatat prin urmatoarele comenzi: 

	ip tcp_metrics show
	sudo ip tcp_metrics flush

Simularea unui atac de tip SYN flood, in contextul setarii corespunzatoarea a parametrilor anteriori, poate fi realizata prin intermediul tool-ului 76 din Netwag. Alternativ, un script Python ce foloseste Scapy, este disponibil aici. Starea conexiunilor TCP mentinute la nivelul sistemului de operare poate fi observata prin comanda:

	netstat -tna

In setup-ul de laborator ce foloseste masini virtuale se poate observa insa ca scriptul Python nu este suficient de eficient pentru a determina efectul DoS. Fiecare incercare de noua conexiune rezulta intr-un reply RST la pachetele SYN/ACK cauzat de integrarea NAT din VirtualBox, ce practic determina eliminarea intrarii SYN respective din coada de conexiuni negand efectul atacului. In cazul implementarii Netwag, cantitatea de flood de mesaje este mult mai crescuta, pana la nivelul la care serverul nu mai reuseste sa trimita raspunsuri SYN/ACK.

Protectie alternativa prin filtrarea traficului asupra atacurilor de tip SYN flood si resetare conexiune pe baza bitului RST

O alta solutie impotriva atacurilor de tip SYN flood, si prin extensie si de resetare conexiune este prezentata in RFC 2827-Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing Ideea principala exprimata de respectivul document este relativ simpla bazandu-se pe un scenariu exemplificat in urmatoarea diagrama: 

                               11.0.0.0/8
                                   /
                               router 1
                                 /
                                /
                               /                       204.69.207.0/24
         ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
          A          B         C        D         2
                    /
                   /
                  /
              router 3
                /
            12.0.0.0/8

Se iau in calcul cazurile cand atacul este condus de o statie ce nu apartine de aceeasi subretea cu victima. Atacatorul va trimite pachete ce contin ca adresa sursa IP adrese falsificate posibil inexistente - in cazul SYN flood, fie o adresa de asemeni falsificata a unei din victime in cazul in care e vorba de un atac de tip resetare conexiune be baza bitului RST. Pachetele respective vor trece printr-un router intermediar, ce poate face o verificare la nivel de adresa IP sursa inainte de a realiza rutarea catre destinatie. Daca adresa IP sursa nu corespunde subretelei pentru care routerul asigura iesirea in internet din care a provenit pachetul, conform cu maparile pe care routerul le detine privind interfetele de retea si adresele de subretele asociate, exista probabilitatea unei falsificari a adresei IP sursa. In exemplul dat putem considera un pachet ce are etichetat ca IP sursa 82.77.229.12 dar provine din reteaua 204.69.207.0. In acest caz, pachetul poate fi filtrat (ingress filtering) de router 2 nefiind trimis mai departe.
Solutia respectiva ofera un oarecare nivel de protectie. Totusi pe langa faptul ca nu acopera toate conditiile in care ar putea avea loc atacul (de ex: din aceeasi subretea) mai exista si cazuri in care nu e aplicabila din diverse motive, fiind posibila negarea de trafic legitim. Pentru mai multe detalii recomandam consultarea RFC-ului mentionat mai sus.

© 2026 Emanuel Onica. Parts of design by W3Layouts