ftp小程序_FTP程序安全吗？

最新推荐文章于 2024-01-10 11:15:15 发布

culi3118

最新推荐文章于 2024-01-10 11:15:15 发布

阅读量403

点赞数

原文链接：https://www.sitepoint.com/are-ftp-programs-secure/

版权

ftp小程序

Do you deploy or transfer files using FTP? Given the age of the protocol and its wildly popular nature amongst a wide number of hosting companies, it’s fair to say you might.

您是否使用FTP部署或传输文件？考虑到该协议的年代以及它在众多托管公司中的广泛流行性，可以肯定地说。

But are you aware of the security issues this may open up for you and your business? Let’s consider the situation in-depth.

但是您是否知道可能会为您和您的企业带来安全性问题？让我们深入考虑一下情况。

Programs such as FileZilla, CyberDuck, Transmit, or Captain FTP can be secure. They may implement measures such as obscuring passwords from view by those around you. But if you’re transferring data with FTP, these measures are effectively mitigated.

FileZilla ， CyberDuck ， Transmit或Captain FTP等程序可以是安全的。他们可能会采取措施，例如使周围的人看不到密码。但是，如果使用FTP传输数据，则可以有效地缓解这些措施。

I’ll cut to the chase; the reason I’m writing this is because of an interesting discussion on SitePoint back in August. The discussion focused quite heavily on FileZilla, making a range of assertions as to how insecure it is (or isn’t).

我会追赶；之所以写这篇文章，是因为8月份在SitePoint上进行了有趣的讨论。讨论主要集中在FileZilla上，对它的安全性(或不安全性)做出了一系列断言。

A key aspect of the debate centered around whether you should store your passwords with FileZilla. One of the comments linked to a quite descriptive article which showed that, despite obscuring your credentials when using the software, if you save your credentials, they’re quite easy to retrieve.

辩论的关键方面集中在您是否应该使用FileZilla存储密码。其中一篇评论与描述性很强的文章相关，该文章表明，尽管使用软件时会模糊您的凭据，但如果保存凭据，则很容易找回它们。

If you’ve not read the article, FileZilla stores connection details in a simple XML file, an example of which you can see below.

如果您尚未阅读本文，FileZilla会将连接详细信息存储在一个简单的XML文件中，您可以在下面看到一个示例。

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<FileZilla3>
    <Servers>
        <Server>
            <Host>localhost</Host>
            <Port>21</Port>
            <Protocol>0</Protocol>
            <Type>0</Type>
            <User>anonymous</User>
            <Pass>user</Pass>
            <Logontype>1</Logontype>
            <TimezoneOffset>0</TimezoneOffset>
            <PasvMode>MODE_DEFAULT</PasvMode>
            <MaximumMultipleConnections>0</MaximumMultipleConnections>
            <EncodingType>Auto</EncodingType>
            <BypassProxy>0</BypassProxy>
            <Name>test site</Name>
            <Comments />
            <LocalDir />
            <RemoteDir />
            <SyncBrowsing>0</SyncBrowsing>test site
        </Server>
    </Servers>
</FileZilla3>

You can see that it’s storing a lot of information about the connection, so that you don’t need to remember it. But note how it stores your password in the clear too?

您会看到它存储了大量有关连接的信息，因此您无需记住它。但是，请注意它也如何清楚地存储您的密码？

Sure, when you use the program, it obscures the password, as shown in the screenshots above, so that it can’t be read over your shoulder.

当然，当您使用该程序时，它会掩盖密码，如上面的屏幕截图所示，以致您无法在肩膀上读取它。

But there’s little point when you can just lift it from the computer, should you have access. To be fair, in the latest version of FileZilla, storing passwords is disallowed by default.

但是，只要有访问权限，就可以从计算机上将其提起，这毫无意义。公平地说，在最新版本的FileZilla中，默认情况下不允许存储密码。

加密的配置文件呢？ (What About Encrypted Configuration Files?)

People suggested that at the very least, the configuration files should be encrypted or be set up in such a way as to ask for a master password before access was granted, much like 1Password and KeePassX do.

人们建议，至少应该对配置文件进行加密或设置，以便在授予访问权限之前要求输入主密码，就像1Password和KeePassX一样。

Louis Lazaris then linked to a discussion on Stack Exchange, which attempted to counter the position. Here’s the core of the post:

然后，Louis Lazaris链接到关于Stack Exchange的讨论，该讨论试图抵消这一立场。这是帖子的核心：

You see, encrypting the credentials requires an encryption key which needs to be stored somewhere. If a malware is running on your user account, they have as much access to what you (or any other application running at the same level) have. Meaning they will also have access to the encryption keys or the keys encrypting the encryption keys and so on.

您会看到，加密凭据需要加密密钥，该密钥必须存储在某个位置。如果您的用户帐户上正在运行恶意软件，则他们具有对您(或以相同级别运行的任何其他应用程序)拥有的访问权限。意味着他们还将有权访问加密密钥或加密加密密钥的密钥等。

I believe the above assertion doesn’t fully appreciate the design considerations of programs such as the two listed above. Applications which are specifically designed to be a secure vault for passwords, and other secure information, would likely not be as easy to crack as this answer implies.

我相信上述主张并未完全理解上述程序之类的程序的设计考虑。专门设计为用于密码和其他安全信息的安全保险库的应用程序可能不会像此答案所暗示的那样容易破解。

For example, a recent blog post from 1Password lists a number of the key mechanisms employed in the fight against crackers.

例如，最近在1Password上发表的一篇博客文章列出了打击饼干中采用的许多关键机制。

These include 128 and 256-bit symmetrical keys, SHA512 and PBKDF2 encryption – along with a range of other features employed to protect the data files being accessed, all while retaining the ease of use and simplicity of them.

这些功能包括128位和256位对称密钥， SHA512和PBKDF2加密-以及用于保护正在访问的数据文件的一系列其他功能，同时又保留了它们的易用性和简单性。

So to infer that employing secure encryption vaults is not really any more secure is incorrect, especially given all of these techniques available.

因此，推断使用安全加密保险库实际上不再具有更高的安全性是不正确的，特别是考虑到所有这些可用技术。

它是FTP，而不是您的应用！ (It’s FTP, Not Your App!)

But the arguments of whether credentials should or shouldn’t be saved is moot, as there’s a key point which using FTP in the first place overlooks – your credentials and data are sent in the clear. Don’t believe me? Have a read of Why is FTP insecure, on the Deccanhosts blog.

但是，是否应该保存凭据的争论还没有定论，因为首先要注意的是使用FTP忽略了一个关键点- 您的凭据和数据以明文形式发送 。不相信我吗在Deccanhosts博客上阅读“ 为什么FTP不安全” 。

If you weren’t aware of it, through using a simple packet sniffer, such as Wireshark, you can retrieve not only the username and password used, but any other credentials stored in the files being sent, along with the algorithms, database structures, and anything else stored there.

如果您不知道它，可以使用简单的数据包嗅探器(例如Wireshark) ，不仅可以检索使用的用户名和密码，还可以检索存储在要发送的文件中的任何其他凭证以及算法，数据库结构，还有其他存放在那里的东西。

Given the fact that, for quite some time, it’s been common practice to store this information in .ini and config files, I’d suggest quite a large amount of readily downloaded software, such as WordPress, Joomla, etc., will be developed in such a fashion.

考虑到很长一段时间以来，将这些信息存储在.ini和config文件中这一事实已经成为惯例，我建议开发大量易于下载的软件，例如WordPress，Joomla等。以这种方式。

FTP was never designed with security in mind; it was designed as a public service. Inherent in this design were a series of further assumptions, which also didn’t take security into consideration. Enrico Zimuel, senior software engineer at Zend, even goes so far as to say: Never use FTP – ever!

FTP的设计从未考虑过安全性。它被设计为一项公共服务。此设计中固有的是一系列进一步的假设，这些假设也没有考虑安全性。 Zend的高级软件工程师Enrico Zimuel甚至说： 永远不要使用FTP！

Yes, security changes came later, but they were added on — not built-in. There’s no protection against brute-force attacks and while SSH tunneling is possible, it’s difficult, as you need to encrypt both the command and data channels. As a result, your options are limited. And when you seek to implement them, the difficulty factor isn’t always trivial.

是的，安全更改后来出现了，但是它们是添加的-不是内置的。没有针对暴力攻击的保护措施，虽然可以进行SSH隧道传输，但是这很困难，因为您需要同时加密命令和数据通道。结果，您的选择受到限制。而当您寻求实施它们时，困难因素并不总是那么琐碎。

Are you a Webmaster? Do you enable a chroot jail for your FTP users? If you’re not familiar with the term chroot, it’s a way of limiting user movement and access. From the directory they log into, they can descend into any sub-directory but can’t move outside of it.

您是网站管理员吗？是否为您的FTP用户启用chroot监狱？如果您不熟悉chroot一词，这是一种限制用户移动和访问的方式。从他们登录的目录中，他们可以进入任何子目录，但不能移出该目录。

FTP的备用选项 (Alternate Options to FTP)

Before I convince you that it’s all doom and gloom – it’s not. A number of the FTP programs around today – especially the ones referenced earlier – also support some more secure derivatives of and alternatives to FTP. Let’s have a look at them.

在我说服您这一切都是厄运和忧郁之前，并非如此。如今，许多FTP程序(尤其是前面提到的FTP程序)也支持FTP的一些更安全的派生和替代。让我们看看它们。

FTPS和SFTP (FTPS and SFTP)

FTPS is Secure FTP, much like HTTPS is secure HTTP, and runs over SSL (Secure Sockets Layer) and TLS (Transport Layer Security). The user credentials and data are no longer sent in the clear; instead they are encrypted before they’re transmitted.

FTPS是安全FTP，就像HTTPS是安全HTTP一样，它在SSL(安全套接字层)和TLS(传输层安全性)上运行。用户凭证和数据不再以明文形式发送；而是在传输之前先对其进行加密。

Client software also has the flexibility, if it’s allowed by the server, to encrypt only parts of the communication, not all of it. This might seem counterintuitive based on the discussion so far.

如果服务器允许，客户端软件还具有灵活性，可以仅加密部分通信，而不是全部加密。根据目前的讨论，这似乎违反直觉。

But if the files being transferred are already encrypted, or if no information of a sensitive nature is being transferred, then it’s likely ok not to incur the overhead that encryption requires.

但是，如果正在传输的文件已经被加密，或者没有任何敏感信息正在传输，那么可能不会招致加密所需的开销。

However, switching to FTPS does come at a cost (and a price). Using FTPS involves generating either a self-signed SSL certificate, or purchasing one from a trusted certificate authority. So better security is available, but there’s a greater amount of effort and cost involved.

但是，切换到FTPS确实要付出一定的代价(和代价)。使用FTPS涉及生成自签名SSL证书，或从受信任的证书颁发机构购买证书。因此可以获得更好的安全性，但是涉及更多的工作量和成本。

But before you shy away, ask yourself how much your information is worth to your business? That might convince you to preservere.

但是，在您回避之前，请先问问自己，您的信息对您的企业有多少价值？那可能会说服您保存。

Now let’s look at SFTP. SFTP, or SSH File Transfer Protocol, works differently to FTPS. Designed as an extension of SSH 2.0, SFTP creates a normal FTP connection but executes it over an already encrypted connection. The FTP data stream itself is no more secure than normal FTP, however, the connection over which it operates is more secure.

现在让我们看一下SFTP。 SFTP或SSH文件传输协议与FTPS的工作方式不同。 SFTP被设计为SSH 2.0的扩展，可创建普通的FTP连接，但会在已加密的连接上执行它。 FTP数据流本身并不比普通FTP安全，但是，其操作所基于的连接更为安全。

If you’re going to move away from FTP, why take half measures? Why use FTP at all? If you’ve installed SFTP, you’ve installed the SSH tools; these give you access to a wide array of functionality.

如果要离开FTP，为什么要采取一半措施？为什么要完全使用FTP？如果已经安装了SFTP，则已经安装了SSH工具。这些使您可以访问各种功能。

Starting at the top with SSH itself, this provides full user access to the remote system, letting them do more than standard FTP ever would, or could. The connection is secure and data can be copied from one system to another quite easily.

从SSH本身的顶部开始，它提供了对远程系统的完全用户访问权限，从而使他们可以执行比标准FTP曾经或可能做的更多的事情。连接是安全的，可以很容易地将数据从一个系统复制到另一个系统。

If you’re a bit of a command line guru, you can even use a tool such as Rsync over SSH.

如果您有点命令行专家，甚至可以使用诸如Rsync over SSH之类的工具。

In a simple use case, it can be used to recursively copy all files from a local directory to a directory on a remote machine. The first time it’s run, all files are copied over.

在一个简单的用例中，它可以用于将所有文件从本地目录递归复制到远程计算机上的目录。第一次运行时，所有文件都被复制。

The second and subsequent times, it checks for file differences, transferring only the differences, newer files, and optionally removing files and directories on the remote machine no longer present locally.

第二次及以后，它将检查文件差异，仅传输差异，更新文件，还可以选择删除本地不再存在的远程计算机上的文件和目录。

The problem is that granting this kind of access is in itself a security issue waiting to happen. But the effects can be mitigated. OpenSSH allows for a number of configuration choices, such as disallowing root access, limiting the users who can login remotely, and chroot’ing users to specific directories.

问题在于，授予这种访问权限本身就是一个等待发生的安全问题。但是效果可以减轻。 OpenSSH允许许多配置选择，例如禁止root访问，限制可以远程登录的用户以及将用户chroot到特定目录。

Perhaps users don’t need to be on the remote machine in the first place or don’t need many privileges while they’re there. If that’s the case, and it likely is, you can pick from a number of shells, designed to accommodate these situations.

也许用户一开始不需要在远程计算机上，或者在他们不在时不需要很多特权。如果是这种情况，很可能是这样，您可以从许多旨在适应这些情况的外壳中选择。

Two of the best are scponly and rssh. Scponly only allows a user to copy files to a remote machine.

最好的两个是scponly和rssh 。 Scponly仅允许用户将文件复制到远程计算机。

The user can’t login, move around, look at, or change files. What’s great is that it still works with rsync (and other tools). rssh goes a bit further, allowing access to SCP, SFTP, rdist, rsync and CVS.

用户无法登录，四处浏览，查看或更改文件。很棒的是，它仍然可以与rsync(和其他工具)一起使用。 rssh更进一步，允许访问SCP，SFTP，rdist，rsync和CVS。

To implement it, a systems administrator need only change the user’s shell, with their tool of choice, and then edit /etc/rssh.conf, listing the allowed protocols. Here’s an example configuration:

要实现它，系统管理员只需要使用他们选择的工具来改变用户的外壳，然后编辑/etc/rssh.conf ，列出允许的协议。这是一个示例配置：

allowscp
allowsftp

This configuration allows users to use only SCP and SFTP.

此配置允许用户仅使用SCP和SFTP。

SSH密钥 (SSH Keys)

Next, let’s consider SSH keys. The process takes a bit of an explanation, but I’ll try and keep it quick and concise, paraphrasing heavily from this answer on Stack Exchange:

接下来，让我们考虑SSH密钥。该过程需要一些解释，但是我将尝试使其保持简洁明了，从Stack Exchange上的此答案中大量阐述：

First, the public key of the server is used to construct a secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication. After the channel is functional and secure, authentication of the user takes place.

首先，通过启用对称密钥的协商，使用服务器的公共密钥来构建安全的SSH通道，该对称密钥将用于保护其余会话，启用通道机密性，完整性保护和服务器身份验证。在通道正常运行并安全之后，将对用户进行身份验证。

The server next creates a random value, encrypts it with the public key of the user and sends it to them. If the user is who they’re supposed to be, they can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model.

接下来，服务器创建一个随机值，使用用户的公共密钥对其进行加密并将其发送给他们。如果用户是他们的真实身份，则他们可以解密质询并将其发送回服务器，服务器再确认用户的身份。这是经典的挑战响应模型。

The key benefit of this is that the private key never leaves the client nor is any username or password ever sent. If someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) – your private details will never fall in the hand of the attacker.

这样做的主要好处是，私钥永远不会离开客户端，也不会发送任何用户名或密码。如果有人拦截了SSL流量并能够对其进行解密(使用受损的服务器私钥，或者如果您在连接到服务器时接受了错误的公钥)，那么您的私密信息将永远不会落入攻击者的手中。

When used with SCP or SFTP, this further reduces effort required to use them, while increasing security. SSH keys can require a passphrase to unlock the private key, and this may seem to make them more difficult to use.

与SCP或SFTP一起使用时，这进一步减少了使用它们所需的工作量，同时提高了安全性。 SSH密钥可能需要密码来解锁私钥，这似乎使它们更难以使用。

But there are tools around which can link this to your user session, when you log in to your computer. When set up correctly, the passphrase is automatically supplied for you, so you have the full benefit of the system.

但是，当您登录到计算机时，有一些工具可以将其链接到您的用户会话。正确设置后，将自动为您提供密码短语，因此您将获得系统的全部好处。

连续交付呢？ (What About Continuous Delivery?)

Perhaps you’ve not heard the term before, but it’s been floating around for some time now. We’ve written about it on SitePoint before, as recently as last week. Coined by Martin Fowler, Continuous Delivery is defined as:

也许您以前没有听过这个词，但是现在已经有一段时间了。早在上周，我们就在SitePoint 上进行了介绍。由马丁·福勒(Martin Fowler)创造，连续交付定义为：

A software development discipline where you build software in such a way that the software can be released to production at any time.

软件开发专业，您可以以可以随时将其发布到生产环境的方式构建软件。

There’s many ways to implement it, but services such as Codeship and Beanstalk go a long way to taking the pain away.

有很多方法可以实现它，但是诸如Codeship和Beanstalk之类的服务可以大大减轻痛苦。

Here’s a rough analogy of how they work. You set up your software project, including your testing code and deployment scripts, and store it all under version control. I’ll assume you’re using an online service, such as GitHub or Bitbucket.

这是它们工作方式的粗略类比。您可以设置软件项目(包括测试代码和部署脚本)，并将其全部存储在版本控制下。我假设您使用的是在线服务，例如GitHub或Bitbucket。

When a push is made to either of these services, after a commit or release is made in your code branch, the service then runs your application’s tests. If the tests pass, then a deployment of your application is made, whether to test or production.

当对这些服务之一进行推送时，在您的代码分支中进行了提交或释放之后，该服务将运行应用程序的测试。如果测试通过，则将部署应用程序，无论是测试还是生产。

Assuming everything went well, it would then take care of rolling out a deployment for you automatically. You’d be notified afterwards that the deployment had either succeeded or failed.

假设一切顺利，那么它将为您自动部署一个部署。之后会通知您部署成功或失败。

If it succeeded, then you can continue on with the next feature or bug fix. If something went wrong, you can check it out to find the cause of the issue. Have a look at the short video below, showing the deployment of a test repository in action with Codeship.

如果成功，则可以继续进行下一个功能或错误修复。如果出现问题，您可以检查出问题的原因。观看下面的简短视频，该视频展示了Codeship实际使用的测试存储库的部署。

What did you have to do? Push a commit to the Github repository – that’s it! You don’t need to remember to run scripts, where they are, what options and switches to pass to them (especially not late on a Friday evening, when you’d rather be anywhere but doing work).

你该怎么办将提交推送到Github存储库–就是这样！您无需记住运行脚本，运行脚本的位置，传递给脚本的选项和开关(尤其是在周五晚上不愿去工作的时候)。

I appreciate that’s rather simplistic and doesn’t cover all the options and nuances, but you get the idea.

我很欣赏那很简单，并没有涵盖所有的选择和细微差别，但是您明白了。

人为错误问题 (The Problem of Human Error)

Let’s finish up by moving away from the basic security concerns of using FTP, to the effectiveness of doing so on a day-to-day basis. Let’s say, for example, that you’re developing a website, say an e-commerce shop, and your deployment process makes use of FTP, specifically FileZilla.

最后，让我们从使用FTP的基本安全问题转移到日常使用的有效性上。例如，假设您正在开发一个网站，例如一家电子商务商店，并且您的部署过程使用了FTP，特别是FileZilla。

There’s a number of inherent issues here, relating to human error:

这里有许多与人为错误有关的固有问题：

Will all the files be uploaded to the right locations?
是否会将所有文件上传到正确的位置？
Will the files retain or obtain the required permissions?
文件将保留还是获得所需的权限？
Will one or two files be forgotten?
一两个文件会被遗忘吗？
Is there a development name that needs to be changed in production?
在生产中是否需要更改开发名称？
Are there post deployment scripts that need to be run?
是否需要运行部署后脚本？

All of these are valid concerns, but are all easily mitigated when using continuous delivery tools. If it’s late, if the pressure’s on, if the person involved is either moving on from the company or keen to get away on holidays, manually transferring files over FTP is asking for trouble.

所有这些都是有效的关注点，但是在使用连续交付工具时，所有这些都可以轻松缓解。如果太晚了，压力越来越大，如果涉及的人正在从公司搬迁或者想休假，那么通过FTP手动传输文件会带来麻烦。

Ok, manually transferring files, period, is asking for trouble. Human error is just too difficult to remove.

好的，手动传输文件会引起麻烦。人为错误很难消除。

快速道歉FileZilla (Quick Apology to FileZilla)

I don’t want to seem like I’m picking on FileZilla. It’s a really good application and one I’ve made good use of over a number of years. And there have been techniques used to attempt to make it more secure.

我不想看起来像在选择FileZilla。这是一个非常好的应用程序，并且我已经使用了很多年了。并且已经有一些技术试图使它更加安全。

The key point I have is with FTP itself, not necessarily with FileZilla alone.

我的要点是使用FTP本身，而不必单独使用FileZilla。

结语 (Wrapping Up)

So this has been my take on the FTP security debate. My recommendation — just don’t use it; what’s more, when managing deployments, keep security in mind. After all, it’s your data.

因此，这就是我对FTP安全性辩论的看法。我的建议-只是不要使用它；此外，在管理部署时，请牢记安全性。毕竟，这是您的数据。

But what are your thoughts? Do you still use FTP? Are you considering moving away? Share your experiences in the comments and what solutions you’ve tried so we can all work towards a solution that’s practical and easy to use.

但是您有什么想法？您还在使用FTP吗？您正在考虑搬走吗？在评论中分享您的经验以及您尝试过的解决方案，以便我们共同努力制定实用且易于使用的解决方案。