Section 2.12 Replace These Weak Doors with Brick

   


2.12 Replace These Weak Doors with Brick

graphics/fivedangerlevel.gif

Each 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 Finger

graphics/threedangerlevel.gif

Finger is a method by which a remote user can obtain a great deal of information about a user. This information includes:

  • All terminals that the user currently is logged into, when she logged in to each, how long since she has typed characters on each terminal, and if connected via telnet what system she connected from.

  • Does she have e-mail (in her in-box) and is any of it unread?

  • The contents of her GECOS entry in /etc/passwd. The GECOS field is used as a comment and often contains the person's full human name and sometimes phone numbers and mail stop or address.

  • Her login directory path.

  • What shell she uses.

  • The contents of her .plan and .project files (which are intended for this purpose).

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.

[23] They will even spend the computrons to encrypt the password as if they were going to compare the encrypted version with the copy in /etc/passwd or /etc/shadow.

This is to prevent a cracker from noticing the difference in time taken before saying Login incorrect depending on whether the account exists. This lesson too was learned the hard way.

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 rwhod

graphics/twodangerlevel.gif

The 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 rwalld

graphics/twodangerlevel.gif

The 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 SNMP

graphics/fivedangerlevel.gif

Simple 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.

There is a joke among security experts that SNMP means "Security Not My Problem." Please keep that in mind.


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 portmap

graphics/fivedangerlevel.gif

NFS 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 TCP

One 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.

[24] On newer kernels one can do

 cat /proc/sys/fs/file-max /proc/sys/fs/inode-max 

to see the current settings or

 echo 4096 > /proc/sys/fs/file-max 

to alter them. My 2.2.12-20 kernel was set for a maximum of 4096 files. It would let me use echo to increase it to 4097 but no more. This appears to be an off-by-one bug to me.

2.12.7 Turn Off rsh, rcp, rlogin, and rexec

graphics/fivedangerlevel.gif

The 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 Chargen

graphics/twodangerlevel.gif

These 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 ntalk

graphics/twodangerlevel.gif

These 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 TFTP

graphics/fourdangerlevel.gif

TFTP 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 netstat

graphics/threedangerlevel.gif

Like 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 Services

graphics/twodangerlevel.gif

Most 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


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

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