Deploying Security Onion on Amazon Web Services (AWS) using Virtual Private Cloud (VPC) Mirroring
Amazon announced this week a feature which I’m sure many Cyber Security professionals have been waiting for a while — the ability to mirror the network traffic of a Virtual Private Cloud (VPC) and direct it towards a single network interface. This is something we’ve had the ability to do in on-premise environments for many years, and when combined with network monitoring tools, can be used to generate a security analyst’s favorite data source - Packet Capture.
Now that Amazon has enabled this feature, you can deploy sensors in your cloud environments to capture, analyse, and alert on suspicious network activity, not just at your gateways, but across your VPC (EDIT: Not entirely true. Amazon, you promised so much!). In an on-prem environment, this would typically require choke points in the security architecture to achieve the same level of monitoring.
There is one primary caveat — The hosts you are monitoring must be Nitro instances. What does this mean? Well essentially, you need to make sure you use a relatively new generation of EC2 instances. The hardware supporting these contains Amazon’s new Nitro card which contains among other things, NVMe storage and improved network connectivity. They’ve been around since 2017, and the full list of instance types is available on Amazon’s technical documentation. If you don’t have an instance that is Nitro enabled, you can upgrade your instances to these using the default AWS instance upgrade processes.
This is a feature I’ve personally been waiting for a while, and so I wondered if I could implement my own sensor on an AWS instance, rather than using one of the partner products AWS has beta tested the functionality with. Insert, Security Onion.
Security Onion is an open source Linux distribution designed to be deployed as a network monitoring sensor. It comes with a host of open source tools such as Suricata, Zeek, Elasticsearch, and that stalwart of packet analysis, Wireshark. It’s easy to deploy (although a little trickier in this instance, more on that later), and can provide you with a quick and effective network monitoring tool to build your capability off of.
After some fruitful discussion, @alecjlangford and myself set off to install, configure and test an implementation of Security Onion using the mirroring feature to monitor a test AWS VPC. I’ve detailed the steps below for those who are also keen to take advantage of this new feature.
- Firstly set up your VPC. For Alec and I, we used the VPC Wizard in US North Virginia as both of us house our normal AWS workloads in Asia Pacific Sydney, and unfortunately mirroring is not available in that location yet. Nothing special is required for your VPC configuration (other than mirroring which will come later), so if you’re deploying a sensor in an already mature AWS architecture, you can skip this step.
- Next deploy an EC2 instance running Ubuntu 16.04. This is where the trickiness comes in — in a normal on-premise environment you could use the Security Onion ISO, but that’s not possible on EC2. Make sure you configure the instance with 2 network interfaces — one for management, and one for receiving the mirrored traffic. You will have to assign an IP address for the mirrored traffic network interface, but we’ll disable this at the operating system level. We chose to use an m5.large for our sensor (as this meets the minimum hardware specs), but you can base your own deployment on the hardware sizing guide provided by Security Onion depending on the size of your environment.
- Once you’ve deployed the EC2 instance, it’s time to configure it. Thankfully, Security Onion provide instructions on how to install their sensor on top of a traditional Ubuntu 16.04 installation. For this test case we’re using their “Quick and Dirty” instructions, but if you’re deploying this in anger I’d recommend you use their “Production Deployment” instructions. Configure the monitoring interface as your second network interface.
- Now it’s time to configure AWS to mirror traffic from the VPC into the network interface of the sensor. To do this, you need to navigate to the VPC control panel, and create a target, a filter, and a session. The target is fairly simple, select the network interface you want to use as the destination for the mirrored traffic.
- Filter time! I setup a filter with two rules, inbound from 0.0.0.0/0 to 0.0.0.0/0 and outbound to the same ranges (make sure you do this or you won’t see any traffic at all. Rules are not optional really). This will allow me to see all traffic going to the VPC. You can cut this down if you’d like depending on your use case — perhaps you have a VPC which is VPN connected to your corporate environment, in which case you may want to exclude that traffic.
- Finally, time for the session. It’s at this stage we realised you can only mirror a single network interface, to a single monitoring interface in a session, and you can only have 3 sessions per target address. Bollocks. Less useful, but still can be helpful. We defined the session from the external network interface of the NAT gateway and the monitoring interface. You don’t need to configure anything beyond the defaults here unless you want to.
- Now we find out if it’s working. Login to the Security Onion sensor, and see if you can see packets coming in to the monitoring interface through tshark. You will also be able to see it through the Elasticsearch interface, and if there’s any malicious activity against your VPC you’ll hopefully see it there too.
Voila! We have a working network monitoring sensor. Obviously, there’s a lot here that can be improved and optimised — using Suricata / Snort as an Intrusion Detection System (IDS), changing the rules on the capture interface, deploying this on both the internal and external network interfaces of your gateway to ensure that things are blocked appropriately. There’s a lot of material available about configuring the capabilities of Security Onion.
Overall, I’m honestly a little disappointed with this new feature from Amazon. I don’t see much particular difference between deploying a virtual router in a VPC, and using that to capture the traffic flowing through it. If you already have a feature capable router (Palo Alto NGFW for example), this is fairly easy to setup. I think where this will come into it’s own is capturing the traffic traversing between VPCs, which Amazon has said is possible but we haven’t tried yet. Maybe once Amazon bring this feature to Asia Pacific Sydney, Alec and I can peer our labs and test out the functionality.
I hope you’ve found this article useful, the next post will hopefully be on how I’ve moved my homelab from an on-prem (in-garage!) VMware cluster to a combination of AWS and Ubiquiti equipment to make communications seamless between the two.
