Search

The brute is back.  By the brute, I mean the SSH brute force attack.  In the last month we have noticed an upturn in SSH brute force traffic targeting hosts addressed in public IPv4 address space.  The highest ranking attack sources we have seen include address allocations in KRNIC, APNIC, and RIPE.  In the cases we’ve encountered, the target user was either the root user or something out of a dictionary.  An SSH brute force attack challenges the complexity of the user generated password associated with a user account by iterating through a dictionary to guess user passwords.  Brute-force code will also generate attempts randomly.  The risk associated with the vulnerability exposed here is great, so its important that some action be taken by administrators to ensure a secure operating environment moving forward.

Does your organization currently employ a strong password policy?  Does your organization currently enforce this strong password policy? A strong password should be 14 characters long and should utilize numeric, upper and lower case alphabetical, and symbol characters such as “!@#$%^&*()”.    Most every modern operating system or directory service (LDAP) implementation supports enforcement of strong password complexity.  Administrators should ensure they are utilizing the password history function of their directory service if available, to minimize the potential for password reuse by end users.  For Linux users not utilizing a directory, you can utilize the PAM module provided by the Openwall project, passwdqc, which provides password complexity enforcement.

If your environment allows, utilize password-less authentication using public key encryption provided by either the RSA or DSS.  Most SSH clients and servers support one or both of these methods.  Finally, Ensure that your SSH server does not allow root or Administrator logins.

If your environment already has a firewall in place to facilitate network access control, you should ensure that TCP port 22 is only available to those networks that need access.  If your environment does not have a firewall, OS level packet filtering is available in all modern operating systems.  When thinking about the SSH surface area in your environment, ensure you include devices that are manageable via SSH including routers, firewalls, switches, and other network appliances.

You should really ask yourself why your SSH service is available to the public if you aren’t explicitly providing a shell service to end users.

Something to say?