Vulnerability scan against the NSX manage reports the following "UDP source port pass firewall"
Article ID: 377641
Updated On:
Products
Issue/Introduction
This is a sample report from a vulnerability scan conducted against the NSX Manager.
Threat reported:
Your firewall policy seems to allow UDP packets with a specific source port (for example, port 53) to pass through while it blocks UDP packets to the same destination ports but with a random source port. In the Result section, the service lists up to 16 such destination ports that can be reached by the UDP probes with a source port of 53. Note that in a default scan, we have only used port 53 as the source port. It is possible that the firewall also allows UDP packets with other well-known ports as source ports to go through.
Following impact is reported:
This weakness may allow a malicious remote user to bypass the firewall policy and reach UDP ports that are supposed to be protected by the firewall.
Solution:
Make sure that all your filtering rules are correct and strict enough. If they are not, change the firewall rules to filter these requests with a particular source port.
Environment
VMware NSX
Cause
This vulnerability arises due to UDP packets being permitted on port 53.
In NSX release 2.4.0, UDP port 53 rules were updated to enable DNS traffic.
However, there is no longer a requirement to allow packets through port 53.
Resolution
The issue is fixed in version, 4.2.1.
Workaround:
Here's a workaround to remove the UDP 53 port iptable rule.
Steps to remove 'UDP 53 sport' iptable rule -
1. login to manager appliance using root user
2. backup old iptable rule files -
cp -rv /etc/iptables /var/tmp/
3. find iptable rule files containing 'udp 53 sport ACCEPT' rule -
grep -r sport /etc/iptables/ | grep udp | grep 53 | grep ACCEPT
example output -
/etc/iptables/nsx-common.v6rules:-A INPUT -i eth0 -p udp -m udp --sport 53 -j ACCEPT /etc/iptables/nsx-common.v4rules:-A INPUT -i eth0 -p udp -m udp --sport 53 -j ACCEPT
If remote syslog and backup server is set on appliance then it will also list below files -
/var/tmp/iptables/nsx-saved-iptables.v4rules:-A INPUT -i eth0 -p udp -m udp --sport 53 -j ACCEPT
4. Open files listed by above command and remove line containing rule '-A INPUT -i eth0 -p udp -m udp --sport 53 -j ACCEPT'
vim /etc/iptables/nsx-common.v4rules ---> then remove rule and save file
5. run command 'grep -r sport /etc/iptables/ | grep udp | grep 53 | grep ACCEPT' again to make sure rule is not listed.
remove rule from file listed by above command
6. restart set-iptables service to load new rule files -
systemctl restart set-iptables
Rollback:
If there's any issue encountered by running above steps you can rollback the changes by following the below steps:
1. login to manager appliance using root user
2. copy backed-up iptable rules from '/var/tmp/' to '/etc/iptables'
cp -rv /var/tmp/iptables/* /etc/iptables/
3. restart set-iptables service to load new rule files -
systemctl restart set-iptables
Additional Information
Note: There are chances that though the work-around is applied, scanner reports may still detect the vulnerability.
This is because of how scanner tools test UDP connectivity on ports.
When a generic UDP packet is sent to a UDP port of a remote host, one of the following occurs:
- If the UDP port is open, the packet is accepted, no response packet is sent.
- If the UDP port is closed, an ICMP packet is sent in response with the appropriate error code such as Destination Unreachable.
Inference:
- When the NSX Manager does not send a reply, the scanner tool assumes the UDP port is open, marking it as a potential vulnerability.
- NSX Manager does not generate an ICMP error response that would typically indicate the UDP port is closed.
- Due to the lack of an error code, the scanner tool interprets the lack of response as the port being open.
- This behavior can result in a false positive report being generated by the scanner tools, as the port may actually be closed despite no explicit response.
Feedback
