New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenBMC with dropbear SSH library fails a Denial-Of-Service test #2185
Comments
@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 #define DROPBEAR_USE_PRNGD 0 /* Specify the number of clients we will allow to be connected but
/* And then a global limit to avoid chewing memory if connections
|
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 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 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.)
The text was updated successfully, but these errors were encountered: