Chapter 2. Securing 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 and that users can't perform any tasks that don't fit their job description. It's a tall order, but we aim to show that it's doable.

In this chapter, we'll cover the following topics:

• The dangers of logging in as the root user
• The advantages of using sudo
• How to set up sudo privileges for full administrative users and for users with only certain delegated privileges
• Advanced tips and tricks to use sudo
• 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

The dangers of logging in as the root user

A huge advantage that Unix and Linux operating systems have over Windows is that Unix and Linux do a much better job of keeping privileged administrative accounts separated from normal user accounts. Indeed, one reason that older versions of Windows were so susceptible to security issues, such as drive-by virus infections, was the common practice of setting up user accounts with administrative privileges, without having the protection of the User Access Control that's in newer versions of Windows. (Even with User Access Control, Windows systems still do get infected, just not quite as often.)  With Unix and Linux, it's a lot harder to infect a properly configured system.

You likely already know that the all-powerful administrator account on a Unix or Linux system is the root account. If you're logged in as the root user, you can do anything you want to do to that system. So you may think, "Yeah, that's handy, so that's what I'll do." However, always...

The advantages of using sudo

Used properly, the sudo utility can greatly enhance the security of your systems, and it can make an administrator's job much easier. With sudo, you can do the following:

• Assign certain users full administrative privileges, while assigning other users only the privileges they need to perform tasks that are directly related to their respective jobs.
• Allow users to perform administrative tasks by entering their own normal user passwords so that you don't have to distribute the root password to everybody and his brother.
• Make it harder for intruders to break into your systems. If you implement sudo and disable the root user account, would-be intruders won't know which account to attack because they won't know which one has admin privileges.
• Create sudo policies that you can deploy across an entire enterprise network even if that network has a mix of Unix, BSD, and Linux machines.
• Improve your auditing capabilities because you'll be able to see what users are doing with...

Setting up sudo privileges for full administrative users

Before we look at how to limit what users can do, let's first look at how to allow a user to do everything, including logging into the root command prompt. There are a couple of methods for doing that.

Method 1 – adding users to a predefined admin group

The first method, which is the simplest, is to add users to a predefined administrators group and then, if it hasn't already been done, to configure the sudo policy to allow that group to do its job. It's simple enough to do except that different Linux distro families use different admin groups. 

On Unix, BSD, and most Linux systems, you would add users to the wheel group. (Members of the Red Hat family, including CentOS, fall into this category.) When I do the groups command on my CentOS machine, I get this:

[donnie@localhost ~]$ groups
donnie wheel
[donnie@localhost ~]$

This shows that I'm a member of the wheel group. By doing sudo visudo, I'll open the sudo policy file. Scrolling down...

Setting up sudo for users with only certain delegated privileges

A basic tenet of IT security philosophy is to give network users enough privileges so that they can get their jobs done, but no privileges beyond that. So, you'll want as few people as possible to have full sudo privileges. (If you have the root user account enabled, you'll want even fewer people to know the root password.) You'll also want a way to delegate privileges to people according to what their specific jobs are. Backup admins will need to be able to perform backup tasks, help desk personnel will need to perform user management tasks, and so on. With sudo, you can delegate these privileges and disallow users from doing any other administrative jobs that don't fit their job description.

The best way to explain this is to have you open visudo on your CentOS virtual machine. So, go ahead and start the CentOS VM and enter the following command:

sudo visudo

Unlike Ubuntu, CentOS has a fully commented and well-documented sudoers...

Advanced tips and tricks for using sudo

Now that we've looked at the basics of setting up a good sudo configuration, we're confronted with a bit of a paradox. That is, even though sudo is a security tool, certain things that you can do with it can make your system even more insecure than it was. Let's see how to avoid that.

The sudo timer

By default, the sudo timer is set for 5 minutes. This means that once a user performs one sudo command and enters a password, he or she can perform another sudo command within 5 minutes without having to enter the password again. Although this is obviously handy, it can also be problematic if users were to walk away from their desks with a command terminal still open. If the 5 minute timer hasn't yet expired, someone else could come along and perform some root-level task. If your security needs require it, you can easily disable this timer by adding a line to the Defaults section of the sudoers file. This way, users will have to enter their passwords every...

Locking down users' home directories the Red Hat or CentOS 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. A security administrator who oversees a mixed environment of different Linux distros will need to take this into account.

One beautiful thing about Red Hat Enterprise Linux and all of its offspring, such as CentOS, is that they have better out-of-the-box security than any other Linux distro. 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------. 2 donnie donnie 79 Sep 27 00:24 donnie
drwx------. 2 frank frank...

Locking down users' home directories the Debian/Ubuntu way

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

• useradd on Debian/Ubuntu

• adduser on Debian/Ubuntu

useradd on Debian/Ubuntu

The useradd utility is there, but Debian and Ubuntu don't come with the handy preconfigured defaults as Red Hat and CentOS do. If you were to just do sudo useradd frank on a default 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 would look something like:

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

In this command:

• -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 home directories, you'll see that they're wide open, with execute and read privileges for everybody:

donnie@packt:/home$ ls -l
total 8
drwxr-xr...

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 on what the minimum length of a password should be.

The most interesting controversy of...

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 separately or together. When someone...

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 frustrate users
• It will cause extra...

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 us look at the following example:

• 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

In regard to the last point, you may be asking yourself, "Why can't we just delete the accounts of people who are no 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...

Setting up security banners

Something that you really, really don't want is to have a login banner that says something to the effect, "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 the 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, just to be on the safe side, you do want to set up login...

Summary

We covered a lot of ground in this chapter, and hopefully you found some suggestions that you can actually use. We started out with showing you the dangers of always logging in as the root user and how you should use sudo, instead. In addition to showing you the basics of sudo usage, we also looked at some good sudo tips and tricks. We moved on to user management, by looking 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 lockout user accounts, and set up security banners.

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