Traffic Analysis • Wireshark • hping3 • Bash & Python Automation • TCP/IP
| Field | Value |
|---|---|
| Topic | Denial of Service (DoS) & Distributed Denial of Service (DDoS) |
| Platform | Personal Lab/RootX |
| Difficulty | Intermediate to Advanced |
| Author | Yusuf Muhammad Husayn Ramadan |
| Date | July 2, 2026 |
Document, in full technical detail, a hands-on DoS/DDoS lab built entirely with Kali Linux and Metasploitable2: attack workflows for ICMP, SYN, HTTP, TCP, and Ping-of-Death floods, a locally simulated multi-source ("DDoS") variant of each attack, full Wireshark traffic analysis for every stage, and applicable defensive measures.
Important
This project was conducted entirely inside an isolated lab environment (Kali Linux attacking a Metasploitable2 virtual machine on a private virtual network) for educational and defensive security purposes. No attacks were performed against public or third-party systems.
Note
The "DDoS" stages in this lab simulate distributed attack volume by running multiple concurrent flood processes from the single attacking Kali host via tmux, rather than coordinating attacks from genuinely separate physical or virtual sources. This scope limitation is intentional and is discussed under Future Improvements.
dos-ddos-lab/
├── README.md
├── LICENSE
├── .gitignore
├── images/
└── scripts/
├── bash/
└── python/
- Prerequisites
- Introduction
- Lab Environment
- Network Topology
- Lab Workflow
- Tools & Scripts Used
- Attack Types
- ICMP Flood
- SYN Flood
- HTTP Flood
- TCP Flood
- Ping of Death
- Simulated DDoS Stage
- Traffic Analysis (Wireshark)
- Mitigation Techniques
- Attack Summary
- Lessons Learned
- Future Improvements
- Skills Demonstrated
- Screenshots Index
- Packet Capture Index
- Lab Limitations
- Conclusion
- References
- VMware Workstation / VirtualBox
- Kali Linux (attacker)
- Metasploitable2 (victim)
- Wireshark
- hping3
- tmux
- Python 3
- Bash
A Denial of Service (DoS) attack aims to make a targeted service or infrastructure unavailable to legitimate users, by exhausting resources such as CPU, memory, or network bandwidth. Unlike data breaches, the goal is disruption, not theft.
A DoS attack originates from a single machine using a single NIC, processor, and memory pool. A Distributed Denial of Service (DDoS) attack scales this up using many sources targeting a single victim simultaneously, which increases both the traffic volume and the difficulty of mitigation. In this lab, the DDoS stage is approximated using concurrent multi-process flooding from one attacker host, run via tmux sessions, to observe the difference in impact and traffic signature compared to a single-stream DoS.
Figure 00. Overall lab topology showing the Kali Linux attacker, Metasploitable2 target, and Wireshark traffic capture within an isolated virtual network.
Attacker Machine
- Kali Linux
- hping3, tmux, Python 3, custom Bash scripts
Victim Machine
- Metasploitable2
- Apache2 (manually started/stopped during testing to compare service states)
Packet Analyzer
- Wireshark, run on the Kali host to capture traffic on the lab interface
Network
VMware Workstation virtual networking.
Attacker: NAT Adapter
Target: Host-Only Adapter
Connectivity was verified before every experiment.
The Kali Linux attacker VM was configured with a NAT network adapter for internet access and package management. The Metasploitable2 target VM was connected to an isolated host-only network for the attack demonstrations.
| Device | IP Address |
|---|---|
| Kali Linux (Attacker) | 192.168.12.128 (NAT) |
| Metasploitable2 (Victim) | 192.168.1.25 (Host-Only) |
Connectivity between the attacker and target virtual machines was verified before every experiment using ICMP echo requests and application-layer service checks.
The lab was conducted inside VMware using isolated virtual networking. The attacker and target virtual machines were configured to communicate over the virtual network while remaining isolated from external systems.
graph TD
A[Kali Linux - Attacker VM<br/>192.168.12.128] -->|ICMP / TCP / HTTP| B[Metasploitable2 - Apache2 Target<br/>192.168.1.25]
A -->|Local Capture| C[Wireshark - Same Host as Attacker]
Wireshark was run locally on the Kali attacker host rather than a separate capture VM, capturing outbound attack traffic and inbound replies on the lab interface.
graph LR
A[Verify Connectivity - ip a / ping] --> B[Start Target Service - Apache2]
B --> C[Capture Baseline Traffic]
C --> D[Run Single-Source DoS per Attack Type]
D --> E[Run Simulated Multi-Source DDoS per Attack Type]
E --> F[Capture & Save pcapng per Stage]
F --> G[Analyze in Wireshark]
G --> H[Compare Against Baseline]
H --> I[Review Mitigation Options]
Baseline capture was taken before any attack traffic was generated (01-baseline.pcapng), so every subsequent capture could be compared against normal traffic patterns rather than analyzed in isolation.
Figure 01. Baseline network traffic captured before any attack activity, providing a reference for comparison.
Target-side verification was performed by starting and stopping Apache2 on Metasploitable2 (sudo /etc/init.d/apache2 start / stop) and checking the listening state with netstat -antp | grep 80 before and after each HTTP-related test, to confirm the service state independently of the attack traffic itself.
Base attacker platform for all traffic generation and capture.
Used to hand-craft and flood ICMP, SYN, and oversized ICMP (Ping of Death) packets.
Used for live capture and post-attack analysis of every stage, filtered per protocol.
Used to run multiple flood processes concurrently in separate panes/sessions, simulating the volume of a distributed attack from a single host. Sessions were torn down after each stage (tmux kill-session / tmux kill-server) before moving to the next attack type.
| Script | Purpose |
|---|---|
00-icmp-ddos-script.sh |
Launches multiple concurrent ICMP flood processes via tmux to simulate distributed ICMP flood volume |
01-syn-ddos-script.sh |
Launches multiple concurrent SYN flood processes via tmux to simulate distributed SYN flood volume |
02-http-ddos-script.sh |
Launches multiple concurrent HTTP flood processes via tmux to simulate distributed HTTP flood volume |
03-pod-ddos-script.sh |
Launches multiple concurrent oversized-ICMP (Ping of Death style) processes via tmux |
04-tcp-ddos-script.sh |
Launches multiple concurrent TCP flood processes via tmux |
00-tcp-data-flood.py |
Python-based TCP payload flood generator |
01-botnet.py |
Python script coordinating multiple local flood processes to simulate a distributed source pattern against a single target |
02-http-ddos.py |
Python-based HTTP request generator used by the HTTP DDoS script |
Script contents are not reproduced in this write-up; only their role in the lab workflow is documented, consistent with responsible disclosure practice for offensive tooling.
| Metric | DoS Stage | Simulated DDoS Stage |
|---|---|---|
| Source Count | Single hping3/script process | Multiple concurrent processes via tmux, same host |
| Detection Complexity | High visibility, easy to trace to one stream | Higher traffic volume, more connections/sec to correlate |
| Traffic Volume | Limited by one process/interface | Multiplied by concurrent process count |
| Real-World Equivalent | Single attacker | Approximates distributed volume, but not distributed source IPs |
Overview A high volume of ICMP Echo Request packets is sent to the target. The target attempts to process and reply to each one, consuming bandwidth and network-stack CPU cycles.
Attack Workflow
sequenceDiagram
participant A as Kali (Attacker)
participant V as Metasploitable2 (Victim)
A->>V: ICMP Echo Request (flood)
V-->>A: ICMP Echo Reply
Note over V: Bandwidth and CPU load increase with flood rate
Impact Increased bandwidth usage and processing load on the victim's network stack, visible as a spike in the IO Graph during the attack window.
Wireshark Analysis
Figure 02. Single-source ICMP flood captured in Wireshark, showing a continuous stream of ICMP Echo Request packets.
Figure 03. Execution of the ICMP flood simulation script using multiple concurrent tmux sessions.
Figure 04. Simulated multi-process ICMP flood producing a significantly higher packet rate than the single-source attack.
Key Findings ICMP floods are the easiest attack type to detect and filter, since legitimate ICMP traffic volume is normally very low; the DDoS stage differs mainly in packet rate, not in signature.
Overview Exploits the TCP three-way handshake. The attacker sends a flood of SYN packets and never completes the handshake with a final ACK, leaving connections half-open until the victim's connection queue is exhausted.
Attack Workflow
sequenceDiagram
participant C as Legitimate Client
participant S as Server
participant A as Attacker (Kali)
C->>S: SYN
S-->>C: SYN-ACK
C->>S: ACK
Note over C,S: Connection established
A->>S: SYN (repeated, flood)
S-->>A: SYN-ACK (allocates memory)
Note over S: No ACK received — connection stays half-open
Impact Exhaustion of the server's connection queue, which can block or slow new legitimate connections.
Wireshark Analysis
Figure 05. Single-source SYN flood showing repeated SYN packets without completing the TCP three-way handshake.
Figure 06. Execution of the SYN flood simulation script across multiple concurrent processes.
Figure 07. Simulated SYN flood demonstrating an increased number of half-open TCP connections.
Key Findings SYN floods are identifiable by the SYN/ACK asymmetry in the filtered capture and by the growing number of half-open connections over the attack window.
Overview Targets the application layer (Layer 7) with structurally valid HTTP requests against the Apache2 service running on Metasploitable2. These requests are indistinguishable from legitimate traffic at the network layer, since the goal is to exhaust application-side resources rather than raw bandwidth.
Attack Workflow Repeated HTTP GET requests are sent to the target's web service. The Python-based generator (02-http-ddos.py) issues requests concurrently across multiple processes during the DDoS stage.
Impact Application-level resource pressure (Apache worker processes, connection handling) rather than pure bandwidth exhaustion. Service state was verified independently with netstat -antp | grep 80 before, during, and after testing.
Wireshark Analysis
Figure 08. Single-source HTTP flood showing a high rate of HTTP GET requests sent to the target web server.
Figure 09. HTTP request headers captured during the application-layer flood analysis.
Figure 10. HTTP flood automation script launching multiple concurrent request generators.
Figure 11. Simulated HTTP flood generating a substantially higher request rate against the Apache2 service.
Key Findings Layer 7 floods are the hardest attack type to distinguish from real users at the network layer alone; request-rate anomalies and connection concurrency were the clearest signals observed in this lab, rather than packet-level structure.
Overview A generic TCP-layer flood using crafted payload data (00-tcp-data-flood.py) to saturate the connection handling capacity of the target beyond a simple SYN flood, by establishing and holding connections with data payloads.
Attack Workflow The attacker opens TCP connections to the target and sends flood-rate payload data, consuming both connection slots and processing time on the victim.
Impact Combined bandwidth and connection-table pressure on the victim, more resource-intensive to generate than a pure SYN flood but harder for the victim to distinguish from legitimate data transfer at first glance.
Wireshark Analysis
Figure 12. Single-source TCP flood transmitting continuous payload data to the target.
Figure 13. Execution of the TCP flood simulation script across multiple concurrent processes.
Figure 14. Simulated TCP flood demonstrating increased connection volume and payload throughput.
Key Findings TCP floods that include payload data are more resource-intensive to generate but produce traffic that looks closer to legitimate data transfer than SYN-only floods, making them slightly harder to triage from packet headers alone.
Overview Historically, oversized or malformed fragmented ICMP packets could cause buffer overflows during reassembly, crashing legacy systems. This lab reproduced the classic oversized-ICMP packet pattern (hping3 -1 -c 10 -d 65495 -w 65495) against the Metasploitable2 target to observe how a modern-era Linux network stack handles it.
Attack Workflow Oversized ICMP Echo Request packets, at or near the maximum IP packet size, were sent to the target for reassembly.
Impact Metasploitable2 accepted the oversized ICMP traffic without crashing. Packet captures showed that malformed fragments were discarded by the network stack, demonstrating resistance to the historical Ping of Death attack.
Wireshark Analysis
Figure 15. Oversized ICMP packets generated during the Ping of Death demonstration.
Figure 16. Execution of the Ping of Death simulation script using multiple concurrent processes.
Figure 17. Simulated multi-process Ping of Death traffic captured in Wireshark.
Key Findings This attack is largely a historical case study against fully patched modern kernels, but remains a useful test against older or specifically vulnerable targets like Metasploitable2, which is intentionally left unpatched for training purposes.
Observed that Metasploitable2 dropped the malformed fragments due to modern kernel handling, confirming it is resilient against legacy PoD attacks.
Each attack type above was re-run using its corresponding *-ddos-script.sh, which opens several tmux panes and launches one flood process per pane against the same target simultaneously. This approximates the traffic volume of a distributed attack while originating from a single source IP — a meaningful distinction from a genuine multi-host DDoS, and one worth stating clearly in a graduation project defense.
Each DDoS-stage script was terminated cleanly after capture with tmux kill-session -t ddos_simulation (or tmux kill-server where multiple sessions were used), before moving to the next attack type, to avoid cross-contaminating captures between stages.
Figure 18. Multiple concurrent hping3 processes executing in parallel during the simulated DDoS stage. The Apache web service became temporarily unavailable, resulting in a browser connection timeout while the target operating system remained operational.
Figure 19. During the simulated DDoS stage, the target became temporarily unreachable. ICMP echo requests resulted in 100% packet loss, while the Apache web service returned an "Unable to connect" error, demonstrating successful service disruption without crashing the target operating system.
| Purpose | Filter |
|---|---|
| ICMP | ip.addr == 192.168.1.25 && icmp |
| SYN | ip.addr == 192.168.1.25 && tcp.flags.syn == 1 && tcp.flags.ack == 0 |
| HTTP | ip.addr == 192.168.1.25 && http |
| Post-Attack Port State | ip.dst == 192.168.1.25 && tcp.dstport == 80 |
| TCP Retransmission | tcp.analysis.retransmission |
| Conversations | Statistics > Conversations |
- Conversations
- Endpoints
- IO Graph
- Protocol Hierarchy
Every stage was saved to a dedicated .pcapng file so the traffic can be independently re-analyzed:
Packet capture files
00-baseline.pcapng
01-icmp-dos.pcapng
02-syn-dos.pcapng
03-http-dos.pcapng
•••
10-tcp-ddos.pcapng
- mod_evasive / mod_security: Apache modules that detect and throttle abusive request patterns at the application layer.
- Connection/keep-alive tuning: lowering
TimeoutandMaxKeepAliveRequestsreduces how long a single flood connection can hold a worker slot. - fail2ban: automatically bans source IPs generating abnormal connection or error rates.
- Firewalls & IPS: drop volumetric patterns like unrequested ICMP floods and excessive half-open connections at the perimeter.
- Rate limiting: cap requests per source IP over a time window (e.g. via
iptableshashlimitor a reverse proxy). - SYN cookies: kernel-level mitigation (
net.ipv4.tcp_syncookies) that avoids allocating memory for half-open connections until the handshake completes.
For internet-facing production services, routing traffic through a cloud defense network filters malicious packets before they reach the origin server:
- Cloudflare
- AWS Shield
- Azure DDoS Protection
| Attack | Layer | Target | Effect |
|---|---|---|---|
| ICMP Flood | L3 | Network | Bandwidth/CPU exhaustion |
| SYN Flood | L4 | TCP stack | Half-open connection exhaustion |
| HTTP Flood | L7 | Apache2 | Application resource exhaustion |
| TCP Flood | L4 | TCP stack | Connection + bandwidth exhaustion |
| Ping of Death | L3 | Network stack | Legacy buffer overflow (mitigated on modern kernels) |
- TCP handshakes are inherently vulnerable to resource exhaustion without SYN-cookie style protection.
- ICMP and SYN floods are easy to identify in packet captures via simple filters; HTTP floods are not.
- Simulated multi-process flooding from a single host meaningfully increases traffic volume and impact compared to a single stream, even without true source distribution.
tmuxis an effective way to orchestrate and cleanly tear down multiple concurrent attack processes during controlled testing.- Comparing captures against a genuine baseline made every subsequent anomaly easier to identify with confidence.
- Repeat the DDoS stage using genuinely separate attacking VMs/hosts instead of a single-host simulation, to compare traffic signatures against distributed source IPs.
- Deploy
mod_evasiveor a WAF in front of Metasploitable2 and re-run the HTTP flood to measure mitigation effectiveness quantitatively. - Analyze the same captures with Zeek and compare detection against manual Wireshark filtering.
- Evaluate Suricata/Snort signatures against the saved
.pcapngfiles. - Add response-time/latency measurements (e.g.
curl -w) captured during each attack stage as a quantitative impact metric. - Collect CPU, memory, and network utilization metrics from both the attacker and victim hosts during each attack stage to quantitatively evaluate resource exhaustion and service impact.
- Network Traffic Analysis
- Wireshark Packet Inspection & Filtering
- TCP/IP Protocol Analysis
- HTTP Analysis
- Linux System & Service Administration (Apache2, netstat)
- Bash Scripting & Process Orchestration (tmux)
- Python Scripting for Traffic Generation
- Vulnerable-Service Lab Setup (Metasploitable2)
- Defensive Security & Mitigation Planning
| # | File | Description |
|---|---|---|
| 00 | 00-topology.png |
Lab Topology |
| 01 | 01-baseline.png |
Baseline Traffic Capture |
| 02 | 02-icmp-dos.png |
ICMP Flood — Single Source |
| 03 | 03-icmp-ddos-script.png |
ICMP DDoS Script Execution |
| 04 | 04-icmp-ddos.png |
ICMP Flood — Simulated Multi-Source |
| 05 | 05-syn-dos.png |
SYN Flood — Single Source |
| 06 | 06-syn-ddos-script.png |
SYN DDoS Script Execution |
| 07 | 07-syn-ddos.png |
SYN Flood — Simulated Multi-Source |
| 08 | 08-http-dos.png |
HTTP Flood — Single Source |
| 09 | 09-http-headers.png |
Captured HTTP Headers |
| 10 | 10-http-ddos-script.png |
HTTP DDoS Script Execution |
| 11 | 11-http-ddos.png |
HTTP Flood — Simulated Multi-Source |
| 12 | 12-tcp-dos.png |
TCP Flood — Single Source |
| 13 | 13-tcp-ddos-script.png |
TCP DDoS Script Execution |
| 14 | 14-tcp-ddos.png |
TCP Flood — Simulated Multi-Source |
| 15 | 15-pod-dos.png |
Ping of Death — Single Source |
| 16 | 16-pod-ddos-script.png |
Ping of Death DDoS Script Execution |
| 17 | 17-pod-ddos.png |
Ping of Death — Simulated Multi-Source |
| 18 | 18-simulated-ddos-service-timeout.png |
Simulated DDoS — Browser Timeout During Concurrent Attack |
| 19 | 19-ddos-service-unavailable.png |
Simulated DDoS – 100% Packet Loss and Service Unavailability |
Note
The raw packet capture files generated during this project are not stored in this repository because the complete capture set exceeds GitHub's practical repository size limits.
Download the complete PCAP collection:
Google Drive – Complete PCAP Collection
| File | Stage |
|---|---|
00-baseline.pcapng |
Pre-attack baseline traffic |
01-icmp-dos.pcapng |
ICMP Flood — single source |
02-syn-dos.pcapng |
SYN Flood — single source |
03-http-dos.pcapng |
HTTP Flood — single source |
04-pod-dos.pcapng |
Ping of Death — single source |
05-icmp-ddos.pcapng |
ICMP Flood — simulated multi-source |
06-syn-ddos.pcapng |
SYN Flood — simulated multi-source |
07-http-ddos.pcapng |
HTTP Flood — simulated multi-source |
08-pod-ddos.pcapng |
Ping of Death — simulated multi-source |
09-tcp-dos.pcapng |
TCP Flood — single source |
10-tcp-ddos.pcapng |
TCP Flood — simulated multi-source |
This laboratory simulated DoS and DDoS behavior within an isolated VMware environment.
The attacks were generated from a single Kali Linux host using multiple concurrent processes rather than a geographically distributed botnet.
As expected, the experiments demonstrated service degradation and temporary application-layer unavailability instead of a complete operating system crash.
This behavior accurately reflects the objective of DoS/DDoS testing in a controlled educational environment, where the primary goal is to exhaust application and network resources rather than permanently disable the target operating system.
The objective of the laboratory was to analyze attack behavior, traffic characteristics, and defensive techniques rather than reproduce Internet-scale DDoS attacks.
This project built a complete, self-contained DoS/DDoS lab using only Kali Linux and Metasploitable2, covering five distinct attack primitives — ICMP flood, SYN flood, HTTP flood, TCP flood, and Ping of Death — each tested first as a single-source DoS and then as a locally simulated multi-process DDoS via tmux. Every stage was captured independently in Wireshark and compared against a clean baseline, allowing clear identification of each attack's traffic signature at Layer 3, 4, and 7. A combined-attack stage demonstrated cumulative impact on service availability. The project closes with a concrete, honest limitation — the DDoS stage simulates volume rather than true source distribution — and a set of practical next steps (multi-host testing, WAF deployment, IDS signature evaluation) to extend the work further.
An interactive version of this project, including detailed study notes, explanations, and supplementary material, is available on Notion.
🔗 View the Notion Documentation
- OWASP Testing Guide — Denial of Service Methodology
- CISA & MS-ISAC Joint Guide — Understanding and Responding to DDoS Attacks
- Cloudflare Learning Center — Layer 7 vs Layer 4 Mitigation
- Imperva Distributed Denial of Service (DDoS)
- Wireshark Documentation
- Metasploitable2 Documentation
- hping3 Manual (
man hping3)
- How to Perform a DDoS Attack Using Kali Linux | Educational Tutorial
- DDoS Attack Explained | How to Perform DOS Attack | Ethical Hacking and Penetration Testing
- How to Install Metasploitable on New VMware Workstation
- i bought a DDoS attack on the DARK WEB (don't do this)
If you found this project useful, consider starring the repository.