At three o'clock in the morning, I was hugging the quilt dreaming of marrying my daughter-in-law, and my cell phone suddenly shook wildly like a catalyst. Touch over a look, monitoring alarms blew up - the customer's production environment traffic instantly soared to 20 times the usual, TCP connections burst the table, the business response is slow as a snail crawling. First reaction: DDoS again. The first reaction: another DDoS. I copied the phone to call the CDN vendor to urge emergency cleaning, while cursing while logging into the console to block the IP. half an hour finally stopped, but the boss the next day chased and asked: "Who in the end did it? How can we prevent it next time?" I stared at the background of the blocked IP segments, suddenly realized: no log analysis, security is simply blindfolded fighting.
High-defense CDN this thing, many people think to buy a package, with a domain name CNAME on the end of the matter. Attacks come by vendors cleaning, daily by cache acceleration, logs? That is not the thing that takes up the hard disk? But in the real battlefield, the log is the real "battlefield recorder". You blocked every IP, blocked every malicious request, cache every hit, all lying inside. Security engineers who do not know how to dig logs are just like taking a golden bowl - the resources are there, but you will not use them.
What treasure is hidden in the journal? For example, the last time I encountered a CC attack, the other party used thousands of puppet IP low-frequency climb login interface, the traffic is not big but extremely disgusting. The regular WAF rules were not triggered, but the business side kept reporting a surge in CAPTCHA errors. I directly pull the real-time logs of CDN07 (his family supports second log push), wrote a Python script to run field statistics:
Immediately pulled out a dozen IP: each IP request about 30 times per minute, return all 200 but with CAPTCHA error mark. You see, just look at the traffic curve farts can not be found, but the logs directly give you a portrait of the attacker - IP segment concentration, User-Agent disguised as Chrome, Referer uniformly for the empty. Later directly to this group of IP added a speed limit rules: more than 10 login requests per minute to jump the CAPTCHA, the attack on the same day to rest.
Trace the source of the attack? You're blind without a log. Don't believe those "one-click traceability" bragging propaganda, really encountered advanced point of the attack, the other party has already put the IP pool, proxy chain laid. But logs can help you spell out the attack chain. For example, last year I ran into a blackmail gang that used AWS elastic IP to penetrate the API interface of one of our customers. Relying on CDN5's detailed logs (his family defaults to recording X-Forwarded-For and real client IPs), I restored the attack timeline:
Without logs, the most you can see is the end result of "US IP theft". However, combining timestamps, URIs and IP geographic changes, you can invert the attacker's tool chain and proxy strategy - this is too critical for subsequent reinforcement: WAF rules plus Sqlmap fingerprinting, login interface plus geographic anomalies (such as Vietnam IP suddenly jumped to the U.S. to directly trigger the secondary authentication).
Optimizing defense strategies? Tuning parameters by feel is metaphysics. I've seen a lot of teams buy high defense CDN just follow the default rules with, was hit on the crazy plus slider verification, normal users complained. In fact, the logs have long told you how to optimize. Take 08Host's log as an example, each of their requests are labeled "security event label" (such as "Web attack" "CC attack" "normal request"). I directly write a script to analyze last week's logs:
Turns out: the /api/v1/payment callback interface is swept every day, but the 80% malicious requests come from an IP segment under the same ASN. Simple enough - directly add a smart traffic limit to this ASN number, with rules as loose as 5 requests per second (enough for normal business, but not enough for blasting), and zero false positives. And save money on buying extra CC protection packages.
How do you play with logs in real life? First.Don't use the castrated version of the console log view.-Fields are incomplete, the sampling rate is pitiful, the search is slow to skepticism. Honestly open the full amount of logs to push, docking S3 or Elasticsearch. CDN07 and CDN5 support real-time logs to push, 08Host have to add money to buy the enterprise version (here to spit: are high defense still key logging features?). I'm not sure if you're going to be able to do that. I usually directly dislike to ELK stack, take Kibana to do visualization. Share a common Kanban configuration I use:
Secondly.Don't just focus on IP blocking... Advanced attackers change IPs more often than socks. I prefer to analyze session patterns: for example, it is normal behavior for the same IP to visit "login page -> user home page -> order page" for a short period of time, but "login page -> CAPTCHA interface -> login page" cycling 10 times is definitely a blast. This requires correlating multiple log entries into sessions - we recommend writing a real-time rule with Flink or Spark Streaming, which works much better than single-point IP blocking.
Throw in a final hardcore case: One time a customer was crashed by a slow attack, where each TCP connection was held for several minutes before sending a few bytes. The traffic monitor could not see any abnormality at all. Later, CDN5's TCP logs (note: not HTTP logs!) were pulled and found that a large number of connections came from the IP segment of a niche cloud provider. I found a large number of connections from a niche cloud service provider's IP segment, each connection survival time of more than 300 seconds but less than 1KB of data transfer. directly write iptables rules to block the entire ASN:
The world is clean. You can't even determine the type of attack without a log, let alone accurately block it.
Seriously, these days even the CDN have to "prevent teammates" - some vendors in order to show "good defense", deliberately filter the attack logs cleanly, the console only give you to see the number of bans. Really encountered advanced infiltration, such as people hit the source station you have not noticed. SoIt's more important than anything to keep a copy of the original log at home., the day the defense is torn down, you can still rely on the logs to do a digital autopsy.
To summarize, log analysis of high-defense CDN is not an "optional feature" at all, but the nerve center of the defense system. By relying on it, you can see the whole picture of the attack, adjust the accuracy of the strategy, and even push back the attacker's intention. Don't wait for the moat to be blown through before you remember to dig trenches - start collecting logs today. (And of course, remember to buy a hard drive. Don't ask me how I know.)
