Security Auditing

Security Auditing

After installing a new Solaris system, and applying the local security policy, a security audit must be undertaken to ensure that no known vulnerabilities exist in the system, particularly threats posed by remote access. As we have examined earlier, 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 denial of service 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.

Tip 

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, there are a number of tools 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, which is freely available from World Wide Digital Security at http://www.wwdsi.com/saint/. SAINT, currently in version 3.0, is the Security Administrator’s Integrated Network Tool, and 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 critical, requiring immediate attention, while 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” remote access commands, may be risky but acceptable in suitably protected local area networks. 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 like SAINT actually contribute 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 uses 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 frontline systems, such as routers, gateways, and web servers.

In this section, we will examine how to install and configure the SAINT program, and run an audit on a newly installed Solaris 9 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 that exists on shipped Solaris products is discovered. 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 (http://www.cert.org/advisories/CA-99-14-bind.html). However, some CERT advisories are of a more general nature, since no specific code fix will solve the problem. One example is the identification of a distributed denial of service system known as “Stacheldraht,” which combines the processing power and network resources of a group of systems (that 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 their 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 will contain 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), which is responsible for mapping the fully qualified domain name of Internet hosts to a machine-friendly IP address. In particular, the Berkeley Internet Daemon (BIND), commonly used for DNS resolution, is susceptible to vulnerabilities.

  • File Transfer Protocol (FTP), which allows remote users to retrieve files from the local file system, has historically been associated with serious daemon buffer overflow problems.

  • Internet Message Access Protocol (IMAP), which supports advanced e-mail exchange facilities between mail clients and mail servers, also has buffer overflow issues, which have previously allowed remote users to execute privileged commands arbitrarily on the mail server.

  • Network File System (NFS) service, which shares disk partitions to remote client systems, is often misconfigured to provide world read access to all shared volumes, when this access should only be granted to specific users.

  • Network Information Service (NIS), which is a distributed network service that shares maps of users, groups, and passwords between hosts to minimize administrative overheads, can be compromised if a rogue user can detect the NIS service operating.

  • Sendmail Mail Transport Agent (MTA), which once allowed Solaris commands to be embedded within e-mails that 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 password. SAINT checks all of 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 denial of service attacks, where a huge 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 will 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, as the C language does not prevent a program from doing this. Since Solaris daemons are typically written in C, a number 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).

The latest release of SAINT may be downloaded from http://www.wwdsi.com/saint/. To run SAINT, you will need to install the GNU C compiler or use the Sun C compiler. The Perl interpreter and Netscape web browser supplied with Solaris 8 or later are also required. After using make to build the SAINT binary, SAINT can be started by typing the command

# ./saint

This starts up the Netscape web browser, with the URL shown in Figure 7-3.

Click To expand Figure 7-3: Security Administrator’s Integrated Network Tool

SAINT has several pages, including data management, target selection, data analysis, and configuration management. These pages can be visited sequentially in order to conduct your audit. The data management page, shown in Figure 7-4, allows you to create a new SAINT database in which to store the results of your current audit. Alternatively, you may open an existing SAINT database if you have created one previously, and/or merge data from other SAINT scans.

Click To expand
Figure 7-4: The Data Management page

Next, you will need to use the target selection page to identify the host system that you wish to scan using SAINT, as shown in Figure 7-5. Here, you need to enter the fully qualified domain name of the host that you wish to scan. Alternatively, 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 local area network, which should only be performed after hours as it places a heavy load on network bandwidth.

Click To expand
Figure 7-5: The Target Selection page

You also need to select a scanning level option, which includes the following:

  • Light scanning, which is difficult to detect.

  • Normal scanning, which is easy to detect.

  • Heavy scanning, which won’t crash Windows NT targets.

  • Heavy+ scanning, which may well 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/topten.htm. These flaws include BIND weaknesses, vulnerable CGI programs, Remote Procedure Call (RPC) weaknesses, sendmail buffer overflow, mountd, 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, UDP, and denial of service 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 of the data has been collected, the results of the scan are then displayed on the Data Analysis page, as shown in Figure 7-6. 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 should be selected. In addition, it is possible to view information about the target system by class of service, type of system, domain name, subnet, and hostname.

Click To expand
Figure 7-6: The Data Analysis page

Vulnerabilities are listed in terms of danger level: there are critical problems, areas of concern, and potential problems, as shown in Figure 7-7. 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 CVE 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.

Click To expand
Figure 7-7: Identifying vulnerabilities

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 was displayed (CVE 1999-0612).

  • The remote users list daemon was active, providing a list of users on the system to any remote user (CVE 1999-0626). Like the finger daemon, information gathered from the ruserd could be used to stage an attack.

Two possible vulnerabilities were identified:

  • The chargen program is vulnerable to UDP flooding used in denial of service attacks, such as Fraggle (CVE 1999-0103).

  • The sendmail server allows mail relaying, which may be used by remote users to forward mail using the server. This makes it easy for companies promoting SPAM to make it appear as if their mail originated from your server.

Six recommendations were made to limit Internet access, including stopping all of 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, such as Courtney (http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html#Courtney). Courtney monitors TCP traffic to determine whether or not a single remote machine is systematically scanning the ports within a specified timeframe. Obviously, this program is useful for detecting all kinds of port scanning, and not just SAINT.

aset

The Automated Security Enhancement Tool (aset) is supplied by Sun as a multilevel system for investigating system weaknesses. In addition to reporting on potential vulnerabilities, aset can actually fix problems that are identified. There are three distinct operational levels (low, medium, and high) for aset:

  • Low level Undertakes a number of checks, and reports any vulnerabilities found. No remedial action is performed.

  • Med level Undertakes a moderate number of checks and reports any vulnerabilities found. Restricts system access to some services and files.

  • High level Undertakes a wide range of checks and reports any vulnerabilities found. Implements a restrictive security policy by enforcing pessimistic access permissions.

Low-level reports are recommended to be run as a weekly cron job, allowing administrators to determine if newly installed applications, services, or patches have compromised system security. In contrast, a medium-level aset run should be performed on all newly installed systems that lie behind a firewall. For all systems that are directly connected to the Internet, such as web and proxy servers, a high-level aset run should be performed directly after installation. This will ensure that many of the default system permissions that are assigned to system files are reduced to an appropriate scope. It is possible to modify the asetenv file to change the actions that are performed when aset is executed. The individual tasks performed by aset include:

  • tune Checks all file permissions.

  • cklist Validates system directories and file permissions.

  • usrgrp Checks user accounts and groups for integrity.

  • sysconf Verifies the system files stored in /etc.

  • env Parses environment variables stored in configuration files.

  • eeprom Checks the security level of the OpenBoot PROM monitor.

  • firewall Determines whether or not the system is secure enough to operate as a packet filter.

TCP Wrappers

Logging access information can reveal whether an organization’s networks have an authentication problem. In addition, specific instances of unauthorized access to various resources can be collated and, using statistical methods, assessed for regular patterns of abuse. Monitoring of log files can also be used by applications to accept or reject connections, based on historical data contained in centralized logging mechanisms provided under Solaris, such as the syslogd system logging daemon.

One reason why access monitoring is not often discussed is that implementations of the standard UNIX network daemons that are spawned by the Internet superserver inetd (discussed earlier) do not have a provision to write directly to a syslog file. Later Internet service daemons, such as the Apache web server, run as stand-alone services not requiring inetd, but have enhanced logging facilities that are used to track web site usage.

Wietse Venema’s TCP Wrappers are a popular method of enabling daemons launched from inetd to log their accepted and rejected connections, since the wrapper programs that are installed for each service do not require alterations to existing binary software distributions or to existing configuration files. TCP Wrappers can be downloaded in source form from ftp://ftp.porcupine.org/pub/security/index.html.

In their simplest form, TCP Wrappers are used for monitoring only, but they could be used to build better applications that can reject connections on the basis of failed connections. For example, a flood of requests to log in using rsh from an untrusted host could be terminated after three failed attempts from a single host. TCP Wrappers work by compiling a replacement daemon that points to the “real” daemon file, often located in a subdirectory below the daemon wrappers. The wrappers log the date and time of a service request, with a client hostname and whether the request was rejected or accepted. The current version of TCP Wrappers supports the SVR4 (System V Release 4) TLI network programming interface under Solaris, which has equivalent functionality to the Berkeley socket programming interface. In addition, the latest release supports access control and detection of host address or hostname spoofing. The latter is particularly important in the context of authentication services that provide access to services based on IP subnet ranges or specific hostnames in a local area network: if these are spoofed, and access is granted to a rogue client, the entire security infrastructure has failed. It is critical to detect and reject any unauthorized connections at an early stage, and TCP Wrappers are an integral part of this mechanism.

When writing access information to syslog, the output looks like this:

Nov 18 11:00:52 server in.telnetd[1493]: connect from client.site.com
Nov 18 11:25:03 server in.telnetd[1510]: connect from workstation.site.com
Nov 18 11:25:22 server in.telnetd[1511]: connect from client.site.com
Nov 18 12:16:30 server in.ftpd[1556]: connect from workstation.site.com

These entries indicate that between 11:00 A.M. and 1:00 P.M. on November 18th, clients connected using telnet from client.site.com and workstation.site.com. In addition, there was an FTP connection from workstation.site.com. Although we’ve only examined wrappers for in.ftpd and in.telnetd, wrappers can be compiled for most services launched from inetd, including finger, talk, tftp (trivial ftp) and rsh (remote shell).



Part I: Solaris 9 Operating Environment, Exam I