Internet & Intranet Security

7.1 INTRODUCTION

While Internet connectivity offers enormous benefits in terms of increased availability and access to information, Internet connectivity is not always a good thing, especially for sites with low levels of security. As we discussed in Part I, the Internet suffers from glaring security problems that, if ignored, could have disastrous impacts for unprepared sites. Inherent problems with the TCP/IP protocols and services, the complexity of host and site configuration, vulnerabilities introduced in the software development process, and a wide variety of other factors all contribute to making unprepared sites open for intruder activities and other security-related threats. For example, host systems and access controls are usually complex to configure and test for correctness. As a result, they are sometimes accidentally misconfigured, and this may result in intruders gaining unauthorized and illegitimate access to system and information resources. It is a rather astonishing fact that some vendors still ship their systems with access controls configured for maximum (i.e., least secure access), which can result in unauthorized and illegitimate access if left as is.^[2] Furthermore, a number of security incidents have occurred that are due in part to vulnerabilities discovered by intruders. Because many UNIX systems have their network code derived from BSD UNIX that is publicly available in source code, intruders have been able to study the code for bugs (e.g., buffer overflows) and error conditions that may be exploited to gain unauthorized and illegitimate access. The bugs exist in part because of the complexity of the software and the inability to test it under all circumstances and in all the environments in which it must operate. Sometimes the bugs can be discovered and corrected; other times, however, little can be done except to rewrite the entire software, which is usually the last-resort option. Because of its open source distribution, the same argument also holds for the Linux operation system.

Host security is generally hard to achieve and does not scale well in the sense that as the number of hosts increases, the ability to ensure that security is at a high level for each host usually decreases. Given the fact that secure management of just one single system can be a demanding task, managing many such systems could easily result in mistakes and omissions. A contributing factor is that the role of system administration is often undervalued and performed in a difficult situation. As a result of this, some systems will be less secure than others, and these systems will probably be the ones that ultimately break the security of either a site or an entire corporate intranet. This book does not address host and site security. There is an informational RFC specifying a site security handbook published in 1997 [1]. You may refer to this reference for a comprehensive overview about issues related to host and site security.

In days of old, brick walls were built between buildings in apartment complexes so that if a fire broke out, it would not spread from one building to another. Quite naturally, these walls were and still are called firewalls.

Today, when a private network (i.e., intranet) is connected to a public network (i.e., Internet), its users are usually enabled to communicate with the outside world. At the same time, however, the outside world can also interact with the private network and its computer systems. In this situation, an intermediate system can be plugged between the private network and the public network to establish a controlled link, and to erect a security wall or perimeter. The aim of the intermediate system is to protect the private network from network-based attacks that originate from the outside world, and to provide a single choke point where security and audit can be imposed. Note that all traffic in and out of the private network can be enforced to pass through this single, narrow choke point. Also note that this point provides a good place to collect information about system and network use and misuse. As a single point of access, the intermediate system can record what occurs between the private network and the outside world. Quite intuitively, these intermediate systems are called firewall systems, or firewalls. In other literature, Internet firewalls are also referred to as secure Internet gateways or security gateways. We are not going to use these alternative terms in this book.

In essence, a firewall system represents a blockade between a privately owned and protected network, which is assumed to be secure and trusted, and another network, typically a public network or the Internet, which is assumed to be nonsecure and untrusted. The purpose of the firewall is to prevent unwanted and unauthorized communications into or out of the protected network.

In addition to the physical firewall analogy mentioned earlier, there are other analogies that may help to better understand and motivate for the use of firewalls:

• Passports are generally checked at the border of a country.

• Apartments are usually locked at the entrance and not necessarily at each door.

• Similarly, offices do not usually have a door to the outside world.

• And yet, a bank still has a vault to store money and valuable goods.

Other analogies include the toll booth on a bridge, the ticket booth at a movie theater, and the checkout line at a supermarket.

These analogies and the first three analogies itemized above illustrate the fact that it sometimes makes a lot of sense to aggregate security functions at a single point. Nevertheless, the last analogy itemized also illustrates that additional security precautions may be required under some circumstances. Note that a firewall is conceptually similar to locking the doors of a house or employing a doorperson. The objective is to ensure that only properly authenticated and authorized people are able to physically enter the house. Unfortunately, this protection is not foolproof and can be defeated with enough effort. The basic idea is to make the effort too big for a burglar, so that he or she will eventually go away and find another, typically more vulnerable, house. However, just in case the burglar does not go away and somehow manages to enter the house, we usually lock up our valuable goods in a safe. According to this analogy, the use of a firewall may not always be sufficient, especially in high-security environments in which we live these days. This point is emphasized by the last analogy itemized and will (hopefully) become more clear in the rest of Part II.

There are several possibilities to define the term firewall. For example, according to [2], a firewall refers to "an internetwork gateway that restricts data communication traffic to and from one of the connected networks (the one said to be 'inside' the firewall) and thus protects that network's system resources against threats from the other network (the one that is said to be 'outside' the firewall)." This definition is fairly broad and not too accurate.

In their pioneering book [3] and article [4] on firewalls and Internet security, William Cheswick and Steven Bellovin defined a firewall (system) as a collection of components placed between two networks that collectively have the following three properties:

• All traffic from inside to outside, and vice versa, must pass through the firewall.

• Only authorized traffic, as defined by the local security policy, will be allowed to pass.

• The firewall itself is immune to penetration.

Note that these properties are design goals. A failure in one aspect does not necessarily mean that the collection is not a firewall, simply that it is not a good one. Consequently, there are different grades of security that a firewall can achieve. In either case, there must be a security policy for the firewall to enforce.

This definition is more accurate than the one given in [2]. If, however, one wanted to exclude the fact that a simple packet filter can be called a firewall, one would have to come up with an even more complex definition for the term firewall. In this case, a system can be called a firewall if it is able:

• To enforce strong authentication for users who wish to establish inbound or outbound^[3] connections;

• To associate data streams that are allowed to pass through the firewall with previously authenticated and authorized users.

Again, it is a policy decision if a data stream is allowed to pass through a firewall. Thus, this definition also leads to the necessity of an explicitly specified firewall policy, similar to the definition of Cheswick and Bellovin.

Later in this chapter, we will distinguish between packet filters and application gateways. It is interesting to note at this point that the last definition requires the use of application gateways (i.e., circuit-level gateways or application-level gateways). Because application gateways operate at the higher layers of the OSI-RM, they typically have access to more information than packet-filtering devices (e.g., screening routers) and can therefore be programmed to operate more intelligently and to be more secure as well. Some vendors, perhaps for marketing reasons, blur the distinction between a packet filter and a firewall to the extent that they call any packet filtering device a firewall. For the sake of clarity, however, this book makes a clear distinction between packet filters (operating at the network and transport layers of the OSI-RM) and firewalls (operating at the higher layers of the OSI-RM). This distinction is emphasized by the last definition given above. Note that the definition can be applied not only to TCP/IP-based firewalls, but also to modem pools with serial line interfaces that provide support for strong user authentication.

From a more pragmatic point of view, a firewall refers to a collection of hardware, software, and policy that is placed between a private network, typically a corporate intranet, and an external network, typically the Internet. As such, the firewall implements parts of a network security policy by enforcing that all data traffic is directed or routed to the firewall, where it can be examined and evaluated accordingly. A firewall seeks to prevent unwanted and unauthorized communications into or out of a corporate intranet, and to allow an organization to enforce a policy on traffic flowing between its intranet and the Internet. Typically, a firewall also requires its users to strongly authenticate themselves before any further action is deployed. The last definition given above has made this requirement mandatory for a firewall. In this case, strong authentication mechanisms are used to replace password-based or address-based authentication schemes.

The general reasoning behind firewall usage is that without a firewall, a site is more exposed to inherently insecure host operating systems, TCP/IP protocols and services, and probes and attacks from the Internet. In a firewall-less environment, network security is totally a function of each host, and all hosts must, in a sense, cooperate to achieve a uniformly high level of security. The larger the network, the less manageable it usually is to maintain all hosts at the same level of security. As mistakes and lapses in security become more common, break-ins can occur not only as a result of complex attacks, but also because of simple errors in configuration files and inadequately chosen passwords. Assuming that software is buggy, one can conclude that most host systems have security holes that can eventually be exploited by intruders. Firewalls are designed to run less software, and hence may potentially have fewer bugs, vulnerabilities, and security holes than conventional hosts. In addition, firewalls generally have advanced logging and monitoring facilities and can be professionally administered. With firewall usage, only a few hosts are exposed to attacks from the Internet, which considerably simplifies the task of securing the intranet environment.

Later in this book, we will discuss the advantages and disadvantages of the firewall technology as a whole. Probably one of the main disadvantages is due to the fact that a firewall cannot protect sites and corporate intranets against insider attacks. For that matter, internal firewalls may be used to control access between different administration and security domains, or to protect sensitive parts of a corporate intranet. Internal firewalls are sometimes also called intranet firewalls. From a purely technical point of view, there is nothing that distinguishes an intranet firewall from an Internet firewall except for the policy it enforces. Consequently, we are not going to differentiate between intranet and Internet firewalls in this book.

^[2]For example, the attack against the database of the World Economic Forum (WEF) that occured in early 2001 exploited an initial password that was neither modified nor removed.

^[3]In this book, the terms inbound and outbound are used to refer to connections or IP packets from the point of view of the protected network, which is typically the intranet. Consequently, an outbound connection is a connection initiated from a client on an internal machine to a server on an external machine. Note that while the connection as a whole is outbound, it includes both outbound IP packets (those from the internal client to the external server) and inbound IP packets (those from the external server to the internal client). Similarly, an inbound connection is a connection initiated from a client on an external machine to a server on an internal machine. Following this terminology, the inbound interface for an IP packet refers to the physical network interface on a screening router on which the packet actually appeared, while the outbound interface refers to the physical network interface on which the packet will go out if it is not denied by the application of a specific packet-filtering rule.