Re: blocking Google Desktop

[sekure <sekure () gmail com>]

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/