NetScaler secure deployment guide

Network security

August 20, 2024

Contributed by:

When deploying NetScaler in a production environment, we recommend that the following key configuration changes are made:

Do not expose the NetScaler administrator interface (NSIP) to the Internet.
The NetScaler default SSL certificate must be replaced.
HTTPS (HTTP over TLS) must be used when accessing the GUI and the default HTTP interface disabled.

The following section provides more information on these key considerations, in addition to the further changes that are recommended.

Key network security considerations

Do not expose the NSIP and Management Service IP address to the Internet:

We recommend that the NetScaler Management IP (NSIP) address and Management Service IP address of SDX is not exposed to the public Internet and is deployed behind an appropriate stateful Packet Inspection (SPI) firewall.

Replace the NetScaler default TLS certificate:

During the initial configuration of NetScaler, the default TLS certificates are created. These certificates are not intended for use in production deployments and must be replaced.

We recommend that customers configure NetScaler to use certificates either from a reputable Certificate Authority (CA) or appropriate certificates from your enterprise Certificate Authority.

When bound to a public-facing virtual server, a valid TLS certificate from a reputable CA simplifies the user experience for internet-facing web applications; user web browsers require no user interaction when initiating secure communication with the web server. To replace the default NetScaler certificate with a trusted CA certificate, see Knowledge Center article CTX122521: “How to replace the default certificate of a NetScaler appliance with a trusted CA certificate that matches the host name of the appliance.”

Alternatively, it is possible to create and use custom TLS certificates and private keys. While this action can provide an equivalent level of transport layer security, it requires the TLS certificates to be distributed to users and requires a user interaction when initiating connections to the web server. For more information on how to create custom certificates, see Knowledge Center article CTX121617: How to Create and Install Self-Signed Certificates on NetScaler Appliance.

More information on TLS certificate management and configuration can be found in the “NetScaler TLS Recommendations” section of this guide.

Disable HTTP access to the administrator interface:

To protect traffic to the NetScaler administrative interface and GUI, NetScaler must be configured to use HTTPS. Perform the following steps:

Create a 2048-bit or greater RSA private and public key pair and use the keys for HTTPS and SSH to access the NetScaler IP address, replacing the factory provisioned 512-bit RSA private and public key pair.
Configure NetScaler to use only strong cipher suites and change the ‘DEFAULT’ set of cipher suites to strong cipher suites on NetScaler. We recommend that you use the list of approved TLS Cipher suites in section 3.3 of NIST Special Publication 800-52 (Revision 1). This document can be found on the NIST website at the following address: https://www.nist.gov/publications/guidelines-selection-configuration-and-use-transport-layer-security-tls-implementations?pub_id=915295
Configure NetScaler to use SSH public key authentication to access the administrator interface. Do not use the NetScaler default keys. Create and use your own 2048-bit RSA private and public key pair. For more information, see Knowledge Center article CTX109011: How to Secure SSH Access to the NetScaler Appliance with Public Key Authentication and the NetScaler product documentation: SSH key-based authentication for local system users
Once the NetScaler has been configured to use these new certificates, HTTP access to the GUI management interface can be disabled with the following command:

set ns ip <NSIP> -gui SECUREONLY
<!--NeedCopy-->

For more information on how to configure secure access to the Administration GUI, see the Knowledge Center article CTX111531: How to Enable Secure Access to NetScaler GUI Using the SNIP/MIP Address of the Appliance.

Other network security considerations

Limit VPX shell access of VPX administrators who are not trusted to manage the SDX:

In situations where it is desirable to have a different person administer a VPX to that of the Management Service, the Management Service administrator must create a VPX admin user which has limited shell access on the VPX and only provide the restricted admin user account to the VPX administrator.

Some operations might require shell access (such as administering SSL certificates). However, only individuals who are trusted to administer the SVM must be granted access to the VPX instance shell. RBAC level commands, listed later in this section, can be assigned to those accounts. These recommendations are applicable for all SVM-IP/VPX-NSIP (L2/L3) management workflows and must be followed for secure access auditing purposes.

The following steps can be used to remove shell access from a VPX admin.

Securing an existing VPX instance:

Log in to the VPX CLI as nsroot or superuser.

We recommend not to use the nsroot account and instead create a superuser account. When using the nsroot account, ensure that the passwords are strong with special characters. For details on strong passwords, see Administration and management.
- Create a user and an RBAC policy in a VPX instance on NetScaler SDX.
- Bind that user to the policy.
```
    > add system user userabc
    Enter password:
    Confirm password:
    Done
    > bind system user userabc superuser 2
    Done
    > add system cmdpolicy shell deny (shell)
    Done
    > bind system user userabc shell 1
    Done

```
Note:

In this example, the system cmdpolicy (ex: cmdpolicy name: shell) is created to deny shell access. This policy is bound to the user userabc with priority high. Default superuser cmdpolicy is also bound as lower priority to the system user. With this configuration, the new system user has superuser RBAC policies but shell access is denied.

Verify that the current user has applied the RBAC policies.
Run any commands that the user is authorized to. (for example, show system cmdpolicy)
Run the shell command to verify that shell access is restricted.

Pre-authentication banner message from server:

| #############################################################################
> ##
| #
>  #
| #        WARNING: Access to this system is for authorized users only
>  #
| #         Disconnect IMMEDIATELY if you are not an authorized user!
>  #
| #
>  #
| #############################################################################
> ##
|
End of banner message from server
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Last login: Thu May 13 04:11:15 2021 from 10.10.1.1
Done
<!--NeedCopy-->

> whoami
    UserName:  userabc        LoggedIn:  "Thu May 13 04:18:50 2021"
Done
<!--NeedCopy-->

In the console of that VPX, log in as that user and make sure that the shell access is not allowed for this user:
```
> shell
ERROR: Not authorized to execute this command [shell]

```

> shell
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.

root@Zela-40G-10#
<!--NeedCopy-->

Securing a new VPX instance:

When a new VPX instance is created from the Management Service GUI, create an INSTANCE ADMIN user, and clear the Shell/SFTP/SCP Access checkbox. On disabling shell access, svm_access_policy (action DENY) is bound explicitly to the specified instance admin user.
Provide this user information to the VPX admin. The SDX admin must retain this nsroot admin password and must not share it with the VPX admin.

Notes:

To change the nsroot password, log on to Management Service, select the instance, and change the password. Never change the nsroot password from the VPX CLI.

For details about RBAC users, see User, user groups, and command policies.

For modifying the password of NetScaler from SVM, see Modify a NetScaler instance.

For provisioning NetScaler with instance administration, see Add a NetScaler instance.

Disable SSH port forwarding:

SSH port forwarding is not required by NetScaler. If you do not want to use this functionality, then we recommend that you disable it by using the following steps:

Edit the /etc/sshd_config file by adding the following line:

AllowTcpForwarding no
Save the file and copy it to the /nsconfig directory to ensure that the changes are persistent in case you reboot during the tests.
Restart the sshd process by using the following command:
```
kill -HUP `cat /var/run/sshd.pid`

```

Configure NetScaler with high availability:

In deployments where continuous operation is required, NetScaler can be deployed in a high availability setup. Such a setup provides continued operation if one of the NetScaler stops functioning or requires an offline upgrade.

For information on how to configure a high availability setup, see Configuring high availability.

Set up secure communication between peer appliances:

If you have configured your NetScaler in a high availability, cluster, or GSLB setup, secure the communication between NetScaler appliances.

To secure communication, we recommend that you change the internal user account or RPC node password, and enable the Secure option. RPC nodes are internal system entities used for system-to-system communication of configuration and session information.

NetScaler features can also use an SSH key-based authentication for internal communication when the internal user account is disabled. In such cases, the key name must be set as “ns_comm_key”. For more information, see Access a NetScaler appliance by using SSH keys and no password.

Change the default passwords:

For enhanced security, we recommend that you change the administrator, and internal user account or RPC node passwords for both on-premises and cloud deployments. Frequently changing the passwords is advisable.

Administrator password: See Change administrator password.
Internal user account or RPC node password: See Change an RPC node password.

Note

We also recommend that you disable the internal user account and instead use the key-based authentication.

Configure network security domains and VLANs:

We recommend that network traffic to NetScaler management interface is separated, either physically or logically, from normal network traffic. The recommended best practice is to have three VLANs:

Outside Internet VLAN
Management VLAN
Inside server VLAN

We recommend configuring the network to make the LOM port part of the management VLAN.

When deploying NetScaler in two-arm mode, dedicate a specific port to a specific network. If VLAN tagging and binding two networks to one port is required, you must ensure that the two networks have the same, or similar, security levels.

If the two networks have different security levels, VLAN tagging must not be used. Instead, consider dedicating a port for each specific network and use independent VLANs distributed over the ports on NetScaler.

Consider using NetScaler Web App Firewall: A Premium edition licensed NetScaler provides a built-in NetScaler Web App Firewall that uses a positive security model and automatically learns the proper application behavior for protection against threats such as command injection, SQL injection, and Cross Site Scripting.

When you use NetScaler Web App Firewall, users can add extra security to the web application without code changes and with minimal change in configuration. For more information, see Introduction to NetScaler Web Application Firewall.

Restrict non-management applications access: Run the following command to restrict the ability of non-management applications to access NetScaler.

set ns ip <NSIP> -restrictAccess enabled
<!--NeedCopy-->

Secure cluster deployment: If NetScaler cluster nodes are distributed outside the data center, we recommend that you use secure RPC for Node to Node Messaging (NNM), AppNNM, and a high availability setup.

To enable the Secure RPC feature for all NetScaler IP addresses in a NetScaler Cluster and a high availability setup, run the following command:

set rpcnode <ip> -secure on
<!--NeedCopy-->

Note: Other configurations might be required. For more information, see the Clustering topics on the Product Documentation.

When deployed in an L3 cluster deployment, packets between NetScaler nodes are exchanged over an unencrypted GRE tunnel that uses the NSIP addresses of the source and destination nodes for routing. When the exchange occurs over the internet, in the absence of an IPsec tunnel, the NSIPs are exposed on the internet, which is not recommended as it doesn’t comply with the security best practices for NetScaler.

̇We recommend that customers establish their own IPsec solution to use the cluster over the L3 feature.

If the IP forwarding feature is not in use, use the following command to disable L3 mode:

disable ns mode L3
<!--NeedCopy-->

Use secure MEP for global server load balancing (GSLB): To encrypt the MEP between NetScaler for GSLB, run the following command from the NSCLI:

set rpcNode <GSLB Site IP> -secure yes
<!--NeedCopy-->

Secure the load balancing persistence cookie:

We recommend encrypting the load balancing persistence cookie in addition to the SSL/TLS channel. For more information, see HTTP cookie persistence.

Helloverifyrequest parameter to mitigate the DTLS DDoS amplification attack:

Starting from NetScaler release 12.1 build 62.x and release 13.0 build 79.x, the helloverifyrequest parameter is enabled by default. Enabling the helloverifyrequest parameter on the DTLS profile helps mitigate the risk of an attacker or bots overwhelming the network throughput, potentially leading to outbound bandwidth exhaustion. That is, it helps mitigate the DTLS DDoS amplification attack.

To view the helloverifyrequest parameter status, at the CLI prompt, type:

show dtlsProfile
<!--NeedCopy-->

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Network security

August 20, 2024

Contributed by:

August 20, 2024

Contributed by:

Network security

Key network security considerations

Other network security considerations

In this article