|
The issue, in this case, the study discusses a UDP port is open as per outside pen test and nmap scan with the use of 'nmap -p [port number] -Pn -sU -sV -sC [IP]' and 'diagnose sys udpsock'. The related configuration on the FortiGate is given below, according to which the FortiGate should block SNMP port:
chen-esx02 # show | grep -f SNMP
config firewall service custom
edit "SNMP" <---
set category "Network Services"
set tcp-portrange 161-162
set udp-portrange 161-162
next
end
config firewall local-in-policy
edit 1
set uuid 3e68f392-d809-51ef-fbb0-b8a554c07cf9
set intf "any"
set srcaddr "all"
set dstaddr "all"
set service "SNMP" <---
set schedule "always"
next
end
As per the pen test and the test from nmap with the command below, the FortiGate appears to have the UDP port 161 open. In addition to these test results, the FortiGate output shows the same port being open:
chen-esx02 # diagnose sys udpsock | grep 161
0.0.0.0:161->0.0.0.0:0 state= txq=0 rxq=0 uid=0 inode=11348 process=2645/snmpd
This result is a combination of special circumstances. As per the engineering team investigation:
'Nmap UDP scan open' result can be misleading because, unlike TCP, UDP often does not send a response even when a port is open, making it difficult to distinguish between an open port and a filtered port that simply drops the packet, potentially reporting a port as 'open' when it might actually be blocked by a firewall; this is a common issue with UDP scans and is considered one of the main reasons why UDP scanning is less reliable than TCP scanning.
As a result of the SNMP daemon being up, the port remains open, even though the configuration is blocking it and it is not responding to this traffic, which can be confirmed with the sniffer and the debug flow.
The sniffer does not reply to the scan:
chen-esx02 # diagnose sniffer packet any "port 161" 4
Using Original Sniffing Mode
interfaces=[any]
filters=[port 161]
2.304328 port1 in 172.26.158.29.54986 -> 10.109.22.35.161: udp 14
2.752435 port1 in 172.26.158.29.55008 -> 10.109.22.35.161: udp 113
7.756717 port1 in 172.26.158.29.55719 -> 10.109.22.35.161: udp 61
12.762054 port1 in 172.26.158.29.54180 -> 10.109.22.35.161: udp 64
17.769485 port1 in 172.26.158.29.63986 -> 10.109.22.35.161: udp 67
And the debug flow confirms that this traffic is being blocked:
chen-esx02 # 2025-01-21 16:30:41 id=65308 trace_id=3 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=17, 172.26.158.29:61934->10.109.22.35:161) tun_id
=0.0.0.0 from port1. "
2025-01-21 16:30:41 id=65308 trace_id=3 func=init_ip_session_common line=6047 msg="allocate a new session-00001ef6"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_dnat_check line=5281 msg="in-[port1], out-[]"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_dnat_tree_check line=824 msg="len=0"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_dnat_check line=5293 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_access_proxy_check line=439 msg="in-[port1], out-[], skb_flags-02000000, vid-0"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check line=2281 msg="gnum-100017, check-00000000be26f26a"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_policy_group_check line=4703 msg="after check: ret-no-match, act-accept, flag-00000000, flag2-00000000"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_in_check line=472 msg="in-[port1], out-[], skb_flags-02000000, vid-0"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check line=2281 msg="gnum-100011, check-000000009ed12b69"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_policy_group_check line=4703 msg="after check: ret-no-match, act-drop, flag-00000000, flag2-00000000"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check line=2281 msg="gnum-100001, check-00000000be26f26a"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check_one_policy line=2033 msg="checked gnum-100001 policy-1, ret-matched, act-accept"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_user_identity_check line=1807 msg="ret-matched"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check_one_policy line=2251 msg="policy-1 is matched, act-drop"
2025-01-21 16:30:41 id=65308 trace_id=3 func=__iprope_check line=2298 msg="gnum-100001 check result: ret-matched, act-drop, flag-08010000, flag2-00000000"
2025-01-21 16:30:41 id=65308 trace_id=3 func=iprope_policy_group_check line=4703 msg="after check: ret-matched, act-drop, flag-08010000, flag2-00000000"
2025-01-21 16:30:41 id=65308 trace_id=3 func=fw_local_in_handler line=615 msg="iprope_in_check() check failed on policy 1, drop"
Therefore, the port is open turns out to be a 'false positive'. Blocking the traffic by configuring an appropriate local-in policy and disabling SNMP from the interface remains the correct way to block this traffic.
|
