10.6. Securing by UserThere 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 ServiceAs 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 FTPThere are a variety of FTP services available. Many allow you to configure various forms of access, including:
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 ApacheYou 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.
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 AuthenticationPluggable 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. |