RH9 proFTP speed issue

benbroad · 11-30-2004, 05:11 AM

I’m not sure if this should go in here or in the networking forum... I am new to Linux and have set up a virtual hosts web server LAMP to teach myself as much as possible.

The problem I am having is that ftp is running VERY slowly. The actual data transfer seems to be fine, but there is a massive long wait between sending commands and getting a response.

I am using RH9, proFTP. I have a load of iptables rules set up and I am unsure whether this is causing the problem. I have enabled resume on uploads.

Any ideas would be greatly appreciated.

B.

linuxles · 11-30-2004, 05:32 AM

What happens if you use gFTP or just the regular ftp? Is there still a speed issue?
This would single out whether or not it's a proFTP issue...

Have you tried using sftp which is part of openssh? It uses port 22 instead of 21.
SSH stands for secure shell. You'll have to allow ssh traffic through the firewall.
If you are concerned about security, sftp is way more secure than ftp. It provides
secure encrypted communications between two untrusted hosts over an insecure
network. gFTP has an option for using sftp instead of ftp to transfer files.

Otherwise, post your "/sbin/iptables -L" output to the list.

/Les

benbroad · 11-30-2004, 06:38 AM

I have tried specifying the passive ports in proftpd.conf, with the matching ports open in iptables all to no avail.... Its just odd, it gets there in the end but MY GOD does it take a while getting there!

It must be an iptables problem, as I am waiting for it to output an 'iptables -L' and it is taking AGES. The first 9 lines appear instantly (including the ftp line) but the others just take yonks - about 30 seconds per line.

I am also worried about line 2 - is it me or does that say accept any from anywhere?

Code:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere           state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere           tcp spts:1024:65535 dpt:http
ACCEPT     tcp  --  anywhere             anywhere           tcp spts:1024:65535 dpt:https
ACCEPT     tcp  --  anywhere             anywhere           tcp spts:1024:65535 dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere           tcp spts:1024:65535 dpt:pop3
ACCEPT     tcp  --  anywhere             anywhere           tcp spts:1024:65535 dpt:ftp
LOG        tcp  --  anywhere             anywhere           tcp dpt:ssh state INVALID,NEW LOG level warning prefix `iptables: '
ACCEPT     tcp  --  83.104.xxx.xxx       anywhere           tcp spts:1024:65535 dpt:ssh
ACCEPT     tcp  --  81.154.xxx.xxx/24       anywhere           tcp spts:1024:65535 dpt:ssh
ACCEPT     tcp  --  83.104.xxx.xxx       anywhere           tcp spts:1024:65535 dpt:mysql
ACCEPT     tcp  --  81.154.xxx.xxx/24       anywhere           tcp spts:1024:65535 dpt:mysql
ACCEPT     tcp  --  80.177.xxx.xxx/24      anywhere           tcp spts:1024:65535 dpt:mysql
ACCEPT     tcp  --  83.104.xxx.xxx       anywhere           tcp spts:1024:65535 dpt:8443
ACCEPT     tcp  --  81.154.xxx.xxx/24       anywhere           tcp spts:1024:65535 dpt:8443

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

benbroad · 11-30-2004, 09:46 AM

After doing a thorough Google / forum search (something I should have done to start with!) I came accross:

http://www.linuxquestions.org/questi...ght=slow+login
and...
http://www.linuxquestions.org/questi...ght=slow+login

Now this seems to be exactly the problem I am having. I will add my office and home IPs to the /etc/hosts file and see if that helps, but can I turn RDNS off for FTP as I will have a quite a few people connecting from unknown IP addresses.

I think this is why the iptables grinds along as it only goes slow on the ip ranges it tries to look up.

benbroad · 11-30-2004, 10:31 AM

Right it's definitely a DNS / Bind issue as dig timesout and unless a host is specifically mentioned in the /etc/hosts file, it timesout.

Looks like I will have to start looking into how to set up BIND (YOINKS!)

benbroad · 11-30-2004, 11:41 AM

I appreciate that this thread is pretty much me gassing on, but for those of you who have read down this far....

If I disable the firewall then I can use dig with no problems. I have added a line in my iptables setup to allow traffic on port 53 and I have altered /etc/named.conf to include the line:

Code:

query-source address * port 53;

so dns queries should all go through port 53. Still no dice. Puzzling...

benbroad · 11-30-2004, 11:50 AM

Done. Yayy!

Code:

iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535  -j ACCEPT

it was my bloody iptables setup that was causing it.

linuxles · 11-30-2004, 01:57 PM

After re-reading the initial post, it dawned on me that this was a host lookup issue.
Looks like you figured it out yourself, good work...

Notes about your iptables output:

About: line 2 -- that's correct. The default is ACCEPT then DENY anything that doesn't
match the rules that follow. Read the section on TARGETS in the iptables man page.

About allowing and denying certain hosts to connect to services. I prefer to put that
type of control in the hosts.allow and hosts.deny files.

Also, when posting output to the list (like info in your iptables), you may want to
obscure part of the ip information. Something like: 83.104.xxx.xxx, you don't want
anyone trying to spoof your ip adresses to gain access to your box. You should be
able to go back and edit your post to clean that up a bit...

I also don't see anything specifically Rejecting anything that doesn't match any of the
above rules. Since your default policy is DROP you may be ok. My default policy is
ACCEPT, then REJECT anything that doesn't match. So, the last line in my INPUT policy
states:
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

I wonder if adding that would make it a double negative?

Looks like I may need to study iptables a bit more...

/Les

benbroad · 12-01-2004, 02:33 AM

Whoops! Thanks for pointing that out - I am normally very diligent about that kind of thing, it must have been my stress levels yesterday.

I altered my iptables so that the second line does not occur.

If you do some research into REJECT please let me know how you get on. I thought REJECT would be a security risk on a web server as I didnt want someone port scanning to get any message back on rejected packets - but this is all a bit new to me!