how to blocked facebook.com using http proxy

[aspangilinan]

hi to all

please help me

how to blocked facebook.com using http proxy

Thanks
Arnel

[christian]

it has been discussed already almost hundreds of time here. I'm sure you will find the answer searching this forum using only "facebook" search string 

[aspangilinan]

ok thanks. 

[Sam Graf]

Christian's search advice is the best because currently there is no simple, easy answer. If there was, we could post a sticky with the answer.

[Lonniebiz]

I blocked facebook by first creating a network object in Zentyal that includes all facebook IP ranges:
Zentyal Web Interface > Network > Objects

List of IP ranges:
http://stackoverflow.com/questions/11164672/list-of-ip-space-used-by-facebook

Then I added a packet filter rule under:
Zentyal Web Interface > Firewall > Packet Filter > Filtering rules for internal networks

This rule blocks all https traffic destined to the facebook object I created. It is fine for them to go to http://facebook.com because it immediately forwards them to
https://facebook.com which is blocked by the rule.

So, essentially if you block only https traffic to their network ranges this is sufficient.

[christian]

  how often do you check if list of IP changed ?
Any other site you block using same approach ?

[ProNetic.dk]

Its petty easy.

1. Create filter profile, under Domains and URL, type in facebook.com and facebook.x (whatever the county your in, mines facebook.dk) and last, set it to "Deny"
2. Go to Access rules, you should have a general rule "All time"
3. Edit the rule
4. Choose decision, set it to "Apply filter Profile"
6. Choose "whatevername you gave the profile" i choosed Facebook as the name.

And now it should be blocked.

[christian]

Its petty easy.
.../...
And now it should be blocked.

Unfortunately, this is not as simple 

This is as simple as what you describe if you have configured HTTP proxy in explicit mode. 

If for some reason you decided to go for transparent proxy, then, due to the way transparent proxy works (packets are intercepted at default gateway level and HTTP requests are transparently sent to proxy while HTTPS requests bypass proxy and go directly through firewall) then HTTPS can't filtered. 

[ProNetic.dk]

Just to clarify im running Transparent proxy, and the HTTPs block also work for me

Edit: just tried it again, and ye it work even for the app on my Samsung III it blocks facebook when running wireless

[christian]

Wow, that's magic then 
I really wonder how this can work at proxy level as, in order to allow HTTPS when running transparent proxy 

If you read this document, although I would not call it "perfect Zentyal Gateway setup" it explains clearly that HTTPS requires additional firewall rule and can't go through proxy transparently.
Is there something new with Zentyal 3.0 bringing some magic stuff between these 2 proxy layers that will permit to transparently intercept and redirect HTTPS flow ?
Still redirection would mean "no HTTPS proxy".
Look at this closer: from webserver standpoint, when proxy is used, web client is your proxy, not your browser. When performing HTTPS request, if done by proxy, it can not (easily) be redirected to browser

Well, if it really works for you, I would like, if you don't mind, spend some time to understand better what you did and why it works.

[Lonniebiz]

Another old way I'd block facebook, was to add its domain into the local dns and point it to the IP of my client's own website. When someone tries to go to facebook they see their own company's website instead 

With this, you can also enable transparent DNS cache, so that if they try using a public dns, it will be intercepted by the local DNS after entering the Zentyal Gateway.

However, I like the method I mentioned earlier better and there's no reason you couldn't implement both methods at the same time to be even more confusing.

No matter what you do, there's always ways around it, but you can at least make it as inconvenient at possible. These methods stop most users from getting to facebook.

Christian, I'm not too concerned about the scenarios you mentioned regarding the "blocked ip ranges" method. For one, I don't expect to get too many complaints from users about sites they cannot get to (due to that filter rule). Also, I'm not totally blocking those ranges, I'm only blocking https to those ranges. So if there is an http website within those ranges that is not Facebook, they could still see it. In the very rare instance that the user may need to fill out a https form on websites in those ranges (which would probably be extremely rare for a work related task), I could easily modify the ranges in my facebook network object.

If facebook buys new IP ranges, I will notice activity in the logs and block those too. Hopefully by that time, users will already be trained that facebook doesn't work and give up on trying.... if not I'll block the new ranges...

[christian]

 

[christian]

Just to clarify im running Transparent proxy, and the HTTPs block also work for me
Edit: just tried it again, and ye it work even for the app on my Samsung III it blocks facebook when running wireless

So it means that Zentyal has now implemented the "Squid-in-the-middle" trick (SSL Bump) permitting to break SSL tunnel so that browser can be fooled 
Otherwise, according to Squid documentation, it still doesn't work... or you have invented some nice unexpected set-up or... your test is (partially) wrong.

FYI, extract from Squid doc about transparent proxy: 

Code: [Select]

However there are also significant disadvantages for this strategy, as outlined by Mark Elsen:

    Intercepting HTTP breaks TCP/IP standards because user agents think they are talking directly to the origin server.
    Requires IPv4 with NAT on most operating systems, although some now support TPROXY or NAT for IPv6 as well.
    It causes path-MTU (PMTUD) to fail, possibly making some remote sites inaccessible. This is not usually a problem if your client machines are
    connected via Ethernet or DSL PPPoATM where the MTU of all links between the cache and client is 1500 or more.
    If your clients are connecting via DSL PPPoE then this is likely to be a problem as PPPoE links often have a reduced MTU (1472 is very common).
    On older IE versions before version 6, the ctrl-reload function did not work as expected.
    Connection multiplexing does not work. Clients aware of the proxy can send requests for multiple domains down one proxy connection and
    save resources while letting teh proxy do multiple backend connections. When talking to an origin clients are not permitted to do this and will open
    many TCP connections for resources. This causes intercepting proxy to consume more network sockets than a regular proxy.
    Proxy authentication does not work.
    IP based authentication by the origin fails because the users are all seen to come from the Interception Cache's own IP address.
    You can't use IDENT lookups (which are inherently very insecure anyway)
    ARP relay breaks at the proxy machine.
    Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP.
    You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since the client will not know how to deal with it.
    Intercepting Caches are incompatible with IP filtering designed to prevent address spoofing.
    Clients are still expected to have full Internet DNS resolving capabilities; in certain intranet/firewalling setups, this is not always wanted.
    Related to above: suppose the users browser connects to a site which is down. However, due to the transparent proxying, it gets a connected
    state to the interceptor. The end user may get wrong error messages or a hung browser, for seemingly unknown reasons to them.
    DNS load is doubled, as clients do one DNS lookup, and the interception proxy repeats it.
    protocol tunnelling over the intercepted port 80 or 443 breaks.
    WebSockets connectivity does not work.
    SPDY connectivity does not work (HTTPS interception proxy).
    URL-rewriting and SSL-Bump forms of interception are usually not compatible. SSL-Bump generates a fake server certificate to match what the
    server presents. If URL-rewrite alters what sever is being contacted the client will receive wrong certificates.
    OR, attempting to re-write a HTTPS URL to http::// - the server will not present any SSL certificate. Both of these will result in user visible errors.

[Sam Graf]

One of my pet peeves is "clever" solutions where the people espousing the clever solution don't include clear disclosures about side effects understandable by non-clever users.

The conversations here have already included IP address blocks, DNS, and so forth. Search should reveal all of those. If Zentyal is now breaking the SSL tunnel, that was discussed too, if I recall correctly (and there certainly should be clear disclosure of that).

So to me, blocking any given major website is nontrivial if you are searching for a method without side effects. Solutions with side effects are of course permitted, but for the sake of simple people like me, those side effects should be mentioned.

IMHO, of course.

[christian]

In IT world, everything has potential side effect because side effectt is something variable and not perceived the same way depending on who looks at it.
There is no clever solution but only solution you like or not and reason for adopting or rejecting solution is your and only your, based on your priorities.
Debates we already had in the past about proxy have clearly shown this, that's why I'll not discuss whether one solution is better than another one, not wiling to enter again into endless and useless debate 

So not discussing whether one choice is better than another but focusing on Zentyal technical capability, what is really interesting here is to validate ProNetic.dk's statement because if it works like described, it may help some users here