Where's the fox?
Is the fox in your hen house? Or was the fox already there?
November 1995
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Where's the fox?Is the fox in your hen house? Or was the fox already there? |
November 1995
|
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 |
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:
|
|
|
|
|
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:
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.
|
|
Resources
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 peter.galvin@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-11-1995/swol-11-security.html
Last modified: