Abstract
Ricreati attacchi di riflessione e amplificazione DNS in una LAN controllata per misurare fattori di amplificazione, latenza sul bersaglio e risorse del server. Script Scapy personalizzati hanno effettuato spoofing del bersaglio variando i tipi di query (A, MX, NS, ANY) tra 10k e 50k pacchetti/s. Lo studio documenta latenza oltre 100 ms per le richieste ANY, saturazione della CPU durante gli attacchi intensificati e valuta contromisure.
Informazioni
Un resolver BIND9 è configurato su macchine Ubuntu che fungono da riflettore e vittima. Script Scapy generano query DNS spoofate con rate controllato, mentre Wireshark, dig, ping e psutil raccolgono metriche di rete e risorse. I fattori di amplificazione sono calcolati confrontando dimensioni di richiesta/risposta per record A, MX, NS e ANY. I campioni di latenza mostrano che un’amplificazione maggiore degrada la reattività, soprattutto per gli ANY (>100 ms). Portando il traffico a 50k pps il server non riesce a rispondere a tutte le query, riflettendo solo parzialmente e facendo salire la CPU dal 4% a ~25%. L’indagine si chiude con raccomandazioni di mitigazione (rate limiting, riduzione della dimensione delle risposte, filtri in ingresso).
Risultati chiave
- 1.46
- AF A
- 4.14
- AF MX
- 4.46
- AF NS
- 7.30
- AF ANY
- ≈44 ms @10k pps
- MX Mean Query Time
- ≈96 ms @10k pps
- NS Mean Query Time
- >100 ms @10k pps
- ANY Mean Query Time
- Mean 174 ms, peaks 400 ms
- Amplified Attack (50k pps)
- >30% (baseline ~4%)
- Server CPU Peak
- ≤48 ms (minimal)
- Ping Latency Impact
Scoperte principali
- I fattori di amplificazione misurati sono 1.46× (A), 4.14× (MX), 4.46× (NS) e 7.30× (ANY), con ANY che genera la riflessione più forte.
- A 10k pacchetti/s la latenza media di dig è salita a ~44 ms per MX, ~96 ms per NS e oltre 100 ms per ANY rispetto al baseline pre-attacco.
- Portando l’attacco a 50k pacchetti/s la latenza media è arrivata a 174 ms (picchi 400 ms) e la CPU del server DNS è passata da ~4% a 24.5% (picchi >30%).
- La latenza ICMP è rimasta ≤48 ms durante gli attacchi, segno che la congestione ha colpito soprattutto l’elaborazione DNS e non la rete generale.
Sfide
- Gli esperimenti in LAN non replicano la banda di botnet reali, limitando la validità esterna.
- Le misure di CPU e RAM dipendono da sensori software con ritardi di campionamento, introducendo imprecisioni.
- Le contromisure sono state discusse ma non testate nello stesso ambiente per vincoli di tempo.
Metodologia
- 01Configure BIND9 resolver and victim hosts on Ubuntu
- 02Generate spoofed DNS queries via Scapy with adjustable packet rates
- 03Capture request/response traffic and latency using Wireshark, dig and ping
- 04Profile server CPU and RAM with psutil while varying record types (A, MX, NS, ANY)
- 05Compute amplification factors by comparing response and request payload sizes
