DDoS Reflected e Amplification Attack

Un DDoS Reflected sfrutta server terzi legittimi come amplificatori involontari: l'attaccante invia richieste con IP sorgente falsificato (quello della vittima) a server come DNS, NTP o Memcached. Questi server, senza sapere di essere usati come armi, inviano le loro risposte massive direttamente alla vittima. L'attaccante rimane nascosto e moltiplica il suo volume di attacco senza investire banda proporzionale.

Mappa globale

#

IP Spoofing - il prerequisito del Reflected DDoS

#

Il Reflected DDoS non e' possibile senza IP spoofing: l'attaccante deve falsificare l'IP sorgente dei propri pacchetti con l'IP della vittima, in modo che le risposte dei server terzi vadano alla vittima invece che a lui. Questo e' il principio su cui si basa tutta la tecnica.

Un kernel normale inserisce automaticamente il proprio IP come sorgente nei pacchetti. Per falsificarlo si usano i raw socket, che richiedono privilegi root/admin e permettono di costruire il pacchetto IP campo per campo.

# Scapy - DNS ANY query con IP sorgente spoofato
from scapy.all import *
send(IP(src="vittima.ip", dst="dns.server") / UDP(dport=53) / DNS(rd=1, qd=DNSQR(qname="example.com", qtype="ANY")))

Perche' funziona solo con UDP, non TCP: con TCP il three-way handshake tradisce l'attacco. Il server manda il SYN-ACK all'IP della vittima (non all'attaccante). La vittima riceve un SYN-ACK per una connessione che non ha mai aperto, e risponde con RST. La connessione non si stabilisce e non c'e' amplificazione. Solo UDP, essendo connectionless, permette al reflector di rispondere senza verifica.

Attaccante → SYN [src = vittima] → Server reflector
Server      → SYN-ACK           → vittima (non attaccante)
Vittima     → RST               → Server (non sa nulla di quel SYN)
Connessione non completata - nessuna amplificazione

Reflected DDoS - il flusso

#

Il principio base del Reflected DDoS: l'attaccante non manda il traffico direttamente alla vittima, lo fa fare a un terzo.

flowchart LR
    %% Nodi globali
    ATT["Attaccante"]
    REFL1["Server DNS legittimo"]
    REFL2["Server NTP legittimo"]
    REFL3["Server Memcached"]
    VITT["Vittima"]
    NOTA["Traffico massivo
    mai richiesto dalla vittima"]

    %% Flusso attacco
    ATT -->|"Richiesta [src = IP vittima]"| REFL1
    ATT -->|"Richiesta [src = IP vittima]"| REFL2
    ATT -->|"Richiesta [src = IP vittima]"| REFL3
    REFL1 -->|"Risposta 50x"| VITT
    REFL2 -->|"Risposta 500x"| VITT
    REFL3 -->|"Risposta 50.000x"| VITT
    VITT --- NOTA

    style VITT fill:#5c1a1a,color:#ffffff
    style ATT fill:#2a1a00,stroke:#f0c040,color:#ffffff
    style NOTA fill:#1a2a3a,stroke:#4a9eff,color:#ffffff

Il server terzo non sa di essere usato come arma: vede una richiesta legittima proveniente dall'IP della vittima e risponde educatamente a quell'IP. Dal suo punto di vista e' normale traffico. L'attaccante non riceve mai le risposte: non gli servono. Il suo obiettivo e' far si' che migliaia di server onesti bombardino la vittima con risposte che lei non ha mai richiesto.

Amplification Factor - il moltiplicatore

#

L'amplification factor e' il rapporto tra la dimensione della risposta e quella della richiesta. E' il motivo per cui il Reflected DDoS e' cosi' efficiente: l'attaccante investe 1 Gbps di banda e genera decine o migliaia di Gbps sulla vittima.

La formula dell'attacco e' semplice:

banda attaccante × amplification factor = banda ricevuta dalla vittima
1 Gbps (attaccante) × 50x (DNS) = 50 Gbps sulla vittima
1 Gbps (attaccante) × 500x (NTP) = 500 Gbps sulla vittima
1 Gbps (attaccante) × 50.000x (Memcached) = 50 Tbps sulla vittima

Con Memcached basta un attaccante con 1 Gbps di banda per generare un attacco da 50 Tbps sulla vittima, usando come armi i server Memcached esposti su internet di terze parti.

Reflected vs Amplified - la distinzione

#

Le due varianti sono spesso confuse perche' condividono lo stesso meccanismo base (IP spoofing + riflessione via terzi). La distinzione e' nel focus:

Difese

#

Le difese operano su livelli diversi: alla fonte (impedire lo spoofing), sul protocollo (limitare l'amplificazione), e davanti alla vittima (assorbire il traffico).

Difese lato protocollo:

BCP38 - Egress Filtering: il Best Current Practice 38 chiede agli ISP di filtrare in uscita i pacchetti con IP sorgente non appartenente alla propria rete. Se tutti gli ISP applicassero BCP38, il Reflected DDoS sarebbe impossibile: i pacchetti spoofati verrebbero eliminati prima di raggiungere internet. In pratica non e' universalmente applicato.

BGP Blackholing: quando la vittima e' sotto attacco, si annuncia via BGP che il traffico verso il suo IP deve essere scartato upstream. Ferma l'attacco ma rende anche il servizio irraggiungibile per i client legittimi. E' una misura di emergenza temporanea.

Scrubbing center (Cloudflare, Akamai, AWS Shield): il traffico in ingresso viene deviato verso data center specializzati che filtrano il traffico malevolo e inoltrano solo quello legittimo. E' la difesa piu' scalabile per volume di attacco.

Dev parallel: un endpoint Node.js o PHP che restituisce payload grandi (es. export CSV, API con risposta verbose) puo' diventare un reflector involontario se esposto senza autenticazione. Chiunque con IP spoofato puo' inviare richieste e far si' che il server invii MB di dati a un IP terzo. La difesa e' autenticazione su tutti gli endpoint pesanti, rate limiting, e soprattutto non esporre su internet servizi come Memcached che per design non hanno autenticazione.

Mappa figlia - Difese contro Reflected DDoS

#

Note correlate: tcp-udp | ids-ips | bgp-asn-fundamentals | anycast