IIS短文件名枚举，文件说白了就是名枚利用Windows文件系统的老毛病，把服务器上不该看的文件东西翻出来。这个漏洞从IIS 6.0时代就存在，名枚到现在2024年了，文件Win Server 2022上的名枚IIS 10照样中招。别不信，文件我去年做渗透测试时，名枚还靠这招在一家银行的文件DMZ区服务器上找到了备份文件。

原理其实特别简单。名枚Windows为了兼容老程序，文件给每个长文件名都自动生成一个8.3格式的名枚短名。比如"Important_Financial_Data_2024.xlsx"会变成"IMPORT~1.XLS"。文件IIS在处理这些短文件名请求时，名枚响应时间和状态码会有细微差别。文件攻击者就是靠这个差异，一个字符一个字符地猜。

具体怎么操作？拿dir命令的扫描器举例。你发送请求让IIS去访问一个不存在的文件，比如"GET /a~1*"。如果服务器返回404，说明没有以a开头的文件。如果返回400或者404但响应时间明显变长，那就说明有戏。继续换第二个字符，直到把整个短文件名拼出来。整个过程像在玩猜字游戏，但效率出奇地高。

更麻烦的是，这个漏洞没法彻底修复。微软给过官方补丁，但只是把IIS的响应时间随机化，增加猜测难度。真要完全禁用8.3文件名生成，你得在注册表里改NtfsDisable8dot3NameCreation，还得重启服务器。很多生产环境根本不敢动这个设置，因为某些老应用还依赖短文件名访问。

我见过最离谱的案例是某政务网站。管理员把数据库备份文件放在网站根目录下的backup文件夹里，文件名就叫"db_backup_2023.bak"。扫描器不到十分钟就猜出了短文件名"DB_BAC~1.BAK"，然后直接下载走了。整个攻击过程没触发任何告警，因为请求看起来都是正常的404。

防御思路得分层。首先，确认你的IIS是否真的存在这个漏洞——不是所有版本都受影响，IIS 6.0之后微软做过一些调整。其次，Web.config里加URL过滤规则，拦截包含"~"的请求。但最有效的还是把敏感文件移出Web根目录，别放在能被HTTP访问到的地方。还有个小技巧，在站点根目录放一个名为"a"到"z"的空文件，让攻击者的猜测结果变得混乱。

这漏洞给人最大的教训是：很多"老掉牙"的问题并不会因为系统升级而消失。它们藏在细节里，等某个好奇心重的攻击者来发掘。下次部署IIS时，记得先跑一遍短文件名扫描器——用攻击者的视角审视自己的服务器，永远是最直接的安全测试。