SSL Orchestrator Advanced Use Cases: Office 365 URL Management

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: Office 365 URL Management 

If you're reading this article, it's a good bet that your organization relies on Office 365 for your Office productivity, email, and/or collaboration tools. It's also a good bet that you're concerned about encrypted malware, and thus how to deal with malware that sneaks its way into Office 365. Given the shear number of products available to address it, it shouldn't take much to convince you there's a potential threat there. Of course, the service itself is not inherently insecure. But within Office 365, you create, manage and share documents, and send and receive emails with attachments. The issue is that the documents and attachments themselves are malware vectors, and email phishing attacks are hard to catch. Moreover, as the bulk of that traffic is all encrypted, you're faced with a dilemma. Do you rely solely on Microsoft's security to protect your organization, or endpoint security tools? Hopefully your answer is a resounding 'no' to both of these, and that you do indeed decrypt and inspect in active defense against malware and data exfiltration. But therein lies another problem. What and when do you decrypt? What about Office 365 components that don't play well with decryption tools, or where Microsoft recommends to bypass decryption for the sake of performance? At a most recent count, Office 365 encompasses around 350 unique resource URLs, and roughly 160 IPv4 and IPv6 addresses. These URLs represent the different Office 365 services, and are dynamic (i.e. frequently changing). So then I will ask again. What and when do you decrypt and inspect Office 365 traffic based on the revelation that not all Office 365 URLs should be managed the same way, and they're ever-changing. 

If at this point you're still not completely clear on the complexity of this scenario, that's okay. I'll refer you to a few Microsoft resources that go into great detail on the subject:

• https://techcommunity.microsoft.com/t5/office-365-blog/announcing-office-365-endpoint-categories-and-office-365-ip/ba-p/177638
• https://techcommunity.microsoft.com/t5/office-365-blog/getting-the-best-connectivity-and-performance-in-office-365/ba-p/124694
• https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Microsoft also now tags URLs with an internal category system, as defined here:

• https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#new-office-365-endpoint-categories

Those categories are:

• Optimized URLs - endpoints required for connectivity to every Office 365 service, and the most sensitive to network performance, latency and availability.
• Allow URLs - endpoints required for specific Office 365 services, but not as sensitive to latency as the Optimized URLs.
• Default - endpoints that represent Office 365 services that do not require optimization.

Fortunately, F5's SSL Orchestrator can provide an elegant solution to this complex problem. Intelligent traffic classification allows you to define rules that can be used to control availability (allow or block), decryption (intercept or bypass), and steering through dynamic sets of security devices (service chaining). Bypassing TLS decryption on an Office 365 resource can be as simple as a single rule that matches on all Office 365 URLs. Or, you can decrypt some and bypass others, as Microsoft recommends. And you can choose to pass traffic through the service chain of security devices irrespective of decryption. 

Managing Office 365 URLs

To make all of this work, you first need the Office 365 data source. As previously illustrated, Office 365 URLs and IP addresses are dynamic, updating roughly every 30 days. This feed isn't built into the BIG-IP, but there's an easy way to add it with a simple Python script:

https://github.com/f5devcentral/sslo-o365-update

Basically, a Python script is configured to run periodically on your BIG-IP to keep local custom URL categories and/or data groups in sync with the Office 365 URL source. These collections can then be consumed natively by the SSL Orchestrator security policy. You can then use these new URL categories as you would anything else in the security policy, like bypassing decryption for the set of "optimized" Office 365 URLs, or perhaps bypassing a proxy security device in an SSL Orchestrator decrypted service chain.

Figure 1: SSL Orchestrator security policy with O365 category rule

The Github repo has all of the instructions, but setup is pretty straightforward:

• Download the Python script - download on both devices in an HA pair:

curl -k https://raw.githubusercontent.com/f5devcentral/sslo-o365-update/main/sslo_o365_update.py -o sslo_o365_update.py

• Install the script with the --install flag, and provide an interval for the script to run:

python sslo_o365_update.py --install 3600

• When the installation is complete, edit your SSL Orchestrator security policy and add a traffic condition to match on one of the new Office 365 managed URL categories.

That's it. In a HA pair, the script runs independently on each unit. If you need to make adjustments to the configuration, jump on a BIG-IP console/SSH session and edit the json config data as described in the repo:

tmsh
edit sys file ifile o365_config.json

If you mess something up or just want to rebuild, run the script again manually with the --install flag (and time interval). You can configure the script to:

• Create all or some of the URL categories, for different customer endpoints and different service areas
• Create just data groups and/or just categories
• Manage just URLs and/or just IPs
• Include and exclude URLs and IPs.

** Note that you will also need to configure system DNS and a gateway route on the BIG-IP to access this remote Microsoft content. **

And there you have it. In just a few steps you've configured your SSL Orchestrator security policy to identify and take action on the dynamic set of Office 365 URL/IP resources, and along the way you have hopefully recognized some of the immense flexibility at your command.