Mastering Linux Security and Hardening: Secure your Linux server and protect it from intruders, malware attacks, and other external threats

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...

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:

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.

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

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...

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.

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...

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

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

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

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:

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...

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...

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:

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:

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...

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...

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.