This article outlines the importance of monitoring vendor advisories and applying appropriate software patches when necessary.  It uses the Ramen epidemic as an example showing the possible effects of poor system administration. Whether you're a security professional, system administrator, or average Linux user you've probably already heard many of the stories surrounding the recent outbreak of the Ramen worm. If you haven't heard the details, or would like an overview of the specifics, you may want to skip down to the middle of this paper. I have answered some of the most common questions and provided specific information on how to prevent and disable the worm as well as how it works. Ramen does not only exploit vulnerabilities in wu-ftpd, nfs, and LRPng, it takes advantage of lazy/inattentive/irresponsible/naive system administrators.

In this paper I answer many questions. What actually enabled the Ramen worm to be so successful? Who's responsible? What knowledge can we take from this situation?

Maintaining a secure network can be broken up into 4 abstract parts:

1. Know your system
2. Be proactive
3. Update when necessary
4. Educate yourself
Know your system - One of the most important factors of maintaining a system is knowing what you have. This often means reading documentation completely before installing, understanding all configuration options, and being aware of any risk that a particular package may incur. If you do not have a specific need for a package or service, then by all means remove it. Packages just lying around should be considered a threat and removed immediately. An administrator should be aware of all executables, configuration files, processes, users, and normal system operation. Know your system intimately!

The Ramen worm is a great example showing how package negligence can lead to vulnerabilities. This particular worm attacks nfs, wu-ftpd, and LPRng, but it might as well have been a samba exploit in a general case. The specific vulnerable packages do not matter, it is the attitude of the administrator. I would be willing to bet that in most cases where there was a compromise the vulnerable services were not in use. Most users install Linux using an "out-of-the-box" configuration leaving the door wide open to compromise. Most distributions require a small bit of configuration before actually being ready for the Internet. Too often, unskilled users put boxes up not knowing what kind of significant effect it can have. This is a problem that will continue until vendors put more emphasis on a secure default configuration. Many times users will ignore warnings given simply because they do not maintain a high-profile server or have a connection faster than dialup, cable, or DSL. Proper precautions should still be taken because privately owned systems are often used as stepping stones to attack larger servers. By not updating regularly, you are contributing to the problem.

Be proactive - Having a cut down Linux box is a good first step, but that does not eliminate the problem. It is necessary to monitor vendor advisories from the packages and distributions that you are using. Again, knowing your system is helpful. What packages do you have installed? Many system administrators have trouble managing advisories, keeping up with the lists, and following through. We have tried to make this process easier for you. For those of you who are not aware, we release a weekly vulnerability newsletter "Linux Advisory Watch." Linux Advisory Watch is comprehensive newsletter that outlines the security vulnerabilities that have been announced throughout the week. It includes pointers to updated packages and descriptions of each vulnerability.

Update when necessary - If no steps are taken to fix known problems then the system is still vulnerable. Often, administrators will read new vendor advisories, but then get distracted performing other tasks. The system then sits idle and remains vulnerable until a new release of the distribution is installed. The process repeats itself. Advisories are often numerous and annoying. This is why it is necessary to have the minimum amount of packages installed. It should be your sole purpose in life to make sure that vulnerable packages are patched as soon as an advisory is released. If you are/were vulnerable to the Ramen worm, a general updating scheme could have eliminated that risk. Advisories dating back to June 2000 provided fixes to today's Ramen worm problem. Who's fault it that? If not this time, it will be the next. Staying current is extremely important.

At times there may be situations when a patch is not available and you want to limit the impact of a vulnerability that may arise. Something as simple as:

ipchains -A input -i eth0 -p tcp -s 0/0 -d 21 -j DENY

ipchains -A input -i eth0 -p tcp -s 0/0 -d 23 -j DENY

can be used to restrict access to telnet and ftp from the external interface. Although beyond the scope of this paper, ipchains should play an important roll in your configuration.

Educate yourself - When you have time on your hands, it can be best spent reading articles and white papers that describe how to build and maintain secure networks. Where can you find good papers? Each week, in the "Linux Security Week" newsletter, outlines the best two or three articles/papers released. An archive of releases can be found here: LinuxSecurity News Education will help you avoid falling into problems that other people have faced. Security requires experience and often a bit of creativity.

What else can be done? Testing your system often reveals vulnerabilities that you may not have been aware of. Here is an excellent paper on NMAP that can get you started. Red Hat users may want to consider using up2date (Red Hat Update Agent), a program that initiates an interactive process to easy apply the appropriate RPMSs to a system.

The Ramen worm was successful because of a few factors.

Lack of system knowledge
Systems are installed using all default values not giving the configuration any thought

Passive Administrators
Advisories are not monitored and taken into consideration

Failure to see significance.
Vendor Advisories should be held in high regard and taken seriously

Security requires constant learning. How can you prepare for new vulnerabilities?

What is the Ramen Worm?

The 'Ramen worm' is a set of scripts written to propagate by compromising vulnerable systems, downloading itself, and then using the compromised host to search for other systems to attack. After the system is compromised, the script replaces all files named 'index.html' with the text "Hackers looooooooooove noodles" and a picture touting their favorite snack, "Top Ramen." After the damage has taken place the scripts seemingly close the vulnerabilities (only disable FTP) to prevent the server from future Ramen attacks or looting script kiddies.

What systems are vulnerable?

Red Hat 6.2 systems not patched for wu-ftp for nfs vulnerabilities and Red Hat 7.0 systems not patched for LPRng are vulnerable. Although Red Hat is the only distribution specifically mentioned, other distributions (especially those based on Red Hat) that distribute these packages are also at risk.

What exactly does the Ramen Worm do?

do {

Initially after a system has been compromised, the Ramen worm starts scanning for systems with port 21 (common port used for FTP) open. The scripts then grab the FTP banner and use the version and date information to determine which vulnerability would most likely exist. After a system is exploited it creates a directory "/usr/src/.poop" and requests a copy of itself (ramen.tgz) for download through its own port 27374. It then changes every instance of "index.html" found on the system.


How can it be prevented?

After reading the text above, you should probably already know the answer to this question. In short, get to know your system, remove what you don't use, and update what you do use. Currently the Ramen worm targets Red Hat systems running LPRng, wu-ftp, and nfs.

Red Hat 6.2 - wu-ftpd

6/23/2000 23:14 : Red Hat: wu-ftpd update
Red Hat Advisories
rpm -Uvh

Red Hat 6.2 - nfs-utils

7/17/2000 23:19 : Red Hat: Updated package for nfs-utils available
Red Hat Advisories
rpm -Uvh

7/21/2000 13:32 : Red Hat: UPDATE: nfs-utils vulnerability
Red Hat Advisories

Red Hat 7.0 - LPRng

09/26/2000 13:28 : Red Hat: 'LPRng' vulnerability
Red Hat Advisories
rpm -Uvh

How do I detect and remove the worm?

This email address is being protected from spambots. You need JavaScript enabled to view it. has written an excellent paper that describes the makeup of the Ramen Worm in great detail. It is titled "Ramen Internet Worm Analysis" and is located here:

He offers a detailed section on removal and incident recovery. Here is the method that he outlines for removal. If you have any questions or have the curiosity to want to know how the scripts actually work I would highly recommend reading his paper.

  • If you want to allow anonymous FTP, then remove "ftp" and "anonymous" from /etc/ftpusers
  • If you use wu-ftpd then upgrade to the latest version from the Red Hat errata web site
  • If you use NFS then upgrade to the latest version from the Red Hat errata web site
  • If you use LPRng then upgrade to the latest version from the Red Hat errata web site
  • Remove "/usr/src/.poop/start*.sh" from /etc/rc.d/rc.sysinit
  • Delete the /usr/src/.poop directory containing worm files
  • Delete /tmp/ramen.tgz
  • Delete /sbin/asp
  • Change /etc/xinetd.conf or /etc/inetd to no include /sbin/asp
  • Red Hat 6.2: Remove "asp stream tcp nowait root" from /etc/inetd.conf
  • Red Hat 7.0: Remove asp entry from /etc/xinetd.conf
  • Restore /etc/hosts.deny unless you didn't use tcp wrappers
  • Restore any replaced index.html files with originals from backup
  • Reboot the system to kill active worm daemons