How safe are FTP servers? - Security

This is a discussion on How safe are FTP servers? - Security ; I have a server that I use to distribute code to my customers. Each customer has an account on the server which they access via ssh using RSA authentication. I have a new customer at a large defense company that ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: How safe are FTP servers?

  1. How safe are FTP servers?

    I have a server that I use to distribute code to my customers. Each
    customer has an account on the server which they access via ssh using RSA
    authentication. I have a new customer at a large defense company that
    can't use ssh, their firewall doesn't allow it. To accommodate that
    customer I've put Proftp on the release server. I've set it up so there
    is no root login and access is limited to users with a valid shell. In
    addition all user accounts have 700 privileges so no one can see anyone
    else's directories. This server machine doesn't have ssh access to any
    other machine on my network, I require RSA authentication on all of my
    boxes and there is no public key from this server on any other box. I
    also don't have any legacy servers installed on any of my systems so I'm
    assuming that even if someone gained access to my release server they
    could access any other system.

    I've tried to avoid FTP because it uses passwords instead of RSA keys and
    I don't want to be subject to password guessing attacks. Now that I'm
    stuck with an FTP server I'd like to know if I've just been overly
    paranoid. How safe is an FTP server? What else should I do to secure my
    network?

  2. Re: How safe are FTP servers?

    On 2007-05-17, General Schvantzkoph wrote:
    >
    > I've tried to avoid FTP because it uses passwords instead of RSA keys and
    > I don't want to be subject to password guessing attacks. Now that I'm
    > stuck with an FTP server I'd like to know if I've just been overly
    > paranoid. How safe is an FTP server? What else should I do to secure my
    > network?


    How safe is largely a function of which ftp server. IME proftpd is
    fairly good; vsftpd is also quite good. Historically wu-ftpd has not
    been very secure, but I have not used it or read anything about it in
    some time.

    Aside from that, your largest concern would be password sniffing.
    Question: if you are using this ftp server to distribute code, would it
    make sense to use anonymous FTP? This way there's no password to be
    sniffed. If that's not an option, then you could consider running your
    ftp daemon in a chroot'd environment, and not allowing PUT requests at
    all. Give each user who needs to retrieve your code a minimal
    unwritable home directory under the chroot, and/or make each user's home
    be a directory where you copy only the code they need to download. If a
    user's password is sniffed, all the cracker can do is retrieve the files
    you've allowed your user to retrieve; he can't even upload any cracking
    tools to help him gain a shell from the ftp daemon.

    You can also set up a secure web server, if your defense company client
    allows https: through their firewall. For distributing files to
    authorized users, this might actually be an easier option than the ftp
    scenarios I describe.

    The main problem with my suggestions is that they are one-way. If your
    clients need to copy data to you, you need some other way. You can set
    up a CGI on a secure web server to upload data, if password-sniffing is
    more of a concern than ease of setup (since regular ftp will be a lot
    easier to deal with; you've already done it, after all).

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  3. Re: How safe are FTP servers?


    "General Schvantzkoph" wrote in message
    newsan.2007.05.17.13.06.32@yahoo.com...
    >I have a server that I use to distribute code to my customers. Each
    > customer has an account on the server which they access via ssh using RSA
    > authentication. I have a new customer at a large defense company that
    > can't use ssh, their firewall doesn't allow it. To accommodate that
    > customer I've put Proftp on the release server. I've set it up so there
    > is no root login and access is limited to users with a valid shell. In
    > addition all user accounts have 700 privileges so no one can see anyone
    > else's directories. This server machine doesn't have ssh access to any
    > other machine on my network, I require RSA authentication on all of my
    > boxes and there is no public key from this server on any other box. I
    > also don't have any legacy servers installed on any of my systems so I'm
    > assuming that even if someone gained access to my release server they
    > could access any other system.
    >
    > I've tried to avoid FTP because it uses passwords instead of RSA keys and
    > I don't want to be subject to password guessing attacks. Now that I'm
    > stuck with an FTP server I'd like to know if I've just been overly
    > paranoid. How safe is an FTP server? What else should I do to secure my
    > network?


    The simple answer is 'not very safe'
    But why are you using ftp?
    FTP allows your server to receive files from clients, something like would
    be needed in a large web hosting operation, where every user manages their
    own space for their own website
    If all you are doing is allowing clients to download files, then there are
    many other applications which will perform that task.
    Depending on you security needs, Apache will do that very well with
    negligible security risk to your server.
    There are all kinds of neat 'authentication' modules.


    Back to ftp, you can 'jail' users in the 'public' area, so the chance of
    root level damage it remote.
    You can set permissions to prohibit writing, so you ftp site can not be used
    as a repository for pirated files.
    You can use decent passwords.
    If it is just to protect the files from unauthorized access, such as 'trade
    secret' type software, you can encrypt it before posting it.

    If you need more ideas, I can find one of my 'linux security' manuals.

    Stuart



  4. Re: How safe are FTP servers?

    General Schvantzkoph writes:

    >I have a server that I use to distribute code to my customers. Each
    >customer has an account on the server which they access via ssh using RSA
    >authentication. I have a new customer at a large defense company that
    >can't use ssh, their firewall doesn't allow it. To accommodate that


    So why do you not simply have ssh listen to port 80 on the server. As long
    as it is not also an http server, it will not get confused and almost all
    firewalls allow outgoing port 80 ( of web browsing does not work from that
    machine).

    On his end he simply tells his ssh to use port 80 rather than 22.

    Note that you could also set up rsync to distribute the code and have the
    rsync daemon running.



    >customer I've put Proftp on the release server. I've set it up so there
    >is no root login and access is limited to users with a valid shell. In
    >addition all user accounts have 700 privileges so no one can see anyone
    >else's directories. This server machine doesn't have ssh access to any
    >other machine on my network, I require RSA authentication on all of my
    >boxes and there is no public key from this server on any other box. I
    >also don't have any legacy servers installed on any of my systems so I'm
    >assuming that even if someone gained access to my release server they
    >could access any other system.


    >I've tried to avoid FTP because it uses passwords instead of RSA keys and
    >I don't want to be subject to password guessing attacks. Now that I'm
    >stuck with an FTP server I'd like to know if I've just been overly
    >paranoid. How safe is an FTP server? What else should I do to secure my
    >network?


  5. Re: How safe are FTP servers?

    On Thu, 17 May 2007 17:23:12 +0000, Stuart Miller wrote:

    > "General Schvantzkoph" wrote in message
    > newsan.2007.05.17.13.06.32@yahoo.com...
    >>I have a server that I use to distribute code to my customers. Each
    >> customer has an account on the server which they access via ssh using
    >> RSA authentication. I have a new customer at a large defense company
    >> that can't use ssh, their firewall doesn't allow it. To accommodate
    >> that customer I've put Proftp on the release server. I've set it up so
    >> there is no root login and access is limited to users with a valid
    >> shell. In addition all user accounts have 700 privileges so no one can
    >> see anyone else's directories. This server machine doesn't have ssh
    >> access to any other machine on my network, I require RSA authentication
    >> on all of my boxes and there is no public key from this server on any
    >> other box. I also don't have any legacy servers installed on any of my
    >> systems so I'm assuming that even if someone gained access to my
    >> release server they could access any other system.
    >>
    >> I've tried to avoid FTP because it uses passwords instead of RSA keys
    >> and I don't want to be subject to password guessing attacks. Now that
    >> I'm stuck with an FTP server I'd like to know if I've just been overly
    >> paranoid. How safe is an FTP server? What else should I do to secure my
    >> network?

    >
    > The simple answer is 'not very safe'
    > But why are you using ftp?
    > FTP allows your server to receive files from clients, something like
    > would be needed in a large web hosting operation, where every user
    > manages their own space for their own website
    > If all you are doing is allowing clients to download files, then there
    > are many other applications which will perform that task. Depending on
    > you security needs, Apache will do that very well with negligible
    > security risk to your server. There are all kinds of neat
    > 'authentication' modules.
    >
    >
    > Back to ftp, you can 'jail' users in the 'public' area, so the chance of
    > root level damage it remote.
    > You can set permissions to prohibit writing, so you ftp site can not be
    > used as a repository for pirated files.
    > You can use decent passwords.
    > If it is just to protect the files from unauthorized access, such as
    > 'trade secret' type software, you can encrypt it before posting it.
    >
    > If you need more ideas, I can find one of my 'linux security' manuals.
    >
    > Stuart


    My customers need to upload as well as download. I've been using ssh for
    this function which I'm comfortable with, I'm hoping that this customer
    can work things out with his IT people so that he will be able to use ssh
    in the future, in the mean time I've set up FTP so that he can get a
    release. I'm only going to open the port when he needs to get a new
    release.

    I have some questions on chroot. To chroot Proftp is the following
    correct,
    Put the following in /etc/init.d/proftpd

    DefaultRoot ~

    Can I do the same thing with ssh access?

  6. Re: How safe are FTP servers?

    Keith Keller wrote:

    > ... Historically wu-ftpd has not been very secure, but I have not used
    > it or read anything about it in some time.


    For what it's worth, wu-ftpd mostly got a bad rap because it was
    non-trivial to configure properly. Very flexible in terms of what you
    could setup with it, but that lead to complexity. That's not to say
    there weren't security vulnerabilities with older versions, but the
    biggest cause of trouble with it was poor configuration.

    I've been using that FTP server for years, and was even contributing to
    its development at one point, in the form of patches that (hopefully)
    helped make it easier to configure in only the features that were needed
    for a specific installation.

    To the OP, if you're only *sending* files to your clients, as someone
    else has suggested, a password-protected HTTP/SSL server would be a
    better idea. If you find that you either *must* use an FTP server, or
    decide that you would prefer to, whichever one you use, be very certain
    of its configuration, and of where your clients are intended to access
    the service from (TCP_Wrapper is your friend). Review periodically and
    keep up to date with any bug-fixes.

    The FTP server is only as secure as its weakest link, and your original
    instinct was right: your users are sending re-usable passwords in
    plain-text. Whether these passwords are likely to be intercepted at any
    point along the way depends largely on the security of the client system
    and the network it's on, the server and the network it's on, and all
    points in between. End-to-end encryption between the client and server
    (as with https, or SSH which you already prefer) is a much better idea.

    FTP is often still suitable for anonymous access to download files, or
    on well protected networks where the path between each end-point is well
    known and trustworthy, but as with any service that uses plain-text
    authentication (telnet, POP/IMAP, and others), accessing an FTP service
    over public networks is not advisable.

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

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

  7. Re: How safe are FTP servers?

    On Thu, 17 May 2007 18:26:34 +0000, Unruh wrote:

    > General Schvantzkoph writes:
    >
    >>I have a server that I use to distribute code to my customers. Each
    >>customer has an account on the server which they access via ssh using
    >>RSA authentication. I have a new customer at a large defense company
    >>that can't use ssh, their firewall doesn't allow it. To accommodate that

    >
    > So why do you not simply have ssh listen to port 80 on the server. As
    > long as it is not also an http server, it will not get confused and
    > almost all firewalls allow outgoing port 80 ( of web browsing does not
    > work from that machine).
    >
    > On his end he simply tells his ssh to use port 80 rather than 22.
    >
    > Note that you could also set up rsync to distribute the code and have
    > the rsync daemon running.
    >
    >
    >
    >>customer I've put Proftp on the release server. I've set it up so there
    >>is no root login and access is limited to users with a valid shell. In
    >>addition all user accounts have 700 privileges so no one can see anyone
    >>else's directories. This server machine doesn't have ssh access to any
    >>other machine on my network, I require RSA authentication on all of my
    >>boxes and there is no public key from this server on any other box. I
    >>also don't have any legacy servers installed on any of my systems so I'm
    >>assuming that even if someone gained access to my release server they
    >>could access any other system.

    >
    >>I've tried to avoid FTP because it uses passwords instead of RSA keys
    >>and I don't want to be subject to password guessing attacks. Now that
    >>I'm stuck with an FTP server I'd like to know if I've just been overly
    >>paranoid. How safe is an FTP server? What else should I do to secure my
    >>network?


    I've tried alternate ports for ssh in the past, they work fine with
    vanilla firewalls but they haven't worked with customers who are at large
    corporations, those firewalls seem to want to limit services to the
    default ports. Also if I changed ports I'd have to have all my customers
    change their ~/.ssh/config files, I'd rather not do that.

  8. Re: How safe are FTP servers?

    In comp.os.linux.security Unruh :
    > General Schvantzkoph writes:


    >>I have a server that I use to distribute code to my customers. Each
    >>customer has an account on the server which they access via ssh using RSA
    >>authentication. I have a new customer at a large defense company that
    >>can't use ssh, their firewall doesn't allow it. To accommodate that


    > So why do you not simply have ssh listen to port 80 on the server. As long
    > as it is not also an http server, it will not get confused and almost all
    > firewalls allow outgoing port 80 ( of web browsing does not work from that
    > machine).


    > On his end he simply tells his ssh to use port 80 rather than 22.


    $$ firewalls inspect the data flow and might be configured to
    drop if it isn't http traffic.

    > Note that you could also set up rsync to distribute the code and have the
    > rsync daemon running.


    Or something working with https.


    >>I've tried to avoid FTP because it uses passwords instead of RSA keys and
    >>I don't want to be subject to password guessing attacks. Now that I'm
    >>stuck with an FTP server I'd like to know if I've just been overly
    >>paranoid. How safe is an FTP server? What else should I do to secure my
    >>network?


    Run vsftpd in chroot mode. It can in addition support TSL/SSL if
    the client and connection allow. man vsftpd.conf for details.

    Good luck

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 220: Someone thought The Big Red Button was a
    light switch.

  9. Re: How safe are FTP servers?

    On Thu, 17 May 2007 22:04:18 +0200, Michael Heiming wrote:

    > In comp.os.linux.security Unruh :
    >> General Schvantzkoph writes:

    >
    >>>I have a server that I use to distribute code to my customers. Each
    >>>customer has an account on the server which they access via ssh using
    >>>RSA authentication. I have a new customer at a large defense company
    >>>that can't use ssh, their firewall doesn't allow it. To accommodate
    >>>that

    >
    >> So why do you not simply have ssh listen to port 80 on the server. As
    >> long as it is not also an http server, it will not get confused and
    >> almost all firewalls allow outgoing port 80 ( of web browsing does not
    >> work from that machine).

    >
    >> On his end he simply tells his ssh to use port 80 rather than 22.

    >
    > $$ firewalls inspect the data flow and might be configured to drop if it
    > isn't http traffic.
    >
    >> Note that you could also set up rsync to distribute the code and have
    >> the rsync daemon running.

    >
    > Or something working with https.
    >
    >
    >>>I've tried to avoid FTP because it uses passwords instead of RSA keys
    >>>and I don't want to be subject to password guessing attacks. Now that
    >>>I'm stuck with an FTP server I'd like to know if I've just been overly
    >>>paranoid. How safe is an FTP server? What else should I do to secure my
    >>>network?

    >
    > Run vsftpd in chroot mode. It can in addition support TSL/SSL if the
    > client and connection allow. man vsftpd.conf for details.
    >
    > Good luck


    I've installed vsftpd. I setup the following lines in the vstpd.conf
    files as follows,

    # Allow anonymous FTP? (Beware - allowed by default if you comment this
    out).
    anonymous_enable=NO

    # You may specify an explicit list of local users to chroot() to their
    home
    # directory. If chroot_local_user is YES, then this list becomes a list of
    chroot_local_user=YES
    # users to NOT chroot().
    chroot_list_enable=YES
    # (default follows)
    chroot_list_file=/etc/vsftpd/chroot_list

    the chroot_list file is empty. IS there any thing else that I should do?

  10. Re: How safe are FTP servers?

    On 17 May, 20:34, Sylvain Robitaille wrote:
    > Keith Keller wrote:
    > > ... Historically wu-ftpd has not been very secure, but I have not used
    > > it or read anything about it in some time.

    >
    > For what it's worth, wu-ftpd mostly got a bad rap because it was
    > non-trivial to configure properly. Very flexible in terms of what you
    > could setup with it, but that lead to complexity. That's not to say
    > there weren't security vulnerabilities with older versions, but the
    > biggest cause of trouble with it was poor configuration.


    There were other issues. The code base was old and grew in complexity
    over time to add new features. Cleaner, modern FTP servers like vsftpd
    and proftpd work much more reliably.

    But in this day and age, there's no excuse for FTP unless your clients
    need anonymous download only, or you want to publish symlinks in an
    identifiable format. WebDAV over HTTPS works very well for secure
    upload and download, and avoids the lack of chroot and need for
    working user accounts of OpenSSH.

    I've now replaced numerous FTP uploads with WebDAV/HTTPS, and it is
    vastly simpler to configure over firewalls due to using only a single
    port, not the separate command and data ports of FTP.


  11. Re: How safe are FTP servers?

    In comp.os.linux.security General Schvantzkoph :
    > On Thu, 17 May 2007 22:04:18 +0200, Michael Heiming wrote:


    >> In comp.os.linux.security Unruh :
    >>> General Schvantzkoph writes:

    [..]

    >> Run vsftpd in chroot mode. It can in addition support TSL/SSL if the
    >> client and connection allow. man vsftpd.conf for details.


    > I've installed vsftpd. I setup the following lines in the vstpd.conf
    > files as follows,


    > # Allow anonymous FTP? (Beware - allowed by default if you comment this
    > out).
    > anonymous_enable=NO


    > # You may specify an explicit list of local users to chroot() to their
    > home
    > # directory. If chroot_local_user is YES, then this list becomes a list of
    > chroot_local_user=YES
    > # users to NOT chroot().
    > chroot_list_enable=YES
    > # (default follows)
    > chroot_list_file=/etc/vsftpd/chroot_list


    > the chroot_list file is empty. IS there any thing else that I should do?


    If you want benefits from using chroot, it would be helpful to
    list the users in the chroot_list...

    Good luck

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 146: Communications satellite used by the military
    for star wars.

  12. Re: How safe are FTP servers?

    General Schvantzkoph (07-05-17 13:06:32):

    > I have a server that I use to distribute code to my customers. Each
    > customer has an account on the server which they access via ssh using
    > RSA authentication. I have a new customer at a large defense company
    > that can't use ssh, their firewall doesn't allow it. To accommodate
    > that customer I've put Proftp on the release server. I've set it up so
    > there is no root login and access is limited to users with a valid
    > shell. In addition all user accounts have 700 privileges so no one can
    > see anyone else's directories. This server machine doesn't have ssh
    > access to any other machine on my network, I require RSA
    > authentication on all of my boxes and there is no public key from this
    > server on any other box. I also don't have any legacy servers
    > installed on any of my systems so I'm assuming that even if someone
    > gained access to my release server they could access any other system.
    >
    > I've tried to avoid FTP because it uses passwords instead of RSA keys
    > and I don't want to be subject to password guessing attacks. Now that
    > I'm stuck with an FTP server I'd like to know if I've just been overly
    > paranoid. How safe is an FTP server? What else should I do to secure
    > my network?


    You can imagine yourself how safe FTP is, and a few other people have
    already given an answer to this question. I understand your problem is
    that you want to distribute files, and the traffic should be encrypted
    as well as securely authenticated (i.e. no passwords). There are a few
    alternatives. One of them should certainly pass almost any firewall.

    As Unruh already mentioned, you can use rsync. This is probably the
    best method to distribute files, especially source code, which changes
    frequently, but also for data that doesn't change. The big advantage is
    that rsync can run transparently over a few protocols, including SSH
    (where it looks just like SCP) and rsync's own protocol.

    For the problem, where SSH traffic is blocked, you can use authenticated
    HTTP. That means that both you and your client have a valid
    certificate. There are two options. The first is that you aquire a
    server certificate from some big CA, which is known to most webbrowsers.
    A few of them are free. Then you can give out client certificates
    (i.e. let them generate one and sign them with your own). That's less
    user-friendly than rsync with SSH, but gives equivalent security.

    Last, but certainly not least, you can try using FTP with TLS. Unlike
    SSL, where the application protocol is embedded into, in TLS it's the
    opposite way. TLS is embedded into FTP, so the firewall should not be
    able to detect the difference (without specifically watching for it).
    vsftpd supports this. Then disable password-based authentication and
    work with certificates, just like with HTTP/S.


    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.

  13. Re: How safe are FTP servers?

    Ertugrul Soeylemez wrote:



    > You can imagine yourself how safe FTP is, and a few other people have
    > already given an answer to this question. I understand your problem is
    > that you want to distribute files, and the traffic should be encrypted
    > as well as securely authenticated (i.e. no passwords). There are a few
    > alternatives. One of them should certainly pass almost any firewall.


    Agree completely. Theer are two main security considerations here:

    a) Can some little t*sser crack your server daemon outright? eg buffer
    overrun, get into your system, root it etc. This is addressed by using
    decent server software with a good track record, or by layering another
    stronger system over the top (eg ssh tunnels).

    b) If not a), can they sniff your client's authentication credentials
    between your server and theirs and then log in normally and nick/wreck your
    data? This is addressed by either securing the network or securing the
    channel, eg by encryption.

    > As Unruh already mentioned, you can use rsync. This is probably the
    > best method to distribute files, especially source code, which changes
    > frequently, but also for data that doesn't change. The big advantage is
    > that rsync can run transparently over a few protocols, including SSH
    > (where it looks just like SCP)



    Just to clarify, rsync uses it's own rsync protocol over SSH, stuffed
    through an SSH tunnel. To illustrate, do an rsync over SSH and observe the
    remote end - you will find and rsync process running on the end of a unix
    stream back to an sshd service process. I assume you meant by "looks just
    like SCP" you meant "looks like some random encrypted scunge". :-)


    > and rsync's own protocol.
    >
    > For the problem, where SSH traffic is blocked, you can use authenticated
    > HTTP. That means that both you and your client have a valid
    > certificate. There are two options. The first is that you aquire a
    > server certificate from some big CA, which is known to most webbrowsers.
    > A few of them are free. Then you can give out client certificates
    > (i.e. let them generate one and sign them with your own). That's less
    > user-friendly than rsync with SSH, but gives equivalent security.


    You could of course also generate your own cert and you only need one on the
    server if you then use something like Basic HTTP authentication as well -
    at least you get an encrypted channel. It's more vulnerable to attacks done
    like that, but it's often "good enough TM".

    > Last, but certainly not least, you can try using FTP with TLS. Unlike
    > SSL, where the application protocol is embedded into, in TLS it's the
    > opposite way. TLS is embedded into FTP, so the firewall should not be
    > able to detect the difference (without specifically watching for it).
    > vsftpd supports this. Then disable password-based authentication and
    > work with certificates, just like with HTTP/S.


    I never worked out why FTP over SSL or TLS never seemed to catch on. Seems
    as obvious as IMAP over SSL.

    Cheers

    Tim

  14. Re: How safe are FTP servers?

    Tim Southerwood (07-05-18 14:14:41):

    > a) Can some little t*sser crack your server daemon outright? eg buffer
    > overrun, get into your system, root it etc. This is addressed by using
    > decent server software with a good track record, or by layering
    > another stronger system over the top (eg ssh tunnels).


    That's an entirely different issue and off-topic in this thread. The
    main problem the OP addresses is that of authenticating users based on
    something that isn't human-chosen.

    BTW, "SSH tunnels" and "layering another stronger system over the top",
    don't make sense together in the context of exploitability of
    programming errors.


    >
    > Just to clarify, rsync uses it's own rsync protocol over SSH, stuffed
    > through an SSH tunnel. To illustrate, do an rsync over SSH and observe
    > the remote end - you will find and rsync process running on the end of
    > a unix stream back to an sshd service process. I assume you meant by
    > "looks just like SCP" you meant "looks like some random encrypted
    > scunge". :-)
    >


    And I said nothing different.

    It's just that someone who is interested in the inner workings of rsync
    can always read the documentation or the source code. It's enough here
    to say that rsync transfers files efficiently, and that it works over
    authenticating protocols.


    > You could of course also generate your own cert and you only need one
    > on the server if you then use something like Basic HTTP authentication
    > as well - at least you get an encrypted channel. It's more vulnerable
    > to attacks done like that, but it's often "good enough TM".


    If you generate a self-signed certificate, then you have to securely
    distribute this certificate to end-users, and help them installing it.
    You have to do this for every user separately. You can also become your
    own CA, but that way you force users to give full trust to you to not
    launch an MITM attack against them. Both are bad practice.

    That's why we call a CA a trusted _third party_. It simply _has_ to be
    an independent third party.


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


    Because FTP itself never really catched up, and I'm glad about that.
    FTP is so much broken that it doesn't make sense to work around this
    using innocent protocols like SSL or TLS.


    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.

  15. Re: How safe are FTP servers?

    Ertugrul Soeylemez wrote:

    > Tim Southerwood (07-05-18 14:14:41):
    >
    >> a) Can some little t*sser crack your server daemon outright? eg buffer
    >> overrun, get into your system, root it etc. This is addressed by using
    >> decent server software with a good track record, or by layering
    >> another stronger system over the top (eg ssh tunnels).

    >
    > That's an entirely different issue and off-topic in this thread. The
    > main problem the OP addresses is that of authenticating users based on
    > something that isn't human-chosen.


    Yes, indeed. I apologise, I lost track of the bit: "I've tried to avoid FTP
    because it uses passwords instead of RSA keys and I don't want to be
    subject to password guessing attacks." that was in the original post,
    between yesterday and today, and I got focussed on the ftp concept.

    > It's just that someone who is interested in the inner workings of rsync
    > can always read the documentation or the source code. It's enough here
    > to say that rsync transfers files efficiently, and that it works over
    > authenticating protocols.


    Fair enough.

    >
    >> You could of course also generate your own cert and you only need one
    >> on the server if you then use something like Basic HTTP authentication
    >> as well - at least you get an encrypted channel. It's more vulnerable
    >> to attacks done like that, but it's often "good enough TM".

    >
    > If you generate a self-signed certificate, then you have to securely
    > distribute this certificate to end-users, and help them installing it.
    > You have to do this for every user separately. You can also become your
    > own CA, but that way you force users to give full trust to you to not
    > launch an MITM attack against them. Both are bad practice.


    Then again, if the OP found a way to distribute an RSA key, then
    distributing an SSL client cert is no different. I accept the point about
    the self-signing though.

    Tricky one...

    Tim

  16. Re: How safe are FTP servers?

    On Thu, 17 May 2007 13:06:32 +0000, General Schvantzkoph wrote:

    I wish to thank everyone for their suggestions. I want to keep everything
    as simple as possible so the web server solutions are out. What I'm doing
    is temporarily opening my FTP port while this one customer gets their
    stuff and then I'm closing it. I'm using vsftpd with chrooting for him.
    I'm hoping that his IT people will be able to get him ssh access and then
    I can forget about FTP. All of my other clients have been happy with ssh.

    My big concern is that the FTP server can be compromised through some
    sort of attack. I'm not worried about password sniffers so much as
    password guessers, my ssh server gets several such attacks a day.
    Criminals don't have the means to be able to intercept internet traffic
    and search for passwords, only the NSA can do that, so the fact that FTP
    sends things in the clear is of lower concern then the fact that FTP
    servers have been historically easy to compromise.

    If my customer isn't able to talk his IT people into providing him with
    ssh access I might revisit this problem.

  17. Re: How safe are FTP servers?

    General Schvantzkoph writes:

    >On Thu, 17 May 2007 13:06:32 +0000, General Schvantzkoph wrote:


    >I wish to thank everyone for their suggestions. I want to keep everything
    >as simple as possible so the web server solutions are out. What I'm doing
    >is temporarily opening my FTP port while this one customer gets their
    >stuff and then I'm closing it. I'm using vsftpd with chrooting for him.
    >I'm hoping that his IT people will be able to get him ssh access and then
    >I can forget about FTP. All of my other clients have been happy with ssh.


    >My big concern is that the FTP server can be compromised through some
    >sort of attack. I'm not worried about password sniffers so much as
    >password guessers, my ssh server gets several such attacks a day.
    >Criminals don't have the means to be able to intercept internet traffic
    >and search for passwords, only the NSA can do that, so the fact that FTP
    >sends things in the clear is of lower concern then the fact that FTP
    >servers have been historically easy to compromise.


    Absolutely wrong. Anyone along the line of transmission between you and him
    can see the password. Any computer hooked to the net. Thus, if your service
    provider, or his service provider, or some other customer or your or his
    service provider may be able to see the information. Needs nothing from
    NSA. Historically far more passwords have been sniffed than ftp servers
    broken into I suspect.


    >If my customer isn't able to talk his IT people into providing him with
    >ssh access I might revisit this problem.


  18. Re: How safe are FTP servers?

    On 2007-05-18, General Schvantzkoph wrote:
    >
    > I wish to thank everyone for their suggestions. I want to keep everything
    > as simple as possible so the web server solutions are out.


    Well, there are some simple web servers out there.

    > My big concern is that the FTP server can be compromised through some
    > sort of attack. I'm not worried about password sniffers so much as
    > password guessers, my ssh server gets several such attacks a day.


    Well, the questions to ask are: 1) what will be compromised if the
    password is guessed; and 2) is the password likely to be guessed?
    If the password is a good one, then it probably won't be guessed.
    To reduce your exposure, be sure to limit the users who are permitted
    to log in to only those who require ftp.

    > Criminals don't have the means to be able to intercept internet traffic
    > and search for passwords,


    What makes you think criminals don't have an in at various ISPs?
    You're right, though, it's probably not worth their time or energy
    to obtain passwords by sniffing the network. Much more likely
    they're just spying on your client. ;-)

    --keith


    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  19. Re: How safe are FTP servers?

    On 18 May, 23:15, Keith Keller francisco.ca.us> wrote:
    > On 2007-05-18, General Schvantzkoph wrote:


    >
    > > Criminals don't have the means to be able to intercept internet traffic
    > > and search for passwords,

    >
    > What makes you think criminals don't have an in at various ISPs?
    > You're right, though, it's probably not worth their time or energy
    > to obtain passwords by sniffing the network. Much more likely
    > they're just spying on your client. ;-)


    Yes, it is. Tools to re-route packets and scan for the keywords
    "password" or "Passwd:" are too easy to insall and too cheap to run,
    and popular at campuses where the routers and switches are configured
    with default passwords. (It's been years since I had to deal with that
    sort of mess, but I've certainly seen the results when 2000 people
    were told they had to change their passwords.)

    There are reasons that tools like Kerberos, and SSH, spend so much
    time making sure that nothing happens in the clear.


  20. Re: How safe are FTP servers?

    General Schvantzkoph (07-05-18 15:41:58):

    > I wish to thank everyone for their suggestions. I want to keep
    > everything as simple as possible so the web server solutions are
    > out. What I'm doing is temporarily opening my FTP port while this one
    > customer gets their stuff and then I'm closing it. I'm using vsftpd
    > with chrooting for him. I'm hoping that his IT people will be able to
    > get him ssh access and then I can forget about FTP. All of my other
    > clients have been happy with ssh.


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


    > My big concern is that the FTP server can be compromised through some
    > sort of attack. I'm not worried about password sniffers so much as
    > password guessers, my ssh server gets several such attacks a day.
    > Criminals don't have the means to be able to intercept internet
    > traffic and search for passwords, only the NSA can do that, so the
    > fact that FTP sends things in the clear is of lower concern then the
    > fact that FTP servers have been historically easy to compromise.


    Always remember that attacks against a company mostly originate from
    inside it. It's easy for any employee to intercept the whole network.
    That's why using FTP is the worst thing you could do -- even
    temporarily. It's a good idea to at least wrap it into SSL or TLS. Use
    TLS to bypass intelligent firewalls.

    TLS is SSLv3 effectively, so cryptographically there is no difference.
    The difference lies in how the connection is negotiated.


    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.

+ Reply to Thread
Page 1 of 2 1 2 LastLast