Snort: a tripwire, not a sink fix (2026)

An IDS only sees the traffic you point at it, and only the signatures or rules you kept current.

Snort and Suricata sit on a span, a tap, or a host. They can tell you a known exploit kit crossed the wire. They cannot authorize an object in your API, and they cannot patch the box that still answers on 22.

The usual mistake is installing a rule pack once and treating the green dashboard as coverage. Rule age and placement matter more than the brand name on the sensor.

This page is what an IDS is for, when Suricata is the current line, and the jobs it does not replace.

OISF marked Suricata 7 end of life on 9 July 2026, with 7.0.17 as the last build in that series. that release note. Snort 3.12.2.0 is the tarball on snort.org downloads as of this writing. Cisco Talos still shipped a certified pack on 18 August 2026. A signature engine that sits inline and drops on the first Emerging Threats hit is not a control. It is a self-inflicted outage.

Be honest about encryption, honest about which engine is still getting builds, and honest that a match is a ticket, not a close. Pair host hardening with this sensor. Pair application bugs with the checklist, not with a new sid.

What a signature engine still sees

Snort and Suricata match bytes they are given against a ruleset. They are not a WAF. They are not sshd. They do not fix CVE-2024-6387. They notice a pattern you already wrote down, or that Talos or Proofpoint already wrote down, and they emit a line.

Most of the public web in 2026 is TLS 1.3. The engine that is not terminating the handshake sees ciphertext. One of the first performance notes in both manuals is still “detect and skip encrypted flows so you do not burn CPU on random bits.” What remains useful without a decrypt hop:

• Cleartext services you should not have published. 21, 23, 80 as the real app, 25 without STARTTLS, a forgotten redis or postgres on a public address.
• Metadata on 443. Dest IP, dest port, SNI if the client still sends it, JA3 or JA4 fingerprints, cert fields on the server hello you can observe from the wire.
• East-west that never got TLS. A container talking HTTP to another container on the same bridge. A backup job on 3306 across a VLAN you thought was empty.
• Volume and fan-out. Twenty SYNs to 22 from one source in a minute. A host that suddenly speaks to a thousand new destinations. That is a threshold, not a payload match.

If the only listener on the host is 443 with a certificate you own, a network IDS will not see the SQL string or the XSS payload. Those belong in the app. See injection and the headers guide. The sensor is for the packet you did not mean to allow, and for the known exploit kit that still hits an old cleartext port.

Snort 3 and Suricata 8 in August 2026

Martin Roesch released Snort in 1998. Cisco has stewarded it since 2013. Snort 3 is the current engine: multi-threaded, new rule language, still GPL. GitHub releases API for snort3/snort3. Tag 3.12.2.0 is dated 23 April 2026. The same tarball is the one snort.org lists under Snort 3 downloads. Talos’s 18 August 2026 advisory still publishes a 2.x subscriber pack (build 2092000) next to 3.x packs. If you are starting in 2026, do not install Snort 2. Install 3.12.2.0 or the distro package that tracks it, then pull Talos or Emerging Threats for that major.

Suricata is the OISF engine. 8.0.0 shipped 8 July 2025. 8.0.6 and 7.0.17 shipped 9 July 2026 as a security release. The same note says 7.0.17 is the last 7.x and tells you to move to 8.0. Suricata 8 is the new deploy: native threads, AF_PACKET, EVE JSON that a log pipe already understands.

Pick one engine. Running both on the same SPAN wastes CPU and doubles the mute list. If you already have Cisco Firepower, Snort 3 is the language that shop speaks. If you are putting a sensor on a Linux tap and you want a JSON line per event, Suricata 8 is the shorter path. Compatibility notes: Suricata still loads most Snort 2.x community rules. Snort 3’s native format is not a drop-in for Suricata. Plan a validation pass with suricata -T or snort -T before you call the ruleset live.

Keep the sensor off the request path

IDS mode is a copy. IPS mode is a bump in the wire. yabones’s May 2022 note is still the right default: copy first. A false positive that only writes a line is a mute. A false positive that drops SYN is a customer outage you will spend a weekend on.

On a switch you admin, mirror the ports that face the app and the ports that face the internet onto a capture NIC. On a single VPS, af-packet on the public interface in IDS mode is enough. Do not insert an nft queue to userspace until you have a week of alerts you have read and a written allow for each drop sid.

# /etc/suricata/suricata.yaml (excerpt, IDS)
af-packet:
 - interface: eth0
 cluster-id: 99
 cluster-type: cluster_flow
 defrag: yes

outputs:
 - eve-log:
 enabled: yes
 filetype: regular
 filename: /var/log/suricata/eve.json
 types:
 - alert
 - anomaly
 - tls
 - dns
 - ssh

Home net must be a list you typed, not any. A rule that fires on “external to $HOME_NET 22” is useful only if $HOME_NET is the prefix you actually own.

# /etc/suricata/suricata.yaml
vars:
 address-groups:
 HOME_NET: "[203.0.113.10/32]"
 EXTERNAL_NET: "!$HOME_NET"

Replace 203.0.113.10/32 with the host or VPC CIDR. If you leave HOME_NET as the stock RFC1918 list on a public VPS, half the rules will never fire and the other half will fire on yourself.

Load a ruleset you can name

A sensor with no rules is a pretty process. A sensor with a 40,000-rule dump you have not read is a noise cannon. Name the feed.

• ET Open. Free. Suricata-native. This is the starting feed I would enable with suricata-update.
• ET Pro. Paid, same-day. Only if you have already operationalized ET Open and still miss coverage you can describe.
• Talos subscriber. Same-day for money, 30-day delay on the free registered feed. Natural fit if the engine is Snort 3.
• A local file you wrote. Thresholds and “this host should never speak 3306 to the internet.” Keep it in git. Give it sids in a range you reserved.

# After: apt-get install suricata suricata-update
sudo suricata-update enable-source et/open
sudo suricata-update
sudo systemctl restart suricata
sudo suricata --build-info | head

A local threshold that is defense, not a payload recipe: many SYNs to 22 from one source. This is a tripwire on password noise after sshd already refuses passwords. It does not replace PasswordAuthentication no.

# /etc/suricata/rules/local.rules
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"LOCAL many SSH SYNs"; \
 flags:S; threshold:type both, track by_src, count 20, seconds 60; \
 classtype:attempted-recon; sid:1000001; rev:1;)

Load local.rules from the yaml rule-files list. Test with suricata -T -c /etc/suricata/suricata.yaml. Do not write a rule that tries to reconstruct an exploit. If you need that class of coverage, take it from ET Open or Talos and mute what you cannot explain.

Write EVE, then page a human

An alert that dies in a ring buffer is theatre. Suricata’s EVE file is one JSON object per line. Point a shipper you already run at /var/log/suricata/eve.json, or have the unit print to journald and pick it up there. The contract is small: event_type is alert, alert.signature_id is the sid, src_ip and dest_ip are the five-tuple you will grep at 02:00.

# Prove a line exists after you restart suricata
sudo journalctl -u suricata -n 20 --no-pager
sudo tail -n 5 /var/log/suricata/eve.json

Page on a small allowlist: your sid:1000001, a Talos or ET sid you have already accepted as high, a sudden zero-alert day that means the sensor died. Do not page on every ET policy hit. That is how the channel goes mute in a week.

Unauthorized use, the phrase in the old title, is a human reading those lines plus the host auth log. A signature will not tell you a contractor still has a key. sshd -T and a review of authorized_keys will. The sensor tells you someone is still knocking on 22 from a net that should be quiet.

CLIENT ---- tcp/443 ----> PROXY ---- 127.0.0.1:8080 ----> APP
 \
 \ SPAN / af-packet copy
 \
 +--> suricata (alert only)
 |
 +-- eve.json
 +-- journald
 +-- page on sid 1000001

Prove a copy of your own traffic alerts

You are not attacking a foreign host. You are proving the sensor on a box you admin emitted a line when you sent traffic you already send.

1. suricata -T or snort -T is clean after the last rules pull.
2. systemctl is-active suricata is active. eve.json is growing, or the journal shows the unit reading packets.
3. From an admin host you own, send twenty TCP SYNs to your own port 22 in a minute. Expect sid:1000001 in EVE. If sshd is not public, run the same count against a lab port you listed in local.rules.
4. Open one TLS session to your own 443. Expect a tls EVE record with SNI, not an HTTP body.

sudo suricata -T -c /etc/suricata/suricata.yaml
systemctl is-active suricata
# From your admin host, against your host only.
for i in $(seq 1 25); do
 timeout 1 bash -c "echo >/dev/tcp/203.0.113.10/22" || true
done
sudo jq 'select(.alert.signature_id==1000001)' /var/log/suricata/eve.json | tail

If EVE is silent, the copy is not arriving, HOME_NET is wrong, or local.rules was not in rule-files. If EVE is a flood of ET policy sids on your own browser, mute those sids. Do not flip the engine to drop to make the file quieter.