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.

What are IDS and 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.

Why IDS and IPS matter

Detect threats earlier

Identify suspicious network behaviour and give analysts evidence for investigation.

Enforce tested decisions

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

Improve network visibility

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

Preserve audit evidence

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

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.

What makes IDS and IPS useful

Start with a network question

Can we detect and safely stop this specific unwanted traffic?

  1. 1Choose visibilityPlace the sensor where it can observe the required traffic.
  2. 2Define detectionMatch the smallest reliable protocol, address, direction, and content conditions.
  3. 3Test safelyValidate the rule in alert-only mode against target and benign traffic.
  4. 4Enforce and verifyEnable prevention, confirm the result, and retain a rollback path.
Plan for operational friction
Encrypted trafficPacket lossAsymmetric routesNoisy rulesSensor latencyFail-open decisions

Sensor placement determines visibility, and a match does not prove malicious intent. Tune false positives and false negatives, record rule versions, monitor inline availability, and test how to undo every prevention change.

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