M9000SSH服务支持弱加密算法漏洞问题
- 0关注
- 0收藏，115浏览
1. 备份当前配置
2. 生成新的安全密钥对（推荐2048位以上RSA，或更优的ECDSA）：
public-key local create rsa 2048
3. 禁用SSH弱密钥交换算法、加密算法和MAC算法：
ssh server key-exchange algorithm dh-group-exchange-sha256 dh-group14-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384
ssh server encryption algorithm aes128-ctr aes192-ctr aes256-ctr
ssh server mac algorithm hmac-sha2-256 hmac-sha2-512
4. 保存配置并验证。
*注意：需确认SSH客户端支持上述安全算法，避免无法登录。*
仅绑定ACL无法替代算法整改，该漏洞仍需处理。 ACL只能限制“谁能访问”，但无法改变SSH服务“用什么算法加密”这一根本问题。
ACL的作用与局限
你已配置的ACL能限制SSH访问源IP，这在安全加固中确实是必要的一步。但它存在明显局限：
ACL是访问控制，不是加密加固：ACL仅控制连接来源，一旦合法IP范围内的用户建立连接，SSH协商仍会使用RC4、CBC等弱加密算法。
内部威胁风险依然存在：若运维网段内某台主机被攻陷，攻击者仍可利用弱加密算法窃听或破解该网段内其他设备的SSH认证信息。
合规性要求：漏洞扫描器的告警项是“SSH服务支持弱加密算法”，ACL并不能使该告警消失。在等保、安全审计等场景中，算法未加固通常被视为未完成整改。
完整整改方案
正确的做法是算法加固为主，ACL限制为辅，两者结合才能彻底消除风险。
第一步：禁用弱加密算法，仅保留强算法
第二步：保留并强化ACL限制
第三步：重启SSH服务使配置生效
第四步：验证配置效果
确认输出中不再包含RC4、CBC、3DES、MD5、SHA1等弱算法，仅保留AES-GCM、AES-CTR、SHA2等强算法。
暂无评论
核心结论：就算 SSH 服务绑定了 ACL，该漏洞仍然需要整改。 ACL 的作用是访问控制（哪些 IP 能发起 SSH 连接）；而本次漏洞是SSH 服务端自身支持弱加密算法（arcfour、aes128-cbc、blowfish-cbc、3des-cbc），属于服务配置层面缺陷，二者不是一回事。 漏扫原理：扫描器只要能和防火墙 22 端口完成 TCP 握手，不需要成功登录，仅通过 SSH 版本协商阶段，就可以探测服务器支持的全部加密算法列表，直接判定漏洞存在。只要扫描源 IP 在 ACL 允许范围内，就能扫出该漏洞；就算 ACL 只放行运维网段，等保 / 运营商安全测评场景下依然判定为不合规。
一、原理区分
- SSH ACL：控制源 IP 是否允许建立 SSH 连接。
- ✅作用：阻断非授权 IP 访问 SSH 端口；
- ❌不能消除漏洞：允许的 IP（运维、漏扫服务器），在握手协商阶段依然能看到 M9000 开放了弱加密套件。
- SSH 弱加密算法漏洞：SSH 服务端在协商阶段对外宣告支持不安全 CBC/arcfour/3des 等算法。
- 风险：允许中间人攻击，CBC 模式存在 IV 漏洞；只要协商套件列表包含弱算法，漏洞就存在，和能不能登录无关。
- 测评 / 等保口径：只要扫描能探测到弱算法套件，判定高危 / 中危漏洞，ACL 不能作为漏洞豁免理由。
二、M9000 Comware V7 修复配置（版本 7.1.064 支持 ssh2 algorithm cipher 命令）
目标：只保留强加密算法，剔除：arcfour、aes128-cbc、blowfish-cbc、3des-cbc、des-cbc
system-view
# 重新指定SSH2加密算法列表，仅保留ctr/gcm强加密模式
ssh2 algorithm cipher aes128-ctr aes192-ctr aes256-ctr aes128-gcm aes256-gcm
# 同步清理弱MAC算法（可选，配套加固，漏扫经常一并扫MAC弱算法）
ssh2 algorithm hmac sha2-256 sha2-512
# 清理弱密钥交换算法
ssh2 algorithm key-exchange ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
# 保存配置
save
说明：
- 配置完成后不需要重启防火墙，新建立的 SSH 会话会使用新算法列表；已经建立的存量 SSH 会话不受影响。
- 提前验证运维客户端兼容性：部分老旧 SSH 客户端只支持 CBC 算法，修改后会协商失败无法登录，需要提前测试运维终端。
三、验证命令（配置完成后自检）
#查看当前SSH2生效的加密算法列表
display ssh2 algorithm
也可以用 nmap 扫描验证：
nmap --script ssh2-enum-algos -p22 防火墙IP
输出结果中不再出现3des-cbc、aes128-cbc、arcfour、blowfish-cbc即为修复成功。
四、两种处置方案（合规场景选择）
方案 A：彻底整改（推荐，满足等保 / 运营商漏洞闭环）
执行上面 ssh2 algorithm 命令，删除弱加密套件；复测漏洞消失，直接闭环。
方案 B：风险说明（仅特殊临时场景，不建议作为长期闭环）
仅当存在老旧运维终端，只能使用 CBC 算法，无法修改客户端时使用。
- 确认 SSH ACL 严格限制，仅内网运维管理网段可访问 SSH22 端口，互联网完全不可访问；
- 提交风险说明材料：明确 ACL 最小访问范围、运维审计、登录双因素 / 密码策略；
- 注意：多数运营商 / 等保测评不接受该方案作为漏洞关闭，仅作为临时风险缓释，不能替代漏洞整改。
五、额外注意点
- M9000 是主备 RBM 环境：主、备两台防火墙都需要单独配置 ssh2 algorithm，不能只配置主设备；
- 版本限制：7.1.064 版本支持 ssh2 算法自定义命令，不需要升级版本，直接配置即可；
- 不要混淆：
ssh server acl只是访问白名单，无法修改 SSH 协商的加密套件列表，不能消除本次漏洞。
六、常见踩坑
- 配置完后复测漏洞仍然存在：大概率只在主设备配置，备机未同步；或者使用了旧的 SSH 会话缓存，扫描器需要重新发起 TCP 连接。
- 运维终端 SSH 连不上：客户端太老，仅支持 CBC 模式，需要更换 Xshell/Putty 新版本。
暂无评论
结论先说
只要设备上确实已经正确配置 ssh server acl（IPv4）/ssh server ipv6 acl（IPv6），ACL 规则正确、仅放行运维网段，就算漏扫没扫出来，从安全加固层面已经完成整改，不需要重复整改；但必须做配置核验 + 留存证据，用来给等保 / 内审解释漏扫原因。
设备：M9000-X06，版本 7.1.064 Feature9927P0101（Comware V7 防火墙平台，支持
ssh server acl全局绑定 ACL，这个特性在该版本是原生支持）
一、为什么会出现【实际配了 ACL，扫描器漏报】
- 扫描器检测方式局限：很多漏洞扫描器是通过 TCP 22 端口全端口扫描、尝试握手判断是否开放 SSH，不会登录进设备读取设备内部
ssh server acl配置；它只能看到 22 端口可达，无法识别设备内部已经做了 SSH 服务级白名单，直接判定 “SSH 未限制源 IP”。 - 注意区分两种访问控制，审计经常会混淆：
- ✅ ssh server acl：全局绑定，针对 SSH 服务本身，在设备控制平面直接拒绝不在 ACL 里的 IP 发起 SSH 连接（推荐加固方式，你当前用的）H3C
- ❌ 安全域策略放通 22 端口：仅在转发平面放行，不是 SSH 服务白名单，不能替代
ssh server acl
重点：
ssh server acl生效时，非法 IP 发起 TCP 握手阶段就被设备丢弃，TCP 三次握手都无法完成，扫描器很难识别这个控制平面白名单。
二、核验步骤（必做，作为整改证据）
# 查看SSH绑定ACL
display current-configuration | include ssh server acl
display current-configuration | include ssh server ipv6 acl
# 查看ACL内容，确认只放行运维IP/网段，末尾隐含deny all
display acl basic XXXX
# 开启拒绝登录日志（建议配置，审计加分）
system-view
ssh server acl-deny-log enable
核验判断标准：
- 有
ssh server acl XXXX配置 - ACL 内只有运维管理源 IP permit，没有 rule permit any，ACL 末尾默认隐式 deny
- 测试验证：非运维 IP 尝试 ssh，TCP 直接拒绝，无法建立连接
三、两种审计场景的处置建议
- 等保 / 内审（人工复核为主） 提供配置截图 + 测试抓包 / 登录测试结果，说明是扫描器误报漏检，不属于设备未加固，可做风险说明，不需要额外整改。
- 必须过扫描器基线（扫描平台强制要求）
可叠加二层加固手段作为补充（不替代 ssh server acl）：
- 管理口单独安全域，安全策略只放通运维网段到管理口 22
- 修改 SSH 服务端口，降低被扫描概率
- 管理 VLAN 隔离，不在业务域开放管理 IP
四、版本额外注意点（M9000-X06 7.1.064 Feature9927P0101）
- 该版本
ssh server acl是全局控制，只对 stnet/ssh 服务生效，不控制 NETCONF over SSH；如果审计包含 NETCONF，需要单独对 NETCONF 做访问限制。 - 该命令只拦截新建 SSH 连接，已经建立的 SSH 会话不会被断开。
- 双机主备场景，两台 M9000 都要单独配置 ssh server acl，不要只在主墙配置。
五、需要继续整改的例外情况
如果下面任意一条成立，仍然要整改：
ssh server acl绑定的 ACL 是空 ACL / ACL 里有permit source any- 只在安全域策略限制 22 端口，没有配置 ssh server acl
- IPv6 开启 SSH 但未配置
ssh server ipv6 acl，IPv6 无访问限制
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论