1. 当SSH握手变成CPU绞肉机D(HE)ater攻击原理拆解那天凌晨三点运维老张被刺耳的告警声惊醒。监控大屏上十几台服务器的CPU曲线全部飙到100%而罪魁祸首竟然是看似无害的SSH服务。这就是典型的D(HE)ater攻击现场——攻击者用特制的密钥交换请求让服务器在握手阶段就开始疯狂计算。要理解这个漏洞的杀伤力得先看看SSH握手时发生了什么。传统Diffie-Hellman密钥交换DHE就像两个特工在公开场合商量秘密暗号客户端说咱们用质数p23和底数g5吧服务端回复好我选个秘密数字a6算出的公钥是5^6 mod 238客户端也选个秘密数字b15算出公钥5^15 mod 2319双方用对方的公钥计算共享密钥服务端算19^6 mod 232客户端算8^15 mod 232问题就出在模幂运算g^x mod p上。当攻击者发送精心构造的假公钥时服务端会陷入复杂的数学计算。我实测过单次2048位DHE计算就要消耗15ms CPU时间而攻击者可以每秒发起上千次请求。更糟的是这招对老漏洞CVE-2002-20001和新漏洞CVE-2022-40735都有效。去年曝光的dheater工具GitHub可查甚至能自动化攻击用单台笔记本就能拖垮企业级服务器。这就像有人用伪造的谜语大全不断骚扰解密专家消耗其精力直到崩溃。2. 密钥交换算法的安全进化论从DHE到ECDHE十年前我第一次配置SSH时配置文件里清一色的diffie-hellman-group14-sha1。如今再看现代服务器的KexAlgorithms列表已经变成curve25519-sha256这类ECDHE算法为主。这个转变背后是密码学实战的宝贵经验。让我们用快递员送钥匙来类比不同算法传统DHE快递员带着沉重的保险箱大素数计算每个箱子要专门定制临时密钥既慢又耗体力ECDHE快递员改用轻便的智能密码盒椭圆曲线重量只有传统保险箱的1/10还能随时变更密码静态RSA永远用同一把钥匙被人偷拍一次就完蛋实际测试数据更说明问题。在Xeon Gold服务器上算法类型单次握手耗时CPU负载DHE-204815ms3%ECDHE-nistp2562ms0.5%x255191ms0.3%不过算法迁移要注意兼容性坑点。有次我给银行系统升级时发现老式ATM设备只认DHE。最后折中方案是先用ECDHE作为首选算法同时保留group16-sha512作为备选并通过防火墙规则限制DHE连接速率。3. 纵深防御实战从配置到监控的完整方案看到扫描报告里的DHE DoS漏洞别急着全禁用算法我有套组合拳方案。去年给某交易所做加固时这套方法成功扛住了每秒3000次的模拟攻击。3.1 算法层面的精准打击首先用这个命令检查当前支持的算法ssh -Q kex | grep diffie-hellman然后编辑/etc/ssh/sshd_config我推荐这样的安全配置模板# 优先使用现代算法 KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384 # 兼容场景保留一个强DHE选项 HostKeyAlgorithms ssh-ed25519,rsa-sha2-512 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com MACs hmac-sha2-512-etmopenssh.com3.2 连接限流的艺术MaxStartups这个参数很多人都设错了。常见误区是直接设成MaxStartups 10这会导致正常用户被误伤。正确的姿势应该是MaxStartups 30:50:100这表示前30个连接直接放行31-50个连接按50%概率拒绝超过100个直接拒绝配合iptables效果更好# 限制单IP新建连接数 iptables -A INPUT -p tcp --dport 22 -m connlimit --connlimit-above 3 -j DROP # 启用SYN Cookie防护 sysctl -w net.ipv4.tcp_syncookies13.3 监控与应急响应我在Prometheus里配了这些关键指标- name: ssh_dos_protect rules: - alert: SSHDosAttack expr: rate(sshd_connections[1m]) 50 for: 2m labels: severity: critical annotations: summary: SSH DoS攻击检测 (instance {{ $labels.instance }})应急响应时有个小技巧临时启用tarpit功能拖慢攻击者# 用nftables实现SSH tarpit nft add table ip ssh_protect nft add chain ip ssh_protect input { type filter hook input priority 0 \; } nft add rule ip ssh_protect input tcp dport 22 meter flood size 100000 { ip saddr timeout 60s limit rate over 3/minute } drop4. 从攻击者视角看防御红队实战经验去年做渗透测试时我发现D(HE)ater攻击最怕以下几种防御姿势场景1云服务器遭遇爆破某客户ECS突然CPU飙升查日志发现大量sshd[pid]: Connection closed by invalid user admin [preauth]快速应对方案先用fail2ban封禁可疑IP临时启用证书认证禁用密码登录添加--with-ssl-engine编译选项启用硬件加速场景2内网跳板机被攻陷攻击者在内网横向移动时喜欢用弱DHE组进行中间人攻击。防御方法是在sshd_config添加# 禁用小于2048位的DHE组 KexAlgorithms ...-group14-sha256,group16-sha512有次客户坚持要用DHE我就给他们演示了如何用dheater工具在30秒内让服务器无响应。现场演示比任何报告都管用他们当场同意了我的算法升级方案。5. 特殊场景下的生存指南物联网设备是重灾区。某次审计智能摄像头时发现其SSH服务居然支持diffie-hellman-group1-sha1768位。这种设备往往无法升级OpenSSH我的解决方案是用防火墙做前置过滤# 只允许特定管理IP连接 iptables -A INPUT -p tcp --dport 22 -s 10.8.0.0/24 -j ACCEPT启用内核级防护# 限制进程CPU占用 echo 20 /sys/fs/cgroup/cpu/ssh.slice/cpu.cfs_quota_us终极方案禁用SSH改用串口管理这招在工控设备上特别管用。金融行业还有个特殊需求——合规审计。某证券公司的解决方案是在SSH网关前部署解密器所有会话存档到Splunk。既满足监管要求又避免了直接暴露SSH服务。