Security Handbook/Pre-installation concerns
As threats grow, so does the need for security. System security should be considered important for every system administrator. A good security model consists of layers of controls; this is also referred to as defense-in-depth. After breaching one layer of security, another layer should be behind it posing as an additional barrier to a bad actor. Generally speaking, more layers of security offer more protection for the asset that is being protected.
Location and accessibility play major roles in physical security; it can can be considered one layer of the proverbial onion.
Many non-physical controls can be easily circumvented by an attacker with physical access to a system. Despite this, there are at measures that provide a degree of security against an attacker with physical access.
Putting the hardware in a locked closet prevents an attacker from simply unplugging a system and carting it off. Locking the computer's case is also a good idea. With enough time and effort, it is certainly possible for a bad actor to circumvent a locking mechanism, however a lock helps to ensure an attacker cannot quickly and easily walk away with a disk drive.
To prevent an attacker from booting from another disk, which will easily circumvent any controls on login restrictions present on the local disk, be sure to set the hard drive as the first boot device in the motherboard firmware and disable all unauthorized methods of booting. This would include network and USB boot options. Then set a strong passphase/password to prevent unauthorized modifications to the system's firmware. It is also important to set a secondary bootloader password (in LILO, GRUB, or systemd-boot) to prevent malicious users from booting into single-user mode and gaining root level access to the system.
Daemon and service planning
Good daemon and service security starts with good planning. Start by documenting what services the host will need to run in order to accomplish the objective. This will help with composing an appropriate partition scheme for the system, and allow for more accurate security measures. Of course, this may be unnecessary if the host serves a single, simple purpose, such as a single user workstation, or operates as a dedicated firewall.
Whatever the use case is determined to be, a secure system will only enable the bare minimum number of services that are required to fulfill the purpose or objective of the system. Keeping running services to a minimum will reduce the surface area upon which a bad actor can collect network reconnaissance. It also reduces the number of handles to be exploited and will positively impact the security profile of the system.
Many security system administrators made an exception for the sshd service for remote management. A later section will explore how this service can be hardened.
Populating and recording the service list can also be used to aid system administration. By keeping a current list of version information, it will be much easier to keep the relevant packages up to date if a remote vulnerability (like a zero day) is discovered in a service.
There are various methods of inventorying the service list. Depending on the size and scale of the system(s) in question, a simple text document may be effective. Automation also exists to help track enabled and/or running services.
The following points are best-practice guidelines for filesystem partitioning:
- Any directory tree a user should be able to write to (e.g. /home or /tmp) should be on separate partitions and use disk quotas. This reduces the risk of a user filling up filesystems that are critical to the operation of the host. Portage uses /var/tmp to compile files, so that partition should be as large as necessary for the packages that must be emerged.
- Alternatively, Portage can be configured to install pre-compiled packages from a binary package (commonly shortened to "binpkg") host. This may enable the /var/tmp directory to much smaller than otherwise possible.
- Any directory tree containing non-distribution software should be on a separate partition. According to the File Hierarchy Standard. Directories for this include /opt and /usr/local. If these are accessed as separate partitions, they will not be erased if the operating system must be reinstalled.
- For extra security, static data can be put on a separate partition that is mounted read-only (commonly abbreviated as 'ro'). The truly paranoid, try using read-only media like a CD-ROM, DVD-ROM, or Blu-ray disks.
The root user
The 'root' user is the most vital user on the system and should not be used for any task except when absolutely necessary. If an attacker gains root access, the only way to trust the system again is to completely reinstall the operating system.
Golden rules about 'root':
- Always create a user for everyday use and if this user needs to have root access, add the user to the 'wheel' group. This makes it possible for a normal user to su to root.
- Never run the X server or any other user application as root. This is especially true for web browsers! The root account should only be used when absolutely necessary; if a vulnerability exists in an application running as a user, an attacker can gain user level access. But if that application is running as root, the attacker gains root access.
- Always use absolute paths when logged in as root (or always use su -, which replaces the environmental variables of the user with those of root, while being sure root's PATH value only includes protected directories like /bin and /sbin). It is possible to trick root into running a different application rather than the one meant to be run. If root's PATH is protected or root only uses absolute paths, we can be sure this won't happen.
- If a user only needs to run a few commands as root, instead of everything that root normally can do, consider using sudo instead. Just be careful who you give this access to, as well!
- Never leave the terminal when logged in as root.
Gentoo has some default protection against normal users trying to su to root. The default PAM setting requires that a user be a member of the group "wheel" in order to be able to su.
There are several reasons to draft a security policy for each system and network:
- A good security policy allows security to be outlined as a "system", rather than simply a jumble of different features. For example, without a policy an administrator might decide to turn off telnet, because it transmits unencrypted passwords, but leave on FTP access, which has the same weakness. A good security policy allows administrators to identify which security measures are worthwhile, and which are not.
- In order to diagnose problems, conduct audits, or track down intruders, it may be necessary to intercept network traffic, inspect the login and command history of users, and look in home directories. Without outlining this in print, and making users aware of this, such actions may actually be illegal and put you in legal jeopardy.
- Hijacked user accounts pose one of the most common threats to system security. Without explaining to users why security is important, and how to practice good security (such as not writing passwords on a Post-It note on their desks), it is unlikely you will have any hope of secure user accounts.
- A well-documented network and system layout will aid system engineers and administrators, as well as law enforcement forensics examiners, if need be, in tracing an intrusion and identifying weaknesses after the fact. A security policy "issue" banner, stating that the system is a private network and all unauthorized access is prohibited, will also help ensure the ability to properly prosecute an intruder, once they are caught.
The need for a good security policy is hopefully now more than clear.
A security policy itself is a document, or several documents, that outlines the network and system features (such as what services are provided), acceptable use and forbidden use, security "best practices", and so forth. All users should be made aware of the security policy, as well as changes made to keep it up to date. It is important to take the time to help users understand the policy and why that policy needs to be signed or what will happen if they act directly against the policy (the policy should also state this). This should be repeated at least once a year, since the policy can change (but also as a reminder to the user of the policy itself).
Create policies that are easy to read and be very precise on every subject.
A security policy should at least contain the following subjects:
- Acceptable use.
- Screen savers.
- Password handling.
- Software download and installation.
- Information stating if the users are being monitored.
- Use of anti-virus software.
- Handling of sensitive information (any written form, paper, or digital).
- Clean desk and locked up classified information.
- PC shutdown before leaving.
- Use of encryption.
- Handling of keys to trusted co-workers.
- Handling of confidential material when traveling.
- Handling of computer equipment when traveling.
- Laptop handling during travels and hotel stays.
Certain users may require different levels or types of access, and as such the policy may vary to accommodate them all.
The security policy can become huge, and vital information can easily be forgotten. The IT-staff's policy could contain information that is confidential for the ordinary user, so it is wise to split it up into smaller policies; e.g. Acceptable Use Policy, Password policy, Email policy, and Remote Access policy.
You can find example policies at the SANS Security Policy Resource page. Administrators with small networks who may not be able implement such policies can consider the Internet Engineering Task Force's Site Security Handbook which details practical guidance for securing information and services.