Rulează orice cu un IP public suficient de mult timp și vei da peste un atac de tip denial-of-service. Partea incomodă e că nu există un singur control care să le rezolve pe toate: tehnica ce absoarbe o reflecție UDP de 200 Gbps e inutilă împotriva a 100k cereri pe secundă de HTTP perfect valid.
Acesta e un tur al straturilor, ce costă fiecare și unde se oprește fiecare din a mai funcționa. E scris din perspectiva operatorului, nu ca o prezentare de produs.
Peisajul amenințărilor
Tipurile de atac cu care se confruntă de obicei un operator de rețea:
| Tip de atac | Volum tipic | Protocol |
|---|---|---|
| Reflecție UDP (DNS, NTP, memcached) | 10–400 Gbps | UDP |
| SYN flood | 1–50 Mpps | TCP |
| HTTP flood (L7) | 50k–500k RPS | HTTP/S |
| Carpet bombing (împrăștiat pe un /24) | 50–200 Gbps | Mixt |
| GRE/IP-in-IP flood | 10–100 Gbps | GRE |
Ideea-cheie: atacurile volumetrice și cele la nivel de aplicație necesită strategii de mitigare complet diferite. O singură soluție nu e de ajuns.
Observă volumele. Mare parte din tabelul de mai sus depășește de-a dreptul capacitatea de transit a unei rețele mici sau medii — exact motivul pentru care există straturile din amonte de mai jos. Dacă un atac e mai mare decât portul tău, nimic din ce faci pe propriile routere nu te va salva, pentru că blocajul e deja în amonte de ele.
Stratul 1: filtrare la furnizorul de transit
Prima linie de apărare e înainte ca traficul să ajungă la routerele tale. Lucruri pe care merită să le aranjezi cu fiecare furnizor de transit:
- Filtrarea bogon-urilor — adresele RFC 1918, spațiul nealocat și propriile tale prefixe nu ar trebui să sosească niciodată dinspre transit
- Rate-limit pe ICMP — nu există niciun caz legitim de utilizare pentru gigabiți de ICMP
- Blackholing pe bază de community — etichetezi un prefix cu community-ul de blackhole al furnizorului (RFC 7999 definește unul well-known) și el îl aruncă în amonte, înainte să ajungă la portul tău
Blackholing-ul e un instrument brut: îndeplinește scopul atacului pentru adresa vizată, dar salvează tot restul. Schimbul ăsta merită de obicei și e adesea singura pârghie care funcționează când atacul e mai mare decât capacitatea ta.
Stratul 2: BGP Flowspec
Flowspec distribuie reguli de filtrare a traficului prin BGP. Gândește-te la el ca la o regulă de firewall care se propagă pe fiecare router de edge în câteva secunde.
# Drop UDP traffic to a specific host on port 53
# (a common DNS amplification target)
flow {
match destination 185.x.x.10/32;
match protocol udp;
match destination-port 53;
then discard;
}
Puterea Flowspec e viteza și acoperirea. Un singur update BGP și fiecare router de edge aruncă traficul — fără SSH pe routere, fără modificări manuale de ACL-uri. E mult mai chirurgical decât un blackhole, pentru că poate face match pe protocol și port, în loc să arunce tot ce merge către o adresă.
Un lanț tipic de automatizare arată așa:
- sFlow eșantionează pachete la, să zicem, 1:1000
- FastNetMon analizează flow-urile în timp real
- La detecție, împinge o regulă Flowspec prin ExaBGP
- Routerele de edge încep să arunce traficul în câteva secunde
Avertismentul: regulile Flowspec sunt în continuare aplicate pe propriile tale routere, deci traficul a traversat deja link-ul de transit. Protejează rețeaua din spatele edge-ului, nu edge-ul în sine.
Stratul 3: filtrare XDP/eBPF
Pentru atacurile care au nevoie de mai multă inteligență decât „aruncă tot UDP-ul către portul X”, XDP (eXpress Data Path) rulează un program de filtrare la nivelul driverului de NIC, înainte de stiva de rețea a kernelului — astfel că pachetele pot fi inspectate și aruncate la rate mari, cu un cost modest de CPU.
// Simplified XDP program — drop packets matching an attack signature
SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx) {
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;
struct ethhdr *eth = data;
if ((void *)(eth + 1) > data_end)
return XDP_PASS;
if (eth->h_proto != htons(ETH_P_IP))
return XDP_PASS;
struct iphdr *ip = (void *)(eth + 1);
if ((void *)(ip + 1) > data_end)
return XDP_PASS;
if (ip->protocol == IPPROTO_UDP) {
struct udphdr *udp = (void *)ip + (ip->ihl * 4);
if ((void *)(udp + 1) > data_end)
return XDP_PASS;
// Check against attack signatures in a BPF map
if (is_attack_signature(udp, data_end))
return XDP_DROP;
}
return XDP_PASS;
}
XDP își merită locul pentru:
- SYN flood — validare de SYN cookie la viteza firului
- Carpet bombing — rate limiting per IP pe un întreg /24, fără să faci blackhole traficului legitim
- Anomalii de protocol — aruncarea pachetelor malformate înainte să irosească CPU
Stratul 4: centre de scrubbing
Pentru atacurile volumetrice care depășesc capacitatea portului tău, traficul e deviat printr-un furnizor de scrubbing folosind BGP:
- Atacul e detectat
- Prefixul vizat e anunțat către furnizorul de scrubbing
- Traficul trece prin scrubber, care elimină traficul de atac
- Traficul curat e tunelat înapoi peste GRE
- Când atacul se oprește, anunțul e retras și traficul circulă din nou direct
Acesta e stratul care rezolvă cu adevărat atacurile mai mari decât propria ta capacitate, pentru că scrubbing-ul se întâmplă pe rețeaua mult mai mare a altcuiva. Costul e latența — ocolul prin tunel e real — așa că e de obicei rezervat atacurilor pe care straturile mai ieftine nu le pot absorbi.
Stratul 5: protecție la nivel de aplicație
Atacurile L7 ocolesc tot ce e mai sus, pentru că folosesc conexiuni TCP legitime și cereri bine formate. Nu există nicio semnătură de pachet pe care să faci match. Uneltele de aici sunt diferite:
- Rate limiting per IP, per sesiune, per endpoint
- Pagini de challenge — provocări proof-of-work sau JavaScript pe care boții simpli le pică
- Analiză comportamentală — utilizatorii legitimi nu cer același endpoint de 1000 de ori pe secundă cu headere identice
- Reguli WAF — blocarea tiparelor de atac (SQLi, XSS) amestecate adesea în campaniile DDoS
Detecție: să vezi atacurile înainte să lovească
Nu poți mitiga ce nu poți vedea. Un pipeline convențional de detecție:
sFlow (sampled packets)
→ FastNetMon (real-time flow analysis)
→ Anomaly detection (baseline comparison)
→ Threshold alerts + auto-mitigation
→ Dashboard (visibility)
→ On-call notification (if manual intervention is needed)
Baseline-urile contează mai mult decât pragurile absolute. Un server de gaming care primește în mod normal 5 Gbps de UDP nu e alarmant; un server web care primește brusc 5 Gbps de UDP e, cu siguranță. Un prag fără un baseline în spate produce fie alarme false în continuu, fie tăcere.
O notă despre detecție vs. mitigare
Merită să fim preciși, pentru că cele două se confundă în textele de marketing: a detecta un atac și a-l opri sunt capabilități separate. Un IDS în mod alert-only îți dă vizibilitate și nimic altceva — traficul e inspectat, logat și livrat exact așa cum ar fi fost oricum.
E un punct de plecare legitim. Blocarea inline vine cu propriul ei risc: un filtru care aruncă un procent din traficul real poate costa mai mult decât atacul. Să rulezi mai întâi detecția, să capeți încredere în ce ar fi prins regulile și abia apoi să le armezi este calea conservatoare.
Doar nu lăsa un dashboard plin de detecții să fie confundat cu mitigarea.
Lecții
- Automatizează — mitigarea manuală e prea lentă pentru atacurile moderne
- Apără pe straturi — nicio unealtă singură nu acoperă toate tipurile de atac
- Cunoaște-ți plafonul — dacă un atac depășește capacitatea ta de transit, doar straturile din amonte ajută
- Urmărește rata de fals-pozitive — un filtru care aruncă trafic legitim e un outage pe care ți l-ai provocat singur
- Comunică — clienții ar trebui să vadă datele despre atac pe un dashboard, nu să afle de pe Twitter
Articole conexe
Vezi harta amenințărilor pentru detecțiile pe care le publicăm de la edge-ul AS210622, sau pagina rețelei noastre pentru cum e construită rețeaua.
