How to Stop a DDoS Attack: Step-by-Step Response Guide

When a DDoS attack hits, you need a clear plan. Panic and ad-hoc troubleshooting waste the minutes that matter most. This guide gives you a step-by-step response procedure you can follow during an active attack, plus the preparation steps that make a fast response possible.

If you are currently under attack, skip to Step 1 below. If you are reading this to prepare for future incidents, start with the preparation section at the end.

Step 1: Confirm It Is a DDoS Attack

Not every spike in traffic is a DDoS attack. Before you start applying mitigation, confirm that you are actually under attack and not experiencing a legitimate traffic surge, a misconfigured service, or a different type of outage.

Check These Indicators

• Packets per second (PPS): A sudden spike in PPS, especially in a single protocol (UDP, SYN, ICMP), strongly suggests a DDoS attack
• Source IP distribution: Attack traffic typically comes from many distributed sources. If all traffic comes from one IP, it might be a single misconfigured client
• Traffic pattern: DDoS traffic is usually uniform (same packet sizes, same protocol, same destination port). Legitimate traffic varies
• Service health: Are all services affected, or just one? DDoS typically impacts everything on the targeted network/server
• Monitoring alerts: Did your detection system classify this as an attack?

If you have Flowtriq deployed, this step is already done. Flowtriq's automatic classification tells you immediately whether you are experiencing a DDoS attack, what type it is, and which node is targeted. You can skip directly to mitigation.

Quick Diagnostic Commands

If you do not have automated detection, these commands help you assess the situation:

# Check current PPS and bandwidth
sar -n DEV 1 5

# Count connections by state
ss -s

# Top source IPs by packet count (quick sample)
tcpdump -i eth0 -c 10000 -nn 2>/dev/null | \
  awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

# Check for SYN flood (high SYN_RECV count)
ss -tan state syn-recv | wc -l

# Protocol distribution
tcpdump -i eth0 -c 5000 -nn 2>/dev/null | \
  awk '{print $2}' | sort | uniq -c | sort -rn

Step 2: Identify the Attack Type

Knowing the attack type determines your mitigation approach. The most common types and how to identify them:

UDP Flood

Signs: Massive spike in UDP packets, often to random destination ports. Bandwidth utilization increases sharply.

SYN Flood

Signs: Large number of SYN_RECV connections in ss -tan state syn-recv. High rate of new TCP connections with very few completing the handshake.

DNS/NTP Amplification

Signs: High volume of UDP packets from source port 53 (DNS) or 123 (NTP). Packets are large (often 512+ bytes for DNS, 400+ bytes for NTP). Your server did not initiate these requests.

HTTP Flood

Signs: Web server CPU spikes. Access logs show high request rates to specific endpoints. Individual requests look valid but the volume is abnormal.

ICMP Flood

Signs: Spike in ICMP echo request packets visible in tcpdump or netstat output.

Flowtriq automatically classifies attacks into eight categories (SYN flood, UDP flood, ICMP flood, DNS amplification, NTP amplification, HTTP flood, TCP ACK flood, GRE flood) within one second of detection, eliminating the manual investigation this step usually requires.

Step 3: Apply Immediate Local Mitigation

The first priority is to reduce the impact on your server. Local firewall rules are the fastest mitigation because they operate at the kernel level on your own machine.

For UDP Floods

# Drop all UDP except specific services you need
iptables -A INPUT -p udp --dport 53 -j ACCEPT   # Keep DNS if needed
iptables -A INPUT -p udp --dport 123 -j ACCEPT  # Keep NTP if needed
iptables -A INPUT -p udp -j DROP                 # Drop everything else

# Or rate limit UDP
iptables -A INPUT -p udp -m limit --limit 500/s --limit-burst 1000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

For SYN Floods

# Enable SYN cookies (may already be on)
sysctl -w net.ipv4.tcp_syncookies=1

# Rate limit SYN packets
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Reduce SYN-RECV timeout
sysctl -w net.ipv4.tcp_synack_retries=2

For DNS/NTP Amplification

# Block unsolicited DNS responses
iptables -A INPUT -p udp --sport 53 -j DROP

# Block NTP monlist responses
iptables -A INPUT -p udp --sport 123 -j DROP

For ICMP Floods

# Rate limit ICMP or block entirely
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Block Specific Source Networks

If the attack traffic comes primarily from identifiable IP ranges:

# Block a specific source network
iptables -A INPUT -s 192.0.2.0/24 -j DROP

# For many sources, use ipset for better performance
ipset create attackers hash:net
ipset add attackers 192.0.2.0/24
ipset add attackers 198.51.100.0/24
iptables -A INPUT -m set --match-set attackers src -j DROP

Important: Flowtriq automates all of these steps. When an attack is detected, your configured auto-mitigation rules generate and apply the appropriate iptables or nftables rules within seconds. No SSH, no manual commands, no typing errors under pressure.

Step 4: Assess Whether Local Mitigation Is Sufficient

After applying local rules, check whether the situation has improved:

• Is your application responding to legitimate requests?
• Has bandwidth utilization returned to manageable levels?
• Are the firewall rules actually dropping the attack traffic?

# Check iptables drop counters
iptables -L -v -n | grep DROP

# Check if bandwidth is still saturated
sar -n DEV 1 3

# Test application responsiveness
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" http://localhost/

If your application is responding normally and the firewall is dropping the attack traffic, your local mitigation is working. Move to Step 6 (monitoring) and skip the escalation step.

If your upstream bandwidth is still saturated (meaning the attack volume exceeds your network capacity), local firewall rules will not help. You need to escalate to upstream mitigation.

Step 5: Escalate to Upstream Mitigation

When the attack volume exceeds your server's or network's capacity, you need to stop the traffic before it reaches your infrastructure.

Option A: Contact Your Hosting Provider or ISP

Most hosting providers and ISPs have DDoS mitigation capabilities. Contact their support or NOC and provide:

• Your IP address(es) being targeted
• The attack type (UDP flood, SYN flood, etc.)
• Approximate volume (Gbps or PPS if you can measure it)
• Source port or protocol characteristics they can filter on

Response time varies by provider. Some have automated mitigation that activates in minutes. Others require manual intervention that can take hours.

Option B: Activate Cloud Scrubbing

If you have a cloud scrubbing service (Cloudflare, Akamai, Voxility), activate it according to their procedures. For BGP-based services, this means announcing your IP prefixes through their network. For DNS-based services (Cloudflare for web), it means ensuring your DNS points through their proxy.

Option C: BGP FlowSpec

If you have BGP peering with your upstream provider and they support FlowSpec, you can push filtering rules upstream:

# Example: FlowSpec rule to drop UDP from source port 53 to your IP
# (Actual syntax depends on your BGP implementation)
flow {
    match destination 203.0.113.10/32;
    match protocol udp;
    match source-port 53;
    then discard;
}

Flowtriq can trigger BGP FlowSpec rules automatically as part of its escalation policy. If local iptables rules do not reduce the attack volume sufficiently, Flowtriq pushes FlowSpec rules to your configured BGP peers without manual intervention.

Option D: RTBH (Last Resort)

If nothing else works and the attack is impacting your entire network, you can black-hole the targeted IP address. This sacrifices availability for that single IP but protects everything else on your network.

# Announce a /32 route to your ISP's RTBH community
# This causes all upstream routers to drop traffic to this IP

RTBH means the attacker wins for that specific IP. Use it only when the collateral damage of the attack on your broader network outweighs losing one IP address.

Step 6: Monitor and Adjust

DDoS attacks are not static. Attackers change their tactics when they see their initial approach being mitigated. Stay vigilant and watch for:

• Vector shifts: The attack switches from UDP flood to SYN flood or HTTP flood
• Volume escalation: The attacker increases the volume to overwhelm your mitigation
• Target changes: The attack moves to a different IP address or service
• Multi-vector combination: Multiple attack types launched simultaneously

Keep your monitoring active and be ready to adjust your mitigation rules. If the attack shifts to a different vector, you may need to apply additional firewall rules.

Flowtriq's continuous monitoring handles this automatically. If the attack vector changes, Flowtriq detects the new pattern, reclassifies the attack, and adjusts mitigation rules accordingly. You receive updated alerts with the new classification.

Step 7: Document and Communicate

While the attack is being handled, keep stakeholders informed:

• Post a status update on your status page
• Notify affected customers through your support channels
• Keep your team updated on mitigation progress in your incident channel
• Log every action you take with timestamps for the post-incident review

Be honest about the impact. Customers appreciate transparency more than silence.

Step 8: Post-Attack Recovery

Once the attack subsides, do not just remove mitigation rules and move on. Follow these recovery steps:

Verify Service Health

• Check that all services are responding normally
• Verify database connections are stable
• Confirm that load balancers and reverse proxies are routing correctly
• Test from multiple geographic locations

Remove Mitigation Rules Gradually

Do not remove all firewall rules at once. Attackers sometimes pause and resume. Remove rules one at a time and monitor for resurgence. If the attack returns, reapply immediately.

Flowtriq handles this automatically with its mitigation lifecycle management. Rules are maintained while the attack is active and removed gracefully when traffic returns to baseline.

Review Forensic Data

Analyze your PCAP captures and incident logs to understand:

• What type of attack was it?
• Where did the traffic originate?
• Were the sources spoofed or real (check TTL distribution)?
• Did the attack match any known botnet signatures?
• How long did each phase last?
• What mitigation was most effective?

Flowtriq's incident reports include all of this information, with AI-powered PCAP analysis that highlights the key patterns without requiring you to manually examine packet captures in Wireshark.

Step 9: Improve Your Defenses

Every attack is an opportunity to strengthen your defenses. Based on what you learned:

• Update your mitigation playbook with lessons from this incident
• Tune your detection thresholds if the attack was detected too slowly or generated false positives
• Add auto-mitigation rules for the specific attack types you experienced
• Review your escalation path and pre-configure upstream mitigation so it activates faster next time
• Check for exposed services that could be locked down (close unnecessary ports, restrict source IPs)
• Consider adding detection coverage to any servers that were not monitored during this attack

Preparing Before the Attack

If you are reading this before an attack, here is what to set up now:

1. Deploy detection on every server. Flowtriq's agent installs in under five minutes and provides instant coverage with dynamic baselines.
2. Configure alerting channels. Set up Slack, Discord, PagerDuty, or whatever your team monitors. Test that alerts actually reach the right people.
3. Set up auto-mitigation rules. Define what should happen automatically for each attack type. At minimum, configure iptables rules for SYN floods and UDP floods.
4. Establish your escalation path. Know who to contact at your hosting provider. Pre-configure BGP FlowSpec if available. Set up cloud scrubbing integration if needed.
5. Document your runbook. Write down the steps specific to your infrastructure. Include IP addresses, contact numbers, login credentials for provider portals, and BGP configuration details.
6. Run a drill. Simulate an incident and walk through your response procedure. Identify gaps before a real attack finds them.

The best incident response is the one that happens automatically. With Flowtriq's detection, classification, alerting, and auto-mitigation, most attacks are handled before your team finishes reading the alert notification. The manual steps in this guide become your fallback for unusual scenarios, not your primary response.

Back to Blog

Related Articles