1.  Physical Security

No matter how many safeguards you implement, they can all be easily circumvented by an attacker with physical access to your computer. Despite this, there are at least some measures that can be taken to provide a degree of security against an attacker with physical access to your machine. Putting your hardware in a locked closet prevents an attacker from simply unplugging it and carting it off. Locking your computer's case is also a good idea, to make sure that an attacker cannot simply walk away with your hard drive. To prevent an attacker from booting from another disk, nicely circumventing your permissions and login restrictions, try setting the hard drive as the first boot device in your BIOS, and setting a BIOS password. It is also important to set a LILO or GRUB boot password, to prevent a malicious user from booting into single-user mode and gaining complete access to your system. This is covered in more detail in Chapter 3, under (Setting a GRUB password) and (Setting a LILO password).

1.  Daemon/Service Planning

Start by documenting what services this machine should run. This will help you compose a better partition scheme for your system, and allow you to better plan your security measures. Of course, this is unnecessary if the machine serves a single simple purpose, such as a desktop, or a dedicated firewall. In those cases, you should not be running any services, except perhaps sshd.

This list can also be used to aid system administration. By keeping a current list of version information, you will find it much easier to keep everything up to date if a remote vulnerability is discovered in one of your daemons.

1.  Partitioning Schemes

Partitioning rules:

• Any directory tree a user should be able to write to (e.g. /home, /tmp) should be on a separate partition and use disk quotas. This reduces the risk of a user filling up your whole filesystem. Portage uses /var/tmp to compile files, so that partition should be large.
• Any directory tree where you plan to install non-distribution software on should be on a separate partition. According to the File Hierarchy Standard, this is /opt or /usr/local. If these are separate partitions, they will not be erased if you have to reinstall the system.
• For extra security, static data can be put on a separate partition that is mounted read-only. For the truly paranoid, try using read-only media like CD-ROM.

1.  The root user

The user 'root' is the most vital user on the system and should not be used for anything except when absolutely necessary. If an attacker gains root access, the only way to ever trust your system again is to reinstall.

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 only includes protected directories like /bin and /sbin). It's 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 you are 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.

1.  Security policies

There are several reasons to draft a security policy for your system(s) and network.

• A good security policy allows you to outline security 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 you 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 you, 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 your system is a private network and all unauthorized access is prohibited, will also help ensure your ability to properly prosecute an intruder, once he is caught.

The need for a good security policy is hopefully now more than clear.

The 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 your security policy, as well as changes you make to keep it up to date. It is important that you take the time to help users understand your policy and why that policy needs to be signed or what will happens 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).

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

Different users may require different levels or types of access, and as such your 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. If you have a small network and think these policies are too much you should look at the Site Security Handbook.