Articles

Set Up Snort IDS on Linux for Network Intrusion Detection (2026)

April 16, 2026 7 min read

Snort is a free and open-source network intrusion detection system (NIDS) that monitors network traffic for malicious activity and protocol anomalies. It can detect various types of attacks, including buffer overflows, stealth port scans, and CGI attacks.

Here’s how to set up Snort IDS on a Linux system:

1. Installation

First, you need to install Snort. The installation process varies slightly depending on your Linux distribution.

On Debian/Ubuntu:

sudo apt update
sudo apt install snort

On CentOS/RHEL/Fedora:

You might need to enable EPEL (Extra Packages for Enterprise Linux) repository first:

sudo yum install epel-release
sudo yum install snort

During installation, you might be prompted to configure Snort’s network interfaces. It’s generally recommended to set up Snort to listen on the interface connected to the network segment you want to monitor.

2. Configuration

The main configuration file for Snort is snort.conf, usually located at /etc/snort/snort.conf. You’ll need to edit this file to tailor Snort to your network environment.

a. Network Variables:

Find the ipvar and var sections. The most important one is HOME_NET. This variable defines your internal network(s). Snort uses this to understand what traffic is considered "local" and what is "external."

# Set your internal IP address or network here
ipvar HOME_NET 192.168.1.0/24

If you have multiple internal networks, you can list them:

ipvar HOME_NET [192.168.1.0/24,10.0.0.0/8]

You’ll also want to define EXTERNAL_NET. This is typically set to any to represent all external IP addresses.

# External network variable
var EXTERNAL_NET !$HOME_NET

b. Rule Sets:

Snort’s power comes from its rules. You need to tell Snort where to find these rules and which ones to enable.

First, ensure you have a directory for your rules. By default, Snort might look in /etc/snort/rules.

You’ll need to download the Snort community rules or subscribe to Snort VRT (Vulnerability Research Team) rules. For community rules:

cd /etc/snort/rules
sudo wget https://www.snort.org/rules/snortrules-snapshot-CURRENT.tar.gz
sudo tar -xvzf snortrules-snapshot-CURRENT.tar.gz
sudo rm snortrules-snapshot-CURRENT.tar.gz

Now, in snort.conf, locate the include statements. You’ll want to include the rule files you’ve downloaded. Comment out any default includes and add your own.

# Uncomment and modify these to include your rule sets
# include $RULE_PATH/local.rules
# include $RULE_PATH/community.rules
# include $RULE_PATH/malware-cnc.rules
# include $RULE_PATH/exploit-kit.rules
# include $RULE_PATH/web-attacks.rules
# include $RULE_PATH/sql-injection.rules
# include $RULE_PATH/backdoors.rules
# include $RULE_PATH/dos.rules
# include $RULE_PATH/icmp-info.rules
# include $RULE_PATH/policy.rules
# include $RULE_PATH/scan.rules
# include $RULE_PATH/smtp.rules
# include $RULE_PATH/specific-attack.rules
# include $RULE_PATH/stream5.rules
# include $RULE_PATH/traceroute.rules
# include $RULE_PATH/web-apps.rules
# include $RULE_PATH/web-delays.rules
# include $RULE_PATH/xor.rules

The local.rules file is where you can add your own custom rules.

c. Output Plugins:

Snort needs to know where to log its findings. The default logging is to syslog, but you can configure other outputs. A common and useful output is to a unified2 binary log file, which can be read by tools like barnyard2.

In snort.conf, find the output section. Uncomment and configure the unified2 output:

# Unified2 output to be read by barnyard2
output unified2: filename snort.log, limit 128 MB

You might also want to configure PCAP (packet capture) logging for later analysis:

# PCAP output for full packet capture
output log_pcap: stream_max_bytes 0, stream_age 300, ip_timeouts 0, port_timeouts 0

3. Testing Configuration

Before running Snort in real-time, it’s crucial to test your configuration file for syntax errors.

sudo snort -T -c /etc/snort/snort.conf

This command will parse your snort.conf and report any errors. Fix them before proceeding.

4. Running Snort

You can run Snort in several modes. For basic intrusion detection, you’ll typically run it in packet logging mode, which analyzes traffic and logs alerts.

a. Packet Logging Mode (IDS):

This command runs Snort in IDS mode, listening on interface eth0, reading rules from /etc/snort/rules, and logging to /var/log/snort/.

sudo snort -A console -i eth0 -c /etc/snort/snort.conf -D
  • -A console: Alerts are sent to the console (you can change this to full, fast, or none).
  • -i eth0: Specifies the network interface to listen on. Replace eth0 with your actual network interface name (e.g., ens33, enp0s3). You can find your interface names using ip addr or ifconfig.
  • -c /etc/snort/snort.conf: Specifies the configuration file.
  • -D: Runs Snort as a daemon (in the background).

b. Packet Dump Mode (for testing):

You can also run Snort to simply dump packets to a file, which is useful for testing rule syntax or understanding traffic.

sudo snort -v -d -l /var/log/snort/ -c /etc/snort/snort.conf -i eth0
  • -v: Verbose output (show packet headers).
  • -d: Dump packet payloads.
  • -l /var/log/snort/: Log directory.

5. Viewing Logs

Snort logs are typically stored in /var/log/snort/.

  • Alerts: If you’re using the default syslog output, alerts will go to /var/log/syslog or /var/log/messages. If you configured unified2 output, you’ll need a tool like barnyard2 to process these logs into a more human-readable format (e.g., a database).
  • Packet Captures: If you enabled PCAP logging, you can view the captured packets using tools like Wireshark or tcpdump.

6. Custom Rules

You can create your own rules in /etc/snort/rules/local.rules. A basic rule structure looks like this:

alert tcp any any -> $HOME_NET 80 (msg:"HTTP connection attempt"; sid:1000001; rev:1;)
  • alert: The action to take (can be log, alert, pass, drop).
  • tcp: The protocol (e.g., tcp, udp, icmp, ip).
  • any any: Source IP address and port (any).
  • ->: Direction of traffic.
  • $HOME_NET 80: Destination IP address and port (any IP in your HOME_NET, destination port 80).
  • ( ... ): Rule options.
    • msg:"...": The message to log when the rule triggers.
    • sid:1000001: A unique rule ID (use IDs above 1000000 for local rules).
    • rev:1: Revision number of the rule.

After adding or modifying local rules, remember to test your configuration again: sudo snort -T -c /etc/snort/snort.conf.

barnyard2 is a tool designed to read Snort’s unified2 binary log files and output them to various formats, including relational databases (MySQL, PostgreSQL), syslog, or even back to PCAP. This makes analyzing and querying alerts much easier.

Installation:

# On Debian/Ubuntu
sudo apt install barnyard2

# On CentOS/RHEL/Fedora (might require building from source if not in repos)
# sudo yum install barnyard2

Configuration:

barnyard2 has its own configuration file, usually at /etc/barnyard2/barnyard2.conf. You’ll need to configure database connections if you want to log to a database, and specify the input unified2 log file.

Running Barnyard2:

sudo barnyard2 -c /etc/barnyard2/barnyard2.conf -d /var/log/snort/ -f snort.log -w /var/log/barnyard2/barnyard2.waldo
  • -c: Path to barnyard2 configuration.
  • -d: Directory containing Snort’s unified2 logs.
  • -f: The base filename of the unified2 logs (Snort’s filename snort.log becomes snort.log.12345...).
  • -w: Waldo file to keep track of processed logs.

Once barnyard2 is running and logging to a database, you can use SQL queries to analyze your alerts.

Common Pitfalls

  • Incorrect HOME_NET: This is the most common mistake. If HOME_NET doesn’t accurately reflect your internal network, Snort will misclassify traffic, leading to missed alerts or false positives.
  • Missing or Outdated Rules: Snort is only as good as its rules. Regularly update your rulesets.
  • Interface Configuration: Ensure Snort is listening on the correct network interface that sees the traffic you want to monitor. For monitoring traffic between multiple network segments, Snort needs to be placed strategically (e.g., on a switch SPAN port, or a dedicated monitoring interface).
  • Permissions: Snort often needs to run with root privileges to access network interfaces in promiscuous mode and write to log files. Ensure the user Snort runs as has the necessary permissions.
  • Resource Usage: Snort can be resource-intensive, especially on busy networks with many rules enabled. Monitor CPU and memory usage.

After setting up Snort, the next step is often to fine-tune its ruleset to reduce false positives and ensure it’s catching the specific threats relevant to your environment.

Want structured learning?

Take the full Cdk course →