It’s depressing for security professionals to see just how many of the vulnerabilities on the new SANS/FBI Top 20 List have CVE numbers in the 1999-xxxx range—meaning that they were identified and fixed years ago on some systems. Newer problems appear in each category, but far too many bear old CVE numbers.
The SANS/FBI Top 20 List tracked actual attacks and listed them according to the frequency of their occurrence. My previous article examined Windows vulnerabilities on the list. Now, I'm going to look at the UNIX vulnerabilities, nearly all of which also apply to Linux.
Here is the list of the top 10 UNIX vulnerabilities:
U1 Remote Procedure Calls (RPC)
U2 Apache Web Server
U3 Secure Shell (SSH)
U4 Simple Network Management Protocol (SNMP)
U5 File Transfer Protocol (FTP)
U6 R-Services—Trust Relationships
U7 Line Printer Daemon (LPD)
U10 General UNIX Authentication—Accounts with No Passwords or Weak Passwords
Of particular note on the UNIX side, BIND/DNS vulnerabilities are now number 9 on the top 10 UNIX list, down from number one on the original Top 10 list from June 2001. After this long, it shouldn’t be there at all. And it wouldn’t be, if systems were updated every few years.
RPC weaknesses are now number 1 on the UNIX list, up from number three in 2001, but some of the same CVEs are still cited today, which means that known holes have yet to be fixed on a vast number of systems.
RPCs let one computer exchange files and run applications on other systems, so it’s commonly used for remote network management and other tasks.
Applicability—Most UNIX and Linux systems are affected. RPCs are installed and enabled by default in most installations. Try to run rpcinfo to see whether RPC services are enabled.
Fix—Install patches and block unnecessary services. Click here for links to various patches.
Internet Web servers are inherently vulnerable for various reasons, as you can see by the fact that Apache is number two on the UNIX list, while IIS is number one on the Windows list. Although Apache is considerably more secure than IIS, the myth that it is totally secure accounts for the lax attention to Apache security and actually leaves the server highly vulnerable.
Applicability—Most UNIX and Linux versions come with Apache enabled.
Fix—Apply Apache patches. Compile only the functions you really need. For a laundry list of steps, you can take to help secure Apache see the SANS/FBI report.
SSH is used to replace Telnet, FTP, and R-commands and is considerably more secure than those programs, but both OpenSSH and the SSH Communication Security’s commercial version of SSH have a number of vulnerabilities.
Applicability—Any system running OpenSSH 3.3 or earlier, or SSH 3.0.0 or earlier is affected.
Fix—Keep SSH updated with the latest version.
SNMP was designed to make it easy to remotely manage networks via TCP/IP and is therefore vulnerable simply because it is intended to allow outsiders to run software remotely. Even the smallest vulnerability can allow unauthorized users to take over a network.
SNMP is also found in the Windows world, but SNMP attacks are almost exclusive to UNIX and Linux systems, perhaps because there are so many other ways to attack Windows.
Applicability—Most Linux and UNIX systems come with SNMP installed and enabled by default.
Fix—The best fix is to disable SNMP if you can do without it. Otherwise, keep your version patched and use v3 if possible. On v1 and v2, treat community names as if they were passwords (i.e., make them difficult to guess and change them regularly). Additional tips on hardening SNMP are found in the original SANS/FBI report.
Back when the Internet was a friendlier place, everyone placed files on servers and invited anyone to download them using FTP. Anonymous FTP is still widely available, but companies aren’t using it for confidential data any longer. The problem with even authenticated FTP file transfers that require a unique user ID and password is that the data is transmitted in clear text. If that’s not bad enough, a lot of FTP server programs have serious vulnerabilities.
Applicability—Most UNIX and Linux systems have FTP installed and enabled by default. Use the free Nessus scanner to see whether your server is vulnerable to FTP.
Fix—Disable FTP if possible. If that isn’t an option, place as many limits on it as you can, including placing administrative accounts in /etc/FTPusers to protect them and at a minimum, disabling the anonymous upload capability. Use TCP wrappers to limit FTP access to certain IP addresses. Click here if you need to install TCP wrappers on your system. See more options in the SANS/FBI report.
Rsh, rcp, rlogin, and rexec allow external access to a system and make it easy to move between systems without having to log in each time. R-Services are dangerous because they are not encrypted and use poor host authentication.
Applicability—Most UNIX and Linux systems have R-Services installed and enabled.
Fix—Disable the services if at all possible; if not, use TCP wrappers to restrict access.
LPD lets users connect to a printer via TCP port 512.
Applicability—Most UNIX and Linux systems are affected.
Fix—See CERT's general advisory about LPD, issued in 2001, for detailed help.
This popular program is used for running an SMTP server.
Applicability—Most UNIX and Linux systems have Sendmail installed and enabled.
Fix—Updating to the latest version will address a multitude of problems. You should not allow Sendmail to run in daemon mode except on dedicated mail servers or relays.
This DNS server software is widely used and hence a popular target, but fixes are posted quickly. The major threat is to systems with older versions installed.
Applicability—Because of its popularity, administrations of all versions of BIND need to be aware of this general threat.
Fix—Keep versions updated. Otherwise, disable the BIND daemon (named) unless needed. Other steps to secure BIND are detailed in the Top 20 document.
No comment should be necessary regarding this vulnerability, but you'll find detailed recommendations in the SANS/FBI report.
Ports to block
Of special interest to those who must make quick and dirty fixes, this is the list of ports to block at your firewall that can dramatically reduce your problems. The list is taken directly from the SANS/FBI report:
Telnet (23/tcp), SSH (22/tcp), FTP (21/tcp), NetBIOS (139/tcp), rlogin et al (512/tcp through 514/tcp)
RPC and NFS
Portmap/rpcbind (111/tcp and 111/udp), NFS (2049/tcp and 2049/udp), lockd (4045/tcp and 4045/udp)
NetBIOS in Windows NT
NetBIOS 135 (tcp and udp), 137 (udp), 138 (udp), 139 (tcp)
For Windows 2000, you also have to include 445 (tcp and udp)
6000/tcp through 6255/tcp
Block DNS (53/udp) to all machines that are not DNS servers, DNS zone transfers (53/tcp) except from external secondaries, LDAP (389/tcp and 389/udp)
SMTP (25/tcp) to all machines, which are not external mail relays, POP (109/tcp and 110/tcp), IMAP (143/tcp)
HTTP (80/tcp) and SSL (443/tcp) except to external Web servers—may also want to block common high-order HTTP port choices (8000/tcp, 8080/tcp, 8888/tcp, etc.)
Ports below 20/tcp and 20/udp, time (37/tcp and 37/udp)
TFTP (69/udp), finger (79/tcp), NNTP (119/tcp), NTP (123/udp), LPD (515/tcp), syslog (514/udp), SNMP (161/tcp and 161/udp, 162/tcp and 162/udp), BGP (179/tcp), SOCKS (1080/tcp)
Block incoming echo requests (ping and Windows traceroute). Block outgoing echo replies, time exceeded, and destination unreachable messages except "packet too big" messages (type 3, code 4). This assumes that you are willing to forego the legitimate uses of ICMP echo requests in order to block some known malicious uses.
A useful defense, if not a solution
Blocking the ports on this list won’t actually fix any vulnerabilities, so blocking these ports is really a stopgap measure. Nevertheless, in concert with the top 20 list itself, the port block list can be a valuable tool for those who are swamped with the shear volume of threats they must address.
Many of the vulnerabilities found in UNIX (and therefore in Linux) stem from the days when a modem ran at 0-300 baud and was a rare piece of hardware. Hackers were the good guys, and you had to have physical access to a computer to do any damage. I wouldn’t want to go back to those days, but security was definitely a different game back then. Unfortunately, many of the legacy features of UNIX, which were designed for that era, now make it vulnerable. And apparently, not enough systems have been updated or had unnecessary features disabled to circumvent the problems. The SANS/FBI report can help you make the proper adjustments for today's connected environment.