This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Security Handbook/Pre-installation concerns
Why is security an important part for every server admin?
Physical security
Location and accessibility play major roles in physical security.
No matter the number implemented, safeguards 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. This helps ensure an attacker cannot simply walk away with a disk drive.
To prevent an attacker from booting from another disk, nicely circumventing the permissions and login restrictions, set the hard drive as the first boot device in the motherboard firmware, and set a firmware password. It is also important to set a secondary bootloader password (in LILO or GRUB) to prevent malicious users from booting into single-user mode and gaining root level access to the system.
Bootloader security is covered in more detail in Bootloader section. Sections for GRUB2 password and LILO are available.
Daemon and service planning
Good security starts with good planning. Start by documenting what services the machine will need to run. This will help with composing an appropriate partition scheme for the system, and allow for more accurate security measures. Of course, this is unnecessary if the machine serves a single, simple purpose, such as a workstation, or a dedicated firewall. In those cases, no services should be running, except perhaps sshd for remote management.
This list can also be used to aid system administration. By keeping a current list of version information, it will be much easier to keep everything up to date if a remote vulnerability is discovered in a service.
Partitioning schemes
Partitioning rules:
- Any directory tree a user should be able to write to (e.g. /home or /tmp) should be on a separate partition and use disk quotas. This reduces the risk of a user filling up the whole filesystem. Portage uses /var/tmp to compile files, so that partition should be large as large as necessary for the packages that must be emerged.
- 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 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'). For 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 ever trust the system again is to 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 group 'wheel'. This makes it possible for a normal user to su to root.
- Never run X or any other user application as root. root 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.
Security policies
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 Project. Administrators with small networks who think these policies are too much should look at the Site Security Handbook.