Blocking messengers

I'm sure we've all heard it before, and I just did a search and didn't find anything recent or conclusive. So here it goes...

AIM,MSNM,ICQ....how do you block these at the perimeter. The only solution I've heard so far is to implement and enforce a better security policy. Well that's all fine and good, but whn you have sites sprawled all over North America, its hard to keep an eye on them. I've heard other solutions involving registry edits in the login script as well. Its also feasible to deny access to the providers logon servers, but if they change, then everything is open again. I just feel that we should be able to block these things on one machine, that one of course being the firewall.

I know that almost all of these products go through port 80 if the one they ususally use is being blocked. So how does one stop this traffic? Of course a packet filter style firewall will be totally useless, but what about an application level firewall? Can't you filter out packets from these products?

Using Checkpoint's FW-1 I was able to block MSNM using its URL filter to block the string that it sends to its logon server. So I thought it might be just as easy with ICQ, but didn't quite work that way.

There has to be something we can use to filter these out without worrying about them slipping through the cracks 3 weeks down the line.

Has anyone had any success in this endeavor?

To block AIM, you can just block port 5190, and block all to login.oscar.aol.com

I think the best policy is to block ALL outgoing traffic, except for specified services (WEB, FTP, etc). It's a little more work, but it's effective.

I know you can explicity deny access to the logon servers, but if they change the logon server name, or if they add a new logon server, then its open season again for messengers.

I haven't tested AIM, so I don't know if it tries to route through port 80 if its standard one is blocked.

Thanks for the reply though!
:D

Most messaging software use specific ports to communicate. If you don't want to block all outgoing traffic you will have to identify the specific ports and block them at the firewall.

Yes, they do use specific ports, and if those ports are blocked then they will route through port 80 (ICQ also uses 21). Port 80 is used to access the internet via http. I can't really block that.
MSNM for example defaults to 1863(9). That port is blocked....it will then go through port 80.

MSNM, ICQ,and Yahoo (pretty sure about yahoo) all re-route through port 80 if their original one is blocked.

So blocking their specific ports will not help.

When you say "they" in "but if they change the logon server name" you refer to AIM, ICQ.... or to your users?
If you refer to the societies which have created those IMs, don't worry. Think that if they would change their logon servers names, the big majority of their users could not be connected to them due to the default config into the softwares (they are not created to check somewhere in the net the name of the server, the name is directly put in their config, I'm not totally sure about this for MSN and Yahoo but I'm sure for ICQ and AIM).

When you say "they" in "but if they change the logon server name" you refer to AIM, ICQ.... or to your users?
If you refer to the societies which have created those IMs, don't worry. Think that if they would change their logon servers names, the big majority of their users could not be connected to them due to the default config into the softwares (they are not created to check somewhere in the net the name of the server, the name is directly put in their config, I'm not totally sure about this for MSN and Yahoo but I'm sure for ICQ and AIM).

Thanks KC!

Yes, the "they" in question are the IM's...shoulda clarified that. I'll probably just go with blocking thier logon servers for now I guess. Although they could easily create an "update" that auto runs on the client machine when they log on to the IM network, that modifies their config.....
Either way, thanks for the reply!

Thanks KC!

Yes, the "they" in question are the IM's...shoulda clarified that. I'll probably just go with blocking thier logon servers for now I guess. Although they could easily create an "update" that auto runs on the client machine when they log on to the IM network, that modifies their config.....
Either way, thanks for the reply!

"There are not technical solution to Administrative problems."

Saw this some where......

Basically.......Policy says dont do it or else!!!

"There are not technical solution to Administrative problems."

Saw this some where......

Basically.......Policy says dont do it or else!!!

I have found that the best policy is not "do not or else" but is "cannot at all".

I have found that the best policy is not "do not or else" but is "cannot at all".

You can make all your user restricted so they cannot install any software on there machine.

You can make all your user restricted so they cannot install any software on there machine.

I agree with what gypsygeek said "There are not technical solution to Administrative problems." In short unless you are backed up with a policy that has some teeth in it users will use web based chat. Depending on the firewall at least with one that I used a few years you could ban access based upon the program accessing the web even if it rode on top of the web browser. Better bet is not to block a server name but the IP address range, followed by the ports they use. Another alt way is to aduit the users of chats computers most if not all by default save a log (boy this can really bite a company), simply review the log and chat times etc then confront the user that is chatting and not working. Work is work play is play :) Unless they dig around logs will be there unless they have shut them off, also check out the really hidden M$ files they keep it all and takes much effort to find and remove those files, but do a google search and find out how to read them.

I agree with what gypsygeek said "There are not technical solution to Administrative problems." In short unless you are backed up with a policy that has some teeth in it users will use web based chat. Depending on the firewall at least with one that I used a few years you could ban access based upon the program accessing the web even if it rode on top of the web browser. Better bet is not to block a server name but the IP address range, followed by the ports they use. Another alt way is to aduit the users of chats computers most if not all by default save a log (boy this can really bite a company), simply review the log and chat times etc then confront the user that is chatting and not working. Work is work play is play :) Unless they dig around logs will be there unless they have shut them off, also check out the really hidden M$ files they keep it all and takes much effort to find and remove those files, but do a google search and find out how to read them.

Depending on how serious you are about enforcing the no chat policy (and hence your willingness to track everything down), you could set up the blocks to those ip's/domains and then log all those denies (or even the default port for the application). You would then know who tried to access it and you could take whatever actions are necessary to remove the messenger from the network.

As a side note, many IDS systems have signatures that detect the use of messengers, you could set it up to either log the events or even to kill the connections as it sees them (usually with a reset that is sent to both ends of the connection), but you need to be a little careful with that in that you might accidentally block legitimate traffic (depending on how good those signatures are).

/nebulus

Depending on how serious you are about enforcing the no chat policy (and hence your willingness to track everything down), you could set up the blocks to those ip's/domains and then log all those denies (or even the default port for the application). You would then know who tried to access it and you could take whatever actions are necessary to remove the messenger from the network.

As a side note, many IDS systems have signatures that detect the use of messengers, you could set it up to either log the events or even to kill the connections as it sees them (usually with a reset that is sent to both ends of the connection), but you need to be a little careful with that in that you might accidentally block legitimate traffic (depending on how good those signatures are).

/nebulus

I know there's different options to achive the same goal. Thats not what I was asking. Either way, best bet is to block their logon servers I guess. Simplest anyway, and doesn't give me a headache.

Thanks for all the replies though!

I know there's different options to achive the same goal. Thats not what I was asking. Either way, best bet is to block their logon servers I guess. Simplest anyway, and doesn't give me a headache.

Thanks for all the replies though!

If you use a NIDS you can also create rules to look for the SYN's on the default port. This will catch the initial SYN against the, (blocked), default port. The you can take a womble down to the offending users desk and slap the little ******* for contravening policy.

Works for me...... :D

If you use a NIDS you can also create rules to look for the SYN's on the default port. This will catch the initial SYN against the, (blocked), default port. The you can take a womble down to the offending users desk and slap the little ******* for contravening policy.

Works for me...... :D

Hey Nebulus,

I didn't know IDS's could block traffic as well. What IDS were you referring to? I might check out that option....then supplement that with Tiger Shark's idea. :D

Thanks everyone!

Hey Nebulus,

I didn't know IDS's could block traffic as well. What IDS were you referring to? I might check out that option....then supplement that with Tiger Shark's idea. :D

Thanks everyone!

I am wanting to say snort can do this (not 100% sure, haven't really tried to do this very often). When I stated this, I had ISS RealSecure in mind, but really I think that most modern NIDS have this capability. It isn't anything special really, it just sends a spoofed packet to the source and destination (pretending to be one or the other) and sends a reset. Both sides will think there was a communication or some other kind of error and drop the connection. If it is something you are not seeing very often it would be safe to do this, but if you were not careful and you set it up to do that on an event that is frequently triggered, you will wind up amplifing the amount of traffic (for every packet it triggers off of, it generates 2 packets to kill the connection) which could do more harm than just letting the event go without resetting the connection.

Hope this helps,

/nebulus

I am wanting to say snort can do this (not 100% sure, haven't really tried to do this very often). When I stated this, I had ISS RealSecure in mind, but really I think that most modern NIDS have this capability. It isn't anything special really, it just sends a spoofed packet to the source and destination (pretending to be one or the other) and sends a reset. Both sides will think there was a communication or some other kind of error and drop the connection. If it is something you are not seeing very often it would be safe to do this, but if you were not careful and you set it up to do that on an event that is frequently triggered, you will wind up amplifing the amount of traffic (for every packet it triggers off of, it generates 2 packets to kill the connection) which could do more harm than just letting the event go without resetting the connection.

Hope this helps,

/nebulus

Just an FYI for those that didn't know: AIM does, in fact, allow you to search and connect on other ports. The other day, I tried connecting with the default port, and it would not allow me to contact the login server. Next, I went into the configuration - where you can change to go through a proxy and so on... Here, I found an option to scan for a port to connect through, and low and behold, it connected over port 21! UGH!

Just an FYI for those that didn't know: AIM does, in fact, allow you to search and connect on other ports. The other day, I tried connecting with the default port, and it would not allow me to contact the login server. Next, I went into the configuration - where you can change to go through a proxy and so on... Here, I found an option to scan for a port to connect through, and low and behold, it connected over port 21! UGH!

Nebulus: No point in using the IDS to drop both sides of the connection, (Yes Snort will do this if the rule is written to do it and there is also a test facility that allows a message to be sent to the two machines I believe - I gotta look into that in a minute..... ;) ), since the client will assume it is dropped at the firewall and allow the alternative connection to take place.

I'm gonna take a look at the message thingy, test it and see what it does. The I might add the message part to a rule for these chat proggies that will be received by the offending user telling them to quit or die...... :D . I'll see if it works and get back to you all.

Pooh..... :(

I use a custom version of snort that does not include flexresp therefore it doesn't recognize the react keyword and fails out on the rule....... Also, this used to send a message to the browser rather than a windows messaging message, (which would be real nice), so it is designed to limit web access more than anything else - shame really... I coulda had a lot of fun with my (L)users...... :D

Nebulus: No point in using the IDS to drop both sides of the connection, (Yes Snort will do this if the rule is written to do it and there is also a test facility that allows a message to be sent to the two machines I believe - I gotta look into that in a minute..... ;) ), since the client will assume it is dropped at the firewall and allow the alternative connection to take place.

I'm gonna take a look at the message thingy, test it and see what it does. The I might add the message part to a rule for these chat proggies that will be received by the offending user telling them to quit or die...... :D . I'll see if it works and get back to you all.

Pooh..... :(

I use a custom version of snort that does not include flexresp therefore it doesn't recognize the react keyword and fails out on the rule....... Also, this used to send a message to the browser rather than a windows messaging message, (which would be real nice), so it is designed to limit web access more than anything else - shame really... I coulda had a lot of fun with my (L)users...... :D

I simply restrict access to the hosts file, and then add the servers URL to it.
127.0.0.1 www.aol.com <----- repeat for ALL the aol chat servers.
quick buddy is another one to block too since its Javabased.
*shrug* its work, but if your seriously wanting it gone, it works for me.
the kiddies cant access C:\ so they cant get the hosts file...
its not the best way in a open machine, but its how I stopped it.

I simply restrict access to the hosts file, and then add the servers URL to it.
127.0.0.1 www.aol.com <----- repeat for ALL the aol chat servers.
quick buddy is another one to block too since its Javabased.
*shrug* its work, but if your seriously wanting it gone, it works for me.
the kiddies cant access C:\ so they cant get the hosts file...
its not the best way in a open machine, but its how I stopped it.

I am in the fortunate position of having extremely unsophisticated users and a firewall that is blocking their attempts. I was just going to add a snotty message for my own amusement and edification..... :)

As to blocking access to C:...... Wouldn't work in my environment..... Good suggestion for others tho....

I am in the fortunate position of having extremely unsophisticated users and a firewall that is blocking their attempts. I was just going to add a snotty message for my own amusement and edification..... :)

As to blocking access to C:...... Wouldn't work in my environment..... Good suggestion for others tho....