Today we’ll be showing you how to set up your own active defense infrastructure. One of our researchers gave a talk about Active defense a while ago and we wanted to share our setup, so that other people can try it out. This will be a series of posts, so stay tuned for more on this topic. If you already have cool ideas to add to our active defense setup, please let us know!


Before we begin building out this setup, do know that we are going to potentially harass dangerous people. We’ll try to act as vulnerable targets to lure attackers in our environment, so we can play with them instead of the inverse. Don’t start with active defense if you still have weak spots in your infrastructure. After they got shunned they might retaliate on those systems. If you want to play safe, start with a non-attributable system, e.g. a VMware instance from a cloud provider. We’ll be using just that to show this demo. That being said, it is a lot of fun and a great learning experience to see how adversaries work, let’s get rocking!


So, to lure in attackers, play with them and learn from them, we’ll need a few things:

  • Public IPs for them to connect on
  • “seemingly” vulnerable machines in a segmented network
  • A firewall to set up some basic network segmentation and to perform NAT (pfSense)
  • Reporting & monitoring tools, we’ll be using the ELK stack+ some fancy scripting.
  • A VPN to do administration of our setup

This post will focus on getting the infrastructure ready to go, so we can dive in with setting up the vulnerable machines in the follow up posts, as well as the reporting system.


We will be using one baremetal node with esxi on it and exactly one network connection, you can install this yourself, or just get a prepped one from sites like OVH or hetzner for a mere 50 euros per month. After install you should have something like this:

Pretty empty right? Before we dive into setting up our firewall, let’s configure some switches, two to be exact. If we check our virtual switches under Networking > Virtual switches, there should already be one: the default vSwitch0. This vSwitch provides the management console of VMware. Let’s go ahead and add another virtual switch named LAN, without any uplink.

Now let’s create some portgroups. Portgroups function like access mode ports on a switch: Untagged traffic goes in and gets tagged with a specific VLAN ID. We can use these portgroups to segment our data into separate vlans, and place VMs in a certain VLAN.

You can find portgroups on the tab left of the virtual switches. Let’s start by adding a WAN portgroup on the VSwitch0 with VLANID 0 and create a portgroup named “TRUNK” with VLANID 4095 on our LAN vSwitch. This VLANID is a bit special, as it basically means receive all traffic.

The TRUNK portgroup will only contain our PfSense FW instance, as this one will be used to route and tag all traffic. Here are some screenshots that will help you through this setup.


Now that we’ve finished setting up our switching infrastructure, let’s get on with setting up the firewall.

You can download the latest version of pfSense at, I’ll take the 64-bit CD Image to work with. The specs for the pfSense VM are:

  • 1 CPU
  • 2GB RAM (1GB minimum)
  • 16GB HD (8GB minimum)
  • 1 NIC with portgroup WAN
  • 1 NIC with portgroup TRUNK

I added a bit of RAM and disk space, since I have quite some resources, and I’d rather have my FW performing well and not having disk space problems at any moment in time. As soon as we have the reporting system up and running, we can stream our logs from pfSense to our ELK stack, so they don’t take up space on the VM itself. You can go through the screenshots to see the setup of the VM in detail.