What's the best way to configure selective access to Facebook and Twitter (where some users have full access, while everyone else has no access).
The sources will be identified by IP address for right now (usernames later when I get to that).
So far, all my attempts using combinations of App-ID and URL Filtering Profiles have failed. I think the main thing that is giving me grief right now are the dependencies required for the App-IDs. The Facebook and Twitter App-IDs also need the "Web-Browsing" App-ID to be allow through, but this ends up giving the selected users too much access (because their web-browsing hits this rule instead of the main "Allow Web-Browsing Out" rule further down the list that contains the URL Filtering Profile).
I need to have the URL Filtering Profiles on the "Allow Web-Browsing Out" rule to block access to other social networking sites and other URL categories.
I've beening hitting my head against this brick wall for long enough....
Thanks in advance for the help.
Solved! Go to Solution.
This should work for you.
1) Create a custom URL category that includes facebook and twitter URLS.
So you can create the category to include the following URLS "*.facebook.com/*" and "*.twitter.com/*
2)In the security policy select the following options.
application- web-browsing,facebook-base & twitter
service/URL category- add the custom URL category that you have created in step 1.
This should allow only facebook and twitter.
I think I got it (finally) working. I'll have to do more testing to confirm that it does what I want without allowing something I don't want.
Here's a screenshot of the firewall rules:
I separated the rules into two parts. My thinking was that this way the rule "Twitter and Facebook 2" will only match traffic that is web-browsing AND fits the custom URL category I configured--nothing else. Also, another reason is that Facebook and Twitter pulls dynamic page contents from multiple URLs, which have different URLs (and URL categories)--all of which will automatically be allowed by the "Twitter and Facebook 1" rule because the only URLs (and URL categories) that will match that rule will have an App-ID of facebook or twitter, which is what I want.
Also, here's a screenshot of the custom URL category. Some of the URLs maybe redundant and were added as I was initially testing this solution. I'll have to test some more to see what is needed and delete the extras.
I hope that helps anyone else who is trying to do the same thing I am.......keeping in mind I'm still testing this solution
And thanks again to sdurga for pointing me in the right direction.
Are the *.ak.fbcdn.net, s-static.ak.fbcdn.net and s-static.ak.facebook.com really needed?
I mean doesnt *.facebook.com and *.fbcdn.net already cover these?
I think is more easy to configure that with security police rule with aplications.
SO First create a policy allowing who you want have acess to facebook and twitter , etc....
After create other policy bottow of this policy denied everyone to application facebook and twitter.
If you use URL filter , users can use other sites that connect to facebook with other URL like ebuddy.com.br
As I was working on this earlier, I tried many different things and combinations of things, including adding more and more URLs to see if that helped or not. When I got things working, I did not go back and clean up the URLs I added (yet).
Anyways, after some more trial and error (mostly error), here's the "clean" version of the custom URL category. Note that I removed the /* wildcard from the end of each URL--it seems to make everything work better.
P.S. I forgot to mention that the Facebook App-ID complained about a dependency call "jabber" needed for Facebook-chat. I don't really care about the chat function in Facebook, so I probably won't put much effort in resolving this issue.
In fact, that's what I tried at first. My very first attempt I had four rules, in the following order:
The problem is that before Facebook or Twitter (or many other applications) can be identified, they start out as basic "SSL" (for Facebook, "web-browsing" for Twitter) and as additional traffic is received, the Palo Alto gets enough traffic to identify the application traffic as Facebook or Twitter or whatever. So, the inital traffic (i.e. the first packet of the TCP connection) is classified with a "SSL" App-ID and hits rule #3, which has the URL filtering blocking social networking. Rule #3 will then block the inital Facebook/Twitter traffic, killing the connection before any further traffic is identified as Facebook/Twitter--Rules #2 and Rule #3 are never used.
My original issue was that the Facebook and Twitter App-IDs needed "web-browsing" and "ssl" App-IDs to work, but adding those two dependent App-IDs would have allowed too much access for the selected Facebook and Twitter users. But adding the basic URL filter profile to restrict access would have stopped the Facebook and Twitter App-IDs from working. A little bit of a Catch-22 right there. The custom URL category allows me to have a second "web-browsing" and "ssl" rule that only applies to the specific users I am allowing access to Facebook and Twitter. Everyone else would hit the main "web-browsing" rule near the bottom of the policy list.
I'm not using URL filtering to block Facebook and Twitter, I'm using the Facebook and Twitter App-IDs to allow specific people through. Everyone else hits the Deny All rule at the bottom.
The URL filter is only for the web-browsing and SSL dependencies required for the Facebook and Twitter App-ID.
Instead of allowing facebook (which currently includes: facebook-mail, facebook-chat, facebook-social-plugin, facebook-base, facebook-apps, facebook-posting, facebook-file-sharing - check Application Research Center for more info) you could just allow facebook-base (and perhaps facebook-posting).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!