Full Disclosure mailing list archives
Re: blocking Google Desktop
From: sekure <sekure () gmail com>
Date: Tue, 14 Feb 2006 12:06:03 -0500
Check out flowbits. The first rule would get flowbits:noalert; flowbits:set,google.user.agent; And the second rule would get flowbits:isset,google.user.agent; That way the alert for the first rule would be suppressed and the second rule would only trigger if the first one occured previously. On 2/13/06, Michael Holstein <michael.holstein () csuohio edu> wrote:
First, I made a mistake in the version number. The current/new one is version 3 (the one that uploads your data to Google) I've been experimenting with Snort sigs to detect this. Google Desktop uses a unique user-agent (I got a tip about this from another user at full-disclosure -- thanks Charles!) : User-Agent: Mozilla/4.0 (compatible; Google Desktop) So here is a snort sig for that ... alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg: "BLEEDING-EDGE Google Desktop User-Agent Detected"; flow: to_server,established; content:"User-Agent\: Mozilla/4.0 (compatible\; Google Desktop)"; nocase; classtype: policy-violation; sid: 3000001; rev:1; ) That sig would at least let you know who's using it, but blocking that traffic wouldn't do anything except prevent the RSS feeds (news, weather, etc) from loading. Now, for the file-specific stuff, since that's all done over SSL to google.com : Upon examining the SSL/TLS session setup, I wrote this one to flag the certificate Google is using (from Thwarte). This will probably change when they change/renew their certificates. alert tcp $EXTERNAL_NET 443 -> $HOME_NET 1024:65535 (msg: "BLEEDING-EDGE Google SSL key exchange"; flow: from_server,established; content:"|30 36 30 36 30 37 32 32 31 32 35 34 5A 30 68 31|"; rawbytes; content:"|77 77 77 2E 67 6F 6F 67 6C 65 2E 63 6F 6D|"; rawbytes; classtype:policy-violation; sid: 3000002; rev:1; ) Note that this also flags logons to gmail. The fetches with the "Google Desktop" user-agent happen first when the application is started -- then you get the SSL setup for any new data to be uploaded to Google's servers. Unfortunately, the dynamic/activate stuff in snort dosen't let you do an "alert" action after an activate -- because it's designed to just dump the next (n) packets. If there was a good way to chain the two rules together -- to say "after seeing 1, do REACT on #2" you could reliably kill any SSL/TLS sessions from somebody running Google Desktop, thus preventing the upload of anything. Thoughts? Michael Holstein CISSP GCIA Cleveland State University _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: blocking Google Desktop, (continued)
- Re: blocking Google Desktop Gaddis, Jeremy L. (Feb 10)
- RE: blocking Google Desktop Randall M (Feb 11)
- Re: blocking Google Desktop mamo (Feb 13)
- Re: blocking Google Desktop J.A. Terranson (Feb 11)
- Re: blocking Google Desktop Jason Coombs (Feb 11)
- Re: blocking Google Desktop J.A. Terranson (Feb 11)
- Re: blocking Google Desktop Michael Holstein (Feb 13)
- Re: blocking Google Desktop Prabhat Sharma (Feb 13)
- Re: blocking Google Desktop Valdis . Kletnieks (Feb 13)
- Re: blocking Google Desktop Michael Holstein (Feb 13)
- Re: blocking Google Desktop sekure (Feb 14)
- Re: blocking Google Desktop Michael Holstein (Feb 14)
- Re: blocking Google Desktop sekure (Feb 14)
- RE: Some one needs their coffee. WAS: blocking Google Desktop Randall M (Feb 11)
- Re: blocking Google Desktop gboyce (Feb 11)
- Re: blocking Google Desktop Nick FitzGerald (Feb 11)
- Re: blocking Google Desktop gboyce (Feb 11)