Setting up a complete lab

Introduction

In the chapter “Setting Up a Basic Lab ,” we covered how to install a simple Threat Hunting lab using OpenSearch on Alma Linux in VirtualBox. Now, in this chapter, we’ll focus on building a more comprehensive lab environment with additional tools based on the system described in the previous chapter. Our main goal here is to automate the installation process so the environment can be easily set up and torn down as needed.

My Current setup

To make things easier for you, I’ve turned my personal threat hunting workstation into a series of installation files you can use. Here’s an overview of the setup I currently use:

I’ve created an installation routine to guide you through setting up the environment, starting from a fresh install of Alma Linux (right after the first login). But before diving in, let’s talk a bit more about this project named “Threat Hunting Workstation”.

About the Threat Hunting Workstation

The Threat Hunting Workstation is meant to be a complete toolkit designed to help teams set up a dedicated environment for efficient threat hunting - as well as an environment you can teardown and setup time whenever required. It includes a SIEM tool for log importing and analysis, a wiki for documentation, and a collection of essential utilities for threat hunting and incident management. Delivered as an installation script for a virtualized Alma Linux instance, this workstation provides a centralized, powerful solution to improve team collaboration and streamline security operations.

This installation routine is based on Ansible - please have a look at the setup-ansible.yml YAML file to see each step involved in setting up this workstation.

Architecture

The workstation architecture looks like this:

flowchart LR
 B[Virtualbox]
 C[Alma Linux]
 D[Docker]
 E[OpenSearch]
 F[XWiki]
 G[Portainer]
 H[CyberChef]
 I[DFIR-IRIS]

 subgraph A[Threathunter Workstation]
    subgraph B[Virtualbox]
        C-->D
        D-->E
        D-->F
        D-->G
        D-->H
        D-. Future .->I
    end
 end
 

Installation

The great thing about this installation is that you need only to worry about one single script. That’s right, no need to Git clone a repo or similar. In general, the installation consists of two steps:

1. Install Alma Linux in Virtualbox. Not covered in this installation instruction.
2. Install the Threathunting Workstation toolset using the script covered in this installation instruction.

Obtain the installation script:

curl https://raw.githubusercontent.com/rjohnsen/threathunting-workstation/main/install-workstation.sh -o install-workstation.sh

Run setup script:

chmod +x install-workstation.sh
./install-workstation.sh

Then follow directions.

Service Ports

The following table displays the communication ports for each intalled service. This table also serves as a reference for setting up port forwarding for NAT Networks in Virtualbox:

XWiki initial setup

First time reaching XWiki over the web it will kickstart its installer. The installer will guide you through four steps:

1. Admin user - make sure to create a user with administrative right
2. Flavor - install or update the flavor of this wiki. Make sure to install and use “XWiki Standard Flavor” as presented in the GUI.
3. Orphaned dependencies - make sure orphaned extension dependencies are either removed or made top level.
4. Extensions - update the installed extensions

Alma Linux Default Credentials

The Ansible script will create a user belonging to the “wheel” group. This user can run “sudo”. Its default credentials is “hunter:hunter”

Upgrading the stack

Use these instructions to update the Docker containers installed by the installer script. Run the following steps as ROOT or via sudo.

Updating Alma Linux

dnf upgrade

Updating Docker containers

Update all containers

docker compose pull
docker-compose up -d

After these commands completes, give it some minutes before trying to reach the hosts in a browser.

Verifying versions after update

OpenSearch

In a suitable browser, visit https://localhost:9200, log in and you’ll be presented with a JSON object stating the version. Example:

{
  "name" : "opensearch-node1",
  "cluster_name" : "opensearch-cluster",
  "cluster_uuid" : "N7IOLSfnSFWasG-EoI7IUg",
  "version" : {
    "distribution" : "opensearch",
    "number" : "2.17.0",
    "build_type" : "tar",
    "build_hash" : "8586481dc99b1740ca3c7c966aee15ad0fc7b412",
    "build_date" : "2024-09-13T01:04:14.707418737Z",
    "build_snapshot" : false,
    "lucene_version" : "9.11.1",
    "minimum_wire_compatibility_version" : "7.10.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

Troubleshooting

Winlogbeat and others fails to connect

Re-enabling OpenSearch compability setting

Historically, many multiple popular agents and ingestion tools have worked with Elasticsearch OSS, such as Beats, Logstash, Fluentd, FluentBit, and OpenTelemetry. OpenSearch aims to continue to support a broad set of agents and ingestion tools, but not all have been tested or have explicitly added OpenSearch compatibility. As an intermediate compatibility solution, OpenSearch has a setting that instructs the cluster to return version 7.10.2 rather than its actual version. If you use clients that include a version check, such as versions of Logstash OSS or Filebeat OSS between 7.x - 7.12.x, enable the setting:

PUT _cluster/settings
{
  "persistent": {
    "compatibility": {
      "override_main_response_version": true
    }
  }
}

Check HTTPS settings and credentials

Check if you need to update connection data in shippers to use HTTPS. Change or add credentials accordingly.