Firewall Wizards mailing list archives
Re: Blocking Google Talk
From: "Jon Czerwinski" <jonc () cohnconsultingcorp com>
Date: Tue, 20 Jun 2006 17:39:40 -0400
How about blocking the program execution with domain group policies? This takes subversion back to a conscious decision by the person installing the application to go around the restrictions you've put in place. Jon Czerwinski -----Original Message----- From: firewall-wizards-bounces () listserv icsalabs com [mailto:firewall-wizards-bounces () listserv icsalabs com] On Behalf Of Mike Powell Sent: Tuesday, June 20, 2006 2:04 PM To: firewall-wizards () listserv icsalabs com Subject: Re: [fw-wiz] Blocking Google Talk I'm the original poster of the "blocking google talk" question, so I feel the need to weigh in on this.
Bleh. Filtering out nameservers is one way of using a proxy to block traffic. You do run your own recursive resolvers anyway, right? Not running your own resolvers is a bad idea in the first place. [...]
It is a "band-aid" approach rather than a mature solution. [...]
We are running our own DNS internally, so although manually returning localhost for talk.google.com will stop the Google Talk connections, I also agree that it is a band-aid approach.
If Google can't provide a mature way of preventing traffic *1 what
does > >that tell
you about the design of the program/protocol?Lets see, https for authentication, XMPP for communication? Rather
open
standards, aren't these? [...]
It would be, if it actually happened that way. XMPP is supposed to use port 5222. None of our users can get out on port 5222, and I see the connections being successfully blocked in the logs. The Google Talk client then goes on to make connections on ports 80 and 443 and happily goes on about its business as if nothing was wrong. My belief is that the Google Talk client identifies that port 5222 is blocked, and falls back to transmitting data using HTTP-compliant communications in order to get around the blocking that has been put in place. To me, this says that someone planned for Google Talk to work around blocking, even if XMPP on port 5222 was filtered. I call that deliberate subversion (and it means that google lied on their google talk faq page about how the client works). If someone out there has actually dissected the google talk data on the wire, and my assumption that the client falls back to http and/or http-over-ssl is incorrect, I would be happy to be set straight. Note: we are not merely allowing ports 80 and 443 to pass, they go through as proxied connections. This means that the Google Talk connections are being made as proxy-aware http-compliant connections.
This isn't a bandaid. Oh, and if you really want to stop the problem, why not just prevent the installation of the software in the first place? [...]
Hey, what a great idea! FYI, I have installed Google Talk onto a machine using an unprivileged domain user account. The google talk installer will not let you continue with the install pointed into c:\Program Files, but if you choose a directory that you as a user have full access to (such as your own desktop), the installer will allow you to complete and Google Talk will successfully start up. It won't add itself to the Add/Remove Programs section if you are not a local admin, but it will copy its files and allow the user to run it. Again, to me it sounds like someone spent a lot of effort to make sure that non-admin users with only limited internet connectivity (proxied http connections on ports 80 and 443) would be able to successfully run the google talk client. Fortunately, I have been able to stop the google talk client from logging in by blocking all URLs that start with http://talk.google.com and https://talk.google.com. However, for those running firewalls that are not http protocol-aware for filtering out specific URLs, it looks like you are pretty much upriver sans propulsion. You can't just block all communications to talk.google.com, because the addresses that talk.google.com points to are the same addresses that www.google.com points to. If you block talk.google.com by IP, you will also block www.google.com. Again, as I stated earlier, if someone has more time to dig into this and can prove that Google Talk will not work with port 5222 blocked and fails to install for a non-admin user, I would be happy to be corrected. However, the information within this message is my understanding from what I have been able to observe, and I haven't been very happy with what I've observed. Mike Powell _______________________________________________ firewall-wizards mailing list firewall-wizards () listserv icsalabs com https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards _______________________________________________ firewall-wizards mailing list firewall-wizards () listserv icsalabs com https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: Blocking Google Talk, (continued)
- Re: Blocking Google Talk Frank Knobbe (Jun 19)
- Re: Blocking Google Talk R. DuFresne (Jun 20)
- Re: Blocking Google Talk Devdas Bhagat (Jun 20)
- Re: Blocking Google Talk Frank Knobbe (Jun 20)
- Re: Blocking Google Talk Dale W. Carder (Jun 21)
- Re: Blocking Google Talk Oliver Humpage (Jun 21)
- Re: Blocking Google Talk James (Jun 27)
- Re: Blocking Google Talk Paul D. Robertson (Jun 27)
- Re: Blocking Google Talk Frank Knobbe (Jun 19)
- Re: Blocking Google Talk Devdas Bhagat (Jun 21)
- Re: Blocking Google Talk Jon Czerwinski (Jun 21)
- Re: Blocking Google Talk Jim Seymour (Jun 21)