Windows站点搭建常被忽略的3大安全权限断点

　　前不久给某客户搭Windows站点，风扇一直在转，屏幕上的行数跳得我眼晕——结果上线三天就被黑，直接把数据库表清空了。我原以为是他家开发手抖改了配置，结果查日志才发现，是三个被忽略的安全权限断点，硬生生把站点变成了筛子。这事儿现在想起来都后怕，优胜劣汰的互联网环境里，这种低级错误真能要命。

　　第一个断点在IIS的"应用程序池标识"。客户非要用默认的"Network Service"账户跑站点，说"省事儿"。我查日志时发现，攻击者通过一个上传漏洞，直接拿到了这个账户的权限——因为"Network Service"默认能访问C:\Windows\Temp，而他们家开发把临时文件全堆那儿了。更离谱的是，这个账户还能读写注册表里的HKEY_LOCAL_MACHINE\SOFTWARE，攻击者直接改了IIS的默认文档设置，把首页指向了挖矿脚本。我后来跟开发吵了一架："你们就不能新建个专用账户？就两分钟的事儿！"开发叼着烟说："以前没遇到过啊。"我差点把键盘摔了——以前没遇到，不代表不会遇到啊！

　　第二个断点在NTFS权限的"继承"设置。客户家的站点目录是从D盘根目录共享出来的，父目录的权限是"Everyone完全控制"——他们说"这样运维方便"。结果攻击者通过一个XSS漏洞，直接遍历了整个D盘，把备份文件、日志文件全打包带走了。最绝的是，站点目录的权限虽然单独设置了，但"继承"选项没取消，导致父目录的"Everyone"权限直接覆盖了子目录的设置。我查权限时，运维路过问了句"好了没"，我指着屏幕说："你们这权限设置，比我家小区的门禁还松。"运维挠挠头："我们以为子目录权限优先级高啊。"我冷笑："优先级高？那继承选项是摆设吗？"

　　第三个断点在SQL Server的"sa"账户。客户家开发非要用"sa"账户连接数据库，说"其他账户权限不够"。我查连接日志时发现，攻击者通过暴力破解拿到了"sa"密码——因为密码是"Admin@123"，这种密码在黑客字典里排前十。更可怕的是，"sa"账户默认能执行xp_cmdshell，攻击者直接通过存储过程在服务器上开了个后门。我后来跟领导汇报时说："这哪是站点啊，这是给黑客开的自助餐厅。"领导叹了口气："他们说改密码麻烦，要走审批流程。"我差点气笑："审批流程能防住黑客？还是能防住你们自己？"

文章配图，仅供参考

　　后来我逼着客户改了权限：新建专用账户跑IIS，取消NTFS权限的继承，禁用"sa"账户改用Windows认证。改完当天，攻击尝试次数直接降了90%。但我知道，这只是治标——真正的问题是，很多开发觉得权限设置是运维的事儿，运维觉得权限设置是安全的事儿，安全觉得权限设置是开发的事儿。结果没人管，最后成了"三不管"地带。我原以为这种低级错误早就绝迹了，结果在优胜劣汰的互联网里，它还在偷偷活着。

　　下一步我打算写个脚本，自动检查这三个断点——但我知道，这治不了根。真正的根，是大家对权限设置的轻视。就像有个同行说的："权限设置就像空气，平时感觉不到，出事儿了才知道重要。"可等出事儿了，黄花菜都凉了。我现在唯一能做的，就是在群里多吐槽，让更多人知道这三个断点的存在——哪怕能救下一个站点，也算没白忙活。

（编辑：我爱制作网_池州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!