Having your own home lab is great! Building and breaking stuff in your own environment is also a good fun. I’ll use my lab to try things out and to gain more understanding of different attack methods and how to mitigate those. In this series I’ll walk you through how I built my own lab.

Goal

#

I want my lab to have:

Servers
* 1-2 Domain controllers (Windows)
* 1 File server (Windows)
* 1 CA (Windows)
* 1 SIEM (Linux)
* 1 Webserver (Linux)
* 1 DBserver (Linux)

Clients
* 1 PAW (Windows)
* 2-10 client computers (Windows + Linux)
* 2-1000 users

Network
* Firewall
* Segmentation
* Mirroring for SIEM

Lab network should mimic real world organization with basic network services and a proper network segementation. I don’t want to harden my lab to the maximum since the whole purpose of this lab is to practice different attack scenarios and how to detect them.

OWN HARDWARE vs. CLOUD

#

Deciding where to build test lab is the first decision I’ll need to make. I have been in the industry for quite a long time and have all kinds of equipment laying around. However, I wanted my lab to have proper SIEM and other services which required so much resources that running lab within a laptop or two didn’t seem possible or reasonable.

Second option was using the cloud and build my lab there. Cloud is a good and cheap option if you want play with your lab few hours or days at time, but running this much services on cloud could easily become very expensive, so cloud was ruled out.

In the end I decided to rent a server just for this purpose.

Budget

#

• Server ($45/month)

  • 8 CPUs
  • 64GB RAM
  • 2 x 512GB SSD w/RAID Mirroring
  • 1 public ip-address

• Domain name ($15/year)

Virtualization

#

Host server came with Debian preinstalled. I just needed to install Proxmox and was good to go. Proxmox install couldn’t be much simpler than it is. You browse to Proxmox website and either download an ISO-file or add their software repository to your existing Debian system.

Install guide

Only hickup during the setup was that my hosts /etc/hosts file kept changing on every server reboot. I fixed it by setting the immutable bit to that file. Immutable bit prevents file to be modified, deleted or renamed.

 $ sudo chattr +i /etc/hosts

There probably is more eloquent solution to this problem, but this one worked for me. Now we have our hosting platform all setup.

Now I just browse to https://my.public.ip:8006, enter my credentials and I’m good to go.

Easy :-)

Networking

#

My host has only one public ip-address available and I didn’t want to buy any additional addresses. If you want to run public services on your server, then it might be a good idea to have at least two addresses, so you can separate management traffic from the other traffic.

My lab needs to connect to internet for updates, ntp time, dns etc. but other than that, there shouldn’t be any need for lab machines to connect to the internet. After initial setup is done I will install proxy server and limit available services to the minimum.

Public ip-address is currently assigned to host interface, so I create a linux bride and assign that address to that interface. I also need to add internal bridges, at this point I don’t add VLAN-ids to any of them.

Pfsense will act as my lab firewall and gateway, it will also provide DHCP-service to lab. To ease this setup, I add another network between my host (vmbr0) and my internal network (vmbr5). Pfsense will have “public” address on vmbr1 network and internal network on vmbr2. Both vmbr2 & vmbr2 use private ip-ranges so I’ll need to add route to my host, so firewall can communicate to internet.

$ sudo ip route add 10.26.10.0/24 via public.ip

For the inside part of the lab network I’ll use OVS Bridge instead of a classic Linux bridge. This allows me to use port mirroring and capability to monitor all network traffic within my lab.

$ sudo apt update
$ sudo apt install openswitch-switch

Here is my networking plan.

Networks:

• vmbr0 (Internet)
• vmbr1 (fw int0)
• vmbr2 (fw int1)
• vmbr5 Port Mirror

My internal lab network will have limited internet access but no incoming traffic is allowed. Lab servers will use outdated and vulnerable releases, so it is a good idea that lab is not reachable from the internet.

Ok, that’s it. Hopefully you got something out of this and I’ll see you in next post.