preface
Traditional DDOS defenses often use a “hard” approach, which can be expensive and sometimes ineffective. For example, if DNS is used to switch over faulty IP addresses, the front-end service cannot take effect quickly because the domain name is affected by cache and usually has a minute-level delay. For example, the CDN service can resist most network layer attacks, but it often fails to attack the application layer. Attackers can consume traffic and log storage expenses through malicious requests, resulting in service failure. For example, the purchase of flow cleaning and other services, although the effect is good but the cost is very expensive.
Today share an ultra-low cost website DDOS defense solution – without using any back-end defense services, pure front-end implementation! Of course, the effect can be extreme: if the user has not visited the site before, this defense does not take effect and the site is still inaccessible. But if the user has visited the site before, then can ignore the attack, even the server down the site can be accessed, and can be updated!
The front-end agent
Cloudflare comes to mind when it comes to features such as low cost, anti-attack, and offline access. However, as mentioned earlier, we don’t use back-end defense, but a pure front-end implementation.
In fact, we can move Cloudflare to the browser front end! The Service Worker, an API in HTML5, can intercept all requests from the current site and control the results, acting as a reverse proxy Service. With this black technology, you can realize the CDN function in the front end.
We can prepare multiple sites for redundant backup of static resources. When the Service Worker loads the resource incorrectly, it does not return the error to the upper page, but continues to load from the secondary site until the correct result is obtained. This way, resources do not fail to load as long as an alternate site is available.
This JS-controlled scheme can be accurate to the millisecond level and has many chances of trial and error, significantly increasing stability compared to the minute delay of traditional DNS switching over failed IP.
Offline access
Service Worker is designed to enhance the offline experience of web pages. Therefore, once installed, it can run in the background for a long time. Even if the server is shut down and the browser is restarted, it will not fail.
In fact, in addition to resources in the web page that can be blocked by the Service Worker, the web page itself can be blocked as well. When the Service Worker is installed, the request made by the user entering the URL into the address bar is actually blocked, allowing the web file to be loaded from the alternate site.
Note that this is not a redirect and the address bar will not change.
So even if the site goes down, previously visited users can still access it by loading pages from the alternate site via the Service Worker.
Free node
Although using redundant sites can improve the stability, attackers can still launch attacks on standby sites, especially malicious attacks that consume traffic costs, resulting in a significant increase in costs.
A more extreme solution is to use free CDNS as backup sites, such as Jsdelivr.net, unpkg.com, IPFS Gateway, etc., with photos uploaded to albums on various websites.
For non-picture type files, you can even package them into pictures to upload, and then extract them when you use them! For example, this file is extracted from this image.
While the stability of a single free CDN may not be high, the stability increases exponentially with a few more.
As for malicious attacks, they are almost impossible to defeat. The essence of Distributed DOS (DDOS) is that Distributed traffic is aggregated to increase damage. We, on the other hand, neutralize attacks by spreading centralized traffic around as a decentralized, distributed site.
demo
Although the principle of this scheme is not complicated, there are still many details in its implementation, such as the selection strategy of nodes, the format of resource list, etc., and security issues such as content integrity of third-party sites and offline resources tampered with by XSS should also be paid attention to.
For the convenience of developers, a command line tool github.com/EtherDream/… , can achieve all the functions mentioned above.
Demo case: freecdn.etherdream.com/time.html
This page through HTML output current time, refresh can change.
Close the page and exit the browser. Add 0.0.0.0 freecdn.etherdream.com to hosts to block the domain name and the simulated site is crashed.
Open your browser and visit the page again. Not only is the page accessible, it can even be refreshed and updated!
As you can see from the console, the Service Worker can still load pages from the standby site even though the current site is disconnected!
Interface defense
For sites with purely static resources, we can accelerate all resources, including HTML files, through free CDN, thus greatly reducing costs and increasing stability.
But how to defend against dynamic interfaces? Dynamic interface defense is a little more complicated, but there are still some clever schemes. For example, cloud firewall and Service Worker use the agreed algorithm to generate port numbers, so as to constantly change ports to intercept attack traffic. For example, agents to multiple cloud host vendors “uproot” free amount of defense traffic; For example, buying a large number of public IP addresses from the cheapest preemptive host… More on that next time.
Of course, even without the dynamic interface, a crashed site can still access static content, just not interact with it, which is much better than not being able to open it at all.