Blocking Instant Messaging Applications
November 25, 2005
Hi,
I’m interested in hearing what others are doing to block Instant
Messaging traffic on their networks. We would like to block all IM
traffic due to security concerns and, less so, bandwidth concerns (large
file transfers).
Normal measures that one would take are futile. These IM applications
are very “port agile” and will simply try another port if the first
doesn’t work. Blocking 1863/TCP, for example, does nothing to stop MSN
Messenger.
Many months ago, I implemented the tips that Microsoft outlined in KB
article 889829 (http://support.microsoft.com/default.aspx/kb/889829) to
no avail. A few days ago, I made our DNS servers “authoritative” for
messenger.hotmail.com and webmessenger.msn.com, and added A records
pointing to 127.0.0.1. These seems to have taken care of MSN Messenger
for the meantime, but it’s only a matter of time before someone figures
out what’s going on and how to bypass it. I haven’t yet attempted to
block AOL or Yahoo’s Instant Messengers, but those will be next.
We have a policy that takes care of the problem on the employee side of
things, but we are an .edu and we can’t apply that same policy to
students using the labs or wireless networks in our building.
I’m interested in hearing about “software” solutions to this problem,
and am trying to avoid throwing additional network appliances or devices
into the mix if at all possible.
Thanks,
* Some people will arguing how much this help, but it has helped us out a lot.
We use a GPO with a Software Restriction Policy. We then restrict all IM programs via the hash of the binary. This can be hard to maintain because each new or old version you need to obtain the hash of the binary. I’m still in search for some master hash database. It works well for what its worth. Combined with other measures it works out pretty good.
* Jeremy,
A solution that I implemented in the past (for MSN) is as follow:
1. Install a firewall, block everything that is a direct connection
from the desktop.
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.
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.
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.
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.
6. Relax and enjoy.
There might be other ways. I’m just giving you my own recipe.
* At the PIX or firewall, or wherever your ACLs are kept, block incoming
or outgoing traffic to oscar.aol.com, the messenger login servers,
trillian, yahoo, etc etc etc.
You should be able to pull those from the connection logs. The clients
initiate contact with those authentication services, and if they can’t
reach them, then they cannot logon and use them.
Cleanest and easiest to me. If people cant logon to the service, then
you have rendered it useless.
* Hi Nick–do you use the hash of the binary because there’s a way round it if
you just used the .exe name? So clever users can rename the file and be back
online?
Regards
Murad Talukdar
* Unfortunately, this method also has a great deal of administrative
overhead. Do a lookup on messenger.hotmail.com. Do another lookup two
weeks from now. A beer says that the IPs will differ. Trying to keep
up with this is futile. If you don’t believe me, see MS KB Article
#889829 (http://support.microsoft.com/default.aspx/kb/889829). I
implemented this on February 13th. It worked for perhaps a month.
Heck, just checked and that article isn’t even available anymore. It’s
referenced at http://www.microsoft.com/security/incident/im.mspx, but
clicking on the link gets you to an error page.
* Just in the process of doing same here.
I have initially (For MSN Messenger) followed guidelines for disabling it
from running at all:
Of course–this is no good if they are localadmin.
http://woodwardcc.com/content/view/20/
I’m looking at other IM apps too now–will see how I can handle it on my
Watchguard. Perhaps something that looks at the type of traffic and blocks
it rather than by port?
Or disable at the source?
I’ve used winguard pro before to block apps at client level.(No good if
you’re not on Windows).
www.winguardpro.com
* Regarding your last paragraph, you may never block IM without additional
appliances. Once you block MSN, they can use Web Messenger
(webmessenger.msn.com I think).
Maybe content filtering may be the route to take?? Perhaps embracing the
technology could be an option, and add your own IM server??
* 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.
* Nick Duda wrote:
> We use a GPO with a Software Restriction Policy. We then restrict all IM programs via the hash of the binary. This can be hard to maintain because each new or old version you need to obtain the hash of the binary. I’m still in search for some master hash database. It works well for what its worth. Combined with other measures it works out pretty good.
Sorry, I should’ve mentioned that we’re already doing this. This was
the first thing we did in an attempt to stop IM. Unfortunately, these
programs are updated so frequently that it’s impossible to keep up with
them. While this is good in conjunction with other methods, this alone
isn’t good enough (for us).
Thanks,
* easier and les expensive use sonicwall ($500) with IPS enabled
* Use DNS to resolve them (hostnames like oscar.aol.com) to a
local-non-existent address.
Or just block the associated outgoing ports at the firewall.
Or use a thirdparty filter like:
SurfControl
or
Websense
JMB
* I agree with Simon.
It’s not easy to block MSN or any other IM (Skype is even worse – no
centralized servers). There are many ways to use MSN “secretly”. There
are tons of web based ways to use it (web messenger, meebo.com, etc.).
Plus someone could create a reserve tunnel and bypass any traffic restrictions.
I guess a proper usage policy might keep people from using it. But it
looks like IM is here to stay. Those businesses (Yahoo, AOL, MSN, ICQ)
do anything possible to grow their user base at the expense of our
security.
* > Maybe content filtering may be the route to take?? Perhaps
> embracing the technology could be an option,
I would also recommend content filtering
> and add your own IM server??
>
Jabber servers work very nice with trillian as clients. You can write your
own plugins for policy compliance, or if you want open client there is
Miranda
* > Hi Nick–do you use the hash of the binary because there’s a
> way round it if you just used the .exe name?
> So clever users can rename the file and be back
> online?
Also the hash mechanism would also be very easily defeated with
Reshacker or even with echo. >> exefilename.exe
This would keep the file working and alter the hash of the file
* I think I’m able to block MSN and hopefully won’t be able to use
web-versions or other IM(please let me know if my hope is false). Users who
shouldn’t be using MSN cannot surf the net like normals because they have no
net access except for a few allowed sites.
Some users are allowed to use MSN(directors etc–you know the usual deal!).
So they have been schooled in what’s safe and what’s not.
Regards
Murad Talukdar
*
Posted in
December 5th, 2005 at 5:50 pm
I didn’t read all postings, but i can suggest one easy step: drop all traffic to messenger central servers – just connect and write down IP’s of servers.
January 5th, 2006 at 6:47 pm
Hi,
Why don’t you use a path rule rather than a hash rule?
Just block msnmsgr.exe, ypager.exe and any others you find along the way.
Whilst a user could simply rename the file, it seems easier to maintain than a hash list.
Jason
April 18th, 2006 at 12:56 am
DNS is your best software/cheap solution to BLOCK these IM’s, although it does require periodic maintenance.
WebSense or SurfControl is your second best software solution as previously mentioned – although you need a server to run the database on – I think a workstation will work as a server if enough RAM is installed.
— I wouldn’t think BLOCKing is allowed at an Educational institution because that restricts learning.
I think your best bet is the Packeteer appliance – with this you don’t BLOCK (unlawful at an EDU) but limit the bandwidth of these IM apps to a miserable to use level – thereby slowly negating their use because the response is so slow. Unfortunately Packeteer is not FREE.