Open generatz opened 2 years ago
@prkatti1 Please visit this .
From any client or IP we can have max 5 un-authenticated connections to avoid DoS & reduce unnecessary load on BMC.
https://github.com/mkj/dropbear/blob/master/default_options.h
/* Specify the number of clients we will allow to be connected but
/* And then a global limit to avoid chewing memory if connections
@joseph-reynolds @generatz ^^^
OK, thanks @prkatti1 . I thought it seemed logical for anti-DOS measure, but I had not seen it work on any system I tried. I wonder if the firmware is at fault, or whether the test is at fault. I tried opening 6 ssh sessions to a BMC manually from 6 consoles and that succeeded. Has anyone seen this work in practice?
I have no experience with this. But I am interested in making this limit work.
I believe the dropbear SSH server configuration above is ineffective because dropbear is a systemd socket-activated service, which means it starts when there in an incoming connection, establishes a SSH session, then stops.
To make this work, I have been looking into the dropbear systemd socket file configuration - https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear.socket documented here https://www.freedesktop.org/software/systemd/man/systemd.socket.html but I don't see any way to control MaxPreAuthenticatedConnections or know how systemd would know the state of a connection. (So, help wanted.)
A solution might require moving away from a socket-acctivated service, or moving away from dropbear and moving toward OpenSSH.
@prkatti1 anything we need to follow on this one?
In openbmc-test-automation/security/test_bmc_connections.robot there is the following test case:
The test case does what it sounds like: The test opens 5 concurrent ssh login sessions and leaves them hanging - it does not attempt a login to those 5 sessions. It then opens a 6th session and attempts a login there. The test passes if it is unable to login with the 6th attempt. In other words, it anticipates that the BMC should limit the number of concurrent, not-yet-completed login sessions.
Note that it is not testing for a limit on the number of concurrent login sessions (which I assume it should not). And it is not testing for a limit to the number of sequential failed logins (which would be good, but might be covered elsewhere.)
I haven't heard of such a security requirement, and wonder whether it should be optional, vendor specific, or deprecated. (FWIW, it doesn't pass on the various BMCs I've tested.)