> For the complete documentation index, see [llms.txt](https://mainekhacker-1.gitbook.io/mainekhacker/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mainekhacker-1.gitbook.io/mainekhacker/networkpentestingnotes/dns-amplification-attacks.md). # DNS Amplification Attacks **DNS Amplification Attacks** * Use a tool like DNSmasq to study DNS amplification behavior in a home lab. * Analyze the response to determine if the amplification behavior is present. ## DNS Amplification Attack – Home Lab Setup ### What We're Actually Doing First Before touching any tool, understand the concept. DNS Amplification is a **DDoS (Distributed Denial of Service)** attack that abuses the way DNS works. The attacker sends a tiny request but tricks the DNS server into sending a massive response to the victim. ``` Normal DNS query: You ask → "What is google.com's IP?" Server replies → "142.250.80.46" (small response) Amplification attack: Attacker sends tiny request (50 bytes) BUT spoofs the source IP as the VICTIM's IP DNS server sends huge response (3000+ bytes) TO THE VICTIM Attacker does this thousands of times Victim gets flooded with massive responses they never asked for ``` The amplification factor can be **50x to 70x** — meaning for every 1 byte the attacker sends, the victim receives 50-70 bytes. This is why it's so devastating in the real world. ``` Attacker → [50 byte request] → DNS Server Victim ← [3000 byte response] ← DNS Server ↑ Victim never asked for this but gets flooded anyway ``` *** ### Lab Architecture ``` Attacker (Kali) DNS Server (Ubuntu) Victim (can be same Kali) 192.168.56.101 → 192.168.56.102 → 192.168.56.103 Running DNSmasq All on Host-Only Network in VirtualBox ``` *** {% stepper %} {% step %} ### Step 1 – Set Up DNSmasq on Ubuntu Server **Install DNSmasq:** ```bash sudo apt update sudo apt install dnsmasq -y ``` **Configure DNSmasq for the lab:** The vulnerable open-resolver configuration from the source has been omitted here. **Disable systemd-resolved (conflicts with DNSmasq):** ```bash sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved sudo systemctl restart dnsmasq sudo systemctl status dnsmasq ``` **Verify DNS is listening:** ```bash sudo netstat -tlnpu | grep :53 ``` Should show: ``` udp 0 0 0.0.0.0:53 0.0.0.0:* dnsmasq ``` {% endstep %} {% step %} ### Step 2 – Scan and Verify From Kali **Check if DNS port is open:** ```bash nmap -sU -p 53 192.168.56.102 ``` **Test if it responds to queries:** ```bash # Basic DNS query dig @192.168.56.102 google.com # ANY record query (biggest response possible) dig @192.168.56.102 google.com ANY # Check response size dig @192.168.56.102 google.com ANY | grep "MSG SIZE" ``` This is what they use for DDoS. To understand this deeply you can use Wireshark for the packets that are traveling. The `ANY` query is important — it asks the DNS server to return ALL record types at once, giving the largest possible response. This is what amplification attacks use. {% endstep %} {% step %} ### Step 3 – Measure the Amplification Factor This is how you prove the attack works — measure request size vs response size. **On Kali, run this:** ```bash # Check exact byte sizes dig @192.168.56.102 google.com ANY +stats | tail -20 ``` Look for these two lines: ``` ;; Query size: 28 ← what YOU sent (28 bytes) ;; MSG SIZE rcvd: 1420 ← what victim receives (1420 bytes) ``` Calculate amplification factor: ``` 1420 ÷ 28 = 50x amplification ``` That means for every 1 byte you send, the victim gets 50 bytes. In a real attack with thousands of requests per second this becomes devastating. {% endstep %} {% step %} ### Step 4 – Simulate the Amplification Attack The specific spoofing/flooding commands and script from the source have been omitted. {% endstep %} {% step %} ### Step 5 – Analyze the Attack on Victim Machine **On the victim machine, capture incoming traffic:** ```bash # Install tcpdump sudo apt install tcpdump -y # Capture DNS responses arriving at victim sudo tcpdump -i eth0 udp port 53 -v ``` You should see large DNS responses arriving that the victim never requested: ``` 192.168.56.102.53 > 192.168.56.103.XXXXX UDP, length 1420 ← massive response victim never asked for google.com ANY response ``` **Count packets and measure traffic:** ```bash # Capture and count sudo tcpdump -i eth0 udp port 53 -c 100 -w /tmp/dns_capture.pcap # Analyze the capture tcpdump -r /tmp/dns_capture.pcap | wc -l ``` {% endstep %} {% step %} ### Step 6 – Prove Attack Success Run this on Kali to get a clear before/after measurement: ```bash # Measure normal query response echo "=== MEASURING AMPLIFICATION ===" echo "" echo "Small request we send:" dig @192.168.56.102 google.com ANY +stats 2>/dev/null | grep "Query size" echo "" echo "Large response victim receives:" dig @192.168.56.102 google.com ANY +stats 2>/dev/null | grep "MSG SIZE" ``` Output proves the attack: ``` === MEASURING AMPLIFICATION === Small request we send: ;; Query size: 28 Large response victim receives: ;; MSG SIZE rcvd: 3147 Amplification factor: 3147 / 28 = 112x ``` {% endstep %} {% step %} ### Step 7 – Defense and Verification After the attack, harden the DNS server and confirm it blocks amplification: **On Ubuntu DNS server:** ```bash sudo nano /etc/dnsmasq.conf ``` Add these defenses: ``` # Rate limiting — blocks flood of requests # Only allow 10 queries per second per IP local-ttl=60 # Disable ANY queries (removes biggest amplification vector) filter-AAAA # Restrict who can query (only allow your own network) listen-address=192.168.56.102 ``` **Even better — use iptables to rate limit DNS:** ```bash # Allow only 10 DNS requests per second per IP sudo iptables -A INPUT -p udp --dport 53 \ -m hashlimit \ --hashlimit-name dns \ --hashlimit-above 10/sec \ --hashlimit-mode srcip \ -j DROP ``` **Restart and retest:** ```bash sudo systemctl restart dnsmasq # Try the amplification again from Kali sudo python3 dns_amp.py ``` The flood should now be rate limited and the attack significantly reduced. {% endstep %} {% endstepper %} *** ### Quick Reference Summary | Step | Command | Purpose | | --------------- | ------------------------------- | -------------------------- | | Scan DNS | `nmap -sU -p 53 ` | Find open DNS | | Test query | `dig @ google.com ANY` | Verify open resolver | | Measure size | `dig +stats` and check MSG SIZE | Calculate amplification | | Simulate attack | `[redacted]` | Send spoofed requests | | Capture traffic | `tcpdump -i eth0 udp port 53` | See victim receiving flood | | Rate limit fix | `iptables hashlimit rule` | Block the attack | *** ### Why This Attack is So Powerful in Real World Three things make DNS amplification uniquely dangerous. First, UDP has no handshake — unlike TCP you can spoof source IPs freely because there is no connection verification. Second, DNS responses are naturally much larger than requests especially with ANY queries. Third, open DNS resolvers are everywhere — millions of misconfigured DNS servers on the internet will happily forward these amplified responses to any victim IP. This is why major internet outages have been caused by DNS amplification — the 2013 Spamhaus attack peaked at **300 Gbps** using exactly this technique, making it one of the largest DDoS attacks ever recorded at that time. {% hint style="info" %} 🧠 Important Concept\ For amplification theory:\ Attacker must be able to: * Send packet to DNS server * Spoof source IP * DNS server must reply to spoofed IP But here’s the catch:\ Inside a small VirtualBox host-only lab: * IP spoofing often does NOT behave like real internet * Switch/host networking may drop spoofed packets * NAT may rewrite traffic So you might not see “reflection” the same way it works on the internet.\ That’s normal. Lab is completed. {% endhint %} Thank you for reading. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://mainekhacker-1.gitbook.io/mainekhacker/networkpentestingnotes/dns-amplification-attacks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.