Intrusion Detection and Prevention
Intrusion detection and prevention systems monitor network or host activity for signs of attack. Detection raises an alert; prevention also takes an action such as dropping traffic or ending a session.
itDefensive security and security operations | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Dont Panic — Intrusion Detection and Prevention
An intrusion detection and prevention system watches events, decides whether they look troublesome, and then either tells someone or interferes with traffic. It exists because packets, logs, and process events are poor at filing their own incident reports. Before this layer, people had the same raw evidence and a larger collection of hopeful assumptions.
The useful model is a control loop: collect an event, add enough state to understand it, apply detection logic, and produce an alert or action. A sensor may watch copied network traffic, wireless activity, flow patterns, or local host events. Each view has blind spots. A network sensor can notice a connection. A host sensor can show what happened after it arrived. Neither gets to declare itself the whole story merely because it has a dashboard.
The awkward fork is inline prevention. A passive IDS observes a copy of traffic, so a bad match wastes analyst time. An inline IPS sits in delivery, so the same bad match can break a legitimate service. Rule promotion starts with replay and alert-only observation, then narrow tuning, then controlled blocking with a rollback path. The rule has not become more correct because it became more enthusiastic.
Signatures match known patterns. Anomaly detection compares behavior with a baseline. Stateful protocol analysis checks whether a conversation follows protocol rules. They cover different failures, and all trade false positives against false negatives. Encryption adds a complication: a payload signature cannot inspect ciphertext, although metadata or host evidence may still help. The sensor sees only what reaches it and what it can interpret, which is less comforting than a blinking green light but considerably more useful.
Read the Intro for architecture and placement choices. Use Slides for the control path and comparisons. Keep the Cheatsheet nearby when evaluating rules, alerts, and health signals. The Practice reference and exercise turn a harmless packet capture into a tested rule result. Field Notes covers operational costs after the alert starts arriving. The reference links lead into standards and tool documentation once the vocabulary has stopped behaving like a small ambush.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://csrc.nist.gov/pubs/sp/800/94/final
Supports
- IDPS purpose, components, detection methods, technology classes, deployment, operation, prevention actions, false positives, false negatives, and evasion
- Passive and inline distinctions, sensor placement, tuning, health monitoring, and complementary controls
- Quiz answers and the primary reference path
- https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-94.pdf
Supports
- Detailed false-positive and false-negative tradeoffs
- Prevention through session termination, external control changes, blocking, and content modification
- https://csrc.nist.gov/glossary/term/intrusion_detection_system
Supports
- IDS definitions and network-based versus host-based vantage points
- Reference-link rationale
- https://docs.snort.org/start/inspection
Supports
- Packet capture, interface inspection, passive mode, inline mode, DAQ, and direct blocking
- https://docs.snort.org/rules/
Supports
- Rule headers, bodies, required option matching, actions, protocols, addresses, ports, and direction
- The claim that an alert establishes a rule match rather than successful compromise
- https://docs.suricata.io/en/suricata-8.0.3/ips/index.html
Supports
- Suricata inline IPS operation and deployment arrangements
- https://docs.suricata.io/en/suricata-7.0.15/rules/thresholding.html
Supports
- Alert threshold modes and the continued application of drop and reject actions to matching packets
- https://docs.suricata.io/en/suricata-8.0.0/output/eve/
Supports
- EVE alerts, anomalies, protocol records, flows, drops, and statistics
- https://www.ossec.net/docs/index.html
Supports
- Host-based log analysis, integrity checking, registry monitoring, rootkit detection, alerting, and active response
- OSSEC reference, awesome-link, and landscape placement
- https://github.com/sbilly/awesome-security
Supports
- Discovery of Security Onion, OSSEC, Wazuh, CrowdSec, and Fail2Ban for the IDS, IPS, host IDS, and host IPS ecosystem
- https://securityonionsolutions.com/software/
Supports
- Suricata signature detection, protocol metadata, packet capture, host visibility, hunting, and case management in a sensor grid
- Security Onion awesome-link and landscape rationale
- https://documentation.wazuh.com/current/getting-started/index.html
Supports
- Wazuh agent, server analysis, indexer, dashboard, and response architecture
- Wazuh awesome-link and landscape rationale
- https://docs.crowdsec.net/u/getting_started/intro/
Supports
- Log acquisition, parsing, behavior scenarios, decisions, and separate remediation components
- CrowdSec awesome-link rationale
- https://github.com/fail2ban/fail2ban
Supports
- Log-driven detection and firewall-rule enforcement after repeated failures
- Fail2Ban awesome-link rationale
- https://www.snort.org/
Supports
- Snort landscape identity, open-source engine, rule-driven IDS and IPS placement
- https://suricata.io/
Supports
- Suricata landscape identity as an open IDS, IPS, and network security monitoring engine
- https://secure.cisco.com/secure-firewall/v7.6/docs/intrusion-policy-73
Supports
- Snort inspection, network analysis policy, intrusion rules, alert and block actions, and inline deployment
- Cisco Secure Firewall landscape placement
- https://docs.paloaltonetworks.com/advanced-threat-prevention/getting-started/about-advanced-threat-prevention
Supports
- Firewall-integrated signatures and inline analysis for exploits, malware, and command-and-control traffic
- Palo Alto Networks landscape placement
- https://docs.fortinet.com/document/fortigate/7.2.10/administration-guide/565562
Supports
- FortiGate IPS signatures, protocol decoders, heuristics, threat intelligence, and inspection profiles
- Fortinet landscape placement
- https://www.checkpoint.com/quantum/intrusion-prevention-system-ips/
Supports
- Gateway protections, detect-only mode, recommended profiles, scope, prevention, and virtual patching
- Check Point landscape placement and virtual-patching quiz answer
- https://www.trendmicro.com/en/business/products/network/integrated-atp/next-gen-intrusion-prevention-system.html
Supports
- Dedicated inline inspection, enforcement, centralized management, and vulnerability-focused filters
- TippingPoint landscape placement
- https://www.trellix.com/products/network-security/
Supports
- Conventional IPS, behavioral analysis, sandboxing, and inline blocking
- Trellix landscape placement
- https://www.cerias.purdue.edu/about/history/coast_resources/idcontent/ids_bib.html
Supports
- April 1980 publication of James P. Anderson's Computer Security Threat Monitoring and Surveillance report
- https://faculty.nps.edu/dedennin/
Supports
- August 1985 IDES requirements and model report
- February 1987 publication details for An Intrusion-Detection Model
- https://doi.org/10.1109/TSE.1987.232894
Supports
- The 1987 audit-record, profile, statistical-model, and rule framework milestone
- https://docs.zeek.org/en/current/about/history.html
Supports
- Bro design in 1995, deployment in 1996, original paper publication, and project evolution
- https://secure.cisco.com/secure-firewall/v7.2/docs/snort-3-adoption
Supports
- Snort as a 1998 network sniffer, 1999 IDS, and 2004 inline IPS
- https://csrc.nist.gov/pubs/sp/800/31/final
Supports
- November 2001 IDS guidance and its enterprise integration scope
- https://suricata.io/timeline/
Supports
- First code in 2007 and OISF formation with Suricata 1.0 release in 2010
- https://zeek.org/2018/10/renaming-the-bro-project/
Supports
- October 2018 adoption of the Zeek name and continuity with the Bro project
- https://docs.suricata.io/en/latest/command-line-options.html
Supports
- Offline PCAP replay, exclusive rule loading, configuration testing, and output directories for the practice reference and exercise
- https://docs.suricata.io/en/latest/output/eve/eve-json-format.html
Supports
- Alert fields and PCAP replay context used as observable exercise results
- https://docs.suricata.io/en/latest/performance/statistics.html
Supports
- Capture and drop counters plus TCP reassembly gaps for the Field Notes signal card
- https://corelight.com/blog/ai-assisted-rule-writing
Supports
- Field Note on trusted rule test corpora and validation before production use
- https://corelight.com/blog/beating-alert-fatigue-with-integrated-data
Supports
- Field Note on preserving alert context for investigation
