Home Lab

This page is intended to be a high level look at the evolution of my home lab over time along with some of the lessons I've learn along the way. It's laid out in reverse chronological order with the latest changes listed first. It's not specifically designed to read as a how-to but feel free to reach if you have any questions or need help building something similar. I've made enough mistakes to where I can hopefully help someone else avoid a few.
- Build a space to perform threat emulation
- Gather host and network forensic artifacts and write logic to detect malicious activity
- Gain insight into engineering and maintaining infrastructure
- Stand up a Windows domain to get more keyboard time with Powershell and Active Directory



LAB 2.2 - CURRENT

COMPLETED TASKS:

  • Acquired TP-Link 8 Port Switch to mirror outbound traffic
  • Configured network monitoring (Zeek/Suricata) for:
    • In/Out Traffic
    • Queries to my internal DNS Server/Pihole
    • Traffic between hosts on virtual switches
  • Setup subnets for each functional group of machines
  • Zeek/Suricata running locally on Kali machine to listen on the VPN connection to HackTheBox and TryHackMe

LESSONS LEARNED:

  • Duplicate Traffic - Considerations need to be made to avoid capturing duplicated traffic from different locations in an environment
  • Configuring BPF filters to limit what traffic Zeek monitors is pretty straightforward once you have subnets defined for different portions of your environment.
  • Sensor Positioning Matters - Monitoring from an internal DNS to outbound makes it impossible to see what host is actually making the query. Grabbing the traffic from the other side of the DNS server tells you who is asking the questions. Not a new concept to me but a humble reminder.
  • DHCP Allocation Range - In order to change the IP allocation range of a DHCP server, you have to change the range of the gateway. The IP address of the DHCP server also has a CIDR range associated with it, make sure you update this to reflect the new range as well. (example: 192.168.1.53/24)

FUTURE PLANS:

  • Deploy Logstash server to enrich Zeek/Suricata Logs
  • Install Elastic Agent on endpoints to leverage Elastic Endpoint Security
  • Install Squid Proxy to Capture
  • Configure separate VLANS to segment traffic
  • Move mobile and IOT devices to guest wireless network

LAB 2.1 - JULY 2021

Looking to mature my monitoring of the environment by enabling security on my Elastic Stack and start ingesting data from my hosts.

COMPLETED TASKS:

  • Installed Metricbeats and Logbeats on most systems in the lab
  • Configured SSL encryption between Elasticsearch and Kibana and between the nodes themselves
  • Stood up two Windows Servers and two Windows 10 hosts for future domain

LESSONS LEARNED:

  • Monitor After Configuration Changes - After initial configuration, host logs were flowing to Elasticsearch correctly but I had ignored a few errors on service start. The underlying issue that I ignored generated a tremendous amount of syslog and journal entries. I only noticed this because metric beat reported a 10 percent increase in storage usage over a 30 minute period. Had I configured the machines and walked away without monitoring them first, I would have had 4 machines with completely full hard drives.
  • Configuration File Ownership Matters - After building out a filebeat configuration file, I used scp to push it out to the other hosts. This caused an issue because the config files were owned by the user I used to transport instead of the user that was running Filebeat (root). A simple chown solved this but it was a learning moment.
  • Configuring for Security is a Huge Burden - When I originally stood up my Elastic Stack all I cared about was functionality. My only measure of success was seeing data flow into the Kibana dashboards I had built. Revisiting these configurations to enable authentication and SSL was a considerable lift. I can absolutely understand how system admins and engineers don’t bother with it unless security professionals lay out a solid case for why it’s important.

LAB 2.0 - MAY 2021

From a logical perspective this step was relatively unchanged from the previous state of my lab. The major jump here was to a new hardware platform that allowed me to keep things running persistently without having to shuffle around resources. I picked up a used HP DL380p G8 Server (128GB ram, Dual Processors - 16 cores) with plenty of empty slots for future expansion.

COMPLETED TASKS:

  • Acquired server to support persistent environment
  • Configured ESXi on both the server and the workstation
  • Rebuilt Elasticstack Cluster and handful of VMs

LESSONS LEARNED:

  • Enterprise Component Compatibility - Enterprise hardware is very picky about the components that you plug into them. For example if you try to use non-HP drives in the DL380p, the system marks them as “OVERHEATING” and the system shuts down 10 minutes after start up. Getting non-HP brand drives (that I had already purchased) to work in this machine was a journey. Do you research first before assuming that things with “just work” together.
  • ESXi Data Stores - I had hoped that I could simply migrate my VMware workstation VMs over to ESXI by plugging in my ext4 formatted drives. Turns out ESXi uses a different format that acts as a data store. Rebuild everything which was great experience.
  • Custom ESXi Images - After many failed attempts at installing the based image of ESXi, I learned that there are customized ESXi images for servers that have required drivers and management software baked in.

LAB 1.2 - FEBURARY 2021

Expanded the Elastic Stack to a 3 node cluster to facilitate studying for the Elastic Engineer Certification. The data ingestion was less important at this point, I was more interested configuring the nodes to talk to each other and move data around.

COMPLETED TASKS:

  • Elastic Stack 3 Node Cluster
  • Installed Metric Beats on a few VMs

LESSONS LEARNED

YAML - YAML configuration files are incredibly finicky! Watch those spaces, quotes and brackets. Windows cmd text editor - I need to learn more about how to modify files within a windows system

Services/Peristance - When standing up monitoring or agents, it’s important to configure your applications in a way that they can survive a reboot.

Future Limitations - If I am going to have a persistent 3 node ES cluster, my current hardware isn’t going to support it alongside other VMs.

LAB 1.1 - NOVEMBER 2020

GOALS:

Primary Focus was to build an environment where I could tinker with Elastic products and study for the Elastic Engineer Cert

COMPLETED TASKS:

  • Installed Pihole on a Raspberry Pi

  • Configured single Elasticsearch + Kibana

LESSONS LEARNED

  • DNS/DHCP Configuration - In order to have your hosts use a new DNS server, you need to ensure that the DHCP server is handing out the right address for the requests. With Pihole, it just makes sense to let it take care of both DHCP and DNS and turn off both of these services from your home router.

  • Accidental Secondary DNS - The purpose of Pihole is to drop requests made to known add domains. If you aren’t careful about your configuration, your hosts may end up with valid secondary DNS servers. If this is the case it will:

    • Reach out to the PiHole, and get no response (ad blocked)

    • Fall back to the secondary DNS server and resolve that ad domain

    • Ad will load

LAB 1.0 - JULY 2020

When I originally set out to build a lab environment I just needed a machine with enough resources to run a few VMs. I found a refurbished HP Workstation (64GB Ram, Dual Processors - 24 Cores) that would have plenty of power to run a handful of VMs without impacting the performance of my daily system.

COMPLETED TASKS:

  • Installed Ubuntu on the workstation with VMware Workstation running
  • Setup the following VMs:
    • Windows 10 VMs
    • Kali Linux
    • Few SANS VMs