Traffic Steering with 3rd party Policy Manager (Layered Architecture with Explicit Proxy)

PKI · ‎01-Jun-2021

Introduction

A previous advanced use case described the use of Internal Layered Architecture for reducing complexity (ref: https://devcentral.f5.com/s/articles/SSL-Orchestrator-Advanced-Use-Cases-Reducing-Complexity-with-Internal-Layered-Architecture)

Some organizations standardize their policies and/or operational procedures based on a platform/tool, to manage security and access policies for outbound access. One interesting design that is gaining popularity is leveraging a 3rd party tool, via sideband API calls, to obtain a traffic steering/management decision. Organizations with deep investments in a specific tool/technology for policy management, cannot transition to a net-new solution without significant friction. If this tool/system has a REST API interface or a way to create a service to respond to HTTP queries, the BIG-IP can initiate a sideband API call, requesting such a decision via an HTTP request, and leverage that decision in the SSL Orchestrator flow. Here’s what that looks like:

w

Here’s a quick rundown of the flow by step numbers:

Client attempts to browse to www.xyz.com. Client points to the Explicit Proxy VIP address (usually achieved by PAC file entry), which is the first of the multi-layered SSL Orchestrator architecture.
The BIG-IP holds the client request, extracts headers(eg: username, source IP, Dest URL) from the HTTP Connect, and initiates a sideband API call to the 3rd Party policy manager (can be anything), including the required headers that the policy manager needs to provide a decision.
Policy manager replies with a custom value, usually a custom HTTP header, that provides a decision/action that SSL Orchestrator can use to make a traffic steering/management decision. Example, if the decision header is named “X_Decrypt_Decision”:
X_Decrypt_Decision == Intercept - Send to Intercept topology
X_Decrypt_Decision == Bypass - Send to Bypass topology
X_Decrypt_Decision == Block - Send to Block Topology
Based on the policy decision, SSLo steers the traffic to the appropriate topology via VIP targeting (example iRule below)
Depending on which topology was targeted, traffic passes through the respective service chain for typical security inspection steps
Finally, once the service chain has been traversed, BIG-IP sends the traffic out the egress path as defined (can be a single egress path, or topology-specific paths)

This method can provide significant flexibility, there are some minor drawbacks/trade-offs, that should be considered. A few have been listed here:

Pros:

1) Flexibility to define/manage policies on a 3rd party policy manager/engine

2) Ability to create conditional logic with multiple decisions from policy manager, before a bypass/intercept/allow decision is made

3) Limit or remove need for URL database management and update on BIG-IP devices

Cons:

1) Additional latency when performing sideband calls to 3rd party tool

2) Dependency on 3rd party tool for a traffic steering decision

3) Multiple logging sources, resulting in some troubleshooting complexity

We’ll walk through the steps of configuring this behavior, using a McAfee Web Gateway as our policy manager. The same principle applies to other products (eg: Broadcom ProxySG). Here, we use an Explicit Forward proxy VIP, that is a manually created VIP (i.e. not created by an SSL Orchestrator topology), to perform additional functions at the traffic steering point. A manually created virtual server allows us to insert the conditional sideband calls and traffic steering decision, early into the traffic flow, as the traffic would be too far down the road, if it already made it to the Service Chain. While the configuration here uses an Explicit forward proxy, it doesn’t have to be so, and can be a transparent proxy as well.

Let’s start with the MWG:

McAfee Web Gateway API Configuration

LTM explicit proxy VIP trigger and iRule that generates an API call to McAfee Web Gateway GTI interface on client request and MWG returns policy actions (intercept/bypass/block). MWG thus maintains sole control of policy engine (single source of truth) – no need for URLDB subscription on SSL Orchestrator.

Initially this requires configuration on the MWG to support this mechanism, and the following presents basic settings to enable this. In this case, the MWG will be configured to listen on an alternate (proxy) port, and a corresponding blocking policy will respond directly to HTTP headers sent to it.

Proxy

In the MWG UI, under the Configuration section -> Appliance -> Proxies, configure a new HTTP Proxy listener on a new port (ex. 2082). A policy will listen on this port and respond to API calls.

Policy

In the MWG UI, under the Policy section, create a new Rule Set.

Enable: checked
Applies to: check all
Apply this rule set: if the following criteria is matched:
Proxy.Port equals 2082

The MWG policy should look something like this:

Rules

Get URL and CLIENTIP from Parameter

## This rule extracts a URL from a “url” query string and client IP from a “clientip” query string, and stores in “URL” and “CLIENTIP” variables respectively

Rule Criteria: URL.HasParameter(“url”) equals true
Action: Continue
Events: Set URL = URL.GetParameter(“url”)
Rule Criteria: URL.HasParameter(“clientip”) equals true
Action: Continue
Events: Set clientip = URL.GetParameter(“clientip”)
Action: Continue