# Lab 22: Same Logs, New SIEM — Setting Up Splunk From Scratch

Lab 21 closed the detection gap in Elastic.

31 alerts fired. End-to-end detection confirmed. The Elastic SIEM phase of the portfolio was complete.

So naturally, I installed a second SIEM.

Lab 22 is the start of the Splunk chapter — deploying Splunk Enterprise 10.2.2 on the same Kali Linux host, pointing it at the same log source, and seeing what it takes to build detection coverage from scratch on a completely different platform.

Same logs. Same threats. Different tool.

* * *

### Why Splunk

Real SOC environments don't run one SIEM and call it done. Different organizations use different platforms — Elastic, Splunk, Microsoft Sentinel, IBM QRadar. An analyst who only knows one tool is an analyst with a ceiling.

The goal of the Splunk series isn't to prove that Splunk is better or worse than Elastic. It's to demonstrate that the detection engineering concepts I built in Labs 11–21 aren't platform-specific. The logic transfers. The syntax changes.

That's what platform-agnostic detection actually looks like in practice.

* * *

### Installing Splunk Enterprise on Kali Linux

Splunk Enterprise doesn't come pre-installed. The setup starts with downloading the `.deb` package directly from Splunk's servers:

```plaintext
wget -O splunk-10.2.2-linux-amd64.deb "https://download.splunk.com/products/splunk/releases/10.2.2/linux/splunk-10.2.2-80b90d638de6-linux-amd64.deb"
```

Then installing it:

```plaintext
sudo dpkg -i splunk-10.2.2-80b90d638de6-linux-amd64.deb
```

Then starting Splunk and accepting the license:

```plaintext
sudo /opt/splunk/bin/splunk start --accept-license --run-as-root
```

On first launch, Splunk prompts you to create an admin account. Once that's done, the web interface is accessible at [`http://localhost:8000`](http://localhost:8000) — Splunk's browser-based UI where everything lives.

First impression coming from Elastic: different layout, different terminology, same fundamental concept. You're building a pipeline from log source to searchable index to detection logic. The plumbing is just labeled differently.

* * *

### Configuring Log Ingestion

Getting Splunk to ingest logs follows a similar path to Elastic — you tell it where to look, what to call it, and how to handle it.

The configuration path in Splunk's web interface:

**Settings → Add Data → Monitor → Files & Directories**

Settings applied:

*   **Source:** `/var/log/auth.log`
    
*   **Source Type:** `linux_auth` (custom, created to properly categorize authentication log events)
    
*   **Host:** `kali`
    
*   **Index:** `default`
    
*   **Continuously Monitor:** Yes
    

That last setting — Continuously Monitor — is important. It means Splunk doesn't just take a one-time snapshot of the file. It watches for new events in real time, which is what you need for live detection.

* * *

### Verifying Ingestion

A pipeline that's configured but unverified is a pipeline you can't trust. Lab 21 taught me that lesson the hard way.

I ran a baseline search to confirm events were actually making it into Splunk's index.

**Result: 180 events indexed.**

Then I ran a targeted search to confirm the SSH brute force events from Labs 13 and 21 were present:

**Result: 76 events — all SSH brute force attempts confirmed.**

That number matters. 76 events from previous lab simulations, sitting in Splunk's index, immediately available for analysis. The rsyslog fix from Lab 21 wasn't just about closing the Elastic detection gap — it was a prerequisite for everything that comes next in the Splunk series.

One fix. Two SIEMs. Both operational.

* * *

### What This Lab Actually Taught Me

Installing a second SIEM reinforced something that's easy to read about but harder to internalize until you've done it:

**The tool is not the skill.**

The ability to configure a log source, verify ingestion, and confirm that the right data is in the index — that process is identical whether you're in Elastic or Splunk. The interface looks different. The search syntax is different. The underlying discipline is exactly the same.

Analysts who understand the pipeline — log source → ingestion → index → search → detection — can work in any SIEM. Analysts who only memorized the clicks in one platform are going to struggle the moment they sit in front of another one.

That's the gap I'm closing with this series.

* * *

### What's Next

Splunk is running. Logs are flowing. 76 SSH brute force events are sitting in the index waiting to be detected.

Lab 23 is where the detection rules get built — writing SPL queries targeting SSH authentication failures and configuring real-time alerts. Same logic as Lab 12 in Elastic. Different syntax.

Full lab report and documentation on GitHub: [github.com/RouteToRoot](https://github.com/RouteToRoot)

* * *

*Follow the journey:*  
*GitHub: github.com/RouteToRoot*  
*YouTube: youtube.com/@RouteToRoot\_Sec*  
*Portfolio:* [*routetoroot.io*](http://routetoroot.io)