Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: juppy on September 05, 2011, 09:50:51 pm
-
I'm in trouble to configure this Zentyal because i cannot set Zentyal to block some https sites
I have created a non transparent http Proxy (on 3128 port) with user content filter dhcp dns ecc...end it works well.
...but when i try to stop some https sites (like facebook) my filter doesn't work!!!
I have created a object with the facebook ips
I have created the https service on port 443
I have configured the internal network of the firewall for blocking the outgoing facebook https requests
...but Nothing to do... the Zentyal didn't stop the https of facebook
Do you have some ideas? Help needed please. :o
-
Because HTTPS should be a direct connection between client and server, it's correct behavior for a proxy to not be in the middle of HTTPS traffic.
This has been discussed a few times here. See this post (http://forum.zentyal.org/index.php/topic,7867.msg31690.html#msg31690) (and the topic it's in) as an example, and for additional information.
-
Yes i have understand but i have follow this documentation to buil my gateway but no way... it dosn't stop the https traffic.
The only thing that i didn't follow was the tipology of the proxy .... in my case is not transparent mode...but it' s no a real problem because i set manually the browser to use the gateway.
-
Sorry but I do not share the statement :-[
I'm not saying it's wrong but at least a bit misleading.
Direct connection is one option, obviously ;) another one is to use proxy "CONNECT request" method.
To me, proxy can and must still be in the middle between browser and server. what is not supposed to be done (and not done BTW except with proxy implementing "man in the middle" behaviour) is content content filtering and obviously caching.
As a result, if your browser is configured to use proxy including for SSL and if firewall doesn’t authorize direct connection (BTW, if DNS doesn't resolve internet names, direct connection doesn't work ;D), then the only way to access HTTPS based server is proxy and it does work!!! reason why I say "statement is misleading".
Then as goal is to block access to some HTTPS sites, and because content filtering cannot be implemented, some other mechanisms have to be deployed :P
this can be done by preventing... proxy to reach these IP addresses in IPtables.
using domain filtering in Zentyal works too ;)
see attached picture 8) give a try yourself and let me know :P
-
christian, is it correct that we have to add BOTH the firewall block rule AND the proxy domain filter rule?
That would explain why many of us had trouble blocking these kind of sites.
Cheers.
-
Christian's response has me a little confused. As the HowTo says,
As you can see you have blocked facebook.com (just as example) but have in mind that HTTP Proxy only filters HTTP on port 80. In this case users can still reach HTTPS version of the page, so we also create a firewall rule blocking that traffic. You will need an object (Objects menu) containing facebook.com address pool ...
In my experience that's how it actually works. And it would seem to me that if we deny a destination via the firewall that the proxy's rule becomes redundant.
So I'm looking forward to reading along and see where this conversation goes ...
-
Sam,
Sure, if you deny destination in FW, proxy rule is redundant. I do not deny this ;)
From this point, we will have mostly philosophical discussion ;D because multiple ways exist to reach same (almost) behaviour that is, here, to block Facebook.
I will elaborate on this later (I definitely hardly write short posts :-\ )but I do want first to clarify the misunderstanding about Squid not handling HTTPS, reason why filtering must be done in FW. This is not correct.
Let's start some "philosophy" now :-*
The way I perceive it (but no saying "I'm correct" and even less "I'm the only one correct"):
1 - HTTP PROXY module is deployed to handle and potentially filter HTTP and HTTPS protocols. Why, if there is no technical constraint, would you authorize to by-pass it for HTTPS?
2 - having to control HTTP(S) flow using 2 different interfaces (proxy and fw) whenever it's HTTP or HTTPS is a bit confusing isn't it?
3 - what if tomorrow Facebook moves to another IP? Will you adapt FW rule?
I you can do it, just try my way of achieving it and let me know... ;)
-
christian, is it correct that we have to add BOTH the firewall block rule AND the proxy domain filter rule?
As far as I understand (and just experimented for this purpose last night), no, it's not correct. Then I'm very open to further discussion in case I made a mistake.
As I answered to Sam, either you decide to authorize HTTPS through FW and then you MUST filter destination in FW or your approach is to make HTTP PROXY mandatory and then it's enough to filter in PROXY.
All come from a misconception that Squid (and HTTP PROXY in general) can NOT handle HTTPS. It can NOT perform anything based on content (because of the encrytption) but can definitely handle connection even for HTTPS.
Did you ever wonder why your browser permits to configure proxy even for SSL?
However, I'm still investigating, reading Squid documentation, to understand where blocking occurs in case of HTTPS.
For sure, if FW is needed, it's not because of client but because of prox accessing this site.
and I confirm it works for me without ANY specific FW rule ;D ;D
-
So I'm looking forward to reading along and see where this conversation goes ...
There is one point I would like to clarify asap: unless all HTTPS flow is denied, there is no way to block 100% user willing to access web site:
if user accesses, using HTTPS, open proxy (or "anonymizer") on internet that is not blocked in your local proxy (or FW ;D ), then access to Facebook will be possible.
-
And just for the fun because this topic is really an interesting one, here is another (dirty) method to prevent (within the limit of above post) access to Facebook:
- browser being configured to use proxy
- NSS configured to rely first on file (i.e; /etc/hosts)
- configure, at Zentyal level, www.facebook.com as local address, e.g. localhost
when proxy will try to access it, it will access instead this address.
I do not promote this approach: goal is only to explain that multiple and different ways to achieve "almost" same behaviour exist 8)
-
sorry if this does not work but
could you not create a DNS entry for
facebook.com
on your zentyal installation? i believe this would intercept all DNS lookup within your network - and lock any dns queries to go through your firewall as well.
Nicolas
-
could you not create a DNS entry for
facebook.com
OMG!!!! Christian, what did you do :o ??? Opening Pandora box generates a lot of alternative proposal to solve something that is supposed to work out of the box (not the Pandora one) with proxy module only ;D ;D ;D ;D
Sorry guys, I didn't aim to do this :P :P :P
Joke aside, yes it might work but redefining you own facebook.com zone or even alias is really dirty isn't it?
Did anyone test that what I did last night is working for you too (I'll try again this evening just to be sure)?
-
In my case the Zentyal gateway is perfect as user domain filter but it's no way to stop https sites (like facebook).
I have tried to create a ojbect (facebbook with the ips), a service (on 443 port called https) and i have added the firewall roule (As suggested in the manual)...but Zentyal doesn't seems to work correctly.
Note:
I want to stop the https of facebook but not other https sites.
Tonight i will reinstall the system and then i hope to understand if it's only a my problem or it' s a Zenthyal bug that for same reason at this point didn't apply firewall roules correctly.
???
If some of you have any suggestion to solve the problem... i' m here !!
-
Juppy,
Do you mean that what I describe doesn't work for you?
I made another test right now: without domain rule in proxy settings, I can access Facebook. Adding such rule (as shown in my previous) prevent me to access.
I do NOT add anything at firewall level.
How is you browser configured for what concerns use of proxy?
-
My head hurts ...
OK, let's see if we can sort this out:
There is one point I would like to clarify asap: unless all HTTPS flow is denied ...
But of course we aren't trying to block all HTTPS trafffic. Just some. What I'm saying is that Squid, it appears, can't discriminate about HTTPS traffic in the same way it can for HTTP traffic. I can block some HTTP traffic without having to block all HTTP traffic. So far, it seems HTTPS traffic cannot be handled in the same way using Zentyal. But maybe I'm just badly confused ... :'(
However, if the real point here is that we shouldn't be using a transparent proxy in the first place, we have other issues to hash out that are outside the scope of this topic. For to me, that brings us squarely back to the idea that Zentyal needs to find a home in a VDI world--where I might reasonably do away with transparent proxies for device-independent virtual desktops.
I will elaborate on this later (I definitely hardly write short posts :-\ )but I do want first to clarify the misunderstanding about Squid not handling HTTPS, reason why filtering must be done in FW. This is not correct.
Again, what it seems that Squid cannot do is discriminate this HTTPS traffic from that HTTPS traffic. I'm not saying I know that for a fact, but I'm saying that I have yet to see clearly how I can parallel Zentyal's HTTP site blocking capability for HTTPS traffic. Maybe I'm just dumber than a stump? :D
1 - HTTP PROXY module is deployed to handle and potentially filter HTTP and HTTPS protocols. Why, if there is no technical constraint, would you authorize to by-pass it for HTTPS?
Because I don't seem to be able to block some HTTPS traffic. Out of the box, Zentyal simply blocks all HTTPS traffic when using a transparent proxy.
2 - having to control HTTP(S) flow using 2 different interfaces (proxy and fw) whenever it's HTTP or HTTPS is a bit confusing isn't it?
Well, at this point I'm more confused by where we're headed here than I am by Zentyal, but I'm not giving up. :D
3 - what if tomorrow Facebook moves to another IP? Will you adapt FW rule?
Well, why not? I am constantly editing the HTTP site rules (people legitimately need access to blocked sites, Zentyal delivers a false positive, etc.). So while the process is different, it all takes time, one way or another.
I you can do it, just try my way of achieving it and let me know... ;)
I am dumber than a stump for sure, because I'm just not clear how even to try your way. I am really missing something here. :-[
-
Sam,
I'm sure we will succeed at aligning our views.
1 - I do understand that goal is not to block all HTTPS traffic. This is clear to me.
2 - Test I made is blocking only Facebook, both HTTP and HTTPS, which is the goal if I understand well
3 - with transparent proxy enabled, this can NOT be achieved without firewall rules.
If you have Zentyal test platform, try the following:
- set up Zentyal as gateway with firewall and proxy
- configure proxy as "NON transparent"
- configure your browser to use proxy for all protocols (yes, including SSL/TLS, i.e. HTTPS)
- do not configure extra rules in FW and ensure HTTPS does not bypass proxy (when you stop proxy, access to internet should not work for HTTP nor HTTPS)
- ensure you can access Facebook with both HTTP and HTTPS.
So far so good :)
Then go to HTTP proxy menu then filter profiles.
change configuration of default profile to add, in domains filtering, "facebook.com" in "domains and URL rules".
save then try to access facebook with either HTTP or HTTPS.
How to is behaves?
-
I'll try this, but I think the fact that Squid needs "help" at the client end to handle HTTPS traffic in the same way it can handle HTTP traffic without help at the client end more or less shows that in a practical, non-technical sense, it's correct to say that Squid can't get into the middle of HTTPS traffic on its own, at least in Zentyal's implementation. The client has to send the HTTPS traffic Squid's direction. Then, and only then, can the proxy selectively block HTTPS traffic, it seems.
The practical complications of this are significant for companies and organizations not tightly controlling the hardware side of things. But that remains discussion for another topic.
-
Unfortunately this is the way it works :-[
Because of this, mechanisms have been deployed to help maintaining such config client side.
We were discussing in parallel in the "flash" related topic and I've also, BTW, launch poll to get better view of who is doing what here.
"proxy.pac" mechanism is the very first step.
Then WPAD (that is no more than an helper to find easily proxy.pac) is the second step.
Of course one will always have to ensure that browser is configured, client side, at least to automatically discover proxy. But it's like network: if you interface is configured in static mode, you will never benefit from DHCP isn't it? ;D
-
Some day we'll have to start a topic on the problems this approach creates for international business let alone SMBs. In the meantime, thankfully we at least have the transparent proxy option! ;D
-
Sure.
I think we are now done with this never-ending thread: different approaches exist whether proxy is used in transparent or non transparent mode.
I hope pros and cons are well understood by everyone and also acknowledge that Zentyal platform doesn't provide, as of today, all the all the bells and whistles to ease "standard" proxy (meaning, from my side ;) non-transparent) deployment without some manual tricks in case automatic proxy detection is wished.
At least if our long discussion doesn't result in an clear deployment strategy, it has permitted to clearly share understanding of some technical aspects and why such setting like "FW rules" are required depending on your design.
TTFN.
-
One last comment ... Not to have the last word, but to tie this back to Zentyal.
"Standard" enterprise IT and "standard" SMB IT are almost certainly very different animals. In my 20 something years of working with non-profit and small business technology, the "path of least resistance" rule prevails more often than not. Today, that sort of "procedure" has been formalized in the concept of IT as a service.
IT as a service is playing out in at least two new ways in SMBs: BYOD and desktop or application virtualization. Today, virtualization software can run on a commodity infrastructure. Commodity servers, entry level gigabit switches, and plain old TCP/IP are pretty much all that's needed.
Zentyal itself is an excellent example of standard path-of-least-resistance SMB IT. Transparent this and transparent that are the right things to do in a traditional SMB context, and IMHO, Zentyal needs to stay on that course for now. Like Zentyal itself, this kind of transparency is going to be frowned on by at least some advocates of traditional, "old style" enterprise IT approaches, where IT isn't seen as a service.
The difficult task in front of Zentyal as an SaaS offering is balancing these two different approaches to IT, to optimize market potential. To me, this includes intentionally accounting for the new BYOD and virtualization trends taking place in the SMB market.
Anyway, finally ... I'm done.
-
Still we can find that services in IT is moving between BYOD and various applications. Saas provider cannot manage both things at a time.