Sniffers In The Wrong Hands.

by Robert Kane, Intrusion Detection Inc.

The nature of LAN protocols, originally developed to make sharing data and devices an easy and simple task, are such that anyone with a simple protocol analyzer or sniffer can read and re-assemble all transmitted data with little difficulty. In addition to observing the specific information on the LAN, it gives those intent on gaining access to private information resources a set of addresses, passwords, access codes and traffic patterns.

What Is Promiscuous Mode?

Due to the open nature of LAN technology, when two or more LAN devices communicate, a packet consisting of data and associated routing information, is broadcast throughout a LAN for all other devices to "hear." For example, when communicating, a workstation's LAN card listens for the network destination address of all transmitted data and system information. While all LAN devices listen to all network packets, when network cards operate in so-called "non promiscuous" mode they only read the associated packet of data when encountering its own unique network address.

However, a knowledgeable user with modification authorization for network operating system programs could easily change default communications settings to enable a "promiscuous" mode. As its name implies, a promiscuous mode change enables the LAN card to read and receive all broadcasted data packets. The determined hacker easily could filter through all transmitted LAN data for sensitive information.

More critically, IDs and passwords of other corporate platforms accessible via the LAN could be accessed, including the corporate mainframe.

While the average user will probably not know how to enable a "promiscuous" mode setting, there are an increasing number of network management tools available that can be used to easily set workstations into "promiscuous" mode.

Internet Sniffers

The internet contains numerous public domain and shareware programs that allow monitoring of data packets. Armed with network scanning tools and encryption techniques, Internet intruders have grown bolder during 1995.

Internet prowlers have used "sniffers" to pluck passwords and access codes from network traffic and covered their tracks with widely available encryption tools, members of the Forum of Incident Response and Security Teams (FIRST) said at a recent conference in Boston.

One of the worst Internet attacks in history occurred when more than 100,000 Internet accounts were comprised using sniffers last year between January and March. Inserted through system holes detected by hackers, these sniffers are software programs that sit quietly and just monitor network traffic. Because sniffers are not transmitting data, they are often difficult to uncover.

These silent packet analyzers can record the first 128 bytes of a log-in session and in that way capture host names, user names and passwords. The danger is that sniffers can feed off the Internet's connections and garner root privileges from a vast number of remote computers, routers and gateways.

But if information is truly valuable, why use a shareware product when robust professionally designed sniffers are available for only about $900. For example, Intel's LAN Desk Manager or Novell's MangeWise are reasonably priced tools for managing Novell LANs. Both can be used to monitor traffic and capture non NetWare user Ids and passwords. IN addition, the real sniffer, from Network General Corp., while expensive at $20,000 is a very robust hardware-based tool.

Encryption As A Solution

Encryption is the primary solution to the inherent security exposures of the broadcast technology used by LANs. By encrypting data packets, while leaving routing information unencrypted, the data confidentiality on a network can be ensured.

There are a number of new products that provide Ethernet data packet encryption, including data sanitization through the use of intelligent hubs. Bay Networks, Cabletron Systems and Racal-Guardata all offer products that either encrypt of sanitize transmitted data sanitization.

Encryption Strength

Not only is it important to encrypt sensitive information, but the encryption technique used must be a strong defense especially as the level of sensitivity of the information transmitted on the LAN increases. For example, quarterly earnings reports from the chief financial officer's office or merger and acquisition data can be sold or traded upon.

It is important to use secure encryption methods, such as the U.S. National Security Agency-endorsed data encryption standard (DES) or R.S.A.'s Public Key Encryption. In addition, it is well worth keeping up to date on technology advancements effecting security. For instance, there are increasing reports of weaknesses in DES that could reportedly make it easier to crack. These claim are still being investigated.

Computer security experts have speculated for years that DES has a trap door. They ponder why else would the N.S.A. have promoted a code, to be widely used and sold, that it could not crack? However, DES has stubbornly resisted the penetration efforts of mathematicians and computer scientists. But poking away at DES seems to have become a hobby for many civilian cryptographers wondering what the NSA's secret in building codes is.

However, it appears cracking methods are still not practical since they require nearly as many calculations as performing an exhaustive search. In addition, these method requires an encoded copy of a known message.

Traffic Flow Analysis

While strong encryption methods are recommended by security consultants and experts, there are other methods to obtain information about a company such as by watching traffic flows through the network.

How would this be useful? By watching the flow of information on the LAN, the traffic of critical decision and senior management makers can be identified. Once identified, sensitive data traffic can be focused on interception.

Based on the theory that information usually flows from decision makers to workers, an infamous hacker's (Kevin Mitnick) early exploits led to the discovery of a serious security exposure in Digital's VAX/VMS Operating System. Mitnick apparently had a gift for sensing how organizations functioned and who was important in an organization. And while untrained, he could look at patterns of communication in stored electronic mail and figure out who had power and who had valuable information. In this way, he found e-mail that was worth looking at further.

Mitnick eventually identified the mailboxes of two VMS security experts who together conversed and collected information about VAX/VMS security flaws. Ironically enough, it was while snooping through these security experts mail that Mitnick found the infamous Chaos Computer Club patch. During the summer of 1987, the Chaos Computer Club, hacked into NASA's worldwide SPAN computer network, the backbone of which are VAX machines.

Incidentally, the Chaos patch, was basically a password harvesting program, which upon login sent a copy of a users password to a remote corner of the system, where it sat unnoticed until someone, like Mitnick came to retrieve it.

Return Back To Index

Network Security White Paper

And so, the critical question remains:

How do you stop unwanted access to your corporate data?

The Network Security Crisis - A White Paper

Table of Contents

1. Introduction - The Issues Surrounding Security
   • The Technology is Not Foolproof
   • Attacks Through the Network
   • Attacks from Within
   • Security is Your Responsibility
   • Solving the Problem
2. The First Steps in Security
   • Basic Reasons for Security
   • Security in Networks
3. Packet Filtering Gateways
   • Bargain Firewalls
   • How They Work
   • Configuring a Packet Filter
   • Not Hacker-Proof
4. Application Level Gateways
   • Purpose-Built Protection
   • How it Works
   • Secure E-Mail
   • Realtime Security Monitoring
   • Spoofing
   • Auto-Checking
   • Encryption
   • Unplanned Activity Monitoring
   • Managing Subnets
   • Protecting Your LANs at the Desktop
5. Circuit-Level Gateway
   1. The Gateway as a Wire
   2. How it Works
   3. Managing a Circuit-Level Gateway
6. Frequently Asked Questions
   1. What is a network firewall?
   2. Why would I want a firewall?
   3. What can a firewall protect against?
   4. What can't a firewall protect against?
   5. What are good sources of print information on firewalls?
   6. Where can I get more information on firewalls on the network?
   7. What are some of the basic design decisions?
   8. What are proxy servers and how do they work?
   9. What are some cheap packet screening tools?
   10. What are some reasonable filtering rules for my Cisco?
   11. How do I make DNS work with a firewall?
   12. How do I make FTP work through my firewall?
   13. How do I make Telnet work through my firewall?
   14. How do I make Finger and whoois work through my firewall?
   15. How do I make gopher, archie, and other services work through my firewall?
   16. What are the issues about X-Window through a firewall?

Introduction: The Issues Surrounding Security

"The Technology is Not Foolproof"

Instant access to information by anyone, from anywhere, results in some serious security issues. The network is usually the most insecure part of an organisation's computer system. Telecommunications protocols used by the Internet were not designed with security in mind, and may users and network administrators are not willing to put up with the extra "nuisance" of security controls. These issues, coupled with the fact that vendors do not write totally secure and bug-free operating systems, create holes that can be exploited by the knowledgeable system hacker.

Although organisations like CERT try to communicate security holes, the networking community is only alerted when a fix is available. Few system/network managers have the time and resources to test, install, and debug these fixes within their enterprise. The problem is further exacerbated when legacy machines are not replaced, and more secure releases of operating systems are incompatible with the main-frames that store the bulk of a corporation's data. As a result, most of these widely known holes remain unfixed.

"Attacks Through the Network"
Successful "system hackers" communicate with "would-be hackers." Here's an example. Early in 1994 a successful "sniffing" program was installed by unidentified individuals at PANIX (Public Access to UNIX in New York). Within days, thousands of user names and passwords were stolen. Shortly thereafter, a similar incursion was successfully accomplished at BarNet in California. Again, account information was stolen. The clincher came when the source code for this password sniffer was openly posted on the Internet. Within days, hundreds of attacks were launched around the world.

As organisations become global, they are increasingly vulnerable to "snooping" from their competitors and even from foreign governments. There is overwhelming evidence that some foreign governments routinely tap electronic mail from US companies to their subsidiaries and affiliates and pass technical data on to their local industries for competitive advantage. The former director of DSGE (the French equivalent of the US Secret Service) has publicly stated : "It would not be normal to spy on the US in political matters or military matters. But in economic competition, in technical competition, we are competitors. We are not allied."

"Attacks from Within"
A common fear is that a network will be compromised by "outsiders." Data from the FBI suggests that over 85% of all computer crime is perpetrated by individuals who are authorised to use the systems they are working on. They may be disgruntled employees, they may have been bribed, or they may just be larcenous.

Regardless of the motivation, user authentication systems like smart cards or non-reusable passwords are important parts of an overall security policy, but by themselves, do not provide adequate protection or security to the overall network. Employees are legal users. Once they get onto one machine, networks can fall like dominoes. And, according to an Ernst and Young study, one in four North American companies have suffered financial losses ranging from $100,000 to $1 million due to computer security breakdowns.

"Security is Your Responsibility"
A study conducted by Information Week in 1993 found that over 90% of surveyed IS executives classed "access to information by those who did not need to know" as their biggest unsolved problem.

Pending laws will mandate that data security is your responsibility. The 1992 California electronic Privacy Act proposed that if you so poorly protect your data, and if someone is able to access it and then commits a crime with it, you are also guilty. Although the target of this law is the credit card companies, it was written so broadly that the final decision about what constitutes and adequate level of protection may well be decided by juries. Lawsuits have already been filed against directors and officers of major organisations for the failure to adequately protect intellectual property (including computerised data files and confidential information).

The current standards for legal liability state that if you choose not to implement "reasonable" safeguards to prevent a dangerous event, you may be found guilty of negligence.

What makes computer crime so difficult to deal with is that physical access to the machines is not necessary. It is possible to break into machines from anywhere in the world, at any hour of the day or night. Because of insecurities in the network protocols, it is possible to do this without leaving the slightest electronic fingerprint by which they can be traced "after the fact."

"Solving the Problem"
Obviously, the problem won't go away. Few companies are willing to commit intellectual and economic suicide by not making their LANs available, or by not joining the Internet community.

Two traditional approaches have been used to protect corporate data: a simple network firewall and routers. While they provide a certain level of security, their limitations create loopholes that make network access simple.

A firewall is a gateway system that prevents network traffic from getting into your system. Although firewalls keep people out, they make it impossible for your employees to access their own data and systems when they are outside the walls of your network.

Routers can be used as very limited gateways. Routers, however, do not provide any real-time trace back ability for suspicious activity, nor can they alert system management if anything is amiss. And routers, by design, can be reprogrammed remotely - for nefarious or well-intentioned purposes. Another problem with routers is that the authorisation rules that you specify can often be re-sequenced by the router vendor's compilation tools to give you the exact opposite of what you are trying to achieve.

The First Steps in Security

"It is easy to run a secure computer system. You merely have to disconnect all dial-up connections and permit only direct-wired terminals, put the machine and its terminals in a shielded room, and post a guard at the door." - F.T. Grampp & R.H. Morris

"Basic Reasons for Security"
For better or for worse, most computer systems are not run that way today. Security is, in general, a trade-off with convenience, and most people are not willing to forgo the convenience of remote access via networks to their computers. Inevitably, they suffer from some loss of security.

The situation is even worse for computers hooked up to some sort of network. Networks are risky for at least three major reasons. First, and most obvious, more points now exist from which an attack can be launched. Someone who cannot get to your computer cannot attack it; by adding more connection mechanisms for legitimate users, you are also adding more vulnerabilities.

A second reason is that you have extended the physical perimeter of your computer system. In a simple computer, everything is within one box. The CPU can fetch authentication data from memory, secure in the knowledge that no enemy can tamper with it or spy on it. Traditional mechanisms -- mode bits, memory protection, and the like -- can safeguard critical areas. This is not the case in a network. Messages received may be of uncertain provenance; messages sent are often exposed to all other systems on the net. Clearly, more caution is needed.

The third reason is more subtle, and deals with an essential distinction between an ordinary dial-up modem and a network. Modems, in general, offer one service, typically the ability to log in. When you connect, you are greeted with a login or username prompt; the ability to do other things, such as sending mail, is mediated through this single choke point. There may be vulnerabilities in the login service, but it is a single service, and a comparatively simple one. Networked computers, on the other hand, offer many services: login, file transfer, disk access, remote execution, phone book, system status, etc. Thus, more points are in need of protection -- points that are more complex and more difficult to protect. A networked file system, for example, cannot rely on a typed password for every transaction. Furthermore, many of these services were developed under the assumption that the extent of the network was comparatively limited. In an era of globe-spanning connectivity, that assumption has broken down, sometimes with severe consequences.

"Security in Networks"
Networked computers have another peculiarity worth noting: they are generally not singular entities. That is, it is comparatively uncommon, in today's environment, to attach a computer to a network solely to talk to "strange" computers. More commonly, organisations own a number of computers, and these are connected to each other and to the outside world. This is both a bane and a blessing: a bane, because networked computers often need to trust their peers, to some extent, and a blessing, because the network may be configurable so that only one computer needs to talk to the outside world. Such dedicated computers, often called "firewall gateways," are at the heart of our suggested security strategy.

The purpose here is twofold. First, we wish to show that this strategy is useful. That is, a firewall, if properly deployed against the expected threats, will provide an organisation with greatly increased security. Second, we wish to show that such gateways are necessary, and that there is a real threat to be dealt with.

Packet-Filtering Gateways

"Bargain Firewalls"
Packet filters can provide a low-cost and useful level of gateway security. Used by themselves, they are cheap: the filtering abilities come with the router software. Since you probably need a routerto connect to the Internet in the first place, there is no extra charge. Even if the router belongs to your network service provider, you'll probably find that they'll install and filters you wish.

"How They Work"
Packet filters work by dropping packets based on their source or destination addresses or ports. In general, no context is kept; decisions are made only from the contents of the current packet. Depending on the type of router, filtering may be done at input time, at output time, or both. The administrator makes a list of the acceptable machines and services and a stoplist of unacceptable machines or services. It is easy to permit or deny access at the host or network level with a packet filter. For example, one can permit any IP access between host A and B, or deny any access to B from any machine but A.

Most security policies require finer control than this: they need to define access to specific services for hosts that are otherwise untrusted. For example, one might want to allow any host to connect to machine A, but only to send or receive mail. Other services may or may not be permitted. Packet filtering allows some control at this level, but it is a dangerous and error-prone process. To do it right, one needs intimate knowledge of TCP and UDP port utilisation on a number of operating systems.

Even with a perfectly implemented filter, some compromises can be dangerous.

"Configuring a Packet Filter"
Configuring a packet filter is a three-step process. First, of course, one must know what should and should not be permitted. That is, one must have a security policy, as explained earlier. Next, the allowable types of packets must be specified formally, in terms of logical expressions on packet fields. Finally -- and this can be remarkably difficult -- the expressions must be rewritten in whatever syntax your vendor supports.

An example is helpful. Suppose that one part of your security policy was to allow inbound mail (SMTP, port 25), but only to your gateway machine. However, mail from some particular site SPIGOT is to be blocked, because of their penchant for trying to mail several gigabytes of data at a time. A filter that implemented such a ruleset might look like this.

action	ourhost	port	theirhost	port	comment
block	*	*	SPIGOT	*	we don't trust these prople
allow	OUR-GW	25	*	*	connection to our SMTP port

The rules are applied in order from top to bottom. Packets not explicitly allowed by a filter rule are rejected. That is, every ruleset is followed by an implicit rule reading like this.

action	ourhost	port	theirhost	port	comment
block	*	*	*	*	default

This fits with our general philosophy: all that is not expressly permitted is prohibited.
Note carefully the distinction between the first ruleset, and the one following, which is intended to implement the policy "any inside host can send mail to the outside."

action	ourhost	port	theirhost	port	comment
allow	*	*	*	25	connection to their SMTP port

The call may come from any port on an inside machine, but will be directed to port 25 on the outside. This ruleset seems simple and obvious. It is also wrong.

"Not Hacker-Proof"

The problem is that the restriction we have defined is based solely on the outside host's port number. While port 25 is indeed the normal mail port, there is no way we can control that on a foreign host. An enemy can access any internal machine and port by originating his call from port 25 on the outside machine.

A better rule would be to permit outgoing calls to port 25. That is, we want to permit our hosts to make calls to someone else's port 25, so that we know what's going on: mail delivery. An incoming call from port 25 implements some service of the caller's choosing. Fortunately, the distinction between incoming and outgoing calls can be made in a simple packet filter if we expand our notation a bit.

A TCP conversation consists of packets flowing in two directions. Even if all of the data is flowing one way, acknowledgement packets and control packets must flow the other way. We can accomplish what we want by paying attention to the direction of the packet, and by looking at some of the control fields. In particular, an initial open request packet in TCP does not have the ACK bit set in the header, all other TCP packets do. [Strictly speaking, that is not true. Some packets will have just the reset (RST) bit set. This is an uncommon case, which we do not discuss further, except to note that one should generally allow naked RST packets through one's filters]. Thus, packets with ACK set are part of an ongoing conversation; packets without it represent connection establishment messages, which we will permit only from internal hosts. The idea is that an outsider cannot initiate a connection, but can continue one. One must believe that an inside kernel will reject a continuation packet for a TCP session that has not been initiated. To date, this is a fair assumption. Thus, we can write our ruleset as follows, keying our rules by the source and destination fields, rather than the more nebulous "OURHOST" and "THEIRHOST":

action	src	port	theirhost	port	flags	comment
allow	(our hosts)	*	*	25		our packets to their SMTP port
allow	*	25	*	*	ACK	their replies

The notation "{our hosts}" describes a set of machines, any one of which is eligible. In a real packet filter, you could either list the machines explicitly, or you could specify a group of machines, probably by the network number portion of the IP address.

Application-Level Gateways

"Purpose-Built Protection"
An application-level gateway represents the opposite extreme in firewall design. Rather than using a general-purpose mechanism to allow many different kinds of traffic to flow, special-purpose code can be used for each desired application. Although this seems wasteful, it is likely to be far more secure than any of the alternatives. One need not worry about interactions among different sets of filter rules, nor about holes in thousands of hosts offering nominally secure services to the outside. Only a chosen few programs need be scrutinised.

Application gateways have another advantage that in some environments is quite critical: it is easy to log and control all incoming and outgoing traffic. Outbound FTP traffic is restricted to authorised individuals, and the effective bandwidth is limited. The intent is to prevent theft of valuable company programs and data. While of limited utility against insiders, who could easily dump the desired files to tapes or floppies, it is a powerful weapon against electronic intruders who lack physical access.

An application-level "proxy" system, addresses the need for network security -- and overcomes the outstanding problems of less robust approaches, like packet filters. It is an integrated gateway system comprising a coherent security architecture. It can be configured to let selected sites have access to your system while excluding all others.

"How it Works"

The Gateway

It has the responsibility of taking network traffic packets and handing them off to another network. Usually this means taking them from the Internet and putting them onto your local network (and vice versa). The Gateway opens packets, examines their content, and ensures that they cannot potentially damage your network.

Once the packets are checked for safety, the Gateway builds new ones with the same contents. Hence, only packet types for which there is construction code can be sent out from the Gateway. It is impossible to send unauthorised packet types because there is no code to generate them. This prevents "back doors".

The new packets are sent out through an entirely separate network interface. By not sharing the "input" interface, it is impossible for undesired packet types to bypass the Gateway and get onto your net unchecked.

When a user outside your network wants to use a machine on your LAN, they must go through the Gateway box. Authorising access is handled by your systems Administrator.

The Authorisation Process

The Authorisation is placed in a separate sector of the workstation disc. This stops a remote user from interfering with the authorisation process. Only your system administrator, sitting at the console of the Authorisation workstation, can change the authorisation file.

The system administrator can specify that individual or entire groups of outside machines can use individual machines inside (and vice versa). They can specify times of day when service is permitted or denied. And they can ask to be alerted when certain requests are made, even if they are allowed. This feature is important, for example, in the case of a brokerage firm that would want to know every time a connection to them is made, regardless of the time of day.

"Secure E-Mail"
Electronic mail is often passed through an application-level gateway, regardless of what technology is chosen for the rest of the firewall. Indeed, mail gateways are valuable for their other properties, even without a firewall. Users can keep the same address, regardless of which machine they are using at the time. The gateway machines also worrys about mail header formats and logging (mail logging is a postmaster's friend) and provide a centralised point for monitoring the behaviour of the electronic mail system.

It is equally valuable to route incoming mail through a gateway. One person can be aware of all internal connectivity problems, rather than leaving it to hundreds of random system administrators around the Internet. Reasonably constant mail addresses -- Firstname.Lastname@Org.D is popular -- can be accepted and processed. Different technologies, such as uucp, can be used to deliver mail internally. Indeed, the need for incoming mail gateways is so obvious that the DNS has a special feature -- MX records -- defined to support them. No other application has a defined mechanism for indirect access.

These features are even more valuable from a security perspective. Internal machine names can be stripped off, hiding possibly valuable data. Traffic analysis and even content analysis and recording can be performed to look for information leaks. But these abilities should be used with the utmost reluctance, for both legal and ethical reasons.

Application gateways are often used in conjunction with the other gateway designs, packet filters and circuit-level relays. An application gateway can be used to pass X11 through a firewall with reasonable security. The semantic knowledge inherent in the design of an application gateway can be used in more sophisticated fashions. Gopher servers can specify that a file is in the format used by the uuencode program. But that format includes a file name and mode. A clever gateway could examine or even rewrite this line, thus blocking attempts to force the installation of bogus .rhosts files or shells with the setuid bit turned on.

The type of filtering used depends on local needs and customs. A location with many PC users might wish to scan incoming files for viruses.

"Realtime Security Monitoring"
To provide yet another level of security, the gateway architecture should include a watch-dog feature that constantly monitors the network. All unusual activity is logged and traced. This whole process is called active security and differentiates the application level firewall from passive security approaches.

Active security systems have rules that help them define "suspicious" activity. They quietly gather information about where the attempted break-in is originating from, how it got there, what the person appears to be trying to do, etc. This lets systems administrators find a perpetrator, and have the reports and documentation to prosecute them. With other systems, once a hacker has gone, there is rarely an electronic footprint that will aid in their identification and apprehension.

"Spoofing"
It is relatively easy for a system wizard to "spoof" machine addresses - i.e., pretend that your machine is a different one. Because the proxy firewall prevents access to the internal structure of your network, an outsider cannot determine which of your machines is down, and pretend to be one of them, in order to steal your data and information.

"Auto-Checking"
At random times the firewall host ( Sun, IBM, HP ) can give itself a detailed examination, which includes computing an unforgeable metric of the state of its controlling software. If it has been changed in any way from the correct state, it will cease to function. This prevents an insider from "patching" the executable programs to let a cohort get around the firewall.

"Encryption"

Similarly, the firewall software should self encrypt and decrypt itself and its configuration files to make it extremely difficult for someone to reverse-engineer it.

"Unplanned Activity Monitoring"
Having set your rules as to who can do what at specific times etc, it is easy to monitor and log activities that happen outside of pre defined limits, the frequency is monitored for each rule invoked during a pre-set time period.

eg: A university is authorised to log into your system, and does so an average of five times per day for the last several weeks. One morning they log in 25 times. You would be alerted of the unusual activity. This helps prevent someone who is allowed to access your net from stealing information in small chunks, thereby requiring many log-ins. Alternatively, they may be running a password guesser in an attempt to break into a machine where they are not authorised to go.

"Managing Subnets"
Corporate networks must often be divided into subnets of contained activity. The firewall must meet the security needs of inter-departmental LANs offering the same security features as the external gateway, but sitting inside your net and allowing you to control which machines can talk to each other. Using the Authorisation table for all of its access information. Hence, there is only one master file to maintain and secure, not multiple routers and bridges to administer and synchronise.

"Protecting your LANs at the Desktop"
The firewall must prevent unauthorised people from entering your network through a modem. When considering the number of individuals in an organisation who have PCs on their desk with modems, the opportunity for security breaches is astronomical. Modems can send calls out, or receive them, without benefit of screening. PCs were never designed with security in mind, so breaking past their rudimentary safeguards is trivial.

This aspect of security is generally an additional facility which works in conjunction with the primary firewall to match physical addresses on Ethernet boards to those authorised to access the network. If access is requested via a modem, the firewall refuses to return the Ethernet address. Therefore, if you are dialling in from off-site, you will be denied access to anything except your immediate local area network.

The strength of such systems is in their simplicity. There is no way to avoid using the software because the firewall will refuse to allow communication from machines that are supposed to be running additional security software, that do not provide the "secret handshake."

The mechanisms just described are intended to guard against attack from the outside. A clever insider who wanted to retrieve such files certainly would not be stopped by them. But it is not a firewall's job to worry about that class of problem.

The principal disadvantage of application-level gateways is the need for a specialised user program or variant user interface for most services provided. In practice, this means that only the most important services will be supported. This may not be entirely bad -- again, programs that you do not run cannot hurt you-- but it does make it harder to adopt newer technologies. Also, use of such gateways is easiest with applications that make provision for redirection, such as mail and X11. Otherwise, new client programs must be provided.

Circuit-Level Gateways

"The Gateway as a Wire"

The third type of gateway is circuit level. Circuit gateways relay TCP connections. The caller connects to a TCP port on the gateway, which connects to some destination on the other side of the gateway. During the call the gateway's relay program(s) copy the bytes back and forth: the gateway acts as a wire.

Application and circuit gateways are well suited for some UDP applications. The client programs must be modified to create a virtual circuit to some sort of proxy process; the existence of the circuit provides sufficient context to allow secure passage through the filters. The actual destination and source addresses are sent in-line. However, services that require specific local port numbers are still problematic.

"How Circuit Gateways Work"

In some cases a circuit connection is made automatically. For example, we have a host outside our gateway that needs to use an internal printer. We've told that host to connect to the print service on the gateway. Our gateway is configured to relay that particular connection to the printer port on an internal machine. We use an access control mechanism to ensure that only that one external host can connect to the gateway's printer service. We are also confident that this particular connection will not provide a useful entry hole should the external host be compromised.

In other cases, the connection service needs to be told the desired destination. In this case, there is a little protocol between the caller and the gateway. This protocol describes the desired destination and service, and the gateway returns error information if appropriate. In our implementation, called proxy, the destination is a host name. In socks, it is the numeric IP address. If the connection is successful, the protocol ends and the real bytes start flowing. These services require modifications to the calling program or its library.

In general, these relay services do not examine the bytes as they flow through. Services should log the number of bytes and the TCP destination. These logs can be useful. For example, we recently heard of a popular external site that had been penetrated. The Bad Guys had been collecting passwords for over a month. If any of the users used these systems, we could warn them. A quick grep through the logs spotted a single unfortunate (and grateful) user.

The outgoing proxy TCP service provides most of the Internet connectivity our internal users need. As noted, though, protocols such as FTP and X11 require incoming calls. But it is too much of a security risk to permit the gateway to make an uncontrolled call to the inside.

Any general solution is going to involve the gateway machine listening on some port. This approach demonstrates a subtle problem with the notion of a circuit gateway: uncooperative inside users can easily subvert the intent of the gateway designer, by advertising unauthorised services. It is unlikely that, say, port 25 could be used that way, as the gateway machine is probably using it for its own incoming mail processing, but there are other dangers. What about an unprotected telnet service on a non-standard port? An NFS server? A multiplayer game? Logging can catch some of these abuses, but probably not all.

"Managing a Circuit-Level Gateway"

Clearly, some sorts of controls are necessary. These can take various forms, including a time limit on how long such ports will last (and a delay before they may be reused), a requirement for a list of permissible outside callers to the port, and even user authentication on the setup request from the inside client. Obviously, the exact criteria depend on your stance.

The other big problem with circuit relays is the need to provide new client programs. Although the code changes are generally not onerous, they are a nuisance. Issues include availability of application source code for various platforms, version control, distribution, and the headache to users of having to know about two subtly different programs.

Several strategies are available for making the necessary changes. The best known is the socks package [Koblas and Koblas, 1992]. It consists of a set of almost-compatible replacements for various system calls: socket, connect, bind, etc. Converting an application is as simple as replacing the vanilla calls with the socks equivalents. A version of it has been implemented via a replacement shared library, similar to that used in securelib [LeFebvre, 1992] and 3-D FS [Korn and Krell, 1989]. This would permit existing applications to run unchanged. But such libraries are not portable, and it may not be possible to include certain of the security features mentioned earlier.

Frequently Asked Questions

• What is a network firewall?
  
  A firewall is any one of several ways of protecting one network from another untrusted network. The actual mechanism whereby this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one that exists to block traffic, and the other that exists to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasise permitting traffic.
  
• Why would I want a firewall?
  
  The Internet, like any other society, is plagued with the kind of fools who enjoy the electronic equivalent of writing on other people's walls with spraypaint, tearing their plants up, or just sitting in the street blowing their car horns. Some people try to get real work done over the Internet, and others have sensitive or proprietary data they must protect. A firewall's purpose is to keep the idiots out of your network while still letting you get your job done.
  
  Many traditional-style companies and data centres have computing security policies and practices that must be adhered to. In a case where a company's policies dictate how data must be protected, a firewall is very important, since it is the embodiment of the corporate policy. Frequently, the hardest part of hooking to the Internet, if you're a large company, is not justifying the expense or effort, but convincing management that it's safe to do so. A firewall provides not only real security, it often plays an important role as a security blanket for management.
  
  Lastly, a firewall can act as your corporate "ambassador" to the Internet. Many companies use their firewall systems as a place to store public information about corporate products and services, files to download, bug-fixes, and so forth. Several of these systems have become important parts of the Internet service structure (e.g. Uunet.uu.net, gatekeeper.dec.com) and have reflected well on their corporate sponsors.
  
• What can a firewall protect against?
  
  Some firewalls permit only E-mail traffic through them, thereby protecting the network against any attacks other than attacks against the E-mail service. Other firewalls provide less strict protections, and block services that are known to be problems.
  
  Generally, firewalls are configured to protect against unauthenticated interactive logins from the "outside" world. This, more than anything, helps prevent vandals from logging into machines on your network. More elaborate firewalls block traffic from the outside to the inside, but permit users on the inside to communicate freely with the outside. The firewall can protect you against any type of network-borne attack if you unplug it.
  
  Firewalls are also important since they can provide a single "choke point" where security and audit can be imposed. Unlike in a situation where a computer system is being attacked by someone dialling in with a modem, the firewall can act as an effective "phone tap" and tracing tool.
  
• What can't a firewall protect against?
  
  Firewalls can't protect against attacks that don't go through the firewall. Many corporations that connect to the Internet are very concerned about proprietary data leaking out of the company through that route. Unfortunately for those concerned, a magnetic tape can just as effectively be used to export data. Firewall policies must be realistic, and reflect the level of security in the entire network. For example, a site with top secret or classified data doesn't need a firewall at all: They shouldn't be hooking up to the Internet in the first place, or the systems with the really secret data should be isolated from the rest of the corporate network.
  
  Firewalls can't protect very well against things like viruses. There are too many ways of encoding binary files for transfer over networks, and too many different architectures and viruses to try to search for them all. In other words, a firewall cannot replace security consciousness on the part of your users. In general, a firewall cannot protect against a data-driven attack -- attacks in which something is mailed or copied to an internal host where it is then executed. This form of attack has occurred in the past against various versions of Sendmail.
  
• What are good sources of print information on firewalls?
  
  There are several books that touch on firewalls. The best known are:
  
  Cheswick and Bellovin, "Firewalls and Internet Security:
  Repelling the Wily Hacker" Addison-Wesley, 1994
  
  Garfinkel and Spafford, "Practical UNIX Security" O'Reilly
  and Associates (discuses primarily host security)
  
• Where can I get more information on firewalls on the Internet?
  
  The internet firewalls mailing list is a forum for firewall administrators and implementors. To subscribe to Firewalls, send "subscribe firewalls" in the body of a message (not on the "Subject:" line) to "Majordomo@GreatCircle.COM".There is also a UK based mailing list called (surprisingly) firewalls-uk, you can subscribe to this my e-mailing to majordomo@gbnet.net and including "subscribe firewalls-uk" in the body of the message.
  
  Archives of past Firewalls postings are available for anonymous FTP from ftp.greatcircle.com in pub/firewalls/archive
  
  ftp.tis.com - Internet firewall toolkit and papers.
  Directory: pub/firewalls
  
  research.att.com - Papers on firewalls and break-ins.
  Directory: dist/internet_security
  
  net.Tamu.edu - Texas AMU security tools.
  Directory: pub/security/TAMU
  
  http://www.zeuros.co.uk/firewall
  The Rotherwick Firewall Resources - hundreds of links to information all over the internet
  
• What are some of the basic design decisions?
  
  There are a number of basic design issues that should be addressed by the lucky person who has been tasked with the responsibility of designing, specifying, and implementing or overseeing the installation of a firewall.
  
  The first and most important reflects the policy of how your company or organisation wants to operate the system. Is the firewall in place to explicitly deny all services except those critical to the mission of connecting to the net, or is the firewall in place to provide a metered and audited method of "queuing" access in a non-threatening manner. There are degrees of paranoia between these positions; the final stance of your firewall may be more the result of a political than an engineering decision.
  
  The second design issue is what level of monitoring, redundancy, and control do you want? Having established the acceptable risk level (e.g. how paranoid you are) by resolving the first issue, you can form a checklist of what should be monitored, permitted, and denied. In other words, you start by figuring out your overall objectives, and then combine a needs analysis with a risk assessment, and sort the almost always conflicting requirements out into a laundry list that specifies what you plan to implement.
  
  The third issue is financial. We can't address this one here in anything but vague terms, but it's important to try to quantify any proposed solutions in terms of how much it will cost either to buy or to implement. For example, a complete firewall product may cost between £ 60,000 at the high end, and free at the low end. The free option, of doing some fancy configuring on a Cisco or similar router will cost nothing but staff time and cups of coffee. Implementing a high end firewall from scratch might cost several man- months, which may equate to £ 20,000 worth of staff salary and benefits. The systems management overhead is also a consideration. Building a home-brew is fine, but it's important to build it so that it doesn't require constant and expensive fiddling with. It's important, in other words, to evaluate firewalls not only in terms of what they cost now, but continuing costs such as support.
  
  On the technical side, there are a couple of decisions to make, based on the fact that for all practical purposes what we are talking about is a static traffic routing service placed between the network service provider's router and your internal network. The traffic routing service may be implemented at an IP level via something like screening rules in a router, or at an application level via proxy gateways and services. The decision to make here is whether to place an exposed stripped-down machine on the outside network to run proxy services for telnet, ftp, news, etc., or whether to set up a screening router as a filter, permitting communication with one or more internal machines. There are plusses and minuses to both approaches, with the proxy machine providing a greater level of audit and potentially security in return for increased cost in configuration and a decrease in the level of service that may be provided (since a proxy needs to be developed for each desired service). The old trade-off between ease-of-use and security comes back to haunt us with a vengeance.
  
• What are proxy servers and how do they work?
  
  A proxy server (sometimes referred to as an application gateway or forwarder) is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls, to prevent traffic from passing directly between networks. Many proxies contain extra logging or support for user authentication. Since proxies must "understand" the application protocol being used, they can also implement protocol specific security (e.g., an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP).
  
  Proxy servers are application specific. In order to support a new protocol via a proxy, a proxy must be developed for it. SOCKS is a generic proxy system that can be compiled into a client-side application to make it work through a firewall. Its advantage is that it's easy to use, but it doesn't support the addition of authentication hooks or protocol specific logging.
  
• What are some cheap packet screening tools?
  
  The Texas AMU security tools include software for implementing screening routers (FTP net.tamu.edu, pub/security/TAMU). Karlbridge is a PC-based screening router kit (FTP nisca.acs.ohio-state.edu, pub/kbridge). A version of the Digital Equipment Corporation "screend" kernel screening software is ported or is in the process of being ported to BSD/386. Many other commercial routers support screening of various forms.
  
• What are some reasonable filtering rules for my Cisco?
  
  The following example shows one possible configuration for using the Cisco as a filtering router. It is a sample that shows the implementation of a specific policy. Your policy will undoubtedly vary.
  
  In this example, a company has Class B network address of 128.88.0.0 and is using 8 bits for subnets. The Internet connection is on the "red" subnet 128.88.254.0. All other subnets are considered trusted or "blue" subnets.
  
  Keeping the following points in mind will help in understanding the configuration fragments:
  
  1. Cisco routers applying filtering to output packets only.
  2. Rules are tested in order and stop when the first match is found.
  3. There is an implicit deny rule at the end of an access list. If no rule permitting traffic is encountered, the traffic is blocked.
  
  The example below concentrates on the filtering parts of a configuration. Line numbers and formatting have been added for readability.
  
  The policy to be implemented is:
  
  1. Anything not explicitly permitted is denied.
  2. Traffic between the bastion host and blue net hosts is allowed.
  3. Permit services originating from the blue net.
  4. Allow a range of ports for FTP data connections back to the blue net.
  
  1 no ip source-route
  2 !
  3 interface Ethernet 0
  4 ip address 128.88.1.1 255.255.255.0
  5 ip access-group 10
  6 !
  7 interface Ethernet 1
  8 ip address 128.88.254.3 255.255.255.0
  9 ip access-group 11
  10 !
  11 access-list 10 permit ip 128.88.254.2 0.0.0.0 128.88.0.0 0.0.255.255
  12 access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 lt 1025
  13 access-list 10 deny tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 4999
  14 access-list 10 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255
  15 !
  16 access-list 11 permit ip 128.88.0.0 0.0.255.255 128.88.254.2 0.0.0.0
  17 access-list 11 deny tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255 eq 25
  18 access-list 11 permit tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255
  
  Explanation of Lines:
  
  Line 1 Although this is not a filtering rule, it is good to include here. This prevents a form of address spoofing that can be used to attack router-based firewalls. Some routers with older firmware do not implement this option correctly.
  
  Line 5 Ethernet 0 is on the red net. Extended access list 10 will be applied to output on this interface. You can also think of output from the red net as input on the blue net.
  
  Line 9 Ethernet 1 is on the blue net. Extended access list 11 will be applied to output on this interface.
  
  Line 11 Allow all traffic from the gateway machine to the blue net.
  
  Lines 12-14 Allow connections originating from the red net that come in between ports 1024 and 5000. This is to allow ftp data connections back into the blue net. 5000 was chosen as the upper limit as it is where OpenView starts.
  
  Note: We are assuming this is acceptable for the given policy. There is no way to tell a Cisco to filter on source port. Since the rules are tested until the first match we must use this rather obtuse syntax.
  
  Line 16 Allow all blue net packets to the gateway machine.
  
  Line 17 Deny SMTP (tcp port 25) mail to the red net.
  
  Line 18 Allow all other TCP traffic to the red net.
  
  Cisco.Com has an archive of examples for building firewalls using Cisco routers, available for FTP from: ftp.cisco.com in /pub/acl-examples.tar.Z
  
• How do I make DNS work with a firewall?
  
  Some organisations want to hide DNS names from the outside. Many experts disagree as to whether or not hiding DNS names is worthwhile, but if corporate policy mandates hiding domain names, this is one approach that is known to work.
  
  This approach is one of many, and is useful for organisations that wish to hide their host names from the Internet. The success of this approach lies on the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and there are often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine.
  
  First, you set up a DNS server on the bastion host that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the "public" server.
  
  Then, you set up a DNS server on an internal machine. This server also claims to be authoritative for your domains; but unlike the public server, this one is telling the truth. This is your "normal" nameserver, into which you put all your "normal" DNS stuff. You also set this server up to forward queries that it cannot resolve to the public server (using a "forwarders" line in /etc/named.boot on a UNIX machine, for example).
  
  Finally, you set up all your DNS clients (the /etc/resolv.conf file on a UNIX box, for instance), including the ones on the machine with the public server, to use the internal server. This is the key. An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the "restricted" answer from the public server.
  
  This approach assumes that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but otherwise restricts DNS between other hosts.
  
  Another trick that's useful in this scheme is to employ wildcard PTR records in your IN-ADDR.ARPA domains. These cause an address-to-name lookup for any of your non- public hosts to return something like "unknown.YOUR.DOMAIN" rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This may fail when talking to sites that do a DNS cross-check in which the host name is matched against its address and vice versa.
  
  Note that hiding names in the DNS does not address the problem of host names "leaking" out in mail headers, news articles, etc.
  
• How do I make FTP work through my firewall?
  
  Generally, making FTP work through the firewall is done either using a proxy server or by permitting incoming connections to the network at a restricted port range, and otherwise restricting incoming connections using something like "established" screening rules. The FTP client is then modified to bind the data port to a port within that range. This entails being able to modify the FTP client application on internal hosts.
  
  A different approach is to use the FTP "PASV" option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation.
  
  Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library.
  
• How do I make Telnet work through my firewall?
  
  Telnet is generally supported either by using an application proxy, or by simply configuring a router to permit outgoing connections using something like the "established" screening rules.
  
• How do I make Finger and whois work through my firewall?
  
  Permit connections to the finger port from only trusted machines, which can issue finger requests in the form of: finger user@host.domain@firewall.
  
  This approach only works with the standard UNIX version of finger. Some finger servers do not permit user@host@host fingering.
  
  Many sites block inbound finger requests for a variety of reasons, foremost being past security bugs in the finger server (the Morris Internet worm made these bugs famous) and the risk of proprietary or sensitive information being revealed in user's finger information.
  
• How do I make gopher, archie, and other services work through my firewall?
  
  This is still an area of active research in the firewall community. Many firewall administrators support these services only through the character-cell interface provided by telnet. Unfortunately, many of the sexier network services make connections to multiple remote systems, without transmitting any online information that a proxy could take advantage of, and often the newer information retrieval systems transmit data to local hosts and disks with only minimal security. There are risks that (for example) WAIS clients may request uuencoded files, which decode and modify security related files in the user's home directory. At present, there is a lot of head-scratching going on between the firewall administrators who are responsible for guarding the network perimeters, and the users, who want to take advantage of these very sexy and admittedly useful tools.
  
• What are the issues about X11 X-Windows through a firewall?
  
  X Windows is a very useful system, but unfortunately has some major security flaws. While attempts have been made to overcome them (For example MIT "Magic Cookie") it is still entirely too easy for an attacker to interfere with a user's X display. Most firewalls block all X traffic. Some permit X traffic through application proxies such as the DEC CRL X proxy (FTP crl.dec.com).