l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2008 Aug 16 22:22

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] security
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] security

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@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.

  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

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.