Table of Contents

Description

Each time I visit a potentially new customer, there’s always that moment after a sip of coffee, after a few whiteboarding events and heated technical discussions when the following question pops up:


“How do you manage this Multicloud environment ?”
“Isn’t this complex for my Operations Team ?"


If you had asked me this 5-6 years ago…I would have probably said yes.
I was there jumping into action, incidents in the middle of the night, pager alarms and zombie eyes after 4-5h of sleep and the rollercoaster just kept going.

The daily struggle to reduce configuration and administration headaches was something real. I used Bash scripts, Python, Ruby, a mix of various vendor tools and still lost a lot of time investigating each time what went wrong.


This is where in the last few years Terraform has come to the rescue and has provided a consistent way of defining infrastructure while at the same time making tracking of changes easy

(hint: Github/Gitlab + a CI/CD pipeline).


Sounds like a dream come true, right ? Not if you're restless like me and always want to see what's under the hood...

Why this article?

Terraform has evolved recently into the de-facto tool for provisioning Infrastructure, be it On-Premise or in the Cloud but for the curious it leaves a lot of questions unanswered…

What is really happening behind the scenes when I create an Aviatrix Distributed Firewall Policy on a Cloud GW with TLS Inspection and IDS ?

resource "aviatrix_distributed_firewalling_policy_list" "guac" {

  policies {
    name     = "App1-Prod-Internet"
    action   = "INTRUSION_DETECTION_PERMIT"
    priority = 6
    protocol = "TCP"
    src_smart_groups = [
      aviatrix_smart_group.app1-prod.uuid
    ]
    dst_smart_groups = [
      var.smartgroup_internet

    ]

    flow_app_requirement = "TLS_REQUIRED"
    decrypt_policy       = "DECRYPT_ALLOWED"

    port_ranges {
      hi = 443
      lo = 443
    }
    logging = true
  }

  policies {
    name     = "DENY-ALL"
    action   = "DENY"
    priority = 20000000
    protocol = "ANY"
    logging  = true
    watch    = false
    src_smart_groups = [
      var.smartgroup_any
    ]
    dst_smart_groups = [
      var.smartgroup_any
    ]
  }


}

What if I want to use Tufin or another Orchestrator that supports only API Integration.

Fear not, for each Problem I’ve learned that there’s always a solution.

You just have to find it.

BURP - no SSL can stop us :)

Say “hi” to Burp, the man in the middle proxy that sits on your laptop and intercepts all traffic that passes through it (Terraform providers will be in fact sending API requests in order to create the resources you specified. ).

How does BURP work ?

  • You first need to see what FQDN name your Terraform provider contacts (in my case this was the Aviatrix Controller FQDN)
  • Then second you add an entry in your /etc/hosts, on your laptop, mapping that FQDN to 127.0.0.1 (localhost)
  • You configure Burp to listen to port 443 on localhost
  • You configure Burp itself to resolve the DNS of your intercepted FQDN directly on the Internet (not rely on the /etc/hosts entry that points to localhost)
  • You run your Terraform and get the output from Burp (GET, POST, PUT requests and the BODY that you can then put into a 3rd party tool)

What and how to configure

Download Burp Community Edition

https://portswigger.net/burp/communitydownload

The community edition will not save your work so if you plan on using this for other purposes as well or on a regular basis, then I recommend looking into the paid version.

Configure Burp

First start it up as root, otherwise it won’t be able to listen to port 443 (ports lower than 1024 as a matter of fact):

sudo /Applications/Burp\ Suite\ Community\ Edition.app/Contents/MacOS/JavaApplicationStub

Then configure it to listen for HTTPs requests on localhost:

Configure your local /etc/hosts so that your Controller IP resolves to localhost (where it finds Burp listener):

127.0.0.1	controller.lab.mihai.tech

Configure Invisible Mode (no it’s not Jules Verne’s invisbile man I’m afraid):

This one will configure Burp as a Transparent Proxy.

Configure DNS resolution inside Burp for the intercepted FQDN to bypass your /etc/hosts.

If you don’t do this, then Burp will resolve the FQDN for itself using /etc/hosts thus resulting in a loop.

Burp gets a request for FQDN, resolves FQDN to localhost, gets again the request…

The Result - how it looks