Skip to content

Understanding IDS and IPS

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) inspect network activity for signs of attacks or policy violations. They use similar detection techniques, but they respond differently when suspicious traffic is found.

What you will learn

By the end, you should be able to distinguish IDS from IPS, trace the detection process, interpret its outcome, and identify the safeguards required before enabling prevention.

This page focuses on network-based IDS and IPS. Host-based systems monitor activity on individual endpoints and operate differently.

IDS versus IPS

Intrusion Detection System

An IDS receives a copy of network traffic, analyses it, and generates an alert when activity matches a detection rule. Because it is normally out of band, the original traffic continues to its destination.

Out of band means the IDS observes a copy of the traffic without sitting in its direct path.

Primary outcome: Detect and alert

Intrusion Prevention System

An IPS sits inline with network traffic. It can allow, reject, or drop traffic based on its inspection result, providing an automated enforcement point.

Inline means the traffic passes through the IPS before reaching its destination.

Primary outcome: Detect and block

IDSObserve and alert
IPSInspect and enforce
Traffic pathObserves a copy of traffic
Traffic pathProcesses live traffic inline
ResponseGenerates alerts for investigation
ResponseCan automatically block or reject traffic
Operational effectDoes not directly interrupt network flow
Operational effectCan affect availability if incorrectly configured
Best fitVisibility and threat hunting
Best fitImmediate enforcement

What IDS and IPS are not

FirewallEnforces connection and access policy
Web application firewallProtects web applications and HTTP traffic
SIEMCollects and correlates events from many sources

Connected, but not interchangeable

These tools can work with IDS/IPS but serve different purposes. A detection is also not proof that an attack succeeded: an alert is evidence for investigation, while a prevention action reflects a configured policy decision.

Where they sit in the network

IDS: copied traffic
Internet Network IDS sensor
Alert

Traffic reaches the network while a mirrored copy is sent to the sensor for inspection.

IPS: inline traffic
Internet IPS
Allow or block Network

Every inspected connection passes through the IPS before it can reach the protected network.

How detection works

Signature-based

Matches traffic against known attack patterns, much like comparing it with a list of known warning signs. It is effective for recognised threats but may not detect new or substantially modified attacks.

Anomaly-based

Identifies activity that differs from a baseline, which is a record of what normal activity usually looks like. It can reveal unfamiliar behaviour but may create false alarms until it is adjusted for the environment.

Policy-based

Detects traffic that violates an organisation's rules, such as prohibited protocols, destinations, or connection patterns.

The detection process normally follows five stages:

  1. CaptureReceive traffic directly or receive a copy from a network TAP or mirror port.
  2. Understand the trafficIdentify the network services being used and rebuild complete conversations where possible.
  3. InspectEvaluate the activity using signatures, behavioural logic, and security policy.
  4. Alert or enforceRecord the result and, when configured inline, allow, drop, or reject the traffic.
  5. Review and tuneValidate outcomes, reduce noise, and adjust rules using observed traffic.

Write a simple blocking rule

An alert reports repeated connections from 203.0.113.77 to internal host 10.0.20.15. Assume the source has been investigated and approved for temporary blocking. Complete and apply the simplified Snort/Suricata-style rule.

Suspicious source203.0.113.77 Destination10.0.20.15:443 ActivityRepeated connections
drop ip source_ip any -> $HOME_NET any (msg:"Block suspicious host"; sid:1000001; rev:1;)
  • drop blocks matching traffic.
  • ip applies the rule to IP network traffic.
  • source_ip any identifies the source address and allows any source port.
  • $HOME_NET any means any port on the protected network.
  • msg supplies the alert message, while sid and rev identify the rule and its revision.

2. Apply the rule — drop tells an inline IPS to discard matching traffic.

Key takeaway

An IDS and IPS may detect the same activity. An IDS reports it, while an inline IPS can enforce a configured action. Drop silently discards traffic; reject discards it and may notify the sender. Neither action proves that the underlying detection was correct.

Benefits and operational considerations

Earlier warning

Identify suspicious network behaviour and give analysts evidence for investigation.

Automated enforcement

Use an IPS to interrupt high-confidence malicious traffic before it reaches its destination.

Network visibility

Record protocol and connection details that support monitoring, threat hunting, and incident response.

Audit evidence

Retain alerts and event records to support investigations, reporting, and compliance processes.

Plan for operational limitations

  • Encryption can hide content, packet loss can remove evidence, and traffic travelling along different routes in each direction can leave a sensor with only part of a conversation. Sensor placement determines which traffic can be seen.
  • Poorly tuned rules can create false positives (benign activity flagged) or false negatives (malicious activity missed).
  • An inline IPS must process traffic quickly enough to avoid delays and must remain available when the network needs it. Decide whether traffic should continue if the IPS fails (fail open) or stop (fail closed).
  • Test new rules in alert-only mode where practical, then enable prevention with monitoring, recorded rule versions, a way to undo the change, and regular adjustment based on results.

Solutions in this kit

Both are open-source IDS/IPS engines. Choose according to the surrounding architecture, required integrations, team experience, and testing results.

Established rule ecosystem

Snort

Choose it when: Your team wants a widely adopted, rule-driven IDS/IPS with broad community knowledge.

Strengths: Flexible rules and packet inspection.

Test rules, performance, and inline behaviour in the intended environment. Structured protocol evidence

Suricata

Choose it when: Your team needs detailed protocol inspection and structured event output.

Strengths: Protocol parsing, JSON events, file inspection, and integration options.

Plan for the configuration and tuning required by advanced features.

Validate the fit

Compare rule management, output formats, integrations, inline options, and team familiarity. Test with representative traffic rather than assuming one engine will be faster in every environment.

Continue learning