application vs url categories dependencies

[LCMember2860]

I want to allow access to Twitter, but block all other social-networking services.

The obvious approach is to allow the Twitter application and then have a rule blocking the social-networking category for web-browsing and ssl, but this doesn't work, Twitter gets blocked also.  In order to allow Twitter to work I have to add twitter.com and *.twitter.com to a custom category and allow this as well.

Surely this defeats the point of having web based applications defined seperately, I have the same problem trying to allow Google Docs but block other file sharing apps - I have to add docs.google.com to a custom category.

If I go to www.twitter.com in a browser, should the firewall not recognise this as "application: twitter"?  Or am I configuring it wrong?  Whitelisting URLs (particularly for backend API and content server urls) in order to get applications to work is not scalable and runs contrary to Palo-Alto's claims to be application-aware.

Liam.

[mikand]

What does your traffic log tells you regarding application when you have the following?

1) Allow appid:twitter

2) Deny appid:<filter all social network>

Today there are application dependencies which might be tricky to workaround.

I guess that in order to allow twitter you must also allow web-browsing. When you allow web-browsing in rule 1 the client will be able to reach even social network sites (until the flow is identified as a particular social network and then blocked by rule 2).

You can see this for Facebook for example. Visiting just the frontpage of facebook is being identified as web-browsing. Not until you have logged in the flow will be identified as appid:Facebook. You can see this if you enable "log on session start".

So in order to totally block even the initial visit to Facebook (before the appengine is 100% sure this really is Facebook) you must add URL filtering to your rules.

The thing to watch out for in this case is if your rule becomes to narrow. You can compare this with skype - in order to block skype you must allow skype-probe.

Rumours says that PANOS 5.0 will somewhat address this so you no longer will be forced to add (for example) web-browsing when you just want to allow twitter. Which means that the PANOS will take care of this for you and also if the flow isnt twitter after a couple of packets it will be denied (compared to today if you have just rule 1 above containging appid:twitter, web-browsing which would allow all sort of web-browsing).

[LCMember2860]

hopefully you're correct about PAN-OS5 - I expect app-id to take care of this for me, I don't want to have to analyse which URLs twitter (for example) uses and whitelist them.  The current implementation may be effective for blocking by application, but not for allowing by application where those apps are dependent on web-browsing, this is fairly major drawback IMO.

Your suggestion of allowing the twitter app and blocking other social-networking by app-filter won't work because not every social networking service is defined as an app, I'd still need to block the URL category and then I'm back to having to whitelist URLs to get twitter to work.

[mikand]

I think you should open a support case to have this investigated (and then update this thread with the result).

Personally I dont see any problem with adding url filtering to narrow the rule down to what is actually being allowed (but I can agree with you that allowing "twitter" should include urls aswell - at least when used in a allow rule, while a deny rule could perhaps ignore the url in order to be as wide as possible). People with a SPI-only firewall have the same problem (they open up TCP80 but have no clue if its really HTTP which is going through that hole).

However if urls would be included in the appid (I guess they already are in some way) you would have a higher probability of false positives, or rather complete misses. You can compare this with facebook which I think not only uses *.facebook.com but also *.fb.com and other sites. By defining appid as the flow itself and not destination used I think you as the administrator have a better option to also include (if you wish) url filtering to also filter on destination (same as appid on its own doesnt necessary act on destination ip, if you want to block something towards a specific ip address you must manually set this up in your security rule in the destination ip column).

Your deny rules can be setup this way:

D1) Deny appid:<filter subcat:social-networking>

D2) Deny url-category: Social Network

while your allow will look something like:

A1) Allow appid:twitter,web-browsing url-filter:*.twitter.com, twitter.com

dont forget to also enable ssl termination so you dont miss HTTPS traffic.