ProFTPD Timeout Issues / Firewalls & PAM

[Matt Sonnentag]

Environment - VPS box (Media Temple), Centos 5.6, Plesk 8.6, CSF firewall w/lfd - latest yum updates from art, dag and base

We have been having a strange problem with ftp timing out the I hop someone can shed some light on for me. The issue is that we have a mac running Transmit that stays connected for extended periods of time, the owner of the mac - who is paying for the server btw, would like to not have to login over and over. Apparently, prior to updates and install of the firewall this was not an issue - so somewhere in that work we managed to make this problem happen.

To resolve, we upped the timeouts on proftpd in the config file to:

<Global>
DefaultRoot ~ psacln
AllowOverwrite on
TimeoutLogin 300
TimeoutNoTransfer 28800
TimeoutIdle 0
PassivePorts 30000 35000
DebugLevel 5
</Global>

Which basically keeps them connected for a day without a transfer. Probably not the best practice, but wth.

Anyway, this doesn't work - it seems as if something else is nixing the connection somewhere. As you can see we have debuglevel 5 set and are getting copious feedback in our /var/log/secure file and we are actually testing this on a Win7 box with Filezilla installed.

What we see is the client and the server doing a NOOP / keepalive dance for 30 minutes. We see the transactions on both ends in the /var/log/secure file and Filezillas log display. The two boxes happily chat for the 30 minutes and then we stop seeing any traffic from the server as noted in the following logs:

From the server:
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_tls
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching PRE_CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching CMD command 'NOOP' to mod_core
Jun 8 11:46:54 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - dispatching LOG_CMD command 'NOOP' to mod_log
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory
Jun 8 11:56:50 clientsrv proftpd: Deprecated pam_stack module called from service "proftpd"
Jun 8 11:56:50 clientsrv proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0
Jun 8 11:56:50 clientsrv proftpd: pam_unix(proftpd:session): session closed for user xxxxman
Jun 8 11:56:50 clientsrv proftpd[11689]: clientsrv.com (209.169.208.194[209.169.208.194]) - FTP session closed.

From the PC:

10:45:54 Response: 257 "/" is the current directory
10:46:24 Status: Sending keep-alive command
10:46:24 Command: PWD
10:46:24 Response: 257 "/" is the current directory
10:46:54 Status: Sending keep-alive command
10:46:54 Command: NOOP
10:46:54 Response: 200 NOOP command successful
10:56:50 Error: Disconnected from server: ECONNABORTED - Connection aborted

So, I am not sure what happens after 10:46:54. It seems that something is going on with the server and it is having trouble extending the session. I have researched all of those FTP related errors in secure log and gotten nowhere. I am suspecting that some sort of communication is happening on the server and the firewall might be blocking it.

Note: we do have passive ports configed in the fwall and everything seems to work properly other than the extended timeout. Also verifyed that scoreboard is there and being written to, and tried a number of different configs for pam and proftpd.

My theory at this point is that proftpd (managed by pamd) needs to go and check its config to update the timeout or perhaps the scoreboard file (using the network??) and is getting blocked by the firewall. My next troubleshooting step is to go through this process again and see if we can monitor dropped packets in the firewall as well.

Any thoughts or help would be much appreciated.

Just a quick followup:
I enabled CSF watch mode and logged everything related to the servers IP as well as my own and this yielded no additional information at all.

 

[atomicturtle]

That sounds a lot like the firewall rules are dropping ESTABLISHED (this is a session state in netfilter) connections after a fixed time period. As a test try clearing them completely (/etc/init.d/iptables stop) and then see if the sessions will stay active for more than 30 minutes.

 

[Matt Sonnentag]

Will give that a try to see if it stays connected. How would one approach resolving such an issue?

 

[atomicturtle]

Funny you should mention that, I wrote a book about this very topic
http://www.amazon.com/Troubleshooting-Linux-Firewalls-Michael-Shinn/dp/0321227239

 

[Matt Sonnentag]

Thanks for the reply on the issue, I will put the book on my shopping list (don't know when I will have time to read though).

I did a test this morning - shut off csf, lfd and iptables. Exact same behavior - no change at all. Timed out after 30 minutes.

 

[Anders Jacobsen]

I had similar behaviour, but after loading ip_conntrack and ip_conntrack_ftp modules in the firewall and adding the established and related rules to the port, this went away.
We had instant timeouts though.

 

[raz3k]

I am having the same issue, added required modules in iptables-config, i am using apf.

Also added timeouts in proftpd conf and restarted xinetd, what should i try next?

Centos 5.6 x86_64, Plesk 9.5.4 latest updates added.