guide1

Version 1.4 Securing a Solaris 8 Server This web page is a merging of the published security suggestions of several people. These people include Lance Spitzner, Keith Watson and Alex Noordergraaf, among others. It combines, and extends, their ideas using the paranoia I've learned through 22 years of working in the computer field. More information on the source papers can be found in the bibliography. In addition, several people at the San Diego Supercomputer Center (SDSC) assisted me with this web page. That help included: a) Pointing me to additional reference papers, b) Helping with some of the more esoteric technical issues, and c) Proofreading to find glaring technical errors. Finally, Stephanie Gates of The Scripps Research Institute (TSRI) was of enormous assistance in the final editing. This web page was written specifically for the initial release of Solaris 8. Most of the functions performed here will also work on other versions of Solaris, but the exact procedure (file names and variables) may change. Additionally, many of the topics covered in this web page are applicable to other versions of UNIX, and to non-Server systems. Table of Contents: Introduction History of this Web Page Overview Network Topology System Hardware Configuration Initial Installation Minimizing Solaris Minimizing Network Services Remove the Solaris Installation Leftovers Install Necessary Third Party Packages Close the Doors Obscure the Tracks Post the Warnings Perform System Backups Watch for Changes Sources of Tools

1. Introduction

I have 22 years experience in the computer field. Three of these were as a computer operator, and nineteen as a programmer. The last six years, I've also had to do hardware work. I guess that makes me a programmer with a screwdriver. Scary, isn't it?

I used to be employed by Cray, Inc. as a Customer Engineer for the San Diego Supercomputer Center (SDSC). Before that, I worked for the Atlantic Research Corporation (now a part of Computer Sciences Corporation) and Logicon (now a part of Northrop-Grumman).

I was first introduced to the concept of computer security in 1980, when I worked for the government as a computer operator. In 1983, I worked for Logicon developing a Multilevel Secure Operating System. In 1987, I worked for Atlantic Research Corporation developing a B1 secure DBMS command and data filtering system (TruData).

Since 1990, I've worked for Cray. The average Cray customer pays quite a bit for their computer, and they expect to get the full capabilities of what they bought. They do not expect to have it stolen by a resource thief. As part of my job, I've been asked, on occasion, to help ensure that the systems I worked on were appropriately secure.

2. History of this Web Page

I have several computers that the SDSC is kind enough to allow me to place directly on the Internet. One of the policies they have is that if a system is broken into, it will be confiscated for investigation. In order to keep this from occurring, I researched how to secure them. Since there were multiple systems (same operating system), I documented what I had done, so that I could do it again. Tom Perrine, SDSC's senior computer security expert, saw what I had done, and suggested that I give a presentation on it.

Instead of a presentation, I decided to create a paper. This web page is that paper.

3. Overview

The goal of this web page is to demonstrate how to secure a Solaris Server. This demonstration is based on actual experience, not just on theory.

Before going any further, I think I should describe what I mean when I say that a system needs to be secured, and why it needs to be done.

When we secure a server, we take measures to ensure that only those people with a legitimate reason to be on a computer, actually have access to it. We also make sure that those users that do have access to the computer, only have access to their information, and have the ability to allow, or restrict, such access for others.

We are interested in securing servers to keep one person's information from being improperly available to another. We also secure servers to ensure that the disk space, network bandwidth, and CPU resources are available for the intended users.

There are three general classes of people that we're securing the server against. The one thing that people in these classes all have in common is that they're criminals.

"Children" Playing

This class of person compromises more computers than any of the other classes discussed here. Often, it's just a game, to see who can break into the most computers. The most common forms this game takes are Denial Of Service (DOS) attacks, web page defacement, and general vandalism. Sometimes the participants are too young to know that what they're doing is unlawful, but not always.

Resource Thieves

These people want to use the server's resources without paying for it. This use includes using the computer to break into other computers, using it to store information, or using it to send large amounts of E-mail to people who would rather not see it.

Data Thieves

These people are looking for information. Sometimes, they're looking for specific information; other times, they're looking for anything that they find interesting. These people will often use the information they get for their own personal gain, which may include selling it to a competitor.

An extreme version of this type of person might modify the data on your server. This might be done to discredit a person or organization, or to cause incorrect/invalid results or conclusions.

These people are separate and distinct from the commonly found web page defacers and vandals, due to their motivation. The motivation of this group is usually either money or revenge. This motivation tends to create a determination that is not normally found in the other groups.

Here is a list of the various security philosophies whose implementation I discuss in this web page:

Defense in Depth

Defense in Depth is the single most useful concept that I cover here. When used with computer security, it means that you never depend on a single security measure (like a firewall) to keep your system secure. You assume that there's a hole in any security measure you put in place, and provide for it's being broken through.

The goal here is to either have enough security doors blocking the intruder that they give up, and move on, or they run into a door that they don't know how to get through. From the security standpoint, both of these can be considered a win, or at least a draw.

This concept should also be applied to the physical security of a server, and will be discussed in greater depth in the section on System Hardware Configuration.

Less is Better

Less is Better means that the less there is on a system, the more secure the system can be made. It refers to less software, fewer daemons, fewer users logging in, and fewer services being offered.

This concept is why large organizations have dedicated name servers, NFS servers, web servers, time servers, etc..

Strong Configuration Management

Strong configuration management is critical to properly securing a server in the long term. This measure is accomplished by the use of a properly configured change detection system (i.e. Tripwire), and/or a centralized configuration management system (i.e. cfengine). These two tools can be used independently, or together.

The purpose of an intrusion detection system is to inform a system administrator when a possible intrusion has occurred. This detection is often done by looking at the fingerprints of critical system files.

The purpose of a centralized configuration management system is to ensure that each system has the correct configuration at all times. The system should report when a discrepancy is found.

If you wish to run both of these tools, then the intrusion detection system should finish running prior to starting the centralized configuration management system, so that it can properly identify any changes that may have been made.

Hazard Awareness

A system administrator should always be aware of the hazards that come with operating a computer connected to the Internet, and protect against them. Usually, there are multiple ways to secure a service. The system administrator should be aware of the hazards that may arise because one or more of these actions is not performed. Making an informed decision to not close a particular security door is not necessarily bad; not monitoring it is.

Also, there are several security oriented E-mail lists, whose purpose is to keep administrators informed about current security issues. Among these are CERT, Bugtraq (from SecurityFocus) and SANS. URLs for these organizations may be found in the section on Sources of Tools.

Security Through Obscurity

This form of security is done by providing a minimal amount of information on the software configuration, software version, hardware configuration, or even the hardware vendor. Wherever it's possible to NOT provide information, don't provide it. In general, if someone has a legitimate need to know about what's on a system, they'll ask. The reasoning behind this is to never give the intruder a free ride. As an example, if you don't advertise that your web server has PHP, most intruders won't try the PHP exploits.

It should be noted that this security philosophy only serves to muddle the playing field. It is not sufficient, without the support of the other security philosophies described here. The Code Red worm is an example of why this security philosophy is inadequate. It didn't look or ask, it just hit.

Give a warning shot to the chest

This philosophy means that every feasible path into the system should get a warning message, and these messages should be plain, direct and to the point. Don't worry about being excessively polite. On the other hand, don't be excessively abusive.

These messages are not very useful against intrusion, but they may improve your legal position, if an intrusion occurs.

4. Network Topology

This web page is about securing a solaris server, not about creating a secure network infrastructure. It should be used as a rough guide, for the purposes of establishing the level of threat that a system faces.

For most people, the network topology that they use is already set. This section is to help them to understand the strengths and weaknesses of the topology they have to work with. The network administrator should be able to provide further assistance and clarification.

For the lucky few who are building a network from scratch, there's enough information here to give you a general idea of what you want to do, but probably not enough to actually do it. I suggest that you work with your network people, your ISP, a good vendor representative, or a reputable consultant, as this will greatly improve your chances of creating a functional network.

The O'Reilly book Building Internet Firewalls (1) has additional information on network topologies.

The general network topology that I've assumed in the rest of this web page, is a server with one or more network interfaces that are connected to the Internet, without any filters.

If your border router is performing packet level filtering, or if your server is behind a firewall, your server will be more secure from outside attacks. It will not be any more secure from inside attacks. Unfortunately, most disastrous intrusions occur due to inside attacks.

Several general network topologies are available. I have created diagrams of three network topologies that show, in general, how most networks are configured. Each of these will be briefly discussed.

Co-located Server

In this topology, you either own, or rent, a server and place it at an ISP. There is a direct connection from the ISP's router (or switch) to your system, usually over a 100 MegaBit connection. This topology places the highest possible security demands on your server, as it is fully and directly accessible from the Internet. The high speed of the connection will also allow large amounts of data to be transferred if an intrusion occurs.

Flat Network

In this topology, the router is not performing packet filtering. Typically, the decision to not filter packets would be made because the router doesn't have enough CPU power to perform packet filtering. The decision could also be made because the configuration management for the router tables would get too complex, or because a political decision has been made that no packet filtering will be performed. Often, the router will be a DSL or Cable modem. This topology is often used in a Small Office/Home Office (SOHO) network.

Many educational institutions also use this topology, even though they often use leased lines, with several MegaBits per second bandwidth, coupled with powerful routers and switches, and is an example of a political decision to use this topology.

With this topology, all systems on your network are fully and directly accessible from the Internet. The security demands on each system on your network are similar to those for a Co-located Server. The only improvement over the Co-located Server is that the bandwidth through which a compromised system can be exploited is usually lower. In most cases, this network topology is acceptable, only if there are a very small number of systems on your network.

Careful configuration of network routes can improve the security of this topology, but it's a complex task.

VPN connections are possible with this network configuration.

Medium Office Network

This network has the same topology as is shown for the SOHO Network. The primary difference (as far as security is concerned) is that with a Medium Office Network, packet level filtering is being performed in the Border Router. This network topology can be made almost as secure as the Partitioned Network topology. Usually, VLANs are being used in the switch(es), to simplify communications configuration.

The Mac and PC desktops are kept in separate subnets from the rest of the systems, as these systems send more broadcasts. Also, PC systems running Windows are more difficult to secure than UNIX systems.

The Authentication Server and the Internal File Server should both be connected to dedicated switch ports. Both systems should not have any direct communications with external systems.

Properly authenticated users (login and password) of the Dial-in Server should be allowed connections to external systems, in a manner similar to the internal desktop systems, and should receive the same degree of protection. File sharing should only be done to dial-in systems that are appropriately authorized (a separate issue from authentication). Optimally, only secured connections (ssh) to the internal systems should be allowed.

Partitioned Network

This network topology is capable of being very secure. Both the border router and the main router are performing packet filtering. If a firewall is not used, the Medium Office Network configuration can be used, as the second router provides little additional security.

The Firewall system should be capable of monitoring the state of the connection. This monitoring gives a high assurance that connections aren't being made to unprotected internal ports.

Some people feel that a Firewall system gives a false sense of security, and that it's better to not use them, and make sure that all the systems are properly secured. Other people feel that nothing can replace a properly configured Firewall. I fall between these two camps. I feel that a Firewall is useful in adding to the security of a network, but that it should not be relied upon to give complete security.

If additional protection of, and from, the Dial-in Server is desired, it could be connected to a port on the Firewall, thus providing additional protection for both the internal network, and the dial-up user. This may be useful if a user password becomes compromised.

If there exists a portion of the network, where there is external access to the switching and/or communication fabric, then that network should also be connected through the firewall. This lack of security is most often found with wireless networks.

If VPN is used in this configuration, it should be done in the border router. A connection request should not be allowed to enter the border router from the ISP, unless it's for one of the external servers, or for the Firewall. Also, no RPC or UDP requests should be accepted from the ISP, unless they're for one of the external servers that's supposed to receive them, or responses to DNS or NTP requests.

In theory, the capabilities of both the Border Router and the Main Router can be combined into a single router, but this complicates the configuration.

5. System Hardware Configuration

System Placement

The first thing to consider is the physical placement of the server. If you have a location with 24 hour staffing, and adequate power, cooling and connectivity, that's the ideal place to put a server. This would typically be a staffed computer room, or a security office.

If there is no available location that's staffed continuously, then a lockable room (or ventilated cabinet) should be used. Only a minimum number of people should have access to this space. There should be adequate power, cooling (may be difficult for a lockable ventilated cabinet), and network connectivity.

Disk Layout

Most of this subject has little bearing on security, but now is the proper time to consider it. I've searched for information on this topic, but found very little. Due to lack of information, I've assembled some background information, and a few suggestions, based on my experience.

This section does not cover file-system mount options, which does have an impact on security. Those options are covered later in this paper.

Disk Channels

Disks are connected to a computer over channels. The most commonly used types of channels are IDE, SCSI and Fiber Channel. If your server is performing disk intensive operations, then an attempt should be made to maximize the number of channels available.

Channel Contention

IDE Channels

IDE disks are relatively inexpensive, in comparison to SCSI or Fiber, because they are produced in much larger quantities, and because the electronics on the disk is simpler. The drawback is that IDE drives exhibit quite a bit of channel contention. If at all possible, use only one disk per IDE channel. If it's necessary to put a second disk on the channel, one of the disks should have relatively low I/O requirements. No more than two disks can be placed on an IDE channel.

SCSI Channels

SCSI disks usually have a faster access time than IDE disks, and a faster data transfer rate to/from the platter. With UNIX, the actual bus speed has little effect on I/O throughput, as long as it's greater than the platter data speed, because of the buffering that UNIX performs.

SCSI disks are usually priced between two and three times as high per GigaByte as IDE disks. Once the disk I/O requirements exceed what IDE can deliver, it becomes necessary to move to SCSI. SCSI disks have little channel contention, until the bus is saturated with data. With a limit of 15 disk drives (more if Logical Unit Numbers are used), it is not a difficult task to saturate a SCSI bus on a busy system.

Fiber Channels

Fibre channel disks (also spelled fiber) are normally built using the HDA (Head Disk Assembly), and most of the drive electronics of a SCSI drive. Only the physical interface, and a little bit of the microcode (the software that runs on the actual disk drive) needs to be changed. The primary advantage of Fibre disks over SCSI disks is the number of devices that can be put on a single channel (127 vs. 15). Another advantage is that the disks can be located farther from the system.

Fibre channel computer interfaces are available with either copper of optical connections. The copper interconnect cable is less expensive than the optical cable, but the optical interconnect cable is immune to electrical interference, and can be used on longer runs. In any case, the interface to the disk drive is always copper, with any necessary conversion being done in the chassis.

The pricing for Fibre disks is similar to the pricing for SCSI disks. The main reason for the price similarity is that the HDA for a given SCSI disk is normally also used in a Fibre disk, with different interface electronics.

Drive Contention

When there is activity on a single disk drive from multiple sources, this is called drive contention. Proper file-system layout can minimize this, but it usually requires a significant amount of knowledge about the I/O patterns of each file-system. The knowledge to lay out file-systems to minimize drive contention is usually gained from painful experience, and is difficult to put clearly into words.

File-system Layout

As part of the Solaris installation, you will be given a choice between a Custom and an Automatic (default) file-system layout. If you select Custom, you will be asked to enter the information about the file-system layout that you want. The following should be kept in mind when the file-system layout is entered.

1. It is necessary to have both a root and a swap partition. In fact, multiple swap partitions are supported, and, under some circumstances, might be appropriate. Additional information on the swap partition(s) is located near the end of this section.

2. It is possible to have a separate /usr file-system. On desktop workstations, this may be a good idea, but I don't suggest that it be done on a server. One of the problems is that the only way to check the /usr file-system is to boot from an external source (CDROM or Network).

3. I suggest that you establish a separate /var file-system. This is the file-system that is used to spool information to be processed, or that has been processed and is waiting to be returned to the user, and to store logs. It is also the file-system that is used by Solaris to store information on the packages and patches that have been installed. If you do not create a separate /var file-system, then an action that generates large amounts of data for the /var directory tree could easily fill the root file-system, causing the system to exhibit erratic behavior.

   Additionally, if the system is a mail server, then it is often appropriate to have a separate /var/spool/mail file-system. The partition for this file-system should be made significantly larger that you expect will be needed. Other examples of the /var file-system needing to be further subdivided are /var/log on a log server, /var/adm on an accounting server, /var/spool/mqueue on an outgoing mail server, and /var/spool/lpd for a print server.

4. Many of the SUN optional packages, and third-party binary packages, are installed under the /opt directory tree. If you use many of these, it might be a good idea to have a separate /opt file-system. As with the /var file-system, the goal is to keep the root file-system from filling up. Again, the partition for this file-system should be made significantly larger that you expect will be needed.

5. Many of the freeware and source (i.e. GNU) packages are normally installed under the /usr/local directory tree. If there are more than just a few of these, I suggest that you have a separate /usr/local file-system. This will help to keep the /usr file-system (or the root file-system where there is no /usr file-system) from filling up. Again, the partition for this file-system should be made significantly larger that you expect will be needed.

6. The /tmp and /var/run directories are, by default, mounted on top of the swap partition (file-system type of tmpfs). This means that they use the same disk space as the swap partition. It is possible that this could cause a server to run out of swap space, or /tmp space (space in /var/run shouldn't be a problem). If either of these problems arises, or is expected to arise because of an expected heavy load on the /tmp file-system, then it is suggested that a separate partition be allocated for the /tmp file-system. Alternatively, it might be appropriate to allocate more space to the swap partition(s). Never allow the /tmp directory to be left in the root partition.

   This is a tradeoff between speed (tmpfs is very fast, because it's heavily buffered in memory) and contention (is memory to be used for tmpfs or programs). This sort of decision often requires benchmarking to determine the best solution.

Swap

First, it should be noted that calling anything on a Solaris system swap is a misnomer. In reality, the swap partition is used for paging. The name is a carryover from the earlier days of UNIX, when paging wasn't supported, and entire programs had to be moved from memory to disk (swapped).

The swap space on a Solaris system functions as an extension of the memory on the system. Disk space that is used in this manner is referred to as virtual memory. When real memory (the RAM in a system) becomes full, the operating system will move portions of programs (called pages; usually 4096 bytes per page) onto virtual memory. The act of moving pages between real memory and virtual memory is called paging.

Keeping track of these virtual memory pages isn't significantly more complex then keeping track of real memory pages. The problem is that paging from virtual memory back into real memory can be a time consuming task.

When determining the amount of disk space to allocate for swap, you need to consider the maximum possible system memory usage. The sum of real memory and virtual memory (swap space) should be well in excess of the maximum possible system memory usage. This is primarily because applications have a tendency to grow, and users always seem to find something new to run on a system. Although it is theoretically possible to run a Solaris system with no swap space, only an expert should attempt to do so.

Also, when Solaris performs a crash dump, it places the dump into the swap area. As part of the reboot, this dump is read into the /var/crash directory (if dumps are enabled; they are by default). If there is not adequate space in swap to store the dump, then it will be lost. For this reason, it is advised that the swap space be at least as large as real memory. The operation of crash dumps can be altered with the dumpadm command.

Finally, the file-system type of tmpfs uses both real and virtual memory. This creates a very fast file-system, as much of the file-system structure resides in memory. Unfortunately, this file-system format is also transient in nature, as it is lost each time the system is rebooted. By default, the /tmp and /var/run file-systems are mounted as type tmpfs. There are several kernel tuning parameters that adjust the functionality of tmpfs. These are discussed in the Solaris Tunable Parameters Reference Manual (9).

Network Connectivity

When you install a system, you should have a good idea as to how much network connectivity the system will need. If the system is placed in a location where the network connections need to be run, it would be a good idea to make sure that the number of connections run to that location is at least twice the number needed. Allowing for growth will increase the amount of time until additional or replacement network connections need to be run.

Additionally, a server should never be connected to a hub. If possible, a server should receive a dedicated switch port to maximize the bandwidth actually available to the server.

6. Initial Installation

Before installing a Solaris server, disconnect all network interfaces to ensure that there are no intrusion attempts while the installation is occurring, before the system can be properly secured. To transfer data (patches, 3rd party packages and source) to the system being installed, use either CDROM, or tape (or any other non-networked, physically connected device).

Some of the newer SUN systems have neither a CDROM, nor an external SCSI connector. For these systems, you will need to perform the installation from the network. The best way to do this would be to use JumpStart on a fully isolated build network. Additionally, there are several papers on the SUN BluePrints website that cover the JumpStart procedure.

When installing Solaris for a server, it is normally not necessary to start with more than the CORE installation. The current Solaris installation is on two CDROMs. Unfortunately, the installation script isn't smart enough to request the second CDROM, unless Java is installed, and Java isn't part of the CORE installation. For this reason, any additional packages should be installed manually, at a later time. Fortunately, the entire CORE installation resides on the first CDROM.

Set minimum password length

In the /etc/default/passwd file, set the PASSLENGTH variable to 8. This will require that passwords be eight characters long. It should be noted that, with the default password methodology, any portion of the password beyond eight characters is ignored.

Set default password changing parameters

In the /etc/default/passwd file, set the MAXWEEKS variable to the maximum number of weeks that can pass, before a user must change their password. If MAXWEEKS is too short, users will have a tendency to cycle through a list of passwords. This value is normally not set to less than 13 (3 months).

Also, set the MINWEEKS variable to the minimum number of weeks that must pass before a user is allowed to change their password. The purpose of this variable is to lessen the likelyhood that a user will cycle through a password list, or change their password, then change it right back. For this reason, the MINWEEKS variable should not be set too small. On the other hand, if it is set too large, a user might not be able to change their own password, if it were to become compromised. I feel that a value between 2 and 4 is appropriate for this variable.

Finally, set the WARNWEEKS variable to the number of weeks that must pass since the last password change, before a user will receive password change warnings. This number should be slightly shorter than the value the MAXWEEKS variable was set to. If the difference between MAXWEEKS and WARNWEEKS is too small, users might return from a vacation, and find that they can't log in. I feel that the difference should be at least three weeks.

Add critical hosts

The critical hosts should be added to the /etc/hosts file. A critical host is one that is explicitly referenced in one of the other configuration files. Also, all the names for this host should be in the /etc/hosts file. This is done so that system critical issues do not need to have DNS or NIS functioning. Non-critical hosts can be retrieved through DNS.

If your network is small enough, and you don't need to log the host name of external hosts, or connect to external hosts by name, you might be able to use only the /etc/hosts file (preferable, if it can be done).

Add network names

Add the local networks to the /etc/networks file. Typically, you'd only be concerned about those networks you're directly connected to. This makes some of the netstat outputs easier to read and understand.

Configure DNS

Put the appropriate information into the /etc/resolv.conf file (only needed if you're running DNS).

Set hostname lookup

The /etc/nsswitch.conf file needs to be updated. The hosts line should have files as the first entry. Also, the networks line should have files as the only entry. Any references to NIS or NIS+ should be removed from the hosts line.

Update the login scripts

The files /etc/.login, /etc/cshrc and /etc/profile should be updated, as appropriate for your installation. These are the login script for the C-shell, and the startup scripts for the C-shell and the Bourne-shell, respectively.

Set available shells

The file /etc/shells should be updated to list all the commands that will be allowed to be used as shells by various system utilities. These utilities include ftp and sendmail.

Verify console settings

In the file /etc/default/login, ensure that the value for CONSOLE is set to /dev/console, allowing root logins only from the physical console. Solaris should make /dev/console the default, but it needs to be checked.

Use Journalling file systems

In the file /etc/vfstab, add the mount option logging on all mountable local file-systems. In case of a crash, use of a journalled file-system will minimize the corruption; very important for log files.

Install the patches

SUN comes out with a new recommended patch cluster about twice a month. In general, these should be installed as soon as possible after they come out. This is a task that never ends.

When performing the first patch install, the patches should come from a CDROM, or a tape because your network connection is still not connected; an important consideration, as Solaris (as delivered) is not well configured for security.

7. Minimizing Solaris

The CORE installation loads many packages that are not needed for a server to function. Among them are several X11 and OpenWindows packages. Alex Noordergraaf wrote a good paper on how to minimize Solaris (2).

Minimizing Solaris is a simple way of removing potential security issues. As an example, if a hacker knew of a security hole in a specific daemon that's not running, they might try to get it started. If it's not there, then they'd have to find another way in.

The most important thing to consider is that you don't want to remove any packages that are critical to your system. A great amount of care should be taken in removing driver packages. Also, you should have a good understanding of the needs of your application. If a package is needed by your application, it shouldn't be removed. When in doubt, leave it.

The drivers for some of the less frequently encountered hardware may not be include in the CORE installation. If you have hardware in your system that doesn't seem to work, please make sure that the package containing the driver has been installed.

As an example, I have a PC with Solaris 8 installed. The almost minimized package list is as follows (I didn't take the time to try to minimize further):

NCRos86r	NCR Platform Support, OS Functionality (Root)
SUNWadmr	System & Network Administration Root
SUNWadp		Adaptec 29xx/39/xx/78xx Family of SCSI HBA
SUNWcar		Core Architecture, (Root)
SUNWcsd		Core Solaris Devices
SUNWcsl		Core Solaris, (Shared Libs)
SUNWcsr		Core Solaris, (Root)
SUNWcsu		Core Solaris, (Usr)
SUNWdfb		Dumb Frame Buffer Device Drivers (deprecated)
SUNWesu		Extended System Utilities
SUNWkey		Keyboard configuration tables
SUNWkvm		Core Architecture, (Kvm)
SUNWlibms	Sun WorkShop Bundled shared libm
SUNWloc		System Localization
SUNWnamos	Northern America OS Support
SUNWos86r	Platform Support, OS Functionality (Root)
SUNWos86u	Platform Support, OS Functionality (Usr)
SUNWpsdcr	Platform Support, Bus-independent Device Drivers (Root)
SUNWpsdir	Platform Support, ISA Bus Device Drivers, (Root)
SUNWrmodr	Realmode Modules, (Root)
SUNWrmodu	Realmode Modules, (Usr)
SUNWswmt	Install and Patch Utilities

I also have a SPARCstation LX with Solaris 8 installed. The almost minimized package list is as follows (again, I didn't take the time to minimize further):

SUNWadmr	System & Network Administration Root
SUNWcar		Core Architecture, (Root)
SUNWcg6		GX (cg6) Device Driver
SUNWcsd		Core Solaris Devices
SUNWcsl		Core Solaris, (Shared Libs)
SUNWcsr		Core Solaris, (Root)
SUNWcsu		Core Solaris, (Usr)
SUNWdfb		Dumb Frame Buffer Device Drivers
SUNWesu		Extended System Utilities
SUNWkey		Keyboard configuration tables
SUNWkvm		Core Architecture, (Kvm)
SUNWlibms	Sun WorkShop Bundled shared libm
SUNWloc		System Localization
SUNWnamos	Northern America OS Support
SUNWrmodu	Realmode Modules, (Usr)
SUNWswmt	Install and Patch Utilities

Install the minimum number of Solaris packages necessary to perform the required tasks. I added the following packages. Installation of other Solaris or third-party packages may require additional Solaris operating system packages to be installed.

On-line manual pages

SUNWdoc		Documentation Tools
SUNWlibC	Sun Workshop Compilers Bundled libC
SUNWman		On-Line Manual Pages

Network Time Protocol

SUNWntpr	NTP, (Root)
SUNWntpu	NTP, (Usr)

GNU tools

SUNWbash	GNU Bourne-Again shell (bash)
SUNWgpch	The GNU Patch utility
SUNWgzip	The GNU Zip (gzip) compression utility
SUNWless	The GNU pager (less)

Various shells

SUNWtcsh	Tenex C-shell (tcsh)
SUNWzsh		Z shell (zsh)

Needed to build many source packages

SUNWarc		Archive Libraries
SUNWbtool	CCS tools bundled with SunOS
SUNWhea		SunOS Header Files
SUNWsprot	Solaris Bundled tools
SUNWtoo		Programming Tools
SUNWxcu4	XCU4 Utilities
SUNWxcu4t	XCU4 make and sccs utilities

Needed to build Bind

SUNWscpu	Source Compatibility, (Usr)

Needed to build SSH

SUNWlibm	Sun WorkShop Bundled libm

Needed to build PostgresSQL

SUNWipc		Interprocess Communications
SUNWlldap	LDAP Libraries

Misc. system maintenance stuff

SUNWaccr	System Accounting, (Root)
SUNWaccu	System Accounting, (Usr)
SUNWadmc	System administration core libraries
SUNWadmfw	System & Network Administration Framework
SUNWspl		Spell Checking Engine - Base Release (English)
SUNWsutl	Static Utilities
SUNWter		Terminal Information

It should be noted that there are some decisions to be made here. If a package is needed, and the package is available as source (sendmail, NTP, perl, Apache and FTP being examples), it is necessary to decide whether to use the vendor package, or to build from source.

Building from source gives more flexibility in configuration, at the expense of greater system administration time and effort. Also, upgrades and security patches are usually available for source packages sooner.

8. Minimizing Network Services

The primary source for this information is a web page by Lance Spitzner (3).

Most network services are offered by inetd. The file inetd.conf lists the services that inetd is to offer, and what programs to execute when a connection is made to the service. If a line has a '#' as the first character, it will be treated as a comment, and any information that might be there about a service will be ignored.

Each service in the inetd.conf file should be individually analyzed to determine if it is necessary for the system to function properly. In most cases, the answer will be no. If a service is determined to be unnecessary, the line should be commented out, by inserting a '#' as the first character of the line. If you don't know what the service does, try to comment it out, and see is everything still works. NOTE: After the inetd.conf file is changed, the inetd program needs to be instructed to reread the file, by using the kill command to send it a SIGHUP (e.g. kill -1 (PID)).

Some of the services in the inetd.conf file are offered for both IPv4 and IPv6. These services may be identified by the protocol type of tcp6. If it is necessary to leave a service in for IPv4, but disable it for IPv6, the protocol should be changed from tcp6 to tcp. If the server is not running IPv6, then none of the services should be have a protocol of tcp6.

The most commonly used inetd services are telnet and FTP. If secure shell is used, these services can usually be disabled.

Among the least secure services offered by inetd are the R commands. These are rlogin, rexec, rcp and rsh. If at all possible, these services should be disabled in the inetd.conf file.

If the inetd.conf file gets to the point where all of the lines are commented out, then there is no longer any reason to run the inetd daemon. If this occurs, comment out the line that starts inetd, found in the /etc/rc2.d/S72inetsvc file (NOTE: number may not be 72; please check first with ls /etc/rc2.d/S*inetsvc).

Not all network services are offered by inetd. Sometimes, it is either necessary, or faster, to execute a daemon directly, and allow it to wait for connections. Here are the most common of those daemons:

Apache

Apache is an open-source web server, which is provided on the Solaris installation CDROMs. The version provided has only a minimal set of modules, which is not adequate for most web servers. If you are not running a web server, this software should not be installed.

There are modules available for Apache that enable almost any imaginable web functionality. In most cases, to use a module you will have to build Apache from source.

If you choose to run Apache, installed from source, I suggest that you install Apache from the Solaris installation CDROMs, save the startup scripts (/etc/rc2.d/*[Aa]pache*), and remove the package. These startup scripts should work well, as long as Apache is installed in the same location.

Automountd

The automountd daemon is used to automatically mount NFS file-systems when they are needed, and unmount them when they become unneeded. This helps to free up kernel resources, and keep the mount table small.

This might be useful on a desktop system, but I feel that it has no place on a server. When using NFS on a server (hopefully, this isn't too often), the delay for mounting a new file-system is not good, and could cause response problems.

Kerberos Authentication

Kerberos is a protocol for authenticating users. There are both advantages and disadvantages of using Kerberos, as compared to other readily available authentication protocols.

There exists a Kerberos daemon, which only needs to run on the Key Distribution Center (KDC). This daemon performs the tasks of saving user pass phrases, and distributing Kerberos Tickets. It also interfaces with remote Kerberos administration tools. Installation of a KDC, and configuration of Kerberos, is beyond the scope of this web page. For a description of how this is done, please either read the manual pages, or read the Addison-Wesley book Kerberos - A Network Authentication System (4).

Also, there are Kerberized clients (they use Kerberos tickets for authorization) listed in the inetd.conf file. These clients include ktelnet, kftp, krlogin, krlogin, krsh and krcp. Additionally, there exist other Kerberized clients for login, IMAP, POP, and many other authenticated access methods. When using Kerberos, these clients should not be commented out of the inetd.conf file (except, possibly, on the KDC).

LDAP

If it was necessary to install the LDAP package to get a third party package to build, it is normally a good idea to disable the LDAP daemon. To disable the LDAP daemon, enter the following command (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*ldap.client):

mv /etc/rc2.d/S71ldap.client /etc/rc2.d/_S71ldap.client

LPD

The LPD (Line Printer Daemon) is only needed on a system that functions as a print server. Other systems should only have the printer queueing commands (lp, lpc, lpq, lpr and lprm). To disable LPD, remove the SUNWpsr package.

Also, there is a reference to in.lpd in the /etc/inetd.conf file. To disable LPD, this would also have to be disabled.

LPRng

LPRng is a third-party software package, covered by the GPL, that is sometimes used to replace the LPD system. It has several features that make it more useful then the LPD system, under certain circumstances.

When a default install is performed, several files are added to the /etc/rc2.d directory, for the purpose of starting the print daemon. If the system is not functioning as a print server, then the startup of the print daemon should be disabled.

To disable startup of the LPRng print daemon, enter the following commands (NOTE: numbers may not be 60 and 80; please check first with ls /etc/rc2.d/S*lprng):

mv /etc/rc2.d/S60lprng /etc/rc2.d/_S60lprng
mv /etc/rc2.d/S80lprng /etc/rc2.d/_S80lprng

NFS

If the server is on an unprotected network, or if there are users on the network that shouldn't see all the data in the server, then NFS should not be used. To disable NFS, enter the following commands (NOTE: numbers may not be 73 and 15; please check first with ls /etc/rc2.d/S*nfs.client and ls /etc/rc3.d/S*nfs.server):

mv /etc/rc2.d/S73nfs.client /etc/rc2.d/_S73nfs.client
mv /etc/rc3.d/S15nfs.server /etc/rc3.d/_S15nfs.server

NIS

SUN has created a powerful tool called NIS. This tool is very helpful for central configuration control of large groups of systems. Unfortunately, the design did not consider that passwords could be easily broken. Since DES encrypted passwords can no longer be considered to be secure, I strongly suggest that NIS not be used. To disable NIS, remove the SUNWnisu and SUNWnisr packages.

NIS+

As the name implies, this is a followon to NIS. It improves on the power, flexibility and security of NIS. If all (or almost all) of the UNIX systems on your network can use this protocol, it might be worthwhile using. Please note that the servers for NIS+ need to be carefully configured to be properly secure.

The O'Reilly book Managing NFS and NIS (5) has information on properly configuring servers and clients to use NIS+.

NTP

NTP is a package that can be used to synchronize the time on systems. Keeping times in sync is very useful, as it makes the log entries easier to interpret. It is also important when NFS is being used.

Routed

The routed daemon is used to determine where network traffic should go when it leaves a host. If there exists a /etc/defaultrouter file, then the IP address contained in that file would be used as the default route, and the routed daemon will not be started.

The routed daemon is not normally needed, unless a system has multiple network interfaces.

RPC

RPC is a service that allows remote (and local) programs to request that an action be performed. The rpcbind daemon allows remote users to determine what RPC services are being offered. This could allow a potential intruder to scan for hosts with a vulnerable service.

The rpcbind daemon is needed for NFS, NIS and parts of X11, among others. If you aren't running any of these, you may wish to try disabling RPC. To disable RPC, enter the following command (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*rpc):

mv /etc/rc2.d/S71rpc /etc/rc2.d/_S71rpc

When disabling the rpcbind daemon, it is a good idea to make sure that the necessary network services function properly both before and after the change. NOTE: The system should be booted immediately prior to any such testing being done.

If you find that the rpcbind daemon is necessary for proper system functionality, it is possible to use TCP-Wrappers with rpcbind, to limit the hosts that can access the RPC information. For more information on this, please see the documentation that comes with the TCP-Wrappers package.

Sendmail

Most servers have an occasional need to send mail. Although it is not necessary to have sendmail running to send mail, it is often a good idea, as sendmail also scans the mail queues, trying to send out mail that was previously unsendable.

If the server doesn't need to receive mail (it's not one of the mail servers), then the -bd flag should be removed from the execution line. The file where this resides is /etc/rc2.d/S*sendmail. NOTE: With sendmail 8.12 and above, this change will cause locally initiated messages to not be deliverable.

An alternative to removing the -bd flag would be to not start the sendmail daemon, and to run sendmail -q from cron every hour.

If you're running the Solaris 8 sendmail, the configuration file /etc/default/sendmail can be used to disable the receipt of external mail. This file is not included in the initial Solaris 8 release, but it is in one of the update releases, and it is also in the latest patch cluster.

Reguardless of the state of the sendmail daemon on a system, it is critical that the configuration file (usually /etc/mail/sendmail.cf) be properly configured.

SSH

SSH is a secure replacement for telnet and FTP. SSH uses fully encrypted sessions, and allows forwarding of connections (i.e. X11 or FTP forwarding). SSH is discussed more in the section Install Necessary Third Party Packages.

SSH requires that a daemon be running to accept connections. Due to the computational overhead of computing a key pair at startup, this daemon should not be started from inetd.

Syslogd

The syslogd service serves as a way to combine log messages from several sources into a few centrally located log files. It also allows log messages to be sent to another system.

Although the socket that syslogd listens on is a potential security threat, the risks are more than offset by the ability to log information to another system in a timely manner. This ability may provide additional information, in the event of a compromise. For that reason, syslogd should always be used, and, whenever possible, it should be configured to send security related information to another system (i.e. a secured, dedicated log server).

It should be noted that the Solaris 8 syslogd deamon will create a UDP socket for use in sending log information to the remote host, and that the socket will be closed and reopened on a new port every few days. This could cause false positives on a network scan, and on some intrusion detection systems.

If the system will not be receiving messages from another system, then the syslogd daemon should be started with the -t flag. This will cause it to not listen on the UDP socket.

9. Remove the Solaris Installation Leftovers

Much of the information for this section came from a security benchmark by the Center for Internet Security (6).

When the Solaris installation is performed, a significant amount of unnecessary stuff is left behind, which should be cleaned up, to minimize the potential for unauthorized system access and DOS attacks.

Remove reconfiguration scripts.

Three configuration scripts are left behind. The purpose of these scripts is to allow simple reconfiguration, if necessary. The bad news is that these scripts can be triggered just by the creation of a file. Many exploits will allow the creation of such a file. As a result, when the system is rebooted the next time, the startup will be delayed, while the reconfiguration scripts run, and wait for input. Also, when they run, they may destroy some of the previously entered configuration information.

The following commands will keep the system installation configuration scripts from being run at boot time: (NOTE: numbers may not be 30, 71 and 72; please check first with ls /etc/rc2.d/S*sysid.net /etc/rc2.d/S*sysid.sys /etc/rc2.d/S*autoinstall):

mv /etc/rc2.d/S30sysid.net /etc/rc2.d/_S30sysid.net
mv /etc/rc2.d/S71sysid.sys /etc/rc2.d/_S71sysid.sys
mv /etc/rc2.d/S72autoinstall /etc/rc2.d/_S72autoinstall

Remove unneeded accounts

Remove any unnecessary accounts from the system. Usually, this will include listen, nobody4, nuucp, smtp and uucp. The command to do this is passmgmt -d ACCOUNT.

If you are running Sendmail 8.12 or higher, do not remove the smmsp account.

Lock system accounts

Any non-root system accounts (UID < 100) should be locked, so that they can't be used as login accounts. The command to do this is passwd -l ACCOUNT. The login shell should also be changed on these accounts. The most secure login shell I know of is /dev/null, but some IDSs use a special shell to warn of intrusion attempts. The command to change the login shell is passwd -e ACCOUNT.

Set directories for NULL accounts

The accounts nobody, noaccess and nobody4 should have their login directories changed to /dev/null. The command to change the login directory is passmgmt -m -h /dev/null ACCOUNT. The login shell for these accounts should also be changed, as above.

Adjust /etc/inittab for system console

As distributed, the /etc/inittab file allows logins from both the console and the serial ports. This should be changed to allow logins on only one of these. If the keyboard is in use, then the serial ports should be disabled by commenting out the line containing /usr/lib/saf/sac. If a serial console is in use, then the keyboard should be disabled by commenting out the line containing /usr/lib/saf/ttymon.

Remove cachefs startup

In most servers, there is no need for the cachefs daemon. If this is the case, the startup script should be disabled. This can be done by the use of the following commands (NOTE: numbers may not be 73 and 93; please check first with ls /etc/rc2.d/S*cachefs.daemon and ls /etc/rc2.d/S*cacheos.finish):

mv /etc/rc2.d/S73cachefs.daemon /etc/rc2.d/_S73cachefs.daemon
mv /etc/rc2.d/S93cacheos.finish /etc/rc2.d/_S93cacheos.finish

Remove preservation of editor sessions

When the system is taken down (or crashes) and an editor (vi) session is active, the keystroke file is left behind. The startup script /etc/rc2.d/S80PRESERVE copies these keystroke files to the /usr/preserve directory, and sends E-mail to the users whose sessions were saved, informing them of the procedure to recover their sessions.

On most servers, there will be little editing, and this step in the startup procedure need not be done. The following commands will disable the saving of keystroke files during startup: (NOTE: number may not be 80; please check first with ls /etc/rc2.d/S*PRESERVE):

mv /etc/rc2.d/S80PRESERVE /etc/rc2.d/_S80PRESERVE

10. Install Necessary Third Party Packages

Most servers need to have software installed on them that is not part of Solaris, many of which are available as precompiled packages. These can be found on various Internet sites. If you're not sure you can trust the site where you found the package, don't install it. On my Solaris 8 x86 system, the following precompiled packages were added:

GNUbison       GNU bison 1.28 i86pc Solaris 8
GNUgcc         GNU gcc 2.95.2 i86pc Solaris 8
GNUgroff       GNU groff 1.15 i86pc Solaris 8
GNUm4          GNU m4 1.4 i86pc Solaris 8
GNUmake        GNU make 3.78.1 i86pc Solaris 8

On my SPARCstation LX, the same packages were added, but the descriptions were slightly different.

NOTE: The specific packages above are only examples. I installed them on my system, as I prefer to use source releases, whenever possible.

NOTE: Some people prefer to not build packages on the server, but to build them elsewhere, and transfer the installed files. If you have the ability to find every file installed by the package, and a spare system with the same architecture as your server, to do the builds on, this is probably a better idea.

In addition, there are many packages which are available in source form, but are not available precompiled for Solaris. There may also be packages that are available precompiled for Solaris, but with options set that aren't optimum for your installation. In these cases, you will have to locate and download the source package, and compile, test and install it.

When looking for a source package, it is useful to go to the origin site. This is because additional information on the package may be there. The actual package may be retrieved from mirror sites, if it's convenient, as long as the version number is current.

To make upgrades, and patch installation easier, I strongly suggest that you save the commands that you enter to build the packages. Some of these packages are quite complex to build. An example of this is the command sequence I used to build GAS:

#! /bin/sh
echo Building GAS
if [ -d binutils-2.10.1 ]
then
    rm -rf binutils-2.10.1
fi
cp dist/src/binutils-2.10.1.tar.gz .
gunzip binutils-2.10.1.tar.gz
tar xf binutils-2.10.1.tar
rm binutils-2.10.1.tar
cd binutils-2.10.1
./configure
cd bfd
make
cd ../libiberty
make
cd ../gas
make
make install
cd ../..
echo GAS Complete

There are several packages that, for security reasons, I suggest be installed on any system. These are:

LSOF

This package is very useful for tracking down possible problems in a system.

SSH

This package (from SSH Communications Security) can be used to replace both telnet and FTP (along with the remote commands: rlogin, rexec, rcp and rsh). It uses fully encrypted sessions. It also allows ports to be forwarded through it, allowing encrypted remote X11 access.

Another version is available from OpenSSH. There is an excellent paper out (12) that covers the installation of OpenSSH on a Solaris system.

SUDO

This package allows a system administrator to give limited super-user permissions to individual users.

TCP Wrappers

This package can be used to filter access to a system, based on the service being requested, and the client host.

Before building TCP Wrappers, change LOG_MAIL to LOG_AUTH, everywhere in the Makefile (it's in several places).

To allow extended option processing, the make command must contain the option STYLE=-DPROCESS_OPTIONS.

The minimum configuration only needs the /etc/hosts.allow file. The first line of the file should be ALL:localhost:ALLOW. The last line should be ALL:ALL:DENY. Placing the line ALL:ALL:DENY into the /etc/hosts.deny file can slightly increase your security.

11. Close the Doors

Many of the items in this section came from two papers by Alex Noordergraaf and Keith Watson (7 and 8), and a document from SUN (9). There is also information here from a web page by Lance Spitzner (3).

Add administrative group

Add the group wheel (or some similar name) to the /etc/group file, making sure that the GID is unique. This will be the group that can perform privileged functions.

Create Administrator Login

Create the login account for the primary administrator. This is not root, but the user that will log in, then su as necessary. Use the useradd command with the -d and -m options to do this. This user should be a member of the administrative group (wheel). Please remember to set a password immediately.

Check setuid files

Check for setuid files, and modify them, as appropriate. The command to check for these files is:

find / -local -type f -perm -4000 -exec ls -ld {} \;

Some files must be left unchanged (/usr/bin/login, /usr/bin/passwd). Other files may have their group set to the administrative group (wheel), and have their modes changed to 4750 (/usr/sbin/ping, /usr/sbin/traceroute). Still others may be removed. NOTE: A server should be checked for setuid files after patches are updated, and after third-party packages (source or binary) are installed.

The setuid files found on my system, and the action performed, is as follows:

/bin/su				set administrative group
/sbin/su.static			set administrative group
/usr/bin/at			set administrative group (1)
/usr/bin/atq			set administrative group (1)
/usr/bin/atrm			set administrative group (1)
/usr/bin/crontab		set administrative group (1)
/usr/bin/eject			set administrative group
/usr/bin/fdformat		set administrative group
/usr/bin/login			leave alone
/usr/bin/newgrp			leave alone
/usr/bin/passwd			leave alone
/usr/bin/pfexec			set administrative group (1)
/usr/bin/rcp			set administrative group (1)
/usr/bin/rdist			set administrative group
/usr/bin/rlogin			set administrative group (1)
/usr/bin/rsh			set administrative group (1)
/usr/bin/i86/ps			leave alone (3)
/usr/bin/i86/uptime		leave alone (3)
/usr/bin/i86/w			leave alone (3)
/usr/bin/su			set administrative group
/usr/bin/tip			set administrative group (4)
/usr/bin/yppasswd		remove (2)
/usr/lib/acct/accton		set administrative group
/usr/lib/fs/ufs/quota		leave alone (4)
/usr/lib/fs/ufs/ufsdump		set 555 mode
/usr/lib/fs/ufs/ufsrestore	set 555 mode
/usr/lib/pt_chmod		leave alone
/usr/lib/sendmail		leave alone
/usr/lib/utmp_update		leave alone
/usr/local/bin/lpq		leave alone
/usr/local/bin/lprm		leave alone
/usr/local/bin/lpr		leave alone
/usr/local/bin/lpstat		leave alone
/usr/local/bin/ssh1		leave alone
/usr/local/bin/ssh-signer2	leave alone
/usr/local/sbin/lpc		leave alone
/usr/sbin/allocate		leave alone (4)
/usr/sbin/deallocate		leave alone (4)
/usr/sbin/list_devices		leave alone (4)
/usr/sbin/mkdevalloc		leave alone (4)
/usr/sbin/mkdevmaps		leave alone (4)
/usr/sbin/ping			set administrative group
/usr/sbin/sacadm		set administrative group
/usr/sbin/i86/whodo		leave alone (3)
/usr/sbin/traceroute		set administrative group

Note 1: For these commands, it might be preferable to create another group (the privileged group), similar to the administrative group, but with more members. The members of the administrative group should also be members of this group.

Note 2: For some reason, SUN leaves this link to /bin/passwd around, even after all the NIS packages have been removed. If NIS isn't being used, this should be removed.

Note 3: These commands are architecture specific. The SPARC versions for a SPARCstation LX are:

/usr/bin/sparcv7/ps
/usr/bin/sparcv7/uptime
/usr/bin/sparcv7/w
/usr/sbin/sparcv7/whodo

Note 4: For these commands, it might be preferable to place them into a privileged group (see Note 1) and change their mode to 4750, or remove them.

Check setgid files

Check for setgid files, and modify them, as appropriate. The command to check for these files is:

find / -local -type f -perm -2000 -exec ls -ld {} \;

NOTE: A server should be checked for setgid files after patches are updated, and after third-party packages (source or binary) are installed.

The setgid files found on my system, and the action performed, is as follows:

/usr/bin/mail			leave alone
/usr/bin/mailx			leave alone
/usr/bin/netstat		leave alone
/usr/bin/passwd			leave alone
/usr/bin/write			leave alone
/usr/bin/yppasswd		remove
/usr/platform/i86pc/sbin/eeprom	set 2550 mode (1)
/usr/sbin/i86/prtconf		set 2550 mode (1)
/usr/sbin/i86/swap		set 2550 mode (1)
/usr/sbin/i86/sysdef		set 2550 mode (1)
/usr/sbin/wall			set 2550 mode
/usr/xpg4/bin/i86/ipcs		set 2550 mode (1)

Note 1: These commands are architecture specific. The SPARC versions for a SPARCstation LX are:

/usr/platform/sun4m/sbin/eeprom
/usr/sbin/sparcv7/prtconf
/usr/sbin/sparcv7/swap
/usr/sbin/sparcv7/sysdef
/usr/xpg4/bin/sparcv7/ipcs

Check for world writable files and directories

Check for world writable files and directories, and modify them, as appropriate. The command to check for these files is:

find / -local -perm -2 \! -type l -exec ls -ld {} \;

NOTE: A server should be checked for world writable files and directories after patches are updated, and after third-party packages (source or binary) are installed.

The world writable files and directories found on my system, and the action performed, is as follows:

/var/sadm/install/.pkg.lock	set 644 mode
/var/adm/spellhist		leave alone, or remove
/var/mail			leave alone on mail server;
				otherwise remove
/var/preserve			remove
/var/spool/pkg			set 750 mode
/var/tmp			set 1755 mode
/tmp				set 1755 mode
/tmp/.s.PGSQL.5432		leave alone (used by DBMS)

In addition to the above files, there were many device nodes (under /dev and /devices). These are either protected by the device driver, or not in need of protection (i.e. /dev/null).

Check permissions on /tmp and /var/tmp

The permissions on /tmp and /var/tmp should be set, both before and after the file-system mounts are performed. This can be done by entering the following commands:

echo '#! /bin/sh' > /etc/rc2.d/S00setmodes
echo '' >> /etc/rc2.d/S00setmodes
echo 'chmod 1755 /tmp' >> /etc/rc2.d/S00setmodes
echo 'chmod 1755 /var/tmp' >> /etc/rc2.d/S00setmodes
chmod 744 /etc/rc2.d/S00setmodes
ln /etc/rc2.d/S00setmodes S02setmodes

Set permissions on /etc/security

Change the mode of the /etc/security directory to 750.

Lock down remote commands

The files /etc/hosts.equiv, /.rhosts and /.netrc should be removed, touched and chmoded to 0. Doing so will lock out the remote commands for root. Some people suggest that these files be removed. I feel that it's easier for an intruder to create a file than it is for them to remove, then create a file.

Other people suggest that empty (mode=0, owner=root) directories be placed here. Using directories, instead of empty files, adds a minor improvement in security, but at an increase in potential confusion.

Disable rhost authentication

In the file /etc/pam.conf, comment out all lines that contain pam_rhosts_auth. If the remote commands (rlogin, rexec, rcp and rsh) have been left in the /etc/inetd.conf file, they will require passwords.

Disable dialup authentication

In the file /etc/pam.conf, comment out all lines that contain pam_dial_auth. If the system has modems connected, do not do this.

Lock down cron and at commands

The cron and at commands should be locked down, so that only those users who have a need of them will be allowed to. To lock these commands down, the /etc/cron.d/cron.allow and the /usr/lib/cron/at.allow files will need to be modified. The following commands will initialize these files for minimal usage:

echo 'root' > /etc/cron.d/cron.allow
echo '' > /usr/lib/cron/at.allow
chmod 644 /etc/cron.d/cron.allow /usr/lib/cron/at.allow

If a user needs access to either the cron or at command, their login should be added to the appropriate file.

Enable cron logging

Enable cron logging of executed commands by adding the following line to the /etc/default/cron file.

CRONLOG=YES

Disable execution of stack

Add the following two lines to the /etc/system file, to disallow execution of instructions in the stack. In 32-bit architectures, this should not be done if debuggers are to be used on the system, as they break debuggers. This is not usually a problem on servers. Also, on x86 architectures, these two lines don't do anything.

The reason for adding these settings is that many buffer overflow problems are related to execution of code on the stack. Although it is possible to exploit a buffer overflow with these settings, it is much more difficult.

set noexec_user_stack=1
set noexec_user_stack_log=1

Ignore NFS requests from non-privileged ports

Add the following line to the /etc/system file to cause NFS to ignore requests originating on non-privileged ports (over 1024). This change should be made, even if NFS has been disabled.

set nfssrv:nfs_portmon=1

Inhibit core dumps

Add the following line to the /etc/system file to keep core files from being generated.

set sys:coredumpsize=0

System crash dumps

System crash dumps can be both good and bad. They can be bad, as they introduce the ability for an experienced Solaris person to extract passwords, or other critical information. On the other hand, they are very helpful for solving problems related to system crashes. If you have either the ability to perform a crash analysis, or a support contract that covers crash analysis, then I feel that the benefit outweighs the risk.

If you have neither the ability, nor a support contract that includes crash analysis, then you should disable copying of crash dumps into /var/crash. This may be done by entering the following commands (NOTE: number may not be 71; please check first with ls /etc/rc2.d/S*savecore):

mv /etc/rc2.d/S75savecore /etc/rc2.d/_S75savecore

Set query port for Bind Version 8

In Bind version 8, it is possible to set the source port number for queries to remote systems. This should be set to port number 53, by placing the following line into the options section of /etc/named.conf, and restarting named. This simplifies firewall configuration, as allowing port 53 (UDP and TCP) through the firewall is all that's required for DNS to function properly.

query-source address * port 53

Create ftpusers file

In Solaris, the /etc/ftpusers file is used to limit the users who have access to FTP. As a minimum, root, and all users that have login disabled, should be in this file. If FTP is not to be used on this system, the entire user population should be listed in this file.

Anonymous FTP

Anonymous FTP carries with it special hazards. When running Anonymous FTP, it is important to follow all of the directions included with the FTP package you use.

One additional hazard is that special attention should be paid to any directory in which anonymous users are allowed to have write permissions. If they are also allowed read or directory permissions, your system could easily be subverted for use as a server for unlawful or unwanted data. Although you would be unlikely to face criminal charges, you could easily find that your server is confiscated (at least temporarily) by law enforcement agencies.

Disable IP forwarding

To disable IP forwarding, you should touch the /etc/notrouter file. This file should exist, even if there is only one network interface on your system.

Use random IP sequence numbers

In the file /etc/default/inetinit, change the value of TCP_STRONG_ISS to 2 to generate random sequence numbers, instead of the default randomly incrementing sequence numbers. This change is made for the purpose of combating IP spoofing attacks.

Close off IP security holes

Add the following commands to the /etc/rc2.d/S69inet script (NOTE: number may not be 69; please check first with ls /etc/rc2.d/S*inet). Detailed information on what the individual changes mean can be found in the Solaris Tunable Parameters Reference Manual (9). These commands should be located immediately after the ISS generation is set:

# Change LOTS of network parameters.  This should help to secure
# the system against some types of Denial Of Service attacks, and
# intrusion attempts.  It will also keep us from forwarding Denial
# Of Service attacks to other networks.

# Combat ARP DOS attacks by flushing entries faster.
/usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60000
/usr/sbin/ndd -set /dev/ip ip_ire_arp_interval 60000

# Combat ICMP DOS attacks by ignoring them.
/usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0
/usr/sbin/ndd -set /dev/ip ip6_respond_to_echo_multicast 0
/usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
/usr/sbin/ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0

# Ignore redirect requests.  These change routing tables.
/usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1
/usr/sbin/ndd -set /dev/ip ip6_ignore_redirect 1

# Don't send redirect requests.  This is a router function.
/usr/sbin/ndd -set /dev/ip ip_send_redirects 0
/usr/sbin/ndd -set /dev/ip ip6_send_redirects 0

# Don't respond to timestamp requests.  This may break rdate
# on some systems.
/usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp 0

# If a packet isn't for the interface it came in on, drop it.
/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1
/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1

# Don't forward broadcasts.
/usr/sbin/ndd -set /dev/ip ip_forward_directed_broadcasts 0

# Don't forward source routed packets.
/usr/sbin/ndd -set /dev/ip ip_forward_src_routed 0
/usr/sbin/ndd -set /dev/ip ip6_forward_src_routed 0

# Combat SYN flood attacks.
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 8192

# Combat connection exhaustion attacks.
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024

# Don't forward reverse source routed packets.
/usr/sbin/ndd -set /dev/tcp tcp_rev_src_routes 0

# Combat IP DOS attacks by decreasing the rate at which errors
# are sent.
/usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 1000
/usr/sbin/ndd -set /dev/ip ip_icmp_err_burst 5

There are also places in this script where ip6_ignore_redirect is set to 0. These lines should be commented out.

SUN also has a package called nddconfig that performs these functions. It is one of their BluePrint security tools. It performs most of the functions of the above, but it has been tested to work on all versions of Solaris from 2.5.1 to 8.

Disable Multicast

Multicast is used to send data to multiple locations, using only a single address. If the server doesn't use Multicast (most don't), it should be disabled. This can be done by commenting it out of the /etc/rc2.d/S72inetsvc file (NOTE: number may not be 72; please check first with ls /etc/rc2.d/S*inetsvc). It is near the end of the file, and well commented.

Set up accounting

The system accounting information is very useful for determining the extent of an intrusion. The information stored in the accounting records may indicate what actions were performed by the intruder, thus giving an idea as to the extent of the intrusion, and possibly the reason.

Also, The system accounting information may be useful in monitoring a system for intrusions. This information is used to determine changes in user behavior. As the number of systems being monitored increases, the usefulness of manual monitoring of this data decreases. This is due to the limited amount of time available to check the results.

If the monitoring of accounting data is automated, the usefulness of accounting data for intrusion detection remains high with more systems. To perform this properly would require a complex database system. It would also normally require several months of usage, before it could put out useful information.

As an example, if a user has been using 45MB of their 1GB quota, and their usage jumps to 950MB, then there has been a change that should be checked. This change could be due to a runaway program. It could also be due to an intrusion.

To run accounting, the SUNWaccr and SUNWaccu packages must be installed. Also, the following lines should be added to the crontab for the root user.

#
# The root crontab should be used to perform accounting data collection.
#
0 * * * * /usr/lib/acct/ckpacct > /dev/null 2>&1
0 23 * * * /usr/lib/acct/dodisk / /var /usr/local > /dev/null 2>&1
59 23 * * * /usr/lib/acct/runacct > /dev/null 2>&1

The dodisk line should list all file-systems that you want to run disk accounting on. This should include all local file-systems that are normally mounted read/write.

Quotas

Quotas don't help to secure a system against intrusion, but can be used to limit the amount of data that an intruder can store on the system. On the other hand, poorly administered quotas could cause user data to receive lower security than is appropriate.

Quotas are a two-edged sword. Proper usage of quotas (along with user education) will tend to create a cooperative user community, which should tend to reduce the amount of time that a system administrator needs to spend on solving disk space issues. Also, if a user account is compromised, quotas can limit the amount of data that an intruder can store on the system.

On the other hand, by controlling quotas too tightly, and not considering the needs of the users it's possible to create a situation where the users ignore security to find a place to put their files. In extreme cases, this could become a security problem.

In general, normal users shouldn't be writing data in the root, /usr, /usr/local or /var (exclusive of /var/tmp) file-systems. The non-root usage of these file-systems should be static, and the root usage should change slowly, or not at all.

With respect to users, quotas are best used to remind users when it's time to clean up their files, and to keep runaway programs from filling an entire file-system. Currently, disk is so inexpensive that for the effort required to minimize space usage, it would have been cheaper to just buy more disk. Obviously, this philosophy has limits, but if users are often hitting their disk quotas, the system administrator might want to try to determine the root cause for the problem.

NTP

In the NTP configuration file, include the entry restrict default ignore after the servers and/or peers are set. After this, add specific permissions that you want hosts to have.

Enable logging

You should touch the log files /var/adm/loginlog, /var/adm/sulog, and /var/adm/tcpdlog. The daemons think that if the log file isn't there, then they shouldn't do logging.

Enable inetd logging

The inetd daemon posts listens, according to the /etc/inetd.conf file. When a connection occurs, inetd executes the appropriate command, and waits for another connection. By adding the -t option to the inetd invocation (in /etc/rc2.d/S72inetsvc), you can cause inetd to use the syslog daemon to log all connections. The daemon facility is used at the notice priority. This should be done, even if inetd is disabled in /etc/rc2.d/S72inetsvc.

Log FTP sessions

The in.ftpd daemon is executed by the inetd daemon when a connection is made to the TCP port 21 (if FTP is enabled in /etc/inetd.conf). By adding the -l option to the in.ftpd invocation (in /etc/inetd.conf), you can cause in.ftpd to log all sessions via the syslogd daemon. The daemon facility is used at the notice priority. This should be done, even if in.ftpd is disabled in /etc/inetd.conf.

Limit nscd caching

The nscd daemon is used by Solaris to cache frequently used data. This daemon's abilities have grown considerably, since it's inception as a Name Service Cache Daemon. These extra abilities can easily be disabled. It is not suggested that the nscd daemon be disabled, as that can cause severe problems.

A sample /etc/nscd.conf file, which minimizes the functionality of nscd, is as follows:

logfile                 /var/adm/nscd.log
enable-cache		passwd		no
enable-cache		group		no
positive-time-to-live   hosts           3600
negative-time-to-live   hosts           5
suggested-size          hosts           211
keep-hot-count          hosts           20
old-data-ok             hosts		no
check-files		hosts           yes
enable-cache		exec_attr	no
enable-cache		prof_attr	no
enable-cache		user_attr	no

If your system has any instability with respect to host names and/or IP addresses, it is possible to substitute the following line for all the above lines containing hosts. This may slow down host name lookups, but it should fix the name translation problem.

enable-cache		hosts		no

Set mount options

SUN suggests that the nosuid (no setUID) mount option be set on the /var file-system. I feel that this is probably a good idea.

SUN also suggests that the ro (read-only) mount option be set on the /usr file-system. This has good effects, but it requires that additional work be done prior to adding patches. In particular, it requires that the file-system be remounted read-write. This can be done with the /etc/mount -o remount,rw /usr. Unfortunately, the only way to return to read-only is to reboot the system. Since a reboot is often done after patches are installed, the inability to return to read-only could be only a minor nuisance.

They also suggest that whenever possible, other file-systems be mounted with either the ro option, the nosuid option, or, even better, both options. This may be quite difficult, politically.

The ro option might be useful on an archive file-system. The nosuid should always be used on NFS mounted file-systems, and may be appropriate for local file-systems containing users' home directories.

Vold

The vold daemon is used to automatically mount removable media (CDROM, Floppy, Optical, JAZ and ZIP). This simplifies the process of mounting removable media, but creates a potential security issue, if an unauthorized person gains access to the system. Also, this daemon, although potentially useful, is not normally necessary. My advice is to not use it. To disable vold, remove the SUNWvolg, SUNWvolr and SUNWvolu packages.

Also, the /etc/rmmount.conf file should be configured to mount file-systems with the -o nosuid flag set. This flag would be placed on the mount line for the file-system.

Set user file creation mask

In each of the files /etc/.login, /etc/cshrc and /etc/profile, there should be an invocation of the umask command. This invocation should be positioned immediately after the initial comments. The value passed to umask is an octal mask of the mode bits that are not set when a file is created. Acceptable values are 022, 026 (suggested) and 027. Each of these has advantages and disadvantages. Please read the umask manual page prior to selecting the value to be set.

Set FTP file creation mask

Add the following line at the end of the /etc/default/ftpd file. If there is another line for UMASK, it should be commented out. This line contains the default umask value that will be used by FTP when a file is created. The value shown here is for demonstration purposes only. The umask value chosen for the user file creation mask (above) should be used.

UMASK=026

Set system startup file creation mask

The default umask during system startup should be changed from 000 (022 in Solaris 8) to 077. This change can be done by entering the following commands:

echo '#! /bin/sh' > /etc/rc2.d/S00UMASK.sh
echo '' >> /etc/rc2.d/S00UMASK.sh
echo 'umask 077' >> /etc/rc2.d/S00UMASK.sh
chmod 744 /etc/rc2.d/S00UMASK.sh

Set the PROM security mode

For SPARC systems, use the eeprom Solaris command, or the setenv OpenBoot command to set the security-mode variable to either command or full. It should be noted that on some systems, setting security-mode to full will disable auto-boot.

For a PC, the BIOS usually has a value that can be set to require a password prior to booting, or prior to entering BIOS. The procedures for this are different from system to system. Setting the BIOS to require a password prior to booting will disable autoreboot.

Set the PROM password

For SPARC systems, use the eeprom Solaris command, or the setenv OpenBoot command to set the security-password variable to the password you'd like to use. NOTE: If you forget this password, it is very difficult to reset, and will usually require a service call.

For a PC, the BIOS usually has a password that can be set. The procedures for this are different from system to system. NOTE: If you forget this password, you will have to reset all the BIOS parameters to factory default to clear the password, which will require setting a jumper on the motherboard.

Disable keyboard abort

For SPARC systems, you may want to disable the keyboard abort sequence (L1-A). If the system hangs, this will require a power cycle to initiate a reboot. If you want to do this, use the eeprom Solaris command, or the setenv OpenBoot command to set the keyboard_abort variable to disable. This may not be available in older systems.

12. Obscure the Tracks

The goal for this step is to locate the source of messages that a potential intruder can receive, and do whatever can be done, to make them as generic as possible. Remember, any message your computer sends may be used against it.

Apache

After the ServerType line, there should be a line that says ServerTokens Prod. This change will remove the Apache version number and the list of available modules from responses.

Bind (version 8)

In the options section, add the line version "DNS";. This string (DNS) will be given out as the server description.

FTP

This information is covered in the Post the Warnings section.

Sendmail

In the .mc file that is used to generate the sendmail.cf file, set the confSMTP_LOGIN_MSG variable to be $j Sendmail; $b. This change will remove the sendmail version number from responses.

If you are using the default SUN sendmail, then the configuration file (usually /etc/mail/sendmail.cf) should be modified, setting the variable SmtpGreetingMessage to $j Sendmail; $b.

Telnet

This information is covered in the Post the Warnings section.

SSH

When using the -v flag of ssh, I know of no way to disable the version number exchange, short of modifying the code.

13. Post the Warnings

This section describes how to post warnings so that they will be seen by users. I strongly suggest that the exact wording of these messages be checked by your legal department.

/etc/default/telnetd

Add the following line at the end of this file. If there is another line for BANNER, it should be commented out. This line contains a message that will be displayed when a telnet connection occurs. This should be done, even if telnet is disabled.

BANNER="\r\nWARNING: Authorized use only.  Usage may be monitored.\r\n\r\n"

/etc/default/ftpd

Add the following line at the end of this file. If there is another line for BANNER, it should be commented out. This line contains a message that will be displayed when a FTP connection occurs. This should be done, even if FTP is disabled.

BANNER="\r\nWARNING: Authorized use only.  Usage may be monitored.\r\n\r\n"

/etc/motd

Place the following message (or a similar one) into this file. It contains a message that will be printed after a successful login.

This is a private computer facility.  Access for any reason must be
specifically authorized by the owner.  Unless you are so authorized,
your continued access and any other use may expose you to criminal
and/or civil proceedings.  Usage may be monitored.

/etc/issue

Place the following message (or a similar one) into this file. It contains a message that will be printed during the login process.

This is a private computer facility.  Access for any reason must be
specifically authorized by the owner.  Unless you are so authorized,
your continued access and any other use may expose you to criminal
and/or civil proceedings.  Usage may be monitored.

NOTE: The users may see both the /etc/motd and the /etc/issue messages when they login.

Boot PROM

The SPARC Boot PROM can store a warning message, to be displayed at boot time. This message is stored in the oem-banner environment variable, which should be set as follows:

This system property of ABCD Corp

Please remember to replace the company name (ABCD Corp) with the name of your company.

14. Perform System Backups

System backups of servers should be done on a regular basis. The backups of the system file systems should be done to non-networked media that can be read after performing only a CORE install, or even better, from the boot CDROM. Networked backup usually requires that much more than the CORE install be done to perform a restore, and therefore may not be appropriate for the system file-systems (i.e. root, /usr and /var).

Additionally, if an intrusion occurs, there is no guarantee that you will be able to identify all the files that have been modified. For that reason, the suggested resolution is to either reinstall from scratch, or to rebuild from backups that you know to be from prior to the intrusion.

15. Watch for Changes

Install a package to inform you about changes to configuration files, and other critical files (executables and shells). There are several packages available to do this.

ASET

ASET is a SUN package for Solaris (SUNWast). It's fairly good, but the SUN security experts recommend against using it. The reason for this was not obvious from the message. Based on this, I wouldn't use it.

Axe Handle

This is a set of scripts that I created. Their purpose is to look for the results of a successful intrusion. This tool examines files and network status. These scripts are available for use under the GNU Public License.

COPS

This tool was developed at Purdue University. It primarily searches for new security problems in a system, but is also useful in securing a system initially.

Tripwire

Tripwire is the most frequently used intrusion detection tool. It is available in both commercial and freeware versions.

For those with a bit less paranoia (or a bit more scripting / programming skill), a simple set of scripts could be constructed to perform similar functions. I have done this, and found that it only takes a few hours to create a rather flexible, and powerful, tool. The advantage provided is that you will know exactly how it works.

Now, it is time to reconnect your system to the network. All reasonable security measures have been put in place, along with the appropriate monitoring tools.

16. Sources of Tools

Here are some tools that you may find useful in securing your Solaris server. In general, I don't like to use tools to perform this function. The reason is that I like to know what changes were made, so that they can be monitored. Most tools hide the details of their actions, so that you don't know what was changed, and can't monitor the changed files, to determine if an intrusion has occurred.

fix-modes

Fix-modes was created by Casper Dik to adjust the permissions of several files and directories in Solaris, for the purpose of improving security. It is available from ftp://ftp.wins.uva.nl/pub/solaris/fix-modes.tar.gz.

It is also available from SUN, under http://www.sun.com/blueprints/tools.

JASS Toolkit

The JASS toolkit was developed by SUN to simplify building secured Solaris systems. It is available from http://www.sun.com/blueprints/tools. There exists good documentation for the current release (0.3) of this toolkit. The best of the documents is the Internals document (11). This document provides fair detail as to what the toolkit actually does.

If you choose to use the JASS toolkit, please be aware that it will be necessary to verify that the changes you made previously are still in place after JASS runs.

Titan

The Titan toolkit was created by Brad Powell to fix or tighten potential security holes in UNIX (Solaris, Linux and FreeBSD). It is available from http://www.fish.com/titan.

Here is a short list of web sites that you may find useful.

• sunsolve.Sun.COM/pub-cgi/show.pl?target=home - SUN Recommended & Security Patches
• web.mit.edu/kerberos/www - Kerberos home page
• www.auscert.org.au - Australian Computer Emergency Response Team
• www.cert.org - CERT Coordination Center
• www.cisecurity.com - The Center for Internet Security
• www.fish.com - Dan Farmer's web site with lots of computer security related stuff
• www.ibiblio.org/pub/solaris/sparc - Solaris Package Archive (SUNSite)
• www.infrastructures.org/cfengine - Cfengine
• www.rootprompt.org - Root Prompt -- Nothing but Unix
• www.sabernet.net/papers/Solaris.html - Solaris Security Guide
• www.sans.org - SANS Institute
• www.securityfocus.com - SecurityFocus
• www.solarisguide.com - SolarisGuide.com
• www.sun.com/bigadmin - Sun Large System Administration
• www.sun.com/blueprints - SUN Blueprints
• www.sun.com/security/blueprints - SUN Security Blueprints
• www.sun.com/security/jass - Additional information on the SUN JASS toolkit
• www.sunfreeware.com - Sunfreeware

Bibliography

1. Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper and D. Brent Chapman (ISBN 1-56592-871-7).
2. Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology by Alex Noordergraaf.
3. Armoring Solaris and Armoring Solaris: 2 by Lance Spitzner.
4. Kerberos - A Network Authentication System by Brian Tung (ISBN 0-201-37924-4).
5. Managing NFS and NIS by Hal Stern, Mike Eisler and Ricardo Labiago (ISBN 1-56592-510-6).
6. Center for Internet Security Solaris Security Benchmark
7. Solaris Operating Environment Security by Alex Noordergraaf and Keith Watson.
8. Solaris Operating Environment Network Settings for Security by Alex Noordergraaf and Keith Watson.
9. Solaris Tunable Parameters Reference Manual
10. Solaris Security by Peter H. Gregory (ISBN 0-13-096053-5).
11. The Solaris Toolkit - Internals by Alex Noordergraaf and Glenn Brunette.
12. Building and Deploying OpenSSH for the Solaris Operating Environment by Jason Reid and Keith Watson.

To contact ACCS:

P.O. Box 948316
La Jolla, CA 92037-8316
Phone: (858) 689-ACCS
Email: sales@accs.com

If you have comments or suggestions, please E-mail webmaster@accs.com