Zebedee — a simple, free, secure tunnel program
zebedee -s [-dDt] [-f file] [-k keybits] [-n name] [-o logfile] [-r ports] [-v level] [-x config] [-z level] [redirect-host]
zebedee [-dDmt] [-e command] [-f file] [-k keybits] [-n name] [-o log] [-v level] [-x config] [-z level] [[localport:]host[:remoteport]]
zebedee -p [-f file]
zebedee -P [-p] [-f file]
zebedee -h [file ...]
zebedee -H string ...
zebedee [-n name] -S [install[=file] | remove | run]
Zebedee is a simple program to establish an encrypted, compressed TCP/IP “tunnel” between two systems. This allows TCP-based traffic such as telnet, ftp and X to be protected from snooping as well as potentially gaining performance over low-bandwidth networks from compression.
The main goals for Zebedee are to:
Provide client and server functionality under both UNIX and Windows 95/98/NT.
Be easy to install, use and maintain with little or no configuration required.
Have a small footprint, low wire protocol overhead and give significant traffic reduction by the use of compression.
Use only algorithms that are either unpatented or for which the patent has expired.
Be entirely free for commercial or non-commercial use and distributed under the term of the GNU General Public Licence (see CREDITS AND LEGALITIES).
Of course, Zebedee is by no means the first, or only secure tunnel program available. It does not pretend to compete with the likes of ssh or SSL in terms of breadth of function but if you want something quick, simple and completely free then it may be the tool for you.
This document describes the features of Zebedee as at release 1.3.0.
In case you were wondering, or even if you weren’t, Zebedee is named after its three main components:
Zlib compression
Blowfish encryption and
Diffie-Hellman key agreement.
So now you know!
To set up a secure connection between your local machine and a remote host you need first to run Zebedee in server mode on the remote system. The easiest way to do this is to run Zebedee with the -s option. Like this:
zebedee -s
If all goes well (and it should!) Zebedee will detach from the terminal (or console window under Windows) and run in the backgroud. It will then be listening for incoming requests from clients.
On your local machine you then run Zebedee in client mode. You need to specify the name of the remote machine and the
name of the service or number of the port to which the tunnel should be
established. If the remote machine is called remhost and you want to set up a secure telnet session then you would run:
zebedee remhost:telnet
In fact, if you don’t specify a service or port the default is telnet so
zebedee remhost
would do just as well in this instance. When you run this command it will
print out a message telling you the port number which is the local end of
the tunnel. Zebedee will then detach from the terminal and run in the background waiting for
you to connect to the local port. If, for example, the port number it
printed out was 1234 then to connect to remhost using the secure tunnel you would run:
telnet localhost 1234
Most of the time you will want to run Zebedee and then run a command that connects to the port straight away. You can do this in a single invocation of Zebedee as follows:
zebedee -e "telnet localhost %d" remhost
The “%d” in the string is automatically replaced with the local port number so
there is no need for Zebedee to print it out.
Sometimes you need to control the local port number that the client uses. This is necessary if the command whose connection you are trying to protect expects to connect only to a specific port. In this case you can also specify the local port number by invoking Zebedee as follows:
zebedee localport:hostname:remoteport
In server mode Zebedee will handle multiple simultaneous connections and the process will continue to run, waiting for new connections, until it is terminated. By default a Zebedee client, however, runs in “single-use” mode in that once the connection is closed then Zebedee exits. This fine for many purposes but sometimes you want to establish a more permanent tunnel between two systems so that any connections to a specific local port are tunnelled to a known remote port. To enable this “multi-use” mode you can use the -m option. So, for example, the command:
zebedee -m 8000:webhost:80
will allow you to secure all HTTP connections to webhost. See EXAMPLES for more details.
You can also use a single Zebedee client to handle multiple simultaneous tunnels to different remote ports on the same host. In this case the local and remote port specifications are lists of ports. For example:
zebedee 9001,9002,9003:somehost:daytime,telnet,ftp
This will tunnel traffic on the local port 9001 to the daytime port on the remote system, traffic on 9002 to the telnet port and traffic on 9003 to the ftp port. If you use Zebedee in this way with multiple port then “multi-use” mode is implicit and you do not have to specify the -m option.
See the localport and remoteport keywords for more details.
The behaviour of Zebedee is probably best controlled through the use of a configuration file. A configuration file can be specified using the -f command-line option. The file is read at the point at which the option is encountered so later command-line options may override the contents of the file.
Lines are of the form:
key value # optional comment
The key is a single, case-insensitive word. The value is either a single word or a
string. Strings are enclosed either in double quotes ("like
this") or single quotes (’like this’). Double quotes may appear in single quoted strings and vice versa ("here’s an example"). Case is preserved in the values where appropriate.
Blank lines and lines beginning with a “#” (after any leading whitespace) are ignored. Long strings may be
continued onto the next line by ending the line with a “\” character. This character is eliminated and the next line is joined on
to the end. Note that there is a limit of a total of 1024 characters on any
line and its continuations. Line continuation happens before anything else,
including comment recognition so the lines:
server false # This comment continues on the next line \ server true
will leave the value of server as false.
The keys and their meanings are as described below. Most, but not all, keys have equivalent command-line options. These are shown where available. There are also a few command-line options that have no equivalent in the configuration file. These are described at the end of this section.
If a key is described as being a boolean then its value must be the words “true” or “false”.
Several keys require a list of ports to be specfied. Where this the case
the value is string that consists of a comma or white-space delimited list
of port names, numbers or numeric ranges. For example “telnet, ftp 5900-5903”. This is equivalent to the list “23,21,5900,5901,5902,5903”.
A number of the keys are either only applicable to clients or only applicable to servers. The same Zebedee program runs as either client or server and will silently ignore inappropriate options for the current type of usage. The choice of client or server behaviour is controlled by the server keyword:
This is a boolean indicating whether the program should run as a client or a server. The default is to run as a client if this key is not specified. The command-line -s option is equivalent to setting this to true.
The following keywords apply only to Zebedee clients:
When running as a client, this is a command that will be spawned to run
connected to the tunnel. If the value contains the character sequence “%d” this will be replaced at run-time with the local port number (see the
localport keyword). As this is done using sprintf the conventions of that routine apply with regards to escaping “%” characters (i.e. use “%%” to generate a single “%”). In addition, specifying more that one “%d” or other format sequence will very likely crash the program.
Note that you can not use automatic command spawning in when a single Zebedee client is handling multiple connections in multiuse mode or when a list of ports has been specified with the localport keyword.
This is the port or list of ports on which the Zebedee client will listen for local connections.
If the client is going to tunnel to a single remote port then then this value may be omitted in which case the port will be assigned automatically (and a message will be printed to the terminal giving the port number).
If a list of ports is given then the number of ports in the list must exactly match that in the list of remote ports, whether specified on the command-line or via the remoteport keyword.
By default a Zebedee client runs in “single-use” mode and exits after the connection to the server has been closed. If this value is true then the client will handle multiple (potentially simultaneous) connection requests and will establish a new tunnel to the server for each one.
The command-line -m option is equivalent to setting this to true.
Any client listening on multiple ports will automatically run in “multi-use” mode, even if this is set false (see localport).
This is the name of the remote host to which a tunnel is to be connected. There is no default and a host name must be specified either in a configuration file or on the command line.
This is the port or list of ports to which Zebedee is to establish tunnels on the remote host. The default if not specified is “telnet” (port 23).
If a list of ports is given then the number of ports in the list must exactly match that in the list of local ports, whether specified on the command-line or via the localport keyword.
The following keywords apply only when running as a server:
This is a list of the ports which the server will redirect. For example “telnet, ftp, 5900-5910”. If no redirect keyword is specified then requests to tunnel traffic to any port will be
accepted. While this is convenient for testing it may pose a security risk
so you should specify an explict list of allowed ports if at all possible.
The keyword (or -r option) may be specified multiple times in which case redirection will be allowed to any of the ports specified.
By default a Zebedee server will redirect all incoming tunnels to ports on the local machine. If this keyword is specified it names the host to which all redirections will be made. This can be useful if the overhead of managing Zebedee tunnels is being offloaded onto a machine that connects to the final destination machine via an otherwise secure network. It can also be useful in tunnelling ftp traffic. See EXAMPLES for more details.
The name of the host to which to redirect traffic may also be specified as a final, optional parameter on the command-line when Zebedee is run in server mode.
The following keywords control the compression and encryption of data passing through the tunnel. They apply to both clients and servers:
Zebedee can support both zlib and, if enabled at compile time, bzip2
compression. This keyword specified the type and level of compression to be
used. The value is of the form type:level where type is either “zlib” or “bzip2” and level is an integer from 0 to 9. As a special case an integer without any prefix
implicitly selects a zlib compression level.
The level specifies the maximum compression level to used (9 is the maximum
and 0 is no compression). The actual compression level used will be the
minimum of the client’s and server’s values. For these purposes all bzip2
levels (except 0) are considered to be greater than all zlib levels so if either client or server does not support bzip2 the protocol degrades gracefully to using zlib. The default compression value is “zlib:6”.
Note that because of the way that bzip2 compression works and the buffer sizes that Zebedee uses bzip will probably only be useful if continuous streams of data are flowing. On smaller transfers, such as those in a normal telnet session, zlib will usually win out. You will have to experiment to see what works best for you. In addition, because the buffer size is small there is no gain from using bzip2 levels above 1 and Zebedee will round any higher values down to this level.
You can see exactly how much compression is gaining you at verbosity levels 2 and above when basic statistics are printed out on connection termination. For example:
zebedee(232/210): read 166 bytes (265 expanded) in 3 messages zebedee(232/210): wrote 20969 bytes (30499 expanded) in 247 messages
This is the “generator” for the Diffie-Hellman key exchange and is a hexadecimal string. The default value is “2”. I recommend that you don’t mess with this unless you know what you are doing.
This is an integer specifying the maximum key length (in bits) for the Blowfish encryption. It should be a multiple of 4 between 4 and 576. The key length used will be the minimum of the client’s and server’s values (subject to any setting of minkeylength). The default is 128. As a special case setting this value to 0 will turn off key negotiation and encryption.
If this key is specified its value is a command string that will be executed in order to generate a private key. The command should write a single line of hexadecimal digits to stdout. This line must be a string of at least 10 hexadecimal digits.
This is an integer between 0 and 2 inclusive that determines how strong the key generation in Zebedee should be. The default is 2 (the strongest) and you should generally not change this unless connection setup performance becomes unacceptable.
Briefly, on UNIX-like systems the level-2 key generation mechanism uses
/dev/random if this is available. However, if too many calls are made against this
device in quick succession the process will block, potentially for several
seconds, while the kernel accumulates sufficient “entropy”. If
/dev/random is unavailable or the level is set to 1 data from the current contents of
the /proc file-system, if there is one, will be used otherwise at level 0 only data
from the current process will be used.
On Windows systems there is currently no distinction between different key generation strength levels and this keyword is effectively ignored.
If supplied this specified the minimum acceptable key length to be used by client or server. If a client requests a lower level of a server the server will reply with this minimum. If a server replies with a lower level to a client then the client will terminate the connection.
The value of this key is a hexadecimal string specifying the modulus value for the Diffie-Hellman key exchange. Don’t alter this unless you are both paranoid and know what you are doing.
The default modulus is the 1024-bit prime:
f488fd584e49dbcd 20b49de49107366b 336c380d451d0f7c 88b31c7c5b2d8ef6 f3c923c043f0a55b 188d8ebb558cb85d 38d334fd7c175743 a31d186cde33212c b52aff3ce1b12940 18118d7c84a70a72 d686c40319c80729 7aca950cd9969fab d00a509b0246d308 3d66a45d419f9c7c bd894b221926baab a25ec355e92f78c7
This was taken from the file testdh.h in Peter Gutman’s CryptLib. The comment in this code says that the value was among those “generated by Colin Plumb for SKIP”. It further says that “these values were chosen as representative well-known public values to allay fears of possible trapdoors in self-generated values. The generation method and actual values can be checked against the SKIP standards document.”
By default Zebedee will generate a new private key for each session. If, however, you wish to use the same key then it can be specified as a string of hexadecimal digits. You will definitely need to do this if you wish to use the identity checking feature. Note that the key must be at least 10 digits long.
The following keywords apply equally to clients and servers:
This names a file that contains a set of identities that will be checked before allowing a connection to be completed. This is described further in the description of identity checking. You may specify only one identity file. If this keyword appears multiple times only the last value will be used.
Note that as of version 1.3.0, if a keylength of zero has been agreed then no identity checking will be performed.
This is a boolean indicating that Zebedee should run in “debug” mode. In this case a server (or client running in multiuse mode) only accepts and handles a single connection at a time and does so “inline” without creating another process or thread. This is useful when running the program under the control of a debugger. It is false by default. The command-line option -D is equivalent to setting this to true.
This is a boolean indicating whether the process should detach itself from the controlling terminal and run in the background (in UNIX terms, to run as a “daemon”). This is valid for both client and server and is true by default. The command-line option -d is equivalent to setting this to false.
Note that this does not always seem to work from an interactive command prompt under Windows systems. The symptom is that output to the console window will stop and interrupt signals will be ignored but the console prompt will not be issued until Zebedee terminates. In order to work around this you can use the “start” command as in the following example:
DOS> start zebedee -f server.zbd
This will start Zebedee in a new console session from which it will then detach. You may see a console window appear briefly before it detaches but Zebedee should be running in the background when it disappears.
This specifies the name of another configuration file to read and parse at this point before continuing with the remainder of the file. It might be used, for example, where a private key is stored in a separate, more tightly protected file. There is a limit of 5 levels deep of include processing (counting the initial configuration file as level 1). This avoids unintentional recursion.
This specifies the size, in bytes, of the buffer Zebedee will use to read data from applications. The actual size of buffer used will be the minimum of the client’s and server’s values.
By default Zebedee attempts to read data from the client or server programs at each end of the tunnel in chunks of 8192 bytes. There may be occasions when you want to decrease this if, for example, you have a highly interactive application and the response seems sluggish because you end up waiting for large data transfers. You can reduce the buffer size to one byte, but unless you are trying to debug misbehaviour or have time to waste I don’t recommend it! Conversely, you may increase the buffer size up to a maximum of 16383 bytes to attempt to gain the most from data compression where large blocks of data are being transferred. Note that the maxbufsize value does not affect how much memory is allocated by Zebedee, only the size of data chunks read.
The specifies a string that will be logged at verbosity level 1 when it is encountered in the configuration file.
This is the name of the program that is to be used in messages rather than the executable file name. Under Windows it is also the name of any service to be installed or removed.
This is the name of the file to which messages will be written. If it is not specified then messages are written to stderr.
Two special “file names” are also recognised as valid values. If the name is NULL the all messages will be turned off. If the name is SYSLOG then messages will be written to the host system log. On Windows systems this is the system application event log. Elsewhere messages are written to the syslog service.
This is the port on which the Zebedee server will listen for connections. The default is 11965 (0x2EBD). It causes a server to listen on this port and a client to attempt to connect to this port on the remote system.
This is a boolean value indicating whether log messages should contain a time-stamp. The default is not to do so. The command-line option -t is equivalent to setting this to true.
This is an integer specifying the level of message logging with 0 being just error messages and 5 giving excruciating detail of the message traffic. The default (and generally most useful level) is 1.
Messages are written to stderr (unless redirected using the -o command-line option or logfile keyword). The general form of messages is something like:
zebedee(54/119): Listening on local port 1172
The numbers in brackets represent the process and thread identifiers of the
code logging the message. All error messages are logged at level 0 and are
preceded by the word ERROR, as follows:
zebedee(54/119): ERROR: failed to connect to localhost:11965
Messages are indented according to the level at which they are logged.
There are a few command-line options that have no equivalent in the configuration file. These are described below.
This causes Zebedee to generate a private key value and to write it to standard output in a form that can be used in a configuration file. For example:
privatekey "c480bd48f707c69dec54c9e7b6e22dd04cac659e"
This causes Zebedee to generate a public “identity” suitable for use by the identity checking feature. The result is written to standard output. For example:
ef8153a0e392df005f67321ca2f0ace5bb8c5a1f myhostname
This option must either be specified with a configuration file that contains a private key value or must be used in conjunction with -p to generate private and public keys simultaneously.
This option causes the remaining command-line arguments to be treated as
the names of files. Each file is read in 8192 byte chunks and the SHA hash
is calculated. If no arguments are specified or the argument is “-” then the standard input is read and the hash of that is calculated. For
example:
$ zebedee -h /etc/passwd bb1e734aeffd2111417761f5938dea3b53759598 /etc/passwd $ zebedee -h < /etc/passwd bb1e734aeffd2111417761f5938dea3b53759598 -
This is similar to the -h option except that each argument is treated as a literal string and the SHA hash of the string is calculated and printed:
$ zebedee -H hello world ac62a630ca850b4ea07eda664eaecf9480843152 hello 86bf25ecb8a40b40b885c097c683b6e236fc8085 world
On Windows systems Zebedee can be installed and run as a “service” — an independently running process that is started automatically at system boot time.
Zebedee can be installed as a service by specifying the install parameter with the name of a configuration file, for example:
zebedee -Sinstall=c:\zebedee\service.zbd
You should always specify the full path to the configuration file. This will be read at service start-up and must contain all the parameters required for the service to run.
By default, the name of the installed service will be taken from the name of the program file, and hence is usually zebedee, but you can change this by using the -n option:
zebedee -n "Zebedee Client Service" -Sinstall=c:\zebedee\clientsvc.zbd
Once the service has been installed it will be automatically started the next time that the system reboots. Alternatively you can start it manually using the Service Control Panel (under Windows NT).
To remove the service specify first stop it and then use the remove parameter to the -S option, along with any necessary service name using -n. For example:
zebedee -n "Zebedee Client Service" -Sremove
There is one further valid parameter to the -S option and this is run. This is used internally by Zebedee to invoke the service start-up code and should not be used directly.
This option can be used to set those configuration parameters that do not have any other direct command-line equivalent. It takes a string as an argument and this string is treated as if it were a line read from a configuration files (including comments but without “\” line continuation). So, for example:
zebedee -x " server true # It’s a server!"
is a rather perverse way of achieving the same effect as:
zebedee -s
By default Zebedee just establishes an encrypted channel between two points. While you know that the data is protected from snooping “on the wire” there is no guarantee that the channel ends up where you think it does. It is open to “man-in-the-middle” attacks. If you are concerned primarily with using data compression or protecting against casual “network sniffing” then you may be happy with this situation. If, however, you want more assurance that your connection is not being redirected then Zebedee provides some basic facilities for doing so.
If the same modulus, generator and private key are used they will always generate the same public value for use in the Diffie-Hellman key exchange protocol. If you use a fixed private key (specified using the privatekey) keyword in a configuration file) then Zebedee can generate a key “fingerprint” by hashing together the modulus, generator and public key value. This is done using the -P option, for example, if the file server.key contains the following value:
privatekey "1e34d6769502bae1087c18d2e8c8776e4a17ddaf"
then the command
$ zebedee -P -f server.key > server.id
will generate output something like this:
135f04050961d37553731250d5c6f7495f088b32 myhostname
The initial string of hexadecimal digits is the “fingerprint”. Anything else on the line is a comment describing the owner of the identity. By default it is the name of the host on which the identity string was generated.
If the checkidfile keyword is specified in a configuration file then its value is the name of a file containing “fingerprint” lines. If the identity of the system at the other end of the connection does not match any of those in the file then the connection will be closed.
In keeping with the desire to keep the protocol overhead as low as
possible,
Zebedee does not perform any data integrity validation on the transmitted data
stream. It is, therefore, possible for an attacker to alter data packets in
transit. The encryption used should make it extremely hard for them to
transform them arbitrarily at will — for example turning “ls -l” into “rm -f” — but do not depend on Zebedee to protect your application from the effects of being fed random data!
One possible attack on many networked systems is that of capturing data streams that have a known effect — for example, a telnet session during which an administrator was known to be performing certain “dangerous” actions — and then replaying it at some later time. This does not require cracking the encrypted data stream itself, merely knowing that the same network packets sent to a server will elicit the same response.
When Zebedee is operating in “anonymous” mode the risk of such an attack being successful is low because different keys will be generated and used for every session. However, if the identity checking features are used the keys will be fixed and replay is a real possibility. For this reason the final part of the connection setup involves a challenge-response exchange that verifies that the system at the other end of the connection really knows the shared secret key and is not just parrotting back previously recorded data.
In addition, Zebedee uses Blowfish encryption in “cipher feedback” mode which means that decryption of any part of the data depends upon successful decryption of all the data packets that have gone before it. The challenge-response exchange “salts” the data-stream so even if the protocol being tunnelled is determined a “known plain-text” attack is made more difficult.
A poorly-chosen key can compromise even the strongest encryption mechanism. When generating keys Zebedee attempts to gather as much hard-to-guess state data as possible and then “stir” it using the SHA hashing algorithm. On modern UNIX systems this generation process should give pretty good keys.
On Windows the available state data is somewhat more predictable, particularly if an attacker has access to the system. Having said that, it should be quite acceptable for most purposes. The comments in the code explain this in more detail if you are interested.
If you are unhappy with the key generation mechanisms then you should call out to an external key generation program using the keygencommand option in a configuration file. Suggestions for improving the built-in capabilities will also be gratefully received!
Although Zebedee should work “out of the box” you might encounter some problems. These are most likely during connection setup — once that has been accomplished the data transfer generally goes smoothly. The eaisest way to see what is happening during the setup process is to use the -v option. You will usually want to combine this with the -d and -D options to stop Zebedee from the terminal and to force it to handle only a single connection at a time. So, for example, you might use the following command to start up a server:
zebedee -dD -v 3 -s
Setting the logging level to 3 should show you the main exchanges during connection setup. If you believe there is a problem after this then levels 4 and 5 will show you what message traffic is being exchanged.
In the Zebedee distribution there are a number of example configuration files. The following sections describe how they can be used as well as how to use Zebedee to tunnel some specific protocols.
There is an example server configuration file (server.zbd) shipped with the Zebedee distribution. This shows most of the common options.
# # Default Zebedee server configuration file #
verbosity 1
server true # Yes, it’s a server! detached true # Run detached from terminal
# Uncomment the following line to log messages to a file # # logfile ’./server.log’
# Uncomment the following line if you want to use a fixed private # key stored in a static file. # # include ’./server.key’
# Set up allowed redirection ports. # These should be pretty safe -- but it’s not a good idea # to open up all ports.
redirect "telnet ftp" # Basic services redirect 5900-5999 # VNC traffic redirect 6000-6010 # X Window System redirect "daytime chargen" # Ports useful for testing
compression zlib:9 # Allow maximum zlib compression keylength 256 # Allow keys up to 256 bits maxbufsize 16383 # Allow maximum possible buffer size
One of the reasons behind writing Zebedee was to use it over dial-up lines with VNC. VNC is a free system to provide remote display capabilities using a “remote frame-buffer” concept. You can use it to display Windows desktops remotely or, with an “Xvnc” server to access an “X desktop” from any VNC client machine, or even a Java-enabled browser! See http://www.uk.research.att.com/vnc/ for more details.
The supplied sample server configuration file server.zbd is configured to allow redirection of ports 5900-5999 which will allow tunnelling of VNC sessions. This file can be used on both UNIX and Windows but note that on Windows you must set the “AllowLoopback” flag in the registry in order for tunnelling to work. Saving the following snippet (without any leading spaces) in file a and then importing it into regedit will do the trick:
REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3] "AllowLoopback"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3\Default]
You will find a file with these contents in the Zebedee distribution by the name vncloopback.reg. Having set these registry entries then the file vncviewer.zbd can be used to invoke a VNC viewer tunnelled to the host named on the command line. By default it will tunnel to ther server on port 5900 (the WinVNC default) but you can override this by specifying that on the command line too. Here are the contents of the file vncviewer.zbd:
#
# Zebedee configuration file to start up a tunnelled VNC session
#
# Usage: zebedee -f vncviewer.zbd remote-host[:vnc-port]
#
verbosity 1 # Basic messages only
server false # It’s a client
detached true # Detach from terminal
message "Starting VNC viewer on localhost:99"
# On Windows systems you might use the following:
command ’"c:\Program Files\ORL\VNC\vncviewer.exe" localhost:99’
# On UNIX systems you might use the following:
# command ’vncviewer localhost:99’
remoteport 5900 # Remote VNC server on port 5900 unless overridden
# by a value specified on the command-line
localport 5999 # Local connection on 5999 -- i.e. localhost:99 compression 6 # Request normal compression
So using this file as follows:
zebedee -f vncviewer.zbd somehost:5901
will start a VNC viewer tunnelled to the VNC server on somehost port 5901 (the server you would usually refer to in VNC-parlance as “somehost:1”). The viewer is connected to the local port 5999.
VNC also supports a Java viewer. If the server is running on port 59xx then the viewer can be downloaded via port 58xx. However, it appears that the Java viewer communicates the main VNC port number to the client. So, to tunnel traffic when using the Java viewer you must make sure that the local and remote ports use the same numbers. So, for example, to tunnel traffic to a VNC server using port 5901 you should do something like:
zebedee 5801,5901:remotehost:5801,5901
This will be problematic if you already have a VNC server running locally on port 5901, but you can usually arrange local and remote VNC servers so that there is no clash.
There is one last point worth mentioning. If you are using compression with VNC it is worth experimenting a bit with the VNC protocol encoding. I have found that “raw” encoding often compresses best and sometimes gives better performance with Zebedee over slow links. But, as they say, your mileage may vary!
The X Window System uses ports in the range 6000 onwards.
Let’s assume that your local machine called xlocal is running an X server on port 6000. This would be the port normally used by the display known as xlocal:0. You now want to send a secure xterm session back to your local display from a machine called xremote. To do this you might run the following command on xlocal:
zebedee -r 6000 -s
Then on xremote you could run:
zebedee -e "xterm -display localhost:1" 6001:xlocal:6000
Note that in order for this to work correctly you must add an entry for localhost to the access control list for the X server in xremote. You can do this by running the following command:
xhost +localhost
Zebedee can be used to secure all traffic to a Web server by using the client in “multi-use” mode. So, for example, if a Web server is running on the machine webhost on port 80 and it is also running a Zebedee server then the command:
zebedee -m 8000:webhost:80
will set up a tunnel via port 8000 on the local host. Now any URLs that previously were addressed via webhost, for example:
http://webhost/private/index.html
can now be accessed securely as follows:
http://localhost:8000/private/index.html
You could redirect all HTTP traffic via the secure tunnel by setting “localhost:8000” as your proxy. Be careful, however, only to set this as the proxy for
HTTP connections — other protocols (including Secure HTTP) should be
directed elsewhere. It is also possible to configure most browsers to use
different proxies for different domains and so secure connections
selectively. Consult your browser’s documentation for details on how to do
this.
It is possible to protect the FTP control connection (over which the username and password are sent) for many FTP servers using Zebedee “out of the box” by following the instructions below. It is also possible to protect the control connection for other servers and even “passive-mode” data connections by using Zebedee in conjunction with the ftpgw.tcl script in the Zebedee distribution.
The simplest approach, which works with some FTP servers, is to run the Zebedee server as follows:
zebedee -s -r ftp ftpserverhost
Note that even if you are running Zebedee on the same machine as the FTP server you should explictly name it on the command line (or using the redirecthost keyword). Do not refer to it as localhost. On the client system you could then run Zebedee as follows to set up a multi-use tunnel via port 10000:
zebedee -m 10000:ftpserverhost:ftp
To connect to the FTP server you would then use a command like:
ftp clienthost 10000
Again, use the local client host name not, localhost. If your FTP client does not support specifying the port on the command
line, as is the case with the standard Windows FTP client program, you may
be able to use the command “open clienthost 10000” from within the program. If you are not running an FTP server on the
client machine you could also try running Zebedee as:
zebedee -m ftp:ftpserverhost:ftp
and then just invoking the FTP client program as:
ftp clienthost
The approach just described will work for FTP servers that do not check that the FTP control and data connections appear to come from the same source. However, some servers such as the widely-used wu-ftpd are more strict about this — for good security reasons. If you can apparently establish a connection to the server but directory listing and file retrievals fail or hang then it is likely that your server is one of the strict ones.
To help overcome this problem there is an “FTP gateway” script in the Zebedee distribution called ftpgw.tcl. This is a program, written using the freely-available Tcl scripting language (see http://www.scriptics.com) that intercepts FTP requests and re-writes them so that a server is shielded from the presence of Zebedee. You should run this on the same system as the Zebedee server. Assuming that the FTP server is also running on the same system you can just run this as:
tclsh ftpgw.tcl
This will start the gateway listening on port 2121. Obviously, in real usage you will probably want to start this in the background. You then start the Zebedee server as:
zebedee -s -r 2121
Note that in this case you do not have to specify the local host name, although you may do so if you wish. On the client side you can now run:
zebedee -m 2121:ftpserverhost:2121
followed by:
ftp clienthost 2121
You must still, however, use the client host name here.
This configuration will allow you to tunnel the FTP control connection but will not affect any data connections. Using ftpgw.tcl it is, however, also possible to secure the data channels provided that your FTP client can operate in “passive” mode. Examples of clients that can do this are Netscape Navigator and the Windows program WS_FTP.
To secure passive-mode data connections you must choose a range of ports on the server that will be used for data connections. In this example we will use 30000 to 30100. You then start ftpgw.tcl with the -p option to specify this port range:
tclsh ftpgw.tcl -p 30000-30100
The Zebedee server would then be started as:
zebedee -s -r 2121,30000-30100
and the client as
zebedee 2121,30000-30100:ftpserverhost:2121,30000-30100
To access the server with both control and data connections secured using Netscape you would then supply a URL of the form:
ftp://username@clienthost:2121/
where username is your user-name on the FTP server host.
The following information can also be found in the file LICENCE.txt in the Zebedee distribution.
Copyright (c) 1999, 2000 by Neil Winton. All Rights Reserved.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
A copy of the GNU General Public License can be found in the file GPL2.txt.
You may obtain the latest copy of Zebedee, including full source code from http://www.winton.org.uk/zebedee/ and other enquiries about Zebedee can be e-mailed to the author at zebedee@winton.org.uk
Zebedee would not have been possible without the use of a large amount of freely-available software to do all the really hard stuff. I gratefully acknowledge the contributions made by the authors of the following software packages.
Zebedee uses the “Blowfish” encryption algorithm devised by Bruce Schneier. For more information on Blowfish see http://www.counterpane.com/blowfish.html . The implementation used is by Eric Young and is covered by the following copyright:
Copyright (C) 1995-1997 Eric Young (eay@mincom.oz.au) All rights reserved. This package is an Blowfish implementation written by Eric Young (eay@mincom.oz.au). This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution. Copyright remains Eric Young’s, and as such any Copyright notices in the code are not to be removed. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Eric Young (eay@mincom.oz.au) THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The license and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distrubution license [including the GNU Public License.] The reason behind this being stated in this direct manner is past experience in code simply being copied and the attribution removed from it and then being distributed as part of other packages. This implementation was a non-trivial and unpaid effort.
Zebedee uses the zlib compression library by Jean-loup Gailly and Mark Adler. It is covered by the following copyright notice:
(C) 1995-1998 Jean-loup Gailly and Mark Adler
This software is provided ’as-is’, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler jloup@gzip.org madler@alumni.caltech.edu
Zebedee may use the bzip2 compression library by Julian Seward which is covered by the following licence:
This program, "bzip2" and associated library "libbzip2", are
copyright (C) 1996-1999 Julian R Seward. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
3. Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.
4. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Julian Seward, Cambridge, UK.
jseward@acm.org
bzip2/libbzip2 version 0.9.5 of 24 May 1999
Zebedee uses the GNU MP library. This is covered by the GNU Library General Public License a copy of which can be found in the file LGPL2.txt. The copyright is as follows:
Copyright (C) 1991, 1993, 1994, 1996 Free Software Foundation, Inc. The GNU MP Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU MP Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU MP Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Zebedee uses the Secure Hash Algorith (SHA) the code for which was derived from Uwe Hollerbach’s SHA module for perl. The code contains the following statement:
NIST Secure Hash Algorithm heavily modified by Uwe Hollerbach <uh@alumni.caltech edu> from Peter C. Gutmann’s implementation as found in Applied Cryptography by Bruce Schneier
This code is in the public domain
Under Windows, Zebedee uses an implementation of the getopt function covered by the following copyright:
Copyright (c) 1987, 1993, 1994
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS” AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
Special thanks go to those people who have taken the trouble to give me feedback and suggestions for improvement!
$Id: zebedee.pod,v 1.9 2000/01/21 21:39:33 nwinton Exp nwinton $