CompTIA Linux+ Certification: Embracing Best Security Practices

Key Topics:
User Security
Network Security
 

Objective 2.1: Summarize the purpose and use of security best practices in a Linux environment
In this guide we'll explore some of the common practices used to make your Linux system more secure. Fortunately, many knowledgeable Linux administrators have blazed a trail for us to follow to implement good security practices on our Linux systems. This guide divides these practices into three categories: user security, system security, and network security.

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

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 might 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 on the Linux+ exam.
Students at MIT developed the Kerberos project to support the single sign-on (SSO) concept on networks. With SSO, you need to log into the network only once to access any server on the network. Three pieces are involved with the Kerberos authentication process:
Authentication server (AS): Users log into the AS to initiate the authentication process. The AS acts as the traffic cop, directing the login process through the multiple Kerberos servers involved.
Key distribution center (KDC): The AS passes the login request to the KDC, which issues the user a ticket-granting ticket (TGT) and maintains it on the server. The TGT has a timestamp and time limit for how long the ticket is valid. The KDC encrypts the ticket to make it harder to duplicate or impersonate valid tickets.
Ticket-granting service (TGS): After the KDC issues the user a ticket, the user can log into servers on the network that support the Kerberos system. When the user attempts to log into a server, that server contacts the TGS to determine if the user's ticket is valid. If the ticket is valid, the server uses the 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 the objects on the server that the user account has access to. That itself can become complicated when working with multiple servers on a network.

LDAP
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 and is the model on which Microsoft's Active Directory is built.

RADIUS
As its name suggests, the Remote Authentication Dial-In User Service (RADIUS) protocol 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. Though not as versatile as LDAP, it can provide some basic database features for authentication to multiple devices on the network.

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

Note: TACACS+. The TACACS+ protocol incorporates full authentication, authorization, and accounting features and also encrypts all data as it traverses the network.

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 their 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 scanning, 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, two token keys are used together: a private key and a public key. The private key uniquely matches its public key, and no other key will match. The user maintains control over their 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 nonrepudiation. Nonrepudiation 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.

Enforce Strong Passwords
Password-based authentication is only as good as the passwords your system users use. Good security practices mandate that user passwords should be complex and change at a regular interval. Unfortunately, on their own most users prefer to not use complex passwords, nor change them at any regular interval. Fortunately, Linux provides a few ways for you to force your system users to follow good security practices with their passwords.

The “Administering Users and Groups” guide introduced the /etc/login.defs configuration file, which defines how the system handles user passwords.

Using this file, you can define some basic security settings for passwords with the following settings:

PASS_MAX_DAYS: The number of days until a password change is required
PASS_MIN_DAYS: The number of days after a password is changed until the password may be changed again
PASS_MIN_LENGTH: The minimum number of characters required in a password
PASS_WARN_AGE: The number of days a warning is issued to the user prior to a password's expiration

These settings apply to the length and age of a password but not to the complexity level. For that, you need to use features in the pluggable authentication modules (PAM) authentication services (read “Looking at Access and Authentication Methods”).
As mentioned in this Linux guide, the PAM system provides libraries that control how the Linux system authenticates user accounts for access. Each library uses settings that customize the method and process used to authenticate users. Defining password complexity rules is one of those library settings.
The pwquality.so library defines password rules that apply to the system user accounts. By adding this library to the PAM rules, you can set additional password rules above what the standard /etc/login.defs settings define.

Note: pwquality.so library is installed by default in Red Hat–based distributions, but you must install it in Debian-based distributions. For Debian-based distributions, such as Ubuntu, install the libpam-pwquality software package.
In Red Hat–based distributions, you define the password quality settings in the /etc/pam.d/system-auth configuration file. For Debian-based distributions, you define them in the /etc/pam.d/common-password file.

In both files the quality settings are defined on this line:
password requisite pam_pwquality.so
The settings are added at the end of the line, in this format:
directive=value

TABLE: PAM password standard directives
 

You'll notice in the above table that these directives don't include any password complexity directives. The complexity setting directives work a bit differently, using a concept called credits.
With credits you define one or more types of password requirements, such as uppercase letters, lowercase letters, numbers, or special characters, and then define how many of each type the user passwords must contain (for example, one uppercase letter, two lowercase letters, and one number). This system allows passwords to be any length, as long as the mandated types and quantities are present, and in any order.


TABLE:  The PAM password complexity directives

The credit directives are somewhat odd in that you specify the values as negative numbers. For example, to specify a complexity rule that requires at least one numeric character, two lowercase characters, and one uppercase character, you'd use the rule
password requisite pwquality.so dcredit=-1 lcredit=-2
ucredit=-1

The required characters can appear anywhere in the password, and there can be more than the specified minimum present in the password value.

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.

Completely Blocking Root Access
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 because 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.

Tip: /usr/sbin/nologin utility is also handy for securing service accounts. Applications that need to continually run in background mode, such as web and database servers, need to log into the system but not to a Bash shell. Best security practices mandate that individual applications each use their own login account (called a service account) rather than log in as the root user account, thus limiting the damage that an attacker can do if an application is compromised. The best way to restrict service accounts is to assign the /usr/sbin/nologin shell as their default login shell in the /etc/passwd file.

Blocking Root Access from Specific Devices
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 an /etc/securetty file on the system. The /etc/securetty file lists all 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.

Blocking Root Access from SSH
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 this 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.

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

Separation of Data
When you install most Linux distributions, by default they create a single partition for the root of the virtual directory (read “Handling Storage”), 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 multiuser 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 multiuser 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 co-between 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.
Warning: - 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.

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.

Preventing Access to the BIOS/UEFI
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 disc 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.

Preventing Access to the GRUB Bootloader
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 plaintext, 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.

Disabling the Ctrl+Alt+Del Key Combination
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.

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 deny list and allow list 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 filenames suggest, the .allow files contain lists of user accounts allowed to schedule jobs, whereas the .deny files contain lists of user accounts prevented from scheduling jobs.

The order in which Linux checks these can get a little complicated:
If a user is found in the .allow file, they are allowed to schedule a job, and no further checks are performed.
If the user is not found in the .allow file, the system checks the .deny file.
If the user is found in the .deny file, they are not allowed to schedule a job.
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
USB devices have made life much easier for us, but 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 U.S. 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 cve.mitre.org website.
Each CVE event describes the risk involved with an event and the steps you should take as a 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 about what's going on in your Linux system, but they don't quite cover everything. Events 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.

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

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 deny list 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 (read this guide) 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 (FTP) sends user account and application data across the network in plaintext using TCP ports 21 and 22.
Telnet: The original remote terminal application also sends all user and application data across the network in plaintext using TCP port 23.
Finger: An old legacy application that provides remote lookup 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 may temporarily thwart attackers trying to exploit the application, as the application is not listening for connections on the port it normally should be. However, many advanced hackers use port scanning tools to look for applications on nonstandard ports. 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.

Using Encryption on the Network
These days it's never a good idea to send any type of data across the network in plaintext. 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 ( “Introduction to Services”).
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.


EXERCISE: Creating an Encrypted Disk
You'll get some practice creating an encrypted partition on a removable USB stick. This helps protect your data in a mobile environment. 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.

1. Log into your Linux graphical desktop.
2. Insert a blank USB storage device (or one with data you don't mind losing) into a USB port on your workstation.
3. Open the Disks application from your graphical desktop menu.
4. Select the icon for the USB storage device from the left-side list of storage devices.
5. Click the minus button under the disk partition layout on the right side of the window. Click the Delete button in the dialog box that appears (if the partition is a Linux partition and is currently mounted, you will have to unmount it first).
6. When the partition is deleted, a plus button will appear under the partition. Click the plus sign button to create a new partition.
7. Click the Next button to partition the entire USB drive.
8. In the Volume Name text box, type Test Drive.
9. In the Test section, select the radio button “Internal disk for use with Linux systems only (ext4).”
10. Under that option, select the Password Protect Volume (LUKS) check box. Click Next.
11. Enter a password for the encrypted volume, and confirm it. Don't forget the password you choose, as you'll need it to mount the new drive.
12. Click Create to start building the encrypted drive.
13. When the process completes, view the drive from your File Manager program.
14. Remove the USB drive and plug it into a non-Linux workstation. If the workstation prompts you to reformat the drive, select Cancel.
15. Plug the drive back into your Linux workstation. At the password prompt, enter the password you assigned in step 11. Linux will mount the drive and allow you to read and write to the drive.
16. If you wish to convert the USB drive back for normal use, plug it into your workstation and follow the prompts to reformat the drive.

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

Important exam questions

1. 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 that they can keep their private key secret and only disclose their public key to servers.

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

3. 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 deny list or allow list. 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 plaintext, 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.