Section 26.3.3.2, “DMZ WWW Server,” discusses the basic security policy of the Web server. Some of the consequences of the policy are as follows.

From these implications, several constraints emerge. The Web server consequences (WCs) of interest are as follows.

The development system lies in the internal network, on the development subnet (called the “devnet”). It must provide an environment in which developers can produce code for dribbles. Because users will be active on the system, its policy is considerably different than that of the Web server system.

The devnet has both infrastructure and user systems. The infrastructure systems are the devnet firewall (which separates it from other internal subnets), a DNS server, a logging host (which provides a central repository for logs), one or more file servers, and one or more systems containing user information common to the workstations (the UINFO servers). There is also an isolated system used to build a “base system configuration” (system files, configuration files, company-approved software, and so on) and to burn CD-ROMs. The policy that follows does not apply to these systems. They are under much tighter controls. The components of the security policy relevant to our discussion are as follows.

These components have several consequences, two of which affect the infrastructure and configuration of workstations. Policy component 3 leads to the use of a firewall at the boundary of the devnet and the other subnets to enforce the network security policy. This allows the network security administrators to enforce changes in the network policy without having to alter each system on the devnet. Any changes need only be made at the firewall. Also, the systems on the devnet need not be so tightly configured as must the firewalls. The firewalls enforce the policy that hosts outside the devnet see; the hosts inside the devnet enforce the policy specific to the developers and their hosts (the policy outlined above).

Policy component 3 also bars direct access between the Internet and devnet systems. This decision was based on a risk analysis. The security officers and management of the Drib realized that the Drib would benefit from allowing telecommuting and access to remote Web sites. However, the dangers of opening up an avenue of attack from Internet hosts to internal hosts, and allowing unsuspecting Drib employees to download untrusted, and possibly malicious, code, outweighed the perceived benefits. This portion of the policy is under review, and the Drib is considering changes to allow telecommuting (see Exercise 8 in Chapter 26).

Some developers need access to the Internet to determine what equipment to obtain as they plan new mechanisms and devices to enhance the value of the Drib's products. These developers are given separate workstations connected to a commercial Internet Service Provider (ISP) outside the Drib's perimeter. These “ISP work stations” are physically separated from the internal network, and the ISP workstation cannot easily be connected with the devnet workstation. These procedural mechanisms enforce the desired separation.

Other consequences of the policy apply to the devnet workstations. The development system consequences (DCs) of interest are as follows.

Two points about this policy, and its implications, are apparent. First, the system security policy relies on the outer and inner firewalls to prevent Internet users from reaching the system. If one firewall fails, the other will still block such accesses.^[1] Also, the firewall at the perimeter of the developer's subnet enforces the access restrictions among the users of the other two subnets and the systems on the developer's subnet.^[2] So the system policy assumes that those who can connect to the system are authorized to access developer systems.

The security policy also requires procedural enforcement mechanisms.

Here, the Drib must rely on procedural mechanisms to enforce the policy. In this case, the procedures should specify both the prohibition and the consequences of violating it. This puts all employees on notice that the prohibition will be enforced, and encourages them to use the allowed methods to obtain approval.

The differences between the policies of the DMZ WWW system and the devnet developer system arise from their different roles. The DMZ WWW server is not a general-use system. It exists only to serve Web pages and accept Web orders. The devnet developer system is a general-use computer. It must allow compilation, editing, and other functions that programmers and software engineers need to design, implement, and test software.

The DMZ Web server system's security policy focuses on the single purpose of the server: to run the Web server. Two sets of users can access the server: the system administrators, who maintain the security and the Web pages; and the users from the Internet, who must go through the outer firewall and can access only the Web server. The developer system's security policy focuses on more complex purposes. These purposes include software creation, testing, and maintenance. The developer system requires more supporting software than does the DMZ Web server system. The user population is different and provides an environment more amenable for attackers than does the DMZ Web server system, because the users may not be as security-conscious as the security officers comprising the user population of the DMZ Web server system.

That the system administrators of the DMZ Web server system are trained in security (hence, the term “security officers”) should be expected. The developer systems are more numerous and require more administrative effort to maintain. More system administrators are required. The administrators will also have different skills and abilities; some may be very senior and experienced, whereas others will be junior and inexperienced. Hence, the system administrators for the developer systems may not be trained in security. So the system security officers may not be administrators. This leads to situations in which system administrators and security officers disagree on what actions are appropriate. The policy must have some mechanism for resolving these disputes. The mechanism typically involves a person, or a group of people, performing a cost-benefit analysis of each option and selecting the option that provides the greatest benefit at the least cost. This type of analysis was briefly discussed in Section 1.6.1.

We now examine several areas of system administration in light of these security requirements. Our goal is to install, and manage, as secure a system as possible. Our approach is to compare and contrast these two systems. What follows is organized into areas, and each system is examined with respect to the mechanisms used to enforce the policy. We then compare the two systems.

Item WC1 limits network access to the Web server.^[4] External users can reach the system only by using Web services and connecting through the outer firewall. Internal users can reach the system by using SSH from the trusted administrative system, through the inner firewall. A security mechanism must block any other types of connections, or any connections from sources other than the outer firewall or the trusted administrative server.^[5] Moreover, item WC4 requires that all attempts to connect be monitored^[6] to validate that the security mechanism functions according to this policy (or to detect failures).^[7]

Consider the Web server first. Although requests can come from any IP address on the Internet, all such requests go to the outer firewall's Web proxy. That firewall forwards well-formed requests to the DMZ Web server. Hence, the Web server's access control mechanism can discard any requests from sites other than the outer firewall. Whether to accept requests from the inner firewall depends on several policy factors. The current policy for the Drib is not to allow the Web server to accept these requests.^[8] However, the policymakers have realized that some situations may require internal users to access the Web server directly (these situations typically will involve debugging or checking for errors). Should this be necessary, the security officers will reconfigure the inner firewall to run a Web proxy identical to the one on the outer firewall. Thus, the DMZ Web server is configured to accept requests from the inner firewall as well as the outer firewall. The server will not accept requests from other DMZ systems, because they are not to be used for accessing the Web server.

order allow,deny

allow from outer_firewall
allow from inner_firewall
deny from all

Item WC1 requires the DMZ Web server to allow administrative access from the trusted administrative Web server. This allows system administrators to update Web pages, reconfigure and modify software, and perform other administrative tasks. The Web server runs an SSH server. This server provides enciphered, authenticated access to the Web server system using cryptographic mechanisms to provide those security services. Of interest here is that the server requires both the host and the user to be authenticated.^[9] This allows the system administrators to restrict access to users connecting from the trusted administrative server only.

allow trusted_admin_server
deny all

Section 27.4.1 discusses users, and authentication of both hosts and users, on the Web server system.

To maximize availability, the Web server system wraps each server with a small script. If the server terminates, the script starts a new instance of the server.

#! /bin/sh
echo $$ > /mnt/users/servers/webdwrapper.pid
while true
do
       /usr/local/bin/webd
       sleep 30
done

By virtue of item WC3, the Web server system should run a minimum of network servers. Because access is to be given only to Web requests and administrative logins, no network servers other than the Web server and the SSH server are needed.^[10]

The Web server runs several network clients, however. Because the Web server system must request IP addresses and host names, it must make requests of, and receive replies from, a DMZ DNS server. At any time, multiple requests may be outstanding. By virtue of item WC1, this satisfies the policy. However, several types of attacks on DNS clients [892] involve “piggybacking” of multiple host name and address associations onto a reply to a request for a single such association.^[11] The Web server system's DNS client will use only the requested data. It will discard any additional data as well as any logs that such data has been received.^[12] Furthermore, if the client receives a response that provides information that was not requested, or if two responses provide different answers to the same query, both are logged and discarded, and the client acts as though the DNS request has timed out.

The Web server system also runs a logging client to send log messages to the log server. Programs use an internal message delivery system to send messages to the logging client, which then delivers them to the appropriate hosts and files. The delivery addresses lie in a configuration file. Each log message is timestamped and has the name of the process and (Web server) system attached.

The system is configured to log any attempts to connect to network ports on which no servers are listening. The three reasons for doing this follow from item WC4. First, it serves as a check that the outer firewall is intercepting all probes from the Internet to the Drib's Web server. Second, it detects probes from the internal network to the DMZ Web server. Because the inner firewall has one port that is filtered rather than proxied (the SSH port), such probing is possible if the filter does not check the destination port number. This should never happen, of course, unless the inner firewall is misconfigured or compromised. Thus, in order for an attack on the firewall to be undetectable, two failures must occur (the firewall fails to block, and the DMZ Web server fails to log).^[13] Third, probes to other ports from within the DMZ indicate unauthorized activities on the DMZ systems, meaning that one of them has been compromised. This requires immediate investigation.

Item DC1 requires that the development system accept user connections only when they are authenticated and encrypted. Like the DMZ Web server, the development systems run SSH servers to provide such access. Both hosts and users use public key authentication.^[14]

Unlike the DMZ Web server system, the development system runs several other servers. It runs a line printer spooler to send print requests to a print server. It runs a logging server to accept log messages and dispose of them properly. It also runs servers to support access to both the file server and the user information database system. These servers are necessary in order for the developers to be productive on that system.

The development system does not have the ftp or Web services. Instead, special ftp and Web server systems mount directories from the central file servers. The workstations run an SMTP server as a convenience to users,^[15] but all mail is forwarded to a central mail server and is never delivered locally. (This allows workstation SMTP servers to be very simple programs.^[16]) Users can access mail on any workstation, because the mail spooling directory resides on the central file server. Similarly, users can make files available for ftp and Web access by placing them into user-specific directories on the central file server. The corresponding servers mount these directories for remote access. They cannot access other parts of the file systems on the file servers.

Placing the mail, ftp, and Web services on systems other than the development workstations has two advantages that satisfy item DC2. First, it minimizes the set of network servers that each workstation has to run. Second, it minimizes the number of systems that provide the services.^[17] This enables the firewall to be configured to allow traffic for these services through to a small set of systems, and the security administrators can configure those systems to handle access control appropriately.

The development system uses access control wrappers to support access controls. The firewall provides this control for systems not on the devnet, but the workstation's access control wrappers provide this control for other devnet workstations, as well as duplicating the firewall's control rules. If the firewall's access controls fail (for example, as a result of a configuration error), the workstation will still honor the network security policy.^[18] Furthermore, the development system logs all attempts to access servers. These logs provide both evidence of intrusions and verification of the correct functioning of the security mechanisms, as required by item DC8.

Item DC8 requires checking of the security of the development workstations. To ensure that they remain at the desired level of security, the system security officers occasionally scan each system. Their scanner probes each port and records those that are open. The results are compared with the list of ports that are expected to be open. Any discrepencies are reported to the security officers. Moreover, the scanners record the address of each system on the network. Any unauthorized system is reported immediately, as are any unexpected changes in addresses. The security officers make these scans periodically. To prevent an attacker from determining the schedule, the security officers launch additional scans at irregular intervals as well.^[19]

Finally, the security officers occasionally attack devnet systems to determine how well they withstand attacks.^[20] These operations are sustained and take some time, but the information gleaned from them has proven invaluable. When flaws are discovered, the security officers determine whether they are attributable to the initial configuration or to user changes in the system. In the former case, the security officers develop a patch or modification of the standard configuration. In the latter case, they assess the situation in more detail, and act on the basis of that analysis.

The difference between approaches to network services and accesses springs from the use of, and the locations of, the systems.

The DMZ Web server system is dedicated to two specific tasks—serving Web pages and accepting commercial transactions. Only those functions and processes required to support this specific task are allowed. Any other programs, such as those required for general use, are simply not present in the system. It need not provide access to a line printer, or handle remote file systems from central servers. Everything is present in the system itself. No extraneous services are provided or used.^[21]

The development system performs many tasks, all designed to achieve the goal of providing an environment in which the developers can be productive.^[22] It has general-purpose tools ranging from compilers and text editors to electronic mail reading programs. It shares user files with other workstations using a central file server, and user information with a central user information system. Users can run processes freely.

The environment plays a role in configuration. Both systems use a “defense in depth” strategy of providing access controls that duplicate some of the firewall controls.^[23] The DMZ Web server system does not depend on the firewall to filter or block Web client requests. Even if the inner firewall allowed messages to flow through it with no control, the DMZ Web server system would function as required by policy.

However, access to the development systems depends on the devnet firewall's filtering abilities. If a user from another internal subnet tries to access a development system, the devnet firewall will determine whether or not access to the devnet is allowed. If it is, then the developer system determines whether or not to accept the connection. This allows the Drib network administrators to control access among the three subnets and the DMZ independently of the system administrators within the subnets (who do not control the firewalls). It also allows the developer workstations to support developers on other subnets—if the Drib policy allows it.

Items WC2 and WC3 suggest that the number of user accounts on the system be minimal. The Web server requires at most two users and a sysadmin. The first user is a user with enough privileges to read (and serve) Web pages and to write to the Web server transaction area. The second user is a user who can move files from the Web transaction area to the commerce transaction spooling area. The reason the Web server has minimal privileges lies in the assumption that the Web server, which interacts with other systems on the Internet, may be compromised. A compromised Web server running with sysadmin privileges could allow the attacker to control the system, but if the Web server had only enough priviliges to read Web pages, then compromising it would be less likely to compromise the system. The commerce server and the Web server should be different users in order to prevent an attacker from compromising the Web server and then deleting files from the commerce server's area. Access control mechanisms^[25] can inhibit this, but defense should not depend on one control only.^[26] If the Web server and commerce server are different users, and the Web server is compromised, the attacker must then compromise either the sysadmin or the commerce server user.

Some systems (such as many UNIX systems) use a simplified mechanism that does not allow individual users to be placed in an access control list.^[27] However, group mechanisms achieve the same end.

There is a tension between the desire to minimize the number of accounts (item WC2) and the desire to minimize the privileges of these accounts (item WC3). Most computer systems allow the assignment of privilege to accounts independently of name. This means that there can be multiple sysadmin accounts. Each person designated as a system administrator could have a separate sysadmin account or could use a single, role account.^[29] The reason for having separate sysadmin accounts is to tie each action to a particular user. Whether or not this can be done depends to some extent on the implementation of the Web server system.

Some UNIX systems support an audit, or a login, UID.^[30] This UID is assigned at login and is not changed throughout the lifetime of the process. Furthermore, all children of the process inherit that audit UID. Assigning each system administrator a unique user account (each with a unique UID) associates that UID with every action that account takes. This includes acquiring administrator privileges.

Because item WC4 requires strict user accountability, the Web server system is set up to disallow direct logins from system administrators. Each user must log into the system from the trusted administrative server. As stated in Section 27.3.1, this requires the use of SSH, so the user must be an authorized user of the Web server system.^[31] The set of allowed users is enumerated in the SSH configuration file in the Web server system. Once logged in, the user may switch to a role account. To do so, the user supplies a password. The program checks that the user has self-authenticated correctly, and then that the user is authorized to access the requested role account. If so, the user is switched into this role.

Direct login to a sysadmin account is allowed in one situation only. The Web server system allows logins to role accounts (such as root) from the system console. Although the system cannot identify the individual logging into the role, the console itself is in a locked room to which only a few highly trusted individuals have access. At least three people are in that room at all times, including one security officer. The officer can identify by sight the set of people authorized to enter the room.^[32] So, if someone walks up to the console and logs into a role account, the security officer will log that individual's use of the console.^[33] Thus, should the SSH server become unexpectedly unavailable, a system administrator could fix it.

Unlike the DMZ WWW server system, the development system requires at least one user account per developer (items DC1, DC3, and DC6). It also requires administrative accounts, as well as groups corresponding to projects (items DC2 and DC3). Furthermore, an account on different development systems must refer to the same individual, role, or project (item DC1). Otherwise, inconsistent use of identifiers may allow access rights that exceed the level authorized by the security policy.

To meet the requirement for consistency of naming, the Drib developers have decided to use a central repository to define users and accounts, the UINFO system. They use the NIS protocol [969] to allow distribution of user information. All systems on the developer subnet, except the firewall, use the NIS server to obtain information about users and accounts. Any new account must be instantiated on the databases of this server. No user accounts are created on the developer workstations themselves, and all system accounts have entries in the server databases.

The developers benefit from this arrangement. Because their files are kept on NFS file servers, a developer can access them at any devnet workstation, as required by item DC6. If one workstation cannot function, the developer can walk to another workstation and continue development. The system and network administrators can then repair the malfunctioning workstation with minimal loss of developer time.

To satisfy item DC2, each developer workstation has a local root account and one local account for each system administrator.^[35] This account gives administrators access should the workstation be unable to contact the NIS server. Because there are both primary and secondary NIS servers, and backups for each, the only reason that this situation might arise would be either a network problem or a workstation problem. Using the local root account, the administrator could access the workstation, diagnose the problem, and (if possible) correct the problem at the client.

As allowed by item DC2, the Drib administrators have set up several accounts to perform system functions. Examples are the mail account, which allows the user to manipulate mail queues and configuration files, and the daemon user, under which most network daemons run. These accounts do not have root privileges. This is an application of the principle of least privilege,^[36] because few functions require the powers of the root account.

The NIS mechanism uses cleartext messages to transmit user information. This violates requirement DC1, because the messages are not integrity-checked. They are susceptible to network-based attack, because an attacker can inject responses to queries. However, a quick analysis demonstrates why this is not a problem in the particular environment of the Drib.

The development system is not accessible to users from the Internet. The outer firewall, inner firewall, and devnet firewall prevent any direct connections from the Internet. The threat comes from insiders, people with access to the Drib's internal network. The security analysts classified these threats into two distinct sets.

The first set involves nonadministrative information. This data is sent enciphered and integrity-checked, using mechanisms that the analysts trust. Compromising this data could lead to corruption of user-specific data, and the analysts felt that the other mechanisms provided sufficient protection to deter this.

The second set involves administrative information—specifically, the NIS user records. These records are not encrypted. However, none of these records include administrative accounts, so only ordinary users can be compromised.^[38] The security analysts configured each workstation so that only root could inject false information that either the clients or the server would accept as legitimate.^[39] They then physically secured the network to prevent unauthorized personnel from connecting workstations to the Drib's network. Fake NIS replies can be put on the network only from the outside (such replies would have to go through the devnet firewall) or from a host on the network (such replies would require root access). In the first case, the devnet firewall would reject the packets before they entered the devnet network. In the second case, root could access that user's account by running the su command on the system under attack, making unnecessary the injection of false NIS packets to obtain access to a user's account.

Given this analysis, the Drib's policy managers agreed with the system developers, administrators, and security officers that the violation of item DC1 was acceptable. However, if there is evidence of a problem, the policy managers reserved the right to require that some other scheme be developed with security the foremost consideration.

The difference between selecting users for the DMZ Web server system and selecting users for the development system reflects the differences between the security policies of the two systems. The root lies in the intended use of each system.

The DMZ Web server system is in an area that is accessible to untrusted users (specifically, from the Internet). Although access is controlled, the controls may have vulnerabilities. Limiting the number of users on the system, and ensuring that untrusted users access servers running with minimal privileges, increase the difficulty of an attacker obtaining unauthorized access to the system.^[40] Except for the superuser, users can perform only restricted actions. Finally, the user information is kept on the system, so attackers cannot inject false information (such as information on other users) into the system's accesses to a user information database.^[41]

The development system allows general user access, so it has many more accounts. Furthermore, the development system shares its user population with other systems on the same subnet, so it accesses a centralized database containing the information. This keeps the user and file information consistent across platforms. The features of the NIS system (notably, the “+” and “–”) [969] allow each devnet system administrator to control authorization to use that particular system. System accounts other than that of the superuser allow the system administrators to control administrative actions to a fairly high degree of granularity. The trade-off is that these administrative accounts can access files on the file server, whereas the superuser can access only public files.

Finally, the difference in means of access reflects the differences in the environments and uses of the two systems. The DMZ Web server system allows access only through a small set of tightly controlled access points: the Web server (from the outer firewall), the SSH server (from the inner firewall), and a login server bound to the physical console of the system. This reflects the classes of users who are authorized to use the system, as well as the ways in which they are authorized to use it.^[42] External users can access only the Web server; internal users, only the SSH server. However, the devnet system is in the internal network. Hence, users can come from a wide variety of systems and can access any server. The only controls on access are that the accesses must come from within the devnet, unless explicitly stated otherwise, and that the users must have accounts on the devnet centralized database system.

As required by WC1 and WC2, the SSH server uses cryptographic authentication to ensure that the source of the connection is the trusted administrative host. If the connection is from any other host, the SSH server is configured to reject the connection. Furthermore, SSH uses a cryptographic method of authentication rather than relying on IP addresses.^[43]

When a user connects to the SSH server, that server attempts to perform cryptographic authentication. If that attempt fails, that server requests a password from the user. Were this likely to remain unchanged, the administrator would configure the authentication routines directly in the SSH daemon. However, the Drib is experimenting with one smart card system and plans to try two more. Because such a system would require changes in the authentication methods, the system administrator has elected to use PAM to avoid having to modify the source to the SSH server, recompile, and reinstall.^[44]

The UNIX system used for the Web server system allows the use of an MD-5-based password hashing mechanism. The advantage of this scheme over the standard UNIX scheme is that the passwords may be of arbitrary length. The password changing program on the Web server system is set to require passwords to have a mixture of letters, numbers, and punctuation (including white space) characters. When a password is changed, the password changing program runs the proposed password through a series of checks to determine if it is too easy to guess.^[45] If not, the change is allowed.

The system administrator has disabled password aging. Password aging is suitable when reusable passwords may be tried repeatedly until guessed, or if the hashed passwords can be obtained and cracked.^[46] Here, all user connections come from the trusted administrative host, so only users who are authorized to use that system can get to the Web server system's SSH server. These users are trusted. The purpose of password aging is to limit the danger of passwords being guessed. Because the only users who could guess passwords are trusted not to do so, password aging is unnecessary.

The development system supports several users. It is in a physically secure area, accessible only to Drib employees. However, employees other than developers (such as custodians and managers) have access to the restricted area, so authentication controls are required.^[47]

Item DC1 means that each user must self-authenticate at login. Although the Drib is moving toward a smart card system, each user currently has a reusable password. Because the users are not administrators (and therefore have no superuser privileges), cracking of passwords would gain them additional privileges. Hence, password aging is in effect. The mechanism uses the time-based approach. Once changed, a password may not be changed again for 3 days. Because the Drib has administrators present at all times, if a user suspects a compromise, the system administrator can reset the password. The Drib computed that guessing passwords in 180 days would require more computing power than was conveniently available on site, so the system administrators require users to change their passwords every 90 days. One week before a user's password expires, the user is warned at login that the password is about to expire. Once the password expires, the user may begin logging in but will be asked for a new password before the login can be completed. The user is also given the option of terminating the login at that point rather than supplying a new password.^[48]

Each proposed password is checked to ensure that it is not easy to guess.^[49] The criteria include a mixture of case, character type, length, and testing against various word lists and transformations of those lists. Like the Web server system, the development system uses a password hashing scheme based on MD-5.

Although the Drib does not expect to upgrade the methods of authentication on the development system, that system uses PAM to provide a uniform, consistent interface for authentication. The system maintainers found that providing consistency and simplicity, as the interface to PAM does, eases the burden of administration.

To allow developers to access the system from anywhere within the Drib's offices, the development system runs an SSH server. This is configured to accept connections from any system within the internal network. It validates host identities using public key encryption and validates users using public key authentication, smart card authentication, and (if needed) password authentication.^[50] However, to meet item DC3, root access is blocked. A system administrator must log in as an ordinary user and then change to root. To enforce this, the server's configuration file disallows root logins, and the system is set to disallow root logins on all terminals (network terminals and console). Other role accounts simply have a password hash that cannot be produced when any password is entered. Thus, users cannot log into them. To gain access, administrators must use a special program on the workstation that validates their identities, and then checks their authorization to access the desired role account.^[51]

Both the DMZ Web server system and the devnet system use strong authentication measures to ensure that users and hosts are correctly authenticated. The SSH server requires cryptographic authentication of not only the user but also the host from which the user is connecting, and the server responds only to known hosts. Host and user identities are established using the RSA public key cryptosystem. The certificates are initialized by trusted system administrators, so systems that are set up by unauthorized personnel will not be able to connect over SSH to any Drib system.

Both systems also allow reusable passwords. However, the DMZ Web server system uses an MD-5-based hash, whereas the development system uses the traditional UNIX DES-based hash, because it is the version supported by NIS. An undesirable side effect is that reusable passwords on the development system are restricted to a maximum of eight characters, whereas those on the DMZ Web server system may be of arbitrary length. This also explains why the development system uses password aging but the DMZ Web server system does not. Because the users of the Web server system have chosen very long passwords, attackers are expected to take much longer to guess them than if they were only eight characters long, as they are on the development system—assuming that attackers can even get to the SSH server on the DMZ Web server system.

As required by WC5, the Web server runs a minimum set of processes^[52] because its function is only to serve Web pages and batch transactions for off-line processing. The required services are as follows.

Items WC2 and WC3 require each server to run with a minimum of privileges. The SSH and login servers need enough privileges to change to the user logging in. The Web and commerce servers run with minimal privileges, because they only need to access public data. Neither the login nor the commerce server accepts network connections.^[53] The former is tied to specific, hard-wired terminals (such as a console); the latter simply responds to interprocess communication from the Web server.

Consider the level of privilege that the servers need.^[54] The SSH server must run with sysadmin privileges to support the remote access and tunnelling facilities. The login server (if present) must run with this level of privilege also. The Web server requires enough privileges to read Web pages and invoke subordinate CGI scripts. The Web pages can be world-readable, so the Web server simply needs minimal privileges. The CGI scripts manipulate Web pages or generate transaction data, and with appropriate settings of file permissions can write into the Web server's area. The commerce server needs enough privileges to copy transaction files from the Web server area to the transaction spooling area. However, it should not have enough privileges to alter Web pages. Other required servers run with appropriate privileges.

File access is an important issue. File system access control lists^[55] provide one defense. We can adapt another defense from capabilities.^[56] Recall that in a pure capability system, the capability names the object; if the subject does not possess the capability, it cannot even identify an object. An access control-based system does not work this way. However, if we can change the meaning of a file system name, then we can confine all references to a particular part of the file system. The Web server, for example, needs to reference only programs and files within the hierarchy of Web pages (and CGI scripts). The commerce server needs access only to the transaction spooling area and the area where the Web server's CGI script places transactions.

EXAMPLE: Most UNIX systems provide a system call chroot that changes the process' notion of the root of the file hierarchy. For example, suppose a process wishes to open the file /usr/web/pages/index.html.The appropriate system call would be

if ((fd = open("/usr/web/pages/index.html",
        O_RDONLY)) < 0)
        perror("open /usr/web/pages/index.html for reading
          failed");

But the system call chroot(“/usr/web”) changes the process' notion of root to usr/web rather than /. After this, the system call that would open the same file as above is

if ((fd = open("/pages/index.html", O_RDONLY)) < 0)
        perror("open /usr/web/pages/index.html for reading
          failed");

because the kernel maps the first / in /pages/index.html to the directory /usr/web. Every full path name that the process refers to uses /usr/web as its beginning. The process could not directly refer to the file /usr/trans/1.

Depending on the nature of the hierarchy, the process may be able to refer indirectly to the file /usr/trans/1. Some variants of the UNIX system allow the superuser to make links to a directory. Consider the hierarchy shown in Figure 27-1. The directory xdir is a child of trans, so the entry .. in xdir refers to trans. The superuser has created a hard link in web that refers to xdir. Now suppose a process executes the call chroot(“/usr/web”). The process can no longer access /usr/trans/1 by that name, but it can access it as xdir/../1 because the change in root does not affect the interpretation of the path name.

Figure 27-1. A UNIX file system. The directed edges indicate the parents of each directory. A hard link to “xdir” lies in “Web.”

This shows that, in addition to the chroot, the file hierarchy in which the process is rooted must not have any hard links extending to directories not in that file hierarchy.

Finally comes interprocess communication. Processes should be able to communicate only through known, well-defined communication channels.^[57] The issue here is how the Web server communicates with the commerce server to tell it that transaction files are present, and the names of those files.

The simplest method of communication is to use the directory that both the Web server and commerce server share. The commerce server periodically checks for files with names consisting of trns followed by a set of digits. When a transaction begins, the CGI script creates a temporary transaction file. It builds the transaction data and enciphers it using the appropriate public key. It then renames the temporary file with a name consisting of trns followed by the integer representation of the date and time, followed by one or more digits. (See Exercise 5.) When the commerce server checks the directory, it moves any files with that type of name to the spooling area.

If the Web server and commerce server run with the same real or effective UID, or either runs with superuser privileges,^[58] then they can communicate using the UNIX signaling (asynchronous interrupt) mechanism. If an attacker acquires access through the Web server, and can signal the commerce server, then the attacker can damage the Drib with a denial of service attack. Hence, the Web server and the commerce server should run as distinct users, with different privileges.

Unlike the DMZ Web server system, the development workstation serves developers who will compile, test, debug, and manage software. They will also write reports and analyses, communicate with other developers on different systems in the devnet, and send and receive electronic mail over the Internet. The system must support all these functions.

Consider servers and clients first. The devnet workstations may run servers to provide administrative information (such as who is currently logged into the system). These servers require administrative users. As discussed in Section 27.4.2, item DC2 requires these users to be local. Item DC1 requires that users be named (and numbered) consistently. The NIS protocol provides user information to clients, ensuring this consistency. Hence, the devnet workstation runs NIS clients. Similarly, the workstation runs NFS clients to satisfy item DC6. Servers run with the fewest privileges necessary to perform their tasks. In many cases, servers begin with root privileges to open privileged ports. They then drop privileges to a more restricted user.^[59]

Server processes on the development machine run with as few privileges as necessary, as required by item DC2. Whenever possible, they run with the nobody UID and the nogroup GID to ensure that the clients can obtain only information that the developers deem public (that is, available to others within the confines of the Drib's internal network).^[60] When access to privileged ports is required, one of two methods is used. In the first, the inetd daemon (which runs with root privileges) listens for messages at the port. When a message is received, inetd spawns the server with the limited privileges. In the second method, the server starts with root privileges, opens the ports and other files accessible only to root, and drops to a lesser privilege level. This minimizes the actions that the process takes when it has unlimited privilege.^[61] It also allows the operating system to enforce normal file system access checks.^[62] As with the WWW server system, the servers run in a subtree of the file system whenever possible.

To satisfy item DC3, the development system has a logging mechanism that can record any operating system call, its parameters, and the result.^[63] Logged information is recorded locally and sent to a central logging server. The security officers monitor the logs from that server using an intrusion detection system.^[64] If an attack is suspected, the central logging server can instruct the kernel to begin (or cease) recording data to augment the current set of data. Initially, the system logs process initiation and termination, along with the audit UID and effective UID of the user executing the command.

In addition to requiring the use of file servers, item DC6 requires that the workstations have sufficient disk space available for local users' work. To meet this goal, every night, or when disk space reaches 95% of capacity, a program scans the file system and deletes auxiliary files such as editor backup files and files in temporary directories that are not in current use (defined as not having been accessed within the last 3 days).

As required by item DC1, the devnet workstations allow remote access using SSH. This allows devnet users to test software using multiple workstations, which is useful when the software involves network connections or concurrency. It also allows system administrators to log in remotely to perform maintenance activities.

The DMZ Web server system uses a minimalist approach: only those processes necessary for the Web server, remote administration, and the operating system are present. All other processes are eliminated. This requires that any new software be compiled on other systems and that all development be done elsewhere. Only those programs essential to the serving of Web pages, to remote administration, and to the operating system are available. The number of processes active at any time on this system is small.^[65] By way of contrast, the devnet system must provide an environment in which developers can be productive. This requires that more programs be available, and that more processes be active, than on the DMZ Web server system. Compilers, scripting languages, Web servers, and other tools help the developers carry out their tasks.

Both systems run servers with the minimum level of privilege needed. This includes not only minimizing user privileges but also restricting the environment in which the process runs.^[66] The difference between the systems is that the “minimum environment” for the DMZ Web server system is different from the minimum environment for the Web servers on the devnet systems. In the latter, users wish to share data, so users must be able to place data into areas in which the devnet system's Web server can make it available to other users on the development network. The DMZ Web server system has no such requirement.^[67] The root user installs all new Web pages. So the Web server needs to serve data only from a part of the file system to which the root user can write. No other user needs access, except for the commerce user—and that user has tightly restricted access.

Both systems have processes that log information, but the types of the logging processes differ. The devnet system has a log server that accepts messages from other programs, timestamps and formats them, and writes them to locations specified in a control file. This conforms to the way most UNIX-like systems handle logging and allows devnet systems to use off-the-shelf software. The DMZ Web server system has no such daemon. Each program writes log entries to a local log and to a remote daemon on the log server.^[68] This minimizes the number of servers on the DMZ Web server system.

The Web server system's goal is to serve the Web pages. The system programs and configuration files will not change; only the Web pages, log files, and spooling area for the electronic commerce transactions will change. To preserve their integrity, as required by item WC4, all system programs and files are on a CD-ROM. When the system boots, it boots from the CD-ROM. The CD-ROM is mounted as a file system, so even if attackers can break into the Web server, they cannot alter system files or configuration files.^[69] A hard drive provides space for temporary and spooled files, for the home directories of authorized users, and for portions of the Web pages.

Because the Web pages change often, it is not feasible to burn them onto a CD-ROM. However, the CGI programs change very infrequently, and are to be protected from any attacker who might gain access to the system, as required by item WC4. Hence, the Web page root directory, and the subdirectory containing the CGI programs, are on the CD-ROM. In the Web page root directory is a subdirectory called pages that serves as a mount point for a file system on the hard drive. That file system contains the Web pages. In other words, an attacker can alter Web pages, but cannot alter the CGI programs or the internal public key, which is also kept in a directory under the Web page root directory on the CD-ROM. (See Exercise 10.)

When the system boots, one of its start-up actions is to mount two directories from the hard drive onto mount points on the CD-ROM. The hard drive file system containing the Web pages is mounted onto the mount point in the Web page root directory. A separate area, containing user home directories for the system administrators, a temporary file area, and spooling directories for transactions, is also mounted on the root file system.

As dictated by item WC3, the Web server runs confined to the Web page root directory and its subdirectories.^[70] An attacker who compromises the Web server cannot alter the CGI programs, nor add new ones, but can only damage the Web pages on the server.

The commerce server has access to the Web page directory and the spooling area. When a CGI program has processed a request for an electronic transaction, it names the transaction file appropriately (see Section 27.6.1). The commerce server copies the data to the spooling area and deletes the original data. Because the Web server is confined to the Web page partition, an attacker who seizes control of the Web server will be unable to control the commerce server. Moreover, because the CGI programs (and the containing directory) cannot be altered, an attacker could not alter the programs to send raw data to the attacker. Because the CGI programs encipher all data using a public key system before writing the data to disk, the attacker cannot read the raw data there.^[71] The corresponding private key is on the internal network, not the DMZ system, so the attacker cannot decipher the data without breaking the public key system.^[72]

The system administrator partition provides a home directory area when an administrator logs in. It is small and intended for emergency use only.

Finally, WC5 also specifies that the number of programs on the system be minimal.^[73] Fortunately, the system itself requires few programs. No compilers or software development tools are available. Because all executables are statically linked, the dynamic loader is not present (see Exercise 3). The only programs that are available allow the users to log in and out; run commands (command interpreters); monitor the system; copy, create, edit, or delete files; and stop and start servers. Programs such as mail readers, news readers, batching systems (the at and cron commands), and Web browsers are not present. This minimizes what an attacker can compromise.

WC4 suggests that the integrity of the system should be checked. Periodically, or whenever there is a question about the integrity of the system, the Web server is stopped, transaction files are transferred, the system is rebooted from the CD-ROM, the hard drive is reformatted, and the contents of the user and Web page areas are reloaded from the internal Web server system clone mirroring the DMZ system (see Section 26.3.3.2). This restores the Web pages and user directories to a known, safe state. If an attacker has left any back doors or other processes to gather information, the reformatting of the hard drive eliminates them.

The development system's goal is to provide the resources that developers need to develop new software for the Drib's products and (if necessary) infrastructure and systems. This requires a variety of software. A site can take two approaches.

The first approach is to allow each developer to configure his or her own workstation. The Drib rejected this approach because it would create too many different systems for the system administrators to manage. Furthermore, tools available on one workstation might not be available on another, violating the interchangeability required by item DC6. Meeting item DC5 would also be infeasible because read-only media would have to be created for each workstation separately—an effort that was deemed unacceptable.^[74]

The second approach is to develop a standard configuration that provides developers and system administrators with needed software tools and configuration settings. To create such a configuration, the Drib policy managers gathered developers, system administrators, security officers, and all other users of the development workstations. The group developed a configuration that met the Drib's policies and that was acceptable to as many people as possible, and ensured that all members of the group were willing and able to use systems with that configuration.^[75] The system administrators then installed and configured a base system on an isolated workstation system and created a bootable CD-ROM. This CD-ROM was copied and given to all developers. The developers use this CD-ROM to boot their workstations, ensuring that the resulting configuration is the standard one. All updates and upgrades are made to that isolated workstation system and tested, and a new CD-ROM is created. The CD-ROM is copied and distributed to the developers. This eliminates the problem of inconsistent patching or upgrading of workstations.^[76] It also ensures that files are available on all workstations (through mounting of the central file server's file systems) and that the naming scheme is consistent (through use of the same user database system), satisfying items DC1 and DC5. Finally, the local system configurations of all workstations are identical, so all have the same administrative accounts.

Some members of the group pointed out the need for local writable storage. In the event that no file servers are available, the local administrators may need to create files (for example, to save output from a program for analysis). Furthermore, spool files require space, and many programs use temporary storage. Hence, each workstation has a hard drive with several file systems. When the computer boots from the CD-ROM, the root file system is located on the CD-ROM itself. All system programs and configuration files lie on the CD-ROM, as indicated above. During the boot, the workstation mounts the file systems on the hard drive at mount points in the CD-ROM file system. This provides the workstation with appropriate writable storage, satisfying item DC5.

This approach also prevents developers from adding new system programs to the workstations. Programs can of course be added to the writable file systems, but adding a program to the configuration requires that it be added to the isolated system and that new CD-ROMs be burned.^[77] This satisfies part of item DC4. Procedural mechanisms (ranging from warnings to firings) enforce the requirement that programs be inspected before they are added to the writable file system. The organization of the various file systems allows the writable media to be wiped during the boot procedure, eliminating any and all programs added to the workstation. This is part of the recommended boot procedure, but it can be skipped if spool files are queued.

Wiping the writable disks deletes some local log files. However, the logging server also forwards log messages to an infrastructure system that records messages from all workstations. Security analysts examine these logs using various analysis tools, including host-based and network-based intrusion detection tools, to detect misuse and attacks. To validate that the analysis tools are working as expected and are configured correctly, every day the analysts select 30 minutes' worth of log entries and examine them to determine if the analysis tools correctly analyzed those entries. The analysis either validates the security mechanisms and procedures as effective, or reports (or finds) problems. This serves two purposes: validation of the current configuration and software (item DC4)^[78] and detection of security incidents (item DC8).^[79]

The use of read-only media eliminates the need for integrity checking of the development system binaries and configuration files. Scans of the writable media locate files that match patterns of intrusions. When such files are found, the security officer merely reboots the system, wiping the writable hard drive. This cleans up the workstation. An extensive check of the file servers follows.

Both the Web server system and the development system rely on physical protection of media to prevent unauthorized alteration of system programs and configuration files. Both boot from the CD-ROM and use the CD-ROM's file system as the main file system. Because some files on both systems must change (for example, transaction files on the Web server system and spooled files on the development system), both have file systems on writable media that are mounted on the main file system.^[80]

When the Web server system must be reloaded (because the integrity of the system may have been violated), the spooled transaction files are removed from the system, the system is booted, and the writable medium is reformatted. Then the Web pages and user directories are reloaded from a clone kept in a state known to be safe. The development system does not require this, because any nontransient files are kept on a centralized file server that is itself regularly checked. The only local files are temporary files that the users can reinstantiate when they log back in, so the system is simply rebooted and the media reformatted. Because the main file system is on a CD-ROM, its integrity is ensured.

The differences between the approaches used in developing the two CD-ROMs spring from the question of attack from within the company. The developers are all trusted not to attack the workstation, because at any time a developer may have to use any workstation. However, the developers may be used as “vectors of attack” if they should (accidentally or deliberately) make errors in programming or bring in software from untrusted sources.^[81] This led to the consensus-based development of the workstation CD-ROM. The developers had great influence, because they would be using the workstations. Security was a consideration, but it was weighted against productivity and morale. The outer, inner, and devnet firewalls were to provide the bulwark of the security for the development network systems.^[82]

The set of users trusted to work on the DMZ Web server system was much smaller. Thus, the DMZ Web server system was designed to withstand attack from both the Internet and the internal network. For example, the Web server originally was intended to handle transactions; the security people vetoed this as allowing too many potential attacks, and instead suggested the staging approach, in which the DMZ Web server acts as a proxy for the transaction processing systems on the customer data subnet (see Figure 26-1). The construction of the CD-ROM began with the security officers devising the most secure, minimal Web server system they could construct and then adding those features necessary for the Drib's special needs.^[83] They monitor activities on the Web server, and several vulnerability tracking lists and news services, to ensure that they are up to date on all potential problems.

The DMZ Web server system is self-contained in that all files are local. None are served remotely.^[84] If an attacker alters files, a reboot and a reload restore the files to their original state. No other system depends on those files. However, the development workstation relies on file servers. This removes user file integrity from the purview of the development workstation's security. Integrity of the configuration becomes critical, to ensure that the right servers are used, but the CD-ROM ensures that the configuration file data is correct. However, the security of the development systems depends more on the security of the infrastructure of the development network than the security of the DMZ Web server system depends on the security of the infrastructure of the DMZ network.

The Web server on the DMZ Web server system runs a minimal set of services. It keeps everything possible on unalterable media.^[85] Except for the Web server process, the system accepts only enciphered, authenticated connections from a known, trusted host by known, trusted users.^[86]

The Web server process must accept connections from any host on the Internet. However, all such connections go through an outer firewall that can (if desired) be configured to reject requests.^[87] This means that denial of service attacks could be handled at the outer firewall and not by the DMZ Web server.

The Web server and commerce server run with minimal privileges. Neither may communicate with the other except through a shared directory used to transfer transaction requests from the public Web server area to a private spooling area from which they can be retrieved through the enciphered link.^[88] The transaction files themselves are enciphered using a public key algorithm, so an attacker who compromises the Web server cannot alter the transaction files, but can only delete them. To minimize this risk, the commerce server moves the transaction files as quickly as possible to an area that is inaccessible to the Web server.

Access to the administrative account requires that the user access a trusted host (the internal trusted administrative host) and then authenticate to the DMZ Web server using a public key protocol. Automated processes will authenticate on the basis of the host from which they are run, which is the internal trusted administrative host. The SSH server ignores connections from other hosts, and host identity is determined using public key authentication, not IP addresses.

Other servers and programs are simply deleted from the system, so they cannot be run even by accident.^[89] This simplifies system maintenance. It also deprives any attackers of available tools should they penetrate the Web server system.

The development system also runs a minimal set of programs and services.^[90] The notion of “minimal” is different for the development system than for the DMZ Web server system, because the systems must serve many functions. Users compile and debug programs. They test programs, and they integrate different programs into a single software system. They may use ancillary hardware (such as embedded systems) to support the development. The development systems must support this functionality.

Given this, security plays a prominent but not dominant role. Hidden behind three firewalls, each development workstation has sufficient security mechanisms to hinder attackers, and to allow quick recovery if an attack does occur,^[91] but these systems rely more on the infrastructure than does the DMZ Web server system.

The development system allows a large number of users access from any development network system and (possibly) from systems in other subnets of the internal network. User information resides in a centralized repository to maintain consistency across all development systems. Reusable passwords are supported, and password aging is not enforced. However, passwords are tested for strength before they are accepted, and the security officers periodically try to guess passwords. Other password schemes are also supported.

Backups occur daily. Because each workstation has a local writable area, users may keep files in that area rather than place them on the file servers. These areas are backed up. The dumps are typically small, because most users work on directories mounted from the file servers. The main reason for these backups is to preserve the log files should an investigation require them.