RE: Port funnels?

["Stout, Bill" <StoutB () pioneer-standard com>]

Thanks for the direct replies.  I should've mentioned inetd and portmapper
on my original post.  I may have my moments, but alzheimers is many decades
off yet.

In one situation I have an ERP application (JDEdwards) which has a heavy
Windows client app.  I'd like to use simple port filtering on a semi-private
net to limit ports accessed on the server.  I've also looked at adding
TriStrata (startup of John Atalla) software, which builds application-level
security software (VPN, user management, auditing, logging, group management
delegation, etc).  However the TriStrata software only secures direct
application access, and nothing else.

So, if there were an application-level 'funnel', which intercepts internal
calls to specific ports, listens to incoming traffic from inetd, and funnels
that to one port pair (all the while keeping track of proper sessions), now
that would be useful.  Essentially this would be a built-in application
gateway doing port-level NAT through software. Much easier to filter all
these non-firewall friendly applications.  Sounds odd, but my Packet
Throtting post did too.

Bill Stout
_____   
'Backofficer friendly' alternate names: 
'Butt Armour', 'Steel Shorts', 'Chastity belt', 'Rear guard', and 'The
Plug'.
;^)

                -----Original Message-----
                From:   davidg () genmagic com [SMTP:davidg () genmagic com]
                Sent:   Tuesday, April 13, 1999 4:22 PM
                To:     Stout, Bill; firewall-wizards () nfr net
                Subject:        Re: Port funnels?

                On 12 Apr 99, at 12:42, Stout, Bill wrote:

                > I'm looking for a server utility that would funnel
application ports
                > onto one port number pair.  Any exist?  This would greatly
simplify
                > remote access to applications. 
                > 
                > I'm rather unclear on why application vendors do only
define the
                > inbound port, and then use random (or simply different)
ports to
                > reply.  I may have missed that day of lecture. 

                  Suppose that on host A, we want to open two connections to
the same 
                service on host B (perhaps these are telnet sessions for two
different 
                users, or perhaps our web browser uses multiple sessions to
grab 
                graphics, or ...).  There's no gain in forcing these
connections to use 
                the same port at our end -- and how do we discriminate which
responding 
                traffic belongs to which session????[*]
                  The service daemon (or whatever) on host B will find out,
from our 
                connection requests, what port numbers to send responses to.

                  In general, having the protocol specify an originating
port number 
                (usually the same as the destination...) makes sense only
when the 
                protocol is connectionless (UDP...) AND no host is both a
client and a 
                server for this protocol.  [A host which is only a client
might choose 
                to use the same address for both, but a server cannot
require that 
                unless the protocol meets this condition.]

                [*] This looks like we've got both sessions going to the
same port 
                number at host B, but typically it is only the connection
request that 
                goes to this port; a new port is allocated for the session,
and its 
                number is returned to the client for use throughout the rest
of the 
                connection.

                  Going back to your original question, it sounds like you
want to run 
                a bunch of different protocols over top of some single
protocol; this 
                is commonly done with, for example, PPTP and (far too
often!) HTTP.  
                From a firewall perspective, though, this is as much a
*problem* as a 
                solution.  Do you have a problem that this would solve?
Maybe there's 
                a better (or at least, more secure) solution....


                David G