我见过太多人栽在这个漏洞上。短洞解2018年某省级单位的文件门户网站被扫描出短文件名漏洞，运维组连夜改代码，名漏结果改了三天没改对——因为他们根本不知道IIS的决方8.3短文件名机制是怎么回事。

这个漏洞的短洞解本质很简单：Windows文件系统为了兼容老程序，会自动为每个长文件名生成一个“短别名”。文件比如 web_config_2019_final.aspx 会被截成 WEB~1.ASP。名漏IIS在处理HTTP请求时，决方如果你访问 WEB~1.ASP，短洞解它会返回不同的文件响应状态码——404和400的区别，或者响应时间不同。名漏攻击者就靠这个差异，决方用字典爆破出服务器上真实存在的短洞解文件名。

最坑的文件是，这个漏洞没法彻底“修复”，名漏只能缓解。因为短文件名是NTFS文件系统的硬性机制，你删不掉它。网上那些说“禁用8.3名称创建”就能解决的教程，只对新建文件有效——已经存在的文件，短名还挂在那儿。

那怎么办？我实测过几种方案，效果排序如下：

第一，最直接的是修改注册表 NtfsDisable8dot3NameCreation 为1，然后重启。但注意，这只对之后创建的文件生效。存量文件你得用 fsutil 8dot3name strip /s /f D:\wwwroot 强制清除。我在测试环境跑过，一个500G的站，跑了大概40分钟，期间IIS会间歇性无响应——生产环境得在凌晨操作。

第二，URL重写规则能挡掉大部分扫描。在web.config里加一条规则：如果请求路径包含 ~ 且长度小于10，直接返回404。但攻击者会换用 * 通配符变体，比如 WEB~1.*，所以还得配合请求过滤，把包含 ~ 的URL全部拦截。我见过一个案例，运维只挡了 ~，没挡 *，结果被扫描出 backup_2017.zip 这种备份文件，直接下载走了。

第三，也是最容易被忽略的——把敏感文件移出网站根目录。短文件名漏洞能探测到的只是“文件是否存在”，但如果你把备份、配置、日志都放到网站目录之外，就算被扫到名字，他也访问不到实际内容。我帮人做过一个方案，把 App_Data 和 backup 文件夹挪到D盘非web目录，再设置NTFS权限拒绝IIS用户访问，扫描器就彻底哑了。

还有个偏方，虽然不推荐但确实有效：把网站所有文件改成6位以内的短文件名。比如 index_2024.aspx 改成 i24.aspx。这样系统生成的短文件名和原文件名一致，扫描器无法通过“长名转短名”的差异来判断文件是否存在。缺点是你得改所有代码里的引用——我见过一个团队这么干，改了两周，最后发现有个第三方控件写死了长文件名，直接白干。

最后提醒一句：别只盯着IIS配置。这个漏洞的根源是Windows文件系统，意味着你服务器上任何一个可访问的目录都可能被扫。检查一下IIS里是否开了目录浏览——如果开着，攻击者连爆破都不用，直接列目录看文件名。我遇到过最离谱的案例，某站把 upload 目录设了可写，结果被人传了个探针文件，配合短文件名漏洞把整个服务器盘符扫了个遍。

实际操作层面，你至少要做三件事：关掉目录浏览、启用请求过滤、定期用扫描器自查。网上有开源的 iis-shortname-scanner，拿它扫自己的站，跑一遍就知道哪些文件暴露了。扫出来的结果会让你吃惊——我扫过一个客户的站，发现 old_website_2015_do_not_delete.zip 这种名字的文件就躺在根目录里，短名是 OLD_W~1.ZIP，一猜就猜得到。

别迷信防火墙和WAF，它们能拦常规扫描，但拦不住慢速定向爆破。真正靠谱的还是从文件系统层面断根——要么清短名，要么挪文件。两种都做，基本就稳了。

(责任编辑：休闲)