Files

2025-09-14 22:27:11 +00:00

11 KiB

Raw Permalink Blame History

【M22项目】Security Policy在限定了source ip的情况下安全日志出现其他client ip

ID	Creation Date	Assignee	Status
OMPUB-1343	2024-06-27T16:06:33.000+0800	杨威	已关闭

M22现场下发一条策略：“Lantern_vpn_ test”，策略详情如图：

!image-2024-06-27-14-27-05-083.png|width=422,height=218!

!image-2024-06-27-14-27-42-813.png|width=425,height=272!

策略于2024-06-27 09:52:24已经限定Source IP Address，但是在查询Security Events（2024-06-27 10:33:26 to 2024-06-27 10:45:53）日志的时候发现，日志展示的client ip出现一些除了Source IP Address条件限定外的IP Address，如图：

!image-2024-06-27-16-12-30-071.png|width=560,height=293!

在此期间除了客户修改了策略条件外，无其他操作，修改前后策略对比：

!image-2024-06-27-16-13-02-214.png|width=267,height=403!

!image-2024-06-27-14-33-12-912.png|width=261,height=393!

zhengchao commented on 2024-06-27T20:10:47.778+0800:

[~liuchang] 写个maat的单测复现一下，用maat_cmd_set_line接口构造：

session属性： src IP_X -> dst IP

测试流程：

规则 rule1: src IP_Y & dst IP

maat_scan(session.src_ip_Y), maat_scan(session.dst_Ip)

EXPECT 不命中

新建规则 app1（compile）: dst IP

修改rule1 : src IP_Y & app1

reset maat_state

maat_scan(session.src_ip_X), maat_scan(session.dst_Ip)

EXPECT不命中

yangwei commented on 2024-06-27T20:22:39.849+0800:

用户操作

根据audit log，{}10:33~10:52{}之间，对应策略存在如下修改操作：

!image-2024-06-28-17-24-50-136.png|width=247,height=560!!image-2024-06-28-17-25-00-177.png|width=277,height=565!

v12 策略条件 source IP + destination IP
v13 策略条件从source IP + destination IP，变更为source IP + APPID
v14 策略失效
v15 策略生效
v16 策略失效
v17 策略生效

异常日志

从现场导出Security Event Log，查询条件为“reveive time：10:34-10:52， start time 10:31-10:33” 共计13752条日志，其中ClientIP非策略条件中的11555条（{}异常日志{}） ** 异常命中的会话，会话持续时间普遍超过60s，少量会话持续时间较短（<10s） ** 92台Sled均出现异常日志
按sled_ip==10.161.12.10过滤，异常命中会话出现的end time（策略条件为Deny，该时间通常为命中策略的时刻）时段为{}10:33:28~10:46:27{}，对应maat的日志[^firewall.cm.maat.2024-06-27]

功能端日志

查询10.161.12.10设备的maat规则更新日志，10:33:28~~10:46:27之间，存在6次增量，每次加载的entries在3~~6条之间 ** 10:41:39的增量加载后，SECURITY_COMPILE_PLUGIN的rule_count从130变更为129 ** 10:41:52的增量加载后，又从129变回130

!image-2024-06-27-20-07-09-538.png|width=875,height=298!

根据现场收集的信息，本issue中的误命中，发生时段为用户界面多次修改策略的过程。推测在该过程中，功能端执行策略时，策略条件退化为APPID。

liuchang commented on 2024-06-28T14:19:29.899+0800:

maat单测用例未复现，测试流程：

session属性： src IP 45.112.178.18 -> dst IP 2.2.2.2

规则 rule1: src IP 103.89.49.6 & dst IP 2.2.2.2

maat_scan_ipv4("45.112.178.18"), maat_scan_ipv4("2.2.2.2")

EXPECT 不命中，{}实际不命中{}

新建规则 app1（compile）: dst IP{}（只新建了app_id表的一个group）{}

修改rule1 : src 103.89.49.6 & app1（group）

reset maat_state

maat_scan_ipv4("45.112.178.18"), maat_scan_group(app1.group_id)

EXPECT不命中，{}实际不命中{}

zhangwei commented on 2024-06-28T15:49:08.038+0800:

在信息港44.3环境模拟现场操作情况，操作一条生效的，ID为212的安全策略：

修改策略条件：修改前条件source+destination，修改后条件source+application，产生如下图的MAA_UPDATE_STATUS，修改操作每个表的每个操作版本号+1（删除+1，新增+1），下图涉及两张表，所以本次修改操作，MAAT_VERSION+4

!image-2024-06-28-15-41-40-712.png!

停用策略，MAAT_VERSION+2（两张表）

!image-2024-06-28-15-41-10-125.png!

启用策略：MAAT_VERSION+2（两张表）

!image-2024-06-28-15-46-16-611.png!

liuchang commented on 2024-06-28T16:05:01.646+0800:

补充测试：MAAT单测中模拟CM的行为操作策略，修改策略条件和启停策略，未复现bug

liuxueli commented on 2024-06-28T20:57:38.863+0800:

京版网关环境稳定复现本BUG，误命中的持续时间约4分钟 ** 策略ID=5211 2024-06-28 20:03:39~20:07:33存在误命中
京版网关环境复现步骤： ** 创建策略条件：Source IP+Destination IP, 生效策略

{code:java} [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.dip]# cat MONITOR_COMPILE.00000000000000086731 | grep 5211 5211 11 1 0 2 {} {"packet_capture":{"enable":0},"traffic_mirror":{"enable":0},"vsys_id":1} 2 1 1719575997000000 0 key=5211 [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.dip]# cat GROUP_MONITOR_COMPILE_RELATION.00000000000000086731 | grep -w 5211 8758 5211 0 ATTR_SOURCE_IP 0 1 1719575997000000 0 key=9844 16328 5211 0 ATTR_DESTINATION_IP 1 1 1719575997000000 0 key=9845 [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.dip]# {code}

** 修改策略条件: Source IP+ Application, 生效策略

{code:java} [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.del.dip.add.app]# cat MONITOR_COMPILE.00000000000000086735 | grep 5211 5211 11 1 0 2 {} {"packet_capture":{"enable":0},"traffic_mirror":{"enable":0},"vsys_id":1} 2 1 1719576219000000 0 key=5211 [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.del.dip.add.app]# cat GROUP_MONITOR_COMPILE_RELATION.00000000000000086735 | grep -w 5211 16365 5211 0 ATTR_APP_ID 0 1 1719576219000000 0 key=9846 8758 5211 0 ATTR_SOURCE_IP 1 1 1719576219000000 0 key=9847 [root@tsg-traffic-engine-vsys-1-firewall-854678cd59-h42pr policy.5211.sip.del.dip.add.app]#{code}

** 从dump的策略详情可以看出，{color:#ff0000}策略修改前后ATTR_SOURCE_IP对应的cluster ID由0变更为1{color}，在这种场景下maat添加自测试用例能复现误命中问题：用例如下： *** 添加策略 **** 添加策略条件 ATTR_SOURCE_IP(1.1.1.1) cluster ID=0 **** 添加策略条件 ATTR_DESTINATION_IP(2.2.2.2) cluster ID=1 **** Scan Source IP(3.3.3.3) **** scan Destination IP (2.2.2.2) *** 修改策略 **** 删除策略条件 ATTR_SOURCE_IP cluster ID=0 **** 删除策略条件 ATTR_DESTINATION_IP cluster ID=1 **** 添加策略条件 ATTR_SOURCE_IP cluster ID=1 **** 添加策略条件 ATTR_APP_ID(group=1000) cluster ID=0 **** Scan Application(group_id=1000)

原因： ** maat扫描命中group ID后将clause ID记录在maat_state中，策略更新时clause ID发生变化时没有更新maat_state中的clause ID，故发生误命中。 *** 扫描source IP + Destination IP后配置更新（clause ID发生变化），maat_state中clause ID未更新，接着扫描Application时实际生效条件变为Destination IP + Application

gitlab commented on 2024-07-01T14:58:10.825+0800:

[刘畅|https://git.mesalab.cn/liuchang] mentioned this issue in [a merge request|https://git.mesalab.cn/tango/maat/-/merge_requests/292] of [TSG-OS / Maat|https://git.mesalab.cn/tango/maat] on branch [bugfix/should-clear-clause-id-when-reomve-group-from-clause|https://git.mesalab.cn/tango/maat/-/tree/bugfix/should-clear-clause-id-when-reomve-group-from-clause]:{quote}fix OMPUB-1343 and add a test case for this bug{quote}