Security
Difficulty: Advanced
4 min read

Snort: Network Intrusion Detection (NIDS)

A detailed tutorial to install and configure Snort, a network intrusion detection system (NIDS), to monitor and secure your infrastructure.

Back to tutorials
What is Snort?
Snort is an open-source network intrusion detection and prevention system (IDS/IPS). It analyzes network traffic in real time and compares it against a set of rules to identify malicious activity, port scans, vulnerability exploitation attempts, and other threats. It is one of the oldest and most widely recognized IDS tools.

Why use Snort?

  • Signature-based detection: Very effective at detecting known threats thanks to vast rule sets (official, community, or paid).
  • Three operating modes: It can act as a simple packet "sniffer", a packet logger, or a full intrusion detection system.
  • Mature and stable: It has decades of development and production use behind it.
  • Integration: It can be integrated with other tools (firewalls, SIEM) for automated response.

Prerequisites

  • A Linux server (Ubuntu/Debian) with at least two network interfaces: one for management and one for listening (monitoring).
  • Root access or sudo privileges.

Premium Content

This advanced tutorial is reserved for premium members.

9,90€ / month
  • All advanced tutorials
  • New content every week
  • Progress tracking
  • Cancel anytime

Written by

Morgann Riu

Cybersecurity and Linux administration expert. I share my knowledge through free tutorials and training to help system administrators and developers secure their infrastructures.

Frequently asked questions

Snort is running but no alert ever fires, where do I start?
Three causes account for nearly every case. Rules first: check that var RULE_PATH really points at /etc/snort/rules and that the include $RULE_PATH/local.rules line is uncommented. Then the interface: the -i flag must name the monitoring interface, not the management one, otherwise Snort only watches its own admin traffic. Finally HOME_NET: if the value does not match your real network, rules written against $HOME_NET never match. Start with snort -T -c /etc/snort/snort.conf to rule out a configuration error.
Why does the sensor need two network interfaces?
One carries management traffic (SSH, monitoring) and keeps a reachable address; the other is dedicated to listening to the traffic under inspection, and that is the one you pass to -i. Keeping them apart stops the sensor from analysing its own management flows and lets you place the capture interface on the segment you actually want to watch. In IPS mode you go further and use a pair of interfaces (-i eth0:eth1), since traffic has to cross Snort for it to be blocked.
What is the practical difference between IDS mode and IPS mode?
In IDS mode Snort is passive: it observes traffic on its listening interface and only raises alerts, on the console with -A console or into /var/log/snort. In IPS (inline) mode it is started with -Q --daq afpacket and a pair of interfaces, traffic genuinely flows through it, and rules switched from alert to drop or reject actually block packets. IPS mode is considerably more complex and must be handled with extreme care: an overly broad rule cuts legitimate traffic.
Snort or Suricata for a new deployment?
Suricata is a more modern fork of Snort, designed from the ground up to be multi-threaded, which generally makes it faster on today's multi-core hardware. Snort closed part of the gap with Snort 3, but for a new high-throughput deployment Suricata is often the default pick. Snort still has maturity on its side, with decades of development and production use and a very rich rule ecosystem.
How do I keep the rules current without overwriting my own?
Snort is only worth as much as the freshness of its rules: a frozen rule set stops detecting anything recent. Manually, you download the community rules from the Snort site and drop them into /etc/snort/rules/. In practice you automate it with a rule manager such as Oinkmaster or PulledPork, which fetches and applies updates for you. Keep your own rules in local.rules, separate from the official rule files, so an update never wipes them out.

Share this tutorial

Did you enjoy this article?

Comments

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.