View Full Version : Slow vs-FTP server
Ned
7th September 2004, 11:56 AM
Hi,
I've set up an FTP server (using vs-ftp) with mostly the default settings on FC2 but it seems rather slow.
Transfers are OK internally over the lan, but for external users they're slow. Large files seem OK but the delay comes between files so when there's lots of small files to download it grinds to a halt establishing a connection to each new file.
Any thoughts/ideas?
Ned
ewdi
7th September 2004, 02:10 PM
i have same problem, one solution is to disable NS lookup
I'll paste my config file to disable ne lookup when i got home
Ned
7th September 2004, 03:49 PM
Thanks ewdi - that would be very helpful.
I have absolutely no nameserver, dns or whatever set up - all just done by IP address. Could explain why it's fast internally on my lan but slow to the outside world?
Ned
ewdi
7th September 2004, 03:51 PM
Yap, since you have no name server, it will wait until name server lookup is timeout then allow connection, so you wil have to disable them
Ned
7th September 2004, 04:52 PM
Thanks ewdi :)
I have no idea how to do this, so could you point me in the right direction please?
Is it a setting in /etc/vsftpd/vsftpd.conf I need to set or is it something globally I need to change?
Ned
ewdi
7th September 2004, 04:54 PM
yeah it should be in /etc/vsftpd/vsftpd.conf, i cant remember what config line i use, i will post it here when i got home, now at work with solaris :p
Ned
7th September 2004, 05:09 PM
yeah it should be in /etc/vsftpd/vsftpd.conf, i cant remember what config line i use, i will post it here when i got home, now at work with solaris :p
Thank you very much Sir :)
Catch you later...
in the meantime I'll check the man pages for vsftpd.conf ;)
Ned
jeru
8th September 2004, 08:09 AM
Is it because you have no PASV support setup?
pasv_enable=YES
pasv_min_port=65000
pasv_max_port=65534
pasv_address=<external IP>
enable then forward that port range to the vsftpd server. You can really pick whatever port ranges you want over 1024.
Ned
9th September 2004, 02:39 AM
pasv is enabled - as per defaults.
enable then forward that port range to the vsftpd server. You can really pick whatever port ranges you want over 1024.
Do you mean I need to forward all these pasv ports from my hardware firewall/router to the ftp box? If so, why?
Ned
jeru
9th September 2004, 04:26 AM
because most ftp clients want to use PASV by default....
The port range is because the PASV port used is generated by RPC each time the connection is established. The range I put in there is irrelivent, it simply acts as a boundry that you know about for your firewall and you can put whatever you want there for that range.... The routable/external IP is there so you can let your clients know what IP they should be connecting to when RPC generates a port for them to use. But if pasv is enabled and the server is generating a reponse that says something like 192.168.x.x or 10.x.x.x..., etc... port 'anything in the world'. You can obviously imagine how an internet client might not like that response. Thus forcing the client through 21 as a non pasv connection and making things 'slow' if it doesn't just flat out die when it gets a non routable IP to connect to. (just watch the connection log on the client)
It was just a guess since that would make internet based clients slow and local clients fast.
Ned
13th September 2004, 02:06 AM
Jeru,
Sorry for the delay in replying, but you appear to be right :)
I've now had the opportunity to connect to the ftp server from off site and indeed PASV seems to be the problem. When I tell the client ftp program to NOT use PASV, it connects immediately.
So now I've identified and confirmed the problem, how do I fix it?
I think I sort of uderstood what you said above, but I'm unsure/wary about opening/forwarding extra high ports. I have iptables firewall running on the server box (192.168.0.2) and it's connected via a netgear hardware firewall/router. The hardware firewall is accepting/forwarding connections on port 20/21 and the iptables firewall is accepting all connections on port 21. Both are spi firewalls with ESTABLISHED/RELATED allowed, so why aren't the higher port PASV connections be covered by the ESTABLISHED/RELATED rule?
How much of an additional security risk is it to open additional high ports for PASV and what advantages are there to using PASV mode?
Sorry for all the questions - just trying to understand all this a little better before I go punching holes in my firewall.
Thanks,
Ned
jeru
13th September 2004, 10:11 AM
well, running any service is an additional security risk right? As far as what happens when you open up a PASV port range. Those don't stay open until the connection is established on 21 and redirected to the PASV port designated by the server. When the session is done, the port closes back up.
As to why the related rule doesn't work acrost both firewalls. Well without something like UPnP, the first(Netgear) firewall has no idea that the internal system just opened another port for an incoming connection. Outgoing is fine with a NAT firewall because the packets are translated internal to external, external to internal can't work in that same manner as a one-to-many relationship without something else telling it where it should go. (the port range you picked and directed) The relation rule only applys locally. And that should be working if you can connect from the local segment like you can right? (unless you aren't filtering anything from 192.168.0.0/24)
The security risk lies in the idea that maybe a trojan or somebody starts running another service using the ports you have open. And as far as a trojan is concerned.... that would be pretty lucky since there are thousands of ports you or the trojan could be choosing. And with linux, things like trojans don't happen very often. But if they do, you probably have a far larger security problem on your hands than the hole you punched for PASV. (that could be the user on your system that has process rights or however the trojan got there in the first place)
But when that port closes, it is closed..... To anybody trying to break in, it's like knocking on a brick wall and expecting somebody to answer. The service is the security problem. (e.g. ProFTP's history) vsftp is pretty tight on security when it comes to ftp thou. Thus the reason people like kernel.org, redhat.com, debian.org, etc all use it on their sites. And the reason vsftpd rarely ever changes.
In reality, the security implication are different if you plan on this thing being a public, private to dummy accounts or private to unix accouts. If it is private to unix accounts only (pam auth).... You may be more interested in using sftp over ftp. I don't generally allow unix logons via ftp unless I absolutly cannot do anything else. At which point it usually becomes a hosts.allow and hosts.deny configuration.
but again, vsftp is pretty secure, you probably don't need to worry too much about it being hackable by running it. It's one of the more tried and true software packages in the Fedora repo's.
Ned
13th September 2004, 05:33 PM
Thanks jeru - I got it now :)
Ned
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.