Troubleshooting SSL Decryption using Dynamic Address Groups

Introduction

This document will walk through an automation example using the Palo Alto Networks firewall and Dynamic Address Groups (DAGs). Using DAGs is a powerful way to bring automation to security policies. The idea is to have pre-set policies configured on the firewall which utilize Dynamic Address Groups. As conditions change for a host, it may be dynamically moved to a DAG, and therefore, be subject to a different policy in the rulebase. If conditions change once more for that host, it may be moved to yet another DAG, hitting a different policy altogether. All without an administrator adding and deploying new rules or committing changes to be pushed out.

The conditions which may be monitored are vast! In this example we will use DAGs to dynamically move a host into and out of an SSL decryption group for troubleshooting. However, the use cases are virtually endless.

Requirements

Required Item	Notes
Palo Alto Networks Firewall	Tested with a VM50, PANOS 8.1.0
Host with browser	Tested with Windows 7 64-bit VM

Network Diagram

Use Case Diagrams

Configuration

Dynamic Address Group

We will begin by creating the tag which will be used by the Dynamic Address Group. Create the tag for disabling SSL decrypt.

Objects > Tags > Add

Create the DAG to be used within the decryption policy.

Objects > Address Groups > Add

• Name the address group

• Change type to ‘Dynamic’

• Click the Add Match Criteria and select the tag created in the previous step to denote no SSL encryption

SSL Decryption Policy

Configure the SSL decryption policies to decrypt (hosts outside of DAG) and exclude decryption (hosts inside of DAG).

Policies > Decryption> Add

• Add two policies in this order

  • Do not decrypt

    • Use the do not decrypt DAG as the source address

    • Make the Action ‘no-decrypt’

  • Decrypt all other

    • Use Any for source/destination addresses

    • Make the Action ‘decrypt’

    • Ensure the Type is ‘ssl-forward-proxy’

Note: this document assumes there is a certificate on the firewall and client to perform the decryption. See instructions here if needed: https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption/ta-p/59719

The decryption policies should reflect the following:

Vulnerability Signatures

Before we add the logging conditions, we need a way to trigger the condition. In this example, we will create custom vulnerability signatures that watch for a specific URI paths. We will use the URI path as way to move a host into or out of our DAG.

Create a vulnerability signature which looks for the URI path of ‘/kw-nodecrypt/’.

Objects > Custom Objects > Vulnerability > Add

For the Configuration tab:

• Assign the Thread ID a custom signature number

• It is recommended to set Severity to informational and Action to Alert

  • For live environments, work with the Incident Response team so they know to ignore this specific alert

• Direction is client2server

For the Signatures tab:

• Add a Standard signature (opens a new window)

• Leave the Scope as Transaction

• Use the green plus button to Add And Condition (opens a new window)

• Change context to: http-req-uri-path

• For the Pattern, enter our custom command to disable decryption: /kw-nodecrypt/

Select OK to see the result.

Click OK twice to save.

Create a vulnerability signature which looks for the URI path of ‘/kw-nodecrypt-remove/’. This will tell the firewall to remove the host from the SSL bypass DAG and begin decrypting once again. This will be further explained in the Log Forwarding portion of the configuration.

Objects > Custom Objects > Vulnerability > Add

For the Configuration tab:

• Assign the Thread ID a custom signature number

• It is recommended to set Severity to informational and Action to Alert

  • For live environments, work with the Incident Response team so they know to ignore this specific alert

• Direction is client2server

For the Signatures tab:

• Add a Standard signature (opens a new window)

• Leave the Scope as Transaction

• Use the green plus button to Add And Condition (opens a new window)

• Change context to be http-req-uri-path

• For the Pattern, enter our custom command to disable decryption: /kw-nodecrypt-remove/

Click OK to see the result.

Click OK twice to save.

The two custom vulnerability signatures similar to the following:

Log Forwarding Profile

With the supporting configuration in place, we can now configure the firewall to watch for our custom signatures and take action (move host into or out of a DAG).

Create a custom Log Forwarding profile.

Objects > Log Forwarding > Add

• Name the log forwarding profile

• Select Add to create a new match list (opens a new window)

• Name the match list

• Select threat as the Log Type

• For the filter use: (name-of-threatid eq 41000)

  • Use the threatID you entered when creating the first vulnerability signature

  • Note: the filter can also be manually built by selecting the down arrow in this field and choosing Filter Builder

• Select Add in the Built-in Actions window (opens a new window)

• Name the Action

• Select Tagging as the action type

• Target is Source Address

• Action is Add Tag

• Registration is Local User-ID

• In the Tags dropdown, select the tag created in the first step

Click OK twice to be taken back to the Log Forwarding Profile. If you exit too far, click on the Log Forwarding Profile so you can add another match list.

• Select Add to create a second match list (opens a new window)

• Name the match list

• Select threat as the Log Type

• For the filter use: (name-of-threatid eq 41001)

  • Use the threatID you entered when creating the second vulnerability signature

  • Note: the filter can also be manually built by selecting the down arrow in this field and choosing Filter Builder

• Select Add in the Built-in Actions window (opens a new window)

• Name the Action

• Select Tagging as the action type

• Target is Source Address

• Action is Remove Tag

• Registration is Local User-ID

• In the Tags dropdown, select the tag created in the first step

Click OK three times to save the Log Forwarding profile. The results should be similar to the following:

Vulnerability Profile

In order to have the custom vulnerability objects to appear in the threat logs, we will need to modify an existing vulnerability profile, create a new one, or clone one. Take these steps to clone the default.

Objects > Security Profiles > Vulnerability Protection

• Clone the default by selecting the checkbox to the left of ‘Default’ and clicking on Clone at the bottom of the window

• Open the cloned profile

• (optional) change the name of the profile

• Select the ‘simple-client-medium’ rule and clone it

• Open the cloned rule (opens a new window)

• Change the rule name to read: simple-client-informational

• Change the Action to Alert (this will provide a threat log entry)

• Check ‘informational’ in the Severity (uncheck all others)

Click OK twice to save the profile.

The new vulnerability profile should look something like this:

Firewall Policy

Configure a firewall policy to use the Log Forwarding profile and custom vulnerability profile.

Policies > Security

Select a rule which allows web browsing and edit the rule.

Under the Actions tab, select the newly created Log Forwarding profile in the Log Forwarding dropdown.

Change the Profile Type to ‘Profiles’ and ensure the newly created vulnerability profile is selected.

Click OK to save the policy.

Commit the configuration.

Test Configuration

Ensure the default action to decrypt SSL is working. Browse to an encrypted site such as https://paloaltonetworks.com and look at the certificate information in the browser.

Look for SSL decryption column ‘yes’ in Traffic logs. If the column isn’t visible, it can be added ( https://live.paloaltonetworks.com/t5/Management-Articles/Adding-Columns-to-the-Traffic-Logs-to-View-Additional-Session/ta-p/54193 )

Check the dynamic address group to see that the group is empty (i.e. no host is bypassing SSL decryption).

Objects > Address Groups

Under the Addresses column, select ‘more’ from the dynamic address group created in the first steps. Ensure the group is empty.

Use the URI path created to remove a host from SSL decryption. The command should trigger one of the custom vulnerability signatures, which will trigger the log forwarding profile to add a tag which will exempt the host from SSL decryption.

On the host, browse to any site and append the URI string you created which indicates no decryption:

/kw-nodecrypt/

For example, https://paloaltonetworks.com/kw-nodecrypt/

The browser will not pull up the page (404 error) as it does not exist, but more importantly, the host should now be exempt from SSL decryption. Be sure to close the browser to trigger the log event if the policy is configured to log at session end.

Verify that the correct vulnerability signature is recorded in the threat logs.

Monitor > Logs > Threat

Check the dynamic address group to see that it contains your host.

Objects > Address Groups

Under the Addresses column, select ‘more’ from the dynamic address group created in the first steps.

Browse to another HTTPS site and check the certificate. It should not show your certificate.

Check the traffic logs to ensure SSL sites are not being decrypted.

Monitor > Logs > Traffic

Use the URI path created to remove a host from decryption exemption. The command should trigger one of the custom vulnerability signatures, which will trigger the log forwarding profile to remove a tag which will cause the host to undergo SSL decryption.

On the host, browse to any non HTTPS site and append the URI string you created which indicates you want to decrypt:

/kw-nodecrypt-remove/

For example: http://www.calculator.net/kw-nodecrypt-remove/

The browser will not pull up the page (404 error) as it does not exist, but more importantly, the host should now be subject to SSL decryption. Be sure to close the browser to trigger the log event if the policy is configured to log at session end.

Verify that the correct vulnerability signature is recorded in the threat logs.

Monitor > Logs > Threat

Browse to another HTTPS site and check the certificate. It should show your certificate.

Check the traffic logs to ensure SSL sites are being decrypted.

Monitor > Logs > Traffic

Summary

There are many use cases for Dynamic Address Groups and Log Forwarding. From this example it served useful in troubleshooting SSL decryption by way of dynamically directing a host between decryption rules. When creating conditions in Log Forwarding objects, virtually anything that is logged is available.

• Traffic

• Threats

• WildFire

• Authentication

• Tunnel

• Data

• URL