To keep the servers and PCs under your care secure, you will have to have control over the users who login both locally and remotely. You will also need to find ways to intelligently monitor the system processes themselves so you can spot strange activities and dig deeper. We're going to discuss some of the tools available to Linux SysAdmins. It's possible, by the way, that some of these tools aren't installed by default on your system, but apt-get or yum can quickly fix that. If you're not sure where to find a package, on a Debian-based system including Ubuntu, you can use apt-cache search and then the name of the program you're after. In this case, we can see the netstat is part of the net-tools package. One of the simplest things you can do to prevent unauthorized control over your servers is to limit who gets administrative rights and when.

Your first job, therefore, is to make sure that users who don't need admin rights don't get them. To protect against legitimate admin users carelessly leaving their root sessions unwatched, discourage your admin users from using root sessions via sudo su.

Instead, they should use sudo. Sudo invokes root powers, but only for that particular command. Once the command is done, the shell session returns to non-admin permissions. This makes it much less likely that some kind of account hijacking will cause all that much damage.

As we previously seen, users can use sudo to invoke root if they've been added to the sudo group in etc/group, or in some Linux distributions, to the wheel group.

Behavior of the sudo group is controlled through the etc/sudoers file, which by the way, requires sudo just to view. Note the user privilege specification line, which in my case gives full root authority to members of the sudo group. As you can see, sudoers should never be edited directly, but through the visudo command.

You can add or remove a user from the sudo group either by editing the etc/group file or by using usermod. The -a -G will add Steve to the group called sudo.

It's no secret that passwords are among the weakest links in the security chain. Most people choose short passwords that are easy to remember, and then use them over long periods of time for multiple accounts, which is exactly what makes them the easiest to guess or crack. And the more accounts people have, the more likely it is that they'll compensate with even fewer and weaker passwords.

We simple system administrators can't be expected to solve all the world's problems, but we can use Linux tools to enforce some password standards.

Although this isn't an LPIC exam requirement, you should at least be aware of packages like PAM or APG that force users to use longer and more complex passwords. What is part of the LPIC exam is chage, which stands for change age.

We've seen this in a previous video, but let's have a quick review. We'll run chage against my own user Ubuntu. We're shown the last time I changed my password, expiry settings and minimum and maximum days between password changes. Meaning that as an admin, I can force the Ubuntu user, who happens to be me in this case, to change the login password every X number of days.

You set the maximum with the uppercase M, and the number of days you'd like to force the new password; 30 in our case.

Let's review. Sudo, which invokes root powers only for a single command, is far preferred over starting a root shell using sudo su.

Sudo can be used by members of the sudo or Wheel group which is controlled by the etc/sudoers file. You use usermod to add sudo to the sudo group.

Chage can be used to force users to regularly change their passwords. Besides controlling system access, you should also regularly monitor the system itself for unusual and suspicious behavior. For the remainder of this lecture, we're going to explore some tools and techniques for doing that.

However, it's unreasonable to think that you're actually going to do all these things regularly enough to make them useful. It'd be much more realistic to include them in scripts run automatically by cron that will issue notifications of anomalies.

At any rate, here's how you can effectively monitor your servers. As we discussed way back in the Linux partitions and filesystems course, you can, if necessary, provide non-root users full access to system binaries, even to binaries that will act with root privileges through SUID and SGID.

This way, for instance, as we've explained, regular users will change their passwords using usr/bin/passwd even though passwd works by updating the etc/shadow file which belongs to root.

We can see this by looking at the passwd file in the usr/bin directory. Notice the S in the first set of permissions, signifying that the SUID bit is set. We could remove the bit using chmod -s, but then you'd need to be root in order to update your password.

As you can probably guess, chmod +s will add the SUID bit. Using the SGID bit, you can do the same thing for binary files group permissions. Now all this is very nice, I hear you saying.

But what does it have to do with system security? Good question. The point is that while SUID and SGID bits are really useful, they're are also a huge security hole, since any user can exploit them to effectively get full root access. If you want to maintain control of these permissions, you should regularly audit your system to make sure that there aren't any files that through accident or malice have been left improperly open.

You can do this using find. A slash followed by -type f tells find to search for and list files in every directory below root whose user permissions include the SUID bit.

We could run the same command using -G to search for SGID bits. Now you can look through the output to see if there's anything there that shouldn't be.

Alternatively, you can create a script that checks the output of find against the files you know should be there, and then sends an alert if there is anything new.

You should also be able to keep track of processes running on your system to make sure nothing is being used without proper authorization. PS as we've seen, will list all running processes, and grep can help you find specific entries from out of the long list. But you might need to narrow down your search based on more specific rules. Fuser, which stands for file user, will return all processes running within a specified directory. In this case, we can see all the process IDs currently running within the root hierarchy. You will want to run fuser as sudo to make sure you're accessing all system processes. For more information like the process user and the command, run fuser with the verbose argument. You can restrict your output to a specific executable like the Apache 2 Web server in this case. Or if you suspect that someone might be accessing a particular port without authorization, you can run fuser with -n specifying the TCP protocol and the HTTP port 80. In addition to netstat, which we discussed in the previous course, you can learn a great deal about the state of your network facing server using nmap. We'll run nmap against the LXC container I'm on right now.

We can see that port 22 is open for SSH, port 25 for outgoing mail, and 80 because I have the Apache Web Server installed and working.

All that is what I would've expected taking into account the various ways I've been using this container. If there is anything I didn't recognize, I would naturally want to investigate. By default, nmap looks for TCP activity. If I wanted to scan for processes using the UDP protocol, I would add -sU as an argument.

Note how UDP searches require sudo authority. It's also important to keep track of who is logged onto your system.

Since Linux is by design built for multiple users, you can have all kinds of users logged in from remote locations without you even being aware of it. You'll really want to keep an eye on login activity to make sure that there's no one sneaking in behind your back. Linux has a few very similar tools that can do this, each with a subtle angle all its own. Last will print the login times of all users since the beginning of the month.

By default, it uses data from the file var/log/wtmp. Besides the Ubuntu user and root, we can see that Steve is logged in too. W will display a list of all users logged in along with information on their current activity. Who will also print the names of logged in users. When used with -b, it will also display the time of the last system boot. Now that we know whose accounts are logged into our system, and that Steve is one of them, we might like to find out what he's been up to.

Since just about everything that happens in Linux is built on files, searching for files that are open and associated with a particular user can tell us a great deal.

Lsof which stands for list open files can do just that. A quick look through the data we get back shows that these are all normal processes associated with any normal SSH session. But if there was something funny going on, it wouldn't be too hard to spot.

Let's review. You can search for files with the SUID or SGID bit set using find. Fuser will print all processes running within a specified directory or file, or using a particular port. Netstat and nmap will both scan network addresses for open ports. Last, w and who will all display user login data. Lsof can tell us which files are currently open and who is using them.