Protezione e filtraggio dei pacchetti DDoS

Breve riepilogo

Gli attacchi DDoS sono di tre classi: L3/L4 volumetric (segnare il canale/hardware), state-exhaustion (esauriscono le tabelle di stato/CPU su bilancini/file) e L7 (generano richieste di applicazione «plausibili»). Le difese efficaci si basano su più livelli: misure di rete sul perimetro, filtraggio/scrabbing fuori dalla rete, protezione su bilanci/proxy e applicazione, e procedure operative con SLO misurabili.

Paesaggio delle minacce

Volume (UDP/ICMP flood, amplificazione DNS/NTP/SSDP/CLDAP/Memcached) - L'obiettivo è segnare il canale e le porte.
TCP state-exhaustion (SYN/ACK flood, TCP fragmentation, connessioni a mezzo strato) - Esaurisce il connack/listener.
L7 HTTP (S )/ WebSocket/GraphQL flood, cache-busting, richieste «lente»: mangiare CPU/IO delle applicazioni e dei livelli cache.
Riflection/Amplificazione - Utilizzo di riflettori/amplificatori aperti con sottomenu di origine IP.
Carpet bombing - Distribuire il traffico in molti prefissi IP, rendendo più difficile il filtraggio a punti.

Misure di rete di base (prima degli attacchi)

1. Antispoofing: uRPF/BCP38 al confine; drop di sacchetti in uscita con sorgenti estranee.
2. ACL su edge/PE: divieto di protocolli/porte indesiderati elenchi separati per il segmento mgmt.
3. CoPP (Control Plane Policing) - Polising al router (BGP, OSPF, SSH, SNMP).
4. Rate-limits/polising alle porte: bps/PPS per classi «rumorose», impostazioni burst.
5. Distribuzione del carico di lavoro: Anycast per IP pubblici, georassici; CDN/WAAP per statico e cache.
6. RPKI/ROA + importazione rigorosa di BGP: riduce il rischio di highjeck/reindirizzamento del traffico.
7. Surface reduction: minimizza i servizi pubblicati, chiudi origin crude dietro proxy.

Risposta rapida all'attacco: strumenti di rete

RTBH (Remote Triggered Blackhole): BGP-Committee per il percorso zero/32 (o/128) della vittima.
BGP Flowspec: rapida diffusione delle regole L3/L4 (src/dst/porta/flag TCP) a PE/edge.
provider Scrubbing/anti-DDoS: tunnel GRE/VRF o upstream diretto; filtraggio, quindi traffico «pulito» verso di voi.
Anycast-antiDDoS: separazione del flusso per presenza, localizzazione del danno.
CDN/edge-cache: mostra origin, fornisce limiti L7 e meccanismi «challenge».

Protezione host e L4

SYN cookies/SYNPROXY - Non mantenere lo stato fino alla conferma del client.

Linux: `sysctl net. ipv4. tcp _ syncookies = 1 'o' SYNPROXY'sul bilanciatore di ingresso.

• Modera «nf _ conntrack _ max» ragionevolmente aumentando hassize;
• Ridurre i timeout per gli stati semiaperti e inattivi.
• eBPF/XDP: drop precoce su protezione NIC (PPS), filtraggio su firme/velocità fino al kernel.
• nftable/iptable: limiti per PPS, flag sospette, connlimit.
• UDP hardening: se il servizio non utilizza un drop UDP al confine; se utilizza - limitare le sorgenti/porte.

nft table inet filter {
sets {
bad_ports { type inet_service; elements = { 19, 1900, 11211 } } # chargen/SSDP/memcached
}
chains {
input {
type filter hook input priority 0; policy drop;
ct state established,related accept ip saddr 127. 0. 0. 0/8 drop ip6 saddr::1/128 drop

limit new TCP tcp flags & (syn    ack) == syn limit rate 200/second burst 400 accept tcp flags & (syn    ack) == syn drop

deny bad UDP ports udp dport @ bad _ ports drop

ICMP rate-limit icmp type echo-request limit rate 50/second burst 100 accept icmpv6 type echo-request limit rate 50/second burst 100 accept
}
}
}

bash iptables -t raw -A PREROUTING -p tcp --syn -j CT --notrack iptables -A INPUT -p tcp -m tcp --syn -m hashlimit --hashlimit 100/second --hashlimit-burst 200 --hashlimit-mode srcip --hashlimit-name syns -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m state --state INVALID -j DROP

Protezione L7 (breve)

WAAP/WAF: modello positivo su percorsi critici, rate-limits, challenge/JS, tracciamento comportamentale.
Cache/offload statico: riduce le richieste a origin; Protezione da cache-busting (normalizzazione/black list parametri).
restrittivi « », « », inibizione introspection in .
BFF-pattern: token client sottili, logica pesante/limiti sul server.
Idampotenza e code: impediscono ripetizioni di valanga in caso di degrado.

Telemetria e rilevamento

Flussi di rete: NetFlow/sFlow/IPFIX (pps, top talkers, protocolli/porte/ASN).
Sensori passivi L7: loghi di bilanciatori/proxy (nginx/avvoy), metriche p95/99, errato-rate.
Le soglie di base sono: «crescita inaspettata di PPS/CPU su edge», «picco SYN-RECV», «UDP inappropriato».
Firme/comportamento: frequenze IP/ASN/JA3, picchi 4xx/5xx, anomalie user-agente.
Visualizzazione: singoli dashboard L3/L4/L7; mappa del traffico geo/ASN; Tempo fino all'attivazione di RTBH/Flowspec.

SLO/SLI e alerting

• MTTD anomalie 60 secondi, MTTM (attivazione RTBH/Flowspec) 3 min.
• "p95 latitanza via edge 50 ms fuori dagli attacchi; all'attacco di 200 ms sotto mitigazione".
• «La percentuale di traffico malevolo deviato è del 99%, mantenendo il 98% di legittimo».

• PPS/CPU/IRQ nodi di rete> soglia;
• SYN-RECV/half-open > X;
• Altezza 5xx/latency negli endpoint pubblici;
• percentuale di challenge/deny WAF> soglia (rischio FP).

Cartelli di difesa architettonici

1. Tiered Defense: Edge (ACL/CoPP) → Scrubbing/Anycast → L7-proxy/WAAP → Applicazione.
2. Commutazione Traffic: BGP community per screabbing, GRE-Beckhol per il picco.
3. Stateless Edge: filtraggio massimo stateless fino al conntrack stateful - più vicino all'applicazione.
4. eBPF/XDP First: drop iniziali (JA3/porte/velocità) fino al nucleo.
5. Golden Paths: singoli domini IP per API critiche per non «demolire» tutto.

Procedure operative e incidenti

Runbooks: chi e quali metriche include RTBH/Flowspec/Scrabbing, come cambiare Anycast/pool.
Black List e TTL: blocco a breve termine per non «sovraccaricare»; e-test automatico delle sorgenti.
Comunicazioni: modelli di messaggio a provider/partner/venditori; canale di comunicazione esterno al dominio da attaccare.
Post-Inserent - Report con linea temporale (T0... Tn), «che ha funzionato/no», aggiornamento della directory di prova.
Esercitazioni: game-days regolari: dry-run RTBH, perdita della regione Anycast, Linetta saturazione, attacchi «lenti».

Tuning Linux/Bilanciatori (campionamento)

bash
TCP sysctl -w net. ipv4. tcp_max_syn_backlog=4096 sysctl -w net. ipv4. tcp_syncookies=1 sysctl -w net. ipv4. tcp_fin_timeout=15 sysctl -w net. ipv4. tcp_tw_reuse=1

Conntrack (if enabled)
sysctl -w net. netfilter. nf_conntrack_max=1048576 sysctl -w net. netfilter. nf_conntrack_tcp_timeout_syn_recv=30 sysctl -w net. netfilter. nf_conntrack_udp_timeout=15

NIC/IRQ ethtool -G eth0 rx 4096 tx 4096

Errori frequenti

Mantenere tutto il traffico attraverso stateful-firewall su edge esaurimento conntrack. Fate stateless dove potete.
Il canale RTBH/Flowspec è già a zero. Automatizzare le soglie e l'attivazione.
Un fronte IP per «tutto» non c'è isolamento blast radius. Dividere i domini/IP e le quote.
Cache zero ogni chiamata L7 colpisce origin; attivare la cache e la normalizzazione dei parametri.
Blocco cieco dei paesi/ASN senza analisi della legite - taglia la conversione; Usate le regole di sfumatura/challenge.
Limiti troppo aggressivi, FP di massa all'apice del business.

Road map di implementazione

1. Valutazione della superficie: inventario IP/prefissi/porte/protocolli, mappa dei percorsi critici.
2. Igiene della rete: antispoofing, ACL, CoPP, RPKI/ROA, abbandono di servizi UDP in eccesso.
3. Diversione del traffico: contratto con scrabbing provider, Anycast/CDN, BGP communities.
4. Edge-tuning: filtraggio stateless, SYNPROXY/eBPF, timeout conntrack ragionevole.
5. L7/WAAP: modello positivo, limiti/challenge, cache.
6. Osservazione: NetFlow/sFlow, L3/L4/L7, alert, SLO.
7. Automazione: pulsanti RTBH/Flowspec, IaC per le regole, fogli di configurazione.
8. Esercitazioni e RCA: test regolari, aggiornamento playbook.

Caratteristiche iGaming/Fintech

Eventi di punta (tornei, promozioni, partite): pianifica capacity/limiti, riscaldamento della cache, pre-warming CDN.
Integrazione dei pagamenti: privilegi IP/domini dedicati, canali prioritari tramite provider anti-DDoS, PSP, limiti rigorosi per endpoint critici.
Anti-frod/bot control: schizzi comportamentali e challenge umani in registrazione/login/bagnato.
UX e conversione: in caso di protezione aggressiva, utilizzare fogli grace per VIP/partner, degrado morbido (cache/readonly).
Requisiti legali: trasparenza dei registri, memorizzazione della telemetria, debug dell'impatto delle misure su Time-to-Wallet e metriche di circolazione.

Esempi: Flowspec e RTBH (concettuale)

route 203. 0. 113. 10/32 blackhole set community 65535:666 announce to upstream

match destination 203. 0. 113. 0/24 protocol = udp destination-port {19,1900}
then rate-limit 1000

FAQ

La WAF decide il DDoS?
In parte per la L7. Contro L3/L4 e volumetric è necessario uno screabbing/Anycast/misure di rete.

I cookie SYN sono sufficienti?
Si tratta di una protezione di base contro SYN-flood, ma senza limiti di rete o scrabbing è comunque possibile segnare il canale.

È necessario disattivare l'ICMP?
No, no. Meglio rate-limit e solo tipi pericolosi, ICMP è utile per la diagnosi/PMTU.

Un tunnel GRE con scrubbing non aggiungerà la latitanza?
Sì, ma di solito è accettabile. Compensa con una cache e un percorso preciso fino al PoP più vicino.

Totale

La protezione DDoS affidabile è un'architettura su più livelli: igiene di rete (antispoofing/ACL/CPP), sabotaggio rapido del traffico (RTBH/Flowspec/scrubbing/Anycast), host e L7 (SYNPROXY, eBPF/XDP) (WAAP), più telemetria, SLO e playbook regolati. Questo approccio riduce al minimo la complessità, mantiene vivi i canali e mantiene le metriche aziendali anche sotto la pressione di attacchi distribuiti.