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 computer? Should they? Can you protect your computer 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 computer 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 computers. Many of the following sections will help out. If you are in an office, you may or may not need to secure your computer 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 chapter :-)

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 computers (most notably SPARCs and Macs) have a dangle on the back: 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 computer.

BIOS Security

The BIOS is the lowest level of software that configures or manipulates your x86-based hardware. grub and other GNU/Linux boot methods access the BIOS to determine how to boot up your GNU/Linux computer. Other hardware that GNU/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 computer and manipulating your GNU/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 (GNU/Linux for SPARC(tm) processor computers), 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' web sites and astalavista 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 computer, and you set up a boot password, your computer 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 ;(

OpenBoot Security

The PROM is the lowest level of software that configures or manipulates your SPARC-based hardware. SILO and other GNU/Linux boot methods access the PROM to determine how to boot up your GNU/Linux computer. Other hardware that GNU/Linux runs on has similar software (OpenFirmware on Macs and new Suns, x86 BIOS, etc.). You can use your PROM to prevent attackers from rebooting your computer and manipulating your GNU/Linux system.

OpenBoot is much more advanced than a PC BIOS when it comes to security (consult the “Installation Guide” on how to access and use OpenBoot).

  1. Warning

    It is important to set your password before setting the security mode, as you would be unable to set it any more. Moreover, SUN claims you need to contact your vendor's customer support service to make your computer bootable again.

    This is an interaction example on how to set your boot password:

    > password 
    > New password (only first 8 chars are used):
    > Retype new password:
    >

  2. You can choose between three security levels setting the security-mode variable:

    1. Full: all commands except for go require the password.

    2. Command: all commands except for boot and go require the password.

    3. None: no password required (default).

    This is an interaction example on how to set your security mode:

    > setenv security-mode full 
    >

Note

If you have a server computer, and you set up a boot password, your computer 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 ;(

Boot Loader Security

Keep in mind when setting all these passwords that you need to remember them :-) Also remember that these passwords will only 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 boot passwords!

If you are using security in conjunction with a boot loader, you might as well password-protect the PROM.

Note

Once again, if you have a server computer, and you set up a boot password, your computer 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!

With GRUB

The various GNU/Linux boot loaders also can have a boot password set. grub is quite flexible in that sense: your default configuration file /boot/grub/menu.lst may contain a line allowing the loading of a new configuration file with different options (this new file may contain a new password to access another third configuration file and so on).

So you must add a line in your /boot/grub/menu.lst file, something like:

password very_secret /boot/grub/menu2.lst

and of course generate a new /boot/grub/menu2.lst configuration file where you move insecure entries previously removed from /boot/grub/menu.lst.

>From the grub info page:

 - Command: password passwd new-config-file
     Disable all interactive editing control (menu entry editor and
     command line). If the password PASSWD is entered, it loads the
     NEW-CONFIG-FILE as a new config file and restarts the GRUB Stage 2.

With LILO

LILO 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).

With SILO

The SILO boot loader may also have a boot password: password requires password at boot time, whereas restricted requires a boot-time password only if you specify options (such as single) at the SILO prompt.

From the silo.conf man page:

password=password
      Protect booting by  a  password.  The  password  is
      given  in  cleartext  in  the  configuration  file.
      Because of that the configuration  file  should  be
      only  readable  by  the super user and the password
      should differ if possible from other  passwords  on
      the system.

restricted
      A password is only required to boot the image spec-
      ified in /etc/silo.conf if parameters are specified
      on  the  command line or if the image is not speci-
      fied in the configuration file at all  (i.e.   arbi-
      trary file load).

xlock and vlock

If you wander away from your computer 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. You can run xlock from any xterm on your console and it will lock the display and require your password to unlock. Most desktop environment also propose this feature in their respective menus.

vlock is a simple little program that allows you to lock some or all of the virtual consoles on your GNU/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.

Of course, locking your console will prevent someone from tampering with your work, but won't prevent them from rebooting your computer or otherwise disrupting your work. It also does not prevent them from accessing your computer from another computer 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 KDM (or other).

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.

Detecting Physical Security Compromises

The first thing to always note is when your computer was rebooted. Since GNU/Linux is a robust and stable OS, the only times your computer should reboot is when you take it down for OS upgrades, hardware swapping, or the like. If your computer has rebooted without you doing it, that may be a sign that an intruder has compromised it. Many of the ways that your computer can be compromised require the intruder to reboot or power off your computer.

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 computer 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 in 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 the section called “Keep Track of your System Accounting Data” in this chapter.


Hosted by Internet News Unlimited