Access Anywhere Hardening Advisory
First published on February 13, 2019.
Last edited on February 22, 2019.
Introduction
We take extensive measures to ensure that Access Anywhere (NAA) conforms to best practices for information security. From time to time we identify changes that can be made to deployed NAA VMs to further harden them. This advisory presents our latest hardening recommendations. We strongly recommend that NAA administrators read this advisory carefully and implement the recommended changes as appropriate for their sites.
Apache HTTPD TLS Settings and Ciphers
TLS versions and cipher recommendations change as new threats are discovered. Some scanning tools will flag the availability of older ciphers and protocol versions in the NAA as minor vulnerabilities. Should you wish to address those, here is how to update Access Anywhere's configuration with the latest recommended settings.
We recommend that you use Mozilla SSL Configuration Generator to generate the list of ciphers. When using the Mozilla SSL Configuration Generator please select Apache server and Modern profile.
On the date of writing these are the modern setting recommended by Mozilla. Use them if all your clients (OS, mobile devices) are the latest versions.
As the root user edit the following file with the vi or nano editor after making a backup copy:
vi /etc/httpd/conf.d/ssl.conf
Find and replace the following line (note that it may line-wrap and appear to be several lines):
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!RSA
with (for example; always get the latest cipher list from Mozilla SSL Configuration Generator):
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Additionally replace the line:
SSLProtocol all -SSLv3 -TLSv1
with:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
After saving the file restart apache:
systemctl restart httpd
SSH Settings
(for initial deployments of version 1901 or earlier)
You can also restrict the ciphers when connecting for administration using ssh.
This procedure should only be attempted if you have console access to your VM. If you make a mistake then it may be impossible to connect to the VM over the network. In that case you will only be able to restore network access if you have console access.
As the root user edit the following file with the vi or nano editor after making a backup copy:
vi /etc/ssh/sshd_config
Find and replace the following line:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
with these 3 lines:
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
After saving the file restart the sshd service as root:
systemctl restart sshd
Disable CloudFTP
The NAA provides legacy protocol adaptors that allow you to use FTP, FTPS or SFTP to access any storage that is connected to the NAA . These protocols are presented by the NAA 's CloudFTP service.
To provide compatibility with a wide range of clients, SFTP and FTPS support many encryption protocols and ciphers including some that are known to be relatively insecure, and the FTP protocol does not support encryption. Unless you have a specific need for FTP, FTPS or SFTP access to your NAA , you may choose to disable CloudFTP service. Here is how to do that.
As root:
systemctl stop cloudftp systemctl disable cloudftp
Remove Web Access to Icons Directory
(for initial deployments of version 1901 or earlier)
The NAA 's Apache Web server configuration allows access to a directory containing icons. Although this is not a security risk, some scanning tools will flag it as one. Here is how to remove access to that directory.
As root remove the following file:
rm /etc/httpd/conf.d/autoindex.conf systemctl restart httpd