any to application default

[jdprovine]

We are working on hardening our firewall rules by replacing any to application default(service) and from any to the specific application(application). Example - we changed any to web-application and any to application-default. People hitting the same rule had different results some it didn't work and they weren't able to get to the web page and some could. Didn't matter what browser

[Brandon_Wertz]

Application "web-browsing" includes only tcp/80.  Are you seeing denies of those users where it didn't work on ports other than the standard port or are you seeing denies for users to web-browsing over port 80?

Were the users that are being denied going to the same URL?

[jdprovine]

Yes going to the same url

[Brandon_Wertz]

What does the block log say?  Is it going to the same port?  Is the user apart of the same security groups that the other user(s) are that are working?

Maybe they're not hitting the same rule because of group association?

[rmonvon]

Hi...Please check the traffic & url logs to see what app(s) are being denied.  It is possible that the user is visiting a web page and some of the contents are detected as flash, http-audio, etc.  We need to verify that policies are allowing these apps.  

[jdprovine]

as I said previously we are all testing with the same url and getting different results on the same browser

[Brandon_Wertz]

lol...look dude.  We aren't TAC.

If you don't wanna share policy/config stuff for OPSEC / Confidentialy reasons fine.  But you've really provided no substantive information with which any of us can make any sort of definitive statements of support.

to say..."As I said previously" is tant amount of "look moron...I just said above..."

Again, we're just trying to be help.  If you aren't getting what you need here, feel free to open a TAC case.

[jdprovine]

I already opened a TAC case

[reaper]

if you compare logs between the successful and unsuccessful sessions, are all users hitting the same policy?
is there a generic drop rule set to logging so you can verify if some sessions may not be hitting a policy (the default implied drop-all policy at the end of your rule base does not log, so you may be discarding sessions and not know about it)

if the policy goes "trust - untrust- web-browsing - app-default" the only reason sessions would get blocked using the web server is running (sometimes?) on a non-standard port or the application is identified as something other than web-browsing (might be Facebook or something else for example which would cause the block)


hope this helps

[mivaldi]

Some sites are listed in the HSTS list, which means that even if you're trying to browse to the HTTP site, your browser will force it to go to the HTTPS version, which requires ssl application to be added to the policy.

Not all browsers will process HSTS, so different browsers may yield different results. Those that don't push you to HTTPS will work, and you'll fail as long as you don't add application ssl to the list.

[jdprovine]

Very interesting thought reaper, it does seem that there is something that is not being identified as the standard port for the site. But its more interesting that two different users can go to the same link on the same browser, one is allowed and one is not. The only other thing I can think of to try is two have the failing user log on to the workings uses laptop and see if he can get to it from there

[jdprovine]

So you are saying that even thought they are using the same browser and the same thinkg there could still be a slight difference between the browsers enough to have it not recognized by the PA as that port/app. That's going to make it hard to harden some of the firewall settings