蓝队监测组工作

目前主要分三组，监测组 、应急响应组，主防处置组，初步制定三组 ，磨合磨合熟练后，再准备组织溯源反制组。
经过几天的演练，基本确定3班倒的模式，监测组监控厂商设备 ，发现异常及时填处置单交给应急响应组，应急响应组拿到处置单，要进行分析，期间要反复和甲方、系统供应商沟通，然后形成处置建议 ，交给主防处置组，最后主防处置组进主防处置。
主要要求看懂设备，设备相当于监控设备，硬件，有web界面，把别人攻击的都会展示出来。分工溯源、分析日志一般都是天眼之类的，溯源，别人攻击的反溯源一下。
加固：HW前内部的巡检，自己家的资产全部过一遍，有漏洞赶紧修复，护网过程加固少，被打就被打了，封IP，停系统。
发现攻击：被攻击的系统进入应急响应，先封IP、再关站、断网，红队拿到shell，把流量转发出来才能拿到更多的分。
一个总结就是：系统误报太多，交流消耗太大。整理一下两天的处置单，一共是68个，其中确定误报的为58个，确定为攻击的为6个，还在继续排查的4个。
大致分为四类：
1、业务系统之间的调用请求，设备报警，内网渗透向；
2、业务公司人员上生产系统上的poc测试（直接执行注入和远程读取命令），被系统误报成渗透攻击（这一条应该不算是误报，毕竟有攻击行为，只不过是自己人干的）；
3、centos系统自动更新系统文件，设备报警，未经授权的访问外网；
4、业务人员配置中间件，设备报警；

二、交流消耗太大
我所在的现场，根据甲方需求，分为4组：监测组、防守应急组、处置组、溯源反制组
流程如下：
1、监测组监测设备，整理报警信息，提交处置单给防守应急组 ；
2、防守应急组拿到处置单，进行排查，该组没有看机器的权限，只能和处置组建群沟通，根据处置单（期间要不停的去监测组设备上看详细信息），提出处置建议，让处置组来操作；
3、处置组，主要是甲方的业务人员，因为很多对应急的操作不是很熟悉，而且有些系统他们还需要找系统服务商进行操作，这就增加了沟通的成本；
4、溯源反制组，根据确定2的攻击进行溯源和反制，前两天真实攻击较少，这组的兄弟这两天很哈皮，基本没啥事，静等盒饭了
所以一个处置单 ，基本消耗在不停的找人的路上，一个处置单最初只有建群的时候只有3个人，中间遇到不停的问题不停的加人入群，有负责VPN的、系统业务开发公司的、甲方维护的、系统管理的。。。。就这样不停的加，直接一个处置单群，加了20多个人，这个问题最终才解决，最终发现居然是误报，自己人操作、系统的业务正常调用等等

1、随着护网的进行，要不停的修改报警规则，从源头上减少误报
2、从VPN上排查谁登陆了报警IP是一个高效的方法
3、增加扁平化的沟通交流方式

   具体⼯作内容也是围绕着⼏个点展开，根据各单位不同的要求，⼯作量也不同，⼤体上主要⼯作内容为：收到告警-判断告警真实性-上报IP-封禁
   1. 收到告警后，需要根据⾃动判断的攻击类型查看特征流量，判断是否是误报：特征流量与攻击类型是否符合，是否是因为正常流量中的某些参数与攻击流量相似产⽣误报。如果通过特征流量判断不出来，则可以通过全流量包进⾏深⼊分析。
   2. 如果是误报则不需要上报，有能⼒可以⾃⾏修改告警规则减少误报（⼀般不⽤）
   3. 如果是真实告警，则需要进⼀步判断是否攻击成功，如果攻击失败，直接上报给封禁组，进⾏IP封禁。如果攻击成功，则需要⽴即上报应急响应组，开始应急响应流程
   4. 如果遇到⼤量告警，根据不同⼚商设备有不同功能可以统⼀批量处理（睿眼会将⼀段时间内的同⼀个IP发出的攻击流量，统⼀显示）