[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Secure FTP?
Dave;
Trust me, a subscription to System/I Network will be the best ~$200 you will spend all year, even if all you do is get the sftp articles. It will save you and your company lots of time and pain.
Duane Christen
--
Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx
Visit PAETEC.COM
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of daparnin@xxxxxxxxxxxxxx
Sent: Monday, October 25, 2010 3:19 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Secure FTP?
Thanks everybody for the feedback. This gives me a direction. I just have the basic System/i Network access which isn't good enough to get to the articles but I'll dig around and see what I can find.
Dave Parnin
--
Nishikawa Standard Company
324 Morrow Street
Topeka, IN 46571
260-593-2156 ext. 621
daparnin@xxxxxxxxxxxxxx
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Date: 10/25/2010 03:25 PM
Subject: Re: Secure FTP?
Sent by: ftpapi-bounces@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
-----------------------------------------------------------------------