From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: rec.games.netrek
Subject: trekhopd v1.4 (RSA update)
Date: 11 Nov 92 22:56:05 GMT
Reply-To: fadden@amdahl.uts.amdahl.com (Andy McFadden)
Organization: Amdahl Corporation, Sunnyvale CA

trekhopd v1.4 is now up on charon.amdahl.com (pub/netrek/thd1.4.tar.Z).

Big change is that it now correctly supports RSA v2.0.  If you're playing
through gw, forget it, it won't work with RSA.  Neither will the old version
of trekhopd.


If you haven't heard of trekhopd, here's a piece of the README:

-----
trekhopd v1.4 - Netrek firewall hop daemon
By Andy McFadden (fadden@uts.amdahl.com)
Updated: 11-Nov-92


OVERVIEW:

"trekhopd" (Trek Hop Dee) is a daemon process intended to run on an Internet
firewall machine.  It will pass TCP and UDP packets from a modified netrek
client from a host on the inside to a server on the outside.

This program was developed as an alternative to "gw", a general-purpose
firewall bridge.  trekhopd has several advantages:

- works with RSA v2.0 servers.

- the server host and local UDP port are specified by the Netrek client at
  execution time, and may optionally be checked against a list of "approved"
  server hosts & ports.  "gw" had one port for every possible server, and
  listened to them all; the client was required to attach to the right port
  on the server machine.  This is no longer necessary.

- local networks (or local hosts) can be specified.  By setting some variables
  in the configuration file, you can block connections from machines outside
  the network.  Connections TO machines on the listed local networks are
  always forbidden unless the host is specifically listed on the "approved"
  list.

- the UDP ports aren't opened until they're needed; "gw" used two file
  descriptors per UDP port whether they were in use or not.  Also, the
  UDP ports on the firewall machine are allocated dynamically, instead of
  being specified in the configuration file (they're passed back to the
  client after the connection is established).

- since this is a specific-purpose tool, the risk to the company from users
  doing stupid things is minimized.  It was possible to route data from
  outside the company back in under "gw".  With trekhopd, the configuration
  is done only once, by the sysadmin (or at least someone with a clue).

- because it's a daemon, it runs all the time, so you don't need somebody
  to start it up (ask your sysadmin to add it to the rc scripts).  In general,
  the people using it don't need accounts on the firewall machine.

- trekhopd uses non-blocking connect() calls, so you won't get stalled
  whenever someone else makes a new connection (especially important for
  connections to machines which are down).

- it's easier to adapt XNetrekM to work with trekhopd.

The primary disadvantage of trekhopd is that it requires a slightly modified
client (need a tweak in socket.c).  The server host, server port, and the UDP
port must be sent immediately after opening the TCP connection; if the data
is invalid the connection is dropped before any outside connections are
made.
-----


trekhopd was designed to make my sysadmin happy (he wasn't too thrilled with
"gw"), and if you present it to yours the right way, he'll probably be
happy too.  There are enough security features to prevent both deliberate
break-ins and administrative screw-ups.  And, since it can be run as a daemon,
it can be under the direct and exclusive control of the administrators.

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Organization: Carnegie Mellon, Pittsburgh, PA