Chapter 12: Conclusions and Outlook | Internet & Intranet Security

Team-Fly

OVERVIEW

If properly designed, implemented, deployed, and administered, a firewall can provide effective access control services for corporate intranets. Consequently, more and more network administrators are setting up firewalls as their first line of defense against outside attacks. After having introduced and discussed the fundamentals and the underlying principles of the firewall technology, its components (i.e., packet filters, circuit-level gateways, and application-level gateways), and some possible configurations, we use this chapter to conclude Part II, to give a brief overview about the current state-of-the-art and future directions in firewall research and development, and to elaborate on the role of firewalls in future IT landscapes.

First of all, it is important to note that firewalls are a fact of life on the Internet and that it is not likely that they will disappear in the future. In fact, the firewall technology is the most widely deployed security technology on the Internet. Many companies and organizations regularly perform market surveys and publish corresponding results. In a world of multiple vendors, interoperability is becoming a critical requirement. Against this background, CheckPoint Software Technologies, Inc., founded the open platform for security (OPSEC^[1]) in 1997. Initiatives like OPSEC are very important for the evolution of the firewall technology in the future.

In spite of their commercial success, however, the firewall technology has remained an emotional topic within the Internet community. We briefly summarize the major arguments:

Firewall advocates consider firewalls as important security measures and additional safeguards because they aggregate security functions in a single point, simplifying installation, configuration, and administration. Many companies and organizations use firewalls as corporate ambassadors to the Internet and use them to store public information about products and services, files to download, software patches, and so forth. From a U.S. manufacturer and vendor's point of view, the firewall technology is interesting mainly because it does not use cryptographic techniques and is therefore exportable. In addition to that, the technology's use is restricted neither to the TCP/IP protocols nor to the Internet, and very similar techniques can be used in any packet-switched data network, such as X.25 data networks.
Firewall detractors are usually concerned about the difficulty of properly setting up, administering, and using firewalls, as well as their interference with the usability and vitality of the Internet as a whole. They claim that firewalls foster a false sense of security, leading to lax security within the firewall perimeter.

At the least, firewall advocates and detractors both agree that firewalls are a powerful tool for network security, but that they are not by any means a panacea or a magic bullet for all network and Internet-related security problems. Consequently, they should not be regarded as a substitute for careful security management within a corporate environment. Also, a firewall is useful only if it is configured to handle all data traffic to and from the Internet. This is not always the case, as many sites permit dial-in access to modems that are located at various points throughout the intranet. This is a potential backdoor and could negate all the protection provided by the firewall. A much better method for handling modems is to concentrate them into a modem pool. In essence, a modem pool consists of several modems connected to a terminal server. A dial-in user connects to the terminal server and then connects from there to other internal systems. Some terminal servers provide security features that can restrict connections to specific systems, or require users to strongly authenticate themselves. Obviously, RADIUS or TACACS+ can be used to secure communications between the terminal server and a centralized security server. Sometimes, authorized users also wish to have a dial-out capability. These users, however, need to recognize the vulnerabilities they may be creating if they are careless with the use of modems. A dial-out capability may easily become a dial-in capability if proper precautions are not taken. In general, dial-in and dial-out capabilities should be considered in the design of a firewall and incorporated into it. Forcing outside users to go through the strong authentication of the firewall should be reflected in the firewall policy.

In addition to unauthorized modems, there are at least two types of security problems that firewalls cannot address:

Firewalls cannot protect against insider attacks. This is because the insider—as the name suggests—operates from the inside and must not pass the firewall at all. Consequently, the firewall is not aware of anything that happens inside the perimeter it protects. Protection against insider attacks can only be achieved by designing, implementing, and deploying appropriate authentication, authorization, and access control mechanisms inside the firewall. Furthermore, intranet firewalls can be used to limit the scope of an inside attack.
Similarly, firewalls generally cannot protect against data-driven attacks, such as those employed by users downloading virus-infected software from archives or transferring corresponding program files in MIME-type attachments of e-mail messages. Because these program files may be encoded, compressed, and encrypted in any number of ways, a firewall is not always able to scan them to search for known virus signatures with any degree of accuracy. The same is true for macro viruses that may be included in innocent-looking data files (e.g., Word documents or PowerPoint presentations). It is possible and very likely that this problem will become more severe in the future, simply because more data traffic is encrypted on an end-to-end basis. Using end-to-end encryption, however, it is generally no longer possible for an intermediate system (e.g., a firewall or proxy server) to decrypt the data traffic and to make intelligent decisions about the nonexistence of malicious code. Protection against data-driven attacks can only be achieved by having users be restrictive in terms of software they accept, install, and execute, as well as having them use recent releases of antivirus software products.

With regard to computer viruses and data-driven attacks, it is important to note that the use and wide proliferation of executable content and mobile code, as provided, for example, by Java applets and ActiveX controls, has dramatically intensified the security problems [1–3].^[2] If, for example, a user downloads a Java applet or ActiveX control to a client machine that is configured to accept it by default, the Java applet or ActiveX control is automatically executed without asking the user for further permission. As such, the Java applet or ActiveX control may potentially compromise the security of the system.^[3] The situation is dangerous, simply because the user imports a program that is executed locally without knowing exactly what the program is all about or what functions it actually implements. Think of this situation as something conceptually similar to a reverse remote procedure call (RPC).

As further addressed in Chapters 9 and 11 of [3], there are only a few technologies that can be used to address the security problems related to executable content and mobile code. For example, the Java security architecture employs the concept of a sandbox that can be configured to heavily restrict the runtime environment and the permissions of a Java applet. Similarly, the authenticity of an ActiveX control can be verified using digital signatures. With its lack of a concept similar to the Java sandbox, ActiveX is going to pose even more severe security problems than Java. For example, some time ago the German Chaos Computer Club demonstrated the danger of using ActiveX when they wrote and put on the Web an ActiveX control that was actually a Trojan horse. In the background, the ActiveX control prepared a money transfer order for the Microsoft Quicken software and put it in the corresponding payment queue. So, when the user had Quicken transfer its money orders the next time, the faked money transfer order generated by the Trojan horse would also be transferred. If the amount of transferred money is not too large, chances are that the user does not realize the manipulation.

It is also worthwhile mentioning that firewalls offer strong protection, but that tunnels can always be used to circumvent and bypass them. In essence, tunneling refers to the technique of encapsulating a data unit from one protocol in another, and using the facilities of the second protocol to traverse parts of the network. At the destination point, the encapsulation is stripped off, and the original data unit is reinjected into the local network. There are many uses for tunneling, and in some cases, a protocol may also be encapsulated within itself. For example, IP tunneling is used in both the evolving Multicast Backbone (MBone) and the IPv6 Backbone (6Bone).

With regard to the MBone, IP multicast packets are tunneled using IP unicast packets. More precisely, IP packets with multicast destination addresses are encapsulated in IP packets with unicast destination addresses and tunneled through the existing Internet accordingly. Only destinations that are able to handle multicast traffic decapsulate the packets and eventually reinject them into their local networks.
Similarly, IPv6 migration suggests the use of IP tunneling for transmitting IPv6 packets in the existing IPv4-based Internet. In this case, IPv6 packets are tunneled using IPv4 packets. More precisely, IPv6 packets are encapsulated in IPv4 packets and tunneled through the existing Internet. Only destinations that are able to handle IPv6 packets decapsulate the IPv6 packets and eventually reinject them into their local networks. Later, when IPv6 has become more widely deployed, it is possible and very likely that IPv4 traffic will be tunneled through an IPv6-based Internet.

Unfortunately, IP tunneling can also be misused to circumvent and bypass firewalls. We assume that a firewall permits at least one type of traffic to pass through bidirectionally. In this case, an insider and an outsider who dislike the firewall and wish to bypass it can build a tunnel between an internal system and an external system. What they basically do is encapsulate arbitrary IP packets in legitimate IP packets or some higher layer messages that are authorized to pass through the firewall. As such, the legitimate IP packets or some higher layer messages are transmitted to the destination system, where they are decapsulated to retrieve the original IP packets. Consequently, the two accomplices have established a tunnel that allows the free flow of IP packets through the firewall. From a security point of view, an unauthorized tunnel is far worse than a simple outbound connection, since inbound connections are usually permitted through the tunnel as well. Unauthorized tunnels are, in the final analysis, a management problem, not a technical one. If insiders do not generally accept the need for information security, firewall systems and other access control mechanisms will always be futile. The establishment of unauthorized tunnels is actually an insider problem, as it requires the cooperation of a legitimate inside user.

One should also notice that tunnels through firewalls also have their good sides. When properly configured and employed, they can be used to bypass the limitations of a particular firewall configuration. For example, a tunnel could be used to interconnect two physically separated sites. Firewalls at each location would provide protection from the outside, while a tunnel provides connectivity. If the tunnel is entirely encrypted, then the risks of such a configuration are low and the benefits are high.

To some people, the notion of a firewall is questionable. They argue that in most situations, the network is not the resource at risk; rather, the endpoints of the network are threatened. Given that the target of the attackers is the hosts on the network, should they not be suitably configured and armored to resist all possible attacks? The answer is that they should be, but probably cannot be. There will be bugs, either in the network programs or in the administration of the systems. Consequently, firewalls have been constructed and are used for pragmatic reasons by organizations interested in a higher level of security than may be possible without them. According to Steven Bellovin, firewalls are not a solution to network security problems, but rather a network response to a host security problem [4]. More precisely, they are a response to the dismal state of software engineering. Taken as a whole, the industry has missed the opportunity to produce software that is correct, secure, and easy to administer.

Firewall systems provide basic access control services for corporate intranets. But firewalls are not going to solve all security problems. A pair of historical analogies can help us better understand the role of firewall technology for the current and future Internet [5]:

Our Stone Age predecessors lived in caves, each inhabited by a family whose members knew one another quite well. They could use this knowledge to identify and authenticate one another. Someone wanting to enter the cave would have to be introduced by a family member trusted by the others. Human history has shown that this security model is too simple to work on a large scale. As families grew in size and started to interact with one another, it was no longer possible for all family members to know all other members of the community, or even to reliably remember all persons who had ever been introduced to them.
In the Middle Ages, our predecessors lived in castles and villages surrounded by town walls. The inhabitants were acquainted with one another, but this web of knowledge was not trusted. Instead, identification, authentication, authorization, and access control were centralized at a front gate. Anyone who wanted to enter the castle or village had to pass the front gate and was thoroughly checked there. Those who managed to pass the gate were implicitly trusted by all inhabitants. But human history has shown that this security model does not work either. For one thing, town walls do not protect against malicious insider attacks; for another, town walls and front gates do not scale easily. Many remnants of medieval town walls bear witness to this lack of scalability.

Using these analogies, the Internet has just entered the Middle Ages. The simple security model of the Stone Age still works for single hosts and local area networks (LANs). But it no longer works for wide area networks (WANs) in general and the Internet in particular. As a first (and let's hope intermediate) step, firewalls have been erected at the intranet gateways. Because they are capable of selectively dropping IP datagrams, firewalls restrict the connectivity of the Internet as a whole. The Internet's firewalls are thus comparable to the town walls and front gates of the Middle Ages. Screening routers correspond to general-purpose gates, whereas application gateways correspond to more specialized gates.

We do not see town walls anymore. Instead, countries issue passports to their citizens to use worldwide for identification and authentication. The Internet may need a similar means of security. TTPs and CAs could issue locally or globally accepted certificates or tickets for Internet principals, and these certificates or tickets could then be used to provide security services such as authentication, data confidentiality and integrity, access control, and non-repudiation services. In the remainder of this book, we are going to elaborate on these approaches (i.e., how to use cryptographic techniques to provide security services for an intranet or the Internet).

^[1]http://www.checkpoint.com/opsec/

^[2]In some literature, Java has also been attributed to be an "automatic malicious software distribution system" [4].

^[3]Access the WWW home page of DigiCrime, Inc., at URL http://www.digicrime.com to learn how executable content could, in fact, damage your system.

Team-Fly