Intrusion Prevention
This domain tests how IPS signatures, protocol anomaly detection, and response actions attach to traffic on a USG. Expect questions about why an IPS profile did not block an attack.
Core rules
- IPS is signature- and anomaly-based; signatures carry severity, category, and actions such as alert, block, or reset.
- An IPS profile is applied to a security policy rule that permits the traffic. Traffic denied by policy never reaches IPS inspection.
- Inline IPS can drop malicious packets; detection-only mode logs without blocking.
- Encryption limits inspection unless the gateway terminates the tunnel or decrypts the traffic.
- Tuning matters: broad signatures create false positives; exceptions and thresholds reduce them.
Worked example
A DMZ web server is hit by SQL injection. Permit Untrust-to-DMZ HTTP and HTTPS, attach an IPS profile with SQL-injection signatures set to block, and enable logging. Reasoning: the policy must permit first; the profile then inspects the permitted flow; the signature action decides drop versus alert. If the rule is deny, IPS is irrelevant because no packet reaches the inspection engine.
Traps that cost marks
- Attaching IPS to a deny rule.
- Expecting IPS to inspect IPsec traffic without decryption.
- Setting every signature to block and breaking business applications.
- Ignoring signature updates and false-positive tuning.