Custom IPS Signature Not Matching Due to Wrong Protocol Decoder
A FortiGate administrator configures a custom IPS signature with the pattern 'attack' in the HTTP request URI. After applying the signature, no alerts are generated even though the traffic matches. What is the MOST likely cause?
Quick Answer
The answer is that the custom IPS signature is not matching because its protocol decoder is not set to HTTP. Without explicitly assigning the HTTP decoder, the FortiGate IPS engine does not know to parse the HTTP request URI for the pattern 'attack'; instead, it inspects the raw packet payload against the wrong protocol layer, causing the signature to never trigger. On the Fortinet NSE 7 Advanced Security NSE7 exam, this tests your understanding that custom signatures require a precise decoder assignment to match application-layer traffic—a common trap is assuming the IPS engine automatically detects the protocol from the traffic flow. Remember the memory tip: “No decoder, no detector”—if you omit the protocol decoder, the pattern is blind to the URI.
⚠ Common exam trap
Candidates often assume a signature will automatically inspect all traffic or that the 'pass' action suppresses alerts, when in fact the protocol decoder is a mandatory prerequisite for any application-layer pattern matching in FortiGate IPS.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The signature's protocol decoder is not set to 'HTTP'
The custom IPS signature pattern 'attack' will only be inspected against the HTTP request URI if the signature's protocol decoder is explicitly set to 'HTTP'. Without this decoder assignment, the IPS engine does not know which protocol layer to parse, and the pattern is never matched against the URI, resulting in no alerts despite matching traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The signature's protocol decoder is set to 'HTTP'
Why it's wrong here
Setting the protocol decoder to HTTP is required for URI matching, so it cannot explain missing alerts. It is tempting because a mismatched decoder is a common custom-signature fault, but here the decoder is correct; the failure lies elsewhere, such as the action or the profile not being applied.
- ✗
The signature action is set to 'pass'
Why it's wrong here
A 'pass' action lets matching traffic through without logging or blocking, so no alert fires even though the pattern matches. Setting the action to 'block' or 'alert' would generate the expected event. Pass is intended for traffic you deliberately want to exempt from inspection, such as trusted internal flows.
- ✓
The signature's protocol decoder is not set to 'HTTP'
Why this is correct
A custom signature only inspects traffic handled by its assigned protocol decoder. Without the HTTP decoder, the pattern 'attack' is never evaluated against the request URI, so matching traffic passes uninspected and generates no alerts.
- ✗
The signature severity is too low
Why it's wrong here
Severity only labels the alert's priority; it does not suppress detection or logging. It is tempting because low-severity signatures are easy to overlook in filtered log views, but the signature would still generate an alert, so severity cannot explain the total absence of alerts.
Go deeper
Related to this question
About these practice questions
Courseiva writes every NSE7 question from scratch — 718 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on NSE7
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An IPS administrator wants to detect a new custom attack that sends malformed HTTP headers. The attack pattern is a specific sequence of bytes that is not covered by existing signatures. What is the BEST way to detect this attack on FortiGate?
medium- A.Use an automation stitch to block traffic with unusual headers
- B.Enable protocol anomaly detection in the IPS sensor
- C.Deploy FortiWeb as a reverse proxy
- ✓ D.Create a custom IPS signature
Why D: Custom IPS signatures allow you to define a specific byte sequence or pattern (e.g., via a regular expression or hex pattern) that matches the malformed HTTP header. FortiGate's IPS engine can then inspect HTTP traffic at the application layer and trigger an alert or block when the custom pattern is found, even if no existing signature covers it.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE7 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE7 exam.