Applications and services
Configure NetScaler to delete or pass the upgrade header
A new parameter passProtocolUpgrade
is added to the HTTP profile to prevent attacks on the back-end servers. Depending on the state of this parameter, the upgrade header is passed in the request sent to the back-end or deleted before sending the request.
- If the
passProtocolUpgrade
parameter is enabled, then the upgrade header is passed to the back end. The server accepts the upgrade request and notifies it in its response. - If this parameter is disabled, then the upgrade header is deleted and the remaining request is sent to the back end.
The passProtocolUpgrade
parameter is added to the following profiles.
- nshttp_default_profile - enabled by default
- nshttp_default_strict_validation - disabled by default
- nshttp_default_internal_apps - disabled by default
- nshttp_default_http_quic_profile - enabled by default
We recommend that you set the passProtocolUpgrade
parameter to disabled.
Set the passProtocolUpgrade
parameter by using the CLI:
At the command prompt, type the following:
set ns httpProfile <name> [-passProtocolUpgrade ( ENABLED | DISABLED )]
Set the passProtocolUpgrade
parameter by using the GUI:
- Navigate to System -> Profiles -> HTTP Profiles.
- Create or edit an HTTP profile.
- Select the Pass Protocol Upgrade checkbox.
Configure NetScaler to drop invalid HTTP requests
We recommend that NetScaler is configured with strict checking and enforcement of HTTP requests to prevent invalid HTTP requests passing through virtual servers. To do so, bind an in-built HTTP profile, nshttp_default_strict_validation, to one or more virtual servers using the following command on the CLI:
show ns httpProfile (Shows the available http profile (default+user configured profiles))
set lb vserver <vserver name> -httpProfileName nshttp_default_strict_validation
<!--NeedCopy-->
We recommend that customers using this option test the changes in a staging environment before releasing it to production.
Protection against the HTTP desync attacks is enabled by default on the strict HTTP validation profile (nshttp_default_strict_validation). Use the strict profile for all the client-facing entities.
For more information on HTTP request smuggling attacks and its mitigation, see the support article NetScaler - HTTP Request Smuggling Reference Guide.
Configure protection against HTTP Denial of Service attacks
The NetScaler firmware supports limited countermeasures against HTTP Denial of Service attacks, including ‘slow-read’ type attacks. You can configure these features by using the nsapimgr
utility from the NetScaler shell prompt:
- small_window_threshold (default=1)
- small_window_idle_timeout (default=7 sec)
- small_window_cleanthresh (default=100)
- small_window_protection (default=Enabled)
The default settings are adequate for preventing the HTTP Denial of Service attacks, including slow-read attacks, however, some tuning of the parameters might be required for other attacks.
To protect against such attacks, adjust the small_window_threshold
property upward by using the following nsapimgr
command from the NetScaler shell prompt:
$ nsapimgr –ys small_window_threshold=<desired value>
Note:
The
small_window_threshold
desired value can be set based on the incoming traffic pattern in the deployment. The acceptable range is from 0 to 2^32.
You can verify the protection against HTTP Denial of Service attacks by monitoring the following counters with nsconmsg –d stats
command from the NetScaler shell prompt:
- nstcp_cur_zero_win_pcbs: This counter tracks the number of PCBs that currently have a low window value.
- nstcp_err_conndrop_at_pass: This counter is incremented when NetScaler detects that, while passing packets through from one side to the other, it has exceeded the nscfg_small_window_idletimeout value.
- nstcp_err_conndrop_at_retx: This counter is incremented when the time that lapses during retransmission exceeds the nscfg_small_window_idletimeout value.
- nstcp_cur_pcbs_probed_withKA: This counter tracks the number of PCBs in the surge queue that are probed with a KA probe.
We recommend that customers using this option test the changes in a staging environment before releasing it to production.
Configure NetScaler to defend against TCP spoofing attacks
The following commands can be used to help protect back-end servers against TCP spoofing attacks:
set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED
Done
set lb vserver lbvserver1 -tcpProfileName profile1
Done
<!--NeedCopy-->
We recommend that customers using this option test the changes in a staging environment before releasing it to production.
Configure NetScaler to accept specific HTTP headers
It is possible to configure the NetScaler to accept only specific HTTP headers. This can be accomplished by adding a rewrite action to restrict network traffic with specific, defined HTTP headers from being passed to the back-end server.
The following global rewrite action sends only network traffic with headers such as Host, Accept, and test to the server:
add rewrite action act1 replace_all q/HTTP.REQ.FULL_HEADER.after_str("\r\n")/ q{TARGET.REGEX_SELECT(re/(iu)^(Host|Accept|test):.*\r\n/) ALT ""} -pattern q{re/(U).+:.+r\n/}
add rewrite policy pol1 HTTP.REQ.IS_VALID act1
bind rewrite global pol1 100
<!--NeedCopy-->
Configuring close-notify
A close-notify is a secure message that indicates the end of SSL data transmission. In compliance with RFC 5246: The client and the server must share knowledge that the connection is ending to avoid the truncation attack. Either party can initiate the exchange of closing messages by sending a close_notify alert. Any data received after a closure alert is ignored, unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. To ensure that audit events are captured for TLS termination events log on to the CLI as a superuser or sysadmin and run the following commands:
set ssl parameter -sendCloseNotify y
save ns config
<!--NeedCopy-->
Secure Management GUI, NITRO API, and RPC communication
To secure the management GUI, NITRO API, and RPC communication on NetScaler and NetScaler Gateway, the setting maxclientForHttpdInternalService
is added in NetScaler. This setting is disabled by default. You must enable the parameter to secure the management GUI, NITRO API, and RPC communication.
It is also recommended that you set maxclientForHttpdInternalService
to match the MaxClients value in /etc/httpd.conf by using the following shell command. The default value of MaxClients is 30.
nsapimgr_wr.sh -ys maxclientForHttpdInternalService=<val>
<!--NeedCopy-->
For more information on setting the maxclientForHttpdInternalService
value and the NetScaler versions that support this setting, see https://support.citrix.com/article/CTX331588.
In this article
- Configure NetScaler to delete or pass the upgrade header
- Configure NetScaler to drop invalid HTTP requests
- Configure protection against HTTP Denial of Service attacks
- Configure NetScaler to defend against TCP spoofing attacks
- Configure NetScaler to accept specific HTTP headers
- Configuring close-notify
- Secure Management GUI, NITRO API, and RPC communication