Jose M. Sanchez <[EMAIL PROTECTED]> wrote:
>
> This indicates that the module is indeed "doing something" with the
> inbound packets (where my problem is), what I need to do is to turn on
> debugging and watch what is actually occuring...
Well, the hacker way to do it would be to simply comment out the code
that watches for 'PASV' responses, so that the module will no longer try
to do anything.
> > * Look at incoming ftp packets to catch the response to a PASV
> > * command. When we see one we build a masquerading entry for
> > * the client address, client port 0 (unknown at the moment),
> > * the server address and the server port. Mark the current
> > * masquerade entry as a control channel and point the new entry
> > * at the control entry. All this work just for ftp keepalive
> > * across masquerading.
After analyzing this further, I believe this is simply building an
association between the command channel (on port 21) and the data
channel (on the specified port). One problem with masquerade is that
during a long ftp transfer, the command channel has no traffic, and can
get timed out by the masq box. By associating the command channel with
the data channel, the command channel is kept active and won't be timed
out. I don't think this code does anything further to the traffic. But
it would be interested to find out.
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut
sometimes known as David DeSimone || butter quite like unrequited love."
http://www.dallas.net/~fox/ || -- Charlie Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
