Signature Update Breaks a Business Application on TCP 8080
MediTrust runs an SRX380 at a clinic. A homegrown inventory application uses TCP 8080 and is accessed by 60 pharmacy users through the trust-to-untrust policy. The policy matches application any and applies an IPS profile named recommended plus antivirus. After a signature update last night, users report that the inventory client disconnects every few minutes; other HTTPS traffic is fine. AppID shows the inventory flow as junos:unknown, and the IPS log shows a high-severity signature with action drop on the server-to-client direction. The security team wants to disable IPS globally to restore service, while the vendor says the application is HTTP-like and should be allowed. The clinic cannot accept unmonitored traffic, and a change freeze starts in four hours.
1. How would you confirm that IPS, rather than the application or the network, is causing the disconnects?
Read the worked answer
I would correlate the disconnect times with IPS log entries and the session table. The IPS log already shows a drop action on the server-to-client direction for the same flows, which is strong evidence. I would confirm the signature ID, the policy that matched, and whether the drop is occurring on the return path only. A flow trace filtered to one affected client and TCP port 8080 can show the session being torn down after the IPS event. I would also check whether the application works when tested through a temporary policy that permits the same source and destination with no IPS, but I would not disable IPS for all users. Comparing the application behavior before and after the signature update, and checking whether the vendor changed the client, helps rule out an application-side change. Finally, I would verify that antivirus is not also scanning and blocking the same flow; the log should distinguish IPS from UTM actions.
2. What is the most defensible fix under the change freeze, and why is disabling IPS globally a poor choice?
Read the worked answer
The defensible fix is a narrow exception: create a custom AppID signature for the inventory application, match it in a policy above the broad application-any policy, permit only the required users and destinations, and either remove IPS for that custom application or attach an IPS profile with the offending signature exempted. This preserves IPS for all other traffic and documents the business exception. Disabling IPS globally removes protection for every user, including HTTPS and email, and violates the clinic's requirement for monitored traffic. It also creates a dangerous precedent: the next unknown application will produce the same response. If time is too short to build a custom signature, an IPS exemption for the specific signature ID and destination server is a temporary control, paired with a ticket to implement the custom application. The policy must still be specific; do not exempt the signature for all destinations. After the change, clear the AppID cache so the new signature is evaluated.
3. How would you validate the exception and monitor it after the change?
Read the worked answer
Validate with a test user on the affected subnet, confirming that the inventory client stays connected through several save cycles and that the IPS log no longer shows the drop for that signature and destination. Check that the session table shows the expected policy and that AppID now classifies the flow as the custom application rather than junos:unknown. Confirm that other traffic still hits the original IPS profile by testing a known signature or reviewing IPS counters. Monitor for 24 hours for new signature hits on TCP 8080, and review whether the custom signature is too broad. Also verify that antivirus and any other UTM features still apply as intended. Document the exception with the business owner, the signature ID, the source and destination scope, and an expiry date. If the vendor updates the application, retest the signature because the matching pattern may no longer be valid.