Home Lab 6

So recently I decided I needed to set up my blue team game. I've been leaning others in this area a lot in my career and am mostly just the guy who implements all the best practices and sets everything up without staying around for the day-to-day. Well, I figure a great way to build on my skills in a lot of areas is to start attacking my own Home Lab while also trying to detect my own attacks! Besides I've learned a lot since I setup my Home Lab and my habits have spawned certain requirements from my setup which do not exist today, it's time for a pivot! Here's what I want to achieve:

  1. Further segment my network for increased isolation between workload profiles
  2. Actually properly implement my firewall rules in pfSense
  3. Add Security Onion to provide SIEM, NIDS and HIDS.

What exists now

This is my existing network Topology 1 There are a few big issues with this setup...

Proxmox Hosts on WAN

My Proxmox hosts aren't behind pfSense, meaning it takes extra effort and care to manage and monitor their firewalls. These are also the most critical systems in my lab, they're the whole castle. If someone gets into either node of the cluster, the game is over I've been pwned! The issue is, I don't have a dedicated host for just pfSense so it takes extra effort to prevent the hosts from actually using the WAN network. When I first got everything setup I was just excited to get in and start playing and didn't put very much thought into the network topology. Making improvements in your network topology and security posture is always an iterative process, so here we are! What I'd like to do instead, is use PCI passthrough to let the pfSense VM completely control a the NIC carrying the WAN VLAN. Then pfSense can DHCP to a subnet created by pfSense on a separate VLAN trunked through my switch. Essentially from a network perspective, even though pfSense is running within Proxmox, the Proxmox host is behind pfSense! 2 This is also going to be of great use for a SPAN Monitoring line for Security Onion. Proxmox has some quirks with how it deals with Linux Bridge's, it acts more like a router than a Layer 2 switch. This causes some traffic to get filtered out by the bridge. For a monitoring connection, we do not want that. Not at all! We really can't have a false sense of observability that would be terrible.

Minimal Segmentation

I did go through the effort of at least not dropping all my devices onto VLAN1 and having a completely flat network. However, I didn't go quite as far as I should have and with some of my new requirements it's going to need some work. Right now, there are a few profiles of workloads in my LAN that really deserve a separate VLAN on their own. My media server setup for example is running an OpenVPN client on the host, potentially allowing leaks of traffic outside the VPN and it's downloading and serving fairly untrusted data so it should absolutely be as isolated as possible from the rest of my network. This increased segmentation means nothing without proper firewall rules, so we'll get to that don't worry. Here's what I want to get to to support my goals

+----------+------------------+----------------+--------------------------------+
| 1 COLUMN |     2 COLUMN     |    3 COLUMN    |            4 COLUMN            |
+----------+------------------+----------------+--------------------------------+
| VLAN #   |  Name            |  Subnet        |  Description                   |
|          |                  |                |                                |
| 10       |  LAN             |  10.10.0.0/24  |  Critical services (Gitea      |
|          |                  |                |                                |
| 20       |  Wifi            |  10.20.0.0/24  |  Access point for most devices |
|          |                  |                |                                |
| 40       |  Remote VPN      |  10.40.0.0/24  |  Remote connection access poin |
|          |                  |                |                                |
| 50       |  Security        |  10.50.0.0/24  |  Security Onion will get deplo |
|          |                  |                | yed here                       |
|          |                  |                |                                |
| 99       |  Isolated        |  10.99.0.0/24  |  A completely Isolated VLAN fo |
|          |                  |                | r malware analysis             |
|          |                  |                |                                |
| 100      |  Management      |  10.100.0.0/24 |  Management network where admi |
|          |                  |                | n interfaces can be accessed a |
|          |                  |                |                                |
| 101      |  WAN             |  10.101.0.0/24 |  Tagged WAN traffic from Acces |
|          |                  |                | s mode ports on switch         |
|          |                  |                |                                |
| 200      |  Third party VPN |  10.200.0.0/24 |  This subnet will be forced th |
|          |                  |                | rough a third party VPN provid |
+----------+------------------+----------------+--------------------------------+

Getting there

First I need to get everything ready for the outage I'm about to cause. My lab is going to lose it's WAN connection and I'm going to lose access to Wifi until things are mostly back up and running. First, I plugged in my management laptop and logged into the cisco switch. I double-checked that I could login to the proxmox nodes from here as well. Here's what I did to move around my VLAN's without having to serial port into a server.

  1. Shutdown all Proxmox QEMU VM's except pfSense
  2. Grant temporary access to Wifi to the management network
  3. From Wifi, create a second Management network (VLAN 100)
  4. Update both Proxmox hosts so their default gateway was on the new VLAN
  5. Shutdown pfSense
  6. Confirm I can access both proxmox hosts from an access port on the switch configured for VLAN 100
  7. From my management laptop, preform the remainder of the VLAN changes on the switch. This was the hardware configuration I wound up with: 3 My next battle was setting up PCI passthrough for the pfSense WAN connection and the SPAN Monitoring port for Security Onion. This wound up being enough of a struggle to warrant it's own separate blog, so you can check that out here if you're interested in how I did it. With that done, my hardware setup was actually complete. I'm finally ready to start configuring my workloads again, starting with pfSense. The initial configuration steps are straight forward, I simply had to re-assign all the network interfaces, bridges and VLANs. Then I had to re-declare the new subnets and DHCP ranges. I took the opportunity to reconfigure my static host mappings to the new subnets before those hosts boot. With this done, and nothing but an allow-all rule in all my interface firewall's my Wifi was working again, but the NAT wasn't, so I reconfigured my NAT rules and then that was all good now too. To test that everything was working as before, I started bringing up services that I knew were going to stay on the LAN in the LAN. I simply had to set a new VLAN tag in the interface assignment on each VM and boot it up. I already set their new static DHCP entries so it was all nice and smooth. With everything, aside from my media server, working as before it was time to move on!

Third party VPN VLAN

I setup an isolated pfSense interface routed through a remote VPN for my media server. This ensured that all traffic leaving that node (including DNS) was ran through the VPN, while not forcing the rest of my network to also go through it. Most people would run their entire network through the VPN, but I didn't want to impact my normal devices at all and just wanted an area where I could quickly access the VPN if needed, and a place to relegate services that I knew were emitting traffic that my ISP may not entirely enjoy.

Security VLAN

The primary goal of all this was to setup a Security Onion instance so I can start fine tuning my firewall, securing my hosts and eventually doing attack/defense simulations on my own network. I already have the VLAN in place, so all I really had to do was Install Security Onion in a new VM! They provide the image, and the installation is pretty streamlined so it was very easy. The difficult part of all this is simply ensuring you have sensors in the right places and that your SPAN port is in the right part of your network to observe the traffic you care about. Once I got it installed, I did a basic observability test on my network. I systematically sent requests from hosts within each vlan to another to ensure I could observe all the traffic. 4 I'm pretty new to Security Onion so I started from the built-in connections Dashboard I found there: 5 And then to Hunt to run OQL queries to look for source/destination of the hosts I was testing from: 6

Next Steps

Next It's all about tuning rules in security onion and tuning my firewall rules! You'll hear from me soon about many things I've learned throughout this, and a little later hopefully about my fun times attacking and defending my own network!