|
On Sun, 27 Nov 2005, Roberto Nibali wrote:
> >> Is there an indication in RFC959 which states that this "behaviour" is
> >> legal as well for active FTP?
> >
> > no-one requires code to obey standards to sell it ;-(
>
> Well, vsftp is GPL and written by someone I happen to know even :). But
> it must be RFC conformant or else clients would not be able to properly
> interact with the server.
As far as I understands the RFC leaves no room for a different src port
for the data connection. It's not fixed at 20 but should be 1 below the
controll port. Which is what ip_vs uses literally IIRC.
> I wonder if there is a special string returned be either one of the
> which indicates that behaviour. If so, we could easily extend the ftp
> part of IPVS.
So, no.
> >> On top of that, does netfilter cope with this or do you need a RELATED
> >> rule?
> >
> > this is one of the points of discussion.
>
> I've read his initial post and so it seems that RELATED is sufficient
> regarding netfilter. Of course we cannot implement the RELATED code in
> IPVS, well we could, however it'll be quite an overkill.
Hmm... not sure what you mean with "the RELATED code", but the way I see
it it is already there. ip_vs_ftp and ip_conntrack_ftp do much of the same
thing. The only difference is that in iptables you need an explicit rule
to handle the connection entries created, when in ipvs they are allways
used.
The real difference is only in the details of the connection entry they
create. In ipvs there is the assumption/requirement that the connection
will originate from port 20 (assuming the ftpd is listening on port 21).
The ip_contrac_ftp module (aparently) does not make this assumption.
Taking the RFC as a guide the assumption is ofcource valid. So the quesion
is; why doesn't ip_contrack_ftp make this assumption, or have this
requirement? A bug? Just Lazy? Or someone there just likes vsftpd? :)
Or... ??
Whetever their reason is, it might be reason for ipvs to just do the same.
Or ipvs could do it just for consistancies sake; have different subsystems
in linux make the same assumptions about the same protocol.
> Mark, what about following setup:
Not sure where you want to go with this...
> connect_from_port_20 = NO
> ftp_data_port = >1024
That's my status-quo... And the whole idea is that the port is >1024 so it
does not need privileges to open privileged ports...
> Or
>
> pasv_enable = YES
passive support is also enabled... (a lot of clients will default to
passive mode or fallback to it if active does not seem to be working.
which is prolly the main reason I've had relatively few complaints about
active ftp not working.)
> Would that be good enough for you? We still need to address IPVS but at
> least it'll be somewhat static (in_ports could be used). It remains to
??
> be said that there is likely to be an issue when dealing with some
> commercial firewalls, if you're using ftp-data not on port 20 with
> active FTP.
I think that is not ipvs's problem. I think we should let ppl shoot
themselves in the foot if they so desire. (btw I'm behind some chekpoint
thing now and it handles if just fine.)
>
> A "hacky" solution to your problem of course would be to fwmark
> ip_local_port_range and 21 and create one persistent service for that.
> This will work instantly, without the need to fix some code. Use the sed
Sorry, I don't understand. How would that affect how the SNAT of the
active connection is done?
Regards,
Mark
|
