Securing Normal User Accounts

Managing users is one of the more challenging aspects of IT administration. You need to make sure that users can always access their stuff and that they can perform the required tasks to do their jobs. You also need to ensure that users’ stuff is always secure from unauthorized users. In this chapter, we’ll look at how to lock down user accounts and user credentials to protect them from attackers and snoopers. We’ll wrap up by taking a brief look at a few centralized user management systems:

• Locking down users’ home directories
• Enforcing strong password criteria
• Setting and enforcing password and account expiration
• Preventing brute-force password attacks
• Locking user accounts
• Setting up security banners
• Detecting compromised passwords
• Understanding central user management systems

Locking down users’ home directories the Red Hat way

This is another area where different Linux distro families do business differently from each other. As we shall see, each distro family comes with different default security settings for users’ home directories. A security administrator who oversees a mixed environment of different Linux distros will need to take this into account.

Traditionally, Red Hat Enterprise Linux and all of its offspring, such as CentOS and AlmaLinux, have had better out-of-the-box security than any other family of Linux distros. This makes it quicker and easier to harden Red Hat-type systems because much of the work has already been done. One thing that’s already been done for us is locking down users’ home directories:

 [donnie@localhost home]$ sudo useradd charlie
 [sudo] password for donnie:
 [donnie@localhost home]$
 [donnie@localhost home]$ ls -l
 total 0
 drwx------. 2 charlie charlie 59 Oct 1 15:25 charlie
 drwx...

Locking down users’ home directories the Debian/Ubuntu way

Debian and its offspring, such as Ubuntu, have two user creation utilities:

• useradd
• adduser

Let’s look at both of them.

useradd on Debian/Ubuntu

The useradd utility is there, but Debian and Ubuntu don’t come with handy preconfigured defaults as the Red Hat-type distros do. If you were to just do sudo useradd frank on a Debian/Ubuntu machine, Frank would have no home directory and would be assigned the wrong default shell. So, to create a user account with useradd on a Debian or Ubuntu system, the command will look something like this:

sudo useradd -m -d /home/frank -s /bin/bash frank

Here’s a breakdown of what all this means:

• -m creates the home directory.
• -d specifies the home directory.
• -s specifies Frank’s default shell. (Without the -s, Debian/Ubuntu would assign to Frank the /bin/sh shell.)

When you look at the...

Enforcing strong password criteria

You wouldn’t think that a benign-sounding topic such as strong password criteria would be so controversial, but it is. The conventional wisdom that you’ve undoubtedly heard for your entire computer career says:

• Make passwords of a certain minimum length.
• Make passwords that consist of a combination of uppercase letters, lowercase letters, numbers, and special characters.
• Ensure that passwords don’t contain any words that are found in the dictionary or that are based on the users’ own personal data.
• Force users to change their passwords on a regular basis.

But using your favorite search engine, you’ll see that different experts disagree on the details of these criteria. For example, you’ll see disagreements about whether passwords should be changed every 30, 60, or 90 days, disagreements about whether all four types of characters need to be in a password, and even disagreements...

Setting and enforcing password and account expiration

Something you never want is to have unused user accounts remain active. There have been incidents where an administrator set up user accounts for temporary usage, such as for a conference, and then just forgot about them after the accounts were no longer needed.

Another example would be if your company were to hire contract workers whose contract expires on a specific date. Allowing those accounts to remain active and accessible after the temporary employees leave the company would be a huge security problem. In cases like these, you want a way to ensure that temporary user accounts aren’t forgotten about when they’re no longer needed. If your employer subscribes to the conventional wisdom that users should change their passwords on a regular basis, then you’ll also want to ensure that it gets done.

Password expiration data and account expiration data are two different things. They can be set either...

Configuring default expiry data for useradd for Red Hat-type systems only

The /etc/default/useradd file has the rest of the default settings. In this case, we’ll look at the one from the AlmaLinux 9 machine:

Ubuntu also has the useradd configuration file, but it doesn’t work. No matter how you configure it, the Ubuntu version of useradd just won’t read it. So, the write-up about this file only applies to Red Hat-type systems.

# useradd defaults file
GROUP=100
HOME=/home 
INACTIVE=-1 
EXPIRE= 
SHELL=/bin/bash 
SKEL=/etc/skel 
CREATE_MAIL_SPOOL=yes

The EXPIRE= line sets the default expiration date for new user accounts. By default, there is no default expiration date. INACTIVE=-1 means that user accounts won’t be automatically locked out after the users’ passwords expire. If we set this to a positive number, then any new users will have that many days to change an expired password before the account gets locked. To change the...

Setting expiry data on a per-account basis with useradd and usermod

You might find it useful to set the default password expiry data in login.defs, but you probably won’t find it too useful to configure the useradd configuration file. Really, what are the chances that you’ll want to create all user accounts with the same account expiration date? Setting password expiry data in login.defs is more useful because you’ll just be saying that you want new passwords to expire within a certain number of days, rather than to have them all expire on a specific date.

Most likely, you’ll want to set account expiry data on a per-account basis, depending on whether you know that the accounts will no longer be needed as of a specific date. There are three ways that you can do this:

• Use useradd with the appropriate option switches to set expiry data as you create the accounts. (If you need to create a whole bunch of accounts at once with the same expiry...

Setting expiry data on a per-account basis with chage

You will only use chage to modify existing accounts, and you will use it for setting either an account expiration or a password expiration. Here are the relevant option switches:

Option	Explanation
-d	If you use the -d 0 option on someone’s account, you’ll force the user to change his or her password on their next login.
-E	This is equivalent to the lowercase -e for useradd or usermod. It sets the expiration date for the user account.
-I	This is equivalent to -f for useradd or usermod. It sets the number of days before an account with an expired password will be locked out. ...

Preventing brute-force password attacks

Amazingly enough, this is another topic that engenders a bit of controversy. I mean, nobody denies the wisdom of automatically locking out user accounts that are under attack. The controversial part concerns the number of failed login attempts that we should allow before locking the account.

Back in the stone age of computing, so long ago that I still had a full head of hair, the early Unix operating systems only allowed users to create a password with a maximum of eight lowercase letters. So in those days, it was possible for early man to brute-force someone else’s password just by sitting down at the keyboard and typing in random passwords. That’s when the philosophy started of having user accounts get locked out after only three failed login attempts. Nowadays, with strong passwords, or better yet, a strong passphrase, setting a lockout value of three failed login attempts will do three things:

• It will unnecessarily...

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 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 publicly traded companies can delete from their computers. If...

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 most of 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 folks who just keep logging in to the root account...

Setting up security banners

Something that you really, really don’t want is to have a login banner that says something to the effect of Welcome to our network. I say that because, quite a few years ago, I attended a mentored SANS course on incident handling. Our instructor told us a story about how a company took a suspected network intruder to court, only to get the case thrown out. The reason? The alleged intruder said, “Well, I saw the message that said Welcome to the network, so I thought that I really was welcome there.” Yeah, supposedly, that was enough to get the case thrown out.

A few years later, I related that story to the students in one of my Linux admin classes. One student said, “That makes no sense. We all have welcome mats at our front doors, but that doesn’t mean that burglars are welcome to come in.” I have to confess that he had a good point, and I now have to wonder about the veracity of the story.

At any rate,...

Detecting compromised passwords

Yes, dear hearts, the bad guys do have extensive dictionaries of passwords that either are commonly used or have been compromised. One of the most effective ways of brute-forcing passwords is to use these dictionaries to perform a dictionary attack. This is when the password-cracking tool reads passwords from a specified dictionary and tries each one until either the list has been exhausted or the attack is successful. So, how do you know if your password is on one of those lists? Easy. Just use one of the online services that will check your password for you. One popular site is Have I Been Pwned?, which you can see here:

Figure 3.4 -- The Have I Been Pwned site

You can get to Have I Been Pwned? here:

https://haveibeenpwned.com

All you really have to do is to type in your password, and the service will show if it’s on any lists of compromised passwords. But think about it. Do you really want to send your production...

Understanding centralized user management

In an enterprise setting, you’ll often have hundreds or thousands of users and computers that you need to manage. So, logging in to each network server or each user’s workstation to perform the procedures that we’ve just outlined would be quite unworkable. (But do bear in mind that you still need those skills.) What we need is a way to manage computers and users from one central location. Space doesn’t permit me to give the complete details about the various methods for doing this. So for now, we’ll just have to settle for a high-level overview.

Microsoft Active Directory

I’m not exactly a huge fan of either Windows or Microsoft. But when it comes to Active Directory, I’ll have to give credit where it’s due. It’s a pretty slick product that vastly simplifies the management of very large enterprise networks. And yes, it is possible to add Unix/Linux computers and their users...

Samba on Linux

Samba is a Unix/Linux daemon that can serve three purposes:

• Its primary purpose is to share directories from a Unix/Linux server with Windows workstations. The directories show up in Windows File Explorer as if they were being shared from other Windows machines.
• It can also be set up as a network print server.
• It can also be set up as a Windows domain controller.

You can install Samba version 3 on a Linux server, and set it up to act as an old-style Windows NT domain controller. It’s a rather complex procedure, and it takes a while. Once it’s done, you can join both Linux and Windows machines to the domain and use the normal Windows user management utilities to manage users and groups.

One of the Linux community’s Holy Grails was to figure out how to emulate Active Directory on a Linux server. That became something of a reality just a few years ago, with the introduction of Samba version 4. But setting it up is...

Summary

In this chapter, we looked at how to lock down users’ home directories, how to enforce strong password policies, and how to enforce account and password expiration policies. Then, we talked about a way to prevent brute-force password attacks, how to manually lock out user accounts, how to set up security banners, and how to check for compromised passwords. We wrapped things up with a brief overview of central user management systems.

In the next chapter, we’ll look at how to work with various firewall utilities. I’ll see you there.

Questions

1. In which file would you configure complex password criteria?
2. When using the useradd utility on a RHEL 7-type machine, what should the UMASK setting be in the /etc/login.defs file?
3. When using the adduser utility on an Ubuntu 20.04 machine, how would you configure the /etc/adduser.conf file so that new users’ home directories will prevent other users from accessing them?
4. What change did the National Institute for Standards and Technology recently make to its recommended password policy?
5. Which three of the following utilities can you use to set user account expiry data?
   1. Useradd
   2. Adduser
   3. Usermod
   4. chage
6. Why might you want to lock out the user account of a former employee, rather than delete it?
   1. It’s easier to lock an account than it is to delete it.
   2. It takes too long to delete an account.
   3. It’s not possible to delete a user account.
   ...

Further reading

• You might not need complex, alphanumeric passwords after all: https://www.pcmag.com/news/355496/you-might-not-need-complex-alphanumeric-passwords-after-all
• The new NIST Guidelines-We had it all wrong before: https://www.riskcontrolstrategies.com/2018/01/08/new-nist-guidelines-wrong/
• Linux user management: https://www.youtube.com/playlist?list=PL6IQ3nFZzWfpy2gISpCppFk3UQVGf_x7G
• The FreeIPA Project home page: https://www.freeipa.org/page/Main_Page
• RHEL 9 Documentation (Scroll down to the Identity Management section):
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9
• RHEL 8 Documentation (Scroll down to the Identity Management section): https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/
• RHEL 7 Documentation (Scroll down to the Identity Management section): https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
• pam_faillock: Lock user account after X...

Answers

1. /etc/security/pwquality.conf
2. 077
3. Change the DIR_MODE= value to DIR_MODE=750
4. They abandoned their old philosophy about password complexity and password expirations.
5. a, c, and d
6. d
7. a and d
8. c
9. d

Join our book community

Join our community’s Discord space for discussions with the author and other readers:

https://packt.link/CyberSec