DDoS Attack Log Analysis and Traceback Methods: Layered Forensics and Response When Bandwidth Is Saturated

Seeing a dense list of unfamiliar IPs in the logs and rushing to block or trace their origins often leads to collateral damage for legitimate users without relieving bandwidth pressure. The correct approach is to first use logs to determine whether the attack hits the network layer, transport layer, or application layer, then decide based on protocol characteristics whether to scrub at the edge or rate-limit at the origin.

Logs Can Identify Attack Type, Not the Attacker

In most people's intuition, logs are enough to find the attacker, but in UDP reflection amplification scenarios, this logic completely fails. The source IP recorded in logs is not the attacker's real address but the address of a exploited public server (e.g., NTP server). For NTP services running on UDP port 123, the stateless nature of UDP makes it easy for attackers to spoof source IPs. When an attacker sends tiny queries to open NTP servers on the internet, exploiting the monlist feature from the historical vulnerability CVE-2013-5211, it can trigger response packets amplified up to 5500 times bouncing back to the victim's target IP.

Therefore, the true value of log analysis is not to lock in the attacker's identity but to deliver three things: which layer the attack hits, what protocol technique is used, and at which layer to respond. For reflection attacks, the endpoint of traceback is a list of reflection sources and a set of traffic characteristics, not the attacker's geographic location. If you block based on source IPs in logs, you are essentially blocking innocent public infrastructure, which neither cuts off the attack source nor may cause compliance risks.

Inbound Traffic and Port Distribution: How to Read Reflection Ports Like UDP 123, DNS

The first critical piece of evidence comes from inbound traffic sampling at the network layer. Ops personnel should focus on three metrics: inbound bandwidth curve, packets per second (pps), and port/protocol distribution. When traffic is concentrated on a single UDP port, you can preliminarily classify it as a reflection amplification attack. For example, UDP port 123 indicates NTP reflection, while DNS, CLDAP, etc., also belong to the common reflection port family.

The key to interpreting this set of features lies in "asymmetry": the destination port is fixed to the victim's service port, the source port is fixed to the protocol's default port (like 123 or 53), source IPs are highly dispersed across open services worldwide, and single packet sizes are usually larger than normal, with almost no corresponding outbound traffic. This traffic pattern is sufficient to prove the use of reflection amplification. Given the unreliability of source IPs, the response focus should shift from "chasing people" to "breaking the path": identify which protocol ports are being abused and perform inbound drops on these non-essential UDP ports at the firewall or edge nodes.

Connection States and L4 Counters: Division of Labor Among Half-Open, Concurrent, and New Connection Rates

The second piece of evidence comes from L4 connection state statistics. Unlike network-layer floods, transport-layer attacks focus on exhausting server connection resources. By bucketing connection counts by state, you can distinguish attack patterns: accumulation of half-open connections (SYN_RECV) typically indicates SYN flood attacks, while a large number of ESTABLISHED states with very low actual requests points to slow connection occupancy.

At this stage, it is essential to strictly distinguish between "total concurrent connections" and "new connection rate per second." The former reflects the current resource occupancy level, while the latter reflects the impact intensity of the attack. Note that even if anomalies are found in L4 statistics, they still cannot reveal the attacker's identity because SYN floods can also spoof source IPs during the TCP handshake via deception techniques. The primary role of L4 counters is to help ops judge whether the incident is "connection exhaustion" or "bandwidth saturation," thereby deciding whether to adjust kernel parameters to limit connections, increase bandwidth capacity, or enable traffic scrubbing.

Seven-Layer Feature Fields in access.log and limit_req Rate-Limit Logs

The third piece of evidence comes from L7 request logs, which is the key area for distinguishing how to distinguish DDoS from CC attacks. CC attacks differ fundamentally from network-layer floods in that they leave complete HTTP request records in access.log. Effective interpretation includes URI concentration, homogeneity of User-Agent and Referer, regularity of request intervals, and per-IP request rates.

NGINX's ngx_http_limit_req_module uses a leaky bucket algorithm for rate limiting. Its configuration semantics are shown in the table below:

Requests that are rate-limited leave records in the error log, and this is the only category of L7 evidence where source IPs are basically trustworthy. In terms of layered capability comparison, RockCloud's high-defense CDN and WAF retain L7 request and interception logs at the edge, complementing origin logs: after network-layer reflection traffic is absorbed at the edge, no such logs remain at the origin, but L7 request records can still be obtained at the edge. Ops personnel should note that after integrating such edge protection, they must confirm real IP passthrough configuration; otherwise, the source IP dimension in origin logs will be completely lost, causing rate-limit keys to degrade to origin IPs, potentially affecting all site users.

Reflection Source List and Spoofed Source IPs: What Can Traceback Truly Deliver?

Synthesizing the evidence from the first three layers, we need to re-examine the value of traceback. There are three roles in the reflection amplification chain: the attacker, the exploited open reflection servers, and the victim. Victim-side logs can only see the middle layer. Therefore, the deliverable is not the attacker's identity but a list of reflection sources—which open services were exploited, which protocols and ports were concentrated—and a set of traffic characteristics, including packet size, source ports, and rate curves.

This list and feature set are highly valuable in practice: they can be used to petition upstream ISPs for filtering, submitted to cloud service providers for scrubbing policies, or served as a basis for internal protocol hardening. Source IP spoofing relies on the stateless nature of UDP, which is inherent at the protocol level, not merely a configuration error. Attempting to penetrate this mechanism via logs to find the manipulator behind it is often futile without cross-organizational intelligence collaboration.

Three Scenarios Where Logs Fail: Saturated Links, Upstream Blackholes, and Sampling Gaps

Log analysis is not omnipotent; in the following three scenarios, source-side logs lose their meaning. First, when link bandwidth is saturated, data collection itself suffers packet loss, affecting log writes, and the visible curve is truncated and distorted data. Second, after upstream ISPs trigger blackhole routing, inbound traffic drops to zero, presenting a false "attack stopped" appearance while business is actually interrupted. Third, if NetFlow/sFlow sampling ratio is too high or sampling is interrupted, high-frequency small-packet attacks can be severely underestimated.

According to Cloudflare reports, in the first half of 2026 there were 935 network-layer DDoS attacks exceeding 1 Tbps, with a 519% sequential increase in Q2 compared to Q1; DNS flood attacks rose to 40.0% of network-layer attacks, and CLDAP reflection floods surged by 580% sequentially. At such scales, single machines and ordinary data centers have no chance to leave valid logs, so classification must be pushed to the edge. On the topic of what to do when logs show only origin IPs after CDN integration, the core solution still relies on real IP passthrough using headers like X-Forwarded-For; if not configured correctly, L7 logs cannot be used for IP-based analysis of CC attacks.

From Judgment to Action: Which Layer of Response Does Each Evidence Layer Map To?

The final action guide is to map each layer's judgment to specific response actions. If inbound port distribution indicates reflection amplification, the response should be port convergence and inbound drop on non-essential UDP ports, with absorption done at the edge rather than the origin. If L4 connection states indicate connection exhaustion, the response should be to implement limits on connection counts and new connection rates, and tighten timeout parameters. If L7 logs indicate a CC attack, the response is rate limiting based on limit_req and rule-based interception.

For businesses that have already suffered large traffic attacks, you can refer to the architectural solution for responding to T-level DDoS attacks to optimize network topology. Also, if you suspect origin IP leakage, follow the emergency handling and repair steps for origin IP leakage for remediation. It is recommended to first classify this incident to a specific layer following the three-layer evidence order in this article, then decide on response actions; if the judgment falls into the category where "the link is already saturated and origin-side logs have lost meaning," consider pushing scrubbing and L7 classification to the edge. RockCloud's high-defense CDN and WAF offer such edge-bearing and request logging capabilities; before integration, confirm real IP passthrough and origin-pull enforcement configurations.

FAQs

In what order should I check logs when my server is abnormal?

Follow the order of network layer, transport layer, and application layer. First look at inbound traffic graphs to confirm if bandwidth is saturated, then check connection state statistics to confirm if resources are exhausted, and finally analyze access.log for request patterns. This order helps quickly rule out underlying physical bottlenecks, avoiding wasted effort at the application layer.

What kind of attack is high inbound traffic on UDP port 123?

This is typically an NTP reflection amplification attack. UDP 123 is the NTP service port, and attackers exploit features like monlist to spoof source IPs and send requests, causing a flood of response traffic. Characteristics include dispersed source IPs, larger than normal packet sizes, and no corresponding outbound traffic. Immediately check NTP configuration or block the port.

Can DDoS source IPs be traced when spoofed?

You cannot trace back to the real attacker, but you can trace to the reflection sources. The IPs in logs are exploited public servers. The true "traceback" deliverable is a list of abused protocol ports and reflection sources, which can be used to appeal to ISPs or perform targeted blocking on those reflection paths in firewalls, rather than hunting the mastermind.

How do I analyze CC attack IPs in nginx logs?

Look at URI concentration, User-Agent homogeneity, and request frequency. Normal user behavior is dispersed; CC attacks often show high-frequency access to specific endpoints. Combined with error logs from limit_req, you can filter IPs that trigger rate limiting. Ensure real IP passthrough is enabled; otherwise, logs will only show CDN origin IPs.

After integrating CDN, logs only show origin IPs—how to restore source IP analysis?

You must configure the real_ip module on your origin web server (e.g., NGINX), specify the CDN origin IP ranges, and extract the client's real IP from the X-Forwarded-For header. Without this, all access log remote_addr will be CDN node IPs, causing rate-limit policies to fail or inadvertently block legitimate traffic.