User manual

Etherboot User Manual
from a local device, then specify the full device name and either enable the "-DFLOPPY" option or store
a boot image (as generated by "mknbi-blkdev") under this name on the TFTP server.
It might be a good idea to install non-functional bootcode in the master boot record of your harddisk and
install any locally required boot code in the boot sectors of the individual partitions. Both "etherboot"
and "mknbi-blkdev" know how to boot from partitions such as "/dev/hda1" (first primary partion) or
"/dev/hdb5" (first logical partion on the second harddrive).
If you have the choice, then do not offer operating systems which come without effective password
protection and virtualization. This basically rules out all of the following: DOS, Windows, Win95, ...
You should be aware of the fact, that offering one "dangerous" operating system, makes all other
operating systems vulnerable as well. A noteworthy example is the availability of tools which allow an
arbitrary DOS user to read and modify the contents of a Linux harddisk partition (similar tools are
supposedly available for accessing NT partions).
C.4. PASSWORDS PROTECTED BOOT-PROMS
Password protected BOOT-Proms are a considerable improvement over the standard security measures
offered by the PC architecture, but they are still vulnerable to a variety of attacks. Most of these attacks
are related to the weaknesses of the BOOTP and TFTP protocol and these issues are discussed in another
section of text.
As the BOOT-Prom cannot store the passwords locally, it has to request them from the BOOTP/TFTP
server. The BOOTP and TFTP protocols do not allow for any elaborate challenge/response authorization
scheme. Thus the BOOT-Prom requests the password from the server and subsequently compares it with
the password as input by the user. As packets transmitted on the ethernet can easily be monitored, the
server sends a MD5 message digest (as invented by Ron Rivest/"RSA Data Security, Inc.") of the actual
password. The BOOT-Prom computes the MD5 value for the user input and compares these two values.
It is generally believed that there is no way of computing a valid plain text from a known MD5 message
digest, other than comparing it against all conceivable input texts. Thus, this approach is still vulnerable
against dictionary attacks. You should aim for using long passwords (although, anything beyond 20
characters is unlikely to considerably improve the security of the password) which are not listed in any
dictionary. Make sure that these passwords are memorized and not available in un-encrypted form.
Replace the passwords regularly and do not offer more menu entries in the BOOTP data than are
absolutely necessary.
C.5. BOOTING DOS
If you have to offer DOS or a related operating system, then do not fool yourself into believing that you
can install security software in one of its configuration files. All of these mechanisms can easily be
avoided. In many cases, even average users can figure out how to do this.
C.6. BOOTING LINUX
There are a variety of ways that allow for booting Linux in single user mode. The most common
42