Where I work, we do not allow general access to Social Networking sites. However, we have a facebook site and we'd like a policy to allow internal users access to that specific site only. I ran a rule trace to see what might go into such a policy and judging by the array of connections to CDNs and such, I'm not sure it's feasible. My original theory was to limit access by matching URL.Host and and URL (looking for our account), but like I said, there are many connections to CDNs that are quite generic, so inspecting the various properties isn't effective.
Has anyone else had to implement such a policy? How might I approach this?
Thanks for any suggestions you have.
I came across a couple of posts that looked like they might help:
The second post looks to be exactly what I need, however when I enable the "Allow Connect" rule set, the users are prompted to authenticate. They can cancel and it moves on, but obvioulsy that is not going to work well.
Has anyone tried the technique outlined in DOC-4810? Did you have any issues with it?
My Allowed Connect rule looks like this:
Any input would be appreciated.
we installed different MWG implementations where facebook is controlled based on user, usergroups or IPs.
First of all:
SSL Scan MUST be enabled. Otherwise you are NOT able to control facebook at all.
Afterwards we did different things.
- Application Control on MWG is able to manage different parts of facebook.
- The chat bar can be removed with the HTML Filter without any error message shown to the user.
If a user connects to facebook MWGs "Rule Engine" seed a CONNECT Request to an IP address. At this moment ruleset properties like URL.host or URL.Path and so on are not working, because MWG is not able to see anything within the transaction. THis is not a MWG issue, this is how HTTPS is working.
The ruleset properties can be used after the client has successfully established the SSL/TLS connection, because when the SSL tunnel is established MWG is able to see the whole HTTP Header AND the HTTP body.
Now, it depends.
If you have an own facebook site, today, the URL is always the same. e.g. https://www.facebook.com/MyCompany. Just note, some content will not work, e.g. when a posting is linking to another site or content.
Hope this helps.
Yes, SSL scanning is enabled. The scanning rule is above the “Allow Connect” rule.
Here, Management wants to limit access to just our site on FB. I tried the "Allow Connect" rule, but it somehow interfered with the Authentication rules (the users were repeatedly prompted for credentials). I can’t recall ATM if I moved the Allow Connect rule below the Auth rules, I should go back and test.
The URL, as you mentioned, is mostly the same, except for the CDN connections, where I’ve noticed that in those cases, the referer header has the full URL to the site, so I think that can be managed.
My current sticky issue is the Allow Connect, I don’t know why it breaks the Auth rules.
there must be a good reason why the allow rule interferes with authentication. Since we don't know your policy and how authentication is performed it is hard to find out what is causing the authentication popups. Maybe you should share some more details about how authentiaction is performed and/or troubleshoot a little more (rule engine traces, etc) to find our what is happening. Without further information we won't be able to tell why authentication does not work with that allow rule.
Basically when you access a site like "https://www.facebook.com/andre" the following happens:
- The request goes through the request cycle with Command.Name = "CONNECT". At this stage the SSL traffic is not decrypted, so MWG only sees "www.facebook.com" and has no clue about the path
- Once that finishes another request goes trough the rule engine with Command.Name = "CERTVERIFY". Same limitation applies as for the CONNECT request
- After that the "real" request with Command.Name = "GET" and www.facebook.com/andre goes through the request cycle
If you now make a rule that says
- Allow facebook.com/andre
- Block facebook.com
you have the problem that during the first two cycles I indicated above MWG does not know anything about /andre. Therefore it will block your access to the single allowed website BEFORE MWG sees the path. With the "Allow Rule" you make sure that the first two cycles do not hit your Facebook rules to avoid that the "Block All" rule blocks the request. Only the third request contains the path and will cause your Facebook allow rule to match correctly.
Authentication must interfere somewhere in between. Are you using Authentication Server or explicit proxy authentication? Probably these details help you to find out whats happening.
Thanks for that lucid explanation, that will help a lot.
The basic configuration at this point is non-transparent proxy using kerberos.
I've been deploying this in our production network, bit by bit as policy development progressed. So I can't 'cowboy' it anymore. I'll create a test environment and take it up again after that. I'll post back if the issue is reporduced in the test environment.