FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 09-18-2012, 11:27 PM
Walter Stanish
 
Default Entropy Management?

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
 
Old 09-18-2012, 11:49 PM
"Tóth Attila"
 
Default Entropy Management?

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, +36-20-825-8057

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
>
 
Old 09-19-2012, 05:00 AM
Matthew Thode
 
Default Entropy Management?

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)
 

Thread Tools




All times are GMT. The time now is 07:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org