Network Intrusion Detection for SMBs: Catching Attacks with Suricata and Snort

Most SMB security stacks already have an EDR on endpoints and servers. It catches a malicious binary executing, an in-memory injection, a suspicious PowerShell command. What it structurally cannot see is what moves between machines before, during, and after execution: a C2 implant beaconing outward, an SMB share enumeration from a compromised workstation, a network exploit landing against a service before any malicious code ever reaches an agent. That is the job of a Network Intrusion Detection System (NIDS) such as Suricata or Snort: it watches traffic, not processes. Network intrusion detection is not a duplicate of your EDR, it is a blind spot your EDR cannot cover by design.

Where a NIDS sits: passive or inline

There are two ways to wire an engine like Suricata into your network, and the implications differ sharply.

Passive, off a SPAN port or a TAP. The switch or a physical TAP mirrors traffic to the sensor, which observes a copy without ever touching the original flow. No added latency, no risk of breaking production if the engine crashes. This is the right starting point for an SMB: deploy, observe, tune rules for weeks with zero risk to business traffic. The tradeoff: passive mode detects, it does not stop anything. The alert flows to the SIEM, and a human or a playbook acts afterward.

Inline, in IPS mode. Traffic physically passes through the engine, which can then drop a packet or reset a connection in real time. Far more powerful, but it changes the nature of the risk: a miscalibrated rule in IPS mode can cut a legitimate business flow, not just generate a noisy alert. For an SMB new to NIDS, the recommended sequence is almost always: passive first, inline later, and only on a subset of rules with a proven, measured false-positive rate.

Either way, what the engine sees that endpoint tooling does not falls into three buckets: C2 beaconing (periodic connections to a suspicious domain or IP, often before the implant does anything locally), lateral movement (SMB, RDP, WinRM between machines that never normally talk to each other), and a network exploit landing pre-execution (a malicious payload transiting inside an HTTP request or an SMB packet before it ever becomes a process on the host). That last point matters: a NIDS can block an attack before it ever becomes an event for the EDR to catch.

Anatomy of a Suricata rule

Take a representative example: an exploit attempt against an exposed SMB service.

alert tcp any any -> $HOME_NET 445 (
    msg:"POSSIBLE SMBv1 Exploit Attempt - Anomalous Trans2 Request";
    flow:established,to_server;
    content:"|FF|SMB"; offset:4; depth:4;
    content:"|32 00|"; distance:1; within:2;
    pcre:"/^.{8}\x00{4}/R";
    classtype:attempted-admin;
    sid:2100657; rev:3;
    metadata:attack_target Server, deployment Perimeter, signature_severity Major, created_at 2011_06_14, updated_at 2024_03_02;
)

(Illustrative example: the structure matters more than the specific CVE.) Each block carries a distinct role:

• The header (alert tcp any any -> $HOME_NET 445) sets the action, protocol, source, and destination. Here: any source, any source port, toward the internal network ($HOME_NET, a variable defined in suricata.yaml), on the SMB port.
• flow:established,to_server requires an already-established TCP connection and a packet flowing from client to server. Without this line, the rule would also evaluate SYN packets and server responses, doubling the volume checked for no benefit.
• content and pcre are the heart of the signature: they look for a precise byte pattern (the SMB header, a command code), then refine it with a regular expression on the packet structure.
• classtype places the rule into a severity family (attempted-admin, trojan-activity, attempted-recon, and so on), used downstream for prioritization.
• sid and rev uniquely and versionably identify the rule: a sid is never reused, a rev increments with every fix.
• metadata carries actionable context: target, severity, creation and update dates. This is what lets you sort and correlate afterward, exactly like CVE classification in a vulnerability scan template.

Sources of rules: buy, build, or subscribe

An SMB effectively has three options, with very different tradeoffs.

ET Open (Emerging Threats Open), free, is the historical backbone of the Suricata community. Large volume, actively maintained, but a meaningful false-positive rate on certain categories when deployed as-is, with no local triage or tuning. It is an excellent starting point and a poor end state for a team that does not have hours to spare triaging hundreds of alerts a week.

ET Pro, paid, tightens some of that noise and adds faster coverage on emerging threats. The tradeoff is now financial, and it still assumes a team able to absorb the volume and tune it.

Talos (Snort) publishes a ruleset maintained by Cisco's research team, with community access lagging behind subscriber access.

Curated in-house rule packs answer a different need: a pack tested on a real engine against benign traffic and a patched target, with a false-positive rate measured before delivery rather than discovered in production. The buy-versus-build-versus-subscribe logic comes down to this: building everything in-house costs an amount of engineering time few SMBs have; subscribing to a raw, untriaged feed shifts the cost to daily alert triage instead; a curated pack absorbs that triage work upstream, once, for everyone downstream.

The founding false-positive trap

The single most common, and most costly, mistake is a rule that matches on a port with no content and no connection-state check:

# Bad: a guaranteed alert storm
alert tcp any any -> $HOME_NET 445 (msg:"SMB traffic"; sid:9000001; rev:1;)

This rule fires on every TCP packet toward port 445, including everyday legitimate SMB traffic. The result: thousands of identical alerts drowning out real anomalies, until the team simply disables the rule, or worse, the entire category. The principle of specificity is simple: the more matching conditions a rule requires together (flow:established, a precise content, a packet size, a byte sequence), the fewer false triggers it produces. A rule with no content and no flow is not detection, it is a traffic counter disguised as an alert.

Prioritize and route to the SIEM

Once rules are in place, not everything deserves the same handling. The classtype and the priority field (which can be overridden per rule) let you route traffic: a trojan-activity alert at priority 1 should reach the SOC team or an automated playbook immediately, while an attempted-recon alert at priority 3 can roll up into a weekly trend inside the SIEM.

This is exactly where the gap shows between an ET Open feed pasted in as-is and a curated pack with a low false-positive rate: the former forces the team to do that triage work itself, rule by rule, week after week; the latter arrives already classified, already tested against a benign-traffic corpus, with prioritization that reflects real exploitation rather than a CVE's theoretical severity score.

The bottom line

A NIDS does not replace an EDR, it covers what the EDR structurally cannot see: C2 before execution, lateral movement between machines, the network exploit at the moment it transits. The quality of a Suricata or Snort deployment is not measured by how many rules are loaded, but by their specificity and by a false-positive rate that is measured, not assumed.

That is exactly what the ThreatClaw NIDS rule pack delivers: ready-to-use Suricata signatures, tested on a real engine against benign traffic and patched targets, prioritized by classtype and real-world severity, so you can detect without drowning your team in false positives.