今天在网上也看到了类似的帖子。我觉得，这应该不只是群晖的问题，各类 NAS 都可能成为攻击目标。我的飞牛 NAS 从 10 月 17 日之后就开始遭遇 SSH 爆破发现异常后，我设置了防护规则：SSH 登录失败 1 次，就立即拉黑对应 IP 。以下是本月被我拉黑的部分 IP：139.59.114.91172.233.43.7172.233.49.112172.235.165.148172.235.182.100172.235.182.24172.235.191.206172.236.19.167172.236.25.23577.239.124.100这里有几个问题让我比较好奇。我已经修改了 SSH 默认端口，攻击者是怎么找到新端口的？难道攻击者是在针对我个人进行有针对性的入侵，还是说他们有一套自动化扫描机制，能够扫描公网 IP 的开放端口，并识别出运行 SSH 服务的端口？攻击者似乎会根据防火墙规则调整爆破频率。假设我设置了防火墙规则：1 分钟内 SSH 登录失败 5 次，就禁止该 IP 继续访问。但我感觉攻击者似乎会主动测试防护规则，然后将尝试频率控制在每分钟 4 次，以避免触发封禁。
3# 奔跑的蜗牛 黑裙，公网开了服务，昨晚 11 点多入侵的，有 root 权限，全盘加密了。
AI 上去看了看说是 C3RB3R ，而且无法确认从哪里入侵的。ssh 关了密码登录，所以估计是某个群晖自己的服务？
损失……虽然不算很惨重，但是松鼠病给我狠狠治了一治。
大家也注意及时升级服务吧，我这个群晖好久没升级了反正。
⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉
https://github.com/soimy/c3rb3r-rescue/blob/main/README_CN.md已经有成功解密的案例了
5# SYS宇晖 公网直连加长期不升级基本就是活靶子，群晖那些自带服务漏洞一抓一大把。建议重要数据做份离线冷备，公网入口走VPN或反代。想问下你DDNS和QuickConnect是不是一直开着？
[这只是一个小尾巴]
通过一台服务器 frpc 转发的端口会有被攻破风险吗？ 禁用 admin ，启用二次验证。今天凌晨 5 点被扫了。```群晖安全检查报告检查日期：2026-10-29 ，时间均为北京时间（ UTC+8 ）设备：HomeNAS / DS1819+ / 192.168.10.2系统：DSM 7.4.1-90080 Update 1检查时间：约 20:03–20:19结论在本次在线检查覆盖的文件名、当前进程、计划任务和日志中，没有发现 L0CK3D 加密已经发生或对应恶意程序正在运行的证据。但是，已确认 NAS 在今天凌晨收到过明确的漏洞利用输入。不能将本次结果表述为“从未遭攻击”或“绝对未被入侵”。确认的恶意请求2026-10-29 05:01:29–05:01:32 ，DSM 登录接口 SYNO.API.Auth_7_login 、PID 9440 ，在三个错误处理位置记录了相同的多行恶意用户名。不能将这三条错误记录当成三次独立攻击。输入包含 PLUGIN_VALUE_END 、LD_PRELOAD 、LD_DEBUG=libs ，目标文件前缀为 /etc/cron.d/synotkzh 。编码内容仅在本机离线解码，其意图是每分钟以 root 下载并执行 hxxp://46[.]8[.]78[.]122/xdy5.sh 。检查过程中没有访问这个地址，也没有执行恢复出的命令。这一组合与公开的 DSM 登录插件环境变量注入利用手法相符。日志显示 authentication failure ，但认证失败不能证明漏洞利用失败；日志中的 euid=0 也不代表攻击者已取得 root 。认证日志记录来源为 192.168.10.1 。它可能是路由器/NAT/代理，不能据此确定真实外部来源；下载服务器地址也不等于请求发起地址。关键证据位置（本报告同目录下）- evidence/var__log__synoscgi.log：第 7615 、7627 、7639 行起的完整多行记录。- evidence/var__log__auth.log：第 13895 行附近的同时间、同 PID 认证失败记录。- evidence/var__log__synoupdate.log：第 452 行，2026-10-21 08:11:29 开始更新至 90080-1 ；其后记录更新完成。- evidence/var__log__messages：第 31474 行，2026-10-21 08:14:11 已以 DSM 7.4.1 90080-1 完成启动；第 32277 行是今天用户确认的重启。未发现的副作用- /etc/cron.d 全目录（包括隐藏项）仅见两个 DSM 调度文件，没有 synotkzh* 或 synotgkk*。- 未发现 /bin/libgld 、/bin/qnetd 、/bin/l0ck.enc 或 /tmp/log.0 。- 当前 rm.log 未命中上述任务/程序/下载目标的相关清理痕迹。rm.log.1.xz 截止 2026-06-25 ，不覆盖本次事件，不能用于证明本次未发生清理。- 415 个已采样进程没有命中已知名称，也未发现从 /tmp 、/var/tmp 、/dev/shm 运行、exe 已删除或 memfd 的可疑用户态程序。内核线程无 exe 属正常现象。- 当前网络连接可对应 DSM 、Plex 等进程。198.18.x.x 与用户确认的代理环境相符，192.168.10.135 的连接属于 Plex ；未因此判定恶意。- 五项 DSM 计划任务对应自动更新、安全顾问、照片备份、备份检查与数据校验调度，未发现恶意下载执行任务。- Container Manager 当前没有列出任何容器。- root 为唯一 UID 0 账户。管理员组为 admin 、hoyt 、Virtualization ；未发现额外 UID 0 账户。未通过 passwd -S 核实 admin 是否禁用，因为系统没有该命令，不能由账户存在推定可登录。文件扫描范围与完成情况低优先级枚举文件名、不跟随符号链接。检查 .L0CK3D / .LOCK3D 、read-me3.txt 、libgld 、init-rsysd.lo 、l0ck.enc 、synotgkk 等名称特征。共扫描 475,823 个文件及目录条目，其中 /volume1 为 432,590 个条目。所有列出的扫描根目录均完成，无权限错误、无扫描超时、无名称命中。根目录：/tmp 、/var/tmp 、/dev/shm 、/root 、/bin 、/sbin 、/etc 、/usr 、/var 、/volume1 。排除：/volume1/@sharesnap （快照内容）及 /volume1/@appdata/ContainerManager/all_shares （重复绑定的共享目录，原始共享目录已扫描）。不跟随符号链接，未检查未挂载存储和备份镜像内部内容。这是文件名与现场状态检查，不是对全部文件内容进行杀毒扫描或对系统二进制做完整可信基线校验。日志覆盖与保全已保全 10 份原始日志文件，共 8,264,412 字节：auth.log 、synoscgi.log 及四份 xz 轮转、messages 、rm.log 及一份 xz 轮转、synoupdate.log 。所有副本均完整、采集时未检测到文件变化，并通过远端/本地 SHA-256 一致性校验。采集没有修改源文件内容。第一轮有界日志扫描发现线索后，第二轮取得上述完整日志；未命中结论以已保全范围为限。本次 sudo 审计命令本身在 auth.log 中产生了包含检索字符串的记录，已在判断中排除，不能当成恶意命中。journal 仅保留今天 19:42 重启之后的内容，无法用它还原凌晨插件/进程执行链。未取得完整 HTTP 请求、历史进程审计或网关日志，因此不能证明利用确实被补丁拦截，也不能排除已清理痕迹的历史活动。原始日志、脚本和结果保存在本机权限受限的目录中。SSH 与 sudo 密码由用户直接在本机终端输入，没有作为聊天消息或工具参数传递。仍需留意的配置NAS 当前 IPv4/IPv6 INPUT 默认策略均为 ACCEPT ，未见限制管理端口来源的 NAS 本机防火墙规则。当前 IPv6 地址仅见回环 ::1 ，没有发现可用公网 IPv6 地址。用户已确认关闭外网端口转发；本次未登录路由器独立核查映射、反向代理或 QuickConnect 的实际可达性。建议1. 保持 DSM 管理端口与 SSH 的公网入口关闭；远程管理通过 VPN 等受控入口进行。2. 在保留当前可信局域网管理通路的前提下，配置 NAS 防火墙仅允许所需来源和服务。本次未修改防火墙或其他配置。3. 核对默认 admin 已禁用、管理账号启用多因素认证，并确认有 NAS 无法改写的离线/异地备份。多因素认证不能替代漏洞修补。4. 本次检查结束后，可在 DSM 中关闭临时开启的 SSH 。保留本报告与日志，若后续出现改名、勒索信、共享目录异常或新告警，可直接交给群晖支持继续取证。公开依据Rapid7 原始研究（ DSM CVE-2024-10441 与环境变量/cron 注入机制）：https://www.rapid7.com/cdn/assets/bltad0709de42b54e82/689604359f008cdd02f69917/disguise-delimit-whitepaper.pdf群晖 SA-24:20：https://www.synology.com/en-global/security/advisory/Synology_SA_24_20群晖 SA-26:13 （ DSM 7.4 修复基线为 7.4-90075 ）：https://www.synology.com/en-global/security/advisory/Synology_SA_26_13用户所引个案作者的取证记录（个案线索不等于本机感染证据）：https://github.com/soimy/c3rb3r-rescue/blob/main/docs/attack-path.md```
@haoshuaiwang ssh 没关密码登录么？关了的话随他爆破去……解密的案例我试试吧，感谢~不过内存的话可能有点悬了