Ftp "ftp bounce attack" on my personal firewall from client behind pfsense
-
Many years ago I wrote a script that would back-up data and ftp it to my house (in case the main office burned down). Its been working fine, until I upgraded our router at the office with pfsense.
What is weird, is it isn't pfsense that is dropping the packets-its my firewall at home. The exact firewall message is:
"ftp bounce attack, victim is 192.168.1.4:2266, action, DROP"
That is a little odd, as the IP address of the victim is actually the private IP address of the client behind pfsense.
Any guesses on this one?
Strangely enough, my webmaster who uses a lot of ftp sites isn't having any issues. (I did have to create a firewall with an alias list of all used ftp sites would only use a single gateway instead of load balance).
Thanks,
-Alan
-
A little further digging suggests the problem is Windows command line ftp doesn't support PASV mode…I might can work around this issue somehow.
However, since it used to work, I can only conclude that for whatever reason pfsense isn't rewriting the packets from the ftp client with its public IP address...
I am new to pfsense, and I am aware that there used to be an ftp proxy, or helper of some sort that is no longer included, but I was under the impression that the kernel was "ftp aware" and the proxy was no longer needed.
So I guess my question is, IS pfsense ftp aware and capable of rewriting client packets private address space with its public IP address? OR is it some side-effect of my configuration (possibly PURE NAT for reflection?).
I imagine no one else is having issues because all my other users use REAL ftp client programs; I'm the only one doing command line batch file ftp transfers...
Thanks again everyone,
-Alan
-
Dude, get a usable FTP client (ftp.exe from M$ is certainly NOT one) and read https://doc.pfsense.org/index.php/FTP_without_a_Proxy
Better yet, switch your backups to a less craptastic and more secure protocol.
-
Dude, get a usable FTP client (ftp.exe from M$ is certainly NOT one) and read https://doc.pfsense.org/index.php/FTP_without_a_Proxy
Better yet, switch your backups to a less craptastic and more secure protocol.
Funny enough, I have actually read that doc, but completely forgot about it. Yep, guess its time to ditch ftp.exe.
But thanks for your sarcasm. I am not ftping NSA secrets, or government documents here. I could give a rat's behind if someone is able to read the data during transfer.
The fact of the matter is, when you set something up and it "just works", its pretty counter productive to have to revisit it over and over again just because a "better method" comes along. I have WAAAAYYYYY to many responsibilities to "reinvent the wheel" when something "just works."
I will investigate the use of a secure transfer when I have SPARE time. In the mean time, I will see if I can switch to a command line ftp program that supports PASV mode, and convert my batch files.
-Alan
-EDIT- Guess I am just old, grumpy, and set in my ways, but at my age, I don't have time to waste reinventing the better mouse trap.
-
when something better comes along its not reinventing a mouse trap, its dropping deprecated crap for something better.
There a lots and lots of backup solutions that don't have anything to do with ftp. Crashplan for 1 example. You pick your folders you want to backup and forget about it. These files will be backed up very quickly once a new file is put in place, not when your ftp job kicks.
And its way more secure to boot. Ftp should of died off years ago, another option is to just move to sftp which can be scripted as well and doesn't have to deal with control and data ports and passive or active connections.
-
when something better comes along its not reinventing a mouse trap, its dropping deprecated crap for something better.
… Ftp should of died off years ago...
I am not going to get into a pissing match over this, but what I have quoted above is your OPINION, not fact. Again, maybe I am just too old, but I come from a generation where you don't just throw something away because it is "deprecated crap".
I came here with a problem, and just needed a solution-its that simple. While I do appreciate alternative approaches, the method of transfer is only ONE variable in the equation. One that is solely being focused on. As I said, I put this in place YEARS ago, maybe even a decade ago, and it "just worked", until now. I will investigate a better approach when I have the SPARE TIME; for now, changing the ftp client is the quickest, easiest down and dirty solution.
Now, I am new here. However, I am coming to GREATLY love pfsense. Although I haven't posted much, I have lurked a LOT, and have seen a level of arrogance here that is a little disconcerting that I never saw on my previous vendor's forum.
The general consensus is not to use ftp. I get it. I have seen that stated in the docs more than once. As I mentioned, I had forgot about the doc linked above. HOWEVER, just because it is YOUR opinion that ftp is "deprecated crap", does not make that fact. The fact IS, it is still widely used out in the wild. I saw another ftp thread where the OP was attacked over this very same thing. He had users on his lan than needed access to ftp, and was told basically "don't use ftp" or to configure his server. Since his users were connecting to remote ftp sites, NEITHER was a solution.
Now in my case, no one is forcing its use, and as I said I will investigate a better method later. But some of you need to get off your high horse and drop the "I'm holier than thou" attitudes. Kindly offer alternatives, and leave it at that. But don't tout your opinions as gospel.
Although this has no bearing on the subject at hand, you want to talk about things that should be "deprecated crap", then how about NAT itself. In my opinion, its an abomination. It was a band-aid to work around the short comings of a network that during its design they did not anticipate the sheer explosion of its popularity, and the number of connected devices that it would eventually see. If ANYTHING should have died long ago, it is NAT itself. But that is just MY opinion.
Off my soapbox. Have a GREAT DAY.
-Alan
-
ftp uses command channel which messes up stuff. It's simple and free to setup SFTP.
-
FWIW-Its all fixed.
I apologize if I got snarky earlier. My goal was not to have to spend another dime on yet another piece of equipment, software, or replace anything and use what was already in place. Also, I didn't want to waste any more time than necessary fixing something that had previously been working for years. So much for not wasting time-took me quite a while to figure it all out.
In the end the easy fix was to switch the ftp client. But even after that I STILL ran into problems. I then set the PASV port range on my ftp server, and opened those ports in my personal firewall, and voila…it worked perfectly.
Yes, yes, I know...this should be pretty common knowledge. But I am left scratching my head as to why I NEVER had to forward the passive range before. That part I do not understand. Only thing I can come up with is both the firewall at work, AND at home were from the same vendor. Maybe they were just more "FTP aware" than pfsense is. I am not knocking pfsense for that. FTP is a damn tricky thing to get working.
BUT, as a bonus-I took the suggestions here and ran with it...I setup my transfers for FTPS, so now everything is encrypted. Luckily the client I used (WinSCP) supports scripting/command line batch files and encryption, and my server of course supports TLS as well.
All is well.
-Alan
-
"ftp bounce attack, victim is 192.168.1.4:2266, action, DROP"
Opening and forwarding the ports would be one thing, but then setting up rules that are matching
exactly this ports and services is also a must be. Could it be that only the firewall rules are not matching
this behavior?Using FTP.exe imply to me that you were also able to use something likes FileZilla Server
software because it is also free of charge and offers on top S/FTP service.Also a script that opens a SSH connection to your home firewall would be nice running and able to do.
