Originally, the people on the Internet were the people who built the Internet, but as time passed and the Internet became more useful and more reliable, they were joined by other people at their companies and universities--and then by other companies and universities. With fewer common goals and more people, the Internet became a much more dangerous place. Although various sorts of mischief were quite common, these incidents got little publicity, and most people who thought of computer security problems at all assumed that such problems involved teenagers breaking into banks with modems.
The Internet Worm changed all that. In November of 1988 the Internet linked about 60,000 computers, and a good many of them found themselves under attack. Even those not affected by the Worm still had to be checked and rechecked to be sure they were safe from infection. Estimates of the total price tag for the incident are in the hundreds of millions of dollars.
The Worm was the first Internet security incident to hit the nightly news. People who had been working in obscurity suddenly found TV camera crews in their machine rooms. The issue was no longer whether you needed to secure your computer systems--it was how you were going to secure them.
In the years since the Worm, there has been an explosion in Internet usage--and a corresponding explosion in new types of Internet attacks. Consider a few recent reports from the front:
Most systems and users have tightened up their security in the wake of the Internet Worm. Guest and admin passwords have become rarer, but password security as a whole is still laughable in most places. Group accounts abound, and invariably at least 10 percent of the passwords users select are poor (the only way to make them better is to install a password program that forces good passwords). Readily available password dictionaries, cracking programs, and password sniffing combine to make passwords very vulnerable.
How can you avoid password attacks? Educate the users on your system so they pick better passwords. Consider using system-generated passwords or, better still, stronger types of authentication, such as one-time (nonreusable) passwords.
How does password sniffing work? In many network setups, it is possible for any machine on a given network to hear the traffic for every machine on that network. This is true for most Ethernet-based networks, and Ethernet is by far the most common local area networking technology in use today. This characteristic of Ethernet is especially dangerous because most of the protocols in use today are unencrypted. As a result, the data sent and received is there for anybody to snoop on. This data includes files accessed via network file systems, passwords sent to remote systems during Telnet, FTP, and rlogin sessions, electronic mail sent and received, and so on.
A password sniffer is a program that takes advantage of this characteristic to monitor all of the IP (Internet Protocol) traffic on its part of the network. By capturing the first 128 bytes of every FTP or Telnet session, for example, password sniffers can easily pick up your user name and password as you type them. Password sniffers may use programs provided for network debugging as building blocks, or may be written to use the services directly. Special-purpose password sniffing toolkits are widely available to attackers.
The danger of password sniffing attacks is in their rapid spread. Favorite targets for sniffers are network providers and public access systems where the volume of Telnet and FTP connections is huge. One sniffer on large public access systems can collect thousands of sniffed account names and passwords, and then compromise every system accessed. Even if your systems are as secure as possible and your user passwords are not guessable, you can be infected by a packet sniffer running at any site that your users can log in from, or at any site their packets will cross to get to you.
Password sniffing can happen anywhere. Many people make the mistake of assuming that because they're using a well-known, commercial service, there is no danger in remotely accessing their own machines across the network. In fact, the commercial services are prime targets, and most of them are periodically compromised. In any case, a connection may cross a large number of intermediate networks, which each represent unknown risks. How can you avoid being sniffed? In general, you can't and still provide remote network access. If your password ever passes across a network which might be insecure--electronically or physically--it is likely to be captured. What you can do is ensure that an intruder who gets your password can't use it. One-time (nonreusable) passwords are probably the most effective way. Using a freely available program like Bellcore's S/Key may not keep your passwords from being viewed, but because these passwords are used only once, it doesn't really matter if they are seen.
The Network File System (NFS) and Network Information Service (NIS) are notoriously easy ways to attack a system. NFS allows systems to share files over a network by letting a client mount a disk on a remote server machine. NIS maintains a distributed database of password tables, group files, host tables, and other information that systems on a network can share. Many sites choose not to support NIS at all, and some avoid even NFS. However, these services are not a problem if they are run in a protected environment (for example, behind a fire wall).
If you haven't properly protected your site, an attacker may be able to simply NFS-mount your filesystems. The way NFS works, client machines are allowed to read and change files stored on the server without having to log into the server or enter a password.
Because NFS doesn't log transactions, you might not even know that someone has full access to your files.
NIS is most often used to distribute password information, and most implementations of NIS provide absolutely no control over which machines can request information. As long as an attacker can guess the name of your NIS domain and can send an NIS request to your NIS server, that attacker can get a full copy of your password information (including encrypted passwords), even if you are running shadow passwords and the passwords are not in the /etc/passwd file. The attacker is then free to crack your passwords at leisure.
NFS, NIS, and other services have additional security vulnerabilities, both obvious and not so obvious. For example, NFS has very weak client authentication, and an attacker may be able to convince the NFS server that a request is coming from a client that is permitted in the exports file (the file that lets you specify which file systems can be mounted via NFS, and which other machines can mount them). There are also situations in which an attacker can hijack an existing NFS mount. (See the discussion of hijacking attacks later in this article.)
In the other category of attack, equipment or services are completely shut down or disabled. With ICMP attacks, which are becoming more common on the Internet, an attacker sends an ICMP message to a host or router, telling it to stop sending packets to all or part of the network.
How can you prevent denial of service attacks? The best defense against an ICMP attack is to install a firewall that ignores or filters ICMP messages.
In general, though, denial of service attackers are tough to prevent--electronically, as well as in real life. If you accept things from the external world--electronic mail, telephone calls, or packages--it's possible to get flooded. The famous college prank of ordering a pizza or two from every pizzeria in town to be delivered to your least favorite person is a form of denial of service. (It's hard to do much while arguing with 42 pizza deliverers.) In the electronic world, denial of service is as likely to happen by accident as on purpose. (Have you ever had a persistent fax machine try to fax something to your voice line?) The most important thing is to set up services so that if one of them is flooded, the rest of your site keeps functioning while you fix the problem.
Fortunately, denial of service attacks are not terribly popular. They're easy enough to be unsporting; they tend to be simple to trace back--and therefore risky to the attacker; and they don--t provide the attacker with the information or the ability to use your computers that is the payoff for most other attacks. Intentional denial of service attacks are the work of people who are angry at your site in particular--and at most sites, there are very few such people.
Certain kinds of firewalls work by keeping packets from being routed from an outside system into your internal network. In normal packet routing, packets are routed in the most efficient way from source to destination. However, if the source routing option is specified for a packet, it shows the particular route that the packet is to follow. Unfortunately, turning off the regular routing of packets from the Internet to an inside network doesn't turn off the routing of source-routed packets on BSD systems. At tackers have exploited this peculiarity and used it to penetrate systems that are expecting their firewalls to keep all such outside packets out.
Another attack, which surfaced for the first time in early 1995, involves attackers creating packets with false IP addresses. By exploiting applications that use authentication based on IP addresses (such as the so-called Berkeley RrS commands, which include rlogin, rsh, and rcp), intruders have been able to gain access. Most of the attacks take advantage of the ability of intruders to guess sequence numbers associated with network connections and the acknowledgments passed between machines. These attacks are technically tricky, because the intruder doesn't receive the responses to the packets it sends; when they succeed, however, the payoff for these attacks can be high. (The attack on Shimomura described earlier was this type.)
How can you prevent these attacks? Firewalls are the only sufficient defense. You want to look for packets on your external interface (that is, packets coming from outside your internal network) that claim to have internal source IP addresses and for packets that have source routes specified. You can do this by installing an appropriately configured packet filtering router. It's also best to avoid address-based authentication completely, if you can.
This sort of attack has always been possible, but is easier to do and harder to detect with the new tools. Various forms of hijacking--from the completely unsubtle method of waiting for someone to get up for a cup of coffee without locking their screen, to the devious exploitation of window systems--have long been the most popular attacks at universities and other places where people may legitimately have access and yet simultaneously be hackers. In the past, these attacks have mostly been aimed at users at the site where the attacks were taking place. The new attacks are aimed at getting from a compromised system to an otherwise uncompromisable system across the Internet.
How can you prevent this attack? Once intruders have root access, you can't. So keep them out to begin with.
There isn't a magic Internet security bullet. The best security solution isn't a simple solution, but a collection of strategies and techniques. Your own site's security philosophy, the characteristics of your users, the type of data you're protecting, and your budget all help determine the right approach for you. Here are some suggestions.
In Practical UNIX Security, Simson Garfinkel and Gene Spafford offer hundreds of specific suggestions for host security and also discuss a wide range of network security problems and solutions. This book has become the classic security reference for UNIX users and system administrators.
PGP is a program that implements the RSA algorithm and is freely available on the Net (for noncommercial use within the United States). In PGP: Pretty Good Privacy, Simson Garfinkel describes how to use PGP to encrypt files and email and how to "sign" your email with an unforgettable digital signature, proving to recipients that your messages were sent by you and weren't modified during transmission. The book also contains a fascinating, behind-the-scenes look at the development of Phil Zimmermann's controversial program and the issues surrounding privacy, the export of encryption programs, and cryptography patents.
The dictionary definition of "firewall" is: "A fireproof wall used as a barrier to prevent the spread of a fire." A fire may damage, or even destroy, one section of a building, but a firewall may keep that fire from spreading to other sections of the building; at the very least, it may slow down the spread until the fire can be brought under control.
On computer networks, firewalls serve an analogous purpose. A security problem somewhere on a network--for example, eavesdropping, a major break-in, or a worm program--may do a great deal of damage to one portion of the network. But if a fire wall is in place, it can isolate what's behind it from the security problem. Without firewalls network security problems can rage out of control, dragging more and more systems down. Once one system on a network has been compromised, it's often trivial to compromise the others. Shared system resources, homogeneous services, and trust policies may all contribute to the spread of a security problem from one system to another.
Think of a firewall as a checkpoint; all traffic is stopped and checked at this point--usually, at the perimeter of your internal network, where you connect to the Internet (see the figure above). Your own site's security policy determines what happens at the checkpoint. Some requests (e.g., requests for email service) might pass right through. Others (e.g., requests for potentially dangerous service like NFS or NIS) might be turned away. Still others (e.g., requests for FTP file transfers) might be routed to proxy services, which satisfy the requests without directly exposing internal systems.
If your site is connected to the Internet, you may want to check out our forthcoming book, Internet Security Firewalls, by D. Brent Chapman and Elizabeth D. Zwicky. It contains the details of various firewall approaches and architectures, how you can build packet filtering and proxying solutions at your site, and how to configure Internet services to work with a firewall.
Two books provide valuable information on understanding and establishing security at your site.
Computer Security Basics, by Deborah Russell and G. T. Gangemi, is the first book to read if you want to learn what computer security is all about. It contains the basics of access control, encryption, trusted systems, and physical security, as well as a history of computer security developments, U.S. Government security programs (such as the "Orange Book"), and a complete glossary and resource summary.
Computer Crime: A Crimefighter s Handbook, by David Icove, Karl Seger, and William VonStorch, is aimed particularly at those who need to investigate computer crimes--law enforcement, managers, and others. It describes targets, criminals, methods, and security measures you can take to prevent them. It also details the way to detect, investigate, and prosecute computer crimes, and it includes the complete text of all computer crime laws, both federal and state.
Comments are appreciated to: Markus Hübner.