app web-browsing not allowing soap after 545 update.

[rrowe]

Application and Threat Content Release Notes Version 545 had a modification on an app for SOAP. We had a rule that was allowing users for the app 'web-browsing' and now it is showing them denied using Application soap on port 80. The users are app developers using visual studio. They are fixed now by allowing on a new rule for service port 80. Thats more or less a FYI, my question is: If you have a rule with a group of apps and instead of using the service 'application-default' you add a port, will the apps use its default ports AND that service port OR the apps will try to use ONLY that listed service port ?

[Raido_Rattameister]

Lets assume you have 2 applications in one rule "web-bworsing" and "ssl".

If you use application-default as service then web-browsing runs on 80 and ssl runs on 443 only.

If you create 2 new services tcp-80 and tcp-443 (there are preconfigured services actually for http and https) and change application-default to those 2 services then web-browsing can run on 80 and 443 and same with ssl - can run on 80 and 443.

Basically there are AND between columns and OR between rows in single policy.

[clindloff]

I have/had the same issue.  Two rules, one inbound and one outbound allowed the App ID's "ssl" and "web-browsing".  On the 17/18th they broke because they were being denied on port 80 App ID "soap".

Changing the rules to ports (80/443) fixed the problem.  Final solution was to go back to App ID and allow "ssl", "web-browsing" and "soap".

Is there a good way to be notified when this kind of change (App ID change?) happens?

Thanks!

[rrowe]

Maybe this could be a feature request. If I had a lot of apps using app-default svcs, then a request for a special port needs to be added, then its either a new rule or add all ports for all apps listed for the rule, which could be easy to miss something.. Thanks..

[rrowe]

Are you subscribed to the updates@paloaltonetworks.com ? http://support.paloaltonetworks.com/ Thats where I got an email on the 'Modified Applications' But still had to put 2 and 2 together to troubleshoot. If the dev team didnt know to ask for ANY changes, they could have spent days debugging their code, etc... Its hard to tell what is affected when such a HTTP decoder is modified too.. FYI...

[Bwilli]

We had the same issue. The fix was also allowing SOAP on the security policy, in addition to web-browsing. We also rolled the app and content update back to version 544-3039 (from 12/8/2015) and only allowed web-browsing as the app. This fixed it, too, confirming the problem was how SOAP was identified in version 545. I opened a case with Palo Alto to see if there was any further detail about what was changed. Turns out they consider what they changed as a fix because SOAP traffic wasn't being properly ID'd before as that and was showing up as web-browsing.

What this'll probably end up causing though for us in the long run is disabling automatic updates like this in production and testing them out in a non-production environment first. Honestly surprised this sort of thing hasn't happened to us before. 

Good ideas to write allow policies based on port as a "safeguard." However, doesn't that allow any app on the defined port to get through? I guess it's a tradeoff between security and functionality...

[clindloff]

"However, doesn't that allow any app on the defined port to get through?"

Yes it does.  This is one of the big reasons we got rid of our ASA's and moved to the PAN products.  We try to use App ID for every Security rule and we are proabably 90% there.