All too often we hear about breaches in security where usernames and passwords were obtained and published online. Most of the time, what's revealed is that most passwords are very simple or iterative of a previous version (e.g., 12345 followed by 123456 on the next change). Implementing password requirements can help keep weak passwords out of your environment. These forced changes have their pros and cons, but when it comes down to it there are still flaws in authentication.
Managing password and security related issues in Linux is important, but there are some simple steps you can take to make your system more secure. Here is a look at a few options to consider. Let's look first at managing those passwords and accounts and then move on to just how often people are trying to access those accounts. Lastly, we'll cover some of the things we can do to limit those attempts.
Linux password management
Changing a user's password using the passwd command is pretty straightforward, but there's a lot more it can do. Did you know you can also use it to lock and unlock an account? What about passing in a password via stdin?
Change a password
passwd [username]
Change a password via stdin
echo “Some_STRONG_PASSWORD” | passwd —stdin root
Lock and unlock a password
passwd -l [username] passwd -u [username]
Files
When you work with passwords, both the /etc/passwd and /etc/shadow files are updated. The passwd file contains a lot of information, but ironically enough not the actual password hash. The hash is contained in the /etc/shadow file.
Why the /etc/shadow file?
In the early days, the hashed password was stored in the /etc/password file, but there was a problem—this file needed to be able to be read by everybody. Your password's hash being available to everybody is not a good thing. So the actual hash was moved to the /etc/shadow file, which is only readable by a privileged user.
How often are break-ins attempted?
Ever wonder how many times somebody has tried to log on to your publicly accessible server? The last command shows us the number of successful attempts. The lastb command shows us the number of unsuccessful attempts. As an example, my server has had 7,464 unsuccessful attempts in the past 12 hours.
Extra tip: The last and lastb commands write to the /var/log/wtmp and /var/log/btmp files, respectively. If you ever see these files zeroed out, you might have a problem.
What else can we do?
We've seen that there can be a large number of attempts to log on to a publicly accessible system. So, what can we do? There are a few things we can to do either limit or mitigate the number of attempts.
Change the port
The first thing we can do is change the port that SSH listens on. This can mitigate some of the attempts, but there are also tools like nmap that can scan for open ports.
Firewalls
Firewalls (iptables, UFC, and firewalld) are great. Their goal is to limit access to SSH to a smaller set of servers. The drawback is that you can, at times, lock yourself out if your IP changes or if you are attempting to log in from a new place.
Fail2Ban
Knowing what we know from the lastb command, we can look to tools like Fail2Ban to automatically block IPs after a certain number of unsuccessful attempts.
I hope this helps give some insight into passwords on your server and some direction in limiting attack vectors.
14 Comments