Splunk Free Setup & First Search Tutorial 2026: Install, Forward & Search

Splunk is a data platform that collects, indexes, and searches time-series machine data — logs, metrics, and events from servers, network gear, endpoints, and applications. For security work it functions as a SIEM: you point every log source at it, then hunt across all of them at once with SPL. Instead of grepping ten boxes over SSH, you ask one question in one place and get answers across your entire estate in seconds.

Everything flows through three logical stages, whether they run on one box (as they do in this lab) or across a cluster:

Four building blocks cover almost everything you will touch in this guide. Understanding which is which saves hours of confusion later — especially the difference between the full Enterprise instance you install once and the lightweight Universal Forwarder you deploy on every machine you want to collect from.

There is no separate "Splunk Free" download — you install Splunk Enterprise, which starts as a 60-day full-feature trial and can be switched to the perpetual Free licence at any point. Free caps indexing at 500 MB/day and drops a handful of enterprise features, but it keeps unlimited search, so it is ideal for learning and small labs.

Splunk's reference server spec is 12+ CPU cores and 12 GB RAM for production indexing, but that is for heavy load. A lab that indexes well under the Free 500 MB/day limit runs fine on the figures below. Give it more RAM if you plan to run Splunk plus other lab VMs on the same host.

Splunk uses a small, fixed set of TCP ports. You will open these in your host firewall and reference them constantly. The three that matter most: 8000 (the web UI you log into), 8089 (management/REST, and how forwarders are administered), and 9997 (the receiving port forwarders send data to).

Everything here is a free download from Splunk once you create a free splunk.com account. Grab the Splunk Enterprise package for your server OS and the matching Universal Forwarder for the machines you will monitor. Versions in this guide target the current 10.x release train.

Best practice is to run Splunk as a non-root user. Create a splunk account, extract the tarball into /opt (which creates /opt/splunk), and hand ownership of that directory to the service account before the first start.

The first start accepts the licence and forces you to set the admin username and password. You can do it interactively, or pre-seed credentials with --seed-passwd for an unattended build. Run these as the splunk user so file ownership stays correct.

Make Splunk survive reboots by registering it as a systemd service. Modern Splunk generates a proper unit file and runs the daemon under your service account. Run the enable command as root, telling it which user to run Splunk as.

Two environment variables are mandatory: SPLUNK_START_ARGS=--accept-license and SPLUNK_PASSWORD (the admin password, minimum 8 characters). Publish port 8000 for the UI and the container boots a full single-instance Splunk Enterprise in a minute or two.

A Compose file gives you a reproducible, persistent Splunk you can tear down and rebuild without losing data. It names the ports, sets the admin password, and mounts two named volumes for the Splunk config (etc) and index data (var). Save this as docker-compose.yml and run docker compose up -d.

Create a VM with the "comfortable lab" spec (4 vCPU / 8 GB / 100 GB), install Ubuntu Server 24.04 LTS with OpenSSH selected, then patch it and set a static IP so your forwarders always know where to send data. A static address is not optional — forwarders are configured to point at a fixed indexer IP.

Inside the VM, perform the identical tarball install from Method 1, then open the Splunk ports in ufw so your browser and forwarders can reach the service. Do this only on an isolated lab network — never expose 8000/8089 to the internet.

Browse to http://<your-server-ip>:8000 and sign in with admin and the password you set at first start. The landing page is the Search & Reporting app. The gear-and-cog Settings menu (top-right) is where all administration lives.

• 1
  Open http://10.10.10.20:8000 in a browser.
• 2
  Log in: admin / the password from --seed-passwd.
• 3
  You land on Apps → Search & Reporting.
• 4
  Note the top nav: Settings (admin), Activity, and the app bar.

By default you are on the 60-day Enterprise trial. To keep the instance alive indefinitely, switch to the Free licence group. This is a deliberate, reversible choice in the licensing UI — you can switch back to a trial or a paid licence later.

Portal: Settings → Licensing → Change license group → Free license

Splunk indexes its own logs into the _internal index from the moment it starts, which is perfect for a first search before you have added any real data. Open the Search app and confirm events are flowing. This proves the search pipeline works end-to-end.

Rather than dumping everything into main, create purpose-built indexes so you can control retention and scope searches. Here we add a Linux and a Windows index. The UI path is quickest, but the CLI is scriptable and shows exactly what happens.

Portal: Settings → Indexes → New Index

The simplest input is a file or directory monitor. On the Splunk server itself you can index its own /var/log to get data flowing immediately, tagging it with a sourcetype and routing it to your Linux index. This is a great smoke test before you deploy forwarders.

Portal: Settings → Data inputs → Files & Directories → New

After adding an input, confirm events are actually indexed before moving on. Search the target index directly. If nothing appears, the input path, permissions, or index name is wrong — catch it now, not three steps later.

The indexer will not accept forwarder traffic until you turn on a receiving port. Enable 9997 once, on the Splunk Enterprise server. This is the step people forget — the forwarder connects, the port is closed, and no data arrives.

Portal: Settings → Forwarding and receiving → Configure receiving → New Receiving Port

On the machine you want to monitor, extract the separate Universal Forwarder package into /opt/splunkforwarder, start it, point it at your indexer, and tell it which logs to ship. The UF is deliberately minimal — no web UI, tiny footprint.

On Windows the UF ships as an MSI that can be driven fully from the command line — ideal for scripted rollout. The install flags set the receiving indexer and enable the Windows event-log inputs (Security, System, Application) in one shot. Run from an elevated prompt.

Back on the indexer, verify the forwarders are actually connecting and sending. The Forwarder Management page lists phoning-home instances, and a quick search against the internal metrics confirms data volume per host.

A search names an index and optional keywords, then filters. Start narrow: pick an index, a sourcetype, and a time range in the picker. Splunk auto-extracts fields you can filter on with field=value. Keep the most selective terms first — it is faster.

Raw events are noise; aggregation is signal. The stats command turns thousands of events into a table — counts, sums, distinct values — and is the workhorse of every useful search. timechart does the same but bucketed over time for trend lines.

A search you re-run is a search worth saving. On the Free licence you cannot schedule alerts, but you can build dashboards that run these searches on demand — turning your hunting queries into a reusable SOC view. Save any good search straight to a dashboard from the results page.

• 1
  Run a search you like (e.g. the brute-force stats above).
• 2
  Click Save As → Dashboard Panel.
• 3
  Create a new dashboard "SOC — Auth Monitoring" and add the panel.
• 4
  Repeat for Windows 4625, add a timechart as a line panel.
• 5
  Open the dashboard any time for an at-a-glance auth view.

The Free licence tolerates occasional overages, but repeated violations within a rolling 30-day window will lock search. Track your daily volume so you can throttle noisy inputs before that happens. These commands and searches are your early-warning system.

Work this table top to bottom before assuming anything exotic — nearly every "no data" problem is a closed port, a permissions issue, or a wrong index name. Splunk's own _internal index almost always contains the error that explains the failure.

You now have a working Splunk indexing real data from Linux and Windows, with searchable indexes and a dashboard. Build on it — more data sources make every future detection tutorial land against a live environment.