Recently, I helped a friend to check a station that was hit by a hanging, and found that although they put on a high-defense CDN, they didn't verify whether the defense was effective or not. Once the attack came, the source station IP was directly exposed, and the CDN became a setup. These days, even the CDN have to “defense teammates” - some vendors have not written their own configuration documents to understand.
Is it true that a high defense CDN can carry a beating? Don't listen to sales bragging, they measured it. I've seen too many people think that they bought the service to rest easy, and as a result, the first wave of traffic over the direct naked. Today's chat of the two test methods, I stepped on the pit over the years stepped out of the experience, and can even in turn force the vendor to give you the configuration.
Let's start with a cold shower: what you think is “in effect” may be an illusion.Many vendors default to only open protection for some nodes, or caching policy is set so badly that the traffic does not go to the cleaning center at all. The core of the test is just one sentence:Ensure that all attack traffic must pass through the CDN's cleansing node while the originating site is completely invisible.
The two methods below, the first for quick verification and the second for high voltage simulation, are used in combination for true peace of mind.
Method 1: DNS resolution test - basic but deadly
If you don't do this step right, it's all for naught. I found that more than 30% of the configuration problems in the DNS resolution. Many people change the CNAME thought it was finished, but do not know the local DNS cache, TTL time difference can let you run naked for hours.
Always remember:First, use dig or nslookup to check your domain name resolution resultsThe command: "resolves" is a command that is used to resolve an IP address. Ideally. the resolved IP must be the node IP of the CDN vendor and not your source site IP. such as with this command:
If the pop-up is your source station IP, hurry to check the DNS configuration. Don't laugh, I also met a customer last month, CNAME record value filled in the wrong letter, resolution directly back to the source, hard “false protection” for three months.
The tougher move isModify local Hosts file to force resolution to CDN node. For example, you point the domain name to the test IP provided by the CDN vendor, and then visit the website to see if it is normal. If normal, it means that the return link from the node to the source is through; if it reports an error, there may be a problem with the return configuration (e.g., host headers or certificates).
Some vendors such as CDN07 will provide a dedicated test domain, so you do not have to wait for DNS to take effect to check the status of the node. This feature is actually quite practical, but 80% of the sales will not take the initiative to tell you - after all, more is better than less.
Method 2: Simulated Attack Test - Playing for Real is Reliable
It is not enough to parse correctly, you have to prove that the node can really carry the hit. Here are two recommended directions: DDoS traffic simulation and CC attack testing.
DDoS TestingIt's best to find a vendor to work with. Legitimate high-defense vendors such as CDN5 and 08Host allow customers to launch simulated attacks during the test period (of course, you have to make an appointment in advance). Their engineers will keep an eye on the traffic panel to help you analyze the cleaning effect. Don't fight blindly by yourself, especially those who buy a VPS and open hping3 rash - be careful of being blocked by the operator's network segment.
Focus when testingLatency variation and packet lossThe website should be almost imperceptible under normal cleaning conditions. Normal cleaning state, site visits should be almost senseless, while monitoring the background to see the cleaning traffic spike. For example, the last time I measured 08Host node, 200G per second UDP flood hit the past, business latency only rose 20ms, which is really effective.
CC Attack TestIt's more suitable for messing with yourself. Use a tool to simulate a lot of normal requests, like frantically scrubbing some dynamic page:
Pay attention to the QPS curve and status code return from the CDN console. If a large number of requests go directly back to the source or the source CPU spikes, it means that the CC rules are not in effect. Good protection should be able to intercept malicious requests directly at the edge nodes and even return CAPTCHA challenges.
Here's the spitball: some manufacturers' CC rules have ridiculously low default sensitivities that you have to take a beating before they're willing to adjust. So you might want to go hard on it when testing, and hit it right up to the trigger threshold to get it right.
A bonus tawdry action: back-propagating attack paths with SSH logs
If your source server has SSH on, go straight to the /var/log/secure logs (Linux systems). In a real attack, if the CDN isn't in effect, you'll see a lot of blasted login attempts coming from the real IP; if it's in effect, all requests should only be coming from the CDN's return source IP segment.
This method is more accurate than looking at business logs because hackers always love to sweep port 22 by hand, and this type of traffic is not cached, and definitely goes back to the source.
Testing is not a one-off
Just because it works today doesn't mean it will work tomorrow. Especially when your website has new features or changed its architecture, it is likely that some interfaces bypass the CDN again. It is recommended that you use the above method to fully check every three months, especially DNS resolution and source site exposure risk.
One last big riposte:The depths of high defense CDNs are often not in the technology but in the business. Some vendors sell you 10G of protection, the actual may share the bandwidth pool; claiming that any attack can be prevented, the result of CC rules have to add money to open. Tests not only verify the effect, but also a means to force them to fulfill their promises.
After all, you're paying for security, not psychological comfort.
