In this chapter we’ll explore some of the common practices used to make your Linux system more secure. Fortunately for us, many knowledgeable Linux administrators have blazed a trail for us to follow to implement good security practices on our Linux systems. This chapter divides these practices into three categories: user security, system security, and network security.
While a great deal of work is spent in trying to keep unauthorized users out of Linux systems, as the Linux administrator you need to worry about the authorized users as well. The following sections discuss some techniques you can use on your Linux system to help identify authorized users, know what they are doing, and provide easier access to network resources after a user authenticates on a server.
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:
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.
Students at MIT developed the Kerberos project to support the single sign-on (SSO) concept on networks. With SSO, you only need to log into the network once to access any server on the network. There are three pieces involved with the Kerberos authentication process:
kinit
utility to store the ticket in a credentials cache, which maintains any tickets used to log into the server. To view the tickets contained in the server’s credentials cache use the klist
command.Kerberos centralizes the authentication process but still requires individual servers to maintain their own database of what objects on the server the user account has access to. That itself can become complicated when working with multiple servers on a network.
This is where the Lightweight Directory Access Protocol (LDAP) comes into play. LDAP utilizes a hierarchical tree database structure to store information about both network users and resources. Network administrators can enter permissions for various network resources into the LDAP database structure. When a user account requests access to a resource on a server, the server accesses the centralized LDAP database to determine if it should grant the user access to the resource. This provides a centralized authorization database for all of the servers in a network.
One nice feature of LDAP is that you can distribute the LDAP database among multiple servers on the network. Each server can contain either a part of the LDAP database tree or a copy of the entire tree. This can help speed up the lookup process, especially for networks that are geographically separated.
While you can use LDAP for user authentication, many network administrators implement a combination of Kerberos for authentication and LDAP for resource authorization. This utilizes the strengths of both packages. This is the model on which Microsoft’s Active Directory is built.
As its name suggests, the Remote Authentication Dial-In User Service (RADIUS) is somewhat of an old authentication technology. It was originally created to provide centralized authentication services for dial-up bulletin board servers. However, its simplicity and ease of implementation make it a popular option for modern authentication applications requiring a simple authentication approach. You’ll commonly find RADIUS authentication servers in network environments for authenticating network access, such as the IEEE 802.1x authentication protection on network switches.
The RADIUS protocol allows an authentication server to authenticate not only the user account, but also other information about the user, such as a network address, phone number, and access privileges. While not as versatile as LDAP, it can provide some basic database features for authentication to multiple devices on the network.
The Terminal Access Controller Access-Control System (TACACS) defines a family of protocols that provide remote authentication in a server environment. The original TACACS authentication protocol was popular in the early days of Unix systems.
The original TACACS protocol uses a centralized authentication server to authenticate user accounts from a single database server. Each server on a network submits the authentication request individually to the centralized server, requiring users to log into each server separately, even though there’s a common authentication database.
Cisco Systems updated the original TACACS protocol and called the update TACACS+. The TACACS+ protocol incorporates full authentication, authorization, and accounting features and also encrypts all data as it traverses the network.
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:
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.
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:
The su
and sudo
commands allow any user account to perform administrative jobs without actually logging in as the root user account. This is better as they provide a way of logging who is performing those administrative tasks. With the su
and sudo
commands, there may not even be a reason to allow the root user account to log in at all.
To prevent anyone from logging into the Linux system as the root user account, you can use a trick that involves the /etc/passwd
file. The /etc/passwd
file maintains several pieces of information about user accounts, including the shell that Linux runs when the user account logs into the system. The trick of locking out a user account is to replace the default Bash shell assigned to the root user account with the /usr/sbin/nologin
shell, like this:
root:x:0:0:root:/root:/usr/sbin/nologin
The nologin
shell doesn’t produce a usable shell; it just displays a message on the console:
$ /usr/sbin/nologin
This account is currently not available.
$
When you assign that as a user’s shell, the account can’t log into the system but just sees the output message. Setting this for the root user account prevents it from being able to log in, but the su
command will still work just fine.
For Linux systems that use a console physically attached to the system, you may want to block anyone from walking up to the system and logging in as the root user account.
To do this, create a /etc/securetty
file on the system. The /etc/securetty
file lists all of the devices the root user account is permitted to log in from. If this file is empty, the root user account will not be able to log in from any physical console, although this does not block the root user account from logging in via the network.
To block the root user account from logging in from the network, you’ll need to modify the OpenSSH program, which provides secure connections to your Linux system. You accomplish this by a setting in the OpenSSH configuration file.
The OpenSSH configuration file is located at /etc/ssh/sshd_config
. Open the file in a text editor, and look for the line
#PermitRootLogin yes
Remove the pound sign to make the setting active, and change the yes
to no
to block the root user account from logging in via SSH.
As the Linux administrator, it’s your job to ensure that the system keeps running and stays secure under all conditions. The following sections describe a few techniques that can help you with that task.
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.
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:
/dev/mapper
area.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.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.
Since the application running in the chroot jail thinks the new root directory is the real directory structure, you must copy any Linux utilities or libraries that it requires into the new root directory structure using the same paths.
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.
When you start a computer system, it uses either the Basic Input/Output System (BIOS) or the newer Unified Extensible Firmware Interface (UEFI) to control how the system boots. Access to either of these utilities can allow an attacker to redirect the system to boot from a DVD disk or other portable medium.
To restrict this, it’s always a good idea to enable the password feature in the BIOS or UEFI software. When a password is assigned, you must enter it to gain access to the BIOS or UEFI menu system to make changes.
During the boot process, when Linux starts to boot, it uses the GRUB bootloader to load the appropriate operating system image from a hard drive. The GRUB system also provides a way for you to break out of the boot process and access the GRUB menu, where you can alter where or how the Linux system boots.
To protect your Linux system from physical attack, you should also place a password on the GRUB bootloader system to prevent unauthorized users from accessing the GRUB menu. Since the GRUB configuration files are plain text, for best security you should encrypt the password value before storing it in the configuration file.
To do this on a Debian-based system, use the grub-mkpasswd-pbkdf2
utility:
$ grub-mkpasswd-pbkdf2
Enter password:
Reenter password:
PBKDF2 hash of your password is
grub.pbkdf2.sha512.10000.FE548777A9E101604D00DB
610E6BBB8E2269D4E98E17C1533C3B64EE3305B21D4F8AE089EE900668C78FCA4BE429D906ED104
9A8EF5C80A7621E5E17866DC556.250AAB4CD88CB2FB80D29D04DF3C381946A76AC9E1059B2C109
015217A63422C748A4E6E642517E15659FB69C4EAE55D953A4484C9C0D88DE37C099EAD79C27B
$
After you’ve created the encrypted password, you can add it to the password setting in the GRUB configuration file. On the Ubuntu system, the file is /etc/grub.d/40_custom
. Add the lines
set superuser "userid"
password_pbkdf2 userid password
where userid
is the user account you want to use to log into the GRUB boot menu and password
is the value provided from the grub-mkpasswd-pbkdf2
utility.
For Red Hat–based systems, the utility to generate the password is grub-md5-crypt
. The line to add to the GRUB menu file is
password --md5 password
Now when you reboot your Linux system, it will prompt you for the user account and password before allowing you to enter the GRUB menu.
The Windows operating system has used the Ctrl+Alt+Del key combination, commonly called the three-finger salute, to reboot the entire system since the early days of Windows. This action has carried over to the Linux world and is commonly supported by most Linux distributions that run on IBM-compatible hardware.
If your Linux system has a physical console that is open to others, it’s a good idea to disable the Ctrl+Alt+Del key combination from rebooting your system. How to disable the key combination depends on what startup method your Linux system uses.
For systems that use the SystV init method, the Ctrl+Alt+Del action is defined in the /etc/inittab
file:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
The key combination triggers the /sbin/shutdown
program, which initiates the shutdown of the Linux system. To prevent that, you just need to modify what program the key combination runs. For example, to just log the event, use the logger
application:
ca::ctrlaltdel:/bin/logger -p authpriv.warning -t init "Ctrl+Alt+Del
was ignored"
Now if anyone attempts the Ctrl+Alt+Del key combination, the event will just trigger an entry in the standard log file for the system and not reboot the system.
For systems that use the systemd startup method, you’ll need to disable the ctrl-alt-del.target
target using the systemctl
command:
$ sudo systemctl mask ctrl-alt-del.target
Now systemd will ignore the Ctrl+Alt+Del key combination as well.
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:
.allow
file, they are allowed to schedule a job, and no further checks are performed..allow
file, the system checks the .deny
file..deny
file, they are not allowed to schedule a job..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.
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.
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.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.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.
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.
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:
You define events to monitor by creating rules. There are three types of rules you can create:
auditd
behaviorYou 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.
Placing your Linux system on a network is like having the front door to your house open to the public. Any device on the network can attempt to access your Linux system from the network. The following sections describe some basic security measures you can take to help protect your Linux system when it’s connected to a network.
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.
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:
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:
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.
Most network applications define the default network port in their configuration file. Usually you can just edit the configuration file to change the default port and restart the application. However, make sure any clients that connect to the application also have the ability to change the port they try to connect with to access the application.
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.
This exercise demonstrates how to use LUKS to encrypt a removable USB storage device so that any data stored on the device can be read only from your Linux system.
There are many aspects to protecting a Linux system for use in today’s world. Most security practices break down into user security, system security, and network security. For user security, there are many different methods for authenticating users and authorizing them to access resources. The Kerberos package provides a centralized login system for multiple network servers. The LDAP package creates a distributed database for defining resources and users and granting users access to the network resources. The RADIUS package is a simpler authentication package that’s commonly used for network devices, such as switches and routers. The TACACS+ protocol was developed by Cisco Systems to provide more advanced network authentication processes.
System security involves securing the Linux system environment itself. One step for system security is to utilize separate partitions for the OS files and user data files. That way if an overzealous student fills up the disk space, it won’t stop the OS. Disk encryption has also become an important tool these days, especially when storing data on removable devices. Protecting applications from one another is yet another system security feature. With the chroot jail process, you can create separate filesystem areas within the main filesystem so that applications can’t trounce on each other’s files.
Network security has become a popular topic these days, and Linux provides several tools that you can use to help out. The hosts.deny
and hosts.allow
files allow you to either block specific hosts or allow only specific hosts when communicating via the network. If your Linux system contains packages for some of the legacy network tools, such as FTP, Telnet, and Finger, it’s a good idea to ensure that those software packages are disabled and users can’t run them. If you want to attempt to confuse potential attackers, you can move the default TCP or UDP ports used by standard applications to alternative port numbers. Finally, the chapter discussed using the OpenSSL package to provide SSL- and TLS-level encryption for network traffic.
Describe the different authentication methods available in Linux. For network servers, the four most popular user authentication methods are Kerberos, which uses a single sign-on method of authenticating users; LDAP, which incorporates authorization as well as authentication; RADIUS, which provides a simple authentication process; and TACACS+, which is commonly used for network devices. Linux also supports several two-factor authentication methods, including using biometric data such as fingerprints, iris scans, and facial recognition; both software and hardware tokens, which provide a digital certificate identifying the user; and PKI, which allows users to create public and private keys so they can keep their private key secret and only disclose their public key to servers.
Describe the different types of system security that you should consider on Linux systems. The separation of system data and user data is a relatively simple security feature that you can implement. By creating a separate partition for user data, you will prevent a user from filling up the entire disk space on the system and stopping the server. Using encrypted storage is useful in environments where the storage device may leave the physical area, such as in laptops or external storage devices. Restricting applications using chroot is also helpful in preventing accidental or malicious applications from gaining data used by other applications. Likewise, disabling USB storage devices is a good option for systems that require control over data leaving the server. If your Linux system is in a vulnerable physical location, it’s also a good idea to prevent unauthorized rebooting of the server by disabling the Ctrl+Alt+Del key combination along with implementing a BIOS/UEFI password as well as a GRUB boot menu password.
Explain the different methods of protecting your Linux system on the network. For protecting your Linux system on the network, you can create a hosts blacklist or whitelist. The hosts.deny
file allows you to block suspicious hosts from accessing network resources on your system. If you prefer, you can instead use the hosts.allow
file to allow only specific hosts to connect to applications on your system. It’s also a good idea to disable any unused network applications, especially those that send and receive user accounts and data in plain text, such as FTP, Telnet, and Finger. It may also help to change the default ports used by network applications to help deter attackers from finding them on your system. Finally, it’s a good idea to incorporate encryption on any network application on your Linux system. The OpenSSL package provides both SSL and TLS encryption services for any application.
Which authentication method issues tickets to users and helps with implementing the single sign-on feature in a network of servers?
Mary wants to implement two-factor authentication using fingerprint readers for her users to authenticate with the Linux system. Which method of authentication should she look into implementing?
Jaime is interested in using a distributed database method for authorizing users to access resources located on multiple network servers. Which authentication method would be best for her to use?
Fred wants to block users from logging in directly with the root user account from any console or terminal session. How can he do that?
/etc/passwd
file./usr/sbin/nologin
.Which directory should you place on a separate partition to separate user data from system data?
/usr
/home
/etc
/sbin
/bin
Sally is concerned about an application that allows guests to connect to her Linux system and access a database. What can she do to limit the application to a specific directory structure on the Linux server so it can’t access system data?
chroot
.Ted wants to provide encryption at the disk level so users don’t need to encrypt individual files as they store them. What Linux feature should he use?
chroot
auditd
Ned notices in the logs that a user account schedules a job every day at noon that uses all of the system resources. How can he prevent that user account from doing that?
chroot
for the user account.nologin
as the user’s default shell./etc/cron.deny
file./etc/hosts.deny
file./etc/motd
message telling users to not schedule large jobs.Tom sees an attacker continually attempt to break into a user account on his Linux system from a specific IP address. What can he do to quickly mitigate this issue?
nologin
shell to the user account./etc/hosts.deny
file./etc/cron.deny
file.Despite his warnings, Fred continues to see users transfer files to his Linux server using unsecure FTP. How can he stop this?
/etc/motd
file telling users to stop./etc/hosts.deny
file./etc/cron.deny
file.