Bill Broadley wrote:
> Hmm, maybe I should have sent this mail to the list instead of the
> other one, oh well.
Again, hoping you won't take amiss my posting this quickly-written
response. Please consider posting the mail I'm answering; you make good
points that should really be heard by the community.
Geting to the meat of things:
Hi, short on time, but:
Quoting Bill Broadley ([EMAIL PROTECTED]):
> Right, so tripwire runs ONLY from secure media. How do you get august's
> 1000's of file updates securely into tripwire?
Personally, by not installing the kitchen sink or enabling a bunch of
things I don't need in the first place.
> I wonder how many services, users, and servers ranum manages. How he avoids
> ssh....
I'm curious about that too.
> and if he's applied a bunch of bind patches lately.
*I* run BIND9, but am not proud of it. (My home server is an example of
the cobbler's kids going barefoot. It needs re-doing. OTOH, even with
some questionable choices for convenience's sake and horrible neglect,
it's turned out to do fine.)
Deployment of caching recursive-resolver nameservice is an excellent
illustrative example of Ranum's point: You always had better
alternatives than BIND9. (No, I'm not a DJB fan in general, but he did
happen to be right.)
To save time, let me borrow from a summary I did for _Linux Gazette_:
So, basically, improved port randomisation in client resolvers is
getting rolled out with newer OS kernels.
Having access to _reliably_ random data is actually a quite difficult
problem, and unfortunately many programmers get bitten by the results of
trying to punt the problem, e.g., by just tapping into the OS's
/dev/random or /dev/urandom. The former tends to be pretty good (but
not great) on most 'Nixes including Linux -- _but_ tend to exhaust the
system's "entropy pool" quickly. The latter (urandom) is an _unlocked_
random generator that re-uses the internal pool, so it produces more
numbers before conking out, but of lower quality.
A cautious programmer would look at that situation, and think "Gosh, if
my code needs reliable random data, I guess I need a decent random
number generator library (RNG), rather than just punting to the OS."
Which is indeed what smart nameserver authors did, a long time ago.
Compare:
Caching recursive resolvers:
o BIND9: Wasn't smart, recently patched to compensate
o MaraDNS: Author built in a custom RNG from the beginning
o PowerDNS Recursor: Retrofitted a custom RNG in March 2008, after
someone filed a security bug anticipating the Kaminsky issue
o djbdns/dnscache: built in a custom RNG from the beginning, _and_
the author made a point of warning everyone else of the pitfall
o Unbound: Author built in a custom RNG from the beginning
Caching forwarders:
o pdnsd: Author built in a custom RNG from the beginning
o dnsmasq: Wasn't smart, recently patched to compensate
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
