Recently encountered an evil thing, a customer's e-commerce station obviously hung a high defense CDN, or was brushed more than 100,000 fake orders. Check the log found that the attacker perfectly forged the CDN node IP, the request directly bypassed the protection system. These days, even the CDN have to “defense teammates” - you think a shield on the security, but do not know the source station verification is not good, high defense CDN will become the springboard for attackers.
IP spoofing attacks are nothing new. However, many people think that the CDN on the peace of mind, in fact, a big mistake. Attackers will now first step scanning CDN node IP segment, and then forged X-Forwarded-For this kind of header, the garbage traffic packaged as “legitimate CDN traffic” directly to the source station. I tested three mainstream CDN service providers last year, two of the default configuration actually allows any IP statement that they are CDN nodes, this security hole is simply more than a sieve leak.
The root cause is that many operations and maintenance blindly trust the IP list provided by the CDN service provider. But CDN node IPs are updated ah brother! The list of IP segments just updated last week may be invalid this week. Not to mention those CDN vendors that use elastic IPs for cloud services, node IPs change faster than a book. Expecting to manually maintain an IP whitelist? Might as well just send an invitation to the attackers.
First of all, the source IP verification. Don't use the “CDN IP Segment Book” downloaded from the internet, it expires faster than the shelf life of yogurt. I now all projects have changed to use dynamic authentication mechanism: in the CDN control panel to generate a unique Token, and then through a custom Header passed to the source station. The source site Nginx configuration directly write dead:
This trick is ruthless in what? Even if the attacker forged the IP can not get Token. tested CDN5 and CDN07 two, with custom Header authentication, illegal request interception rate directly to 100%. However, it should be noted that the Token has to be regularly rotated, it is recommended to use the key management system to automatically update.
Token alone is not enough. Last year, we encountered a case, the attacker through social engineering to get the Token (an employee threw the configuration file on GitHub), this time we need a second line of defense - fingerprinting. The principle of this technology is actually very simple: to each legitimate CDN node with a digital watermark, just like the agents issued identification badges.
I've tried to play with this on 08Host's node: inject a specific JS code snippet into the CDN configuration, and the source site confirms the identity by detecting this fingerprint. For example, have the CDN node automatically add it when it returns a response:
After the source station receives the request, the same algorithm is used to check the signature, and the time stamp deviation of more than 5 seconds is directly rejected. The most tawdry part of this program is that even if the attacker gets the key, it is useless, because the timestamp and node ID are dynamically changing. Specific implementation can be embedded in OpenResty using Lua scripts:
Now, let's talk about performance overhead. Many people hear “cryptographic authentication” on the head, think it will affect performance. In fact, the actual test, single request verification delay increase of less than 2 milliseconds. Compared to the cost of being paralyzed by DDoS, this overhead is almost negligible. But pay attention to the choice of key algorithms, don't be silly to use RSA as a heavy weapon, ECDSA or HMAC-SHA256 is completely sufficient.
Recently to help a financial platform to do penetration testing, found a more insidious attack: the attacker will first legitimate access to the CDN node, capture the fingerprint characteristics of the response header, and then try to replay the attack. At this time, just rely on static signature check is not enough, you have to add a one-time random number (Nonce) mechanism. I saw in the management background of CDN07 that the latest version of their Nonce generator has been supported, automatically refreshing the seed value once every 10 minutes.
In fact, the most hassle-free program is to directly use the vendor's SDK. like CDN5's Edge Auth module encapsulates a full set of authentication logic, the source station just need to adjust an API to verify the authenticity. But don't rely entirely on black-box solutions - I've seen a vendor's SDK blown up with a hard-coded key vulnerability. Now my approach is to use hybrid authentication: I use the vendor's SDK to do the initial filtering, and I also implement an alternate set of signature verification logic.
Speaking of specific configurations, let's give an example of Nginx in action. The following configuration implements the triple protection of IP whitelisting, Token verification and fingerprint signing at the same time:
Finally, some small CDN service providers in order to save costs, even the basic security checks are too lazy to do. Last time I tested a CDN called “intelligent high defense”, found that they actually put the verification logic on the client JS execution - this is not obvious to tell the attacker “quickly to bypass me? This is a clear message to the attackers, ”Come on, bypass me! So the selection must be technical team field test protection program, do not just look at the publicity blown sky-high.
A truly reliable protection system must be multi-layered and dynamic. Source IP verification is just the foundation, fingerprinting is the rebar, but also with a series of measures such as traffic behavior analysis (to detect abnormal request patterns), rate limiting (to prevent CC attacks). I now deploy solutions to all customers, will require at least once a month to do a simulation bypass test - security this thing, there is no once-and-for-all program.
To be honest, in the last three years, the amount of IP forgery attacks has doubled more than tenfold. Attack tools have begun to integrate CDN fingerprinting, and any open source tool can automatically identify CDN vendors and capture node characteristics. If the defense is still stuck in the “configuration of a whitelist on the level of thinking,” the breach is really just a matter of time.
Lastly, I'd like to share a lesson learned: never leak validation details in the error log! I've seen a system that returns “Signature Expired” and “Token Invalid” when verification fails, isn't that like handing a knife to an attacker? The correct approach is to return a uniform “404 Not Found”, so that the attacker can not even touch the reason for failure.
Protecting against IP forgery attacks is like playing a game of cat and mouse; there is no silver bullet solution. The key is to establish a continuously evolving defense system, after all, the attacker's means are also constantly upgrading. At least from my combat experience, the combination of dynamic Token and cryptographic signature program, the 90% forgery attack can be held down at the source.
