Homelab

My HomeLab: A Dive into Cybersecurity

Welcome to the world of my HomeLab, where cybersecurity experimentation and hands-on learning come to life. In this blog post, I’ll take you on a journey through my personal lab setup, showcasing the tools, techniques, and projects I’m using to stay ahead in the ever-evolving field of cybersecurity. Whether you’re a seasoned professional or just starting out, you’ll find insights into practical applications, challenges faced, and the innovative solutions developed within the confines of my HomeLab.

1. Introduction: Overview of the Cybersecurity Homelab

My cybersecurity homelab simulates real-world environments to explore penetration testing, defensive security measures, and system monitoring. The lab includes virtualization setups, the use of Kali Linux for offensive testing, Ubuntu server configurations for defensive measures, and the implementation of SIEM solutions to monitor network traffic and threats.

2. Lab Architecture and Virtualization Setup

• High-level Overview: As per the picture, the architecture show 3 clients with each their own purpose:

  • Kali: The purpose is penetration testing, on external sources such as THM, HTB, and OWASP's juice shop. But also internally testing the ubuntu 1 and 2 defensive measurements.

  • Ubuntu1: Is the main server that is a practice run in both server setup, network management.

  • Ubuntu2: Is a SIEM like server, that uses ubuntu1 as a client, to network log and monitor incoming and outgoing data, using splunk and nessus.

  • Virtualization Platform: VMWare as i was most comfortable with this virtualization tool

  • VMs Setup: Each client has a set of firewall rules, and has a zero trust policy, except the traffic from ubuntu 2 to 1 which is white listed. Also using the principal of least privilege.

  • Virtual Router: Using Juniper VSRX to secure the outer perimeter, acting as a gateway

3. Offensive Security with Kali Linux

• High-level Overview: I use Kali Linux as my penetration testing VM. Using a lot of tools like Nmap, Metasploit, Burp Suite, and other built in scripts.

• Low-level Details: Writeups are currently being written in the "Cyber Security" section:

  • Reconnaissance: Is one of the five stages of pentesting, in which we scan the internal workings of a server / company / client.

  • Exploitation: We find a vulnerability from our recon stage, and try to exploit.

  • Post-Exploitation: Once we're in thanks to the previous stage, it's time to gain access and privileges in the system, trying to laterally / vertically improve our posistion.

4. Defensive Security: Ubuntu Server Setup

• High-level Overview: The Ubuntu server in my homelab serves as a primary defensive layer. It hosts critical services while enforcing strong security measures to safeguard against potential attacks. I configured the server with firewall rules, Intrusion Detection Systems (IDS), and system hardening techniques to emulate enterprise-level defense. This setup protects services like Apache, SSH, and others by mitigating vulnerabilities found during penetration testing with Kali Linux.

  Firewall Setup (UFW Configuration):
  

  • The Uncomplicated Firewall (UFW): is configured to control inbound and outbound traffic. The server allows SSH connections only from trusted IP ranges and blocks all unused ports.

    • Firewall Setup:
      

      Purpose: This configuration ensures that only authorized IP addresses can access critical services like SSH, while the web server (Apache) is publicly accessible for legitimate traffic. All other inbound connections are denied to minimize the attack surface

  • Intrusion Detection:

    • I deployed Snort as an IDS to monitor network traffic for suspicious activity. Snort analyzes incoming and outgoing traffic, detecting any potential attacks such as port scanning, brute-force attacks, or malicious payloads.

      Purpose: Snort provides real-time alerts for any anomalous network behavior, allowing me to detect and respond to potential breaches.
      

    • System Hardening:
      I applied several system hardening techniques, including:

      • SSH Configuration: Disabled password-based authentication and enforced key-based login to secure remote access.

    • File Permissions: Restricted permissions on critical system files and directories to prevent unauthorized access.

    • User Role Separation: Created non-privileged users for routine tasks to reduce the impact of any compromise, adhering to the principle of least privilege (PoLP).

• Low-level Details: Services Running on the Ubuntu Server:

  • Apache Web Server: Hosts a mock website for simulating real-world web traffic. Configured to only serve secure content via HTTPS, using a self-signed SSL certificate.

  • SSH: Configured with key-based authentication and restricted root login.

• Defensive Measures and Vulnerability Mitigation:

  • During penetration testing with Kali Linux, I discovered an exposed SSH port and weak password-based authentication. I mitigated this vulnerability by restricting SSH to key-based authentication and limiting access to specific IP addresses.

  • The Snort IDS identified multiple port scan attempts from the pentesting VM, allowing me to create firewall rules to block repeated offenders.

By securing the Ubuntu server with UFW, Snort, and hardening techniques, I ensured that only legitimate traffic could reach critical services, while proactively detecting and mitigating any potential threats.

5. SIEM and Log Monitoring (Splunk / ELK Stack)

• High-Level Overview: In my homelab, I implemented Splunk as a SIEM (Security Information and Event Management) solution to monitor logs from various sources, including my Kali Linux pentesting VM, Ubuntu server, and network traffic. Splunk is responsible for log aggregation, threat detection, and real-time alerting. The goal is to simulate how enterprises monitor their infrastructure for potential security incidents.

  Splunk enables me to visualize key security metrics, identify suspicious activities like brute-force login attempts, and analyze the overall security posture of the network in real-time.

  • Splunk Setup: I configured Splunk to collect and index logs from multiple sources:

    • Ubuntu Server: System logs (e.g., /var/log/syslog), firewall logs (UFW/IPTables), and SSH login attempts.

    • Kali Linux: Logs from penetration testing activities.

    • Network Traffic: Captured using Syslog and forwarded to Splunk for monitoring.
      

    Splunk was set up to automatically ingest logs using the Universal Forwarder on the Ubuntu server and Syslog for network traffic.

  • Dashboard Creation: I created a custom dashboard within Splunk to track:

    • SSH Login Attempts: Displaying successful and failed login attempts over time.

    • Network Traffic: Visualizing inbound and outbound traffic to detect unusual spikes or anomalies.

    • Firewall Alerts: Monitoring UFW logs for blocked IP addresses, indicating potential attacks like port scans or brute-force attempts.
      

    Example Dashboard Widgets:

    • Line Chart: Showing the number of failed SSH logins over time, helping identify brute-force attempts.

    • Pie Chart: Categorizing the types of traffic by protocol (TCP, UDP) to detect unusual patterns in network traffic.

  • Alerting: I configured alerts in Splunk to trigger when specific thresholds are met:

    • Brute-force Detection: If there are more than five failed SSH login attempts within a minute from the same IP address, an alert is triggered. This could indicate a brute-force attack.

    • Network Anomalies: If inbound traffic suddenly spikes above normal levels or if traffic comes from suspicious countries, an alert is sent to notify of potential DDoS or reconnaissance activity.

    • Email Notifications: TBA.

• Low-Level Details:
  

  • Types of Logs Monitored:

    • System Logs: Tracking general system events, user authentication logs, service failures, and other events from /var/log/syslog on the Ubuntu server.

    • Firewall Logs: UFW logs from the Ubuntu server, specifically monitoring for blocked IP addresses and port scanning attempts.

    • SSH Login Attempts: All SSH authentication events, including failed and successful login attempts, sourced from /var/log/auth.log.

    • Network Traffic Logs: Inbound and outbound traffic data from various sources to detect anomalies.

  • Specific Alerts and Dashboards:

    • Brute-Force Attack Alert: The alert detects multiple failed login attempts from a single IP address within a short timeframe, signaling a possible brute-force attack.

    • Suspicious Traffic Alert: This alert monitors network traffic for abnormal spikes or traffic coming from blacklisted IP addresses or geolocations outside of regular patterns.

    • Custom Dashboards: I built dashboards to give an at-a-glance view of the system's security status, such as visualizing blocked IPs, login attempts, and traffic anomalies.
      

  Practical Outcome Example:

  During a simulated attack from the Kali Linux VM, Splunk detected multiple failed SSH login attempts from the Kali IP address within a minute. I responded by reviewing the logs and identified the attacking IP, which I blocked using UFW on the Ubuntu server. The incident was visualized in the dashboard, showing the spike in failed login attempts, providing real-time insight into the attempted breach.

  This practical experience demonstrated my ability to configure and respond to security events using Splunk, showcasing my knowledge in log management, SIEM solutions, and active network defense.

  • Splunk Setup: How you’ve set up Splunk to collect logs from various sources (e.g., Kali, Ubuntu, and network traffic).

  • Dashboard Creation: Show how you’ve built dashboards to visualize network activity, detect anomalies, and respond to potential threats.

  • Alerting: Discuss the rules and alerts you’ve set up for real-time monitoring.

• Low-level Details: Dive into specific configurations:

  • The type of logs being monitored (e.g., system logs, firewall logs, SSH login attempts).

  • Specific alerts or dashboards you’ve built to detect certain types of attacks (e.g., brute-force attempts, suspicious traffic).

6. Network Segmentation and Security (Practical Network Management)

• High-Level Overview: In my homelab, I implemented network segmentation to simulate real-world corporate environments. Each segment is isolated to restrict access between systems, preventing potential attackers from moving laterally after compromising one machine. This network setup is crucial for protecting high-value assets and limiting the damage from breaches.
  

  The network is divided into different segments:

  1. Penetration Testing Segment: Hosting the Kali Linux machine for offensive security testing.

  2. Production Segment: Hosting the Ubuntu Server with services like web servers and databases.

  3. Monitoring Segment: Hosting the Splunk/SIEM infrastructure for log monitoring and threat detection.
     

  By isolating these environments, I can simulate real-world attack scenarios and monitor how attackers attempt to traverse the network.

  
  

  • Virtual Network Configurations: Each VM in the homelab is placed in its own subnet to represent distinct departments or functionalities within a typical enterprise environment. Here's the basic segmentation structure:

    • Penetration Testing Subnet: 192.168.10.0/24

    • Production Subnet: 192.168.20.0/24

    • Monitoring Subnet: 192.168.30.0/24

    Network Segmentation Strategy:

    • The Kali Linux machine is placed in the Penetration Testing Subnet to simulate attacks from an external attacker.

    • The Ubuntu Server running web applications and services resides in the Production Subnet.

    • The Splunk instance resides in the Monitoring Subnet, collecting logs from both the Production and Penetration Testing segments.

    Each subnet is isolated using virtual routers and firewalls, ensuring that the Penetration Testing environment can't directly access the Production or Monitoring segments without proper authorization.

  • Firewall Rules: I configured firewall rules between subnets to restrict unnecessary communication:

    • The Production Subnet only allows traffic on ports 80 (HTTP) and 443 (HTTPS) for web services.

    • The Monitoring Subnet allows inbound traffic on port 9997 (Splunk forwarder) to collect logs but blocks all other traffic from external sources.

    • The Penetration Testing Subnet is heavily restricted, only allowing outbound traffic for reconnaissance and attack purposes.

    These rules ensure that even if the Kali Linux machine compromises a service in the Production Subnet, it can’t easily reach the Monitoring Subnet, which contains critical logging data.

    
    

  Low-Level Details:

  • Network Segmentation Setup: The virtual network was configured using VirtualBox’s internal networking feature, which allowed me to create isolated networks for each segment.

    • Penetration Testing Subnet (192.168.10.0/24): Kali Linux VM configured to have internet access for updates but restricted from accessing any other internal subnets directly.

    • Production Subnet (192.168.20.0/24): Ubuntu server running services like Apache and SSH. Limited access from only trusted IPs or segments like the Monitoring Subnet.

    • Monitoring Subnet (192.168.30.0/24): Splunk instance collecting logs from all subnets, with restricted access to other systems to avoid tampering with log files.

    Each virtual machine was assigned an IP within its respective subnet, and I configured NAT routing for internet access while enforcing segmentation between the internal subnets.
    

  • Firewall Configurations: I used UFW and iptables on the Ubuntu server to enforce network isolation. For example, the following rule blocks the Kali Linux machine from accessing the Production Subnet directly:

    Additionally, I set up logging in UFW to monitor any attempts to breach the subnet boundaries. For example, if Kali Linux tries to access the Production Subnet, the traffic is logged, providing visibility into potential attacks.

    
    

    This log data is then forwarded to Splunk for real-time monitoring and analysis.

  Practical Example
  

  During a penetration test from the Kali Linux VM, I attempted a reconnaissance scan (using Nmap) on the Production Subnet (192.168.20.0/24) to identify open ports and services. However, due to the firewall rules I implemented, traffic from the Penetration Testing Subnet was blocked:

  "nmap -sS 192.168.20.0/24"

  
  

  The scan results returned no open ports, indicating that the network segmentation was successful in preventing unauthorized access. Meanwhile, UFW logs on the Ubuntu server captured the denied traffic, and this data was automatically forwarded to Splunk for analysis.

  In Splunk, I could visualize the failed connection attempts from the Penetration Subnet in real-time, confirming that the segmentation and firewall rules were functioning as intended. This example showcases how network segmentation and firewalls can effectively contain and monitor attacker activities, limiting their ability to move laterally within a network.

7. Results and Practical Outcomes

• High-Level Overview: Over the course of developing my homelab, I gained practical experience in identifying and mitigating vulnerabilities, improving the overall security posture of my environment. Each phase of my setup involved an iterative process of testing, discovery, and fortification. Below, I outline the results and practical outcomes achieved from both defensive and offensive activities within my homelab.

  
  

  1. Vulnerabilities Found and Mitigated

     • Weak SSH Configuration: During the initial setup of the Ubuntu server, I used default settings for SSH, which allowed password-based authentication. Through penetration testing with Kali Linux, I identified that this configuration was vulnerable to brute-force attacks. The solution involved disabling password authentication and enforcing key-based login only.

       Outcome: After implementing these changes, brute-force attacks against SSH from my Kali machine were effectively blocked, improving system security.

     • Exposed Services on Open Ports: Using Nmap scans from the Kali VM, I discovered several unnecessary open ports on the Ubuntu server (e.g., FTP and Telnet). These services were not in use and presented potential attack vectors.

       Outcome: I closed all unnecessary ports and services, significantly reducing the attack surface. Subsequent Nmap scans showed only the necessary ports (e.g., HTTP/HTTPS and SSH) remained open.

     • Web Application Vulnerability: While running a mock web application on Apache, a vulnerability scan using Nikto revealed that it was vulnerable to XSS (Cross-Site Scripting) due to outdated versions of certain libraries.

       Outcome: After patching the vulnerable libraries and adding proper input sanitization, the XSS vulnerability was mitigated, confirmed by a follow-up Nikto scan.

  2. Metrics for Success

     • Reduced Attack Success Rate: Before hardening the network and services, simulated attacks from Kali Linux had a success rate of over 50%, meaning that half of my attempts to compromise the Ubuntu server were successful. After implementing firewalls, IDS, and system hardening, the success rate of attacks dropped to less than 10%, as documented by repeated attack attempts through tools like Metasploit and Hydra.

     • Log Monitoring Effectiveness: Using Splunk, I tracked security incidents and quantified the number of blocked IP addresses, failed login attempts, and suspicious traffic detections. Over the course of a month, Splunk identified and blocked multiple brute-force login attempts and detected reconnaissance activity from the Penetration Testing Subnet. This data helped demonstrate the effectiveness of my firewall and monitoring setup.

       Outcome: I measured a 90% decrease in unauthorized login attempts after implementing proper SSH restrictions and enhanced firewall rules, significantly reducing the risk of unauthorized access.

     • System Uptime and Stability: With proactive defenses in place, including automated patch management and service monitoring, I maintained 99.5% uptime for all critical services. This demonstrated both the robustness of the Ubuntu server configuration and my ability to ensure operational continuity.

  Practical Example

  During a simulated attack on the production web server hosted in the Production Subnet, I utilized Kali Linux to launch a SQL Injection attack against the web application. Initially, the attack succeeded, leading to data leakage. I responded by updating the web application's backend to properly sanitize user inputs and enforce parameterized queries.

  After implementing these fixes, I reran the attack using SQLMap, and the injection failed, confirming the vulnerability was mitigated. This practical exercise showcased my ability to identify security gaps, respond effectively, and validate the results through continuous testing.

8. Future Plans and Enhancements

• High-Level Overview: To continuously improve and expand my homelab, I plan to integrate advanced security solutions, simulate more sophisticated attack scenarios, and enhance automation in both detection and response mechanisms. These upgrades will not only provide more comprehensive coverage of the latest security challenges but will also ensure the lab remains a practical and evolving environment for learning and experimentation.

  1. SOAR (Security Orchestration, Automation, and Response) Integration

     • Current Plan: Implement a SOAR solution to automate responses to specific security events detected by Splunk. For instance, upon detecting a brute-force attack, the system will automatically block the offending IP address and send a notification without manual intervention. This enhancement aims to reduce response times and improve security efficiency.

       Example Plan in Action:

       • When the Splunk dashboard detects more than five failed SSH login attempts from the same IP, it will trigger a pre-configured playbook in SOAR.

       • The playbook will automatically update the UFW firewall rules to block the suspicious IP, preventing further attempts, and generate an alert via email for review.

       Expected Outcome: This will minimize manual intervention in routine attacks, reduce the impact of automated attacks, and free up time for more complex investigations.

  2. Cloud Security Simulation

     • Current Plan: Expand the homelab to include cloud-based infrastructure using platforms like AWS or Microsoft Azure. The goal is to simulate hybrid environments where on-premise and cloud services interact. I will also explore security challenges specific to the cloud, such as misconfigured IAM roles, cloud storage exposures, and cloud-native attacks.

       Example Plan in Action:

       • I plan to create a hybrid architecture where services in the homelab communicate with resources deployed in the cloud. Penetration testing will involve simulating cloud misconfigurations, such as S3 bucket exposures or improper IAM permissions, and responding to these incidents.

       Expected Outcome: This will provide a more modern and realistic attack surface, reflecting the transition many organizations face in moving from on-premise to cloud environments.

  3. Advanced Attack Vectors

     • Current Plan: Simulate more advanced attack vectors, such as Ransomware, Advanced Persistent Threats (APTs), and zero-day exploits. These exercises will test the lab's defenses and allow for fine-tuning of security measures like endpoint protection, incident response, and data recovery strategies.

       Example Plan in Action:

       • I plan to deploy a simulated ransomware attack within the Production Subnet, using Kali Linux tools like Metasploit to emulate how ransomware might propagate across a network.

       • Defensive measures will include isolating infected machines, restoring backups, and using Splunk to track the behavior of the malware.

       Expected Outcome: This will deepen my understanding of incident response and data recovery processes, critical for handling real-world scenarios involving sophisticated threats.

  Practical Example

  As a practical enhancement, I plan to automate firewall responses based on specific network traffic patterns detected by Snort and Splunk. For example, if a DDoS attack is detected from a certain IP range, the SOAR system will automatically scale defensive actions by blocking a broader range of IPs and initiating a notification process for incident response.

  This automation will allow my homelab to better simulate real-world enterprise security practices, where quick and automated responses to known threats are vital to minimizing damage and downtime.