· Design and Implementation
· Results and Performance Analysis
· Future Work
· Conclusion
· Credits
Corporate internal networks today are often connected to the Internet to provide employees with the ability to do research using the World Wide Web (WWW). These networks are typically protected from external attacks via "firewalls". Firewalls are special packet routers that allow or deny traffic (typically TCP/IP traffic, but possibly other kinds of network traffic) based on source address, destination address, and port. For example, a common practice is to allow traffic which originates inside the internal network and utilizes port 80 (the WWW), but to deny all other packets. While it is certainly sensible to limit network traffic that originates outside the boundaries of the internal network, it is futile and perhaps counterproductive to eliminate traffic that seeks to use special ports when the origination address is inside the corporate firewall.
A well-setup Firewall can observe the traffic and monitor the information going through instead of just closing the ports. This way the users are still able to use mail and FTP applications as far as the type of traffic is not abnormal.
Another sort of Firewall, which is common in corporate environments today, simply blocks all traffic to the Internet. Again, access to specific protocols (e.g., HTTP) is allowed through a "proxy server". Users are required to configure their WWW browsers to point to this proxy server and the server then parses some of the HTTP and forwards requests to the destination host.
The Firehole program demonstrates the futility of blocking ports other than port 80, by showing that traffic bound for other ports can be re-routed through port 80 (even when using a proxy server that parses HTTP protocol packets), thus subverting the Firewall. Nonetheless, this by itself would not render internal corporate networks insecure. However, we suggest that putting undue roadblocks to reasonable employee purposes may incent employees to utilize subversion methods, which might compromise network security. For example, the Firehole technology employed in an indiscriminant fashion could be used to forward external traffic into the corporate network, and thus provide a serious security risk.
At this time we have not found another program addressing the issue of Firewall bypassing. There are programs which simply forward data received on a given port to another port (e.g., redir), but this is not sufficient to subvert typical proxies which look for HTTP data specifically. The idea for Firehole is probably not unique, but we have actually implemented it. As we have developed this project, we have had numerous requests from friends and business associates who wish to utilize Firehole, particularly for access to their own POP3 email.
To implement our idea we need two independent communicating modules: one client deployed inside the corporate network and a server deployed somewhere outside in the open Internet. The client is configured to accept packets received on a certain port (our client can be configured to accept on any port available; port 8027 is the default for the Firehole server, but can be changed through a command line option) and forward these packets via the HTTP protocol on port 80 across the firewall through the proxy server to the Firehole server. The Firehole server then unwraps the forwarded packets and uses proprietary routing information encoded by the client to forward the packet on to its true destination. For the purpose of exchanging this information we developed the Firehole protocol which is encapsulated by the HTTP protocol. The Firehole protocol consists of a message header and a message body. The header contains all the information regarding the real destination of the messages, as well as the type of connection, and the transaction and session ID. The message body is the real message sent from client/server. The Firehole server then receives the response from the destination server, encapsulates it in HTTP, and replies to the Firehole client on port 80. The Firehole client can then unwrap the HTTP packets takes off the header and forward the result to the application client.
Java was our choice of language for implementation, because of its portability and ease to work with networks, sockets, packets, etc. Implementation of the system includes three main Java classes: FireholeServer, FireholeClient (plus Service Thread, Wrapper), and FireholeProtocol. For control of the transmission we developed a small state machine for each protocol so the Client and Server could know when to stop listening or sending. A time out is used to kill the threads that are blocked or when an error occurs. Configuring the servers and ports on the Client side is done through a stand-alone GUI application to help the user set up the Firehole system. Since configuration is stored in an ASCII text file, one can alternatively make configuration changes manually.
· Detailed Firehole protocol specifications
Firehole has been tested in two environments. Initially, tests were conducted using our own Proxy server which only simulated a real proxy that would run on a real firewall. Our sample proxy simply forwards HTTP traffic to the requested destination, receives the response, and replies with the response to the requester. This is a good simulation of the function of a real proxy in a production environment, but its performance (particularly latency) is probably overly optimistic since it typically is run with only one request hitting it at a time.
Tests run using the test proxy running locally on an NT 4.0 workstation that also ran both the Firehole Client and the Firehole Server performed fairly well. Checking POP mail when no messages were present took about 8 seconds, versus 2 seconds with no Firehole or Proxy intermediaries. The same test, but with retrieving two short messages typically took about 12 seconds using the Firehole system versus about 6 seconds with no intermediaries. It appears that each POP command is subject to approximately 2 seconds latency using the Firehole system in this way. That is, Firehole does not add significant overhead to the communication bandwidth used by the POP protocol itself. However, Firehole does introduce additional latency due to its call-response-disconnect paradigm.
This analysis was born out by additional testing done inside a real production firewall in the Columbia office of Engineering Animations, Inc. (EAI). The EAI network consists of a local area network which is routed through a Virtual Private Network (VPN) through a T1 to an Internet Service Provider (ISP). From the ISP, the VPN makes its way across the Internet to the EAI home office in Ames, Iowa. The Ames network connects to the open Internet via a proxy server which only accepts HTTP requests on port 80. No other traffic is allowed in or out of the Ames intranet.
Tests were conducted running the Firehole Client on a machine in the Columbia EAI office, the real EAI Proxy in Ames, and the Firehole Server on the University of Missouri campus. These tests indicated that a simple POP mail check with no messages present took about 50 seconds. Further tests indicated that reasonably short messages each added about 10 seconds to the overall communication time. It appears that in this environment, about 10 seconds latency per POP command can be expected. It was not possible to test POP mail retrieval in this configuration without the Firehole system since the firewall blocks such traffic. However, the extreme latency of the network itself (e.g., 200 ms to 400 ms ping times from the Columbia office to the proxy server during the testing interval) may give a good indication that the experimental Firehole times are not unreasonable.
It may appear that 70 seconds is a very long time to wait to retrieve a few email messages, and this is quite true in a sense. However, one may consider this delay to be quite reasonable if it is compared to driving across town to a site outside the firewall in order to retrieve email at all! Certainly improvements can be made to the Firehole protocol that may greatly improve performance. For example, one might consider "batching" a number of commands together. In order to implement such a scheme, one would have to make an assumption of success for each of the individual commands. This might work well for most instances, but would certainly make error tracking more difficult.
The following table summarizes our test results using the POP3 protocol:
Messages |
Configuration |
With Firehole |
Without Firehole |
0 |
Campus |
8 seconds |
2 seconds |
2 |
Campus |
12 seconds |
6 seconds |
0 |
EAI |
50 seconds |
N/A |
2 |
EAI |
70 seconds |
N/A |
Proxy - upper left hand corner
FireholeServer - upper right hand corner
FireholeClient - lower right hand corn
Due to lack of time some features are not implemented and are left to a future revision of the application.
The first thing that we have in mind, once we are done with this version of the Firehole application, is to extend the number of protocols supported. So far these protocols are supported:
We have implemented a general solution because we are using an interface in the Firehole application. To add other protocols we only need:
Some useful protocols to be implemented are FTP, Telnet, etc.
While FTP is fairly easy to implement, the Telnet protocol is more complicate due its requirement of a persistent connection. In the Telnet case the Firehole application will need a mechanism to remember the session (maybe with a session ID) and make transparent the open/close communication behavior between the Firehole client and the Firehole server through the firewall.
Another important feature remaining to implement is to have a time-out mechanism. This mechanism will prevent the Firehole client and server from requiring user intervention under error conditions. In this way, we will also improve the use of resources in the system (by stopping threads that are using memory, CPU, etc.) as well as network resources (by closing connections between the participants). The time-out mechanism will take care of connections in both of these communication paths:
Each time we have a time-out, it will be propagated to the Firehole client or to the Firehole server (depending on which side of the connection the time out was generated).
Security was not the focus of our project, although this would clearly be an issue in a production system. The likely traffic though port 80 is HTTP commands and HTML/XML documents. In our case, the type of information going through port 80 - user name, password, personal information, etc. is private and thus vulnerable to prying eyes. Encryption on the both sides - client and server Firehole is desired. This should work in two steps. First, encrypt at the client, encapsulate with the Firehole protocol, and send to the server. Second, de-encapsulate, decrypt the message and send it to the receiver.
Another feature to implement, that is going to improve the performance of the Firehole application, is the batching of commands. Batching commands will reduce the number of connections between the participants. This is important and relevant in low-bandwidth/high-latency environments (as one of our test environments has proven). Although this feature will present new challenges:
R:
220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S:
HELO USC-ISIF.ARPA
R:
250 BBN-UNIX.ARPA
S:
MAIL FROM:<Smith@USC-ISIF.ARPA>
R:
250 OK
S:
RCPT TO:<Jones@BBN-UNIX.ARPA>
R:
250 OK
S:
RCPT TO:<Brown@BBN-UNIX.ARPA>
R:
250 OK
S:
DATA
R:
354 Start mail input; end with <CRLF>.<CRLF>
S:
Blah blah blah...
S:
...etc. etc. etc.
S: .
R:
250 OK
S:
QUIT
R:
221 BBN-UNIX.ARPA Service closing transmission channel
R:
220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S:
HELO USC-ISIF.ARPA
R:
250 BBN-UNIX.ARPA
S:
MAIL FROM:<Smith@USC-ISIF.ARPA>
Firehole Client: 250 OK
S:
RCPT TO:<Jones@BBN-UNIX.ARPA>
Firehole Client: 250 OK
S:
RCPT TO:<Brown@BBN-UNIX.ARPA>
Firehole Client: 250 OK
Firehole Client:
MAIL FROM:<Smith@USC-ISIF.ARPA>
RCPT TO:<Jones@BBN-UNIX.ARPA>
RCPT TO:<Brown@BBN-UNIX.ARPA>
Firehole Server: OK
Firehole Server: MAIL FROM:<Smith@USC-ISIF.ARPA>
R:
250 OK
Firehole Server: RCPT TO:<Jones@BBN-UNIX.ARPA>
R:
250 OK
Firehole Server: RCPT TO:<Brown@BBN-UNIX.ARPA>
R:
250 OK
Firehole Server:
250 ok
250 ok
250 ok
Firehole Client: OK
S:
DATA
R:
354 Start mail input; end with <CRLF>.<CRLF>
S:
Blah blah blah...
S:
...etc. etc. etc.
S: .
R:
250 OK
S:
QUIT
R:
221 BBN-UNIX.ARPA Service closing transmission channel
<= Back to the top
The Firehole project shows that it is possible to tunnel other protocols through HTTP in order to defeat the firewall/proxy security scheme employed by many organizations. Here, we use Firehole only to obtain access to services which exist outside the firewall, from locations inside the firewall. This same sort of scheme, through polling techniques, could be used to provide access to resources inside the firewall from outside. Such a use of the technology would be very inefficient and would be a clear security risk.
However, we feel that our method of simply obtaining outside services from inside a firewall is quite legitimate. For example, a user may wish to receive his outside email from inside a firewall environment. This seems to be a very legitimate and innocuous purpose. In fact, we have been deluged with requests to use Firehole for this very purpose since the time we first proposed the project. It seems that users (ourselves included) will find ways to subvert arbitrary security schemes if these schemes become an impediment to legitimate and proper purposes. Organizations would be better served to limit only services which actually affect security rather than applying blanket denial policies as is so often the case today.
This was truly a team effort. Everyone worked hard and contributed a great deal over the course of many weeks. We designed the project as a group, spending a lot of time hashing out details on a chalkboard. The project seemed straightforward at the outset, but turned out to be a great deal of work. Nonetheless, we all learned a great deal and now we have a working and useful product!
Here are some of the specific contributions for individual team members: