[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
1. Pre-Installation Concerns
1.a. 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.b. 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.c. Partitioning Schemes
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
1.d. 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.e. Security policies
There are several reasons to draft a security policy for your system(s) and
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).
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
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
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
[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.