Certification Objective 7.03Controlling System Security

Certification Objective 7.03—Controlling System Security

Exam Objective 4.4: Control system security through restricting ftp access and using /etc/hosts.equiv and $HOME/ .rhosts files, and SSH fundamentals.

A user can also access the Solaris system through ftp. Even more dangerous access is through the .rhosts file. So, these accesses need to be controlled and restricted.

Restricting ftp Access

The ftp utility, based on the open Internet standard called File Transfer Protocol (FTP), is a standard tool used to transfer files across a network and across the Internet. If you leave your system with ftp enabled, the remote users may have access to your system by logging in through ftp. It is just another entryway into your system, and every entryway has to be guarded, from a security perspective.

You can restrict ftp access by using the following three files:

    /etc/ftpd/ftpusers    /etc/ftpd/ftphosts    /etc/shells 

The ftpusers file is used to restrict access at user level. This file contains a list of login names that you can see by issuing the following command:

    # less /etc/ftpd/ftpusers 

Any login name included in this list is prohibited from using ftp. So, if you want to deny a user access to your system through ftp, just edit the ftpusers file, type in that user's login name, and save the file. When a user attempts to start an ftp session, the system searches the user's login name in the ftpusers file. If a match is found, access is denied.

On the Job 

The names in the ftpusers file must be the login names. In order to ensure that, make sure they exactly match with the login names in the /etc/passwd file.

You can use the ftphosts file to restrict ftp access at host level in order to allow or deny access to a user coming from a specified host. For example, the following entry in the ftphosts file allows the user jkerry to connect to your system using ftp remotely from machines with IP addresses: 205.25.2.3, 195.26.3.4, and 210.23.4.5:

    allow jkerry 205.25.2.3 195.26.3.4 210.23.4.5 

However, the following entry denies user gbush an ftp access from the host machine with IP address 132.12.13.5:

    deny gbush 132.12.13.5 

A user interacts with the Solaris system through a shell, and there are several shells around. If the user is using a shell that the system does not support, obviously the user will be denied access. This indirect method can also be used to restrict ftp access. By default, the system supports a number of shells. You can restrict the number of shells supported by the system by creating the following file and typing in the shells that you want the system to support:

    /etc/shells 

Let's assume you made the following entries into this file:

    /bin/sh    /bin/csh    /sbin/jsh 

Now, if a user, for example, using the /etc/ksh shell attempts to gain ftp access, access will be denied.

Be careful about the combined effect of all these options. For example, if a user is using the allowed shell but the corresponding user name has included the ftpusers file, access will still be denied. The same is the case when the username is not in the ftpusers file, but the user is using the wrong shell.

Exam Watch

If you create the /etc/shell file, the shells listed in the file are the only permitted shells. The users listed in the /etc/ftpd/ftpusers files are the users who are not permitted to have ftp access.

The .rhosts File: A Major Security Risk

Each entry in the $Home/.rhosts file contains the host-username pair. If a host-user exists in the file, that means the specified user from the specified host is allowed to log in remotely to this system without a password (yes, that's not a typo). However, for this to work, the .rhosts file must be in the home directory of the user at the top level; a file in a subdirectory of the home directory will not work.

Now, this is a severe security problem, because any user can create the $HOME/.rhosts file, not just the system administrator. You can disable .rhosts files altogether by commenting out lines in the following file that reference am_rhosts_auth.so.l:

    /etc/pam.conf 

If you do this, rlogin will still work, but it will ask for a password even from the users who are listed in the .rhosts files. The rlogin related entries in the pam.conf file look like the following:

    rlogin auth sufficient pam_rhosts_auth.so.1    rlogin auth requisite pam_authtok_get.so.1    rlogin auth required pam_dhkeys.so.1 

The hosts that are used in the .rhosts authentication are also listed in the /etc/hosts.equiv file, which is also used by the rlogind and rshd daemons. Why do we need these two files? The /etc/hosts.equiv file applies to the entire system, whereas each $HOME/.rhosts file is maintained by an individual user. An entry in both the .rhosts file and the hosts.equiv file may have the following syntax:

    <hostname> <username> 

This means that a user specified by <username> can access this system from the host specified by <hostname> by using the same user name as on the <hostname>. An entry into these files may also have the following syntax:

    <hostname> 

This means that any user from the host specified by <hostname>, except the root user, can have access to this system on which this file (.rhosts or hosts.equiv) exists.

We have been talking about securing the system. The Internet has added another security dimension involving the communication lines between the computers. Communication with the system from another computer also needs to be secured, because it may contain sensitive information. Solaris offers communication-related security by implementing the secure shell (SSH), which we discuss next.

Secure Shell Fundamentals

The secure shell (SSH) implemented in Solaris enables users to securely access a remote system over an insecure network or Internet. SSH provides strong authentication and secure communication over the public (unsecure) Internet. Users can use the SSH to accomplish the following:

• Log in to a remote system by using the ssh utility. Without ssh, the user would use rlogin or rsh.

• Transfer files across the network by using sftp. Without ssh, the user would be using ftp.

• Run commands securely on the remote system.

The SSH protocol is based on the client /server communication model. The host that initiates the connection, is called the client, and the host that accepts the connection and serves the requests made by the client is called the server. When the system is started, it starts the sshd daemon by running the following script:

    /etc/init.d/sshd 

It happens on both the client and the server machines. The sshd is configured on both machines by using the following file:

    /etc/ssh/sshd_config 

The sshd uses the variables in the /etc/default/login file and the login command. The variables values in the /etc/default/login file can be overridden by the values set in the sshd_config file.

The ssh command syntax is:

    ssh [-l <login_Name>] <hostname> 

or

    user@hostname [<command>] 

So far, we have explored the security issues related to system access. Once a user has accessed the system, the next things to secure are the resources on the system. Data is an important resource on the system, and we explore data security next.