How safe are FTP servers? - Security

This is a discussion on How safe are FTP servers? - Security ; Ertugrul Soeylemez wrote: > You should at least force SSL and authenticate that way. FTP is the > worst protocol to send files through. Many would disagree with you on that. FTP was _designed_ for transferring files, after all. It ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: How safe are FTP servers?

  1. Re: How safe are FTP servers?

    Ertugrul Soeylemez wrote:

    > You should at least force SSL and authenticate that way. FTP is the
    > worst protocol to send files through.


    Many would disagree with you on that. FTP was _designed_ for transferring
    files, after all. It *is*, however, the worst protocol to send user
    authentication through ...

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  2. Re: How safe are FTP servers?

    In article <464da6c2$0$640$5a6aecb4@news.aaisp.net.uk>,
    Tim Southerwood wrote:

    > I never worked out why FTP over SSL or TLS never seemed to catch on.


    Partly because it's a PITA when firewalls are involved.

    The FTP protocol is a little bizarre in its use of ports. The server
    listens for connections on port 21. But when a session is established,
    the data traffic flows on another port. Depending on whether you're
    using active or passive mode, either the client or the server starts
    listening on a port >1024, and sends a message to the other end over the
    control session to tell it which port to use.

    This caused a problem when people got paranoid and started installing
    firewalls. If the FTP session was "active" mode (which used to be a
    common default), the "client" started acting like a "server", in the
    sense that it started listening on some random port > 1024. Since most
    client firewalls thought that a program suddenly starting to listen on
    some random port was probably not a good thing, this broke FTP.

    So "passive" mode was suggested as an alternative. This meant that the
    client didn't have to act like a server. The server would open the port
    for the data connection, and tell the client to use it. In many cases,
    this wasn't much better, because a lot of server firewalls didn't like
    the idea of random ports suddenly opening up.

    Then firewalls got smart. They started monitoring the traffic on port
    21, and when they saw the "port" command on the FTP session advising the
    other end which port to connect to, they would dynamically open that
    port just for the appropriate IP address, for the duration of that
    session.

    Then people got even more paranoid and turned on TLS in their FTP
    sessions, encrypting all the traffic, or at least all the traffic on the
    control sessions. Now the smart firewalls couldn't eavesdrop any more,
    so they were no longer able to work their magic to compensate for FTP's
    strange use of multiple ports.

  3. Re: How safe are FTP servers?

    Sylvain Robitaille (07-05-21 04:26:54):

    > > You should at least force SSL and authenticate that way. FTP is the
    > > worst protocol to send files through.

    >
    > Many would disagree with you on that. FTP was _designed_ for
    > transferring files, after all. It *is*, however, the worst protocol
    > to send user authentication through ...


    I'm unable to find a worse protocol. Unclear specifications (like how
    to interpret file listings) and a nightmare for firewalled hosts.
    Further it is pretty limited by itself. You will do a lot of useful
    stuff through extensions, and that's bad either.

    It was designed for that purpose when there were no other general
    purpose alternatives, but it's showing its age already.


    Regards,
    Ertugrul Söylemez.


    --
    Security is the one concept, which makes things in your life stay as
    they are. Otto is a man, who is afraid of changes in his life; so
    naturally he does not employ security.

  4. Re: How safe are FTP servers?

    On 21 May, 05:26, Sylvain Robitaille wrote:
    > Ertugrul Soeylemez wrote:
    > > You should at least force SSL and authenticate that way. FTP is the
    > > worst protocol to send files through.

    >
    > Many would disagree with you on that. FTP was _designed_ for transferring
    > files, after all. It *is*, however, the worst protocol to send user
    > authentication through ...


    And horses were designed for people to ride on. Doesn't mean they're a
    good vehicle to commute to the office in, though: the available tools
    have evolved considerably. When FTP was invented, the world of
    security and firewalls and software were rather different. It's become
    stable, but from a security standpoint, it's a very bad idea to use
    for handling any protect content, and it's a pain in the neck for
    firewalls to cope with.

    I've had good success migrating companies off of it to HTTPS for
    download and HTTPS/WebDAV for upload.


  5. Re: How safe are FTP servers?

    Nico wrote:

    > And horses were designed for people to ride on.


    I don't think so, no ... That is about as correct as "NNTP was designed
    to transfer binary content". It wasn't, but people adapted it, just as
    they adapted horses.

    > ... it's a very bad idea to use for handling any protect content, ...


    As I said in my previous post, it's an awful protocol for exchanging
    authentication information with (and I agree with you regarding *any*
    sensitive content).

    > I've had good success migrating companies off of it to HTTPS for
    > download and HTTPS/WebDAV for upload.


    You migrate people *from* FTP to WebDAV, in the name of security? I'll
    grant that you've already said you're using HTTPS which is obviously the
    right way to go ...

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  6. Re: How safe are FTP servers?

    Sylvain Robitaille (07-05-28 01:34:26):

    > > I've had good success migrating companies off of it to HTTPS for
    > > download and HTTPS/WebDAV for upload.

    >
    > You migrate people *from* FTP to WebDAV, in the name of security?
    > I'll grant that you've already said you're using HTTPS which is
    > obviously the right way to go ...


    Probably that's even too complicated. For most applications, there are
    much easier alternatives, which are equivalently secure.


    Regards,
    Ertugrul Söylemez.


    --
    Security is the one concept, which makes things in your life stay as
    they are. Otto is a man, who is afraid of changes in his life; so
    naturally he does not employ security.

  7. Re: How safe are FTP servers?

    >>>>> "Matt" == Matt Simpson writes:

    Matt> The FTP protocol is a little bizarre in its use of ports.
    Matt> The server listens for connections on port 21. But when a
    Matt> session is established, the data traffic flows on another
    Matt> port.

    This is a valid reason for this design:

    The FTP is designed with command and data using different TCP
    connections. This enables the following scenario: I use client
    computer C and run a FTP client to connect to server A, over a slow
    WAN link. I also instruct the same FTP client process to connect to
    server B, over a slow WAN link, too. Between A and B is a fast fibre
    network. I can order my FTP client program to instruct A to directly
    transfer a file to B, or vice versa. That transfer is rapid, because
    goes through a TCP connection established between A and B _directly_,
    which are connected via a fast network. The file data doesn't go
    through C at all.

    In other words, 3 TCP connections exist in this scenario:

    1) C connects to A (command channel)
    2) C connects to B (command channel)
    3) connections between A and B (file data channel)

    This would be impossible if FTP used just one TCP connection/port and
    multiplexes it for both command and data.



    I remember seeing a nice diagram depicting this scenario in the RFC
    for FTP, which I read more than a decade ago.


    --
    Lee Sau Dan u ~{@nJX6X~}

    E-mail: danlee@informatik.uni-freiburg.de
    Home page: http://www.informatik.uni-freiburg.de/~danlee

  8. Good secure file transfer, was Re: How safe are FTP servers?

    On 28 May, 02:50, Ertugrul Soeylemez wrote:
    > Sylvain Robitaille (07-05-28 01:34:26):
    >
    > > > I've had good success migrating companies off of it to HTTPS for
    > > > download and HTTPS/WebDAV for upload.

    >
    > > You migrate people *from* FTP to WebDAV, in the name of security?
    > > I'll grant that you've already said you're using HTTPS which is
    > > obviously the right way to go ...

    >
    > Probably that's even too complicated. For most applications, there are
    > much easier alternatives, which are equivalently secure.
    >
    > Regards,
    > Ertugrul Sylemez.


    Oh? For download, HTTPS is fine and well supported, and has plenty of
    clients available for the scriptable, command line, or graphical
    interfaces. And unlike FTP, requires only a single firewall port
    without complexities to handle the traffic. And most web servers
    already have the "restrict user to single directory access", very
    flexible controls over symlink handling and directory browsability,
    multiple well-supported user authentication techniques, etc.

    FTP has some of those, but breaks down on the clear-text user login
    and password handling. And the mutliple ports causes real problems
    with firewalls and proxies set up to be quite fascist.

    SSH/SFTP/SCP have very, very serious flaws in controlling user access
    to the server's file system. They work well for certain operations:
    having a command line browseable, more secure tool than FTP is good.
    But The lack of a chroot cage to hide server content, such as /etc/
    passwd or other configuratoins, and the difficulty of preventing shell
    access for SSH users, all lead to some real risks in running it on a
    server. There are some SSH servers that provide this (RunSCP comes to
    mind), but they're nowhere near as commonly deployed as plain old
    OpenSSH.


  9. Re: Good secure file transfer, was Re: How safe are FTP servers?

    Nico writes:

    > SSH/SFTP/SCP have very, very serious flaws in controlling user access
    > to the server's file system.


    Really? I'd like to hear what these flaws are for ssh/scp.

    > They work well for certain operations:
    > having a command line browseable, more secure tool than FTP is good.
    > But The lack of a chroot cage


    What's a chroot cage?
    --
    % Randy Yates % "Ticket to the moon, flight leaves here today
    %% Fuquay-Varina, NC % from Satellite 2"
    %%% 919-577-9882 % 'Ticket To The Moon'
    %%%% % *Time*, Electric Light Orchestra
    http://home.earthlink.net/~yatescr

  10. Re: Good secure file transfer, was Re: How safe are FTP servers?

    Randy Yates wrote:

    > Nico writes:
    >
    >> SSH/SFTP/SCP have very, very serious flaws in controlling user access
    >> to the server's file system.

    >
    > Really? I'd like to hear what these flaws are for ssh/scp.


    He means that unlike typical FTP or Web servers, one cannot choose easily to
    present a sub directory as browseable only SFTP/SCP users (or a particular
    user).

    SFTP/SCP is excellent for machine where the normal shell users use their own
    accounts top remotely copy/mount files/filesystems.

    >> They work well for certain operations:
    >> having a command line browseable, more secure tool than FTP is good.
    >> But The lack of a chroot cage

    >
    > What's a chroot cage?


    One where say:

    user@host:/ => host:/export/somewhere/pub/ftp

    and (from the client connection):

    cd .. doesn't get you out of the cage.

    Tim

  11. Re: Good secure file transfer, was Re: How safe are FTP servers?

    Tim S writes:
    > [...]
    > He means ...


    Thanks for the clarifications, Tim. Got it.
    --
    % Randy Yates % "She tells me that she likes me very much,
    %% Fuquay-Varina, NC % but when I try to touch, she makes it
    %%% 919-577-9882 % all too clear."
    %%%% % 'Yours Truly, 2095', *Time*, ELO
    http://home.earthlink.net/~yatescr

  12. Re: Good secure file transfer, was Re: How safe are FTP servers?

    Randy Yates wrote:

    > Tim S writes:
    >> [...]
    >> He means ...

    >
    > Thanks for the clarifications, Tim. Got it.


    Heh - sorry about the typos - I'm surprised anyone got anything out of that!

    (Not feeling well today)

  13. Re: Good secure file transfer, was Re: How safe are FTP servers?

    Nico (07-05-28 02:19:45):

    > > > > I've had good success migrating companies off of it to HTTPS for
    > > > > download and HTTPS/WebDAV for upload.
    > > >
    > > > You migrate people *from* FTP to WebDAV, in the name of security?
    > > > I'll grant that you've already said you're using HTTPS which is
    > > > obviously the right way to go ...

    > >
    > > Probably that's even too complicated. For most applications, there
    > > are much easier alternatives, which are equivalently secure.

    >
    > Oh? For download, HTTPS is fine and well supported, and has plenty of
    > clients available for the scriptable, command line, or graphical
    > interfaces. And unlike FTP, requires only a single firewall port
    > without complexities to handle the traffic. And most web servers
    > already have the "restrict user to single directory access", very
    > flexible controls over symlink handling and directory browsability,
    > multiple well-supported user authentication techniques, etc.


    The user authentication is what I'm referring to. Cryptographical
    authentication via HTTPS has some remarkable difficulties compared to
    other protocols. This is because HTTPS is mainly used to authenticate
    servers, not users.


    > FTP has some of those, but breaks down on the clear-text user login
    > and password handling. And the mutliple ports causes real problems
    > with firewalls and proxies set up to be quite fascist.


    I don't think that I sounded like a supporter of FTP, but if I did, then
    I'm sorry. I hate FTP.


    > SSH/SFTP/SCP have very, very serious flaws in controlling user access
    > to the server's file system. They work well for certain operations:
    > having a command line browseable, more secure tool than FTP is good.
    > But The lack of a chroot cage to hide server content, such as /etc/
    > passwd or other configuratoins, and the difficulty of preventing shell
    > access for SSH users, all lead to some real risks in running it on a
    > server. There are some SSH servers that provide this (RunSCP comes to
    > mind), but they're nowhere near as commonly deployed as plain old
    > OpenSSH.


    SSH means `Secure SHell'. That implies regular shell access. However,
    if you system is configured properly, then there is no problem with
    that, besides that it adds a further layer of potential security
    problems. To avoid that, avoid SSH, or chroot it (which is well
    possible [1,2]).


    Regards,
    Ertugrul Söylemez.


    References:
    [1] http://chrootssh.sourceforge.net/index.php
    [2] http://www.brandonhutchinson.com/chroot_ssh.html


    --
    Security is the one concept, which makes things in your life stay as
    they are. Otto is a man, who is afraid of changes in his life; so
    naturally he does not employ security.

  14. Re: Good secure file transfer, was Re: How safe are FTP servers?

    On 29 May, 02:05, Ertugrul Soeylemez wrote:

    > SSH means `Secure SHell'. That implies regular shell access. However,
    > if you system is configured properly, then there is no problem with
    > that, besides that it adds a further layer of potential security
    > problems. To avoid that, avoid SSH, or chroot it (which is well
    > possible [1,2]).


    [ Note that this is about OpenSSH, not the commercial SSH server at
    ssh.com. ]

    chrooting OpenSSH is possible. But it's *not* supported by the
    authors, and they've previously said "no" to attempts to integrate it.
    That means you have to play games like maintaining your own version of
    OpenSSH on the server. It's painful: I used to maintain one of the
    codebases and download sites for those patche. There are notes at
    chroot.sourceforge.net, but it remains difficult to support.

    The chroot option in OpenSSH has nothing to do with restricting users
    to chroot cages: it restricts the sshd itself for certain operations.
    Like the UseDNS option in sshd_config, it's very confusingly named.


  15. Re: Good secure file transfer, was Re: How safe are FTP servers?

    On 28.05.2007, Nico wrote:
    > SSH/SFTP/SCP have very, very serious flaws in controlling user access
    > to the server's file system. They work well for certain operations:
    > having a command line browseable, more secure tool than FTP is good.
    > But The lack of a chroot cage to hide server content, such as /etc/
    > passwd or other configuratoins, and the difficulty of preventing shell
    > access for SSH users, all lead to some real risks in running it on a
    > server.


    Erm. If you patch sftp-server.c a bit (comment out one line), compile it
    as shared ELF library, write small program chrooting to $HOME and
    executing sftp-server.so (about 130 lines)[*] and set it as login shell
    for users, then you'll need to restrict X11 and port forwarding for sftp
    users in sshd_config.
    And voila, you have sftp without shell and even filesystem access.

    So please *don't* claim that sftp has flaws in controlling access to
    server's filesystem. If you have no idea how to restrict access it
    doesn't mean there's no way to do that easily.
    [*] http://dynamit.im.pwr.wroc.pl/dozzie/code/sftponly.git/ (comments in
    Polish, but the code is simple enough).

    --
    Secunia non olet.
    Stanislaw Klekot

  16. Re: How safe are FTP servers?

    On 28 May, 02:34, Sylvain Robitaille wrote:
    > Nico wrote:
    > > And horses were designed for people to ride on.

    >
    > I don't think so, no ... That is about as correct as "NNTP was designed
    > to transfer binary content". It wasn't, but people adapted it, just as
    > they adapted horses.


    I thought the modern horse, as a species, was human-evolved from an
    older species, much as dogs were evolved from canids. A fast Wikipedia
    search doesn't seem to agree with me, so your point is taken.

    > > ... it's a very bad idea to use for handling any protect content, ...

    >
    > As I said in my previous post, it's an awful protocol for exchanging
    > authentication information with (and I agree with you regarding *any*
    > sensitive content).
    >
    > > I've had good success migrating companies off of it to HTTPS for
    > > download and HTTPS/WebDAV for upload.

    >
    > You migrate people *from* FTP to WebDAV, in the name of security? I'll
    > grant that you've already said you're using HTTPS which is obviously the
    > right way to go ...


    Yes, I do. I find the necessarty firewall configuration to be easier,
    and the fine-grained control of user authentication and access to be
    vastly superior. The one problem is symlinks.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2