Securing a Solaris 8 Server : guide 1
par
popularité : 8%
guide1
Securing a Solaris 8 ServerThis 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:
|
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.
- 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.-
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.
-
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).
-
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.
-
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.
-
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.
-
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):
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):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
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.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
On-line manual pagesNetwork Time ProtocolSUNWdoc Documentation Tools SUNWlibC Sun Workshop Compilers Bundled libC SUNWman On-Line Manual PagesGNU toolsSUNWntpr NTP, (Root) SUNWntpu NTP, (Usr)Various shellsSUNWbash GNU Bourne-Again shell (bash) SUNWgpch The GNU Patch utility SUNWgzip The GNU Zip (gzip) compression utility SUNWless The GNU pager (less)Needed to build many source packagesSUNWtcsh Tenex C-shell (tcsh) SUNWzsh Z shell (zsh)Needed to build BindSUNWarc 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 utilitiesNeeded to build SSHSUNWscpu Source Compatibility, (Usr)Needed to build PostgresSQLSUNWlibm Sun WorkShop Bundled libmMisc. system maintenance stuffSUNWipc Interprocess Communications SUNWlldap LDAP LibrariesSUNWaccr 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:On my SPARCstation LX, the same packages were added, but the descriptions were slightly different.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
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:
There are several packages that, for security reasons, I suggest be installed on any system. These are:#! /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
- 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:
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.find / -local -type f -perm -4000 -exec ls -ld {} \;
The setuid files found on my system, and the action performed, is as follows:
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./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 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:
NOTE: A server should be checked for setgid files after patches are updated, and after third-party packages (source or binary) are installed.find / -local -type f -perm -2000 -exec ls -ld {} \;
The setgid files found on my system, and the action performed, is as follows:
Note 1: These commands are architecture specific. The SPARC versions for a SPARCstation LX are:/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)
/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:
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.find / -local -perm -2 \! -type l -exec ls -ld {} \;
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:
There are also places in this script where ip6_ignore_redirect is set to 0. These lines should be commented out.# 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
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:
Please remember to replace the company name (ABCD Corp) with the name of your company.This system property of ABCD Corp
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
Commentaires Forum fermé