UNIX System Administration Handbook - Evi Nemeth [390]
Check also the permissions on /dev/drum and /dev/mem if your system has them. These files provide unfettered access to the system’s swap space and physical memory, and they are potentially just as dangerous as /dev/kmem.
/etc/passwd and /etc/group should not be world-writable. They should have owner root and mode 644. The group should be set to some system group, usually daemon. The passwd command runs setuid to root so that users can change their passwords without having write permission on /etc/passwd.
Directories that are accessible through anonymous FTP should not be publicly writable. Such directories create a nest for hackers to distribute illegally copied software and other sensitive files. If you manage an FTP archive that allows submissions, be sure to screen the submissions directory regularly.
See page 696 for information about setting up a secure FTP server.
Setting up anonymous FTP usually involves copying a skeleton password file into ~ftp/etc/passwd so that ls will work correctly. Make sure to remove the encrypted password strings.
Device files for hard disk partitions are another potential source of problems. Having read or write permission on a disk device file is essentially the same as having read or write permission on every file in the filesystem it represents. Only root should have both read and write permission. The group owner is sometimes given read permission to facilitate backups, but there should be no permissions for the world.
21.6 MISCELLANEOUS SECURITY ISSUES
The sections below present some miscellaneous security-related topics. Most are either features that are useful to you as an administrator or misfeatures that can provide nesting material for hackers if not kept in check.
Remote event logging
The syslog facility allows log information for both the kernel and user processes to be forwarded to a file, a list of users, or another host on your network. Consider setting up a secure host that acts as a central logging machine and prints out security violations (the auth facility) on an old line printer. This precaution prevents hackers from covering their tracks by rewriting or erasing log files.
See Chapter 11 for more information about syslog.
Secure terminals
Some systems can be configured to restrict root logins to specific “secure” terminals. It’s a good idea to disable root logins on channels such as dial-up modems. Often, network pseudo-terminals are also set to disallow root logins.
The secure channels are usually specified as a list of TTY devices or as a keyword in a configuration file. On Solaris, the file is /etc/default/login.6
On HP-UX and Red Hat Linux, the file is /etc/securetty, and on FreeBSD it is /etc/ttys.
/etc/hosts.equiv and ~/.rhosts
The hosts.equiv and ~/.rhosts files define hosts as being administratively “equivalent” to one another, allowing users to log in (via rlogin) and copy files (via rcp) between machines without typing their passwords.7
Use of this facility was once common during the party days of UNIX, but everyone eventually woke up with a nasty headache and realized that it wasn’t such a good idea.
We recommend that rshd and rlogind, the server processes that read .rhosts and hosts.equiv, be disabled. On most systems, this is done by simply commenting them out of /etc/inetd.conf. Once the server daemons have been disabled, the host will no longer be reachable by rlogin, rsh, or rcp. However, the functionality of these commands can be replaced with higher-security equivalents such as SSH; see page 672.
For basic remote logins, you can use telnet to continue to access a system on which rlogin has been disabled. But be aware that telnet