Building a Network IDS Lab

What Are Snort and Splunk?

Snort: The Network Watchdog

Snort is an open-source Network Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) developed by Cisco Talos. Think of it as a security camera for your network—it watches all traffic passing through and alerts you when it sees something suspicious based on rules you define.

Snort analyzes network packets in real-time, comparing them against a database of known attack signatures. When it detects malicious activity like port scans, SQL injection attempts, or SSH brute-force attacks, it generates alerts that can be logged for analysis.

Splunk: The Security Brain

Splunk is a powerful Security Information and Event Management (SIEM) platform that collects, indexes, and analyzes machine-generated data. It's like having a super-intelligent analyst that can process millions of log entries, find patterns, and present them in easy-to-understand dashboards.

For security operations, Splunk is invaluable because it centralizes logs from multiple sources (firewalls, IDS, servers, applications) and allows you to correlate events, detect threats, and investigate incidents—all from one interface.

Project Architecture

Here's how everything fits together in this lab:

• Ubuntu VM: Runs Snort IDS and Splunk Universal Forwarder
• Snort IDS: Monitors network traffic and generates alerts
• Splunk Universal Forwarder: Collects Snort logs and forwards them to Splunk Enterprise
• Splunk Enterprise (Linode Cloud): Receives, indexes, and analyzes logs
• Attack Machine: Kali Linux for testing detection rules

Part 1: Setting Up Splunk Enterprise

I hosted Splunk Enterprise on Linode's cloud platform, which provides $100 in free credit—perfect for this project. The marketplace deployment made setup incredibly easy.

Configuring Data Reception

First, I configured Splunk to receive forwarded data on port 9997:

Verified that port 9997 was open in the firewall, then accessed Splunk at http://[SPLUNK_IP]:8000 and navigated to Settings → Forwarding and Receiving → Configure Receiving to add a new receiver on port 9997.

Installing Snort Alert App

I installed the "Snort Alert for Splunk" app from Splunkbase, which provides pre-built dashboards and visualizations specifically designed for Snort data. This app makes analyzing IDS alerts much more intuitive.

Part 2: Installing and Configuring Snort

Installation

During installation, Snort prompts for your network's CIDR range (e.g., 192.168.1.0/24). This defines your "HOME_NET"—the network Snort will protect.

Configuring snort.conf

The /etc/snort/snort.conf file is Snort's brain. I made key modifications:

Key changes:

• Set ipvar HOME_NET to my Ubuntu VM's IP address
• Commented out all default rules
• Added my custom rule file: include $RULE_PATH/my_custom.rules

Part 3: Writing Custom Snort Rules

This is where things got really interesting. I created custom detection rules for various attack types. Here's what I built:

ICMP Ping Detection

Rule Breakdown: This detects ICMP Echo Requests (Type 8) from external networks to internal hosts. Perfect for identifying reconnaissance activity.

SSH Brute-Force Detection

Rule Breakdown: Triggers when 5+ SSH connection attempts occur from the same source within 60 seconds—a clear indicator of brute-force attacks.

Nmap Scan Detection

Rule Breakdown: These detect various Nmap scanning techniques by analyzing TCP flags. SYN scans (stealth scans), Xmas scans (FIN, PSH, URG flags), Null scans (no flags), and FIN scans are all covered.

SQL Injection Detection

Rule Breakdown: Detects a specific SQL injection payload (' OR '1'='1') commonly used to bypass authentication.

XSS Attack Detection

Rule Breakdown: Identifies Cross-Site Scripting attempts by looking for encoded <script> tags and JavaScript alert payloads in HTTP requests.

Part 4: Splunk Universal Forwarder Setup

To get Snort logs into Splunk, I installed the Universal Forwarder on the Ubuntu VM:

Installation

Downloaded the 64-bit .deb package from Splunk's website and installed it. Then configured it to forward to my Splunk Enterprise server:

Configuring Log Monitoring

Added Snort's alert log to the forwarder:

Editing inputs.conf

Modified the forwarder configuration to properly tag Snort alerts:

This tells Splunk to treat the logs as Snort alerts, enabling the pre-built visualizations in the Snort app.

Part 5: Testing the Detection Rules

Time to put the system to the test! I used a Kali Linux attack machine to generate various types of malicious traffic.

Starting Snort

First, I ran Snort in IDS mode:

Command Breakdown:

• -q: Quiet mode (reduces console output)
• -l: Log directory
• -i: Network interface to monitor
• -A full: Full alert mode (detailed logging)
• -c: Configuration file path

Test 1: ICMP Ping Detection

From Kali, I sent ping requests:

Result: Snort detected the ICMP packets and generated alerts. In Splunk, I could see each ping logged with source IP, destination IP, and timestamps. The "Ping Request Detected" message appeared exactly as configured.

Test 2: SSH Brute-Force

Using Hydra to simulate a brute-force attack:

Result: After five connection attempts within 60 seconds, Snort triggered the "SSH Brute Force Attempt" alert. Splunk showed multiple alerts clustering from the same source IP—exactly the behavior you'd want to investigate in a real SOC.

Test 3: Nmap Scanning

Performed various Nmap scans:

Result: Snort caught every scanning technique—SYN scans, Xmas scans, Null scans, and FIN scans. The Splunk dashboard showed a spike in scan-related alerts, and I could drill down to see which ports were being probed.

Test 4: SQL Injection

I set up DVWA (Damn Vulnerable Web Application) on the Ubuntu machine and attempted SQL injection:

Result: Snort immediately detected the malicious payload in the HTTP request. The alert included the full URL with the injection attempt, making incident analysis straightforward.

Test 5: XSS Attack

Injected a Cross-Site Scripting payload:

Result: The XSS detection rule fired, capturing the encoded script tags and alert payload. In a real environment, this would immediately flag potential web application exploitation.

Analyzing Data in Splunk

This is where the magic happens. With all alerts flowing into Splunk, I had incredible visibility into network activity.

Snort Event Summary Dashboard

The Snort Alert for Splunk app provides a pre-built dashboard showing:

• Events and Sources Over Time: A timeline graph showing alert spikes
• Top Source Countries: Geographic distribution of attackers
• Event Counts: Total number of detected events
• Top Classifications: Most common attack types
• Event Types by Signature: Breakdown of specific rules triggered

After my testing, the dashboard showed 9,260 total events—mostly from my scanning and injection attempts. The visualization made it immediately obvious when attacks occurred and what types of attacks were most common.

Custom Field Extraction

I created custom field extractions for source IP addresses and timestamps, making it easier to filter and analyze specific attackers or time periods. This is crucial for incident response—you want to quickly answer questions like "Show me all activity from this IP" or "What happened between 2 AM and 3 AM?"

Lessons Learned and Best Practices

Rule Writing is an Art

Writing effective Snort rules requires balancing sensitivity with false positives. Too sensitive, and you'll be drowning in alerts. Too loose, and you'll miss real attacks. I learned to:

• Use thresholds for noisy rules (like scan detection)
• Be specific with content matches to reduce false positives
• Test rules thoroughly before deploying to production
• Document each rule's purpose and expected behavior

Log Management Matters

Snort generates a LOT of data. Without proper log rotation and management, you'll quickly fill up disk space. In production environments, you'd want:

• Automated log rotation
• Retention policies based on compliance requirements
• Archive strategies for historical analysis

Tuning is Continuous

This project taught me that IDS deployment isn't "set it and forget it." You need to continuously tune rules based on your environment. What's normal traffic in one network might be malicious in another.

Integration is Key

Having Snort generate alerts is only useful if someone sees them. Integration with Splunk made the difference between having raw log files and having actionable intelligence. The visualizations, search capabilities, and alerting features transformed Snort from a detection tool into a security monitoring platform.

Real-World Applications

While this was a lab environment, the skills and setup directly translate to real SOC (Security Operations Center) work:

• Threat Hunting: Use Splunk queries to proactively search for IOCs (Indicators of Compromise)
• Incident Response: Quickly investigate alerts and determine if they're genuine threats
• Compliance Monitoring: Demonstrate to auditors that you're monitoring for specific attack types
• Security Posture Assessment: Identify which attacks are most common against your infrastructure

Next Steps and Improvements

If I were to expand this project, I'd add:

• Multiple sensors: Deploy Snort on different network segments
• Automated response: Configure Splunk to trigger automated blocking via firewall
• Machine learning: Use Splunk's ML toolkit to detect anomalies
• Correlation rules: Create alerts that fire when multiple suspicious events occur
• External threat intelligence: Integrate threat feeds into Splunk

Conclusion

Building this Snort + Splunk integration lab was an incredible learning experience. I gained hands-on experience with two of the most important tools in defensive security, learned how to write effective detection rules, and saw firsthand how SIEM platforms transform raw logs into security intelligence.

The troubleshooting process was valuable too—nothing worked perfectly the first time, and debugging configuration issues taught me more than following a perfect guide would have. Every error message was a learning opportunity.

If you're studying for certifications like PNPT, CySA+, or pursuing a career in defensive security, I highly recommend building a similar lab. The hands-on experience is invaluable, and you'll have something concrete to discuss in job interviews.

[ IDS DEPLOYED ] - [ THREATS DETECTED ] - [ LOGS ANALYZED ] - [ NETWORK SECURED ]