Looking Beyond the Theory: Building a SYN Flood DoS Home Lab
Almost every beginner in cybersecurity has heard the textbook explanation of a Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack:
A large amount of malicious traffic is sent to a server until it becomes overwhelmed.
That explanation is technically correct, but it skips the interesting part.
Why does the server become overwhelmed? What exactly happens during those few seconds? Where do the packets go? Why do half-open TCP connections consume resources? How does a detection system recognize that something abnormal is happening, and how can defenders slow it down or mitigate it?
Those were the questions I wanted answered.
The internet has countless articles explaining the theory behind DoS attacks, but I wanted to experience it firsthand. Instead of reading another diagram of the TCP three-way handshake, I generated the traffic myself, captured it with Wireshark, watched it hit the target machine, detected it with Suricata, and applied rate limiting with iptables to see how much it actually helped.
(And yes, having a college assignment that required a cybersecurity project was the perfect excuse to build it. 😄)
Project Objective
This project was never about learning how to attack a server. The goal was to understand what actually happens during a SYN Flood attack from a defender’s perspective.
I wanted to answer:
- What does a SYN Flood look like at the packet level?
- Why do half-open TCP connections consume server resources?
- How does an IDS detect abnormal connection attempts?
- Can a simple firewall configuration reduce the impact of the attack?
Building the Lab
To keep the setup simple and reproducible, I built a small virtual lab consisting of:
- A virtualization platform
- An Attacker VM (Kali Linux)
- A Defender VM (Ubuntu Server)
- hping3 to generate SYN packets
- Wireshark to capture and visualize network traffic
- Suricata for intrusion detection
- iptables to experiment with rate limiting and basic mitigation
The complete documentation, setup guide, screenshots, and configuration files are available in my GitHub repository:
GitHub Repository: https://github.com/Siriin4k/Denial-of-Service-DoS-SYN-Flood-Attack
A Quick Refresher on DoS Attacks
Not all DoS attacks work the same way. They target different parts of a system.
Volumetric Attacks attempt to consume the available network bandwidth by flooding the target with massive amounts of traffic.
Protocol Attacks exploit weaknesses in networking protocols to consume connection tables or memory instead of bandwidth. This project focuses on one such attack: the TCP SYN Flood.
Get Shreenivas Jagdale’s stories in your inbox
Join Medium for free to get updates from this writer.
Application Layer Attacks target applications rather than the network itself by sending resource-intensive requests that consume CPU, memory, or application threads.
I chose a Protocol Attack (TCP SYN Flood) for this lab because it’s a good way to understand how the TCP handshake works and why incomplete connections become a problem for servers.
The Build Was Easy, Until It Wasn’t
Setting up the lab sounded straightforward on paper. Two virtual machines, a few networking tools, generate some traffic, capture packets.
Reality was slightly different.
The biggest challenge wasn’t launching the SYN Flood, it was making sure the entire lab communicated correctly. Like most virtual networking projects, I spent considerably more time troubleshooting the environment than generating the attack itself. Ubuntu networking occasionally refused to cooperate, interfaces needed verification, firewall rules had to be checked, and small configuration mistakes often resulted in nothing happening at all.
Ironically, the attack itself was probably the easiest part of the project.
Watching the Attack Unfold
The first thing I noticed wasn’t a system crash. Instead, Wireshark quickly began filling up with TCP SYN packets originating from the attacker. Almost immediately after, the Ubuntu server started replying with SYN-ACK packets, attempting to establish legitimate TCP connections.
But something was missing.
The attacker never completed the final step of the TCP three-way handshake. Every SYN-ACK sent by the victim was simply ignored. As more SYN packets arrived, the server kept allocating resources for each new connection, assuming the client would eventually respond.
That was the moment everything clicked.
The SYN Flood attack isn’t sending large amounts of random traffic, it’s exploiting how TCP was designed to establish reliable connections. Every incoming SYN request causes the server to reserve memory and create an entry in its connection queue while it waits for the final ACK packet. When thousands of these half-open connections accumulate, the server gradually runs out of available connection slots, making it difficult, and eventually impossible, for legitimate clients to connect.
Watching this happen in Wireshark made the attack far easier to understand than any diagram or animation I’d seen before. Instead of memorizing the TCP handshake, I was watching it fail in real time.
Detecting the Attack with Suricata
Once I understood what was happening at the packet level, the next step was seeing how a defender would identify the attack.
I configured Suricata on the Ubuntu server with a custom rule to detect an unusually high number of TCP SYN packets targeting the same host within a short period. As the flood continued, Suricata generated alerts flagging the suspicious SYN traffic, confirming that the IDS was recognizing the abnormal connection pattern.
Suricata wasn’t performing any kind of magic. It wasn’t detecting a SYN Flood because it somehow knew an attack was happening, it was observing network behavior that deviated significantly from normal traffic. After watching the packets in Wireshark first, the alerts Suricata generated made a lot more sense.
Understanding the underlying network traffic makes interpreting IDS alerts much easier.
Slowing the Attack with iptables
Detection alone doesn’t stop an attack, so the next step was experimenting with a basic mitigation technique using iptables.
I configured rate-limiting rules to restrict the number of new TCP SYN packets accepted each second. The goal wasn’t to eliminate the attack entirely, that would take more advanced infrastructure in real-world environments, but to reduce its effectiveness by capping how many new connection requests the server would process.
Repeating the attack after enabling the firewall rules showed a noticeable difference. The server stopped trying to process every incoming SYN packet, and the overall impact of the flood dropped. It’s not a complete defense against modern large-scale DDoS attacks, but it showed how even simple rate limiting can protect a service from smaller, less sophisticated attacks.
That was probably my biggest takeaway: cybersecurity isn’t just about detecting attacks, it’s about understanding how defensive controls change the attacker’s behavior and make systems more resilient.
Final Thoughts
When I started this project, I expected to learn about DoS attacks. Instead, I learned far more about networking, troubleshooting virtual labs, and how detection systems actually work. Launching the attack turned out to be the easiest part, getting everything else working together was the real challenge.
That’s exactly why I enjoy building these projects. They force me to move beyond theory and understand what’s happening underneath the surface.
If you’re learning cybersecurity, build your own lab instead of just reading about these attacks. Seeing packets move across the network teaches lessons no textbook or certification course can fully replicate.
Thanks for reading. If you have ideas for improving this lab or suggestions for future projects, I’d love to hear them.
