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!!
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