[BUG] ip_nat_ftp fails for some ftp servers (fwd)
Xuan Baldauf
xuan--lkml@baldauf.org
Sun, 07 Oct 2001 15:23:06 +0200
--------------00FD175982DCFDA5FF6FE916
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Martin Josefsson wrote:
> I forwarded your mail and ny response to the netfilter-devel list and g=
ot
> this response.
>
> /Martin
>
> Never argue with an idiot. They drag you down to their level, then beat=
you with experience.
>
> ---------- Forwarded message ----------
> Date: Sun, 7 Oct 2001 13:42:41 +0200
> From: Svenning S=F8rensen <sss@sss.dnsalias.net>
> To: Martin Josefsson <gandalf@wlug.westbo.se>, netfilter-devel@lists.sa=
mba.org
> Subject: RE: [BUG] ip_nat_ftp fails for some ftp servers (fwd)
>
> > I can confirm that I can't list the contents of ftp://ftp.tu-chemnitz=
=2Ede/
> > when using active mode and sitting behind a linuxrouter running 2.4.9=
-ac12
> > with ip_conntrack ftp and ip_nat_ftp loaded.
>
> This is not a netfilter bug.
>
> I just tried it myself:
> Even though the control connection was made to 134.109.132.107, the FTP=
server
> used 134.109.132.117 as source address for the data connection.
>
> So you can hardly blame netfilter for this.
>
> If you open the control connection to 134.109.132.117, everything works=
as expected.
>
> Svenning
Hello Svenning,
so the problem is that netfilter creates a "matcher" like this:
protocol tcp
source-ip-address <server ip-address>
source-port any
destination-ip-adress <router ip-address>
destination-port <router masquerading-port>
is that right? If so, is it possible to change this too-restrictive behav=
iour to something like
protocol tcp
source-ip-address any
source-port any
destination-ip-adress <router ip-address>
destination-port <router masquerading-port>
I know that this may be a security problem, so this should only be option=
al. But on the other
side, does the ftp server do anything wrong?
RFC959.2.3 states:
The user-DTP or its designate should "listen" on
the specified data port, and the server initiate the data
connection and data transfer in accordance with the specified
parameters.
The user-DTP (the masqueraded ftp-client) actually does listen on the spe=
cified data port. The
server does initiate the data connection. Nothing of the RFC says that th=
e server does need to
initiate the data connection from the same ip-adress the control connecti=
on is connected to.
Maybe "in accordance with the specified parameters" only means that the p=
roperties of the data
connection to be opened are only specified by the parameters. All other p=
roperties, which are
not defined by the parties, must be accepted, and may not be restricted t=
o only a subset of all
possible undefined properties.
That's why I think the "offending" ftp server actually does not violate R=
FC959. Actually, cases
where both data-connection-initiator and data-connection-receiver are dif=
ferent from the
ftp-client are explicitly allowed.
So, because the ftp server does not violate RFC959, can the too-restricti=
ve netfilter-behaviour
considered as bug and fixed at least by module option?
Xu=E2n.
--------------00FD175982DCFDA5FF6FE916
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<p>Martin Josefsson wrote:
<blockquote TYPE=CITE>I forwarded your mail and ny response to the netfilter-devel
list and got
<br>this response.
<p>/Martin
<p>Never argue with an idiot. They drag you down to their level, then beat
you with experience.
<p>---------- Forwarded message ----------
<br>Date: Sun, 7 Oct 2001 13:42:41 +0200
<br>From: Svenning Sørensen <sss@sss.dnsalias.net>
<br>To: Martin Josefsson <gandalf@wlug.westbo.se>, netfilter-devel@lists.samba.org
<br>Subject: RE: [BUG] ip_nat_ftp fails for some ftp servers (fwd)
<p>> I can confirm that I can't list the contents of <a href="ftp://ftp.tu-chemnitz.de/">ftp://ftp.tu-chemnitz.de/</a>
<br>> when using active mode and sitting behind a linuxrouter running 2.4.9-ac12
<br>> with ip_conntrack ftp and ip_nat_ftp loaded.
<p>This is not a netfilter bug.
<p>I just tried it myself:
<br>Even though the control connection was made to 134.109.132.107, the
FTP server
<br>used 134.109.132.117 as source address for the data connection.
<p>So you can hardly blame netfilter for this.
<p>If you open the control connection to 134.109.132.117, everything works
as expected.
<p>Svenning</blockquote>
<p><br>Hello Svenning,
<p>so the problem is that netfilter creates a "matcher" like this:
<p><tt>protocol
tcp</tt>
<br><tt>source-ip-address <server ip-address></tt>
<br><tt>source-port
any</tt>
<br><tt>destination-ip-adress <router ip-address></tt>
<br><tt>destination-port <router masquerading-port></tt><tt></tt>
<p><tt>is that right? If so, is it possible to change this too-restrictive
behaviour to something like</tt><tt></tt>
<p><tt>protocol
tcp</tt>
<br><tt>source-ip-address any</tt>
<br><tt>source-port
any</tt>
<br><tt>destination-ip-adress <router ip-address></tt>
<br><tt>destination-port <router masquerading-port></tt><tt></tt>
<p><tt>I know that this may be a security problem, so this should only
be optional. But on the other side, does the ftp server do anything wrong?</tt><tt></tt>
<p><tt>RFC959.2.3 states:</tt><tt></tt>
<p><tt> The user-DTP or its designate should
"listen" on</tt>
<br><tt> the specified data port, and the
server initiate the data</tt>
<br><tt> connection and data transfer in
accordance with the specified</tt>
<br><tt> parameters.</tt><tt></tt>
<p><tt>The user-DTP (the masqueraded ftp-client) actually does listen on
the specified data port. The server does initiate the data connection.
Nothing of the RFC says that the server does need to initiate the data
connection from the same ip-adress the control connection is connected
to. Maybe "in accordance with the specified parameters" only means that
the properties of the data connection to be opened are only specified by
the parameters. All other properties, which are not defined by the parties,
must be accepted, and may not be restricted to only a subset of all possible
undefined properties.</tt><tt></tt>
<p><tt>That's why I think the "offending" ftp server actually does not
violate RFC959. Actually, cases where both data-connection-initiator and
data-connection-receiver are different from the ftp-client are explicitly
allowed.</tt><tt></tt>
<p><tt>So, because the ftp server does not violate RFC959, can the too-restrictive
netfilter-behaviour considered as bug and fixed at least by module option?</tt><tt></tt>
<p><tt>Xuân.</tt>
<br><tt></tt> </html>
--------------00FD175982DCFDA5FF6FE916--