新版Astp

ConfigCluster: Nacos作为注册&发现&配置中心
Astp: 原业务单元
Gateway: 网关应用, 作为DubboRpc的媒介

创建应用

原版

新版

桑老师细化标准

下载

原版

新版

报道

原版

新版

去掉报道环节

注册

原版

新流程

主流程

余下注册后获取配置/心跳等简约情况

三方组件上报

https://10.1.2.8/confluence/pages/viewpage.action?pageId=114229353

全量上报: 发现md5变了,或者此次上报缺失了就成了自动修复了, 成就了修复的逻辑了
非全量上报: Agent什么时候搜集到就什么时候上报
通过AgentId获取语言
通过AgentId获取应用AppId
通过AgentId获取版本Id
根据语言获取处理类
isNew判定是否第一次上传还是覆盖上传
获取最近一次,非当前Agent上传的三方组件信息: 对比应用维度之前的三方组件信息
遍历上传的三方组件信息doHandler
- 生成三方组件BuildAssemlby
- 处理三方组件的插入和更新 doHandlerDb

每次来每次改

已发现->已修复->再次发现->已修复

tb_library 导入的检测库应对的各类版本
tb_assembly_hole 组件漏洞库
tc_assembly_hole_cve\tc_assembly_hole_cnvd\tc_assembly_hole_cnnvd 漏洞详情

潜在的问题

批量的改/增, 会有大量的锁

我需要你再给我

自动修复
逻辑要不要变

代码片段

AssemblyHandler代码片段

问题代码

AssmblyService里面查询各个组件应用版本,效率特别慢

痛点数据
//检测漏洞
detectVulne(1, “检测漏洞数据”), — 可无
//攻击
defendVulne(2, “攻击数据”), — 重点
//流量
flow(3, “流量数据”), — 重点
//agent请求量
agentClick(4, “请求量数据”), — 重点
//心跳
heartbeat(5, “心跳脉冲”), — 重点
//报文
response(6, “报文信息”), — 可无
//状态
status(7, “异常信息”), — 发错误码
//配置反馈
feedback(8, “配置反馈”), — Hook点
//系统信息 b
systemInfo(9, “系统信息”),
//框架信息 k
frameInfo(10, “框架信息”),
//升级反馈 y
promotion(11, “升级反馈”),
//hook 信息 e
hookInfo(12, “hook信息”),
//三方组件 d
thirdInfo(13, “三方组件信息”),
//api l
apiInfo(14, “api信息”),
//主动验证 j
verify(15, “主动验证”),
//自动版本管理 r
authVersion(16, “自动版本管理”),
//流量重放响应内容 w
replyResponse(17, “流量重放响应”),
//日志收集 n
uploadLog(18, “日志收集”),
//上报漏洞存在标志 n
vulnSing(19, “上报漏洞存在标志”),
//流量重放下发消息
replyInfo(20, “流量重放下发消息”),
//hook点信息返回
hookInfoBack(21, “hook点信息反馈”),
//熔断状态点信息
fuseState(22, “熔断状态上报”),
// 诊断功能上报下发
diagnosisConfig(23, “诊断功能上报和下发”),
// 安全插件管理
securityPluginManager(24, “安全插件管理”),
// 3.8版本新增的漏洞上报接口
holeUpload(25, “3.8版本新增的漏洞上报接口”),
// 3.8版本新增的日志收集上报
newLogCollect(26, “3.8版本新增的日志收集上报”),
// 安全函数自动检测发现上报
securityFunctionDetect(27, “安全函数自动检测发现上报”),

原版

数据流入端

三方组件流入

许可&漏洞库更新

数据展示端

三方组件列表

三方组件其余查询

新版

数据流入端

三方组件流入 - 通道

三方组件流入 - 处理

Load（仅对 Linux/Unix-like 机器生效）：当系统 load1 超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps minRt 计算得出。设定参考值一般是 CPU cores 2.5。
CPU usage（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0）。
RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

Api发现

先搜Path后搜方法, 查询会友好
Api覆盖率有总和(但是去重), 应用维度覆盖率(Api发现那边服务器)，应用内部覆盖率(内部指的是应用维度)
Api发现里面的ServerName: 服务器名称+服务器版本号
目录树是按层级进行获取,未来修正: 通过parentId获取底下二次层级数据
每个接口的Url, 单独获取, 通过Method又可以获取漏洞/应用版本/检测时间
泛化的概念

表结构

tb_url_find_load
load:节点的描述
type: 类型
clickable: 是否是叶子节点
directory_type: 是否目录,叶子节点等
method: GET/POST
template: 全路径Url

tb_url_find_load_version
header
paremeter
应用版本
path路径
方法签名
最后检测时间

Core 查询Api情况
鉴权的Api:rejectionWithInfo

getOverviewMerge 获取覆盖率
UrlFindApi#getAppTreeRootMerge 获取根目录
子sql的计算可能没有必要算一些没有用到的字段,可以忽略
UrlFindApi#getAppTreeLeaf
获取叶子节点
UrlFind遍历叶子节点和非叶子节点可以通过clickable/directory, 但是他for循环每次都去查了
apiFuse: 熔断-由当前Api带来的熔断限额, 所以要在当前Api上要标识出来熔断的情况
目录节点 + 叶子节点两大部分进行返回
array_agg无法distinct去重

点击叶子节点获取ApiInfo-getApiInfo + 点击Method获取ApiInfo-getMethodInfo

没有代码全路径签名signature,默认给Method放进去

Proxy Api上报

ApiInfoHandler
Api上报(主要),流量上报(补充),漏洞上报(补充), 同一份数据批量的改只是为了改最近检测时间、当前漏洞检测状态、当前Api覆盖情况

14号接口:Api信息上报

pathList: 路径一直都是一个,但是这里是一个List
produces: 是不是和header冲突
isUsed：是不是很无语

AgentService#addUrlInfo 添加Url信息
一整个Url进行拆分路径,落多个数据,而且partentId要单独先去pgsql划分好,所以强同步

期望
存Api -> Api基本信息
存检测日志 –> 功能界面Api发现旁边的检测日志
存主动式流量相关的 –> 主动式流量

流量和漏洞处理ApiInfo的流程

流量

FlowService#addAgentUrlInfo
reportRequest需要转换到Api专有的形式
主动式流量
tsecpointIndependentMapper#insertUrlInfoList就是插入检测日志

漏洞处理
数据来源不一样的,其实底层处理也还是差不多的

原版

数据流入端

Api上报最主要的入口:ApiInfoHandler
流量上报: 主要做覆盖,以及会做Api补充
漏洞上报: 主要做覆盖,以及会做Api补充

Api上报处理器

流量上报

漏洞上报

数据展示端

Api列表树结构查询

Api覆盖率其余查询

新版

数据流入端

Api流入

存Api -> Api基本信息
存检测日志 –> 功能界面Api发现旁边的检测日志
存主动式流量相关的 –> 主动式流量

Api流入- 通道

Api数据-流入业务通道

Api流入- 处理

存Api -> Api基本信息
存检测日志 –> 功能界面Api发现旁边的检测日志
存主动式流量相关的 –> 主动式流量

数据优先级敲定?
数据协议通道标识优先级

Rpc数据包过大?

Nginx配大小,防止打爆下游
Gateway接一下,发现过大,报警数据量大–>职能服务

高优先级数据

日志搜集
重放
复测接口
命令下发: 主动命令搜集三方组件/搜集Api发现
命令下发搜集上来的数据

检测日志50/100限额

Api整理

漏洞上报

数据结构

tp_app_hole: 漏洞主表
tp_app_hole_log: 检测记录
tb_hole_share: 漏洞分享模块
tb_app_hole_sub:漏洞描述/总览/调用栈: 用在导出报表侧
tb_holedetail: 漏洞细节->概述->细节: 页面上的堆栈信息
tb_holedetail_overview: 漏洞细节->概述
tb_app_hole_log_link: 全链路的记录
tb_app_hole_http: 漏洞细节->请求信息

漏洞来源

tb_hole_template: 漏洞模板: 展示在漏洞概述->模板
tb_hole_type: 漏洞类型
tb_hole_type_language: 漏洞语言/ 安全代码描述|不安全代码描述|引用连接
tb_hole_deduplication: 后端漏洞聚合

其他

tb_hole_reply_http: 重放:记录下发的重放记录
tb_security_policy: 安全控制
tb_agent_delete: 删除,只是蒋数据放到这张表代表删除

复测

复测在漏洞列表页, 批量选择漏洞, 选择服务器, 进行流量重放下发

原流程

检测数量直查
细微操作
- 排除规则
- 安全函数: 联动漏洞列表的状态[已发现]->[关闭-内部安全控制]经过安全控制函数
  隐藏的Tab
- 修复依据(经过安全控制函数)
- 验证信息(经过主动验证)

全链路

漏洞描述的模板要修正:https://192.168.2.2:27921/app/52/vuln?vulnId=58#1603

LinkUploadService

processAppHoleHttp: 处理流量信息\ 如果调用下游就报, 没有下游调用且没有漏洞就进过滤规则
processAppDistributeNode: 处理漏洞信息\ appHoleHttp直接进库
- 中间节点: 我有父、也有子, 还有自身
- 尾部节点&头节点: 我有自身和尾/头部节点
uploadHoleLinke: 定时三十秒进行组织全链路漏洞处理、批量的修正之前写入的数据

span:节点信息
ObjectMode:参数对象模型

AppHoleLogLink:每个数据节点内部内容

数据流入端

HoleInfo{
	AppHole;
	AppHoleLog;
	Language;	
}

HoleUploadService#mainLogic

processEntity 转换DTO
- getPackage获取包名(自己/第三方)
- 获取Agent和缓存的配置信息: 单模块缓存, 拿数据后放缓存
- 遍历reportList组装singleVulnInfo
  - 225的漏洞强关
  - 组装包
  - vulnerabilityPlugin: 拿漏洞类型
  - 设定模板
  - 设置去重规则
  - 调用模板生成generateHoleInfo
    - generateAppHoleLog:实现点(HttpSpotHole污点跟踪),Description尽量少用JSONText去模板化处理
      - HttpSpotHole(各个子类设定死templateId,根据不同的处理类运用不同的template)
        
        【generateAppHoleLog】 HoleBase实现
        
        【generateAppHoleDetail】
        
        HoleDetailInfo: 生成漏洞细节
        
        HoleDetailOverView: 漏洞阶段&语言
        
        initMarkKey: 污染源片段
        
        encodeShorRange 获取片段关键, encodeName/encodeMode名称与模式
        
        getPullutionOrigin: 污染源
        
        【generateHoleHttp】: 生成漏洞细节->请求信息
    - generateAppHole:生成AppHole漏洞信息
    - generateDeduplicationKey: 去重Key生成
  - 互相关联hole和vuln
  - 去重并插入
processAppHole 存AppHole
processAppHoleSub: 处理报表
processAppHoleLog: 存检测日志
processHoleSafeControl: 处理安全控制
- 上报的reportList->Phase: Rule阶段(isSec是否经过安全控制函数)\n在外层state=1的情况下内部isSec是经过安全控制
- 经过安全控制, 状态变为【关闭-内部安全控制】/【系统自动修复】
- 模糊/模式匹配, 除方法名,其他都可以模糊化匹配
processHoleVersion: 漏洞版本 tb_hole_version
processAppHoleFlow: 处理流量
processUrlInfo: 检测日志【新流程砍掉】
processAppHoleDetail: 处理holeDetai和holeDetailOverview
asyncFuture: 异步通知新发现的漏洞
删除检测日志: 定时删除漏洞检测记录信息

重复利用/所有漏洞检测记录归一化

问题

流量和漏洞对应关系(一个流量对应一份漏洞)

url的decode问题(各处decode)

标星:保留4~5条

改进项

重复利用/所有漏洞检测记录归一化

数据展示端

漏洞列表

筛选条件有联动效果

listFilterName: 查询过滤名称
- 内部带有commonPermission公共权限

漏洞列表查询

列表查询部分的表可以冗余字段\可以删减字段

/api/app-hole 漏洞列表

漏洞详情

meshmap

图表的数据

overview

漏洞细节->右侧大流程

hole-detail

漏洞细节->右侧内容细节

app-hole

漏洞->属性,基本的漏洞数据

app-hole/assigned

漏洞处理状态

app-hole/harm

危害描述

app-hole-log

检测记录

httpId迁出请求信息

hole-type

修复建议/合规信息

新流程

漏洞流入

漏洞流入- 通道

漏洞流入 - 处理

漏洞流入 - 存储

类图

原先AppHole以及AppHoleLog存在的查询太多太散列,可以开始归拢起来
归拢规则参考

定义公共取数据:list列表/page分页/get单个/count计数
定义公共写数据:save写入(插入+修改)/delete删除
查询尽量归一填充大的QueryDTO: 让QueryDTO覆盖很多查询条件, Repository底下的各个List/page/get/count入参QueryDTO可以填充各种查询条件及排序条件, 满足单一Mehtod的多样化查询
返回数据如果不符合,非必要就不开新接口
- 比如我只想要聚合结果集, 聚合底下的某几个count数量,但是返回一堆的BaseInfo信息需要利用代码级别Lambda进行groupBy(可能的确会浪费Jvm内存,但是只要数据量可控且不是热点查询尽量少起头写GroupBySql【全在数据库做GroupBy,数据库单点问题凸显出来, 但是Jvm机器是可以水平扩展的】)
- 又比如我想要多个数据一起聚合的结果, 衡量代码里面写还是直接Sql groupBy还是看数据量可控且不是热点数据尽量代码里面做groupBy

流程图

数据展示端

数据展示流程

数据存储-查询

Rasp

表结构

tb_rasp_attack_event: 攻击事件表
tb_rasp_attack_event_detail: 攻击事件详情表
tb_rasp_attack_log: 攻击日志表
tb_rasp_hole_type: 攻击漏洞类别
tb_rasp_plugin: 系统管理中心->插件管理
tb_rasp_plugin_algorithm: 插件算法: Js脚本算法
tb_rasp_plugin_attribute: 插件算法属性:策略管理-防护规则-Rasp算法规则的属性

数据流入流程

注册的时候会拿取Rasp配置

再去拿防护许可

开启防护后拦截住了进行上报
Rasp的攻击日志-执行数据和内部是不一样的字段和取法,其实是一致的

流量做成一份, Rasp和Iast:归一

AttackHandler#handle

tb_rasp_vlun_tmp: 一来就插临时表
raspLog: 解析临时数据
- addAttackLog: 插入攻击日志
  - 领取raspType:漏洞类型
  - 开始解析raspEvent
    - 当前ip下30分钟内的攻击事件聚合
    - 插入/更新 tb_rasp_attack_event/tb_rasp_attack_event_detail 事件及详情
raspHttp: 解析Http: 请求信息
- tb_rasp_hole_http
raspLogDetail: tb_rasp_log_detail: 攻击详情
raspLogSave: tb_rasp_attack_log:

事件管理

模板规则: 它和全局的区别在于它不能编辑小组,且不影响之前建立的小组规则,它会影响所有新建小组
事件的类型 –> ActionEnum或者–>EventEnum
全局规则: 全局可以编辑小组, 且影响之前建立的小组规则
小组规则

tb_notification_rule【时间触发规则】

事件规则名称
事件
事件触发条件->事件、应用、漏洞验证、危害等级、检测规则
动作
动作触发条件 ->发邮件还是创建Jira任务 ActionEnum

SeenFirstVulnPollEmailActionExecutor
notification:vuln 漏洞
jms->MessageEnum

VulnerabilityConsumer 漏洞消费器
matchEventOptions –> 事件过滤
matchActionOptions –> 动作过滤

定时器走法
NotificationTask -> task()

报表管理

报表导出流程

报告列表->全局

应用漏洞->漏洞详情->下载【Exce报告】 –> /api/app-hole/export

详细报告,概要报告, 这两个基本的模板

模板不满足可以自己进行模板建设
自定义模块里面有模块

模块就是代码的处理块
单独的可以导出的

表结构

tb_report_template_module 报表模板模块拆分表 —> 模块
tb_report_template_configuration 报表模板自定义配置
tb_report_record 生产的报表记录

点击生成报告->点击模板->选择应用
生成报告
后端异步去做报告

有Bug一直在正在生成
前端一直在刷拿到【报告】的【最新状态】

ReportService#export真正的导出口子
内部会有mergeReport合并报告的操作
以版本进行遍历

template.buildWord真正具体的内容实施点

一阶段任务情况精确里程碑120人日
目前推进deadline 120人力日/5个人 = 24个工作日满打满算年前不请假,客户支持不多的情况正好可以到1月20日

基建设施建设 (沈) 【总体完成】【7人力日】

Jenkins CI/CD建设(沈)
Harbor仓库建设(沈)
Kafka建设(沈)
Mongodb建设(沈)
Pgsql建设(沈)
Nacos建设(沈)

Gateway建设(桑、沈) 【部分完成】【35人力日】

Api接口搜集(桑)
Api列表(桑)
Api编辑及ApiDefine定义(桑)
Api接口测试(沈)
错误码及错误子码(桑)
Api文档搜集(沈)
Api文档列表(桑)
Api文档详情查阅(桑)
Pipeline-下游Call接入Dubbo及Kafka(桑)
Pipeline-区分数据质量等级(桑)
Pipeline-$UserId注入(沈) ######## 完成
gRPc-数据下行DubboCall(沈)
gRpc-数据上行配置Push(沈)
gRpc-维护心跳(沈)
WebSocket-数据下行DubboCall(桑) ######## 完成百分之82%
WebSocket-数据上行配置Push(桑)
WebSocket-维护Nacos心跳(桑)

数据服务建设-三方组件(张汇龙) 【刚开始】【17人力日】

三方组件列表
三方组件列表-查询条件
三方组件列表-图表
三方组件列表-汇总信息
三方组件列表-指派信息
三方组件列表-评论信息
三方组件列表-状态信息
三方组件列表-漏洞标准
三方组件列表-检测日志
三方组件漏洞库升级-升级状态
三方组件漏洞库升级-在线升级配置查询
三方组件漏洞库升级-在线升级配置更改保存
三方组件漏洞库升级-是否自动升级
三方组件漏洞库升级-升级进度查询
三方组件漏洞库升级-升级时间查询
三方组件漏洞库升级-最后一次更新状态
三方组件-数据流入
三方组件-漏洞库升级-上传升级包
三方组件-漏洞库升级-在线升级

数据服务建设-Api(蔡博瀚) 【刚开始】【13人力日】

Api处理-写入流程
Api处理-Api列表树结构查询
Api处理-覆盖率查询
Api处理-Http流量存档

数据服务建设-安全威胁(曹高俊) 【刚开始】【6人力日】

安全威胁-攻击事件列表
安全威胁-攻击日志列表
安全威胁-攻击事件详情
安全威胁-攻击日志详情
安全威胁-攻击写入

数据服务建设-漏洞核心(黄老师带队+曹+蔡)【未开始】【19人力日】

漏洞上报-基础漏洞上报
漏洞上报-全链路漏洞上报
漏洞展示-漏洞列表
漏洞展示-漏洞详情
漏洞展示-漏洞检测日志列表
漏洞展示-漏洞检测日志详情
漏洞展示-漏洞检测日志-细节概要
漏洞展示-漏洞检测日志-细节详情
漏洞展示-部分图表支持
漏洞展示-漏洞描述-节点流程图
漏洞操作-安全控制
漏洞操作-评论信息
漏洞操作-指派信息
漏洞操作-状态信息

应用服务建设-应用模块(黄老师带队+桑)【未开始】【14人力日】

应用创建
应用列表-查询
应用列表-设置应用
应用列表-删除
Agent-注册
Agent-探活
DaemonAgent-注册
DaemonAgent-探活

职能服务建设-用户授权(桑)【未开始】【2人力日】

登录中心-Login授权Token
登录中心-找回密码

SecpointJava调整-【未开始】【7人力日】