Tactical Options | Solaris System Management (New Riders Professional Library)

A number of tactical options are available to the system manager of a Solaris network to help tighten up the security and make it much more difficult for unauthorized access to be gained . Some of these are discussed in the next sections. This is not an exhaustive discussion, but it provides a good indication of the type of action that can be taken to protect a business from malicious and, in some cases, accidental incidents.

Routing Options

By default, Solaris runs the routing daemon (in.routed). It allows routes to be dynamically added to the routing table instead of statically routing through a known gateway. Greater security and control of network routes can be achieved by creating the file /etc/defaultrouter and adding an entry containing either the name or the IP address of the primary router that the system uses. When the system is next rebooted, only the default route defined in this file will be used. Further routes can be manually added using the route command.

setuid and setgid Programs

Quite a number of programs make use of the setuid and setgid features of Solaris. Some, such as the passwd command, are needed, but others are not. setuid programs are not normally recommended because they pose added security risk. Also, when there are a large number of them on the system, it is difficult to spot a potential cracker adding one more!

The system manager should have a policy whereby setuid programs are closely managed. One good way of doing this is to collect a list of setuid and setgid programs and then compare them regularly to see if any unauthorized ones have been added.

To obtain a list of programs that have the setuid bit set, use the following command:

 find  /  -perm 4000 -print

Or, another way:

 find  /  -perm -u+s -print

The lists should be saved in a secure location and be used as a baseline template for comparisons to be made.

If any programs have the setuid or setgid bit set, then they should be reviewed to see if this is really necessary. Those that are not deemed necessary should have the bit(s) removed. As an example, consider the program ufsdump in the directory /usr/lib/fs/ufs. The only time that this program is used is by the superuser (root), and the program is already owned by user root. The setuid bit can easily be removed from this program without causing adverse affects on anything else.

Logging of Repeated Failed Login Attempts

Detailed logging of failed login attempts can be obtained by creating a file called loginlog. These three commands set this up correctly:

 touch /var/adm/loginlog  chmod 600 /var/adm/loginlog  chgrp sys /var/adm/loginlog

The addition of this extra logging causes an entry to be written to the log file if five failed login attempts occur. The majority of the time, it is simply a user that has forgotten the password, but it could also alert the system manager (or administrators) to an intruder trying to guess passwords.

Disabling or Removing Unnecessary Services

If a particular service is not required, it should be disabled and then removed. By leaving it, the company could be exposing itself to an avoidable risk of intrusion. For example, if NFS is not being used, then comment out or remove the relevant entries in the /etc/services file, and rename or remove the scripts in /etc/rc2.d and /etc/rc3.d that automatically start NFS at system startup.

Many network facilities are started via the inetd process, its configuration file being /etc/inetd.conf. Each of the facilities listed in this file should be inspected to see whether it is appropriate for the specific environment ”if not, then disable it by commenting out the entry or removing it. For example, if a company requires a more secure system, then it is a good idea to replace the standard /etc/inetd.conf file with one that just allows Telnet and FTP services (if these are required). A very good example of a network service to disable is finger because it has been known to have security problems.

Making Use of Groups

When administering user accounts, many companies create the accounts with a group of staff or general. This is less secure and potentially allows user accounts to have access to files and data that should be restricted. It is a better policy to create groups for relevant sections or functions, and then modify them as necessary when further access is required. For finer management of permissions, a combination of groups and ACLs (mentioned earlier in the "Bundled with Solaris" section) can be used.

For example, when defining groups for sections, possible candidates could be sales, marketing, or personnel. Here, the accessibility of unauthorized data is immediately reduced, preventing staff from sections outside of personnel from reading sensitive files. The other popular alternative for grouping user accounts is by function, such as sysadmin, which provides greater privilege for system administrators yet does not require them to always use the superuser account (root). Management would be a further function grouping allowing managers from various sections to share information requiring limited access, such as sensitive reports or financial data.

Top