Recently to help a few social platforms to do security reinforcement, turn over their high-defense CDN logs almost did not make me laugh - attackers are now even “3:00 a.m. on time to punch the clock to work” this kind of tawdry operation have been engaged in this year's blackmail also rolled into a twist ah.
To be honest, many teams don't even look at CDN defense logs. Thought open WAF can rest easy, the results of the attack traffic around like a stroll in the back garden. I've seen the most outrageous case: a social app was gripped 300G traffic every day, the operation and maintenance froze for three months to see the logs did not find any abnormal fields.
Let's start with the distribution of attack types. From the CDN5 and CDN07 logs that I tested, 70% of the attacks on social business are focused on the API layer. Especially the user dynamic release interface, just change a User-ID can traverse the entire user data:
Such requests are hidden very deep in the logs. Normal user requests are around 200ms, malicious traversal requests are commonly over 2 seconds, but you need to correlate the response length field with the 5xx error code query to lock it down.
Even nastier are CC attacks faked to look like crawlers. When a customer used CDN5's default configuration, it was penetrated by 800 login interface requests per second - the attacker simulated the complete behavior of Chrome browser for each IP, even the MouseMove event was faked. I later added dynamic fingerprinting checks to the WAF to stop it:
When it comes to crawler defense, don't believe the CDN vendors advertise “intelligent human-machine recognition”. I tested three mainstream service providers, the default rules on the recognition rate of simulated clicks is less than 40%. later to 08Host proposed a program: in the login page buried in the invisible Honeypot field, the robot 100% will fill these fields, the real person can not be seen - a single move to stop 90% of automation! This is a good way to stop 90% of the automated registration attacks.
In fact, the biggest pitfall of log analysis lies in time correlation. Once the customer said that the traffic spiked in the early hours of the morning every day, thinking that it was a normal user activity. As a result of a look at the log, the attacker picked 3:00 am to 6:00 am to brush the coupon interface, because this time the operation and maintenance of the most lax monitoring. Later made a hot interface time distribution map before pulling out:
This type of attack is to be analyzed with temporal correlation. I poured CDN07 logs into ELStack (self developed logging system) and set up an anomalous time band alert rule:
Another advanced attack is a slow HTTP DoS, where the attacker sends only a few bytes per request, dragging the entire connection pool. In the logs, it is shown as a very long connection duration + very small traffic, which can't be found by regular WAF. Later, I added TCP link layer analysis to the edge node of 08Host, and saw more than 10 minutes of half-open connections directly pinch line.
Speaking of optimization strategies, the first thing to change is the default CDN configuration. Almost all vendors of WAF factory settings are “low sensitivity”, even SQL injection detection are watered down. It is recommended that the first thing to do when you get the permission is to adjust the rule base:
The second focus is on customizing rule weights. Many teams directly open the learning mode, and the result is poisoned by attackers - deliberately triggering false positives with normal requests, so that the WAF will adjust the malicious rule weights down. I now recommend using dual engines in parallel: CDN5's AI engine for primary screening, and then use self-developed rules for secondary checking:
Finally, you must do attacker profiling. Once I found that a certain IP tried 20 kinds of attack techniques every day, from SQL injection to SSRF to change the pattern. It was found to be an infiltration team hired by a competitor, specializing in testing vulnerability offers. Later, we directly made a threat scorecard and started human verification on the high scoring IPs:
Nowadays, blackmail loves to play a combination of punches. First, half an hour of slow detection to find the URL parameter format released by WAF, and then use 200 cloud function nodes to explode at the same time. Once the defense log showed that the attacker even used ChatGPT to generate normal user conversation content to hide the malicious payload - this year AI are starting to engage in blackmail.
To be honest, looking at defense logs is like solving a crime. Attackers will always leave traces: an IP never with Referrer, a User-Agent version number is fixed to 99.0, a certain type of request must be triggered by the 504 error ... Recently, to help customers troubleshooting found that the attacker group actually used the popular video ID as a control command in the comments of the Shake Shot, buried in the encrypted command word decoding triggered a CC attack, which is the hole in the brain! This is a great idea.
It is recommended to take half an hour every weekend to go through the logs. Focus on the distribution of anomalous response codes, the diversity of requests from the same IP, and the API calls in unconventional time periods. Once I found that a certain IP requests per second is always 59 times (just stuck in the 60 times / second threshold of the flow limit), along the way to the end of a professional DDoS gang.
Now the customer is using the solution I tuned to deploy a mix of CDN07 and 08Host for dual-link redundancy. The rulebases of the two vendors complement each other, 08Host is good at identifying protocol layer attacks, and CDN07's AI engine is more sensitive to behavior detection. Monthly defense costs increased by 8%, but the traffic gripped by blackmail dropped from 20TB per month to less than 100GB - this ROI ratio is blood money.
Finally throw a king bomb solution: bury custom scripts in CDN edge nodes. When encountering a suspicious request to return to the fake data + tracking markers, not only can reduce the attack revenue, but also reverse traceability of the attacker. The specific code is too long to post, the core idea is:
Security is never permanent. Today to prevent the attack method, tomorrow may be a new variant. The key is to analyze logs as a daily routine, and slowly you can develop the intuition of “one glance false” - once I was because of an IP TCP initial window size anomaly, I dug out a network using IoT devices as proxies.
By the way, don't be fooled by the defense statements provided by vendors. They will include simple attacks to show their effectiveness, and the actual effective defense rate may be discounted. It is best to write your own scripts to run log analysis, focusing on the business impact of the real attack blocking data.
Now customers are much more calm when they encounter attacks. Last time a social platform was hit by a million QPS, according to the defense logs quickly adjusted the rate limiting strategy, ten minutes to stabilize the situation. The boss's words were: “This sense of security is more real than buying three years of insurance”.
