FTP partially blocked-- how to trace?

Hello,

I use various programs to such as Ultraedit to upload files via FTP. On one site, all of a sudden I began having a mysterious problem. I can log onto the site, but I cannot do anything alse. I am able to get the name of the directory I am in but I can't get any other directory information, change directories or access any files.

I am only having this problem on one site. All my programs, smartFTP, WSFTP, HtmlKit , NVU were effected at the same time, except WinSCP which still works fine. The Server tech had changed some firewall settings but has been unable to figure out what the problem is. I'm still suspect it has something to do with the firewall settings on the server. It only seems to effect my account, It doesn't make a difference if I use passive or not passive, or if I take down all firewalls on my end. I double checked that it is not something on my computer by using another computer, albeit from the same location. It had the same problem.

Here is one attempt by htmlKit, in non passive mode:

HtmlKit: FTP > PWD FTP < 257 "/home/trt/www/html/website.com" is your current location FTP > PORT 192,168,1,101,4,110 FTP < 500 Unknown command FTP > 500 Unknown command FTP - Could not get directory list. (933) FTP > CWD /home/trt/www/html/website.com FTP < 250 OK. Current directory is /home/bvb/www/html/website.com

Any Idea what it could be ?

I had the idea that if I could possibly see the requests that WinSCP and UltraEdit send to the server, I could compare them and and possibly see what is working and what is not. If it were http traffic, I would use Charles

an HTTP proxy / HTTP monitor. Is there an FTP equivilant ?

Thanks.

Red

The carbonbased lifeform red inspired comp.security.firewalls with:

Sounds like a (Unix) permission problem. Try 'ls -al' in that directory and see if this and other directories have the 'x' (search bit) and 'r' (read bit) set for the user and group.

Theo

In message at 10:55:33 on Sun, 19 Aug 2007, Theo v. Werkhoven wrote

The OP probably won't know what user and group are. Permissions could be something like rwxrwxrwx or r--r--r-- for example The first 3 characters refer to user, the next 3 the group and the final

3 "other users"

Doesn't he want to be looking at the permissions on the directory itself, so he needs to go up to the parent directory - possibly won't be able to do that unless he has access to the full directory structure

Anyway, I had similar experiences to the OP when I started using Kapersky, and I've never got to the bottom of it.

comp.security.firewalls with:

I figured it out. Once I realized that WinSCP works because it uses a secure protocol, it was obvious that someone must have changed something on the server to only allow secure FTP. When I changed the protocol in Ultraedit from SCP to SFTP -SSH2 it fixed the problem.

As a test, I changed the protocol in WinSCP from SFTP to SCP and it still worked. So the permission denials were not based on using SCP as an FTP protocol - they were based on SSH

Then I changed the SSH to SSH1 and it didn't work anymore.

I'm not sure this has anything to do with SSH but the permissions of the root folder are rwxr-xr-x

There's one thing that still doesn't make sense though:

Other servers that I FTP to also require SSH2. If I try to log onto them using WinSCP with SSH1, I can't even log on. But if I uncheck SFTP -SSH2 in UltraEdit, it still works fine. I'm not sure what's going on there.

Why does not having SFTP -SSH2 checked work fine on one server that requires SSH2 but not another server that also requires SSH2. I would think the difference would be in the FTP protocol(SFTP vs SCP) but as I said SFTP doesn't seem to be required on the same server that requires that SFTP -SSH2 be checked.

It works well enough that I can get back to work, but its little things like that that bug me no end.

comp.security.firewalls with:

I went to take a walk and it suddenly occurred to me that not having SFTP -SSH2 checked doesn't mean it uses SSH1, it means there is no SSH. No SSH is allowed, but SSH1 is not allowed. Now it makes sense!

Your client tries active mode and that doesn't work.

scp or sftp uses ssh and so overcomes the common ftp protocol crap.

The log of the ftp session shown below is quite clear.

ftp active mode (that is what your client tries at least in the example you gave) doesn't work.

ftp active mode (that i what your client tried in this case) doesn't work.

If it is really correct that passive mode doesn't work either it could that the ftp server offers ftp active mode only (I'd call that a braindead configuration for an ftp server) and a filter in front of the server permits ftp passive mode only. Use a sniffer like tcpdump and/or wireshark to find out which connections are trying to be established.

gives you an idea about the difference between active and passive mode and for what to look for in the log of the sniffer.

Wolfgang