Hi Cisco gods,
I have successfully blocked all chat services at the PIX firewall, I think. As I walk around and find people using MSN or Messenger I find that public proxy they are using and kill it too. BUT, I am having a hell of a time with ICQ. I do have all the ports UDP and TCP blocked so it does not work UNLESS they use port 80. This is where I am stuck, I cant block port 80 as you know so how do I kill this monster? Has any one had luck with this and has anyone found a way to stop the public proxy usage? I really feel as if I am fighting a losing battle, cuss for every block I am countered with a way around it.
My inside ACL in the pix is quite impressive and all just for blocking this crap, if anyone would like it for theirs I will provide as it is proven and works, with exception to ICQ.
Rob Mears III, CCNP, MCSE, CNE, NNCDS, NNCSS, NNCPS, MCP+I, A+
It seems like the Proxy fully goes out to the internet without restriction. Configure the Pix to filter out this Proxy, and allow certain protocols and ports only.
I would appreciate if I can get a copy of your impressive ACL. I am also working on blocking some peer-peer file services and instant messengers.
Would you email a copy of those ACL's to me. I'm running Websense as well but have 9 locations connected via VPN tunnels (506's to 515 at host end) and would like to do some port blocking on the remote 506's. Currently do not have the ability to put a websense server in each location and for a few of them I don't want send all traffice back through the host to get internet access, seems like a waste. My email address is email@example.com. Thanks.
Have you tried to block the server login.icq.com on all ports? For users to be able to use ICQ they have to authenticate to the login server for their status to be known to other users
You really should take the advice of jerryd: "block the server login.icq.com"
It's the only way, apart from handing off to a CVP server. I imagine you could probably halve your access-lists at the same time.
Having 100 access-lists is just not going to solve your problem.
ie I personally use port 443 for icq and am sure many others do as well.
I would really like to receive a copy of your inside acl.
I'am facing more or less the same problem.
Could you send it to the following address:
Trying to block instant messenging is a losing battle. You are far better off trying to deal with it through a computer use policy rather than waisting cpu cycles on your PIX.
Since you have to leave port 80 open that is always going to leave a window open. Some of the programs are automatic in their search for a connection looking for any open port and others it is more of a manual process but, eventually all of them will find that open port. The only sure way to block them is to block them by IP. Problem with that is that each messenging service has many many servers and finding every one of them is going to be time consuming. There is also the fact that they seem to be expanding constantly adding new servers so the job of keeping up with them is never ending.
I don't know about you but, I would rather spend my time doing real work instead of making sure people aren't running IM. I would rather let HR deal with these people. Get a good computer use policy going and make them all sign it.
Just the 2 cents of someone who has gone down that road :)
Southern Web Services
One more "I can't help with the problem but would like a copy of your ACL"
I am migrating from a 520 on a single T1 to a set of 525's on 2 T3's and going from 4.4(4) to 6.01 so I never used acls. Your list will be a great help.
Good luck with your problem. I use a proxy and block the sites...
Other than blocking specific destinations, I'm pretty sure you have "hit the wall," (so to speak) with the Pix.
There are other boxes / software that can accomplish total/ near total blockage of all the chat clients ... I believe Packeteer has a product (and there are others, I'm sure) that look for specific traffic signatures, not source/destination addresses or ports. So, regardless of the actual addresses or ports, the traffic signature is recognized, and the traffic is handled according to your desired profile.
Aside from that - What's the first rule of security? POLICY! get the policy restated, start logging, and whack the offenders - there's really not much else you can do. If management decides it's not enough of an issue to do it right, then you've covered your a$$.
Just my .02
The best approach to this problem is with an acceptable use policy. That being said, blocking access to the login servers used by the chat services using nslookup and acl's is an effective, if not administratively efficient, method to control the problem. Another method of blocking access to these servers is with DNS. You can create false records in DNS for these hosts, pointing to addresses on a non-existant internal network, then route all that traffic to that network to null0 on a LAN router.
Rich is absolutely corect.
Creating fake records/domains and redirecting to requests to these holes is the easiest and most common technique. It works, what can I say more..