事情的起因是收到运维人员的通知，部署在某云的一台SQL Server数据库，其中存在未启用密码过期策略的账号，并且提供了账号列表。
问题在于，我们并没有提供SQL Server的登录账号给运维，也没有将除自己之外的操作系统账号或组加入SQL Server，运维是如何拿到这个信息的呢？经咨询，这个结果是某云的安全扫描发现的。由于这台SQL Server存放的是监控结果数据，里面的信息不存在敏感信息，所以也没有太在意。
但问题始终还是要搞清楚，在有暇的时候，做了测试观察，搞清楚了这个安全扫描潜入SQL Server的方式，比较有趣，所以写了这个日记。
首先，登录SQL Server有两种身份验证模式：一种是SQL账号，这个是用账号+密码的方式；另一种是Windows身份验证，使用当前登录操作系统的账号做为凭据进入SQL Server（当然，SQL Server中要先建立 对应的映射，并授予合适的权限）。SQL Server支持仅Windows身份验证和混合身份验证（Windows+SQL）这两种身份验证模式供选择。
对于SQL身份验证验证，需要明确的用户名和密码，所以安全扫描不可能用这种方式潜入（我们的密码都是复杂加长的，sa也是禁用了的，安全扫描不可能能轻易破解，而且SQL Server日志中也没有登录失败的尝试）。
Windows身份验证应该是突破口，我们并没有将除自己之外的Windows用户或用户组加入SQL Server，检查也没有发现我们所在用户组有自己之外的用户存在。所以通过管理员用户之类的身份潜入SQL Server的情况可以被排除。
第二个需要排除的点是SQL Server服务的启动用户，因为某些原因，我们的SQL Server使用了Local System做为服务的启动用户，对安全比较熟习和敏感的同学同学都知道，在这种情况下，如果有本机操作系统的足够权限，可以很轻松地通过Local System进入SQL Server。这无疑是安全扫描可能潜入的一个有效途径（运维将安全扫描安装在我们的操作系统中，并且有足够权限）。
于是，我们将SQL Server的启动账户更换成了SQL Server默认的虚拟账号，相对于Local System，这个的安全性更高一些。更换之后，我们发现安全扫描照样能够潜入。祭起Porfiler这个法宝来确定一下安全扫描的潜入方式吧（在排查问题的初期没有用这个，是因为不太好把握潜入的时间点，也没有足够的规则来缩小Profiler的范围，所以先猜猜看），通过Profiler捕获的数据分析，确定了安全扫描是通过SQL Server服务账号潜入的。
对于通过虚拟账号登入SQL Server的这种骚操作，之前还真没有考虑过，所以自己做了一下实验，过程稍微有点曲折，但不难做到。
接下来就是防御的了，由于是本机潜入的，所以防火墙隔离就不用想了。SQL Server服务账号也不可能禁用或调整权限（毕竟服务自己还在用呢），登录触发器似乎是目前能够想到的唯一解，于是做了一个登陆触发器，检查通过服务账号进行的登录，如果其PID不是SQL Server服务自己的PID，那么将其Rollback。
到这里似乎可以结束了，我们已经在日志中看到了登录失败的信息，证明登录触发器确实有阻挡作用。但随后我们的通过Profiler做最终验证的时候，我们发现安全扫描软件仍然潜入了。
难道是我们的登录触发器规则有漏洞，但对比Profiler的结果，我们的触发器中的Rollback规则是没问题的。我们在触发器中，将Rollback的登录给记录下来，对比Profiler，我们发现安全扫描潜入时的某些登录，并没有触发登录触发器。查阅官网对登录触发器的说明，没有查到有哪些特例会导致不触发登录触发器。最后我们想到了管理员连接，经验证，管理员连接确实不会触发登录触发器。但本机的管理员连接是无法关闭的（目前我没有找到关闭的办法，能打开和关闭的只有远程管理员连接）；同样，因为是本机连接，所以也不能通过防火墙限制管理员连接端口。最后能够想到的办法就是自己先建立 一个管理员连接，将连接给占用。通过这个措施之后，我们发现安全扫描无法潜入了。（到了这里，感觉这个安全扫描就是一个典型的渗透软件）
最后需要补充的是，服务的账号可以改成带密码的本地账户或域账户，这样就规避了无密码潜入的途径，但这样的结果是：要么建立 一个密码永不过期的账号，要么改账号密码的时候重启SQL Server服务。
当然，除了SQL Server自己的服务账号之外，SQL Server Agent服务账号也是一个可以用于潜入。
【本文在个人微信公共号ZJCXC上同步发表】
1723
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
