在工作中，我们一直在尝试将面向外部的服务从包容性政策（我们试图接受尽可能多的人）转移到更加注重安全的设置。
第一步是对我们的一些核心 Web 应用程序进行渗透测试，其中的重点往往是应用程序代码中的弱点，但 SSL/TLS 套件和密码已经说了很多。在这些测试结果的背后，我已经设法至少让足够多的人对在 Qualys 测试中获得 A-、A 和 A+“等级”感兴趣（管理就像可量化的等级——谁知道？！）。
但是，我们的一些软件的另一个关键组件是通过 SFTP（即通过 SSH）进行批量文件上传/下载。我一直尝试在 SFTP 服务器上应用我可以确定的最佳实践，因此我们经常使用：
- 仅密钥身份验证
- 将重复的身份验证失败列入黑名单
- 2,048 位密钥
- 禁用 shell、exec 和端口转发
但我必须承认，我对加密实现知之甚少，因此几乎总是使用默认设置。但是，我认为，如果渗透测试人员标记 RC4、3DES、MD5 等。在基于 TLS 的设置中，他们还会在 SFTP 服务器中标记这些算法（是否包含在他们的范围内）。
我主要在 Windows 堆栈上工作，多年来我们一直使用 VanDyke VShell 作为我们选择的 SFTP 服务器。默认情况下，它启用所有密码和 MAC 选项（“无”除外）和所有密钥交换选项，“Kerberos”和“Kerberos（组交换）”除外。
这留下了以下算法，由 VShell 应用程序命名：
- 密钥交换： diffie-hellman-group14、diffie-hellman、diffie-hellman-group
- 密码： AES-256-CTR、AES-192-CTR、AES-128-CTR、AES-256、AES-192、AES-128、Twofish、Blowfish、3DES、RC4
- MAC： SHA1、SHA1-96、MD5、MD5-96、UMAC-64 （以及更新版本） SHA2-512、SHA2-256
至于问题：
- 我在哪里可以确定哪些现在被认为太弱而无法使用？
- 我如何才能最好地确定禁用其中任何一项是否会对我的最终用户产生不利影响？
- 是否有任何类似 Qualys 的测试可以用来定期评估这些服务器，最好有令人信服的证据来击败管理层提交？