What Is an Intrusion Detection System (IDS)? Types, IDS vs IPS and What to Watch
An intrusion detection system watches networks or computers for signs of attack and raises alerts. Learn the main types, how IDS compares with IPS and what a host-based IDS should watch.
Updated October 16, 2026
What is an intrusion detection system? IDS meaning in cyber security
In cyber security, IDS stands for intrusion detection system. NIST's SP 800-94, Guide to Intrusion Detection and Prevention Systems, describes intrusion detection as watching what happens on computers and networks and analyzing those events for signs of possible incidents. The NIST glossary defines an IDS as software that automates that process.
An IDS does not stop an attack by itself. Its job is to notice malicious or suspicious activity, such as a burst of failed sign-ins, a new administrator account or traffic to a known-bad address, and raise an alert with enough evidence for a person to act: when it happened, on which machine, from which address and which rule fired.
IDS vs IPS: detection versus prevention
An intrusion prevention system (IPS) does what an IDS does and can also act: drop traffic, block an address or end a session. NIST covers both under the name IDPS, because many products can run either way.
- Where it sits: a network IDS usually watches a copy of the traffic, while a network IPS sits in the traffic path. On a single computer, the difference is whether the tool only reports or also changes firewall rules.
- Cost of a mistake: a false alarm from an IDS wastes time; a false block from an IPS can cut off a customer, a partner or your own administrator.
- Typical rollout: run in detection-only mode first, review what would have been blocked, then allow blocking for rules you trust, with a quick way to undo blocks.
Types of intrusion detection systems: network-based and host-based
SP 800-94 groups these technologies into four classes: network-based, wireless, network behavior analysis and host-based. Most organizations choose between, or combine, the first and the last.
- Network-based intrusion detection system (NIDS): a network intrusion detection system monitors network traffic. Sensors at points such as an internet connection inspect packets and connections for many machines at once. They miss traffic that never passes the sensor, and they can see that an encrypted connection happened but not what is inside it. Suricata and Snort are well-known open-source examples.
- Host-based intrusion detection system (HIDS): an agent on each computer reads its logs, accounts, services, files and connections. It sees what actually happened on that machine, but it has to be installed and kept running everywhere. Wazuh and OSSEC are common open-source examples.
- Wireless and network behavior analysis: wireless sensors watch Wi-Fi for rogue access points; behavior analysis looks for unusual traffic volumes or new connections.
Signature vs anomaly detection
NIST describes three detection methods, and most tools mix them:
- Signature-based detection: compare activity with patterns of known attacks or lists of known-bad addresses. It is precise and easy to explain, but blind to anything new or slightly changed.
- Anomaly-based detection: learn what normal looks like, then flag departures, such as a sign-in at 3 a.m. from a new country or a server that suddenly contacts hundreds of hosts. It can catch new attacks, but it raises more false positives (false alarms) and needs a clean starting point. A sudden flood of traffic from a denial-of-service (DoS) attack is a classic anomaly. Many products now add machine learning to anomaly-based detection; treat those alerts as leads that a person still confirms.
- Stateful protocol analysis: compare traffic with how a protocol is supposed to behave and flag requests that break its rules.
A simple form of anomaly detection suits small networks: record how each machine looks on the first day, then report what changes.
What a host intrusion detection system watches on Windows and Linux
On Windows, the Security and System event logs record most of what matters. Microsoft's list of events to monitor is a good reference, and it notes that some events are recorded only after you configure the matching audit policy. Watch for:
- Bursts of failed sign-ins (event 4625) and successful sign-ins from new addresses (4624).
- New user accounts (4720) and members added to local groups such as Administrators (4732).
- New services (4697, or 7045 in the System log) and new scheduled tasks (4698).
- A cleared Security log (1102), a common way to hide tracks.
- Microsoft Defender detections, and Defender being disabled.
Linux intrusion detection follows the same ideas with different sources: the authentication log or system journal, the audit subsystem and the file system. Watch for:
- SSH password guessing, and sign-ins from addresses never seen before.
- sudo and su failures, new users and changes to administrator groups or the sudoers file.
- New cron and at jobs, timers and service units.
- Changes to
authorized_keys, a common way to keep access, as MITRE ATT&CK documents. - Kernel modules loaded after start-up, and new listening ports.
Decoys and honeytokens: alerts worth reading
The NIST glossary describes a honeypot as a system or resource designed to attract attackers. A honeytoken is the small version: a fake credential, file, account or network port that no legitimate person or program has a reason to touch. Because normal work never touches them, a decoy alert is usually worth reading at once.
- Decoy account names: names that password-guessing tools try first, such as admin or test, that are not real accounts on the machine.
- Bait files: believable credential files with made-up passwords, watched for opening, changes or deletion.
- Decoy ports: ports that nothing real listens on, so any connection is suspicious.
Never put real secrets in a decoy, exclude backup and indexing tools that read every file, and write down where the decoys are so your own staff do not trip them. Host tools such as LurkerLock include all three kinds.
Alert fatigue and IDS tuning
An untuned IDS can bury real attacks under thousands of harmless alerts until people stop reading them. NIST's guide stresses tuning to improve accuracy, and tuning is never finished. Practical steps:
- Start with a baseline, so what was already on each machine is not reported as new.
- Run blocking rules in detection-only or dry-run mode until you trust them.
- Route by severity: critical alerts reach a phone right away; low ones go into a daily summary.
- Suppress known-good activity with a written reason and an expiry date, not a permanent blanket exception.
- Review the noisiest rules each week, then fix or retire them.
- Keep logs long enough to investigate, somewhere an attacker on one machine cannot erase them. The event logging best practices that Australia's cyber security centre published with CISA and other partners cover what to collect and protect.
Every alert should have an owner and a next step. If nobody would act on it, it should not wake anyone up.
Where an IDS fits with firewalls, EDR and patching
An IDS is one layer, and each of the others answers a different question:
- Firewalls decide which traffic is allowed. An IDS tells you what is happening inside what was allowed.
- Endpoint detection and response (EDR) records detailed activity on computers and can isolate a machine or stop a process. It overlaps with host-based detection; some organizations run both, and others use a HIDS where EDR is not deployed.
- Antivirus scans files for known malware. An IDS watches the behavior around it, including antivirus being disabled.
- Patching closes the holes attackers use. CISA's Known Exploited Vulnerabilities Catalog helps you decide what to patch first.
- Multifactor sign-in and backups limit what a stolen password can do and how much damage a break-in causes.
For a small organization, a reasonable start is host-based detection on the machines that matter most, logs kept off those machines, prompt patching and multifactor sign-in. An IDS tells you something went wrong; it does not make a network secure on its own.
Where LurkerLock fits
LurkerLock is host security for Windows PCs and Linux servers, in early access. A sensor on each machine watches many of the events above: sign-ins and password guessing, new accounts, services and scheduled tasks, a cleared audit log, Microsoft Defender detections, cron jobs, SSH authorized keys, kernel modules and new listening ports. It checks outbound connections against public threat lists and your own list, and it sets decoy account names, bait files and decoy ports.
Sensors report to a LurkerLock Server you host yourself, with a web console, or a single machine can run the sensor with no server. Blocking stays off until you enable it, and then it starts as a dry run that only records what it would block. When it acts, it blocks single addresses and never blocks the machine's own addresses, your allowlist or your management addresses. Every finding, block and decision is recorded on the machine and on your server. There is no telemetry, license server or update check.
It does not scan files for malware itself; on Windows it reports what Microsoft Defender detects. Findings can include account names, addresses and command lines, so tell users their computers are monitored where your rules or employment law require it. See how LurkerLock works.
Frequently asked questions
What does IDS mean in cyber security?
IDS means intrusion detection system: software that watches network traffic or computer activity for signs of an attack and alerts a person.
What is the difference between IDS and IPS?
An IDS detects and alerts. An IPS can also act, for example by dropping traffic or blocking an address. Many products do both, and many teams run prevention in detection-only mode first.
What are the main types of IDS?
NIST lists four: network-based, wireless, network behavior analysis and host-based. Network-based and host-based systems are the most common, and they are often used together.
Do I need a host-based IDS if I have a firewall?
A firewall decides what traffic is allowed; it does not tell you that a new administrator account appeared or an audit log was cleared. A host-based IDS covers what happens on the machine after a connection is allowed, including sign-ins with stolen passwords.
What should Linux intrusion detection watch first?
Start with SSH sign-in failures, successful sign-ins from new addresses, sudo use, new user accounts, changes to authorized_keys and cron jobs, and new listening ports. Those cover common ways attackers get in and stay in.