Hit by DDoS? Emergency Response Steps

Site under DDoS—what now? Walks through confirming attack type, first-hour actions, SYN Flood temporary mitigation, switching to anti-DDoS, and post-incident hardening.

Site suddenly unreachable, bandwidth saturated. First thought is usually: am I under DDoS? This FAQ walks the full emergency process after a DDoS hit: how to confirm attack type, what to do in the first hour, how long the server can hold, when to switch to anti-DDoS, and the post-incident hardening checklist.

Q: How do I confirm this is real DDoS, not a traffic spike?

Business peaks vs DDoS come down to three checks: traffic far above historical peaks, source IPs abnormally dispersed or abnormally concentrated, and whether requests have business meaning. Log into the server and confirm fast:

`# Check TCP connection state distribution
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn
# Check real-time bandwidth and connection sources
iftop -nNP`

If SYN_RECV is in the thousands, bandwidth is saturated, and source IPs have no business pattern, it is DDoS. Also contact the cloud provider or colo to confirm ingress traffic—they see it more clearly than the server.

Q: After confirming the attack, what should I do in the first hour?

• Confirm attack type: volumetric (UDP Flood, SYN Flood) vs application-layer (CC). Countermeasures differ completely.
• Notify upstream: contact the cloud vendor or colo immediately; request traffic scrubbing or blackhole routing.
• Switch protection: if you already have anti-DDoS IP / anti-DDoS CDN, cut DNS to the anti-DDoS nodes immediately.
• Preserve evidence: export traffic screenshots and log snippets for later claims and attribution.

Do not scramble the order: keep the site reachable first, then investigate why you were hit.

Q: Can SYN Flood be mitigated temporarily on the server?

Yes. Enable SYN cookies so the kernel does not wait on half-open confirmation:

`sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_synack_retries=2`

tcp_syncookies=1 is the core switch. tcp_max_syn_backlog grows the half-open queue. tcp_synack_retries cuts retries and speeds release. Be clear: these parameters only mitigate low-volume attacks. Once attack bandwidth exceeds the server uplink (e.g. 1Gbps+), no server-side tuning helps. Scrub upstream.

Q: How to handle UDP reflection/amplification?

UDP amplification (DNS, NTP, Memcached reflection) is characterized by fixed source ports, huge volume, and no relation to the business. Disable all unnecessary UDP services on the server and have the upstream provider apply ACL filtering at the edge. The server itself cannot withstand this class of attack. Upstream scrubbing only.

Q: When should I buy anti-DDoS IP or anti-DDoS CDN?

Rule of thumb: attack bandwidth over 100Mbps, a single incident lasting over 30 minutes, or repeated hits in a short window. Choice:

• Anti-DDoS IP: origin hidden behind anti-DDoS. Fits port-based services, games, and app backends.
• Anti-DDoS CDN: fits websites. Scrubbing plus acceleration, simpler config.
• Tight budget: ordinary CDN day-to-day, switch to anti-DDoS lines under attack. Common compromise.

Q: Does changing IP fix it?

Usually no. Attackers typically locate the target via DNS. A new IP is re-scanned within hours to a day. Correct approach: change IP and hide origin together. Origin firewall allows only anti-DDoS node origin-pull (whitelist fixed origin-pull IP ranges). Domain always resolves through anti-DDoS/CDN. Also handle old IPs leaked in DNS history.

Q: What hardening after the incident?

• Hide origin: origin firewall allows only anti-DDoS/CDN origin-pull nets.
• Monitoring/alerts: bandwidth and connection-count thresholds. Know within 5 minutes of attack start.
• Playbook: write down anti-DDoS cutover steps. Drop DNS TTL to under 300 seconds in advance.
• Pre-provision: onboard and test anti-DDoS before you need it. Do not wait until you are hit to open the service.

Core idea for DDoS: solve traffic problems at the traffic layer. Server and application tuning is auxiliary. Finer playbook, smaller live loss.