Although Linux systems are by-and-large more secure than many other systems, they still need to be administered intelligently. Stupid configurations often lead to unfortunate results. According to Akamai: “As the number of Linux environments has grown, the potential opportunity and rewards for criminals has also grown”. As a result, there have been a number of Linux systems added to botnets because the owners who enabled ssh had easily-guessed passwords. As part of the IT best practices project, I’ve recently added a rule (itbp-00002) which disallows password authentication over ssh. This blog post explains this, and why people who manage Linux systems should care.

Linux needs good security rules too

Because of the wide availability and frankly horrible track record of some other operating systems, much of the IT world began moving critical infrastructure to Linux back around 2000. In general, this is a good idea, but even a Linux bigot like me has to admit that you can still break into poorly managed Linux systems pretty easily. Akamai says: “The real problem is how many poorly configured Linux systems exist in the real world. Linux isn’t a magic bullet that will make a system secure—it has to be locked down properly, too.” As a result there are a number of botnets that take control of these Linux systems – including the XOR DDOS botnet, the Spike DDOS toolkit, and the IptabLes or IptabLex infestations. The good news is that there are a number of software systems that help you lock your system down, including the Assimilation System Management Suite.

ssh security rules

The US government DISA rules for Linux are actually overall a good start. Nevertheless, they still allow ssh access using passwords – which in this day and age is not such a good idea. If you look at the security logs on systems with ssh password authentication enabled, you’ll see thousands of attempts to log in every day. All day long, and all night long, someone out there is jiggling the doorknob of the front door to your system to see if they can get in. Sometimes you hear people say that using good passwords is enough – and it surely is a good thing. But it isn’t enough.

If your users share passwords across sites, or you have easily guessed passwords, your site will get hacked if you allow ssh with passwords. Since you can’t prevent your users from sharing passwords between systems, and you can’t keep sites where they might have shared them from getting hacked, you simply shouldn’t allow normal passwords in ssh at all.

In the presence of PAM, it is a little more complicated than I’ll discuss here, but for the sake of simplicity, I’ll ignore that for the moment, and concentrate on a rule for disabling password authentication in /etc/ssh/sshd_config. For similar reasons, I’ll not cover how to configure ssh to use ssh keys, or two-factor authentication. Those topics are reasonably well covered elsewhere on the Internet.

IT Best Practices ssh security rule

I’ve written a rule in the IT Best Practices project for disabling tunnelled passwords, and it looks a bit like the text below (I’ve added newlines to improve readability).

{
 “severity”: “medium”,
 “tags”: {“itbp”: [“itbp-00002“] },
 “text”: {
   “en”: {
     “check”: “To check that password authentication is disabled via openssh execute the following command:
# grep PasswordAuthentication /etc/ssh/sshd_config
The result should be an uncommented no. If there is no result the result is commented out or the value is yes, then this is a finding.”,
     “fix”: “To fix this issue, add the following line to /etc/ssh/sshd_config
                PasswordAuthentication no“,
     “long_description”: “By default, the secure shell service allows users to log into systems using passwords tunnelled through secure communications. This makes the services vulnerable to brute force attacks for users with weak passwords or passwords were shared across sites. Although disabling password authentication is a good practice in general, it is critical for any systems which face the public internet.”,

     “short_description”: “The openssh service should not allow logging in using passwords.”
   }
 }
}

Like all rules in the IT Best Practices project, it just provides the text describing this best practice, along with some justification of why you should care. It leaves the implementation to human beings or tools like the Assimilation Suite.

Assimilation best practices ssh security rule

As with all the IT best practices rules, it does not provide automatic detection or repair of the condition. In the Assimilation Project the rule for validating this condition is both straightforward and succinct:

“itbp-00002”: {
      “category”: “security”,
      “rule”: “MUST(EQ($PasswordAuthentication, False))”
 }

The Assimilation code evaluates this rule every time /etc/ssh/sshd_config changes on a machine. As a result, if you enable password authentication on any machine in your environment, you’ll know quickly that it’s out of compliance. This gives you a chance to fix it before an auditor or attacker discovers it, and while the people involved still remember what they did, and why they did it.

Do you want to know when your systems get out of compliance with best practices? If so, look into Assimilation Suite Cybersecurity.