Skip to content
Notifications
Clear all

News reaction: New IDP signatures update broke our legacy app. Rollback steps?

2 Posts
2 Users
0 Reactions
23 Views
(@ci_cd_crusader_v2)
Honorable Member
Joined: 5 months ago
Posts: 513
Topic starter   [#12597]

Just ran headfirst into the latest automatic IDP signatures update on our SRX340 cluster. Classic. The new "enhanced" HTTP inspection logic is now flagging our legacy internal inventory app's SOAP calls as a "HTTP:EVIL:UNUSUAL:HEADER" threat. The app hasn't been touched in years, but it was humming along just fine until 2 AM this morning.

Has anyone else hit this with the recent sig pack? I'm looking at the threat logs and it's a clean kill of the session. No graceful failure. The so-called "application visibility" just cost us visibility into a core process.

I've got a rollback plan, but I'm curious if there's a more surgical fix before I revert the entire signatures package. The obvious workaround is to create an exemption policy, but that feels like putting a bandage on a bullet wound the vendor shot us with.

For anyone needing to rollback, here's the CLI sequence. Assume you have a backup of the old sigs, or download the previous version from the support site.

```shell
# Set the security-idp security-package to rollback
request security idp security-package rollback

# Confirm the rollback version
show security idp security-package version

# Commit and force a policy recompile
commit
request security idp security-package install
```

Post-rollback, you'll need to disable automatic updates unless you enjoy 2 AM firefights. The real question is whether we should be letting these black-box updates anywhere near our perimeter without a staging run in a lab we don't have time to maintain.


null


   
Quote
(@freddiem)
Reputable Member
Joined: 3 months ago
Posts: 295
 

That rollback sequence is spot on, but if you're pressed for time, the quick surgical fix might be to tune the signature itself. Before I rolled back last quarter, I found the specific sig ID in the threat log and set it to `no-action` for that specific server subnet.

Something like this in your IDP policy rule:

```
set security idp idp-policy your-policy rule rule-name your-rule match application default
set security idp idp-policy your-policy rule rule-name your-rule then action no-action
set security idp idp-policy your-policy rule rule-name your-rule then notification
```

It's still a bandage, but at least it's a targeted one while you figure out if the app can be tweaked or if you need to stick with the older sig pack. Did you catch the exact signature number from the log? Sometimes they're false positives on SOAPAction headers.



   
ReplyQuote