|
The behavior in FortiGate v7.0.15
Firewall Policy configuration
edit 234
set uuid 4fcce3e2-e1
set srcintf "a_65"
set dstintf "WEB"
set action accept
set srcaddr "all"
set dstaddr "VIP_220.4.3.21"
set schedule "always"
set service "HTTP" "HTTPS" "8443" "PING"
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set logtraffic all
next
end
When the IPS profile is disabled in debugs:
id=20085 trace_id=1064 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-216, ret-no-match, act-accept"id=20085 trace_id=1064 func=__iprope_user_identity_check line=1814 msg="ret-matched"
id=20085 trace_id=1064 func=__iprope_check_one_policy line=2242 msg="policy-0 is matched, act-drop"
id=20085 trace_id=1064 func=iprope_fwd_check line=819 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"
id=20085 trace_id=1064 func=iprope_fwd_auth_check line=838 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"
id=20085 trace_id=1064 func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 0)"
When the IPS profile is enabled in debugs:
id=1088 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-234, ret-matched, act-accept"
id=20085 trace_id=1088 func=__iprope_user_identity_check line=1814 msg="ret-matched"
id=20085 trace_id=1088 func=__iprope_check line=2272 msg="gnum-4e20, check-ffffffffa002d760"
id=20085 trace_id=1088 func=__iprope_check_one_policy line=2025 msg="checked gnum-4e20 policy-4294967295, ret-matched, act-accept"
id=20085 trace_id=1088 func=__iprope_check_one_policy line=2242 msg="policy-4294967295 is matched, act-accept"
id=20085 trace_id=1088 func=__iprope_check line=2289 msg="gnum-4e20 check result: ret-matched, act-accept, flag-00800008, flag2-00000000"
id=20085 trace_id=1088 func=__iprope_check_one_policy line=2242 msg="policy-234 is matched, act-accept"
id=20085 trace_id=1088 func=iprope_fwd_check line=819 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-234"
id=20085 trace_id=1088 func=iprope_fwd_auth_check line=838 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-234"
id=20085 trace_id=1088 func=fw_forward_handler line=881 msg="Allowed by Policy-234: AV"
id=20085 trace_id=1088 func=av_receive line=434 msg="send to application layer"
Check IPROPE policies and there is a new entry:
policy index=234 uuid_idx=4782 action=accept
flag (8010408): redir d_r master pol_stats
flag2 (4000): resolve_sso
flag3 (b0): !sp link-local best-route
schedule(always)
cos_fwd=255 cos_rev=255
group=00100004 av=00004e20 au=00000000 split=00000000
host=2 chk_client_info=0x0 app_list=0 ips_view=1
misc=0
zone(1): 232 -> zone(1): 99
source(1): 0.0.0.0-255.255.255.255, uuid_idx=3650,
dest(1): 10.20.18.11-10.20.18.11, uuid_idx=4593,
vip(1): 9
service(1):
[6:0x0:1007/(0,65535)->(8015,8015)] flags:0 helper:auto
Workaround:
The workaround includes creating and setting a top priority deny policy to block traffic to VIP external IPs on ports 8008, 8010, and 8015, effectively stopping the leakage without affecting other services. This solution, while effective, is noted as challenging to deploy across multiple firewall clusters globally.
Solution:
Upgrade to v7.0.16.
|
