Palo Alto Networks Knowledgebase: Leveraging Action-Oriented Log Forwarding in Azure

Leveraging Action-Oriented Log Forwarding in Azure

1375
Created On 02/07/19 23:57 PM - Last Updated 02/07/19 23:58 PM
Virtual Systems Virtualization
Resolution

This document is intended as an easy example on how to leverage action oriented and selective log forwarding in PAN-OS 8.0, not as a comprehensive solution document.

 

Goal

In this document, we summarize the information and relevant steps to integrate Palo Alto Networks Next Generation Firewalls with Azure to quarantine a subnet based on a threat detected by the firewall. We will be using the Azure two-tier sample as the basis for this example; however, the concepts are easily extended to other deployments.

 

https://github.com/PaloAltoNetworks/azure/tree/master/two-tier-sample

 

The source code for the Azure Function can be cloned from here:

 

https://github.com/PaloAltoNetworks/AzureNSG

 

Action‐Oriented Log Forwarding using HTTP

To enable better integration between your firewall and IT infrastructure, PAN‐OS 8.0 gives you the ability to trigger an action or initiate a workflow to an external HTTP‐based service when a log is generated on the firewall. You can now send an HTTP request directly to a third‐party service to trigger an action based on the attributes in a firewall log. This enables the firewall to work with any HTTP‐based service that exposes an API. Modification of the URL, HTTP header, parameters, and the payload can be customized to meet your integration needs.

 

This capability can be combined with the Selective Log Forwarding Based on Log Attributes, allowing you to forward logs matching a defined criteria so that you can automate a workflow or an action; you do not need to rely on an external system to convert syslog messages or SNMP traps to an HTTP request.

 

Prerequisites

 Prior to deploying the solution, the following information needs to be collected from your Azure deployment:

  • Tenant ID (Directory ID)
  • Application ID
  • Authentication Key
  • Subscription ID
  • Resource Group Name
  • Network Security Group Name
  • Azure Region

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal

 

Stopping a Brute-force Attack

 For this example, we assume that a web-server in the environment has been compromised and is attempting a brute-force attack against a back-end database server. In this case, the unified log view on the FW will look something like this:

 Picture1.png

 

Create a Function App

 Add a new Function App with the following settings:

  • App name (unique)
  • Subscription (if relevant)
  • Resource Group (deploy to existing)
  • Hosting Plan: Consumption
  • Location: Match currently-deployed infrastructure
  • Storage: Use existing or create a new one

Picture1.png

Add a Function

Select the newly-created function app from the resource group.

 

Picture1.png

 

Select 'Functions' and then click the '+'.

 

Picture1.png

 

 

Leave 'Webhook + API' selected and click 'Start from source control'.

 Picture1.png

 

Under 'Deployments' click 'Setup'.

 

Picture1.png

 

Click 'Configure required settings’.

 

Picture1.png

 Select 'GitHub' for the source.

 

Picture1.png

 

 

Authenticate to GitHub if required. Then, select your organization, the project containing the source code and the desired branch. Click 'OK' when done.

 

Picture1.png

 

A new read-only function will be created with the name 'myfunction1'. Because it is linked to GitHub as the source, it is read-only. Follow the on-screen instructions to change it to read-write if desired.

 

Picture1.png

 

Click '</> Get function URL' at the top of the screen and copy the function URL.

 

Picture1.png

 

Configure the Firewall

 Create an HTTP Server Profile with the following settings:

  • Name: Freeform text
  • Address: The FQDN portion of the function URL
  • Protocol: HTTPS
  • Port: 443
  • HTTP Method: POST

Picture1.png

 

 

Click 'Payload Format' > 'Threat'.

 

Picture1.png

 

Set the URI Format to the URL portion of the function URL and set the 'content-type' header to 'text/html'.

 

Picture1.png

 

Set the payload as follows ('&' REQUIRED):

 

TenantID=########-####-####-####-############

&ClientID=########-####-####-####-############

&ClientSecret=#################### (URL ENCODED!)

&SubscriptionID=########-####-####-####-############

&ResourceGroupName=Azure_RG_Name

&NetworkSecurityGroupName=Azure_NSG

&Region=REGION

&Attacker=$src

 

Where:

 

  • The TenantID, ClientID, ClientSecret, and SubscriptionID are values available from your Azure subscription and Service Principal.
  • The ResourceGroupName, NetworkSecurityGroupName, and Region are values from the specific deployment.
  • 'Attacker=$src' will be the source IP address of the system responsible for the attack(s).

 

Completed Log Forwarding Profile:

Picture1.png

 

Attach the Log Forwarding Profile to the desired rule(s) and commit the changes.

 Picture1.png

 

If desired, monitor the function as it runs from the function definition page in Azure. Select 'Expand' under Logs to view additional log entries.

 

Picture1.png

 

Test the Code

 In this case, a brute-force attack against the database server is initiated from the web server. All action taken by the function is logged for troubleshooting purposes. This can be changed as desired by modifying the code.

 

Picture1.png

 

The NSG has been updated to deny all outbound access from the host. The default rules are not altered but it is possible to do so if desired. Additional/alternate rules may be specified as required.

 

Picture1.png

 

 

 

 



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClDKCA0&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language