Ce este un atac DDoS? Tehnică, niveluri și apărare

Un atac DDoS este încercarea de a face un serviciu inaccesibil printr-o suprasarcină generată artificial, executată simultan de foarte mulți expeditori diferiți. Abrevierea vine de la Distributed Denial of Service, deci de la o refuzare a serviciului provocată în mod distribuit. Atacat nu este nici conținutul unui server, nici o vulnerabilitate din software-ul lui, ci o resursă care este finită: lățimea de bandă a conexiunii, rata de pachete a plăcii de rețea, un loc într-un tabel de stare al kernelului sau timpul de calcul pe care aplicația îl consumă pentru o singură cerere. Dacă una dintre aceste patru resurse este ocupată, utilizatorii reali nu mai trec, și asta fără ca cineva să fi pătruns în sistem.

Acest articol este intrarea în temă. El explică cele trei niveluri pe care au loc atacurile, cu ce factori de amplificare dintr-un octet de cerere se fac 51.000 de octeți de răspuns, de unde vine capacitatea de atac și cât costă ea pe piață, după ce vă dați seama de un atac din propriile valori măsurate, ce mai ajută pe serverul însuși și pe unde trece exact această limită. Toate cifrele sunt indicate cu sursă, ca să le puteți verifica. Dacă serviciul dumneavoastră este oprit chiar acum, citiți mai întâi secțiunea „Ce este de făcut în caz de atac” și măsurați în loc să modificați.

Ce este din punct de vedere tehnic un atac DDoS

Fiecare atac DDoS trăiește dintr-o asimetrie: trimiterea unui pachet trebuie să îl coste pe atacator mai puțin decât îl costă pe ținta lui prelucrarea acelui pachet. Tot restul este doar întrebarea în ce punct este cea mai mare această asimetrie. Există exact patru puncte, și fiecare are o limită superioară dură, care se poate calcula.

Lățimea de bandă a conexiunii. O conexiune de 1 Gbit/s transportă 125 de megaocteți pe secundă, nu mai mult. Cine trimite mai mult produce pierderi, iar pierderile lovesc pachetele utilizatorilor dumneavoastră la fel ca pe cele ale atacatorului, deoarece o conexiune plină nu alege.

Rata de pachete. Cel mai mic pachet Ethernet admis are 64 de octeți și ocupă, cu preambul și cu spațiul dintre pachete, 84 de octeți pe conexiune. Într-un 1 Gbit/s încap în jur de 1,49 milioane pe secundă. Un kernel de server obișnuit prelucrează, în funcție de procesor și de placa de rețea, câteva sute de mii, înainte să înceapă să elimine. Rata de pachete este de aceea aproape întotdeauna limita care se atinge înaintea lățimii de bandă.

Tabelele de stare. Kernelul reține conexiunile TCP pe jumătate deschise și fluxurile de pachete. Aceste tabele sunt limitate numeric, nu în biți pe secundă. Ele se pot umple cu foarte puțină lățime de bandă, dacă fiecare pachet poartă o adresă de expeditor nouă.

Timpul de calcul al aplicației. O căutare, o încercare de autentificare cu verificarea parolei sau o interogare de server care returnează o listă întreagă de moduri costă ținta de o mie de ori mai mult decât pe expeditor. Aici un atac eficient nu are nevoie de multe ori nici măcar de 10 Mbit/s.

DoS și DDoS: diferența care se poate măsura

Baza noțională o dă RFC 4732, „Internet Denial-of-Service Considerations”, o publicație informațională a IETF din noiembrie 2006. Acolo scrie textual: „A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.” Un atac DoS este deci definit prin efect, nu prin numărul surselor. Distribuit, adică DDoS, este atunci când aceste surse sunt numeroase și independente una de alta.

Practic, diferența contează într-un singur punct: la lungimea listei dumneavoastră de blocare. Un atac DoS dintr-o singură sursă îl opriți cu o regulă. Cloudflare a documentat în mai 2025 un atac care venea din 122.145 de adrese sursă diferite, din 161 de țări și 5.433 de sisteme autonome, în medie 26.855 de adrese noi pe secundă, în vârf 45.097. Împotriva unui asemenea lucru nu există nicio listă de blocare care să crească suficient de repede, iar fiecare intrare din ea costă în plus memorie și timp de căutare pe aparatul care este oricum deja suprasolicitat.

Ghidul comun „Understanding and Responding to Distributed Denial-of-Service Attacks” al CISA, FBI și MS-ISAC împarte atacurile în exact trei tehnici: volumetrică, la nivel de protocol și la nivel de aplicație. Această împărțire în trei este cea mai utilă care există, deoarece descrie totodată care dintre cele patru resurse ale dumneavoastră este atacată și unde trebuie să stea apărarea.

Cele trei niveluri ale unui atac DDoS

Atacurile volumetrice pe layer 3 și 4

Un atac volumetric nu vrea nimic altceva decât să umple conexiunea din fața țintei. Se măsoară în biți pe secundă. Mijlocul este de regulă un flood UDP, deoarece UDP nu cunoaște nicio stabilire de conexiune care ar putea fi pretinsă și deoarece adresele expeditorului se pot falsifica.

Cel mai mare exemplu documentat public în acest moment: Cloudflare raportează pentru perioada de până la sfârșitul lui 2025 un atac respins automat cu 31,4 Tbit/s, care a durat 35 de secunde. Aceasta este capacitatea a în jur de 31.400 de conexiuni de server de 1 Gbit/s, simultan, timp de o jumătate bună de minut. În același raport se află o a doua valoare, care face ordinul de mărime mai ușor de cuprins decât valoarea de vârf: în anul 2025 același operator a respins 47,1 milioane de atacuri DDoS, un plus de 121 la sută față de anul precedent, în medie 5.376 de atacuri pe oră.

Cazul mai bine documentat din mai 2025 arată cum arată un asemenea atac atunci când este descompus: 7,3 Tbit/s în vârf, 37,4 teraocteți de date în 45 de secunde, adică în medie în jur de 830 de gigaocteți pe secundă. O conexiune de 1 Gbit/s ar fi avut nevoie pentru aceeași cantitate de date de trei zile bune. 99,996 la sută din trafic au fost flooduri UDP pure, distribuite peste în medie 21.925 de porturi țintă simultan, în vârf 34.517. Această distribuție peste toate porturile este tipică: atacatorul nu știe care port este important, deci le ia pe toate.

Atacurile asupra protocolului: tabelele, nu conexiunea

Un atac asupra protocolului exploatează faptul că kernelul trebuie să rețină stări. Exemplul standard este floodul SYN: atacatorul trimite pachete TCP cu bitul SYN setat și cu adresa expeditorului falsificată, serverul creează pentru fiecare o intrare în coada lui de așteptare pentru conexiuni pe jumătate deschise, răspunde cu SYN-ACK către o adresă care nu a răspuns niciodată și așteaptă. Aici se măsoară în pachete pe secundă, nu în gigabiți.

Lungimea acestei cozi de așteptare stă în net.ipv4.tcp_max_syn_backlog și se află, pe un server obișnuit, în domeniul de patru cifre. O coadă cu 1.024 de locuri este plină, la 1,49 milioane de pachete SYN pe secundă, în mai puțin de o milisecundă. Pentru asta ajung, pur aritmetic, 1 Gbit/s, iar dacă doar tabelul este ținta, ajunge o fracțiune din atât.

Din aceeași familie face parte o metodă care a fost descrisă abia în 2021: reflexia TCP prin dispozitive intermediare cu stare. Lucrarea „Weaponizing Middleboxes for TCP Reflected Amplification” arată că firewallurile și infrastructura de cenzură, care urmăresc starea TCP doar pe jumătate, reacționează la un singur pachet falsificat cu pagini întregi de răspuns. Cu asta se poate folosi abuziv pentru prima dată și TCP pentru amplificare, ceea ce până atunci era considerat practic imposibil.

Atacurile asupra aplicației pe layer 7

Un atac asupra aplicației arată ca trafic obișnuit, deoarece este trafic obișnuit, doar în cantitate greșită. Se măsoară în cereri pe secundă. El vine printr-o conexiune complet stabilită, supraviețuiește deci oricărei verificări care evaluează doar stabilirea conexiunii, și are nevoie de puțină lățime de bandă: 10.000 de cereri HTTP pe secundă înseamnă, în funcție de mărimea cererii, mai puțin de 50 Mbit/s și totuși suficient pentru a pune o bază de date în genunchi.

Etalonul pentru asta se numește HTTP/2 Rapid Reset, făcut public la 10 octombrie 2023 ca CVE-2023-44487. Slăbiciunea stă în capacitatea de multiplexare a HTTP/2: atacatorul deschide un flux de date, trimite cererea și întrerupe fluxul imediat la loc. Serverul a început deja lucrul, atacatorul are însă imediat din nou un loc liber în fereastră. Valorile atinse astfel au fost de 201 milioane de cereri pe secundă (Cloudflare), 398 de milioane (Google) și 155 de milioane (Amazon). Pentru comparație: cel mai mare atac pe layer 7 măsurat până atunci de Cloudflare a fost de 71 de milioane de cereri pe secundă.

La serverele de joc, nivelul layer 7 este chiar stabilirea conexiunii. Nullping, QuietException și floodurile de handshake fals împotriva rețelelor Minecraft nu au nevoie aproape de nicio lățime de bandă și paralizează grupuri întregi de proxy, deoarece fiecare pachet obligă proxy-ul la o decizie de stare costisitoare. Cum arată exact aceste modele scrie în Protecție DDoS și protecție Nullping pentru Minecraft.

Cele trei niveluri în comparație

Atacurile reale nu respectă această împărțire. Cazul cel mai neplăcut în practică este atacul pe mai multe straturi: o parte volumetrică, care ocupă conexiunea, plus o parte pe layer 7, care trece exact în momentul în care atenția stă pe lățimea de bandă. Unul dintre atacurile filtrate la KernelHost, arătate mai jos, era compus din peste douăsprezece modele principale diferite simultan.

Atacurile de amplificare: cum dintr-un octet se fac 51.000

Un atac de amplificare este un atac în care atacatorul nu trage el însuși în țintă, ci determină servicii străine, accesibile public, să o facă pentru el. El trimite o cerere mică către un serviciu deschis și trece ca expeditor adresa IP a victimei. Serviciul răspunde conform regulilor, doar că victimei, iar răspunsul este de mai multe ori mai mare decât cererea.

Raportul dintre mărimea răspunsului și mărimea cererii se numește Bandwidth Amplification Factor, pe scurt BAF. Un BAF de 50 înseamnă că un atacator cu 1 Gbit/s de conexiune proprie dirijează 50 Gbit/s către țintă. Două lucruri trebuie să se întâlnească pentru ca asta să funcționeze: un protocol peste UDP, care răspunde mai mult decât este întrebat, și posibilitatea de a falsifica adresa expeditorului. De aceea falsificarea adresei IP este condiția fiecărui atac de amplificare și nu doar o tactică de disimulare.

Pentru apărător rezultă de aici o proprietate neplăcută: traficul vine de la servere reale, legitime. Sunt resolvere DNS reale, servere de timp reale, servere de joc reale. O listă de blocare după adresa sursă blochează deci fie jumătăți de țări, fie nu are niciun efect.

Factorii de amplificare ai protocoalelor folosite abuziv

Factorii următori provin din alerta TA14-017A a US-CERT, respectiv CISA, „UDP-Based Amplification Attacks”, care este extinsă continuu din 2014. Ea este referința la care se raportează întreaga industrie.

Tabelul explică de ce lista porturilor blocate arată asemănător în fiecare firewall bine întreținut. Ce puteți face dumneavoastră este puțin, dar important: verificați cu ss -lnup dacă pe serverul dumneavoastră stă deschis în rețea un serviciu din acest tabel. Un memcached care nu este legat pe 127.0.0.1 face din serverul dumneavoastră o armă împotriva unor terți, vă costă propria lățime de bandă de ieșire și vă duce adresa IP pe liste de blocare din care iese greu la loc.

De ce protocoalele de interogare ale jocurilor fac parte din listă

Serverele de joc stau în acest tabel cu două roluri. Sunt amplificatoare, deoarece portul lor de interogare răspunde la un pachet mic cu numele, harta, numărul de jucători și lista completă de moduri. Și sunt victime, deoarece aceeași interogare consumă timp de calcul, adesea exact pe nucleul care duce simularea jocului.

Factorul de amplificare al protocolului Steam este mic, 5,5, cel al protocolului Quake mai vechi este mare, 63,9. Efectul nu atârnă însă doar de factor, ci de mărimea răspunsului în fiecare caz în parte: un server cu 200 de moduri livrează un răspuns vizibil mai mare decât unul fără. Bohemia Interactive documentează pentru Arma 3, sub tichetul T83469, din 2015, că deja 4 Mbit/s de interogări falsificate către portul Steam Query au fost suficienți pentru a îngheța un server. Patru megabiți pe secundă sunt mai puțin decât produce o singură conexiune casnică.

De aici rezultă regula valabilă pentru fiecare joc: portul de interogare se limitează, nu se blochează. Cine îl blochează dispare din lista de servere și nu mai este găsit de jucătorii noi. Care port este acesta la fiecare joc și cât de strâns are voie să fie condus scrie în articolele specifice fiecărui joc, mai jos, de exemplu pentru Arma 3, CS2 și titlurile Source sau Rust.

Cazul memcached: 1,35 Tbit/s împotriva GitHub

La 28 februarie 2018, GitHub a fost inaccesibil de la 17:21 până la 17:26 UTC și până la 17:30 UTC doar cu intermitențe. Atacul a atins 1,35 Tbit/s la 126,9 milioane de pachete pe secundă și venea din peste 1.000 de sisteme autonome diferite și din zeci de mii de puncte finale individuale. Amplificat a fost prin memcached, cu un factor de până la 51.000: un octet al atacatorului genera până la 51 de kiloocteți în direcția țintei.

Acest caz este până astăzi cea mai bună lecție, deoarece arată trei lucruri deodată. În primul rând: amplificarea bate mărimea botnetului. Atacatorul nu a avut nevoie de o sută de mii de dispozitive, a avut nevoie de instanțe memcached deschise, dintre care pe atunci stăteau în rețea, în toată lumea, peste 90.000. În al doilea rând: 126,9 milioane de pachete pe secundă înseamnă în jur de 85 de ori mai mult decât poate transporta în general o conexiune de 1 Gbit/s. Nicio setare de pe server nu schimbă nimic la asta. În al treilea rând: apărarea a funcționat deoarece traficul a fost deviat într-o rețea de filtrare, iar timpul de indisponibilitate s-a terminat astfel la nouă minute în loc de nouă ore.

De unde vine capacitatea pentru un atac DDoS

Botneturi din dispozitive preluate

Un botnet este un ansamblu de dispozitive străine, preluate cu software rău intenționat, pe care un atacator le comandă de la distanță, centralizat. Proprietarii nu observă de regulă nimic, deoarece dispozitivul face în continuare ceea ce pentru care a fost cumpărat. Atacate sunt mai ales dispozitive care atârnă permanent în rețea, sunt rar actualizate și poartă parole standard: rutere, camere de supraveghere, înregistratoare de rețea, cutii de televiziune.

Etalonul este Mirai, al cărui cod sursă a fost publicat la sfârșitul lui septembrie 2016. Lucrarea „Understanding the Mirai Botnet” (USENIX Security 2017) urmărește rețeaua timp de șapte luni și cifrează punctul maxim la peste 600.000 de dispozitive infectate. Atacul asupra paginii lui Brian Krebs din septembrie 2016 a atins 620 Gbit/s și venea din peste 175.000 de dispozitive. La atacul asupra operatorului DNS Dyn din 21 octombrie 2016, care a făcut simultan inaccesibile Twitter, Spotify și Reddit, au fost numărate în jur de 107.000 de adrese IP atacatoare.

Nouă ani mai târziu, ordinul de mărime este altul. Cloudflare pune atacul record de 31,4 Tbit/s pe seama unui botnet cu o mărime estimată de unu până la patru milioane de dispozitive infectate, majoritar cutii de televiziune Android. În valul de atacuri din decembrie 2025 au fost numărate 902 de atacuri hipervolumetrice, în medie 53 pe zi, cu valori de vârf de 9 miliarde de pachete pe secundă, 24 Tbit/s și 205 milioane de cereri pe secundă. Mărimea botneturilor a crescut astfel, în decurs de un deceniu, cu factorul 5, iar lățimea de bandă atinsă cu factorul 50.

Serviciile booter și stresser și cât costă un atac

Între botnet și cel care comandă atacul stă un serviciu care vinde capacitatea de atac în abonament. Aceste servicii apar sub numele de „booter”, „stresser” sau „IP stresser” și susțin în condițiile lor de utilizare că servesc testării la sarcină a sistemelor proprii. Ele nu verifică niciodată dacă ținta introdusă îi aparține utilizatorului, și exact asta este diferența dintre o unealtă și o ofertă.

Utilizarea se face printr-o interfață web cu trei câmpuri: țintă, port, durată. Există procese de plată, asistență pentru clienți și programe de revânzare. Pachetele de intrare se află la în jur de 10 până la 20 de euro pe lună, pachetele mai mari, cu mai multă lățime de bandă și cu durată de atac mai lungă, la câteva sute de euro pe lună. Cu asta este răspuns și la întrebarea de ce sunt lovite și proiectele mici: un atac care costă un server de joc seara de sâmbătă îl costă pe cel care îl declanșează mai puțin decât două bilete de cinema și nicio cunoștință tehnică.

De cealaltă parte stă o presiune permanentă a urmăririi penale. În săptămâna de acțiune a operațiunii internaționale PowerOFF din aprilie 2026, autoritățile din 21 de țări au preluat 53 de domenii ale unor asemenea servicii, au arestat patru persoane și au efectuat 25 de percheziții domiciliare. Cu acea ocazie, anchetatorii au obținut acces la datele a peste trei milioane de conturi de utilizator, iar peste 75.000 de utilizatori identificați au fost contactați în scris. În decembrie 2024 fuseseră închise, în aceeași operațiune, 27 de platforme. Cine plătește un asemenea serviciu lasă deci o urmă de plată într-o bază de date care mai devreme sau mai târziu este confiscată.

Cum recunoașteți un atac DDoS

Ce raportează utilizatorii și ce spune deja asta

Prima informație vine aproape întotdeauna de la utilizatori, și este mai utilizabilă decât sună. Patru raportări au un înțeles clar:

• „Toți am fost dați afară în același timp.” O întrerupere simultană la toți utilizatorii vorbește pentru conexiune sau pentru procesul serviciului, nu pentru conexiuni individuale. O problemă de încărcare lovește utilizatorii unul după altul.
• „Pingul sare de la 20 la 400 și înapoi.” Timpul de parcurgere care oscilează, în condițiile în care conexiunea continuă să existe, este modelul unei cozi supraîncărcate din fața țintei, nu al unui proces suprasolicitat.
• „Lista de servere ne arată ca offline, dar eu mă pot conecta.” Acesta este indiciul unui val de interogări: portul de interogare nu mai răspunde, portul de joc încă da.
• „Prin rețeaua mobilă intru, prin conexiunea mea nu.” Un comportament diferit în funcție de rețeaua de acces arată că nu serverul dumneavoastră, ci un drum până la el este saturat.

Cele patru valori măsurate pe server

După aceea se măsoară, și anume în această ordine: rata de pachete, lățimea de bandă, stările conexiunilor, contoarele de pachete eliminate. Afișarea gradului de utilizare a procesorului vine la urmă, deoarece la un atac de rețea rămâne adesea fără nimic ieșit din comun.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 livrează pachetele și octeții pe secundă pentru fiecare interfață, pe zece secunde. Decisiv este raportul: multe pachete la puțini octeți înseamnă pachete mici, deci un atac asupra protocolului. Puține pachete la foarte mulți octeți înseamnă pachete mari, deci un atac de amplificare. ip -s link show arată în coloanele dropped și overrun dacă kernelul elimină deja. ss -tn state syn-recv numără conexiunile pe jumătate deschise: o valoare de trei cifre este normală, una de cinci cifre este un flood SYN. Iar nstat livrează contoarele care rămân și după ce atacul s-a terminat.

Cel mai important pas este acela pe care aproape nimeni nu îl face dinainte: crearea unei baze de comparație cât timp totul merge normal. Fără o valoare normală nu puteți spune dacă 40.000 de pachete pe secundă sunt mult sau este pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent în fundal. Instrucțiunile detaliate pentru interpretare se află în Recunoașterea unui atac DDoS.

Liniile de jurnal care sunt lămuritoare

Patru mesaje din jurnalul kernelului și din jurnalul serverului web sunt practic dovezi. dmesg -T | tail -50 le arată pe primele trei:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Prima linie înseamnă că a fost depășită coada de așteptare pentru conexiuni pe jumătate deschise și că kernelul a comutat pe SYN cookies. Dacă acolo scrie în schimb Dropping request, atunci net.ipv4.tcp_syncookies este pus pe 0, iar serverul elimină cereri, inclusiv pe cele reale. A doua linie înseamnă că urmărirea conexiunilor este plină, iar din acel moment serverul elimină și trafic legitim. A treia linie este un efect secundar: kernelul suprimă mesaje, deoarece altfel ar fi ocupat cu jurnalizarea. A patra linie mută problema în aplicație.

În jurnalul de acces al serverului web sunt relevante două lucruri. O pondere bruscă a codului de stare 499 înseamnă că clientul închide conexiunea înainte ca răspunsul să fie gata, și exact asta face un atac pe layer 7, care vrea doar să declanșeze muncă și nu să citească. Iar un câmp referrer gol la aproape toate cererile deosebește un atac de un aflux real de vizitatori, care aduce cu el referreri de la motoare de căutare și rețele sociale.

Contraproba: atac, aflux sau greșeală proprie

Ce ajută pe serverul însuși

Pe server se poate obține mai mult decât se susține adesea, și anume împotriva a tot ce rămâne mic: boți neglijenți, surse individuale, valuri de interogări și atacuri asupra aplicației. Uneltele pentru asta sunt nftables, urmărirea conexiunilor, SYN cookies și o limitare de rată pe fiecare adresă sursă. Toate datele următoare sunt valabile pentru Debian 12, Debian 13, Ubuntu 22.04 LTS și Ubuntu 24.04 LTS și sunt scrise pentru root.

nftables: eliminați devreme, calculați puțin

Principiul sună astfel: un pachet care este eliminat trebuie eliminat cât mai devreme și cât mai ieftin posibil. Fiecare regulă care rulează înaintea lui costă timp de calcul ori rata de pachete. Setul de reguli următor pentru /etc/nftables.conf lasă să treacă un server web și un serviciu de joc și elimină restul, cu o limitare de rată pentru conexiunile TCP noi pe fiecare adresă sursă:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Treceți la adminips propria dumneavoastră adresă fixă înainte să încărcați, altfel vă blocați singur accesul la SSH. Verificarea și activarea se fac așa:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Trei puncte decid asupra efectului. ct state established,related accept stă intenționat ca a doua regulă, pentru ca prin tot setul de reguli să nu treacă conexiunile existente. ct state invalid counter drop îndepărtează combinațiile de flaguri eronate și fragmentele întârziate, fără să fie nevoie să le descrieți pe fiecare în parte. Iar counter înaintea fiecărui drop este motivul pentru care știți ulterior care regulă a acționat: dacă rămân contoarele la zero, regula nu este atinsă, și acesta este un diagnostic complet diferit de un set de reguli fără efect.

SYN cookies și limita cozii de așteptare

SYN cookies sunt o metodă prin care serverul nu reține o conexiune pe jumătate deschisă, ci scrie datele necesare, criptate, în propriul lui număr de răspuns. Când se întoarce al treilea pachet al stabilirii conexiunii, el recalculează starea din acesta. Cu asta coada de așteptare nu mai este depășită, deoarece pentru aceste conexiuni nu există nicio coadă.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Aceste valori se pun într-un fișier sub /etc/sysctl.d/ și se preiau cu sysctl --system, altfel sunt pierdute după următoarea repornire. Pe Debian și Ubuntu, tcp_syncookies este pus din fabrică pe 1, ceea ce este corect. Valoarea 1 nu înseamnă „întotdeauna cookies”, ci „cookies de îndată ce coada de așteptare este depășită”.

Prețul pentru asta este real și este rar menționat. Într-un cookie nu este loc pentru opțiunile TCP ale părții opuse. Linux salvează mărirea ferestrei și confirmarea selectivă doar atunci când net.ipv4.tcp_timestamps este pus pe 1, deoarece atunci datele călătoresc odată cu marca de timp. Fără marcă de timp ele dispar, iar conexiunea rulează mai lent pentru tot restul duratei ei de viață. În plus, pentru dimensiunea maximă a pachetului sunt disponibili doar trei biți, deci opt trepte grosiere în locul valorii exacte. SYN cookies sunt un regim de avarie care salvează conexiuni, nu o setare pentru cazul normal.

conntrack: tabelul care se umple primul

Urmărirea conexiunilor din kernel creează o intrare pentru fiecare flux de pachete, și pentru UDP, deși UDP nu cunoaște conexiuni. Exact acest tabel este, la un atac distribuit, prima resursă care se termină, și se termină foarte repede: la 1,49 milioane de pachete pe secundă, fiecare cu o adresă de expeditor nouă, un tabel cu 262.144 de locuri este plin în mai puțin de o cincime de secundă.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

O intrare ocupă în jur de 300 de octeți, 524.288 de intrări deci în jur de 150 de megaocteți de memorie a kernelului. Mărimea tabelului hash nu se stabilește prin sysctl, ci ca parametru de modul, de obicei la un sfert din limita superioară, în /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Pentru un server pur de joc sau de voce, soluția mai elegantă este să nu lăsați traficul de joc să fie urmărit deloc. Asta economisește tabelul complet:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Atenție: notrack și regulile cu stare se exclud reciproc. Cine scoate un port din urmărire nu mai are voie să folosească pentru acel port nicio regulă cu ct state, altfel deschiderea nu mai are efect, iar serviciul este închis.

Limitare de rată pe fiecare adresă sursă

O limitare de rată pe fiecare adresă sursă este măsura individuală cea mai eficientă de pe server, deoarece lovește exact ceea ce face un atacator și lasă să treacă exact ceea ce face un utilizator. Diferența este mare: un browser de servere real interoghează de câteva ori pe minut, un atacator de sute de ori pe secundă. Cu nftables se lucrează pentru asta cu mulțimi dinamice, ca în setul de reguli de mai sus, cu iptables clasic cu hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Toate cifrele din asemenea reguli sunt valori de pornire, nu adevăruri. Măsurați mai întâi o săptămână în regim normal, altfel vă dați afară propriii utilizatori, și asta în cel mai prost moment. Rețineți în plus că regulile iptables pure sunt pierdute după o repornire (apt-get install -y iptables-persistent, apoi netfilter-persistent save) și că sub UFW ele se pun în /etc/ufw/before.rules, deoarece altfel dispar la următorul ufw reload. Setul complet de reguli pentru exploatarea curentă se află în Protejarea serverelor împotriva atacurilor DDoS.

Unde se termină orice filtrare de pe server

Acum partea pe care niciun fișier de configurare nu o rezolvă. Toate măsurile de până acum rulează pe serverul dumneavoastră, deci la capătul conexiunii. O regulă de firewall decide asupra unui pachet care a trecut deja prin cablu. Îl puteți elimina, dar nu îl puteți face netrimis. Dacă conexiunea din fața lui este plină, pachetele utilizatorilor dumneavoastră nu mai ajung nici înainte de asta, și anume indiferent cât de bun este setul dumneavoastră de reguli.

Acest tabel răspunde, pentru fiecare caz în parte, la întrebarea dacă autoprotecția este suficientă. Atacul asupra GitHub, cu 126,9 milioane de pachete pe secundă, încape la limită, ca rată de pachete, pe o conexiune de 100 Gbit/s, dar pentru cei 1,35 Tbit/s de volum ar fi nevoie de paisprezece dintre ele simultan. Atacul record de 31,4 Tbit/s corespunde cu 314 de conexiuni de 100 Gbit/s complet saturate. Un server de joc atârnă de regulă la 1 Gbit/s sau la de două ori 1 Gbit/s: limita autoprotecției se află astfel la în jur de 1,5 până la 3 milioane de pachete pe secundă, și practic vizibil sub atât, deoarece kernelul cedează mai devreme.

Mai există o a doua limită, mai neplăcută. De îndată ce conexiunea este saturată, este posibil să nu vă mai ajungă nici măcar sesiunea SSH cu care voiați să măsurați. Cine nu are atunci un acces independent de rețea, de exemplu o consolă VNC în panoul clientului, nici nu mai poate să se uite ce se întâmplă.

Ce ajută doar în fața serverului: filtrarea în rețea și scrubbing

Poate filtra eficient doar cine are mai multă capacitate decât atacul. Asta presupune un loc în care se adună multe conexiuni, deci o rețea, nu o mașină. Acolo există două metode, care se completează.

Filtrare în timp real în rețea. Tot traficul trece permanent printr-o treaptă de filtrare, care evaluează fiecare pachet înainte să fie predat serverului. Avantajul este că nu există nicio comutare: protecția nu trebuie să recunoască mai întâi un atac pentru a avea efect. Exact asta este decisiv la jocuri, deoarece un timp de comutare de două minute este o rundă pierdută, iar un timp de comutare de două minute la un atac care durează 35 de secunde nu este nicio apărare.

Scrubbing. Dacă rețeaua recunoaște un atac volumetric mare, traficul afectat este deviat către centre de filtrare, este eliberat acolo de părțile dăunătoare și este apoi livrat în direcția țintei. Sensul acestei devieri este apropierea: traficul de atac se termină în locul în care intră, în loc să ajungă abia la centrul de date. Regulile de filtrare sunt distribuite pentru asta în rețea, descrise tehnic în RFC 8955 ca Flow Specification.

Contramăsura structurală împotriva adreselor de expeditor falsificate este de altfel cunoscută din anul 2000 și se află în RFC 2827, adică BCP 38: cine racordează un client elimină la această graniță toate pachetele a căror adresă de expeditor nu aparține acelui client. RFC 3704 extinde asta la rețelele racordate multiplu. Dacă toți operatorii de rețea ar pune asta în practică, întreaga clasă a atacurilor de amplificare ar fi rezolvată. Nu este, deoarece este suficient ca unii să nu o facă.

Și mai există o a treia metodă, pe care trebuie să o cunoașteți, deoarece este adesea vândută ca protecție: nullrouting, tehnic Remote Triggered Black Hole Filtering după RFC 5635. Acolo adresa IP atacată este anunțată în rețea ca inaccesibilă, tot traficul către ea este eliminat, traficul de atac la fel ca cel al utilizatorilor dumneavoastră. Asta protejează rețeaua furnizorului, pentru dumneavoastră rezultatul este identic cu un atac reușit, și de obicei încă ore după aceea. Întrebați la nevoie dacă se filtrează sau se face nullrouting. Răspunsul decide mai mult asupra disponibilității dumneavoastră decât orice specificație de hardware.

Ce opune KernelHost

Protecția permanentă, inclusă în fiecare pachet de server

Protecția DDoS de la KernelHost este construită pe două niveluri și este activă permanent, fără să fie nevoie să activați, să comandați sau să configurați ceva:

• Nivelul 1: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing. Atacurile volumetrice sunt curățate aproape de sursa lor, înainte să ajungă la centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps la Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate modelele specifice fiecărui protocol, pachet cu pachet.

Două proprietăți sunt decisive. Protecția rulează permanent și este activă de la livrarea serverului, deci nu există minute la începutul unui atac în care serviciul lipsește. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, eliminate sunt doar pachetele dăunătoare. Ce jocuri și protocoale au profile de filtrare proprii le enumeră Protecție DDoS în timp real pentru servere de joc.

Advanced DDoS Protection pentru proiectele atacate permanent

Unele proiecte nu sunt atacate ocazional, ci țintit și săptămâni la rând, în fiecare seară la aceeași oră și cu modele schimbătoare. Pentru asta există Advanced DDoS Protection de la 50,00 € pe lună, PrePaid, fără durată minimă și fără taxă de instalare. Diferența nu stă în mai multă capacitate, ci în control:

• IP de protecție dedicat din nucleul de la Frankfurt, pe care serverul dumneavoastră este comutat în propria noastră rețea. De partea dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră, pe fiecare port și protocol în panoul clientului: setați separat ce este permis pe portul de joc și ce pe portul de interogare și puteți folosi astfel exact asimetria din secțiunea despre protocoalele de interogare.
• Modificările se aplică în timp real, deci puteți ajusta în timpul unui atac în curs, în loc să așteptați o fereastră de mentenanță.
• Profil de protecție potrivit fiecărui serviciu, la fel și pentru aplicații modificate și scrise de dumneavoastră, pe orice porturi TCP sau UDP.

Advanced DDoS Protection se adresează clienților KernelHost și presupune un server la KernelHost. Dacă proiectul dumneavoastră rulează momentan în altă parte și este atacat acolo în mod regulat, mutarea aici este calea, nu o îngrijire de la distanță a adresei dumneavoastră de până acum.

Cele două niveluri în comparație

Patru atacuri reale filtrate în exploatare

Următoarele patru atacuri au lovit servere ale unor clienți KernelHost și au fost filtrate complet în timp real, de fiecare dată fără întrerupere. Imaginile provin din monitorizarea live a apărării.

Server de voce TeamSpeak 3, portul 9987 UDP. Atac complex cu mai multe modele simultane, peste 473,4 Gbit/s și peste 41,5 milioane de pachete pe secundă. Aceasta este în jur de rata de pachete înmulțită cu 28 a unei conexiuni de 1 Gbit/s.

Server de joc ARK, portul 7777 UDP. Flood UDP simplu, fără structură complexă, în schimb peste 112,2 Gbit/s și peste 8,7 milioane de pachete pe secundă. Cum se securizează un cluster ARK pe lângă asta scrie în Protejarea serverelor ARK împotriva DDoS.

Atac pe toate porturile, porturile 0-65535 TCP și UDP. Peste douăsprezece modele principale de atac diferite împotriva tuturor porturilor simultan, în total peste 21,3 Gbit/s și peste 3,9 milioane de pachete pe secundă. Acest caz arată împrăștierea peste toate porturile, pe care o prezintă și cazul Cloudflare din mai 2025, cu în medie 21.925 de porturi țintă.

Minecraft și OpenVPN, porturile 25565 TCP și 1194 UDP. Atac combinat cu peste șaisprezece modele principale de atac diferite, peste 4 milioane de pachete pe secundă și peste 8,6 Gbit/s. Ambele servicii au rămas accesibile permanent, deși vorbesc protocoale diferite.

Ce este de făcut în caz de atac, în această ordine

Ordinea este mai importantă decât pașii în sine, deoarece cele mai frecvente greșeli se întâmplă în primele cinci minute.

1. Măsurați, nu modificați. Salvați mai întâi valorile din sar -n DEV 1 10, ip -s link show, ss -s și dmesg -T într-un fișier. După atac ele nu mai există, iar fără ele nu vă poate ajuta nimeni.
2. Nu reporniți. O repornire șterge toate contoarele, toate stările conexiunilor și orice dovadă, iar încărcarea este din nou acolo după câteva secunde.
3. Stabiliți ce nivel este. Octeții împărțiți la pachete dau dimensiunea medie a pachetului. Sub 100 de octeți arată către un atac asupra protocolului, peste 1.000 de octeți către un atac de amplificare, dimensiuni normale la o încărcare mare a procesorului către layer 7.
4. Închideți porturile de administrare. Panoul, baza de date, RCON și tot ce nu trebuie să fie public se restrânge la propria dumneavoastră adresă. Asta reduce suprafața de atac imediat și fără risc pentru utilizatori.
5. Puneți o limitare de rată, strânsă pe portul de interogare, largă pe portul de utilizare. Nu blocați portul de interogare, altfel dispăreți din orice listă de servere.
6. Nu vă schimbați pripit propria adresă. O schimbare de adresă are efect doar cât timp adresa nouă nu apare din nou public, iar o intrare DNS veche și uitată face schimbarea ineficientă.
7. Implicați furnizorul cu cifre. Deschideți un tichet cu momentul, portul țintă, rata de pachete, lățimea de bandă și dimensiunea medie a pachetului. Aceste cinci date decid cât de repede sunt ajustate regulile de filtrare pentru adresa dumneavoastră.
8. Documentați după aceea. Rețineți când a început, cât a durat și care model a fost. Atacurile repetate la aceeași oră sunt criteriul după care se decide dacă un proiect are nevoie de un IP de protecție dedicat.

Desfășurarea detaliată pentru un atac greu, care durează mai mult, se află în Atac DDoS sever: ce faceți?.

Situația juridică: un atac DDoS este o infracțiune

În Austria, un atac DDoS intră sub incidența § 126b din Codul penal austriac (StGB), „Perturbarea funcționalității unui sistem informatic”. Fapta de bază prevede pedeapsă cu închisoarea de până la șase luni sau o amendă de până la 360 de zile-amendă. Dacă perturbarea durează mai mult timp, sunt până la doi ani. Dacă sunt atacate multe sisteme cu un program creat vizibil în acest scop, sunt până la trei ani. Iar în cazul unei pagube de peste 300.000 de euro, în cazul unui atac asupra infrastructurii critice sau ca membru al unei organizații criminale, cadrul este de la șase luni până la cinci ani. Suplimentar, § 126c din Codul penal austriac pedepsește deja producerea, răspândirea și punerea la dispoziție a programelor destinate acestui scop.

În Germania se aplică § 303b din Codul penal german (StGB), „Sabotaj informatic”: până la trei ani de închisoare sau amendă, până la cinci ani atunci când prelucrarea datelor servește unei exploatații, unei întreprinderi sau unei autorități, iar în cazuri deosebit de grave de la șase luni până la zece ani, de exemplu în cazul faptelor comise cu titlu profesional sau în cazul afectării infrastructurii critice. Tentativa este pedepsită, iar pentru actele pregătitoare, § 303b alin. 5 din Codul penal german trimite la § 202c din același cod.

Serviciile booter și stresser nu sunt de aceea o zonă gri, ci partea plătită a unei infracțiuni. Trei puncte sunt în mod regulat înțelese greșit. În primul rând, mențiunea „doar pentru teste la sarcină ale sistemelor proprii” nu face nimic legal, deoarece serviciile nu verifică cui îi aparține ținta introdusă. În al doilea rând, este pedepsit și cel care comandă atacul, nu doar operatorul: Europol a contactat în scris, după săptămâna de acțiune din aprilie 2026, în mod expres peste 75.000 de utilizatori identificați, tocmai pentru a clarifica acest lucru. În al treilea rând, nici un test la sarcină asupra propriului server printr-un asemenea serviciu nu este o soluție, deoarece traficul de atac trece prin rețeaua furnizorului și astfel peste conexiunile altor clienți, ceea ce orice contract de găzduire interzice. Cine vrea într-adevăr să măsoare rezistența serviciului său o face anunțat și în înțelegere cu furnizorul. Această secțiune redă stadiul legislației și nu este consultanță juridică.

Ghidul potrivit pentru serviciul dumneavoastră

Acest articol explică principiul. Care port trebuie să fie deschis, care directivă de configurare limitează care interogare și unde se află limita la fiecare joc: asta scrie în articolele despre serviciul individual, de fiecare dată cu tabelul de fapte al porturilor.

• Bazele și desfășurarea: Recunoașterea unui atac DDoS, Protejarea serverelor împotriva atacurilor DDoS, Atac DDoS sever: ce faceți?, Protecție DDoS pentru jocuri cu filtrare în timp real
• Minecraft și voce: Minecraft și Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Jocuri de rol pe bază de GTA: FiveM, RedM, RAGE MP și alt:V, SA-MP și open.mp, MTA:SA
• Supraviețuire și construcție: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Tactică și trageri: CS2 și Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Pe scurt

• Un atac DDoS ocupă una dintre patru resurse finite: lățimea de bandă, rata de pachete, un tabel de stare al kernelului sau timpul de calcul al aplicației. El nu folosește nicio vulnerabilitate, de aceea actualizarea singură nu protejează.
• RFC 4732 definește un atac DoS prin efect, nu prin numărul surselor. Distribuit se numește atunci când sursele sunt numeroase: în cazul Cloudflare din mai 2025 au fost 122.145 de adrese din 161 de țări.
• CISA, FBI și MS-ISAC deosebesc trei tehnici: volumetrică în Gbit/s, la nivel de protocol în pachete pe secundă, la nivel de aplicație în cereri pe secundă. Fiecare are nevoie de altă apărare.
• Atacurile de amplificare folosesc abuziv servicii UDP deschise. Factorii merg de la 5,5 la protocolul Steam, prin 30,8 la SSDP și 556,9 la NTP, până la 51.000 la memcached, de citit în US-CERT TA14-017A.
• Capacitatea vine din botneturi de dispozitive preluate, de la 600.000 la Mirai în anul 2016 până la estimat unu până la patru milioane în spatele atacului record de 31,4 Tbit/s, și este revândută de la în jur de 10 euro pe lună.
• Pe server au efect nftables, SYN cookies, limitele conntrack ajustate și limitarea de rată pe fiecare adresă sursă. Ele se termină la în jur de 1,5 milioane de pachete pe secundă, deoarece o conexiune de 1 Gbit/s nu transportă mai mult.
• Peste această limită decide exclusiv filtrarea din rețeaua din fața serverului. Nullrouting nu este o apărare, ci rezultatul pe care îl voia atacatorul.
• La KernelHost, protecția permanentă pe două niveluri este inclusă în fiecare pachet de server fără cost suplimentar și este activă de la livrare, fără nullrouting: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing plus filtrare Arbor în timp real cu 3,2 Tbps la Frankfurt pe Main. Advanced DDoS Protection o completează, de la 50,00 € pe lună, cu un IP de protecție dedicat și cu reguli administrabile de dumneavoastră pe fiecare port.
• Un atac DDoS este pedepsit în Austria potrivit § 126b din Codul penal austriac și în Germania potrivit § 303b din Codul penal german, pentru cel care îl comandă la fel ca pentru operatorii serviciilor.

Dacă proiectul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să fie nevoie să faceți ceva. Dacă observați totuși lucruri ieșite din comun, deschideți un tichet de suport cu cele cinci date din pasul 7, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În cazul unui atac în curs ne găsiți în plus prin chatul de urgență WhatsApp la +43 650 8209883.