587 lines
14 KiB
HTML
587 lines
14 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Physical Security</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Security HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Overview"
|
|
HREF="x82.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Local Security"
|
|
HREF="local-security.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Security HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x82.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="local-security.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="physical-security"
|
|
></A
|
|
>3. Physical Security</H1
|
|
><P
|
|
> 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?
|
|
</P
|
|
><P
|
|
> How much physical security you need on your system is very dependent
|
|
on your situation, and/or budget.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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. :)
|
|
</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN190"
|
|
></A
|
|
>3.1. Computer locks</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN195"
|
|
></A
|
|
>3.2. BIOS Security</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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:
|
|
</P
|
|
><P
|
|
> j262
|
|
AWARD_SW
|
|
AWARD_PW
|
|
lkwpeter
|
|
Biostar
|
|
AMI
|
|
Award
|
|
bios
|
|
BIOS
|
|
setup
|
|
cmos
|
|
AMI!SW1
|
|
AMI?SW1
|
|
password
|
|
hewittrand
|
|
shift + s y x z
|
|
</P
|
|
><P
|
|
> I tested an Award BIOS and AWARD_PW worked. These passwords are quite
|
|
easily available from manufacturers' websites and
|
|
<A
|
|
HREF="http://astalavista.box.sk"
|
|
TARGET="_top"
|
|
>http://astalavista.box.sk</A
|
|
>
|
|
and as such a BIOS password cannot be considered adequate protection
|
|
from a knowledgeable attacker.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> <EM
|
|
>Note</EM
|
|
>: 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. ;(
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN206"
|
|
></A
|
|
>3.3. Boot Loader Security</H2
|
|
><P
|
|
> The various Linux boot loaders also can have a boot password set.
|
|
LILO, for example, has <TT
|
|
CLASS="literal"
|
|
>password</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>restricted</TT
|
|
>
|
|
settings; <TT
|
|
CLASS="literal"
|
|
>password</TT
|
|
> requires password at boot time,
|
|
whereas <TT
|
|
CLASS="literal"
|
|
>restricted</TT
|
|
> requires a boot-time password only if you
|
|
specify options (such as <TT
|
|
CLASS="literal"
|
|
>single</TT
|
|
>) at the <TT
|
|
CLASS="literal"
|
|
>LILO </TT
|
|
> prompt.
|
|
</P
|
|
><P
|
|
> >From the lilo.conf man page:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> 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).
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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!
|
|
</P
|
|
><P
|
|
> >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:
|
|
</P
|
|
><P
|
|
> password --md5 PASSWORD
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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:
|
|
</P
|
|
><P
|
|
> grub> md5crypt
|
|
Password: **********
|
|
Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.
|
|
</P
|
|
><P
|
|
> Then, cut and paste the encrypted password to your configuration
|
|
file.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> If anyone has security-related information from a different boot
|
|
loader, we would love to hear it. (<TT
|
|
CLASS="literal"
|
|
>grub</TT
|
|
>, <TT
|
|
CLASS="literal"
|
|
>silo</TT
|
|
>, <TT
|
|
CLASS="literal"
|
|
>milo</TT
|
|
>, <TT
|
|
CLASS="literal"
|
|
>linload</TT
|
|
>, etc).
|
|
</P
|
|
><P
|
|
> <EM
|
|
>Note</EM
|
|
>: If you have a server machine, and you set up a boot password,
|
|
your machine will <EM
|
|
>not</EM
|
|
> boot up unattended. Keep in mind that you will
|
|
need to come in and supply the password in the event of a power
|
|
failure. ;(
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN234"
|
|
></A
|
|
>3.4. xlock and vlock</H2
|
|
><P
|
|
> 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: <TT
|
|
CLASS="literal"
|
|
>xlock</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>vlock</TT
|
|
>.
|
|
</P
|
|
><P
|
|
> <TT
|
|
CLASS="literal"
|
|
>xlock</TT
|
|
> 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 <TT
|
|
CLASS="literal"
|
|
>xlock</TT
|
|
> from any xterm on your
|
|
console and it will lock the display and require your password to
|
|
unlock.
|
|
</P
|
|
><P
|
|
> <TT
|
|
CLASS="literal"
|
|
>vlock</TT
|
|
> 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. <TT
|
|
CLASS="literal"
|
|
>vlock</TT
|
|
> ships with RedHat
|
|
Linux, but your mileage may vary.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN247"
|
|
></A
|
|
>3.5. Security of local devices</H2
|
|
><P
|
|
> 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.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN250"
|
|
></A
|
|
>3.6. Detecting Physical Security Compromises</H2
|
|
><P
|
|
> 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 <EM
|
|
>you</EM
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> Some things to check for in your logs:
|
|
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> Short or incomplete logs.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Logs containing strange timestamps.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Logs with incorrect permissions or ownership.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Records of reboots or restarting of services.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> missing logs.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <TT
|
|
CLASS="literal"
|
|
>su</TT
|
|
> entries or logins from strange places.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> We will discuss system log data <A
|
|
HREF="secure-prep.html#logs"
|
|
>Section 9.5</A
|
|
>
|
|
in the HOWTO.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x82.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="local-security.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Overview</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Local Security</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |