Re: Blocking Google Talk

["Jon Czerwinski" <jonc () cohnconsultingcorp com>]

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