各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 204期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

上期精彩内容请点击：MacOS风险排查怎么做；春节安全值守怎么安排

话题抢先看

1. 应对监管部门审计，如何提供安全事件应急响应管理制度的落实情况？

2. 针对短信验证码，如果第一次输入错误，是否需要求销毁让用户重新获取？

3. 关于WebShell的检测思路及控制措施的探讨。

4. 抗DDoS的应急预案分享。

话题一：应对监管部门审计需要提供安全事件应急响应管理制度的落实情况，这个一般提供些什么？

A1：

第一就是你们有没有完善的应急响应制度规范，第二就是你们有没有定期组织演练应急演练工作及档案留存，第三就是你们针对各种安全事件的应急相应流程设计及应急响应的组织架构，我个人理解的大致就是这些。

A2：

不能同意更多。先有制度，体现人员组织架构的保障，流程的保障，特定行业的报送，合规保障，和定期演练，以及执行具体情况的记录。先有，再谈做得好不好。

A3：

有没有？基本文档；
做没做？日常运行记录；
好不好？度量指标、各部门绩效。

Q：各种制度肯定是有的，但是都是基于书面的文档，审计落实情况是要按着你的制度一条一条核对？

A4:

是的，然后就是落实你们写的内容，留存。

A5：

按理是要这样的，但是先要确定制度是合理的。应急有KPI?是SLA是吧？

A6：

应该不是KPI，是SLA，主要还是在应急响应演练中出材料。

A7：

定义好SLA，这次我负责的审计被揪出来这个点了，虽然每次Case都是ASAP去完成的。

A8：

那就是不符合项吧，SLA不达标要融合到责任方KPI里。

A9：

确实不完全符合，不过有计划在前，分阶段进行也可以表明良好的态度，风险评级会有所下调。

A10：

这个是，不过正常情况下还是通过演练产出。

A11：

内部演练投入产出性价比个人感觉有限，人力和业务规模完全不成比例。

A12：

做到合规就好了，演练也有不同方式，最廉价的是桌面演练。

A13：

SRC，更多是侧重漏洞挖掘啊，而不是应急响应啊。

A14：

确实，第一步合规，在此基础上再进行多样化的演练形式尽可能贴近真实事件。SLA主要还是看你们对于应急响应威胁的容忍度吧，譬如你们要求多少分钟要响应，多少分钟要恢复数据，多少分钟要溯源，什么事件上报到什么级别，流程怎么流转，看你们自己定义。

A15：

对的，谈到这里的话，就是挺极致一个状态了，因为涉及RTO RPO的关系而定出相应的SLA，随之而来的就是备份机制也会被调查。

A16：

备份机制看有没有钱吧，我这边使用的是CDP的备份方式，本地一份，同城异地一份，云上一份。

A17：

没钱就真没辙了，安全就是得投入了，至少异地一下。还有就是备份的频率，不然是无法满足RTO RPO,同时也就是说SLA也不能被满足。

A18：

所以再定SLA，一定要提前问好公司的投入以及领导想法，很重要。我这之前死活不买，还是去年美的勒索事件，我借机去说，然后推动这个事情。

话题二：针对短信验证码，如果第一次输入错误，你们会不会要求销毁让用户重新获取？

A1：

看了多家电商和金融，好像没有这样做过的。

A2：

如果不这样做，那不就可以暴力破解？

A3：

不会，这个可以通过有效期和验证码位数在一定程度解决。

A4：

有个上限就行吧，设置频率和上限。

A5：

你的意思是只能输入错三、四次这样吧。

A6：

业务上应该都有这样的模型，照顾用户体验，短信延迟和手速、手误的情况下，1分钟6位密大概几次。
可以拿手机银行App转账试下，有没有上限机制。

A7：

要是增加难度，可以采取征信验证码方式，大小写数字验证码，控制频率、增加验证码滑块机制，设置错误请求次数。

A8：

我们公司就是这么设置的，实现原理：超过次数，让短信验证码的Redis缓存过期。

话题三：对于WebShell的检测思路有哪些？发现后可以采取哪些控制措施，比如即使有了后门，但服务器不给任何权限，不让修改任何内容？

A1：

主机安全和流量检测应该都能发现WebShell上传、命令执行。WAF或者下一代防火墙也可以检测到相关日志。

A2：

文件修改时间，文件特征扫描查杀，内存查杀。如果降权限要在之前做，给Web、数据库的权限本身就不用最高。

A3：

文件修改时间可以改，文件特征也可以改，内存查杀没用，因为是WebShell。

A4：

内存查杀没用是因为没有注入内存，和是不是Webshell没关系吧，文件查杀没有是因为代码注入内存了，无文件落地，没有用。

A5：

就话题来说啊，你要分情况那就复杂了。那要按内存注入这么延伸，说不好听点就是根本查不了，WebShell然后再后续R3免杀Shellcode注入内存，你咋查？内存查杀随便你查。

A6：

常规检测思路就是用中间件日志分析、WAF、或者一些Edr Agent扫描，针对免杀的可以进行所有的文件hash及文件内容比对，有后门不给权限修改处理方法比较多，先两种：

1.暂停服务写权限申请；

2.以暴制暴，怎么传进来的WebShell，就再怎么传一个普通文件把WebShell替换了。

A7：

权限看业务，加白都可以。如果是正常业务需要还是要合情放开。

A8：

白名单真的可以吗？

A9：

可以，但是要结合业务考虑。但白名单难，可能影响业务，做黑名单容易。

A10：

一步步来，代码安全是一部分，但主要还是靠WAF+HIDS的安全能力。

A11：

主机、流量层面均可以发现；主机安全、安全域划分、边界防火墙均可以一定程度上限制。

A12：

白名单会出事，业务找来也难扛，除非所有可能场景能全覆盖，不过有点难。

Q：WebShell检测往往需要基于流量或者本地读取到文件，能否实现在不获取流量信息及WebShell源文件的情况下进行远程检测？

A13：

不读流量，不看文件，怎么知道有？除了日志还真想不到其他的路子了。

A14：

WebShell在上传了在静默情况无法感知，除了hids之类的做定期主动扫描，没法发现。

A15：

应该还可以通过开放的服务端口进程排查吧。

A16：

有没有这么一种可能，根据行为，进程异常行为标记也可以。

A17：

安全设备啊，HIDS。

A18：

安全设备也是看日志、流量，端口也是看流量。

A19：

看标记的恶意IP，比如矿池、WebShell之类的，从防火墙之类的看连接记录就知道中没中。

A20：

远程检测其实应该还是有的，就是类似黑盒测试，在知道网址的情况下进行黑盒模拟测试，从而发现可能存在的WebShell。

A21：

通过异常行为，有没有开端口，有没有起BASH、CMD之类的。

A22：

在服务器上对文件和流量进行检测，可不可以理解是白盒测试，不能获取文件和网络流量等信息，是不是就要做黑盒测试？

A23：

我也入侵一遍，然后上门摸索下有没有WebShell？

A24：

不，这叫黑盒检测，模拟测试，或者说，通过信息收集，获取网站对应的服务信息，组件信息，判断存在风险的高低。

A25：

在我看来就只能是主动防御和主动扫描，被动发现。要发现异常行为只能靠流量和系统日志监测分析，属于主机安全和态势感知能力范围。

A26：

还有一种方法，开发一个自己特有的Web系统，让市面上所有的WebShell解析的框架都是失效，什么PHP啊，ASP啊，JSP啊，都不用，用FB语言编写。

话题四：能否分享下抗DDoS的应急预案，云或本地机房都可以。我们这边有些对公众开放的服务，逐步迁上云了，所以想搞个应急预案

A1：

我以前的做法是提前准备DNS和DHCP ，如果入流量或者并发数超过一定程度，先阻截（比如WAF/防火墙、IPS啥的）禁用攻击IP ，同时观察有效用户的反应，如果因为攻击导致正常用户也不能用了，发个公告，然后路由器把端口Down掉，启用备用线路，同时切换DNS ，让用户退出APP后重新登录，自动刷新新的DNS。

A2：

迁移上云了，可以Dnspod之类的改DNS解析，走到云上抗DDoS，云上直接买抗DDoS服务，缺点是得云上有一套 同步的Nginx集群，以及云上云下专线互联，让流量能从云上清洗完后回到本地IDC。

A3：

这个比较难，见招拆招了，无论本地机房还是云，做清洗肯定绕不开带宽提供方，只有拥有把源流量全部吸收的能力，才能做清洗。改DNS的云清洗有一个弊端，如果源站IP暴露了，别人是可以绕过云清洗的。

与云WAF不同，云WAF可以做白名单，仅允许反向代理IP访问Web端口，但是DDoS是直接针对资源消耗的攻击，一旦源站IP暴露，云清洗就失效了。

A4：

DDoS是一个攻防成本非常悬殊的玩意，流量大到一定程度，神仙也没办法，直接做路由黑洞了。

A5：

租用IDC机房的话，流量达到一定程度机房都给你丢了，里面设备根本处理不了。自建我就不清楚了，可能会选择运营商来做吧。

FreeBuf 观点总结

俗话说的好，身正不怕影子歪，在应对监管部门审计时，只要有完善的应急响应制度规范、完善的人员组织架构，做好定期演练、留档，无论是面对监管检查还是真实的安全风险，都能在最大程度上积极应对。

在WebShell检测思路的讨论中，大家提到了中间件日志分析、WAF、文件特征扫描查杀等多种方式，以主机安全、安全域划分、边界防火墙等进行一定程度上的限制。也有人提出以白名单的形式进行权限控制，但白名单似乎被吐槽做起来较难，而且容易引发业务上的矛盾。至于能否实现在不获取流量信息及WebShell源文件的情况下进行远程检测，大多认为脱离了流量很难实施，但也提出了如类似黑盒测试，在知道网址的情况下进行黑盒模拟测试，从而发现可能存在的WebShell。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf2022，备注：甲方会员