Date: Mon, 2 Jan 2012 00:52:39 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: speaking of DoS, openssh and dropbear (CVE-2006-1206) Hi Nico, It was high time to bring this up on a public list. Thank you! On Sun, Jan 01, 2012 at 04:53:09PM +0100, Nico Golde wrote: > given the hash DoS I remembered a small program I wrote some time last year to > demonstrate why the default configuration of openssh sucks (MaxStartups and > LoginGraceTime). I think not only the default configuration, but also the approach behind MaxStartups sucks (either a fixed limit or RED). In fact, I told this to OpenSSH folks before, and I proposed an alternative, but clearly I should have done more (contributed code) in order for anything to change. To be fair, there are also things that I do like about MaxStartups: the idea to limit only not-yet-authenticated sessions (or to limit them separately from authenticated sessions) and the close-a-pipe-fd trick. > ... how to properly handle this issue with openssh? In the same way that I did in popa3d, I think: per-source limits. Maybe also per-source-netblock (e.g., separately for /8, /16, /24 - although this is IPv4-specific and these don't reflect actual netblock allocations). Another thing that popa3d's standalone mode takes care of is log flood. It makes sure that every single source IP address that is permitted to connect is logged at least once, but it avoids making mostly redundant records when a threshold is reached. For purpose of these limits, sessions are treated as active for at least a certain number of seconds after the connection is made. So if an attacker opens and closes connections rapidly, the per-source limit is hit and further connections start to be rejected and not even logged until those "zombie sessions" expire. (With per-netblock limits, this may become trickier as we'd want to log each individual IP address at least once.) In xinetd, we have per-source limits (my contribution from many years ago), but no log flood protection yet (something to fix). Speaking of log flood, this is not only about filling up a filesystem, but also about exhausting syslogd bandwidth (especially easy if fsync's are not disabled). When the latter happens, the network service (sshd, etc.) and other services may be impacted. I've been toying with the idea of writing a libinetd that would have this functionality in it (and we'd have an inetd clone, sshd, and other services use it), but I never got around to doing it. > I feel uncomfortable to further ignore this problem. Same here. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ