11 月 12 日，日本滋贺县甲贺市的 229 个户外扩音器同时安静了。不是设备坏了，也不是停电——是它们背后那台服务器，被勒索软件加密了。
第二天（11 月 13 日）市政府通报：语音广播系统服务器遭勒索软件攻击，户外扩音器与家庭语音广播终端全部失效，紧急信息、行政通知、正午报时旋律、讣告播报一律暂停，恢复时间表给不出来。替代方案是官方 LINE 账号、电视和广播。
这条新闻在国内大概只会被当成「日本地方政府网络安全又出事」扫过去。但它其实是近两年勒索软件最典型的一次选靶：不是挑有钱的，是挑不能停的。
一、先把事实摆清楚
| 项目 | 通报内容 |
|---|---|
| 时间 | 11 月 12 日遭攻击，11 月 13 日对外通报 |
| 对象 | 甲贺市语音广播系统服务器（防災行政無線 的控制端） |
| 直接影响 | 229 个地点的户外扩音器、家庭语音广播终端无法使用 |
| 停摆业务 | 紧急信息、行政通知、报时旋律、讣告播报 |
| 临时替代 | 官方 LINE 账号、电视、广播 |
| 恢复时间 | 无明确时间表 |
| 数据风险 | 正在核查终端登记用户的姓名、企业名称是否泄露 |
| 攻击类型 | 勒索软件（ransomware） |
| 未披露 | 操作系统、入侵入口、勒索金额、是否已联系攻击者 |
最后一行很重要：通报里没有说入口。这意味着调查还没定性，也意味着现在流传的任何「因为是 XX 漏洞」的说法都是猜的。我们只谈能确定的部分。
二、三个细节，比新闻本身更值得看
细节一：「无明确恢复时间表」是全文最刺眼的一句
政府系统出故障，标准话术通常是「正在全力抢修，预计 X 小时内恢复」。这次给不出来，往往只有两种可能：
- 备份不可用——没有备份、备份也在同一台机器上、或者备份服务器同样被加密了；
- 备份可用但不敢恢复——不清楚攻击者是否还在内网、不清楚入口堵没堵住，恢复等于再送一次。
这两种情况都指向同一件事：他们大概从来没有演练过「整站被加密之后怎么起来」。
细节二：替代渠道，在最需要它的时候最不管用
LINE、电视、广播，平时够用。但防灾广播存在的唯一理由，是地震、台风、海啸、暴雨这类场景——而那正是手机网络拥塞、基站断电、电视信号中断的时候。
换句话说，这套系统的设计前提是「其他通信手段都可能失效」，现在系统本身失效了，拿「可能失效的手段」去顶。这不是甲贺市的问题，是所有冗余设计都会遇到的困境：备份方案必须在设计时就假定主方案会挂，而不是出事之后临时找。
这句话对做网站的人也成立。你的主站挂了，微博和公众号能顶吗？如果答案是不能，那它们就不是备份，只是另一个入口。
细节三：家庭终端登记了姓名和企业名称
这类终端（戸別受信機）安装时要登记住户和单位信息，本质上是一个带实名地址的个人信息库。勒索软件加密之后，攻击者手上往往还有一份拷走的数据。
这就是这几年勒索的主流玩法——双重勒索：加密是逼你付钱，泄露是逼你不敢不付。对政府来说，第二条比第一条难缠得多，因为它涉及信息公开与问责。
三、勒索软件的选靶逻辑，已经换了一套标准
| 维度 | 几年前 | 现在 |
|---|---|---|
| 目标特征 | 有钱、有数据、有支付能力 | 业务不能停、系统跑不了、决策链短 |
| 典型对象 | 大型企业、金融机构 | 医院、市政、学校、工厂产线、物流、能源 |
| 赎金定价依据 | 数据值多少钱 | 你停一天亏多少 |
| 攻击窗口 | 工作时间（人多好钓鱼） | 周末、深夜、长假（人少没人发现） |
| 最怕的对手 | 安全厂商 | 一份能用的离线备份 |
第三条是关键。赎金不是按数据估值算的，是按停摆成本算的。一个市的防灾广播停一周，政绩、舆情、居民信任的损失无法量化，攻击者开的价只要低于这个数，就「划算」。
这也解释了为什么这波攻击里，中小机构反而更危险：它们的停摆成本相对自身财力极高，而防护预算相对极低。
四、「装完就没人管」的系统，五个共同点
防灾广播这类系统，在很多地方是被当成「家电」采购的：装好、通电、验收、然后十年没人登录过。这类资产几乎总有以下五个特征中的四个以上：
| 特征 | 具体表现 | 后果 |
|---|---|---|
| 系统老旧 | Windows Server 2008/2012、嵌入式 XP、厂商定制的精简系统 | 厂商已停止支持，补丁打不上 |
| 口令形同虚设 | admin/admin、安装时设的默认口令、全单位共用一个密码 | 扫描器字典一撞就开 |
| 补丁链断裂 | 升级要厂商上门，一次几千块，于是不升 | 已知漏洞长期敞开 |
| 没有可用备份 | 有备份但从不验证；备份和原机在同一台服务器/同一个域 | 勒索软件一并加密 |
| 无人看日志 | 没有 SIEM，没有告警，登录失败几百次没人知道 | 从踩点到加密有几天窗口，全程没人发现 |
| 扁平内网 | 办公网、监控网、广播网、财务网在同一个二层 | 打穿一台，横向扫全网 |
真正的分水岭不是「有没有防火墙」，而是这台机器是不是有人每周登录一次看看。勒索团伙最爱的就是那种「上次登录时间显示 2019 年」的服务器。
五、往内看：你手上也有同一批资产
国内不少单位有「村村响」应急广播、校园广播、园区广播；企业里则有下面这一串。它们共同的特点是：属于 IT，但不归 IT 管；能上网，但没人给它打补丁。
| 设备类型 | 常见问题 |
|---|---|
| 网络广播/功放主机 | Web 管理界面默认口令，直接暴露在公网 |
| 监控 NVR / DVR | 固件多年不更新，弱口令，UPnP 自动开端口 |
| 门禁、考勤一体机 | 自带云穿透，绕过防火墙直连外网 |
| NAS、打印扫描一体机 | 匿名共享、SMBv1、Web 管理口弱口令 |
| 老 OA / ERP / 进销存 | 跑在 Server 2008 上，绑死 IE，不敢动 |
| 工控 HMI / 组态软件 | 常年不关机、不打补丁、账号共享 |
| VPN 网关、堡垒机 | 边缘设备漏洞是近两年最热入口 |
先做一件事：把它们数清楚。不用工具，一张表就够——设备名、IP、负责人、系统版本、有没有备份、谁在维护。这张表做不出来，后面的防护都是空谈。
然后用两条命令看看暴露面有多大：
# ① 本机在监听什么（排除回环，剩下的都是对外可达的面）
ss -tulnp | awk 'NR==1 || $5 !~ /^(127\.|\[::1\])/'
# ② 网段里还有多少台机器开着高危端口
nmap -p 445,3389,139,5985,5900 --open 192.168.1.0/24
第二条命令的结果通常会让人沉默：一台本该只有 80 端口的广播主机，可能同时开着 445 和 3389，而且口令是 admin。
六、勒索是怎么进来的：六条入口，按命中率排
| 入口 | 典型特征 | 怎么查 |
|---|---|---|
| RDP 3389 暴露公网 | 日志里大量 4625 登录失败，来源是境外 IP | Windows 事件查看器筛 4625、4624 |
| SMB 445 / 永恒之蓝类 | 内网横向扫描，135/139/445 流量异常 | 交换机流量、防火墙日志 |
| VPN / 防火墙等边缘设备漏洞 | 无账号登录成功记录，直接拿到内网 | 设备版本比对厂商公告 |
| 设备默认口令 | NAS、摄像头、广播主机被直接登录 | 逐个试默认口令，改掉 |
| 第三方运维通道 | 厂商远程维护用的向日葵/TeamViewer/单点 VPN | 清理不再使用的远程工具 |
| 钓鱼邮件附件 | 财务、行政人员打开 .zip 里的 .exe 或宏文档 | 邮件网关日志、终端告警 |
前三条占了绝大多数。共性是：不需要零日漏洞，只需要一个没关的端口和一个没改的口令。
七、真被加密了，头 30 分钟做什么
这一节请当作预案来读，别等出事再想。
| 顺序 | 动作 | 为什么 |
|---|---|---|
| 1 | 先断网，别关机 | 断网止血；关机可能丢掉内存里的密钥、进程和连接记录，取证价值全没 |
| 2 | 保留现场：内存镜像、磁盘镜像、日志导出 | 后续定位入口、判断是否可解密，全靠这个 |
| 3 | 确认范围：哪些机器有勒索信、哪些只是共享盘被写 | 避免「以为只有一台」，恢复一台又被加密 |
| 4 | 查入口：先看 3389/445 的登录日志和暴露端口 | 不堵入口，恢复等于重演 |
| 5 | 找解密工具：No More Ransom、ID Ransomware | 部分老旧家族有公开解密器，先试不花钱 |
| 6 | 确认干净后再恢复，恢复后立刻改全部口令 | 备份里可能带着后门和计划任务 |
不要做的事：不要在生产机上直接重装系统（现场没了）；不要一边恢复一边还连着旧网络；不要急着联系攻击者谈价——那会让对方确认你「确实没有备份」。
至于付不付赎金，前面那篇 GMO 拒付赎金 里已经讲过一轮：付了不保证解密，也不保证不泄露，而且会让自己进入「愿意付钱」的名单。
八、备份：勒索软件第一个找的，就是它
现代勒索团伙进内网之后的第一件事不是加密，是找备份、删备份、加密备份服务器。所以「有没有备份」这个问法本身就不够，要问的是：
备份所在的系统，用的是不是和被打的系统同一套账号？它能不能从内网直接访问？它是「可写」还是「只可追加」？
行业里有个已经比较成熟的框架，叫 3-2-1-1-0：
| 数字 | 含义 | 实战要点 |
|---|---|---|
| 3 | 三份数据 | 生产 + 本地备份 + 异地备份 |
| 2 | 两种介质 | 别全放同一套存储 |
| 1 | 一份异地 | 物理隔离或不同云账号 |
| 1 | 一份离线 / 不可变 | 这条是防勒索的核心：对象存储开版本控制 + 对象锁，或定期拔盘的磁带/硬盘 |
| 0 | 零错误（可验证） | 每季度真恢复一次，记录耗时 |
第 4 条最容易被跳过。国内主流对象存储都支持「版本控制 + 保留策略（对象锁/WORM）」，开起来之后，即使攻击者拿到了密钥，在保留期内也删不掉历史版本。这才是真正意义上「删不掉的备份」。
一个最小可用的落地写法（rclone 推到开启了版本控制的对象存储，每次同步把被改动的旧版本留到 history 目录）：
# 每天一次，增量同步并保留历史版本
rclone sync /www/wwwroot oss:site-backup/www \
--backup-dir oss:site-backup/history/$(date +%F_%H%M) \
--transfers 8 --checkers 16 --log-file /var/log/rclone.log
# 数据库单独一份，压缩后一起推走
mysqldump --single-transaction --quick db | gzip > /tmp/db_$(date +%F).sql.gz
rclone copy /tmp/db_$(date +%F).sql.gz oss:site-backup/db/
注意 --backup-dir 这一行：它保证被删除或被覆盖的文件不会立刻消失，而是留一份在 history 里。勒索软件加密文件的那一刻，恰恰就是「文件被大批覆盖」，这份历史版本可能就是你的救命绳。
还有一件比技术更重要的事：把 RTO 写下来。「出事了多久能恢复」这个数字，如果不是演练测出来的，就只是愿望。防灾广播这次给不出恢复时间表，大概就是这个数字从来没测过。
九、收敛：把入口砍到只剩必须的
防护的顺序永远是「减少暴露面」优先于「加检测」。三件事按性价比排：
① 关掉不该对外的端口。管理口只允许跳板机访问，其余全 drop：
# Linux：只允许跳板机 10.10.0.5 访问 3389
iptables -I INPUT -p tcp --dport 3389 -s 10.10.0.5 -j ACCEPT
iptables -A INPUT -p tcp --dport 3389 -j DROP
# Windows：同样的事用 netsh 做
netsh advfirewall firewall add rule name="RDP-JumpOnly" dir=in ^
action=allow protocol=TCP localport=3389 remoteip=10.10.0.5
② 网络分段。广播、监控、门禁这类设备单独划 VLAN，只允许它们访问必要的服务端，禁止它们主动访问办公网和服务器区。勒索横向移动靠的就是「同一个网段随便扫」，切开之后至少能被困在一角。
③ 对外服务前面加一层。凡是必须开在公网的站点和接口，别让源站 IP 直接暴露——把域名解析到云防护，源站只放行回源 IP 段。这一步的收益不只是拦攻击，更是让扫描器根本不知道你的真实 IP 在哪。百度云防护这类 SaaS 接入的 WAF 做的就是这件事，顺带把针对常见 Web 漏洞（注入、上传、命令执行）的规则跑起来，省掉自己维护规则库的成本。对没有人专职值夜班的小团队来说，这是性价比最高的那一层。
④ 加一点「能发现」的能力。不需要上 SIEM，两个土办法就够用：
# ① 蜜罐：放一个隐藏诱饵，正常业务永远不会碰它
echo decoy > /data/share/.decoy_invoice.docx
chmod 444 /data/share/.decoy_invoice.docx
# ② 诱饵被删或被改，立刻告警（单独常驻一个进程）
inotifywait -m -e delete,modify /data/share/.decoy_invoice.docx \
| while read l; do echo "$(date '+%F %T') $l" \
| mail -s "[告警] 诱饵文件被触碰" ops@example.com; done
# ③ 批量改动：60 秒内超过 100 个文件变动，基本就是加密开始
while true; do
n=$(timeout 60 inotifywait -m -r -e moved_to,create \
--format '%f' /data/share 2>/dev/null | wc -l)
[ "$n" -gt 100 ] && echo "$(date '+%F %T') 变动 $n 个" \
| mail -s "[告警] 疑似勒索加密" ops@example.com
done
加密是一个持续几分钟到几小时的高频 IO 过程，不是瞬间完成的。这类告警的价值在于把发现时间从「第二天用户报障」提前到「第三分钟」——而这几分钟，往往决定了你损失一个目录还是整个共享盘。
十、写在最后
这次事件里没有任何新技术：没有零日，没有供应链投毒，没有 APT 级别的技巧。一台服务器被加密，229 个喇叭静音，一个市的应急通知体系退回纸质时代。
真正的问题在于采购逻辑：这类系统在预算表上是「设备」，在安全上却是「服务器」。设备的生命周期是十年，服务器的安全更新周期是三年，两者的账从来没人对齐过。
对读到这里的站长和运维，能带走的大概就三句话：
- 把「装完没人管」的资产列出来，那才是你真正的风险清单，而不是那些天天在改的网站；
- 备份要有一份删不掉的，并且要真的恢复过一次；
- 恢复时间表如果给不出来，说明问题不在攻击者，在平时。
至于防灾广播这类系统该怎么改造，答案其实不复杂：控播链路和业务网物理或逻辑隔离、控制服务器单独打补丁、终端登记信息单独加密存放、保留一套不依赖 IP 网络的备用播发手段（比如卫星或专用无线电）——只是这些都不便宜，而且不会在出事之前被人看见。
