IPFS 节点常常被忽视为「无关紧要的内容分发组件」，但实际上它常常承担着 NFT 元数据、白皮书、链上证据的存储任务，一旦失守，可能波及整个项目。本文给出一份可执行的安全审计清单。
暴露面盘点：从端口到协议
第一步是盘点节点对外暴露的所有端口和协议。Kubo 默认监听 4001（swarm）、5001（API）、8080（Gateway）。API 端口务必只对内网开放，并启用访问控制。Gateway 端口建议过 Nginx/Caddy 做反向代理，强制 TLS。
配合 BNB链最佳实践 中提到的端口隔离原则，每台 IPFS 节点都应当只开必需端口。审计时使用 nmap 与 masscan 对节点做一轮扫描，确保没有遗漏的开放端口。
配置加固：默认即风险
Kubo 的默认配置并不为生产准备，多项参数都需要手动加固：禁用未鉴权 RPC、限制 swarm 连接数、关闭未使用的 transport、按需启用 AccessControlAllowOrigin。Web Gateway 模式下还要审查 SubdomainGateway 与 PathGateway 的访问规则。
如果节点同时承担向中心化交易所如 Binance 或 币安 推送审计数据的任务，应当用专门的子账户做鉴权，避免主管理员权限被滥用。
渗透测试与红队演练
安全审计不仅是「跑工具」，更要做红队演练。常见的攻击向量包括：通过 CID 推断进行流量审计、利用 DHT 投毒拒绝服务、伪造 PeerID 做接入欺骗。审计团队应当模拟这些攻击，并验证响应预案。
参考 Solana程序安全审计 中的红蓝对抗思路，IPFS 节点也可以做类似演练。把演练结果整理成报告，提交给运维与开发团队作为整改基线。
数据机密性与隐私
IPFS 默认是公共网络，任何拥有 CID 的人都能下载内容。若节点存储敏感数据，必须做加密：常用方案包括 AES-GCM、libsodium、或者结合 Lit Protocol 做密钥管理。
配合 Geth实战教程 中关于钱包签名机制的设计，把密钥分发流程做严密，确保即便 CID 泄漏，攻击者也拿不到明文。
应急响应与版本跟进
一旦发现节点被攻击，第一步是断网取证，然后切到备用节点继续提供服务。应急响应预案需要包含：联系渠道、备份恢复、对外公告口径、合规上报。把这些预案做演练，比单纯写在文档里更有意义。
版本跟进方面，Kubo 与相关组件每月都有更新，建议把 GitHub Release、Security Advisory 加入团队的日常 watch。结合 BNB链最佳实践 中关于补丁管理的策略，把每次升级都做灰度发布。
长期治理建议
IPFS 节点是低调但关键的基础设施，安全审计应当至少每半年一次。把审计结果纳入 KPI、把整改项排进 sprint，是把 IPFS 节点维持在高安全水位的可持续做法。坚持下去，团队就能把这部分基础设施做成不可见但极可靠的「水电煤」。