| Previous | Table of Contents | Next |
Some network engineers say that the only way to ensure a networked computer system’s security is to use a one-inch air gap between the computer and the network; in other words, only a computer that is disconnected from the network can be completely secure from network attacks. Although this is a drastic solution, there is always a trade-off between offering functionality and introducing vulnerabilities.
An organized attack on your system will attempt to compromise every software service you offer to the network, such as an FTP archive or web server. For example, permitting electronic mail to cross from the Internet into your internal organizational network means that the firewall must have a network service, such as sendmail running on a dedicated, throw-away host, listening on the SMTP port (TCP/25) and willing to enter into an SMTP protocol exchange with anyone on the Internet. If there are weaknesses in the protocol, errors in the design of the daemon, or misconfiguration problems, your system and network may be vulnerable. Even though an Internet service, such as NCSA’s httpd web server, may be considered secure by some definition today, new releases may introduce vulnerabilities. For example, the introduction of the SITE EXEC command in newer versions of ftpd led to the introduction of a security vulnerability. Administrators must be vigilant against assuming the long-term security of any Internet service. As new vulnerabilities are discovered, administrators can add scans to SATAN to search for these vulnerabilities.
The network protocols themselves can be made secure. New servers that implement the modified protocols must be used, however. A protocol and service is “secure enough” when it has only ITL Class 0 vulnerabilities, as explained later in this chapter. For example, protocols such as FTP or Telnet, which currently send the password in the clear over the network, can be modified to use encryption. Network daemons, such as sendmail or fingerd, can be made more secure by vendors through code review and patching. However, misconfiguration problems, such as the improper specification of netgroups, can lead to vulnerabilities. Also, organizational policies can be very difficult to enforce. For example, even though the IT department of an organization recommends that all computer systems avoid using “+ +” in .rhosts files, it can be difficult to enforce this rule. The IT department can use SATAN to enforce organizational policies by periodically using SATAN to scan all the hosts in the organization.
It is rare to find an organization that has complete control over its computer network. Only the smallest organizations can easily claim daily control over the configuration of all their computer systems. In a large organization, policies and IT groups can and should try to set guidelines for systems, such as not permitting unrestricted NFS access, but the distributed nature of networked systems make this control uncertain.
Many groups and individuals are able to make daily configuration changes to systems on the network, and one vulnerability on any host can endanger the entire network. For example, 500 computers on the U.S. Department of Defense’s MILNET network were successfully attacked in early 1995 because of a single unauthorized Internet gateway that accidentally offered a vulnerability (Leopold, 1995).
With such a dynamic and distributed environment, frequent automated verification is a valuable tool for control. An IT organization can use SATAN to gain such control.
Before looking at potential holes, it is useful to create a classification scale to categorize security holes. This has not been done previously and is introduced in this book as a suggestion for vendors and organizations when prioritizing security problems. This is called the Internet Threat Level scale, or ITL scale. The lowest threat falls into ITL Class 0, and the greatest threat falls into ITL Class 9. Table 8.1 provides descriptions of each ITL Class.
Most security problems can be classified into three major categories, depending on the severity of the threat posed to the target systems:
These classifications can be further split into three finer degrees:
The denial of service attack does not fall cleanly into any category and is listed as ITL Class 0.
| Class | Description |
|---|---|
| 0 | Denial of service attack—users are unable to access files or programs. |
| 1 | Local users can gain read access to files on the local system. |
| 2 | Local users can gain write and/or execution access to non–root-owned files on the system. |
| 3 | Local users can gain write and/or execution access to root-owned files on the system. |
| 4 | Remote users on the same network can gain read access to files on the system or transmitted over the network. |
| 5 | Remote users on the same network can gain write and/or execution access to non–root-owned files on the system or transmitted over the network. |
| 6 | Remote users on the same network can gain write and/or execution access to root-owned files on the system. |
| 7 | Remote users across a firewall can gain read access to files on the system or transmitted over the network. |
| 8 | Remote users across a firewall can gain write and/or execution access to non–root-owned files on the system or transmitted over the network. |
| 9 | Remote users across a firewall can gain write and/or execution access to root-owned files on the system. |
Fixing every security problem and installing every security patch can be an expensive proposition. It might be useful to classify the severity of the threat in order to allocate resources proportional to that severity. For example, if an analysis of your system revealed five Class 1 holes and one Class 9 hole, it would probably be wise to allocate resources toward closing the Class 9 hole. It may not even be necessary to close the Class 1 holes, depending on the importance of the data on the system.
| Previous | Table of Contents | Next |