Blocking Instant Messengers?
Michael Mattes asks: "I have been looking for a set of ports/subnets to block in order to disable instant messengers behind my firewall. While MSN is easy to block, ICQ is a little more difficult and it seems as though Yahoo Messenger is designed to do everything possible to not be blocked. I have been reading more and more articles showing companies choosing to block these tools. It seems irresponsible of Yahoo to leave, what appears to me, no choice but to block their entire domain in this situation. Any help would be appreciated."
whoops, my bad...not login, but scs.yahoo.com, port 5050...if you just block that then they cant log on
The question is not so much what do you want to block, it is what do you want to allow.
If all you want is to give access to the web and maybe e-mail. A proxy will do that for you. Squid is nice. That way you only let internal machines connect to other internal machines (i.e. the proxy).
If that doesn't work just firewall all outgoing ports but the ones that you want (80 for web, 25 and 110 mail, 21 ftp, etc...)
The problem is many businesses, such as Healthcare, Insurance and Financial Services have mandatory federal data retention and auditing guidelines that they must meet.
If communication between employees about a client is made via IM, not only is it insecure, but it is not logged or otherwise recorded anywhere. Without a paper trail, the company cannot defend itself against lawsuits or regulators.
Conformity is the jailer of freedom and enemy of growth. -JFK
What needs to happen is to get a large business software company (read: Microsoft) to integrate IM into their next Office suite.
Already done. Outlook XP (and maybe 2000 too) and Exchange server support corporate IM. There are also plenty of IM client/servers one can set up for use within a company. Go to tools/options/other and check enable Instant Messaging in Microsoft Outlook. I'm sure you could enable it by default and roll out MSN Messenger alongside Outlook. There are also plenty of IM client/servers one can set up for use within a company. I doubt it would be too dificult to give employees IM access to each other without giving them IM access to the rest of the world.
Trillian uses scs.yahoo.com, port 5050 to connect to Yahoo.
It's just not a good idea.
Do you want two HMO employees discussing your medical records over Yahoo! IM? I didn't think so.
Many companies are moving into solutions like jabber, which allow you to own the actual server, provide SSL, log the traffic and provide logging & auditing to ensure that information is being shared properly.
Conformity is the jailer of freedom and enemy of growth. -JFK
Microsoft has a service on Exchange that allows you to run a private instant messaging system. You use the same client as MSN messenger. Maybe they will make it a little more prominent in the next version of Office/Outlook?
What's your goal? What are you trying to accomplish? Are you concerned about security? Then make it known as a security issue ("Don't open IM file attachments").
But if this is a management issue, where you're concerned about productivity, don't waste your time and money.
People do not need technology in order to waste time and be unproductive. If some people are being unproductive because of AIM, they'll go be unproductive on the web. If you block the web, they'll go to email. If you block the email, they'll doodle. If you take away the paper and pencil, they'll get up and talk to the guy next to 'em about last night's game.
Management issues should not be "solved" with technology.
Security concerns with IM are very real.
:-/ . This allows me to educate users before they use the software on things like file download risks, and it allows me to quickly pull the plug on the IM software if an exploit is discovered. I've had to do this twice with MSN messenger - but its still allowed on the LAN, since if I don't allow it I'll have to go and hunt out users anyway, which would be an unpleasant and heavy-handed way of dealing with the problem.
First, technical vunrabilities and exploits. There's fun with MSN Messenger to be had, for one thing - and I'm not confidant all the holes in that are closed. Anyway, do you trust your users to keep software up-to-date?
Second, they're downloading and installing programs off the internet. Big no-no. If they want software, I'll usually gladly install a properly checked and scanned copy. Most users dont understand the difference between ICQ and, say Bonzi Buddy (or Sircam, the new web camera viewer!). The "users will not install software" thing is policy, but I think its a very important policy to have unless you like spyware and viri on your business LAN.
Third: our dear friend social engineering. Most of the users at work are intelligent and paranoid enough not to be fooled by this (journalists) but what about the advertising staff? Its a lot harder to trick people into revealing things over email than over IM, and a lot easier to figure out what happened if it does happen. Luckily at work the advertising ppl run 486s which struggle to run telnet + Eudora so IM is not a possibility. Still, it bears thinking about.
I actually allow IM on our network, so long as I'm consulted and they use the software I provide. Any protocol allowed, but file downloads will be punished by being hung up by the toes and flayed for 3 days with a ribbon cable
Sometimes you can manage a risk better by allowing users to do it openly, giving you the chance to educate them and giving you the info you need in case somthing goes wrong, rather than issuing orders to the effect that "thou shalt not."
This assumes, of course, that there is no other obsticle to allowing it, like the aforementioned law firm issue.
BTW it makes me _furious_ that IM clients are designed to bypass firewalls and make it hard for admins to block them. I would like to be able to block a given client in case of a security hole discovery etc, but can't w/o blocking the whole IP range. Why the hell can't they all be set to go through an HTTP proxy? That way I could even virus scan the (forbidden) file transfers.