Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As an alternative that may be easier to setup and is a bit more secure out of the box, I would suggest vsftpd. If you are very familiar with Apache though, proftpd will be a snap, the config files are very similar
As with anything else, linux/gnu/open-souce, there probably is... I don't know how offhand. I have a very strict MO for the way I do things and I use either DMZ's or dedicated hardware to perform those sorts of protective measures for the boxes themselves. I am always a bit wary of asking software to perform alot of security for themselves. Still it is a very good question and I would be interested in what anyone knows about this.
I need a signature...perhaps something like this...
Be polite, courteous, and professional in every interaction, on every level, with every type of individual. But ALWAYS have a plan for killing anyone you meet. ..from the United States Marine Corps battle doctrine
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
The problem is the DMZ: I have an internal IP address for the dedicated FTP server, and the firewall routes you to the server. However, when going into passive mode, the server will sent out your internal IP-address. This one is (of course) not known on the Net.
Proftpd has the feature to add Masqerading in the config: Just type your external IP address there, and it will reply with the external IP address for connections.
So, when using the DMZ, I still have the same problem. Or do you have a different setup that works in both normal as passive mode?
<Signatures are great, I have a signature, so now I am great too ? >
hmm, sounds as if your idea of a DMZ is different than mine. If I have a box that needs to be net accessible it NEVER goes on the inside, instead it will be something like this:
router/firewall-->live service box (ftp,web etc.)-->firewall-->internal lan
However, if you are running a small biz or SOHO this is a bit much so you might want to do something like what you are doing, I just get the heebie jeebies letting people directly into my LAN (albeit via port forwarding or masquerading).
<I am great...period. You are correct, the signature is unecessary >
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
Quote:
Originally posted by osfestus router/firewall-->live service box (ftp,web etc.)-->firewall-->internal lan
Sorry, was away for a few hrs: IMHO: your FTP box is on the DMZ...
(Same as mine)
However, I have 1 outside IP Address (Assigned to router/firewall).
(Lets call it Red, to stay in terms) This connects to my DMZ.
Then I have a DMZ-network with "internal" ip addresses.
This DMZ addresses I call Orange. (Accessible from Internet, as well as from my lan)
Then I have Firewall / Router with my internal LAN behind it. (The green zone...)
The red router has an external IP, lets say, 123.456.789.1
then the DMZ has multiple servers in it, let say IP Range: 192.168.1.0
then the second firewall has (lets make it crazy: ) 10.2.3.1, and my LAN has the same range: 10.2.3.0
Thats my idea of a DMZ. If i am wrong, Please correct me.. Im not really familiar with it.... (and eager to learn, gimme input input input input input input input)
Now the FTP part: someone connects to my ftp server, and requests passive mode. the server will respond with its ip address and a port to connect to (basic FTP process). Then it will give the caller for example: 192.16.1.2:31600 BANG!!!!
There goes the error! I can't be reached through that address, because its my "orange" one... So (in this example) i set masquerading for proftp to 123.456.789.1 Then it will respond (as it should) with 123.456.789.1:31600
And this is indeed my external (red) address...
(Long story, but I hope you get my point of view...)
Now to the question again: I'm always interested in learning and new techniques... How did you manage it, or is your setup completely different than described above?
Then second part:
Quote:
Originally posted by osfestus
<I am great...period. You are correct, the signature is unecessary >
Ok, that sounds fine except that traditionally the "live" boxes are given live ip's specifically to avoid the types of problems you are encountering. Of course, there are arguments against doing this, and if you don't have more than one static ip it's moot. Sounds like you have a well thought out setup. I don't have any criticisms and now I see precisely why the masquerade is important. What is odd though is that your ftp servers address is not being translated back to the red routers external interface address. I don't use port forwarding myself, but it would seem logical that the outgoing traffic would be appended with red's real ip..... er, you know, NAT. Then you could forego port forwarding and use cnames to refer to the different services running inside the orange zones. It would undoubtedly simplify your firewall set for red. What kind of device is red (if you don't mind saying?)?
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
The red is a black Nokia firewall..
The problem however is that the FTP protocol can't rely on NAT... For as far as i dug into it, what basically happens is this:
client connects on port 21. (forwarded to orange)
orange ftp-server send reply back to open data channel on port 20. (blocked by clients firewall in some cases)
Client asks for passive mode:
server responses with port to connect to... (Check this when using a ftp client, you will see something like 123.456.789.1.3600.4800 (last two numbers representing a port number, this is some kind of calculation), first 4 numbers being the ip address of the server.
Since this is send as a "plain text" answer, the firewall will not recognize this as an IP address (and thus not translate). Now, the client's software will try to connect to the IP and Port number, sent by the server in "plain text".
This is the reason why masquerading should be done by the server: it has to send plain text with the correct IP address...
Note: This only happens when a data-connection cannot be established, so you have to use passive.
So i think the problem is not in the firewall on my side, but on the firewall on the other side: that one will not allow my server to establish a connection to the client. (This connection is setup by the server)
So, what did I do with my ftpserver? I configured it to masqerade its address to my external IP address, and set a passive port-range to only one port (i.e. 2100) . Then I setup my firewall to pass that port (2100) to my FTP server. Now the client gets a plain text reply: 123.456.789.1.2100.1 (whatever the logic in these last two numbers is), and the client will establish a passive connection on port 2100. This port is redirected to my orange FTP server..
Tricks tricks tricks... But I think a lot of people will recognize this issue...
That makes sense. Sounds like a real pain. I think you are probably correct about the way other firewalls are handling port negotiation between your ftp server and the remote client. The issue offhand is that you are no longer doing passive transfers, you simply trick the client and server into using a single port. I know alot will say this kills the whole point of passive transfers, and security, but alot of admins I know don't like opening a couple thousand ports on their firewalls either. For one I would rather protect a couple of ports and one stream. Hey, if you are using ftp to transfer banking info and credit card info you are asking for it anyway. If you are storing programs and just general stuff, there is no big deal. Your average crack-boy is not going to go through the hassle of tapping your data stream to pull things he can easily get anyway off the wire. As far as using ftp and its associated ports to compromise your system, if you are attentive to your logs, permissions, and firewalling, you aren't gonna get much grief from this. Sounds like you are pretty well versed and very attentive to your system.
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
Wow, a compliment!! Thanks man!!
I almost start to *blush*...
Im still a bit of a newbie in this matter, but I try to learn as much as possible. And why not let others use the benefits of my knowledge?
Share your knowledge: don't try to invent the wheel again, just make it a better one!
But, Although its nice to discuss all this options, i think that dvong is indeed confused or dazzled with technical details.... (Yep, I did it again!!!)
I will get some sleep now, and be back tomorrw, to see if my other questions were answered! Great forum....
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.