On 09/18/2012 06:27 PM, Walter Stanish wrote: > 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 >
Like you said, there are some entropy gathering daemons (I use em in VMs), so that's a good place to start I think. After that, I would probably go with some hardware rng solution if you determine this to be that much of a risk. Since you can keep http connections open for long periods of time with HTTP/1.1 that can also be used to help mitigate some exhaustion (rate limit people). In fact, rate limiting in general is probably good. -- -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
