⚠️ 官方预警2026年8月10日，国家计算机病毒应急处理中心发布预警：一个名叫 "Sorry" 的勒索病毒正在国内肆虐，专打 Linux Web 服务器，信创系统全部在靶。从入侵到全盘加密，可能不到 30 分钟。更残酷的事实是——在没有攻击者私钥的前提下，被加密的数据 暂时没有可靠的恢复方法。
🎯一、先说结论：这次为什么不一样？
你可能觉得勒索病毒跟 Linux 运维关系不大——那不是 Windows 的"专利"吗？
这次不一样。三个原因：
🏛️ 第一，官方下场了。 国家计算机病毒应急处理中心专门发了预警报告，这不是某个安全厂商的营销稿，是国家级机构的正式通报，说明感染规模已经到了不能忽视的程度。
🛡️ 第二，信创照中招。 很多人觉得国产 CPU + 国产 OS 天然安全，但 Sorry 病毒用 Go 语言编写，一次编译多平台运行，ARM 架构的信创服务器照样跑得起来。信创解决的是供应链自主可控问题，不等于免疫攻击。
💀 第三，中招即绝杀。 文件被 AES 加密后加 .sorry 后缀，AES 解密密钥又被 RSA 双重加密。官方原话："在没有解密密钥的条件下，被加密的数据暂时没有可靠的恢复方法。"翻译一下：交赎金都不一定拿得回来。
✅ 一句话总结：这不是会不会中的问题，是你的服务器够不够硬的问题。
🔗二、6 步攻击链拆解：它到底怎么打进来的？
根据国家计算机病毒应急处理中心的预警报告，Sorry 的攻击链条非常完整，每一步都踩在运维常见的疏忽上。
🚪1网络入侵——从 Web 漏洞拿到 root
攻击者利用 WebPros cPanel 授权问题漏洞（CNNVD-202604-5641 / CVE-2026-41940）获取服务器管理权限。
关键细节：
- 🔓 这是一个 cPanel/WHM 的授权绕过漏洞，攻击者不需要你的密码就能拿到管理权限
- 👻 病毒被投放后伪装成 sshd 进程，你用
ps 看进程列表，它混在正常的 SSH 服务里，肉眼几乎无法分辨 - 🤫 全程受害者无感知，等你发现时，数据已经被搬空了
💡 运维启示：如果你的服务器暴露了 cPanel/WHM 管理面板在公网，这就是前门大开。很多人装完面板就忘打补丁了，这个漏洞 4 月就被收录（CNNVD 编号里的 202604），但通报 8 月才发，中间有 4 个月的窗口期。
📋2环境探测——给你的服务器"建档"
病毒会生成一个唯一的受害者标识符，采集以下信息并回传攻击者：
这一步的目的有两个：一是确认你值不值得继续打（企业服务器 vs 个人小机器），二是为后续内网扩散做信息侦察。
💡 运维启示：你的服务器上跑了什么、有几个 CPU、有哪些网卡——这些信息你平时可能根本不在意，但攻击者拿到这些，就能判断你的内网规模和资产价值。
🔪3扫清障碍——先杀你的"保安"
这是最狠的一步。病毒会主动终止以下三类服务：
- 🗄️ 数据库服务（MySQL/PostgreSQL/金仓/达梦等）
- 🛡️ 安全防护软件（EDR/XDR/杀毒/堡垒机 agent）
- 💾 备份服务（快照、定时备份、异地容灾 agent）
先杀保安，再搬东西。等你的安全软件被干掉了，后面的窃取和加密就没人拦了。
💡 运维启示：如果你的安全软件可以被一个进程随便终止，那它就是个摆设。Linux 服务器上，安全 agent 的进程需要做好防杀保护——限制非 root 用户 kill 权限、配置进程监控自动拉起、关键服务用 systemd 的 protect 机制。
📤4数据窃取——加密前的"二次勒索"伏笔
在加密之前，病毒会批量窃取：
注意，是先窃取，再加密。这意味着即使你交了赎金拿到解密密钥恢复了文件，攻击者手里还攥着你的数据副本，可以进行"双重勒索"——不给钱就公开泄露。
💡 运维启示：防勒索不仅要防加密，还要防外传。出站流量监控、异常大流量告警、DLP 策略，这些在网络层就该堵住。一个 Linux Web 服务器突然向陌生 IP 上传大量数据，这种异常应该秒级告警。
🔐5数据加密——AES + RSA 双重加密，文件加 .sorry 后缀
加密技术细节：
- 🔒 使用 AES 算法 对用户文件进行加密，业务系统中断、数据无法访问
- 🔑 使用 RSA 算法 对 AES 解密密钥进行双重加密
加密完成后，攻击者会在主机上留下勒索信，要求受害者下载某款加密通信工具与其联系。
💡 运维启示：AES+RSA 双重加密是目前勒索病毒的"标配"手法，单个 AES 密钥加密文件，再用 RSA 公钥加密 AES 密钥，只有持有 RSA 私钥的攻击者才能解密。没有私钥的情况下，暴力破解 RSA 在算力上不现实。所以——备份，备份，还是备份。
🌊6内网扩散——SSH 弱口令横向移动
病毒会扫描 SSH 端口 22、2222、22222，通过弱密码尝试向内网其他 Linux 主机横向传播。
🚨 国家计算机病毒应急处理中心明确指出：该病毒具有主动传播能力，可能造成企业内网大面积感染。
💡 运维启示：一台服务器中招不是终点，是起点。如果你的内网所有服务器共用一套 SSH 弱口令，那 Sorry 从一台机器扩散到整个机房可能只需要几分钟。SSH 端口 22 暴露在公网 + root 密码 123456——这种配置在国内中小企业服务器上至今非常普遍。
🧱三、信创不是金钟罩：3 个安全致命伤
很多人第一反应是：信创系统用国产 CPU 和国产 OS，是不是天然更安全？
❌ 不是。这次信创系统全部在靶。
国家计算机病毒应急处理中心原文："该勒索病毒可在国内大部分主流 Linux 发行版操作系统（含信创操作系统）上运行并实施侵害。"
💔 致命伤 1：安全生态薄弱
主流 EDR/XDR 对信创平台的支持远不如 Windows 和传统 Linux。很多安全产品对信创还在"适配中"，这意味着你的信创服务器上可能根本没有靠谱的终端安全防护。
💭 一台没有 EDR 的 Windows 服务器你会觉得裸奔，但一台没有 EDR 的信创服务器，很多人却觉得很安全——这是最危险的认知偏差。
📋 致命伤 2：运维习惯照搬
习惯 CentOS 运维的工程师，直接照搬脚本、定时任务、系统调优参数。但信创操作系统的部分命令行为、安全策略、防火墙、SELinux 等效配置不一样，脚本批量执行可能直接异常。
⚠️ 更致命的是安全习惯：很多信创服务器用默认配置上线，SSH 端口 22 开到公网，root 密码弱。CentOS 时代养成的坏习惯，原封不动搬到了信创环境。
🐢 致命伤 3：补丁更新链路更长
信创系统的安全补丁推送链路比 CentOS/Ubuntu 更长。传统 Linux 一个 CVE 出来，官方源可能当天就有更新；信创系统需要等厂商验证、适配、打包，周期可能是数周甚至数月。
这次 Sorry 利用的 cPanel 漏洞 CNNVD-202604-5641，4 月就被收录，8 月才发预警——4 个月的窗口期，如果信创系统补丁推送更慢，暴露时间就更长。
🎯 核心认知纠偏：把"国产"等同于"安全"是最大的风险。信创解决的是供应链自主可控问题，不等于免疫攻击。安全看的是配置和运维水平，不是看什么发行版。
🛠️四、防勒索 5 步紧急加固清单
不废话，直接上操作。按优先级从高到低执行：
🚨第 1 步（立即）：堵住入侵入口
# 检查是否暴露了 cPanel/WHM 管理面板ss -tlnp | grep -E '2082|2083|2086|2087'# 如果有，立即升级到厂商最新版本# cPanel/WHM 更新命令（以 cPanel 为例）/scripts/upcp --force# 最优解：管理面板不要暴露在公网# 限制访问源 IP，或通过 VPN/堡垒机访问
- ☐ 排查所有公网暴露的 cPanel/WHM/WP Squared 服务
- ☐ 核实软件版本，确认是否受 CVE-2026-41940 影响
- ☐ 立即升级到厂商最新版本
- ☐ 管理面板限制源 IP 访问或走 VPN/堡垒机
🔑第 2 步（立即）：SSH 安全加固
# 1. 修改默认 SSH 端口（不要用 22/2222/22222）# 编辑 /etc/ssh/sshd_configPort 22022 # 换成一个非标准端口# 2. 禁止 root 直接登录PermitRootLogin no# 3. 禁止密码登录，只允许密钥PasswordAuthentication noPubkeyAuthentication yes# 4. 重启 sshdsystemctl restart sshd
- ☐ SSH 端口从 22 改为非标准端口（不要用 2222/22222，病毒也扫这些）
- ☐ 禁止 root 直接 SSH 登录
- ☐ 关闭密码认证，强制密钥登录
- ☐ 检查所有主机是否共用同一套 SSH 凭证——如果是，立刻分台配置独立密钥
- ☐ 配置 fail2ban 或类似工具，自动封禁暴力破解 IP
💾第 3 步（24 小时内）：备份策略加固
# 创建独立备份脚本，关键数据定期备份 + 异地离线保存# 示例：关键目录打包加密后上传到异地存储#!/bin/bashBACKUP_DIR="/data/backup"DATE=$(date +%Y%m%d)tar czf $BACKUP_DIR/backup-$DATE.tar.gz /etc /var/www /opt/apps# 加密备份包（使用 GPG）gpg --encrypt --recipient admin@company.com $BACKUP_DIR/backup-$DATE.tar.gz# 上传到异地存储rsync -avz $BACKUP_DIR/backup-$DATE.tar.gz.gpg backup@remote-storage:/backups/# 清理超过 30 天的本地备份find $BACKUP_DIR -name "backup-*.tar.gz*" -mtime +30 -delete
- ☐ 网站文件、数据库、业务配置、源代码、重要日志——全部纳入定期备份
- ☐ 备份数据离线保存（外接硬盘、异地存储，断开网络连接）
- ☐ 备份验证：每月做一次恢复演练，确认备份可用
- ☐ 备份服务器与生产网络隔离，防止备份也被加密
🛡️第 4 步（24 小时内）：终端安全加固
- ☐ 安装适配信创/Linux 的终端安全软件（EDR/XDR）
- ☐ 配置进程防杀保护，防止安全软件被恶意终止
- ☐ 关键服务配置 systemd 保护机制：
# 编辑服务单元文件，添加保护参数[Service]ProtectSystem=strictProtectHome=yesNoNewPrivileges=yes
🔍第 5 步（本周内）：全面排查与基线加固
# 排查是否有进程伪装成 sshdps aux | grep sshd | grep -v grep# 正常 sshd 的路径应该是 /usr/sbin/sshd# 如果路径异常，立即深入排查# 检查是否有异常的 .sorry 后缀文件find / -name "*.sorry" 2>/dev/null# 检查 SSH 弱口令（建议用工具如 hydra 自测）# 确保所有用户密码长度 >= 12 位，包含大小写 + 数字 + 特殊字符# 检查防火墙规则，确认管理端口未暴露公网iptables -L -n | grep -E '22|2222|22222'
- ☐ 全网排查：是否有文件已带
.sorry 后缀（可能已被入侵但尚未发现） - ☐ 全网排查：是否有异常 sshd 进程（路径不在 /usr/sbin/sshd 的）
- ☐ 全网排查：SSH 端口是否暴露公网（22/2222/22222）
- ☐ 全网排查：是否有共用同一套 SSH 凭证的主机
- ☐ 配置防火墙白名单，仅允许堡垒机 IP 访问 SSH 端口
- ☐ 管理后台、远程运维接口、数据库端口——一律不直接暴露公网
⚠️五、最后提醒：这些坑不要踩
🕳️ 坑 1：不要信"解密工具"骗局
国家计算机病毒应急处理中心特别提醒：警惕搜索引擎和购物平台上兜售的"勒索病毒解密工具或代理服务"，这是骗局。更不要下载攻击者提供的"加密通信工具"，大概率二次感染木马。
📋 坑 2：不要只做技术加固，不做流程加固
技术加固是"堵枪眼"，流程加固是"不挨枪"。建立变更管理流程——任何公网暴露的服务上线前必须过安全基线检查，任何 SSH 凭证变更必须有审批记录。
🇨🇳 坑 3：不要把"国产"当"安全"
信创解决的是供应链问题，不解决安全问题。信创服务器的安全基线标准和传统 Linux 一样高，甚至更高——因为安全生态还在建设中，更需要手动加固。
💽 坑 4：不要等中招了才做备份
备份是唯一能在勒索面前兜底的东西。但你得提前做，而且得离线保存。在线备份和在线生产环境在同一个网络里——病毒会同时加密它们。
📝写在最后
🐧 Linux 不是免死金牌，信创也不是金钟罩。
安全看的不是你用什么发行版，而是你的加固到位不到位、备份靠谱不靠谱、响应够不够快。
这次 Sorry 的攻击链确实完整——从 Web 漏洞入侵、到伪装 sshd、到杀安全软件、到窃取数据、到 AES+RSA 双重加密、再到 SSH 横向扩散，每一步都踩在运维常见的疏忽上。
✅ 但反过来想，每一步也都是可以堵的。
漏洞打补丁、SSH 换端口禁 root 禁密码、备份离线保存、终端安全防杀、出站流量监控——做到这 5 件事，你的服务器就能挡住 90% 的攻击。
剩下 10%，靠持续的监控和应急响应能力。那就是另一个话题了。
📌 本文信息来源：国家计算机病毒应急处理中心《"Sorry"勒索病毒预警报告》（2026年8月10日）。技术细节以官方通报为准，建议结合自身环境验证后执行。
10个月宝宝每天需要喝多少奶粉？
