Wiki Home

Ze Be Dee


Namespace: SoftwareEng
Zebedee is a combined secure tunnel client / server available under a modified GPL2, and published by Neal Winton. The home page for Zebedee can normally be found at http://www.winton.org.uk/zebedee/ -- there is also a Zebedee project page you can search for at http://www.sourceforge.net/, where you will also find 2 Zebedee mailing lists (both extremely low-volume), Zebedee-Announce and Zebedee-Talk. The manual for Zebedee is extremely thorough and detailed; even a secure tunnel beginner can learn everything needed from the Zebedee manual -- but it may take you several readings.

The key concept to grasp is that Zebedee is interested in 4 distinct hosts, not just 2. In the most common configuration, it happens that the secure tunnel server and the target host are the same machine, and the secure tunnel client and the originating host are the same machine. Don't assume this is necessarily the case, however.

Unless you use the LOCALSOURCE TRUE option on the client piece, anyone on the same network as the secure tunnel client who knows the correct port number can use the secure tunnel; when they do so, the leg of that connection which runs from the originating host to the secure tunnel client would be unencrypted.

Similarly, unless you specify LOCALHOST (followed by ":" and a port number or service name) as the only target in the server's configuration file, it will be possible for the client to open tunnels which deliver traffic to other machines on the same network as the secure tunnel server. That may in some cases be desirable, if for example you want to use Zebedee for encrypted connections to the VNC server on any machine on your home network. However, there are 3 issues to be aware of: The most important is that traffic leaves the encrypted tunnel when it arrives at the secure tunnel server - the leg of the connection which runs from the secure tunnel server to the target host is unencrypted. You must also bear in mind that the traffic appears to originate with the secure tunnel server, which in this case is not necessarily the target host; if you're setting up VNC, you must not use LoopbackOnly except on the PC hosting the secure tunnel server. Finally, there is a bug in Zebedee 2.4.1, which is that all DNS resolution takes place on the secure tunnel client; consequently, unless the secure tunnel client has access to the internal DNS server on the network to which the secure tunnel server is providing access, you cannot use hostnames to specify the target host -- only an actual IP address. There are workarounds for the DNS lookup bug, some theoretical and others tested; see William Hazelrig's post to Zebedee-Talk on this subject in the archives for that list (look it up on http://www.sourceforge.net/).

What Zebedee really does is establish on demand an encrypted tunnel between a particular port on the secure tunnel client and a particular port on the secure tunnel server; while the tunnel is active, all data sent to the indicated port on the secure tunnel client is delivered to the indicated port on the secure tunnel server, as if it had originated at another port on the same host (i.e. on the secure tunnel server). That fact is why you need to enable Loopback connections on the VNC server, if you plan to use Zebedee to secure the connection.

Finally, for the really ambitious, there is a way to do end-to-end encryption between hosts which cannot directly see each other, in most circumstances. Zebedee itself uses port 11965/TCP to listen for incoming connections; this port number can be overridden with the -T command-line option or the SERVERPORT configuration file keyword. If hosts B and C can see each other, hosts A and B can see each other, and hosts C and D can see each other -- but A cannot see C or D, and D cannot see A or B, you can set up the following:

1) With host B as the secure tunnel client and host C as the secure tunnel server, set up a tunnel without encryption (KEYLENGTH 0 and MINKEYLENGTH 0) and without compression (COMPRESSION 0), with the target specified as host C's port 11965/TCP, and the server port specified as, say, 12965 (this is an arbitrary number - pick one that doesn't conflict with applications you use). This will permit PCs on the LAN shared by hosts A and B to connect to the secure tunnel server on host C using port 12965 on host B.

2) Set up a tunnel without encryption and without compression from port 12965/TCP on host A to port 11965/TCP on host D. To do this, use host A as the secure tunnel client and port 12965 on host B as the secure tunnel server -- this is actually host C, which can now be reached by host A using the port-forwarding we set up in step 1.

3) Now, port 12965 on host A is port-forwarded to port 11965 on host D. To set up the end-to-end-encrypted tunnel, use host A as the secure tunnel client, and specify host A's port 12965 as the secure tunnel server (i.e.: host A thinks it is also the server, but use SERVERPORT 12965 to make sure the forwarded port is used to negotiate the Zebedee connection). For this tunnel, do lock down who can send and what targets are permitted. On host A, use the LOCALSOURCE TRUE option to lock out other hosts on the same LAN as host A. On host D, specify as allowed targets only LOCALHOST:11965/TCP, and LOCALHOST:5900/TCP (for default VNC server port). Be sure to use KEYLENGTH 128 (or better) in the client configuration for this tunnel on host A.

If there is only one or are only a few "non-visible" hosts on the network shared by hosts C and D, you can simplify this by combining steps 1 and 2. Instead of establishing the tunnel from host B's port 12965 to host C's port 11965, establish it from host B's port 12965 directly to host D's port 11965. Do the same (using a different port on host B for each) for hosts E, F, and G on host C's LAN.

The solution above is a generalized approach, intended for establishing connections between two very large LANs. If hosts B and C are sufficiently powerful to handle encryption for all connections simultaneously, it would be worthwhile to consider enabling encryption on the first tunnel set up -- not because you need to encrypt it for privacy, but because encryption is a prerequisite for using Zebedee's identity-checking feature. This would permit you to insure that only host B was taking advantage of that nice "connect to Zebedee's secure tunnel request port on every host on host C's LAN" feature. If you choose not to use this approach, be aware that IP spoofing is quite possible, so potentially anyone at all who can see either host B or host C could create an encrypted tunnel to host D (or any other host on host C's LAN), and access whatever services host D was configured to allow encrypted tunnel connections to.

If you can't enforce identity-checking between hosts B and C, and you can't secure that connection some other way, then you must either enforce identity-checking on every host on host C's LAN - and be sure the private keys are kept secure for users on host B's LAN - or else be sure the services to which those tunnels can connect are either totally inoccuous, or require strong passwords (and that those passwords are kept secure for users on host B's LAN...).

Finally, host C should either be purely a tunnel-relay platform (no connections other than to port 11965 permitted) or should be running 2 copies of Zebedee -- one for the unencrypted tunnels to port 11965, and one for encrypted tunnels to permit connections to host C itself. Since they can't run on the same port, you'll need to use the SERVERPORT configuration file keyword for one of those; the logical choice is the one that does the unencrpyted connections -- in which case you'll need to use that same SERVERPORT for any connections relying on host C's secure tunnel server, above. If you don't do this with host C, it will be possible for a misconfigured secure tunnel client to open an unencrypted connection to the ports on host C that you're trying to make available to encrypted connections; the person then using that unencrypted connection will not have any way to know (other than reading your instructions and configuring the tunnel correctly to begin with!) that the connection is unencrypted.
Category Web Tools
( Topic last updated: 2006.01.26 08:27:42 AM )