Recently, I helped my friend to investigate a website that was hit by a hanging, logged into the CDN background to take a look, good guy, the attack traffic is almost breaking through the T-level, but the defense strategy of the high defense CDN is actually like a leaky spoon did not stop a few requests. The real business has long been paralyzed, but the console also shows \u201ceverything is normal\u201d, which is an ironic picture that can be used as a network security propaganda film.<\/p>\n
These days, even CDNs have to \u201cprevent teammates\u201d. Vendor publicity T-level protection sounds bluff, but the configuration is not right or understanding bias, minutes for you to run naked in the Internet gunfire. I tested the market five or six mainstream high-defense services, stepping on the pit summarized five of the most common reasons for the failure of the high-defense CDN - some pits can even let the manufacturer's technical support are scratching their heads.<\/p>\n
First, the source station IP leakage: you think hidden, in fact, in the naked<\/strong><\/p>\n The most common and fatal error. A lot of webmasters think that the set of CDN on a high level of peace of mind, do not know that the attacker minutes can pick out your real server IP. once the source station IP exposure, the attack traffic directly bypass the high-defense CDN to the server, what protection has become a setup.<\/p>\n Last year, I helped an e-commerce site to do penetration testing, using an open source fingerprinting tool to directly scan out the source IP - just because they forgot to delete the source pointing to a sub-domain in the A record. More common is through the mail server, old sub-domains, and even SSL certificate information to reverse check IP. do not believe that \u201cthe set of CDN is absolutely safe\u201d nonsense.<\/p>\n Solution:<\/strong><\/p>\n 1. Strictly isolate the access path to the source station and allow only the CDN return source IP segment to access the server port. Like CDN5 provides a private back to source network is quite good to use, you can also customize the encrypted tunnel;<\/p>\n 2. Periodically use the tool to self-review IP exposure risks:<\/p>\n 3. Separate third-party solution for mail services (e.g. SendGrid), never the same IP as the business;<\/p>\n 4. The server firewall denies all traffic by default and opens the necessary ports only to the IP segments provided by the CDN vendor. the CDN07 documentation provides a list of global node IPs directly. remember to update it once a week.<\/p>\n II. Misconfiguration of protection rules: open lid does not mean ready to use<\/strong><\/p>\n The most outrageous case I've seen is that an enterprise bought a top-tier high defense package, but the WAF does not even turn on basic CC protection - because they thought it was \u201call on by default\u201d. In fact, most CDNs nowadays, in order to reduce the number of false positives, only open the basic rule base by default, such as slow attacks, API abuse, which need to be manually configured.<\/p>\n Others have set their protection thresholds to be extremely aggressive: a single IP is allowed 1000 requests per second, making CC protection a nullity. It is important to know that the peak of real user behavior usually does not exceed 20 requests per second, not to mention the \u201csmart mode\u201d of some vendors is actually just a threshold switch.<\/p>\n Solution:<\/strong><\/p>\n 1. WAF rule base at least open to the \u201cstrict\u201d level, don't be afraid of mistakenly blocked, it's better than being hit by hanging;<\/p>\n 2. Customized frequency rules: I used to set thresholds by business type. the API gateway is limited to 50 times per second for a single IP, static resources are relaxed to 200 times, and the login interface must be pressed to less than 10 times;<\/p>\n 3. Enable human-authentication challenge mode to pop up the CAPTCHA directly for suspicious traffic. 08Host has done a good job in this area and supports multiple modes of senseless authentication and JS challenge;<\/p>\n 4. Regularly look at attack reports: focus on attack patterns that intend to bypass the rules, such as random UserAgent or XFF header fields.<\/p>\n Third, the certificate and protocol compatibility issues: TLS can also become a vulnerability<\/strong><\/p>\n Encountered a particularly pitiful situation: the customer bought a small factory's high-defense CDN, the results of the other party does not support the TLS1.3 protocol. The site was forced to downgrade to TLS1.2, it happened to run into the use of protocol loopholes in the CC attack, the CPU directly soared full. More common is the misconfiguration of the SSL certificate leads to CDN can not be normal handshake, traffic back to the source of the unencrypted naked.<\/p>\n Solution:<\/strong><\/p>\n 1. Test the full encrypted link with Qualys SSL Labs:<\/p>\n 2. Ensure that the certificate chain is complete and intermediate certificates must be deployed. It is recommended to use automatic certificate management services, CDN5 and CDN07 both provide one-stop SSL deployment;<\/p>\n 3. Disable older protocols (SSLv3, TLS1.0) and force the SNI extension to be enabled;<\/p>\n 4. The link back to the source should also be encrypted, don't use HTTP back to the source - seen too many people fall foul of this.<\/p>\n Fourth, DNS resolution misconfiguration: the fatal blind spot of traffic routing<\/strong><\/p>\n High-defense CDN is essentially scheduling traffic through DNS. However, many people have improperly configured CNAME records, or the TTL value is set too large, resulting in delayed parsing when the attack is switched. The most extreme case is that the DNS cache in some areas is up to a few hours, and the business has collapsed long before the defense strategy takes effect.<\/p>\n There are also people who forget to press the line to resolve traffic first when switching between high defense and normal CDN. The result of directly switching DNS records is that some users go to the old node, some go to the new node, and there is a gap in the defense strategy.<\/p>\n Solution:<\/strong><\/p>\n 1. Always CNAME the domain name to the protected domain name provided by the high defense CDN first, and then the CDN back to the source;<\/p>\n 2. Set the TTL time shorter, 300 seconds for normal use and 60 seconds for emergency switching;<\/p>\n 3. Use DNSPod's or Cloudflare's multilinear parsing function to dispatch to high-defense nodes individually for the attack area;<\/p>\n 4. Do DNS penetration testing on a regular basis:<\/p>\n V. Conflicts between business characteristics and protection strategies<\/strong><\/p>\n This is the most easily overlooked point. Certain business itself has high-frequency request characteristics (such as WebSocket long connection, video streaming), blindly open strict protection will lead to a large number of false positives. I've seen an online education platform where video heartbeat packets were intercepted by CC rules, causing users to drop out like crazy when watching classes.<\/p>\n In addition the protection of the API interface should be handled separately. the characteristics of the JSON format POST request are different from those of an ordinary form request and require the adjustment of the WAF detection rules. The default rule base of some vendors has a detection rate of less than 30% for API attacks.<\/p>\n Solution:<\/strong><\/p>\n 1. White list test must be done before the business goes live: record real business traffic for playback and observe the protection rules to kill the situation;<\/p>\n 2. WebSocket and long connection services to take a dedicated forwarding channel, 08Host's WebSocket protection policy is optimized separately;<\/p>\n 3. API services enable specialized protection modes to focus on new attack vectors such as JSON deep parsing and GraphQL injection;<\/p>\n 4. Real-time log analysis must be done, ELK stack or directly with the CDN vendor's logging services to catch anomalous patterns more reliable than simply relying on WAF.<\/p>\n Final Notes<\/strong><\/p>\n High-defense CDN is not a plug-and-play safe, but a sophisticated system that requires continuous tuning. A truly effective defense = 70% correct configuration + 20% monitoring and warning + 10% emergency response. Don't completely rely on the vendor's \u201cautomatic protection\u201d, take a look at the real-time traffic mapping, and regularly do attack and defense drills.<\/p>\n If you really want to recommend - CDN07 cost-effective for small business, CDN5 Anycast network preferred for large traffic scenarios, and the pursuit of extreme customization can look at 08Host's hybrid protection solution. But remember, there is no one-and-done program, only continuous iteration of the security strategy.<\/p>\n (No problem after checking these configuration items? Private message me to send a diagnostic report to help see if you are experiencing an evil attack)<\/p>","protected":false},"excerpt":{"rendered":" Recently, I helped my friend to investigate a website that was hit by a hanging, logged into the CDN background to take a look, good guy, the attack traffic is almost breaking through the T-level, but the defense strategy of the high defense CDN is actually like a leaky spoon did not stop a few requests. The real business has long been paralyzed, but the console also shows \u201ceverything is normal\u201d, the irony of this picture can be used as a network security propaganda film. These days, even CDNs have to \u201cprevent teammates\u201d. Vendor publicity T-level protection sounds bluff, but the configuration is not right or understanding of bias, minutes for you to run naked in the Internet gunfire. I have tested the market five or six mainstream high-defense services, stepping on the pit summarizes the five most common reasons for the failure of high-defense CDN - some pits can even let the manufacturer's technical support are scratching their heads. First, the source station IP leakage: you think hidden, in fact, in the naked run The most common and most fatal error<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-1052","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts\/1052","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/comments?post=1052"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts\/1052\/revisions"}],"predecessor-version":[{"id":1073,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts\/1052\/revisions\/1073"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/media?parent=1052"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/categories?post=1052"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/tags?post=1052"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/collection?post=1052"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}