[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure FTP?
Thanks , your link to security comments was very usefull
- I do agree with you over client side exit programs (our auditors did not agree :) but they are always not happy ). however the other way around (i.e sftp to the as400 being sshd) is not considered good enough because of the exit program issue.
- Regarding complexity. In the times i was asked to implement ssh client the remote server wanted to use user\password authentication (remote site Did not agree to work with keys). That means:
* password stuff needs to be encrypted just like ftps
* Need to use expect for scripting (thanks to your fine article i managed to set it up). I think the expect script is much more complex than the ftps script.
one more minor issue - sftp client support only binary which sometimes mean doing pre proccesing to generate the required file..
----- Original Message -----
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
Date: Monday, October 25, 2010 9:19 pm
Subject: Re: Secure FTP?
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Hello,
>
> On 10/25/2010 12:55 PM, Shahar Mor wrote:
> > can you please describe the reason behind your recommendation for
> > openssh rather than ftps ?
>
> 1) FTPS isn't as secure as SSH. Here's my description of why:
> http://archive.midrange.com/midrange-l/201009/msg00091.html
>
> 2) FTPS is not as widely used as SSH
>
> 3) FTPS is difficult to get working through a firewall, creating much
>
> pain and headaches and unreliability.
>
>
> > The openssh does not support exit programs which are part of security
> > schema of many shops in the as400
>
> We're talking about the _client_ side of communications here, not
> server. Security the client side with an exit program makes no sense.
>
> As an analogy: Imagine if banks didn't have big, secured locked,
> vaults, but instead went to every would-be bank robber's house, and
> nailed their doors shut. Instead of protecting the money in the bank,
>
> they went to every possible thief's house and locked them inside, thus
>
> preventing them from coming to rob the bank! It wouldn't work, would
>
> it? The robber would just find another way out of the house. Or even
>
> if he couldn't, another robber would. Somehow, some way, the bank
> would
> miss one of the robbers. You can't secure them inside all of their houses!
>
> But that's pretty much what you're suggesting when you try to secure
> data by locking down the client. You need to lock down the SERVER
> (the
> bank vault) not the client! Exit programs on the client make no sense.
>
>
> > and it is more difficult to establish batch oriented sftp client
>
> I challenge that. I don't think it's more difficult -- I think it's
> much easier!
>
> an FTPS script to download all files from a directory, then delete
> them
> from the server:
>
> klemscot bigboy
> cd /the/directory
> mget *
> mdel *
> quit
>
> What's wrong with this script?
>
> 1) The userid/password are hard-coded. That's not good, because now
> anyone with access to my source code or compiled object can get my
> password. Now I have to write a system to replace that password
> on-the-fly... more work, and more difficult.
>
> 2) Worse, if this is to be automated, I need to also encrypt that
> password, and protect the key somehow, since I can't have a user
> typing
> it at run-time. Now I need to learn cryptography, and I need to get
> it
> right. Since I'm writing the cryptography myself, I don't have a
> large
> community of crypto-experts to help me. If I make any mistakes, I'm
> vulnerable.
>
> 3) If the 'cd' command fails, it'll download all of the files from the
>
> wrong directory, since the script will just continue running.
>
> 4) If the mget command fails, it'll still delete all of the files from
>
> the directory with mdel, because the script will continue.
>
> 5) After it completes, my program needs to know if it succeeded or
> failed. My only information about that is an output log file -- I'll
>
> need to write a complex RPG program to interrogate that log. I must
> be
> careful to get it right, since I don't know exactly which messages
> will
> occur at run-time. If anything is wrong, I must detect it by
> analyzing
> the log file, or I won't know that it failed.
>
> Now let's look at the same thing with sftp (remember, you told me this
>
> would be _harder_)
>
> cd /the/directory
> get *
> del *
>
> Notice that it's almost identical. What happened to it being harder?
>
> 1) the userid is passed on the sftp command, not hard-coded in the script.
>
> 2) the password is eliminated, and a secure digital key is used in
> it's
> place. The cryptography behind the key was designed and tested by a
> large community of crypto experts who actively maintain it's security.
>
> 3) This script will abort when the commands fail. It will not simply
>
> proceed. That way, I dont' have to worry about the get being run if
> the
> cd fails. Likewise, I don't have to worry about the del being run if
>
> the get fails.
>
> 4) After the script ends and my program regains control I can
> immediately tell if it succeeded or failed by checking the exit
> status... no need to try to analyze and interpret a complex output log.
>
> Harder?!
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------