235 lines
10 KiB
Markdown
235 lines
10 KiB
Markdown
|
# bj环境统计单向流比例将近40%
|
|||
|
|
|
|||
|
|
| ID | Creation Date | Assignee | Status |
|
|||
|
|
|----|----------------|----------|--------|
|
|||
|
|
| OMPUB-1125 | 2024-01-24T17:06:36.000+0800 | 杨威 | 已解决 |
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
!image-2024-01-24-16-56-32-263.png|thumbnail!
|
|||
|
|
请[~zhangzhihan]确认bj环境接入流量是否有存在单向流的情况**zhangzhihan** commented on *2024-01-24T17:13:52.817+0800*:
|
|||
|
|
|
|||
|
|
从sapp的sysinfo.log上看，tcp没有单向流，udp有单向流但比例不高
|
|||
|
|
!screenshot-1.png|thumbnail!
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**doufenghu** commented on *2024-01-24T17:55:10.848+0800*:
|
|||
|
|
|
|||
|
|
单向流计算：(asymmetric_c2s_flows + asymmetric_s2c_flows)/closed_sessions, 选取1月24日最近一小时(16:00-17:00) 单向流比例为38.81%。需Firewall协助排查下。
|
|||
|
|
* asymmetric_c2s_flows + asymmetric_s2c_flows = 130,703
|
|||
|
|
* closed_sessioins = 336,749
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**yangwei** commented on *2024-01-24T20:44:14.964+0800*:
|
|||
|
|
|
|||
|
|
“选取1月24日最近一小时(16:00-17:00) ” 查询会话日志，共计337008条
|
|||
|
|
|
|||
|
|
!image-2024-01-24-20-31-19-292.png|width=609,height=278!
|
|||
|
|
|
|||
|
|
在这个范围内查询{*}session_record中{*}单向流(filter=“sent_pkts=0 OR received_pkts=0“), 共计130969条，可知{*}单向流比例130969/337008=38.8%，与issue描述一致{*}
|
|||
|
|
|
|||
|
|
!image-2024-01-24-20-32-30-278.png|width=1160,height=526!
|
|||
|
|
|
|||
|
|
统计单向流会话的decode as分布，99.67%为BASE，进一步增加过滤条件，仅统计单向流中BASE的IP分布，发现单向流的Client IP排名第一的为5.5.5.5，其余多为内网地址（10.xx或者192.168.xx），Server IP排名靠前的也基本为内网地址。
|
|||
|
|
|
|||
|
|
!image-2024-01-24-20-38-42-125.png|width=810,height=378!
|
|||
|
|
|
|||
|
|
!image-2024-01-24-20-41-06-328.png|width=814,height=373!
|
|||
|
|
|
|||
|
|
结论：通过查询会话日志，1月24日(16:00-17:00) {*}网关流量中接近40%为单向流，其中99%为UDP会话{*}，且通信的双方大部分为内网地址，{*}推测经过网关的流量存在内网地址间的测试流量{*}。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**yangwei** commented on *2024-01-25T09:58:12.184+0800*:
|
|||
|
|
|
|||
|
|
查询1月24日 23:00-24:00)的日志，共计110,232条，其中单向流49,069条，单向流比例44.5%，所有的的Decode path均为BASE。
|
|||
|
|
|
|||
|
|
!image-2024-01-25-09-29-21-037.png|width=721,height=310!
|
|||
|
|
|
|||
|
|
!image-2024-01-25-09-32-07-741.png|width=716,height=322!
|
|||
|
|
|
|||
|
|
!image-2024-01-25-09-33-40-660.png|width=713,height=406!
|
|||
|
|
|
|||
|
|
进一步分析，虽然功能端输出session_record设置需要达到的最小包数和字节数限制（目前限制为包数>3 AND 字节数>5），但是session_record中存在包数为1的记录，
|
|||
|
|
|
|||
|
|
存在该session日志的原因为，该session命中了一条Monitor_ALL的安全策略。
|
|||
|
|
|
|||
|
|
!image-2024-01-25-10-07-37-292.png|width=682,height=375!
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**yangwei** commented on *2024-01-25T10:40:01.025+0800*:
|
|||
|
|
|
|||
|
|
综合上述情况，目前Live Traffic Chart和session_record统计指标存在如下问题：
|
|||
|
|
* 问题1：session record过滤小流的限制条件，在session命中安全策略时仍然会被发送，并且在session record中能够被查询和统计，容易给用户造成困惑。
|
|||
|
|
** 方案1：不再设置过滤小流的限制条件，对所有session进行记录
|
|||
|
|
*** 优点：数据口径一致，不存在用户不可感知的隐藏参数
|
|||
|
|
*** 缺点：日志量可能增加（按照各个现场的经验，由于UDP小碎流的存在，预计日志整体增加一个数量级）
|
|||
|
|
** 方案2：界面开放给用户设置记录session record过滤小流的条件，查询session record时olap执行该条件
|
|||
|
|
*** 优点：用户可感知参数，在设置合理的前提下，能够有效减少小流的日志量
|
|||
|
|
*** 缺点：增加从界面同步的参数
|
|||
|
|
* 问题2：Live Traffic Chart的数据源，对所有的session进行统计输出（未执行session record过滤小流的限制条件），会造成Live Traffic Chart计算的单向流比例，与session record不一致（结合问题1，当前Live Traffic Chart为全量统计结果，session record记录的是过滤后的小流+命中策略的所有流）
|
|||
|
|
** 方案1：从Live Traffic Chart中展示单向流的比例目的出发，如果是向用户展示接入流量的完整性趋势，参照24.01版本之前仅根据session record计算的逻辑，Live Traffic Chart中单向流比例仅展示TCP会话相关的结果
|
|||
|
|
*** 优点：单向流比例不受UDP流干扰，更能反应流量中整体的情况
|
|||
|
|
*** 缺点：未统计所有流，与session record查询结果对比时需要增加ip protocol=tcp的过滤条件，可能增加给用户的解释成本
|
|||
|
|
** 方案2：参照问题1的方案2，功能端输出Traffic Metric时，也执行小流过滤条件，仅输出满足条件的流的统计信息
|
|||
|
|
*** 优点：数据输出口径保持一致
|
|||
|
|
*** 缺点：未对所有流进行统计，增加给用户的解释成本
|
|||
|
|
* 问题3：session record中，对于未达到满足app识别最小包数（当前值为20包）的流，功能端Application字段填充为-，在Live Traffic Chart中，Application值为-和unknown都被计算为unknown，该统计结果，与session record中的值不一致，容易给用户造成困惑。
|
|||
|
|
** 方案1：功能端对未满足app识别最小包数的流，统一标识为unknown
|
|||
|
|
*** 优点：数据口径一致
|
|||
|
|
*** 缺点：Application为unknown可以作为策略条件执行，但对于未满足最小识别包数的流，在流结束时（通常为active timeout）执行安全策略无意义，此时产生安全事件日志容易给用户造成歧义（例如deny失效）
|
|||
|
|
** 方案2：将app识别最小包数作为参数开放至界面允许用户配置，未达到最小识别包数的Application仍然被标识为-，同时Live Traffic Chart中增加-的统计行
|
|||
|
|
*** 优点：用户可感知参数，减少解释成本
|
|||
|
|
*** 缺点：当最小识别包数设置为较小的值时（例如1），安全策略不生效的歧义仍然存在
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**yangwei** commented on *2024-01-29T13:38:51.554+0800*:
|
|||
|
|
|
|||
|
|
经2024-01-29讨论，上述3个问题，对应的解决方案选择如下：
|
|||
|
|
|
|||
|
|
{*}问题1{*}：选择{*}方案2{*}，界面在是否开启session_record的开关处，{*}增加可配置记录最小包数{*}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。
|
|||
|
|
|
|||
|
|
{*}问题2{*}：{*}现有逻辑不做更改{*}。Live Traffic Chart统计的对象为全流量，session_record记录的是过滤后的流信息，两者的结果不能保证完全一致，仍然保留Live Traffic Chart记录所有流的特性
|
|||
|
|
|
|||
|
|
{*}问题3{*}：选择{*}方案1，{*}对于未满足识别长度即结束的流，统一标识为unknown，由于此时已不具备执行安全策略的条件（通常由时间触发active timeout，对应的session状态为closing），在此阶段不再执行安全策略。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**zhangwei** commented on *2024-01-31T15:57:17.319+0800*:
|
|||
|
|
|
|||
|
|
{quote}{*}问题1{*}：选择{*}方案2{*}，界面在是否开启session_record的开关处，{*}增加可配置记录最小包数{*}（仅增加一个参数，减少用户配置的负担）的限制，默认值为2；用户查询session record时，UI查询olap时，增加该限制作为过滤条件。
|
|||
|
|
{quote}
|
|||
|
|
在仍然有Management Vsys的版本中实现此功能，UI和CM在Management Vsys查询Session Records设置该限制作为过滤条件比较复杂，打破了现有CM补全Vsys过滤条件的实现逻辑。
|
|||
|
|
* 当前实现：vsys_id in (1,2,3) and ($filter)
|
|||
|
|
* 如增加最小包数限制作为过滤条件：( (vsys_id=1 and recv_pkts+sent_pkts>=$vsys1_min_packets) or (vsys_id=2 and recv_pkts+sent_pkts>=$vsys2_min_packets) or (vsys_id=3 and recv_pkts+sent_pkts>=$vsys3_min_packets) ) and ($filter)
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**doufenghu** commented on *2024-01-31T16:28:20.330+0800*:
|
|||
|
|
|
|||
|
|
[~yangwei] 界面增加min_packets阈值后，UI查询OLAP默认为什么要增加过滤条件？Session Records 还会有小于min_packets的日志？
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**yangwei** commented on *2024-01-31T16:34:39.265+0800*:
|
|||
|
|
|
|||
|
|
24.01以后，功能端生成session_record与策略日志合并，对于命中策略的会话，即使不满足min_packets的条件，依然会向session_record的topic发送该会话的信息（例如上述分析中提到的命中monitor_all策略，但仅传输1个包的情况）。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**doufenghu** commented on *2024-02-01T10:05:28.718+0800*:
|
|||
|
|
|
|||
|
|
建议命中策略并且小于min_packets的会话，查询时默认不对其增加过滤条件。目前会话日志设计上以流量为中心，以全局视角应看到所有命中策略的日志。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**gitlab** commented on *2024-02-05T18:47:12.855+0800*:
|
|||
|
|
|
|||
|
|
[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|https://git.mesalab.cn/tango/firewall/-/commit/9407dcda1f755ac66eac9ce8a9f986bd20de7cb3] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: Supports user-specified packet number limit for sending logs{quote}
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**gitlab** commented on *2024-02-05T19:07:56.344+0800*:
|
|||
|
|
|
|||
|
|
[刘学利|https://git.mesalab.cn/liuxueli] mentioned this issue in [a commit|https://git.mesalab.cn/tango/firewall/-/commit/ce64026bca82435d3f594ebe84e03378d6ab8222] of [TSG Appliance / firewall|https://git.mesalab.cn/tango/firewall] on branch [feature-tunnel-rename-encapsulation|https://git.mesalab.cn/tango/firewall/-/tree/feature-tunnel-rename-encapsulation]:{quote}TSG-18800, OMPUB-1125: session is not identified app, and unknown is filled by default.{quote}
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## Attachments
|
|||
|
|
|
|||
|
|
**50981/image-2024-01-24-16-56-32-263.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51016/image-2024-01-24-20-31-19-292.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51017/image-2024-01-24-20-32-30-278.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51018/image-2024-01-24-20-38-42-125.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51019/image-2024-01-24-20-41-06-328.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51021/image-2024-01-25-09-27-24-206.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51022/image-2024-01-25-09-27-46-507.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51023/image-2024-01-25-09-29-21-037.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51024/image-2024-01-25-09-32-07-741.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51025/image-2024-01-25-09-33-40-660.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51029/image-2024-01-25-09-54-21-743.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51033/image-2024-01-25-10-06-49-337.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51035/image-2024-01-25-10-07-17-442.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**51034/image-2024-01-25-10-07-37-292.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**50985/screenshot-1.png**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|