Task 1 - Setup Azure CloudShell

Task 1 - Setup your AzureCloud Shell

• Login to Azure Cloud Portal https://portal.azure.com/ with the provided login/password

  

• Click on Cloud Shell icon on the Top Right side of the portal

  

• Click PowerShell

• Click on “Show advanced settings”

  

The field Storage Account should auto populate. If it does not, it is because the “Cloud Shell Region” field is not set to the Region where the Storage Account is located. Please try Central US, East US, and West US

• Select

  • Use existing Resource Group

    • Field should auto populate with USERXX-fgt-as-workshop (USERXX is your Username)

  • Use existing Storage account

    • Field should auto populate with USERXX############ (############) is a random string

  • Use existing File Share

    • This field will not auto populate
    • type cloudshellshare

• Click “Attach Storage”

  

• You now have access to Azure Cloud Shell console.

• Maximize the console window

  

Task 2 - Run Terraform

Task 2 - Run the Terraform Deployment

Perform the following step in your Cloudshell console to create your environment.

1. Clone the Github repo https://github.com/FortinetCloudCSE/fortigate-automation-stitch-workshop
2. Change directory to the fortigate-automation-stitch-workshop/terraform/azure folder
3. Run terraform init
4. Run terraform plan -var="username=$env:USER"
5. Run terraform apply -var="username=$env:USER"

Copy and paste these commands into your Cloud Shell console. The terraform variable username will be populated with the value of the environment variable USER

git clone https://github.com/FortinetCloudCSE/fortigate-automation-stitch-workshop
cd ./fortigate-automation-stitch-workshop/terraform/azure
terraform init
terraform plan -var="username=$env:USER"
terraform apply -var="username=$env:USER" -auto-approve

Task 3 - Terraform Verifications

Task 3 - Terraform Verification

1. Access the FortiGate, using the Terraform output.

   

   • Terraform output can be redisplayed at any point as long as you are in the ./fortigate-automation-stitch-workshop/terraform/azure directory, by using the command terraform output
   • To view the FortiGate and Linux VM login credentials use the command terraform output credentials

   cd
   cd ./fortigate-automation-stitch-workshop/terraform/azure
   terraform output
   terraform output credentials

2. Review the Resource Group and created components.

   • 1 - Automation Account
   • 4 - Disks for the VMs
   • 4 - Network Interfaces for the VMs
   • 2 - Network security groups
   • 1 - Public IP address for the FortiGate
   • 1 - Route table
   • 1 - Runbook
   • 1 - Storage account
   • 3 - Virtual Machines
     • 1 - FortiGate
     • 2 - Linux VMs
   • 1 - Virtual Network - Containing 3 Subnets
     • snet-external
     • snet-internal
     • snet-protected

   ---

   1. Minimize the Cloudshell console window
   2. Click the slide-drawer menu icon (AKA the hamburger menu)
   3. Click Home
   4. Click Resource Groups
   5. Click your Resource Group USERXX-fgt-as-workshop

   

3. Verify your Resources

   

Chapter 1 Discussion

Discussion Points During a Demo - Chapter 1

Fortinet provides a large library of infrastructure as code (IaC) templates to deploy baseline and iterate POC and production environments in public cloud. IaC support includes Terraform, Ansible, and cloud-specific services such as Azure ARM, AWS Cloudformation, and Google Deployment templates. Terraform Providers are available for several Fortinet products to insert and iterate running configuration.

For more information, review the following:

• FortiOS 7.4 Admin Guide

• Terraform Providers

• Ansible Modules

Key questions during your demo - Chapter 1

When giving this TEC Workshop as as demo, the following questions will provide a basis for next steps and future meetings:

• Has your organization standardized on an IaC tool-set for infrastructure provisioning and iteration?
• How are the responsibilities for infrastructure assigned? Does cloud network fall under a DevOps, Cloud Networking, or Application Delivery team, as examples?
• What is view on how IaC can improve workflows?
• Is workflow automation in cloud and cross-organizational collaboration important within your cloud business?

Task 1 - Review Azure Automation Account

Azure Automation

Automation in Azure can be accomplished in a number of ways, Logic Apps, Function Apps, Runbooks, etc. Each of the automation methods can be triggered in a number of ways, for example Events, Webhooks, and Schedules.

An Azure Runbook is just a script, in this case PowerShell, that the Automation Account can run. The Actions the Runbook can perform are controlled by the roles (what actions are allowed) and scope (where those actions can be performed) that have been granted to the Automation Account, via the Automation Account Identity.

The Runbook Actions are provided by PowerShell Modules that have been imported into the Automation Account. The PowerShell Modules are libraries of commands called Cmdlets that are grouped into several domains. For example, Accounts, Automation, Compute, Network, and Resources.

The Runbook created during the Terraform deployment process was imported from the Github repository for this Workshop. The function of the Runbook is to add or remove a route from a route table. The details of the route are related to the IP address of a VM that has been tagged with a specific tag and value.

The Runbook is triggered via a webhook when a VM with a specific tag with a specific value is observed by the FortiGate Azure SDN connector. The tag specifics and SDN Connector are covered in later tasks.

Task 1 - Review Azure Automation Account

1. Click the Automation Account aa-USERXX
2. Click Runbooks
3. Click Update-RouteTable

The overview shows details bout the Runbook. Important items to note are the Runbook type and version. In this case the Runbook type is PowerShell and the version is 5.1

The Runbook can be executed in several ways.

• Manually

• Linked to a schedule

• Via a Webhook

  

Task 2 - View Azure Automation Runbook

Task 2 - View Azure Automation Runbook

1. Click View to view the runbook PowerShell code

   

   The code has several sections

   • Lines 1-10: Indicate the functionality, author and last edit.
   • Lines 11-16: Define a single mandatory parameter named $webhookdata and clears any passed contextual information.
   • Lines 18-85: Several actions take place
     • Was the Runbook triggered by a webhook or not
     • Parse the webhook body
     • Determine if a route is being added, removed, or if an invalid operation was indicated.
       • For both the added and removed option the command Connect-AzAccount -Identity -Force is run to allow the PowerShell to use the Automation Account Identity to perform actions in the Azure environment, e.g., adding/removing a route from a route table.

   A Runbook can be executed by the Automation Account, however if the Runbook attempts to perform an action that the Automation Account identity does not have the privilege to do then the actions will fail. The initial privilege setting of the RunAutomation Account identity is none.

   This Runbook expects to be executed only via a Webhook with a payload provided by the FortiGate.

Task 3 - Review Azure Identity

Azure Identity

Azure uses identity with many objects in the cloud environments. Identity is a way to provide an object with permissions. As mentioned previously the Identity has no permissions until a role is assigned. Permissions are given by assigning one or more Azure Roles to the object. The role assigned permissions are associated to a scope.

Azure’s definition of a role is:

• A Role is a collection of permissions

Azure’s definition of a scope is:

• A Scope is a set of resources that the role assignment applies to. Scope has levels that are inherited at lower levels. For example, if you select a subscription scope, the role assignment applies to all resource groups and resources in the subscription.

Task 3 - Review Azure Identity

1. Click the Automation Account | Runbooks in the breadcrumb links aa-USERXX | Runbooks
2. Scroll down in the left-hand navigation to “Identity”
3. Click Identity
4. Click Azure Role Assignments

The Azure Automation Account Identity has the role of “Contributor” with a scope of the Resource Group USERXX-fgt-as-workshop

This means that any action a Contributor Role can perform can be done by all Runbooks associated with this Azure Automation Account to all of the resources in the scoped Resource Group

Chapter 2 Discussion

Discussion Points During a Demo - Chapter 2

When discussing Azure Automation with the Customer it is important to point out

• Azure Automation Runbooks can be used to provide automation capability with Azure Environments, The Runbooks can be run manually, on a schedule, or via a webhook.
• Azure Automation Identity can be assigned one or more Azure Roles to one or more Azure Scopes.
• Azure Automation Runbooks can be written in PowerShell and Python.

Azure Automation Runbooks can be triggered via a FortiGate Automation Stitch, the Action of the FortiGate Automation Stitch can be a Webhook used to send information from a FortiGate to an Azure Automation Runbook.

Utilizing the FortiGate Azure SDN Connector the FortiGate can react to events in the Azure Environment and trigger actions in the Azure environment.

The FortiGate Azure SDN Connector enables the FortiGate to be dynamically aware of the Azure environment, combine that awareness with Azure Automation Runbooks and there are infinite possibilities for Security issue detection, remediation, and so much more.

Task 1 - Automation Trigger

Task 1 - Create Automation Trigger

This task creates the trigger for when an Admin logs in or out or fails to login.

1. Login to the FortiGate using the IP address and credentials from the Terraform output.
2. Click through any opening screens for FortiGate setup actions, no changes are required.
3. Click “Security Fabric”
4. Click “Automation”
5. Click “Trigger”
6. Click “Create New”

1. Click “FortiOS Event Log” in Miscellaneous section
2. Enter
   • Name: Admin activity trigger
3. Click “+” in Event field
4. Enter search term “Admin Log” in “Select Entries”
5. Click these entries to add to the Event field
   • Admin Login failed
   • Admin Login successful
   • Admin Logout successful
6. Click Close
7. Click OK

Task 2 - Automation Action

Task 2 - Create Automation Action

This task creates the action for when an Admin logs in or out or fails to login.

1. Click “Action”
2. Click “Create New”
3. Click “Email” in Notifications

1. Enter
   • Name: Admin activity action
   • From: “USERXX@ftg.com” <– does not need to be a valid email
   • To: a valid email address to receive the email
   • Subject: Admin activity
2. Click OK

Task 3 - Automation Stitch

Task 3 - Create Automation Stitch

This task creates the stitch for when an Admin logs in or out or fails to login.

1. Click “Stitch”
2. Click “Create New”

1. Enter
   • Name: Admin activity stitch
2. Click “Add Trigger”
3. Click “Admin activity trigger” in “Select Entries”
4. Click “Apply”
5. Click “Add Action”
6. Click “Admin activity action” in “Select Entries”
7. Click “Apply”
8. Click “OK”

Task 4 - Test Automation Stitch

Task 4 - Test Automation Stitch

This task tests the automation stitch for when an Admin logs in or out or fails to login.

1. Logout
2. Login with an incorrect password
3. Login with the correct password
4. Check the destination email for Automation Stitch messages.

Task 1 - SDN Connector & Dynamic Addresses

Task 1 - Create FortiGate Azure SDN Connector and Dynamic Address Objects

The completed Automation Stitch trigger will be when a log is recorded for the following events:

• Dynamic address added
• Dynamic address removed

These log events are recorded when a FortiGate Dynamic Address is updated by adding or removing an address. FortiGate Dynamic Addresses are updated when the conditions of the Dynamic Address filter are met.

The Dynamic address filters can utilize the data returned from the FortiGate Azure SDN Connector. The filters can match on several aspects of the Azure environment. The Dynamic address filters in this task will match on Azure Tags and Values.

The configurations are presented as a combination of FortiGate CLI commands and screenshots of the configured object. All of the command blocks can be copied and pasted into the FortiGate CLI console.

1. Login to the FortiGate using the IP address and credentials from the Terraform output.

2. Click through any opening screens for FortiGate setup actions, no changes are required.

3. Click the CLI Console

4. Enter the following CLI commands to create an Azure SDN Connector named “AzureSDN”

   config system sdn-connector
       edit "AzureSDN"
           set type azure
           set status disable 
       next
   end

   

The Azure SDN Connector is set to disable for now, it will be set to enable in Task 5. The SDN Connector needs to exist for the Dynamic Addresses to refer to it, but at this point in the exercise it needs to remain disabled.

Create Dynamic Addresses

1. Use the FortiGate CLI Console to enter the following commands

2. Create AppServers Address

   config firewall address
       edit "AppServers"
           set type dynamic
           set sdn "AzureSDN"
           set filter "Tag.ComputeType=AppServer"
       next
   end

3. Create DbServers Address

   config firewall address
       edit "DbServers"
           set type dynamic
           set sdn "AzureSDN"
           set filter "Tag.ComputeType=DbServer"
       next
   end

4. Create WebServers Address

   config firewall address
       edit "WebServers"
           set type dynamic
           set sdn "AzureSDN"
           set filter "Tag.ComputeType=WebServer"
       next
   end

For the time being all of the Dynamic Addresses will remain unresolved, because the Azure SDN Connector is currently set to disable. You will view the updated WebServers Address in Task 5 after the Azure SDN Connector is set to enable

Task 2 - Automation Trigger

Create Complex Automation Stitch

A FortiGate Automation Stitch brings together a Trigger and one of more Actions.

FortiGate Automation Stitch Triggers are grouped in categories. The Miscellaneous category includes

• FortiOS Event Log
• Incoming Webhook
• Schedule

The FortiGate Automation Stitch will be triggered by a log entries related to Dynamic addresses. When a Dynamic address is updated by adding or removing an IP address, the FortiGate Automation Stitch will be triggered.

The Dynamic addresses setup in the previous step are updated when a VM with a specific tag and value is discovered or when a previously discovered VM with a specific tag and value no longer exists in the Azure environment.

• Tag: ComputeType Value: AppServer - updates the AppServers address
• Tag: ComputeType Value: DbServer - updates the DbServers address
• Tag: ComputeType Value: WebServer - updates the WebServers address

A Dynamic address is updated by adding or removing an IP address in the object. Either action creates a FortiGate Event Log, the event logs are named

• Dynamic address added
• Dynamic address removed

Task 2 - Create an Automation Trigger for each Dynamic Address - AppServers, DbServers, WebSevers

The configurations are presented as a combination of FortiGate CLI commands and screenshots of the configured object. All of the command blocks can be copied and pasted into the FortiGate CLI console.

1. Login to the FortiGate using the IP address and credentials from the Terraform output.
2. Click through any opening screens for FortiGate setup actions, no changes are required.
3. Click the CLI Console
4. Enter the following CLI commands to create an Automation Stitch Trigger for each Dynamic Address

• AppServers

  config system automation-trigger
      edit "AppServer Existence"
          set description "Tag ComputeType with value of AppServer updates route table."
          set event-type event-log
          set logid 53200 53201
          config fields
              edit 1
                  set name "cfgobj"
                  set value "AppServers"
              next
          end
      next
  end

• DbServers

  config system automation-trigger
      edit "DbServer Existence"
          set description "Tag ComputeType with value of DbServer updates route table."
          set event-type event-log
          set logid 53200 53201
          config fields
              edit 1
                  set name "cfgobj"
                  set value "DbServers"
              next
          end
      next
  end

• WebServers

  config system automation-trigger
      edit "WebServer Existence"
          set description "Tag ComputeType with value of WebServer updates route table."
          set event-type event-log
          set logid 53200 53201
          config fields
              edit 1
                  set name "cfgobj"
                  set value "WebServers"
              next
          end
      next
  end

1. View the configured Triggers in the FortiGate UI

   • Minimize “CLI Console”
   • Click “Security Fabric”
   • Click “Automation”
   • Click the “Trigger” tab

   

2. View WebServer Existence configuration in the FortiGate UI

   • Double-Click the WebServer Existence trigger

   In the CLI configuration the logid was set by specifying the logid number. The logid in the CLI is called the Event in the UI in the UI Clicking the “+” in the event field opens the “Select Entries” dialog, where log events can be searched and selected by name.

   

   The “Field filter(s)” for a log event are the logs fields and the value expected in the log field. In the trigger the Field filter is the log field cfgobj. Logs can be viewed in the UI, however, to view raw logs in the CLI, use the execute log command and sub-commands. An example of the event logs used in the trigger is shown below.

   

Task 3 - Automation Action

Create Complex Automation Stitch

A FortiGate Automation Stitch brings together a Trigger and one of more Actions.

The action is to build and send a Webhook. A Webhook is a way to send an HTTP request to a listening endpoint. The endpoint can then do something with the Webhook based on the HTTP method. FortiGate Webhook actions support several HTTP methods; DELETE, GET, PATCH, POST, and PUT.

The Webhook configured in this task uses the POST method. The HTTP POST method will utilize HTTP headers and the request body to send data to the listening endpoint. The listening endpoint was described earlier in the chapter describing Azure Automation. The Azure Automation Webhook (this is the listening endpoint) was created as part of the Terraform deployment. The Azure Automation Webhook is associated to the Azure Automation Runbook Update-RouteTable.

To summarize there are two Webhooks;

• Azure Automation Webhook listens for incoming requests and sends the request to the Azure Automation Runbook Update-RouteTable
• FortiGate Automation Stitch Action Webhook sends data in the form of an HTTP POST request to the Azure Automation Webhook

The data sent by the FortiGate Webhook action is sent (POSTed) to the Azure Automation Runbook Update-RouteTable where it is parsed and acted upon based on the sent data. Possible runbook actions are

• Update the Azure Route table rt-protected in the Resource Group USERXX-fgt-as-workshop by adding a host route
• Update the Azure Route table rt-protected in the Resource Group USERXX-fgt-as-workshop by removing a host route
• Return an error message indication that the passed data was incorrect or that the runbook was not executed via the Webhook

The FortiGate Automation Stitch action is triggered by a log entry related to Dynamic addresses, when a Dynamic address is updated by adding or removing an IP address. The Dynamic addresses setup previously are updated when a VM with a specific tag and value is discovered or if a previously discovered VM with a specific tag and value is no longer seen in the Azure environment.

The triggers setup in the last task can all utilize the same action.

Task 3 - Create Automation Action

1. Login to the FortiGate using the IP address and credentials from the Terraform output.
2. Click through any opening screens for FortiGate setup actions, no changes are required.
3. Click the CLI Console
4. Enter the following CLI commands to create an Automation Stitch Action that will send a Webhook to Azure

• There are two options to create the action

  1. Replace the values indicated below with the information specific to your deployment. The values can be obtained by running the following terraform commands in the terraform/azure directory - Refer to Chapter 1 Task 2 - Run Terraform

     • YOUR_RESOURCE_GROUP - terraform output
     • YOUR_WEBHOOK - terraform output webhook

  2. Use the contents of the generated FortiOS configuration file

     • terraform/fortios/fortigate_automation_action_cli.cfg
     • This file was created for this specific deployment when the initial terraform apply was executed.

The webhook URI contains a question mark (?) between the words webhooks and token. When pasting text into the FortiGate CLI question marks are removed, due to the question mark having special meaning in the FortiGate CLI.

config system automation-action
    edit "routetableupdate"
        set description "Update Route Table for MicroSegmentation"
        set action-type webhook
        set protocol https
        set uri "YOUR_WEBHOOK"
        set http-body "{\"action\":\"%%log.action%%\", \"addr\":\"%%log.addr%%\"}"
        set port 443
        config http-headers
            edit 1
                set key "ResourceGroupName"
                set value "YOUR_RESOURCE_GROUP"
            next
            edit 2
                set key "RouteTableName"
                set value "rt-protected"
            next
            edit 3
                set key "RouteNamePrefix"
                set value "microseg"
            next
            edit 4
                set key "NextHopIp"
                set value "10.1.1.4"
            next
        end
        set verify-host-cert disable
    next
end

1. View the configured Action in the FortiGate UI

   • Minimize “CLI Console”
   • Click “Security Fabric”
   • Click “Automation”
   • Click the “Action” tab

   

2. View routetableupdate configuration in the FortiGate UI

   • Double-Click the routetableupdate trigger

   

The Action fields

• Protocol - HTTP or HTTPS
• URL - the Azure Automation Webhook is entered into this field without the https:// prefix
• Custom Port - the port the Azure Automation Webhook is listening on
• Method - the HTTPS method
• HTTP body - the body of the POST request - in this request the body is formatted as JSON. The items %%log.action%% and %%log.addr%% represent the FortiGate event log fields from the log that triggered the action. These values are:
  • log.action - object-add or object-remove
  • log.addr - the IP address of the VM with the ComputeType tag
• HTTP header - additional header fields - these fields could also have been passed in the HTTP body

  • ResourceGroupName - the name of the Azure Resource Group containing the Azure Route table to update

  • RouteTableName - the name of the Azure Route table to update

  • RouteNamePrefix - a prefix for the routes managed by the Azure Automation Runbook

  • NextHopIp - the Next Hop IP Address for the routes managed by the Azure Automation Runbook

    • Ensure that a question mark (?) is placed between the words webhooks and token
    • Add a question mark is not present
    • Click “OK” to save the update

Task 4 - Automation Stitch

Create Complex Automation Stitch

A FortiGate Automation Stitch brings together a Trigger and one of more Actions.

Three FortiGate Automation Stitches need to be created, one for each trigger. All the stitches will utilize the same action. Each stitch is used to connect the trigger to one or more actions. The stitches created in this task each only have one action.

Task 3 - Create Automation Stitches

1. Login to the FortiGate using the IP address and credentials from the Terraform output.
2. Click through any opening screens for FortiGate setup actions, no changes are required.
3. Click the CLI Console
4. Enter the following CLI commands to create Automation Stitches to connect the triggers to the action.

• AppServers

  config system automation-stitch
      edit "routetableupdate-AppServers"
          set description "Update route table for App Servers"
          set trigger "AppServer Existence"
          config actions
              edit 1
                  set action "routetableupdate"
              next
          end
      next
  end

• DbServers

  config system automation-stitch
      edit "routetableupdate-DbServers"
          set description "Update route table for Db Servers"
          set trigger "DbServer Existence"
          config actions
              edit 1
                  set action "routetableupdate"
              next
          end
      next
  end

• WebServers

  config system automation-stitch
      edit "routetableupdate-WebServers"
          set description "Update route table for Web Servers"
          set trigger "WebServer Existence"
          config actions
              edit 1
                  set action "routetableupdate"
              next
          end
      next
  end

1. View the configured Action in the FortiGate UI

• Minimize “CLI Console”

• Click “Security Fabric”

• Click “Automation”

• Click the “Stitch” tab

  

1. View routetableupdate-WebServers configuration in the FortiGate UI

• Double-Click the routetableupdate-WebServers Action

  

The configuration is very simple; a single trigger is added and multiple actions can be attached to the trigger.

Task 5 - Enable Azure SDN Connector

Task 5 - Enable Azure SDN Connector

The completed Automation Stitch trigger will be when a log is recorded for the following events:

• Dynamic address added
• Dynamic address removed

These log events are recorded when a FortiGate Dynamic Address is updated by adding or removing an address. FortiGate Dynamic Addresses are updated when the conditions of the Dynamic Address filter are met.

The Dynamic address filters can utilize the data returned from the FortiGate Azure SDN Connector. The filters can match on several aspects of the Azure environment. The Dynamic address filters in this task will match on Azure Tags and Values.

The configurations are presented as a combination of FortiGate CLI commands and screenshots of the configured object. All of the command blocks can be copied and pasted into the FortiGate CLI console.

Enable and View the Azure SDN Connector

1. Login to the FortiGate using the IP address and credentials from the Terraform output.

2. Click through any opening screens for FortiGate setup actions, no changes are required.

3. Click “Security Fabric”

4. Click “External Connectors”

5. Toggle the enable button on the Azure SDN Connector, it will take at least 60 seconds for the SDN Connector to retrieve information from Azure.

6. Hover over “AzureSDN” <– The SDN Connector may have already discovered Azure Environment objects, if so follow the next steps to view them.

   • Click “View Connector Objects”
   • Scroll through discovered objects, the ones that the Dynamic addresses will use in the “Tag” group
   • Click “X” to exit the view

7. Double-Click “AzureSDN” to view the configuration in the UI

   

Notice that the switch “Use managed identity” is enabled. This allows the FortiGate to issue Azure Resource Manager API calls to read the Azure environment. The “Resource path” can also be enabled to scope the read requests to a particular “Subscription ID” and “Resource group”.

The Azure identity of the FortiGate has already been scoped to the Resource Group when the Contributor Role was assigned to the FortiGate during deployment.

View the FortiGate’s Azure Assigned Identity Contributor Role and Scope

1. Login to Azure Cloud Portal https://portal.azure.com/ with the provided login/password
2. Navigate to your Resource Group “USERXX-fgt-as-workshop”
3. Click “vm-fgt”
4. Click “Identity”
5. Click “Azure role assignments”

The Azure “Contributor” role has been assigned to the FortiGate’s associated Azure Identity, with a scope of the Resource Group “USERXX-fgt-as-workshop”. This means that any API request issued by the FortiGate Azure SDN Connector has all the privileges of the Contributor role but only on objects that are in the specified Resource Group.

View the FortiGate Dynamic Address Resolution

Now that the Azure SDN Connector has been enabled the WebServers Address should populate with a resolved IP address for a VM with the Tag ComputeType and the value Webserver.

1. View the configured Addresses in the FortiGate UI

   • Click “Policy & Objects”
   • Click “Addresses”

   

As part of the environment deployment by Terraform:

• A linux VM with the name vm-linux-2 was deployed
• A tag ComputeType with the value WebServer was added to the VM
• The VM data retrieved by the Azure SDN connecter matched the WebServers address filter
• The address object was populated with the IP address of the VM vm-linux-2

The red exclamation point near an address name indicates that the filter(s) for the address did not match anything.

1. View the Matched addresses in the FortiGate UI

   • Hover over the address name WebServers
   • Click the “View Matched Addresses” button

2. View an Address configuration in the FortiGate UI

   • Double-Click the WebServers Address

   

Task 1 - FortiGate Policy

Task 1 - Create FortiGate Firewall Policy

1. Login to the FortiGate using the IP address and credentials from the Terraform output.

2. Click through any opening screens for FortiGate setup actions, no changes are required.

3. Click the CLI Console

4. Enter the following CLI commands to create a FortiGate Firewall Policy “webserver2webserver”

   config firewall policy
       edit 1
           set name "webserver2webserver"
           set srcintf "port2"
           set dstintf "port2"
           set action accept
           set srcaddr "WebServers"
           set dstaddr "WebServers"
           set schedule "always"
           set service "ALL"
       next
   end

5. View the configured Policy in the FortiGate UI

   • Minimize “CLI Console”
   • Click “Policy & Objects”
   • Click “Firewall Policy”

   

6. View webserver2webserver configuration in the FortiGate UI

   • Double-Click the webserver2webserver Policy

   

Notice that the Dynamic address WebServers is used as both the source and destination.

Task 2 - FortiGate Route

Task 1 - Create FortiGate Static Route

1. Login to the FortiGate using the IP address and credentials from the Terraform output.

2. Click through any opening screens for FortiGate setup actions, no changes are required.

3. Click the CLI Console

4. Enter the following CLI commands to create a FortiGate Static Route “webser2webserver”

   config router static
       edit 1
           set dst 10.1.2.0 255.255.255.0
           set gateway 10.1.1.1
           set device "port2"
       next
   end

5. View the configured Action in the FortiGate UI

   • Minimize “CLI Console”
   • Click “Network”

   

6. View 10.1.2.0/24 static route configuration in the FortiGate UI

   • Double-Click the 10.1.2.0/24 Policy

   

Task 1 - Pings

Task 1 - Ping the linux VMs from each other

1. Navigate to the Azure Route table rt-protected

There may already be a host route for vm-linux-2 10.1.2.5/32 with a next hop IP 10.1.1.4, FortiGate port2. This route may be here because of the FortiGate Automation Stitch and when vm-linux-2 was deployed it was tagged with “ComputeType=WebServer”.

The other VM vm-linux-1 has the tag “ComputeType” but the tag value is set to “unknown”. The FortiGate Azure SDN Connector does collect this VM’s information each time a scan of the Azure environment is done, however, the Tag and Value do not match any Dynamic address. A FortiGate Automation Stitch is not triggered.

For the next steps two browser windows should be open to the Azure environment at the same time.

1. Navigate to each linux VM in a separate browser window
2. Scroll to the bottom of the left hand navigation
3. Click “Serial Console”

From each linux VM ping the other linux VM

1. Ping vm-linux-2 from vm-linux-1 - let the ping run even though there is no response
   • ping 10.1.2.5
2. Ping vm-linux-1 from vm-linux-2 - let the ping run even though there is no response
   • ping 10.1.2.4

Task 2 - Sniff

Task 2 - Sniff the linux VMs ping traffic from the FortiGate

1. Login to the FortiGate using the IP address and credentials from the Terraform output.
2. Click through any opening screens for FortiGate setup actions, no changes are required.
3. Click the CLI Console
4. Enter the CLI command to sniff the ping traffic between the two linux VMx
   • diagnose sniffer packet port2 'proto 1' 4 0 a

The output of the sniffer command shows:

• vm-linux-1 (10.1.2.4) is sending a ping to 10.1.2.5
• vm-linux-1 (10.1.2.4) is responding to a ping from 10.1.2.5

Two things to realize from this output

• vm-linux-2 (10.1.2.5) can send traffic directly to vm-linux-1 (10.1.2.4) because they are in the same subnet and there is no host route for vm-linux-1 in the rt-protected Route table because vm-linux-1 is not tagged as a WebServer
• vm-linux-1 (10.1.2.4) can only communicate with vm-linux-2 (10.1.2.5) through the FortiGate however, the traffic is dropped by policy because vm-linux-1 (10.1.2.4) is not in the WebServers Dynamic address.

Task 3 - Tag

Task 3 - Tag the Linux VM vm-linux-1 as a WebServer

1. Navigate to the VM vm-linux-1
2. Click the “edit” link next to Tags
3. Change the “ComputeType” value to “WebServer”
4. Click “Save”

Now that the VM vm-linux-1 has a tag ComputeType with a value of WebServer several actions take place

• FortiGate Azure SDN Connector will return the updated environment information to the FortiGate
• FortiGate Dynamic address “WebServers” will be updated with IP address 10.1.2.4
• FortiGate event log will trigger the FortiGate Automation Stitch to send a Webhook to Azure
• Azure Automation will send the FortiGate Webhook data to the Azure Automation Runbook
• Azure Automation Runbook will run and add a host route for vm-linux-1 to Azure Route table rt-protected
• Traffic will flow between vm-linux-1 and vm-linux-2

These actions take 2-4 minutes to complete. The FortiGate Azure SDN Connector scan every 60 seconds. Once the FortiGate Webhook is sent to Azure Automation the Runbook run is queued. When the Azure Automation Runbook completes the Azure Route table updates can take 1-2 minutes to take effect.

Updated Route table - there is a host route for both linux VMs, all traffic for these VMs must go through the FortiGate and match a policy

FortiGate Sniffer - there is bidirectional traffic for the pings

Linux VM Consoles

This concludes the workshop tasks, to explore further

• Update the ComputeType tag value to AppServer and DbServer
• Update the FortiGate Firewall Policy to allow AppServer and DbServer
• Create an Address Group with AppServers, DbServers, and WebServers
• Allow an AppServer to communicate with a DbServer but not with a WebServer
• and so on…