Dunno all the whys and wherefores of not allowing remote FTP access to the system, but if you put a web server on the remote system and write a secure CGI, you can easily provide listings and downloads, perhaps by only allowing HTTP access from the machine that's currently serving up CGI (i.e. the one through which the users will access the site); even that's not necessary if you just give the web server access to the directories containing the files and let it list the files in the directories (this is very easy to do with Apache, for example).
Keeping it short and sweet, why not let HTTP be your remote file access protocol =)
If not P, what? Q maybe?
"Sidney Morgenbesser"
| [reply] |
Reasons not to use FTP:
- Sends passwords in plaintext
- Multiple-port design is the cause of many headaches for firewall administrators
- Generally considered insecure (though more for historical problems with server software than today's software)
Even if we accept that #3 is due to old and buggy software, #1 is reason enough to dump it. #2 isn't a big deal, since admins running firewalls tend to notice the problem the first week on the job and always keep it in mind from then on. However, it also is a problem for the firewall software itself (the early Linux 2.4 series packet filter had a bug where if you let FTP in, an attacker could get through any port).
Its not like there aren't better alterantives. In particular, the sftp subsystem that comes with OpenSSH is great. It's a one-line change to your sshd.config and works over the existing SSH port.
IMHO, HTTP is a poor subsitute for FTP, except as a quick-and-dirty document retrevial system. Uploading is hacked in, and its stateless nature has been the cause of hackery elsewhere.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
Note: All code is untested, unless otherwise stated
| [reply] |
Hmm, perhaps my intentions behind "whys and wherefores" were not clear; my point was merely that, depending on which reasons were operative in the present case, an HTTP-based approach might be appropriate. Let me address your points one by one, comparing an HTTP-based solution to (direct) FTP
- passwords aren't required for HTTP access; if they are, channel can be encrypted with SSL
- HTTP standardly uses three ports: port 80, port 80, and port 80. HTTPS uses port 443. Firewall administrators know these ports very well.
- Apache (e.g.) is pretty secure, even more so if you turn of unnecessary modules.
As far as the poster has so far told us, this system involves read-only access (see the original node title), so the upload issue is, AFAIK, moot (tho' I agree it would be a point against if r/w access is desired). The clients request the files from server A, which is supposed to be able to list and read the files on server B; my suggestion is that HTTP is a possible (given what we've been told so far) channel for A to talk to B.
My point in advocating HTTP as a possible approach is that it's pretty simple. It may be inappropriate, depending on the specifics of the system CodeJunkie is working with.
If not P, what? Q maybe?
"Sidney Morgenbesser"
| [reply] |
If you have ssh already installed, then you can get sftp with a one-line change to sshd.config. Add this:
Subsystem sftp sftp-server
And then restart sshd.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
