Snort 2 is finished. On October 21, 2026, Cisco Talos declared every open-source Snort 2 release end of life and stopped writing rules for it, according to Mallory’s report on the Snort 2 end-of-support notice. That turns the old IDS vs IPS debate into a live deadline for any team still running 2.9.x sensors.
The question itself has not changed. An intrusion detection system (IDS) watches traffic and raises alerts. An intrusion prevention system (IPS) sits in the traffic path and drops or rejects packets on its own. What has changed in 2026 is the tooling underneath both ideas. Suricata 8.0.7 is the stable release, Snort 3.12.4.0 is the fixed Snort line, Zeek 9.0 shipped as a long-term support release, and CrowdSec has moved toward web application firewall and bot detection. If you already followed our Suricata IDS/IPS setup walkthrough, this piece is the decision layer on top of it.
Here is the short version of what follows. We compare IDS and IPS as deployment modes, then line up four open-source engines on roles, rule models, lifecycle status, and cost. We cover real incidents and release notes from the last three months, give six use-case recommendations, and finish with a migration plan and a verdict. One caution up front: we found no independent, current throughput benchmark we trust for these four tools, so the performance section explains how to measure your own traffic instead of repeating vendor numbers.
- IDS is passive and safe to deploy first. An IPS is inline and can stop attacks, but it can also break production traffic.
- Suricata 8.0.7 and Snort 3.12.4.0 are the two engines that can do both jobs.
- Zeek is a network monitor, not an inline IPS. It produces the logs that make alerts explainable.
- CrowdSec blocks through remediation components called bouncers rather than by inspecting every packet.
- Snort 2 and Suricata 7 are both retired in 2026. Neither belongs in a new build.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
IDS vs IPS: The Core Difference in Plain Terms
The difference is placement and authority. An IDS receives a copy of traffic, usually from a switch mirror port (SPAN) or a network tap, and it can only tell you what it saw. An IPS receives the live packets, makes a verdict on each flow, and forwards, drops, or rejects the traffic itself. The same detection engine can often run in either mode, which is why Suricata and Snort both appear on both sides of the comparison.
That placement choice drives everything else. A passive sensor cannot add latency to a user session, so a rule mistake costs you an annoying alert. An inline sensor sits in the forwarding path, so a rule mistake or a crash can cost you an outage. Most mature teams therefore run detection first, tune for weeks, and only then promote a small set of high-confidence rules to blocking.
| Dimension | IDS (detection) | IPS (prevention) |
|---|---|---|
| Traffic path | Out of band, fed by a tap or SPAN port | Inline, between the source and the destination |
| Action on a match | Alert, log, notify an analyst | Drop, reject, reset, or rate limit, plus alert |
| Effect of a false positive | Analyst time wasted | Legitimate traffic blocked |
| Effect of a sensor failure | You lose visibility | You can lose connectivity unless fail-open is configured |
| Latency impact | None on user traffic | Added to every inspected packet |
| Rollout risk | Low | Medium to high |
| Tuning effort | Moderate, can be done at leisure | High, must be done before blocking |
| Best first step for a new network | Yes | No, promote to it later |
Many buyers also assume IPS is simply a better IDS. It is not. An IPS trades visibility for authority, and an IDS often provides richer context because it can afford to log everything without worrying about the forwarding path. The strongest designs use both: inline blocking for the narrow set of attacks you are certain about, and passive monitoring for the long tail of suspicious behavior you want a human to review.
How an IDS Works: Passive Watching and Alerting
A network IDS reads packets from a capture interface, reassembles flows, decodes protocols, and compares what it sees against detection logic. For signature engines like Suricata and Snort, that logic is a rule: a pattern for a payload, a protocol field, a port, or a combination of these. When a rule fires, the engine writes an alert. For Zeek, the logic is a script that reacts to protocol events and writes structured logs, whether or not anything looks malicious.
Passive deployment has a practical advantage that gets underrated: you can replay history. Because the sensor reads a copy of traffic, you can feed the same packet capture through a new rule set in a lab, compare alert counts, and decide whether a rule is worth promoting. You cannot do that safely against production traffic with an inline device. Teams that skip this step usually learn about their noisiest rules by watching a help desk queue fill. If you want a passive build to practice on, our 13-step Suricata IDS build covers interface setup, rule updates, and alert checks with zero inline risk.
Passive monitoring also has blind spots. Encrypted traffic hides payloads, so signature matching on content loses power as TLS adoption grows. Modern sensors respond by analyzing metadata instead. Zeek 9, for example, adds policy script support that writes fields describing the TLS 1.3 Encrypted Client Hello extension to its ssl.log, according to the project’s own release notes. That is not decryption. It is a reminder that visibility now depends on what the handshake leaks, not on what the payload says.
The cost of an IDS is mostly human. Every alert needs a triage owner, and an unreviewed alert stream is worth almost nothing. If your team cannot staff review, an IDS alone gives you a false sense of coverage. In that case the case for managed detection, or for automated blocking with a tool like CrowdSec, gets stronger. We cover that trade-off in the use-case section below.
How an IPS Works: Inline Blocking and Its Risks
An IPS needs the traffic to flow through it. On Linux, that usually means one of two patterns. In the first, the kernel hands packets to a user-space engine through a queue (NFQUEUE is the common mechanism), the engine returns a verdict, and the kernel acts on it. In the second, the engine bridges two interfaces and forwards traffic itself. Both Suricata and Snort 3 support inline operation, and Cisco embeds Snort 3 in its own firewalls for the same purpose.
Inline mode raises three risks that do not exist for passive sensors. The first is availability: if the engine hangs, so does the traffic. The second is correctness: a rule written for detection can be too broad to block safely. The third is operational drift: a kernel, driver, or engine update can change queue behavior. That last risk is not theoretical. In early October 2026, community forum threads reported that Suricata 8.0.7 running in NFQUEUE mode could leave outbound TCP connections hanging in some setups, and separate reports described packet loops when workers mode, repeat mode, and verdict batching were combined. Those are user reports, not confirmed project defects, but they show why you test an upgrade in a staging path before you put it in front of production.
Good IPS design answers three questions before the first packet is dropped. What happens when the sensor crashes (fail-open or fail-closed)? Which rules are allowed to block, and who approved them? How fast can you switch from blocking back to alert-only? If you cannot answer the third question in under a minute, you are not ready for inline mode.
Firewall-embedded IPS follows the same logic with less tinkering. Cisco’s IOS XE 26.2.x documentation, for instance, describes Catalyst NGFW replacing the older UTD engine’s signature-package workflow with separately managed Talos Lightweight Security Package and Vulnerability Database packages. You trade engine control for a vendor-managed update path, which suits many branch offices and annoys few of them.
Specs Compared: Suricata vs Snort 3 vs Zeek vs CrowdSec
These four tools are often listed together, yet they do different jobs. Suricata and Snort 3 are signature-driven IDS/IPS engines. Zeek is a network security monitor that turns traffic into logs and does not block inline. CrowdSec analyzes logs and community signals, then pushes block decisions to enforcement points. The table below separates what each tool is from what each tool can do in an IDS or IPS role. Version cells use the newest releases we could confirm on October 26, 2026.
| Attribute | Suricata | Snort 3 | Zeek | CrowdSec |
|---|---|---|---|---|
| Newest confirmed release | 8.0.7 (Sept. 15, 2026) | 3.12.4.0 (Oct. 2026 hardening) | 9.0 LTS (Sept. 17, 2026) | 1.8 (Sept. 1, 2026) |
| Primary role | Network IDS, IPS, and monitoring engine | Network IDS and IPS engine | Network security monitor | Collaborative detection and remediation |
| Inline blocking | Yes, in IPS mode | Yes, in inline mode | No, monitoring focus | Yes, through bouncers |
| Passive monitoring | Yes | Yes | Yes, its core use | Not packet based |
| What it inspects | Packets and flows | Packets and flows | Packets and flows | Logs and signals |
| Detection model | Signature rules with protocol-aware keywords | Signature rules with inspector plug-ins | Event-driven scripts and protocol analyzers | Behavior scenarios plus shared blocklists |
| Main output | Alerts and structured logs | Alerts and logs | Rich protocol logs | Block decisions and alerts |
| Rule or content source | Community and third-party rule sets | Free Community Ruleset or paid Subscriber Ruleset from Talos | Scripts and packages | Community-shared threat intelligence |
| Typical placement | Tap, SPAN port, or inline gateway | Tap, inline, or inside Cisco firewalls | Tap or SPAN port feeding a SIEM | On each server or edge host |
| Maintainer | Open Information Security Foundation (OISF) | Cisco Talos | The Zeek Project | CrowdSec (company-led open source) |
| Prior line status | Suricata 7 retired July 9, 2026 | Snort 2 retired Oct. 21, 2026 | 8.0.x ends when 9.1 ships | No retirement confirmed |
| Best fit | General-purpose IDS and IPS | Cisco-centric shops, Talos rule users | Threat hunting and forensics | Internet-facing servers and web apps |
Read the table by role, not by column. If your question is whether a tool can block, only three of the four answer yes, and CrowdSec answers it differently from the other two. If your question is whether you can investigate afterward, Zeek leads by design because it records more than it judges. Most real deployments combine at least two of these tools, which is why the same names keep appearing together.
Current Versions and Lifecycle Status in October 2026
Lifecycle status matters more than feature lists right now, because two of the four tools retired a major line this year. Running a retired engine means no new rules, no security fixes, and awkward audit conversations. The table summarizes where each project stood on October 26, 2026.
| Project | Current line | Retired or sunsetting | What to do |
|---|---|---|---|
| Suricata | 8.0.7, released Sept. 15, 2026 | Suricata 7 reached end of life on July 9, 2026 with 7.0.17 as its final release | Upgrade to Suricata 8 |
| Snort | Snort 3.12.4.0 | Snort 2 reached end of life and end of support on Oct. 21, 2026 | Migrate to Snort 3 |
| Snort 3 earlier builds | 3.12.4.0 supersedes 3.12.2.0 | Older 3.x builds lack the October hardening fixes | Update to the fixed release |
| Zeek | 9.0 LTS, released Sept. 17, 2026 | 8.0.x stops receiving updates when 9.1 ships, expected about four months after 9.0 | Plan the move to 9.x |
| Suricata 9 | Development only | Not a release | Do not deploy |
| Zeek 9.1 | Under development | Not a release | Do not deploy |
Snort 2: retired, with a Snort 3 security release behind it
Cisco published its October Snort 3 hardening release on October 21, 2026, and the related advisory was updated on October 26. Cisco’s advisory names Snort 3.12.4.0 as the fixed release for the affected 3.x line. Cisco’s notes reportedly group several out-of-bounds write issues under CVE-2026-20043, and a separate advisory covers a denial-of-service risk tied to Visual Basic for Applications parsing. Snort 3.12.2.0, which a secondary article described as current in April, is now superseded. If you maintain Snort rules under a Talos subscription, rule updates keep arriving often, and the October 16 Talos rule advisory is one example of that rhythm.
Suricata 7 and Zeek 8: shorter runways than people expect
Suricata announced on July 9, 2026 that 7.0.17 was the last release in the 7.x series, and the project told users to move to Suricata 8. Zeek’s schedule is similar in spirit. The project says its 9.0.x series will receive security fixes and relevant backports for a bit over a year, while 8.0.x will stop receiving updates once 9.1 ships. If your change windows are quarterly, put both dates on the calendar now. A sensor that falls two versions behind is also harder to upgrade, because configuration keys and log fields drift.
Detection Methods: Signatures, Protocol Logs, and Reputation
Signature detection remains the backbone of both IDS and IPS. A rule describes something known to be bad: an exploit string, a command-and-control beacon pattern, a malformed header. The strength is precision. When a good rule matches, you can say exactly what you saw. The weakness is coverage, because a signature cannot describe an attack nobody has written down yet.
Suricata and Snort 3 differ in style but not in philosophy. Both let you write rules that combine protocol fields, content matches, and flow state. Suricata has leaned into protocol-aware keywords. One recent example is the subslice keyword and its prefilter work, described in a technical post the project published, which you can read in the Suricata keyword highlight on subslice. The post does not establish that the keyword is a finished feature in every build, so check release notes before you depend on it. The Suricata team also published an article on September 29 explaining why it supports Vectorscan, a pattern-matching library.
Zeek takes a different route. Rather than asking whether a packet matches a rule, it asks what just happened on this connection, then writes the answer to a log. Detection happens afterward, either in Zeek scripts or in the SIEM that reads the logs. This design is slower to produce a first alert and much better at answering a question like which internal hosts spoke to a given domain in the last 30 days. Zeek is also scriptable. A project published in October 2026 used it to watch environmental readings in a biological incubator, flagging a 37.0 C reading as normal and a 37.8 C reading as critical. Nobody would call that an IDS, which is exactly the point.
CrowdSec represents the third approach, reputation and behavior. Its Security Engine reads logs such as web server or SSH logs, applies scenarios that describe bad behavior like brute-force attempts, and shares the resulting signals with the community. Bouncers then enforce decisions at a firewall, a reverse proxy, or a web server. CrowdSec said in mid-October 2026 that roughly 250,000 machines were actively protected, a company-reported figure that it did not define precisely. The model works well against noisy internet scanning and credential attacks. It does not replace deep packet inspection for lateral movement inside a network.
Performance and Benchmarks: What the Evidence Supports
Most Suricata vs Snort benchmark posts are old, run on different hardware, and use different rule sets, so they compare configurations rather than engines. We looked for a current, independent throughput study covering Suricata 8.0.7, Snort 3.12.4.0, and Zeek 9.0 on the same hardware and found none we would stand behind. We are not going to publish a speed ranking we cannot support. That leaves three useful statements.
- Rule count dominates. A sensor with a few hundred tuned rules behaves very differently from the same sensor with tens of thousands of enabled rules. Published speeds that do not state the rule set are not comparable.
- Traffic shape dominates. Many small packets, long-lived flows, and heavy TLS handshakes each stress different parts of the engine.
- Mode dominates. Inline mode adds a verdict round trip per packet or batch. The NFQUEUE reports mentioned earlier show that queue settings can matter as much as the engine.
The honest way to compare is to replay your own traffic. Capture a representative window, then run each engine against the same capture with the same rule intent. The commands below show the shape of that test. Adjust interface names and paths for your system.
# Offline run: Suricata reads a capture file and reports alerts and timing
suricata -c /etc/suricata/suricata.yaml -r capture.pcap -l /tmp/suri-out
# Offline run: Snort 3 reads the same capture
snort -c /usr/local/etc/snort/snort.lua -r capture.pcap -A alert_fast
# Offline run: Zeek turns the capture into logs
zeek -r capture.pcap local
# Live replay at a controlled rate for a load test (lab only)
tcpreplay --intf1=eth1 --mbps=500 capture.pcapRecord four numbers for each engine: packets processed per second, CPU use per core, memory growth over an hour, and the count of alerts that overlap with the other engines. The last number is the most revealing. Two engines with the same rule intent often disagree on a meaningful share of alerts for reasons that trace back to protocol parsing differences, and each disagreement is a tuning lesson. Replace any assumption of ours with your own measurements.
Hardware planning follows from the test. Give inline sensors headroom: if your replay shows a core running hot, plan for the next traffic peak, not today’s average. Keep the sensor’s capture NIC separate from its management interface. And keep a spare, because an inline sensor with no failover is a single point of failure by definition.
Rules, Licensing, and Pricing
All four engines are open source, so the software license fee is zero. The real cost sits in rules, hardware, staff time, and optional managed services. The table below compares cost models. Where a vendor publishes list prices, we cite them in the text below the table with attribution, because pricing pages change often.
| Tool | Software cost | Rules or content cost | Commercial support | Hidden cost to plan for |
|---|---|---|---|---|
| Suricata | Free, open source | Community rule sets are free, third-party commercial feeds exist | No official commercial plan confirmed in the sources we reviewed | Tuning and upgrade labor |
| Snort 3 | Free, open source | Free Community Ruleset or paid Snort Subscriber Ruleset developed and approved by Talos | Through Cisco products and partners | Subscription per sensor, plus migration from Snort 2 |
| Zeek | Free, open source | Scripts and packages from the community | Third-party vendors and training | Log storage and SIEM ingestion |
| CrowdSec | Free Security Engine | Community signals free, paid blocklist access above that | Paid tiers and add-on support | Per-engine fees at scale |
| Firewall-based IPS | Bundled with the appliance | Vendor subscription | Vendor contract | License renewals |
CrowdSec publishes the most detailed price list of the four. According to its pricing page, updated October 9, 2026, small and midsize business pricing starts at $1,900 per month for access to all blocklists on any number of company endpoints. The same page reportedly lists IP Reputation API access from $49 per month for 5,000 queries, local threat-intelligence replication from $9,000 per month, and optional premium service and support at $1,000 per month per enrolled Security Engine. CrowdSec also describes a pay-as-you-grow model based mainly on the number of Security Engines. Treat these as vendor-listed figures that can change, and confirm them on the pricing page before you budget.
Snort’s model is simpler to explain. Cisco Talos distributes rules in a free Community Ruleset and in a paid Snort Subscriber Ruleset. Subscribers get the paid rules sooner than registered free users, and the license limits redistribution. We do not quote Snort’s per-sensor prices here because we could not confirm them against a current primary page during this review, so check snort.org before you choose a tier.
For Suricata, the sources we reviewed did not show official commercial plans or prices, so budget for free software and for the labor to run it. For Zeek, the dominant cost is storage and the SIEM that ingests its logs. The September 2026 Zeek guidance on reducing JSON log size through field-name mapping and log-filtering hooks speaks directly to that cost, since log volume often drives SIEM licensing more than the sensor does. The total cost of ownership of an open-source sensor is staff time, and experienced sensor engineers are not cheap.
Real-World Examples From the Last Three Months
Abstract comparisons only go so far. The following eight examples come from vendor announcements, project release notes, and community reports published between July and October 2026. Each one shows a different consequence of the IDS vs IPS choice.
- Cisco puts Snort 3 in the cloud firewall. On October 21, 2026, Cisco said Snort 3 is integrated into Cisco Cloud-Delivered Firewall and Cisco Security Analytics for intrusion prevention, and that all instances of both had received the Snort 3 package automatically by that date. Lesson: for managed products, the engine upgrade happens without the customer, which removes upgrade toil and also removes control.
- Catalyst NGFW replaces the UTD signature workflow. Cisco’s IOS XE 26.2.x documentation, dated September 28, 2026, describes independently managed Talos packages replacing the older community and subscriber signature workflow on supported routers. Lesson: branch IPS is converging on vendor-managed content.
- Suricata 7 retires, Suricata 8.0.7 follows. The project issued security releases for both 8.x and 7.x on July 9, 2026, declared Suricata 7 end of life, and then shipped 8.0.7 on September 15 with a heavy vulnerability-fix workload. Lesson: a security-focused patch cadence means a sensor you do not update becomes a liability.
- NFQUEUE reports test the IPS mode. In early October, forum threads described outbound TCP hangs and possible packet loops with Suricata 8.0.7 in NFQUEUE mode under specific settings. One thread also reported that a missing libmagic dependency made the file.magic keyword unavailable until the dependency was installed and the build repeated. Lesson: inline mode is sensitive to build and queue details, so stage every upgrade.
- CrowdSec uncovers the PaperPhone bot network. In a post dated September 29 and updated October 16, CrowdSec said its bot detection identified a scraping network of roughly 75,000 to 80,000 IP addresses across 43 countries, which it attributed to one operator. The bot-detection feature was still labeled alpha. Lesson: shared reputation data catches distributed abuse that a single sensor would never correlate.
- CrowdSec’s WAF blocks PHP attacks before a CVE exists. A report dated October 26 described the CrowdSec WAF blocking attacks against PHP flaws that had not yet received a published CVE identifier. Lesson: behavior-based blocking can protect an application while the formal vulnerability record is still pending.
- Zeek appears in a PHP2Shell defense lab. A public lab-validation document in the php2shell defense kit repository, dated around October 24, used Zeek as part of its validation setup. Lesson: when a new web exploit family emerges, defenders reach for network logs to confirm what actually crossed the wire.
- Zeek watches an incubator. A project published on October 13 used Zeek’s scripting to monitor temperature in a biological incubator, with an Apache-licensed repository. Lesson: Zeek is a general event engine, so a team that already runs it can extend it to non-security monitoring without a new product.
Put together, those cases show a pattern. Commercial firewalls absorb Snort and hide the version number. Open-source sensors move quickly and punish neglect. And the tools that block without inspecting packets, such as CrowdSec, are growing fastest into web application territory. If your environment includes a PHP-heavy web tier, our CrowdSec setup guide shows how to wire the engine and a bouncer together.
Use-Case Recommendations: Which Tool for Which Job
No single tool wins every job. These six recommendations assume you are building or rebuilding in late 2026 and want a supported release line. Each pairs a situation with a pick and a reason.
1. A small team that needs alerts on a flat network
Run Suricata 8 in IDS mode on a mirror port. It gives you signature alerts, structured logs, and a clear upgrade path, and it avoids any chance of breaking traffic. Add a community rule set, then review alerts for four weeks before you consider blocking anything. If you have no one to review alerts, skip ahead to recommendation five.
2. A Cisco-heavy enterprise with Talos rules already in use
Stay on Snort 3 and the Talos subscription, and finish the Snort 2 migration this quarter. You already pay for the content, your firewalls speak the same rule language, and Talos continues regular rule updates. Moving to a different engine would force you to rewrite or translate rule logic for a marginal gain.
3. A threat hunting or incident response team
Deploy Zeek 9.0 alongside an IDS. Alerts tell you where to look, and Zeek’s connection, DNS, TLS, and HTTP logs tell you what happened before and after. The long-term support status gives you a stable base for more than a year. Budget for log storage and apply the field-filtering techniques the project documented in September.
4. A data center that needs inline prevention at the edge
Use a firewall-based IPS from your existing vendor, or run Suricata inline on a dedicated gateway with a tested fail-open path. Inline software engines demand lab time, so unless you have engineers who enjoy kernel queues, the appliance path costs less in total. If you choose the software route, stage every update and test your queue configuration against the October NFQUEUE reports.
5. Internet-facing web servers with no security analyst
Pick CrowdSec with a bouncer on the web server or reverse proxy. Automatic blocking from shared signals suits a team that cannot triage alerts around the clock. Treat the bot-detection component as experimental until it leaves alpha, and keep a manual allow list for partners and monitoring systems.
6. A regulated environment that needs evidence and tamper-resistant logs
Run an IDS and Zeek together, ship both to an immutable log store, and document your tuning decisions. Auditors tend to care less about whether you block and more about whether you can show what you saw and how you responded. Keep a record of which rules were promoted to blocking, who approved them, and when.
Pros and Cons of Each Option
| Tool | Strengths | Weaknesses |
|---|---|---|
| Suricata 8 | Handles both IDS and IPS, active release cadence, protocol-aware rules, strong package support on current Ubuntu releases | Inline mode needs careful queue tuning, October reports of NFQUEUE issues, version 7 already retired |
| Snort 3 | Mature rule ecosystem backed by Talos, embedded in Cisco products, frequent rule updates | Best content sits behind a paid subscription, Snort 2 rules and configs need migration work |
| Zeek 9 | Excellent forensic logs, scriptable, long-term support release, free of rule-license costs | No inline blocking, alerts require extra scripting or a SIEM, log volume can be large |
| CrowdSec | Automatic blocking, shared community intelligence, easy to add to web servers | Not a packet-inspection IDS, key features such as bot detection still in alpha, paid tiers can be costly at scale |
| Firewall-based IPS | One box, vendor-managed content, simple operations | Less transparency, license renewals, limited custom logic |
The pattern that emerges is complementarity. The weaknesses of each tool are the strengths of another. Zeek lacks blocking, Suricata supplies it. Suricata lacks deep reputation sharing, CrowdSec supplies it. CrowdSec does not inspect packets, Suricata or Snort does. Teams that treat the choice as a single-winner contest usually end up buying the second tool a year later.
Migration Guide: From Snort 2 or Suricata 7 to a Supported Stack
Two migrations are time-sensitive in 2026. Snort 2 users must move to Snort 3, and Suricata 7 users must move to Suricata 8. A third path, from IDS to IPS, applies to anyone ready to start blocking. The steps below work for all three.
- Inventory your sensors. List every host running Snort or Suricata, the version, the mode (IDS or IPS), and the rule source. Do not trust old documentation.
- Freeze and export current rules. Save your local rules, thresholds, suppressions, and variable definitions. Local rules are the part vendors cannot migrate for you.
- Build a staging sensor. Install Snort 3.12.4.0 or Suricata 8.0.7 on a spare host or virtual machine. Use the same OS family as production so queue and driver behavior matches.
- Translate configuration. Snort 3 uses a Lua-based configuration file, so a Snort 2 snort.conf will not load. Suricata 8 reads YAML, and an older configuration may need new keys. Convert settings one block at a time and test each.
- Translate rules. Snort 3 includes a rule-conversion workflow for many Snort 2 rules, but custom rules with shared-object or deprecated options need manual review. Count rules that fail to load and fix them before comparing alert output.
- Replay traffic and compare. Run the same capture through the old and new sensors, then diff the alerts. Investigate every rule that fired on one and not the other.
- Run in IDS mode in production. Place the new sensor beside the old one on a mirror port for at least two weeks. Check alert volume, CPU, and memory daily.
- Cut over detection. Move alert consumers, such as your SIEM parsers and dashboards, to the new sensor’s output format. Keep the old sensor running read-only for a week as a fallback.
- Promote selected rules to blocking. Choose a short list of high-confidence rules, such as known exploit attempts against internet-facing services. Switch only those to drop, with alerting retained.
- Test failure behavior. Stop the sensor deliberately and confirm that traffic follows the fail-open or fail-closed behavior you chose. Do this in a maintenance window.
- Document the rollback. Write down how to return to alert-only mode in under a minute, and rehearse it.
- Retire the old sensor. Decommission Snort 2 or Suricata 7 only after a clean cutover week, and remove its credentials and rule subscriptions.
A typical inline Suricata path on Linux looks like the example below. It queues forwarded traffic to Suricata and starts the engine against that queue. Run it only in a lab until you have tested failure behavior.
# Send forwarded packets to NFQUEUE 0 (lab example)
sudo iptables -I FORWARD -j NFQUEUE --queue-num 0
# Start Suricata in IPS mode against that queue
sudo suricata -c /etc/suricata/suricata.yaml -q 0
# Roll back instantly by removing the rule
sudo iptables -D FORWARD -j NFQUEUE --queue-num 0Run the passive phase for a month before you return to the blocking steps above. For the wider set of security guides on the site, the cybersecurity coverage hub groups the related tutorials and comparisons.
Verdict: What to Run in Late 2026
For most organizations the right answer is a pair, not a single tool. Run Suricata 8.0.7 as your general-purpose IDS and, once tuned, as a limited IPS. Add Zeek 9.0 for the logs that make investigations fast. If you are a Cisco shop with Talos rules and firewalls, replace Suricata with Snort 3.12.4.0 and keep the same Zeek pairing. If your main exposure is web servers, add CrowdSec for automated blocking and treat its newer bot-detection feature as a preview.
Two decisions are not close. First, anything still on Snort 2 or Suricata 7 should move now, because both lines are retired and no longer receive rules or fixes. Second, do not start with an IPS. Start with detection, tune for several weeks, and promote only the rules you trust. The cost of that patience is a month of delayed blocking. The cost of skipping it is an outage you caused yourself.
| Your situation | Primary pick | Pair it with | Start in mode |
|---|---|---|---|
| Small team, flat network | Suricata 8.0.7 | Zeek 9.0 when staff allows | IDS |
| Cisco and Talos subscriber | Snort 3.12.4.0 | Zeek 9.0 | IDS, then selective IPS |
| Hunting and forensics | Zeek 9.0 | Suricata 8.0.7 | Passive |
| Web servers, no analyst | CrowdSec | Suricata for network visibility | Blocking via bouncer, with allow list |
| Edge prevention | Firewall IPS or inline Suricata | Zeek for logs | Alert-only for weeks |
One more caution on scope. Network IDS and IPS see traffic, not endpoints, so they will not replace endpoint detection. They also struggle with encrypted payloads, which is why metadata, logs, and host signals matter more each year. Treat the tools in this article as one layer of a stack, and judge them by whether they shorten the time from first malicious packet to a human decision.
FAQ: IDS vs IPS Questions Readers Ask Most
What is the main difference between IDS and IPS?
An IDS detects suspicious traffic and alerts, while an IPS sits inline and blocks it. The IDS watches a copy of traffic and cannot affect it. The IPS sees the live packets and can drop, reject, or reset them. Many engines, including Suricata and Snort 3, can run in either mode.
Is Suricata an IDS or an IPS?
Suricata is both. The project describes itself as an open-source network threat detection engine capable of IDS, IPS, and network security monitoring. The newest confirmed release is 8.0.7, published September 15, 2026, and the project recommends upgrading from Suricata 7, which reached end of life on July 9, 2026.
Is Snort 2 still supported?
No. Cisco Talos announced on October 21, 2026 that all open-source Snort 2 versions reached end of life and end of support, and Talos ended rule support for them. Snort 3 remains active, and Snort 3.12.4.0 is the fixed release named in Cisco’s October advisory.
Can Zeek work as an IPS?
Not as an inline blocker. Zeek is a network security monitor that converts traffic into logs and events. You can build automated responses around its output, for example by feeding alerts to a firewall, but Zeek itself does not sit in the forwarding path and drop packets.
Does CrowdSec replace Suricata or Snort?
No, they solve different problems. CrowdSec analyzes logs and shared signals and enforces decisions through bouncers. Suricata and Snort inspect packets. CrowdSec works well on internet-facing servers, while an IDS or IPS covers network-level traffic, including east-west flows that never reach a server log.
Should I start with an IDS or an IPS?
Start with an IDS. Passive deployment cannot break traffic, and it gives you weeks of data to tune rules. Promote only high-confidence rules to blocking, and confirm that you can roll back to alert-only mode in under a minute before you go inline.
Which version should I run in October 2026?
Run Suricata 8.0.7, Snort 3.12.4.0, or Zeek 9.0, depending on your role. Suricata 9 and Zeek 9.1 are development work and should not be deployed. Check each project’s release page before you upgrade, since patch releases can land at any time.
Does an IPS slow down my network?
An inline IPS adds inspection time to forwarded traffic, and the amount depends on rule count, packet mix, hardware, and queue settings. We found no independent current benchmark we trust, so replay your own traffic and measure packets per second, CPU use, and memory before you size a production sensor.
