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. :)
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.
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 http://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. ;(
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=mypassword
The per-image option `password=...' (see below) applies to all images.
restricted
The per-image option `restricted' (see below) applies to all images.
password=mypassword
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. ;(
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 Red Hat 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.
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.
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 10.5 in the
HOWTO.
