Cloud systems offer a distinct advantage over on-premise legacy solutions. Hosting your content on a local server makes them vulnerable to cyber-attacks. With the resources available today, it is not difficult to launch an attack on systems that are completely on-premise. With the cloud, your content is distributed across a number of servers; sometimes located across the world. This way, even if a server gets under attack, your content is still safe and the backup systems can kick in to keep your services running.
But cloud systems are slowly losing this edge as well. As the recent attack on Dyn shows, services hosted in the cloud are no-less susceptible to DDoS attacks than the on-premise solutions are. And that is mainly possible because of the cloud itself. DDoS attacks are, in practice, always over the cloud. So no matter how distributed your cloud system is, it is theoretically possible to build a cloud network that can overwhelm this service through a DDoS attack.
In essence, this is a cat and mouse game between the hosting provider and the attackers. While it may be pretty impossible to build a foolproof system that attackers can never breach, you can always make it harder for them economically – build a network that is large enough to take on the providers network.
One of the most popular ways to do this is through a Content Delivery Network (CDN). A CDN is essentially a cloud network that caches your content on to their servers so that most of the incoming traffic is handled by their server and not yours. And since their core purpose is to build a fail-safe server system, they have far more resources to invest in building a distributed cloud system that hackers cant afford to bring down.
This comes with its own set of problems. With a CDN, you point all your incoming web traffic to an IP address that belongs to your CDN provider. While this works well for all your content on HTTP/S, your private IPs like your email servers does not pass through the CDN still. So if the hacker is able to get hold on your core IPs this way, they may still be able to attack your system regardless of whether you use a CDN or not. You can prevent this by using separate C-Class ranges for your SMTP and web services.
Another way to fix this is by using a proxy-based solution. Such services act as a TCP/UDP proxy and act as a counter against any network layer DDoS attacks. Your users may however face increased latency due to this. Alternately, users may hide their infrastructure IP addresses by pointing them all to a CDN IP. This protects your IP from being exposed to potential hackers.
A number of businesses are also looking at the option of using multiple CDNs for their services. The most viable way to do this is to use an aggregator service that seems like any other CDN service on the front-end for the user to connect to. In the back-end though, the aggregator is connected to multiple CDN providers. This way, the content presented to your website visitors may come from one of the several CDN providers (depending on your location, the media content you are accessing, etc.). Also, in case of a DDoS attack, your service may still be accessible since the aggregator may pull your content from one of several CDN providers. It is going to be very expensive for an attacker to build a network that can scale up large enough to bring multiple CDN providers down.
