Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Basics
[Top] [All Lists]

Blocking Instant Messaging Applications

Subject: Blocking Instant Messaging Applications
Date: Fri, 18 Nov 2005 13:23:43 -0500
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,
-j

--
Jeremy L. Gaddis, GCWN

"If it's not on fire, it's a software problem."

<Prev in Thread] Current Thread [Next in Thread>