Ensuring Physical Security
It may seem obvious, but if an intruder can physically access your system, then they may be able to take control of your system without the root password, bypassing all the software-based controls that normally limit such activity. How is this possible? 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 a trivial matter 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:
- FTP 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 the drives on the system.
- Launch a distributed denial of service (DDoS) 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 compromising a system in this way is so easy. 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 theboot command, only the default boot device will be available through go.
To set the security level, use the eeprom command. To set the command level, use the following command:
# eeprom security-mode=command
Or, to set the command level, use the following command:
# eeprom security-mode=full
# 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. You will need to order a new PROM from Sun.
Security Auditing
After installing a new Solaris system and applying the local security policy, you must perform a security audit to ensure that no known vulnerabilities exist in the system, particularly threats posed by remote access. As examined earlier in this chapter, there are a number of strategies, such as switching off ports, that should be adopted prior to releasing a system into production and making it accessible through the Internet.
A security audit should first examine what services are being offered and determine an action plan based on services that should be disabled. In addition, monitoring and logging solutions should be installed for services that are sanctioned, so that it is possible at all times to determine what activity is occurring on any service. For example, a DoS attack may involve hitting a specific port (such as port 80, the Web server port) with a large number of packets, aimed at reducing overall performance of the Web server and the host system. If you don't have logs of all this activity, it will be difficult to determine why your system performance is slow and/or where any potential attacks have originated— that's why TCP wrappers are so important. The final phase of a security audit involves comparing the current list of services running on the system to the security bulletins that are released by the Computer Emergency Response Team (CERT) (http://www.cert.org/) and similar computer security groups. After determining the versions of software running on your system, you should determine which packages require patching and/or upgrading in order to eliminate the risks from known vulnerabilities.
SAINT
Running a security audit and implementing solutions based on the audit can be a time- consuming task. Fortunately, a number of tools are available that can significantly reduce the amount of time required to conduct security audits and cross-check existing applications with known security holes. One of these programs is called SAINT (Security Administrator's Integrated Network Tool), which is freely available from World Wide Digital Security athttp://www.saintcorporation.com/products/saint_engine.html. SAINT, currently in version 3.0, is based in part on an earlier auditing tool known as SATAN. Both SATAN and SAINT have the ability to scan all of your system services and identify potential and/or known vulnerabilities. These are classified according to their risk: Some items may be classified as critical, requiring immediate attention, whereas other items may come in the form of suggestions rather than requirements. For example, while many local services are vulnerable to a buffer overflow, where the fixed boundaries on an array are deliberately overwritten by a remote client to "crash" the system, other issues, such as the use of r-commands, may be risky but acceptable in suitably protected LANs. Thus, SAINT is not prescriptive in all cases, and suggested actions are always to be performed at the discretion of the local administrator.
Some administrators are concerned that using programs such as SAINT actually contributes to cracking and system break-ins, because they provide a ready-made toolkit that can be used to identify system weaknesses in preparation for a break-in. However, if sites devote the necessary resources to monitoring system usage and identifying potential security threats, the risk posed by SAINT is minimal (particularly if its "suggestions" are acted upon). Indeed, World Wide Digital Security actually offers a Web version of SAINT (called WebSAINT) as the basis for security consulting. For a fee, they will conduct a comprehensive security audit of your network, from the perspective of a remote (rather than a local) user. This can be very useful when attempting to identify potential weaknesses in your front-line systems, such as routers, gateways, and Web servers.
This section examines how to install and configure the SAINT program and how to run an audit on a newly installed Solaris 10 system. This will reveal many of the common issues that arise when Solaris is installed out of the box. Most of these issues are covered by CERT advisories. Sun often releases patches very soon after a CERT vulnerability is discovered on shipped Solaris products. For example, a patch is available for a well-known vulnerability existing in the Berkeley Internet Daemon (BIND) package, which matches IP addresses with Fully Qualified Domain Names (FQDNs) (http://www.cert.org/advisories/CA-1999-14.html). However, some CERT advisories are of a more general nature, because no specific code fix will solve the problem. One example is the identification of a DDoS system known as Stacheldraht, which combines the processing power and network resources of a group of systems (which are geographically distributed) and can prevent Web servers from serving pages to clients (http://www.cert.org/advisories/CA-2000-01.html). CERT releases advisories on a regular basis, so it's advisable to keep up-to-date with all current security issues by reading CERT's news.
One of the great strengths of the SAINT system is that it has an extensive catalog of CERT advisories and in-depth explanations of what each CERT advisory means for the local system. Every SAINT vulnerability is associated with a CVE number that matches descriptions of each security issue from the Common Vulnerabilities and Exposures database (http://cve.mitre.org/). Each identified vulnerability contains a hyperlink back to the CVE database, so that information displayed about every issue is updated directly from the source. New patches and bug fixes are also listed.
SAINT has the ability to identify security issues for the following services:
- Domain Name Service (DNS) Responsible for mapping the FQDN of Internet hosts to a machine-friendly IP address. In particular, BIND, which is commonly used for DNS resolution, is susceptible to vulnerabilities.
- Internet Message Access Protocol (IMAP) Supports advanced e-mail exchange facilities between mail clients and mail servers. Like FTP, IMAP has buffer-overflow issues, which have previously allowed remote users to execute privileged commands arbitrarily on the mail server.
- Network File System (NFS) service Shares disk partitions to remote client systems. NFS service is often misconfigured to provide world read access to all shared volumes, when this access should be granted only to specific users.
- Network Information Service (NIS) A distributed network service that shares maps of users, groups, and passwords between hosts to minimize administrative overheads. NIS can be compromised if a rogue user can detect the NIS service operating.
- Sendmail Mail Transport Agent (MTA) Once allowed Solaris commands to be embedded within e-mails, which were executed without authentication on the server side.
SAINT works by systematically scanning ports for services that have well-known exploits, and then reporting these exploits back to the user. In addition, it runs a large number of password checks for default passwords on system accounts, or accounts that often have no passwords. SAINT checks all the services and exploits that it knows about, and the database of known exploits grows with each new release. SAINT also tests the susceptibility of your system to DoS attacks, where a large number of large-sized packets are directed to a specific port on your system. This tactic is typically used against Web servers, where some high-profile cases in recent years have highlighted the inherent weakness of networked systems that allow traffic on specific ports without some kind of regulation. Many of the system daemons checked by SAINT have a so-called "buffer overflow" problem, where a system may be crashed because memory is overwritten with arbitrary values outside the declared size of an array. Without appropriate bounds checking, passing a GET request to a Web server of 1025 bytes when the array size is 1024 would clearly result in unpredictable behavior, because the C language does not prevent a program from doing this. Because Solaris daemons are typically written in C, a number of them have been fixed in recent years to prevent this problem from occurring (but you may be surprised at just how often new weaknesses are exposed).
You can download the latest release of SAINT from the SAINT corporation web site. To run SAINT, you need to install the GNU C compiler or use the Sun C compiler. The Perl interpreter and Netscape Web browser supplied with Solaris 10 are also required. After using make to build the SAINT binary, you can start SAINT by typing this command:
# ./saint
SAINT has several pages, including Data Management, Target Selection, Data Analysis, and Configuration Management. You can visit these pages sequentially to conduct your audit. The Data Management page, shown in Figure 9-6, allows you to create a new SAINT database in which to store the results of your current audit. You can also open an existing SAINT database if you have created one previously, and/or you can merge data from other SAINT scans.
Next, you need to use the Target Selection page to identify the host system that you wish to scan using SAINT, as shown in Figure 9-7. Here, you need to enter the FQDN of the host that you wish to scan. If you have a large number of hosts to scan, it may be more useful to create a file containing a list of hosts. This file could then be used by a system behind the firewall to identify locally visible weaknesses, and used by a system external to the firewall to reveal any threats visible to the outside world. You may also elect to scan all hosts in the LAN, which should be performed only after hours, because it places a heavy load on network bandwidth.
On the Target Selection page, you also need to select a scanning level option, which include the following:
- Light scanning Difficult to detect
- Normal scanning Easy to detect
- Heavy scanning Won't crash Windows NT targets
There is a final option that just checks the "top ten" security flaws, as identified by the report at http://www.sans.org/top20/top10.php. These flaws include BIND weaknesses, vulnerable CGI programs, Remote Procedure Call (RPC) weaknesses, Sendmail buffer overflow, mountd exploits, UNIX NFS exports, user IDs (especially root/administrator with no passwords), IMAP and POP buffer-overflow vulnerabilities, and SNMP community strings set to public and private.
Always remember that attempting to break in to a computer system is a criminal offense in many jurisdictions: You should obtain written authorization from the owner of your system before embarking on a security-related exercise of this kind; otherwise, it may be misconstrued as a real attack.
Once the target selection is complete, the data collection process begins by executing a number of scripts on the server and reporting the results through the Web browser. Data is collected by testing many different Solaris services, including ping, finger, RPC, login, rsh, sendmail, tooltalk, snmp, and rstatd.
SAINT uses several different modules to probe vulnerabilities in the system, including tcpscan, udpscan, and ddos, which scan for TCP and UDP DoS issues, respectively. In addition, a number of well-known username and password combinations are also attempted in order to break into an account—you would imagine that root/root would never be used as a username and password combination, but it does happen.
Once all the data has been collected, the results of the scan are then displayed on the Data Analysis page, as shown in Figure 9-8. It is possible to list vulnerabilities by their danger level, by the type of vulnerability, or by the number of vulnerabilities in a specific category. Most administrators will want to deal with the most dangerous vulnerabilities, so the first option, By Approximate Danger Level, should be selected. In addition, it is possible to view information about the target system by class of service, the type of system, domain name, subnet, and by its hostname.
Vulnerabilities are listed in terms of danger level: critical problems, areas of concern, and potential problems. For the local host okami, which was a standard Solaris install out-of-the-box, two critical problems were identified, both associated with gaining root access via buffer overflow:
- The CDE-based Calendar Manager service may be vulnerable to a buffer- overflow attack, as identified in CVEs 1999-0320 and 1999-0696. The Calendar Manager is used to manage appointments and other date/time–based functions.
- The remote administration daemon (sadmind) may be vulnerable to a buffer- overflow attack, as described in CVE 1999-0977. The remote administration daemon is used to manage system administration activities across a number of different hosts.
There were also two areas of concern identified, with information-gathering vulnerabilities exposed:
- The finger daemon returned personal information about users that could be used to stage an attack. For example, the home directory, full name, and project were displayed (CVE 1999-0612).
Two possible vulnerabilities were identified:
- The chargen program is vulnerable to UDP flooding used in DoS attacks, such as Fraggle (CVE 1999-0103).
Six recommendations were made to limit Internet access, including stopping all the "r" services. These make it easy for a remote user to execute commands on the local system, such as spawning a shell or obtaining information about system load, but have been used in the past to break into systems. In addition, some sendmail commands (such as EXPN and VRFY) are allowed by the sendmail configuration: this allows remote users to obtain a list of all users on the current system, which is often the first step to obtaining their passwords.
If you are concerned that a rogue user may be using SAINT against your network, you may download and run one of the many SAINT-detecting programs (http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html ). These tools monitor TCP traffic to determine whether or not a single remote machine is systematically scanning the ports within a specified timeframe. Obviously, such programs are useful for detecting all kinds of port scanning.
