Passing Decrypted Data to Other Tools

In my post on Enabling FortiGate SSL MITM inspection we deployed SSL inspection using the fortigate so that we can provide Fortigate integrated security to SSL encrypted traffic flows, but what if we would like to perform other analysis on this traffic? There are tons of tools out there, from network analyzers, IDS, SIEMs, etc. that will offer you the ability to inspect traffic out of band and analyze it, so you can look for various patterns, network flows, etc.

Fortigates, as of FortiOS ~6.0 offer you the ability to export a packet flow that has been SSL inspected by a firewall, which is what I am going to do in this post. Unfortunately I dont have hardware to plug into a SPAN port, and I want to inspect my traffic in a virtual machine so im going to use GRE enapsulation to send a decrypt SPAN to a Security Onion installation. If you arent aware of security onion, you should get familiar with it, it has a lot of REALLY cool features that are super useful for analyzing traffic flows.

Deploying Security Onion is a little outside the scope of this post but its not terribly hard if you follow the documentation and guides on the Security Onion Website. For this lab im just deploying a all-in-one VM based on the security onion ISO (version 16.04.6.6). I deployed it into my Proxmox VE hypervisor environment.

Because im using a VM, I can’t just plug a VM directly into a physical network interface on the FortiGate. To get around this limitation we can use GRE. ERSPAN is essentially SPAN data, eg read-only copies of a network port, encapsulated inside a GRE tunnel. Using this technique I’ve used wireshark as a live remote SSL decryption/packet sniffing engine, and let wireshark handle the GRE decapsulation since it understands nesting protocols.

As you see in this diagram, the client and server think they are having an encrypted conversation with each other, but the Fortigate is really just doing an MITM on the client, packing that data inside a GRE tunnel and forwarding it to our SecurityOnion installation running on a Virtual machine

Since FortiGates dont really have an “output ERSPAN” data button, we have to find another way to get our data to our VM. FortiGates treat GRE tunnels like just another interface, so we can reference the GRE interface in our SSL output.

How to Send live Data to your Collector (SecurityOnion/Wireshark)

1. Configure SSL inspection. Make sure your clients trust the certificate used by your FortiGate to intercept SSL/TLS. You can see an example and walkthrough of this on My Previous Post

2. Create your GRE tunnel. Make sure your GRE tunnel is pointing to your Packet data collector IP address.

   config system gre-tunnel
     edit "onion" 
       set interface "FG.int"
       set remote-ip "a.b.c.d" 
       set local-ip "w.x.y.z" 
     next
   end
   

   In the config example:

   • FG.int is your local fortigate interface that will be sending the GRE decrypt data
   • a.b.c.d is the ip address of your wireshark/security onion VM
   • w.x.y.z is the ip address of your fortigate’s “FG.int” interface.

3. Edit the firewall policy you want to send decrypted ERSPAN data for. Add set ssl-mirror enable and set ssl-mirror-interface ERSPAN options in your policy. When you add the ssl-mirror option you will get a HUGE disclaimer telling you that you are responsible for not messing this up, you are using this in good faith, etc. The ERSPAN in this example refers to the GRE tunnel we created above in step 2 In FortiOS 6.0 and 6.2 the configuration is done in the policy.

   config firewall policy
     edit <policynumber>
       set ssl-ssh-profile <ssl inspection profile>
       set ssl-mirror enable
       set ssl-mirror-interface 'onion'
     next
   end
   

   In FortiOS 6.4 we have SSL inspection profiles which we can use which allows us to pick which way we want to monitor traffic in, and if you want to monitor traffic sourced from the client, server or both. I ended up having to upgrade from 6.0 to 6.4 as i had issues getting the SSL decrypt working when the output was a GRE tunnel on FortiOS 6.0

   config firewall decrypted-traffic-mirror
     edit 'onion_mirror'
       set traffic-source both
       set interface 'onion'
     next
   end
   config firewall policy
     edit <policynumber>
       set ssl-ssh-profile <ssl inspection profile>
       set decrypted-traffic-mirror 'onion_mirror'
     next
   end
   

   In the config example above:

   • onion is the name of the GRE tunnel I created, pointing to my Security Onion VM instance
   • onion_mirror is the name of the SSL decrypt span policy I used in my FortiOS 6.4 firewall.

4. Configure your listener:

   • If you are using wireshark, launch wireshark, turn on your sniffer and set a BPF filter of proto 0x2f which will limit the traffic to only GRE encapsulated traffic, that way you wont see any captured data from anything other than inbound GRE/ERSPAN data.
   • If you are using SecurityOnion like I am, this is actually much easier than it used to be. Historically you had to load up the GRE kernel module in linux, then set Bro (now Zeek) to listen to the GRE interface, that way the linux kernel was de-capsulating your traffic. Now Zeek does all this work for you. Zeek understands GRE is an encapsulation protocol, decapsulates and then inspects the contents.