Date: Wed, 09 Aug 2006 19:29:48 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: "Marc G. Fournier" <scrappy@freebsd.org> Cc: Howard Jones <howie@thingy.com>, freebsd-questions@freebsd.org Subject: Re: BSDstats Project v2.0 ... Message-ID: <44DA299C.8080801@infracaninophile.co.uk> In-Reply-To: <20060809142006.F7522@ganymede.hub.org> 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> <ef10de9a0608090341l696b6ea3s2187f4b0a9b5fa6e@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44DA299C.8080801>