How To Know If You're Getting DDoS'd: Technical Diagnostic Guide

To determine if you are getting DDoS'd (Distributed Denial of Service), monitor for sudden, unexplained network performance drops, high latency, and CPU or memory exhaustion alongside an anomalous spike in traffic from disparate IP ranges. Validate the attack by checking network interface traffic volume against your established baseline, inspecting active connections using network utility tools to find hundreds of connections in a SYN_RECV or TIME_WAIT state, and analyzing server access logs for repetitive, automated HTTP request patterns.

Pre-Attack Baselines & Log Preparation

Before diagnosing a potential Distributed Denial of Service attack, you must establish baseline performance metrics. Without a clear picture of normal operations, distinguishing between a malicious traffic spike and a sudden burst of legitimate organic users is exceptionally difficult. Systems administrators must maintain a documented inventory of network metrics and keep defensive utility tools pre-installed and configured.

Essential Diagnostic Tools

• Command-line network utility suites including netstat, ss, tcpdump, and tshark.
• System monitoring utilities such as htop, top, or iotop.
• Log analysis software or command-line parsers like awk, grep, and cut.
• Network visualization dashboards such as Grafana, Prometheus, or CloudWatch.

Mandatory Prerequisite Knowledge & Metrics

• Average daily bandwidth consumption measured in Megabits per second (Mbps) or Gigabits per second (Gbps).
• Standard Packets per Second (PPS) rates for both ingress and egress traffic during peak and off-peak hours.
• Typical concurrent connection counts on primary web server ports, specifically Port 80 for HTTP and Port 443 for HTTPS.
• Average CPU, memory, and disk input/output write speeds under normal traffic conditions.

Baseline Calibration Benchmarks

• Estimated Budget: $0 to $150 per month for standard cloud monitoring and logging storage.
• Duration Benchmark: Establish baselines over a continuous 14-day observation window to account for weekly business cycles.
• Log Retention Policy: Maintain a minimum of 30 days of raw server access logs and NetFlow data for comparative analysis.

Step-by-Step Technical Diagnosis of a DDoS Attack

Step 1: Differentiate Local Infrastructure Failures from Network Outages

Before looking for external malicious traffic, you must confirm that the performance degradation is not caused by an internal software failure, database deadlock, or local hardware bottleneck. A crashed web server service or a misconfigured database query can mimic the symptoms of a denial-of-service attack by making your website completely unresponsive.

Begin by attempting to log in to your hosting provider's management console or hypervisor interface. If local console access is highly responsive but public-facing services are completely timed out, the bottleneck is likely situated on the external network interface. Run a simple local ping loopback test on your server to verify that the internal TCP/IP stack is operating correctly.

Inspect the status of your web server daemon, such as Nginx or Apache, and your database daemon, such as PostgreSQL or MySQL. If these services have terminated unexpectedly due to memory exhaustion, restart them and observe if system load immediately spikes back to 100 percent. If the load spikes immediately upon service initialization, external traffic is likely flooding the open ports.

Warning: Do not automatically reboot your server as a first diagnostic step. Rebooting clears system volatile memory, which destroys active connection states, temporary log files, and routing tables that contain the raw evidence needed to identify the origin and type of the DDoS attack.

Step 2: Analyze Interface Bandwidth and Packet-Per-Second Metrics

Volumetric DDoS attacks aim to saturate your physical or virtual network interface card (NIC) by flooding it with more traffic than it can physically process. To confirm a volumetric attack, you must inspect the raw ingress traffic volume and the number of packets entering the network interface.

Access your network monitoring dashboard or execute interface statistics commands directly on the server command line. If you are using a Linux system, commands like sar, ip -s link, or running the nload utility will display real-time network throughput. Compare the current throughput against your established baseline.

If your normal peak traffic is 15 Mbps and the interface is currently receiving 950 Mbps, your network link is experiencing saturation. Pay close attention to the Packets per Second metric. A massive volume of exceptionally small packets (often 64 bytes each) is a classic indicator of a UDP or ICMP flood. Volumetric attacks often originate from thousands of spoofed IP addresses, making simple IP-based filtering at the host level ineffective.

Step 3: Inspect TCP Connection States and Identify Protocol Exploits

Protocol attacks, such as SYN floods, target vulnerabilities in the stateful connection tables of firewalls, load balancers, and web servers. In a standard TCP three-way handshake, a client sends a SYN packet, the server responds with a SYN-ACK, and the client completes the connection with an ACK packet. During a SYN flood, the attacker sends thousands of SYN packets but never returns the final ACK, leaving the server with thousands of half-open connections that exhaust the connection pool.

To identify a protocol attack, open your server terminal and query the state of active network connections. Use the command "netstat -an" or the modern "ss -tan" utility to dump the current state of all TCP sockets. Pipe this output into filters to count the occurrences of specific connection states.

Under normal circumstances, the majority of your connections should be in the ESTABLISHED or TIME_WAIT state. If your analysis reveals thousands of connections stuck in the SYN_RECV state, your system is actively undergoing a TCP SYN flood attack.

Pro-Tip: If your server connection tables are completely full, execute the command "sysctl net.ipv4.tcp_syncookies = 1" on Linux systems to enable TCP SYN cookies. This cryptographic defense mechanism allows your server to handle incoming SYN packets without consuming space in the stateful connection table, mitigating the immediate threat of a SYN flood.

Step 4: Audit Application-Layer (Layer 7) Access Logs

Application-layer attacks target specific resource-heavy endpoints of your software stack, such as database search fields, login forms, or dynamic PDF generators. These attacks do not need to saturate your network link; instead, they mimic legitimate user behavior by executing standard HTTP GET or POST requests. A relatively low volume of highly complex HTTP requests (e.g., 100 requests per second) can easily crash an underlying database server.

Navigate to your web server access log directory, typically found at /var/log/nginx/ or /var/log/apache2/. Use command-line text processing utilities to parse the active log file in real time. For instance, use a combination of awk and sort to isolate the most active IP addresses hitting your server over the last ten minutes.

Inspect the incoming requests for highly repetitive patterns. Look for identical User-Agent strings, requests targeting a single URL endpoint at unnatural intervals, or requests that lack standard HTTP headers like Accept-Language or Referer. If you discover a single IP address or a tight block of IP addresses generating hundreds of requests per minute for dynamic pages, you are facing an application-layer flood.

Step 5: Execute Traceroutes and External Network Path Audits

If you cannot establish a connection to your server from your local machine, the network path between you and your hosting provider may be saturated or experiencing routing failures. This can happen if a volumetric DDoS attack is targeting your hosting provider’s upstream internet service providers (ISPs).

Open the terminal on your local administration machine and run a diagnostic traceroute targeting your server’s public IP address. On Windows, use the command "tracert", and on macOS or Linux, use "traceroute". This utility sends packets with increasing Time-To-Live (TTL) values to map each router hop along the path to your server.

Observe where the packet transmission fails or where latency suddenly spikes. If the traceroute completes successfully through twelve hops and then fails or shows massive latency (e.g., jump from 20ms to 2000ms) at the final hop before your server, the bottleneck is directly at your server's network interface. If the failure or latency spike occurs three or four hops prior to reaching your infrastructure, the upstream network provider is currently overwhelmed by a large-scale volumetric attack, and you must contact your hosting provider to reroute the traffic.

Comparison of DDoS Attack Vectors & Technical Metrics

Common Diagnosis Missteps & Remediation Fixes

Scenario 1: Misidentifying an Organic Traffic Spike ("Slashdot/Reddit Effect") as a Malicious DDoS Attack

• Root Cause: A prominent website, influencer, or media outlet links directly to your web platform, causing an unexpected, massive influx of legitimate human visitors. System resources spike to 100%, database connections exhaust, and the website stops responding.
• Actionable Fix: Inspect your web server access logs using command-line tools to extract the HTTP Referer header. Legitimate referral traffic will contain diverse, valid referral URLs (e.g., reddit.com, news.ycombinator.com) and show a natural distribution of assets loaded, such as images, CSS, and JavaScript files. If the Referer header is present and points to a major public platform, immediately enable aggressive page caching on your web server or activate a Content Delivery Network (CDN) "Under Attack" mode to cache static assets and shield your origin database.

Scenario 2: Overlooking Internal Loopback Failures and Self-Inflicted Resource Exhaustion

• Root Cause: A malfunctioning internal cron job, database backup script, or localized API loop executes infinite recursive loops against your own local endpoints, simulating a Layer 7 DDoS attack from localhost or your own internal IP addresses.
• Actionable Fix: Run the "netstat -anp" or "ss -pan" command to identify the process ID (PID) associated with the overwhelming connection volume. If the source IP of the connections is 127.0.0.1 or your local private network IP, trace the PID back to the executing system service using the "ps aux" command. Terminate the rogue process immediately using "kill -9 [PID]" and correct the application code or cron configuration to prevent loop recursion.

Scenario 3: Implementing Naive IP-Based Firewall Bans on Spoofed Volumetric Attacks

• Root Cause: A network administrator detects a volumetric UDP or SYN flood and attempts to manually block every individual attacking IP address using local iptables or ufw rules. This process fails because the attacker is spoofing IP addresses, causing the local firewall's CPU utilization to spike to 100% as it struggles to process millions of complex rule checks.
• Actionable Fix: Immediately cease manual local IP blocking during volumetric attacks exceeding 100 Mbps. Instead, contact your hosting provider or upstream ISP and request that they implement a Null Route (blackhole filtering) on the targeted IP, or route your traffic through an external cloud-based scrubbing center. This shifts the traffic filtration burden away from your local server's CPU and onto the provider's high-capacity hardware.

Frequently Asked Questions

How do I differentiate between a DDoS attack and a sudden spike in organic traffic?

To differentiate between a DDoS attack and organic traffic, analyze your server's access logs and network packet characteristics. Organic traffic spikes consist of complete TCP handshakes, diverse user-agent strings, valid HTTP headers, and sequential page requests that load associated static assets like images and stylesheets. In contrast, a DDoS attack typically features incomplete handshakes (such as SYN floods), highly repetitive or missing user-agents, static request payloads targeting a single dynamic URL, or a massive surge in UDP packets that do not correspond to any active application service.

Can a DDoS attack compromise my sensitive data or database?

A DDoS attack itself is a resource exhaustion exploit designed to make your systems unavailable, and it does not inherently break encryption or steal sensitive data. However, malicious actors frequently use DDoS attacks as a tactical diversion to overwhelm security teams and saturate intrusion detection systems while executing targeted data exfiltration or vulnerability exploits elsewhere in your network. Additionally, if your database crashes due to resource exhaustion, improper recovery configurations might expose temporary debug logs or unencrypted swap files containing sensitive information.

What commands can I run on my server terminal to check for a DDoS attack?

On a Linux server, you can execute the command "ss -tan | awk '{print $1}' | sort | uniq -c" to see a count of all TCP connections grouped by their current state; an unusually high number in the SYN-RECV state indicates a SYN flood. To find which IP addresses are holding the most active connections to your system, run "netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n", which lists all remote IPs sorted by connection volume. To inspect incoming application-layer requests in real time, run "tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c" to watch for any single IP flooding your web server with rapid HTTP requests.

Why is my server pinging normally but my website is completely down?

If your server responds to ICMP echo requests (pings) with low latency but your website fails to load, you are likely experiencing an application-layer (Layer 7) DDoS attack or a localized service outage. Pings are handled directly by the kernel's network stack at Layer 3, which requires minimal processing power and remains functional even when the web server daemon is overwhelmed. The web server daemon (such as Nginx or Apache) operating at Layer 7 may have exhausted its worker connections or memory pool, preventing it from handling HTTP/HTTPS requests while the low-level operating system continues to reply to pings.

What is the immediate first step I should take once I confirm a DDoS attack?

The immediate first step upon confirming a DDoS attack is to change your server's DNS routing to point to an enterprise-grade DDoS mitigation service or cloud-based proxy network, such as Cloudflare, AWS Shield, or Akamai. If you are already behind a proxy network, you must immediately change your origin server's public IP address because the attackers are likely bypassing the proxy and targeting your server's direct IP. If you do not have a proxy service, contact your upstream hosting provider immediately to request that they apply rate-limiting, BGP flowspec rules, or temporary null-routing to protect your infrastructure.

Secure Your Network Against Malicious Traffic

If your diagnostic checks confirm an active distributed denial of service attack, immediate upstream mitigation is required to restore your system's operational integrity. Contact our network security operations team today to deploy high-capacity cloud scrubbing and permanently shield your origin servers from malicious traffic.