DDoS Protection for Networks: Utilizing AS Prepending to Route Traffic Through Imperva

In order for Imperva to protect customers’ traffic using DDoS Protection for Networks, the Internet must select Imperva as the best path. So what does this mean? Does Imperva automatically take over the customer’s prefix and control the routing of the Internet? Well…not exactly.

Internet Routing

Let’s take some time to first understand Internet routing. At a very high level, the internet is made up of distinct networks called autonomous systems (AS), which communicate with each other by utilizing the Border Gateway Protocol (BGP). For example, Company A could purchase a circuit with ISP1 and Imperva purchase a circuit with ISP2, and even though Imperva does not have a direct connection with the ISP, we can communicate with the customer using BGP protocol.

The Concept of ‘Best Path’

This concept is quite simple when we have only 2 ISPs; however, the Internet has many ISPs and many autonomous systems. Hence, we have to introduce the concept of the best path for BGP. In order to understand this concept, we have to understand the BGP tie breaker on determining the best path. We are not going to talk about the full best path algorithm, as we will focus on the three common cases that we usually see and for which we provide suggestions to customers on how to route their traffic to Imperva. For additional information about the full best path algorithm, you can refer to router vendor documentation, i.e. here.

Three common ways to determine the most preferred path are as follows:

• Highest Local Pref
• Aggregate vs. specific route (most specific address)
• Shortest AS path

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

Shortest AS Path

We can look at the idea for the shortest AS path first, as that is usually the most common way to route traffic, and leave Local Pref and a more specific range concept for a later post. Let’s assume there are no Local Pref and only a single prefix is being sent in this example. As shown in the diagram below, we can see if the customer advertises a prefix to their ISP, the shortest path is going through AS701 AS3356 to Imperva.

**Please note all examples are lab environment only and not actual configuration by respected ASN.

And what if the customer has 2 ISPs and they don’t really want to use ISP1 as their primary path for this prefix? Would there be a way to advertise out to ISP3 instead? This often happens if customers have primary and secondary data centers or even active/backup links due to the cost of the circuits.

One of the common ways to do this is via AS prepending, where they will put “fake” additional AS in the path to make it less attractive to ISP1. Due to the BGP shortest path algorithm, ISP3 will have less AS in the path than ISP1.

If we go to ISP1 looking glass or routing table, we should see it’s getting routed from the customer and it should look something like:

Notice that the red arrow is the path that is being prepended and it’s not the best path. The best path is shown in blue where it will go through via ISP3 (AS2914).
If we go to the Imperva router and take a look at the path, we can see that it’s coming from AS3356, AS2914 – exactly what we expected.

Onboarding DDoS Protection for Networks

Now that we understand how AS prepending can help adjust the best path of the Internet, let’s use this concept and apply it to the Imperva implementation methodology of onboarding a DDoS Protection for Networks customer.

Imperva would create a BGP connection using one of the three options: GRE, Direct Connect or ECX. Customers should provide WAN interface IP (the customer’s IP address with their upstream ISP) for GRE tunnels, then private IP will be provided by Imperva to create BGP connections for all connection types. Imperva could also provide Public IP to establish BGP sessions upon request.

The customer would continue to advertise to their ISP with prepend and advertise the prefix range that they want to get protected by Imperva. Since the route going to Imperva would be the shorter route, as BGP is running through the GRE tunnel, the Internet will decide that Imperva is the best path.

In some cases, the ISP will have a local preference towards customers and prepend routes might not work. This will be discussed in a later article where we might suggest to the customer to remove the advertisement towards their ISP.

Router Configuration

Below is an example of how a customer should configure their router. We recommend that they check with their vendor and internal networking team as each company has different implementations. The below is for a general frame of reference. Note that ISP prepend is not included in the below example:

set interfaces gr-1/0/0 description GRE_TO_IMPERVA
set interfaces gr-1/0/0 unit 0 tunnel source ISP_LINK
set interfaces gr-1/0/0 unit 0 tunnel destination IMPERVA_PUBLIC_IP
set interfaces gr-1/0/0 unit 0 family inet address x.x.x.x/30 (private peer ip)

set policy-options prefix-list IMPERVA_OUT x.x.x.0/24
set policy-options community NO_EXPORT members no-export

set policy-options policy-statement IMPERVA_ROUTES_ADVERTISEMENT term *NAME* from prefix-list IMPERVA_OUT
set policy-options policy-statement IMPERVA_ROUTES_ADVERTISEMENT term *NAME* then community add NO_EXPORT (or other communities)
set policy-options policy-statement IMPERVA_ROUTES_ADVERTISEMENT term *NAME* then accept
set policy-options policy-statement IMPERVA_ROUTES_ADVERTISEMENT term ELSE then reject

set policy-options policy-statement DENY_INCAPSULA_ROUTES term ALL then reject

set protocols bgp group IMPERVA type external
set protocols bgp group IMPERVA import DENY_INCAPSULA_ROUTES (deny all announcements from Imperva)
set protocols bgp group IMPERVA export IMPERVA_ROUTES_ADVERTISEMENT (send relevant prefixes and communities to Imperva)
set protocols bgp group IMPERVA local address x.x.x.x (same as GRE tunnel ip address)
set protocols bgp group IMPERVA neighbor x.x.x.x peer-as 19551
set protocols bgp group IMPERVA remove-private

AS prepending is one of the first recommendations we suggest to customers to encourage traffic from the Internet to route through Imperva. However, sometimes doing AS prepend isn’t enough and when that happens, customers are at risk of being attacked since Imperva cannot scrub the traffic (also known as route leak). In an upcoming article, we will talk about other techniques that customers could use to route traffic through Imperva so they are best protected.