The ever evolving battle between system administrators and hackers boils down to this, the proper implementation of Linux security practices. As a Linux administrator, implementing the best Linux security practices is what will keep you in your job, while as a hacker, understanding the best Linux security practices is essential for knowing how to circumvent them. Take a deeper dive and check out Secur’s article Physical Security for Linux Systems for detailed implementation instructions of many of the items discussed below.
Best Practices in Linux User Security
As much effort spent by administrators keeping unauthorized users out of Linux systems, goes in to providing access methods and systems to authorized system users. The next portion of this article covers techniques to help identify authorized users, monitoring user behaviour, and providing authenticated users with easy access to network resources .
Linux User Authentication Methods
The bedrock of the best Linux Security practices rests upon user authentication methods designed to provide identified people with system access while keeping the rest of the world out. The jumping off point for most authentication methods is the good old fashioned username /password combo, even though it has a number of limitations:
- Credential sharing: Users share their user ID and password with others.
- Password difficulty: Passwords generated by users can often be easy to guess.
- Multiple logins required: As each server has its own database of user IDs and passwords, users who log into multiple servers must present their user ID and password multiple times.
In order to overcome these limitations, utilizing the best Linux security practices involves using other authentication methods.
Kerberos
Developed at MIT, Kerberos provides single sign-on (SSO) functionality so you only need to log into the network once to access any server on the network. It centralizes the authentication process but requires individual servers to maintain their own database of what objects on the server the user account has access which in and itself gets complicated when working with multiple servers. There are three pieces in the Kerberos authentication process (Click this link to view a detailed diagram of the Kerberos process):
- Authentication server (AS): Users initiate the authentication process by logging into the AS, which directs the login process through the multiple Kerberos servers involved.
- Key distribution center (KDC): The KDC is passed the login request from the AS so that a ticket-granting ticket (TGT) can be issued to the user and maintained on the server. Each TGT has a timestamp and time limit in order to limit the duration of its validity. Additionally, the KDC encrypts TGTs to make it difficult to duplicate or impersonate valid tickets.
- Ticket-granting service (TGS): After users receives a ticket from the KDC, they can log into servers on the network supporting the Kerberos system. When a 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 used to store tickets that allow users to log into the server; view the tickets contained in the server’s credentials cache use the “klist” command.
Lightweight Directory Access Protocol and Linux
Lightweight Directory Access Protocol (LDAP) comes into play when working with multiple servers on a network; it utilizes a hierarchical tree database structure to store information about both network users and resources. LDAP can be used for user authentication but network administrators often utilize the strengths of a combination of Kerberos for authentication and LDAP for resource authorization and is actually the model upon on which Microsoft’s Active Directory is built. LDAP works as follows:
- Network administrators 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.
- You can speed up the lookup process, especially for geographically dispersed networks by distributing the LDAP database among multiple servers on the network with each server containing either:
- A part of the LDAP database tree
- A copy of the entire tree.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) was originally created to provide centralized authentication services for dial-up bulletin board servers; despite its advancing age, RADIUS’ simplicity and ease of implementation make it a popular and simple authentication approach for applications. RADIUS authentication servers are commonly used in network environments for authenticating network access IEEE 802.1x authentication protection on network switches.
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; it can provide some basic database features for authentication to multiple devices on the network.
TACACS+
Multifactor Authentication in Linux
As the threat landscape evolves so do the best Linux security practices; authenticating user accounts with user ID/passwords has been around for a long time and is riddled with problems. As a result, a number of other login methods have emerged to provide a more secure login environment.
Two-factor authentication requires a user to have two pieces of information to log into a system:
- Something you know (such as a password)
- Something they possess.
There are a few different types of possessions that two-factor authentication utilizes:
- Biometrics: Use of a user’s physical feature in the authentication process; includes features such as fingerprints, iris design, and even facial recognition.
- One-time password: Provides security as it requires access to an email account on file with the server in order to receive the additional password and use it to the login; ensures the login attempt is being performed by the person who has control over the account.
- With the one-time password setup, you log with your standard user ID and password, the server then sends an additional password to the email address or text message that’s on file for your user account.
- Public key infrastructure (PKI): In an asynchronous key system, two token keys that are used together: a users private key that sits on the users computer and the users public key that resides on the target server.
- 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.
- Tokens: Stored a digital ID as an encrypted file on a user’s computer, and is presented to the server to gain authorization to access the server. Tokens can be hardware tokens (often stored on USB devices), or they can be software tokens, files that reside on the network device.
Unique User Accounts
Another key to implementing industry standard, best Linux security practices is knowing what authorized users are doing on your system, assisting in the detection of users intentionally or accidentally damaging the system.
Non-repudiation, which is the main goal of monitoring users, means that all actions users take on a system can be tracked back to them, due to the fact that:
- Every user must log in with a unique user account (which is associated with an ID)
- All user activity gets recorded, with its associated user account ID, in the various Linux system logs
To ensure you know the correct user account to review when you see inappropriate actions tagged to a specific user account appearing in log files, you needs to enforce that:
- Users do not share their user accounts with others.
- All user accounts are unique.
Restrict the root Account
Completely Blocking root Access
When it comes to providing elevated user privileges to users, the best Linux security practice is to do it with the “su” and “sudo” commands, which allows root level privileges for any so enabled user account in order to perform administrative jobs without logging in as the root user account. This is more secure for a number of reasons:
- Minimizes the need to share root credentials.
- Provide a way of logging who is performing those administrative tasks.
When “su” and “sudo” commands are properly used, there may not even be a reason to allow the root user account to log in at all. As an additional level of security, you can prevent anyone from logging into the Linux system with the root user account, by modifying, the “/etc/passwd” file which maintains several pieces of information about user accounts, including the shell Linux runs when the user account logs into the system. You can lock out a user account by replacing the 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 result is that the nologin shell doesn’t produce a usable shell so you can’t log in; instead 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.
Blocking root Access from Specific Devices
Blocking root Access from SSH
Modify the OpenSSH program (which provides secure connections to your Linux system) in order to block the root user account from logging in from the network; this is done via the OpenSSH configuration file located at “/etc/ssh/sshd_config”. Open the file in a text editor, and look for the line (seen in the screenshot below:
#PermitRootLogin prohibit-password
“PermitRootLogin=without-password/prohibit-password” bans all interactive authentication methods, allowing only public-key, hostbased and GSSAPI authentication.
This setting specifies whether root can log in using ssh and the argument must be:
- yes: Default
- without-password/prohibit-password: If this option is set to “without/prohibit-password”, password authentication is disabled for root. Thus “without-password” allows root login only with public key authentication. This is often used with shell scripts and automated tasks.
- forced-commands-only: If this option is set to “forced-commands-only”, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root.
- no: root is not allowed to log in.
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.
Linux System Security Best Practices
There are a number of other security practices you need to implement if you hope to keep your job as a Linux administrator, a good many of them will protect your system (and your job) in the event that someone gains unauthorized access to the system or attempts to break it.
Separation of Data
When installed, in order to provide maximum flexibility in using the disk space, by default most Linux distributions create a single partition for the root of the virtual directory that consumes all of the available disk space on the system. The result is that while both the Linux system and the users have access to the entire disk, it can cause issues.
As discussed in Secur’s logging articles, Linux systems continually write data to the virtual directory. On an active Linux system, the system writes lots of data to the disk, 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, etc. 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, which can be problematic in a multi-user Linux environment.
So, if all disk space is allocated to the single partition, the same space is used system files and user files; if a users fill up the disk space, there may not be any room for the system logging. If the system logging stops, no one can log into the Linux system. So in a multi-user environment, separate the user data storage from the system storage as 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 theft/loss is a major issue for both governments and businesses and the news is filled with stories related to cyber security misadventures on a daily basis; dealing with stolen laptops, systems being compromised, and rogue applications uploading data to remote websites are now part of our standard operating procedures.
While it is a bit of a process encryption, which makes your data illegible, one method to protect your data should it become compromised. Each time you access the files, they must be decrypted and then re-encrypt the files when you’re done; while you’re using the files in their decrypted state, you’re vulnerable to an attack that can read the data. Rather than encrypting individual files, use disk encryption, which works at the kernel level, to encrypt all the files stored on the partition; as data is read from files on the encrypted disk, decryption occurs automatically, via the kernel and, as data is written to the disk, the kernel automatically encrypts its. The encryption/decryption process makes use of the “Linux Unified Key Setup (LUKS)” application uses two components to interface between the kernel and applications when working with files on a filesystem:
- dm-crypt: A module that plugs into the kernel and interfaces between a virtual mapped drive and the physical drive using the “/dev/mapper” area.
- cryptmount: This command creates the virtual mapped drive and interfaces it with the physical drive via the “dm-crypt” module, ensuring data passed to the virtual drive is encrypted before being storing on the physical drive.
Preventing Unauthorized Rebooting
As much as possible, you should not locate your server in a publicly accessible area with uncontrolled access, but regardless of that fact, you need to prevent an authorized user from rebooting the server and taking control by implementing the following three measures:
- Limit access to BIOS/UEFI
- Computers use either the Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) to control how the system boots upon start.
- Accessing these utilities allows redirection of a system to boot from another source
- 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
- When Linux starts, it uses the GRUB bootloader to load the relevant operating system image from a hard drive during the boot process.
- 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 prevent this, use a encrypted password GRUB configuration files are plain text) on the GRUB bootloader system to prevent unauthorized users from accessing the GRUB menu.
- The screenshot below shows how to accomplish this on a Debian-based system, using the “grub-mkpasswd-pbkdf2” utility.
- Then add the generated hash to the password setting in the GRUB configuration file “/etc/grub.d/40_custom“. Add the lines:
set superuser “userid”
password_pbkdf2 <userid> <password>
- userid: the user account to use to log into the GRUB boot menu
- 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 Linux system will prompt you for the user account and password before allowing you to enter the GRUB menu.
Disabling the Ctrl+Alt+Del Key Combination
SystV init method: the “Ctrl+Alt+Del” key combination triggers the /sbin/shutdown program, which shuts down the system. The “Ctrl+Alt+Del” action is defined in the “/etc/inittab” file with the following line:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
To prevent shut down, modify the program the key combination runs to 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.
systemd startup method: Disable the “ctrl-alt- del.target” target using the systemctl command and your system will ignore the Ctrl+Alt+Del key combination:
$ sudo systemctl mask ctrl-alt-del.target
Restricting Applications
Linux systems with multiple users and multiple applications can run into situations where one application tries to access data associated with another application and problems can cascade across the system. Using a “chroot” jail is a way of protecting applications from one another by running a command in a new root directory structure, within the standard Linux virtual filesystem so that all disk access performed by the executed command is restricted to the new root directory structure.
- You can create a chroot jail anywhere within the Linux virtual filesystem.
- As the application running in chroot jail sees the new root directory as the real directory structure, copy any Linux utilities or libraries required to execute the application into the new root directory using the same path structure.
Use the following syntax for the “chroot” utility is:
chroot <starting_directory> <command>
starting_directory: specifies the location to start the new root directory structure.
command: Defines the command to run within the new structure; as it runs, the command references files and directories relative to the new root directory structure rather than the system root directory structure.
Restricting Unapproved Jobs
Scheduling utilities like “at” and “cron” schedule jobs when administrators are not logged into the system and in some situations, these utilities present a security issue. These utilities use the files listed below to blacklist and whitelist files for to denying or allowing accounts to schedule jobs :
- /etc/at.allow
- /etc/at.deny
- /etc/cron.allow
- /etc/cron.deny
.allow: contain lists of user accounts allowed to schedule jobs,
.deny: contain lists of user accounts prevented from scheduling jobs.
The order in which Linux checks these can get a little complicated but remember that by default, if both the .allow and .deny files are empty/don’t exist, all user
accounts are allowed to schedule jobs on the Linux system.
- If an account is found in the .allow file, it allowed to schedule a job, and no further checks are performed.
- If an account is not found in the .allow file, the system checks the .deny file.
- If an account is found in the .deny file, they are not allowed to schedule a job.
- If the account is not found in the .deny file, they are allowed to schedule a job.
Banners and Messages
Linux provides two ways for you to present messages to system users as they log into the system
- /etc/login.warn: Displays the contents of “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: Displays the contents of the “motd” (message of the day) file immediately after the user logs into the console/terminal session.
- Used for informational messages, such as if there are hardware failures on the system or scheduled downtime coming up.
Restricting USB Storage Devices From Linux Systems
The plug-ability of portable storage devices, like a USB drive, and their ability to copy files are troublesome for administrators when it comes to protecting system data. In order to provide a high level of data protection and security, administrators should prevent users from plugging in USB storage devices to copy data. by utilizing the “modprobe” utility works.
Under regular circumstances, when USB storage device gets plugged, the kernel looks for a module to support the device and if none are installed, the “modprobe” utility is called to automatically load the appropriate kernel module using configuration files in the “/etc/modprobe.d” directory to define it operation and where it looks for module files.
Also in the “modprobe.d” directory is the “blacklist.conf” file that lists modules blocked from loading into the kernel. So a workaround to prevent USB devices from accessing the system is to block the loading of the modules required to interface with USB storage devices, uas and usb_ storage. This is accomplished by modifying the “blacklist.conf” text file by adding 2 lines (then saving and rebooting the system):
blacklist uas
blacklist usb_storage
The system now ignore the kernel request to load the module necessary to interface with the device when user plugs in a USB storage device; it still allows other types of USB devices, such as keyboards and mice, to operate normally
Tracking Viruses, Malware and Other Vulnerabilities
As a Linux administrator, you will rely on the Common Vulnerabilities and Exposures (CVE) database in order to keep up to date on information system security alerts; each CVE event describes the risk involved with an event and the steps you should take as the Linux administrator to mitigate the risk.
Auditing
Standard Linux system logs don’t quite cover everything as there are events that 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 the extra logging capabilities provided by the “auditd” package; it allows the definition of a 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 the three types of rules by either :
- Modifying “/etc/audit/audit.rules” file. Rules modified in the audit.rules file are persistent.
- By using the “auditctl” utility to modify them in real time. Rules defined using the auditctl utility are valid only until the system reboots.
There are three types of rules administrators 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
Linux Network Security Best Practices
The next section of our article highlights some steps you can take to implement network security best practices in a Linux environment. If you want to take a deeper dive, check out Secur’s article Physical Security for Linux Systems for detailed instructions on how to implement many of the items discussed here.
Use the Deny Hosts File
The “deny hosts” file is the starting point for Linux network security and is the most basic network security feature you can implement via modification of the “/etc/hosts.deny” file; it creates a blacklist of hosts not allowed to connect to network resources on your Linux system.
The TCP Wrappers program reads the “hosts.deny” file (as well as the “hosts.allow” file) and blocks attempts from those hosts (listed hosts by name or IP address ) to access your system. You can go next level with network security and use the “/etc/hosts.allow” file; only hosts found in the file can access to network resources on the Linux system. If both files are empty/missing, all hosts are allowed to access the network resources on the system.
Disable Unused Network Services
Many older network applications, some of which are still used by default, use insecure methods of data transferring user data as well as application data, including:
- Finger: Provides remote look-up services to find users on a Linux system; runs on TCP port 79.
- FTP: Sends account/application data across the network in plain text. runs on TCP ports 21 and 22.
- Mail services: The most common Linux email packages are sendmail and Postfix, running on TCP port 25 to receive email messages from remote hosts.
- Telnet: Sends all user and application data across the network in plain text using TCP port 23.
Modify Default Linux Network Ports
For applications to communicate over a network, it needs a network port, a unique number assigned to the application; when remote clients communicate with the server, the server uses these port numbers to know which application to send the connection to. There are three categories of network ports:
- Well-known ports: Ports between 0 and 1023 have been formally assigned to specific (and popular) applications by the Internet Assigned Numbers Authority (IANA).
- These ports are listed in the /etc/ services file on the Linux system.
- 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.
Some Linux administrators move applications that normally use a well-known port to a private port as an additional level of security in order to throw off attackers trying to exploit that particular application, as the application is not listening for connections on the port it normally should be.
When you make this move, ensure 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.
Encrypt Network Traffic
The Secure Sockets Layer (SSL) protocol and Transport Layer Security (TLS) protocol encrypts data as it traverses the network via the OpenSSL package, a library that provides the framework required to send and receive encrypted data on the network. SSL and TSL uses PKI and requires the use of certificates that are used to encrypt/authenticate network traffic.
Summary of the Best Linux Security Practices
Cybersecurity is a multifaceted discipline that is evolving every day, how ever there are some standard security practices that will make you life easier
- User security practices: 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 file- system so that applications can’t trounce on each other’s files.
- Network security.
- The hosts.deny and hosts.allow files allow you to either block specific hosts or allow only specific hosts when communicating via the net- work.
- 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.
