☰

SSH 压缩是否会使协议变得更加不安全？

tag-icon • tag-icon ssh hardening
SSH 压缩是否会使协议变得更加不安全？

我正在使用名为的工具审核一台 ubuntu 服务器莱尼斯，它对配置文件执行了几个测试，并给出了加强服务器的建议。例如，它建议将 MaxAuthTries 的值从 6 减少到 3，这对我来说很有意义……但有一个建议我不明白：

  * Consider hardening SSH configuration [SSH-7408] 
    - Details  : Compression (set YES to NO)
      https://cisofy.com/lynis/controls/SSH-7408/

我已阅读给定的链接SSH-7408，并做了一些网络研究，但我不明白在 SSH 服务器中启用压缩如何会使协议比禁用压缩更不安全。

答案1

从历史背景来看（OpenSSH sshd 7.4 之前），不设置的建议Compression yes确实有意义：

OpenSSH 4.2 在 2005 年引入Compression delayed并解释了为什么他们将其作为其默认设置发行说明。他们还解释了何时/为何Compression yes需要这样做以及会面临哪些风险：

- Added a new compression method that delays the start of zlib
compression until the user has been authenticated successfully. 
The new method ("Compression delayed") is on by default in the 
server. This eliminates the risk of any zlib vulnerability 
leading to a compromise of the server from unauthenticated users.

NB. Older OpenSSH (<3.5) versions have a bug that will cause them
to refuse to connect to any server that does not offer compression
when the client has compression requested. Since the new "delayed"
server mode isn't supported by these older clients, they will
refuse to connect to a new server unless compression is disabled
(on the client end) or the original compression method is enabled
on the server ("Compression yes" in sshd_config)

根据这些评论，您可以轻松明白为什么检测的安全扫描程序Compression yes可能会生成警告。

这是一个潜在的风险设置，仅适用于旧版（2005 年已是旧版）客户端。

但恕我直言，建议应该设置Compression delayed，这也是 OpenSSH 的默认设置。

但 OpenSSH 服务器 7.42016 年发布和：

sshd(8): Remove support for pre-authentication compression.
Doing compression early in the protocol probably seemed reasonable
in the 1990s, but today it's clearly a bad idea in terms of both
cryptography (cf. multiple compression oracle attacks in TLS) and
attack surface. Pre-auth compression support has been disabled by
default for >10 years. Support remains in the client.

据我所知，该版本的行为也Compression yes与（从那时起遗留的）指令相同Compression delayed。

因此对于 OpenSSH sshd 7.4 及更新版本来说Compression yes不应触发任何警告。

如果安全扫描程序生成调查结果并提出具体建议但没有提供任何支持理由和/或不会将其与特定版本关联起来，这确实是一件糟糕的事情。

当被问及来源和理由时2016 年在 Github 上Lynis 建议设置Compression no它似乎是

  • “大多数人不需要 SSH 压缩”

    因为显然ssh 手册页状态：

... 在调制解调器线路和其他慢速连接上，压缩是可取的，但只会减慢快速网络的速度。...

  • “一般来说：不要启用不需要的设置”

    减少功能会自动减少攻击面，这是有效的，也很难辩论，但这也适用于几乎任何其他设置，并不表示使用存在任何特定风险Compression delayed|yes

  • 压缩和加密很危险

    在...的背景下犯罪和违反以及类似的压缩 Oracle 相关攻击，暴露秘密和/或凭证。

前两个原因不太有说服力，最后一个原因不再适用，如果它真的曾经适用的话，因为多年来，当请求压缩时，默认情况下任何当前的 OpenSSH 服务器都只支持该压缩用户成功验证后。

相关内容