Multiple connections for one ftp download

[Silent Ninja]

I've recently seen that when I try to download a folder with subfolders and subitems, the ftp connections goes from 2 to 300 per my IP, and I don't know why.

All of them are using passive ftp ports. I don't mind about the connections, but my firewall (CSF) blocks their IP's when they go further 200 connections to the webserver, so I do mind.

Am I doing something wrong? May the ftp_contract from iptables be missconfigured ?

My pureftpd conf file is setted to 20000 files 20 subdirectories and 8 connections max per IP. If you need to see it I can post it here.

 

[Infopro]

Whats your FTP client max connects set to? Or am I misunderstanding you?

 

[Silent Ninja]

I'm using Filezilla with no custom configuration, just downloaded it and downloaded the folder itself.

I'm attaching my pure-ftpd.conf file, you may want to open it on wordpad or a linux text editor since the line breaks may look a little.. as non-breaking lines :P

This are the lines I believe that matters...

MaxClientsNumber            50
MaxClientsPerIP             8
LimitRecursion              2000 8

But as you've seen before the 300 passive connections from my computer are not limited by the 8 connections per IP.. or it's malfunctioning awfully.

As a complementary note, the folder itself has some recursion and files inside those recursive folders. It's a moddle folder from an Joomla installation. I can download it normally one by one, but I cannot download the hole containing folder since it starts some kind of connection loop that ends up with me being blocked out by the firewall

 

[Valuehosted]

I personally would not set the max clients higher than 4 and I would whitewash your own IP in the firewall so it does not block you - CSF and LFD are good for this as well (http://www.configserver.com/cp/csf.html).

--Tone

 

[Silent Ninja]

I personally would not set the max clients higher than 4 and I would whitewash your own IP in the firewall so it does not block you - CSF and LFD are good for this as well (http://www.configserver.com/cp/csf.html).

--Tone

I am using CSF and LFD, but I won't unblock my clients each time they want to download a folder per day..

This is the netstat from my IP when I begin the ftp connection:

[[email protected] ~]# netstat -plantu | grep 201.255.232.197
tcp        0      0 201.235.253.16:15609        201.255.232.197:18018       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:21           201.255.232.197:18016       ESTABLISHED 25828/pure-ftpd (ID 
tcp        0      0 201.235.253.16:80           201.255.232.197:18017       FIN_WAIT2   -

TOTALLY normal.. but when i download a folder with subfolders (like an untared backup)... wait for a few seconds (at least 10).. and tadá

netstat -plantu | grep 201.255.232.197 | wc -l
296

296 connections.. so wait for a few more minutes and tadá, firewall is blocking you. I want to avoid that, but nor the block, the abnormal multiple connections.

 

[bornonline]

I set Maxclients in pure-ftp conf to like 8 connections per IP.
Then type
[email protected] [/etc]# /usr/sbin/pure-config.pl /etc/pure-ftpd.conf
Running: /usr/sbin/pure-ftpd -A -c50 -B -C4 -D -E -fftp -H -I15 -lextauth:/var/run/ftpd.sock -L2000:8 -m

worked for me.. just make sure you set max connection in the FTP client too.

 

[Silent Ninja]

I set Maxclients in pure-ftp conf to like 8 connections per IP.
Then type
[email protected] [/etc]# /usr/sbin/pure-config.pl /etc/pure-ftpd.conf
Running: /usr/sbin/pure-ftpd -A -c50 -B -C4 -D -E -fftp -H -I15 -lextauth:/var/run/ftpd.sock -L2000:8 -m

worked for me.. just make sure you set max connection in the FTP client too.

MaxClientsNumber 50
# This defines the TOTAL users that can access the FTP i have a webserver, and there are more than 8 guys using it..

MaxClientsPerIP 8
# This defines the TOTAL connections from that IP to the FTP server, that can likely be eight.

The fact is that none of them seems to work since I've got 1 connection to port 21, but 250 to passive ftp ports.
Lowering the total connections to the ftp is no good since it will lower your total ftp availability.

Any other ideas ? Could it be Iptables related, or it's totally "normal" that a user connects 300 times to download 300 files when the logic tells me that 8 should be more than enough if you download 2 files per time?

This is the netstat -plantu after a few seconds of downloading an untared backup (like 1000 files with some subfolders in it):

tcp        0      0 201.235.253.16:22064        201.255.232.197:20107       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:18696        201.255.232.197:20113       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:22250        201.255.232.197:20110       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:19538        201.255.232.197:20111       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:21749        201.255.232.197:20119       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:25447        201.255.232.197:20116       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:30395        201.255.232.197:20106       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:20115        201.255.232.197:20140       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:16914        201.255.232.197:20141       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:7599         201.255.232.197:20109       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:21           201.255.232.197:20104       ESTABLISHED 13450/pure-ftpd (ID 
tcp        0      0 201.235.253.16:9733         201.255.232.197:20112       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:8587         201.255.232.197:20125       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:2129         201.255.232.197:20146       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:32400        201.255.232.197:20187       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:3173         201.255.232.197:20139       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:15969        201.255.232.197:20118       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:26887        201.255.232.197:20163       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:49811        201.255.232.197:20126       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:61427        201.255.232.197:20145       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:38518        201.255.232.197:20179       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:55443        201.255.232.197:20120       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:62874        201.255.232.197:20151       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:52783        201.255.232.197:20108       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:53984        201.255.232.197:20121       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:43113        201.255.232.197:20186       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:52949        201.255.232.197:20138       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:46826        201.255.232.197:20181       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:21           201.255.232.197:20079       ESTABLISHED 13132/pure-ftpd (ID 
tcp        0      0 201.235.253.16:62207        201.255.232.197:20122       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:58271        201.255.232.197:20105       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:56021        201.255.232.197:20169       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:34888        201.255.232.197:20117       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:33511        201.255.232.197:20103       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:54377        201.255.232.197:20180       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:46146        201.255.232.197:20152       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:59481        201.255.232.197:20188       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:59645        201.255.232.197:20184       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:42855        201.255.232.197:20123       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:64442        201.255.232.197:20164       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:48169        201.255.232.197:20114       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:32998        201.255.232.197:20143       TIME_WAIT   -                   
tcp        0      0 201.235.253.16:39739        201.255.232.197:20147       TIME_WAIT   -

I'm downloading 2 files per time, using FireFTP a normal ftp client (Firefox plugin), it has no configuration about "connection limits", more than the passive port limitation, but nothing avoids that you connect 300 times with the same passive port.

 

[equens]

Hello Silent Ninja, have you found a solution for this trouble?

 

[DomineauX]

The problem is that after a single connection for downloading a file, the socket remains in TIME_WAIT status until timing out and closing.

Chirpy from ConfigServer.com (makers of CSF/LFD) recommends the following:

ConfigServer Scripts Forum - View Single Post - Port Scan x Pure-FTP
--------------
If you're referring to Connection Tracking blocks, then you either need to have your clients use a more responsible FTP client that reuses connections (it's the ones that don't that cause problems) or increase the Connection Tracking limit until you no longer have false-positives. Alternatively, you can play with disabling the tracking of the TIME_WAIT connection state, etc.
--------------

Personally I like dropping the ipv4.tcp_fin_timeout to 15 seconds by inserting the following to /etc/sysctl.conf and activating with "sysctl -p":

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

(by default RHEL/CentOS have this set to 60 seconds)

 

[ethical]

sorry for resurrecting an old thread, but this issue is still persistent in filezilla and I wanted to confirm that DomineauX's suggestion of adding in

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

into the /etc/sysctl.conf seems to solve this issue.

I also added in the following based on the cpanel security doc for hardening sysctl:

# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800

# Turn off the tcp_window_scaling
net.ipv4.tcp_window_scaling = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1