Cybersecurity-Lab/LINUX-LAB.md at main · gluppler/Cybersecurity-Lab

Linux Security Operations Lab (Blue Team / SOC)

This document describes a Linux-focused virtual lab for defensive operations and SOC practice.
The lab is designed around:

Linux infrastructure and application servers
Linux desktop clients
A pfSense virtual firewall/router
Central logging, monitoring, and SIEM-style analysis
Optional IDS/IPS, honeypots, and SOAR-style automation

No dedicated attacker machines are included here. This environment is meant to:

Generate rich Linux telemetry across multiple services
Practice log centralization, correlation, and alerting
Experiment with network monitoring, honeypots, and response automation
Integrate later with a separate offensive lab if desired

1. Tool Selection and Justification

This section explains why each tool was chosen for this Linux Security Operations Lab, how it compares to alternatives, and its viability in 2026 and beyond.

1.1. Virtualization Platform: QEMU/KVM

Why QEMU/KVM?

Open-source standard: QEMU/KVM is the de-facto Linux virtualization solution, used by major cloud providers (AWS, Google Cloud, Azure Linux hosts).
Performance: Near-native performance with hardware acceleration, essential for running multiple Linux VMs with various services.
Cost: Completely free, unlike VMware vSphere or commercial hypervisors.
Linux-native: Perfect integration with Linux host systems, no compatibility layers needed.

Alternatives Considered:

VMware Workstation: Commercial licensing required, QEMU/KVM provides equivalent functionality for free.
VirtualBox: Lower performance, especially for I/O-intensive workloads. QEMU/KVM offers superior performance.
Docker/Containers: Not suitable for full OS virtualization needed for SOC lab (firewalls, IDS sensors require full VMs).

2026+ Viability: ✅ Excellent - QEMU 8.0+ actively developed, supports latest Linux kernels and distributions, regular security updates.

1.2. VM Management: libvirt + virt-manager

Why libvirt/virt-manager?

Industry standard: libvirt is used by OpenStack, oVirt, and major cloud platforms, making it highly relevant for learning.
Flexibility: Both CLI (virsh) and GUI (virt-manager) available for different workflows.
Network management: Built-in virtual network creation simplifies lab networking without manual bridge configuration.
Automation: libvirt API enables scripting and automation of VM lifecycle.

Alternatives Considered:

Cockpit: Web-based, good for remote management but virt-manager provides better local console experience.
Proxmox: Full platform, overkill for lab. libvirt is lighter and more flexible.

2026+ Viability: ✅ Excellent - libvirt 10.0+ actively maintained, virt-manager receives regular updates, full support for modern Linux distributions.

1.3. Firewall/Router: pfSense CE

Why pfSense?

Enterprise-grade: Production-ready firewall/router based on FreeBSD, provides realistic network security experience.
Feature-complete: Stateful firewall, NAT, VPN, traffic shaping, and extensive logging capabilities.
Free: Community Edition is fully functional for lab use without licensing restrictions.
Linux integration: Works seamlessly with Linux log forwarding (syslog) and SIEM platforms.

Alternatives Considered:

OPNsense: Modern fork of pfSense, but pfSense has larger community and more documentation/resources.
iptables/netfilter: Native Linux but CLI-only, complex configuration. pfSense GUI is more accessible for learning.
VyOS: CLI-only, steeper learning curve. pfSense provides better learning experience with GUI.

2026+ Viability: ✅ Excellent - pfSense CE 2.7+ actively maintained, regular security updates, supports modern protocols and standards.

1.4. Linux Distributions: Ubuntu Server LTS and Debian

Why Ubuntu/Debian?

Ubuntu Server LTS: Most popular Linux server distribution, widely used in enterprises and cloud environments.
Long-term support: Ubuntu LTS releases supported for 5 years, providing stability for lab environments.
Package availability: Extensive package repositories with security tools, SIEM components, and monitoring software.
Debian: Stable, reliable base used by many organizations, good for learning different package management.

Alternatives Considered:

CentOS/Rocky Linux: Good alternatives, but Ubuntu has larger community and more documentation for security tools.
Fedora Server: More cutting-edge but shorter support lifecycle, less suitable for stable lab environments.
Arch Linux: Rolling release, requires more maintenance, not ideal for lab stability.

2026+ Viability: ✅ Excellent - Ubuntu 24.04 LTS supported until 2029, Debian 12 supported until 2028, both actively maintained.

1.5. Log Forwarding: rsyslog

Why rsyslog?

Standard: rsyslog is the default syslog daemon on most Linux distributions (Ubuntu, Debian, RHEL).
Reliable: Mature, stable, and battle-tested in production environments worldwide.
Flexible: Supports TCP/UDP forwarding, TLS encryption, filtering, and transformation.
SIEM integration: Works with all major SIEM platforms (ELK, Graylog, Wazuh, Splunk).

Alternatives Considered:

syslog-ng: Alternative syslog daemon, but rsyslog is more widely deployed and has better documentation.
journald (systemd-journald): Modern but requires additional configuration for forwarding. rsyslog is simpler for basic forwarding.

2026+ Viability: ✅ Excellent - rsyslog 8.x actively maintained, default on major Linux distributions, regular updates.

1.6. SIEM Platforms: Elastic Stack (ELK), Graylog, Wazuh

Why Multiple Options? Different SIEMs serve different learning objectives and use cases:

Elastic Stack (ELK):

Industry standard: Elasticsearch/Kibana used by many enterprises for log analysis.
Powerful search: Elasticsearch provides powerful full-text search and analytics capabilities.
Visualization: Kibana offers excellent visualization and dashboard creation.
Open-source core: Free open-source version available (though some features require licensing).

Graylog:

Open-source: Free open-source version with core SIEM functionality.
User-friendly: Clean, modern web interface, easier to learn than ELK for beginners.
Elasticsearch backend: Uses Elasticsearch for storage, provides good performance.
Stream processing: Built-in stream processing and pipeline rules for log transformation.

Wazuh:

Comprehensive: Includes HIDS, log analysis, vulnerability detection, file integrity monitoring, and compliance.
Open-source: Completely free, no licensing restrictions.
Active development: Regularly updated with new features and detection rules.
Linux-focused: Excellent Linux agent support, good for Linux-centric SOC labs.

2026+ Viability:

Elastic Stack: ✅ Excellent - Version 8.x actively maintained, widely used in production, regular updates.
Graylog: ✅ Good - Active development continues, though smaller community than ELK/Wazuh.
Wazuh: ✅ Excellent - Version 4.7+ actively maintained, strong Linux support, regular releases.

Recommendation: Start with Wazuh for comprehensive, free learning. Use ELK if you want industry-standard experience. Graylog is good for beginners due to simpler interface.

1.7. IDS/IPS: Suricata

Why Suricata?

Modern: Actively developed IDS/IPS with modern architecture and multi-threading support.
Performance: Better performance than Snort for high-traffic scenarios due to multi-threading.
Open-source: Free and open-source, no licensing restrictions.
Feature-rich: Supports IDS, IPS, network security monitoring (NSM), and file extraction.
SIEM integration: JSON output (EVE format) integrates well with modern SIEM platforms.

Alternatives Considered:

Snort: Older, single-threaded, but more established. Suricata offers better performance and modern features.
Zeek (Bro): More complex, requires more resources. Suricata is simpler for lab use while still powerful.
pfSense Snort package: Good for pfSense integration but Suricata standalone provides more flexibility.

2026+ Viability: ✅ Excellent - Suricata 7.x actively maintained, regular rule updates, supports modern protocols and threats.

1.8. Honeypots: Cowrie and Dionaea

Why Cowrie?

SSH/Telnet honeypot: Most common honeypot type, captures SSH brute-force attempts and command execution.
Python-based: Easy to customize and extend, good for learning honeypot internals.
Active development: Regularly updated with new features and improvements.
Logging: Comprehensive logging of all interactions, perfect for SIEM integration.

Why Dionaea?

Multi-protocol: Supports HTTP, HTTPS, FTP, SMB, and other protocols, providing broader coverage.
File capture: Can capture malware samples downloaded through honeypot interactions.
Mature: Well-established honeypot with extensive documentation.

Alternatives Considered:

Kippo: Older SSH honeypot, Cowrie is the modern fork with better features.
Honeyd: Older, less maintained. Cowrie and Dionaea are more actively developed.
ModernHoneynet: More complex setup, Cowrie/Dionaea are simpler for lab use.

2026+ Viability:

Cowrie: ✅ Excellent - Actively maintained on GitHub, regular updates, Python 3 compatible.
Dionaea: ✅ Good - Still maintained, though less active than Cowrie. Still viable for lab use.

Recommendation: Use Cowrie for SSH honeypot (most common attack vector). Dionaea for multi-protocol coverage.

1.9. Log Shipping: Filebeat

Why Filebeat?

Part of Elastic Stack: Native integration with Elasticsearch and Logstash, perfect for ELK deployments.
Lightweight: Low resource usage, designed for log shipping from multiple servers.
Reliable: Handles network interruptions, can buffer and retry log delivery.
Multi-format: Supports various log formats and can parse structured logs.

Alternatives Considered:

Logstash: More powerful but heavier, requires more resources. Filebeat is lighter for log shipping.
Fluentd: Good alternative but Filebeat has better Elastic Stack integration.
rsyslog: Can forward logs but Filebeat provides better Elasticsearch integration and structured parsing.

2026+ Viability: ✅ Excellent - Filebeat 8.x actively maintained as part of Elastic Stack, regular updates, full Linux support.

1.10. Automation: Bash Scripts

Why Bash?

Native: Available on all Linux systems by default, no installation required.
Standard: Most Linux administrators and security professionals use bash for automation.
Powerful: Can integrate with system tools, APIs, and command-line utilities.
SIEM integration: Can query SIEM APIs, parse logs, and trigger responses.

Alternatives Considered:

Python: More powerful but requires installation and dependencies. Bash is more universally available.
Ansible: Good for configuration management but bash scripts are simpler for SOAR-style automation.
PowerShell Core: Cross-platform but less native to Linux than bash.

2026+ Viability: ✅ Excellent - Bash 5.x is standard on all Linux distributions, actively maintained, core to Linux administration.

2. Host System Requirements

The following values assume all VMs in a given profile are running simultaneously.

1.1. Recommended Host Hardware by Lab Size

Lab Profile	Intended Use	Minimum Host CPU	Recommended Host CPU	Minimum Host RAM	Recommended Host RAM	Minimum Free Disk	Recommended Free Disk
Profile A – Core Services + Logging	Single infra server, 1 SIEM node, 1–2 clients	4 cores	6–8 cores	16 GB	24 GB	300 GB	400 GB
Profile B – Multi-Tier App + SOC	Reverse proxy, app, DB, SIEM, 2+ clients	6 cores	8–12 cores	24 GB	32 GB	450 GB	650 GB
Profile C – Full SOC + Honeypots	Web stack, SIEM, IDS, honeypot, 3–4 clients	8 cores	12–16 cores	32 GB	40–48 GB	600 GB	800 GB+

Notes

Use thin-provisioned virtual disks to save storage (for example, qcow2).
If resources are limited, power off optional components (extra clients, honeypots, heavy analytics nodes) when not in use.

2. Common Network and Services Design

All profiles share a similar foundation:

One internal network (for example, 192.168.60.0/24)
A pfSense VM providing:
- Routing between the lab and the outside world (if enabled)
- Firewalling, including rules and logging
- Optionally DHCP and DNS forwarding
Linux servers providing:
- Core services (DNS, web, application, databases)
- Logging and SIEM-style analytics
- Optional IDS/IPS and honeypot services
Linux desktops for:
- Daily administrative tasks
- Generating normal user activity for monitoring

Example addressing:

pfSense LAN: 192.168.60.1/24
Infrastructure / logging servers: 192.168.60.10–39
Clients: 192.168.60.100–150

3. Profile A – Core Linux Services + Central Logging

Goal: Provide a compact environment for:

Practicing basic Linux server administration
Running core services (DNS, web, SSH)
Aggregating logs on a central logging node

3.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFSA["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 192.168.50.1/24"]
    end

    subgraph CoreA["Core Services Network 192.168.50.0/24"]
        SRV1["SRV1 - Ubuntu Server LTS<br/>Infra Services (DNS/Web/SSH)<br/>192.168.50.10"]
        LOG1["LOG1 - Ubuntu / Debian Server<br/>Central Log Server (e.g., rsyslog + web UI)<br/>192.168.50.20"]
        DESK1["DESK1 - Linux Desktop<br/>Primary Client<br/>192.168.50.101"]
        DESK2["DESK2 - Linux Desktop (optional)<br/>Secondary Client<br/>192.168.50.102"]
    end

    PFSA --- SRV1
    PFSA --- LOG1
    PFSA --- DESK1
    PFSA --- DESK2

    SRV1 --- LOG1
    DESK1 --- LOG1
    DESK2 --- LOG1

3.2. VM Inventory and Specifications

VM Name / Role	OS	vCPU (Min / Rec)	RAM (Min / Rec)	Disk (Min / Rec)	NICs	Primary Purpose
pfSense (PFSA)	pfSense CE	1 / 2 cores	1 GB / 2 GB	16 GB / 20 GB	2	Gateway, firewall, DHCP/DNS forwarder
SRV1	Ubuntu Server LTS (or similar)	2 / 2–3 cores	3 GB / 4–6 GB	40 GB / 60 GB	1	DNS, web, SSH, basic infrastructure services
LOG1	Ubuntu / Debian Server	2 / 3–4 cores	4 GB / 8 GB	60 GB / 100 GB	1	Central log server (rsyslog/Journalbeat + simple dashboards)
DESK1	Ubuntu Desktop / Fedora Workstation	2 / 2 cores	4 GB / 6–8 GB	40 GB / 60 GB	1	Admin and user activity workstation
DESK2 (Optional)	Any Linux desktop	2 / 2 cores	4 GB / 6–8 GB	40 GB / 60 GB	1	Additional client for multi-user scenarios

3.3. Blue Team Focus

Configure SRV1 for:
- SSH with key-based authentication
- A simple web server (for example, Nginx or Apache)
- Local system logging tuned for important events
Configure LOG1 as:
- A central syslog receiver (rsyslog or similar)
- A place to aggregate logs from:
  - SRV1
  - DESK1 and DESK2
- Optionally, a basic web UI (Kibana-like or a lightweight log viewer) for browsing logs
Use DESK1 and DESK2 to:
- Generate normal user activity
- Test how events appear in centralized logs

4. Profile B – Multi-Tier Web Application + SOC Monitoring

Goal: Build a realistic three-tier web application stack with:

Reverse proxy
Application server
Database server
Dedicated SIEM-style analytics node
One or more Linux desktops for analyst and user activity

4.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFSB["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 192.168.60.1/24"]
    end

    subgraph AppB["Web App Network 192.168.60.0/24"]
        RP["RP-SRV - Reverse Proxy<br/>Nginx/Apache<br/>192.168.60.10"]
        APP["APP-SRV - Application Server<br/>e.g., Python/Node/PHP<br/>192.168.60.20"]
        DB["DB-SRV - Database Server<br/>PostgreSQL/MySQL/MariaDB<br/>192.168.60.30"]
        SIEMB["SIEM1 - SIEM / Analytics Node<br/>192.168.60.40"]
        LDESK1["DESK1 - Linux Desktop<br/>User / Analyst<br/>192.168.60.101"]
        LDESK2["DESK2 - Linux Desktop (optional)<br/>User / Analyst<br/>192.168.60.102"]
    end

    PFSB --- RP
    PFSB --- SIEMB
    PFSB --- LDESK1
    PFSB --- LDESK2

    RP --- APP
    APP --- DB
    RP --- SIEMB
    APP --- SIEMB
    DB --- SIEMB
    LDESK1 --- SIEMB
    LDESK2 --- SIEMB

4.2. VM Inventory and Specifications

VM Name / Role	OS	vCPU (Min / Rec)	RAM (Min / Rec)	Disk (Min / Rec)	NICs	Primary Purpose
pfSense (PFSB)	pfSense CE	2 / 2 cores	2 GB / 2–4 GB	20 GB / 30 GB	2	Gateway, firewall, NAT/port forwarding as needed
RP-SRV (RP)	Ubuntu / Debian Server	2 / 2–3 cores	2 GB / 4 GB	30 GB / 50 GB	1	Reverse proxy, TLS termination, HTTP routing
APP-SRV (APP)	Ubuntu / Debian Server	2 / 3–4 cores	3 GB / 6–8 GB	40 GB / 60–80 GB	1	Application runtime (web framework, APIs, business logic)
DB-SRV (DB)	Ubuntu / Debian Server	2 / 3–4 cores	3 GB / 6–8 GB	60 GB / 100 GB	1	Relational database server for lab applications
SIEM1 (SIEMB)	Ubuntu / Debian Server	3 / 4–6 cores	6 GB / 10–16 GB	120 GB / 200–250 GB	1	SIEM-style analytics: ingest logs from all servers and clients
DESK1 (LDESK1)	Ubuntu Desktop / Fedora	2 / 2 cores	4 GB / 8 GB	40 GB / 60 GB	1	User and analyst workstation
DESK2 (LDESK2, Optional)	Any Linux desktop	2 / 2 cores	4 GB / 8 GB	40 GB / 60 GB	1	Additional user/analyst workstation

4.3. Blue Team / SOC Capabilities

Configure SIEM1 to:
- Ingest system logs (syslog, application logs) from:
  - RP-SRV, APP-SRV, DB-SRV
  - All desktops (DESK1, DESK2)
- Provide:
  - Dashboards for HTTP status patterns
  - Query capabilities for authentication events and sudo activity
  - Alerts on anomalies such as repeated failed logins or unexpected service restarts
Configure RP-SRV, APP-SRV, and DB-SRV to:
- Use consistent logging formats and rotation.
- Generate sufficient telemetry to understand:
  - Requests flowing through the stack
  - Errors and exceptions
  - Database access and failures
Use DESK1 and DESK2 to:
- Access applications as normal users.
- Operate as analyst consoles for viewing SIEM dashboards and command-line tools.

5. Profile C – Full SOC Lab with IDS and Honeypot

Goal: Extend the previous profiles into a more complete SOC-style environment with:

Web application stack
Central SIEM
Network IDS/IPS sensor
Dedicated honeypot server for deception
Multiple Linux desktops for analysts and users

5.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFSC["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 192.168.70.1/24"]
    end

    subgraph SOC["SOC Network 192.168.70.0/24"]
        RP2["RP-SRV - Reverse Proxy<br/>192.168.70.10"]
        APP2["APP-SRV - Application Server<br/>192.168.70.20"]
        DB2["DB-SRV - Database Server<br/>192.168.70.30"]
        SIEM2["SIEM2 - SIEM / Analytics Node<br/>192.168.70.40"]
        IDS["IDS-SRV - IDS/IPS Sensor<br/>192.168.70.50"]
        HONEY["HONEY-LNX - Honeypot Server<br/>192.168.70.60"]
        LDESK3["DESK1 - Linux Desktop<br/>Analyst / User<br/>192.168.70.101"]
        LDESK4["DESK2 - Linux Desktop (optional)<br/>Analyst / User<br/>192.168.70.102"]
        LDESK5["DESK3 - Linux Desktop (optional)<br/>Analyst / User<br/>192.168.70.103"]
    end

    PFSC --- RP2
    PFSC --- SIEM2
    PFSC --- IDS
    PFSC --- HONEY
    PFSC --- LDESK3
    PFSC --- LDESK4
    PFSC --- LDESK5

    RP2 --- APP2
    APP2 --- DB2
    RP2 --- SIEM2
    APP2 --- SIEM2
    DB2 --- SIEM2
    HONEY --- SIEM2
    IDS --- SIEM2
    LDESK3 --- SIEM2
    LDESK4 --- SIEM2
    LDESK5 --- SIEM2

5.2. VM Inventory and Specifications

VM Name / Role	OS	vCPU (Min / Rec)	RAM (Min / Rec)	Disk (Min / Rec)	NICs	Primary Purpose
pfSense (PFSC)	pfSense CE	2 / 3–4 cores	2 GB / 4 GB	20 GB / 30 GB	2–3	Gateway, firewall, ability to SPAN/mirror traffic to IDS if desired
RP-SRV (RP2)	Ubuntu / Debian Server	2 / 2–3 cores	2 GB / 4 GB	30 GB / 50 GB	1	Reverse proxy, TLS termination
APP-SRV (APP2)	Ubuntu / Debian Server	2 / 3–4 cores	3 GB / 6–8 GB	40 GB / 60–80 GB	1	Web application logic and APIs
DB-SRV (DB2)	Ubuntu / Debian Server	2 / 3–4 cores	3 GB / 6–8 GB	60 GB / 100 GB	1	Database backend
SIEM2	Ubuntu / Debian Server	3 / 4–6 cores	8 GB / 12–16 GB	200 GB / 300 GB+	1	Central log and event analytics
IDS-SRV (IDS)	Ubuntu / Debian Server	2 / 3–4 cores	4 GB / 8 GB	40 GB / 60 GB	1–2	Network IDS/IPS (e.g., Suricata/Snort) monitoring mirrored traffic
HONEY-LNX (HONEY)	Ubuntu / Debian Server	2 / 3–4 cores	3 GB / 6–8 GB	40 GB / 60–80 GB	1	Honeypot services (e.g., SSH, HTTP, other decoy services)
DESK1 (LDESK3)	Linux desktop	2 / 2 cores	4 GB / 8 GB	40 GB / 60 GB	1	Analyst workstation (dashboards, tools, remote access)
DESK2 (LDESK4, Optional)	Linux desktop	2 / 2 cores	4 GB / 8 GB	40 GB / 60 GB	1	Additional analyst or user workstation
DESK3 (LDESK5, Optional)	Linux desktop	2 / 2 cores	4 GB / 8 GB	40 GB / 60 GB	1	Extra client for load and scenario testing

5.3. IDS, Honeypot, and SOC Configuration

IDS-SRV
- Configure as a network IDS/IPS sensor (for example, with Suricata or a similar tool).
- Attach to a virtual network segment or mirrored interface that observes:
  - Traffic between pfSense and the internal network
  - Traffic to/from RP-SRV, APP-SRV, and HONEY-LNX
- Forward IDS/IPS alerts into SIEM2.
HONEY-LNX
- Run one or more honeypot services, such as:
  - SSH honeypot
  - HTTP/HTTPS honeypot endpoint
  - Other decoy protocol listeners
- Ensure:
  - Extensive local logging of all connection attempts and commands
  - Forwarding of logs and honeypot events to SIEM2
SIEM2
- Collect:
  - System logs from all servers and desktops
  - Application logs from the web stack
  - IDS alerts from IDS-SRV
  - Honeypot events from HONEY-LNX
- Build dashboards and alert rules focusing on:
  - Unexpected traffic to honeypot ports
  - Abnormal HTTP request patterns
  - Repeated authentication failures across multiple hosts

6. SOAR-Style Automation (Optional)

You can add automation workflows that react to events from SIEM1 or SIEM2. Examples:

On a dedicated automation user account or a small automation VM:
- Run scripts that:
  - Tag and quarantine suspicious hosts (for example, by updating pfSense firewall rules).
  - Collect additional forensic data (logs, configuration snapshots) from affected servers.
  - Notify administrators via email or messaging systems.
Clearly document:
- Trigger conditions from SIEM alerts.
- Manual approval steps for high-impact actions.
- Script inputs and outputs.

This provides SOAR-like behavior using open tooling and scripting without requiring commercial platforms.

7. General Build Order and Best Practices

Deploy pfSense
- Configure WAN (NAT from host) and LAN interface for the lab network.
- Establish basic firewall rules and confirm connectivity inside the lab.
Deploy Core Servers
- For each profile, bring up the infrastructure servers first (SRV/APP/DB/LOG/SIEM).
- Assign static IP addresses within the chosen range.
Configure Logging and Monitoring
- Set up centralized log forwarding from all servers and desktops to the appropriate log or SIEM node.
- Standardize time synchronization (for example, via NTP) across all VMs.
Add IDS and Honeypot (Profile C)
- Place IDS sensors where they can see key traffic paths.
- Expose honeypot services only within the controlled lab environment.
Deploy Desktops
- Use desktops for:
  - Regular user-like activity
  - Analyst operations (dashboards, CLI tools, configuration management)
Define and Practice Scenarios
- Authentication failures
- Service misconfigurations
- Unexpected connections to honeypot services
- Unusual HTTP or database access patterns

By following these profiles, you can build a flexible Linux Security Operations Lab that supports a wide range of defensive and SOC training scenarios and integrates cleanly with any separate offensive environments you choose to run.

8. Host Configuration and Virtualization Setup (QEMU/KVM)

The Linux Security Operations Lab is designed to run on a Linux host with QEMU/KVM, libvirt, and virt-manager, following the same approach as in README.md.

8.1. Verify Hardware Virtualization Support

# Count CPU cores with virtualization support
egrep -c '(vmx|svm)' /proc/cpuinfo

# Show line containing virtualization flags
grep -E '(vmx|svm)' /proc/cpuinfo | head -1

A value greater than 0 indicates that virtualization extensions are present.
If not found, enable Intel VT-x or AMD-V in BIOS/UEFI.

8.2. Install QEMU/KVM and Management Tools

Arch Linux

sudo pacman -Sy

sudo pacman -S --needed \
  qemu virt-manager virt-viewer \
  dnsmasq vde2 bridge-utils openbsd-netcat ebtables iptables

which qemu-system-x86_64
which virt-manager
which virsh

Ubuntu / Debian

sudo apt update

sudo apt install -y \
  qemu-kvm qemu-utils \
  libvirt-daemon-system libvirt-clients \
  bridge-utils virt-manager virt-viewer dnsmasq

which qemu-system-x86_64
which virt-manager
which virsh

8.3. Enable libvirtd and Prepare Storage

sudo systemctl enable libvirtd
sudo systemctl start libvirtd
sudo systemctl status libvirtd

# Create base directory for Linux SOC lab VMs
mkdir -p "${HOME}/VMs/linux-soc-lab"
ls -ld "${HOME}/VMs/linux-soc-lab"

Add your user to libvirt / kvm groups if required (distribution-specific), then log out and back in.

9. Network Creation for Linux Security Lab

Create a dedicated isolated network for the Linux SOC lab. pfSense will provide routing and, if desired, NAT to the internet from within the lab.

9.1. Define the `linux-soc` Network

tee /tmp/linux-soc.xml <<'EOF'
<network>
  <name>linux-soc</name>
  <bridge name="br-linux-soc"/>
  <forward mode='isolated'/>
  <ip address='192.168.70.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.70.100' end='192.168.70.200'/>
    </dhcp>
  </ip>
</network>
EOF

virsh net-define /tmp/linux-soc.xml
virsh net-start linux-soc
virsh net-autostart linux-soc

virsh net-list --all

9.2. Network Usage

Attach all Linux SOC lab VMs (pfSense, web servers, SIEM, IDS, honeypot, desktops) to the linux-soc network.
pfSense LAN interface should have a static IP within 192.168.70.0/24 (for example, 192.168.70.1).
pfSense WAN interface should attach to virbr0 or another NAT network to reach the internet for updates and package installation.

10. VM Creation Commands (pfSense, Linux Servers, Desktops)

The following examples provide a command-line workflow using virt-install. You can perform the same operations with virt-manager if you prefer a graphical interface.

10.1. Download pfSense ISO

mkdir -p "${HOME}/Downloads/pfsense"

# Check https://www.pfsense.org/download/ for latest version
PFS_VERSION="2.7.2"
PFS_ISO="pfSense-CE-${PFS_VERSION}-RELEASE-amd64.iso"
PFS_URL="https://atxfiles.pfsense.org/mirror/downloads/${PFS_ISO}"

echo "Downloading pfSense ISO..."
curl -L --progress-bar -o "${HOME}/Downloads/pfsense/${PFS_ISO}" "${PFS_URL}"

ls -lh "${HOME}/Downloads/pfsense/${PFS_ISO}"

10.2. Create pfSense VM

VM_NAME="pfsense-linux-soc"
VM_RAM="2048"       # 2 GiB
VM_CPUS="2"
VM_DISK_SIZE="20"   # 20 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/pfsense/${PFS_ISO}"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole \
  --os-type generic \
  --os-variant generic

After installing pfSense:

Attach the WAN interface to the default NAT network (virbr0).
Keep the LAN interface on linux-soc and configure 192.168.70.1/24 (or your chosen address).

10.3. Create Core Linux Servers

Obtain appropriate Linux ISO images, for example:

Ubuntu Server LTS: https://ubuntu.com/download/server
Debian stable: https://www.debian.org/distrib/

Example for a core infrastructure server (SRV1):

VM_NAME="srv1-core"
VM_RAM="4096"       # 4 GiB
VM_CPUS="2"
VM_DISK_SIZE="60"   # 60 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/ubuntu-server.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics none \
  --os-type linux \
  --os-variant ubuntu22.04

After installation:

Set a static IP in the appropriate range (for example, 192.168.70.10 for SRV1).
Install and configure DNS, web, SSH, or other services as described in the profiles above.
Configure log forwarding from SRV1 to your central log or SIEM node.

10.4. Create SIEM / Analytics Node

Example for SIEM2:

VM_NAME="siem2"
VM_RAM="12288"       # 12 GiB
VM_CPUS="4"
VM_DISK_SIZE="250"   # 250 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/ubuntu-server.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics none \
  --os-type linux \
  --os-variant ubuntu22.04

Configure your preferred open-source SIEM stack (for example, Elastic Stack, Graylog, Wazuh, or similar) and:

Ingest system and application logs from all Linux servers and desktops.
Ingest IDS alerts and honeypot events (Profile C).

10.5. Create IDS and Honeypot Servers

Example IDS server (IDS-SRV):

VM_NAME="ids-srv"
VM_RAM="8192"        # 8 GiB
VM_CPUS="4"
VM_DISK_SIZE="60"    # 60 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/ubuntu-server.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics none \
  --os-type linux \
  --os-variant ubuntu22.04

Install and configure your IDS/IPS (for example, Suricata or Snort) and forward alerts to the SIEM.

Example honeypot server (HONEY-LNX):

VM_NAME="honey-lnx"
VM_RAM="6144"        # 6 GiB
VM_CPUS="3"
VM_DISK_SIZE="60"    # 60 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/ubuntu-server.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics none \
  --os-type linux \
  --os-variant ubuntu22.04

Install your chosen honeypot software and configure:

SSH and HTTP/HTTPS decoy services.
Extensive local logging of all connections and commands.
Log forwarding to SIEM2.

10.6. Create Linux Desktop VMs

Example desktop:

VM_NAME="desk1"
VM_RAM="8192"        # 8 GiB
VM_CPUS="2"
VM_DISK_SIZE="60"    # 60 GiB
DISK_PATH="${HOME}/VMs/linux-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/ubuntu-desktop.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=linux-soc,model=virtio \
  --graphics spice \
  --video qxl \
  --os-type linux \
  --os-variant ubuntu22.04

Assign an IP address via pfSense DHCP or static configuration within 192.168.70.0/24, and configure the desktop to:

Generate normal user activity.
Provide access to SIEM dashboards and administration tools.

11. Post-Installation Configuration: Linux Servers

After creating your Linux VMs, configure networking, services, and logging.

11.1. Configure Static IP Address (Ubuntu/Debian)

On each Linux server:

For Ubuntu 18.04+ (netplan):

sudo nano /etc/netplan/01-netcfg.yaml

Configure (example for SRV1 at 192.168.70.10):

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 192.168.70.10/24
      gateway4: 192.168.70.1
      nameservers:
        addresses:
          - 192.168.70.1
          - 8.8.8.8

Apply changes:

sudo netplan apply
sudo netplan --debug generate  # Verify configuration

For Debian (traditional ifupdown):

sudo nano /etc/network/interfaces

Configure:

auto eth0
iface eth0 inet static
    address 192.168.70.10
    netmask 255.255.255.0
    gateway 192.168.70.1
    dns-nameservers 192.168.70.1 8.8.8.8

Restart networking:

sudo systemctl restart networking

11.2. Configure SSH and Basic Security

On each Linux server:

# Update system
sudo apt update && sudo apt upgrade -y

# Configure SSH key-based authentication
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Generate SSH key pair (on your host or management machine)
# ssh-keygen -t ed25519 -C "your_email@example.com"

# Copy public key to server
# ssh-copy-id user@192.168.70.10

# Disable password authentication (after key setup)
sudo nano /etc/ssh/sshd_config

Edit SSH config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Restart SSH:

sudo systemctl restart sshd

11.3. Install and Configure Core Services

On SRV1 (Infrastructure Server):

# Install DNS (BIND9)
sudo apt install -y bind9 bind9utils bind9-doc

# Configure BIND9
sudo nano /etc/bind/named.conf.options

Add:

options {
    directory "/var/cache/bind";
    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    dnssec-validation auto;
    listen-on-v6 { any; };
};

# Install web server (Nginx)
sudo apt install -y nginx

# Create test page
echo "<h1>SRV1 Infrastructure Server</h1>" | sudo tee /var/www/html/index.html

# Start and enable services
sudo systemctl enable bind9 nginx
sudo systemctl start bind9 nginx

12. Post-Installation Configuration: SIEM Stack (ELK / Graylog / Wazuh)

Choose one SIEM platform for your Linux SOC lab.

12.1. Option A: Elastic Stack (ELK)

On SIEM Server:

Install Java:

sudo apt update
sudo apt install -y openjdk-11-jdk
java -version

Install Elasticsearch:

# Add Elastic repository
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list

sudo apt update
sudo apt install -y elasticsearch

# Configure Elasticsearch
sudo nano /etc/elasticsearch/elasticsearch.yml

Set:

network.host: 0.0.0.0
http.port: 9200
discovery.type: single-node

# Start Elasticsearch
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

# Verify
curl http://localhost:9200

Install Logstash:

sudo apt install -y logstash

# Create logstash configuration
sudo nano /etc/logstash/conf.d/syslog.conf

Configure:

input {
  syslog {
    port => 514
    type => "syslog"
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGLINE}" }
    }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "syslog-%{+YYYY.MM.dd}"
  }
}

sudo systemctl enable logstash
sudo systemctl start logstash

Install Kibana:

sudo apt install -y kibana

# Configure Kibana
sudo nano /etc/kibana/kibana.yml

Set:

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://localhost:9200"]

sudo systemctl enable kibana
sudo systemctl start kibana

Access Kibana: http://192.168.70.40:5601

12.2. Option B: Graylog

On SIEM Server:

Install MongoDB:

sudo apt install -y mongodb-server mongodb-clients

sudo systemctl enable mongodb
sudo systemctl start mongodb

Install Elasticsearch (see section 12.1)

Install Graylog:

# Add Graylog repository
wget https://packages.graylog2.org/repo/packages/graylog-4.3-repository_latest.deb
sudo dpkg -i graylog-4.3-repository_latest.deb
sudo apt update

sudo apt install -y graylog-server

# Configure Graylog
sudo nano /etc/graylog/server/server.conf

Set:

password_secret = <generate-secret>
root_username = admin
root_password_sha2 = <generate-sha256-hash>
http_bind_address = 0.0.0.0:9000
http_external_uri = http://192.168.70.40:9000/

Generate secrets:

# Generate password_secret
pwgen -N 1 -s 96

# Generate root_password_sha2
echo -n "YourPassword" | shasum -a 256

sudo systemctl enable graylog-server
sudo systemctl start graylog-server

Access Graylog: http://192.168.70.40:9000

12.3. Option C: Wazuh

On SIEM Server:

Install Wazuh Manager:

# Add Wazuh repository
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update
sudo apt install -y wazuh-manager

# Start Wazuh
sudo systemctl enable wazuh-manager
sudo systemctl start wazuh-manager

# Check status
sudo systemctl status wazuh-manager

Install Wazuh Dashboard:

sudo apt install -y wazuh-dashboard

# Configure
sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Set:

server.host: "0.0.0.0"
opensearch.hosts: ["http://localhost:9200"]

sudo systemctl enable wazuh-dashboard
sudo systemctl start wazuh-dashboard

Access Wazuh: http://192.168.70.40:5601

12.4. Configure Centralized Logging from Linux Servers

On each Linux server (SRV1, APP-SRV, DB-SRV, etc.):

Configure rsyslog to forward to SIEM:

sudo nano /etc/rsyslog.conf

Add at end:

# Forward to SIEM server
*.* @@192.168.70.40:514

Restart rsyslog:

sudo systemctl restart rsyslog

For systemd-based systems (journald):

# Install and configure journalbeat or filebeat
# Example with filebeat (for ELK)
sudo apt install -y filebeat

sudo nano /etc/filebeat/filebeat.yml

Configure:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/syslog
    - /var/log/auth.log
    - /var/log/nginx/access.log
    - /var/log/nginx/error.log

output.elasticsearch:
  hosts: ["192.168.70.40:9200"]

sudo systemctl enable filebeat
sudo systemctl start filebeat

13. Post-Installation Configuration: IDS/IPS (Suricata)

Configure Suricata as a network intrusion detection/prevention system.

13.1. Install Suricata

On IDS-SRV:

sudo apt update
sudo apt install -y suricata

# Update Suricata rules
sudo suricata-update

# Enable and start Suricata
sudo systemctl enable suricata
sudo systemctl start suricata

13.2. Configure Suricata

Edit Suricata configuration:

sudo nano /etc/suricata/suricata.yaml

Key settings:

# Network interface (adjust to your interface name)
af-packet:
  - interface: eth0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

# Logging
logging:
  default-log-format: "[%i] %t - (%f:%l) <%d> (%n) -- "
  outputs:
    - eve-log:
        enabled: yes
        file: /var/log/suricata/eve.json
        types:
          - alert
          - http
          - dns
          - tls
          - files
          - ssh
          - stats

Update rules:

sudo suricata-update
sudo systemctl restart suricata

13.3. Configure Traffic Mirroring/SPAN

Option 1: Use pfSense packet capture:

Configure pfSense to mirror traffic to IDS-SRV
Or use tcpdump on pfSense and forward to IDS-SRV

Option 2: Configure IDS-SRV to monitor bridge traffic:

# If using libvirt bridge, configure IDS-SRV to monitor br-linux-soc
sudo ip link set eth0 promisc on
sudo suricata -c /etc/suricata/suricata.yaml -i eth0

13.4. Forward Suricata Alerts to SIEM

Configure Suricata to send alerts to SIEM:

sudo nano /etc/suricata/suricata.yaml

Add output:

outputs:
  - eve-log:
      enabled: yes
      file: /var/log/suricata/eve.json
      types:
        - alert
  - syslog:
      enabled: yes
      facility: local5
      format: "[%i] <%d> -- "
      app-name: suricata

Configure rsyslog to forward:

sudo nano /etc/rsyslog.conf

Add:

local5.* @@192.168.70.40:514

Restart services:

sudo systemctl restart suricata rsyslog

14. Post-Installation Configuration: Honeypot Server

Configure a Linux server as a honeypot for deception.

14.1. Install Cowrie SSH Honeypot

On HONEY-LNX:

# Install dependencies
sudo apt update
sudo apt install -y python3 python3-pip python3-venv git

# Create honeypot user
sudo useradd -m -s /bin/bash cowrie
sudo su - cowrie

# Clone Cowrie
git clone https://github.com/cowrie/cowrie.git
cd cowrie

# Create virtual environment
python3 -m venv cowrie-env
source cowrie-env/bin/activate

# Install Cowrie
pip install --upgrade pip
pip install -r requirements.txt

Configure Cowrie:

cd cowrie/etc
cp cowrie.cfg.dist cowrie.cfg
nano cowrie.cfg

Edit:

[output_jsonlog]
enabled = true
logfile = log/cowrie.json

[output_syslog]
enabled = true
host = 192.168.70.40
port = 514

Run Cowrie:

cd ~/cowrie
source cowrie-env/bin/activate
bin/cowrie start

14.2. Install Dionaea HTTP/HTTPS Honeypot

On HONEY-LNX:

sudo apt install -y dionaea-python dionaea-cyberchef dionaea-ipp

# Configure Dionaea
sudo nano /etc/dionaea/dionaea.conf

Configure logging to forward to SIEM:

[output.syslog]
enabled = true
host = 192.168.70.40
port = 514

sudo systemctl enable dionaea
sudo systemctl start dionaea

14.3. Create Decoy Services

Create fake web services:

# Install simple HTTP server
sudo apt install -y python3-http.server

# Create decoy content
sudo mkdir -p /var/www/honeypot
echo "<h1>Internal Admin Portal</h1><p>Login: admin / Password: admin123</p>" | sudo tee /var/www/honeypot/index.html

# Run on non-standard port
python3 -m http.server 8080 --directory /var/www/honeypot &

Create fake database listener:

# Use a simple TCP listener that logs connections
sudo apt install -y netcat

# Create script to log connections
cat > /tmp/fake_mysql.sh << 'EOF'
#!/bin/bash
while true; do
    echo "$(date): Connection attempt from $1" >> /var/log/honeypot.log
    nc -l -p 3306 < /dev/null
done
EOF

chmod +x /tmp/fake_mysql.sh

14.4. Configure Extensive Logging

Ensure all honeypot logs forward to SIEM:

# Configure rsyslog
sudo nano /etc/rsyslog.conf

Add:

# Honeypot logs
/var/log/honeypot.log @@192.168.70.40:514
/var/log/cowrie/cowrie.log @@192.168.70.40:514

sudo systemctl restart rsyslog

15. Post-Installation Configuration: SOAR-Style Automation

Implement automated response workflows using bash scripts and Linux tools.

15.1. Create Automation Directory Structure

On SIEM Server or dedicated automation server:

sudo mkdir -p /opt/soar/{scripts,logs,config}
sudo chown -R $USER:$USER /opt/soar

15.2. Example: Auto-Block IP Script

Create /opt/soar/scripts/block-ip.sh:

#!/bin/bash
# block-ip.sh - Block suspicious IP address via pfSense API or firewall rules

IP_ADDRESS=$1
REASON=$2
LOG_FILE="/opt/soar/logs/automation.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$TIMESTAMP] Blocking IP: $IP_ADDRESS - Reason: $REASON" >> "$LOG_FILE"

# Option 1: Add to pfSense firewall rules via SSH/API
# Option 2: Use iptables on local firewall
# Option 3: Update pfSense via API

# Example: Add to local iptables (if running on same host)
sudo iptables -A INPUT -s "$IP_ADDRESS" -j DROP
sudo iptables-save > /etc/iptables/rules.v4

echo "[$TIMESTAMP] Successfully blocked IP: $IP_ADDRESS" >> "$LOG_FILE"

Make executable:

chmod +x /opt/soar/scripts/block-ip.sh

15.3. Example: Quarantine Host Script

Create /opt/soar/scripts/quarantine-host.sh:

#!/bin/bash
# quarantine-host.sh - Isolate a suspicious host

HOST_IP=$1
LOG_FILE="/opt/soar/logs/automation.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$TIMESTAMP] Quarantining host: $HOST_IP" >> "$LOG_FILE"

# Block host from accessing other systems (via firewall rules)
# Example: Add rule to pfSense or local firewall
sudo iptables -A FORWARD -s "$HOST_IP" -j DROP
sudo iptables -A FORWARD -d "$HOST_IP" -j DROP

# Log action
echo "[$TIMESTAMP] Host $HOST_IP quarantined" >> "$LOG_FILE"

# Send notification (example with mail or webhook)
# echo "Host $HOST_IP has been quarantined" | mail -s "SOAR Alert" admin@example.com

15.4. Example: Collect Forensic Data Script

Create /opt/soar/scripts/collect-forensics.sh:

#!/bin/bash
# collect-forensics.sh - Gather forensic data from suspicious host

HOST_IP=$1
OUTPUT_DIR="/opt/soar/forensics/$(date +%Y%m%d_%H%M%S)_$HOST_IP"
LOG_FILE="/opt/soar/logs/automation.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

mkdir -p "$OUTPUT_DIR"

echo "[$TIMESTAMP] Collecting forensics from $HOST_IP" >> "$LOG_FILE"

# SSH to host and collect data (requires SSH key setup)
ssh "admin@$HOST_IP" << EOF > "$OUTPUT_DIR/processes.txt" 2>&1
ps aux
netstat -tulpn
last
who
EOF

# Collect logs
scp "admin@$HOST_IP:/var/log/auth.log" "$OUTPUT_DIR/" 2>/dev/null
scp "admin@$HOST_IP:/var/log/syslog" "$OUTPUT_DIR/" 2>/dev/null

echo "[$TIMESTAMP] Forensics collected to $OUTPUT_DIR" >> "$LOG_FILE"

15.5. Create SIEM Alert Monitor Script

Create /opt/soar/scripts/monitor-siem-alerts.sh:

#!/bin/bash
# monitor-siem-alerts.sh - Monitor SIEM for high-severity alerts and trigger automation

SIEM_LOG="/var/log/suricata/eve.json"  # Example: Suricata alerts
THRESHOLD=5  # Number of alerts before action
LOG_FILE="/opt/soar/logs/automation.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# Parse SIEM logs (example with jq for JSON logs)
if command -v jq &> /dev/null; then
    # Count alerts per source IP in last 10 minutes
    ALERT_COUNTS=$(jq -r 'select(.event_type=="alert") | .src_ip' "$SIEM_LOG" 2>/dev/null | \
        sort | uniq -c | sort -rn | head -5)
    
    while read -r count ip; do
        if [ "$count" -ge "$THRESHOLD" ]; then
            echo "[$TIMESTAMP] High alert count for IP $ip: $count alerts" >> "$LOG_FILE"
            
            # Trigger automation
            /opt/soar/scripts/block-ip.sh "$ip" "High alert count: $count alerts"
        fi
    done <<< "$ALERT_COUNTS"
fi

# Monitor for specific attack patterns
# Example: Detect brute force attempts
FAILED_LOGINS=$(grep "Failed password" /var/log/auth.log 2>/dev/null | \
    awk '{print $NF}' | sort | uniq -c | sort -rn | head -1)

if [ -n "$FAILED_LOGINS" ]; then
    COUNT=$(echo "$FAILED_LOGINS" | awk '{print $1}')
    IP=$(echo "$FAILED_LOGINS" | awk '{print $2}')
    
    if [ "$COUNT" -ge "$THRESHOLD" ]; then
        echo "[$TIMESTAMP] Brute force detected from $IP: $COUNT attempts" >> "$LOG_FILE"
        /opt/soar/scripts/block-ip.sh "$IP" "Brute force: $COUNT failed logins"
    fi
fi

15.6. Create Cron Job for Automated Monitoring

Set up scheduled task:

# Edit crontab
crontab -e

Add:

# Run SOAR monitoring every 5 minutes
*/5 * * * * /opt/soar/scripts/monitor-siem-alerts.sh >> /opt/soar/logs/cron.log 2>&1

16. Additional References

Virtualization and Management

QEMU/KVM Documentation: https://www.qemu.org/documentation/ - Official QEMU documentation
KVM Virtualization: https://www.linux-kvm.org/page/Main_Page - KVM project homepage and resources
libvirt Documentation: https://libvirt.org/docs.html - Complete libvirt API and tool documentation
virt-manager: https://virt-manager.org/ - GUI for managing virtual machines
virsh Command Reference: https://libvirt.org/manpages/virsh.html - Command-line tool documentation

Networking and Firewall

pfSense CE: https://www.pfsense.org/ - Official pfSense website and downloads
pfSense Documentation: https://docs.netgate.com/pfsense/ - Complete pfSense documentation
pfSense Community Forum: https://forum.netgate.com/ - Community support and discussions

Linux Distributions

Ubuntu Server LTS: https://ubuntu.com/download/server - Download Ubuntu Server LTS
Ubuntu Desktop: https://ubuntu.com/download/desktop - Download Ubuntu Desktop
Debian Downloads: https://www.debian.org/distrib/ - Download Debian installation media
Debian Documentation: https://www.debian.org/doc/ - Debian administration and user guides

Log Management

rsyslog Documentation: https://www.rsyslog.com/doc/ - Complete rsyslog documentation
rsyslog Configuration Examples: https://www.rsyslog.com/doc/v8-stable/configuration/index.html - Configuration reference
systemd-journald: https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html - Journald documentation

SIEM Platforms

Elastic Stack (ELK): https://www.elastic.co/elastic-stack - Elastic Stack overview and downloads
Elasticsearch Documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html - Elasticsearch reference
Logstash Documentation: https://www.elastic.co/guide/en/logstash/current/index.html - Logstash reference
Kibana Documentation: https://www.elastic.co/guide/en/kibana/current/index.html - Kibana reference
Filebeat Documentation: https://www.elastic.co/guide/en/beats/filebeat/current/index.html - Filebeat reference
Graylog Documentation: https://go2docs.graylog.org/ - Graylog official documentation
Graylog Installation: https://go2docs.graylog.org/5-2/installing-graylog/install-graylog-on-ubuntu.html - Ubuntu installation guide
Wazuh Documentation: https://documentation.wazuh.com/current/index.html - Complete Wazuh documentation
Wazuh Installation Guide: https://documentation.wazuh.com/current/installation-guide/index.html - Installation instructions

IDS/IPS

Suricata IDS/IPS: https://suricata.io/ - Official Suricata website
Suricata Documentation: https://suricata.readthedocs.io/ - Complete Suricata documentation
Suricata Rules: https://rules.emergingthreats.net/ - Emerging Threats Suricata rules
Suricata Update Tool: https://suricata.readthedocs.io/en/latest/rule-management/suricata-update.html - Rule update documentation

Honeypots

Cowrie Honeypot: https://github.com/cowrie/cowrie - Cowrie GitHub repository
Cowrie Documentation: https://github.com/cowrie/cowrie/wiki - Cowrie wiki and documentation
Dionaea Honeypot: https://github.com/DinoTools/dionaea - Dionaea GitHub repository
Dionaea Documentation: https://github.com/DinoTools/dionaea/wiki - Dionaea wiki
Modern Honeypot Network: https://www.honeynet.org/ - Honeynet Project resources

Automation and Scripting

Bash Guide: https://www.gnu.org/software/bash/manual/ - GNU Bash manual
Advanced Bash Scripting Guide: https://tldp.org/LDP/abs/html/ - Comprehensive bash scripting guide
Linux System Administration: https://www.linux.org/forums/linux-system-administration.50/ - Linux admin resources

FilesExpand file tree

LINUX-LAB.md

Latest commit

History

LINUX-LAB.md

File metadata and controls

Linux Security Operations Lab (Blue Team / SOC)

1. Tool Selection and Justification

1.1. Virtualization Platform: QEMU/KVM

1.2. VM Management: libvirt + virt-manager

1.3. Firewall/Router: pfSense CE

1.4. Linux Distributions: Ubuntu Server LTS and Debian

1.5. Log Forwarding: rsyslog

1.6. SIEM Platforms: Elastic Stack (ELK), Graylog, Wazuh

1.7. IDS/IPS: Suricata

1.8. Honeypots: Cowrie and Dionaea

1.9. Log Shipping: Filebeat

1.10. Automation: Bash Scripts

2. Host System Requirements

1.1. Recommended Host Hardware by Lab Size

2. Common Network and Services Design

3. Profile A – Core Linux Services + Central Logging

3.1. Topology

3.2. VM Inventory and Specifications

3.3. Blue Team Focus

4. Profile B – Multi-Tier Web Application + SOC Monitoring

4.1. Topology

4.2. VM Inventory and Specifications

4.3. Blue Team / SOC Capabilities

5. Profile C – Full SOC Lab with IDS and Honeypot

5.1. Topology

5.2. VM Inventory and Specifications

5.3. IDS, Honeypot, and SOC Configuration

6. SOAR-Style Automation (Optional)

7. General Build Order and Best Practices

8. Host Configuration and Virtualization Setup (QEMU/KVM)

8.1. Verify Hardware Virtualization Support

8.2. Install QEMU/KVM and Management Tools

Arch Linux

Ubuntu / Debian

8.3. Enable libvirtd and Prepare Storage

9. Network Creation for Linux Security Lab

9.1. Define the linux-soc Network

9.2. Network Usage

10. VM Creation Commands (pfSense, Linux Servers, Desktops)

10.1. Download pfSense ISO

10.2. Create pfSense VM

10.3. Create Core Linux Servers

10.4. Create SIEM / Analytics Node

10.5. Create IDS and Honeypot Servers

10.6. Create Linux Desktop VMs

11. Post-Installation Configuration: Linux Servers

11.1. Configure Static IP Address (Ubuntu/Debian)

11.2. Configure SSH and Basic Security

11.3. Install and Configure Core Services

12. Post-Installation Configuration: SIEM Stack (ELK / Graylog / Wazuh)

12.1. Option A: Elastic Stack (ELK)

12.2. Option B: Graylog

12.3. Option C: Wazuh

12.4. Configure Centralized Logging from Linux Servers

13. Post-Installation Configuration: IDS/IPS (Suricata)

13.1. Install Suricata

13.2. Configure Suricata

13.3. Configure Traffic Mirroring/SPAN

13.4. Forward Suricata Alerts to SIEM

14. Post-Installation Configuration: Honeypot Server

14.1. Install Cowrie SSH Honeypot

14.2. Install Dionaea HTTP/HTTPS Honeypot

14.3. Create Decoy Services

14.4. Configure Extensive Logging

15. Post-Installation Configuration: SOAR-Style Automation

15.1. Create Automation Directory Structure

15.2. Example: Auto-Block IP Script

15.3. Example: Quarantine Host Script

15.4. Example: Collect Forensic Data Script

15.5. Create SIEM Alert Monitor Script

15.6. Create Cron Job for Automated Monitoring

16. Additional References

Virtualization and Management

Networking and Firewall

9.1. Define the `linux-soc` Network