Authentication Methods

The standard user ID/password combination has been used for decades in server environments. However, there are limitations to the user ID/password authentication method:

• Users can share their user ID and password with others.
• Passwords generated by users can often be easy to guess.
• Each server has its own database of user IDs and passwords. Users who need to log into multiple servers must present their user ID and password multiple times.

Because of some of these limitations, Linux administrators have been using other authentication methods. We’ll examine those you’ll come across in the Linux+ exam.

Multifactor Authentication

The user ID/password method of authenticating user accounts has been around for a long time and is ripe with problems. There’s nothing to prevent a user from sharing his or her user ID and password with others, allowing them to log into the system and perform actions.

Over the years other login methods have been developed to help provide a more secure login environment. The idea of two-factor authentication requires a user to have two pieces of information to log into a system: something they know (such as a password) and something they possess. There are a few different types of possessions that two-factor authentication utilizes:

• Biometrics: The most basic form of two-factor authentication is biometrics. Biometrics uses a physical feature that you have to authenticate you. This includes features such as fingerprints, iris design, and even facial recognition.
• Tokens: Digital tokens store a digital ID as an encrypted file. You must present the file to the server to gain authorization to access the server. Tokens can be hardware tokens, which are often stored on USB devices, such as thumb drives, or they can be software tokens, files that reside on the network device.
• Public key infrastructure (PKI): PKI adds a level of complexity and security to tokens by incorporating an asynchronous key environment. In an asynchronous key system, there are two token keys that are used together: a private key and a public key. The private key uniquely matches its public key, no other key will match. The user maintains control over his private key but can share the public key with any server that requires it for login. The user then presents the private key to the server for login. The server matches the private key presented to the public key stored on the server.
• One-time password: With the one-time password setup, you log into a server using your standard user ID and password, but then the server sends an additional password to the email address or text message that’s on file for your user account. You must have access to that account to receive the additional password and apply it to the login. This ensures that the login attempt is being performed by the person who has control over the account.

Unique User Accounts

The key to any type of security plan is to know what your authorized users are doing. This helps in detecting rogue users purposely doing harm to the system, and it can help in detecting novice users who accidentally do wrong things.

The main goal of monitoring users is non-repudiation. Non-repudiation means that every action a user takes can be tracked back to that exact user. So that every action on the system can be attributed to a specific user, every user must log in with a unique user account. The various Linux system logs will track the actions that user account takes and when they’re taken.

Don’t allow users to share their user accounts with others, and under no circumstances should you assign the same user account to more than one person. This ensures that you know what user to question when you see inappropriate actions tagged to a specific user account appear in the system log files. That may not end the problem, but at least it gives you a starting point in troubleshooting the issue.

Restricting the root Account

The root user account is important in that it has complete privileges over all aspects of the Linux system. It’s imperative that you protect who can use the root user account and where they can use it from.

There are several security best practices for helping restrict just how the root user account is used on your Linux system. The following sections discuss some basic security ideas you should think about:

root:x:0:0:root:/root:/usr/sbin/nologin

$ /usr/sbin/nologin
This account is currently not available.
$

#PermitRootLogin yes

Separation of Data

When you install most Linux distributions, by default they create a single partition for the root of the virtual directory (see Chapter 11), using all of the available disk space on the system. Creating just a single partition on the entire disk provides for maximum flexibility in using the disk space; both the Linux system and the users have access to the entire disk. However, this can cause issues.

The Linux system continually writes data to the virtual directory. The kernel logs each kernel event to a log file. As each user logs into the system, that event is logged to a log file. On an active Linux system, the system writes lots of data to the disk.

But with all that logging there’s a catch. If the Linux system attempts to write to the disk but there’s no room in the virtual directory filesystem to store any more data, the system halts. This can be a crucial problem in a multi-user Linux system.

If all disk space is allocated to the single partition, the same disk space is used to manage system files and user files. If a user decides to store their entire music library onto the Linux system, that may fill up the disk space and not leave any room for the system logging. If the system logging stops, no one can log into the Linux system!

In a multi-user environment, it’s always a good practice to separate the user data storage from the system storage. When you use two separate partitions, if users fill up their storage partition, the system can still operate in its own storage partition.

The most common way to do this is to create two partitions on the disk and then assign one to the root (/) folder and the other to the /home directory in the virtual directory.

Disk Encryption

Data finding its way into the wrong hands has become a major issue in today’s world. There are plenty of stories of important data being compromised from stolen laptops, systems being compromised, and rogue applications uploading data to remote websites.

One method to help protect your data is to encrypt it, which makes the data significantly harder for an attacker to use should it become compromised.

However, encrypting individual files is somewhat of a hassle. You need to decrypt the files each time you need to access the data in them and then re-encrypt the files when you’re done. Also, while you’re using the files in their decrypted state, you’re vulnerable to an attack that can read the data.

Instead of encrypting individual files, the solution is to use disk encryption. Disk encryption works at the kernel level and encrypts every file that’s stored on the disk partition. You don’t need to do anything special from your applications. As you read data from files on the encrypted disk, the kernel automatically decrypts it, and as you write data to files on the encrypted disk, the kernel automatically encrypts them.

The Linux Unified Key Setup (LUKS) application acts as the middleman when working with files on a filesystem. It uses two components to interface between the kernel and applications:

• dm-crypt: This module plugs into the kernel and provides the interface between a virtual mapped drive and the actual physical drive. It does this using the /dev/mapper area.
• cryptmount: The cryptmount command creates the virtual mapped drive and interfaces it with the physical drive via the dm-crypt module. This ensures that all data passed to the virtual drive is encrypted before being stored on the physical drive.

Restricting Applications

Much like a busy freeway, if your Linux system supports multiple users running multiple applications, sometimes collisions can occur. A rogue application can attempt to access data intended for another application (either by accident or on purpose), causing problems for the other applications.

One method of protecting applications from each other is incorporating a chroot jail. The chroot utility runs a command in a new root directory structure, within the standard Linux virtual filesystem. All disk access performed by the command is restricted to the new root directory structure.

The format of the chroot utility is

chroot starting_directory command

The first parameter specifies the location to start the new root directory structure. The second parameter defines the command to run within the new structure. As the command runs, it references files and directories relative to the new root directory structure, not the system root directory structure. You can create a chroot jail in any location within the virtual filesystem on the Linux system.

Preventing Unauthorized Rebooting

If your Linux server is located in a publicly accessible area, you may need to take precautions to prevent an attacker from rebooting the server and taking control. There are three common practices that you can follow to prevent that.

$ grub-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is
grub.pbkdf2.sha512.10000.FE548777A9E101604D00DB
610E6BBB8E2269D4E98E17C1533C3B64EE3305B21D4F8AE089EE900668C78FCA4BE429D906ED104
9A8EF5C80A7621E5E17866DC556.250AAB4CD88CB2FB80D29D04DF3C381946A76AC9E1059B2C109
015217A63422C748A4E6E642517E15659FB69C4EAE55D953A4484C9C0D88DE37C099EAD79C27B
$

set superuser "userid"
password_pbkdf2 userid password

password --md5 password

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

ca::ctrlaltdel:/bin/logger -p authpriv.warning -t init "Ctrl+Alt+Del
was ignored"

$ sudo systemctl mask ctrl-alt-del.target

Restricting Unapproved Jobs

The at and cron utilities allow users to schedule jobs when they’re not logged into the system. In some environments, that may be a security issue and needs to be prevented.

Both the at and cron utilities provide blacklist and whitelist files for either denying or allowing user accounts to schedule jobs. These files are as follows:

• /etc/at.allow
• /etc/at.deny
• /etc/cron.allow
• /etc/cron.deny

As the file names suggest, the .allow files contain lists of user accounts allowed to schedule jobs, while the .deny files contain lists of user accounts prevented from scheduling jobs. The order in which Linux checks these can get a little complicated:

1. If a user is found in the .allow file, they are allowed to schedule a job, and no further checks are performed.
2. If the user is not found in the .allow file, the system checks the .deny file.
3. If the user is found in the .deny file, they are not allowed to schedule a job.
4. If the user is not found in the .deny file, they are allowed to schedule a job.

So by default, if both the .allow and .deny files are empty or don’t exist, all user accounts are allowed to schedule jobs on the Linux system.

Banners and Messages

Providing information to users is yet another vital job of the Linux system administrator. Linux provides two ways for you to present canned messages to your system users as they log into the system.

• /etc/login.warn: The system displays the contents of the login.warn file before the login prompt at console logins. This is often used to display legal disclaimers and warnings to attackers on your system.
• /etc/motd: The system displays the contents of the motd file (short for message of the day) immediately after the user logs into the console or terminal session. This is often used for informational messages, such as if there are any hardware failures on the system or any scheduled downtime coming up.

Restricting USB Devices

While USB devices have made life much easier for us, they’ve also created some security concerns. The ability to easily plug in a portable storage device and copy files can be a nightmare for administrators responsible for protecting the data on the system.

For systems that require a high level of data protection, it’s a good idea to prevent users from plugging in USB storage devices to copy data. While there’s no one command to help with that task, you can implement a workaround by exploiting how the modprobe utility works.

When a user plugs in a USB storage device, the kernel automatically looks for a module to support the device. If none is installed, it calls the modprobe utility to automatically load the appropriate kernel module to support the device. The modprobe utility uses configuration files to define how it operates and where it looks for module files. The configuration file is stored in the /etc/modprobe.d directory.

Besides the configuration file, within the modprobe.d directory is also the blacklist.conf file. The blacklist.conf file defines modules that are blocked from loading into the kernel. So one workaround is to block the module required to interface with USB storage devices from loading.

When you install a USB storage device, the kernel loads two modules: uas and usb_storage. To prevent that from happening, open the blacklist.conf text file and add these lines:

blacklist uas
blacklist usb_storage

Save the file and then reboot the Linux system. Now if a user plugs in a USB storage device, the system should ignore the kernel request to load the module necessary to interface with the device. However, it will still allow other types of USB devices, such as keyboards and mice, to operate just fine.

Looking for Trouble

With all the viruses, malware, and spyware floating around the Internet, these days it’s hard to keep track of what applications can cause problems on your system. While it’s true that fewer viruses have been written for Linux systems compared to Windows systems, they still exist, and you still must be vigilant to protect your system.

As a Linux administrator, it’s your job to keep up-to-date on what attacks can be made against your Linux system. The US Department of Homeland Security has contracted with the MITRE Corporation, a nonprofit organization, to publicly publish information system security alerts, called Common Vulnerabilities and Exposures (CVE).

MITRE maintains a database of published CVE events and assigns each entry with a unique CVE Identifier. You can view the current CVE events posted on the https://cve.mitre.org website.

Each CVE event describes the risk involved with an event and the steps you should take as the Linux administrator to mitigate the risk. It’s important to monitor the CVE database for new attacks against Linux systems.

Auditing

The standard system logs available on your Linux system provide a wealth of information on what’s going on in your Linux system, but they don’t quite cover everything. There are events that occur that aren’t logged, such as when standard user accounts access files they shouldn’t or outside attackers probe your system from the network.

Tracking this type of information requires a more robust security auditing system above the standard rsyslog log events. The auditd package provides this extra level of logging for us.

The auditd package allows you to define your own set of security rules to monitor and log lots of different types of system events, such as the following events:

• File and directory access by users
• System calls made by applications
• Specific commands run by users
• Network access by users
• Network connection attempts made by external hosts

You define events to monitor by creating rules. There are three types of rules you can create:

• System rules: Log system calls made by applications
• File system rules: Log access to files and directories
• Control rules: Rules that modify the auditd behavior

You can define the rules either in the /etc/audit/audit.rules file or on the fly by using the auditctl utility. Rules defined using the auditctl utility are valid only until the system reboots. Rules added to the audit.rules file are persistent.

Denying Hosts

The most basic network security feature you can implement is to use the /etc/hosts.deny file. The /etc/hosts.deny file creates a blacklist of hosts you don’t want to allow to connect to network resources on your Linux system. The TCP Wrappers program on the Linux system (discussed in Chapter 16) reads the hosts.deny file and blocks any attempts from those hosts to access your system. You can list hosts by name or IP address in the hosts.deny file.

If you want to take a more extreme approach to network security, you can use the /etc/hosts.allow file. As you can probably guess, when the hosts.allow file exists, only hosts found in it are allowed access to network resources on the Linux system. The TCP Wrappers application handles the hosts.allow and hosts.deny files in the same way the at.allow and at.deny files work. If both files are empty or missing, all hosts are allowed to access the network resources on the system.

Disabling Unused Services

There are many legacy network applications that have still hung around on Linux systems. Unfortunately, many of those legacy network applications use unsecure methods of transferring user data as well as application data. Also unfortunately, many Linux distributions may still activate these legacy network applications by default, providing a backdoor to your Linux system that you may not even know exists.

Some of the more common legacy network services that may still be operational are listed here:

• FTP: The original File Transfer Protocol, sends user account and application data across the network in plain text using TCP ports 21 and 22.
• Telnet: The original remote terminal application, also sends all user and application data across the network in plain text using TCP port 23.
• Finger: An old legacy application that provides remote look-up services to find users on a Linux system. This utility has been compromised and is not typically installed anymore, but you can look for it on TCP port 79.
• Mail services: If your Linux system doesn’t need to send and receive email, it’s a good idea to uninstall any mail applications that may be installed and silently running in the background. The two most common Linux email packages are sendmail and Postfix. Both use TCP port 25 to receive email messages from remote hosts.

Changing Default Ports

For an application to communicate on the network, it must use a network port. The port is a unique number assigned to the application so that when a remote client communicates with the server, the server knows which application to send the connection to.

There are three categories of network ports:

• Well-known ports: Ports between 0 and 1023 that have been formally assigned to specific applications by the Internet Assigned Numbers Authority (IANA)
• Registered ports: Ports between 1024 and 49151, which are registered with IANA but not officially assigned
• Private ports: Ports greater than 49151, which can be used by any application

Most of the popular network applications have been allocated well-known ports by IANA and are expected to be using those ports. These ports are listed in the /etc/ services file on the Linux system.

As an additional level of security, some Linux administrators prefer to move applications that normally use a well-known port to a private port. This throws off attackers trying to exploit the application, as the application is not listening for connections on the port it normally should be. However, if you do move an application to a private port, you must ensure that any clients intending to use the application know that the assigned port has been changed.

Using Encryption on the Network

These days it’s never a good idea to send any type of data across the network in plain text. Instead of using the legacy FTP application to transfer data and telnet to use a remote terminal, these tasks can be done using newer applications that employ encryption.

The Secure Sockets Layer (SSL) protocol, along with the newer Transport Layer Security (TLS) protocol, is commonly used to encrypt data as it traverses the network. To implement these protocols on a Linux system, you’ll need to install the OpenSSL package (discussed in Chapter 2).

The OpenSSL package doesn’t provide the actual network applications but is a library that provides the framework required to send and receive encrypted data on the network. Both SSL and TSL require the use of certificates that are used to encrypt the data. They use PKI, which requires a private key for the server and a public key that can be sent to individual clients to authenticate and encrypt the network traffic.