4.3. Managing Security Policies

4.3.1. What it is

SSL Orchestrator security policies are the engine that drives traffic flow analysis and dynamic service chaining. All of the magic happens right here. With a security policy ruleset, you can define a wide array of traffic matching rules and their corresponding actions:

  • Allow or block


  • Intercept (decrypt) or bypass (dont decrypt)


  • Send to a service chain

../_images/image59.png

Figure 59: SSL Orchestrator Security Policy


The security policy itself is a front-end to an access per-request engine that converts the rules into visual elements in this policy. Also note that the order of rules affects the order of events in the visual policy. Rules are read top-to-bottom and converted into corresponding visual agents nesting from left to right.

../_images/image60.png

Figure 60: SSL Orchestrator Security Policy VPE


While security policy rules work well for most traffic processing scenarios, it may be necessary to go beyond their capabilities and manipulate the visual per-request policy directly.

Keep in mind, however, that the rules engine converts rules to visual elements in one direction only. It cannot convert visual elements back to rules. Therefore, once the visual per-request policy has been manipulated, the Guided Configuration security policies user interface will no longer be available.

4.3.2. How to build it

The easiest way to get started with SSL Orchestrator security policies is to first understand your goals. For example:

  • Do you need to block any type of traffic, and if so, under what condition? For example, you may want to block traffic for known TOR Proxy exit nodes which you can detect with the IP Intelligence subscription.


  • Do you need to bypass decryption for any type of traffic, and if so, under what condition? For example, you may need to bypass decryption for sites that typically contain personally identifiable information (PII) like Financial and Healthcare related sites. You can achieve this with the URL Category subscription.


  • Do you need to send different types of traffic to different service chains, and if so, under what condition? For example, it may be optimal to bypass some traffic types but still send to a subset of security products for additional encrypted analysis.

Once you have identified your goals, the next step is to put them in the correct order. As previously mentioned, security policy rules are nested. So logically, security rules should be placed in relation to order of events in the OSI model. With this in mind, here are a few simple best practices for creating security policy rules:

  1. Match on IP (layer 3) and port (layer 4) conditions first at the top of the rule set. This can also make policy evaluations faster.
  2. Match on protocols (layer 7) at the bottom. In order to know what the layer 7 protocol is, you have to decrypt it.
  3. Put traffic rules that bypass decryption above rules that intercept (decrypt). For example, if you have a rule that requires decrypted analysis, rules below it cannot bypass decryption.
With traffic rules defined and in the correct order, it is time to build an SSL Orchestrator security policy. Security policies are accessible from within an SSL Orchestrator topology workflow or directly from the Security Policy tab in the SSL Orchestrator UI. Depending on the direction of traffic flow, security policies will always either start with “Pinners_Rule” and “All Traffic” rules (for outbound/forward proxy traffic flows),

../_images/image61.png

Figure 61: SSL Orchestrator Security Policy


or simply an “All Traffic” rule (inbound/reverse proxy traffic flows).

../_images/image62.png

Figure 62: SSL Orchestrator Security Policy


Basic Security Policies Description
Pinners_Rule

This rule is auto provisioned for outbound topologies and represents the set of “known” certificate pinning URLs. Certificate pinning is a function whereby a client user agent (ex. a browser) is provided upfront knowledge of a servers certificate that it can use to compare against the certificate presented by the server when a session is established. This technique is often used to prevent man-in-the-middle attacks, but as it also prevents TLS inspection, is detrimental to SSL visibility solutions. Certificate pinning is wholly the responsibility of the client user agent. Thus, there is no mechanism to prevent or detect when, and if, certificate pinning will happen (other than maintaining a list of known pinning URLs to bypass TLS inspection). There are, however, exceptions.

Modern browsers contain two certificate trust stores. A trust store is a database of certificate authorities, typically provided by the browser vendor, that allows the browser to trust public entities. These browsers will have a “system” trust store that contains the certificate authorities maintained by the vendor, and a “user” trust store that contains certificate authorities maintained by the user (or organization). Browsers will ignore certificate pinning rules if the issuer of the server certificate presented is trusted by a CA in the user trust store. In any SSL visibility solution for outbound (Internet-bound) traffic, a local CA is used to re-issue (forge) remote server certificates. And in order to trust this local issuer, the CA certificate must be installed to the browsers user trust store. Therefore, for practical purposes, certificate pinning does not generally affect browser traffic.

The above rule applies to modern browsers and non-browser user agents that adhere to the same multi-trust store pinning methodology. There are, of course, user agents that cannot ignore certificate pinning. These usually include operating system updates, anti-virus/anti-malware updates, and some mobile applications. For these specifically, the Pinners_Rule security policy rule contains a list of customizable URLs to detect and bypass TLS inspection.

All Traffic This rule is auto provisioned for all topology types and represents the default action if no other rules match.

To create a new rule, click the Add button, give the rule a unique name, and select a Condition. Note that the below conditions are generally in order of events in the OSI model.

Security Policy Conditions Availability Description
Client IP Geolocation

Outbound

Inbound

Geolocation can capture the country code or name, continent or state of a given IP address. This particular setting will match the client (source) address against the geolocation database.

For additional information on updating and maintaining the geolocation database, please see:

https://support.f5.com/csp/article/K11176

Client IP Reputation

Outbound

Inbound

IP reputation is a subscription service that provides up-to-date identification of hostile and/or untrustworthy sites. These sites include spam sources, TOR proxy exit nodes, and botnets. This particular setting will match the client (source) IP address against the IP reputation database.

For more information on licensing and maintaining the IP reputation database, please see:

https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-local-traffic-manager-implementations/enabling-ip-address-intelligence.html#GUID-540E5537-CD68-45DE-9A59-BF4490B4DF61

Client IP Subnet Match

Outbound

Inbound

This condition matches the client (source) address directly and must contain both the IP address and a subnet (CIDR) mask. For example, to match a single IP address, you might enter “10.10.0.100/32” where 10.10.0.100 is the IP address and /32 is the CIDR mask indicating a single IP address. To cast a larger net, you could also do something like “10.10.0.0/24”, which matches every address in the 10.10.0.x range of addresses.
Server IP Geolocation

Outbound

Inbound

This condition matches the server (destination) address against the geolocation database.
Server IP Reputation

Outbound

Inbound

This condition matches the server (destination) address against the IP reputation database.
Server Subnet Match

Outbound

Inbound

This condition matches the server (destination) address directly and must contain both the IP address and a subnet (CIDR) mask. For example, to match a single IP address, you might enter “10.10.0.100/32” where 10.10.0.100 is the IP address and /32 is the CIDR mask indicating a single IP address. To cast a larger net, you could also do something like “10.10.0.0/24”, which matches every address in the 10.10.0.x range of addresses.
Client Port Match

Outbound

Inbound

This condition matches the client (source) port.
Server Port Match

Outbound

Inbound

This condition matches the server (destination) port.
SSL Check

Outbound

Inbound

This condition simply determines if traffic is SSL/TLS-based and would typically be used in conjunction with another condition. For example, to check if traffic is SSL before attempting to do an SNI category lookup.
Category Lookup (All) Outbound

URL categorization is a subscription service that provides up-to-date classification of URLs by “category”. There are, at current count, close to 400 categories classifying and constantly updating information on public URLs. For example, the “Financial Data and Services” category contains URLs for financial institutions and financial services. In the context of an SSL Orchestrator security policy, these categories are largely useful to provide identification of sites that may pass sensitive personally identifiable information (PII), which you may opt to bypass decryption for, per regulatory requirements.

The “Category Lookup (All)” rule condition is used to classify URLs based on either SNI or HTTP host header. This condition is most effective when a TCP-base SSL Orchestrator topology consumes traffic on all ports.

For more information on licensing and maintaining the URL category database, please see:

https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-secure-web-gateway/url-database-for-swg.html

Category Lookup (SNI) Outbound This condition is similar to the above except that it only processes URL information from the SNI. The Server Name Indication (SNI) is an extension value that a TLS1.0 and above client will present in its Client Hello message to initiate a TLS handshake.

Category Lookup

(HTTP Connect)

Outbound SSL Orchestrator can be deployed as an explicit forward proxy, but it can also be deployed as a transparent proxy in front of another explicit proxy. In this scenario, clients continue to communicate with (and potentially authenticate) this upstream explicit proxy, using SSL Orchestrator as a route hop to get there. To facilitate URL categorization, the security policy must then pull the URL from the HTTP Connect passing through the topology.
L7 Protocol Lookup (TCP)

Outbound

Inbound

Post decryption (interception), the security policy has an opportunity to inspect the application layer traffic, and in some cases, determine what the protocol is. This condition detects various types of TCP protocols. Note that as this happens after interception, the security policy removes the option to perform SSL intercept/bypass actions on the matching traffic.
L7 Protocol Lookup (UDP)

Outbound

Inbound

Post decryption (interception), the security policy has an opportunity to inspect the application layer traffic, and in some cases, determine what the protocol is. This condition detects various types of UDP protocols. Note that as this happens after interception, the security policy removes the option to perform SSL intercept/bypass actions on the matching traffic.
URL Match

Outbound

Inbound

Post decryption (interception), the security policy can also inspect URI paths of decrypted HTTPS and unencrypted HTTP traffic. Note that as this happens after interception, the security policy removes the option to perform both SSL intercept/bypass and service chain actions on the matching traffic.

To select multiple conditions for a single rule, click the plus sign (+) to the right of the rule. This will provide a new set of options for how to match all, or parts of, the combined conditions.

Security Policy Rule Matching Description
Match Any When selected, traffic can match any of the conditions.
Match All When selected, traffic must match all of the conditions.

As there is a near infinite set of possibilities for creating SSL Orchestrator security policies, it may be useful to show a few sample policies. For example, you might create a policy that does nothing more than intercept any traffic coming from the 10.0.0.0/8 subnet (bypassing everything else).

Security Policy Rule User Input
Name Provide a unique name.
Condition Client IP Subnet Enter 10.0.0.0/8.
Action Select Allow.
SSL Forward Proxy Action Select Intercept.
Service Chain Send to a service chain as required.

../_images/image63.png

Figure 63: SSL Orchestrator Security Policy


To add a bypass rule for finance URLs based on URL categorization, you can add a new rule to this policy. Click the Add button to create a new rule.

Security Policy Rule User Input
Name Provide a unique name.

Condition

SSL Check

Select True.
Click the plus sign (+) to add a second condition.

Condition

Category Lookup (All)

Select Financial Data and Services.
Action Select Allow.
SSL Forward Proxy Action Select Bypass.
Service Chain Send to a service chain as required.
Match Any | Match All Select Match All.

../_images/image64.png

Figure 64: SSL Orchestrator Security Policy Rule


Click the OK button to add the new rule.

../_images/image65.png

Figure 65: SSL Orchestrator Security Policy


Note here that, contrary to rule number 1 in the best practice guidelines, the (layer 3) IP-based rule can be below the category lookup rule. This adheres to rule number 3 where bypass rules should generally happen before intercept rules.

Once you have deployed this security policy, navigate to the Security Policies tab in the SSL Orchestrator UI. For the newly created/modified security policy, click the link under the Per Request Policies header. This will open a new tab to the visual per-request policy.

../_images/image66.png

Figure 66: SSL Orchestrator Security Policy VPE


Notice that the visual policy elements are nested in accordance with the order of the rules in the security policy. The double-bordered boxes represent macro policies, which include the rules defined in the security policy, plus service chains. To show the path through this nested logic, here is the image again with the paths color-coded.

  • The red path is where traffic flows when the Pinners_Rule rule is matched.


  • The blue path is where traffic flows when the finance_bypass rule is matched.


  • The green path is where traffic flows when the client_network rule is matched.


  • The final SSL Bypass Set agent is what is processed if no other rules match the All Traffic rule

The Session Check agent and subsequent fallback path are utilized when the security policy is placed into a transparent proxy captive portal authentication scenario.

../_images/image67.png

Figure 67: SSL Orchestrator Security Policy VPE


Note again that the security policy rules engine converts rules to visual elements in one direction only. It cannot convert visual elements back to rules. Therefore, once the visual per-request policy has been manipulated, the Guided Configuration security policies user interface will no longer be available. The above visual policy is presented to both illustrate the nested path of policy rules and that SSL Orchestrator traffic flow logic can be extended beyond the security policy rule set if that rule set does not meet your requirements.


Troubleshooting Security Policies

There are generally two reasons for security policies to fail (or appear to fail):

  • Traffic breaks through a service chain (defined by a security policy rule)


  • Traffic does not behave as expected through the security policy

Traffic breaking through the service chain is almost always the result of traffic breaking at a security service. Here are a few things you should try when troubleshooting general connectivity through the security policy.

Troubleshooting Security Policies (traffic flow) User Input
Isolate services Simply remove services from the service chain to isolate each one. In this scenario, It is useful to remove all services from the service chain, confirm that traffic flows through the SSL Orchestrator topology, and then re-add the services one-at-a-time until traffic again breaks.
Capture traffic at services

All security services configured through SSL Orchestrator will be attached to the BIG-IP via VLANs and, in most cases, isolated VLANs. Inline L2, L3 and HTTP services will consist of two VLANs (to-service and from-service), and ICAP and TAP services will each consist of one VLAN. For any given security device, it is therefore possible to surgically insert traffic capture probes at specific points in the traffic flow. For example, as inline services have separate to-service and from-service VLANs, you can insert a probe at the to-service VLAN to observe traffic flowing to the service from the BIG-IP and a probe at the from-service VLAN to observe traffic flowing from the service back to the BIG-IP. In many cases, when traffic breaks inside the service chain, you will find traffic flowing to the service, but nothing coming out the other side. This technique of isolated captures is a very simple and effective way to pinpoint connectivity issues inside the service chain.

To create probes for inline services, take note of the full path to a service’s VLANs. This can be found under the Partition / Path column in the Network –> VLANs UI.

../_images/image68.png

Figure 68: Service VLANs


The path to the VLAN uses the following syntax:

ssloN_ + [network name] + .app/ssloN_ + [network name]

So, for example, if the to-service network for a service is called “FEYE_in”, the VLAN path would look like this:

ssloN_FEYE_in.app/ssloN_FEYE_in

To then capture on this interface (traffic going to the service), a tcpdump command would look something like this:

tcpdump -lnni ssloN_FEYE_in.app/ssloN_FEYE_in

To see the full decrypted payload, add the “-Xs0” flags:

tcpdump -lnni ssloN_FEYE_in.app/ssloN_FEYE_in -Xs0

Of course, it is also usually possible to capture on the security device itself. Here again, the goal is to surgically determine whether traffic from the SSL Orchestrator service chain is passing to the inline service and then returns back to the service chain. This will often uncover problems with security device interfaces and routing issues.


Another reason for showing the visual representation of the security policy is to aid in troubleshooting. Traffic that is not behaving as expected through the security policy can often simply be a misunderstanding of how traffic *should* flow the rule set.

Troubleshooting Security Policies User Input
Follow security policy logic

Refer back to the color-coded visual policy image above. A flow will pass from Start, through the logic of each of the agents and macros, and to specific branches of those agents and macros until it reaches the Allow or Reject blocks on the right. With debug logging enabled in the SSL Orchestrator topology, this path will be represented in logs.

The first step is to enable debug logging. Open the corresponding topology workflow and navigate to the Logging page. Set the SSL Orchestrator and Per-Request policy logging options to Debug, then re-deploy.

Open a BIG-IP console shell and enter the following command to watch a filtered view of the SSL Orchestrator log in real time:

tail -f /var/log/apm |grep -IE “following|executed”

Attempt a connection through the topology and observe the log. For each agent the logical flow passes through, you will see “executed” and “following” logs that will correspond directly to the elements in the visual policy.



4.3.3. Sending blocking pages for server certificate validation errors

It may be useful in some environments to generate a blocking page response to clients when a remote server certificate is expired or untrusted. Untrusted certificates will typically be those that are self-signed, not issued by a public certificate authority, or cannot be trusted based on the CA bundle applied to the respective SSL configuration. In any case, the SSL configuration page of the topology workflow allows for either drop (drop the connection) or ignore (ignore the error and forge an expired or untrusted certificate) settings. Certificate error response can be extended by using the Server Certificate Status Check option on the SSL Orchestrator Security Policy page, in which case an HTML blocking page is returned to the client, using a “good” forged certificate. Ensure that the Expire Certificate Response and Untrusted Certificate Response options are set to ignore on the SSL Configuration page, then check the Server Certificate Status Check option on the Security Policy page to enable this feature. Naturally, an HTML blocking page response is only possible when TLS traffic is intercepted/decrypted. On deploying a security policy with this option enabled, the visual policy will contain a new agent in the built-in Pinners_Rule rule that triggers a Server Cert Status macro.

../_images/image69.png

Figure 69: Server Cert Status


The macro performs two key functions:

  • On SSL traffic, performs an evaluation on the received server certificate in the Server Cert Status agent.


  • If the certificate is untrusted or expired, a new mask option is applied for certificate response control in the Server Cert Response Control agent. This option generates a good forged certificate irrespective of the actual certificates status so that a blocking page can be presented to the client.

On failed (expired and untrusted) certificates, a good certificate is forged, and the visual policy follows a path to a Reject ending, which generates the HTML blocking page response to the client.



4.3.4. Egressing to an upstream explicit proxy

While not specifically related to security policies, upstream explicit proxy chaining is controlled by the security policy VPE, so is included on the Security Policy Page. Proxy chaining is effectively how one explicit proxy talks to another explicit proxy. In this case, SSL Orchestrator as an explicit proxy server to a client can then pass egress (re-encrypted) traffic to an upstream explicit proxy (as the client to the upstream proxy).

../_images/image70.png

Figure 70: Proxy Chaining


This mechanism is available for security policies attached to explicit forward proxy topologies. Click the Proxy Connect checkbox to enable this feature.

Proxy Connect User Input
Pool Select an existing pool or create a new pool that directs traffic to an upstream explicit proxy IP address and port.
User Name If the upstream proxy requires authentication and supports Basic auth, enter a static username here.
Password Enter the corresponding password here.

On deploying a security policy with Proxy Connect enabled, the visual policy will contain a new set of “Proxy Select” objects, as illustrated below.

../_images/image71.png

Figure 71: Proxy Chaining VPE


The Proxy Chaining (Connect) agent creates a Proxy Select for egress explicit proxy handling with no URI rewrite (before any policy evaluation). As an initial server-side connection may be required to fetch the remote server certificate, this agent pushes the client Connect through to the remote server (no rewrite). The Proxy Chaining (URI Rewrite) agent creates a second Proxy Select for egress explicit proxy handling after decrypted inspection, in order to create a new Connect request to the upstream explicit proxy.