1. Home
  2. Training Library
  3. Linux Security and Hardening | CSL4 A3.1 |

Controlling Account Access

Start course
3h 21m

In this section, you’ll take a deep dive into Linux security. You’ll build your knowledge and skills through a comprehensive overview of the key areas that you need to know to secure Linux systems.

You’ll begin with Linux security in general before moving on to physical security and the countermeasures you can employ to protect your hardware. From there, you’ll explore authentication systems and the various account types on a Linux system, and how to secure each one. You'll also learn how to enforce strong passwords and manage account and password expirations.

In the networking section, you'll learn how to secure network services that run on Linux systems. You'll also learn how the local firewall works in Linux and how to configure it. You’ll learn about file system security and how permissions work in detail, including special modes, file attributes, and ACLs. You'll also discover what rootkits are, how to detect them, and how to remove them.

You’ll also find several security resources you can use to continue your security education and stay on top of the latest security issues for Linux distributions.

There are several knowledge checks as you go through these resources. These will help you identify any areas that you might need or want to review. At the end you’ll find a final exam, where you can test yourself on what you’ve learnt.

Learning Objectives

  • Get a general view of Linux security including roles, network services, encryption, accounts, and multifactor authentication
  • Learn specific strategies for mitigating physical security risks and protecting your Linux systems against the most common physical attacks
  • Learn about data encryption and how to implement it on new Linux systems, as well as those that are already in service
  • Understand the different types of accounts you'll find on a Linux system and the special precautions you need to take with each account type
  • Learn how to enforce good password security practices on your Linux systems
  • Learn about multi-factor authentication and how it can be implemented in Linux
  • Learn techniques and strategies to secure network services
  • Learn how to secure your files and directories on Linux through permissions, data sharing, special modes, file attributes, ACLs, and rootkits

If you need to lock an account, you can do so by running the passwd command, followed by -l followed by the account name. To unlock the account run passwd -u followed by the account name. Another way to lock an account or make sure it's not used interactively is to set the account's shell to no login. On your screen are a couple of sample entries from etc password. The first entry is from a Sento system and the other one is from an Ubuntu system. In both cases, they are system accounts that should not be used interactively. The path to no login is different on these distributions but the concept remains the same. If you were to switch to these accounts you would get a message from the no login command that says the account is not available. You can manually edit the etc password file but the preferable way to change shells on an account is to use the chsh command. You can use the -s option to supply the path to the desired shell. To lock the Jason account on a Sento system, I would run chsh space - s space /s space /sbin/nologin space jason. You can also set the shell to some other command. Historically, the shell would have been set to /bin/false so you may see that on some older systems. I just wanted to quickly point out that if you configured your systems to authenticate against a central authentication system like LDAP or freeIPA, then when you lock an account, you can lock it everywhere. The obvious downside of using a centralized system like this is if an attacker gained access to that system they can gain access to all the other systems that use it for authentication. Let's say you want to keep users from logging into your Linux system for a period of time. One way to do this is to take advantage of the pam_nologin module. If the module is enabled in your PAM configuration when you create this /etc/nologin or /var/run/nologin file logins are disabled. You can place a message in that file that will be displayed to users when they attempt to log in. To re-enable log-ins just simply remove the /etc/nologin or /var/run/nologin file. A record is created when someone logs into the system. For example, the last command displays a list of last logged in users by looking at entries in the /var/log/wtmp file. wtmp in this case is spelled w-t-m-p Failed login attempts are recorded as well. The last B command displays failed attempts by examining the slash /var/logs/btmp file. Again, that's b-t-m-p in this case. The last log command reports the last time a user has logged in. This information is stored in /var/log/lastlog. Authentication information may be stored in various other log files as well. This actually depends on the configuration being used by the system logger. Common places to find authentication logs are in /var/log/messages, /var/log/syslog, /var/log/secure and /var/log/auth.log. Again, consult the configuration of your system logger for your distribution. Instead of manually examining authentication logs you can use an intrusion prevention system or IPS, also known as an intrusion detection and prevention system IDPS such as a fail2ban. Typically fail2ban is configured to create a firewall rule to block the IP address of an attacker who is attempting a brute force attack. If repeated failed login attempts are detected the IP address is blocked. fail2ban is usually configured to unblock a host or an IP address within a certain period of time so as to not permanently lock out a genuine connection that may have been temporarily misconfigured. fail2ban can be configured to monitor any service that writes log in attempts to a log file. fail2ban even ships with filters for popular software, such as Apache, VSFTBD, qmail and Postfix. We've talked about using multi-factor authentication before. It's typically comprised of something you know, such as a password and something you have. At the time of this recording, there are at least a few good options for multi-factor authentication for Linux systems. One solution is to install and configure the Google authenticator PAM module. When you connect via SSH, you will be prompted for the code that is being displayed on your Google authenticator device, such as your phone. Another option is provided by DuoSecurity. When you connect to a system via SSH, DuoSecurity will send a message to your phone asking if you want to allow the connection to continue. You can also configure your system to use an RSA SecurID token. Like Google authenticator it displays a series of numbers that rotate. When you connect to the system you'll be prompted for the code that is currently displayed on your device. Using multifactor authentication mechanisms such as these can really tighten up account security. These are some popular options at the time of this recording, but there are other options available and these may change over time.

About the Author