Building your own active defense network: Part one

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!

Get your stuff together!

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!

The ingredients

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.

VMWare switching setup

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:

One freshly installed VMWare, coming right up!

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.

Setting up the firewall

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.

Let’s upload the ISO to the datastore, mount it to the VM and power on the VM. PfSense should automatically boot into setup mode. Setup is pretty straightforward, just go with the default options or customize to your needs (and keyboard layout).

After the reboot pfSense will go into config mode. You’ll need the MAC addresses from your two interfaces, as autodiscover doesn’t always work, especially with vmxnet3 type interfaces. Luckily that info can be found on the virtual machine summary page. Configure your WAN and LAN interfaces, but don’t configure any VLANs just yet, it’s way easier from the web interface.

Setting the public address

After this step it gets a little tricky, with OVH ( my provider) we need to provide a MAC address to bind a public IP to, so in my case I provide 00:50:56:03:2c:57, the MAC address from my WAN interface. Next we’ll have to configure the public IP in pfSense (using option 2 set interface address). This depends a bit on your provider. In my case I ordered one IP, so this was a /32. My default gateway is the vmk0 address with .254 at the end. Since my default gateway is not in any configured ranges, I’ll have to configure it via CLI with the following two shell commands and make these settings permanent later on. You can drop into a shell by choosing option 8 in the pfsense CLI menu:

route add -host <<vmk0 gateway>> -iface <<WAN interface>> # add route so it is known what interface to use
route add default <<vmk0 gateway>> # add a default gateway for outbound traffic

After that, give the gateway a ping, if that works, try for example. If those come back, perfect. We have internet connectivity! As said, this is all provider specific, if you have issues with finding this one out, don’t worry. Feel free to drop us a comment, we’ll do our best to help you out ?

Get the web configurator working

Next up, we want to use that fancy web interface pfSense ships with. Since it’s a security product, by default it won’t allow connectivity to the web interface from the WAN side, because it will start in http mode. You’ll first have to set up certificates to get things going in a secure way. We’ll start insecure, change the password and swap to HTTPS. First whitelist your personal source IP with the following CLI command:

easyrule pass wan tcp <<my public IP at home>> <<my remote WAN IP>> 80

To enable https access on WAN for everyone, execute:

easyrule pass wan tcp any <<my remote WAN IP>> 443

Now we can access the pfSense webconfigurator over http. I advise changing your password from the default “pfsense” to something a little more difficult, and do it again after swapping to https, as someone might have seen your password flying by in cleartext the first time.

To change the portal to https go to system > advanced, change it to https and it will automatically pick a self-signed certificate (if you have a DNS record available, you can just as well go for a LetsEncrypt cert as described here: )

Save it, and you can connect over https to your firewall, great success! We are now ready to finalize our initial network setup.

The playground

Our aim is to set up three active defense systems in three different zones, so that an attacker can’t link one setup to another. We’ll use pfSense to route and firewall these zones, and only allow connectivity to our reporting range, which will host the ELK stack. To administer the environment, we’ll set up an OpenVPN that will tunnel all traffic through our firewall.

The network.
The network.

As you can see, we’ll use the VLAN numbers to identify the ranges, which makes it easier to remember ( this is no obligation, choose different ones if you like).We’ll start with adding the VLAN info in pfSense: go to Interfaces > Interfaces assignments. Choose the VLAN subtab and add the VLAN information for each VLAN. Make sure to create them on your LAN interface, vmx0 in my case. Some screenshots below to guide you once more:

The result should be something like this:

Let’s first finish our layer 2 part by adding portgroups that reflect these VLANs in VMWare on the LAN vSwitch. Head back over to your esxi console, go to networking > portgroups and add them:

Now let’s go back to the pfSense interface, straight into interface assignments once more and you’ll see Available network ports. These are our freshly created VLAN interfaces that need layer 3 info to work. Start by adding them all and press the save button. They’ll show up as OPT1-4, but we’ll be able to change that in a moment. Click OPT1 to get to the details menu of that interface, and change it to the defined network ranges in the diagram:

Enable the interface, set the name to something logical (like Zone A in this case) and choose static IP as IPv4 configuration type.

PfSense will play gateway for each of these zones, I’ll be using the “.1” addresses of these ranges, but you can also go ahead and pick the .254 or something else. Select /24 subnet mask. Save and apply changes. Rinse and repeat for all 4 interfaces, and that’s it!

Routing is by default enabled between all zones, but as long as there are no firewall rules that allow traffic, nothing is getting through.


We’ve concluded the first part of our little active defense network setup. Now that we have our base infra laid out we can start expanding. The next episode in this series will focus on setting up an openVPN tunnel to administer our network, set up an ELK stack and define a few simple firewall rules to get updates for our future honeypots and allow syslog forwarding. Until next time!