Why always-on DDoS mitigation is a necessity

Traffic filtration scheme with private encryption keys kept secret

We often hear that a DDoS-mitigation, which in our case is an “always-on” service in most scenarios, is less efficient and more expensive comparing to an “on demand” mitigation.

The reasons used in that type of speech are pretty much the same every time it occurs: the delay of an actual attack mitigation period, due to human involvement after the request for mitigation, versus a higher price of a continuous filtering.

Qrator Labs wants to make it clear how an “always-on” technique differs from the “on demand” filtering and why the first one is, actually, the one and only viable option.

So why an “always-on” mitigation is the only practical approach for defending against DDoS attacks? Severe modern attacks evolve fast.

At the same time a website or an application are also changing, so it may be that the “normal” behavior of users during the previous attack is no longer relevant.

It is not only the time that takes a specialist to acknowledge the attack type before applying accurate and precise countermeasures: he or she will also need to know when the vector of attack changes to make such on-demand mitigation useful.

An under attack adoption of the mitigation service is also quite complicated, mainly due to the service degradation for all users trying to reach the contested resource. If an attack is successful and users do not get the requested resource — they try to get it once again, just refreshing the page or reloading an application. This worsens the attack scenario because it gets harder to differentiate junk traffic from the legitimate one.

Strictly speaking, it does not matter if a DDoS-mitigation service is cloud-based or not (it can be an on-premises solution as well). Both those kind of products allow automatic or manual attack detection and mitigation, and the availability of the first option is crucial.

While cloud mitigation services filter all incoming traffic — it is entirely available for analysis and detection — an on-premises solution installed at the network edge or receiving the copy of the traffic gives you almost the same set of options for real-time monitoring and mitigation. Some vendors advice to detect attacks by analyzing on NetFlow or other metrics and this is a compromise by itself because such an approach could narrow down the options for attack detection and mitigation. Vice versa, cloud services are not obliged to analyze 100% of traffic, but they usually do, since this is the best way to get models built and algorithms learned.

Another NetFlow disadvantage is that it gives only the flow description, not the actual flow data. So you could see the attack basing on those parameters NetFlow shows, but it could not detect those inside data flow sophisticated attacks. So, L7 attacks are hard to detect basing on the NetFlow metric, only if there are serious movements inside transport because above L4 NetFlow is useless.

A general DDoS-mitigation cloud adoption schema

1. Why are cloud DDoS-mitigation providers characterized as an “always-on” filtration network even without ongoing attack?

Because an “always-on” mode is the recommended one to mitigate attacks fast and efficiently. It is important to say here, that an “on-premises” equipment does not differ a lot, except for the fact that it is switched on and off on-premises, somewhere at the datacenter. However, the choice is still there and has to be made.

Theoretically, there could be some degradation in latency — especially when the nearest node is a far away one and the client wants some local traffic. On the contrary, what we often see is a slight improvement in overall latency due to fastening HTTPS/TCP handshakes over properly built filtration network with right node allocation. No one could argue that a proper mitigation system is faster and more reliable than a network that needs protection.

Saying, that reverse proxy usage for traffic filtration limits mitigation options only to HTTP and HTTPS (SSL) protocols is half correct — the other side of the medal is that HTTP traffic is one of the most important components of complex filtration. Reverse proxy is one of the most efficient ways to do this.

2. As we know, DDoS attacks can take many forms and shift from HTTP protocols to others. How is cloud better than a single on-premise equipment?

Overwhelming separate nodes is possible, as it is possible to do the same with a hardware equipment. There is no hardware powerful enough to mitigate those strongest attacks solely — a complex system is needed.

However, even those biggest vendors recommend switching to cloud filtration in worst cases — because their clouds consist of probably the same equipment built into the cluster, which is by default more powerful, than a single piece of hardware installed on-premise. Your machine works only for you, and big filtration networks serve hundreds of clients — so they are by design capable of processing much larger amounts of data during mitigation.

You cannot say in advance before the attack what would be easier — to overwhelm a single hardware CPE or a filtration network node. However, think of this — node denial of service is a provider’s problem, but a piece of equipment shutting down is an issue you have to deal with.

3. Server node acting as a proxy must be able to reach the targeted service to retrieve content and supply data. Does this mean that anyone could bypass the cloud mitigation?

If there is no dedicated physical channel between you and the mitigation provider — yes.

However, going into details makes this answer a bit tricky. It is true that without a direct connection to the mitigation provider from the client malefactors could always find the native IP-address of the service and attack it. Not all DDoS-mitigation providers even have an option of a dedicated channel from mitigation network to the client’s one.

In general, switching to the cloud mitigation means shifting the BGP announces. In this case, the separate IP-addresses of the attacked service could be no longer attractive for the attackers, since they are hidden behind the BGP advertised route.

4. Sometimes the price/expense ratio is used as an argument against cloud mitigation providers. How does it look like in a case of a cloud versus on-premise hardware?

It could be said that no matter how small is an attack cloud DDoS mitigation operator would always process them, even though the internal costs are built around an assumption of intense and powerful, maximum-width and periodic attacks. On the other hand, this does not mean that the mitigation provider is losing money helping clients mitigate small and minor assaults. Yes, he could work slightly more than it is supposed to, but with a mitigated attack no one would notice, and both mitigation provider and its client would be entirely happy to continue such partnership.

Consider the same situation with an on-premise hardware — it costs much, it requires qualified workforce, and still, it would deal with the same smaller or rare attacks. When you were buying this expensive equipment, have you thought of that?

It is a strong thesis that a piece of hardware, along with a contract for technical support, installation, and engineers capable of managing such a piece of equipment, in the end, could cost less than using a suitable tariff basing on your needs and paying exactly for that, ignoring the maximum value. Which, based on experience, would be enormously high and this is the main reason why DDoS-mitigation is a separate business, not a technical unit in every IT-company out there in the world.

Because an attack is a rare event, the solution should be designed in a proper way to mitigate those rare attacks, but also cost reasonable money because most of the time it would be idle. Cloud mitigation providers design and build their networks in an efficient manner to consolidate its risks at one place and deal with them by actually distributing traffic among filtration nodes, which are hardware and software systems, designed especially for this purpose.

It is, actually, the law of large numbers which we know from the probability theory. ISPs sell wider channel capacity than they have. All clients of an insurance company theoretically could, but on practice would never have an accident the same day, and though compensations could be huge those insurance businesses do not fail every day someone crashes or loses a house.

People that are aware of the DDoS attacks landscape know, that the cheapest and therefore most frequent attacks are amplification based, which could not be identified as “small.”

While it is true that you pay a one-time price for the on-premise solution and stay with it — attacks change and continuously evolve over time. Where’s the guarantee that a yesterday equipment could mitigate a next day attack? It is pretty much hypothetical. So the rather significant investment made into such a piece of equipment could lose its value over time, and it would need constant updates.

In mitigating DDoS attacks, it is important to have a scalable solution and overall connectivity of the mitigating network. It is hardly achievable on-premise.

When the attack is aimed at saturation of the internet circuit the hardware equipment is designed to signal the cloud and divert traffic to scrubbing facilities, but no one says that when the channel is choking and suffocating under attack, there is no guarantee that it could make such diversion. Moreover, again, it takes time and effort to switch the data flow.

The only price that really could be paid for the safety of the resource from DDoS attacks is the latency — nothing except that. However, we mentioned earlier, that often we observe an advance in overall latency of the requested service.

Consider this when thinking of purchasing a piece of hardware versus connecting to mitigation cloud.