Over the past few weeks it has become clear that SSH brute force attacks are impacting the operation of the cryptocard servers. ALCF operations staff has been reporting intermittent problems logging into resources. Some of these incidents seem to correlate with periods of distributed SSH brute-force attacks against the lab. Most of these attacks target the user root. We decided to look into improving the situation by seeing if we could limit the number of root login attempts from ALCF systems and we'd like to pass along the information to other teams who use cryptocard. In the case of ALCF we cannot disable root logins on our externally accessible systems because we use the account to manage the systems internally. In our environment authentication for root is completed via a key-based authentication and root should never authenticate via cryptocard. This means that we needed to allow root to authenticate via keys but disable root's ability to authenticate via PAM (which facilitates cryptocard logins using the radius module). There are many ways to approach this problem but we wanted to share a couple solutions we've tested to encourage others who have externally accessible systems to consider preventing root login attempts from sending traffic to the cryptocard server and improving performance and stability (not to mention security) for everyone. 1) SSHD "match" option Newer versions of OpenSSH have a feature that allows conditional configuration options for the server. The version of OpenSSH installed on our systems would need to be upgraded to use this option. match user root KbdInteractiveAuthentication no Including the lines above at the end of the sshd_config would disallow PAM authentication for the root user only. This would prevent external users attempting to log in as root from even receiving the password prompt. match works with other criteria as well such as Host or Address. Address can accept cidr notation so you can disable root logins for all except internal systems. See the sshd_config man page for more info. 2) PAM module pam_listfile.so PAM includes a module that can allow or deny access to a list of users (among other criteria). You can add the module to the sshd authentication stack before PAM attempts radius and prevent the user root from ever being prompted for a password. auth requisite pam_listfile.so onerr=succeed item=user sense=deny file=/etc/ssh/ssh.denyusers The line above would be placed in the /etc/pam.d/sshd file before sshd attempts radius/cryptocard authentication. The "requisite" keyword causes PAM to immediately fail the login attempt as soon as this test fails. "required" still calls the other modules in the auth stack. The file "/etc/ssh/ssh.denyusers" can be named anything and contains the single entry "root". Again, the hostbased and key authentication is unencumbered for internal connections but external users attempting to login as root are not even presented with a password prompt. *Another interesting PAM module is pam_localuser.so which requires that the user be listed in the local /etc/passwd file before allowing PAM authentication to continue. Used with the requisite keyword would cut off the random account name guessing attacks as well. This assumes, of course, that all users on the system exist in /etc/passwd. The module probably won't work if LDAP is being used to user management. ALCF has tested and implemented a solution. The cryptocard server (at MCS) should be seeing practically no attempted root logins from ALCF systems at this time. If you'd like to try this on your systems please don't hesistate to contact me if you have any questions. Thanks! -- Piotr T Zbiegiel Cyber Security Engineer Argonne National Laboratory _______________________________________________ This is the CELS Sysadmins mailing list. It is sent to memebers of: [email protected], [email protected], [email protected], [email protected]. Do not subscribe directly to this list. Thanks.