ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

Introduction

There’s plenty of examples where “better together” is the right way to go. Where would M&Ms be if chocolatiers Forrest Mars Sr. and Bruce Murrie hadn’t shaken hands? They were better together. But also, cheese and crackers, peanut butter and jelly, rice and beans, are arguably better together. Okay, clearly, I need to go eat lunch after this… You could say the same thing for lots of non-food things, though. These days, with the immense volume of TLS traffic on the Internet, application layer security solutions don’t make a lot of sense without decryption, and decryption alone isn’t an adequate security solution by itself. They’re better together.

So, what does this have to do with F5 SSL Orchestrator? Well, as a rule, the primary purpose of the SSL Orchestrator is to provide real-time, dynamic layering of scalable security solutions to combat the wide variety of malware pouring into or out of the enterprise through encrypted protocols. SSL Orchestrator supports inbound and outbound traffic flows, and a diverse set of third-party security products. And this works extremely well under normal network conditions. However, SSL Orchestrator alone does not deal with volumetric attacks – those events that flood the network with bad traffic to create a denial-of-service. That is usually the job of a firewall, and/or a dedicated DDoS appliance, and F5 BIG-IP Advanced Firewall Manager (AFM) happens to be the sort of product that can protect against those volumetric bad-actor strikes. It also just so happens that AFM and SSL Orchestrator will happily run on the same appliance, where AFM protects your BIG-IP and even the backend infrastructure components within your security inspection zones from voluminous and otherwise bad network traffic, and SSL Orchestrator then decrypts and inspects the remaining good traffic. They’re better together.

SSL Orchestrator Use Case: Integrating AFM

In this article I’ll explore a few different ways to deploy and integrate AFM into an SSL Orchestrator architecture. Let’s go see what that looks like!

Licensing Requirements

The license requirements are pretty simple here. You need SSL Orchestrator and Advanced Firewall Manager licensed and provisioned on the BIG-IP. You can license SSL Orchestrator as the base product and add AFM, or license AFM as the based product and add SSL Orchestrator. Either works fine.

Configuring SSL Orchestrator

The beauty here is that not much additional work is required to integrate AFM and SSL Orchestrator. As you will see below, you may need to edit a virtual server, or nothing at all. Build your SSL Orchestrator topologies as you normally would. Please reference the SSL Orchestrator deployment guide for a deep-dive into all that’s possible: https://clouddocs.f5.com/sslo-deployment-guide/.

Configuring AFM

It probably goes without saying, F5’s Advanced Firewall Manager is a wildly powerful product, and this simple article couldn’t begin to do justice to all of its features and capabilities. For that, I would kindly suggest the following excellent AFM resources:

\n
• BIG-IP AFM: Network Firewall Policies and Implementations
\n
• BIG-IP AFM: DoS/DDoS Protection Implementations
\n
• AFM Operations Guide
\n

Keep in mind the goal of this scenario is to protect the BIG-IP itself. AFM is not taking the place of a traditional perimeter firewall in this case, but purely keeping the BIG-IP…and SSL Orchestrator out of harm’s way. In that sense, there are generally two ways you’d consider deploying AFM for this use case:

\n
• Per-application – where you would assert an AFM Network Firewall policy directly at the BIG-IP virtual server(s). In this case, that would be the SSL Orchestrator topology VIP. The benefit here is that you can have different network firewall policies for different applications and/or traffic paths.
\n

\n
• Globally – where you would assert an AFM Network Firewall policy in the global context. The benefit here is that one policy will protect all traffic flows, and no customization is needed at the virtual servers.
\n

Let us first see how to build a very simple AFM policy, and then attach that to each of the above contexts. In the BIG-IP UI, under Security -> Network Firewall -> Policies, click the Create button. Give that policy a name and click Finished. Now click the created policy to edit. Click the Add Rule button. Again, please reference the above resources for broader coverage of the AFM policy settings. At a bare minimum though, and just for testing,

\n
• Name: provide a unique name
\n
• Auto Generate UUID: click to enable (if desired)
\n
• State: Enabled
\n
• Protocol: Any
\n
• Source: type in your local client IP address or IP subnet
\n
• Destination: Any
\n
• Actions: Reject/Drop
\n
• Logging: Optionally enable
\n

All other settings can be left blank. As you can see, this is a highly contrived example to simply demonstrate a policy that blocks all traffic from your IP address. Click the Commit Changes to System button to complete the policy. Now to actually use this policy, let’s explore the separate context options:

\n
• Per-application – Here you will assign this policy directly to an application virtual server. For SSL Orchestrator, that’s the topology VIP. If you’re on an SSL Orchestrator version 8.x and lower, you’ll need to disable strictness on the topology to make custom edits to the virtual servers. In that case I would strongly recommend the global context option. If running 9.0 and above, you can freely edit the topology objects. In the BIG-IP UI, under Local Traffic -> Virtual Servers, find and edit your SSL Orchestrator topology VIP. This will be a VIP with the “sslo_” prefix. On the top Security tab, go to Network Firewall and set Enforcement (or Staging) to Enabled. In the Policy drop-down, select your AFM network firewall policy. Update the VIP. At this point you can test and requests from your IP address should indeed get blocked.
\n

\n
• Global context – Instead of attaching the AFM policy to virtual servers, you can set it in a global context so that it applies to ALL traffic flowing through the BIG-IP. In the BIG-IP UI, under Security -> Network Firewall -> Active Rules, select Global from the Context drop-down. Now click on the Global link below to edit. Go to Network Firewall and set Enforcement (or Staging) to Enable. In the Policy drop-down, select you AFM network firewall policy, then update. At this point you can test and requests from your IP address should indeed get blocked. If you have multiple applications created, the policy will apply to all of these.
\n

Testing your AFM integration

We have already covered a contrived example of blocking by client IP address. There are course MANY different ways to define AFM policies:

\n
• You can filter by protocol
\n
• You can filter by source IP address, subnet, geolocation, and blacklist categories
\n
• You can filter by destination IP address, subnet, geolocation, and blacklist categories
\n
• You can insert iRule logic to extend validation and customize response and policy action behaviors
\n
• You can apply an additional service policy
\n
• You can apply an additional protocol inspection policy
\n
• You can apply an additional traffic classification policy
\n
• You can divert traffic to different virtual servers
\n
• You can apply schedules to your policies
\n
• And you can create sets of rules (Rule Lists) that are re-usable across multiple policies and contexts
\n

Sending to virtual servers

The third-to-last item above, diverting to different virtual servers, is an interesting concept I’d like to expand on. There’s a unique configuration pattern called the “Internal Layered Architecture” that can be used to create additional functionality and flexibility in an SSL Orchestrator deployment. The general idea is explained here: https://github.com/f5devcentral/sslo-script-tools/tree/main/internal-layered-architecture, but it is basically where a frontend virtual server steers traffic to internal SSL Orchestrator topologies based on its own external policy. That policy can derive from iRules and LTM policies, and can pull from data groups, URL categories, and pretty much anything else you can imagine to define a topology as a “function”. In any case, AFM enables this capability right out of the box, without iRules. Each rule in an AFM policy can “Send to Virtual”, where a topology VIP can be that destination. Simply put:

\n
• Create your SSL Orchestrator topologies as simple “functions” with a single “All Traffic” rule that does something (i.e., Allow/block, Intercept/Bypass, service chain), then assign a “dummy” VLAN to the topology. You’ll minimally create one topology for TLS intercept and one for TLS bypass, but then you can create additional topologies that do different things:\n
  \n
  • Different combinations of rule actions
  \n
  • Different service chains
  \n
  • Different SSL properties to allow for per-tenant certificate signing
  \n
  • Different egress paths
  \n
  \n
\n
• Create a client-facing virtual server and apply your AFM network policy. In that policy, define a set of rules, where each rule sends to a different topology VIP. Done. Traffic coming to the BIG-IP will hit the AFM VIP, match a policy rule, and internally steer to an SSL Orchestrator topology.
\n

Summary

In just a few short steps you should now be able to wield the full power of a world-class network firewall and do so with a fully integrated, better together F5 solution. Pretty cool, yes? I urge you to spend some time in the AFM Operations Guide and other AFM references to get a better understanding of the full set of its capabilities. And with that, I hope you can see some of the immense versatility and power of an integrated SSL Orchestrator and F5 IPS solution. Thanks!

Introduction

There’s plenty of examples where “better together” is the right way to go. Where would M&Ms be if chocolatiers Forrest Mars Sr. and Bruce Murrie hadn’t shaken hands? They were better together. But also, cheese and crackers, peanut butter and jelly, rice and beans, are arguably better together. Okay, clearly, I need to go eat lunch after this… You could say the same thing for lots of non-food things, though. These days, with the immense volume of TLS traffic on the Internet, application layer security solutions don’t make a lot of sense without decryption, and decryption alone isn’t an adequate security solution by itself. They’re better together.

So, what does this have to do with F5 SSL Orchestrator? Well, as a rule, the primary purpose of the SSL Orchestrator is to provide real-time, dynamic layering of scalable security solutions to combat the wide variety of malware pouring into or out of the enterprise through encrypted protocols. SSL Orchestrator supports inbound and outbound traffic flows, and a diverse set of third-party security products. And this works extremely well under normal network conditions. However, SSL Orchestrator alone does not deal with volumetric attacks – those events that flood the network with bad traffic to create a denial-of-service. That is usually the job of a firewall, and/or a dedicated DDoS appliance, and F5 BIG-IP Advanced Firewall Manager (AFM) happens to be the sort of product that can protect against those volumetric bad-actor strikes. It also just so happens that AFM and SSL Orchestrator will happily run on the same appliance, where AFM protects your BIG-IP and even the backend infrastructure components within your security inspection zones from voluminous and otherwise bad network traffic, and SSL Orchestrator then decrypts and inspects the remaining good traffic. They’re better together.

SSL Orchestrator Use Case: Integrating AFM

In this article I’ll explore a few different ways to deploy and integrate AFM into an SSL Orchestrator architecture. Let’s go see what that looks like!

Licensing Requirements

The license requirements are pretty simple here. You need SSL Orchestrator and Advanced Firewall Manager licensed and provisioned on the BIG-IP. You can license SSL Orchestrator as the base product and add AFM, or license AFM as the based product and add SSL Orchestrator. Either works fine.

Configuring SSL Orchestrator

The beauty here is that not much additional work is required to integrate AFM and SSL Orchestrator. As you will see below, you may need to edit a virtual server, or nothing at all. Build your SSL Orchestrator topologies as you normally would. Please reference the SSL Orchestrator deployment guide for a deep-dive into all that’s possible: https://clouddocs.f5.com/sslo-deployment-guide/.

Configuring AFM

It probably goes without saying, F5’s Advanced Firewall Manager is a wildly powerful product, and this simple article couldn’t begin to do justice to all of its features and capabilities. For that, I would kindly suggest the following excellent AFM resources:

\n
• BIG-IP AFM: Network Firewall Policies and Implementations
\n
• BIG-IP AFM: DoS/DDoS Protection Implementations
\n
• AFM Operations Guide
\n

Keep in mind the goal of this scenario is to protect the BIG-IP itself. AFM is not taking the place of a traditional perimeter firewall in this case, but purely keeping the BIG-IP…and SSL Orchestrator out of harm’s way. In that sense, there are generally two ways you’d consider deploying AFM for this use case:

\n
• Per-application – where you would assert an AFM Network Firewall policy directly at the BIG-IP virtual server(s). In this case, that would be the SSL Orchestrator topology VIP. The benefit here is that you can have different network firewall policies for different applications and/or traffic paths.
\n

\n
• Globally – where you would assert an AFM Network Firewall policy in the global context. The benefit here is that one policy will protect all traffic flows, and no customization is needed at the virtual servers.
\n

Let us first see how to build a very simple AFM policy, and then attach that to each of the above contexts. In the BIG-IP UI, under Security -> Network Firewall -> Policies, click the Create button. Give that policy a name and click Finished. Now click the created policy to edit. Click the Add Rule button. Again, please reference the above resources for broader coverage of the AFM policy settings. At a bare minimum though, and just for testing,

\n
• Name: provide a unique name
\n
• Auto Generate UUID: click to enable (if desired)
\n
• State: Enabled
\n
• Protocol: Any
\n
• Source: type in your local client IP address or IP subnet
\n
• Destination: Any
\n
• Actions: Reject/Drop
\n
• Logging: Optionally enable
\n

All other settings can be left blank. As you can see, this is a highly contrived example to simply demonstrate a policy that blocks all traffic from your IP address. Click the Commit Changes to System button to complete the policy. Now to actually use this policy, let’s explore the separate context options:

\n
• Per-application – Here you will assign this policy directly to an application virtual server. For SSL Orchestrator, that’s the topology VIP. If you’re on an SSL Orchestrator version 8.x and lower, you’ll need to disable strictness on the topology to make custom edits to the virtual servers. In that case I would strongly recommend the global context option. If running 9.0 and above, you can freely edit the topology objects. In the BIG-IP UI, under Local Traffic -> Virtual Servers, find and edit your SSL Orchestrator topology VIP. This will be a VIP with the “sslo_” prefix. On the top Security tab, go to Network Firewall and set Enforcement (or Staging) to Enabled. In the Policy drop-down, select your AFM network firewall policy. Update the VIP. At this point you can test and requests from your IP address should indeed get blocked.
\n

\n
• Global context – Instead of attaching the AFM policy to virtual servers, you can set it in a global context so that it applies to ALL traffic flowing through the BIG-IP. In the BIG-IP UI, under Security -> Network Firewall -> Active Rules, select Global from the Context drop-down. Now click on the Global link below to edit. Go to Network Firewall and set Enforcement (or Staging) to Enable. In the Policy drop-down, select you AFM network firewall policy, then update. At this point you can test and requests from your IP address should indeed get blocked. If you have multiple applications created, the policy will apply to all of these.
\n

Testing your AFM integration

We have already covered a contrived example of blocking by client IP address. There are course MANY different ways to define AFM policies:

\n
• You can filter by protocol
\n
• You can filter by source IP address, subnet, geolocation, and blacklist categories
\n
• You can filter by destination IP address, subnet, geolocation, and blacklist categories
\n
• You can insert iRule logic to extend validation and customize response and policy action behaviors
\n
• You can apply an additional service policy
\n
• You can apply an additional protocol inspection policy
\n
• You can apply an additional traffic classification policy
\n
• You can divert traffic to different virtual servers
\n
• You can apply schedules to your policies
\n
• And you can create sets of rules (Rule Lists) that are re-usable across multiple policies and contexts
\n

Sending to virtual servers

The third-to-last item above, diverting to different virtual servers, is an interesting concept I’d like to expand on. There’s a unique configuration pattern called the “Internal Layered Architecture” that can be used to create additional functionality and flexibility in an SSL Orchestrator deployment. The general idea is explained here: https://github.com/f5devcentral/sslo-script-tools/tree/main/internal-layered-architecture, but it is basically where a frontend virtual server steers traffic to internal SSL Orchestrator topologies based on its own external policy. That policy can derive from iRules and LTM policies, and can pull from data groups, URL categories, and pretty much anything else you can imagine to define a topology as a “function”. In any case, AFM enables this capability right out of the box, without iRules. Each rule in an AFM policy can “Send to Virtual”, where a topology VIP can be that destination. Simply put:

\n
• Create your SSL Orchestrator topologies as simple “functions” with a single “All Traffic” rule that does something (i.e., Allow/block, Intercept/Bypass, service chain), then assign a “dummy” VLAN to the topology. You’ll minimally create one topology for TLS intercept and one for TLS bypass, but then you can create additional topologies that do different things:\n
  \n
  • Different combinations of rule actions
  \n
  • Different service chains
  \n
  • Different SSL properties to allow for per-tenant certificate signing
  \n
  • Different egress paths
  \n
  \n
\n
• Create a client-facing virtual server and apply your AFM network policy. In that policy, define a set of rules, where each rule sends to a different topology VIP. Done. Traffic coming to the BIG-IP will hit the AFM VIP, match a policy rule, and internally steer to an SSL Orchestrator topology.
\n

Summary

In just a few short steps you should now be able to wield the full power of a world-class network firewall and do so with a fully integrated, better together F5 solution. Pretty cool, yes? I urge you to spend some time in the AFM Operations Guide and other AFM references to get a better understanding of the full set of its capabilities. And with that, I hope you can see some of the immense versatility and power of an integrated SSL Orchestrator and F5 IPS solution. Thanks!

SSL Orchestrator Advanced Use Cases: Integrating F5 Advanced Firewall Manager (AFM)