topic Re: strange FTP behaviour through firewall in Operating System - HP-UX

strange FTP behaviour through firewall

Adisuria Wangsadinata_1 — Sun, 02 Dec 2007 12:13:40 GMT

Hi All,

I have a very strange ftp problem dealing with one filename.

I have one system I call systemA (HPUX) and systemB (I think it is also HPUX). systemA have to pull data from systemB with FTP through 2 firewalls. (systemB manage by other department).

The system was being fine for more than 2 years.

One strange thing just happened 2 days ago, every time we want to list a filename ama.0227, this is what it will show:
ftp> ls ama.0227
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.79,64485) (0 bytes).
ama.022_: No such file or directory
226 ASCII Transfer complete.

You notice the response was ama.022_ not such file or directory (please notice that the filename it response is with underscore)

but if I used wildcard here is the result:
ftp> ls ama.0227*
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.79,64489) (0 bytes).
-r--r--r-- 1 root root 15123904 Nov 29 18:55 ama.0227
226 ASCII Transfer complete.

Then of course my logic said that it could be that file on systemB had a space or hidden character.

But then the sysadmin from systemB claimed that when they do the ls -l ama.0227 locally without any wild character it will show the file correctly. I was confused and could not believe him.

Then I asked them to rename the file to ama.00290 then I tried again.

ftp> ls ama.0290
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.169,64343) (0 bytes).
-r--r--r-- 1 root root 15690744 Nov 30 18:55 ama.0290

expected result, then I tried to see whether the there was still a file ama.0227:

ftp> ls ama.02*
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.169,64129) (0 bytes).
... [I chopped down the list]
-r--r--r-- 1 root root 15292424 Nov 30 18:30 ama.0222
-r--r--r-- 1 root root 16013996 Nov 30 18:35 ama.0223
-r--r--r-- 1 root root 15698404 Nov 30 18:40 ama.0224
-r--r--r-- 1 root root 15709128 Nov 30 18:45 ama.0225
-r--r--r-- 1 root root 15940460 Nov 30 18:50 ama.0226
-r--r--r-- 1 root root 16013996 Nov 30 19:00 ama.0228
-r--r--r-- 1 root root 16082936 Nov
... [I chopped down the list]
226 ASCII Transfer complete.

As you can see there was no ama.0227 file.
but then I tested this:

tp> ls ama.0227
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.169,64214) (0 bytes).
ama.022_: No such file or directory

It is very strange that its response was "ama.022_: No such file or directory" even the file was not there. Because if tested to list a file that was never really there, the result was normal:

ftp> ls ama.02278
200 PORT command successful.
150 ASCII data connection for /bin/ls (10.31.90.169,64215) (0 bytes).
ama.02278: No such file or directory
226 ASCII Transfer complete.

Now I begin to suspect the PROBLEM was on the FIREWALL.

Now I tested again to do a same thing from systemA to a diff system (it is not hpux), called it systemC. The systemC also connected to systemA thorugh the same firewall (but it has totally different file name, so no ama.0227 file)

Then I did a similar to systemC like before:

ftp> ls ama.0227
200 PORT command successful.
150 Opening data connection for ama.022_ (10.31.90.79,60555)

Total of 0 files, 0/0 blocks
226 LIST Directory transfer complete.
ftp> ls ama.0226
200 PORT command successful.
150 Opening data connection for ama.0226 (10.31.90.79,60569)

Total of 0 files, 0/0 blocks
226 LIST Directory transfer complete.

Showed the expected result since the file was not there. then I tried with ama.0227 that never been on systemC and the result:

ftp> ls ama.0227
200 PORT command successful.
150 Opening data connection for ama.022_ (10.31.90.79,60555)

Total of 0 files, 0/0 blocks

I produced a simillar result like systemB, reponse with ama.022_ .

I did the same thing to the systems that were not connected through fire wall, the result was normal as expected.

Now I suspect more and more to the firewall.

The file being regenerated everyday then the systemA needs to pull it everyday.
But I am not familiar with the firewall, and it was manage by other dept.

So my questions are:
o Do you think it is a firewall problem?
o If it is a firewall problem what should ask the network administrator to reset?
o Is it the file being cached in firewall?
o Or any other suggestion?

Thank you.

Iwan Tamimi

Re: strange FTP behaviour through firewall

F Verschuren — Sun, 02 Dec 2007 19:20:23 GMT

hi,
the problem looks likes special caracters in the file name,

can you do a ls -l > filename
view filename

to see if there are special caracters in the file?

ps can you alsow login to the server and check if there ls response is the same?

Re: strange FTP behaviour through firewall

Hasan Atasoy — Sun, 02 Dec 2007 19:24:27 GMT

you can lookat for strange characters in filename by "cat -v filename"

Hasan.

Re: strange FTP behaviour through firewall

Dennis Handly — Sun, 02 Dec 2007 19:26:02 GMT

>F Verschuren: the problem looks likes special characters in the file name

If there are special characters you need to use ls -lb.
I'm not sure that explains why "ls ama.0227" returns "ama.022_", unless the "7" key is broken?

Re: strange FTP behaviour through firewall

Adisuria Wangsadinata_1 — Mon, 03 Dec 2007 01:51:22 GMT

Hi All,

Thanks for the respones.

It is not hidden character on the ftp server side because I ask the sysadmin to check.

And like I explained even I go to other ftp server (I think the server is VMS) that does not have that file at all will respones with ama.022_ when did the ls ama.227 on from ftp prompt.

I found out further even I just did ls 227 on the ftp client prompt to the server on the other serfer the response will be 22_ :

ftp> ls 227
200 PORT command successful.
150 Opening data connection for 022_ (10.31.90.169,54785)

Total of 0 files, 0/0 blocks
226 LIST Directory transfer complete.

So looks like the firewall interpreted someting with 227. but i still understand.

Any explanation?

Regards,

Iwan Tamimi

Re: strange FTP behaviour through firewall

Dennis Handly — Tue, 04 Dec 2007 00:02:03 GMT

>And like I explained even I go to other ftp server (I think the server is VMS) that does not have that file at all will responses with ama.022_ when did the ls ama.227 on from ftp prompt.

It looks like you're right. For every file that doesn't exist, when it prints the error the last char seems to be changed to "_".

I don't think it has anything to do with your firewall, just ftp on the server.

Re: strange FTP behaviour through firewall

LordInfidel — Fri, 11 Jan 2008 20:31:34 GMT

Well Iwan, I can assure you it is not a firewall issue. firewalls do allot of things, changing filenames is typically not one of them.

There is an issue with some ftp servers out there when a filename has 227 at the end of it.

Interesting, 227 is the passive port command for ftp.

This is not limited to just hpux, but also microsofts IIS 6.0 ftp (but not all versions of it).

What it looks like is that the ftp binary get's confused when it sees a file with 227 at the end of it as it being a pasv command and "renames" the file as 22_.

It does not matter what the length of the filename is, just as long as 227 is the last 3 characters.

I don't have a resolution right now except for changing the filename to something other then 227.

LordInfidel

Re: strange FTP behaviour through firewall

LordInfidel — Fri, 11 Jan 2008 20:32:47 GMT

Re: strange FTP behaviour through firewall

LordInfidel — Fri, 11 Jan 2008 21:37:47 GMT

Iwan,

Actually I need to apologize. In my scenario it was the firewall, but it was not really renaming the files.

Check with your firewall team and ask if they are running checkpoint ngx. If they are, have them check if smartdefense application intelligence "FTP" "FTP Bounce" is checked off.

If it is, have them set it to monitor only.

SmartDefense somehow corresponds 227 strictly to passive mode.

Note- this is NOT a normal operation of firewalls. Normally, firewalls do not do content inspection at layer 5+, they usually operate at layers 3/4.

Again I apologize.