Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: aacevedo on June 07, 2011, 08:05:52 pm
-
Good day to everyone. My Zentyal version is 2.0.16, everything working well.
I've been trying to block MSN Messenger. I read that the most effective way is to do it by filtering its MIME Type: "application/x-msn-messenger". My confusion comes when I go to MIME Types Filtering tab in Http Proxy --> Filter Profiles --> Default. I am unsure how to proceed from here. Am I safe to assume that all MIME Types in the list are the only ones allowed since the Allow checkbox is ticked? Therefore any MIME Type not listed would by definition not be allowed. This is not so, since "application/x-msn-messenger" is not in the list and all my users chat away freely all day.
Based on that I figured that by adding "application/x-msn-messenger" to the list and not ticking the allow checkbox I would be disallowing it. I tried that but to no avail. Users keep chatting to their hearts content.
I have searched the forum up and down as well as the documentation but all references just say to "disallow the MIME Type". How exactly does this thing work? Any help will be greatly appreciated!
Regards,
Alejandro
-
Not sure about the MIME thing, haven't tried it.
Have you checked http://support.microsoft.com/kb/927847 (http://support.microsoft.com/kb/927847)? Blocking the ports listed the via firewall may be tricky. On the other hand you should be able to block those URLs easily.
-
Hi Josep, thanks for your quick reply!
I did try to block by ports and/or URLs although not all that are in your link (it's indeed tricky ;)). I blocked ports 1863, 6891-6901, 5190 and 7001 as well as the following URLs: login.live.com, messenger.msn.com, messenger.hotmail.com and gateway.messenger.hotmail.com.
Unfortunately this blocking did not work. That's the reason I was trying to go by MIME Types.
Thanks again!
-
The conversations about this have confused me as well, and it may be down to the fact that there are multiple chat venues to manage.
For example, "banning" live.com via the HTTP proxy closes that entire Web-based door to Messenger (and Hotmail). Since we use Pidgin as our chat client (to take advantage of Zentyal's Jabber feature), I actually have to open the relevant ports in the firewall to permit MSN connections (since apart from an "any-any" rule Zentyal will block all otherwise unaccounted for out-bound traffic, as I understand it). Maybe Windows Live Messenger or the older MSN Messenger are more "creative" than Pidgin at making the connection. But even so, it would seem that some pairing of the proxy's and firewall's features should cover things. Or perhaps the pairing plus removing "creative" software from the equation...
In any case, I've not always understood how MSN/WLM users seem to be hard to stop. It would be nice to nail down an efficient and effective method to get the job done and include that in the community-based documentation, since it does come up regularly. Maybe we could use this topic to explore the whole subject thoroughly?
-
I think you're onto something here Sam. As I see it, the key to nailing this down is in all the "variables" at stake. Off the top of my mind I can think of these:
Ways to access MSN
- Directly by MSN client
- By a generic jabber client as Pidgin
- Online via eBuddy or live.com site
Ways to block MSN
- Blocking ports in Firewall
- Banning sites (like live.com) in Proxy
- Blocking MIME Types (BTW, I still don't know how to use this)
- A combination of the above
Before responding, I did a quick test banning live.com in Proxy. It effectively blocked all on-line access to any "live.com" related service like hotmail, skydrive, on-line messenger, etc. But in my case it did not block access through MSN client nor Pidgin. At least it blocked one of the venues :) I should say that for this test I have no other blocking mechanism in place. It definitely needs a combination!
I, for one, second Sam's proposal to use this thread to approach the subject systematically to learn how to effectively block MSN (and may I add, any other Instant Messaging service). I invite the audience to review the variables listed above and complete them to build a cause and effect matrix.
Any ideas?
-
I intend to set up a vanilla Zentyal test server and start tossing various routes to MSN/WLM IM at it and see what happens. I suspect if there is a "hole" in the system it has to be through some port open for other purposes. But until I take something like a systematic look at this I'm just guessing.
The timing of setting up the server and starting the tests is a little in question; lots going on. It still should be in the next week or two. As I learn something, I'll post it here for everybody to review.
-
Thanks Sam,
Currently this is one of my priorities. I have my testing server which is not as clean but have another box which I am reinstalling as I write this. I'll be doing my "systematic" approach in the next couple of days but if you have the time to give me some pointers I'll be more than happy to put them in practice. After all I'm only a Zen Apprentice ;D
If you prefer please contact me by IM so as not to clutter this thread...
Cheers!
-
After all I'm only a Zen Apprentice ;D
Obviously I dunno what I'm doing either. :D
My thought was to set Zentyal up with just enough modules to run the network with the proxy. Then I'd want to make sure there were no rules in the "traffic between networks" section of the firewall. That should mean that every outbound port not required by Zentyal itself will be closed. Then I'd ban live.com via the proxy.
I'd leave Pidgin out of the test mix since I already know it plays nicely; ports must be opened in Zentyal's firewall for it to connect. But I'd try the common Windows scenarios (the Web and MSN Messenger and Windows Live Messenger) and see what happened. My next steps would be dictated by what I learned.
I'll see if I can get my test machine running before next week, but it's just not looking good at the moment. Sorry about that. :-[
-
If the regular messenger ports are blocked, Messenger will use port 443 to connect.
Because of that, Mime type filtering won't succeed as it is done at a proxy level.
I've tried this before and never really could block this little bugger.
Cheers.
-
... Mime type filtering won't succeed as it is done at a proxy level.
Exactly.
I take it you've already tried blocking outbound traffic on port 443 to Messenger addresses and found it hard to nail down all of them? Depending on users' needs, it might work (and be easier) to allow access only to approved destinations and block everything else.
It seems to me that Messenger must be at a sufficiently finite number of addresses that a little traffic sniffing would help us build the object(s) we need. If nothing else, surely the Microsoft clients know a finite list of addresses to try. So it seems in my head anyway...
-
I was able to spend a good part of the day yesterday setting up my lab and testing the different ways MSN connects and the different ways to try to block it following Sam's recommendation for a systematic approach.
Obviously the right time to block it is when a user tries to connect. So my set up includes, besides my Zentyal box, two Windows XP clients, one with MSN ver 2009 (build 14.0.8...) and the other with an older client ver 2004, build 4.7. (I know, I know I still need to get my hands on a Windows 7 machine, hope to accomplish that today). On the first XP machine I also configured Pidgin for Windows ver 2.7.11. Finally I have my Ubuntu Karmic (this is my desktop machine) with Pidgin 2.6.2 and Psi 0.12.1. I haven't mentioned this before but I also have an Openfire Jabber server on the same box as Zentyal (BTW, it's ver 2.0.16) in substitution of ejabberd. On Openfire I have Kraken plugin configured with MSN gateway. Both clients on Karmic go through Openfire and Kraken's gateway to connect to MSN. What I'm actually trying to achieve is to have this connection the only one allowed, since I can administer it with Openfire.
One last note: I opened Wireshark on the internal interface on the server to observe what was going on in each case as the clients connected through their different methods. Though I'm no network protocol expert I discovered something very interesting. Grossly oversimplifying, all clients go through the following basic steps at connection time:
1 client --> Zentyal: Does a standard query A for domain: login.live.com
2. Zentyal --> client: Gives a standard query response with the CNAME: login.live.com.nsatc.net
3. Zentyal --> DNS service: since it's a CNAME (login.live.com is an alias, basically) it does another query A for login.live.com.nsatc.net
4. DNS service --> Zentyal: comes back with 8 different IPs (which may vary from connection to connection)
5. client --> first IP given on port 443/80: authenticates with service, does handshaking and what not in order to login.
6. client --> MSN service on port 1863: downloads contacts, presence information, etc. using protocol MSNMS
I examined Dansguardian access.log and noticed that all of this goes on using MIME type text/xml, so forget about blocking by MIME types.
At this point I realized the following:
a. blocking login.live.com in the Proxy is no good (it's just an alias)
b. blocking port 1863 in the firewall from internal networks to Zentyal is no good (only DNS traffic goes by)
so, I tried the following:
i. block login.live.com.nsatc.net in the Proxy. Did'nt work. Still have to understand why but I suspect it is because the connection goes on from Zentyal to MSN Service but the proxy sits before this.
ii. block port 1863 in the firewall at the filtering rules for internal networks. It worked!! :D The reason it was effective was because once login is accomplished the client talks directly to MSN service at the IP given by the DNS, it does not go from the client to Zentyal and then to MSN Service. It's not perfect because the client is able to login to the service but then when it tries to use MSNMS protocol to talk to the service it fails and comes back with a Network error.
In my particular case apparently it is also blocking Openfire's communications with MSN Service which is no good for me. I'll keep sniffing around to see if can manage to block at login time, will post back.
Regards,
Alejandro
-
You could also setup a DNS server for domain "live.com". This would certainly disrupt the service.
-
I've not tried Josep's suggestion, but will test it.
aacevedo solution is nice for standalone messenger clients, but probably won't take care of connecting to web messenger or chatting from the Hotmail web page.
But it's a start, and I'm starting to have faith again that it might be possible to block messenger after all.
Cheers.
-
Hi Escorpiom,
A few days back I posted this:
I did a quick test banning live.com in Proxy. It effectively blocked all on-line access to any "live.com" related service like hotmail, skydrive, on-line messenger, etc. But in my case it did not block access through MSN client nor Pidgin. At least it blocked one of the venues :) I should say that for this test I have no other blocking mechanism in place. It definitely needs a combination!
If you want to block access to web messenger and the entire hotmail page just ban live.com at the proxy level. It will block all microsoft's live services. Josep's is no doubt another way to go. Haven't tried that either. Please tell us how it goes.
-
Just thinking out loud, I'm wondering if another layer to this might be to block the Messenger SSL servers ... ?
-
I could be wrong, but it is my understanding that MS servers are able to switch from secure (HTTPS by SSL servers) to plain HTTP "at will". My guess is that if the client cannot connect securely it will go the other way.
Are we talking about the same thing?
-
Probably.
If Messenger can move freely between secure and non-secure connections, then you're right, blocking the certificate servers isn't going to help.