Section 10.6. Securing by User


10.6. Securing by User

There are a number of services and tools that you can secure on a per-user basis. I divide them into two categories. Some services, such as FTP servers, are customizable on a per-user basis. Others may be secured based on user accounts.

10.6.1. Securing by Service

As there are a substantial number of Linux network services, I can only describe securing by service in general terms. I provide an example of securing by user on an Apache and an FTP server.

If you want to secure by user on a shared NFS directory, explore an earlier annoyance in this chapter, "The Boss Wants to Set Up a Special Group of Users." Once you set up a special group and directory, you can share the associated directory with other Linux/Unix systems on your network using NFS. Assuming you have a single database of users and groups, such as the LDAP or Microsoft database mentioned near the beginning of this chapter, the way you configure your special group applies to all systems.

10.6.1.1. Allowing user access on FTP

There are a variety of FTP services available. Many allow you to configure various forms of access, including:

  • Anonymous-only, which limits access to the default FTP data directory

  • Local user access, which allows users to log in to their accounts via FTP

Whatever FTP server you choose, be aware that FTP has a variety of security issues. Choose your FTP server carefully.

However, one reasonably secure solution is vsFTP. It is the default FTP server on Red Hat and Fedora distributions, and it is available for all major Linux distributions. For detailed information on vsFTP, see http://vsftpd.beasts.org/.

The vsFTP service is most commonly used for anonymous access. To see what you can do, open the associated configuration file (/etc/vsftpd.conf on SUSE and Debian; /etc/vsftpd/vsftpd.conf on Red Hat/Fedora). Anonymous access is supported with the following directive; naturally, you can also disable anonymous access with this directive:

 anonymous_enable=YES 

The vsFTP service also supports access by local users. The key directive is:

 local_enable=yes 

If you want to prevent writes via FTP, you can reverse the following directive:

 write_enable=yes 

You can limit access to specific users. Naturally, you'll want to deny access to nonstandard users, including root, bin, adm, and operator. To do so, you'll want to make sure the following directive is set, which denies users in the list defined in /etc/vsftpd.user_list:

 userlist_deny=YES 

With Pluggable Authentication Modules, the vsFTP server can also help you deny access to users as defined in /etc/pam.d/vsftpd. This file points the system to another file that lists users to be denied access to the vsFTP server. Depending on the distribution, the default version of the file may be either /etc/vsftpd.ftpusers or /etc/ftpusers. (It changes from time to time; Fedora Core 5 will apparently use /etc/vsftpd/users_list.)

10.6.1.2. Allowing user access on Apache

You can configure password-protected username access to the Apache web server to support file sharing for operating systems where more secure remote access services are not available.

Any remote access is a security risk. Allowing remote access via Apache creates additional risks, as any cracker with a web browser and knowledge of a username and password can get onto your system. For more information, see Recipe 6.1 from Apache Cookbook by Ken Coar and Rich Bowen (O'Reilly).


If this level of risk is acceptable, you can cite your /etc/passwd authentication file for usernames and passwords. As noted in the aforementioned Apache Cookbook, you could include /etc/passwd as the authentication file, using the AuthUserFile directive:

 <Directory "/home">      AuthType Basic      AuthName HomeDir      AuthUserFile /etc/passwd      Require valid-user      Satisfy All </Directory> 

But that might be a bit too insecure. You could further limit access to computers on the local network; the following directives limit access to computers on the 192.168.0.0/24 private local network:

 Order deny,allow Deny from all Allow from 192.168.0. 

Yes, a cracker could spoof an IP address on a local network, but perhaps the information on your systems does not require such a high level of security.

Instead of referring to the passwd file, you can create your own authentication data for your web server. (Alternatively, you can configure a separate secure web site using the HTTPS protocol, but that's more work.) For example, if you include the following directives on a virtual host, you can limit access to the users of your choice:

 <Directory "/www/docs/testwebsite.example.com>     AuthType Basic     AuthName "Members Only"     AuthUserFile /www/docs/users     Require user michael,donna </Directory> 

Before this works, you'll have to use the htpasswd command to create a username and password database in the AuthUserFile. The first time you create a web password, you'll have to run the htpasswd -c command. The following example is consistent with the stanza for the testwebsite.example.com web site:

 htpasswd -c /www/docs/users michael 

You can add another user, to the same configuration file, without the -c switch:

 htpasswd /www/docs/users donna 

In either case, htpasswd prompts you for a password, which is encrypted in the AuthUserFile you select.

10.6.2. Securing by Pluggable Authentication

Pluggable Authentication Modules (PAM) allow you to change how you secure key administrative commands. PAM modules are stored in the /etc/pam.d directory. One interesting module is su, which regulates access to other accounts. When used alone, it allows a regular user to log in to the root account.

The root user is given full access to the su command with the following directive:

 auth     sufficient     pam_rootok.so 

In that way, the root user can log in as the user of his choice, without knowing that user's password. For example, as root, I can log in to user michael's account with the following command:

 su - michael 

With other modules, you may want to limit access to regular users. For example, you may want to limit access to Red Hat/Fedora configuration tools. One method was already described earlier; you can limit by user via a configuration file. The following directive in the /etc/pam.d/vsftpd file points to /etc/ftpusers for a list of users to deny access to the vsFTP service.

 auth    required     pam_listfile.so item=user  sense=deny file=/etc/ftpusers 

You can use the same type of directive to regulate access within other PAM modules. For example, take the /usr/sbin/setup utility in Red Hat/Fedora Linux, which serves as a frontend to other text-based configuration modules. The associated PAM configuration file is straightforward:

 auth       sufficient   pam_rootok.so auth       required     pam_stack.so service=system-auth account    required     pam_permit.so session    required     pam_permit.so 

These are straightforward modules, which provide unlimited access to the root user and require authentication through the system-auth module for other users, who must have a valid account and be logged in to a valid session.

Now assume you set up a /etc/ssh/sshallow configuration file, with a list of users not allowed to log in to your Secure Shell server. If you add the following directive to /etc/pam.d/ssh, the users listed in the /etc/ssh/sshallow file are the only ones allowed to log in to the local server from a remote location:

 auth required pam_listfile.so item=user sense=allow file=/etc/ssh/sshallow onerr=fail 

This is just one way you can regulate remote access by your administrators. Similar commands work well for other PAM-aware administrative commands and tools.



Linux Annoyances for Geeks
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2004
Pages: 144
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net