Perform Manual Hardening for Versa Analytics
For supported software information, click here.
This article describes the recommended manual hardening for the Versa Analytics Releases 20.2 and later. System hardening ensures that Versa Networks products are secure when running in customer networks.
Use Signed SSL Certificates
By default, Analytics nodes work with autogenerated, self-signed certificates. Production equipment must have a valid signed certificate so that devices accessing the infrastructure do not trigger certificate errors.
To enable secure mode, you must have installed all Versa Director and Analytics devices with production certificates and verified their functionality.
Note: Enabling secure mode has consequences for the procedures described in this article. It is recommended that you verify working condition of all system functions before you enable secure mode.
To generate a certificate signing request (CSR), you use the van-csr-gen.sh script. Depending on the version of Analytics software, the van-csr-gen.sh script may not be present on the Analytics node. If it is not present, upload it to the /opt/versa/scripts/van-scripts directory.
Enable SSL Certificates
- Generate a CSR by running the van-csr-gen.sh script. For example:
$ cd /opt/versa/scripts/van-scripts $ ./van-csr-gen.sh --domain analytics1.versa-networks.com \ --country US --state CA \ --organizationalunit IT --locality "San Jose" \ --email lab@versa-networks.com \ --organization Versa Networks \ --keypass versa123
- Copy the certificate to the Certificate Authority (CA) and sign it. Note that the signed certificate must be in PEM file format.
- In the versa user's home directory, create a temporary directory for the signed certificate, private key, and CA certificate, and assign the directory 700 permission:
$ mkdir certs $ chmod 700 cert
- Install the SSL certificate. Note that the private key is stored in the /var/versa/vnms/data/certs/certificate-name.key file.
$ sudo /opt/versa/scripts/van-scripts/van-import-cert.sh \ --key path-to-private-key-file \ --cert path-to-signed-certificate-file \ --keypass certificate-password \ --cafile path-to-CA-certificate-file
- Securely back up and store the certificate and private key files generated in Steps 1 and 3 to a secure location using the scp command.
- Delete the certificate and private key files generated in Steps 1 and 3 so that the private key in not left for anyone to read.
- Repeat Steps 1 through 6 for all Analytics nodes in the cluster.
Enable SSH Banners
- Create banner text in the /opt/versa/etc/banner.net file using a file editor (for example, Vi or Nano) and save the file.
- Change the file ownership to versa:versa:
$ sudo chown versa:versa /opt/versa/etc/banner.net
- Modify the SSH banner entry in the sshd_config file to use the banner.net file from Step 1:
$ sudo sed -i -e 's/#Banner.*/Banner \/opt\/versa\/etc\/banner.net/' /etc/ssh/sshd_config
- Restart the SSH service:
$ sudo service ssh restart
Update OS Security Package
To harden the Analytics security, regularly update the Analytics nodes to the latest OS security pack (OS SPack). For more information, see Use OS Security Packages.
Configure NTP
You configure the Network Time Protocol (NTP) and the timezone to use in the network so that all devices in the network operate on the same time. Time synchronization is important so that the timestamps in log files match across all devices. Also, there are cryptographic requirements for time synchronization. NTP and timezone services on the Analytics platform are provided by the Ubuntu core operating system.
To modify the NTP servers:
- Log into the Versa Analytics node.
- Edit the /etc/ntp.conf file to update the servers.
- Restart the NTP daemon:
admin@Analytics$ sudo service ntp restart
To configure system timezone:
- Identify the desired timezone. For example:
admin@Analytics$ timedatectl list-timezones | grep -i chicago America/Chicago
- Unlink the current timezone:
admin@Analytics$ sudo unlink /etc/localtime
- Reboot the Analytics node.
Configure DNS
DNS services on the Analytics platform are provided by the Ubuntu core operating system.
To configure system DNS:
- Edit the /etc/network/interfaces file as required.
- Restart the interface:
$ ifdown $ ifup
Verify the Software Version
For the best performance of all SD-WAN components, Versa Networks requires that all components run the same software version.
- To verify the software version of Versa Director or Analytics, log in to the CLI and issue the show system package-info CLI command. For example:
Administrator@analytics1> show system package-info Package Versa Analytics Software Release 16.1R2 Build S9 Release date 20190628 Package id a454c1d UI Package id 3580b52 Package name versa-analytics-20190628-150633-a454c1d-16.1R2S9 Branch 16.1R2
- To verify the software version running on VOS devices:
- In Director view, select the Administration tab in the top menu bar.
- Select Appliances in the left menu bar. The Software Version column displays the version.
Enable Centralized Authentication
For Releases 20.2.2 and later.
To enable centralized authentication (TACACS+) on Analytics nodes:
- SSH to the Analytics Node.
- Start the CLI:
$ cli
- Enter configuration mode:
> configure
- Set the authentication order to be remote first, then local:
% set system external-aaa auth-order remote-then-local
- Set the IP address of the TACACS+ server:
% set system external-aaa tacacs-plus server ip-address key key-value
- Set the functions for which you want to use the TACACS+ server. For example, to use the TACACS+ server for authentication:
% set system external-aaa tacacs-plus action authentication
To use the server for accounting:% set system external-aaa tacacs-plus action accounting
- Save the changes:
% commit
TACACS+ Server Configuration
Users logging in from the TACACS+ server can have administrative permissions or operator permissions. To configure this, the TACACS+ server return must return the following versa-user-group attributes:
- admin—Users have administrative access to the Analytics node.
- oper—Users have operator access to the Analytics node.
Enable Secure Mode
You enable secure mode to harden the Linux core OS components to meet the Linux CIS benchmarks.
Before you enable secure mode, you must enable centralized authentication. For more information, see Enable Centralized Authentication, above.
To enable secure mode:
- From the CLI, execute the secure mode script:
versa@analytics1$ cli versa@analytics1> request system secure-mode enable
For example:
versa@analytics1> request system secure-mode enable Will enable secure mode. Are you sure? [no,yes] : yes status success result Enabling Versa OS secure mode result Hardening SSH service result Hardening password scheme result Disabling USB storage result Hardening permissions on system executables result Hardening permissions on sensitive files result Hardening: Disabling FileSystem knobs result Hardening: Restricting the use of the job-scheduling privilege result Hardening: System knobs and TCP settings result Hardening console login permissions result Hardening port permissions
- Exit the CLI and restart Versa services for the changes to take effect:
versa@analytics1: $ vsh restart
- Change the Linux user passwords on the local device so that they all meet the complexity criteria.
To verify that secure mode is operating:
- Issue the request system secure-mode test brief CLI command
- Check the results in the /var/log/versa/versa-security-test-date.log file. The following is a sample of the log file contents that indicate that secure mode is operating properly:
[admin@director1: ~] $ sudo cat /var/log/versa/versa-security-test-20190411-092258.log [sudo] password for admin: [INFO] sshd config check complete - error count = 0 [INFO] login.defs config check complete - error count = 0 [INFO] pam passwd config check complete - error count = 0 [INFO] blacklist config check complete - error count = 0 [ERROR] Default password found in file (/opt/versa/scripts/strongswan/get_ipsec_params.lua) [INFO] Default password check complete - error count = 1
Change Analytics Database and Service Passwords
For Releases 22.1.4 and later.
Analytics clusters rely on internal passwords to maintain the security of their databases and services. These passwords are set during initial software installation, and you can update these passwords at any time.
Analytics clusters assign passwords for the following features:
- Analytics database—The Cassandra database for the cluster.
- Analytics search engine—The Solr search engine for the cluster.
- Database encryption key—Encryption key used by the Analytics database to encrypt sensitive information, such as keys and passwords, stored in the database.
- Versa Analytics services—Processes critical to the functioning of the cluster.
This section describes how to change Analytics database and service passwords. This section also describes how to restart Analytics services from a Director node.
Versa Analytics Services
Analytics services include processes such as the log collector exporter, which accepts and processes incoming log connections, and the Versa Analytics driver, which processes log files created by the log collector exporter and forwards log data to the database and search engine on the cluster. Each Analytics node runs instances of various services, and the instances interact with the other nodes of the cluster to perform their tasks and maintain synchronization.
To view a list of services running on an Analytics node, log into a shell on the node and issue the vsh status command.
admin@Analytics$ vsh status versa-confd is Running [*] process 23356 versa-lced is Running [*] process 23940 versa-spackmgr is Running [-] process 23516 versa-analytics-monitor is Running [*] process 23436 versa-analytics-driver is Running [*] process 23434 versa-analytics-app is Running [*] process 27050 versa-monit is Running [*] process 23451 versa-analytics-dataops is Running [*] process 23405 versa-analytics-redis is Running [-] process 23711
To restart services for all nodes in an Analytics cluster, log in to a shell on the active Director node and issue the following command:
admin@Director$ sudo ./van_cluster_installer.py --restart-van-services
Modify Database and Service Passwords
When you change the password for a feature using the commands in this section, all nodes in the cluster are updated with the new password.
To modify passwords for an Analytics cluster.
- Login to the shell on the active Director node.
- Change to the van_cluster_install directory.
admin@Director$ cd /opt/versa/vnms/scripts/van-cluster-config/van_cluster_install
- Issue the command displayed in the table to change the password for the listed feature or features:
Feature Command
(Note: By default, the script prompts you for a password. If you append the ‘--force’ option to any of the commands, the script instead assigns a random password.)
Analytics database admin@Director$ sudo ./van_cluster_installer.py --regen-analytics-db-password
Analytics database encryption key admin@Director$ sudo ./van_cluster_installer.py --regen-van-encryption-key
Analytics search engine admin@Director$ sudo ./van_cluster_installer.py --regen-search-db-password
Analytics services admin@Director$ sudo ./van_cluster_installer.py --van-svcs-password
All password types: database, search, encryption key, and analytics services admin@Director$ sudo ./van_cluster_installer.py --regen-all-password
Change Analytics Account and Tomcat Passwords
You must change the default passwords for the following predefined accounts and service on the Analytics platform:
- Shell accounts—admin, versa
- Analytics UI accounts—admin, Administrator
- Tomcat service
Change Shell Account Passwords
The default configuration for Analytics nodes includes two shell accounts: admin and versa. The default password for both accounts is versa123. To harden Analytics nodes, you must change the passwords for these accounts on every search-type and analytics-type Analytics node.
To change passwords for the versa and admin accounts:
- Login to the shell on the node.
- Issue the commands shown below.
admin@Analytics$ cd /opt/versa/scripts/van-security admin@Analytics$ sudo ./analytics_securemode.sh -s Do you want to change the shell login system password (y/N) : y Please enter username:versa versa exists... changing password. New password: new-password Retype new password: new-password passwd: password updated successfully Password is successfully changed for user: versa admin@Analytics$ sudo ./analytics_securemode.sh -s Do you want to change the shell login system password (y/N) : y Please enter username:admin admin exists... changing password. New password: new-password Retype new password: new-password passwd: password updated successfully Password is successfully changed for user: admin
Change Analytics Application UI Passwords
The default configuration for Analytics nodes includes two Analytics application accounts: admin and Administrator. To harden Analytics nodes, you must change the default passwords for these accounts on each of the analytics-type and search-type Analytics nodes. This protects the nodes from unauthorized user access, and is critical if Analytics nodes have public internet access.
If the user logs in as user Administrator to Analytics directly, and if Director is registered for authentication, then the login request is sent to Director. If Director fails, then the local database is used for authentication. If there is no Director registered, the local database is only used for authentication.
Note that you can find the default passwords in the /opt/versa/var/van-app/properties/application.properties file. You need root access to view this file.
To change the default passwords for the admin and Administrator accounts, perform the following procedure on each Analytics node:
- Login to the shell.
- Run the AdminManager.sh script, as follows:
admin@Analytics$ sudo /opt/versa/scripts/van-scripts/AdminManager.sh Versa Analytics Admin Users Manager Passwords for all local UI users need to be changed Please enter password for user:admin Password ? Re-enter password ? Please enter password for user:Administrator Password ? Re-enter password ? Login credentials for all users have been changed, please do vsh restart for change to take effect.
- Restart Analytics services.
admin@Analytics$ vsh restart
Change Tomcat Passwords
As part of Analytics hardening, you must change the Tomcat password and update certificates on each of the analytics-type and search-type Analytics nodes.
To change the Tomcat password and update certificates:
- On the Analytics node, change to the /opt/versa/scripts/van-security directory:
admin@Analytics$ cd /opt/versa/scripts/van-security
-
Run the analytics_securemode.sh script as shown below to modify the Tomcat password.
Note: When the script prompts "Do you want to change the Analytics UI local authentication administration password (y/N):", enter N if you changed the Analytics UI password in the Change the Analytics Application UI Passwords section, above. Otherwise, enter y to change the Analytics UI passwords now.
admin@Analytics$ sudo ./analytics_securemode.sh -a Info: Parsing van-security arguments Info: modify-application-password Do you want to change the Analytics UI local authentication administration password (y/N): N Do you want to change the SSL and Tomcat Certificate passwords (y/N): y Modifying Tomcat passwords ... Change the Tomcat Password if your certificate passwords have changed Please re-confirm (y/N): y Enter NEW Password: new-password ReEnter NEW Password: new-password Modifying self-signed certificate passwords ... Modifying Analytics-Director certificate passwords ... This password should match the password in Director's vd-van-import-cert.sh file Do you want to change the Analytics-Director certificate password (y/N): y Enter NEW Password: new-password ReEnter NEW Password: new-password Please regenerate the certificates for this change to take effect Regenerate certificate file using: van-import-cert.sh script You will need to re-import certificates to Versa Director and re-register Director in Analytics To ensure Analytics-Director communication certificates are changed with non-default passwords Delete the TrustStore at: /opt/versa/var/van-app/certificates/versa_director_truststore.ts Re-import by running: /opt/versa/scripts/van-scripts/van-vd-cert-install.sh
- Delete the Analytics Java keystore file:
admin@Analytics$ sudo rm /opt/versa/var/van-app/certificates/versa_analytics.jks
- Delete the Director trust store file:
admin@Analytics$ sudo rm /opt/versa/var/van-app/certificates/versa_director_truststore.ts
- To use self-signed certificates, switch to the Director node and regenerate them (you can choose to back up the certificates):
admin@Director$ sudo rm /opt/versa/var/van-app/certificates/versa_analytics_client.* admin@Director$ sudo /opt/versa/scripts/van-scripts/van-cert-install.sh
- To use CA-signed certificates, re-import the certificates on the Analytics node:
admin@Analytics$ sudo /opt/versa/scripts/van-scripts/van-import-cert.sh \ --key path-to-private-key-file \ --cert path-to-signed-certificate-file \ --keypass certificate-password \ --cafile path-to-CA-certificate-file
- On the Director node, copy the Director certificate to the Analytics cluster:
admin@Director$ cd /var/versa/vnms/data/certs admin@Director$ scp versa_director_client.cer versa@analytics-node-ip:/opt/versa/var/van-app/certificate
- On the Analytics node, re-import the Director certificate:
admin@Analytics$ cd /opt/versa/var/van-app/certificates/ admin@Analytics$ sudo /opt/versa/scripts/van-scripts/van-vd-cert-install.sh versa_director_client.cer director-hostname
Disable Analytics UI Access (Optional)
This is an optional step you can take to prevent users from directly accessing the Analytics UI. The procedure below redirects the URL normally used to access the Analytics UI so that it accesses the Director node instead.
Caution: Once you redirect the URL, it causes any attempts to login to the Analytics UI by scripts or API calls to fail.
To disable Analytics UI access:
- Login to the shell of each of analytics-type and search-type node in the Analytics cluster.
- Issue the following command to redirect the Analytics UI URL:
admin@Analytics$ sudo /opt/versa/scripts/van-security/analytics_securemode.sh -u Info: Parsing van-security arguments Info: enable/disable url-redirection Do you want to enable/disable VAN UI URL redirection (y/N) : y Do you want to enable or disable (e/d) : e Please enter the complete director URL : https://versa-director-ip Changed the URL to https://versa-director-ip successfully
- Restart Analytics processes for the previous command to take effect.
admin@Analytics$ vsh restart
Disable Unused Kernel Modules
As part of Analytics hardening, you should disable the following unused Linux kernel modules to protect the device against the exploitation of any flaws in its implementation:
- DCCP—Datagram Congestion Control Protocol
- SCTP—Stream Control Transmission Protocol
- TDS—Tabular Data Stream protocol
- TIPC—Transparent Interprocess Communication protocol
To disable the unused kernel modules:
- Edit the /etc/modprobe.d/CIS.conf file. Note that the file may not be present on the device.
# sudo vi /etc/modprobe.d/CIS.con
- Add the following lines to the file. The /bin/true option disables the loading of the kernel module.
install dccp /bin/true install sctp /bin/true install tds /bin/true install tipc /bin/true
- Save the file.
- Check that the modules have been disabled:
# modprobe -n -v dccp install /bin/true # modprobe -n -v sctp install /bin/true # modprobe -n -v tds install /bin/true # modprobe -n -v tipc install /bin/true
Disable Promiscuous Mode
As part of Analytics hardening, you should disable promiscuous mode on the eth0, eth1, and eth2 Ethernet interfaces.
To disable promiscuous mode:
- Edit the /etc/network/interfaces file.
$ sudo vi /etc/network/interfaces
- Locate the line "iface ethx inet static", and replace x with the interface number.
- Add the line "up ip link set ethx promisc off" to the file, replacing x with the interface number.
- Save the file.
- Switch off promiscuous mode:
$ sudo ip link ethx promisc off
The following shows an example of the modified /etc/network/interfaces file for the eth1 interface:
auto eth1 iface eth1 inet static up ip link set eth1 promisc off address 192.168.0.10 netmask 255.255.255.0 mtu 1200 up route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.0.239 up route add -net 10.0.0.0 netmask 255.255.0.0 gw 192.168.0.239 up route add -net 10.1.0.0 netmask 255.255.0.0 gw 192.168.0.239 up route add -net 10.2.0.0 netmask 255.255.0.0 gw 192.168.0.239
Harden SSH
Change the SSH Port
To change the default port that the SSH daemon listens on:
- Change the default SSH port:
$ sudo sed -i ‘s/22/1022/g’ /etc/ssh/sshd_config
- Restart the SSH service:
$ sudo service ssh restart
Disable the SSH Server
As part of system hardening, you can optionally disable the SSH service on the Analytics node.
To disable the SSH server:
- Stop the SSH daemon:
$ sudo service ssh restart
- Remove the SSH daemon from the init.d directory:
$ sudo rm /etc/init.d/ssh
Harden the SSH Server Configuration
To have the SSH server on the Analytics node continue to run, set the following parameters:
- Edit the /etc/ssh/sshd_config file and replace the following values:
- ClientAliveInterval—300
- ClinetAliveCountMax—0
- Save the file.
- Restart the SSH daemon:
$ sudo service ssh restart
Disable strongSwan
To disable the strongSwan VPN on the Analytics node:
- Stop the StrongSwan service:
$ sudo service strongswan stop > /dev/null 2>&1
- Disable the service from starting when the Analytics node boots:
$ update-rc.d -f strongswan remove > /dev/null 2>&1
Perform System Upgrades
When you perform a system upgrade, for example, if you upgrade from Release 16.1R2S9 to Release 16.1R2S10, doe the following to keep the system hardened.
Before you upgrade an Analytics node:
- Back up the /opt/versa/scripts/van-scripts/van-import-cert.sh file.
- Back up the iptables rules:
$ sudo iptables-save > iptables.rules
After you upgrade an Analytics node:
- Restore the /opt/versa/scripts/van-scripts/van-import-cert.sh file.
- If you are upgrading to Release 16.1R2SX, disable port 8080, as described in Harden Port 4566.
- Reapply all the iptables rules.
- Rerun the analytics_securemode.sh –a script as described in Change the Analytics Passwords. Note that changing the Analytics UI local authentication administration password is optional.
Configure IP Packet Filtering Rules
As part of hardening, you define IP packet filter rules for the Linux kernel firewall that allows or blocks traffic to the system. When a connection attempt is made through a port on the Analytics node, the Linux IP tables (iptables) facility searches for a match in its rule set. If no matching rule is found, the default action is taken. Configure iptables rules to block access by default, and then allow access only through required systems.
Note: The iptables rules must be configured even if an external firewall is configured.
Configure iptables Rules
To configure iptables rules:
- Download the analytics_securemode.sh script to each of the Analytics nodes.
- Backup the existing script.
admin@Analytics$ cd /opt/versa/scripts/van-security admin@Analytics$ cp analytics_securemode.sh analytics_securemode.sh.bak
- Download the latest version of analytics_securemode.sh from the following location:
https://download.versa-networks.com/index.php/s/dVyHEx2tZIxNAGG - Copy the downloaded script to /opt/versa/scripts/van-security/analytics_securemode.sh.
- Backup the existing script.
- Configure iptables rules. The following table lists notable port numbers and the methods you use to configure rules for these ports.
Type of Port Access |
Traffic Direction |
Ports |
Configuration Method |
---|---|---|---|
Analytics port for REST Access |
Inbound/HTTPS |
443/8443 |
Configured automatically when you run the analytics_securemode.sh script. See Install iptables Rules Using a Script, below. You can add additional IP subnets by specifying them in a whitelist file. See Configure an iptables Whitelist File, below. |
Inter-cluster database and client communication |
Inbound/TCP |
8983, 9042, 2181 |
Configured automatically when you run the analytics_securemode.sh script. See Install iptables Rules Using a Script, below. |
REST access port configuration and diagnostics of various services running on Analytics nodes |
Inbound/TCP |
5000, 5010, 5020, 8008 |
Configured automatically when you run the analytics_securemode.sh script. See Install iptables Rules Using a Script, below. |
Log collector port where logs are received |
Inbound/TCP |
User configurable |
Configure explicitly for each of the local collector ports on each Analytics node that collects logs. For example, if a local collector is configured to listen on port 1234, issue the following iptables command. $ sudo iptables -A INPUT -p tcp -m tcp --dport 1234 -j ACCEPT |
Monitoring agent ports to retrieve health status and statistics about Analytics nodes |
Inbound/HTTP |
8010, 8020 |
If headend monitoring agents nodemon and vanmon are enabled on Analytics nodes, add iptables rules to allow traffic coming from their source IP addresses and ports. For example: $ sudo iptables -A INPUT -s <versa-monitoring-server>/32 \ -p tcp --dport 8010 -j ACCEPT $ sudo iptables -A INPUT -s <versa-monitoring-server>/32 \ -p tcp --dport 8020 -j ACCEPT $ sudo iptables -A INPUT -p tcp --dport 8010 -j REJECT $ sudo iptables -A INPUT -p tcp --dport 8020 -j REJECT |
Standard SSH |
Inbound/TCP |
22 |
Add iptables rules to allow SSH access to the nodes. It is recommended that you allow only Versa Director IP addresses. For example: $ sudo iptables -A INPUT -s <versa-director-IP>/32 -p tcp \ --dport 22 -j ACCEPT $ sudo iptables -A INPUT -p tcp --dport 22 -j REJECT |
Standard NTP, for time synchronization |
Inbound/UDP |
123 |
Add iptables rules to allow NTP port access to the nodes. $ sudo iptables -A INPUT -p udp --dport 123 -j ACCEPT |
Default access (drop other access) |
|
|
Issue the following commands to drop all other access by default. $ sudo iptables -A INPUT -m state --state \ ESTABLISHED,RELATED -j ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -P FORWARD DROP $ sudo iptables -P INPUT DROP |
- Issue the following command so that the rules persist when you reboot the system.
admin@Analytics$ vsh restart
- To display the updated iptables rules, issue the following command.
admin@Analytics$ sudo iptables -L
Install iptables Rules Using a Script
You can configure many iptables rules using the analytics_securemode.sh script. Each time you issue the analytics_securemode.sh -i enable command, it sets up rules for inter-cluster access and management (UI) access. For inter-cluster access, the script determines the subnet automatically and adds it to the allow list. For management access, the script determines the subnet from the /opt/versa/scripts/van-scripts/vansetup.conf file. The script allows Analytics application port access to Versa Director and Analytics nodes only.
The script adds iptables entries for the following port numbers:
- 8983 (Solr)
- 9042 (Cassandra)
- 2181 (Zookeeper)
- 5000, 5010, 5020, 8008 (Versa)
- 443, 8443 (Analytics Application)
The script can also configure access for additional IP addresses and subnets. To do this, the script automatically searches for entries in the /opt/versa/etc/WHITELIST file. If the file does not exist, the script prompts you to enter the IP addresses and subnets manually.
To configure iptables rules:
- Login to a shell on the Analytics node.
- Ensure that you have download the latest version of analytics_securemode.sh as described in Step 1 of Configure IP Table Rules.
- Change to the /opt/versa/scripts/van-security directory.
admin@Analytics$ cd /opt/versa/scripts/van-security
- Run the analytics_securemode.sh script.
- To run the script and enter additional allowed IP addresses and subnets interactively:
Ensure that no /opt/versa/etc/WHITELIST file exists, and then run the script as follows.admin@Analytics$ sudo ./analytics_securemode.sh -i enable (output omitted for brevity) Info: Please add comma separated subnets/IP eg: 1.1.1.1, 10.10.10.0/24 ===> Please enter subnets/IP (or ENTER if none): 10.10.10.0, 10.20.20.0/24 Info: These are the IP ranges/IP to whitelist for inter-cluster localhost.localhost.localhost.0/24 10.10.10.0/24 10.20.20.0/24 127.0.0.1 ===> Do you want to proceed? (y/N)? y (output omitted for brevity) Info: Please add comma separated subnets/IP eg: 1.1.1.1, 10.10.10.0/24 ===> Please enter subnets/IP (hit ENTER if none): 2.2.2.2, 1.1.1.1 Info: These are the IP ranges/IP to whitelist for UI access 127.0.0.1 localhost.localhost.localhost.0/24 2.2.2.2 1.1.1.1 ===> Do you want to proceed? (y/N)? y (output omitted for brevity) admin@Analytics$ vsh restart
- To run the script using a whitelist file:
-
Add entries to the /opt/versa/etc/WHITELIST file. For access between Analytics clusters, you add entries in the section labeled INTERNAL. For management access, you add additional IP addresses and/or subnets in the section labeled MANAGEMENT.
For example, the following white list file adds subnets 10.10.10.0/24 and 10.20.20.0/24 in the allowed sources list for inter-cluster access. This can be used for additional collector subnets. Additionally, 2.2.2.2 and 1.1.1.1 are added to allow source IP addresses for management access.admin@Analytics$ cat /opt/versa/etc/WHITELIST INTERNAL: 10.10.10.10, 10.20.20.1/24 MANAGEMENT: 2.2.2.2, 1.1.1.1
- Run the script as follows.
admin@Analytics$ sudo ./analytics_securemode.sh -i enable Info: Parsing van-security arguments Info: Setup iptable rules Info: Determined 192.168.1.0/24 to be the VAN inter-cluster subnet, Will add 192.168.1.0/24 to inter-cluster whitelistInfo: Determined 10.40.93.0/24 to be the VAN management subnet, Will add 10.40.93.0/24 to MGMT whitelist Info: Reading arguments from /opt/versa/etc/WHITELIST for iptables rules. If you want to make changes, pls edit the file or remove the file for interactive mode Info: These are the IP ranges/IP to whitelist for inter-cluster communication 192.168.1.0/24 127.0.0.1 10.10.10.0/24 10.20.20.0/24 (output omitted for brevity) Info: These are the IP ranges/IP to whitelist for management communication 2.2.2.2 1.1.1.1 127.0.0.1 192.168.1.0/24 10.40.93.0/24 (output omitted for brevity) Info: You can check the rules by executing 'sudo iptables -L' on the shell admin@Analytics$ vsh restart
-
- To run the script and enter additional allowed IP addresses and subnets interactively:
Supported Software Information
Releases 20.2 and later support all content described in this article, except:
- Releases 22.1.4 adds support for changing database and service passwords for an Analytics cluster from the active Director node.