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 <[EMAIL PROTECTED]> 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/
