[vox-tech] security

[Rick Moen]

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 (bill at cse.ucdavis.edu):

> 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