Most engineers think…
Most people assume that enabling IDP on an SRX means the box is automatically blocking attacks with some built-in rule set. That picture costs you in production and in interviews.
Juniper SRX IDP/IPS is a policy-driven inspection engine: you download a signature database of thousands of attack objects, assemble those objects into an IPS policy with rule-bases, and attach that policy to a specific zone-pair in a security policy. Without the database download the engine has nothing to match against. Without the policy attachment the engine never inspects traffic. Understanding this pipeline — database → attack object → rule → policy → zone-pair — is what separates a junior config-paste from a real security implementation.
① How Juniper SRX IDP/IPS works — the detection pipeline
Juniper SRX IDP (Intrusion Detection and Prevention) is a deep-packet inspection engine built into Junos OS. When traffic matches a security policy that has an IDP policy attached, the SRX passes the session to the IDP engine, which reassembles the stream and compares it against attack objects from the signature database. A match triggers the configured action: drop, drop-connection, drop-packet, alert, or close-client/server.
The pipeline is: security policy permits and calls the IDP policy → IDP engine inspects the stream → attack objects are matched → action is taken → an event log is generated. Traffic that matches no IDP rule passes through untouched. The engine is stateful: it tracks sessions, reassembles fragments, and understands application-layer protocols (HTTP, SMTP, DNS, etc.) so it can catch evasion attempts that a simple pattern match would miss.
IDP sits inline in the forwarding path, meaning it sees every byte before the packet exits the SRX. This is different from a passive SPAN monitor: inline IDP can actually drop a malicious packet before it reaches the server.
What must happen before an SRX IDP engine can match any attack?
② The IDP signature database — attack objects and updates
The signature database (also called the security package) is the heart of SRX IDP. It is a file you download from Juniper and install on the SRX. It contains thousands of predefined attack objects grouped into attack object groups (by OS, severity, category, or vendor). Each attack object describes one known exploit — its protocol context, the byte pattern or anomaly, and Juniper's recommended action.
Two types of attack objects
- Signature-based attacks — match a specific byte pattern or string against reassembled application-layer data. Fast and precise for known CVEs.
- Protocol anomaly attacks — flag traffic that violates the RFC specification for a protocol (e.g. an HTTP header longer than the spec allows), catching zero-day variants that bypass signature matching.
You update the database regularly using request security idp security-package download and request security idp security-package install. Dynamic attack groups let you build a rule that automatically includes every new attack object that matches a filter (e.g. all critical-severity Windows objects), so a database update adds new coverage without you editing the policy.
The downloadable bundle from Juniper containing all predefined attack objects, attack groups, and the recommended IDP policy template. Must be installed before IDP can match anything.
A single pattern describing one known attack — either a byte signature (for known CVEs) or a protocol anomaly (for RFC violations). Referenced in IDP rule-base rules.
A Juniper-provided IDP policy template bundled in the security package. Activating it immediately covers high- and critical-severity attacks — the safest starting baseline.
A group defined by a filter (e.g. severity=critical, OS=Windows) that auto-includes every matching new attack object after each signature database update — no manual policy edits needed.
Instead of listing individual attack objects in your IDP rule, use a dynamic attack group filtered by severity=critical and category=exploit. Every new signature that Juniper adds matching those criteria is automatically included after the next security-package update — no policy edits required.
Which attack object type catches attacks that violate the protocol specification rather than matching a known byte pattern?
③ IPS policy and rule-bases — recommended policy and custom tuning
An IPS policy in Junos OS is a named collection of rule-bases. Each rule-base is an ordered list of rules, each matching on zones, addresses, application, and attack objects, with an action (drop-connection, alert, etc.) and an IP action (block-future, notify-mail, etc.). There are three rule-base types:
- IDP rule-base — the main detection rules. Most deployments use this one, referencing attack object groups.
- Exempt rule-base — tells the engine to skip certain matches. Use to suppress known-false-positives for specific hosts or subnets.
- Terminal rule-base — marks a match as final, stopping further rule-base evaluation. Useful for time-sensitive sessions.
The recommended policy is a Juniper-provided template bundled with the security package. Activating it with set security idp active-policy recommended gives you immediate coverage of high- and critical-severity attacks. Use it as a baseline, then add Exempt rules for legitimate traffic that triggers false positives.
After creating or editing an IPS policy you must attach it to a security policy: set security policies from-zone untrust to-zone trust policy ALLOW_WEB then permit application-services idp-policy MY-IDP. Without this step the IDP engine never inspects traffic on that zone-pair.
You can create the perfect IDP policy, but if you never add 'application-services idp-policy MY-IDP' to the security policy permit action on the correct zone-pair, the IDP engine never inspects that traffic. Always verify with 'show security idp statistics' after a commit — a zero counter means the policy is not attached.
▶ Watch a CVE exploit attempt get blocked inline
How an HTTP exploit packet is inspected and dropped before reaching the web server. Press Play for the healthy block, then Break it to see the classic miss.
A specific internal host triggers a false-positive IDP alert every day. Which rule-base suppresses only that host without disabling the alert for everyone else?
④ Inline vs inline-tap — enforcement modes and custom signatures
Juniper SRX IDP operates in inline mode: the engine sits directly in the forwarding path. Every session that hits a security policy with IDP enabled passes through the engine before the packet leaves the SRX. This is the only fully supported enforcement mode on SRX hardware. Inline mode can drop, reset, or alert on malicious traffic in real time.
Inline-tap mode was designed as a passive variant: instead of inspecting the live packet, the engine would receive a copy and analyse it without affecting the forwarding path. However, inline-tap is not supported on SRX Series devices (removed since Junos OS 15.1X49-D10). If you need passive analysis on SRX, use a SPAN/mirror port to copy traffic to a separate IDS sensor.
Custom signatures
When predefined attack objects do not cover a proprietary application or a newly disclosed CVE, you can write a custom attack signature. Define the protocol context (HTTP, TCP, etc.), the direction, and the byte pattern or regex. Add the custom object to a dynamic attack group so it benefits from the same policy plumbing as vendor signatures. Custom signatures survive security package upgrades because they live in a separate user configuration hierarchy.
Arjun at a Pune e-commerce firm faces this
After enabling the recommended IDP policy on the SRX, the SOC is flooded with alerts. A legitimate internal scanner is triggering hundreds of 'HTTP-Port-Scan' events per hour.
The recommended policy covers a broad set of attacks including vulnerability scanners. The internal Nessus scanner's IP was not exempted before the policy went live.
Check the IDP logs: all high-volume alerts share the same source IP — the authorized Nessus scanner. The attack object is correct but the source is not malicious.
CLI: show security idp attack table | match HTTP-Port-Scan — all events from 10.10.1.50 (Nessus scanner IP)Add an Exempt rule-base entry in the IDP policy scoped to source-address 10.10.1.50 and the HTTP-Port-Scan attack object group. Commit and verify alert volume drops to zero for that source.
Re-run the Nessus scan: no IDP alerts generated. External attack simulation still triggers alerts correctly — the exemption is host-scoped, not global.
After committing an IDP config, run 'show security idp status' and 'show security idp attack table' after sending test traffic. If the attack table is empty but you expected hits, check: (1) is the security package installed? (2) is the IDP policy active? (3) is it attached to the right zone-pair security policy?
An engineer says 'I will enable inline-tap on SRX so I can passively monitor without impacting traffic.' What is wrong with this plan?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: explain why attaching an IDP policy is a two-step process in Junos OS. Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- IDP (Intrusion Detection and Prevention)
- The Junos OS deep-packet inspection engine on SRX that matches live traffic against attack objects and takes configured actions (drop, alert, reset).
- Attack object
- A single pattern (signature or protocol anomaly) describing one known attack, stored in the signature database and referenced in IDP rule-base rules.
- Security package
- The downloadable bundle from Juniper Networks containing all predefined attack objects, attack object groups, and the recommended IDP policy template.
- Recommended policy
- A Juniper-provided IDP policy template bundled in the security package; activating it provides immediate coverage of high- and critical-severity attacks as a starting baseline.
- Dynamic attack group
- An attack group defined by a filter (e.g. severity=critical) that automatically includes new matching attack objects after each security package update.
- Inline mode
- The IDP enforcement mode where the engine sits directly in the forwarding path, able to drop or reset malicious sessions in real time. The only supported mode on SRX Series.
- Inline-tap mode
- A now-deprecated passive IDP mode where a copy of traffic was sent to the engine without affecting forwarding. Not supported on SRX Series since Junos OS 15.1X49-D10.
- Exempt rule-base
- An IDP rule-base that suppresses specific attack-object matches for defined source/destination addresses, used to eliminate known false positives without disabling the signature globally.
- Protocol anomaly
- An attack object type that fires when traffic violates the RFC specification for a protocol, effective against zero-day exploits that bypass pure signature matching.
- Custom signature
- A user-defined attack object written in Juniper syntax to detect attacks specific to proprietary applications; survives security package upgrades.
📚 Sources
- Juniper Networks — Junos OS Intrusion Detection and Prevention User Guide (published 2025-06-23). juniper.net/documentation/us/en/software/junos/idp-policy/idp-policy.pdf
- Juniper Networks TechLibrary — IDP Policies overview: rule-bases, recommended policy, and zone-pair attachment. juniper.net/documentation/us/en/software/junos/idp-policy/topics/topic-map/security-idp-policies-overview.html
- Juniper Networks TechLibrary — Attack Objects and Object Groups for IDP Policies. juniper.net/documentation/us/en/software/junos/idp-policy/topics/topic-map/security-idp-attack-objects-groups.html
- Juniper Networks TechLibrary — IDP Signature Database — download, install, and dynamic attack groups. juniper.net/documentation/us/en/software/junos/idp-policy/topics/topic-map/security-idp-signature-database.html
- Juniper Networks TechLibrary — IDP Basic Configuration on SRX Series. juniper.net/documentation/us/en/software/junos/idp-policy/topics/topic-map/security-idp-basic-configuration.html
- Juniper Networks TechLibrary — Intrusion Detection and Prevention Overview — inline vs inline-tap modes. juniper.net/documentation/en_US/junos/topics/topic-map/security-idp-overview.html
What's next?
Got IDP/IPS covered? Next, explore Juniper SRX AppSecure — AppTrack, AppFW and AppQoS — and learn how layer-7 application identification ties into your security policies.