Software for creating controlled leaks in firewall networks
A software construction from an earlier age of the Internet. From before the coining of the term 'Intranet'. Coded by Edward C Bennett. As told to him by David S Herron
This document created April 5, 1996.
This software created sometime in 1992 or so.
My how time flies and the world changes in such a short time.
Why, in 1992, hardly anybody KNEW of the Internet. Whoda thunk it?
Introduction | What is HoleD? | How does it work
Other possible uses | What HoleD cannot do | Future Directions
Security considerations | Downloading the Source
Firewalls are a necessary and vital thing to have. They limit the exposure your to the world thereby allowing you to feel safer to some degree. As if there were safety anway. In retrospect safety is an illusion for the need to control is simply an indication of ones inner feeling of there being no control. However in the "real world", by the terms and conditions of the societal matrix making up the Internet, it is frequently and understandably desired to have protection and control.
The model for this control in this context is yet another division of the world into pieces. One piece is "out there", or "the 'main' Internet". In pictures of the network this is always drawn as a great large looming cloud. In older computer networking times this large cloud was labeled with terms like "X.25", "DECNET" or "SNA". In these modern times the cloud is labeled "Internet". Same general architecture, with different words and protocols for different times. An analogy to the other "real world" (the world of trees, rivers and oceans we live in) is the ocean itself.
Another piece is an organizationally owned line which is a bridge zone. This bridge zone is an intermediary area in which information is exchanged between the relative safety inside the organization and the raw chaos out there. The bridge zone is like a no mans land, or to use the ocean metaphor, a harbor. Ships come and go from the harbor bringing things, the harbor is where foreigners abound while in the interior of the country the people and places are more uniform protected from the influences of foreign people and events. Likewise those inside the country having business with people outside the country tend to go to the harbor towns to conduct business.
The last piece of the networking model is the interior network. This can be drawn as a cloud too, but is more likely drawn as a number of interconnected line segments with computers hanging off them. This is the technical infrastructure of your organization. It is the wiring which holds the organization together. It is the bones and blood vessels of the flow of electronically exchanged information within the organization. This is the place the crown jewels are stored, the information the organization owns and wants to protect from the world. Not just the information, but also the processes which the organization has learned in order to make itself useful to the world. In the ocean/harbor analogy, this is the towns, villages and road network connecting with the harbor towns.
Like all analogies the ocean/harbor/village one is imperfect. But you get the idea.
The bridge network is both a protection zone and an exchange zone. It protects from outside incursions while allowing the exchange of information. It does not do for the bridge network to be an absolute wall keeping everything out, as that prevents the exchange which is vital and necessary. Instead the bridge network must allow some information to flow hither and yon.
The Hole in the wall Daemon (HoleD for short) is a controlled hole in the bridge network. It allows for tiny breaches to be created allowing for exchanges. It is a small process intended for a Unix system running the BSD suite of Internet software, and was originally developed on a Sun/SPARC server running SunOS 4.1, a 4/280 as I recall. The HoleD may not be entirely necessary in this modern age of wide availability of good firewall software. Like it says in the title area, it was constructed in an earlier age. It is, however, of general design and may be useful for other situations than originally intended.
The HoleD is run from inetd and, depending on the address of the incoming connection, will create a bridging connection elsewhere. It then goes into a loop passing data between them until one closes. That's it. It uses a configuration file to control what incoming ports get connected to which outgoing ports and is otherwise very simple.
This was designed with the following environment. A medium sized software company which we both worked at having a bridge network. One VMS system was the router conntecting the company to the network, being both the TCP/IP router having all the ethernet and high speed connections, as well as the mail hub between the company and out there. One ethernet/TCP/IP network segment was available in a way such that systems on this network were directly visible to out there with no protection. And the rest of the company had no access. There were two systems, other than this VMS based mail hub, another (and extremely dumb) router and the above mentioned Sun server (fortuitously owned by Software Engineering for experimentation purposes) which had a second ethernet interface facing the internal network. The Usenet/NNTP server was located on an internal system without visibility to out there and no good solution for bringing articles into it.
Thus we have motivation: Getting Usenet inside the company network!
The extremely dumb router was certainly incapable of bridging this traffic itself, and it was very unlikely to be replaced. Especially for something viewed to be as nonessential as Usenet. Sigh.
So, witness this spectacle. Two former usenet site administrators, one of them a former member of the Usenet Backbone Cabal (er.. Committee), without a good and reliable news feed, and without the technical infrastructure to support the right connections. Fortunately just the right amount of hardware and technical knowhow was available to do the job. Out of this need was the adventure of creating HoleD born. (Do you think I'll grow up to be a novelist one day? Please give me any feedback on this question as soon as possible.)
Installation is in the olden style of: 1) ponder the source code and Makefile, 2) adjust to local site preferences, 3) compile. You may want to adjust the location of holed.conf controlled by a #define in holed.c, the default is /etc/holed.conf. You also may need to adjust the set of #include's in holed.c as SunOS 4.1 systems are getting rarer as the days go by, they are correct for SunOS 4.1.
This is an example /etc/holed.conf as it was being used by us.
nntp gonzo.twg.com gollum.twg.com nntp gollum.twg.com mips.com nntp mips.com gollum.twg.com nntp idunno.princeton.edu gollum.twg.com nntp-idunno gollum.twg.com idunno.princeton.edu nntp whois boomer.twg.com nic.ddn.mil whois
The first two columns give way to describe incoming connections. Recall that holed is meant to run from inetd. When holed starts it uses getpeername(2) to determine where the connection is coming from. The connection is an IP address and a port number. What is in the file is a protocol name (a lookup in /etc/services tells you the port number) and a host name, and holed compares the port/host names in the file with the IP/port returned by getpeername(2).
If the incoming connection matches the first two columns of one of these lines then it is bridged to the connection described in the third and optional fourth column.
No specific port number is assigned to holed as it does not have its own protocol. Instead one configures inetd to use holed for some of the services offered through inetd. In inetd.conf there is a place to give the name of the executable that provides the given service. Instead of listing, for instance, nntpd to service the nntp protocol, we listed holed instead.
Given the above configuration file, incoming nntp connections are bridged to one of two places, depending on where the connection comes from. The system gollum.twg.com was the main news server at this time and so most of the connections would go there. Most especially note the mips.com and idunno.princeton.edu lines as these are connections from out there which we wished to bridge into the internal network. Likewise nntp coming from gollum.twg.com was bridged to mips.com allowing our outgoing nntp traffic to be sent. However the outgoing connection to idunno.princeton.edu is handled differently. There wasn't a way to distinguish which host out there to bridge to other than to connect with a different port and have holed map the port we numbered nntp-idunno to idunno.princeton.edu:nntp.
That's it. Simple, eh?
The above uses are interesting. There are other possible uses which we never tried, but certainly feel are possible.
For instance some services such as Mail and News are expensive and unneccessary to replicate on every server or workstation. Still it is a more simply configured environment if each server and workstation answers to the NNTP and SMTP ports with a reasonable response. Responding with a failure notification and closing the connection is less than useful. Instead holed can be used on the more simply configured systems to map incoming NNTP/SMTP connections to a more central server system. To do this successfully holed might need to have extra abilities to prevent loops in some form. In any case this is only to be considered useful for internal use, not used in bridging to out there.
The http protocol, HTML markup language, nor any of the other WWW pieces had not been invented yet at the time of creating holed. Just as it is applied to nntp in the example it can be easily applied to http. The configuration file should become more complex giving a way to give wildcards and perhaps to disallow certain addresses.
Maybe you want to offer different http servers to different addresses?
The virtual host metaphor that has been created for WWW marketeering efforts can use something like holed quite well. Instead of responding to the external half of the incoming connection it would respond to the internal half of the incoming connection. Depending on the address being connected TO (as opposed to connected FROM as described above), different addresses to bridge TO would be used. Given the flexible nature of the holed configuration, the destination address can be for different http servers on the local system, or across multiple external systems.
Think of holed as a symbolic link analogue. In modern Unix systems the symbolic link is a way to make one thing appear elsewhere for any of a number of reasons.
The principle limitation is that holed does not know anything about the protocols it is bridging. So it cannot be used to bridge protocols that use side connections, such as ftp, since holed cannot possibly and does not have the context to know to look for the extra connection. Holed could be taught the necessary knowledge, but then it becomes an ftp bridging daemon, not a generic bridging daemon. Another column would have to be given describing the protocol to emulate/bridge.
Holed does not bridge anything other than the data arriving on either side of the TCP connections.
Holed only bridges TCP, not UDP nor RDP.
At the present moment holed is unlikely to be maintained by either Edward Bennett or myself. Neither have the incentive or timeto support this or develop it further. It served our purpose well.
While writing this it occurred to me the following features would be useful additions:
A declaration of which half of the incoming connection to match for.
Some options on the TCP socket, such as buffer sizes, passing of OOB data, SO_LINGER, timeouts, and so forth.
Emulation of some protocols that use side ports. FTP in particular.
More complex matching of incoming host names such as wild cards (both for IP address and host name). Also a way to negate certain hosts or wildcarded hosts. List multiple conditions in one line.
Range of port numbers in the incoming connection in addition to just the single port name as now.
Does the newer security protocols have any impact?
Bridging UDP as well.
Nicer looking configuration file with at least commenting allowed.
A GUI to administer the config file, perhaps as a binary file instead of ASCII.
A way to randomly select a destination host, to implement rudimentary load balancing.
This application is a security breach so it is wise to consider for a moment the security considerations.
Just as symbolic links can be used unwisely to create a tangled mess, so could holed. So the first reccomendation is to keep holed use as simple as possible. It is only one of the many kinds of tools to be used in the well stocked network administrators toolchest. Use it wisely.
Every breach created by holed is created by the person who installed it. Before adding a line to holed.conf consider the implications of exporting that protocol to out there. You should understand something about the protocol, and the abilities of the protocol has both desired and undesired. This should be safe as the normal protocols themselves are safe (relatively) enough to be widely used anyway.
Holed does not, itself, respond to the data it passes so it does not add any extra breaches. It is simply a pipe through which to crosslink two spots. Kind of like the white holes which are supposed to be associated with black holes.
The installation should itself be secure. Do not make holed.conf publicly writable 'lest an unscrupolous user use it to create real security breaches.
The source code for holed is small enough to simply offer directly here. Click on the following links to download each piece:
holed.c C source code for the program. holed.conf Example configuration file. Makefile Instructions for building the program.
Load each into your browser and use Save As to save to disk.
This software is offered free of charge, with no attempt to assert ownership of any kind nor to aquire any support or money for it. Use it as you will. I simply wanted to document a useful piece of technology.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent