Re: [gentoo-hardened] Entropy Management?

[Tóth Attila]

You may use some dedicate hardware to make your server not the first in
the row to fail in case of an entropy exhaustion attack.
http://www.entropykey.co.uk/

Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, [phone]

2012.Szeptember 19.(Sze) 01:27 időpontban Walter Stanish ezt írta:
> Hi there,
>
> This is a bit general, rather than a specific suggestion, since I
> don't think I can make tomorrow's meeting maybe people might like to
> discuss it there.
>
> Reading the more recent OpenSSL man page it occurred to me that there
> may be a potential with some types of daemons (such as recent OpenSSL
> run with the 2.x default of --key-method 2) to facilitate remote
> system entropy exhaustion as a type of DoS.
>
> I am aware of entropy gathering daemons but none so much for entropy
> as an input to overall system management (connection throttling,
> control group freezing, etc.).
>
> Has there been any attempt to integrate system entropy management with
> any major Linux distribution?
> Has Gentoo hardened looked at entropy impact of various packages?
>
> I think there could be some research potential here.
>
> The first step might be to establish suitably automated mechanisms for
> formal testing of package / package revision entropy impact under
> various test loads, with a view towards enhancing the visibility and
> ease of entropy management across hardened gentoo systems.
>  - I'm not sure if there is an automated test suite set up within the
> Gentoo infrastructure at present, though some packages have built-in
> tests, and some packages have a USE flag to enable/disable these, it
> seems difficult to re-run these tests after packages are emerged.
>  - There are also more general testing tools such as the Apache
> Project's 'ab' and 'bonnie++' that could be used for some types of
> packages.
>
> Whilst it is easily possible to monitor entropy over time (eg: using
> rrdtool configured to source data from
> /proc/sys/kernel/random/entropy_avail) I have never heard of any
> attempt to monitor this availability over time and integrate it in to
> system management.  I have however heard of problems with relatively
> commonly deployed daemons (I forget which now, but not so long ago it
> happened to me too) wherein entropy exhaustion causes a complete
> functional DoS for a process blocking for unavailable entropy.
>
> Perhaps a new control group implementation for maximum entropy draw
> rate per namespace might also be a useful contribution to the kernel?
>
> I suppose this sort of thing is tending to increase in importance as
> the density of services per physical system increases under the
> continuing trend towards high density virtual hosting (either
> container based or paravirtualized).
>
> First post here ... hope I'm not completely off track with this, just
> throwing the idea out there.
>
> Cheers,
> Walter
>