vsftpd and iptables
Scott Moseman
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
Trygve Selmer
> 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 :-)
Bill Davidsen
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
Bill Davidsen
Scott Moseman
Changing the open ports to tcp rather than udp works. :)
Thanks!
Scott
Nico Kadel-Garcia
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.
Bill Davidsen
for anonymous ftp services, for the reason you mention.
Grant
>You make a very good point there, that it is desirable to use ftp only
>for anonymous ftp services, for the reason you mention.
Yes, I've had vsftpd up for over a year, anonymous (no password)
access -- no problems at all. iptables limits the ftp connection
rate, though that does nothing to stop an anon user trying all
sorts of ../directory variations before they give up and move on
to a softer target ;)
Grant.
--
Cats are smarter than dogs. You can't make eight cats pull
a sled through the snow.
Kevin D. Quitt
know what file you want to get, and you can't get out of the assigned directory tree.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Menno Duursma
> 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.linux/msg/ac05649d840ef8d5
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.linux/msg/0376cb5ca19e3a09
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.
Nico Kadel-Garcia
> 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.linux/msg/ac05649d840ef8d5
>
> 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.linux/msg/0376cb5ca19e3a09
>
> 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.
Menno Duursma
> 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.linux.slackware/msg/0251d53002559cbe
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.
Nico Kadel-Garcia
"Menno Duursma" <me...@desktop.lan> wrote in message
news:pan.2006.03.10....@desktop.lan...
You seem not to realize that you're helping make my point. Factor in that
there at least 3 different protocols which have been called "sftp", "ftps",
etc., etc. The situation really suffers from the vagaries of which one you
happen to mean, and which one your client happens to support. Check out
http://en.wikipedia.org/wiki/FTPS for some examples. And the firewall
configurations for the dual-channel approach of FTP are often an....
adventure to configure for in a tight environment where the firewall guru is
being really strict. That's a big advantage of the HTTPS/WebDAV approach:
you just need to allow port 443.
"Plenty of clients" does not mean "most clients", or even "the client my
customer likes". WS-FTP is still in strong use, for example, and plenty of
real-time Linux boxes don't support any of the secure FTP versions. But they
do support web browsers or HTTPS for download!
Menno Duursma
> "Menno Duursma" <me...@desktop.lan> wrote in message
>> Gproftpd (not mensioned above) even allows for SSL/TLS cert creation:
>> http://mange.dynalias.org/linux.html
> You seem not to realize that you're helping make my point. Factor in that
> there at least 3 different protocols which have been called "sftp",
This is the SSH thingy mensioned before: sftp != ftps
> "ftps", etc., etc.
Well you have either AUTH TLS on port 21 after which we're scrambled,
encription of the data-channel clients should negotiate. However some
(older) send AUTH SSL and assume the data should be encripted too, Vsftpd
can cope with this.
The older suggestion was to listen on port 990 for connections with an SSL
header (conventionally active ftp-data connects from one port less then
ftp-control, so that's 989. However with passive-mode data a range is used
whatever port the control channel happens to run on.)
So you basically have two ways... And Vsftpd can be configured to accept
the first itself (with either SSLv2, v3 or TLSv1 supporting a whole list
of cyphers, and pretty much any command a client might send). The 990 port
is deprecated and wasn't used often in the first place, some kind of SSL
proxy in front of any FTP daemon should do, if anyone needs it though.
> The situation really suffers from the vagaries of which one you happen
> to mean, and which one your client happens to support. Check out
> http://en.wikipedia.org/wiki/FTPS for some examples.
I know:
curl -D - http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html | \
grep Menno
> And the firewall configurations for the dual-channel approach of FTP are
> often an.... adventure to configure for in a tight environment where the
> firewall guru is being really strict. That's a big advantage of the
> HTTPS/WebDAV approach: you just need to allow port 443.
>
> "Plenty of clients" does not mean "most clients", or even "the client my
> customer likes". WS-FTP is still in strong use,
That works (with the AUTH SSL option and SSLv[23] server support):
http://www.ipswitch.com/Support/WS_FTP/guide/wsftpug80/08sslutil.html
> for example, and plenty of real-time Linux boxes don't support any of
> the secure FTP versions. But they do support web browsers or HTTPS for
> download!
HTTPS for download: fine (although rate-limiting is easier with FTPS).
Idunno about the security implications of WebDAV BTW:
lynx -dump http://www.apsis.ch/pound/ | grep -B22 Subversion
Modern FTP(S) servers, especially Vsftpd (i read some of the code) are
rather paranoid in their input validation checking, usage of privs etc.
--
-Menno.