Network Security
The most difficult system administration issue to address is network security. When you connect your computer to the rest of the world via a network such as the Internet, someone could find an opening.
Firewalls
A way to protect your network from unauthorized users accessing hosts on your network is to use a firewall, or a secure gateway system. A firewall is a dedicated system separating two networks, each of which approaches the other as not trusted—it is a secure host that acts as a barrier between your internal network and outside networks. The firewall has two primary functions: It acts as a gateway to pass data between the networks, and it acts as a barrier to block the passage of data to and from the network. In addition, the firewall system receives all incoming email and distributes it to the hosts on the internal network.
Securing Network Services
Solaris is a powerful operating system that executes many useful services. However, some of these services aren’t needed and can pose a potential security risk, especially for a system connected to the Internet. The first place to start is /etc/inetd.conf. This file specifies for which services the /usr/sbin/ inetd daemon will listen. inetd is the daemon that provides many of the Internet-related services. By default, /etc/inetd.conf is configured for 30 or more services, but you probably need only 2: ftp and telnet. You eliminate the remaining unnecessary services by commenting them out. For example, to disallow telnet logins, you would want to disable the following service in the /etc/inetd.conf file:
#telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
ftpd, tftpd, fingerd, and many other Internet services can all be disabled in a similar manner. Afterward, you must restart the inetd daemon, as follows:
# kill -HUP <inetd pid> It is critical to turn off all unneeded network services because many of the services run by inetd, such as rexd, pose serious security threats. rexd is the daemon responsible for remote program execution. On a system connected to the rest of the world via the Internet, this could create a potential entry point for a hacker. TFTP should absolutely be disabled if you don’t have diskless clients taking advantage of it. Many sites also disable finger so that external users can’t figure out the usernames of your internal users. Everything else pretty much depends on the needs of your site.
The next place to start disabling unneeded processes is in the /etc/rc2.d and /etc/rc3.d startup directories. As stated in Chapter 9, “System Startup and Shutdown,” here you will find startup scripts launched by the init process. Again, some of these processes might not be needed. To keep a script from starting during the boot process, replace the S with a s. Table 16.15 lists some of the startup scripts that might not be needed and that could pose security threats to your system.
Firewalls are one of the fastest-growing technical tools in the field of information security. However, a firewall is only as secure as the operating system on which it resides.
TCP Wrappers
Another issue is TCP Wrappers. TCP Wrappers is a tool commonly used on UNIX systems to monitor and filter connections to network services. Although it does not encrypt, TCP Wrappers does log and control who can access your system. It is a binary that wraps itself around inetd services, such as telnet or ftp. With TCP Wrappers, the system launches the wrapper for inetd connections, logs all attempts, and then verifies the attempt against an ACL. If the connection is permitted, TCP Wrappers hands the connection to the proper binary, such as telnet. If the connection is rejected by the access control list, the connection is dropped.
Why would a firewall need TCP Wrappers? Doesn’t the firewall do all of that for you? First, in case the firewall is compromised or crashes, TCP Wrappers offers a second layer of defense. No firewall is 100% secure. Second, TCP Wrappers protects against firewall misconfigurations that could provide a point of entry for a hacker. Third, TCP Wrappers adds a second layer of logging—verifying other system logs.
Note
Be sure to use a system other than the firewall to retrieve and compile TCP Wrappers. You should not have compilers on the firewall.
The /etc/default/login File
One last way to protect your system from unauthorized access—regardless of whether it’s on the Internet—is via the /etc/default/login file. Make sure the following line is uncommented:
CONSOLE=/dev/console
With this entry, root is allowed to log in only from the secure system console and not via the network by using telnet or rlogin. However, this entry does not disallow a user from using the su command to switch to root after logging in as a regular user.
Modems
Modems are always a potential point of entry for intruders. Anyone who discovers the phone number can attempt to log in. Low-cost computers can be turned into automatic calling devices that search for modem lines and then try endlessly to guess passwords and break in. If you must use a modem, use it for outgoing calls only. An outgoing modem will not answer the phone. If you allow calling in, implement a callback system. The callback system guarantees that only authorized phone numbers can connect to the system. Another option is to have two modems that establish a security key between them. This way, only modems with the security key can connect with the system modem and gain access to the computer.
The Trusted Host
Along with protecting the password, you need to protect your system from a root user coming in from across the network. For example, systemA is a trusted host from which a user can log in without being required to type a password. Be aware that a user who has root access on systemA could access the root login on systemB simply by logging in across the network if systemA is set up as a trusted host on systemB. When systemB attempts to authenticate root from systemA, it relies on information in its local files—specifically, /etc/hosts.equiv and /.rhosts.
The /etc/hosts.equiv File
The /etc/hosts.equiv file contains a list of trusted hosts for a remote system, one per line. An /etc/hosts.equiv file has the following structure:
system1 system2 user_a
If a user (root) attempts to log in remotely by using rlogin from one of the hosts listed in this file, and if the remote system can access the user’s password entry, the remote system enables the user to log in without a password.
When an entry for a host is made in /etc/hosts.equiv, such as the sample entry for system1, this means that the host is trusted and so is any user at that machine. If the username is also mentioned, as in the second entry in the same file, the host is trusted only if the specified user is attempting access. A single line of + in the /etc/hosts.equiv file indicates that every known host is trusted.
Note
Using a + in the hosts.equiv or .rhosts file is bad practice and could pose a serious security problem because you are specifying that all systems are trusted. You should get into the habit of listing the trusted systems and not using the + sign.
The /etc/hosts.equiv file presents a security risk. If you maintain an /etc/ hosts.equiv file on your system, this file should include only trusted hosts in your network. The file should not include any host that belongs to a different network or any machines that are in public areas.
Tip
Change the root login to something other than root, and never put a system name into the /etc/hosts.equiv file without a username or several names after it.
The .rhosts File
The .rhosts file is the user equivalent of the /etc/hosts.equiv file. It contains a list of hosts and users. If a host-user combination is listed in this file, the specified user is granted permission to log in remotely from the specified host without having to supply a password. Note that an .rhosts file must reside at the top level of a user’s home directory because .rhosts files located in subdirectories are not consulted. Users can create .rhosts files in their home directories—another way to allow trusted access between their own accounts on different systems without using the /etc/hosts.equiv file.
The .rhosts file presents a major security problem. Although the /etc/hosts.equiv file is under the system administrator’s control and can be managed effectively, any user can create an .rhosts file granting access to whomever the user chooses—without the system administrator’s knowledge.
Tip
When all of the users’ home directories are on a single server and only certain people have superuser access on that server, a good way to prevent a user from using an .rhosts file is to create (as superuser) an empty .rhosts file in the user’s home directory. Then change the permissions in this file to 000 so that changing it would be difficult, even as superuser. This effectively prevents a user from risking system security by using an .rhosts file irresponsibly.
The only secure way to manage .rhosts files is to completely disallow them. One possible exception to this policy is the root account, which might need to have an .rhosts file to perform network backups and other remote services.
Restricting FTP
Solaris 9’s File Transfer Protocol (FTP) is a common tool for transferring files across the network. Although most sites leave FTP enabled, you need to limit who can use it. Solaris contains a file named /etc/ftpd/ftpusers, which is used to restrict access via FTP. The /etc/ftpd/ftpusers file contains a list of login names that are prohibited from running an FTP login on the system. The following is an example of the default /etc/ftpd/ftpusers file:
# more /etc/ftpd/ftpusers root daemon bin sys adm lp uucp nuucp listen nobody noaccess nobody4
Names in this file must match login names in your /etc/passwd file.
Note
The default in Solaris 9 is to not allow FTP logins by root. It is dangerous to allow root access via FTP because it would allow anyone who knows the root password to have access to your entire system. If you choose to allow FTP logins by root, remove root from the /etc/ftpd/ftpusers file. In addition, make sure that the /etc/default/login file allows remote root login privileges. This procedure is described later in the section titled “Restricting Root Access.”
The FTP server called in.ftpd daemon reads the / etc/ftpd/ftpusers file each time an FTP session is invoked. If the login name of the user trying to gain access matches a name in the /etc/ftpd/ftpusers file, access is denied.
Another file called /etc/shells contains a list of the shells on the system. Whereas the /etc/ftpd/ftpusers file contains a list of users not allowed to use FTP, the /etc/shells file enables FTP connections only to those users running shells that are defined in this file. If this file exists and an entry for a shell does not exist in this file, any user running the undefined shell is not allowed FTP connections to this system.
The /etc/shells file does not exist by default. If the file does not exist, the system default shells are used. The system default shells are as follows:
/bin/bash
/bin/csh
/bin/jsh
/bin/ksh
/bin/pfcsh
/bin/pfksh
/bin/pfsh
/bin/sh
/bin/tcsh
/bin/zsh
/sbin/jsh
/sbin/sh
/usr/bin/bash
/usr/bin/csh
/usr/bin/jsh
/usr/bin/ksh
/usr/bin/pfcsh
/usr/bin/pfksh
/usr/bin/pfsh
/usr/bin/sh
/usr/bin/tcsh
/usr/bin/zsh
You can create this file using the vi editor and listing each shell that you want to be recognized by the system. The following is an example /etc/shells file:
# more /etc/shells
/sbin/sh
/bin/sh
/bin/ksh Note
If you don’t also list all the default shells in the /etc/shells file, as I have done in the previous example, users using these shells will not be allowed access.