Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Ask Slashdot: Secure FTP? 85

Posted by Cliff from the for-the-paranoid-sysadmin dept.
Tobbe Johansson asks: "I would like to put a secure layer between my FTP-daemon and the network. I have searched for a program that encrypts/decrypts the port where my FTP is running but I have not been able to find anything that seems to work. Can anyone help me?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Secure FTP? More

Ask Slashdot: Secure FTP?

Comments Filter:

  • use mc (Score:1)

    by Anonymous Coward
    mc has been able to do this for a while just type cd ftp://[username]@host and it will allow the same operations as a normal fs and also preserves the file attributes. Or use the tar feature of wu-ftpd ie get dir.tar

  • Re:Another way (Score:1)

    by Anonymous Coward
    Engrypt the files, and put them in your anonymous ftp area... If their sufficiently encrypted they'll be safe...

  • Secure FTP ? (Score:1)

    by Anonymous Coward
    Have a look at:

    SSL tunnel:

    http://mike.daewoo.com.pl/computer/stunnel/

  • secure FTP (Score:2)

    by Anonymous Coward
    You can use SSH to encrypt the control connection (i.e. secure your passwords), but it is a pain to also encrypt the data.

    If you want everything to be safely encrypted, your choices are:

    (1) Use scp (part of ssh) to do the transfers. Works like rcp, can also copy over whole directories recursively.

    There are also free versions of scp out there for win and mac.

    (2) Use a SSL-ified FTP server and program. (check www.ssleay.org for a link).

    Problem: I don't know of any SSL FTP programs out there for win or mac

  • IPsec as an option (Score:2)

    by Anonymous Coward
    How about running IPsec between the two boxes.
    If they are both Linux, then look at:
    http://www.flora.org/freeswan/
    Not only will your FTP be encrypted, but so will
    your Telnet, HTTP, and even your pings. The good
    thing about this would be that you don't need any
    special client or server applications.
  • Look in ftp.uni-mainz.de:/pub/int ernet/security/ssl/SSLapps/ [uni-mainz.de] for some SSL-aware telnet/ftp clients and servers.

  • SSL/TLS FTP (Score:5)

    by Jordy ( 440 ) <jordan.snocap@com> on Monday May 10, 1999 @09:24PM (#1898440) Homepage
    You can use an industry standard encryption and authentication protocol with FTP supported by various clients.

    First, go to http://www.openssl.org/ [openssl.org]. OpenSSL is based on SSLeay and is the basis for open source SSL communications in unix. You'll want to grab openssl and compile it and install it. It provides a number of useful programs including md5 & sha for generating checksums on files and a whole suite of other cipher routines.

    Next visit http://www.psy.uq.oz.au/~ftp/Crypto/ [uq.oz.au] and go find an FTP server and client pair which have SSL support. There are also a few general proxy deals which can handle it with any standard FTP server.

    Now there are a few ways to do authentication, you can do normal authentication or authentication based on certificate which requires a CA server (things like verisign will work if you want to shell out some cash, but you can also build your own CA).

    The great thing about SSL is it can autodetect encryption support. So you can take a standard telnet server, make a few minor modifications to get it SSL capable and connect to it using SSL capable telnet client or a vanilla telnet client and it'll use the strongest security possible.

    No need for silly third party daemons or special ports. Although the official TLS service ports are different from their unencrypted couterparts.

    This is good if you are behind a corporate lan which doesn't like allowing anything besides telnet, ftp, and web traffic through their proxy.

    --
  • Actually ssh2 already has an sftp.....
  • SSH2 comes with sftp, however, it seems to have been drinking your mountain dew, because it never seems to work too well (eg at all). However, if you want to do some fairly simple encrypted tunnelling, you can run a ppp connection over an ssh connection, and tunnel the network.
  • Posted by alanut:

    Should be easy to make an app in java 2 using the JCE and streams. What type of encryption do you want?
  • Posted by thomasf:

    lftp will also do this. It also comes with a cool mirror option that will mirror a remote directory to a specified local one.
  • It (tftp) is used for netbooting. Diskless systems often download their kernel via tftp.

    Zero security.

    As far as this topic goes, I echo: sftp, ssh, stunnel
  • I'm pretty sure that MIT's athena distribution provides a modified version of FTP which has kerberos support. This allows for secure authentication, but I'm not sure if the anything else is encrypted. If authentication is all that you need to be secure you might want to check it out. Kerberos can be a pain to get working, but once it is working it's really nice (i.e., you enter a password once and all your kerberos enabled programs never bug you for a password).

    Ssh port forwarding would probably also work, but everybody else has already suggested that so I figured I'd throw out a different option.
  • The FAQ states that you use ssh to encrypt the control port and because of that, only the control information is encrypted, not the data portion. It's been my experience that if you use passive mode, both control and data go across the same port. Since they use the same port, control -and- data are protected.

    Am I wrong here?
  • The Internet draft: draft-murray-au th-ftp-ssl-04.txt [ietf.org] documents the secure FTP mechanism we use (and, ahem, invented) here.

    I don't believe there is a free implementation, but the specs are there, so anyone can have a stab at it (hope they do). There are several commercial implementations of the client.
    --

  • Quite simple, if you understood networking.

    FTP is actually 2 connections:
    -a stateless UDP for data transfer
    -a stated TCP control.

    By using UDP, which requires no acknowledgement of packets, FTP is significantly speedier than its retarded cousin, HTTP. I recommend you read some RFC's.

  • I found that secureCRT (which supports both ssh and telnet) it very nice for windows. As for mac I haven't found anything. There is also a free ssh client for windows that is just called ssh client for windows. Don't have much on that one, it hs some copy paste termial emulation probs.
  • I can answer the first part at least: HTTP was never designed to be used with large files. As such, it can get a bit flaky.

    As for the TLS/SSL bit... well, there you've got me. Secure transfers are indeed a must on the Net today.

  • I would like to expand on this question.

    1. F-Secure SSH on my Windblows 98 clients
    2. ssh1 and ssh2 under Linux

    F-Secure SSH supports port forwarding but I haven't quite figured out how to forward my FTP connections through the F-Secure SSH to my WS_FTP client. Is this possible? If so, is there a HOW-TO anywhere?

    Thanks in advance!

    Eugene
  • That's dependant on the ftp server, smartie. I doubt a WinNT ftp server would be able to tar directories for you.
    --
    Aaron Gaudio
    "The fool finds ignorance all around him.
  • no body just a subject............... I rule BTW And don't spam me.... also one last tidbit while I'm here.. look into scp... though it's not a deamon per say it sedurely transfers files in the strongest of methods

  • SSH can do it... (Score:3)

    by Orion ( 3967 ) on Monday May 10, 1999 @06:39PM (#1898455)
    Secure shell can tunnel anything, including FTP connections. You could probably even throw together a wrapper script called sftp or something. It just means that the server has to have secure shell as well as ftp.
  • Alternately, skip ftp entirely as an inherently insecure method.

    ssh's own scp is a thing of beauty.

    Beware of how scp2 and scp1 interact (or don't, rather), though.

    ~gr
  • Equally, one might ask why HTTP was created at all... Since FTP does nearly everything that HTTP does.

    HTTP cannot perform directory listings, nor can it return those directory listings in terms which a computer can understand - there's absolutely nothing in the standard for it.

    FTP, on the other hand, gives out surprising little information about what the files it is giving access to are for, something that HTTP has done since 1.0. (Note: FTP can, actually, do this too, but it's not

    Don't confuse FTP with HTTP - they're very different protocols, with the common feature of being able to transfer a file in a stable manner. But that's the base use of both - their feature sets diverge heavily from that point.

    Back onto the point in hand, ftp://ftp.replay.com/pub/crypto/ should have all the FTP/SSL stuff you want, but it's non-standard... If you want to make it a standard, head on over to http://www.ietf.org/ and join in the fun.
  • Header information within FTP?

    I assume you mean the kind of meta-information within HTTP/1.1 headers. It does, in the 'MLST' style listings. It can contain MIME types, sizes of files, and almost any other information that you can think of. It's held in a machine readable listing, which allows for a quick and easy method of detirmining which file you want.

    That's a different concept to HTTP's - giving you the file that the author of the site wants to give you - and neither is wrong, just very different.

    But you're right in that neither is worse for large file transfers of a specific file. It's simply that finding that specific file may prove easier with FTP.
  • yeah, i have. i really like it. both the telnet and ftp daemons work well in encrypted mode, and more importantly they handle unencrypted sessions perfectly, too. clients exist for most platforms, keysize can be huge (i use 1024 bit keys, myself), and it's transparent to the user (unlike ssh), so you don't have to "retask" them.

    http://srp.stanford.edu/

    enjoy, it works well!
  • I've had to tangle with http file upload problems at work, for an extranet product, and I can attest that, while http file download works fine (it is, after all, just the first step in viewing any web page), file upload is way more flaky. Problems:
    • When clients have slow connections, frequently the connection times out somewhere along the line before they can send the whole file (especially with large files)
    • So far (AFAIK) there is no way to upload multiple files at the same time. The form element that handles file upload only takes one file at a time.
    • It's just not as fast, and it's a bandwidth hog. These are subjective observations, not benchmarks, but I had to upload a damn lot of files in testing, and it seems to take longer than ftp. The file is sent in chunks, and I think that headers and handling for each of these chunks adds overhead to the upload.
    While we're at it, if anyone knows of a good way to integrate ftp file transfer with a web site, please share!
    ----------------------
  • I am using TeraTerm ssh to connect to linux machines and I have found that zmodem is the easiest way to transfer files. Nothing special to set up - it just works.

    The major disadvantage is that it ties up your interactive connection.


  • Look up stunnel (secure tunnels) on freshmeat. Unix and Windows clients that i know of, at least. It will secure *every* communication between the two machines.


  • I believe Win2K has this. I wouldn't be suprised to see a client back ported to Win9x and NT4 once Win2K is out.
    --

  • Equally, one might ask why HTTP was created at all... Since FTP does nearly everything that HTTP does.
    There are a few things it doesn't do; there's no specification within FTP for the header information transferred with HTTP requests, for example. You could get this by layering HTTP on top of FTP, but then you've got the same problem you've always had with FTP: a lot of complexity that you don't need for this particular application.

    I also find it odd that people find HTTP less reliable than FTP for downloading large files. It really shouldn't make any difference. (Of course, if you've got an unreliable connection, FTP is better assuming both the server and client support resumption of interrupted transfers.)

    cjs

  • Right...I have seen Kerberos FTP at CMU [cmu.edu]...It exists for BOTH Unix and Dos (not seen a Win version..but it must exist...and who cares ? )
    Definitely lot less trouble than ssh (if kerberos is up .. that is)

  • CIPE - Crypto IP Encapsulation (Score:3)

    by yonderboy ( 13585 ) on Monday May 10, 1999 @11:12PM (#1898467)
    CIPE - encrypted IP over UDP tunneling

    "This is an ongoing project to build encrypting IP routers. The protocol used is as lightweight as possible. It is designed for passing encrypted packets between prearranged routers in the form of UDP packets. This is not as flexible as IPSEC but it is enough for the original intended purpose: securely connecting subnets over an insecure transit network. The implementations mentioned below are actually in use in such an application."

    The newest version of CIPE is available on
    http://sites.inka.de/~bigred/devel/cip e.html [sites.inka.de]
    or ftp://sites.inka.de/sites/bigred/devel/cipe.html

    It also works well for getting around those pesky universtity firewalls.
  • Because your password would still be passed in the clear.

  • NCFTP (Score:1)

    by Otto ( 17870 )
    umm, ncftp goes as far down as you want.. might want to get the latest version..

    BUT, ncftp uses the ls -R (i think) command to retrieve the directory listing. That is, it gets the list of the entire tree, then downloads it all. WSFTP gets it one dir at a time, and can work on pretty much any ftp, unlike ncftp. NCFTP also can't handle any kind of ftp servers that return unusual stuff in the directory listings..

  • sendfile (for something completely different) (Score:3)

    by tm23 ( 17908 ) on Monday May 10, 1999 @07:36PM (#1898470)
    If security is a big concern, and your ftp site is really only for a select group of people, you may wish to consider the sendfile suite of utilities based on the SAFT (?) protocol. Basically, it's akin to email or instant messaging systems but with files and with decent security involved (you can filter out spurious senders of files, no passwords need pass over the 'net).

    Something to give a shot for those of you wanting to give your friend, who's too lazy/paranoid/poor to set up an ftp server, a file.
  • Can you possibly point me to these versions of scp (specifically for the mac) ?

    thanks.
  • I'll second that...I've had no problems with it, aside from a slightly cumbersome interface. Aside from NiftyTelnet, are there any other Mac clients? I've done extensive searching and can't seem to come up with anything else.
  • Look for 'stunnel' in your favorite search engine. I think I've seen a nice web page about setting it up too. It uses OpenSSL (formerly SSLeay).
  • For Mac I use Nifty Telnet SSH. It's cost free and works well.

  • scp (Score:1)

    by jap ( 24325 )
    Why not use scp, which is included in the ssh-package and features encryption through the ssh-tunnel, transparant compression and authentication all in one?
  • The Secure Remote Password protocol (SRP) [stanford.edu] provides a supposedly secure login session as well as an encrypted channel if you wish. The web site is well documented. Has anybody used this in the Real World ?
  • As coincidence would have it, I just noticed something called bnc4all [ftp4all.de] on freshmeat [freshmeat.net]. It's a bouncer rather than tunneling or using an encrypted alternative. If you want to increase security while still allowing plain old ftp clients to connect, it may be an option. I have no experience with it, and no idea of its utility.

    On the other hand, ssh/scp rocks. First choice if you can do it.
  • You could stick SSH in front of it. Then you could have an encrypted channel, and no clear-text passwords etc. SSH has clients for just about every platform.

  • Yup, I use xftp.
    It is far better than other ftp clients I have tried.
  • Last time I installed ssh2, I think it came with a client/server package called sftp. Or maybe someone dropped crack in my mountain dew. You should be able to tunnel it through ssh if not.
  • The two commercial secure FTP solutions are FileDrive (www.differential.com) and Connect:Mailbox (www.sterlingcommerce.com). Do these follow your draft? What commercial solutions do? Thanks in advance!
  • i don't know if this would work, but there's at least one more free ssh client out there by Cedomir Igaliy(my pardons to him if i slaughtered his name ;-). Perhaps you can use that?

  • GSSFTP (Score:2)

    by Jered ( 32096 )
    If you download MIT Kerberos 5 [mit.edu], it includes GSSFTP which is a Kerberized FTP service. Unless you have a Kerberos infrastructure at your location, however, this may be an excessively complicated solution for you.

  • Um, I recommend you ACTUALLY read some RFCs. Such as rfc 959, File Transfer Protocol.

    Here's a link to it. [ic.ac.uk]

    Nowhere in the text do the letters UDP even occur in order.

    Furthermore, under section 3.3: Data connection management, we find the following:

    Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once.

    (Emphasis added)

    Please make sure you know what you're talking about next time before you tell others they don't.

  • From the SRP mailing list (credit to Tom Wu):

    The problem is that the ssh public-key exchange is still open to a nice man-in-the-middle attack. For example, if I'm using a kiosk terminal with ssh to connect to my host back at Stanford, even if we assume that the kiosk itself is not tampered with, someone can spoof DNS easily enough and have the kiosk connect to the attacker's host, which gladly gives its own public key to the kiosk, opens a connection to the real host, and patches all the session traffic through, capturing the password and the entire session without the user's knowledge.
  • The only difference between "normal" FTP
    and "passive" mode FTP is that in passive
    mode, the client opens the data connection
    to the server, instead of vise-versa.
    The data connection is still a separate
    stream, and happens between random ports.
    Passive is good for things like NAT firewalls,
    though, because it allows all connections to
    remain outbound instead of requiring an
    inbound connection. But it will still bypass
    your port forwarding.

  • Secure FTP: A few ways (Score:5)

    by angio ( 33504 ) on Monday May 10, 1999 @06:46PM (#1898487) Homepage
    As a previous poster suggested, use ssh with port forwarding. You might want to see the SSH FAQ:

    http://www.uni-karlsruhe.de/~ig25/ssh-faq/ [uni-karlsruhe.de]

    As it points out, this will leave the data connection open to sniffing/hijacking. If you only care about the integrity of the files you transfer, then verifying against (securely obtained) md5 checksums should do the trick. If you want to encrypt the datastream, you'll need to be a bit more fancy.

    If it's possible, consider the use of 'scp' instead of ftp; you'll get protection of both control and data, since it's built into ssh.

    Another option (if you control the clients as well) is to use ssh2's "sftp" client. Beware the licensing issues with ssh2, however.

    If you really trust the clients, it's also quite easy to set up a VPN between the client and server, and then FTP directly. The ways to go about this depend on the OS you're using, so I'll leave it as an exercise to the reader.

  • There's a program called wget that'll do this for unix. You can get it from any of the GNU archives.

  • Ah, but it does matter; on a lot (most) systems, a user's ftp password is the same password that the user uses for interactive logins.
  • A quick and dirty way to do a secure file transfer is to use Z-Modem over a secure telnet session. (man rz and sz for more info...)
    TeraTerm is a free Windows telnet client that has both Z-Modem and SSH support. http://www.zip.com.au/~roca/ttssh.html
    I have been unable to secure WS_FTP using port forwarding with Igaly's SSH client http://www.doc.ic.ac.uk/~ci2/ssh/ because the data port changes on the Windows side with each connection...

  • ssh + ftp passive mode (Score:3)

    by modus ( 122983 ) on Monday May 10, 1999 @06:38PM (#1898491)
    Use ssh's port forwarding, combined with ftp's passive mode. man ssh.

Slashdot Top Deals

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Close