Firewall changes FTP filename?

[Reaper]

I am using CP NG AI R55 firewall and have following problem: When transfering files from inside network to outside, some of the file names chane. The last symbol in filename is replaced with underscore "_".

With tcpdump i have found out that the filename does change inside firewall, but i wonder why. Has anyone had such kind of problems?

[vijayant]

pl check if the rule allowing the FTP access is matching some URI Resource ? In URI is there something in the "replace"

[Reaper]

The rule only check source and destination address and matches ftp service...

227 is renamed into 22_

[Weaver]

Originally Posted by Reaper

The rule only check source and destination address and matches ftp service...

227 is renamed into 22_

Guess this answer is a little to late, anyhow, this behaviour is caused by SmartDefense. Also for example an "mkdir test227" will result in a new dir "test22_".

Smartdefense changest the string and reports a possible "FTP Bounce attack". I'm not sure but I think it doesn't look _where_ the 227 appears, but it interprets it as the 227 code for entering passive mode. Not very smart imho.

The only way I found to fix it is to make a new service, tcp port 21 with no application defined, which implies that also no other ftp checks will work. Does anyone have a better workaround?

[chillyjim]

There is a HF available from TAC for this "227" attack.

[inetd]

Does anybody know where it is?

[inetd]

The fix appears only to be for R55. I have got a box I am seeing it on R60.

They have not updated Smart Defense in a well, wondering if this has been patched there or not.

[RayPesek]

I see it occasionally on R61. Since we only accept files from known sources, I just set the SmartDefense bounce protection to "monitor only."

Ray

[Reaper]

Originally Posted by Weaver

Guess this answer is a little to late, anyhow, this behaviour is caused by SmartDefense. Also for example an "mkdir test227" will result in a new dir "test22_".

Smartdefense changest the string and reports a possible "FTP Bounce attack". I'm not sure but I think it doesn't look _where_ the 227 appears, but it interprets it as the 227 code for entering passive mode. Not very smart imho.

The only way I found to fix it is to make a new service, tcp port 21 with no application defined, which implies that also no other ftp checks will work. Does anyone have a better workaround?

Ok, thank you, now I at least know what's the causing that problem. Unfortunately I cannot create blank FTP service, firewall configuration is too complicated and that would surely break something else in FTP transfers.

I found another forum where the same problem was described:
IT Resource Center forums - strange FTP behaviour through firewall

Replacing 227 with 22_ everywhere sounds more like DumbDefense.

[fdamstra]

We ran into this on 12/27, as a number of vendors send us files that end in the date stamp.

This was supposedly fixed in R65 HFA2. I expect I won't know for sure until 02/27.

[cciesec2006]

I am in the information security business and I work for a financial service
company.

Prior to me joining the company, people were using ftp for transferring
data across the network. What the hell were they thinking?

I started enforcing the company security policy, i.e. no more ftp or telnet
over the network, even internally. Everything has to be ssh version 2
with AES256-cbc/sha-1. Instead of using FTP, I force everyone to
use SecurerFTP. If SSH is available, then SFTP is also available because
SFTP is a sub-system.

This is 2008, not 1998. FTP should not be used anywhere.

my 2c

[rokudan]

Originally Posted by cciesec2006

I am in the information security business and I work for a financial service
company.

Me too my friend!

Originally Posted by cciesec2006

Prior to me joining the company, people were using ftp for transferring
data across the network. What the hell were they thinking?

I started enforcing the company security policy, i.e. no more ftp or telnet
over the network, even internally. Everything has to be ssh version 2
with AES256-cbc/sha-1. Instead of using FTP, I force everyone to
use SecurerFTP. If SSH is available, then SFTP is also available because
SFTP is a sub-system.

This is 2008, not 1998. FTP should not be used anywhere.

my 2c

We have actually put in place several methods for data transfer, since we are actually a datacenter that hosts over 130 different clietns, we had to come up with ways to accomodate them all..

Secure FTP, SSH as well... However we customized an open source app that works through an https interface. We have found that most of our clients prefer that because, well.... They are not so computer inclined and a web browser makes things easy for them.

But I agree... Out with FTP for anything you want to keep secure.