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.

Not the most exciting part, but easily the most useful Easy to understand, harder to ignore..

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.
Consider this: 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 That's the part that actually makes a difference..

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.

Why It Matters / Why People Care

Because a DDoS isn’t just a buzzword—it’s a real‑world revenue killer.
Day to day, 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. On top of that, 2. Because of that, that’s why labs like 9. 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.

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 It's one of those things that adds up..

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 And that's really what it comes down to..

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 Most people skip this — try not to..

6. Correlate With Server Logs

Match the timestamps from Wireshark to the access log. html” every 0.Which means you might notice that the log shows a GET request for “/index. 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 Small thing, real impact..

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.g., “~12,000 packets per second from 150 unique IPs”) Small thing, real impact..

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 That's the part that actually makes a difference..

Common Mistakes / What Most People Get Wrong

Even after a few labs, newbies trip over the same pitfalls.

• 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 Less friction, more output..

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.

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.

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.

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 Not complicated — just consistent..

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 It's one of those things that adds up..

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.

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.On top of that, 2. Day to day, 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.
This leads to 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) Less friction, more output..

This is the bit that actually matters in practice.

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.

Honestly, this part trips people up more than it should And that's really what it comes down to..

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.

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