ERSPAN, or Why I Can't Wait for Bro 2.6: Part 1

March 14, 2017 | Risk Management | By Brian Dulany |
Bromantic or not, you have to admit that ERSPAN makes life easier.

I've said it before: I'm a huge BroMantic. Bro makes my life easier in so many ways. One thing I love using it for is building a network baseline of critical hosts. However, now that virtualization is implemented practically everywhere, getting access to traffic that occurs only within an ESXi cluster (especially when my sensor exists outside of the cluster) is very difficult.

The Problem

Take a look at the diagram below. You'll notice that unless the MSSQL server is communicating with a host outside of it's ESXi host, traffic will never make it to the sensor. Traffic between the SP-WFE and the MSSQL servers will only be visible if they are configured to run on different ESXi hosts. This is especially problematic when High Availability is enabled on the cluster. At any time the virtual machines can migrate between virtualization hosts within the cluster, resulting in only a partial collection of network data.

If MSSQL server is communicating with a host outside of it's ESXi host, traffic will never make it to the sensor.

The Solution

Starting with vSphere 5.1, administrators have the ability to configure ERSPAN on distributed virtual switches (DVS). Using a DVS allows administrators to ensure that regardless of which host a virtual machine is running on, the virtual switch that the VM is connected to never changes. With the introduction of ERSPAN, all network data that passes through the DVS will be encapsulated in a GRE tunnel and forwarded to a remote IP. Security teams can now send network traffic to a sensor located anywhere on the network, without the need for network taps or standard SPAN ports.

Starting with vSphere 5.1, administrators have the ability to configure ERSPAN on distributed virtual switches (DVS).

Current Support

While the current release version of Bro (2.5) does not support ERSPAN at this time, you can take full advantage of the protocol by downloading the latest development version from github and compiling it from source. Once Bro 2.6 is released, ERSPAN support should slowly start making its way into {insert your favorite blue team distro}'s repositories.

Getting ERSPAN Support NOW!

Start off by cloning the latest from the Bro repository:

Start off by cloning the latest from the Bro repository.

Move to bro directory and configure, make, and sudo make install:

Move to bro directory and configure, make, and sudo make install.

That was easy…
To make things easier, feel free to copy and paste the lines below:

git clone --recursive git://git.bro.org/bro
cd bro
./configure
make
sudo make install

The Bro website has more tutorials to get you up and running. Check out these links for more details:

  • https://www.bro.org/sphinx/install/install.html
  • https://www.bro.org/sphinx-git/install/guidelines.html

To demonstrate the difference between the two versions, I created a pcap containing ERSPAN data. If your version doesn't support ERSPAN, you will only see a single entry in the weird.log for an unknown GRE protocol.

Old Bro - As seen in SecurityOnion:

Old Bro as seen in SecurityOnion

If your version of Bro DOES support ERSPAN: a tunnel.log will be created, connections that were encapsulated within the ERSPAN session will be fully recognized by Bro and populate the conn.log.

New Bro - As configured from source:

New Bro as configured from source

In summary, the @Bro_IDS team has done an amazing job on this tool. I'm very grateful for all it's features and especially appreciate the hard work they put in to support ERSPAN.