Protecția împotriva atacurilor de inundații sin, un notebook al administratorului obișnuit)

De fapt, este vorba despre protejarea împotriva atacurilor de inundații SYN:

Un foarte popular atac DoS este de a trimite un număr mare de pachete SYN la serverul dvs. În acest caz, configurarea conexiunii TCP nu este finalizată. Coada de solicitări de conectare semi-deschis este umplută rapid, ceea ce împiedică instalarea conexiunilor normale. Deoarece conexiunea nu trebuie neapărat finalizată, un astfel de atac nu necesită resurse mari de la mașina care atacă, deci este ușor de implementat și de controlat.


Definiți pur și simplu atacul SYN - comanda netstat afișează o listă uriașă de conexiuni semi-deschise:

Putem număra doar numărul:

Mai întâi, verificați parametrul tcp_syncookies - ar trebui să fie 1:

Și pleacă. Implicit, această opțiune este întotdeauna activă în distribuțiile noi.

În cazul în care este instalat tcp_syncookies (disponibil numai când este compilat kernel-ul cu CONFIG_SYNCOOKIES), apoi kernel-ul se ocupă de pachete SYN TCP în modul normal, atâta timp cât locul este plin. După completarea mecanismului de cozi cookie-urile SYN activat.

Activarea mecanismului SYN cookies este o modalitate foarte simplă de a combate atacul de inundații SYN. În același timp, procesorul se încarcă puțin mai mult din cauza necesității de a crea și verifica modulele cookie. Deoarece o soluție alternativă este respingerea tuturor solicitărilor de conectare, cookie-urile SYN sunt o alegere bună.

De asemenea, trebuie să măriți coada de conexiuni semi-deschise - tcp_max_syn_backlog (în Debian Lenny în mod implicit 1024 conexiuni):

În plus, putem reduce timpul de conectare al conexiunii tcp_synack_retries:

Valoarea integeră (1 octet) din tcp_synack_retries determină numărul de încercări de reîncercare pentru pachetele SYNACK pentru conexiuni TCP pasive. Numărul de încercări nu trebuie să depășească 255. Valoarea implicită de 5 corespunde la aproximativ 180 de secunde pentru încercările de conectare.

Reduceți la 1 (aproximativ 9 secunde):

Numărul întreg din fișierul tcp_fin_timeout determină momentul în care soclul este salvat în starea FIN-WAIT-2 după ce acesta este închis de partea locală. Partenerul nu poate închide această conexiune vreodată, deci ar trebui să îl închideți din proprie inițiativă după expirarea timpului de expirare. Timpul prestabilit este de 60 de secunde. În serie de kernel 2.2 utilizate în mod obișnuit valoare de 180 de secunde, și puteți salva această valoare, dar nu uitați că pe serverele încărcate-WEB, riscati să-și petreacă o mulțime de memorie pentru a păstra legături moarte polurazorvannyh. Prizele în starea FIN-WAIT-2 sunt mai puțin periculoase decât FIN-WAIT-1, deoarece absorb nu mai mult de 1,5 Kbyte de memorie, dar pot exista mai mult.

Variabila intreg tcp_keepalive_probes specifică de câte ori sunt transmise eșantioanele keepalive, după care se consideră că conexiunea este ruptă. În mod implicit, 9 eșantioane sunt transmise.

Variabila intreg tcp_keepalive_intvl specifică intervalul de eșantionare. tcp_keepalive_probes lucrare * tcp_keepalive_intvl determină timpul după care conexiunea este încheiată în absența feedback-ului. Intervalul prestabilit este de 75 secunde, adică Timpul de deconectare va fi de aproximativ 11 minute dacă nu există răspunsuri.

Aceasta specifică numărul maxim de pachete pe coadă de procesare dacă interfața primește pachete mai repede decât nucleul le poate procesa.

Numărul maxim de prize deschise care așteaptă o conexiune.

Deoarece astfel de modificări ale parametrilor kernelului nu vor fi păstrate după repornire - adăugați la /etc/rc.local:

În plus, puteți adăuga o limită la numărul de pachete SYN pe unitate de timp în iptables:

Numărul de pachete SYN noi este de maximum 500 pe secundă, când pragul este depășit în 1500 de pachete noi sunt blocate:

Mai clar, acest criteriu poate fi imaginat ca o anumită capacitate cu o ieșire prin care trece un anumit număr de pachete pe o unitate de timp (adică rata de "scurgere"). Rata de "scurgere" determină valoarea - limită. Valoarea -limit-burst stabilește "capacitatea" totală. Și acum imaginați-vă o regulă --limit 3 / minut --limit-burst 5, apoi, după ce a primit 5 pachete (pentru o perioadă foarte scurtă de timp), capacitatea de a „umple“ și fiecare pachet ulterior va provoca „depășire“ capacitate, adică "Triggerarea" criteriului. După 20 de secunde, "nivelul" din rezervor va fi redus (în conformitate cu limita de valoare), deci este gata să accepte un alt pachet fără a provoca o "capacitate deplină", ​​adică declanșând criteriul.

Mi-a plăcut acest lucru: