天眼负责流量分析，部署在旁路，对交换机镜像过来的流量进行监测、分析和溯源。
椒图负责服务器的系统防护，通过在服务器上安装的客户端，将收集到的主机信息发送到控制中心集中分析。
防守方主要分为三个组：安全监控组、事件研判组、应急处置组。
1）监控组分析安全设备的告警，确定是攻击就提交给处置组封禁IP；分析不出来就提交给研判组分析。
2）研判组负责分析监控组提交的告警是否为攻击，必要时可以访问受害网站复现攻击，或者联系受害网站的负责人验证是不是正常业务/人为操作。
3）处置组主要负责封禁IP，如果是webshell这种攻击，还需要联系受害网站的负责人，协助修复漏洞或者加固网站。
三个组通过指挥调度管理系统进行协作防护：
大家上班第一件事就是登录管理系统，监控组向管理系统提交告警的攻击/受害IP、告警类型以及payload，处置组/研判组看到管理系统上有新的告警了就封禁IP/分析告警事件。
原则上来说，我一个安全监控组，只需要盯着安全设备，简单分析一下然后提交告警就可以了。
由于公司就来了我一个，只要是我们产品相关的事，都会把我喊过去。
因此，除了设备监控外，我的工作还包括但不限于：分析webshell文件、分析病毒木马文件、升级/加固安全产品、对失陷主机进行后门扫描和病毒查杀、以及协助失陷网站修整加固。。。
好了，撇开厕所不谈，下面分享几个印象比较深的攻击事件吧：
青藤云的蜜罐检查到，有个用户电脑访问了蜜罐的80端口，用户断网以后用360和火绒查杀了三个毒以后，重新上线，结果又踩了蜜罐，用户又用360和火绒扫了一遍，啥也没扫出来，就喊我过去处理。
当时我就一脸懵逼：这是我一个安全监控该干的事吗？
但架不住一群人直勾勾的盯着我，只能硬着头皮去干
先是用椒图扫了一遍webshell和后门文件。
确认没有后门以后，用专杀工具全盘扫描，扫出来7个病毒。
扔到ti威胁情报中心鉴定，确定就是高危病毒。
然后提交到二线做病毒分析，确认是远控木马类病毒，与触发蜜罐的告警有相关性。
最后删掉病毒，重新上线，没有再出现异常现象。
椒图检测到一个服务器上存在webshell，通知用户紧急下线网站，开始排查和加固。
一群人围在哪里分析了半天，然后理所应当的把这事扔给了我：“你们家的设备，当然要你去处理呀~”
结果上线后，网站访问不了。。。
在重新部署了n遍项目，外加换了两台备用服务器后，时间已经来到了凌晨六点，距离规定的上线时间还差三个小时。
“实在不行，咱们就写个静态主页跳404吧，点啥功能都给跳到404，最起码，他们一时半会儿不会怀疑是我们的问题，咱们也能多点时间排查问题。”
开发的嘴角慢慢上扬，空洞的眼神里重新亮起了光。
不幸的是，这话被项目经理偷听到了，在经理的谴责声中，我看到，开发的眼神，竟慢慢的黯淡下来，直到剩下两个黑黑的眼眶。
兴许是一晚上没去厕所的原因，在换到第三台备用服务器的时候，网站终于恢复了。
事后，我问开发：“你们的运维咋没过来呢？”
“我就是运维。”
“那，开发呢？”
“开发也是我。”
“？？？，那，你们项目组。。。”
“只有我自己~”
平均下来，一天得有三千多条告警，但其中大部分都是误报，接下来分享一些简单的告警流量特征。
看访问路径中是否存在特殊文件或路径。
比如，访问备份文件.zip
访问默认文件
或者特殊类型的文件
看请求参数、请求头或请求体中是否包含SQL语句或关键字。
比如，GET请求中包含SQL语句（联合查询注入）：
POST请求体中包含SQL语句：
为了方便绕过，还会改变SQL关键字的大小写或编码。
比如：大小写绕过：
编码绕过：
客户授权的话，可以复现payload，根据页面的返回结果、响应时间来判断是否注入成功。
看请求体中是否包含代码内容：
如果响应体中有 success 等上传成功的字样，或者有该文件的访问记录，则说明webshell上传成功。
看请求参数或请求体中是否包含JavaScript代码：
将响应体的数据复制到文件中执行，如果弹窗，就说明攻击成功。
如果没弹窗，就 Ctrl+F 搜JS代码，常见的有：
看请求参数、请求头、请求体中是否包含恶意代码。
比如，请求体中包含PHP代码：
因篇幅问题不能全部显示，请点此查看更多更全内容