Salt Vulnerabilities Response for RSA NetWitness Platform 11.3.x

[#1]

Article Number

000001157

Applies To

RSA Product Set: NetWitness Platform
RSA Product/Service Type: NetWitness Admin
RSA Version/Condition: 11.3.x
Platform: CentOS 7

Issue

This document outlines the recommendation for remedying salt vulnerabilities CVE-2020-11651 and CVE-2020-11652 by limiting network access to salt on the NwAdmin server. 

Resolution

This knowledge base article describes how to modify the iptables rules to restrict network access to the salt-master from any non-RSA NetWitness Platform servers. The steps that are provided below are general recommendations for addressing this issue. This article contains an automated and manual process for restricting access. It is suggested to use the automated process, if issues are encountered with the process then the manual steps may be required.

Note: The permanent fix for this issue is in RSA NetWitness Platform 11.4.1.1 and above. RSA suggests upgrading to a fixed version as soon as possible.

Automated Procedure

The following steps are meant to be running on the NW Admin host only.

The following procedure requires the use of custom firewall rules on the NW Admin server. If custom firewall rules are not enabled, follow the steps in How to add custom firewall rules after nwsetup-tui has completed in RSA NetWitness Logs & Network 11.x before continuing.

1. Download the salt_vulnerability_fix.zip from this document.
2. SCP the .zip file to the NW Admin server and place it in the /root directory.
3. SSH to the NW Admin server and go to the /root partition and extract the file. Two files are produced, a Read_Me.txt and salt_vulnerability_fix.sh.

unzip salt_vulnerability_fix.zip

4. Run the salt_vulnerability_fix.sh script.

# ./salt_vulnerability_fix.sh

5. A confirmation appears, press Y to continue running the script.

If the script has already been run once it will not run again. Forcing the script to run multiple times can lead to duplicate iptables firewall entries. If attempting to add hosts after the script has already run, perform the Manual Procedure later in this document for the new host.

6. The script determines the other hosts that are attached to the NW Admin server and attempts to create the required iptables. A backup of the current iptables is created in /etc/sysconfig/iptables.backup<MMDDYYYY> should the original rules need to be reapplied.
7. If the script fails for any reason, see the script log at /var/log/netwitness/salt_vulnerability_fix.log for errors. If opening an RSA NetWitness Support case, ensure this log is attached.
8. If the script does not finish, the Manual Procedure below may be required to fully secure the NW Admin server.
9. Verify that the iptables rules are loaded and saved correctly with the following commands:

   
   iptables -L 
   less /etc/sysconfig/iptables

10. Once the NW Admin server is upgraded above 11.4.1.1, the steps in the Reverting Workaround After Upgrade section must be performed, unless custom firewall rules were already in use before running the script from this article.

Manual Procedure

The following steps are meant to be run on the NW Admin host only.

The following procedure requires the use of custom firewall rules on the NW Admin server. If custom firewall rules are not enabled, follow the steps in How to add custom firewall rules after nwsetup-tui has completed in RSA NetWitness Logs & Network 11.x before continuing.

1. Make a backup of the current iptables configuration on the NW Admin server:

cp /etc/sysconfig/iptables /etc/sysconfig/iptables.backup

2. The line number for the entry must be determined in order to remove the existing salt rule from iptables:

iptables --line-numbers -L | grep '4505\|4506'

Example output:

[root@NWAPPLIANCE15816 ~]# iptables --line-numbers -L | grep '4505\|4506'
4 ACCEPT tcp -- anywhere anywhere tcp multiport dports 4505,4506 /* salt master ports */

Note: If no output is returned, ensure that the command is run on the NW Admin server and that the iptables service is running.

3. Using the line number from the previous command, in the example above its 4, run the following command to remove the current salt firewall rule.

iptables -D INPUT <line number>

For example:

iptables -D INPUT 4

4. The salt-master process can be restricted in two different ways using iptables, individual IP address or by subnets. Customers with large deployments that do not want a large iptables rule set may explore using the subnet option over the individual IP addresses.

Option A - Single IPs

Run the following command on the NW Admin server to add each RSA NetWitness Platform host in the environment. Use the exact same line number from the iptables output provided earlier for every iptables rule entry. This allows the customized rules to "stick" together where the old rule existed within iptables.

iptables -I INPUT <line number> -p tcp -s <IP Address> --match multiport --dport 4505,4506 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

For example:

iptables -I INPUT 4 -p tcp -s 10.10.10.12 --match multiport --dport 4505,4506 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

 

Note: If the host is using NAT, use the NAT IP address not the host's IP address in the command above.

Option B - Subnets

Run the following command on the NW Admin server to add each subnet that contains the RSA NetWitness Platform hosts in the environment. Use the exact same line number from the iptables output provided earlier for every iptables rule entry. This allows the customized rules to "stick" together where the old rule existed within iptables.

iptables -I INPUT <line number> -p tcp -s <CIDR Subnet IP> --match multiport --dport 4505,4506 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

For example:

iptables -I INPUT 4 -p tcp -s 10.10.10.0/24 --match multiport --dport 4505,4506 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Note: If the host is using NAT, use the CIDR NAT subnet IP address, not the host's actual CIDR subnet IP address in the command above.

5. Save the newly changed iptables.

service iptables save

6. Verify that the iptables rules are loaded and saved correctly with the following commands:

iptables -L
less /etc/sysconfig/iptables

 

Adding New Appliances Post Workaround

If a new appliance must be added to the RSA NetWitness Platform environment while this workaround is active, use the steps above to open the required firewall hole on the NwAdmin server. This must be performed before the new appliance is added to the RSA NetWitness Platform environment, otherwise, the orchestration process fails.

Reverting Workaround After Upgrade

The changes in this workaround cause the RSA NetWitness Platform to no longer control the firewall rules on the NW Admin server. This means that any automated rule changes that RSA makes in the future are not reflected on the NW Admin server. This workaround should be reverted to RSA NetWitness Platform control (unless your situation dictates otherwise) once upgraded to RSA NetWitness Platform 11.4.1.1 or later. To revert the control of iptables back to the RSA NetWitness Platform once upgraded to 11.4.1.1 or later, follow these steps.

1. Review How to add custom firewall rules after nwsetup-tui has completed in RSA NetWitness Logs & Network 11.x and follow the instructions on the NwAdmin server, but change the custom-firewall from true to false.
2. Once done with the previous knowledge base article, run the following command on the NW Admin server.

orchestration-cli-client --update-admin-node