How to Eliminate Direct-to-Origin DDoS Attacks

Since releasing Imperva Incapsula IP Protection, we’ve seen our clients start to take advantage of the attack protection it affords. Infrastructure is now a significant target for DDoS attacks, so IP Protection should be an important tool in every security team’s tool box.

Our approach to protecting single IP addresses is unique, and at least for now, nobody has been able to solve the issue of direct-to-origin attacks like we have. So what makes our IP Protection solution unique? The answer lies in how we borrowed an idea from the attackers themselves. Now that we have filed patents, we can share some of it with you.

Before going into detail about how we solved the problem of protecting a single IP, a quick recap of the alternative solutions and why they are sub-optimal is in order:

• On-premises solutions are rapidly losing their advantage as attacks get larger, and bots get more human-like. It makes more sense to mount a community defense, in the cloud.
• Cloud-based solutions are better equipped to handle the changing attack environment, but required that you protect an entire Class C network—even if you wanted to protect just a handful of IP addresses. IP Protection changes that.
• ISP clean pipe solutions lack capacity to handle just average size attacks, especially when it comes to packet-based attacks. Security isn’t always a core capability of an ISP and they often don’t have the security expertise of a dedicated DDoS mitigation provider.
• Proxy-based solutions completely hide the client IP which breaks many applications and completely bypasses the firewall.
• Hybrid solutions are transient, only kicking in when a sustained attack occurs. We’ve heard from clients who’ve used hybrid solutions that they can malfunction during burst attacks, failing to switch over to the cloud when the pipes get congested.

Innovation Kicks In…

When we originally introduced our Infrastructure Protection service back in 2014 we had two key advantages:

• Unlike most providers, we develop our own technology, which gives us a lot of room to innovate.
• We launched infrastructure protection services across our entire content delivery network of 30 PoPs. Other providers use just a few scrubbing centers globally. Our bigger network allows us to serve our clients with minimum latency across the globe, even in an always-on mode.

Soon after launching our infrastructure protection solution we identified a gap in the market, where organizations can’t find a proper solution to protect single IP addresses in an always-on mode. We also started seeing a growing demand for this capability as more organizations started moving assets to public clouds and could no longer use their BGP-based solutions.

To solve the single IP protection problem, we decided to use a solution similar to our Infrastructure Protection. With single-address IP Protection we would use our own IP ranges and “lease” our IP addresses to our clients. Clean traffic would then be routed back to their origin over a GRE tunnel, exactly as we do for our Infrastructure Protection service. This way the packets remain untouched and the source IPs are available for firewalls and back end applications.

We were still left with one big problem: How do we connect clients to our data centers in an always-on mode, in a way that will be both secure, with low-latency and very easy to deploy?

The option of using just a subset of our PoPs for an always-on service was ruled out. For IP Protection, we felt it was extremely importantly to have as much redundancy and distribution (to eliminate latency) as possible. On the other hand, setting up GRE tunnels in front of each of our 30 PoPs in our ever growing network just didn’t make sense.

Why Not Just Use Virtual GRE Tunnels?

We came up with this idea while looking at spoofed IP addresses during a DDoS attack. We immediately realized that we could use the attackers’ methods to build a good solution without compromising on anything.

The solution we came up with, now patent pending, works the following way:

• A virtual GRE tunnel: When the client configures the service they establish just a single GRE tunnel in front of our network. This is actually a virtual tunnel, as it’s shared between all of our PoPs.
• Ingress traffic: Flows through any of our PoPs and on to our clients using spoofed GRE source IPs, where all PoPs use the same source IP address to send the packets (Figure 1).

• Egress traffic: Traffic sent by our clients’ equipment back to our PoPs is Anycasted from all of our PoPs, so that the closest PoP to our client receives this traffic and sends it over to our clients end users (Figure 2).

• If a PoP is unable handle traffic for any reason then the next closest PoP takes the traffic. Since all PoPs are continuously synchronized, the switch to another PoP is a smooth process with no effect on our client or their users (Figure 3).

We immediately knew that this was a killer solution – it’s on the IP level, it completely covers the client’s infrastructure, hides the origin IP address, provides always-on protection and is easy to deploy – just what everyone was looking for.

And indeed, our customers are finding this solution to be an exact fit to their needs. We now have customers in all sizes, including some of the largest enterprises and a few of the most latency-sensitive platforms on our IP Protection service.

Moreover, being the only appropriate solution to protect public cloud infrastructure, we are getting more and more requests from organizations that have moved their infrastructure to public clouds (AWS/Azure/Google). These organizations have lost their BGP-based DDoS protection capabilities and have turned to us to protect their infrastructure on public clouds.

In one of our next blogs we will share the story of one of those customers who had a very complex setup on a few different public clouds and also in their own data center and how we managed to protect their infrastructure using IP Protection.