Locking user accounts
Okay, you’ve just seen how to have Linux automatically lock user accounts that are under attack. There will also be times when you’ll want to be able to manually lock out user accounts. Let’s look at a few examples:
- When a user goes on vacation and you want to ensure that nobody monkeys around with that user’s account while he or she is gone
- When a user is under investigation for questionable activities
- When a user leaves the company
With regard to the last point, you may be asking yourself, Why can’t we just delete the accounts of people who are no longer working here? And, you certainly can, easily enough. However, before you do so, you’ll need to check with your local laws to make sure that you don’t get yourself into deep trouble. Here in the United States, for example, we have the Sarbanes-Oxley law, which restricts what files that publicly traded companies can delete from their computers. If you were to delete a user account, along with that user’s home directory and mail spool, you just might be running afoul of Sarbanes-Oxley or whatever you may have as the equivalent law in your own home country.
Anyway, there are two utilities that you can use to temporarily lock a user account:
- Using usermod to lock a user account
- Using passwd to lock user accounts
In apparent contradiction to what I just said, at some point you will need to remove inactive user accounts. That’s because malicious actors can use an inactive account to perform their dirty deeds, especially if that inactive account had any sort of administrative privileges. But when you do remove the accounts, make sure that you do so in accordance with local laws and with company policy. In fact, your best bet is to ensure that your organization has written guidelines for removing inactive user accounts in its change management procedures.
Using usermod to lock a user account
Let’s say that Katelyn has gone on maternity leave and will be gone for several weeks. We can lock her account with the following:
$ sudo usermod -L katelyn
When you look at Katelyn’s entry in the /etc/shadow file, you’ll now see an exclamation point in front of her password hash, as follows:
This exclamation point prevents the system from being able to read her password, which effectively locks her out of the system.
To unlock her account, just do this:
$ sudo usermod -U katelyn
You’ll see that the exclamation point has been removed so that she can now log in to her account.
Using passwd to lock user accounts
You could also lock Katelyn’s account with this:
sudo passwd -l katelyn
This does the same job as usermod -L, but in a slightly different manner. For one thing, passwd -l will give you some feedback about what’s going on, whereas usermod -L gives you no feedback at all. On Ubuntu, the feedback looks like this:
donnie@ubuntu-steemnode:~$ sudo passwd -l katelyn [sudo] password for donnie: passwd: password expiry information changed. donnie@ubuntu-steemnode:~$
On CentOS, the feedback looks like this:
[donnie@localhost ~]$ sudo passwd -l katelyn Locking password for user katelyn. passwd: Success [donnie@localhost ~]$
Also, on the CentOS machine, you’ll see that passwd -l places two exclamation points in front of the password hash, instead of just one. Either way, the effect is the same.
To unlock Katelyn’s account, just do this:
$ sudo passwd -u katelyn
In versions of Red Hat or CentOS prior to version 7, usermod -U would remove only one of the exclamation points that passwd -l places in front of the shadow file password hash, thereby leaving the account still locked. No big deal, though, because running usermod -U again would remove the second exclamation point.
In Red Hat or CentOS 7, it has been fixed. The passwd -l command still places two exclamation points in the shadow file, but usermod -U now removes both of them.
Locking the root user account
The cloud is big business nowadays, and it’s now quite common to rent a virtual private server from companies such as Rackspace, DigitalOcean, or Microsoft Azure. These can serve a variety of purposes:
- You can run your own website, where you install your own server software instead of letting a hosting service do it.
- You can set up a web-based app for other people to access.
- Recently, I saw a YouTube demo on a crypto-mining channel that showed how to set up a Proof of Stake master node on a rented virtual private server.
One thing that these cloud services have in common is that when you first set up your account and the provider sets up a virtual machine for you, they’ll have you log in to the root user account. (It even happens with Ubuntu, even though the root account is disabled on a local installation of Ubuntu.)
I know that there are some folk who just keep logging in to the root account of these cloud-based servers and think nothing of it, but that’s really a horrible idea. There are botnets, such as the Hail Mary botnet, that continuously scan the internet for servers that have their Secure Shell port exposed to the internet. When the botnets find one, they’ll do a brute-force password attack against the root user account of that server. And yes, the botnets sometimes are successful in breaking in, especially if the root account is set with a weak password.
So, the first thing that you want to do when you set up a cloud-based server is to create a normal user account for yourself and set it up with full sudo privileges. Then, log out of the root user account, log in to your new account, and do the following:
$ sudo passwd -l root
I mean, really, why take the chance of getting your root account compromised?