Intrusion Detection, Built In

Most intrusions show on the wire before they show anywhere else: a port scan sweeping a subnet, a host beaconing to a command-and-control address, a known exploit signature crossing a segment it has no business on. Watching network traffic for those patterns is the job of an intrusion detection system (IDS), and it is one of the places network monitoring and cybersecurity meet. Netmon’s part is the monitoring. It runs an IDS sensor on the appliance, ingests the events that sensor produces in the open EVE JSON format, and lands every one in Logs and Events alongside your syslog, Windows event logs, and flow records — one page, one search, every line attributed to its device.

A sensor, and what Netmon adds

The appliance runs an intrusion-detection sensor built on the open-source Suricata engine, matching your traffic against a maintained, industry-standard threat-signature set (the Emerging Threats ruleset) that Netmon keeps current on its own. Those detections are written in EVE — an open, documented JSON format — and Netmon ingests them into the platform.

That division is the whole idea. The sensor spots the signature; Netmon does everything you actually work with afterward — attributing each event to a device, unifying it with your other logs, keeping the history, and turning any detection into an alert. Because the events arrive as EVE rather than a proprietary black box, the monitoring layer is built on an open format, not a single vendor’s console.

And it is part of the platform, not a separate product or a license tier you add later. The appliance you already run for availability, performance, and traffic monitoring is the same appliance surfacing intrusions — one system to deploy, one system to keep patched.

Always-on inspection

The sensor inspects the traffic on the appliance’s monitored interfaces — the same mirror feed that drives the packet analyzer and the topology map. Point a switch’s SPAN or mirror port at the appliance once (the Network Device Configuration Guide covers this for every common switch and router vendor), and from then on inspection runs continuously. Coverage is around the clock, not just while someone is watching a console — the value of an IDS is that it is looking at 3 a.m. on a holiday weekend, which is exactly when no one else is.

Every detection in one place

A detection is not much use in a silo. Netmon ingests each EVE event and raises it as one of the four streams on the Logs and Events page, next to syslog, Windows event logs, and the flow record — the same toolbar, the same full-text search, the same time axis. Every event carries what you need to judge it:

• a signature naming what matched, and its signature ID;
• a severity — High, Medium, or Low;
• the source and destination addresses and ports, the protocol, and the VLAN and interface it was seen on;
• the device it belongs to, matched by the address at either end of the connection.

From there it works like the rest of the log surface. Search a signature across every device at once, filter to one host or one severity over a chosen window, and open any event to read its full record when you need the packet-level detail. When a benign signature fires all day and will never be anything else, right-click it and add an exclusion filter — the noise drops below the surface while the events themselves are still collected, still counted, and still visible to your alerts, so suppressing a row on the page never quietly disables the alert built on it.

From detection to notification

The point of catching something at 3 a.m. is being told at 3 a.m. IDS events are a first-class alert class in Netmon, so you can write an alert on exactly the conditions that matter — a specific signature or set of signatures, a severity threshold, a particular host or port, a protocol, an interface, or a VLAN — and set how many occurrences in what window should trip it.

Those alerts route through the same Alert Manager as every other alert on the appliance. Send critical signatures to your security team’s inbox and a webhook, mirror high-severity hits into a Slack, Microsoft Teams, or Discord channel, and hold everything during a maintenance window so a planned penetration test does not page the on-call. Each new detection notifies once — a genuinely new match, not the same event ringing every minute — so an alert that fires is an alert worth reading.

Detection, not prevention

Netmon’s IDS is a passive sensor. It reads a copy of your traffic from a mirror port and never sits in the path of it, so it can flag a threat without any chance of dropping legitimate traffic or becoming a bottleneck or a point of failure in your network. It detects and it tells you; the response stays with you and your tools.

That is a deliberate design, and for a monitoring appliance it is the right one: a sensor you can attach to any switch without re-architecting the traffic path, that carries zero risk to production flows, and that gives your team the evidence — the signature, the hosts, the timing — to act on. If you are looking for inline blocking, that is a firewall’s or an IPS’s job; Netmon’s role is to see what crosses the wire and make sure you know about it.

Part of one system

Because the IDS lives inside the monitoring platform, its events sit next to everything else you know about a host. A signature hit is one click from that device’s dashboard, its recent logs, and its interface and performance history — and, when you want to see the packets themselves, an on-appliance packet capture you can open in Wireshark. Threat detection stops being a separate console to check and becomes another lens on the network you are already monitoring.

IDS event history is stored like the other high-volume log streams and is managed from Data Maintenance, so you decide how far back the record reaches.