Security Architecture

So far, we have examined the essential features of Solaris security, including the need to protect individual files (as well as entire systems) from unauthorized access. In addition, we examined how both files and systems can be protected from remote access tools. However, we need to place these individual actions within a context that logically covers all aspects of security, typically known as levels. A level is an extra step that must be breached in order to obtain access to data.

In terms of physical security, a bank provides an excellent analogy. Breaking into a bank s front counter and teller area is as easy as walking through the door, because these doors are publicly accessible. However, providing this level of access sometimes opens doors deeper inside the building. For example, the private banking area, which may normally only be accessed by staff and identified private banking customers, may allow access using a smart card. If a smart card is stolen from a staff member, it could be used to enter the secure area, because the staff member s credentials would be authenticated. Entering this level would not necessarily provide access to the vault: superuser privileges would be required. However, a thorough physical search of the private banking area might yield the key required for entry. Alternatively, a brute force attack on the safe s combination might be used to guess the correct combination. Having accessed the vault, if readily negotiated currency or bullion is contained therein, then an intruder could easily steal them. However, if the vault contained checks that needed to be countersigned, the intruder may not be able to make use of the contents. The lesson here is simple: banks provide public services that open up pathways straight to the cash. Banks know that any or all of the physical security layers may be breached. That s why the storage of negotiable securities is always minimized, because any system designed by humans can be broken by humans , with enough time and patience. The only sensible strategy is to make sure that external layers are as difficult to breach as possible, and to ensure that security experts are immediately notified of breaches.

Similarly, public file areas, such as FTP and WWW servers, are publicly accessible areas on computer systems that sometimes provide entry to a different level in the system. An easily guessed or stolen password may provide user -level (but unprivileged ) access to the system. A brute force attack against the local password database might even yield the superuser password. Accessing a local database might contain the target records of interest. However, instead of storing the data plaintext within tables, data may have been written using a stream cipher, making it potentially very difficult to obtain the data. And because 40-bit ciphers have been broken in the past, obtaining the encrypted data might eventually lead to its dissemination . Again, a key strategy is ensuring that data is secure by as many external layers as possible, and also that the data itself is difficult to negotiate.

Increasing the number of levels of security typically leads to a decrease in system ease of use ”for example, setting a password for accessing a printer requires users to remember and enter a password when challenged. Whether or not printer access needs this level of security will depend on organizational requirements. For a printer that prints on plain paper, no password may be needed. However, for a printer that prints on bonded paper with an official company letterhead, a password should be used to protect the printer, and optionally , a copy of the file being sent to the printer may need to be stored securely for auditing purposes.

For government and military systems, there are a number of security specifications and policy documents available, which detail the steps necessary to secure Solaris systems in top secret installations. The U.S. Department of Defense, for example, publishes the Orange Book, formally known as the Trusted Computer System Evaluation Criteria specification. This book describes systems it has evaluated in terms of different protection levels, from weakest to strongest, including:

• Class D, which are systems that do not pass any tests and are therefore untrusted. No sensitive data should be stored on class D systems.

• Class C1, which are systems that require authentication based on a user model.

• Class C2, which are systems that provide auditing and logging on a per-user basis, ensuring that file accesses and related operations can always be traced to the initiating user.

• Class B1, which requires security labeling for all files. Labels range from top secret to unclassified.

• Class B2, which separates normal system administration duties from security activities that are performed by a separate security officer. This level requires covert channels for data communications and verified testing of an installation s security procedures.

• Class B3, which requires that a stand-alone request monitor be available to authenticate all requests for file and resource access. In addition, the request monitor must be secured and all of its operations logged.

• Class A1, which is a formally tested and verified installation of a class B3 system.

All of the strategies that we discuss in this chapter are focused on increasing the number of layers through which a potential cracker (or disgruntled staff member) must pass to obtain the data that they are illegally trying to access. Reducing the threat of remote access exploits and protecting data are key components of this strategy.

Physical Security

It may seem obvious ”if an intruder can physically access your system, then he or she may be able to take control of your system without the root password, bypassing all of the software-based controls that normally limit such activity. How is this possible, you might ask? If the intruder has access to a bootable CD-ROM drive, and a bootable CD-ROM (of Solaris, Linux, or any other operating system that can mount UFS drives ), it s trivial to enter the following command at the OpenBoot prompt and start the system without a password:

 ok boot cdrom 

Once the system has booted from the CD-ROM drive, a number of options are available to the intruder:

• Do an ftp on any file on the system to a remote system.

• Copy any file on the system to a mass storage device (such as a DAT tape).

• Format all of the drives on the system.

• Launch a distributed denial of service attack against other networks, which you will be blamed for.

Of course, the possibilities are endless, but the result is the same. You may ask why it is so easy to compromise a system in this way: one good reason is that if you forget your root password, you can boot from the CD-ROM, mount the boot disk, and manually edit the shadow password file.

This requirement doesn t really excuse poor security, and the OpenBoot monitor provides some options to secure the system. There are three security levels available:

• None Surprisingly, this is the default. No password is required to execute any of the commands in OpenBoot. This is convenient but dangerous, for the reasons outlined earlier.

• Command This level needs a password to be entered for all commands except boot and go . Thus, details of the SCSI bus and network traffic can t be observed by the casual browser, but an intruder could still boot from the CD-ROM.

• Full This level requires a password for every command except go , including the boot command. Thus, even if the system is interrupted and rebooted using the boot command, only the default boot device will be available through go .

To set the security level, the eeprom command is used. To set the command level, use the following command:

 # eeprom security-mode=command 

Alternatively, to set the command level, use the following command:

 # eeprom security-mode=full 

The password for the command and full security levels must be set by using the eeprom command:

 # eeprom security-password= Changing PROM password: New password: Retype new password: 

Note that if the root password and the full-level password are lost, there is no way to recover the system by software means: a new PROM will need to be ordered from Sun.

Disabling IP Ports

The first step in network security is to prevent unauthorized entry by disabling access to specific IP ports, as defined by individual entries in the services database. This action prevents specific services from operating, even if the inetd attempts to accept a connection for a service because it is still defined in /etc/inetd.conf . In this section, we will examine how to disable specific services from inetd, in conjunction with the services database.

The following services are typically enabled in /etc/services and configured in /etc/inetd.conf . Most sites will want to disable them, and install more secure equivalents. For example, the ftp and telnet services may be replaced by the encrypted secure copy and secure shell programs, respectively. To disable the ftp, telnet, shell, login, exec , comsat, talk, uucp, and finger services, we would comment out their entries in /etc/inetd.conf by inserting a hash character # at the first character position of the line that defines the service. The following configuration enables the ftp, telnet, shell, login, exec, comsat, talk, uucp, and finger services in /etc/inetd.conf :

 ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd -l telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind exec    stream  tcp     nowait  root    /usr/sbin/in.rexecd     in.rexecd comsat  dgram   udp     wait    root    /usr/sbin/in.comsat     in.comsat talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd uucp    stream  tcp     nowait  root    /usr/sbin/in.uucpd      in.uucpd finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd 

The following configuration disables the ftp, telnet, shell, login, exec, comsat, talk, uucp, and finger services in /etc/inetd.conf :

 #ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd -l #telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd #shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd #login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind #exec    stream  tcp     nowait  root    /usr/sbin/in.rexecd     in.rexecd #comsat  dgram   udp     wait    root    /usr/sbin/in.comsat     in.comsat #talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd #uucp    stream  tcp     nowait  root    /usr/sbin/in.uucpd      in.uucpd #finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd 

Similarly, the following configuration enables the ftp, telnet, shell, login, exec, comsat, talk, uucp, and finger services in /etc/services :

 ftp             21/tcp telnet          23/tcp shell           514/tcp         cmd login           513/tcp exec            512/tcp biff            512/udp         comsat talk            517/udp uucp            540/tcp         uucpd finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd 

Similarly, the following configuration disables the ftp, telnet, shell, login, exec, comsat, talk, uucp, and finger services in /etc/services :

 #ftp             21/tcp #telnet          23/tcp #shell           514/tcp         cmd #login           513/tcp #exec            512/tcp #biff            512/udp         comsat #talk            517/udp #uucp            540/tcp         uucpd #finger  stream  tcp     nowait  nobody  /usr/sbin/in.fingerd    in.fingerd