SEO

I'm configuring a vsftpd server that's also running iptables. Without
the necessary udp ports open, data connections are blocked so ftp
clients fail. I configure vsftpd to use a specific range of udp ports
for the pasv transfers. I configure iptables to allow that range of
udp ports. Let me show a quick example of what I'm talking about.

# cat /etc/vsftpd/vsftpd.conf | grep pasv
pasv_min_port=2000
pasv_max_port=2100

# cat /etc/sysconfig/iptables| grep 20000
-A RH-Firewall-1-INPUT -p udp -m udp --dport 2000:2100 -j ACCEPT

When I test with an ftp client, the ftp client *does* use the correct
udp ports, and the ftp client *is* able to list files, send files, etc.
But from the moment it initiates the udp connection to the point at
which the data transfer begins is *really* delayed. Several seconds,
easy.

Am I going about this the wrong way? Why would there be this long
delay? With iptables disabled, the data connections are smoking fast.
So it would seem to have something to do with the iptables service.
The load is 0.00, so it's not like it's working too hard.

Thanks,
Scott

Scott Moseman wrote:
> I'm configuring a vsftpd server that's also running iptables. Without
> the necessary udp ports open, data connections are blocked so ftp
> clients fail. I configure vsftpd to use a specific range of udp ports
> for the pasv transfers. I configure iptables to allow that range of
> udp ports. Let me show a quick example of what I'm talking about.
>
> # cat /etc/vsftpd/vsftpd.conf | grep pasv
> pasv_min_port=2000
> pasv_max_port=2100
>
> # cat /etc/sysconfig/iptables| grep 20000
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 2000:2100 -j ACCEPT

[snip]

Well, maybe because a FTP-server use the TCP protocol :-)

Scott Moseman wrote:
> I'm configuring a vsftpd server that's also running iptables. Without
> the necessary udp ports open, data connections are blocked so ftp
> clients fail. I configure vsftpd to use a specific range of udp ports
> for the pasv transfers. I configure iptables to allow that range of
> udp ports. Let me show a quick example of what I'm talking about.
>
> # cat /etc/vsftpd/vsftpd.conf | grep pasv
> pasv_min_port=2000
> pasv_max_port=2100
>
> # cat /etc/sysconfig/iptables| grep 20000
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 2000:2100 -j ACCEPT
>
> When I test with an ftp client, the ftp client *does* use the correct
> udp ports, and the ftp client *is* able to list files, send files, etc.
> But from the moment it initiates the udp connection to the point at
> which the data transfer begins is *really* delayed. Several seconds,
> easy.
>
> Am I going about this the wrong way? Why would there be this long
> delay? With iptables disabled, the data connections are smoking fast.
> So it would seem to have something to do with the iptables service.
> The load is 0.00, so it's not like it's working too hard.
>
I would suggest they you require clients to use PASSIVE for data
connections, it's the default in many ftp clients. And while the the
ports are reserved to UDP as well as TCP, virtually no clients actually
support using UDP for this. So you may find that you are taking some
lesser traveled code path for a really minimal gain in performance.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

Scott Moseman wrote:
> I'm configuring a vsftpd server that's also running iptables. Without
> the necessary udp ports open, data connections are blocked so ftp
> clients fail. I configure vsftpd to use a specific range of udp ports
> for the pasv transfers. I configure iptables to allow that range of
> udp ports. Let me show a quick example of what I'm talking about.
>
> # cat /etc/vsftpd/vsftpd.conf | grep pasv
> pasv_min_port=2000
> pasv_max_port=2100
>
> # cat /etc/sysconfig/iptables| grep 20000
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 2000:2100 -j ACCEPT
>
> When I test with an ftp client, the ftp client *does* use the correct
> udp ports, and the ftp client *is* able to list files, send files, etc.
> But from the moment it initiates the udp connection to the point at
> which the data transfer begins is *really* delayed. Several seconds,
> easy.
>
> Am I going about this the wrong way? Why would there be this long
> delay? With iptables disabled, the data connections are smoking fast.
> So it would seem to have something to do with the iptables service.
> The load is 0.00, so it's not like it's working too hard.
>
I would suggest they you require clients to use PASSIVE for data
connections, it's the default in many ftp clients. And while the the
ports are reserved to UDP as well as TCP, virtually no clients actually
support using UDP for this. So you may find that you are taking some
lesser traveled code path for a really minimal gain in performance.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

Yeah, that would definitely help with getting this to work!
Changing the open ports to tcp rather than udp works.

Thanks!
Scott

I'd actually moving away from FTP to HTTPS for authenticated downloads, and
WebDAV over HTTPS for uploads. It's a lot easier to configure for firewalls
for various reasons, and there's little chance of having your traffic
sniffed as there is with FTP, which crackers just *love* to monitor for the
key phrase "asswd" and the packets after it with your clear-text password in
them.

Nico Kadel-Garcia wrote:
> I'd actually moving away from FTP to HTTPS for authenticated downloads, and
> WebDAV over HTTPS for uploads. It's a lot easier to configure for firewalls
> for various reasons, and there's little chance of having your traffic
> sniffed as there is with FTP, which crackers just *love* to monitor for the
> key phrase "asswd" and the packets after it with your clear-text password in
> them.
>
>
You make a very good point there, that it is desirable to use ftp only
for anonymous ftp services, for the reason you mention.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

On Thu, 09 Mar 2006 18:35:06 +0000, Bill Davidsen wrote:
> Nico Kadel-Garcia wrote:

>> I'd actually moving away from FTP to HTTPS for authenticated downloads, and
>> WebDAV over HTTPS for uploads. It's a lot easier to configure for firewalls
>> for various reasons, and there's little chance of having your traffic
>> sniffed as there is with FTP,

Why then, not just enable FTPS instead?

>> which crackers just *love* to monitor for the key phrase "asswd" and
>> the packets after it with your clear-text password in them.
>>
> You make a very good point there, that it is desirable to use ftp only
> for anonymous ftp services, for the reason you mention.

Vsftpd can use SSL/TLS encription:
http://groups.google.nl/group/alt.os...05649d840ef8d5

As can Proftpd (although the "TLSProtocol TLSv1" statement one may need to
change to "TLSProtocol SSLv23" for some clients to work):
http://groups.google.nl/group/alt.os...76cb5ca19e3a09

Pureftpd can (currently) only encript the control connection, not the
data, and as such doesn't work with some clients that implicitly expect
otherwize...

--
-Menno.

Menno Duursma wrote:
> On Thu, 09 Mar 2006 18:35:06 +0000, Bill Davidsen wrote:
>> Nico Kadel-Garcia wrote:
>
>>> I'd actually moving away from FTP to HTTPS for authenticated
>>> downloads, and WebDAV over HTTPS for uploads. It's a lot easier to
>>> configure for firewalls for various reasons, and there's little
>>> chance of having your traffic sniffed as there is with FTP,
>
> Why then, not just enable FTPS instead?

Because there is none. Seriously: there are easily half-a-dozen different
protocols, each called "sftp" or "ftps", and many of which have their own
adventures in security (such as the OpenSSH sftp failing to keep the users
in a chroot cage and allowing access to system files outside the target
directory), clients that don't support it the particular way you mention,
etc., etc.

WebDAV/HTTPS support is built into Windows (in the Network Neighborhood for
uploading files) and Linux (in Konqueror and other tools) and is available
in various other means. But the download support is built into every HTTPS
browser in the world, and runs entirely over plain old HTTPS. No muss, no
fuss, easy to manage.

>>> which crackers just *love* to monitor for the key phrase "asswd" and
>>> the packets after it with your clear-text password in them.
>>>
>> You make a very good point there, that it is desirable to use ftp
>> only for anonymous ftp services, for the reason you mention.
>
> Vsftpd can use SSL/TLS encription:
> http://groups.google.nl/group/alt.os...05649d840ef8d5
>
> As can Proftpd (although the "TLSProtocol TLSv1" statement one may
> need to change to "TLSProtocol SSLv23" for some clients to work):
> http://groups.google.nl/group/alt.os...76cb5ca19e3a09
>
> Pureftpd can (currently) only encript the control connection, not the
> data, and as such doesn't work with some clients that implicitly
> expect otherwize...

You see what I mean.

On Fri, 10 Mar 2006 07:21:41 -0500, Nico Kadel-Garcia wrote:
> Menno Duursma wrote:
>> On Thu, 09 Mar 2006 18:35:06 +0000, Bill Davidsen wrote:
>>> Nico Kadel-Garcia wrote:
>>
>>>> I'd actually moving away from FTP to HTTPS for authenticated
>>>> downloads,

This you can do either way.

>>>> and WebDAV over HTTPS for uploads. It's a lot easier to configure for
>>>> firewalls for various reasons, and there's little chance of having
>>>> your traffic sniffed as there is with FTP,
>>
>> Why then, not just enable FTPS instead?
>
> Because there is none.

http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

(Note if you want Vsftpd supporting port 990 control / 989 data aswell,
just configure 'stunnel' for it. However very few clients can use that
anyways so you probably don't have to support it.)

> Seriously: there are easily half-a-dozen different protocols, each
> called "sftp"

Which is an FTP-like commands accepting proxy to scp, which in turn is
just rcp over ssh... Neither Vsftpd, Proftpd, or Pureftpd do this.

> or "ftps",

And this is what i'd suggest the OP enable (the firewall need only allow
incomming on port 21 and outgoing on port 20 plus the passive port range.)

> and many of which have their own adventures in security (such as the
> OpenSSH sftp failing to keep the users in a chroot cage and allowing
> access to system files outside the target directory),

"It should not be confused with SSH file transfer protocol":
http://en.wikipedia.org/wiki/FTPS

> clients that don't support it the particular way you mention, etc., etc.

Well i've had some users complain how WebDAV, and WinSCP and pretty much
anything but the FTP client they're used to useing sucks. Now both Vsftpd
and Proftpd atleast support with SSL/TLS enabled: wsftp, filezilla,
kasablanca, gftp, lftp and curl clients.

[snip]

>> Pureftpd can (currently) only encript the control connection, not the
>> data, and as such doesn't work with some clients that implicitly expect
>> otherwize...
>
> You see what I mean.

Than don't use Pureftpd? The OP is about Vsftpd so that shouldn't be much
of a problem. And anyways plenty of clients _do_ work with AUTH TLS (which
is the method Pureftpd currently _does_ support.)

If the lack of GUI for Vsftpd is a problem maybe look the Webmin module:
http://groups.google.nl/group/alt.os...51d53002559cbe

Otherwize maybe switch to Proftpd, for which there are plenty of GUI tools:
http://www.debianhelp.co.uk/proftpweb.htm

Gproftpd (not mensioned above) even allows for SSL/TLS cert creation:
http://mange.dynalias.org/linux.html

Cheers.

--
-Menno.