What Is an IDS/IPS?
An intrusion detection and prevention system (IDS/IPS) is a network security appliance that inspects all inbound and outbound network traffic for suspicious patterns that might indicate a network or system security breach. If it finds something, the IDS alerts the administrator about the suspicious activity — it checks network traffic for signatures that match known intrusion patterns and triggers an alarm when a match is found.
An Intrusion Detection System sits passively, watches copies of traffic, and raises an alarm when it spots a match. It does not sit inline in the path of traffic — it observes and reports.
An Intrusion Prevention System sits inline (in the direct path of traffic, alongside/near the firewall) so it can actively block or drop malicious packets in real time, not just alert about them.
Mnemonic — Alarm vs Guard Dog
"IDS barks, IPS bites." An IDS is a smoke alarm — it detects and dings a bell but doesn't put out the fire. An IPS is a guard dog standing in the doorway — it can actually stop the intruder from getting through. Detect vs Detect+Block.
How an IDS Works — The Pipeline
Traffic flows from the Internet, through the router and firewall, into the IDS. The IDS preprocessor compares the traffic against a signature file database. If there's no signature match, it runs anomaly detection, then stateful protocol analysis. Any match triggers an action rule.
When a match is found: the alarm notifies the admin and the packet can be dropped, connections from that IP source are cut, and the packet is dropped.
Role of an IDS in Network Defense
An IDS works from inside the network, unlike a firewall, which only looks outside the network for intrusions.
An IDS is placed behind the firewall, inspecting all the traffic, looking for heuristics and pattern matches for intrusions.
Firewall vs IDS — different jobs
A firewall enforces a rule set at the perimeter and blocks based on ports/addresses/protocols. An IDS goes deeper — it inspects traffic content for attack patterns, from a vantage point behind that firewall, so it can catch things the firewall's rules let through.
How an IDS Detects an Intrusion
An IDS uses three core detection techniques, and these are also the "Approach-based" classification of IDS covered later in the chapter.
Signature-Based Detection — Deep Dive
Also known as misuse detection. It monitors patterns of data packets in the network and compares them to pre-configured network attack patterns, known as signatures. This method uses string comparison operations to compare ongoing activity — such as a packet or a log entry — against a list of signatures.
- Detects attacks with minimal false alarms
- Can quickly identify the use of a specific tool or technique
- Helps admins quickly track potential security issues and start incident handling
- Only detects known threats — the database must be constantly updated with new attack signatures
- Uses tightly defined signatures, which prevents it from detecting common variants of attacks
Anomaly-Based Detection — Deep Dive
Alarms for anomalous activities are generated by evaluating network patterns — bandwidth used, protocols used, ports/devices connected to each other. The IDS monitors typical activity for a time interval and builds statistics for the network traffic. Example: an anomaly-based IDS monitors normal Internet bandwidth usage, failed logon attempts, processor utilization levels, etc.
- Identifies abnormal behavior and detects symptoms of attacks without clear details in advance
- Information from anomaly detectors can be used later to define signatures for misuse detectors
- High rate of false alarms due to unpredictable behavior of users and networks
- Needs an extensive set of system events to properly characterize "normal" behavior patterns
Stateful Protocol Analysis
Compares observed events with predetermined profiles based on accepted definitions of benign activity for each protocol, to identify deviations of the protocol state. It can identify unpredictable sequences of commands (e.g., the same command issued repeatedly, or arbitrary commands). It also detects variations in command length, minimum/maximum values for attributes, and other potential anomalies. For any protocol performing authentication, the IDS/IPS tracks the authenticator used for each session and records the authenticator involved in suspicious activity.
Mnemonic — "Known List vs Weird Behavior vs Broken Rules"
"Signature = mugshot, Anomaly = 'that's not like you', Protocol = rulebook check." Signature/misuse detection matches a known "mugshot" (attack pattern) — fast, low false positives, but blind to new attacks. Anomaly detection notices behavior that deviates from a learned baseline — catches unknowns, but trigger-happy (high false positives). Stateful protocol analysis checks whether the conversation is following the protocol's own rulebook (e.g., login sequence, command order).
IDS Classification — Six Axes
An IDS is classified based on six different criteria: approach, protected system, structure, data source, behavior after an attack, and analysis timing.
Mnemonic — "A Pretty Strange Dog Barks, Timely"
Approach, Protected system, Structure, Data source, Behavior after an attack, Timing — the six ways an IDS gets labeled. "A Pretty Strange Dog Barks, Timely" hits all six first letters in slide order.
1. Approach
Signature Detection vs Anomaly Detection (covered in depth above).
2. Protected System
HIDS (host), NIDS (network), or Hybrid (both).
3. Structure
Centralized System vs Distributed System (with an Agent System).
4. Data Source
Audit Trail vs Network Packets vs System State Analysis.
5. Behavior After an Attack
Active IDS vs Passive IDS.
6. Analysis Timing
On-the-fly Processing (real-time) vs Interval-based IDS.
Protection-Based IDS — NIDS vs HIDS vs Hybrid
An IDS is classified based on the system/network it offers protection to.
If it protects the network, it's a network intrusion detection system (NIDS). It sits on the network, watching traffic destined for many hosts.
If it protects a host, it's a host intrusion detection system (HIDS). It's installed on an individual machine and watches only that machine's activity.
If it protects both the network and a host, it's a hybrid intrusion detection system. A hybrid IDS combines the advantages of both the low false-positive rate of a NIDS and the anomaly-based detection of a HIDS to detect unknown attacks.
Mnemonic — "N is for Neighborhood, H is for House"
NIDS watches the Neighborhood (the whole network); HIDS watches one House (one host). One NIDS sensor can watch traffic to/from many HIDS-protected machines at once — that's why the slide shows a single NIDS box connected to five HIDS boxes.
Structure-Based IDS — Centralized vs Distributed
This classification is based on the physical/logical structure of the IDS deployment.
All data is shipped to a central location for analysis, independent of the number of hosts monitored. One IDS console analyzes everything (Network, Application, and Host-based monitoring systems all report in).
Several IDS instances are deployed over a large network and each IDS communicates with each other for traffic analysis — a fully distributed, agent-based control model.
Behavior-Based IDS — Active vs Passive
An IDS is categorized based on how it reacts to a potential intrusion. It functions in one of two modes, based on the behavior after an attack.
Detects and responds to detected intrusions — it can listen and monitor, then take an active response (e.g., cut a connection).
Only detects intrusions — it listens and monitors, and that's it. No automatic response.
Analysis Timing–Based IDS — Interval vs Real-Time
Analysis time is the span of time elapsed between events occurring and the analysis of those events.
Information about an intrusion detection does not flow continuously from monitoring points to analysis engines — it's simply stored and forwarded. Performs analysis offline.
Information flows continuously from monitoring points to analysis engines. Performs analysis on the fly.
Source Data Analysis–Based IDS
An IDS is classified based on the type of data source it uses to detect intrusions — audit trails or network packets.
Help the IDS detect performance problems, security violations, and flaws in applications.
Capturing and analyzing network packets helps an IDS detect well-known attacks.
Misuse vs Anomaly Detection System architecture
Both system types share the same basic pipeline: Auditing Modules → Profiles → an inference engine → Target Systems. The difference is what the engine compares against — a Misuse Detection System runs an Interference (Inference) Engine against known-bad profiles, while an Anomaly Detection System runs a dedicated Anomaly Detection Engine against learned-normal profiles.
IDS/IPS Capabilities, Limitations & Warning Signs
IDS Capabilities
IDS provides an additional layer of security to the network under the defense-in-depth principle. It does several things basic firewalls cannot do, and helps minimize the chance of missing security threats that could come from firewall evasions.
Monitoring and analyzing both user and system activities
Recognizing typical attack patterns
Analyzing system configurations and vulnerabilities
Analyzing abnormal activity patterns
Assessing system and file integrity
Tracking user policy violations
IDS/IPS Limitations — What It Is NOT
IDS/IPS cannot act as, or replace:
Network Logging Systems
Vulnerability Assessment Tools
Antivirus Products
Cryptographic Systems
Mnemonic — "LVAC" (Not a LAVAC)
"IDS is NOT a LVAC" → Logging system, Vulnerability scanner, Antivirus, Crypto system. Four things students often mistakenly assume an IDS covers — it doesn't replace any of them.
IDS/IPS Security Concerns
Improper IDS/IPS configuration and management will make an IDS/IPS ineffective. Deployment should be done with careful planning, preparation, prototyping, testing, and specialized training.
Common Mistakes in IDS/IPS Configuration
- Deploying an IDS in a location where it does not see all the network traffic
- Frequently ignoring the alerts generated by the IDS
- Not having a proper response policy and the best possible solutions to deal with an event
- Not fine-tuning the IDS for false negatives and false positives
- Not updating the IDS with the latest new signatures from the vendor
- Only monitoring inbound connections (ignoring outbound)
General Indications of Intrusions
File System Intrusions
- New or unfamiliar files/programs
- Changes in file permissions
- Unexplained changes in a file's size
- Rogue files not on the master signed-file list
- Missing files
Network Intrusions
- Repeated probes of available services
- Connections from unusual locations
- Repeated login attempts from remote hosts
- A sudden influx of log data
System Intrusions
- Short or incomplete logs
- Unusually slow system performance
- Missing logs / incorrect permissions or ownership
- Modifications to system software and config files
- Unusual graphic displays or text messages
- Gaps in system accounting
- System crashes or reboots
- Unfamiliar processes
IDS Components
An IDS system is built on various components. Knowledge of their functions and placement is required for effective IDS implementation.
Network Sensors
Hardware and software components that monitor network traffic and trigger alarms if abnormal activity is detected. Should be placed at common entry points: Internet gateways, between LAN connections, remote-access/dial-up servers, VPN devices, and on either side of a firewall.
Command Console
Installed and runs on a separate, dedicated system. Provides a UI for the admin to receive and analyze security events, alert messages, and log files, and evaluates security event information from different security devices (e.g., Sguil). Caution: if installed on a non-dedicated computer (firewall, backup server), it drastically slows the response to security events since those systems are busy with other tasks.
Alert Systems
Sends an alert message when any anomaly or misuse is detected (e.g., OSSEC HIDS alerts, Snort NIDS alerts — both shown in the Sguil console).
Response System
Issues countermeasures against any detected intrusion. You must also stay involved in the decision during incident response and be able to respond on your own — you need to decide how to handle false positives and when a response needs escalation. Recommendation: do not solely rely on an IDS response system for intrusion response.
Attack Signature Database
An IDS itself cannot "decide" — instead it maintains a database of attack signatures/patterns. Network traffic is compared against these signatures, and a decision can be made. If a match is found, the IDS raises an alert and blocks the suspicious traffic. Recommendation: periodically update the IDS attack signature database.
Mnemonic — "Sensors See, Console Controls, Alerts Announce, Response Reacts, Database Decides-with"
"Nick's Cat Always Runs Around" → Network sensors → Command console → Alert systems → Response system → Attack signature database. Five components, in the same order the slides present them.
How They Collaborate
End-to-end flow of an intrusion detection event, from sensors on the network to the admin's desk:
In the reference architecture, sensors sit in the screened subnet DMZ while the database server and network management server live in a trusted management subnet — separating "sensing" from "managing."
Deployment of Network- and Host-Based IDS
Staged IDS Deployment
Plan for a staged deployment. It helps gain experience and discover how much monitoring and maintenance of network resources is actually required — this varies depending on the size of an organization's network.
Deploying Network-Based IDS (NIDS)
An effective NIDS deployment requires a lot of attention concerning the network topology of the organization. Possible deployment options are categorized by the location of the IDS sensors. Consider all options and their advantages/disadvantages before placing a network-based IDS.
Place an IDS sensor behind each external firewall and in the network DMZ.
- Monitors attacks originating from the outside world
- Highlights the inability of the firewall/policies to defend against attacks
- Sees attacks targeting web or FTP servers located in the DMZ
- Monitors outgoing traffic resulting from a compromised server
Place an IDS sensor outside an external firewall.
- Ability to identify the number and types of attacks originating from the Internet toward the network
Place an IDS sensor on major network backbones.
- Monitors and inspects large amounts of traffic, increasing the chance of attack detection
- Detects unauthorized attempts from outside the organization
Place an IDS sensor on critical subnets.
- Detects attacks on critical systems and resources
- Focuses on specific critical systems and resources
Mnemonic — "Behind, Beyond, Backbone, Best-stuff"
"B-B-B-B" → Location 1: Behind the firewall/DMZ. Location 2: Beyond (outside) the firewall. Location 3: Backbone (major traffic arteries). Location 4: Best-stuff (critical subnets you most want to protect). Move from "closest to the internet" to "closest to the crown jewels."
Deploying a Host-Based IDS (HIDS)
Deploying a HIDS provides an additional layer of security. This type of IDS must be installed and configured on each critical system in the network — in fact, you should consider installing a host-based IDS on every host in the organization. When deploying a HIDS, it's recommended to have centralized management and reporting functions, which reduces the complexity of managing alerts from a large number of hosts.
IDS Alerts — The Four Outcomes
An alert is a graduated event that notifies that a particular event (or series of events) has reached a specified threshold and needs proper action by a responsible party. It sends a notification indicating that something is wrong and requires immediate attention and monitoring.
| Type | Attack Actually Happening? | IDS Raises Alarm? | Meaning |
|---|---|---|---|
| True Positive | Attack | Alert | Correct — the IDS raises an alarm because a legitimate attack occurred |
| False Positive | No Attack | Alert | Wrong — the IDS raises an alarm when no attack has taken place |
| False Negative | Attack | No Alert | Wrong (and dangerous) — the IDS does not raise an alarm even though a legitimate attack occurred |
| True Negative | No Attack | No Alert | Correct — the IDS stays quiet because there was nothing to catch |
Mnemonic — "Crying Wolf vs Sleeping Guard"
False Positive = crying wolf (annoying, wastes time). False Negative = sleeping guard (dangerous, misses the real attack). Read the label backward: the first word says whether the alarm was truthful or a mistake; "Positive" always means an alert fired, "Negative" always means it stayed silent — regardless of whether an attack was really happening.
Why false negatives are the scarier problem
A false positive wastes an analyst's time. A false negative means a real attack slipped through completely unnoticed — which is exactly why "not fine-tuning the IDS for false negatives and false positives" was listed as a common configuration mistake.
Choosing a Good IDS/IPS & Real-World Tools
Characteristics of Good IDS Solutions
01. Run continuously with less human intervention
02. Must be fault tolerant
03. Resistant to subversion
04. Minimal overhead on the system
05. Observe deviations from normal behavior
06. Not easily deceived
07. Tailored to specific system needs
08. Copes with dynamic system behavior
Selection Criteria for an IDS/IPS Solution
IDS products must meet certain criteria to be deployed in an organization — compare different technology types, then select the one that best meets the requirements.
| Requirement Category | What to Evaluate |
|---|---|
| General requirements | What the IDS products must meet post-deployment; org size affects how many products are needed |
| Security capability requirements | Depends on the organization's environment, policies, and current security/network infrastructure |
| Performance requirements | Capacity to handle network traffic/packet monitoring (NIDS) or event monitoring (HIDS) |
| Management requirements | Must comply with the organization's management policy to be used effectively |
| Life cycle costs | Estimated lifecycle costs should fit within the available budget |
Intrusion Detection with Snort
Snort is an open-source network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis and content searching/matching, and is used to detect a variety of attacks and probes — buffer overflows, stealth port scans, and OS fingerprinting attempts. It uses a flexible rules language to describe traffic it should collect or pass, plus a detection engine that uses a modular plug-in architecture.
Other Intrusion Detection Tools
Suricata
A robust network threat detection engine capable of real-time IDS, inline IPS, network security monitoring (NSM), and offline pcap processing.
AlienVault OSSIM
Open-source security information and event management platform.
SolarWinds Security Event Manager
Commercial SIEM/log-analysis platform.
OSSEC
Open-source host-based intrusion detection system (HIDS).
Zeek
Network security monitoring framework (formerly Bro).
Sagan Log Analysis Engine
Real-time log analysis engine, often paired with Snort/Suricata rule sets.
Snort = the name to remember
If the exam asks for a named open-source NIDS tool, Snort is the headline answer — it's the one the slides single out for its own dedicated slide (real-time traffic analysis + packet logging + rules language + plug-in detection engine).
Exam Tips & Tricks
IDS = detect, IPS = detect + block
IPS is placed inline; IDS typically sits off to the side inspecting a copy of traffic. Don't say IDS "blocks" traffic — that's IPS's job.
Signature = known threats only
Signature-based detection has low false positives but zero-day blindness. Anomaly-based catches unknowns but has more false alarms. This trade-off is a favorite exam question.
False Negative is worse than False Positive
A false negative means a real attack was missed entirely. A false positive is just a false alarm — annoying, but not dangerous.
Six classification axes, in slide order
Approach → Protected system → Structure → Data source → Behavior after attack → Analysis timing. Each axis has exactly 2–3 categories.
NIDS sees the network, HIDS sees one host
Hybrid IDS = low false-positive rate of NIDS + anomaly detection strength of HIDS, aimed at catching unknown attacks.
Four NIDS deployment locations
(1) Behind firewall/in DMZ, (2) outside the firewall, (3) on network backbones, (4) on critical subnets. Each has its own advantage worth memorizing.
IDS is not antivirus, not a vuln scanner, not crypto, not just a log system
A favorite "what IDS is NOT" trick question — remember the LVAC list.
Snort is the star tool
Open-source, real-time traffic analysis + packet logging, rules-based, modular plug-in detection engine. Know it as the flagship named NIDS example.
Quick Reference — Everything at a Glance
| Topic | Key Point |
|---|---|
| IDS/IPS | Network security appliance that inspects inbound/outbound traffic for suspicious patterns |
| IDS vs IPS | IDS detects and alerts (passive); IPS detects and blocks (inline) |
| IDS placement vs firewall | IDS works from inside the network and sits behind the firewall; firewall only looks outside |
| IDS pipeline | Internet → Router → Firewall → IDS → signature/anomaly/protocol checks → alarm + action |
| Signature (misuse) detection | Matches known attack patterns; low false alarms; can't catch unknown/variant attacks |
| Anomaly detection | Flags deviation from learned normal behavior; catches unknowns; more false alarms |
| Stateful protocol analysis | Compares activity to protocol's own accepted-behavior profile; flags command-order/authenticator anomalies |
| Six classification axes | Approach, Protected system, Structure, Data source, Behavior after attack, Analysis timing |
| NIDS | Network intrusion detection system — protects the network |
| HIDS | Host intrusion detection system — protects one host; install on every critical/every host |
| Hybrid IDS | Combines NIDS's low false-positive rate with HIDS's anomaly detection to catch unknown attacks |
| Centralized IDS | All data shipped to one central location for analysis |
| Distributed IDS | Several IDS deployed across a large network, communicating with each other |
| Active IDS | Detects AND responds to intrusions |
| Passive IDS | Only detects intrusions (listen and monitor) |
| Interval-based IDS | Stores and forwards data; analyzes offline |
| Real-time-based IDS | Continuous flow from monitoring points to analysis engine; analyzes on the fly |
| Data sources | Audit trails (app flaws/violations) vs network packets (well-known attacks) |
| IDS capabilities | Monitor user/system activity, analyze configs/vulnerabilities, assess integrity, track policy violations |
| IDS/IPS is NOT | A logging system, a vulnerability scanner, antivirus, or a cryptographic system |
| Common config mistakes | Blind spots in placement, ignoring alerts, no response policy, poor false pos/neg tuning, stale signatures, inbound-only monitoring |
| General intrusion indicators | File system (new/missing files), network (repeated probes, odd logins), system (slow performance, gaps in logs, crashes) |
| IDS components | Network sensors, Command console, Alert systems, Response system, Attack signature database |
| Network sensor placement | Internet gateways, between LAN connections, remote-access/VPN servers, either side of firewall |
| Command console rule | Must run on a dedicated system — non-dedicated hosts slow down security event response |
| Response system rule | Don't rely on it solely — a human must decide on false positives/escalation |
| Attack signature database | Must be updated periodically; IDS compares traffic against it to raise alerts/block |
| Staged deployment | Roll out in stages to learn how much monitoring/maintenance is actually required |
| NIDS deployment Location 1 | Behind external firewall / in DMZ — monitors outside attacks, DMZ server attacks, compromised-server outbound traffic |
| NIDS deployment Location 2 | Outside the external firewall — counts/types all Internet-origin attack attempts |
| NIDS deployment Location 3 | On major network backbones — inspects large traffic volumes, catches outside unauthorized attempts |
| NIDS deployment Location 4 | On critical subnets — focuses on the most critical systems/resources |
| HIDS deployment | Install on every critical system (ideally every host); use centralized management/reporting |
| Alert definition | Graduated event notifying that a threshold was reached; requires action from a responsible party |
| True Positive | Attack happened + alert raised (correct) |
| False Positive | No attack + alert raised (false alarm) |
| False Negative | Attack happened + no alert (missed attack — most dangerous) |
| True Negative | No attack + no alert (correct) |
| Good IDS characteristics | Runs continuously, fault tolerant, subversion-resistant, low overhead, spots deviations, hard to deceive, tailored, adapts to dynamic behavior |
| Selection criteria | General requirements, security capability, performance, management requirements, life cycle costs |
| Snort | Open-source NIDS; real-time traffic analysis + packet logging; rules language + plug-in detection engine |
| Other tools | Suricata, AlienVault OSSIM, SolarWinds Security Event Manager, OSSEC, Zeek, Sagan Log Analysis Engine |