Administering local security

The big part of securing a system includes understanding password protections, making sure they are properly enforced. Here are the five things we will discuss in this chapter.

  1. Securing passwords
  2. Limiting root access
  3. Auditing user access
  4. Setting login, process, and memory limits
  5. Find SUID/SGID files

1. Securing passwords

Early Linux systems stored passwords in /etc/passwd file. Nowadays, hashed passwords are stored in /etc/shadow file which is more restricted. A hashed password is created using one-way chryptographic mathematical alghoritm which takes plain text and turns it into secure ciphertext. Hashing is one-way process because you cannot take ciphertext and convert it back to plain text. Linux also adds salt to the password hashing process, making the hashed password even more secure.

However, there is something called rainbow table. A rainbow table is dictionary of plaintext passwords that are already hashed. How it works is that you enter your plaintext password, and hashed password is compared to other hashes in rainbow table. If new hashed value is found among other millions of hashed values in rainbow tables, then your hashed password is cracked and you have its plaintext value.

Knowing this, anyone who gets access to /etc/shadow file can read hashes, compare them with rainbow tables, and basically, if password is weak, it is already inside rainbow table somewhere on the Internet.

If your Linux system is still storing hashed passwords in /etc/passwd file, move them to the /etc/shadow file with pwconv utility.

How Linux knows you entered right password?

This is great question I never thought off. When you log into your Linux account and enter your plaintext password, system hashes that password, adds salt to it and makes new ciphertext. If the produced ciphertext is same as password hashes stored in /etc/shadow file, then Linux knows it is the right one. If it doesn’t find same ciphertext, it knows password is wrong.

One more important thing to mention. Let’s say we are regular user on a system, and we want to change a password for that user. If we want to change a regular user’s system password, let’s say with passwd program, then we need to edit the /etc/shadow file. But how, since we are not root, and we do not have access to it. The solution for this is SUID permission that is set on a /bin/passwd program. The SUID permission allows regular users to temporarily gain root’s permission status.

As you can see, the rws root permissions are set as SUID, again, meaning that passwd utility can be run temporarily as root user.

Resolving password problems

First thing to check is to see if the account is new, and confirm that it is properly built. It it common to create a user with useradd program, and forget to assign a password to that user. In that case, you should examine /etc/passwd and /etc/shadow files to see if user has password set. To see account records, it is recommended to use getent utiliy:

If you see “!” inside /etc/shadow file instead of hashed password, it means password was not created for this account or service.

Next step to resolve problems with passwords is to see if the account is locked. You can use passwd -S or getent to check this:

After the username, there is a character that explains status of the account. The L stands for locked, but L is also showed for accounts without password. To get around this, use getent shadow username command to see if there is hashed password stored. If the account is locked, use the usermod -U or passwd -u commands.

Third thing to check are expirations. Account expiration dates are typically set up for temporary account users (contractors, interns…). To view if the account is expired, use chage -l username command. To change expiration date, use chage -E

2. Limiting root access

Fact: account management enhances system’s security and reduces attack surface. These are the things to do in order to properly manage accounts:

  • Never allow logins to the root account
  • Allow only one user per account
  • Set expiration dates on temporary accounts
  • Remove unused accounts

Switching the user with su

Using su utility you can log into the other account. If you want to log as root user (if allowed) use su – (su dash). However, if system blocks root logins by default, you will not be able to use this command.

You can also use su to execute one command as other user, and go back to your normal account. To do that, use su -c “passwd USERNAME” and in this example, we change password for the USERNAME easily.

Doing the job as root with sudo command

As we learned, su (switch user) command is used to – switch to another user, or execute a command as another user. However, there is a command sudo which will execute command as root. Whatever you execute using sudo command, will be documented in a log file or journal. By doing this, administrator knows who did what and at what time.

The primary configuration file for sudo command is /etc/sudoers file. Inside this file, you can specify which commands can be executed as root. Here is an example how /etc/sudoers might look like:

The root ALL=(ALL) ALL seems a bit confusing, so let’s see what it means. First field tells for which user this applies to, in this case for root. So, root account can do ALL=(ALL) ALL. Well, first ALL is hostname, so root user can have superuser privileges for all hostnames, second ALL is for (USER:GROUP) in this case he can run commands as all users and groups, and third ALL is for commands, so root can run all commands. This is a format for this:

USERNAME HOSTNAME-OF-SYSTEM=(USER:GROUP) COMMANDS

Another important field in /etc/sudors file is wheel group. Groups are denoted by percent sign (%). So, in the example above, whoever is member of wheel group, he can run all commands (as user or as group), and it doesn’t matter name of host. Quick note here, if you want to add new user on the system, and assign that user to wheel group, use adduser -aG wheel arguments.

Instead of modifying /etc/sudoers file, you can create new file inside /etc/sudoers.d/ directory. Since /etc/sudoers has #includedir /etc/sudoers.d/ line, it causes system to first look at that directory and find files to be part of sudo configuration. If that directory is empy, sudo looks at /etc/sudoers configuration file.

3. Auditing User Access

Another important thing to consider when doing server hardening is audit which users are currently logged in and to know which users have already logged in the past.

One of the two commands that we will mention is who command. With who, you can view information concerning your own account and look at every current user on the system. Example of who is shown below:

With -a argument, it shows time of last system boot, dead processes, system login processes, active processes, current runlevel, last system clock change, user’s message status (+ or -), and currently logged in users.

On the other side, the w command provides few more information about.

First header line shows following information:

  • Current time
  • How long system is up
  • How many users are logged in right now
  • CPU load average for last 1,5, and 15 minutes
  • USER: account’s name
  • TTY: account’s current terminal (tty)
  • LOGIN@: When user has logged in the account
  • IDLE: How long it has been since the user interacted with the system
  • JCPU: How much CPU time account has used
  • PCPU: How much CPU time account;’s current command has used
  • WHAT: What command account is currently running

One quick note, the w command pulls these data from /var/run/utmp file and from /proc files if neccessary.

Forbid logging with /etc/nologin

Cool thing to do when you want to lock an account from logging in to the system is to create /etc/nologin file. When this file exists, users willl not be able to log into the system and if you want you can add message within file to let users read what is going on.

Display access history with last command

The last command pulls information from /var/log/wtmp file and displays list of accounts. List contains all accounts, their last login time and if they are still logged in or not.

4. Set login, process, and memory limits

As users consumes system resources, it puts huge load on the system. Great thing about limiting other users from using too much resources of the system is preventing system overload with unnecessary or vague processes running around. Cool little but versatile command is called ulimit. You can easily limit each account and specify how many resources it can use. One of the things you can do with ulimit is to restrict number of logins, processes, memory usage, maximum file size to be written, amount of CPU time used by user, and more. If you want to mess around with ulimit, use ulimit –help to view all arguments and their descriptors.

5. Locating SUID/SGID files

As I mentioned before, SUID files are set on programs instead of execute permission (rws). What it does it lets execute command as file’s owner to do certain thing on the system. If the file is owned by the root account, user becomes root while they run the program or script. It is crucial to periodically scan the system and see if there are files with SUID/SGID permissions. The easiest way is with find command:

# find / -perm /6000 -type f

As you should know, find command is a monster with huge dog’s muzzle that knows everything. The / indicates we want to search entire virtual directory system. The -perm indicates that we want to locate files based on their permissions, and 6 in /6000 tells to search for both SUID (octal code 4) and SGID (octal code 2). The slash before 6000 tells to ignore other octal codes (000) and focus just on 6 (for SUID and SGID). Finally, type f tells to look at files and their permissions and ignore any directories


That’s it from this book that I extracted, aka most important things to know. Let’s learn now about cryptography concepts, SSH, GPG and public and private keys.

Leave a Reply