[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log
Subject:    $TCPLOCALPORT and linux 2.2/ipchains
From:       "Michael J.Pomraning" <mjp-log () securepipe ! com>
Date:       2003-04-18 13:32:03
[Download RAW message or body]

This is just a quick note detailing a peculiarity of linux 2.2 and ipchains
REDIRECTion (transparent proxying) as encountered by tcpserver.  A co-worker
of mine came across the behavior, and I thought some readers of this list
might be interested.

If tcpserver is the target of an ipchains redirection, the semantics of the
ucspi-tcp "LOCAL" variables change a little bit.  TCPLOCALIP records the
/intended/ destination IP (that is, the address the client thinks it is
connected to).  TCPLOCALPORT, however, holds the original tcpserver bind port,
rather than the intended destination port.

The reason for this is that tcpserver updates TCPLOCALIP after forking, using
values from socket_local4() (getsockname) on the newly accepted socket, but
does not similarly update TCPLOCALPORT.

Again, this is only an issue under 2.2 and chains redirection -- the
getsockname semantics are (much more sensibly, IMHO) moved to a socket option
under 2.4.  Additionally, any redirected, tcpserver'd program can simply
getsockname(0, ...) to figure out the client's intended target.

However, if you enjoy the irony of "LOCAL" variables (local address
structures, really) holding remote values, this is the patch for you:

--- ucspi-tcp-0.88/tcpserver.c.orig     Tue Mar 18 12:06:28 2003
+++ ucspi-tcp-0.88/tcpserver.c  Tue Mar 18 12:06:59 2003
@@ -159,6 +159,7 @@
     strerr_die2sys(111,DROP,"unable to get local address: ");

   localipstr[ip4_fmt(localipstr,localip)] = 0;
+  localportstr[fmt_ulong(localportstr,localport)] = 0;
   remoteportstr[fmt_ulong(remoteportstr,remoteport)] = 0;

   if (!localhost)

Regards,
Mike
--
Michael J. Pomraning
SecurePipe, Inc. -- Managed Internet Security
[prev in list] [next in list] [prev in thread] [next in thread]