IPS Exception After a Signature Update Breaks Order Entry
An R81.10 management server protects 3,200 users through four gateways. The IPS blade uses a profile based on Recommended_Profile: protections rated Critical are Prevent, all others Detect. An automatic signature update ran at 02:00. At 08:30, about 600 users of a custom order-entry application on TCP 8443 began receiving resets. The application uses HTTP/2 with long custom headers. SmartConsole logs show the protection HTTP/2 Invalid Header, severity High, confidence High, action Prevent, on gateway GW-3, destination 10.20.30.40. The vendor confirms the headers are valid, but the signature cannot distinguish them. The security team does not want to disable IPS on the gateway or turn off the whole HTTP category. The change must be scoped and reversible, and the team wants visibility if the signature triggers again.
1. Triage the alert and decide the least-disruptive exception design.
Read the worked answer
First confirm correlation, not just coincidence. Check whether the resets started after the 02:00 update, whether other applications or destinations are affected, and whether the same protection fires on other gateways. Reproduce from a test client against 10.20.30.40 and compare logs before and after a temporary Detect action on one gateway. This proves the protection is the cause.
The least-disruptive design is a scoped exception in a custom Threat Prevention profile, not disabling IPS or the HTTP category. Base the profile on the current profile, add an exception for HTTP/2 Invalid Header only, scope it to source 10.30.0.0/16 and destination 10.20.30.40 on TCP 8443, and set the action to Detect rather than Inactive. Detect keeps visibility and still logs the traffic if the signature fires again. Add a follow-up flag and an expiry date so the exception is reviewed.
If only GW-3 is affected, assign the custom profile to GW-3 only. If all four gateways serve the application, assign the scoped profile to all four but keep the source and destination limits. Do not create an exception for the whole HTTP category or for all destinations.
2. Write the implementation steps, including profile scope and policy install.
Read the worked answer
In SmartConsole, create a new Threat Prevention profile named TP_OrderEntry_Exception, based on the existing profile. Open Exceptions and add a protection exception for HTTP/2 Invalid Header. Set the scope to the specific source group or subnet, the real destination object 10.20.30.40, and service TCP 8443. Set the action to Detect and enable Follow Up.
Assign the profile to the affected gateway object or cluster in the Threat Prevention policy. If the gateways share a profile, do not edit the shared profile directly; the new profile keeps the change isolated. Install the Threat Prevention policy to the affected gateways only, not to the whole estate. Confirm the install report shows success on the intended targets.
After install, run a test transaction from a representative client and confirm it succeeds. Check the logs for the protection: the action should show Detect, and the connection should not reset. If the exception does not match, verify the source group membership, the destination object used before NAT, and the service. Keep the old profile export and document the exception ID, owner, and review date.
3. How do you verify the fix and later remove the exception safely?
Read the worked answer
Verify at three levels: user traffic, logs, and policy state. A test user and a small pilot group should complete the order-entry workflow without resets. Logs should show the protection action as Detect, with the correct source and destination, and no Prevent action for that flow. The gateway should show the custom profile assigned and the policy install successful.
Monitor for at least one full business cycle, such as two weeks, including month-end if order volume peaks then. Watch for the same signature firing on other destinations or from other sources; that may indicate the exception is too narrow or the application has other affected flows. Do not remove the exception while the vendor issue is unresolved.
When the vendor provides a fixed header format or Check Point updates the signature, remove the exception in a maintenance window. Reinstall the Threat Prevention policy to the affected gateways, run the same pilot test, and confirm the protection returns to Prevent without breaking the application. Keep the exception history and the test evidence for audit. If the exception must remain, renew it explicitly with an owner and expiry date rather than letting it become permanent.