Chapter 2 Managing Machine Security (Overview)

Keeping a machine's information secure is an important system administration responsibility. This chapter provides overview information about managing machine security.

The following is a list of the overview information in this chapter.

• Controlling Access to a Computer System

• Controlling Access to Devices

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

• Reporting Security Problems

Controlling Access to a Computer System

In the workplace, all machines that are connected to a server can be thought of as one large multifaceted system. You are responsible for the security of this larger system. You need to defend the network from outsiders who are trying to gain access to the network. You also need to ensure the integrity of the data on the machines within the network.

At the file level, the Solaris OS provides standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are mostly the same. The first line of security defense is to control access to your system.

You can control and monitor system access by doing the following:

• Maintaining Physical Security

• Maintaining Login Control

• Controlling Access to Devices

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

• Reporting Security Problems

Maintaining Physical Security

To control access to your system, you must maintain the physical security of your computing environment. For instance, a system that is logged in and left unattended is vulnerable to unauthorized access. An intruder can gain access to the operating system and to the network. The computer's surroundings and the computer hardware should be physically protected from unauthorized access.

You can protect a SPARC system from unauthorized access to the hardware settings. Use the eeprom command to require a password to access the PROM. For more information, see How to Require a Password for Hardware Access.

Maintaining Login Control

You also must prevent unauthorized logins to a system or the network, which you can do through password assignment and login control. All accounts on a system should have a password. A password is a simple authentication mechanism. An account without a password makes your entire network accessible to an intruder who guesses a user name. A strong password algorithm protects against brute force attacks.

When a user logs in to a system, the login command checks the appropriate name service or directory service database according to the information that is listed in the /etc/nsswitch.conf file. This file can include the following entries:

• files – Designates the /etc files on the local system

• ldap – Designates the LDAP directory service on the LDAP server

• nis – Designates the NIS database on the NIS master server

• nisplus – Designates the NIS+ database on the NIS+ root server

For a description of the nsswitch.conf file, see the nsswitch.conf(4) man page. For information about naming services and directory services, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+).

The login command verifies the user name and password that were supplied by the user. If the user name is not in the password file, the login command denies access to the system. If the password is not correct for the user name that was specified, the login command denies access to the system. When the user supplies a valid user name and its corresponding password, the system grants the user access to the system.

PAM modules can streamline login to applications after a successful system login. For more information, see Chapter 17, Using PAM.

Sophisticated authentication and authorization mechanisms are available on Solaris systems. For a discussion of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.

Managing Password Information

When users log in to a system, they must supply both a user name and a password. Although logins are publicly known, passwords must be kept secret. Passwords should be known only to each user. You should ask your users to choose their passwords carefully. Users should change their passwords often.

Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords. You can also disable a user account by locking the password. For detailed information about administering passwords, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration and the passwd(1) man page.

Local Passwords

If your network uses local files to authenticate users, the password information is kept in the system's /etc/passwd and /etc/shadow files. The user name and other information are kept in the password file /etc/passwd. The encrypted password itself is kept in a separate shadow file, /etc/shadow. This security measure prevents a user from gaining access to the encrypted passwords. While the /etc/passwd file is available to anyone who can log in to a system, only superuser or an equivalent role can read the /etc/shadow file. You can use the passwd command to change a user's password on a local system.

NIS and NIS+ Passwords

If your network uses NIS to authenticate users, password information is kept in the NIS password map. NIS does not support password aging. You can use the command passwd -r nis to change a user's password that is stored in an NIS password map.

If your network uses NIS+ to authenticate users, password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users only. You can use the passwd -r nisplus command to change a user's password that is stored in an NIS+ database.

LDAP Passwords

The Solaris LDAP naming service stores password information and shadow information in the ou=people container of the LDAP directory tree. On the Solaris LDAP naming service client, you can use the passwd -r ldap command to change a user's password. The LDAP naming service stores the password in the LDAP repository.

In the Solaris 10 release, password policy is enforced on the Sun Java^TM System Directory Server. Specifically, the client's pam_ldap module follows the password policy controls that are enforced on the Sun Java System Directory Server. For more information, see LDAP Naming Services Security Model in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Password Encryption

Strong password encryption provides an early barrier against attack. Solaris software provides four password encryption algorithms. The two MD5 algorithms and the Blowfish algorithm provide more robust password encryption than the UNIX algorithm.

Password Algorithm Identifiers

You specify the algorithms configuration for your site in the /etc/security/policy.conf file. In the policy.conf file, the algorithms are named by their identifier, as shown in the following table.

Algorithms Configuration in the policy.conf File

The following shows the default algorithms configuration in the policy.conf file:

#
…
# crypt(3c) Algorithms Configuration
#
# CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to
# be used for new passwords.  This is enforced only in crypt_gensalt(3c).
#
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6

# To deprecate use of the traditional unix algorithm, uncomment below
# and change CRYPT_DEFAULT= to another algorithm.  For example,
# CRYPT_DEFAULT=1 for BSD/Linux MD5.
#
#CRYPT_ALGORITHMS_DEPRECATE=__unix__

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=__unix__
…

When you change the value for CRYPT_DEFAULT, the passwords of new users are encrypted with the algorithm that is associated with the new value. When current users change their passwords, how their old password was encrypted affects which algorithm is used to encrypt the new password.

For example, assume that CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 and CRYPT_DEFAULT=1. The following table shows which algorithm would be used to generate the encrypted password.

For more information on configuring the algorithm choices, see the policy.conf(4) man page. To specify password encryption algorithms, see Changing the Password Algorithm (Task Map).

Special System Logins

Two common ways to access a system are by using a conventional user login, or by using the root login. In addition, a number of special system logins enable a user to run administrative commands without using the root account. As system administrator, you assign passwords to these login accounts.

The following table lists some system login accounts and their uses. The system logins perform special functions. Each login has its own group identification number (GID). Each login should have its own password, which should be divulged on a need-to-know basis.

Remote Logins

Remote logins offer a tempting avenue for intruders. The Solaris OS provides several commands to monitor, limit, and disable remote logins. For procedures, see Securing Logins and Passwords (Task Map).

By default, remote logins cannot gain control or read certain system devices, such as the system mouse, keyboard, frame buffer, or audio device. For more information, see the logindevperm(4) man page.

Dial-Up Logins

When a computer can be accessed through a modem or a dial-up port, you can add an extra layer of security. You can require a dial-up password for users who access a system through a modem or dial-up port. The dial-up password is an additional password that a user must supply before being granted access to the system.

Only superuser or a role of equivalent capabilities can create or change a dial-up password. To ensure the integrity of the system, the password should be changed about once a month. The most effective use of this feature is to require a dial-up password to gain access to a gateway system. To set up dial-up passwords, see How to Create a Dial-Up Password.

Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The dialups file contains a list of ports that require a dial-up password. The d_passwd file contains a list of shell programs that require an encrypted password as the additional dial-up password. The information in these two files is processed as follows:

• If the user's login shell in /etc/passwd matches an entry in /etc/d_passwd, the user must supply a dial-up password.

• If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If the login shell field in /etc/passwd is empty, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If /etc/d_passwd has no entry for /usr/bin/sh, then those users whose login shell field in /etc/passwd is empty or does not match any entry in /etc/d_passwd are not prompted for a dial-up password.

• Dial-up logins are disabled if /etc/d_passwd has the /usr/bin/sh:*: entry only.

Controlling Access to Devices

Peripheral devices that are attached to a computer system pose a security risk. Microphones can pick up conversations and transmit them to remote systems. CD-ROMs can leave their information behind for reading by the next user of the CD-ROM device. Printers can be accessed remotely. Devices that are integral to the system can also present security issues. For example, network interfaces such as hme0 are considered integral devices.

Solaris software provides two methods of controlling access to devices. Device policy restricts or prevents access to devices that are integral to the system. Device policy is enforced in the kernel. Device allocation restricts or prevents access to peripheral devices. Device allocation is enforced at user allocation time.

Device policy uses privileges to protect selected devices in the kernel. For example, the device policy on network interfaces such as hme requires all privileges for reading or writing.

Device allocation uses authorizations to protect peripheral devices, such as printers or microphones. By default, device allocation is not enabled. Once enabled, device allocation can be configured to prevent the use of a device or to require authorization for access to the device. When a device is allocated for use, no other user can access the device until the current user deallocates it.

A Solaris system can be configured in several areas to control access to devices:

• Set device policy – In the Solaris 10 release, you can require that the process that is accessing a particular device be running with a set of privileges. Processes without those privileges cannot use the device. At boot time, Solaris software configures device policy. Third-party drivers can be configured with device policy during installation. After installation, you, as the system administrator can add device policy to a device.

• Make devices allocatable – When you enable device allocation, you can restrict the use of a device to one user at a time. You can further require that the user fulfill some security requirements. For example, you can require that the user be authorized to use the device.

• Prevent devices from being used – You can prevent the use of a device, such as a microphone, by any user on a computer system. A computer kiosk might be a good candidate for making certain devices unavailable for use.

• Confine a device to a particular zone – You can assign the use of a device to a non-global zone. For more information, see Device Use in Non-Global Zones in System Administration Guide: Virtualization Using the Solaris Operating System. For a more general discussion of devices and zones, see Configured Devices in Zones in System Administration Guide: Virtualization Using the Solaris Operating System.

Device Policy (Overview)

The device policy mechanism enables you to specify that processes that open a device require certain privileges. Devices that are protected by device policy can only be accessed by processes that are running with the privileges that the device policy specifies. The Solaris OS provides default device policy. For example, network interfaces such as hme0 require that the processes that access the interface be running with the net_rawaccess privilege. The requirement is enforced in the kernel. For more information about privileges, see Privileges (Overview).

In earlier Solaris OS releases, device nodes were protected by file permissions alone. For example, devices owned by group sys could be opened only by members of group sys. In the Solaris 10 release, file permissions do not predict who can open a device. Instead, devices are protected with file permissions and with device policy. For example, the /dev/ip file has 666 permissions. However, the device can only be opened by a process with the appropriate privileges.

The configuration of device policy can be audited. The AUE_MODDEVPLCY audit event records changes in device policy.

For more information about device policy, see the following:

• Configuring Device Policy (Task Map)

• Device Policy Commands

• Privileges and Devices

Device Allocation (Overview)

The device allocation mechanism enables you to restrict access to a peripheral device, such as a CD-ROM. You manage the mechanism locally. If device allocation is not enabled, peripheral devices are protected only by file permissions. For example, by default, peripheral devices are available for the following uses:

• Any user can read and write to a diskette or CD-ROM.

• Any user can attach a microphone.

• Any user can access an attached printer.

Device allocation can restrict a device to authorized users. Device allocation can also prevent a device from being accessed at all. A user who allocates a device has exclusive use of that device until the user deallocates the device. When a device is deallocated, device-clean scripts erase any leftover data. You can write a device-clean script to purge information from devices that do not have a script. For an example, see Writing New Device-Clean Scripts.

Attempts to allocate a device, deallocate a device, and list allocatable devices can be audited. The audit events are part of the ot audit class.

For more information on device allocation, see the following:

• Managing Device Allocation (Task Map)

• Device Allocation

• Device Allocation Commands

Controlling Access to Machine Resources

As system administrator, you can control and monitor system activity. You can set limits on who can use what resources. You can log resource use, and you can monitor who is using the resources. You can also set up your machines to minimize improper use of resources.

Limiting and Monitoring Superuser

Your system requires a root password for superuser access. In the default configuration, a user cannot remotely log in to a system as root. When logging in remotely, a user must log in with the user's user name and then use the su command to become root. You can monitor who has been using the su command, especially those users who are trying to gain superuser access. For procedures that monitor superuser and limit access to superuser, see Monitoring and Restricting Superuser (Task Map).

Configuring Role-Based Access Control to Replace Superuser

Role-based access control, or RBAC, is designed to limit the capabilities of superuser. Superuser, the root user, has access to every resource in the system. With RBAC, you can replace root with a set of roles with discrete powers. For example, you can set up one role to handle user account creation, and another role to handle system file modification. When you have established a role to handle a function or set of functions, you can remove those functions from root's capabilities.

Each role requires that a known user log in with their user name and password. After logging in, the user then assumes the role with a specific role password. As a consequence, someone who learns the root password has limited ability to damage your system. For more on RBAC, see Role-Based Access Control (Overview).

Preventing Unintentional Misuse of Machine Resources

You can prevent you and your users from making unintentional errors in the following ways:

• You can keep from running a Trojan horse by correctly setting the PATH variable.

• You can assign a restricted shell to users. A restricted shell prevents user error by steering users to those parts of the system that the users need for their jobs. In fact, through careful setup, you can ensure that users access only those parts of the system that help the users work efficiently.

• You can set restrictive permissions on files that users do not need to access.

Setting the PATH Variable

You should take care to correctly set the PATH variable. Otherwise, you can accidentally run a program that was introduced by someone else. The intruding program can corrupt your data or harm your system. This kind of program, which creates a security hazard, is referred to as a Trojan horse. For example, a substitute su program could be placed in a public directory where you, as system administrator, might run the substitute program. Such a script would look just like the regular su command. Because the script removes itself after execution, you would have little evidence to show that you have actually run a Trojan horse.

The PATH variable is automatically set at login time. The path is set through the startup files: .login, .profile, and .cshrc. When you set up the user search path so that the current directory (.) comes last, you are protected from running this type of Trojan horse. The PATH variable for superuser should not include the current directory at all.

Assigning a Restricted Shell to Users

The standard shell allows a user to open files, execute commands, and so on. The restricted shell limits the ability of a user to change directories and to execute commands. The restricted shell is invoked with the /usr/lib/rsh command. Note that the restricted shell is not the remote shell, which is /usr/sbin/rsh.

The restricted shell differs from the standard shell in the following ways:

• The user is limited to the user's home directory, so the user cannot use the cd command to change directories. Therefore, the user cannot browse system files.

• The user cannot change the PATH variable, so the user can use only commands in the path that is set by the system administrator. The user also cannot execute commands or scripts by using a complete path name.

• The user cannot redirect output with > or >>.

The restricted shell enables you to limit a user's ability to stray into system files. The shell creates a limited environment for a user who needs to perform specific tasks. The restricted shell is not completely secure, however, and is only intended to keep unskilled users from inadvertently doing damage.

For information about the restricted shell, use the man -s1m rsh command to see the rsh(1M) man page.

Restricting Access to Data in Files

Because the Solaris OS is a multiuser environment, file system security is the most basic security risk on a system. You can use traditional UNIX file protections to protect your files. You can also use the more secure access control lists (ACLs).

You might want to allow some users to read some files, and give other users permission to change or delete some files. You might have some data that you do not want anyone else to see. Chapter 7, Controlling Access to Files (Tasks) discusses how to set file permissions.

Restricting setuid Executable Files

Executable files can be security risks. Many executable programs have to be run as root, that is, as superuser, to work properly. These setuid programs run with the user ID set to 0. Anyone who is running these programs runs the programs with the root ID. A program that runs with the root ID creates a potential security problem if the program was not written with security in mind.

Except for the executables that Sun ships with the setuid bit set to root, you should disallow the use of setuid programs. If you cannot disallow the use of setuid programs, then you should at least restrict their use. Secure administration requires few setuid programs.

For more information, see Preventing Executable Files From Compromising Security. For procedures, see Protecting Against Programs With Security Risk (Task Map).

Using the Solaris Security Toolkit

the Solaris Security Toolkit provides a flexible and extensible mechanism to minimize, harden, and secure a Solaris system. The Solaris Security Toolkit, informally known as the JASS toolkit, is a tool that enables the user to perform security modifications to a system. The tool can provide a report on the security status of a system. The tool also has the ability to undo previous runs of the tool. The JASS toolkit can be downloaded from the Sun web site, http://wwws.sun.com/security/jass. The web site contains pointers to online documentation.

The toolkit is described in detail in Securing Systems with the Solaris Security Toolkit, by Alex Noordergraaf and Glenn Brunette, ISBN 0-13-141071-7, June 2003. The book is part of the Sun BluePrints Series, which is published by Sun Microsystems Press.

Using the netservices limited Configuration

By default, when the Solaris 10 release is installed, a large set of network services are enabled. To limit a system's network connectivity, you run the netservices limited command. This command activates a “Secure by Default” (SBD) configuration. With SBD, the only network service that accepts network requests is the sshd daemon. All other network services are disabled or handle local requests only. To enable individual network services, such as ftp, you use the Solaris Service Management Facility (SMF). For more information, see the netservices(1M) and smf(5) man pages.

Using Solaris Resource Management Features

Solaris software provides sophisticated resource management features. Using these features, you can allocate, schedule, monitor, and cap resource use by applications in a server consolidation environment. The resource controls framework enables you to set constraints on system resources that are consumed by processes. Such constraints help to prevent denial-of-service attacks by a script that attempts to flood a system's resources.

With Solaris resource management features, you can designate resources for particular projects. You can also dynamically adjust the resources that are available. For more information, see Part I, Resource Management, in System Administration Guide: Virtualization Using the Solaris Operating System.

Using Solaris Zones

Solaris zones provide an application execution environment in which processes are isolated from the rest of the system within a single instance of the Solaris OS. This isolation prevents processes that are running in one zone from monitoring or affecting processes that are running in other zones. Even a process running with superuser capabilities cannot view or affect activity in other zones.

Solaris zones are ideal for environments that place several applications on a single server. For more information, see Part II, Zones, in System Administration Guide: Virtualization Using the Solaris Operating System.

Monitoring Use of Machine Resources

As a system administrator, you need to monitor system activity. You need to be aware of all aspects of your machines, including the following:

• What is the normal load?

• Who has access to the system?

• When do individuals access the system?

• What programs normally run on the system?

With this kind of knowledge, you can use the available tools to audit system use and monitor the activities of individual users. Monitoring is very useful when a breach in security is suspected. For more information on the auditing service, see Chapter 28, Solaris Auditing (Overview).

Monitoring File Integrity

As a system administrator, you need assurance that the files that were installed on the systems that you administer have not changed in unexpected ways. In large installations, a comparison and reporting tool about the software stack on each of your systems enables you to track your systems. The Basic Audit Reporting Tool (BART) enables you to comprehensively validate systems by performing file-level checks of one or more systems over time. Changes in a BART manifest across systems, or for one system over time, can validate the integrity of your systems. BART provides manifest creation, manifest comparison, and rules for scripting reports. For more information, see Chapter 6, Using the Basic Audit Reporting Tool (Tasks).

Controlling Access to Files

The Solaris OS is a multiuser environment. In a multiuser environment, all the users who are logged in to a system can read files that belong to other users. With the appropriate file permissions, users can also use files that belong to other users. For more discussion, see Chapter 7, Controlling Access to Files (Tasks). For step-by-step instructions on setting appropriate permissions on files, see Protecting Files (Task Map).

Protecting Files With Encryption

You can keep a file secure by making the file inaccessible to other users. For example, a file with permissions of 600 cannot be read except by its owner and by superuser. A directory with permissions of 700 is similarly inaccessible. However, someone who guesses your password or who discovers the root password can access that file. Also, the otherwise inaccessible file is preserved on a backup tape every time that the system files are backed up to offline media.

The Solaris Cryptographic Framework provides digest, mac, and encrypt commands to protect files. For more information, see Chapter 13, Solaris Cryptographic Framework (Overview).

Using Access Control Lists

ACLs, pronounced “ackkls,” can provide greater control over file permissions. You add ACLs when traditional UNIX file protections are not sufficient. Traditional UNIX file protections provide read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides finer-grained file security.

ACLs enable you to define the following file permissions:

• Owner file permissions

• File permissions for the owner's group

• File permissions for other users who are outside the owner's group

• File permissions for specific users

• File permissions for specific groups

• Default permissions for each of the previous categories

For more information about using ACLs, see Using Access Control Lists to Protect Files.

Sharing Files Across Machines

A network file server can control which files are available for sharing. A network file server can also control which clients have access to the files, and what type of access is permitted for those clients. In general, the file server can grant read-write access or read-only access either to all clients or to specific clients. Access control is specified when resources are made available with the share command.

The /etc/dfs/dfstab file on the file server lists the file systems that the server makes available to clients on the network. For more information about sharing file systems, see Automatic File-System Sharing in System Administration Guide: Network Services.

Restricting root Access to Shared Files

In general, superuser is not allowed root access to file systems that are shared across the network. The NFS system prevents root access to mounted file systems by changing the user of the requester to the user nobody with the user ID 60001. The access rights of user nobody are the same as those access rights that are given to the public. The user nobody has the access rights of a user without credentials. For example, if the public has only execute permission for a file, then user nobody can only execute that file.

An NFS server can grant superuser capabilities on a shared file system on a per-host basis. To grant these privileges, use the root=hostname option to the share command. You should use this option with care. For a discussion of security options with NFS, see Chapter 6, Accessing Network File Systems (Reference), in System Administration Guide: Network Services.

Controlling Network Access

Computers are often part of a configuration of computers. This configuration is called a network. A network allows connected computers to exchange information. Networked computers can access data and other resources from other computers on the network. Computer networks create a powerful and sophisticated computing environment. However, networks also complicate computer security.

For example, within a network of computers, individual machines allow the sharing of information. Unauthorized access is a security risk. Because many people have access to a network, unauthorized access is more likely, especially through user error. A poor use of passwords can also allow unauthorized access.

Network Security Mechanisms

Network security is usually based on limiting or blocking operations from remote systems. The following figure describes the security restrictions that you can impose on remote operations.

Figure 2–1 Security Restrictions for Remote Operations

Authentication and Authorization for Remote Access

Authentication is a way to restrict access to specific users when these users access a remote system. Authentication can be set up at both the system level and the network level. After a user has gained access to a remote system, authorization is a way to restrict operations that the user can perform. The following table lists the services that provide authentication and authorization.

A possible substitute for Secure RPC is the Solaris privileged port mechanism. A privileged port is assigned a port number less than 1024. After a client system has authenticated the client's credential, the client builds a connection to the server by using the privileged port. The server then verifies the client credential by examining the connection's port number.

Clients that are not running Solaris software might be unable to communicate by using the privileged port. If the clients cannot communicate over the port, you see an error message that is similar to the following:

“Weak Authentication
NFS request from unprivileged port”

Firewall Systems

You can set up a firewall system to protect the resources in your network from outside access. A firewall system is a secure host that acts as a barrier between your internal network and outside networks. The internal network treats every other network as untrusted. You should consider this setup as mandatory between your internal network and any external networks, such as the Internet, with which you communicate.

A firewall acts as a gateway and as a barrier. A firewall acts as a gateway that passes data between the networks. A firewall acts as a barrier that blocks the free passage of data to and from the network. The firewall requires a user on the internal network to log in to the firewall system to access hosts on remote networks. Similarly, a user on an outside network must first log in to the firewall system before being granted access to a host on the internal network.

A firewall can also be useful between some internal networks. For example, you can set up a firewall or a secure gateway computer to restrict the transfer of packets. The gateway can forbid packet exchange between two networks, unless the gateway computer is the source address or the destination address of the packet. A firewall should also be set up to forward packets for particular protocols only. For example, you can allow packets for transferring mail, but not allow packets for the telnet or the rlogin command.

In addition, all electronic mail that is sent from the internal network is first sent to the firewall system. The firewall then transfers the mail to a host on an external network. The firewall system also receives all incoming electronic mail, and distributes the mail to the hosts on the internal network.

A firewall prevents unauthorized users from accessing the hosts on your network. You should maintain strict and rigidly enforced security on the firewall, but security on other hosts on the network can be more relaxed. However, an intruder who can break into your firewall system can then gain access to all the other hosts on the internal network.

A firewall system should not have any trusted hosts. A trusted host is a host from which a user can log in without being required to supply a password. A firewall system should not share any of its file systems, or mount any file systems from other servers.

The following technologies can be used to harden a system into a firewall:

• The Solaris Security Toolkit, informally known as the JASS toolkit, can harden a Solaris system into a firewall. The toolkit can be downloaded from the Sun web site, http://wwws.sun.com/security/jass.

• IPsec and Solaris IP filter can provide firewall protection. For more information on protecting network traffic, see Part III, IP Security, in System Administration Guide: IP Services.

Encryption and Firewall Systems

Most local area networks transmit data between computers in blocks that are called packets. Through a procedure that is called packet smashing, unauthorized users from outside the network can corrupt or destroy data.

Packet smashing involves capturing the packets before the packets reach their destination. The intruder then injects arbitrary data into the contents, and sends the packets back on their original course. On a local area network, packet smashing is impossible because packets reach all systems, including the server, at the same time. Packet smashing is possible on a gateway, however, so make sure that all gateways on the network are protected.

The most dangerous attacks affect the integrity of the data. Such attacks involve changing the contents of the packets or impersonating a user. Attacks that involve eavesdropping do not compromise data integrity. An eavesdropper records conversations for later replay. An eavesdropper does not impersonate a user. Although eavesdropping attacks do not attack data integrity, the attacks do affect privacy. You can protect the privacy of sensitive information by encrypting data that goes over the network.

• To encrypt remote operations over an insecure network, see Chapter 19, Using Solaris Secure Shell (Tasks).

• To encrypt and authenticate data across a network, see Chapter 21, Introduction to the Kerberos Service.

• To encrypt IP datagrams, see Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services.

Reporting Security Problems

If you experience a suspected security breach, you can contact the Computer Emergency Response Team/Coordination Center (CERT/CC). CERT/CC is a Defense Advanced Research Projects Agency (DARPA) funded project that is located at the Software Engineering Institute at Carnegie Mellon University. This agency can assist you with any security problems you are having. This agency can also direct you to other Computer Emergency Response Teams that might be more appropriate for your particular needs. You can call CERT/CC at its 24-hour hotline: (412) 268-7090. Or, contact the team by email at cert@cert.sei.cmu.edu.