Re: Blocking Instant Messaging Applications

• Previous message: Saqib Ali: "Web based utility for securely changing AD password"
• In reply to: Neksus: "Re: Blocking Instant Messaging Applications"
• Next in thread: Alexis Villagra - VILSOL LatinAmerica: "RE: Blocking Instant Messaging Applications"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 21 Nov 2005 19:59:46 -0500
To: Neksus <neksus@gmail.com>

Neksus wrote:
> A solution that I implemented in the past (for MSN) is as follow:

Unfortunately, a number of these won't work for our situation. Not sure
if I mentioned it in the original post or not, but I'm dealing with an
academic environment in this case. They like things to be "open" and as
least restrictive as possible.

> 1. Install a firewall, block everything that is a direct connection
> from the desktop.

While we do have (multiple) firewalls in place, we simply can't do this.
  It would never fly.

> 2. Install a proxy for FTP, web and https (20/21/80/443). Only the
> proxy server should be allowed to directly connect to the internet.

We recently started doing transparent proxying for port 80/TCP. Since
this is a "test", I can't get a couple of more machines to do
redundancy/failover. If the one machine dies, the transparent proxying
can quickly be turned off. Apparently, squid has issues is you try to
transparently proxy HTTPS, for example. For this reason, I can't use
GPOs to configure the proxy settings, as it would take too long to get
changes out to machines if the proxy died and we had to disable
proxying. Not to mention that a number of these are personal machines
(e.g. students'). Trying to do something where they had to configure
the proxy server for every application would result in an exponential
increase in the number of calls to the help desk.

> 3. Put the MSN domain name in your own DNS to prevent the application
> from reaching the server by hoping on port 80. I forgot what is the
> domain name off the top of my head.

This is what I'm doing currently. I have "authoritative" entries for
messenger.hotmail.com, login.oscar.aol.com, msg.edit.yahoo.com, and a
number of others all pointing to 127.0.0.1. This will only last until
someone figures it out, however.

> 4. Block access to the local hosts file to avoid clever users from
> adding the IP in the file (Windows will read this file first, then
> DNS). Users should not be admins of their own machine.

True, but when the users own those machines (see above, some of them
belong to students), I can't control them. For faculty and staff, it's
not a problem. Policy dictates that they don't use IM.

> 5. Install an internal server if you have a large user base (country
> wide or international). Microsoft has one that is easy to setup but
> you'll need to use Windows Messenger instead of MSN messenger. They
> also release Windows Communicator or something close that is Windows
> Messenger on steroids.

We don't use IM, internally, so no need.

> There might be other ways. I'm just giving you my own recipe.

Understood. Please don't think that I'm "bashing" any of your
suggestions -- it's simply that they won't work in the environment I'm
dealing with. This is something I've been struggling with for a lengthy
period of time, with no solution having yet been found.

Thanks,
-j

-- 
Jeremy L. Gaddis, GCWN
http://www.linuxwiz.net/
"If it's not on fire, it's a software problem."

• Previous message: Saqib Ali: "Web based utility for securely changing AD password"
• In reply to: Neksus: "Re: Blocking Instant Messaging Applications"
• Next in thread: Alexis Villagra - VILSOL LatinAmerica: "RE: Blocking Instant Messaging Applications"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]