From owner-freebsd-questions@FreeBSD.ORG Wed Aug 9 18:30:25 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEF3016A4DD; Wed, 9 Aug 2006 18:30:25 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD69043D46; Wed, 9 Aug 2006 18:30:23 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.6/8.13.6) with ESMTP id k79ITtcb005931; Wed, 9 Aug 2006 19:29:55 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=softfail; spf=softfail X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk k79ITtcb005931 Message-ID: <44DA299C.8080801@infracaninophile.co.uk> Date: Wed, 09 Aug 2006 19:29:48 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 1.5.0.5 (X11/20060801) MIME-Version: 1.0 To: "Marc G. Fournier" References: <20060807003815.C7522@ganymede.hub.org> <20060808102819.GB64879@augusta.de> <20060808153921.V7522@ganymede.hub.org> <44D8EC98.8020801@utdallas.edu> <20060808201359.S7522@ganymede.hub.org> <44D91F02.90107@mawer.org> <20060808212719.L7522@ganymede.hub.org> <20060809072313.GA19441@sysadm.stc> <20060809105404.GC19441@sysadm.stc> <44DA0715.1020507@utdallas.edu> <20060809130634.S7522@ganymede.hub.org> <44DA0DDF.40300@thingy.com> <20060809134007.U7522@ganymede.hub.org> <44DA1502.2040803@thingy.com> <20060809142006.F7522@ganymede.hub.org> In-Reply-To: <20060809142006.F7522@ganymede.hub.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5674502C513A720A0EE76548" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.infracaninophile.co.uk [IPv6:::1]); Wed, 09 Aug 2006 19:30:15 +0100 (BST) X-Virus-Scanned: ClamAV 0.88.4/1642/Wed Aug 9 15:30:49 2006 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_TESTING,NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on happy-idiot-talk.infracaninophile.co.uk Cc: Howard Jones , freebsd-questions@freebsd.org Subject: Re: BSDstats Project v2.0 ... X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2006 18:30:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5674502C513A720A0EE76548 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Marc G. Fournier wrote: > On Wed, 9 Aug 2006, Howard Jones wrote: >=20 >> Marc G. Fournier wrote: >> >>> Right, and the bad thing is if yu alias another IP on that device, th= e >>> hash totally changes, so we see that one host now as being two differ= ent >>> ones :) That's why we disqualified using ifconfig right at the >>> beginning ... >> >> But didn't you say that you effectively wipe the database once a month= , >> (or expire entries over that age)? I can't find the post that mentione= d >> that now, naturally... :-) if you aren't using the 'key' as a database= >> key, then what do you care that it changes as long as it uniquely >> identifies the system (which it definitely would)? >> >> I don't know how typical I am, but I don't really remember the last ti= me >> I added an IP alias on a running server, for our few dozen production >> systems. I would imagine that those types of changes might well be los= t >> of systems coming and going. >=20 > I add/remove IPs from our servers several times each week, as we add VP= S > and remove them, or move then between boxes ... This problem is intractable: any scheme you can think of to generate a unique identifying number on a random host out there on the net will eith= er fail to actually be unique, or suffer from mutating over time as machine configuration changes. How about the following. Use the bsdstats.hub.org to generate a random token and hand it to the client. 128 bits of randomness gives a sufficie= ntly large domain (340,282,366,920,938,463,463,374,607,431,768,211,456 differe= nt possible combinations) that given a good RNG collisions are not a problem= =2E You can generate that sort of token easily by, for example: % openssl rand -base64 16 KSOWkPuK03Od99S5vaPGdQ=3D=3D Base64 encoded strings will have to be URL escaped if they are passed as parameters in a HTTP GET -- perhaps encoding as a string of hex digits mi= ght be a better idea: % openssl rand 16 | hexdump -e '16/1 "%01x" "\n"' 566fc9f2374a7e999d9587dc143373fc Anyhow, that's just implementation detail. So the transaction would go like this the first time a client machine tri= ed to report its configuration: Client Server -------------------------------------------------------------------------= ---- Check for cached ID token Not found Request new token from server ------> Generate token Record it in DB Return token to client <------ Cache token in file Generate OS version info Send to server with ID token -------> If token is known, record data in D= B Generate Driver info Send to server with ID token -------> If token is known, record data in D= B etc. etc. -------------------------------------------------------------------------= ---- Because the server generates the tokens, it knows which ones are valid, a= nd can discard any data sent to it without a valid token. That doesn't prev= ent any vandal-minded person from requesting a metric butt-load of tokens to = spam the database with, but that's no worse than the current situation. The n= eat thing is, the number of available tokens is so huge that it is infeasible= to guess or accidentally collide with someone else's token. Eg. At 100Mb/s i= t would take about 10^33 seconds or 10^25 years to exhaustively search the whole = token space. Thus spammed data will just time out at the end of the month with= out affecting anyone else's real data. Stealing an existing ID token by brea= king into a machine or snooping on the net would be possible, but presumably sufficiently difficult to do in a large enough quantity that it wouldn't = have a significant effect on the overall statistics. If snooping turns out to b= e a real problem, then using HTTPS is a possibility, but that will ramp up th= e load on the server quite a bit. For subsequent updates, the client machine just reuses the same token out= of its cache file. If the cached token gets deleted, then the client machin= e will just have to request a new one and rely on the old data timing out at the= end of the month. Saving away the token should be simple -- just make the server return the= data to a 'get_token' query as MIME type text/plain and have fetch dump it in a cache file somewhere. /var/db/bsdstats for example. I can code up the= client side of this in about 5 minutes, but the server end of things will take a= little more work. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig5674502C513A720A0EE76548 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2imj8Mjk52CukIwRCFvCAJ0SmHDREuYumi8T0seNQHKjCi4qfgCfQTPl sjUO4uWrQpal2IVtDXVqGKU= =1o7y -----END PGP SIGNATURE----- --------------enig5674502C513A720A0EE76548--