FTP - LIST command stalls

24 posts / 0 new
Last post
#1 Sat, 07/12/2008 - 10:18
rduval

FTP - LIST command stalls

I'm using the latest virtualmin on a Centos 5 system with the default PROFTPD server.

I can access via ftp using Dreamweaver but not using filezilla or KompoZer.

They both login fine but when they do a LIST command nothing comes back, it just hangs and timesout.

Any idea why?

Rick

Sat, 07/12/2008 - 12:58
Joe
Joe's picture

Some FTP clients default to active FTP and some default to passive FTP. ProFTPd is configured, by default, to accept either...but many firewalls can break one or the other (oddly, as only one requires anything fancy to work).

Opening the high ports used by FTP is usually sufficient to resolve issues like this. I generally open <i>all</i> high ports (1024:65535), since many protocols rely on access to them...though you can also use the RELATED and ESTABLISHED stateful rules in iptables, if the offending firewall is a Linux iptables firewall.

--

Check out the forum guidelines!

Sat, 07/12/2008 - 13:26 (Reply to #2)
rduval

The only firewall is IPtables but Im still not sure that it's relavent.

I CAN connect to the machine and login fine it just hangs on the LIST command.

If it's IPtables causing the problem I shouldn't be able to login if the port is blocked should I?

Sat, 07/12/2008 - 13:33 (Reply to #3)
rduval

FYI, I disabled IPtables and it dis work then so obvisouly you're right but I still don't understand why? I'm not really comfortable opening all high ports...that seems pretty dangerous....

Sat, 07/12/2008 - 14:01 (Reply to #4)
Joe
Joe's picture

<div class='quote'>that seems pretty dangerous...</div>

That's me, always living dangerously!

Actually, it's almost entirely harmless. The only concerns with opening high ports is if you have databases or other services listening on public addresses (which is potentially quite dangerous). But, high ports are specifically <i>for</i> user-level, non-privileged communication--they're intended for everybody on the system to be able to use them for various services. Realistically, not many services use them or need them to be open, and thus it's irrelevant to have them open--it's a security null. Neither positive or negative, if you don't have any services that use them.

There's no need to be superstitious about firewalls and open ports--if you don't have a service running on a port, then opening it is meaningless. No one can exploit a non-existent service, and pretty much nothing in a reasonably configured web server system actually runs on a high port (and those that do, like databases, default to local addresses only). And, if you <i>have</i> configured a service to run on a high port on a public address, then presumably it's because you want to provide some sort of service to the world on that port...and you'd be opening it anyway! ;-)

Anyway, if you want to be specific, you could just open a small range of ports, and configure ProFTPd to only use those ports. By default, it will use any of the high ports--I think any that the client requests. But some folks go for just the ephemeral ports range, which is 49152:65534. Set ProFTPd to use this range with:

PassivePorts 49152 65534

And open iptables with:

iptables -I INPUT -p tcp --dport 49152:65534 -j ACCEPT
iptables-save

Again, you may prefer to instead use a stateful rule something like this:

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables-save

This doesn't open <i>any</i> ports. It allows all traffic that is related to some other connection that's already been allowed--so if you allow the the initial FTP connection on 21 or 20 it'll allow all subsequent requests that are related to that connection. At least, I think it'll work that way.

--

Check out the forum guidelines!

Mon, 07/14/2008 - 09:38 (Reply to #5)
ronald
ronald's picture

then you are left with a few options.

if it is a VPS then you have a control panel for it so that is easy. Either reboot fron there or ask the support to make ssh work.

if its your own box then ask the data center guys to reboot without the IPtable loaded or go to the data center if possible and do it yourself.

on centos its real easy. press I at startup and skip whatever you don't want to load.

another option is to get APC on the box to remotely reboot but that wont help much if the messed up iptable gets loaded at boot.. a RAC will help in those cases.

Mon, 07/14/2008 - 09:54 (Reply to #6)
ronald
ronald's picture

oh and dreamweaver by default uses active connection on port 21.
if Dreamweaver works and any other ftp program doesn't, then likely it is not something on the server but has something to do with the ftp program.

imo you should use winSCP and alternatively filezilla (and generate a ssh key. a local private key can be made by puttygen).

Thu, 07/17/2008 - 16:47 (Reply to #7)
rduval

It was filezilla I was using

Mon, 07/14/2008 - 13:30 (Reply to #8)
ronald
ronald's picture

i happen to have an openvz as well (as a slave-nameserver).
You can't do anything related to the kernel whereas under Xen you can do limited things assuming your host knows his stuff.

iptables for one is extremely limited under openvz and not really worth making a fuzz about on your system, unless you want to run services under different ports than the defaults.

On a side note: My experience with such a VPS is that RAM is extremely important as you do not have swap. Also the OS template your host is using as some have rpmforge enabled which can screw things up for Webmin in a nasty way.

Sun, 07/13/2008 - 03:34
rduval

I tried both of the above changes to iptables. first the top, restarted IPtable just to be safe and then the 2nd and restarted again. No LIST, same as before.

It only works if I run service iptables stop

Sun, 07/13/2008 - 03:43 (Reply to #10)
rduval

I tried forcing filezilla to active mode and it connects fine (wish I'd tried it before the IPtbles mods just to see which was doing the work) but Kompozer (amongshttp://www.virtualmin.com/components/com_fireboard/template/virtualmin/i...
Quick Reply t others) has only passive FTP...

Sun, 07/13/2008 - 03:45 (Reply to #11)
rduval

Oops... ignore the accidental paste in the middle of my last reply.

I tried to edit it after but got a an error from the board....

Sun, 07/13/2008 - 08:11 (Reply to #12)
andreychek

Do you have any additional luck if you enable FTP connection tracking? You can do that with:

/sbin/modprobe ip_conntrack_ftp

That may assist iptables in determining what connections are really from your FTP client and may help both active and passive modes to work.
-Eric

Sun, 07/13/2008 - 09:35 (Reply to #13)
rduval

Hey that worked! thanks!

will that remain enabled through a reboot or tdo I have to modify a conf somewhere?

Sun, 07/13/2008 - 12:36 (Reply to #14)
andreychek

No, it's not persistent, so you'd have to load it up again next time.

On CentOS/RHEL, it looks for a file called /etc/rc.modules. You can put modules you'd like to load in there like this:

echo &quot;/sbin/modprobe ip_conntrack_ftp&quot; &gt;&gt; /etc/rc.modules

Then next time you reboot, it should load that up (you can verify it with /sbin/lsmod).
-Eric

Sun, 07/13/2008 - 13:01 (Reply to #15)
andreychek

Oh, right, and you'll need to make that file executable:

chmod +x /etc/rc.modules

More details here: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-gui...

Sun, 07/13/2008 - 15:07 (Reply to #16)
rduval

It doesn't exist anywhere on the machine.

Should I just create it? Will it know to look for it automatically?

Sun, 07/13/2008 - 15:34 (Reply to #17)
andreychek

If you run this command:

grep -n rc.modules /etc/rc.sysinit

On my system I see:

354:if [ -f /etc/rc.modules ]; then
355: /etc/rc.modules

That is, in the RHEL/CentOS startup files, it looks for that file and when it exists, it executes it.

So, yeah, if you create that file on a RHEL/CentOS system, it'll be executed.

However, you might consider two other options:

1. /etc/modules.conf is also used for loading modules

2. If you're loading iptables via the system script, /etc/init.d/iptables, you can use the RHEL/CentOS way to load an iptables related module by editing /etc/sysconfig/iptables-config and adding &quot;ip_conntrack_ftp&quot; to the IPTABLES_MODULES section. It would then be loaded each time &quot;/etc/init.d/iptables start&quot; is executed.
-Eric

Sun, 07/13/2008 - 16:28 (Reply to #18)
rduval

Thanks much....I wonder why this isn't enabled by default?

Mon, 07/14/2008 - 06:57 (Reply to #19)
rduval

Actually this seems to have broken the machine in other ways... IMAP and POP stopped working so I took it out of the ip-tables-config and rebooted the virtual machine and now that's all back but now I can't ssh into the host it just times out. I think it broke IPtables on the host machine and I can't get into it to try rebooting it....

Mon, 07/14/2008 - 10:13 (Reply to #20)
Joe
Joe's picture

<div class='quote'>Actually this seems to have broken the machine in other ways... IMAP and POP stopped working so I took it out of the ip-tables-config and rebooted the virtual machine and now that's all back but now I can't ssh into the host it just times out. I think it broke IPtables on the host machine and I can't get into it to try rebooting it....</div>

Slow down. You're definitely conflating multiple, unrelated issues into one big &quot;OMGWTFBBQ!&quot; moment. ;-)

So, can you still login to Virtualmin? If so, browse to Webmin:Networking:Linux Firewall and stop the firewall while you figure out what went wrong.

But, I suspect the firewall has nothing to do with IMAP and POP. ip_conntrack_ftp is extremely specific about what it does, and certainly wouldn't break other protocols. I'm not sure what would cause the troubles you describe, except maybe simply not allowing access to the necessary ports in your iptables configuration.

Anyway, you'll need to narrow things down and tackle one problem at a time. Rebooting and random poking and prodding isn't really the right way to go about solving problems. Though I suppose a reboot will be necessary if you have no way to get into the box. ;-)

--

Check out the forum guidelines!

Mon, 07/14/2008 - 10:27 (Reply to #21)
rduval

I guess I need to clarify for a second...

Virtualmin is running on Centos5 virtual machine running under Openvz on a Centos5 host machine. The problem is that I can't ssh (putty) into the HOST since making these changes. Somehow they seem to have caused a problem with the firewall on the host.

I have removed the changes from the virtual machine and had a manual reboot done at the remote centre and now things are back to normal, I can access the hardware.

It seems to me that making the changes to the virtual machine somehow also affected the physical. Perhaps its an Open VZ problem?

Mon, 07/14/2008 - 10:47 (Reply to #22)
Joe
Joe's picture

So, the offending firewall is inside the virtual system?

You wouldn't (shouldn't) be able to insert modules into the host kernel from within the guest system--so I think I'm confused.

--

Check out the forum guidelines!

Mon, 07/14/2008 - 11:38 (Reply to #23)
rduval

Yes, the offending firewall is inside the virtual machine but what I'm saying is that making the mods in the Virtual machine also affected the physical host, but not is a good way.

I know that OpenVZ is &quot;containerized&quot; but it's not run as a completely separate entity to the best of my knowledge. perhaps its a bug of some sort.

Topic locked