Linux workstation security check list
Target readers
This document is intended for users who use Linux workstations to access and manage system administrators in the project infrastructure team.
If your team's system administrator is a remote engineer, you can use this document to help them ensure that their workstation meets the most basic security requirements to reduce the risk of attacks.
Even if your system administrators are not remote office workers, they may also use their laptops in the office environment to do a lot of work, or they may use their home devices to access the work environment during off-duty hours or in an emergency. In these cases, you can adjust this set of specifications to adapt to your current environment.
Limitations
However, please note that this is not a detailed "workstation reinforcement" document, but an attempt to put forward a set of basic suggestions to avoid the loss caused by some obvious security problems. When you read this document, you may feel a little paranoid or superficial. But safety is like driving on a highway. You will think that any speed slower than you is a fool, and faster than you are crazy. This guide is just a set of basic security specifications, neither detailed nor alternative to experience, vigilance and common sense.
Document Structure
Each section of this document is divided into two parts:
1. List of project requirements
2. explain the reason for doing so.
Security level
Each configuration entry provides a security level. We hope this will help you make the decision:
1. High (ESSENTIAL) This entry should be highly valued. If there is a problem, it will cause the workstation to be at a high risk. 2. In NICE, this entry helps improve the overall security of the workstation, but it may affect your work habits. You need to cultivate new work habits. 3. Low (PARANOID) This entry is reserved. We think it will greatly improve the security of the workstation, but it also requires a lot of adjustments.
Please note that these are just references. If you think this security level does not affect the security of your project, you can adjust them as appropriate.
Select the correct hardware
We do not require our administrators to use specified suppliers or specific models. Therefore, this chapter will focus on considerations when selecting a work system.
List
1. The system supports SecureBoot (high) 2. The system does not have firewire, thunderbolt, or ExpressCard interfaces (medium) 3. The system has TPM security chips (medium)
Cause
??SecureBoot
?? Despite some controversy, the SecureBoot function is still able to defend against some wks attacks (such as Rootkits and edevil Maid) without introducing other troubles. The SecureBoot function does not prevent APT attacks, but it is always better.
In addition, you can also choose to deploy an additional Anti edevil Maid, which provides more comprehensive protection measures for SecureBoot attacks, but this requires more investment and maintenance.
??Firewire, thunderbolt, and ExpressCard Interfaces
?? Firewire is a standard that allows any connected device to directly access the system memory (Baidu encyclopedia ). Thunderbolt and ExpressCard also have similar problems, although they subsequently have the ability to restrict the access to memory by thunderbolts. If your system does not have these interfaces, they are the best, but even if they do not matter, they can usually be disabled through UEFI or in the kernel.
??TPM security chip
?? The TPM (Trusted Platform Module) security chip is an encryption chip independent of the processor on the motherboard. It can provide additional system security (such as storing the full-disk encryption key ), but it is basically not used in workstation operations. In other words, the TMP security chip is just a better thing, unless you have special security requirements that need to be used to enhance security.
Environment before installation
The following are a group of suggestions before installing the operating system for the workstation.
List
1. use UEFI Boot Mode (do not use traditional BIOS) (high) 2. set the password configured for UEFI (high) 3. enable SecureBoot function (high) 4. enter the UEFI password (in progress) when starting the instance)
Cause
UEFI and SecureBoot
Although UEFI also has some disadvantages, it provides some security features not provided by BIOS, such as SecureBoot. Currently, most modern systems use UEFI by default.
Make sure that the UEFI configuration mode requires a strong password. Note that many vendors have quietly limited the length of the password, so you may need to use a short password or a long passphrases ).
Depending on the Linux release you selected, you may need or do not need to import additional security keys to start the release. Nowadays, many release versions have already cooperated with Microsoft to sign their kernel using keys recognized by most vendors, thus reducing the user's troubles.
As an additional measure, those who want to enter the boot area and try to do bad things must enter the password before they enter. This password should be different from UEFI's management password to prevent sp. If you need to shut down and start the system frequently, you can ignore this because you already need to enter the password for entering the system. You do not need to enter additional passwords.
Release Version Selection
You may choose a widely used release, such as Fedora, Ubuntu, Arch, Debian, or other releases based on them. No matter which release you choose, you should consider the following before selecting:
List
1. powerful MAC/RBAC functions (SELinux/AppArmor/GrSecurity) (high) 2. release Security Announcement (high) 3. push security patches (high) in time. 4. provide Software Package encryption verification (high) 5. fully supports UEFI and SecureBoot functions (high) 6. provides powerful local full-disk encryption support (high)
Cause
SELinux, AppArmor and GrSecurity/PaX
Mandatory Access Control (MAC) and role-based access control (RBAC) are extensions of the security mechanism of basic users and user groups in the old-fashioned POSIX system. Currently, a few releases have built-in MAC/RBAC functions (Fedora, Ubuntu) or MAC/RBAC as an optional additional item after installation (Gentoo, Arch, debian ). Obviously, we strongly recommend that you select a released version with built-in MAC/RBAC functions. However, if you have a strong willingness to use other releases, after installing the system, install MAC/RBAC.
We should resolutely avoid using Release versions that do not provide MAC/RBAC functions. Today, security measures based on users and user groups like traditional POSIX have proved to be unreliable. If you want to build a MAC/RBAC workstation, AppArmor and GrSecurity/PaX are generally considered easier than SELinux. In addition, there are few or even no Daemon Processes on the workstation, and GrSecurity/PaX's security measures to cope with high risks of running programs from users are also better than SELinux.
Release Security announcements
Most widely used releases have security bulletins for users. However, if you want to study them, you can check whether the developers have a mechanism based on the documentation to remind users about security vulnerabilities and patches. If a release lacks the corresponding security Notice mechanism, it is a very dangerous signal that the release is not mature enough to act as the master server.
Push security patches in time
Most widely used releases are capable of pushing security patches in a timely manner. However, you should always check for updates to ensure that the pushed security patches are installed in a timely manner. Avoid using "derivative version" and "community reconstruction version" because they need to wait for the native version to release corresponding security patches for pushing, which will delay the patch arrival speed to users.
It is hard to see a software package that does not use encrypted signatures, does not update metadata, or contains the release version of both. That is to say, common Release versions have long known these basic security measures (Arch, say you), so this is worth checking.
Fully supports UEFI and SecureBoot Functions
Check whether the release supports UEFI and SecureBoot. Find out whether you need to enter an additional key or whether you need to start a kernel that uses the Key signature recognized by most vendors (such as the release version that cooperates with Microsoft ). Some releases do not support UEFI/SecureBoot, but provide other security measures to prevent the startup environment from being tampered or damaged (Qubes-OS uses Anti edevil Maid, as mentioned earlier ). If a release does not support SecureBoot or prevent Boot-level attacks, check other releases.
Full Encryption
Full encryption is a requirement for data security protection. Currently, most releases support full encryption. As a substitute, systems installed on hard disks with self-encryption functions can also be used (generally implemented by using TPM security chips), which provides higher-level security and faster running speed, but it also requires higher costs.
Release Installation Guide
The installation of all release versions is different. The general guidelines are provided here:
List
1. use a complex password for full-disk encryption (LUKS) (high) 2. make sure that swap partitions are encrypted (high. make sure that the password is required to edit the Startup Program (the same password can be used with LUKS) (high) 4. set a complex root password (the same password can be used with LUKS) (high) 5. use common users as part of the Administrator group (high) 6. the user password must be a complex password and cannot be the same as the root password (high)
Cause
Full Encryption
Unless you use a hard disk with self-encryption function, it is necessary to set full encryption, which will greatly protect the integrity of user data and system files. Simple automatic mounting of cryptfs files is not enough (for Ubuntu of the old version, let's talk about you), because it does not provide protection for system binary files and swap partitions, this may contain a large amount of sensitive data. The recommended encryption method is to encrypt the LVM device, so that only one password is required during startup.
The/boot partition is usually not encrypted, because the boot program needs to start the system kernel before loading the decryption program. Some releases also support encryption of/boot partitions (such as Arch), but this may increase the complexity of system updates. Whether to encrypt the/boot partition is not the key to selecting the release version, because the kernel image does not leak private data and SecureBoot checks the encrypted signature to prevent data tampering.
Select a password
Modern Operating Systems have no restrictions on the password length, so the only restriction on your password length is your paranoia and stubbornness. If you often start the system, you may need to enter two different passwords: one for unlocking LUKS, and the other for logging in. In this case, using a long password may be less convenient. The password is about 2-3 words long and easy to enter. However, it is best to select multiple or compound words.
Below are some instances with good passwords (correct, you can use spaces ):
nature abhors roombas12 in-flight Jebediahsperdon, tengo flatulence
Below are some examples of weak passwords, which may be commonly used words in public work or in your life:
Mary had a little lambyou’re a wizard, Harryto infinity and beyond
If you want to use a non-WORD Password, make sure that the password must contain at least 10-12 characters.
Unless you worry about physical security, you can write down your password and save it in a safe place away from your desk.
Root, user password and Administrator Group
We recommend that you use the same password for the root password and LUKS (unless you share a laptop with someone else, you can allow him to unlock the hard disk, but you cannot use root to log on to your system ). If you are the only user in this notebook, the root password and LUKS password have no more advantages in terms of security. Generally, you can use the same password on UEFI management, hard disk encryption, and root account, because attackers only need to obtain any of the above passwords to fully control your machine, therefore, using different passwords on a single user's workstation has no special security advantages.
You should use another account with the same complex password to complete your daily work. This user should belong to the Administrator group (for example, wheel or other similar ones, depending on the release version you are using). You can use the sudo command to escalate permissions.
In other words, if you are the only user on the workstation, You should have two unique and complex passwords to remember:
Administrator-level application:
1. UEFI Management 2. BOOT program (GRUB) 3. Hard disk encryption (LUKS) 4. Management workstation (root User)
User-level applications:
1. master password of the user account and sudo2. Password Manager
Obviously, the above should use different passwords.
Reinforcement after installation
After installing the system, the security reinforcement depends on the release version you are using. Therefore, you cannot use this general document. However, you should be aware of the following steps:
List
1. globally disable FireWire and lightning module (high) 2. check the firewall to ensure that all incoming ports (high) are filtered. 3. ensure that the root email is forwarded to an account that you frequently view (high). 4. set automatic system update task or update reminder (high) 5. confirm that the sshd service is disabled (medium) by default. 6. set automatic lock screen (in) when idle 7. set logwatch monitoring log (in) 8. install and use rkhunter to scan and kill backdoors (in) 9. install the Intrusion Detection System (IDS) (medium)
Cause
Blacklist Module
Add the FireWire and lightning modules to the blacklist and add the following two lines to the file/etc/modprobe. d/blacklist-dma.conf:
blacklist firewire-coreblacklist thunderbolt
After restart, these modules will be disabled. You can do this even if you do not have these modules.
Root email
Generally, Root emails are only stored in the system and never been read. Make sure that you modify the/etc/aliases file and forward the Root email to a mailbox you will actually view. Otherwise, you may miss some important system notifications and reports:
# Person who should get root's mailroot: [email protected]
After editing, execute the command newaliases to test whether the forwarding is successful, because some email manufacturers refuse to receive emails from non-existent or non-routable domain names.
Firewall, sshd, and listening daemon
The default configuration of the firewall depends on the release version you are using, but most of them will allow incoming traffic from the sshd port. Unless you have any irrefutable reasons, you should filter and disable the sshd process.
systemctl disable sshd.servicesystemctl stop sshd.service
If you need to use it, it can be enabled at any time. Generally, your system should not listen to any port, except for responding to ping. This will help reduce the attack threats from 0-day.
Automatic update or notification
We recommend that you enable automatic update unless you have better reasons for not doing so. For example, if you are afraid that automatic updates will cause system crashes (this is not worrying about people and has happened before ). However, you should at least enable automatic notification of currently available updates. Most releases enable these services by default, so you do not need to do anything. For details, see the relevant documentation of the release.
You should try to pay attention to all the obvious errors (errata), even if some are not specifically marked as "Security Updates" or have corresponding CVE numbers. All bugs may become potential security problems or lead to other new problems. Unknown bugs are generally only safer than known ones.
Monitoring log
You should have a strong interest in what happens on your system. Therefore, you should install logwatch and configure it to send reports about everything happening on your system every night. This does not prevent targeted attackers, but it is a good security habit.
Note that some release systems do not automatically install the syslog service required by logwatch (because systemd will exist in their own logs), so you need to install and enable rsyslog, make sure that your/var/log is not empty before using logwatch.
Rkhunter and IDS
Installing Rkhunter and an IDS (such as aide or tripwire) doesn't matter much unless you really understand how they work and configure them correctly (for example: the database is separated from external media, operating and testing in a trusted environment, updating the hash database after executing system updates and modifications ). If you do not want to perform these steps and adjust the way they work for your workstation, these tools will only increase the trouble and do not play any security role.
We recommend that you install rkhunter and run it once every night. It is easy to learn and easy to use. Although it cannot help you block an experienced attacker, it can help you discover your own mistakes.
Backup personal workstation
Workstation backups are often ignored or arbitrarily backed up, which is not safe.
List
1. Encrypt workstation backups and store them in external storage (high)
2. Use a zero-knowledge backup tool for remote or cloud backup (medium)
Cause
Backup on fully encrypted external storage
Using an external mobile hard disk can easily copy all the backups without worrying about bandwidth and uplink speed (currently, most vendors still provide obviously asymmetric uplink/download speeds ). Needless to say, the hard disk itself needs to be encrypted (again, use LUKS), or you should use a backup tool to create an encrypted backup, such as duplicity or its GUI version deja-dup. I suggest using the latter method and using a good random password to store it in a safe and offline place. If you take your laptop for a tour, you can store your hard disk at home so that you can recover some data if you lose your laptop.
In addition to your home directory, you should also back up/etc and the/var/log directory that can be used for forensics.
The most important thing is to avoid copying the home directory to an unencrypted storage device. Even if this is the fastest COPY method between the two systems, you will definitely forget to delete it once completed, in this way, you will expose potential personal privacy and other sensitive security data to the listener. Especially when you place the storage device and the notebook in the same package.
Select the zero-knowledge backup tool for remote backup
Remote Backup is also very important. You can either ask the boss to provide the space for remote storage, or find cloud providers to provide corresponding services. You can set up a duplicity/deja-dup to back up only important files. This avoids the huge traffic (Network cache, music or download data ).
Alternatively, you can use a zero-knowledge backup tool, such as SpiderOak, which provides an excellent Linux GUI tool and many practical functions, including data synchronization between multiple systems and platforms.
Best practices
The following is a list of best practices that I think you should adopt. It is not very detailed, but tries to provide practical suggestions to help find a balance between security and ease of use.
Browser
Without a doubt, Web browsers are the most vulnerable software on your system. It is a specialized tool for downloading and executing Untrusted code and even malicious code. They also try to protect you from these dangers by using multiple mechanisms such as sandbox and code filtering, but they have been defeated many times before. You should know that using a browser is the least secure at any time.
The following methods can reduce security threats from browsers, but the effective method is to change the way you use workstation.
1: use two different browsers (high)
This is the easiest way to do this, but the security effect is also small. Not all browsers can defend against attackers from browsing your system without restriction. Sometimes they can only read the storage of local browsers and steal active sessions from other tags, capture browser input. Two browsers are used at the same time, one for access to work and high-security websites, and the other for other purposes, which can prevent attackers from stealing all Cookies. However, using both browsers consumes a lot of memory.
Firefox is used to access work and high-security websites
When using Firefox to log on to work-related sites, you must pay special attention to data such as Cookies, sessions, logon information, and key-press records. You should not use this browser to access any other website, except for a few exceptions.
You should also install the following Firefox plug-ins:
NoScript (high)
NoScript stops loading all activity content except the whitelist. If it is used as the default browser, it will be very troublesome (but it provides good security), so we recommend that you use it only on browsers that access work and high security sites.
Privacy Badger (high)
It is used to intercept extensions of advertisers and other third-party tracking providers and protect users from password tracking when Browsing webpages (ad sites and tracking extensions are often attacked, because they can quickly infect thousands of systems around the world ).
HTTPS Everywhere (high)
This plugin ensures that most websites are accessed through secure connections, even if you enter an http Link (which can avoid many attacks, such as SSL-strip ).
Certificate Patrol (medium)
This tool will issue a warning when the TLS Certificate is recently changed at the site you visit, especially when the original certificate is not nearly expired or the new certificate comes from different certification bodies. This alarm helps you prevent man-in-the-middle attacks, but there are also many false positives.
You should not use Firefox as your default browser to open the connection, because NoScript will block loading or executing most activities.
Chrome/Chromium for other
Chromium developers are ahead of Firefox in terms of enhanced security (at least for Linux), such as seccomp sandbox and user namespace in the kernel, this adds an isolation layer between your website and your system. Chromium is an upstream open-source project, while Chrome is a proprietary Binary Package built by Google (insert a paranoid reminder and don't use it to do anything you don't want Google to know ).
In addition, we recommend that you install the Privacy Badger and HTTPS Everywhere plug-ins on Chrome, and then use a theme different from Firefox to demonstrate that this is your "untrusted" browser.
Use two different browsers, one in a dedicated Virtual Machine (medium)
This is similar to the practice recommended above, except that you need to put the browser that runs everything into a dedicated virtual machine, then, a quick protocol is used to share the clipboard and forward sound events (such as Spice or RDP ). This will add an isolation layer between untrusted browsers and your work environment, allowing attackers to break through the VM isolation layer after attacking the browser to harm your system.
This is a good feasible solution, but it requires a lot of memory and a fast processor to handle the increased load. At the same time, administrators need to change their work habits.
Use virtualization technology to isolate work and game environments (low)
See the Qubes-OS project, which is committed to providing a highly secure working environment by dividing applications into fully isolated virtual machines.
Password Management Tools
List
1. use a password management tool (high) 2. use different passwords (high) on unrelated websites 3. use a password management tool that supports group sharing (medium) 4. use a separate password management tool (medium) for non-website accounts)
Cause
A well-used and unique password should be an important rule for every member of the team. Credential theft occurs all the time, whether by attacking computers, stealing website databases, remote use of websites, or other methods. Creden。 cannot be reused across sites, especially for key applications.
Password management tools in the browser
Each browser has a secure password storage mechanism, and data can be synchronized with cloud storage through encrypted data transmission. However, this mechanism has some serious defects:
1. cannot work across browsers
2. do not provide any group sharing creden
Of course, there are also some free or cheap password management tools with good support that can be used across browsers and platforms, and support group sharing (this is usually a paid service ). The specific solution can be easily found through the search engine.
Independent password management tools
Password management tools in any browser have a major drawback, that is, they are vulnerable to intruders as part of the browser. If this is uncomfortable, you should choose to use two different password management tools at the same time. One is integrated into the browser, and the other is used as an independent application. The latter is mainly used to store high-risk creden。, such as the root password, database password, and other shell account creden.
This tool is useful for sharing Super User creden。 with other members in the team (such as the server root password, ILO password, database administrator password, and boot program password ).
The following tools can help you:
1. keePassX, which improves the group sharing Function in version 2. pass, using text and PGP files, integrating git3.Django-Pstore, using GPG to share creden4 between administrators 4. hiera-Eyaml. If you have already used Puppet on your device, you can easily track your server/service credenaml by storing encrypted Hiera data.
Reinforce SSH and PGP private key security
Personal encryption keys, including SSH and PGP private keys, are the most important things on your workstation and are also the things that interest attackers most, this allows them to further attack your device or impersonate you in front of other administrators. You should take additional measures to ensure that the security of these keys is not stolen by others.
List
1. use a strong password to protect the private key (high) 2. use a mobile storage device to save the PGP master key (medium) 3. store the key used for authentication, signature, and encryption on the smart card device. configure SSH to use the PGP authentication key as the private key (medium)
Cause
It is best to protect the private key from being stolen by using a smart card to store the private key used for encryption and never leaving a backup on the workstation. Below are several vendors that support OpenPGP:
1. Kernel Concepts: If you need one, you can purchase a smart card and USB card reader that supports OpenPGP.
2. Yubikey NEO: they not only provide OpenPGP smart cards, but also provide many good functions (U2F, PIV, HOTP, etc ).
Make sure that the PGP master key is not stored on the master workstation and that it is equally important to use the sub-key. A cmk is used only when other cmks are signed and created. These operations are not frequently used. You can refer to the Debian sub-key guide to learn how to move a master key to a mobile storage device and how to create a sub-key.
Then, you should configure the gnupg proxy as the ssh proxy and use the smart card-based PGP authentication key as your ssh private key. Here we have released a detailed guide to how to use a smart card reader or Yubikey NEO to complete these steps.
If you do not want to do this, at least configure a powerful password for your PGP private key and ssh private key, which increases the difficulty for attackers to steal and use them.
Sleep or shut down, do not suspend
When the system hangs, the content in the memory is still stored on the storage chip and can be read by attackers by using a method called Cold boot attack. If you need to leave the system for a period of time, such as leaving the system for a day, you 'd better shut down or sleep instead of suspending it.
Workstation use SELinux
If you are using a release with a SELinux bundle (such as Fedora), the following suggestions can help you maximize security.
List
1. make sure SELinux (high) is forcibly enabled on your workstation 2. regular check, never blindly execute audit2allow-M (high) 3. never execute setenforce 0 (in) 4. switch your account to SELinux user staff_u (medium)
Cause
SELinux is a type of Mandatory Access Control (MAC) designed to expand core POSIX permissions ). It is very mature and powerful, and has gone a long way since its launch. However, many system administrators still repeat the old saying "close it ".
That is to say, SELinux makes little contribution to workstation security, because most of the applications you run are not restricted during running. However, it provides higher network security, because it can effectively prevent attackers from using the vulnerability service for Elevation of Privilege, so as to continue access with root permissions.
We recommend that you enable SELinux forcibly.
Never execute setenforce 0
Using the setenforce 0 command can temporarily enable SELinux to enter the license mode. Although this operation is attractive, you should never use it. In this way, SELinux of the entire system is disabled, and your goal is only to locate the error of an application or process.
To replace the setenforce 0 command, you can use semanage permissive-a [somedomain_t], so that only the required process is assumed in the license mode. First, you can run the command ausearch to locate the process that caused the error:
ausearch -ts recent -m avc
Then find the line of scontext = (content originating from SELinux), like this:
scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023
This tells you that the rejected part is gpg_pinentry_t, so you want to solve this problem by adding it to the license mode:
semange permissive -a gpg_pinentry_t
This will allow you to use the program and collect the remaining AVCs data, and then you can configure local policies with audit2allow. Once you find that there is no new AVC rejection information, you can execute the following command to remove the permission:
semanage permissive -d gpg_pinentry_t
Use workstation with SELinux role staff_r
SELinux native supports configuring roles. user accounts are prohibited or granted permissions based on roles. As an administrator, you should use the staff_r role, which will limit your access to many configuration and security-related sensitive files unless you use the sudo command.
By default, the account will be marked as unconfined_r, and most of the applications executed will not be restricted or (or rarely) restricted by SELinux. To switch the user to the staff_r role, run the following command:
usermod -Z staff_u [username]
In this case, you should log out and log on again to enable the new role. If you execute the id-Z command, you will see:
staff_u:staff_r:staff_t:s0-s0:c0.c1023
When executing sudo, remember to add an additional identifier to tell SELinux that you want to switch to the "sysadmin" role. The command is as follows:
sudo -i -r sysadm_r
At this time, you will see in the execution of the id-Z command:
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
Warning:Before performing role switching, you should use the ausearch and audit2allow commands, because some of your applications may stop working after you switch to the staff_r role. When writing this document, the following popular software will stop working if it is not adjusted to staff_r:
Chrome/ChromiumSkypeVirtualBox
To switch back to unconfined_r, you only need to execute the following command:
usermod -Z unconfined_u [username]
Log out and log on again.
Additional reading
IT security is a bottomless pit. If you want to continue exploring or understanding