I've tried to block chatting from inside gmail account using iptables..but been unsuccessful in my Redhat Linux Box. I gave

service iptables stop

IPTABLES -A INPUT -s 209.85.231.189 -i eth0 -p tcp -j REJECT
IPTABLES -A OUTPUT -s 209.85.231.189 -i eth0 -p tcp -j REJECT

service iptables save

service iptables start

209.85.231.189 is the ip address for chatenabled.mail.google.com.
I tried giving the domain instead of the ip address. People were still able to chat via their gmail accounts. Did I do anything wrong or is there any other way of doing it.

Thanks & Regards,
Arun Vijay.V

When I checked that domain with "dig", it says the IP address is 208.69.36.132.

If you're absolutely sure that blocking that subdomain will do the trick, then a better option might be to use Squid to deny access. An ACL for this might look like:

I'm with win32sux on that one. I would definitely use squid to pull that off.

Thanks guys,
Sorry for the delay in responding to your suggestions. Chat is still possible from inside gmail. I read from another thread in this forum that you cant block/filter a site if it uses "https" connection using squid. Is that true. If so is there any other option left for me because all gmail access here is through "https"

Thanks & Regards,
Arun Vijay.V

Of course you can block a site if it uses HTTPS. The problem here is that if both services (email and chat) use an HTTPS connection to the same host, then your Squid won't be able to differentiate between email and chat traffic, as it'll all be encrypted. So basically, I'd say stick to your original plan (to block access to the .chatenabled.mail.google.com subdomain) and let us know whether it has the desired effect or not. Also, if you could post some access log data from Squid while the chat feature is activated that would help us suggest ACL tweaks.

Thank you... I've tried your suggestion of denying access to the .chatenabled.mail.google.com in squid. It was only after that I posted the reply.

Regards,
Arun Vijay.V

Okay, then could you show us what the access log looks like during a session?

These is the log entries that are generated during a gmail session in the access log

1265355017.435 133 185.168.113.61 TCP_MISS/200 1059 GET http://www.google.co.in/accounts/Logout2? - DIRECT/209.85.231.99 text/html
1265355017.671 236 185.168.113.61 TCP_MISS/200 687 GET http://www.google.co.in/accounts/ClearSID? - DIRECT/209.85.231.99 image/gif
1265355483.416 485 185.168.113.61 TCP_MISS/302 1214 GET http://mail.google.com/mail/ - DIRECT/74.125.113.83 text/html
1265355577.212 154 185.168.113.61 TCP_MISS/302 1117 GET http://www.google.co.in/accounts/SetSID? - DIRECT/209.85.231.99 text/html
1265356573.133 9408 185.168.113.61 TCP_MISS/000 0 POST http://safebrowsing.clients.google.c...ing/downloads? - NONE/- -
1265357095.397 1944 185.168.113.61 TCP_MISS/200 1061 GET http://www.google.co.in/accounts/Logout2? - DIRECT/216.239.61.104 text/html
1265357095.631 157 185.168.113.61 TCP_MISS/200 687 GET http://www.google.co.in/accounts/ClearSID? - DIRECT/216.239.61.104 image/gif

Thanks & Regards,
Arun Vijay.v

Well, I don't see anything there which could be used to single out the chat service. In fact, I'm not even seeing the .chatenabled.mail.google.com subdomain anywhere (which should show up as TCP_DENIED). Are you sure that chat was being used when these log entries were created? It would be nice to see the log starting from when the chat itself is enabled by the user.

Thanks win32x,
Been a bit busy over the past couple of days.. Yes , the chat facility was being used while these log entries were created. I've been told that what ever data are service happens through a secure HTTPS connection is not logged. i mean a log entry is not generated. Is that true. This info too I came across from another thread. Thanks again for your patience.

Regards,
Arun Vijay.V

Squid will log the start of SSL connections.

For example, this is what a line from my log looks like when I connect to LQ via Squid on localhost:As you can see, the CONNECT method is being used, with host www.linuxquestions.org at TCP port 443.

After the SSL connection is initiated, you're toast - which is why you need to check the log file before chat is initiated. If that chatenabled.mail.google.com subdomain (or any other chat-specific one) is used for anything, it should show up in your log. I don't know how Google handles this, but if a connection to that subdomain is necessary in order to get the chat thing working, then blocking it should work. If it's not needed, and everything is happening through subdomains like mail.google.com, then it might not be possible to filter the chat feature without also affecting the webmail service.

1 members found this post helpful.