[Tutorial de siguranță] Atacuri SYN Flood, apărarea cookie-urilor SYN și modificarea parametrilor nucleului pentru Linux/FreeBSD

HackerEste o carieră dorită și promițătoare. Apreciez hackerii buni și urăsc hackerii răi. Așa-zisul hacker rău este genul de tip care face pe cineva de cealaltă parte să lucreze peste program.

    Atacurile SYN Flood sunt un atac tipic de tip denial of service. Așa-numitul atac de negare a serviciului are ca scop indirect atingerea scopului atacului, făcând ca gazda sau rețeaua victimă să nu poată oferi un serviciu bun. Hackerilor le place să joace asta pentru a arăta că sunt echilibrați, capabili și curajoși, făcând cealaltă parte să muncească peste program, dar de fapt, nu înseamnă nimic.

   1: Ce este un atac SYN Flood?

    Atacurile SYN Flood profită de procesul de handshake în trei direcții al protocolului TCP în IPv4. Acest protocol prevede că, dacă un capăt dorește să inițieze o conexiune TCP la celălalt capăt, trebuie mai întâi să trimită un pachet TCP SYN (synchronize) către cealaltă parte, iar cealaltă parte trimite înapoi un pachet TCP SYN + ACK după ce îl primește, iar inițiatorul trimite înapoi un pachet TCP ACK (ACKnowledge Character), astfel încât cele trei handshake-uri să se încheie.

    În procesul de mai sus, există câteva concepte importante:

    Coada nu este conectată: În protocolul de strângere de mână în trei moduri, serverul menține o coadă neconectată care deschide o intrare pentru fiecare pachet SYN al clientului (syn=j) ce indică faptul că serverul a primit pachetul SYN și emite o confirmare către client, așteptând pachetul de confirmare al acestuia. Conexiunea identificată de aceste intrări se află într-o stare Syn_RECV pe server, iar când serverul primește un pachet de confirmare de la client, intrarea este ștearsă, iar serverul intră în starea ESTABLISHED. Cu alte cuvinte, când serverul TCP primește pachetul de cerere TCP SYN, înainte de a trimite pachetul TCP SYN+ACK înapoi către clientul TCP, serverul TCP trebuie mai întâi să aloce o zonă de date pentru a deservi conexiunea TCP formată de această mână. În general, starea de conexiune este când pachetul SYN este recepționat, dar pachetul ACK nu a fost încă primitConexiune semi-deschisă(Conexiune pe jumătate deschisă)。

    Parametrul de backlog: Indică numărul maxim de cozi neconectate.

    Numărul de retransmisii SYN-ACK: După ce serverul trimite pachetul SYN-ACK, dacă pachetul de confirmare al clientului nu este primit, serverul efectuează prima retransmisie, așteaptă o perioadă de timp și nu primește pachetul de confirmare al clientului, apoi efectuează a doua retransmisie; dacă numărul de retransmisii depășește numărul maxim de retransmisii specificat de sistem, sistemul șterge informațiile de conexiune din coada semi-conexiune. Rețineți că timpul de așteptare pentru fiecare retrecere nu este neapărat același.

    Timpul de supraviețuire semi-conectat: Se referă la timpul maxim în care o intrare în coada semi-conexiune supraviețuiește, adică timpul maxim de la momentul în care serviciul primește pachetul SYN până la momentul în care pachetul este confirmat ca fiind invalid, iar valoarea timpului este suma timpului maxim de așteptare pentru toate pachetele de cerere de retransmitere. Uneori numim și timpul de supraviețuire semi-conectat, SYN_RECV timpul supraviețuirii.

    În cel mai frecvent atac SYN flood, atacatorul trimite un număr mare de pachete TCP SYN către victimă într-un interval scurt de timp, moment în care atacatorul este clientul TCP, iar victima este serverul TCP. Conform descrierii de mai sus, victima ar atribui fiecărui pachet TCP SYN o zonă de date specifică, atâta timp cât pachetele SYN aveau adrese sursă diferite (ceea ce ar fi ușor de falsificat pentru atacatori). Acest lucru va pune multă presiune pe sistemul de server TCP și, în cele din urmă, va face ca sistemul să nu funcționeze corect.

    2. Principiul cookie-urilor SYN

    Una dintre modalitățile eficiente de a preveni atacurile SYN Flood este utilizarea cookie-urilor SYN. SYN Motivul D. Inventat de J. Bernstain și Eric Schenk.

    Cookie-urile SYN sunt o modificare a protocolului TCP de handshake în trei căi pe partea serverului pentru a preveni atacurile SYN Flood.Principiul său este:Când serverul TCP primește un pachet TCP SYN și returnează un pachet TCP SYN+ACK, nu alocă o zonă dedicată de date, ci calculează o valoare de cookie-uri pe baza acestui pachet SYN. Când este primit un pachet TCP ACK, serverul TCP verifică legitimitatea pachetului TCP ACK pe baza valorii cookie-ului respective. Dacă este legal, se alocă o zonă dedicată de date pentru a gestiona viitoarele conexiuni TCP.

    Să vorbim despre cum să configurezi parametrii kernelului pentru a implementa cookie-uri SYN în Linux și FreeBSD

    Trei: setări Linux

    Dacă configurația serverului tău nu este bună, numărul de socket-uri TCP TIME_WAIT ajunge la 20.000 sau 30.000, iar serverul poate fi ușor epuizat. Prin modificarea parametrilor nucleului Linux, numărul de TIME_WAIT socket-uri de pe server poate fi redus.

    TIME_WAIT poate fi vizualizat cu următoarea comandă:

Pe Linux, cum ar fi CentOS, poți realiza acest lucru modificând fișierul /etc/sysctl.conf.

    Adaugă următoarele rânduri:

Ilustra:

net.ipv4.tcp_syncookies = 1 înseamnă că cookie-urile SYN sunt activate, ceea ce este un BOOLEAN. Când SYN așteaptă ca coada să depășească, activează cookie-urile pentru a gestiona problema, ceea ce poate preveni un număr mic de atacuri SYN, iar implicitul este 0, ceea ce înseamnă că este închis.
net.ipv4.tcp_tw_reuse = 1 înseamnă că reutilizarea este activată, ceea ce este un BOOLEAN. Permite reutilizarea socket-urilor TIME-WAIT pentru conexiuni TCP noi, implicit la 0, indicând închiderea;
net.ipv4.tcp_tw_recycle = 1 înseamnă pentru a permite reciclarea rapidă a socket-urilor TIME-WAIT în conexiunile TCP, ceea ce este BOOLEAN, iar implicitul este 0, ceea ce înseamnă că este închis.
net.ipv4.tcp_fin_timeout = 30 înseamnă că, dacă soclul este închis de o cerere locală, acest parametru determină cât timp va rămâne în starea FIN-WAIT-2. Unitatea este în secunde.
net.ipv4.tcp_keepalive_time = 1200 indică cât de des TCP trimite mesaje keepalive atunci când se folosește keepalive. Durata implicită este 2 ore, schimbată la 20 de minute. Unitatea este în secunde.
net.ipv4.ip_local_port_range = 1024 65000 indică gama de porturi folosite pentru conexiunile de ieșire. Carcasa implicită este mică: 32768 la 61000, schimbată la 1024 la 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indică lungimea cozii SYN, care este 1024 implicit, iar lungimea cozii mărite este 8192 pentru a acomoda mai multe conexiuni de rețea în așteptarea conexiunii.
net.ipv4.tcp_max_tw_buckets = 5000 indică numărul maxim de socluri pe care sistemul le menține TIME_WAIT în același timp, iar dacă acest număr este depășit, soclurile TIME_WAIT vor fi șterse imediat și va fi tipărit un mesaj de avertizare. Valoarea implicită este 180000, schimbată la 5000. Pentru servere precum Apache și Nginx, parametrii din liniile anterioare pot reduce TIME_WAIT numărul de socket-uri, dar pentru Squid, efectul nu este grozav. Acest parametru controlează numărul maxim de socluri TIME_WAIT pentru a preveni ca serverul Squid să fie tras de un număr mare de socluri TIME_WAIT.
net.ipv4.tcp_synack_retries și net.ipv4.tcp_syn_retries definesc numărul de încercări SYN.

Rulați următoarea comandă pentru ca configurația să intre în vigoare:

Dacă nu vrei să modifici /etc/sysctl.conf, poți folosi și comanda pentru asta:

În al patrulea rând, configurat sub FreeBSD

    Perspectiva personală de învățare a lui yayu: apărarea împotriva syn în FreeBSD poate să nu fie aceeași ca în Linux, parametrii configurați nu sunt exact aceiași, iar configurarea și înțelegerea relevante pot să nu fie corecte :)

    Există unul în legătura TCPMSL (durata maximă de viață a segmentului)Conceptul deTimpul maxim de generareValoarea MSL este luată timp de 30 de secunde în implementările generale, iar unele implementări durează 2 minute. "Oprire pasivă" în mașina de stare TCP: De la CLOSE_WAIT la LAST_ACK, există o regulă următoarea: Când TCP efectuează o oprire activă și trimite înapoi ultimul ACK, conexiunea trebuie să rămână în starea TIME_WAIT de două ori mai mult decât MSL-ul. Acest lucru permite TCP să trimită din nou ultimul ACK în cazul în care acesta este pierdut (celălalt capăt expiră și retrimite ultimul FIN).

    Existența acestei reguli are ca consecință că legătura (adresa clientului, portul și adresa serverului, port) de pe acea adresă nu poate fi folosită în acest timp de 2*MSL. De exemplu, dacă închidem un link după ce îl creăm și apoi îl repornim rapid, atunci portul nu va mai fi disponibil.

    TIME_WAIT timp este 2*MSL. Astfel, poți reduce timpul TIME_WAIT ajustând net.inet.tcp.msl. Pentru serverul web, această valoare poate fi ajustată la 7500 sau 2000 (accesează un web, pagina nu poate fi flash-uitată mai mult de 4~15 secunde, poți lua în considerare să renunți -_-)

    Referință pentru setările parametrilor:

Pe FreeBSD, yayu nu a văzut o comandă de genul "/sbin/sysctl -p" care să poată face conținutul /etc/sysctl.conf eficient, așa că a folosit pur și simplu comanda: