October 14, 2026
Integrating Snort 3 with Splunk Enterprise: A Practical Network Intrusion Detection Lab
Author: Abhinav Sabu
By Abhinavsabuk
7 min read
Abstract
Network intrusion detection systems generate valuable security alerts, but those alerts become more useful when security analysts can search, investigate, and correlate them in a centralized platform. This article documents a practical lab integrating Snort 3, an open-source network intrusion detection and prevention system, with Splunk Enterprise, a platform for searching and analyzing machine data.
The implementation uses Kali Linux to run Snort 3 and Windows to host Splunk Enterprise. A Splunk Universal Forwarder collects Snort's alert log and forwards the events over TCP port 9997. A custom ICMP detection rule is used to generate test alerts, and the successful ingestion of those alerts into Splunk is verified.
The objective is to demonstrate the complete alert-ingestion workflow in a small, educational security lab.
Keywords: Snort 3, Splunk Enterprise, SIEM, IDS, network security monitoring, SOC, Universal Forwarder, ICMP detection.
1. Introduction
Modern networks generate large amounts of traffic, making manual inspection difficult. Security teams use intrusion detection systems (IDS) to inspect network activity and identify traffic that matches known detection rules or suspicious patterns.
Snort is an open-source network intrusion detection and prevention system. It uses rules to identify traffic of interest and can generate alerts when those rules match.
However, generating alerts is only one part of security monitoring. Analysts also need a practical way to collect those alerts, search historical events, identify recurring detections, and investigate suspicious activity.
Splunk Enterprise provides a centralized platform for searching and analyzing machine-generated data. By forwarding Snort alerts to Splunk, we can move from viewing individual alerts in a terminal to searching them through a centralized interface.
This project demonstrates that integration using a simple, reproducible lab.
2. Objectives
The primary objectives of this lab were:
- Deploy Snort 3 on Kali Linux.
- Create a custom rule to detect ICMP traffic.
- Configure Snort to write alerts to a local log file.
- Configure the Splunk Universal Forwarder to monitor the log file.
- Configure Splunk Enterprise to receive forwarded events.
- Verify that Snort alerts become searchable in Splunk.
This was an educational integration exercise. It did not implement automated incident response, firewall blocking, or production-grade threat detection.
3. Lab Architecture
The lab contains three main components: Snort, the Universal Forwarder, and Splunk Enterprise.
Kali Linux runs Snort and generates the alert log. The Universal Forwarder monitors that log and sends its events to the receiving Splunk instance on Windows.
The architecture is:
Kali Linux → Snort 3 → Alert Log → Splunk Universal Forwarder → TCP Port 9997 → Splunk Enterprise on Windows
Component 1: Snort 3
Snort inspects network packets visible to its selected network interface and evaluates them against configured detection rules. When a rule matches, Snort can generate an alert.
Component 2: Splunk Universal Forwarder
The Universal Forwarder collects selected machine data and forwards it to a configured Splunk receiver. In this lab, it monitors Snort's alert file rather than inspecting packets itself.
Component 3: Splunk Enterprise
Splunk Enterprise receives and indexes the forwarded events, making them available for searching and analysis through Splunk Web.
Official references:
- Snort alert logging: https://docs.snort.org/start/alert_logging
- Splunk receiver configuration: https://help.splunk.com/en/data-management/forward-data/universal-forwarder-manual/9.4/configure-the-universal-forwarder/enable-a-receiver-for-splunk-enterprise
4. Environment and Configuration
The following environment was used during the lab.
Component Configuration:
IDS-Snort 3.12.2.0 IDS
operating system-Kali LinuxIDS
network-interfaceeth0
IDS configuration/etc/snort/snort.lua
Local rules/etc/snort/rules/local.rules
Alert file/var/log/snort/alert_fast.txt
Forwarder-Splunk Universal Forwarder 10.6.0.5
SIEM-Splunk Enterprise on WindowsReceiving portTCP 9997
Forwarding destination192.x.x.x:9997Test signatureLAB ICMP test alert
These values describe this particular lab, not mandatory settings for every Snort–Splunk deployment. The IP address above is a placeholder and must be replaced with the appropriate destination address when configuring a lab.
An important implementation detail is that the Windows installation of Snort 2.9.20 initially failed with error 0xC000007B. The investigation indicated a possible executable and DLL architecture mismatch. Rather than spending more time repairing that installation, the lab was continued with Snort 3 on Kali Linux while keeping Splunk Enterprise on Windows.
This change allowed the integration to be tested without making the Windows Snort installation a dependency.
5. Configuring Snort 3
Snort 3 uses a Lua-based configuration system. The configuration file specifies which modules are enabled, which rule files are loaded, and how alerts are generated.
The configuration used in this lab included the local rule file:
ips.rules = [[
include /etc/snort/rules/local.rules
]]ips.rules = [[
include /etc/snort/rules/local.rules
]]This allowed a custom rule to be maintained separately from the main configuration.
5.1 Creating the custom ICMP rule
The following rule was added to local.rules:
alert icmp any any -> any any ( msg:"LAB ICMP test alert"; sid:1000001; rev:1; )alert icmp any any -> any any ( msg:"LAB ICMP test alert"; sid:1000001; rev:1; )The rule fields have the following meanings:
alert: generate an alert when the rule matches.icmp: match ICMP traffic.any any: allow any source address and source port specification.-> any any: match traffic in the specified direction toward any destination address and port specification.msg: provide a readable alert message.sid: assign a signature identifier to the rule.rev: identify the rule revision.
The rule is deliberately broad. It was designed to validate the detection and forwarding pipeline, not to identify malicious ICMP traffic specifically.
Snort's official rule-writing guide explains the structure of rule headers and rule options:
https://docs.snort.org/start/rules
5.2 Enabling alert output
The Snort configuration was updated to enable the fast alert logger:
alert_fast = { file = true }alert_fast = { file = true }Snort was then launched with:
sudo snort -c /etc/snort/snort.lua -i eth0 -A alert_fast -l /var/log/snortsudo snort -c /etc/snort/snort.lua -i eth0 -A alert_fast -l /var/log/snortThe options specify the configuration file, the interface to monitor, the alert output format, and the log directory.
Snort created the file:
/var/log/snort/alert_fast.txt/var/log/snort/alert_fast.txtThe generated alerts included the custom message and signature identifier. This confirmed that the detection rule was matching traffic and that Snort was writing alerts to the configured file.
The fast alert logger produces concise, human-readable events containing information such as the alert timestamp, rule identifier, message, protocol, and available traffic details.
6. Configuring Splunk Enterprise to Receive Events
Snort was generating alerts locally, but those events still needed to reach Splunk.
Splunk's Universal Forwarder uses a configured receiving endpoint to send collected data to Splunk Enterprise. The conventional receiving port used in this lab was TCP 9997.
The receiving port was enabled in Splunk Enterprise on Windows.
The Windows system's lab IP address is represented here as:
192.x.x.x192.x.x.xThe forwarder's destination was configured as:
192.x.x.x:9997192.x.x.x:9997A basic connectivity test was performed from Kali Linux:
nc -vz 192.x.x.x 9997nc -vz 192.x.x.x 9997The test reported that the port was open. This verified network-level reachability at the time of testing, although port reachability alone does not prove that events are being indexed.
Splunk's official documentation explains receiver configuration and the use of port 9997:
7. Configuring the Universal Forwarder
The Universal Forwarder was configured on Kali Linux to monitor the Snort alert file.
The following command was used:
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/snort/alert_fast.txt -sourcetype snort:alertsudo /opt/splunkforwarder/bin/splunk add monitor /var/log/snort/alert_fast.txt -sourcetype snort:alertThe command adds the file as a monitored input and assigns the source type snort:alert.
The source type helps identify the kind of data being ingested and makes it easier to target these events in searches.
The configured forward server was checked using:
sudo /opt/splunkforwarder/bin/splunk list forward-serversudo /opt/splunkforwarder/bin/splunk list forward-serverThe output showed:
Active forwards:
192.x.x.x:9997
Configured but inactive forwards:
NoneActive forwards:
192.x.x.x:9997
Configured but inactive forwards:
NoneThis indicated that the Universal Forwarder had an active forwarding connection to the Windows Splunk receiver.
The forwarder was responsible for collecting the alert file and transporting its events. Snort itself did not send events directly to Splunk.
Splunk's documentation describes the relevant forwarder configuration files and commands:
8. Verifying the Integration in Splunk
A working network connection is not sufficient evidence of successful ingestion. The final test was to search for the actual custom alert in Splunk Enterprise.
Splunk Web was opened on the Windows machine, and the Search & Reporting interface was used to run:
index=* "LAB ICMP test alert"index=* "LAB ICMP test alert"The search returned 29 matching events in the lab screenshot.
The events were associated with the snort:alert source type and the Kali host. This was the most important verification step because it demonstrated that the custom Snort alert had moved beyond the local log file and become searchable in Splunk.
The validation process covered three separate stages:
- Detection: Snort matched the custom ICMP rule.
- Collection and forwarding: the Universal Forwarder monitored the alert file and maintained an active forwarding connection.
- Searchability: Splunk returned the custom alert events in its search interface.
Together, these results confirmed that the basic Snort-to-Splunk alert-ingestion pipeline worked.
9. What the Integration Demonstrates
The lab demonstrates how an IDS can supply detection events to a SIEM without requiring the IDS and SIEM to run on the same operating system.
Snort was responsible for packet inspection and rule-based detection. The Universal Forwarder collected the resulting log data. Splunk Enterprise provided centralized search.
This separation is useful because the detection engine and the analysis platform have different responsibilities.
It also makes troubleshooting easier. If Snort generates alerts but Splunk does not show them, the investigator can check the alert file, the monitored input, the forwarding connection, the receiving configuration, and the search query as separate stages.
10. Limitations and Future Improvements
Although the integration worked, several improvements would be needed before treating it as a more complete monitoring solution.
10.1 The test rule is intentionally broad
The custom rule matches ICMP traffic generally. It is useful for confirming that the pipeline works, but it can generate noisy alerts and should not be treated as a reliable indicator of malicious activity.
A future version could use more specific rules and test them against controlled traffic.
10.2 Alert data is not yet fully normalized
The current setup ingests Snort's fast text alerts. A future iteration could evaluate Snort's JSON output, which can include fields such as timestamps, protocols, source and destination addresses, rule identifiers, and actions.
Structured data can make field extraction, aggregation, dashboards, and alert correlation easier. The exact fields depend on the selected output configuration.
10.3 No production detection validation was performed
The lab verified a custom ICMP rule and successful event ingestion. It did not establish detection accuracy against a representative dataset, measure false-positive rates, or demonstrate coverage of real-world attacks.
10.4 No automated response was implemented
The integration does not block traffic, modify firewall rules, or automatically respond to alerts. Such capabilities would require additional components, careful authorization, and separate testing.
10.5 No performance or reliability benchmark was conducted
The test confirmed that events reached Splunk, but it did not measure ingestion latency, packet loss, throughput, or behavior under sustained high alert volumes.
These limitations define reasonable next steps rather than failures of the integration objective.
11. Conclusion
This lab successfully demonstrated the integration of Snort 3 with Splunk Enterprise using a Splunk Universal Forwarder.
Snort generated alerts from a custom ICMP rule on Kali Linux, wrote those alerts to a local file, and the Universal Forwarder monitored that file and forwarded the events to Splunk Enterprise on Windows over TCP port 9997.
The final search returned 29 matching events, providing evidence that the alerts were available in Splunk for further analysis.
The main lesson is that security monitoring requires more than generating detections. Collecting, transporting, and making those detections searchable is an important part of building a useful monitoring workflow.
This project provides a foundation for future work involving structured alert parsing, more specific detection rules, dashboards, and SOC-style alert investigation.