I remember last year a customer to find me emergency fire, said the site was suddenly hit to downtime, a check of the logs found that the source station IP was precisely blasting - the attacker simply did not go CDN, directly to the source station IP crazy output. I asked him how to match the CDN, he justified: “not on the domain name CNAME to the CDN vendor to the address?” As a result of a look at the configuration, good guy, the source server actually tied to the domain name directly resolved A record, firewall rules do not restrict the CDN back to the source IP segment. This kind of operation, equivalent to the hacker issued a straight through the source station of the VIP ticket.
In fact, the source station IP exposure this shit, nine times out of ten are configuration omissions or understanding bias. Some people think that the use of CDN will rest easy, but do not know that CDN is just a layer of shield, the shield itself is not covered tightly but will become a weakness. Common acts of death include: the source server opened a remote debugging port and public access, DNS records remain in the source A record, SSL certificate application leak source IP, and even directly in the code to write the dead source IP call API. even more outrageous is that some small and medium-sized vendors of the default configuration of the CDN allows users to bypass the cache through a specific Header or URL parameters to connect directly to the source station! --This is simply a backdoor for attackers.
I've tested three major CDN providers and found that even for the same vendor, the default security policies for different packages can be wildly different. For example, CDN5“s Starter Edition actually does not automatically hide the source Server header, while their Enterprise Edition will be forced to rewrite the response header. There is also a pitiful detail: some CDNs will throw the source IP error information to the client when the return source fails, which is called ”fault feedback exposure", specially pitched for white users.
Why do you have to die to hide the source IP, these days DDoS attacks have long been industrialized, the cost of penetrating the CDN is getting higher and higher, but if you touch the source IP, the cost of the attack directly down two orders of magnitude. I have seen the most tragic case is an e-commerce station source IP exposure, was paralyzed with 50Gbps UDP Flood, cloud vendors directly to the source server to pull the black hole for 24 hours - to know that now just a broiler cluster can easily create T-level traffic. What's even more disgusting is that once the source IP is tagged, the subsequent port scanning, vulnerability detection and API abuse all follow, which is as difficult to clean up as a cockroach nest being stabbed.
Speaking of multi-layer forwarding, the essence of this thing is to put a Russian nesting doll on the source IP. The first layer relies on the CDN edge node to carry traffic, the second layer uses a reverse proxy or intermediate source to do isolation, and the third layer is the real source station. The key is to let the attacker can only ever see the outermost proxy IP, and back to the source link IP are intranet or whitelist communication. Here I strongly recommend using the “intermediate source” program: do not let the CDN directly back to the real server, but in the middle of the insert a proxy layer (such as Nginx reverse proxy cluster), the proxy layer and the CDN with a dedicated line or intranet interconnection between the external completely invisible.
Specifically, take the Nginx configuration as a chestnut. Suppose your real source intranet IP is 192.168.1.100, the intermediate source proxy server public IP is 203.0.113.10 (but only allow CDN back to the source IP segment access), CDN edge node back to the source point to this intermediate source IP. then in the intermediate source server, the nginx.conf key configuration is long like this:
Don't underestimate these lines of configuration! I help a financial station to do reinforcement, just rely on this intermediate source architecture to stop 70% of the scanning behavior. Because even if the attacker picks out the IP 203.0.113.10, will only see a proxy layer disguised as a CDN, can not touch the 192.168.1.100 real server. What's more, the intermediate source can also be deployed WAF, rate limiting, human verification and other additional security modules - equivalent to the source station on the double insurance.
Now let's talk about the choice of CDN vendors. Randomly pick three comparisons: CDN5, CDN07, 08Host. CDN5“s strong point is that there are many overseas nodes, but the default security policy is weak, you have to manually open the ”strict back to the source mode“ in order to lock the whitelist; CDN07 domestic acceleration is ruthless, support for multi-layer forwarding native integration (they call it ”shield source architecture“), but the price can be more expensive than 40%; 08Host cost-effective route. ”Shield Source Architecture"), but the price can be more expensive than 40%; 08Host cost-effective route, buy high defense packages to send intermediate source services, but node stability occasionally jerk. I measured the pressure test, CDN07 in 300Gbps DDoS can still maintain the middle source link does not leak the real IP, while some cheap vendors encountered large amounts of traffic directly back to the source of the exposure - so do not believe that "absolutely hidden" nonsense, the key is to look at the underlying network design. The key is to look at the underlying network design of the vendor.
There is also a tawdry operation of nesting with multiple CDNs. For example, using CDN5 to do the first layer of edge acceleration, back to the CDN07 intermediate source cluster, and then ultimately back to the real server. This nesting mode although the cost doubled, but once helped a game company to resist a 1.2Tbps hybrid attack - the attacker even the first layer of CDN Anycast IP did not penetrate, not to mention the traceability. Of course, this solution requires fine-grained DNS scheduling and session hold configuration, or users may experience latency jitter across CDN hops.
Lastly, I'd like to throw some cold water on it: there is no program that can 100% ensure that the source IP is never exposed. There have been hackers who indirectly deduced the source IP through SSL certificate handshake timing analysis, HTTP/2 stack fingerprinting and even CDN node IP segment reverse mapping, etc. So in addition to multi-layer forwarding, you have to work with the regular replacement of the back to the source IP, disable the ICMP response, shut down the non-essential ports and other basic operations. I used to use Shodan to sweep the IPs associated with my own domains once a month to check for any accidentally exposed services - it's much better than waiting to be hit and then crying.
In short, hiding the source IP is a systematic project, not a simple set of CDN is finished. You have to pile up defense from three dimensions: network architecture, configuration specifications, and monitoring response. Now look at my year that was hit by the customer, he later spent double the budget to rebuild the architecture, but to save ten times the potential downtime losses - this wave is not bad. Remember: security this thing, rather than over-designed do not leave it to chance, after all, blackmail buddies can be more than we rolled.
