Click on our Sponsors to help Support SunWorld
Security: Pete's Wicked World by Peter Galvin

Where's the fox?

Is the fox in your hen house? Or was the fox already there?

November  1995
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

Over the last two months we've looked at tools to check and correct security problems. This month we consider the other half of the battle -- tools that help detect whether you've been broken into, and those that actively help prevent break-ins. Next month we start looking at the front door -- firewalls.

Also in Pete's Wicked World this month: An important security hole you should know about and guard against. Finally, check the bookstore for some useful network resources. (2,600 words)

Mail this
article to
a friend
Now that you've filled the open security holes on your system, it's time to tackle the other half of last month's security to-do list: logging and monitoring (see "Re-tooling" SunWorld Online October 1995). You might be tempted to think of this phase as secondary: "Well, I plugged the holes and eventually I'll get around to monitoring the systems." However, consider that the FBI's National Computer Crimes Squad estimates that as many as 97 percent of break-ins are not even detected. While some hackers do cause damage, and are therefore relatively easy to detect, other's simply gain access to your systems to steal company secrets, spy on you or your co-workers, or use your systems as a base for attacks on others.

Don't let your site be the victim of an undetected intrusion. The tools described below are, for the most part, easy to install and use. They don't require much maintenance once they're in place, and they provide a high-level of comfort to you: you know that the chances are good that you'll detect attempted and successful break-ins.

Once again, the best place to start tracking down these tools is the security tools page. With this as a home base, here is the remainder of our to-do list:

  1. Install tools to monitor the system and alert you about system file changes
  2. Log all network connections
  3. Limit access to network daemons
  4. Prevent users from choosing easy-to-guess passwords


Install monitor and alert tools
What happens if a stealthy hacker breaks into your system? Well, he or she first tries to become root, then proceeds to explore your system, do damage, or set up a base camp. In the latter case, a typical scenario involves the hacker installing a set of tools and modifying system programs. Why modify the programs? Well, the intruder wouldn't want ps displaying the fact that a network password-catching program was started, or even that the Ethernet interfaces are in promiscuous mode and watching everything that's happening on your networks. Finally, the hacker would want to leave behind suid-root programs to ease the task of becoming root in the future. With the tools we described last week, you can watch for unusual setuid-root programs. But how can you tell if ps has been modified, or indeed that any system program has been co-opted by an intruder?

To monitor changes to system programs, you need a history -- you need to know what the contents of the files were when they were installed (or at least when you believe the system was not compromised). You then need to compare the "good" contents to the current contents and see what has changed. Of course some programs will have changed due to patches retrieved from Sun. But knowing which have changed is the first step toward determining why they changed and who made the change.

There is one essential tool for monitoring the state of your Unix system programs. The tool is Tripwire, a product of the COAST computer security research project.

Tripwire uses a secure checksum Message Digest (MD) algorithm to take a thumbprint of all specified files, and stores them in a file. On subsequent runs, it compares these checksums against the current checksum of each file and alerts you if the values are different.

Solaris actually comes with a similar facility, part of the ASET tool, which used to be unbundled. Unfortunately, ASET doesn't use as secure a checksum method as tripwire. The risk with any checksum method is that two different files will generate the same checksum value, giving a "false positive" result. The more secure the method, the less likely this will happen. Another limitation of ASET is that it stores the checksum results in a known location. Any hacker knowing this location could remove or modify the checksum file.

With any checksum method, move the results file to a secure location. One option is to hide it in the filesystem, but a better solution is to move the file offline to tape in a secure location, and restore it just before running the next scan.

Log all network connections
There are many different aspects to network monitoring. Consequently (and conveniently) there are several tools to help keep you informed about network activity.

The first tool creates a log of ARP information. ARP is the protocol that resolves an Internet address to an Ethernet address. If a local hacker replaces one of your trusted systems (say a workstation) with a PC, and assigns the PC the same Internet address as the workstation, then in most facilities that PC will be trusted just as the workstation was. This is the weakness of standard Unix network authentication. Secure RPC and NIS+ (when used properly) solve this problem, but most sites simply use Internet addresses as the authentication method between systems. So now we have a situation where a bogus system can have the same Internet address as a trusted system. The only way to detect this situation is to note that the Ethernet address of the device has changed. (Each Ethernet device has a unique address encoded on it; it's those five colon-separated hex values you see associated with Ethernet interfaces.) ARPwatch allows you to watch for this situation.

As mentioned earlier, a tell-tale sign a system has been hacked is that its Ethernet interface is in promiscuous mode. In promiscuous mode, all packets on the network, rather than just the packets sent to the system's Ethernet number, are visible to the system. This method is responsible for many of the password-logging problems on the Internet. In those scenarios, hackers:

  1. Break into an Internet provider.
  2. Place the system's Ethernet port in promiscuous mode.
  3. Run a program which logs the first few characters of every TCP/IP connection, say 128 bytes (because it's usually at the start of a session that the user types in the remote system's password).
  4. Collect the log file or have it e-mailed to them.

Voila! Tens, hundreds, or maybe thousands of hostnames, usernames, and passwords are at the hackers' disposal.

Unfortunately, Solaris 2 provides no way to test to see if your interface is in promiscuous mode. You need the ifstatus tool.

Other useful network tools include:

Limit access to network daemons
One of the most vulnerable facilities in Unix is network services. While the Unix filesystem was designed with at least some security precautions in mind, network services were originally designed for use between trusting hosts. Because many different companies support networking, it is much harder to change a networking standard (like TCP/IP) than it is to add internal security to any given operating system.

So, we live in a world where networking facilities are desirable, forcing you to trust external hosts, but all the while having hackers living on those very same hosts. What to do, what to do? The standard method is to guard your doors (see next month's firewalls column), as well as locking down your goods. To do that, you protect each network service that is protectable, limit access as much as possible, and log all connections to make the job of detecting and resolving problems easier.

The logdaemon tool, written by Wietse Venema, co-author of Satan and a security luminary, is a good place to start. It provides

S/Key is an implementation of the challenge-response (or "one-time password") security mechanism. The theory is that both the system and the user know a secret, and the user proves to the system that he or she knows the secret, but the user never actually sends the secret over the network. Therefore, a cracker snooping the network and witnessing the exchange cannot use what was just discovered and reply to it. It only works once. Challenge-response systems are another topic deserving future discussion in this space.

Further daemon logging is available via tcp_wrappers, which controls access to tftp, exec, ftp, rsh, telnet, rlogin, finger, and systat facilities. Its power is in its convenience: it can be installed without changing any system software components. Rather, /etc/inetd.conf is modified to invoke the tcpwrapper daemon before invoking any of its daemons. tcpwrapper then logs the connection and uses an access control list, if desired, to allow or disallow the access.

A modified version of portmapper is available that disallows proxy access and reduces other vulnerabilities that are known security problems.

Similarly, a new version of rpcbind prevents hackers from bypassing NFS export restrictions.

If you provide Anonymous FTP access to your system, I strongly advise you to replace your ftpd with WU-ftpd. Not only does it add extensive logging to ftpd, but it provides a mechanism for limiting the concurrent number of anonymous ftp connections. Note that WU-ftpd was once the target of a hacker, and had a back door planted in it to allow a remote user full ftp access to the systems it was running on. The important moral is that any software can be a security risk. Only use software that is necessary, only enable daemons that are needed, and trust no package to be uncorruptible.

Finally, you could replace inetd itself with the more secure xinetd. xinetd adds logging and access control for both TCP and UDP services. It is more thorough than tcp_wrappers, because it protects UDP-based services as well. However, it requires you to replace an important system program.

Prevent easily guessable passwords
The best way to prevent users from choosing bad passwords is to educate them. The tools available will not prevent all bad passwords, just the ones that are easy to detect. For instance, a user might use a relative's name as a password. If this word isn't in the dictionaries that a password tool uses, it is allowed as a "good" password. Unfortunately, anyone knowing the user might be able to guess the use of this bad password and break into the system.

We recommend first reading the AUS Security Checklist, which is a good list of system security aspects. The Australian CERT also has a list of rules for chosing a good password. This could be a document you hand out to your users.

Next, you should enforce your password policies by replacing the passwd program with one that checks the password and only allows good passwords. Two tools to look at are passwd+ and npasswd. npasswd seems to be the more thorough and customizable tool, but the Solaris and shadow-password-file version is still in testing and not yet available. I'll include a note in this space when it is ready.

Bug of the Month Club
Those students at U.C. Berkeley have been busy again. Instead of re-inventing Unix, as they were doing a few years back, they are putting computing theory to practice to show that Netscape is not secure. The communication security that Netscape uses (or should I say used) was based on some easily guessable premises. It took the Berkeley students less than a minute to break a secure transaction. Netscape has a description of the method used available on-line, as well as a new version of the Netscape browser that solves the problem. To Netscape's credit, it publicized the problem immediately and acted quickly to remedy the situation. Further, the company is going to make public the new, more secure code for industry experts to scrutinize.

The Bookstore
There's a very nice, general-purpose system-administration page, called the Unix Guru Universe being put together by Kirk Waingrow. Check it out, as it has the best set of pointers to system administration references that I've found. Included, of course, is a nice collection of security pointers.

Also, I wanted to be sure you knew about a very good paper on forming an incident response team even though I haven't covered that topic here yet. (Check out the "Forming*" files there.) I'll tackle the topic in a future column. Feel free to send me comments about what you're interested in reading here, as well as the priorities of the material you'd like me to cover. Want to hear about response teams sooner rather than later? Let me know.

Next Month, on "As Pete's Wicked World Turns"

Next month I begin the long, slow descent into the world of firewalls. First I'll talk about what they're good for, and what they're not good for. Then I'll discuss the technology, the available public-domain and commercial firewalls, and how to go about putting a firewall between you and the bad guys.

Click on our Sponsors to help Support SunWorld


About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a new Systems Integrator. He is also Adjunct System Planner for the Computer Science Department at Brown University, a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: