2.12 Replace These Weak Doors with BrickEach of these services either cannot be made secure or gives out too much information about the system to be allowed on any system that should be secure. They have been used in many successful break-ins. 2.12.1 Do Not Get the FingerFinger is a method by which a remote user can obtain a great deal of information about a user. This information includes:
This dates from the kinder, gentler days of the Internet, where everybody got along well. In modern times this is too dangerous to consider running. This gives out a lot of information that could aid in an intrusion attempt to anyone in the world for the asking. A cracker could do finger root@pentacorp.com to see if any administrators are lurking about that might notice their muckraking. He could list all logged in users with finger @pentacorp.com The login process (and telnet and ftp) will very carefully prompt someone for a password after she entered a bogus account name, even though that password will be ignored.[23] This prevents someone from guessing account names because the indication is the same (Login incorrect) regardless of whether the account name or password is incorrect.
By preventing a cracker from finding out account names, cracking passwords becomes much harder because he must correctly guess the account name and password at once. This is a combinatorial nightmare. This also prevents account name guessing for spamming purposes. The finger facility breaks this too because a cracker simply has to do finger x@pentacorp.com, where x is dave, joe, sally, smith, jones, and so on for the most common names. In some ways finger could be helpful, being able to provide users' addresses and phone numbers to someone using this method, but e-mail has largely replaced it. The bit about "unread e-mail" is so you will know if a given user has read the urgent e-mail you sent. Finger dates back to the early days of ARPANET when only scientists, professors, and graduate students had access. It is not appropriate for the Internet unless your confidence in security is high enough that you do not mind the world knowing when your people are at the office or at home. (It helps crackers to know when it is safer to try to crack a system because there is nobody on it who might notice.) The fingerd service is controlled by an entry in the /etc/inetd.conf; it is turned on by default. You probably will want to edit the inetd.conf file and comment out the line for the finger service. The line to be edited appears somewhat like the following. finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd To disable the finger service, insert a "#" at the start of the line (which makes this a comment) and save the file. To enable your change immediately type killall -HUP inetd As an alternative, you could make use of TCP Wrappers to restrict its use to those in your organization by editing /etc/hosts.allow to restrict finger use. This is discussed in "TCP Wrappers" on page 555. IP Tables could be used instead. 2.12.2 Turn Off rwhodThe rwhod daemon is a process that allows a remote user to see who is logged into your system. The client program is rwho. It has many of the security problems of finger. For a cracker, use of rwho could allow him to watch for times on your system when nobody is logged in to begin his attacks. It also allows him to find out user names of accounts on your system as possible attack points. Luckily, most Linux distributions recognize this vulnerability and although they include rwhod, most do not enable it by default. To verify that it is not running on your system, type the following command: ps axlww | grep rwho If a process other than the grep itself shows up, you should disable it. Note that this is a daemon started out of /etc/rc.d. The reason for this is that each running rwhod daemon broadcasts a list of users logged in to the system to anyone else who might be listening on the network. When a user invokes rwho it queries the local rwhod which then disgorges the cached data from other systems. Because the communications method used is UDP broadcast packets, this data does not go over the Internet. (This is because UDP broadcast packets are not routed beyond a network, but typically restricted to a subnet, unless a router is misconfigured.) Because rwho is not usable over the Internet it might be considered safer than finger so long as there are no compromised systems on the LAN (and the LAN cannot be sniffed by crackers). Still, enabling rwhod would violate the policy of "Rings of Security" because if one system gets compromised rwho could be used to get account names on other systems, allowing the next step in breaking into those other systems. (If telnet and ftp are disabled and replaced with ssh and sftp, and mail is encrypted, even a network sniffer will not see account names on the wire.) On Red Hat and similar distributions, the command to remove rwhod from your system is as follows. rpm -e rwho 2.12.3 Turn Off rwalldThe rwalld daemon is a process that allows a remote user to send broadcast messages to your system that show up on all users' screens. This allows the sending of fake messages and a DoS attack by outputting lots of characters to users' screens and even by loading down the network. 2.12.4 Turn Off SNMPSimple Network Management Protocol (SNMP) is popular among SysAdmins, particularly in large installations where there are many systems. It makes it easy to remotely manage many systems. Unfortunately, the protocol is widely regarded as insecure. When passwords are considered, they are sent in clear text, allowing them to be determined via network sniffing. SNMP uses UDP, allowing source addresses (the "from" machine) to be spoofed with tools readily available from a fine cracker site near you.
Unless you can guarantee, via the use of firewalls, that no cracker (external or internal, upstream or downstream) can subvert SNMP, it should be disabled. SNMP uses UDP port 161. Even the mighty TCP Wrappers will not help, both because of the UDP address spoofing vulnerability and because the service is implemented as a daemon, snmpd. (TCP Wrappers is available only to services started from inetd, though its companion libwrap library may be called from a daemon after minor modification to the daemon's source.) On Red Hat-based systems snmpd may be turned off in the standard way for daemons. This way would be to use chkconfig --del service_name. For snmpd, the command would be chkconfig --del snmpd On other systems that support System V-style startup scripts issue the command ls -l /etc/rc.d/rc*.d/S*snmpd* If any files are found, issue the following command: /etc/rc.d/init.d/snmpd stop and rename the scripts from S... to s.... On Slackware, the following command will locate where it might be started so that it may be commented out and will kill it if it is running. grep snmpd /etc/rc.d/* killall snmpd If you are going to run it anyway, be sure to block its port (UDP port 161) from going to or coming from the Internet. This will allow you to use it from inside the corporate network. (If you also want to use it from outside of the corporate network, simply use ssh to connect to an inside system securely and use snmp from there.) Some have suggested also changing the well-known community names, such as public and private, to other hard-to-guess names. Additionally, please change the default passwords of public and private 2.12.5 Turn Off NFS, mountd, and portmapNFS is not considered secure because the standard NFS uses UDP. The UDP protocol is considered insecure because packets can be spoofed (faked) quite easily and there is no general failsafe defense. (See "Why UDP Packet Spoofing Is Successful" on page 242 for a detailed explanation on UDP packet spoofing.) Thus, you should not run NFS (or any other UDP service) unless you can insulate it from untrusted systems via a firewall, VPN, or similar techniques or otherwise provide security. Even the use of TCP Wrappers will not help both because of the fact that nfsd and mountd are not started from inetd and because UDP packet spoofing cannot be detected by TCP Wrappers or even IP Chains or IP Tables. Modern Linux distributions have the NFS daemon, nfsd, and portmap linked against TCP Wrappers' libwrap. Although libwrap-capable NFS will not solve UDP spoofing, using it over IPSec or SSH will. Recent versions of Linux offer the "tcp" mount option for NFS file systems. This solves these security problems. Another option for those on trusted LANs using firewalls is to allow NFS UDP traffic only over a VPN (Virtual Private Network). One rather elegant solution using SSH and PPP tied together with a Perl script is discussed in "VPN Using SSH, PPP, and Perl" on page 426. The NFS daemon may be turned off by killall portmap killall rpc.mountd killall nfsd killall rpc.rquotad killall rpc.rstatd killall rpc.rusersd killall rpc.lockd killall rpc.statd rm -f /var/lock/subsys/nfs On Red Hat, Mandrake, and other distributions that use the System V style of startup scripts and RPM, it may be shut down and permanently disabled via /etc/rc.d/init.d/nfs stop /etc/rc.d/init.d/nfslock stop /etc/rc.d/init.d/portmap stop chkconfig --del nfs chkconfig --del nfslock chkconfig --del portmap While Red Hat's security in the 7.3 release is much improved over that of the 6.x series, it still enables portmap and rpc.statd. Be sure to turn these off. Alternatively, the Control panel or Linuxconf may be used. On Slackware, edit /etc/rc.d/rc.inet2 to prevent its ever being started again. 2.12.6 Switch NFS to Run over TCPOne of the two principal security problems with NFS (besides vulnerabilities because of security bugs in prior versions) is due to NFS running on top of the UDP protocol. UDP packets can be spoofed easily, allowing a cracker to gain the access to portions of your file system that you grant to your most trusted NFS clients or even send fake data back to legitimate NFS clients. (See "Packet Spoofing Explained" on page 239 for details on spoofing.) The other principal problem is that data is not encrypted thus allowing it to be seen by anyone sniffing the network. Starting around early 2000 some Linux distributions began offering an enhanced NFS that can run on top of TCP as well as the original UDP capability. Running NFS on top of TCP solves the UDP spoofing problem. More specifically, TCP support is in NFSv3 that was first included in the 2.2.14 kernel. The tcp mount option can be used on the client when mounting an NFS file system to cause NFS operations to be done over TCP. It may be placed in /etc/fstab too. Additionally, running NFS on top of TCP allows you to use TCP Wrappers to limit who can access your NFS server and to detect and lock out interlopers with Adaptive TCP Wrappers. The portmap program now supports TCP Wrappers too. (See "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559.) Though I have not seen it myself nor encountered references to it, I expect that one could insert Secure shell (SSH) in the path of NFS over TCP, yielding a facility secure from network sniffing and spoofing. Running recent versions of NFS via SSH-wrapped TCP might be a more secure alternative to not using it at all; there is very little experience with this so it still is an unknown. You will pay a substantial performance penalty, on the order of 50 percent, by switching NFS from UDP to TCP. This is typical of running any given client/server application over TCP instead of UDP. This performance penalty is due to the doubling of traffic to support the protocol's built-in acknowledgment packets. Another limitation of TCP that UDP does not have is that, being connection-oriented, the process on each end of a connection needs a separate open socket and hence a separate file descriptor. Typical limits on Linux are 256 open files per process limited to 4096[24] open files on the machine. Thus, a TCP-based user-space NFS server is limited to handling about 250 clients at a time. Even with multiple NFS daemons the machine will be limited to about 4000 client files at a time.
cat /proc/sys/fs/file-max /proc/sys/fs/inode-max
echo 4096 > /proc/sys/fs/file-max
2.12.7 Turn Off rsh, rcp, rlogin, and rexecThe rsh program, short for the Berkeley-created remote shell (not to be confused with the Bell Labs-created restricted shell not seen on Linux) is a wonderful program for enabling someone on one computer to remotely execute a program on another computer under the same account name. Unfortunately, it is not secure. See "The rsh, rcp, rexec, and rlogin Services" on page 198 for a detailed explanation of their security model, and why it is insecure in today's world. The same is true for rexec. The rlogin service is insecure for the same reasons. It has the additional insecurity of sending unencrypted (clear text) passwords over the network. The telnet service is slightly more secure than rlogin, because it does not have the weak security model of the r* commands allowing operations without a password. Although this model worked well in the different world of the early 1980s, it is not appropriate for the unprotected networks of today. These services should be turned off unless their requests from all systems (except trusted systems) can be blocked. Note that rlogin sends unencrypted passwords so it should not be used over any network that can be sniffed. The SSH (secure shell) is a secure replacement for these r* commands; switching to it is highly recommended. It is explained in "Protecting User Sessions with SSH" on page 409. They may be (and should be) turned off by commenting out their entries in /etc/inetd.conf. Their entries start shell login exec For those that insist on running in.rshd, the server that supports the rsh command, perhaps on isolated networks, adding the -L flag to the in.rshd invocation will log successful connections to auth.info messages and all disallowed accesses to be logged as auth.notice. Additionally, do not use -h as it would allow root to rsh into your systems, a severe security hole if even one system on the network is insecure, or if an intruder can spoof the IP or MAC address of any trusted host. 2.12.8 Turn Off Echo and ChargenThese are two innocent services used for network and system testing. The echo port simply echoed back all data sent to it to test connectivity. The chargen port, short for character generation, output a rotating sequence of printable characters for testing tty devices and other situations where a known and varying sequence was desired. Even these can be corrupted by crackers and so they should be disabled. The UDP versions of echo and chargen (character generation) can be used for a DoS attack against a third system. A cracker merely needs to spoof her source address to be that of the system to be attacked and send packets to that third system by yours. A cracker can have system X telnet to system Y's chargen port and then walk away while Y sends unlimited data to X using up the bandwidth of whichever of them has a smaller "pipe" (bandwidth) to the Internet. 2.12.9 Turn Off talk and ntalkThese daemons allow two users on possibly different systems to communicate with each other. This allows a minor DoS by allowing people on remote systems to send output to your users' screens. Unless you plan to use it and set up TCP Wrappers to protect against it, turn it off. This capability is used less now, in favor of ICQ and AOL Instant Messenger. There are several RPMs available for Linux to support these. GAIM is an Open Source implementation of America Online's Instant Messenger protocol. It may be downloaded from the CD-ROM or from http://gaim.sourceforge.net/index.php There are Linux ICQ clients too. 2.12.10 Turn Off TFTPTFTP is the Trivial FTP server. It was created many years ago to be a server similar to FTP but with an easier protocol. It was intended to allow the client side to be implemented in ROM easily, to allow systems without local disk to boot up over the network. It is not used any more due to memory getting denser. It is not secure and should be disabled. It is disabled on most distributions. It should be blocked at the firewall too. 2.12.11 Turn Off systat and netstatLike finger, systat and netstat hail from the time of a kinder, gentler Internet. The systat service, meaning system status, simply invokes /bin/ps -auwwx. The netstat service, meaning network status, invokes /bin/netstat -a. Either they should be disabled or their access from outside the trusted should be blocked with TCP Wrappers or IP Chains. If you have reasonable trust in the security of your users' home systems, you might want to allow them to invoke these commands so that they can check the status of their jobs. This should not be done if confidential data, such as passwords, could be present on the command line of invoked commands. 2.12.12 Turn Off Internal xinetd ServicesMost Linux distributions enable various internal xinetd services that can be used for DoS attacks against your systems and against third parties. These include echo (port 7) and chargen (port 19). The echo service echoes back what is sent and chargen, short for character generation, sends an unlimited number of ASCII characters intended for testing tty devices. While these were useful in the old days it is best to disable them and the other simple services, such as the time services, daytime (13) and time (37). |
Top |