内容摘要：存在可访问的共享目录漏洞修复 上周帮一家做跨境电商的客户做渗透测试，扫到一个NFS共享目录直接以rw权限挂载在公网IP上。进去一看，里面躺着整个数据库的备份文件，时间戳是三天前的。管理员甚至把备份脚本

存在可访问的访问复共享目录漏洞修复

上周帮一家做跨境电商的客户做渗透测试，扫到一个NFS共享目录直接以rw权限挂载在公网IP上。共洞修进去一看，享目里面躺着整个数据库的录漏备份文件，时间戳是访问复三天前的。管理员甚至把备份脚本的共洞修密钥也放在同一个目录里——这种“贴心”程度，让我怀疑他是享目不是故意给黑客递刀子。

这类漏洞的录漏根源往往不是技术难度，而是访问复运维习惯。很多团队默认内网是共洞修安全的，把共享目录权限设成777或者nobody:nogroup，享目然后图省事直接暴露出去。录漏可内网真的访问复安全吗？去年某大厂被钓鱼邮件打进内网，横向移动时就是共洞修用了一个带弱口令的SMB共享，半小时内把几千台机器搞瘫痪。享目攻击者不关心你内部网络多干净，他们只需要一个入口。

修复的第一步是盘清家底。别只查NFS和SMB，FTP、WebDAV、rsync这些都可能成为共享通道。用netstat -tlnp看监听端口，再用showmount -e扫一遍本机导出的NFS列表，把那些“不知道谁在用”的目录全部记下来。我见过一个客户，共享目录有47个，但实际业务用到的只有5个——剩下的全是历史遗留，有些甚至创建于十年前。

第二步是收缩权限。共享目录必须遵循最小权限原则，业务需要rw就绝不给rwx，能只读就只读。同时禁用匿名访问，强制使用LDAP或Kerberos认证。这里有个细节：很多人改了配置文件就完事，忘了重启服务。NFS的exportfs -ra和SMB的systemctl restart smbd必须执行，不然旧配置还在内存里跑着。

第三步是网络隔离。共享目录不该暴露在0.0.0.0上，用防火墙限制源IP。如果业务确实需要跨地域访问，那就套VPN或者SSH隧道。别嫌麻烦——我见过一个真实案例，某公司把SMB共享绑在公网IP的445端口上，结果被勒索病毒加密了所有文件，最终交了40万美元赎金。要是当初加一条iptables -A INPUT -p tcp --dport 445 -s 192.168.0.0/16 -j ACCEPT的规则，这40万就能省下来。

最后说点实在的。修复完别急着收工，要模拟攻击路径验证。从外部网络尝试挂载，从内网不同网段尝试访问，用弱口令字典测一下认证强度。我习惯在修复后等一周再复查一次，因为很多临时开放的共享会被业务人员“不经意”地重新打开。安全不是一次性的操作，而是持续对抗惰性的过程。

有个反直觉的现象是：越小的公司越容易犯这种错。大企业通常有制度约束，小团队反而觉得“我们没什么价值，黑客看不上”。可现实是，勒索病毒的扫描器不会区分公司大小，它们只找开放端口。你那个挂在公网上的共享目录，在扫描工具里就是一行刺眼的MS17-010或CVE-2021-44142。

修复动作要快，但别慌。先把暴露面收回来，再逐步调整权限和认证。记住，共享目录本身不是罪过，罪过的是让它裸奔在不可信网络上。你要是连自己有哪些共享都说不清，那才是最大的风险。