FortiGate Automation Stitch for Azure VM Micro Segmentation

[JohnMcdo]

A FortiGate Automation Stitch brings together a Trigger and an Action. The Trigger can be internal or external to the FortiGate, when a trigger occurs one of more Actions can be initiated. The Action, like the Trigger can be internal or external to the FortiGate.

The code in the repository fortigate-automation-stitches, is an example of a FortiGate SDN Event Log being the Trigger to initiate the Action of updating an Azure Route Table to enforce VM Micro Segmentation. The SDN event log entry generated when a FortiGate Dynamic Address is updated, triggers the action of sending a Webhook to Azure. The webhook contains the information required to update the Azure route table. The Azure route table update is either the addition of a route or the removal of a route from an Azure route table.

The FortiGate Automation Stitch Azure route table updates are made to support Micro Segmentation of VMs in FortiGate protected networks. In Azure, VMs on the same subnet and network typically have the ability to communicate without restriction. Network Security Groups can be implemented to manage VM communication, however this can be a time intensive process and NSGs do not have the ability to inspect traffic in as thoroughly as a FortiGate. Adding a VM's IP address to the Azure route table where the FortiGate is the next hop can ensure that VM to VM communication is routed via the FortiGate. VM to VM traffic inspection in the same subnet or network space significantly improves security.

Maintaining these VM specific routes can become problematic as a VM may be allocated and deallocated related to any number of metrics. The ability for the FortiGate to recognize when a VM has been allocated or deallocated through the use of the FortiGate Dynamic Address is key to initiating an Azure route table update. The FortiGate Dynamic Address also serves as a Source or Destination in FortiGate Policies. The FortiGate Dynamic Address will be populated with the IP addresses of the VMs that are identified via the Filter criteria in the FortiGate Dynamic Address.

Azure Routes and Route Tables

A route in an Azure route table determines how traffic is directed, based on the destination of the traffic. A standard Azure route table in a FortiGate protected Azure network has the FortiGate (or a load balancer that sends traffic to the FortiGate) as the next hop. VMs in FortiGate protected Azure networks send their traffic via the FortiGate if the destination of the traffic is in the Azure route table and the next hop for that destination is the FortiGate. FortiGate deployments separate traffic into two categories, trusted and untrusted. For Example, untrusted traffic ingresses into the network via the FortiGate port1 and inspected trusted traffic egresses via FortiGate port2. Once trusted traffic in sent out port2 all the VMs in the trusted subnets can be receivers of the traffic, barring any other security measures. VMs is these trusted subnets communicate without their traffic having traverse the FortiGate. Adding a VM's IP address to the Azure route table, this is called a host route, and indicating the FortiGate as the next hop, all traffic to that VM must pass through the FortiGate.

For example, adding the route 10.20.1.4/32 with the FortiGate IP of 10.17.1.6 as the next hop to the Azure route table, would cause a VM with the IP 10.20.1.8 to send traffic to the FortiGate at 10.17.1.6, when communicating with VM 10.20.1.4. Without the addition of the host route to the Azure route table, VM 10.20.1.8 would be able to communicate directly with VM 10.20.1.4 and not have to send traffic via the FortiGate. When VM 10.20.1.4 responds to VM10.20.1.8, the response traffic does not go via the FortiGate unless there is a host route of 10.20.1.8/32 in the Azure route table.

Azure Automation Components

The Azure route table update, either the addition or deletion of a VM IP address in the form of a host route is initiated in Azure via a webhook. The webhook is associated to an Azure Automation Account Runbook, the runbook is a PowerShell script that either adds the route to the Azure route table or deletes the route. The addition or deletion of the route is determined by the information sent from the FortiGate.  The FortiGate SDN event log indicates that an IP address was either added or removed from the FortiGate Dynamic Address.  The webhook is populated with the IP address, the action that was taken on the IP address in the FortiGate Dynamic Address (add or remove), and the Azure specific information, the name of Azure Resource Group that contains the Azure Route Table, the name of the Azure Route Table, the next hop IP address (FortiGate or Azure Load Balancer that sends traffic to the FortiGate), and a prefix string to name the host route.

The Azure Automation components are

• Automation Account - The Automation Account contains Runbooks, Schedules, Webhooks, Access Controls, Metric, etc.
• Automation Account Identity - Setting the Account Identity enables the application of Roles and Scope
  
• Automation Account Runbook - The Runbook is a script with Python or PowerShell that is run in response to a webhook and/or a schedule
  
• Runbook Webhook - The Webhook is an endpoint that calls the Runbook when an HTTPS post is received.

FortiGate Automation Stitch

The example code for the FortiGate Automation Stitch is triggered when an IP address is either added or removed in a FortiGate Dynamic Address.  The FortiGate Dynamic Address is updated when the filter criteria of the FortiGate Dynamic Address is matched.  The FortiGate Azure SDN Connector, when enabled, retrieves Azure environment information on regular intervals. The FortiGate Azure SDN Connector can be scoped to an entire Azure Subscription or as fine grained as an Azure Resource Group. The FortiGate Dynamic Address filter criteria in the example code is an Azure Tag "ComputeType" with a Value of either "WebServer" or "DbServer".

A FortiGate Dynamic Address Object update Event Log can be generated from several events, the events the example code uses are "Dynamic address added" and "Dynamic address removed". The Event Log is generated when the FortiGate SDN Connector retrieved Azure Environment information affects the FortiGate Dynamic Address. In the example code the FortiGate Dynamic Address "WebServers" will be updated with the IP addresses of VMs with the Tag "ComputeType" where the Tag value is "WebServer". The FortiGate Dynamic Address "DbServers" will be updated with the IP addresses of VMs with the Tag "ComputeType" where the Tag value is "DbServer".

The FortiGate SDN Connector Event Log is the Trigger for the FortiGate Automation Stitch. The Automation Stitch once triggered initiates one or more Actions, in the example code a single action is executed. The action is a webhook that sends an HTTPS POST request to the Azure Automation Account Runbook's webhook. The data in the POST request is used to locate the Azure route table to update and what the comprises the update.

FortiGate Automation Stitch Components

The FortiGate Automation Stitch components are

• FortiGate Azure SDN Connector - Retrieves environment information from Azure. The Azure SDN Connector can be scoped to a single Resource Group
• FortiGate Dynamic Address - An Address object that is updated with IP addresses in Azure based on filter criteria, in this example the value of an Azure Tag
• FortiGate Automation Stitch Stitch - The Stitch combines the trigger with one or more actions
• FortiGate Automation Stitch Trigger - The Trigger is an event, internal or external to the FortiGate, in this example an SDN Event Log related to a FortiGate Dynamic Address
• FortiGate Automation Stitch Action - The Action(s) are executed internally or externally, in this example the single Action is a call to an Azure Automation Account Runbook's Webhook
• FortiGate Firewall Policy - The micro segmented VM to VM traffic requires a FortiGate Firewall Policy to allow the VM traffic to traverse the FortiGate

README

The README file in the Github Repository fortigate-automation-stitches goes into detail about the Azure Automation Account and the FortiGate Automation Stitch.

The fortigate-automation-stitches repository contains

• Azure Automation Account setup instructions using PowerShell
• Azure Automation Account PowerShell setup script
• Azure Automation Account PowerShell Runbook to update an Azure Route Table
• FortiGate CLI commands to setup
  
  • Dynamic Addresses
  • Automation Stitch Stitch
  • Automation Stitch Trigger
  • Automation Stitch Action

Tagging an Azure VM

The FortiGate Automation Stitch and Azure Automation Account Runbook depend upon an Azure VM being Tagged. If the VM is never Tagged or if the none of the Tags match the Tag the FortiGate Dynamic Address is firtering for a trigger never happens and the Azure route table is never updated.

Tagging the VMs manually while good for a demo, is not a scalable process.  The VM allocation process should tag the VM accordingly to trigger the FortiGate Automation Stitch. The expectation would be an Azure ARM Template or perhaps a Terraform module is utilized to build and tag the VM.  Deallocation of a VM is sufficient to trigger the FortiGate Automation Stitch as the FortiGate recognizes when the IP address of the tagged VM is no longer present in the Azure Environment.

Resources

Video - https://www.youtube.com/watch?v=I_oD2RYej2I

Repo - https://github.com/movinalot/fortigate-automation-stitches