职业欠钱：漏洞扫描的一些运营常识

今天在群里又看到了漏洞扫描的话题讨论，这让我挺意外，因为我一直觉得“漏洞扫描”是一个行业里最最普遍的事情，但是群友却热心的探讨了一个上午似乎还没停下来的意思。所以想简单的聊一下安全运营里，关于漏洞扫描的一些简单常识。

漏洞扫描是信息安全工作里，完成风险评估最常见的一种手段。就像是医生用X光来检查一下病人的身体，是不是有毛病一样，安全工作者经常通过漏洞扫描来评估目标系统是否存在漏洞，进而决策如何做下一步的安全防护。

2. 漏洞扫描的原理是什么

发送特定的请求，到远程服务，根据远程服务返回的行为，判断是否存在某个具体漏洞（也有很多时候是根据返回的版本号信息来判断）。

3. 漏洞扫描有什么影响

3.1 网络影响

请求网络包的频率、数量，对网络和应用造成影响，交换机/路由器可能因此宕机，引发连锁反应，QPS过高可能超出服务的性能极限，导致业务中断；

3.2 异常处理影响

业务无法正确处理请求包里的特殊输入，引发异常宕机，比如一个私有协议的服务也许只是碰巧监听在了TCP 80端口，收到一个HTTP Get请求就直接挂了；

3.3 日志影响

请求公网的业务时，每一个URL的探测，都可能造成一个40x或者50x的错误日志。而业务的正常监控逻辑正是用Access Log里的状态码来进行的。不做任何处理的话，突然40x猛增，业务的SRE和RD必然要进行响应，如果他们从半夜、假期着急忙慌的登录VPN查了半天发现是安全工程师触发的，甚至还连带了3.1、3.2的影响，把某业务弄出事了，这个责任一定是安全工程师要背负的。

4. 产生了什么问题

对于安全工程师而言，不扫描可能意味着无法开展工作了，无法得知公司风险，无从开展治理工作；

对于业务方而言，扫描意味着添乱，业务不可用的风险是最大的风险；

有不少同行因此背锅黯然受伤的，也有一些强势的同行得罪了业务的。

5. 错在了哪儿

漏洞扫描对于业务侧来说，是一种新的变化。一个变化的首次引入，有问题是必然的，没问题才是异常的。合理的做法是遵循ITIL里的“变更管理”。

变更计划：扫描的时间、IP/URL/端口范围、QPS、测试用例集（有DoS的测试用例选择、有Delete/Update相关的资产选择、有POST隐蔽接口的选择）

变更风险评估：交换机路由器的流量和容量、业务的QPS、业务/网络挂掉的最极端风险评估

变更知会：业务的管理者、RD、SRE、DBA、QA甚至网络维护方，是否知道上述所有关键信息，并授权同意进行扫描（全公司强制的至少做到知会）

回滚计划：如果出了问题，怎么最快速的停止扫描和恢复业务（有些动作要上面的变更知情范围的关键干系人配合）

变更观察：执行扫描的时候，大家有没有在盯着服务是否出错（以及判断业务是否正常），以便在出问题的第一时间响应；

变更总结：灰度执行过程中总结不到位的地方，在下一次工作中改进

严格的说，不按照这些方法，上来就一通猛扫的，的确是安全同行自身没有做到足够专业。不能怪业务侧不理解不支持。

传统的乙方厂商在执行扫描任务之前，好像都会有非常详细的风险说明和授权书给到客户去签署，类似于做手术之前给你签署的风险告知协议一样，你必须知道会发生什么事情，已经同意并授权了，我才给你干活。

你可以说害怕动手术，比如一个80岁的老人，开刀之后恢复的难度很大，不开刀可能还稳妥一些，那你可以拒绝这个手术。

但是对于一个30岁的年轻人，知道自己肚子里可能有个肿瘤，得开刀做活检，看是良性还是恶性，才能决定下一步的医疗方案，不签字也许医院是不会帮你做的，对应的风险也是你自己承担。

对于大型的甲方来说，有时候一个业务不做安全检查可能导致黑客通过它进入内网，威胁内网其他核心业务。这种场景可以理解为，非典高危时期，某个同学要待在集体里，却拒绝接受体温检查，那就由不得这位同学自己了。

按照上述思路和业务方沟通，多数情况下，业务方并不会完全无理拒绝。当然你沟通的业务方最好有一定的管理职级，因为高管理职级的同学在某些通识认知上，沟通成本往往要低很多。

自上而下达成一致，和试图说服每一个一线员工相比，要轻松也有效得多。（业务大佬认可了，一线同学有问题可以回去找自己大佬沟通，你也省事）。

6. 解决建议：公网坚决扫，内网谨慎

按网络分类：互联网公开业务、内网业务

按服务类型分类：Web类、高危服务类、私有协议类

公网Web服务，业务必须接受安全检查，因为我们不扫，黑客也会没日没夜的盯着业务扫。与其未来无计划的被黑客扫挂，不如有节奏的按变更计划，逐步适应被扫描。

在遵守变更管理原则的前提下，也就是首次上线稍微繁琐痛苦一些，比如业务侧需要1个月时间修改监控逻辑（忽略扫描器触发的错误请求），需要对某些扫描触发的异常进行兼容适配，甚至某些无人维护的业务被扫描之后改不了，只好加白名单。这些需要磨合。磨合完毕，也就是安全团队可以例行周期不间断扫描的时候，上述问题根本就不再是问题了。

公网高危服务：只识别协议，不做漏洞检测，因为高危服务的端口开放出来就是不可取的，直接关掉服务比较直接，检测漏洞只是浪费更多的资源罢了；

公网私有协议：大多数扫描器并不能支持这些协议的漏洞检测，只能忽略不做扫描，当然这里会存在盲点，暂时不展开；

内网服务的复杂度比上面高很多倍，一方面，内网你不扫，黑客进来扫的几率没那么大。另一方面，大家对传统的特权的依赖导致内网漏洞比公网多很多，也更禁不住扫，你一扫，大概率就是会出事的。

所以，如果仅仅做端口扫描，确定交换机路由器还扛得住的情况下（嗯，之前遇到过老旧的网络设备你稍微开一点扫描请求它直接挂掉的现象），相对可接受。

协议识别这一步可能触发某些脆弱的服务挂掉，账号爆破则可能触发账号封禁（继而引发连带的事故），而漏洞扫描风险更大。

所以，多数时候其实并不鼓励使用网络扫描的方式来做内网风险评估，如果agent能够采集到版本号、配置、账号相关的信息，其实也能完成风险数据的采集，不必死盯着网络扫描这一个手段。

可是，这样内网岂不是很多风险了？

残酷的事实是，是的，这是现在的绝大多数企业的现状，非常可怕，对么？如果某些漏洞特别情急（比如MS17-010)，针对特定的端口服务，内网其实也可以遵守上面的标准流程去扫描的，但是全量全范围的漏洞扫描，就很难实施了。

好吧，今天先写到这，请大家多多指教。

声明：本文来自君哥的体历，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。