9.2.6 Lab: Analyze A Ddos Attack: Exact Answer & Steps

Ever caught a spike in traffic that looked more like a crowd of angry fans than regular visitors?
One minute your site’s humming, the next you’re staring at a “Server overloaded” message and wondering if the internet just decided to give you a hard time.
Welcome to the world of DDoS analysis—where you become a digital detective, sifting through packets, logs, and timestamps to figure out who’s hammering your server and why Easy to understand, harder to ignore. Surprisingly effective..

What Is a 9.2.6 Lab: Analyze a DDoS Attack

In the cybersecurity curriculum, lab 9.2.6 is the hands‑on exercise that forces you to roll up your sleeves and actually dissect a Distributed Denial‑of‑Service attack.
It isn’t a theory lecture about “what could happen”; it’s a sandbox where you get a packet capture (PCAP), a set of server logs, and a bunch of noisy traffic that pretends to be legit.

The Core Idea

You’re given a simulated environment—often a virtual machine running a web server and a separate attacker VM flooding it.
Your job? Pull the data apart, identify the attack vectors (SYN flood, HTTP GET flood, DNS amplification, you name it), and write a concise report that explains the timeline, the tools used by the attacker, and what you’d do to stop it.

Tools You’ll Touch

• Wireshark – the go‑to packet sniffer for visualizing traffic.
• tcpdump – command‑line capture that’s perfect for quick filtering.
• logwatch / fail2ban – to see how the server reacted.
• iptables – you’ll often add a rule at the end just to prove you can block the traffic.

If you’ve ever played with these tools in isolation, the lab ties them together into a narrative The details matter here..

Why It Matters / Why People Care

Because a DDoS isn’t just a buzzword—it’s a real‑world revenue killer.
That said, think about an online retailer during a flash sale. A few minutes of downtime can translate into thousands of lost orders, angry customers, and a bruised brand reputation.

When you actually analyze an attack, you get three big wins:

1. Root cause visibility – you see whether the flood is coming from a handful of IPs or a botnet of thousands.
2. Defensive insight – you discover which firewall rule would have stopped it, or whether you need a CDN with built‑in DDoS mitigation.
3. Forensic value – if you ever need to involve law enforcement or an insurance claim, a solid analysis report is your evidence.

In practice, most companies outsource DDoS protection, but the internal security team still needs to know what’s happening under the hood. Because of that, that’s why labs like 9. On top of that, 2. 6 are a staple in cert programs and university courses.

How It Works (or How to Do It)

Below is the step‑by‑step workflow most instructors expect you to follow. Feel free to adapt it to your own environment, but keep the core ideas in mind And it works..

1. Set Up the Lab Environment

• Spin up the VMs – one for the target (often Ubuntu with Apache/Nginx) and one for the attacker (Kali Linux works well).
• Configure networking – make sure both VMs are on the same internal network so latency isn’t a factor.
• Start packet capture – on the target VM run tcpdump -i eth0 -w ddos_capture.pcap. This will be your raw data source.

2. Launch the Attack

Most labs give you a script like ddos.sh that runs a flood using hping3 or slowloris.
Typical commands you’ll see:

# SYN flood on port 80
hping3 -S -p 80 --flood 
# HTTP GET flood
while true; do curl http:/// & done

Let the attack run for a predetermined window—usually 5‑10 minutes Most people skip this — try not to..

3. Capture and Correlate Logs

While the flood is happening, open another terminal and tail the web server log:

tail -f /var/log/apache2/access.log

You’ll start seeing a massive surge of identical requests. Note the timestamps; they’ll line up with the PCAP later.

4. Stop the Attack and Close Capture

Kill the attack script (Ctrl‑C on the attacker VM) and stop tcpdump (Ctrl‑C on the capture terminal).
Now you have two primary artefacts:

• ddos_capture.pcap – raw packet data.
• /var/log/apache2/access.log – server request record.

5. Analyze the PCAP

Open the capture in Wireshark. Here’s what you’re looking for:

• Protocol distribution – is it mostly TCP SYN packets? UDP?
• Source IP diversity – a single IP points to a misconfigured script; thousands suggest a botnet.
• Packet size – amplification attacks often have tiny request packets and huge responses.

Use Wireshark’s filters to isolate the traffic. Example:

tcp.flags.syn == 1 && tcp.dstport == 80

If you see a flood of SYNs with no ACKs, you’ve got a classic SYN flood It's one of those things that adds up..

6. Correlate With Server Logs

Match the timestamps from Wireshark to the access log. Also, you might notice that the log shows a GET request for “/index. Which means html” every 0. 01 seconds, while the PCAP shows a corresponding SYN‑ACK handshake.

If the logs contain 404 or 500 responses at the same rate, the server is actually processing the requests—meaning the attack is application‑layer rather than just network‑layer.

7. Identify the Attack Vector

Based on the evidence, label the attack:

• SYN flood – many half‑open connections, no data payload.
• HTTP GET flood – full HTTP requests, often targeting static resources.
• DNS amplification – large UDP responses, source port 53.

Write a short paragraph summarizing the vector, the likely tools (hping3, slowloris), and the scale (e.And g. , “~12,000 packets per second from 150 unique IPs”) Most people skip this — try not to. No workaround needed..

8. Propose Mitigation

Now you switch from detective to fixer. Common mitigations include:

1. Rate‑limit SYN packets – iptables -A INPUT -p tcp --syn --dport 80 -m limit --limit 10/s -j ACCEPT.
2. Enable SYN cookies – on Linux, sysctl -w net.ipv4.tcp_syncookies=1.
3. Deploy a CDN or WAF – offload traffic to a service that can absorb spikes.
4. Block offending IPs – if the source list is short, add them to a blacklist.

Document the exact commands you’d run, and, if possible, test one mitigation in the lab to see the traffic drop.

9. Write the Final Report

A solid report follows a simple structure:

• Executive summary – one paragraph for non‑technical stakeholders.
• Methodology – how you captured data and why.
• Findings – attack type, volume, source diversity.
• Impact – server CPU usage, response time, error rates.
• Recommendations – the mitigations you listed, plus longer‑term strategies (e.g., “invest in a cloud‑based DDoS scrubbing service”).

Keep it concise; a busy manager will skim the executive summary, while the security team will dive into the technical appendix.

Common Mistakes / What Most People Get Wrong

Even after a few labs, newbies trip over the same pitfalls That's the part that actually makes a difference..

• Skipping the baseline – you need a “normal traffic” snapshot to compare against. Without it, you can’t tell if a spike is truly abnormal.
• Relying on a single tool – Wireshark is great for visual inspection, but tcpdump with proper filters can reveal hidden patterns faster.
• Ignoring UDP – many think DDoS is only TCP. DNS amplification, NTP reflection, and memcached attacks are all UDP‑based and show up differently in the PCAP.
• Over‑blocking – adding a blanket iptables -A INPUT -s 0.0.0.0/0 -j DROP will kill legitimate traffic. Always scope your rule to a port or protocol.
• Forgetting to reset counters – after you stop the attack, the kernel’s connection tracking tables still hold half‑open connections, which can skew post‑mortem stats. Run sysctl -w net.ipv4.tcp_syncookies=1 or clear /proc/net/tcp if needed.

Address these early, and your analysis will be far more credible Worth keeping that in mind..

Practical Tips / What Actually Works

1. Start with a narrow filter – tcpdump -nn -i eth0 'dst port 80 and tcp[tcpflags] & (tcp-syn) != 0' captures only SYN packets to port 80. Less noise, faster analysis Easy to understand, harder to ignore. Simple as that..

2. Use uniq -c on source IPs – after extracting IPs with awk '{print $3}' ddos_capture.pcap | cut -d. -f1-4 | sort | uniq -c | sort -nr, you instantly see the top offenders.

3. use tcptrack – a lightweight CLI that shows live connection counts; great for spotting a sudden surge And that's really what it comes down to..

4. Automate the timeline – a quick Python script that parses the PCAP timestamps and plots requests per second gives you a visual “spike chart.”

5. Enable kernel SYN‑cookie logging – add net.ipv4.tcp_syncookies=2 to see when the kernel drops SYNs because of overload.

6. Test mitigation in real time – after adding an iptables rate limit, re‑run tcpdump to confirm the packet rate drops.

7. Document every command – the lab report often expects a reproducible “what I did” section. Paste the exact commands you used; it saves reviewers from guessing Easy to understand, harder to ignore..

FAQ

Q: How can I tell if a DDoS is targeting the network layer vs. the application layer?
A: Network‑layer attacks (SYN flood, UDP flood) show lots of packets with minimal payload and no full HTTP request. Application‑layer attacks contain complete GET/POST requests and usually generate higher CPU usage on the web server.

Q: Do I need root access on the target VM to capture traffic?
A: Yes, tcpdump and most packet‑capture tools require root or the cap_net_raw capability. If you’re on a hosted environment, ask the admin for a pcap export.

Q: What’s the difference between a DDoS and a DoS?
A: A DoS originates from a single source, making it easier to block. A DDoS uses many compromised hosts (a botnet), so blocking one IP hardly makes a dent Took long enough..

Q: Can I use cloud‑based tools to analyze a lab capture?
A: Absolutely. Uploading the PCAP to services like CloudShark lets you share the analysis with teammates, but make sure the lab’s data isn’t confidential.

Q: How do I know if my mitigation actually helped?
A: Re‑run the attack after applying the rule and compare packet rates, server response times, and error codes. A successful mitigation will show a sharp drop in request volume and a return to normal CPU usage.

That’s a full walk‑through of the 9.Plus, 2. 6 lab, from spinning up VMs to writing a polished report.
If you’ve ever felt lost staring at a flood of packets, remember: break it down, filter aggressively, and always keep a “normal traffic” baseline for reference.
Consider this: once you’ve nailed this lab, you’ll have a solid foundation for tackling real‑world DDoS incidents—plus a nice story to tell at the next security meetup. Happy hunting!

Wrapping It All Together

After you’ve finished the capture, filtered the noise, and verified that your mitigation blocks the bulk of the bogus traffic, the final step is to synthesize everything into a coherent narrative. Think of your report as a story with a clear beginning (the baseline), middle (the attack and its fingerprints), and end (the counter‑measure and its impact) Which is the point..

Final Checklist Before Submission

1. Double‑check the capture duration – ensure no late packets were missed.
2. Cross‑verify timestamps – align tcpdump timestamps with the attack script’s start/stop logs.
3. Run wireshark -k -Y "http.request" to confirm no legitimate traffic was mistakenly dropped.
4. Include the raw .pcap in your submission (or a link to a CloudShark session) so reviewers can re‑run the analysis if needed.
5. Proofread – a typo in a rule or a missing -p tcp can make your mitigation look ineffective.

Conclusion

A DDoS lab is not just about dropping packets; it’s about understanding the why behind the flood, learning how to read the silent clues in a packet stream, and proving that a disciplined, layered defense can bring the traffic back to normal. By following the structured workflow above—baseline, capture, filter, analyze, mitigate, validate—you’ll turn raw packets into actionable intelligence.

Quick note before moving on.

Take the time to document each command, each insight, and each decision. That documentation is your most valuable asset: it turns a one‑off lab exercise into a repeatable playbook that can be deployed in a real‑world environment No workaround needed..

Good luck, and may your firewall rules stay sharp and your packet logs stay clean!