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 tra c 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 tra c to communication which is considered trustworthy. For instance, mistrusted tra c can be tra c of a ser- vice that is considered as insecure or tra c from a host whose IP address is not trusted. But although required leaving some channels open for communication provides possibilities to misuse them for tra c 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 tra c nor legitimate tunneling tra c. It is prohibited tra c which is camou aged as regular tra c 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 speci c (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] de nes a rewall as follows: An internetwork gateway that restricts data communication tra c 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 de nition of a rewall it is common, to distin- guish between rewall components, rewall systems and rewall architectures. According to Roedig [19, p. 11] we de ne 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 de nition of a rewall system above, as they do not protect networks but single hosts. Section 2.5 describes content ltering, a technology not speci c 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 tra c 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 speci es 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 tra c 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. Consequently, the hosts are no more connected through a direct connection. Regarding the ISO/OSI reference model, circuit level gateways are working on the transport layer. They provide generic proxy services for the transport protocols (e.g. TCP and UDP). In contrast to simple packet lters, circuit level gateways can be aware of status and contextual information. Figure 3 illustrates the communication of two hosts through a circuit level gateway. Notice, that there is no direct communication between both hosts.
Fig. 3. The operating mode of a circuit level gateway
To implement its functionality, a circuit level gateway is usually realized on a multi homed host. Such a host has two or more network interfaces and is thus connected to multiple networks. Multi homed hosts are typically referred to as bastion hosts, because they mark a critical point for the internal network's security. However, the enhancement of packet lters to dynamic, adaptive and in- telligent systems has minimized the functional dierences between circuit level gateways and packet lters. Both rewall component classes can be seen from a functional perspective as virtually equivalent, as stated by Eckert [13, p. 673].
2.3 Application Level Gateways Application level gateways act like circuit level gateways as proxies. But in contrast to circuit level gateways, they are working on the application layer of the ISO/OSI reference model. That is, they have to provide a dedicated proxy service for each application they support. The application layer gateway illustrated in Figure 4, for example supports HTTP and Telnet.
Fig. 4. The operating mode of an application level gateway
The advantage of application level gateways over circuit level gateways and packet lters is obviously the fact that it works on a higher layer of the ISO/OSI reference model. It is able to check the syntax and semantic of the data coming by. This allows setting up more complex rules which are based on the charac- teristics of these high level protocols. For instance, an application level gateway can allow a subset of commands of an application protocol while denying oth- ers (allow incoming FTP "GET", but deny incoming FTP "PUT" commands). Another advantage is that with an application lter it can be assured, that the type of connection passing the rewall is the one which it is assumed to be. For example, a packet lter could forward TCP connections for port 80 assuming they belong to a web (HTTP) connection. But there is no guarantee that this connection is not of another type, such as a le transfer protocol. In contrast, an application level gateway which implements a HTTP proxy only transmits HTTP connections. This is because the proxy does not allow any non-HTTP connections for port 80. Beside all the advantages, there is the disadvantage of performance loss which might occur due to an application level gateway. This is because the application level gateway has to take a deeper look into the protocol stack as packet lters and circuit level gateways for the inspection of high level protocols. Another disadvantage is the eort that has to be put in setting up a new proxy service, as mentioned by Cheswick and Bellowin [1, p. 76]. In the worst case this can require a modi cation of the con guration of each client program that wants to use the new proxy service.
2.4 Personal Firewalls As already stated above, personal rewalls do not t into the de nition of rewall components. They can rather be de ned as rewall systems for a single host. Such systems are software components and shield the network connection of the computer they are running on. All other hosts even if within the same local network are generally mistrusted, if not speci ed by a lter rule otherwise. The main component of a personal rewall is a (stateful) packet lter. But as personal rewalls are working on the host they are protecting, they have knowledge about each application which is trying to establish a connection. This information is included into the lter rules of the packet lter. Figure 5 shows a host that is protected by a personal rewall. One the one hand, typical internet applications like a browser or a mail client can have access to the outside of the host. On the other hand, (the kernel of) the operating system or other programs that are worthy of protection or do normally not need to access the internet can be shielded from any contact to the outside.
Fig. 5. The operating mode of a personal rewall
As personal rewalls only protect single hosts, they are appropriate for be- ing applied by individuals which want to ensure a secure access to the inter- net. Similarly personal rewalls can also be applied on mobile devices (as note- books) which are likely of being connected to dierent public or other mistrusted networks. Also, modern personal rewalls usually oer a broader spectrum of functionality than common rewall components. Such advanced functionality includes for instance, intrusion detection or special content ltering like adver- tisement blocking or data protection services.
2.5 Content Filtering Content ltering is a technique that is not speci c to rewall systems, but that can be applied to rewall systems in a practical way. Put in simple words, con- tent ltering is the inspection of an amount of data for speci c patterns. For example, antivirus software commonly uses content ltering to scan data for virus signatures. In the eld of rewall technology content ltering can be used in conjunction with every of the discussed rewall components. As such an enhancement it is used for inspecting the payload of each packet or protocol data unit to tighten the rewall functions. For example many companies use a content lter with their web proxy to screen for web sites containing objectionable content.
3 Tunneling
Because rewalls usually act as gatekeeper to a network, they can be a single point of failure if an intruder manages to establish a tunnel through the rewall into the protected network. When succeeded to do so, the intruder can access the resources of the network as if he was directly connected to it. Shirey de nes in RFC 2828 [18, p. 183] a tunnel as a communication chan- nel that encapsulates a communication protocol's data packets in (on top of) a second protocol. In this context encapsulation stands for the act of using the data units (packets) of the protocol to be encapsulated, as payload of the encap- sulating protocol (see Figure 8 for some examples). The latter protocol can be every protocol of the same or a higher ISO/OSI layer theoretically the encap- sulating protocol can also be of a lower layer, but there is no practical use for this option. Consequently, the tunneled protocol remains as long concealed until the encapsulation is removed or the payload of the communication is examined. To secure the encapsulated data from examination it is additionally possible to apply encryption, steganography and/or compression techniques to the payload before encapsulating it. Every tunnel features a tunnel entry and exit. At the entry the data units of the protocol to be tunneled are encapsulated. At the exit of the tunnel the original data units are revealed by removing the encapsulation again. But as communication is ought to be bidirectional the tunnel entry of one direction is usually the exit for the reverse direction and vice versa. For this reason we use the term tunnel gateway as genus for tunnel entrance and exit. Figure 6 shows an example of an legitimate tunnel which connects two net- works by tunneling IP packets over the IPSec protocol ESP. Kent and Atkinson describe the architecture of IPSec and ESP protocol in RFC 2401 [20] and RFC 2406 [21], respectively. ESP provides several security services for IPv4 and IPv6, including encryption and authentication. Hence tunneling with ESP is an appro- priate technique to ensure a secure communication based on the network layer of the ISO/OSI reference model. As stated above, tunneling can be used in multiple ways. First of all, it does not necessarily have to be used in interaction with a rewall. Tanenbaum, for example, mentions in [17] that tunneling might be used as a transport enabler to link two multicast-capable networks (such as Ethernets) over a unicast-only network (such as a T1 leased line). When used in conjunction with a rewall, Fig. 6. IP over ESP Tunnel tunneling can be used in a good and in a bad way. The former is usually when two or more networks or single hosts are connected with a legitimate tunnel over a public (hence insecure) network, a concept referred to as VPN. The latter is when tunneling is used to bypass the rewall to realize connections to the outside of the protected network that are denied otherwise. These tunnel connections are characterized as dangerous because they constitute a violation of the security policy. Generally there are three options where a tunnel gateway can be placed with respect to the rewall. All of them have advantages and disadvantages. In the following these are described from a network administrator's view. From an at- tacker's view the security related advantages and disadvantages are interchanged.
1. The tunnel gateway is placed inside the locally controlled network, but before the rewall, see Figure 7(a). The advantage is that no changes to the rewall policy have to be undertaken and that the tra c can be inspected by the rewall. The disadvantage is that the tra c is revealed before it is located in the shielded area of the locally controlled network. Any intruder who manages to access this unshielded area can read the tra c. This option is independent to any rewall system. 2. The tunnel gateway is placed behind the rewall, see Figure 7(b). This option has the advantage that it supports better peer-to-peer security, because the tra c remains encrypted as long as it is located outside a secure network. The disadvantage is that usually the tra c's data cannot be inspected by the rewall as it is encrypted. In contrast to the previous option, this option is dependent on the rewall. This is because the tunnel tra c has to get though the rewall somehow: Either by con guring the rewall to forward the tra c to the tunnel gateway, or by tricking the rewall in a way that it is not aware of the tunnel. 3. The tunnel gateway is placed into the rewall, see Figure 7(c). This means, the tunnel gateway is a component of the rewall system. This enables the decapsulation and decryption of the tra c before it is sent to a component that would deny the encrypted tunnel payload otherwise. This scenario pro- vides the advantages of both previous options: The tunnel gateway is secured by the rewall system, but can also be inspected by it. Consequently this option is partly dependent on the rewall system namely on the rewall components located before the tunnel gateway. An additional problem of this option is, that it increases the rewall con guration and maintenance eort.
(a) Placement before the (b) Placement behind the (c) Placement into the re- rewall rewall wall
Fig. 7. Tunnel placement options
In this Section we investigate which eorts need to be taken in order to estab- lish tunnels between rewall protected networks or hosts. Firstly, we summarize legitimate tunneling approaches by describing several VPN technologies. Sec- ondly, we describe illegitimate tunneling approaches that can be used to bypass scenarios with a rewall at one of the tunnel's gateways. Lastly, we enhance these approaches to cover scenarios with a rewall at both tunnel gateways. When being legitimate, any con guration to the rewall can be undertaken to realize a tunnel. Thus the tunnel gateways can be placed as described by all three above mentioned options. In contrast, only a placement of the tunneling gateway behind the rewall system is appropriate for illegitimate tunnels if not malware is used to compromise the rewall system. That is, because a decapsulation of illegitimate tunnel tra c before the rewall is useless since illegitimate tunnels cannot depend on a change of the rewalls security policy to permit them.
3.1 Legitimate Tunneling with VPN
A VPN is a data network that makes use of a public networking infrastructure, such as the internet, for transmitting private data. It can be used to connect several local area networks to a WAN or for granting single hosts access to a private network. In the WAN example a VPN can be compared to a transmission line usually leased from a telecommunications provider. This line can then be used by the lessee to make the connection between its individual LANs. The example illustrated in Figure 6, how most modern VPNs are operating. The private networks are connected over the internet by an ESP tunnel. In- stead of ESP some older VPN implementations use the data link layer protocols point-to-point tunneling protocol (PPTP) or layer 2 tunneling protocol (L2TP) for encapsulation. Both protocols encapsulate the point-to-point protocol (PPP). PPTP carries out PPP-over-IP tunneling only, using Generic Routing Encap- sulation (GRE) for encryption. L2TP enables PPP tunneling over any network layer protocol instead. This is done by substituting the PPP header with its own L2TP header. Most commonly L2TP uses UDP and IP to encapsulate PPP. Note that P2TP does not support encryption itself, to ensure secure tunneling L2TP has to be used in conjunction with a cryptographic protocol. Confer RFC 2637 [22] and RFC 2661 [23] for details on PPTP and L2TP. PPP and GRE are described in RFC 1661 [24] and 1701 [25] respectively. Figure 8 shows the simpli ed protocol stacks of each of the above described legitimate tunneling approaches.
Fig. 8. VPN encapsulation methods
The above discussed VPN tunneling techniques span the data link and net- work levels of the ISO/OSI reference model. They are thus also referred to as low level VPN technologies, for example by Bauer in [26]. Above we have solely discussed the most common technologies, Gleeson et al. [27] give in RFC 2764 a comprehensive survey of low level VPN approaches. Alden and Wobber describe in [28] a VPN approach sited on the transport layer that encapsulates IP packets with TCP. They claim their approach to be rewall independent, because it uses a protocol sited on an ISO/OSI layer above the network level and thus gives ". . . the clear advantage that tunnel endpoints need not be packaged with or dependent on a speci c rewall implementation." This is true as long as the rewall does not contain an application level gateway. But if so, the tunnel connection fails at this point, because there is no proxy service available which can handle the encrypted payload data of the TCP pack- ages. If a VPN approach should be rewall independent, including application level gateways, the encapsulating protocol must be located on the application layer. VPN solutions accomplishing this are for example SSL/TLS based approaches like OpenVPN [29] and SSL-Explorer [30] or tunneling connections over the SSH protocol. However, these tunneling approaches have the disadvantage that they are dependent of a speci c high level protocol, if this protocol is not allowed to pass the rewall system they are of no use.
3.2 Illegitimate Tunneling In the scenarios covered by this Subsection, we rst describe settings where the tunnel bypasses illegitimately one rewall and either legitimately a second rewall or no other rewall. Such scenarios can be seen as most common since usually outgoing connections and their replies are allowed. However, at the end of this Section we propose some ideas on how to establish tunnels in a two- rewall-setting. The crux of establishing a tunnel through a rewall system is to pass the tunnel connection through each component of the system. This is why we solely describe the requirements to tunnel single components of the system. If a rewall system consists of more than one component which is likely we presume, that the system can be tunneled by applying a combination of the tunneling techniques required to tunnel each component of the system. Bypassing common packet lters is straightforward. For instance, HTTP con- nections are normally allowed between almost any host of the internal network and almost any host of the external network. This means that the packet l- ter must allow TCP connections over port 80 between all internal and external hosts, possibly some dedicated hosts are excluded. But there is no guarantee that both hosts are really transmitting HTTP. They can as well use any other TCP based protocol. Even if the packet lter denies in- and outbound connections to the intruder's (external) host, the intruder can use IP spoo ng techniques to compromise the packet lter. Another scenario is that the packet lter denies inbound and out- bound connections to the internal host the intruder wants to connect to. Then the intruder can connect to a second, unshielded internal host that is allowed to connect to the shielded host. This second host then forwards the connection to the shielded host by using common port forwarding technologies. Packet lter with stateful inspection as well as circuit level gateways are context-aware. This allows more sophisticated ltering rules to be set up. Ac- cordingly more sophisticated tunneling techniques have to be used to circum- vent such rewall components. The di culty of establishing a tunnel connection through a context-aware component is, that usually all incoming requests are denied except if they are an answer to a previously outgoing request. Conse- quently the tunnel has to be initiated from the inside of the protected network, which poses a signi cant limitation. In the above described situations the encapsulating protocol of the tunnel connection had to be sited somewhere on an ISO/OSI layer above the network layer because the tunneled rewall component inspects transport layer informa- tion. In contrast, application level gateways are rewall components that inspect application layer information, thus the encapsulating protocol has to be sited on the application layer. Additionally, this protocol has to be one of the protocols the gateway is oering. And furthermore, application layer gateways are also capable of employing context information. If a content lter is additionally applied to a rewall system this lter can inspect the payload of the data that passes the rewall. Thus a content lter can for instance deny connections where a low level protocol is found in the payload of a high level protocol. To circumvent content lters the data to be tunneled must be unrecognizable as communication data or look like ordinary application data. One way to realize this is to encrypt or compress the data that is to be tunneled. Zwicky, Cooper and Chapman [15, p. 398 et seq.] describe an HTTP- tunneling approach that is hard to recognize for a content lter. The tunneled data is not only wrapped within HTTP, it is camou aged as multimedia data, such as an image. As mentioned above it might be that additionally, a tunnel has to circum- vent also a second rewall system. This is especially the case, if both systems are sophisticated and neither of them can be adjusted to allow the tunneling. How- ever, such scenarios can be reduced to a one- rewall-setting as described above by using an intermediary host. For instance if both rewalls are context-aware, both tunnel gateways need to initiate the connection, but would be blocked by the rewall on the other side. With interposing an intermediary host that turns each request of the one side into a response for the other side and vice versa, this problem can be solved. Figure 9 illustrates this scenario.
Fig. 9. Establishing a tunnel connection through two rewalls
4 An Adaptable Tunneling Application
We developed an adaptable tunneling application that is capable of establishing tunnels through virtually every rewall setup. This is chie y due to two reasons: Firstly the application is written in Java which makes it executable on a broad range of computers. Secondly and much more relevant this is because the application can be highly customized with plug-ins. Generally we distinguish two dierent types of plug-ins: Access points and lters. In the following we cover the generic features of the application considering each plug-in type and point out to what degree the functionality of the application can be extended by implementing plug-ins. Put in simple words an access point and an array of lters the so-called lter chain act together as the tunnel gateway. In this arrangement the access point is responsible for managing the connections, whereas the lter chain is performing the encapsulating or decapsulating. Access points have very simple interfaces. They have to implement some kind of "Local Connection". Additionally they have to provide some kind of "Remote Connection". Both connections provide "Input Streams" and "Output Streams". The main application then reads the data from the local connections input stream, passes it through the lter chain and writes it to the remote connections output stream. And vice versa. Note that the local connection and the remote connection can be realized in dierent ways. The communication with the counterpart tunnel gateway, the usage of the lter chain and the transmission of data is part of the generic functionality of the application. Consequently, the scope of an access point plug-in is solely the provision of the connections. The connections can be of virtually any type, e.g. standard UDP connections, email communication or a covered channel. We implemented a simple TCP access point that realizes the local connection as a TCP connection to a local port. It realizes the remote connection as a TCP connection to a remote host's port. Without con guring a lter chain this access point can already be used to circumvent a common packet lter as described in Section 3.2. Also generically, the transferred data streams are broken into data units and passed through the lter chain. Each lter can then perform its operation on the data. Such operations can include encrypting or compressing the data or wrapping it within a protocol. Implementing such modifying operations is all that has to be accomplished by lter plug-ins. Figure 10 shows an example lter chain as it can be used in the tunnel application. This example realizes the above cited HTTP tunneling approach described by Zwicky, Cooper and Chapman [15, p. 398 et seq.] which hides the tunneled data in media data of an HTTP response. The zip- lter compresses the data that should be tunneled through the rewall (for example malicious code) and thus transfers it into binary data that is not interpretable ohand. This data is then made interpretable again by the HTTP-wrapper- lter which embeds it in image data contained in an HTTP response. In that way the malicious code can be camou aged as harmless web tra c, which will be allowed through nearly every rewall component and content lter. Fig. 10. A lter chain example
5 Conclusion
Firewalls are well investigated and widespread security systems. But as we have shown these systems can still be bypassed, either in a legitimate or in an illegit- imate fashion. The former if implemented securely and in compliance with the rewalls security policy does not pose a threat to the system. The latter though can cause severe damage to the con dentiality of electronic assets contained in the protected network. We have shown in this paper that the establishment of such bad tunnels is far from being impossible. In contrast, when aggregating tunneling with encryption, steganography and/or compression techniques (i.e. reversible data modi cation techniques), tunnels can be established even through sophisticated rewall sys- tems. With the implementation of a highly adaptable tunneling application we have further realized a framework that enables such an aggregation in multiple ways. Used in combination with attacks and malware like IP Spoo ng, man-in-the- middle or Trojan horses, illegitimate tunneling can have an even more severe impact on the security of computer networks and computers.
References
1. Cheswick, W.R., Bellovin, S.M.: Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley, Reading (1994) 2. Perkins, C.E.: Mobile ip. IEEE Communications Magazine 35(5) (1997) 8499 3. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners- Lee, T.: Hypertext transfer protocol http/1.1. RFC 2616 (1999) http://www. ietf.org/rfc/rfc2616.txt. 4. Brinkho, L.: Gnu httptunnel. http://www.nocrew.org/software/httptunnel. html (2006) 5. HTTP-Tunnel: Http-tunnel. http://www.http-tunnel.com (2006) 6. Visser, J., Jansen, M.: Proxytunnel. http://proxytunnel.sourceforge.net/ (2006) 7. Dierks, T., Allen, C.: The tls protocol version 1.0. RFC 2246 (1999) http: //www.ietf.org/rfc/rfc2246.txt. 8. Ylonen, T., Lonvick, C.: The secure shell (ssh) protocol architecture. RFC 4251 (2006) http://www.ietf.org/rfc/rfc4251.txt. 9. Hatch, B.: Stunnel. http://www.stunnel.org/ (2006) 10. Symbion: Sslproxy. http://sourceforge.net/projects/sslproxy/ (2006) 11. Bitvise Limited: Tunnelier. http://www.bitvise.com/tunnelier.html (2006) 12. Han-Soft: Internet secure tunneling. http://www.han-soft.com/stm.php (2006) 13. Eckert, C.: IT-Sicherheit: Konzepte, Verfahren, Protokolle. 3 edn. Oldenbourg, Muenchen (2004) 14. Stallings, W.: Cryptography and Network Security: Principles and Practices. 3 edn. Pearson Education, New Jersey (2003) 15. Zwicky, E.D., Cooper, S., Chapman, D.B.: Building Internet rewalls. 2 edn. O'Reilly, Sebastopol (2000) 16. Schuba, C., Spaord, E.H.: A reference model for rewall technology. In: Pro- ceedings of the 13th Annual Computer Security Applications Conference. (1997) 133145 17. Tanenbaum, A.S.: Computer networks. 4 edn. Prentice-Hall, Upper Saddle River (2003) 18. Shirey, R.: Internet security glossary. RFC 2828 (2000) http://www.ietf.org/ rfc/rfc2828.txt. 19. Roedig, U.: Firewall-Architekturen für Multimedia-Applikationen. PhD thesis, Darmstadt Technical University (2002) 20. Kent, S., Atkinson, R.: Security architecture for the internet protocol. RFC 2401 (1998) http://www.ietf.org/rfc/rfc2401.txt. 21. Kent, S., Atkinson, R.: Ip encapsulating security payload (esp). RFC 2406 (1998) http://www.ietf.org/rfc/rfc2406.txt. 22. Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, G.: Point-to-point tunneling protocol (pptp). RFC 2637 (1999) http://www.ietf.org/rfc/rfc2637. txt. 23. Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., Palter, B.: Layer two tunneling protocol "l2tp". RFC 2661 (1999) http://www.ietf.org/rfc/rfc2661. txt. 24. Simpson, W.: The point-to-point protocol (ppp). RFC 1661 (1994) http://www. ietf.org/rfc/rfc1661.txt. 25. Hanks, S., Li, T., Farinacci, D., Traina, P.: Generic routing encapsulation (gre). RFC 1701 (1994) http://www.ietf.org/rfc/rfc1701.txt. 26. Bauer, M.: Paranoid penguin: Linux vpn technologies. Linux Journal (130) (2005) 13 27. Gleeson, B., Lin, A., Heinanen, J., Armitage, G., Malis, A.: A framework for ip based virtual private networks. RFC 2764 (2000) http://www.ietf.org/rfc/ rfc2764.txt. 28. Alden, K.F., Wobber, E.: The altavista tunnel: Using the internet to extend cor- porate networks. Digital Technical Journal 9(2) (1997) 516 29. OpenVPN Solutions LLC: Openvpn. http://openvpn.net (2006) 30. 3SP: Ssl-explorer. http://3sp.com/showSslExplorer.do (2006)