I just finished deploying a high defense CDN for a customer, and the website crashed directly. The background white screen, user complaints like snowflakes flying in. A check of the logs, good guy, the server firewall CDN nodes all to the shield - this scene I can meet seven or eight times a year.<\/p>\n
High-defense CDNs and server firewalls aren't natural enemies at all, but misconfiguration can put them at each other's throats. Many teams think that they have bought a protective service and everything will be fine, and as a result, their own firewalls have become the biggest attackers. Today we will break open the rubbing to make it clear, how to make these two brothers coexist peacefully.<\/p>\n
Why was there a civil war?<\/strong>CDNs are proxies by nature, and all traffic is forwarded from CDN nodes. If your firewall is still on IP whitelisting mode, which will only release real user IPs, then all the requests from CDN nodes will be blocked as bandits. I've realistically found that more than 60% configuration conflicts are due to this.<\/p>\n An e-commerce client fell into this pit last year. They used CDN07's top protection package, but forgot to adjust the server firewall rules. On the day of the promotion, all the CDN nodes were blocked by their own firewall, and they directly lost millions of orders. Don't believe in the \"default configuration is enough\" nonsense, security and availability must be adjusted by your own hands.<\/p>\n The real solution is two-way authentication<\/strong>.. Both the firewall should recognize the CDN node and the CDN service should verify the backend server. Here's a configuration plan I polished up in a financial project, follow it to avoid the 99% pitfalls.<\/p>\n Let's address the most damaging whitelisting issue first. Mainstream CDN service providers make their node IP segments public, which must be synchronized to the firewall allowed list in real time. Take CDN5 as an example, their Asian node IP segments are updated weekly, you have to write a timed crawl script:<\/p>\n If you use Cloudflare or CDN07 or other international services, the IP segments change more frequently. It's better to use their API to update dynamically. 08Host's domestic node is more stable, just update it once a month, but remember to set up an exception alarm - I had a half-hour service interruption due to a delay in updating the IP database.<\/p>\n A more advanced play is to use the XFF header for secondary verification<\/strong>. The firewall only releases the CDN node IPs, while the application layer verifies the real user via the X-Forwarded-For header. This way even if the whitelist is breached, there is a second barrier:<\/p>\n Firewall rules need to be refined<\/strong>I've seen too many teams just turn off their firewalls to save money. I've seen too many teams just turn off the firewall to save money, which is the same as leaving the vault door wide open. The correct approach is to limit the CDN nodes to allow access to only the necessary ports. For example, web servers only open 80\/443, database servers are not exposed to CDN. With iptables can be written this way:<\/p>\n Don't forget the protocol compatibility check<\/strong>. Some firewalls intercept CDN's special protocol headers. When debugging CDN5's WAF function last year, I found that their anti-crawler fingerprints were misjudged as malicious loads by the server firewall. It was only when I used tcpdump to grab packets that I found out:<\/p>\n Now my team made a habit: every time on the new CDN service before, necessarily first intranet traffic mirroring test compatibility. Simply put, it is to find a server to mirror the production environment traffic, and gradually release the CDN nodes to observe the firewall logs.<\/p>\n Alarm monitoring is essential<\/strong>. After the configuration is done you should monitor the firewall interception in real time. I recommend using ELK stack to collect iptables logs and set threshold alarms. Immediately notify when the CDN node IP is intercepted an abnormal number of times:<\/p>\n The final word on brand selection: CDN5 has the fewest node IPs, the best firewall management but the protection ability is average; CDN07 has the most global nodes, but the IP segments change frequently and the maintenance cost is high; 08Host's compromise is more suitable for medium-sized enterprises, and the domestic latency can be controlled within 30ms. If the pursuit of ultimate security, you can buy their exclusive node package - although three times more expensive but do not have to share IP segments, firewall rules can be streamlined 70%.<\/p>\n These days even CDNs have to \"prevent teammates\", in the end, or configuration awareness is not in place. Seen too many teams to high defense CDN as a silver bullet, but ignored the most basic firewall tuning. Remember a principle: the security chain can not have a single point of failure, but even more can not contradict themselves. Next time before the deployment, run the configuration script in this article, can save the trouble of being woken up by the alarm in the middle of the night.<\/p>\n A truly excellent architecture should allow high defense CDN and server firewalls to work together like right and left hands. One in the periphery to carry the DDoS flood, an intranet to pull out the leakage of fish. As long as the proper configuration, the combination can make the attacker completely desperate - I am responsible for the highest financial system to carry 800Gbps attack, the business curve did not shake a little.<\/p>\n If your configuration is correct and you are still having problems, it is likely that the TCP stack parameters need to be optimized. cdn traffic is extremely volatile, and the default syn backlog and timeout settings may not be able to hold up. But that's another topic, I'll break down the TCP tuning practices in detail after five hundred likes.<\/p>","protected":false},"excerpt":{"rendered":" I just finished deploying a high defense CDN for a customer, and the website crashed directly. The background white screen, user complaints like snowflakes flying in. A check of the logs, good guy, the server firewall to the CDN nodes are blocked - this scene I can meet seven or eight times a year. High-defense CDN and server firewalls are not natural enemies at all, but improper configuration can make them choke each other. Many teams think that they have bought a protective service and everything will be fine, and as a result, their own firewalls have become the biggest attackers. Today we will break open the rubbing to make it clear, how to make these two brothers coexist peacefully. Why is there a civil war? The essence of the CDN is a proxy, all traffic is forwarded from the CDN node. If your firewall is still open IP whitelist mode, will only release the real user IP, then the CDN node request will all be treated as bandits to stop outside the door.<\/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-1012","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\/1012","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=1012"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts\/1012\/revisions"}],"predecessor-version":[{"id":1113,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/posts\/1012\/revisions\/1113"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/media?parent=1012"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/categories?post=1012"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/tags?post=1012"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/en\/wp-json\/wp\/v2\/collection?post=1012"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}