On Firewalls and Tunneling J. Frommer, A. Wiesmaier, and R. Araújo Department of Cryptography and Computeralgebra Technische Universität Darmstadt Hochschulstr. 10; D-64283 Darmstadt, Germany Abstract. This paper gives a comprehensive overview of the state- of-the-art in rewall and tunneling technologies. We describe the major rewall components and several approaches for legitimate and illegitimate tunneling techniques and investigate their interrelations. Finally we shortly introduce a highly adaptable tunneling application, having the potential to circumvent virtually every rewall system. Keywords. Firewalls, Tunneling, IT-Security, Attacks 1 Introduction Most organizations, and in the last years also an increasing number of individ- uals, employ local area networks to connect their workstations and IT-Systems. These networks usually contain digital assets and have to be protected from unauthorized access. But also they are often connected to the internet or other mistrusted networks which poses a threat to the assets. This dilemma can be solved by deploying rewall systems (in the following also simply referred to as rewalls). In order to provide rewall functionality also for single computers and not only for computer networks the technology of personal rewalls has emerged. Unlike their name suggests, rewalls are not impassable barriers. Actually, they restrict the communication trac between two or more networks. The re- strictions are expressed in the rewall security policy (in the following also simply referred to as security policy). They limit the trac to communication which is considered trustworthy. For instance, mistrusted trac can be trac of a ser- vice that is considered as insecure or trac from a host whose IP address is not trusted. But although required leaving some channels open for communication provides possibilities to misuse them for trac which is not allowed. Such a bypass of the rewall can be archived by applying tunneling techniques and can be used as many technologies in a good and a bad way, as Cheswick and Bellowin mention in [1, p. 79]. A "good" tunnel is a tunnel that is permitted by the network administration for certain instances. For example a virtual private network (VPN) tunnel (see Section 3.1) that connects several local area networks to form a geographically distributed, organization wide network a so called wide area network (WAN) is a good tunnel. Similarly, the access of mobile users to an organization's network via mobility support in IP networks (mobile IP), as described by Perkins [2], is a good tunneling approach. In contrast, a "bad" tunnel constitutes a violation of the security policy. It is neither regular (allowed) communication trac nor legitimate tunneling trac. It is prohibited trac which is camouaged as regular trac to get inside the rewall protected network. In the following we refer to good tunnels as legitimate tunnels, as they are planned in consistency with the rewalls security policy. Likewise, we refer to bad tunnels as illegitimate tunnels. The list of tunneling software tools is too extensive to be covered fully in this work. Anyway, the majority of the available (freeware as well as commercial) tunneling software realizes tunneling using the HTTP protocol (confer to RFC 2616 [3]), as for instance GNU httptunnel [4], HTTP-Tunnel [5] or ProxyTunnel [6]. Other frequently used protocols are TLS/SSL or SSH (confer to RFC 2246 [7] and RFC 4251 [8]) with which tunnel applications like STunnel [9] or SSL- Proxy [10] and Tunnelier [11] or Internet Secure Tunneling [12], respectively, are working. These tools all depend on a specic (high level) protocol, this is why they do not work when the protocol is not allowed to pass through the rewall (for further examples and explanation confer Section 3.1). There are various surveys on rewalls. Almost every textbook on IT, internet or network security contains a chapter or section on rewalls (e.g. Eckert [13] or Stallings [14]). But there are also whole textbooks on rewalls (e.g. Cheswick and Bellowin [1] or Zwicky et al. [15]). Regarding theoretical work on rewalls there is also little work available. Schuba and Spaord [16] as an example propose a formal model for rewalls. There is little literature on tunneling in general, although there are plenty of applications available that enable the establishment of tunnels. The concept of tunneling seems to be regarded as too straightforward. Anyhow there are short sections on tunneling in some works about networks or internet security, for example from Cheswick and Bellowin [1] or Tanenbaum [17]. Nevertheless, the concept of tunneling is used broadly in the eld of network communication. For example as already mentioned above VPN and mobile IP technologies make extensive use of tunneling techniques. This paper provides a combined view on rewalls and tunneling by interre- lating both technologies. We give an overview of the state-of-the-art in rewall technologies (Section 2) and demonstrate several approaches for establishing tun- nels between rewall protected networks or hosts (Section 3). These approaches include legitimate and illegitimate tunneling techniques. Furthermore we shortly introduce in Section 4 a highly adaptable tunneling application. Finally Section 5 sums up our work. 2 Firewall Technologies In RFC 2828 Shirey [18, p. 74] denes a rewall as follows: An internetwork gateway that restricts data communication trac to and from one of the connected networks (the one said to be "inside" the rewall) and thus protects that network's system resources against threats from the other network (the one that is said to be "outside" the rewall). To elaborate this abstract denition of a rewall it is common, to distin- guish between rewall components, rewall systems and rewall architectures. According to Roedig [19, p. 11] we dene these as follows: A Firewall Component is a technical realization (as hard- or software com- ponent) of at least one function (i.e. a part of the security policy) that has to be implemented by the rewall. A Firewall System is composed of one or more rewall components and is the technical realization of all functions (i.e. the whole security policy) that have to be implemented by the rewall. A Firewall Architecture describes the combination of individual rewall com- ponents, as well as their interaction within the rewall system. In other words, rewall architectures describe rewall systems that consist of more than one rewall component on an abstract level. The above mentioned functions implemented by the rewall are primarily access control and audit functions. Schuba and Spaord [16, pp. 139142] distin- guish furthermore authentication, integrity and access enforcement functions. We classify the rewall components in the following Sections 2.1, 2.2 and 2.3 according to their operating mode. In addition we assign the components to the respective layers of the ISO/OSI reference model (as shown in Figure 1; confer for example Tanenbaum [17, pp. 3741] for detailed information). In general a rewall component uses the information from the layer it is assigned to and may use additional information from all lower layers. Fig. 1. The ISO/OSI reference model Section 2.4 describes the concept of personal rewalls, a technology which is more and more present today. Personal rewalls do not really t into the denition of a rewall system above, as they do not protect networks but single hosts. Section 2.5 describes content ltering, a technology not specic to rewalls, but which can be used as an enhancement to the described rewall components. 2.1 Packet Filters A packet lter is a rewall component that is usually located on the connection points of the networks separated by the rewall system. They are very simple to implement and it is possible to integrate them into network infrastructure hard- ware like routers or bridges. A packet lter inspects the packets of the ISO/OSI network and transport layer transferred between both networks. Hence a packet lter can make decisions based on IP addresses, the transport protocol type (e.g. TCP or UDP), port numbers, options and acknowledgements. According to this information, a packet lter can decide whether the inspected packet should be transmitted to its destination or not. As an example a packet lter can narrow the trac between the internet and a private network by applying a rule like: Allow incoming TCP packets assigned to port 22 for host A from hosts X, Y and Z. Deny all other incoming TCP packets assigned to port 22. Put in simple words, this rule species that SSH connections are only possible with the internal host A and only from the external hosts X, Y and Z. Figure 2 visualizes the operating mode of a packet lter. The packet stream between the communicating hosts is forwarded by the lter, if this stream does not violate the security policy. Fig. 2. The operating mode of a packet lter An enhancement and meanwhile a de facto standard of packet lters is called Stateful Inspection. A packet lter with stateful inspection is able to consider status information to tighten access control. As an example, one of the most obvious weaknesses of a packet lter without stateful inspection is that it cannot gure out whether an incoming UDP packet is an answer to a previous request from inside the network. With stateful inspection all incoming trac can be denied except if it is an answer to a previously outgoing request. To verify this, a packet lter keeps information (i.e. the IP address and the port number) of all outgoing connections and allows an incoming connection only if it matches this information. 2.2 Circuit Level Gateways While a packet lter inspects packets and forwards them to its destination, a circuit level gateway acts as a generic proxy. That is, the circuit level gateway takes over the role of the communication partner for each of the communicating hosts: For the client the circuit level gateway acts as a server and for the server it acts as a client.