Introduction
F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases.
If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility.
SSL Orchestrator Use Case: Local DNS Proxy Cache
A basic tenet of an explicit proxy is DNS resolution. That is, the proxy functions to perform DNS requests on the client's behalf. This is a useful security characteristic as it abstracts DNS away from the client and generally prevents IP spoofing. For example, a client cannot spoof the IP of a known-bypassed host because an explicit proxy client does not control the IP address. The client passes a URL to the proxy, and the proxy resolves the URL to the correct address. Needless to say, however, if you have a thousand hosts perform 100 DNS requests per hour (each) in an environment, and you shift that to an explicit proxy, you now have a proxy server that's performing potentially 100,000 DNS requests per hour. Now fortunately, a large portion of the traffic from each of these clients will be going to the same places (ex. google.com), so the proxy server can locally cache a lot of these. But at some point, a dedicated DNS proxy cache can be useful to offload this burden, and in a configurable way.
In an SSL Orchestrator environment, you may also have an explicit proxy security device plugged into a decrypted service chain, and that explicit proxy will also need DNS resolution. So if you've configured an SSL Orchestrator explicit proxy topology, and sending decrypted traffic to an explicit proxy in a service chain, you now have two devices that need DNS. As you've probably guessed by now, there's an elegant solution to this problem. Using a DNS cache profile on the BIG-IP, you can point the topology explicit proxy resolver, and the inline service resolver at the same cache. As traffic arrives at the topology, an initial DNS request flows to the DNS cache. If an answer doesn't exist, the request is forwarded to a defined authority and the answer cached. When the decrypted traffic arrives at the inline service, it attempts a DNS request to the same place and gets an immediate response from the cache. This has additional benefits in both optimizing traffic flow through the inline proxy device, as it doesn't have to wait for a DNS response from an external source, and also removes the need for this inline obfuscated security device to have to communicate outside of its secure enclave (for DNS). It may still have to communicate beyond the enclave for software, signature and licensing updates, but those are not real-time traffic concerns. This article provides a simple set of steps to build a local DNS proxy cache for SSL Orchestrator.
[figure 1: SSL Orchestrator with DNS proxy cache]
** Note that a DNS proxy cache requires the DNS license, which also requires SSL Orchestrator to be licensed as an add-on to base LTM. **
Configuration
Configuring a local DNS proxy cache involves creating the DNS cache and virtual server to hold it. This virtual server basically load balances external DNS and enables optimization through caching. You will point both the SSL Orchestrator resolver and the inline proxy DNS at this virtual server to take full benefit of the optimization. Also note that this could simply be used by an inline proxy service, in the absence of an explicit proxy SSL Orchestrator topology. This allows you to both optimize DNS for the inline proxy, and also not have to build a service control channel for inline proxy DNS to get out to an external DNS resource.
- Create DNS cache - Located under DNS -> Caches -> Cache List, click the Create button.
- Resolver Type: Transparent (None)
- Create DNS profile - Located under Local Traffic -> Profiles -> Services -> DNS, click the Create button.
- DNS Cache: Enabled
- DNS Cache Name: <above DNS cache>
- Create DNS proxy pool - This is the actual DNS resource (ex. 8.8.8.8:53). Find this under Local Traffic -> Pools.
- Create DNS proxy VIP (on XP service's outbound subnet) - This is the virtual server that load balances the DNS resource. Find this under Local Traffic Virtual Servers. It is important to create the inline proxy service first as that will establish the VLAN and IP subnet that this virtual server will attach to.
- Type: Standard
- Source Address: 0.0.0.0/0
- Destination Address/Mask: select a unique IP address on the inline proxy service's outbound (from-service) subnet (ex. 198.19.96.153)
- Service Port: 53
- Protocol: UDP
- Protocol Profile (Client): udp
- DNS Profile: select the previously-created DNS profile
- VLAN: select the inline proxy service's outbound (from-service) VLAN
- Source Address Translation: SNAT as required for routing
- Address Translation: enabled
- Port Translation: enabled
- Default Pool: select the DNS server pool
- Configure the SSL Orchestrator resolver to point to DNS proxy VIP - Navigate to the SSL Orchestrator UI and in the top right corner click on the gear icon to access the DNS resolver configuration. Enter this same virtual server IP address.
- Configure the inline explicit proxy service to point to the DNS proxy VIP - DNS requests will leave the inline proxy service on the service's from-service VLAN to the DNS proxy VIP.
- Optionally create a system route if the DNS pool requires a gateway route - If you need a route to get to the actual DNS resource, create a system route. This is found under Network -> Routes.
To test, initiate a tcpdump capture on your outbound VLAN and look for port 53 traffic. Assuming an explicit proxy SSL Orchestrator topology, you should see a single outbound DNS request. The DNS request from the inline proxy device will be served directly from the newly cached data.
tcpdump -lnni [outbound-vlan] port 53
And there you have it. In just a few steps you've configured your SSL Orchestrator security policy to take advantage of a local DNS proxy cache, and along the way you have hopefully recognized the immense flexibility at your command.