Introducing App Proxies for F5 Silverline

Introduction

When F5 Silverline was first introduced to the market back in 2014, the service was heavily focused on DDoS Mitigation through our globally dispersed Scrubbing centers. Traffic handling and customer configuration was very network focused and IP based.

However with well documentation limitations of available IPv4 address spaces, combined with the need for greater agility of our Layer 7 Application services a new Proxy configuration construct was needed to help scale the F5 Silverline cloud service to a new Regional POP (point of presence) based architecture.

Historically all Application level configuration through the Silverline service was provisioned through our Classic Proxy methodology, however this functionality had a variety of limitations, so is slowly being deprecated within the Portal.

These Classic Proxies, have now been replaced by two separate Proxy configuration objects. Any customers using the Silverline Portal today will see the following two Proxy types, the DDoS Proxy, and the Application Proxy.

The DDoS Proxies, support TCP, UDP and DNS based configuration elements, focused on cleaning and controlling traffic flow to a customer’s infrastructure. Details of what can and can’t be configured through these constructs will be discussed in a future article, but for now we will focus on the Application Proxies, or “App Proxy” for short.

What is on App Proxy?

An App Proxy is the friendly name we use for the logical configuration construct within the Silverline customer portal. Each Application or website a customer wishes to protect will typically have it’s own App Proxy configured via the portal, for the relevant configuration objects to be automatically deployed across the globe within the Silverline cloud service.

An App Proxy allows for a single configuration construct that includes objects for the Incoming expected URL’s for traffic to ingress in to the Silverline service, as well as the Back End configuration objects for your Application Origin Servers. The Construct also of course includes or the Security profiles that you wish to be applied by the Silverline service to protect and secure your application traffic from threats and attacks, before forwarding the good and clean traffic on to your App.

F5 Silverline Web Application Firewall service does act as a Full Proxy configuration, so the returning traffic from your App to the client will also traverse the Silverline cloud, and the response will also be inspected and checked for security purposes.

Why should you use them?

For all new customers subscribing to F5 Silverline today, will see the App Proxy construct as the most logical way to provision Application services to their protected Apps, but for existing customers currently configured with Classic Proxies may need guidance for why to migrate to the new Proxy type, so lets run through some of the reasons to opt for an App Proxy.

Firstly in order to leverage the new Regional POP’s (rPOP) for your Application Security, then the App Proxy construct is the only way to gain access to them. I’ll go into a little bit more detail as to why this is in the next section, but primarily this is to do with the way CNAMEs are issues to the App Proxy, in order to Globally Load Balance traffic to your Application from users based all across the globe.

The next reason to use them, is because they are very easy to use, and act as a single logical construct for all your Application security needs.

Within the App Proxy, you can apply a variety of security policies, such as, a Web Application Firewall (or WAF) policy, a Layer 7 DDoS Profile, a Shape powered Anti-Bot profile, a Threat Intelligence Profile, and the additional benefits of F5 iRule’s for increased security and functionality. The App Proxy construct also facilitates a single place to configured all your TLS & SSL needs for handling both Client-side and Server-side SSL certificates and ciphers.

In June 2020, we also introduced a new Service to the Silverline portfolio, with the introduction of F5 Silverline Shape Defense, this innovative new Service is designed to protect your web applications from automated bot attacks to prevent large-scale fraud, inflated operational costs, and friction for your end users.

The configuration of Silverline Shape Defense, is only supported through the new App Proxy construct, and provides a collective defense strategy to detect and block automate bot traffic. A great example of how effective the combination of the Silverline Service is to defend against automated attacks such as Credential Stuffing, can be found on our YouTube Real Attack Stories playlist HERE

How do they work?

If you're still not convinced by the advantages you can gain from our App Proxies, then maybe we should look at their configuration and functionality in a bit more detail.

First let’s look at some of the configuration options in the App Proxy:

Shown here is an example of the configuration for the Front End and Back End section of a new App Proxy in the Silverline Portal.

There are several items that need to be defined by the customer, including the display name for the App Proxy, which would typically be something logical and relating to the purpose of the App we are protecting.

The more important field in the Blue section, is the Fully Qualified Domain Name, which needs to be correct for the URL of the Application we are going to receive traffic for.

During the provisioning of the App Proxy, the Silverline Portal will automatically assign a CNAME in the f5silverline.com domain space, which will be used to redirect traffic to the Silverline service. (more on this shortly)

There are a couple of additional fields, for adding some descriptive notes, and also the ability for you to define custom Tags, as part of the Silverline Role Based Access Control (RBAC) configuration, which allow for granular access control to configuration objects and data analytics by user.

The Back End Section allows you to define either an IP Address, or a DNS name for the Back-end or Origin Server of your Application.

You can then select which of the Silverline Points of Presence you wish to deploy the configuration of the App Proxy too. You can choose to select them all, or just the ones in which you wish the Silverline Service to be able to Decrypt any HTTPS related traffic, which could help address any compliance or performance needs.

Now this is where things start to get interesting!

As well as the flexibility to select which POP’s you wish to deploy your App Proxy too, you also have the ability to configure Multiple different Back-ends.

Which means, that if you have your Application hosted in multiple different locations, you can configure each one individually as needed, and then select only the Silverline POP’s from the same regions as your own Datacenters, or Public Cloud hosted Apps.

We of course being F5 will handle all the Load Balancing and Global Server Load balancing as needed to ensure data is ingressed in to Silverline at the closet point to the users, and exits Silverline at the closest point , and with the optimum route to you back-end origin servers, regardless of how simple or complex the configuration becomes.

After setting up the Front and Back end configuration, you can then move to the HTTP or HTTPS Service tab to start to define your security policies and profiles.

If you have the Silverline Add-on service for Threat Intelligence, you can create a policy to block different threatening sources based on dynamic IP reputation categories:

Most customers opt to block all the known bad IP address categories, but the flexibility is there for you to granularly control.

You can specify the Ports:

And the iRules you wish to apply to the App Proxy:

If your leveraging the F5 Silverline Web Application Firewall service, this would also be the section where you can apply your WAF policies and any L7 DDoS configuration as well, but as both of these elements can be quite complex, I will be dedicating a future article to each of these topics individually.

I’ll also be writing another article specifically relating to the F5 Silverline Shape Defense service, and the configuration options you would have in the Portal. Which would also be configured under the App Proxy construct, and even has it’s own full page of options.

There are some other configurable options in the Advanced tab, which vary based on the objects and settings you configure in the App Proxy. Which we don’t have time to cover today.

The one thing I did want to go in to more detail about however, is how traffic actually gets directed to your App Proxy, and the relevance of the CNAME I referenced earlier.

Handling GSLB to App Proxies

As a critical element to the Regional POP expansion and the App Proxy construct, we need to look in to a bit of detail about how DNS is used to direct traffic to the Silverline Service, in what we refer to as “Proxy Mode”. The Service can also use “Routed mode” the leverage BGP route advertisement to redirect all of your traffic through Silverline, but this is typically reserved for tour F5 Silverline DDoS Protection customers.

In Proxy Mode, we need to leverage DNS in order to get traffic destined for your Websites and Applications, to be redirected first to the F5 Silverline Cloud for processing.

So when you provision a new App Proxy in the Portal, you will be allocated a CNAME record that we specific bind to your App Proxy.

In your own DNS system, you will then need to modify the DNS response for your relevant Application from its original IP, to the CNAME of the Silverline App Proxy. While you’re doing this, you can also set the TTL to a longer time period such as an Hour or more.

The Silverline Service will automatically provision you a new GSLB record in our GSLB solution. We will set the TTL of this record to 30 seconds, to help with our dynamic autoscaling and orchestrated App Proxy deployment methodology.

Depending on the number of POP’s you selected for the App Proxy, we will add the different dynamic IP addresses of the different Regional POP’s to the GSLB system. For each rPOP,your App Proxy GSLB record will be populated with 3 separate IP Addresses, to span different availability zones.

As requests come in for different users in different regions’ around the globe, we will then issue the relevant IP address closest to the clients LDNS. Our primary Scrubbing centers, will typically leverage an IP Anycast address, which also gets added to the GSLB pool.

It’s a difficult thing to put in to a single image, but here is an example of the GSLB style system for our App Proxies:

This GSLB solution for App Proxies, provide a lot of benefits and flexibility for Global availability and the capability for us to dynamically scale the Silverline cloud platform as need demands.

Are there any recently introduced App Proxy features?

Also, in recent times, we have also just added support for “Multi-FQDN” support within a single App Proxy. This means, that as long as your Back-end Origin Servers can serve the content to each of the FQDN’s or URL’s of your application, then you can provision them all as a single App Proxy to save administrative overhead, and to simplify security and policy tuning.

Each individual FQDN, can be define in the App Proxy Front end screen, and assigned the relevant Client-side SSL Profile.

As shown in the example image below:

As you then move through the Security Tabs of the App Proxy configuration page in the portal, you will be able to define which L7 DDoS Profile and WAF policy to assign to each or all of the define FQDN’s.

Each defined FQDN, can then be handled by the same Silverline allocated CNAME DNS record, and handled by our GSLB solution.

What are the benefits of F5 Silverline App Proxies?

Hopefully you can now see what many of the benefits are for leveraging the new App Proxy construct within the F5 Silverline Portal for deploying you Layer 7 Security Services. They really are easy to use, and provide a single logical structure for all your Application Security needs. They have a great amount of flexibility and functionality to meet the changing needs of your applications. The use of CNAME records for traffic redirection through the Silverline Proxy mode, helps with dynamic scale and Global availability of your Apps.

What does the future hold for App Proxies?

For anyone familiar with F5 Silverline, you will know we operate a two week release cycle of Portal & Platform enhancements. All new Application delivery and Application Security features, will be built around the App Proxy construct. So if you want your Apps to benefit from the innovative new features in the roadmap for Silverline, now is the time to start to leverage the F5 Silverline App Proxy!