# Juniper SRX IDP/IPS — Signatures, Policies & Inline Enforcement Source: https://ai.techclick.in/blog_juniper_srx_idp_ips Markdown: https://ai.techclick.in/blog_juniper_srx_idp_ips.md Publisher: Techclick Infosec Pvt Ltd Master Juniper SRX IDP/IPS in 2026: attack objects, signature database updates, IPS policy rule-bases, custom signatures, recommended policy, and inline vs inline-tap enforcement modes — all with interview-ready framing. Juniper SRX IDP/IPS — Signatures, Policies & Inline Enforcement student learning map A visual study map for Juniper SRX IDP/IPS — Signatures, Policies & Inline Enforcement showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Juniper SRX IDP/IPS — Signatures, Policies &... Juniper · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① How Juniper SRX IDP/IPS works —... 4. Practice ② The IDP signature database —... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. Figure 1 — SRX IDP/IPS detection pipeline Every inspected session flows through this five-stage pipeline before a packet exits the SRX. - SRX IDP/IPS detection pipeline Zone match security policy fires IDP attach IDP policy selected Inspect stream reassembled Match attack object hit Action drop / alert / log Every inspected session flows through this five-stage pipeline before a packet exits the SRX. Quick check · Q1 of 10 · Understand What must happen before an SRX IDP engine can match any attack? a) Enable IDP in the global config and reboot b) Download and install the signature database, then attach an IDP policy to a security zone-pair c) Purchase a UTM bundle and enable Unified Threat Management d) Enable flow mode — IDP activates automatically Correct: b. The IDP engine needs two things: the signature database (attack objects to match against) and an IDP policy attached to a security policy on the right zone-pair. Without both, no inspection happens. 👉 So far: SRX IDP/IPS pipeline: security policy fires → IDP policy attached → engine inspects stream → attack object matched → action taken. Without the database and policy attachment, no inspection happens. ## ② 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. Figure 2 — Signature database layers The security package bundles predefined objects into groups you reference in rule-bases. - Signature database layers Dynamic groups auto-include by filter (severity, OS, vendor) Attack object groups curated bundles (e.g. Windows-Critical) Attack objects individual signatures & protocol anomalies The security package bundles predefined objects into groups you reference in rule-bases. 📦 Security Package tap to flip 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. 🎯 Attack Object tap to flip 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. 📋 Recommended Policy tap to flip A Juniper-provided IDP policy template bundled in the security package. Activating it immediately covers high- and critical-severity attacks — the safest starting baseline. ⚡ Dynamic Attack Group tap to flip 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. Use dynamic attack groups for maintainability 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. Quick check · Q2 of 10 · Remember Which attack object type catches attacks that violate the protocol specification rather than matching a known byte pattern? a) Custom signature attack b) Dynamic group filter c) Protocol anomaly attack d) Terminal rule match Correct: c. Protocol anomaly attacks flag traffic that violates the RFC definition for a protocol (e.g. malformed HTTP headers). They catch zero-day variants that bypass pure signature matching. 👉 So far: The security package contains predefined attack objects (signatures + protocol anomalies) and the recommended policy template. Download + install before configuring any IDP policy. ## ③ 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. Figure 3 — IPS policy — one policy, three rule-bases A single IPS policy contains three rule-base types, all evaluated in order per session. - IPS policy — one policy, three rule-bases IPS Policy active policy name IDP rule-base Exempt rule-base Terminal rule-base Recommended policy Zone-pair attach A single IPS policy contains three rule-base types, all evaluated in order per session. Forgetting to attach the IDP policy to the security policy 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. ① SYN arrives Attacker sends an HTTP GET with a CVE exploit payload toward the DMZ web server through the SRX untrust→DMZ zone-pair. ▼ ② IDP engine The security policy permits the zone-pair and calls the attached IDP policy. The IDP engine reassembles the HTTP stream. ▼ ③ Attack match The attack object for the CVE fires: the payload matches the signature string in the predefined attack object group 'HTTP-Critical'. ▼ ④ Drop + log Action = drop-connection. The SRX sends a TCP RST to the attacker, the session is terminated, and an IDP event is logged with source IP, attack name and severity. Press Play to step through the inline block path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply 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? a) Add an Exempt rule-base entry scoped to that host's IP b) Delete the attack object from the security package c) Move the IDP policy to Terminal rule-base for all traffic d) Disable the recommended policy entirely Correct: a. The Exempt rule-base lets you carve out specific source/destination addresses from IDP inspection, so one noisy host is suppressed while the same signature still fires for all other hosts. 👉 So far: An IPS policy has three rule-bases: IDP (detect), Exempt (suppress known false positives per host), Terminal (stop further evaluation). Attach it to a security zone-pair permit action to activate inspection. ## ④ 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. Figure 4 — Inline vs inline-tap enforcement Inline is the only supported mode on SRX hardware; inline-tap was deprecated in Junos 15.1X49-D10. Inline vs inline-tap enforcement Inline (supported) Engine in forwarding path Can drop / reset in real time Adds latency per session Required for active blocking Inline-tap (deprecated on SRX) Passive copy of traffic Cannot drop packets Not supported on SRX hardware Use SPAN/mirror + separate IDS Inline is the only supported mode on SRX hardware; inline-tap was deprecated in Junos 15.1X49-D10. 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. Likely cause 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. Diagnosis 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) Fix 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. Verify Re-run the Nessus scan: no IDP alerts generated. External attack simulation still triggers alerts correctly — the exemption is host-scoped, not global. Confirm IDP is actually running inline 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? Quick check · Q4 of 10 · Analyze An engineer says 'I will enable inline-tap on SRX so I can passively monitor without impacting traffic.' What is wrong with this plan? a) Nothing — inline-tap is the default on all SRX models b) Inline-tap uses twice the CPU of inline mode c) Inline-tap mode is not supported on SRX Series hardware; use a SPAN/mirror port instead d) Inline-tap only works with custom signatures, not predefined ones Correct: c. Juniper removed inline-tap support on SRX Series starting in Junos OS 15.1X49-D10. For passive analysis on SRX you must SPAN/mirror traffic to a separate IDS sensor. 👉 So far: Inline mode is the only supported enforcement on SRX hardware — inline-tap was removed in Junos 15.1X49-D10. Custom signatures survive package upgrades and can feed dynamic attack groups automatically. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is an attack object in Juniper SRX IDP? How do I get attack objects onto my SRX? What is the recommended policy and when should I use it? What is a dynamic attack group and why use it? What is the difference between inline and inline-tap mode on SRX? How do I write a custom signature for a proprietary application? 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. Q5 · Remember Which Junos OS command installs the IDP signature database on an SRX? a) request security idp security-package install b) set security idp active-policy recommended c) set security policies then permit application-services idp-policy d) request system software add idp-signatures Correct: a. The two-step process is: download with 'request security idp security-package download', then install with 'request security idp security-package install'. Without install, the engine has no attack objects to match. Q6 · Understand Why are protocol anomaly attack objects valuable for catching zero-day exploits? a) They use machine learning to predict future attacks b) They fire on traffic that violates the protocol RFC, catching attacks with no known byte signature yet c) They block all traffic from untrusted zones by default d) They replace the need for signature-based objects entirely Correct: b. Protocol anomaly objects detect RFC violations (malformed headers, impossible field values, etc.), which many zero-day exploits use to evade signature matching. They complement, but do not replace, signature-based objects. Q7 · Apply You activate the recommended IDP policy but legitimate Nessus scans from 10.1.1.10 are triggering false positives. What is the correct fix? a) Delete the recommended policy and write all rules from scratch b) Add an Exempt rule-base entry scoped to source-address 10.1.1.10 for the triggering attack objects c) Disable IDP on all zone-pairs until scanning is complete d) Switch to inline-tap mode so no traffic is dropped Correct: b. The Exempt rule-base suppresses specific matches for defined source/destination addresses without touching the rest of the policy. Deleting the policy removes all coverage; inline-tap is unsupported on SRX. Q8 · Remember Where must you add the IDP policy reference to make the IDP engine inspect traffic on a zone-pair? a) Under 'set security idp active-policy' only b) Under the security zone definition c) Under the security policy permit action as 'application-services idp-policy' d) Under 'set system services idp-policy' Correct: c. The IDP policy is attached at: set security policies from-zone X to-zone Y policy NAME then permit application-services idp-policy MY-IDP. Without this line, the IDP engine never inspects sessions on that zone-pair. Q9 · Evaluate An interviewer asks: 'Should I use inline-tap on my SRX for passive monitoring?' Best answer? a) Yes, inline-tap is the recommended low-impact mode for production SRX deployments b) Inline-tap mode is not supported on SRX Series hardware; for passive monitoring, mirror traffic via SPAN to a dedicated IDS sensor instead c) Only enable inline-tap if CPU usage is below 50 percent d) Inline-tap works on SRX300 series but not SRX5000 Correct: b. Inline-tap was removed from SRX Series support in Junos OS 15.1X49-D10. The correct answer demonstrates knowledge of this specific limitation and offers the correct alternative (SPAN/mirror to a dedicated IDS). Q10 · Analyze A dynamic attack group is configured with filter severity=critical. You install a new security package with 10 new critical-severity objects. What happens to the IDP policy? a) Nothing — you must manually add each new object to the policy rule b) The policy reverts to the recommended policy template automatically c) The 10 new objects are automatically included in the dynamic group, adding new coverage without any policy edit d) The SRX rejects the new objects until you re-commit the IDP policy Correct: c. Dynamic attack groups are filter-based: any new attack object matching the filter (severity=critical) is automatically included after the package install. This is the key advantage of dynamic groups over static lists. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: Step one: create the IDP policy (and set it as active with 'set security idp active-policy'). Step two: attach it to a specific zone-pair security policy permit action using 'application-services idp-policy NAME'. The two-step design lets you have multiple IDP policies for different zone-pairs, all drawing from the same signature database — so a strict policy can apply on untrust-to-DMZ while a looser policy applies on trust-to-DMZ, without duplicating the database. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Juniper SRX at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt