[sllug-members]: vsftpd problems

[Lamont Peterson]

On Thursday 07 February 2008 04:17:37 pm Rusty Keele wrote:
> Hi,
>
>     I have recently set up vsftpd on our server, but I am having a few
> problems.
>
>     I am using SuSE Linux Enterprise Server 10, and I can connect to the
> ftp server from another machine and log in as a local user.  Once I am
> logged in I can issue the 'pwd' command without any problems, but if I try
> the 'ls' command I get  "229 Entering Extended Passive Mode (|||12313|)"
> ... and then it freezes up and nothing else happens.
>
>     If I turn off the server's firewall it works like a charm.  I am
> guessing that it is a problem with port numbers, and I have opened ports 20
> & 21 on the server's firewall - but no luck.
>
>     Any ideas what I am doing wrong?

Don't worry about port 20, you won't be using it.

When you use what is now called active mode with FTP, the server is told by 
the client where to connect (IP and port) and then the servers uses port 20 
as the source for opening the data connection.  There's all sorts of things 
wrong with this from a security standpoint, so it's a *really* bad idea to 
allow active mode, anymore.

In passive mode, the client asks the server to do 'PASV'.  The server then 
binds a randomly selected, unprivileged port (1024 - 65535) and tells the 
client, "You can make the data connection to me on port ____."  The client 
then establishes a second connection to the server and the data transfer 
(either up or down) begins.  When it's done, the TCP connection is closed.

When you have NAT or a firewall (or a combination of both) between the outside 
world and the FTP server, trying to use passive mode brings us to the problem 
you are seeing.  There are 3 possible solutions:

1.  Open up all unprivileged ports so connections from outside can get to the 
FTP server.
2.  Configure the FTP server to always use one particular port (20 comes to 
mind) for the data connections.
3.  Use a firewall that can recognize FTP PASV requests and dynamically open 
and close pin-prick holes in the firewall to allow the data connections.

Option 1, at first glance, would seem like a completely horrid though, 
however, if the server is running Linux, it could work out without causing 
any serious security compromise.  After all, if there's no service on a port 
that someone tries to use, the kernel won't allow the connection (this isn't 
Windows).  Still, I can not recommend this approach, even if one thinks they 
know what they'd be getting themselves into.

Option 2 will work very nicely and keeps the firewall and DNAT configurations 
simple, too.  However, most FTP server implementations do not support such a 
feature.  Last I checked (admitidly, it was more than a year ago), vsftpd 
doesn't.

Option 3 will work with any FTP server software.  It's transparent and easy to 
set up.  On SLES, if you are using their SuSEfirewall2 stuff, it provides 
options to have the needed modules loaded for you, so you don't have to deal 
with manual configuration.  If you're building your own firewall scripts, 
simple add the needed modprobe commands:

 modprobe ip_conntrack_ftp; modprobe ip_nat_ftp

For those who are using something newer, the netfilter module names have 
recently changed.  I think this change shows up in 2.6.23, but don't hold me 
to that version number.  It also appears that there are no longer two 
separate modules for these kinds of things (again, I need to do a little more 
digging to be sure).  This means that you simply need to add:

 modprobe nf_nat_ftp

For those who seem to think the idea of using Red Hat's /etc/init.d/iptables 
script is good enough for any firewall needs, I would point out that there 
are limitation to that approach.  It's not a bad idea, but there are cases 
where writing your own SysV Init script will allow to do things better.  
However you choose to go about it, remember that iptables-restore won't load 
such modules for you.

HTH.
-- 
Lamont Peterson <lrp at xmission.com>
[ http://www.xmission.com/~lrp/ ]
GPG Key fingerprint: C51E DD83 B03F D147 A974  939C 5D13 289C 17F1 FFBE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://sllug.org/pipermail/sllug-members/attachments/20080207/1814f6d4/attachment.pgp