Kali Linux & BackTrack渗透测试实战——1.4 检查清单

本节将介绍实际业务中制定项目检查清单的方法。我也很难确定检查清单这一术语是否适用于渗透测试业务。对服务器、网络、数据库等的安全设置进行诊断时需要脚本检查清单，它是否得到执行在某种程度上也决定着危险程度。 进行渗透测试时，根据访问的服务、诊断过的环境、访问方式的不同，每个环节存在的威胁也会不同。比如，即使存在文件上传的漏洞，却很可能完全不会影响系统。另外，即使是非常简单的错误处理事件，有时却会引发严重的读取问题。因此我有时也很费解，为什么非要根据死板的检查清单来判断影响度不可。 不过，此处介绍检查清单却另有目的。假设一位诊断人员对100种服务进行检测，他应当使客户理解，自己对所有服务都运用了事前定好的方法。如果对方要求提供相关的证明材料时，你跟客户说：“啊~渗透测试没有您要求的检查清单！渗透测试采用的并不是那样的攻击方式……（解释很长时间）……存在这样的差异。”如果客户回答说：“啊！原来如此，我明白了。”那该多好啊。 可实际上还有不这么做的客户。首先，只要客户有要求，就应该提供证据，而且都已按项目整理清楚。 第二，应站在项目经理的立场上考虑问题。项目经理在管理100种服务时，首先应按URL、系统或漏洞进行整理。如果不是由一人管理，而是由3~4名组员一起执行的，那么在100%信任那些组员的情况下，可以跟他们说：“各位，你们想怎么检测就怎么检测。只要出好结果就行！”当组员们提交结果时，你说了句“检测终于结束了”就轻松通过，你觉得如何？这时，你会幻想听到客户说“不错，结果很不错。我看所有的服务都检测到了”吗？现实往往没那么简单。 客户虽重视结果，却更加重视我们有没有完全检测到已知的或新发现的漏洞，并且是否解除了危险。现在再次站在项目经理的立场上对顾客说：“我们在此类服务中全部运用了如此定义的项目检查清单，共发现了几个A漏洞，B漏洞是不含在现有服务内的，没有发现C漏洞。这就是全部的统计数据，制作成了表单形式，请查阅。”换做你是客户也会感到高兴的。 项目开始后，项目经理的职责之一就是查看组员们是否对所有服务、所有漏洞进行了检测。对于组员们随时上报的漏洞，总是要提问：“这是怎么访问的呢？结果又如何呢？”“A服务存在未加密通信漏洞，B服务也可能存在这样的漏洞，检测了吗？”如果未能向组员很好地传递这些信息，项目经理就要准备饱受来自客户的责难，之后把所受的责难发泄给组员。他完全没有意识到是自己的责任……