Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: aspangilinan on July 18, 2013, 01:38:19 pm
-
hi to all
please help me
how to blocked facebook.com using http proxy
Thanks
Arnel
-
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 ;)
-
ok thanks. :-\
-
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.
-
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 (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.
-
:o how often do you check if list of IP changed ?
Any other site you block using same approach ?
-
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.
-
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. 8)
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. :-[
-
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 :)
-
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 (http://trac.zentyal.org/wiki/Documentation/Community/HowTo/GatewaySetup), 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.
-
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...
-
:-*
-
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 8)
Otherwise, according to Squid documentation (http://wiki.squid-cache.org/SquidFaq/InterceptionProxy), 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: ::)
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.
-
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. :)
-
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 :)
-
In IT world, everything has potential side effect...
Not just in the IT world.
But that isn't my point. My point is that people need to be able to make reasonably informed decisions. So for my purposes, a side effect is problematic result (major or minor) or a result requiring further action.
I'm advocating for telling people up front what they're getting into rather than assume they know or can figure it out. Small business people don't like or need surprises, especially technical ones. At some point technical capability and practical outcomes have to merge in the small business conversation, as far as I'm concerned. It is at least sometimes the reluctance of technical people to do that--to get practical in a small business sense--that helps make many "debates" endless and useless. The conversation doesn't even have the same end goal, so how could it be otherwise?
Now we are officially off topic, but I've had my say. :)
-
Sure but what is side effect for you is not perceived as such for me and vice-versa.
Some people feel painful to maintain DNS entries for their own servers while they agree to maintain external servers IP in network object.
Some may feel really painful to manually edit configuration file...
So what is really a side effect ?
All of this has been discussed already at length, therefore my initial answer: please rely on forum search feature and make you own opinion based on your own criteria.
Although I understand your point, I've absolutely no interest in any non-technical discussion :-X
Look at Squid documentation link I posted above. It contains some pros & cons, most having been discussed here and there.
Is it understandable for non-technical people ? Perhaps not everything but "how to make technical choice for non-technical people" is another topic ;)
If you decided to go for Zentyal but have no clue about technical stuff behind, my strong advice is:
read the "Zentyal perfect gateway" document (http://trac.zentyal.org/wiki/Documentation/Community/HowTo/GatewaySetup) and apply.
-
Sure but what is side effect for you is not perceived as such for me and vice-versa.
This I don't see given my definition of side effect.
Although I understand your point, I've absolutely no interest in any non-technical discussion :-X
I'm aware.
Is it understandable for non-technical people ? Perhaps not everything but "how to make technical choice for non-technical people" is another topic ;)
What is not another topic is saying that it's really quite simple to block Facebook without telling people the whole story of the solution. That was and is my point. If people here really think that it's OK to provide "clever" solutions without helping people see how the solution actually shakes out in the real world, then I don't see the point of having anything but a purely technical forum. And I don't see at all how that helps make Zentyal a practical buisness solution for an ever wider group of customers.
Sigh ... I think I'll just :-X too. ::)
-
You guys are absolutely right, i am very sorry if you feel that my "Its pretty easy" are offending the spirit of the forum/technical stuff.
I just started using Zentyal for about a month ago and ive tried out the different features and i really like what i see.
I am a network administrator, i currently hold a CCENT, CCNA, CCNP, CCNAS and CSSA, and i have 10 years of experience with infrastructure management, but primarily focused on Windows and Cisco. Therefore i have not looked at the deep technical details of all features, i have an understanding how proxy work but not the deep details.
I already ordered the Zentyal manual and i am also going to get certified, so i really try to apply my self because i really wanna learn.
I have always loved Open source and Linux, and when i came across Zentyal it seamed like the perfect solution for me.
I agreed that we have to find out why it works for me, to clarify what happens since the Squid documentation clearly states the HTTPs should not work.
My setup atm.
VDSL Modem -> Cisco ASA firewall -> Zentyal inside VMware ESXi and Clients. The Cisco ASA are the gateway/firewall, Zentyal running DNS, PDC and firewall(yet i am not using it as a firewall)
I am not using Zentyal as a gateway yet(waiting for hardware), just turned on the Proxy feature and set my Clients proxy settings to point on the Zentyal server. On the Clients i enabled "Use the same proxy server for ALL protocols"
When i access facebook via. HTTP i get a page "Access deny" when i use the HTTPs i just get "Page not found".
Sorry for the bad English
-
This is as simple as what you describe if you have configured HTTP proxy in explicit mode. 8)
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. :-[
As I explained in this previous post, indeed you can do it easily, as you do BTW, when proxy is configured in explicit mode.
What doesn't work is when proxy is configured in transparent mode ::) therefore this discussion about potential workarounds ;)
-
Okay so when you say explicit mode, and i have selected "transparent Proxy" in Zentyal, but my browser settings are "Use the same proxy server for all protocols" that will essentially override my "transparent proxy" in Zentyal?
-
Transparent proxy is used only when you decide not to configure proxy at client level.
In its simplest design, it requires proxy to be also network default gateway.
As your Zentyal server is not defined as network default gateway, activating transparent proxy is useless because this is very unlikely that any packet reaches your Zentyal server on port 80. Therefore this is not matter of "overriding".
You are using proxy in its explicit mode and indeed blocking HTTPS "per domain" is straightforward.
Too bad there is no magic trick in your configuration.