Instant messaging (IM) increases productivity with the

advantages of instant feedback and reduced communication costs. However, the

problems IM creates in a business environment are those of liability and

responsible use. This is particularly true in the Financial Services sector and

other regulated environments. The Financial Services Authority and similar

regulatory bodies are of the opinion that IM is no different than e-mail,

therefore the same requirements for record keeping exist. I think many users of

IM (including myself) see the conversations as ephemeral, vanishing into the

ether of time and space. Not so. All IM clients have logging facilities and

there are also packages available for network administrators which enable

logging of all conversations passing through the network. If any type of

dispute arises involving information given via an IM conversation, your

organization needs to know exactly what has been said. The same can apply

internally if disputes arise within the company due to improper use. Another

issue which must be addressed is that of increased vulnerability to security

threats. Virus writers and scammers are turning their attention to users of IM;

new Trojans, worms, and phishing attacks are discovered daily.

For a business–and more specifically–its IT department,

the control of IM poses a problem. Firstly, do you have a policy on the use of IM?

If so, how do you enforce this policy and how do you ensure that you are

fulfilling the regulatory obligations imposed? If you do not have the processes

in place to log and archive records in a tamper proof and accessible format;

messaging should be stopped. But how?

Two methods which I come across frequently are port and IP

Port blocking: This is very simple; find out what ports are

used by the IM clients and then block them on your firewall. The problem with

this is that the clients try to use many different ranges of ports, and these

tend to increase with every new release. “Well,” you say, “my

firewall blocks all outgoing connections unless I specifically ask it to pass

them.” That’s good, but do you allow port 80 (http)? Most of today’s IM

clients can now work perfectly well through port 80, and if you allow your

users to surf the net then they can probably IM too. I recently read that the

latest clients embed traffic data within an HTTP request, meaning that even

with advanced protocol analysis, they will be very difficult to stop! Smells

like guerilla tactics…

IP blocking: Again, very simple in theory, but with its own

problems. Using netstat along with googled resources, you can find the IP

addresses which an IM client will connect to. Block all outgoing connections to

this IP (or subnet) and eventually, once all servers have been found, the IM

client will be unable to go online. This looks like a better method than

blocking individual port ranges as it still leaves http open for web access. This

method still has limitations; in the amount of time it takes for the software

company in question to make a DNS or client update, a new server is added which

needs to be blocked. Because this can be hard to keep on top of, I keep the

major IM clients running on my desktop. In the rare event that one actually

manages to go online, a simple netstat can track down the new server, which can

be added to the block list. One of the major IM providers has started to have

their client program connect to IPs which also host their web services. This

means that if you block their IM client, you also lose access to these services.

Not much of a loss, until you realize that you can’t run Windows Update! Looks

like we’re heading for an all out Guerilla war!

Lets consider that we have blocked IM (don’t forget to hunt

down and block services like–if

you don’t, then your ‘users’ will use them).

The powers that be have decided that they now want to allow one

of the messenger services. Reversing the measures taken to stop that particular

IM service won’t be difficult, but you have to find a way to log and archive

communications. There are many companies offering software to log IM traffic;

examples would be IMlogic

and Akonix.

One of the previously mentioned products runs on a Windows platform, one is a

plug and play appliance. If you run on Unix/Linux/BSD then take a look in to

the dsniff set of tools.

This set of tools can log IM conversations, unencrypted password transactions,

url requests, and more.

Our company has decided that public IM services should not

be used; however for internal communication, IM can be a very useful tool,

especially when you have offices spread across a large geographical area. Running

your own internal IM server is easier than you might think. Jabberd is an

implementation of the common messaging protocol, now known as XMPP (Extensible

Messaging and Presence Protocol). There are server implementations available

for various platforms including Windows and Linux; this is also true of client

applications (I personally use PSI).

The best thing about this implementation of an internal IM server is that it’s

free, and there are no complex licensing schemes regardless of how many users you

want to have on the system. Logs can be archived in files or SQL format, whichever

you feel more comfortable with. If the configuration seems too complex or you

would rather use a commercial solution, take a look at Jabber Inc.

IM in the financial services sector is a very hot topic at

the moment and promises to continue as new regulations put IT policies to the

test. Google is just starting to release its IM service, while Microsoft is

trying to push the use of MSN Messenger within a business environment–the firewall-bypassing efforts made by its

application backup this policy. New problems for IT departments to solve

will follow…

I would be interested to hear reader’s comments on this

topic; do you know other methods for blocking or logging IM conversations? Let

me know…