Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: Re: Reading a remote Filesystem

by arturo (Vicar)
on May 12, 2003 at 12:58 UTC ( #257415=note: print w/replies, xml ) Need Help??

in reply to Re: Reading a remote Filesystem
in thread Reading a remote Filesystem

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"

Replies are listed 'Best First'.
Re: Re: Re: Reading a remote Filesystem
by hardburn (Abbot) on May 12, 2003 at 14:16 UTC

    Reasons not to use FTP:

    1. Sends passwords in plaintext
    2. Multiple-port design is the cause of many headaches for firewall administrators
    3. 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

      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

      1. passwords aren't required for HTTP access; if they are, channel can be encrypted with SSL
      2. HTTP standardly uses three ports: port 80, port 80, and port 80. HTTPS uses port 443. Firewall administrators know these ports very well.
      3. 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"

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://257415]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2023-03-22 03:27 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (60 votes). Check out past polls.