Export Firewall Logs on VMware Cloud on AWS to VMware Log Intelligence and Splunk

This blog post will walk through how to export VMware Cloud on AWS Firewall logs to a SIEM like Splunk.

Most of my blog posts are driven by customer questions and one that has come up on several occasions is the requirement to log network firewall flows.

This is typically required for auditing, troubleshooting and security analysis purposes. I needed it myself recently to troubleshoot a connectivity issue in my own lab.

To export firewall logs from traffic traversing VMware Cloud on AWS firewalls, we need to send the logs via Log Intelligence:

VMware Cloud on AWS integrates with VMware’s Cloud Logging platform VMware Log Intelligence. VMware Log Intelligence is essentially our Logging-As-A-Service platform.

A very good post was previously written on this subject on the VMware Cloud blog – mine is more focused on exporting the security logs to Splunk.

Log Intelligence provides visibility into VMware Cloud on AWS NSX-T network packet logs. We can analyze and troubleshoot application flows through visibility into packets matching specific NSX firewall rules.

In practical terms, VMware Log Intelligence is another service that can be accessed over the VMware Cloud Portal (console.cloud.vmware.com).

On the Log Intelligence portal, simply enable “NSX-T Firewall Logs Collection” in Log Management – NSXT.

You can now go back to the VMware Cloud on AWS Console.

When you create a firewall rule (on any of the gateways or on the distributed firewall), you can simply enable the Logging on the firewall rule.

For example, if you wanted to capture traffic to your SDDC NSX Manager, just enable logging on the rule on the right-hand side (in the example below, the source is “Any” but obviously you can specify which source IPs you want to allow).

You will see logs appearing in VMware Log Intelligence:

When you drill down on some of these logs, you can see for example a packet sent from 172.30.0.177 (vRealize Network Insight Proxy on-prem) to the VMware Cloud on AWS vCenter on 10.56.224.4 over HTTPS (443). You will notice the Firewall Action (PASS) – we are allowing the traffic through.

Even more powerful is the ability to forward these logs to a SIEM (Security Information and Event Management), with Splunk being the most common and widely deployed SIEM.

I deployed a Cloud-hosted version of Splunk Enterprise Version 7.2.5.1 on an EC2 instance from an AMI in the AWS Marketplace. Installing it was fairly straight-forward for someone who’s never used Splunk before. Obviously you can deploy a Splunk elsewhere – on-prem or on VMware Cloud on AWS itself.

For Splunk to accept logs over HTTP/HTTPS from VMC, we need to first set up the data inputs and configure HTTP Event Collector. The instructions on the Splunk website were a good help.

The Splunk administrator simply needs to create a new token, which will be used for authentication. In our Splunk, the token value is e0b3fac1-4110-a51c-3d6ddccfc213.

Log Forwarding on VMware Log Intelligence requires the use of a Cloud Proxy (a virtual appliance, which Log Intelligence will communicate through to forward logs to a SIEM). The installation and configuration is really straight-forward. We already have deployed a Cloud Proxy in our lab to leverage VMware Cloud Assembly so I could just re-use it.

On the Log Intelligence portal, go to the Log Forwarding section, select Destination (On-Prem), select the Cloud Proxy and the Endpoint Type (Splunk) in my example.

The endpoint URL should be the Splunk collector (https://splunk-url:8088/services/collector) and make sure the Authorization header follows the model below (“Splunk API-token” where the API token is the one previously configured.).

You can forward all logs to Splunk – might be more than you actually need!

Or if you’re just interested in firewall logs, just export a subset of the logs with this:

Once set up, you will see how many events and logs are forwarded over to Splunk.

Make sure you allow traffic to the 8008 port to your Splunk (I had to allow it on my AWS Security Group) or the traffic will be dropped.

That’s it ! I know this post is a bit niche but some of our customers asked so it might be useful someday for someone. Thanks for reading.