NetScaler Web App Firewall security recommendations

• For RFC compliance checks, it is recommended to keep ‘APPFW_RFC_BLOCK’ as the default rfcprofile for the WAF profile.

• WAF supports inserting Samesite cookie attribute value and the cookie can be restricted to the same-site or cross-site context by selecting ‘Strict’ or ‘Lax’ values.

Deploy NetScaler in the two-arm mode

With a two-arm mode installation, NetScaler is physically located between the users and web servers that NetScaler protects. Connections must pass through NetScaler. This arrangement minimizes the chances of finding a route around NetScaler.

Use a ‘Default Deny’ policy

We recommend that administrators configure NetScaler Web App Firewall with a deny all policy at the global level to block all requests that do not match a NetScaler Web App Firewall policy. The following is a sample set of commands to configure a ‘deny all’ policy at the global level:

add appfw profile default_deny_profile -defaults advanced

add appfw policy default_deny_policy true default_deny_profile

bind appfw global default_deny_policy <PRIORITY>
<!--NeedCopy-->

Note:

The PRIORITY setting must ensure that the default policy gets evaluated last (only if the request does not match any other configured policies).

NetScaler software includes default profiles, such as appfw_block, which when configured block requests that do not match the NetScaler Web App Firewall policies. Run the following command to set the default profile:

set appfw settings -defaultProfile appfw_block
<!--NeedCopy-->

NetScaler Web App Firewall – Building multiple tiers of security

The following guidelines help you build multiple tiers of security depending on your environment and the applications that are supported.

Configure a different value for the sessionCookieName parameter in each tier.

set appfw settings -sessionCookieName "citrix_ns_id_1"
<!--NeedCopy-->

First tier of security

To build the first tier of security, perform the following:

• Enable Buffer Overflow, SQL injection, and Cross Site scripting.
• A start URL is needed when the application is particular on which URLs must be accessed and have to protect against forceful browsing.
• Enable Field Format Checks if your application is expecting inputs in a form field.

Cross-site scripting check might generate false positives as many companies have a large installed base of JavaScript-enhanced web content that violates the same origin rule. If you enable the HTML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity.

Roll out the first tier, look for false positives, deploy the exceptions and then move on to the next tier. A staged implementation helps in managing the AppFw deployment.

Second tier of security

To build the second tier of security, do the following:

Enable Signatures on the profile in addition to Buffer Overflow, SQL injection, and Cross Site scripting. There are 1300 + signatures. Try to enable only those signatures that are applicable for protecting your application, rather than enabling all signature rules.

Roll out the second tier, look for false positives, deploy the exceptions and then move on to the next tier. A staged implementation helps in managing the NetScaler Web App Firewall deployment.

Third tier of security

To build the third tier of security, do the following:

• Based on the application needs, enable Advanced Profile Security checks like CSRF tagging, Cookie Consistency, Form Field consistency on parts of applications that need it.
• Advanced security checks require more processing and can affect the performance. Unless your application needs advanced security, you might want to start with a basic profile and tighten the security as required for your application.

The security checks disabled in the basic NetScaler Web App Firewall profile all operate on objects in the HTTP response. Therefore, these security checks are more resource intensive. When the NetScaler Web App Firewall performs response side protections, it needs to remember the information sent to each individual client. For example, if a form is protected by the NetScaler Web App Firewall, form field information sent in the response is retained in memory. When the client submits the form in the next subsequent request, it is checked for inconsistencies before the information is sent to the Web Server. This concept is referred to as Sessionization. Security checks such as URL Enclosure within Start URL, Cookie Consistency, Form Field Consistency, and CSRF Form Tagging all imply Sessionization. The amount of CPU and memory resources used by these security checks increments linearly with the number of requests sent through the NetScaler Web App Firewall. For example:

• Enable Form Field Consistency check: This check is required to verify if the web forms were not modified inappropriately by the client. An application that serves and hosts critical information in forms needs the check.

• CSRF Form tagging check: This check is for forms. The Cross Site Request Forgery (CSRF) Form Tagging check tags each web form sent by a protected website to users with a unique and unpredictable FormID, and then examines the web forms returned by users to ensure that the supplied FormID is correct. This check protects against cross-site request forgery attacks. This check must be enabled if the application has web-based forms. This check requires relatively little CPU processing capacity compared to certain other security checks that analyze web forms in depth. It is therefore able to handle high volume attacks without seriously degrading the performance of the protected website or the NetScaler Web App Firewall itself.

NetScaler Web App Firewall workflow steps

Perform the following steps in the NetScaler Web App Firewall workflow:

1. Configure the security profile.
2. Apply signatures for all known threats - the negative model.
3. Configure traffic policies that can detect the correct traffic flow where this security profile must be activated.

You are ready for the production traffic to pass-through the system. The first level of flow is completed. Further, configure the learning infrastructure. Many times, customers want to do learning in production traffic thus having the signatures applied avoids any risk. Perform the following steps:

1. Configure the learning infrastructure.
2. Deploy the learned rules for protection.
3. Validate the learning data along with the signatures applied before going live.