AI 时代的防备
该标签下有 13 篇文章
Linux内核CVE-2026-98432：可通过网络触发的TCP释放后使用漏洞（CVSS 9.8）；请安装已修复的内核、重启并检查MPTCP
CVE-2026-98432是Linux内核IPv4 TCP代码中的一个释放后使用漏洞，于2026年10月15日公布。内核项目的CNA给出CVSS v3.1 9.8分（网络、无需权限、无需用户交互）。据报道，一家AI公司的研究人员在实验室中、依据其自身报告，演示了针对带有Multipath TCP（MPTCP）监听器的服务器以root身份远程执行代码。BleepingComputer称，针对普通TCP服务器的远程代码执行尚未公开展示，也未确认有在野利用，本站于11月1日在CISA的KEV目录中没有找到该CVE。上游修复包含在5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56和7.2.10及之后的版本中。截至11月1日，Debian已有修复的内核，SUSE有部分，Ubuntu和Red Hat将修复列为进行中。仅禁用MPTCP并不是完整的修复。本站的结论是：随着修复发布，更新面向互联网的Linux服务器并重启，仅在此之前使用厂商的临时缓解措施。
AI 时代的安全防护｜个人开发者现在就该夯实的基本功（按优先级排序的清单）
AI 强化的不是『新弱点』，而是『自动、大规模地利用既有弱点』那一侧。所以比起特别的新对策，按正确的顺序夯实基本功才是最好的准备。CVE 立即打补丁＋依赖监控、停止密码复用＋MFA、清除暴露的机密、最小权限、收缩公开面、日志/IOC 的准备、备份——全都用一份按优先级排序的清单讲清楚。
AI 时代有效的安全对策与无效的对策：为什么小站也会成为目标
纠正 AI 时代的 4 个误解。①太小不会被盯上→自动化攻击不需要由人来挑选目标②需要特别的新对策→基本功依然最有效③装个产品就安心→比起检测，先做到『不让它发生』的设计④AI 生成代码又快又安全→可能带着漏洞上线，上线前必须复查。真正有效的，是按正确顺序把不起眼的基本功做扎实。
冒充自己域名的邮件：如何与被入侵区分，以及如何用 SPF・DKIM・DMARC 防止
即使收到自称来自自己域名的可疑邮件，多数也不是『服务器被入侵』，而是『发件人(From)被伪造』。因为 SMTP 允许任意填写 From。读懂邮件头里的 Authentication-Results、Received、Reply-To，就能分辨是入侵还是冒充。它能进到收件箱的主因是没有配置 DMARC。用 SPF→DKIM→DMARC(p=none→reject) 的分阶段引入来止住它。
备份基础：3-2-1 规则与抵御勒索软件的恢复计划
备份只是「有做」还不够，只有「已确认可以恢复」的备份才有用。基础是 3-2-1 规则（3 份副本、2 种介质、1 份异地）。要防勒索软件，还需要至少 1 份「离线或不可变（immutable）」副本，因为长期连着的备份会连同原件一起被加密。云同步不是备份（误删和加密也会被同步）。多版本管理和定期恢复测试才算完整的做法。
多因素认证(MFA)如何正确选择：「抗钓鱼」是什么，SMS 为什么弱
MFA 组合不同类别的因素。手动输入的验证码可能被钓鱼中继，SMS 还依赖对手机号的控制。重要账户应优先考虑通行密钥或 FIDO2 安全密钥等抗钓鱼方式，并检查用户验证要求和恢复流程。
漏洞（CVE）处置实务：彻底修复，并持续监控复发
漏洞处置不是『修了』就完事。完成＝①扫描②修复③隔离/移交④监控四点齐备才算数。尤其在加上监控（每日变化检测）之前都算未完成——因为依赖明天又可能变得脆弱。修复内容哪怕100分，只要下一次部署就被覆盖，也等于0分。小团队靠自动变化检测和『local→push→deploy』这两条纪律就能保持安全。
osv-scanner 的安装与使用：自动找出依赖包里的 CVE
osv-scanner 是一款免费工具，扫描锁文件或容器以排查依赖中的 CVE。本文把安装、运行、CI 集成做成步骤，并理清它与 npm/pnpm audit、Dependabot 的取舍。本站的观点：哪个工具合适，取决于你的架构。多语言混用或不依赖 GitHub 就用 osv-scanner，单一 npm 用自带的 pnpm audit 就够了。
密码管理器安全吗？工作原理与云端、本地的区别，以及如何选择
密码管理器帮助你为每项服务使用强且不重复的密码。零知识加密旨在提供方泄露加密数据时保护内容，但安全性还取决于主密码强度、加密设置和设备安全。通过 MFA 防止未经授权的登录，并按用途选择云端型或本地型。
是否把密钥文件遗忘在了公开目录里：webroot 盘点
放进 webroot 的文件，任何人都能通过 URL 取走。令牌或认证凭据的 JSON、.env、备份一旦遗忘在那里，就会立即暴露；如果源自共用模板，所有站点都带着同一个文件。对策：公开目录只放可以公开的东西，密钥放在 webroot 之外并设为权限 600，一旦发现一处，就排查所有站点和主机。
个人开发 / 小规模运营的安全底线：按优先级排列的行业标准对策
最低限度的对策并非『全都一样重』。本站的优先级 ＝ ①管理账户·域名·邮箱（多因素认证）②密钥与代码 ③应用本体 ④补丁 / 检测 / 恢复。资源有限的个人，按这个顺序从上往下填才是正解。多数事故并非新型攻击，而是这些基本对策的缺失造成的。
SSH 密钥的最小权限：别把生产的 root 密钥放进可能被入侵的临时环境
从可能被入侵的临时环境（GPU pod、CI runner、一次性 VM）向生产登记 root 密钥，那个环境一旦被入侵，攻击者就能拿到生产的 root 权限。对策：不在临时环境放 root 密钥；不用了就删掉；再次需要时，用非 root 用户加上把密钥限定为一个操作的 command 限制密钥。把复用的密钥当作最重要的资产，绝不要搭出漏一把密钥就能打开所有服务器的结构。
AI 写的代码泄露了 API key 并被盗刷：原因是未打补丁的 CVSS 10.0 漏洞
账单暴涨只是症状。原因是公开已久、却一直没打补丁的 CVSS 10.0 RCE。本文把一个匿名化的案例提炼成防御的教训。