mylamour / blog

Your internal mediocrity is the moment when you lost the faith of being excellent. Just do it.
https://fz.cool
61 stars 14 forks source link

攻防之道之从渗透测试看应急响应 #37

Open mylamour opened 6 years ago

mylamour commented 6 years ago

记得之前面试默安,谈到最近在对接渗透测试服务时,云舒大大问了一个问题:寻求第三方测试前,自己为什么不先进行下渗透测试呢? 在我看来,攻防之道可以用八个字描述(ps:以我目前的菜逼境界): 轻重缓急,大小多少。

其他工作中,也无非如此。以下,本次对接渗透测试服务中产生的思考以及应急响应产生的思考。至于哪些漏洞的发现,直接看最下面的附录部分。

  1. 问题一: 渗透测试者的水平(未知的攻击能力) 经常可以发现渗透测试者的水平可谓是远近高低各不同,所以选到靠谱的渗透测试服务团队就是一个问题了,收费的话也是不一而足。但是我最不喜欢的就是被忽悠,当然任何一个人也都不喜欢被忽悠。这个忽悠不仅包括服务方,还包括老板。

  2. 问题二: 预算与老板的预期(未知的支付能力) 有的老板豪放,有的缜密。有的喜欢预付款,有的喜欢白干,然后付费。那么当你遇到这种需要预付费但是心思缜密的老板,毫无疑问。Go die。

  3. 问题三:公司内团队的防守能力(已知的技术能力) 不肯学习的菜逼一直都会是菜逼,笨蛋不会爆炸,一流员工招一流员工,二流员工招三流员工。防守能力,心知肚明。心里的B数很明显。 技术能力,以及互相协调的能力等等决定了防守的能力。

  4. 问题四:非防守团队的员工安全意识(未知的弱点) 很不幸的是,在第二次的渗透测试过程中,对方发现有员工的github信息泄露,测试环境的账号密码,均暴露了,虽然并不能访问,但是也还是泄露了关键信息。这部分的问题出现职责也在安全这边没有培训好。

  5. 问题五:程序根本上的设计问题(未知的代码能力) 代码中存在的漏洞是基础安全之外的一个重要切入点,产生的危害非常大。所以SDL的推动是必须的。这样才能从整个过程完善安全能力。

可以看到的是,整个过程中,已知的只有己方的技术能力。然后,很大程度上的在和未知的攻击对抗过程中失效。进行应急响应的时候,往往意味着,系统出现了问题。对方可能已经进入后渗透阶段了。此时应急响应的优先级应该排在首位(根据出现问题的严重情况,即出现的问题是否严重,涉及多少资产),去进行响应。此时响应的过程中面临的问题又有:

  1. 问题一:其他机器上恢复资源,访问事故机器,阻断恶意攻击
  2. 问题二:针对机器进行取证,检查有无后门 老鸟早已删除痕迹,但还是要看dump下内存,看日志 accesslog, /var/log/messages/,看有没有隐藏文件?有没有恶意文件留下?非法进程在哪?启动文件有没有修改?在目标机器上操作,尽量不要安装新的东西,避免产生影响。最好的办法,重新部署一套到新的机器。 问题三:批量自动化的操作 大量的资产,手工已经不是现实的,当你缺乏这些自动化的时候?需不需要先去自动化?ROI为主。
  3. 问题四:面临哪些已经失去联系的服务器,或者不可控的资源,或者是失去关键数据? 有的机器已经被加密或者被删除,等待向勒索者支付。或者aws账号都已经被盗了,快速的申诉?企业专属支持通道?关键数据缺乏备份?事前无日志收集系统。比如说前几天在群里看到有人问了一个问题是:怎么查找是谁rm -rf的数据库。 当我面临这个问题的时候,第一会先恢复数据库,然后审计跳板机log,如果没有跳板机怎么办?看云环境上的记录log,是谁访问的。上去看syslog,binlog已经不现实了。然后通过确认哪些员工可以访问?哪些员工有权限删除,哪些没有? 所以,备份是很重要的啊!权限分级是很重要的啊!

tips: 可是,你没有发现tmux可以绕过jumpeserver的命令录屏记录吗?但是如果备份到其他存储就不行了。

Other

当前过程中我面临的问题:

Resources