【问题标题】:Best way to implement an SFTP server solution? [closed]实施 SFTP 服务器解决方案的最佳方式? [关闭]
【发布时间】:2011-11-22 04:07:14
【问题描述】:

我目前正在设置一个商业 SFTP 服务器,我只是在寻找您对我目前正在考虑实施的设置的一些意见,以及关于什么商业安全 FTP 服务器软件的建议最好适合。请记住,我负责的数据非常敏感,因此非常感谢任何 cmets/反馈。

这是场景:

1) 在文件上传之前,使用带有盐的 AES 256 压缩和加密文件。

2) 通过 SFTP(端口 22)从客户端服务器上传到我们的 SFTP 服务器的文件。

3) 我们的其他客户端使用一次性密码验证(强 10 字符字母数字密码)通过 HTTPS 下载文件

我正在考虑的实现细节是:

对于上面的第 (2) 部分,使用主机密钥匹配、公钥认证和用户名/密码组合打开连接。两边的防火墙被限制为只允许客户端服务器的静态IP连接。

对于第 (3) 部分,为其他客户端提供了每个用户的用户名/密码(用于审核),以登录其在服务器上的被监禁帐户。文件本身的加密密码是基于每个文件提供的,所以我试图在这里始终应用两种加密模式(除非文件位于服务器上)。

加上双方的专用防火墙,SFTP 服务器上的访问控制将被配置为在短时间内阻止一定次数的失败尝试的 IP 地址,无效的密码尝试将锁定用户,将实施密码策略等.

我想我已经尽可能多地介绍了,但我很想听听你们对这个实现的看法?

对于商业服务器方面,我已将其范围缩小为带 SSH 和 HTTP 模块的 GloalSCAPE SFTP 或 JSCAPE 安全 FTP 服务器 - 我将在周末评估每个服务器的适用性,但如果你们有有任何经验我也很想听听。

【问题讨论】:

标签: security https ssh aes sftp


【解决方案1】:

由于从客户的角度来看,数据显然既重要又敏感,我建议您咨询安全专家。本土解决方案通常是过度杀伤和杀伤力不足的结合,导致机制既低效又不安全。考虑:

  • 文件已预先加密,因此 SFTP/HTTPS 的唯一好处是会话本身的加密(例如登录),但是...

  • 您使用 PKI 进行上传,使用 OTP 进行下载,因此没有泄露密码的风险,只有用户 ID - 这对您来说很重要吗?

  • 您将如何传输一次性密码?传输安全吗?

  • 请记住,任何锁定方案都应该是临时的,否则黑客可以通过锁定每个帐户来禁用整个系统。

要问自己的问题:

  • 我在保护什么?
  • 我在保护谁?
  • 攻击媒介有哪些?
  • 违规的可能性和风险是什么?

一旦你回答了这些问题,你就会对实施有更好的了解。

一般:

  • 您选择的 AES256 + salt 非常合理。
  • 多因素身份验证可能比加密的多次迭代更好。它通常被认为是“您拥有的东西,加上您知道的东西”,例如证书和密码,两者都需要才能访问。

就可用的实用程序而言,许多现成的软件包既安全又易于使用。初学者请查看 OpenSSH、OpenVPN 和 vsftp。

祝你好运 - 请告诉我们您选择的方法!

【讨论】:

  • +1 建议引进以此为生的人
  • 我猜想在通过 sftp 通道之前加密内容的目的是内容在服务器上保持加密状态,因此服务器人员无法偷看它。使用 sftp 服务器可能只是为了方便(安全身份验证)。
  • 您在这里提出的问题确实是人们在深入研究协议和算法之前应该考虑的问题。为此 +1。
  • HTTPS 还提供端点身份验证。普通的 OTP 可以轻松实现 MITM。高价值交易需要考虑物理安全、业务连续性等。
【解决方案2】:

那么,Linux 和 BSD 附带的 OpenSSH 有什么问题?

【讨论】:

    【解决方案3】:
    Before file upload, files are compressed & encrypted using AES 256 with a salt.
    

    这部分敲响了一些警钟...您是否编写了一些代码来执行此加密/压缩?您如何进行密钥管理?您还说您的密钥是密码派生的,因此您使用 AES 256 和 salt 会给您一种错误的安全感 - 您的真实密钥空间要少得多。此外,此处使用“盐”一词也不合适,这表明存在更多弱点。

    最好使用经过充分验证的实现(例如 PGP 或 GPG 之类的东西)。

    此外,如果您对文件本身使用 PGP 样式的公钥加密(以及适当的密钥管理),您的 SFTP 服务器的安全性将不会那么重要。您的文件可以静态加密。

    关于系统其余部分安全性的论点非常复杂(大量协议、身份验证方案和控制) - 稳健地保护文件会容易得多,然后对其余部分进行最佳实践(这将不那么重要,而且是独立控制)。

    【讨论】:

    • PGP 或 GPG 是否为您提供对称密码?这似乎是他所需要的。
    • 可以,但我建议他使用公钥方法 - 反正他已经在管理公钥,所以他也可以在重要的地方使用它们。
    • 我反对在这种情况下使用公钥。他们要求您在编码时知道收件人的密钥,这可能不是这里的情况。
    • 我的意思是 GPG/PGP 为您提供了一个可供选择的密码列表,而不是一个特定的密码。事实上,AES256 就是其中之一。公钥仅用于上传。下载端使用 OTP。所以这可能并不容易。
    • 是的,但我认为所有这些都是独立的——而且它很复杂,听起来像是“通过复杂性实现安全”,这是一种反模式。先独立保护文件,然后看看还有哪些威胁。我还 +1 推荐了让安全审查员加入的想法。
    猜你喜欢
    • 2012-12-06
    • 2011-10-15
    • 2013-06-11
    • 1970-01-01
    • 1970-01-01
    • 2012-04-23
    • 2013-10-19
    • 1970-01-01
    • 2021-04-11
    相关资源
    最近更新 更多