Re: Interesting Telnet scenario

["Paul D. Robertson" <proberts () clark net>]

On Wed, 8 Sep 1999, Bowden, Kevin wrote:

> I have a requirement for clients in my network to Telnet to a server outside
> the network for password changing on the remote server.  (This is an
> application password and is for that particular server, it is not their
> network password.)  The requirements of the Telnet session are that the
> SOURCE PORT of the Telnet session be a given port (XXXXX).  How can I make

That's a bad requirement considering your users are behind a proxy-based 
firewall that can only have one connection at a time to a particular host 
from a single source port.  You should *really* talk to the application 
designer and have them fix it so that connections from the outside interface 
of your firewall are valid.

> this work through Gauntlet?  If I use the proxy, I cannot control the source
> port of the session.  If I use a packet filter (forward w/ replies) I reveal
> internal address numbers.  I think if I use packet filters with the absorb
> option I will still lose the mandatory source port as the proxy will again
> take over.  I thought of having the users telnet to an intermediate server
> or the firewall and then connect to the remote server, but how can I force
> this Telnet session to use a particular source port manually - I know I can
> tell it to use a particular destination port, but a source port?  Please

You can change the source of tn-gw (or plug-gw) from the Firewall Toolkit 
(since NAI has chosen to spray paint all over what was once the crystal box of 
Gauntlet) to bind to a particular sorce port and use that.  However, if 2 
users attempt to run the new code at the same time, it will fail for the 
second user because the socket pair would be the same as the first 
connection - that would make it pretty easy for a user to provide a 
Denial of Service attack by simply telnetting and waiting for the 
connection to timeout.  This may be acceptable as a short-term solution 
though, depending on your environment.

> feel free to correct any bad assumptions above or to provide "Basic
> Training" if it is appropriate.  TIA!   (Solaris 2.6 / Gauntlet 5.0)

The bad assumption was on the part of the application designer, who will 
have problems with multi-user Operating Systems (I assume this will include 
Windows Terminal Server even if they ship a little application themselves.)  
You *really* should insist that the application be fixed- especially if 
it's working as designed.

You might be able to use NAT on a device external to the firewall to re-map 
the outbound telnets, but once again you're going to have multi-user 
issues unless you can remap to a new source IP for each connection and 
have enough available external addresses to support this.

Another option, which might be better for your users- is to write a CGI 
that does the password change and put this on an external Web server.  
You could then handle serializing the password requests.  Depending on 
where the source port is in the range of ports, you could have a 
password-changing daemon keep the socket bound to reserve it.

If you haven't written socket programs before, and can't find someone 
local with a clue, pick up a copy of the recently deceased [:(] W. Richard 
Stevens' Unix Network Programming, 2nd Ed.  Unless you've never seen a C
compiler before you should have the framework for something useable 
inside an hour or two.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280