cancel
Showing results for 
Search instead for 
Did you mean: 
Kevin_Stewart
F5 Employee
F5 Employee

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: DNS-over-HTTPS Detection

Despite the rapid evolution of Internet standards, and increasing amount of encryption, there's one aspect of our daily online world that hasn't really changed that much in its nearly 4 decades of breath. That of course is DNS. We don't tend to think about it often, which is probably why it hasn't evolved as much as other things, but it truly is the heart and backbone of everything we do online. That is, unless you want to memorize "2607:f8b0:400a:0804:0000:0000:0000:2004" as the way to get to Google, you had better have a working DNS. But DNS is inherently insecure. It's been shown to be vulnerable to all manner of attacks, and for the purposes of this discussion specifically, also exposes where you're going. That is, while the HTTP payload may be encrypted, there's still that (visible) DNS request that goes out first. That's not to say that there haven't been any improvements though. DNSSEC was developed to help secure DNS and prevent spoofing, but in the many years since its introduction it still isn't as widespread as we'd have hoped. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) are more recent developments that focus mainly on the privacy aspect of DNS communications (or lack thereof). With DoH and DoT, clients and servers forego the typical DNS protocol request over UDP or TCP port 53 and embed the request inside an encrypted HTTPS or pure TLS connection.


But...while that sounds pretty cool, there are some pretty serious implications to encrypted DNS. The US National Security Agency (NSA) actually published a warning on this:


https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.P...


The basic idea is that while *your* DNS privacy is a good thing, encrypted DoH and DoT can also mask malware command-and-control. Plus all of the current DoH providers are external resources (like Cloudflare), so organizations have very little control over DoH communications, including DNS monitoring, protection systems, and allowing these third parties to see what your users are doing. 


If you follow the NSA guidance, you should either block DoH altogether, or force users to only use a local enterprise DoH resolver. If you don't have access to an enterprise DoH resolver though, what else could you do? Well, I'm so glad you asked. DoH is of course encrypted, so unless you disable DoH at the clients, set up a DoH resolver, or attempt to do encrypted analysis to find DoH traffic, you need to decrypt and inspect. And as it turns out, F5 has an elegant solution to do just that. In this blog post I am going to present a solution to perform DoH detection through SSL Orchestrator decrypted analysis. Once you've decrypted HTTPS and detected that it's DoH, there are a number of things you can do:


  • Simply detect and block: there are actually three forms of DoH requests, Wireformat GET/POST, and JSON (detailed here: https://developers.cloudflare.com/1.1.1.1/dns-over-https), though the vast majority of clients use the Wireformat POST method. In any case, this option follows the NSA's first recommendation to simply detect and block DoH requests. A DoH-capable browser that receives a reject on DoH request will natively revert to DNS.


  • Detect and log: you may simply want to log that DoH is happening, who's asking and what they're asking for, as an extension to your current DNS monitoring protocols.


  • Detect and blackhole: also as a possible extension to your current DNS protection protocols, you may need to block some DoH requests from happening. As with any DoH/DoT request, if you simply block it the client will revert to DNS. So the best way to prevent a valid response to DoH/DNS request is to provide an invalid response instead, a technique called "blackholing". In this approach, you can flag specific hostnames (matching on URL categories) to provide a blackhole response.


The first option above is actually super easy. You just need to add the iRule to your SSL Orchestrator outbound topology (any topology that consumes routed TCP traffic). On any decrypted HTTPS traffic it examines the HTTP request methods for the three signature DoH methods and sends a reject on a match. Easy Peasy.


when HTTP_REQUEST priority 750 {
  if { ( [HTTP::method] equals "GET" and [HTTP::header exists "accept"] and [HTTP::header "accept"] equals "application/dns-json" ) or \
     ( [HTTP::method] equals "GET" and [HTTP::header exists "accept"] and [HTTP::header "accept"] equals "application/dns-message" ) or \
     ( [HTTP::method] equals "POST" and [HTTP::header exists "content-type"] and [HTTP::header "content-type"] equals "application/dns-message" ) } {     
     reject
  }
}


The second two options above are available in a single iRule here: https://github.com/f5devcentral/sslo-script-tools/tree/main/sslo-dns-over-https-detection


As with the previous, add the iRule to the box, then associate that iRule with an SSL Orchestrator (routed) outbound topology. You'll need to make a few adjustments in the iRule to configure for your environment, and those are all presented as simple static variable assignments:


  • static::LOCAL_LOG: enable or disable local Syslog logging.


  • static::HSL: enable or disable remote high-speed logging (HSL).


  • static::URLDB_LICENSED: set to 1 (on) if you've licensed and provisioned the subscription-based URLDB, or 0 (off) if you have not and want to just use custom URL categories for DoH blackholing.


  • static::BLACKHOLE_URLS: leave empty to disable, or add a list of URL categories to search for URL-based DoH blackholing.


  • static::BLACKHOLE_RTYPE_A: enable or disable blackholing matched A record requests.


  • static::BLACKHOLE_RTYPE_AAAA: enable or disable blackholing matched AAAA record requests.


  • static::BLACKHOLE_RTYPE_TXT: enable or disable blackholing matched TXT record requests.


And there you have it. In just a few steps you've configured your SSL Orchestrator to detect and manage DNS-over-HTTPS traffic through your environment, and along the way you have hopefully recognized the immense flexibility at your command.



Comments
Kevin_Stewart
F5 Employee
F5 Employee

SSL Orchestrator Advanced Use Cases: DNS-over-HTTPS Detection

Version history
Last update:
‎08-Feb-2021 08:13
Updated by:
Contributors