3. Physical Security
The first layer of security you need to take into account is the physical
security of your computer systems. Who has direct physical access to your
machine? Should they? Can you protect your machine from their tampering? Should
you?
How much physical security you need on your system is very dependent on your
situation, and/or budget.
If you are a home user, you probably don't need a lot (although you might
need to protect your machine from tampering by children or annoying relatives).
If you are in a lab, you need considerably more, but users will still need to be
able to get work done on the machines. Many of the following sections will help
out. If you are in an office, you may or may not need to secure your machine
off-hours or while you are away. At some companies, leaving your console
unsecured is a termination offense.
Obvious physical security methods such as locks on doors, cables, locked
cabinets, and video surveillance are all good ideas, but beyond the scope of
this document. :)
3.1. Computer locks
Many modern PC cases include a "locking" feature. Usually this will be a
socket on the front of the case that allows you to turn an included key to a
locked or unlocked position. Case locks can help prevent someone from stealing
your PC, or opening up the case and directly manipulating/stealing your
hardware. They can also sometimes prevent someone from rebooting your computer
from their own floppy or other hardware.
These case locks do different things according to the support in the
motherboard and how the case is constructed. On many PC's they make it so you
have to break the case to get the case open. On some others, they will not let
you plug in new keyboards or mice. Check your motherboard or case instructions
for more information. This can sometimes be a very useful feature, even though
the locks are usually very low-quality and can easily be defeated by attackers
with locksmithing.
Some machines (most notably SPARC's and macs) have a dongle on the back that,
if you put a cable through, attackers would have to cut the cable or break the
case to get into it. Just putting a padlock or combo lock through these can be a
good deterrent to someone stealing your machine.
3.2. BIOS Security
The BIOS is the lowest level of software that configures or manipulates your
x86-based hardware. LILO and other Linux boot methods access the BIOS to
determine how to boot up your Linux machine. Other hardware that Linux runs on
has similar software (Open Firmware on Macs and new Suns, Sun boot PROM,
etc...). You can use your BIOS to prevent attackers from rebooting your machine
and manipulating your Linux system.
Many PC BIOSs let you set a boot password. This doesn't provide all that much
security (the BIOS can be reset, or removed if someone can get into the case),
but might be a good deterrent (i.e. it will take time and leave traces of
tampering). Similarly, on S/Linux (Linux for SPARC(tm) processor machines), your
EEPROM can be set to require a boot-up password. This might slow attackers down.
Another risk of trusting BIOS passwords to secure your system is the default
password problem. Most BIOS makers don't expect people to open up their computer
and disconnect batteries if they forget their password and have equipped their
BIOSes with default passwords that work regardless of your chosen password. Some
of the more common passwords include:
j262 AWARD_SW AWARD_PW lkwpeter Biostar AMI Award bios BIOS setup cmos
AMI!SW1 AMI?SW1 password hewittrand shift + s y x z
I tested an Award BIOS and AWARD_PW worked. These passwords are quite easily
available from manufacturers' websites and https://astalavista.box.sk/ and as such a BIOS password cannot be
considered adequate protection from a knowledgeable attacker.
Many x86 BIOSs also allow you to specify various other good security
settings. Check your BIOS manual or look at it the next time you boot up. For
example, some BIOSs disallow booting from floppy drives and some require
passwords to access some BIOS features.
Note: If you have a server machine, and you set up a boot password,
your machine will not boot up unattended. Keep in mind that you will need to
come in and supply the password in the event of a power failure. ;(
3.3. Boot Loader Security
The various Linux boot loaders also can have a boot password set. LILO, for
example, has password and restricted settings; password requires
password at boot time, whereas restricted requires a
boot-time password only if you specify options (such as single) at the LILO prompt.
>From the lilo.conf man page:
password=password
The per-image option `password=...' (see below) applies to all images.
restricted
The per-image option `restricted' (see below) applies to all images.
password=password
Protect the image by a password.
restricted
A password is only required to boot the image if
parameters are specified on the command line
(e.g. single).
|
Keep in mind when setting all these passwords that you need to remember them.
:) Also remember that these passwords will merely slow the determined attacker.
They won't prevent someone from booting from a floppy, and mounting your root
partition. If you are using security in conjunction with a boot loader, you
might as well disable booting from a floppy in your computer's BIOS, and
password-protect the BIOS.
Also keep in mind that the /etc/lilo.conf will need to be mode "600"
(readable and writing for root only), or others will be able to read your
passwords!
>From the GRUB info page: GRUB provides "password" feature, so that only
administrators can start the interactive operations (i.e. editing menu entries
and entering the command-line interface). To use this feature, you need to run
the command `password' in your configuration file (*note password::), like this:
password --md5 PASSWORD
If this is specified, GRUB disallows any interactive control, until you press
the key <p> and enter a correct password. The option `--md5' tells GRUB
that `PASSWORD' is in MD5 format. If it is omitted, GRUB assumes the `PASSWORD'
is in clear text.
You can encrypt your password with the command `md5crypt' (*note md5crypt::).
For example, run the grub shell (*note Invoking the grub shell::), and enter
your password:
grub> md5crypt Password: ********** Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.
Then, cut and paste the encrypted password to your configuration file.
Grub also has a 'lock' command that will allow you to lock a partition if you
don't provide the correct password. Simply add 'lock' and the partition will not
be accessable until the user supplies a password.
If anyone has security-related information from a different boot loader, we
would love to hear it. (grub, silo, milo, linload, etc).
Note: If you have a server machine, and you set up a boot password,
your machine will not boot up unattended. Keep in mind that you will
need to come in and supply the password in the event of a power failure. ;(
3.4. xlock and vlock
If you wander away from your machine from time to time, it is nice to be able
to "lock" your console so that no one can tamper with, or look at, your work.
Two programs that do this are: xlock and vlock.
xlock is a X display locker. It should be included in
any Linux distributions that support X. Check out the man page for it for more
options, but in general you can run xlock from any xterm
on your console and it will lock the display and require your password to
unlock.
vlock is a simple little program that allows you to
lock some or all of the virtual consoles on your Linux box. You can lock just
the one you are working in or all of them. If you just lock one, others can come
in and use the console; they will just not be able to use your virtual console
until you unlock it. vlock ships with RedHat Linux, but
your mileage may vary.
Of course locking your console will prevent someone from tampering with your
work, but won't prevent them from rebooting your machine or otherwise disrupting
your work. It also does not prevent them from accessing your machine from
another machine on the network and causing problems.
More importantly, it does not prevent someone from switching out of the X
Window System entirely, and going to a normal virtual console login prompt, or
to the VC that X11 was started from, and suspending it, thus obtaining your
privileges. For this reason, you might consider only using it while under
control of xdm.
3.5. Security of local devices
If you have a webcam or a microphone attached to your system, you should
consider if there is some danger of a attacker gaining access to those devices.
When not in use, unplugging or removing such devices might be an option.
Otherwise you should carefully read and look at any software with provides
access to such devices.
3.6. Detecting Physical Security
Compromises
The first thing to always note is when your machine was rebooted. Since Linux
is a robust and stable OS, the only times your machine should reboot is when
you take it down for OS upgrades, hardware swapping, or the like. If
your machine has rebooted without you doing it, that may be a sign that an
intruder has compromised it. Many of the ways that your machine can be
compromised require the intruder to reboot or power off your machine.
Check for signs of tampering on the case and computer area. Although many
intruders clean traces of their presence out of logs, it's a good idea to check
through them all and note any discrepancy.
It is also a good idea to store log data at a secure location, such as a
dedicated log server within your well-protected network. Once a machine has been
compromised, log data becomes of little use as it most likely has also been
modified by the intruder.
The syslog daemon can be configured to automatically send log data to a
central syslog server, but this is typically sent unencrypted, allowing an
intruder to view data as it is being transferred. This may reveal information
about your network that is not intended to be public. There are syslog daemons
available that encrypt the data as it is being sent.
Also be aware that faking syslog messages is easy -- with an exploit program
having been published. Syslog even accepts net log entries claiming to come from
the local host without indicating their true origin.
Some things to check for in your logs:
-
Short or incomplete logs.
-
Logs containing strange timestamps.
-
Logs with incorrect permissions or ownership.
-
Records of reboots or restarting of services.
-
missing logs.
-
su entries or logins from strange places.
We will discuss system log data Section
9.5 in the HOWTO.
