WAF profile configuration
To access the WAF profile from the CWAAP GUI, you must access the Configuration module and click Policies. The Policy Configuration
page shows the WAF Profile
option. To configure a new WAF Profile, you must first set up a Proxy configuration. Once you have an active Proxy configuration:
-
Click the Configure a New Policy button. A menu for ‘Choose Proxy for WAF Profile Configuration options’ will be displayed.
-
Select one of the Proxy configurations by clicking the associated Configure WAF Profile. The WAF Policy Editor will be displayed.
-
assigns the policy options you want to create for your profile. Details for the policies are shown in the tables below.
-
Once you have provided all the policy information, click the submit button at the bottom right of the screen.
Manage existing WAF configuration
From the WAF Profile page, click “Edit” next to the host name field of the configuration you want to update. The update configuration screen will be displayed. Here you can make any changes you want make and click Save to submit the updated configuration. From this screen, you can also Delete the configuration by selecting the “Delete” button at the top right of the screen.
Enable WAF
Before you can create and configure your Web Application Firewall (WAF) Policies, you must first enable WAF for your account, and select the type of WAF Policy you want to configure.
From the Edit Account page, navigate down to the Services section. For WAF to be enabled for the account, the Proxy settings have to be Enabled. If they are Disabled, the options to configure and customize the basic WAF settings will be removed.
In the WAF drop-down menu, you can select either:
- Disabled
- Basic Application Security (Basic WAF)
- Advanced Application Security
Once you have selected the WAF type, the WAF Signatures default to 3, unless you select another option. You can opt to enable any other Proxy and WAF settings, but click the Save button when you are done.
Access WAF profile
To access the Web Application Firewall (WAF) Profile, select Configuration from the left-hand navigation panel, and then click Policies, and then click WAF Profile tab.
If there are no WAF Policies configured, or you want to create a WAF Policy, you must first configure a Proxy. To find more details on how to configure a Proxy, please use the following help file DNS Proxy Configuration
.
Once you have an active Proxy configuration:
- Click the Configure New Proxy button.
- Select one of the Proxy configurations by clicking the associated Configure WAF Profile.
- Using the WAF Policy Editor, assign the policy options you want to create for your profile.
- Once you have provided all the policy information, click the Create Profile button at the bottom right of the screen.
The WAF profile page has security checks available under three categories - Core, Advanced, and XML.
Core security checks
The core security checks apply to any aspect of web security that either does not involve content or is equally applicable to all types of content.
The core security checks are as follows:
-
HTML SQL Injection. The CWAAP HTML SQL Injection check provides special defenses against injection of unauthorized SQL code that might break the security. If CWAAP detects unauthorized SQL code in a user request, it either transforms the request, to render the SQL code inactive, or blocks the request.
-
HTML cross-site scripting. The HTML Cross-Site Scripting (cross-site scripting) check examines both the headers and the POST bodies of user requests for possible cross-site scripting attacks. If it finds a cross-site script, it either modifies (transforms) the request to render the attack harmless, or blocks the request.
-
CSRF Settings. The Cross Site Request Forgery (CSRF) settings check 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 applies only to HTML requests that contain the web form, with or without data. It does not apply to XML requests.
-
Buffer overflow. The Buffer Overflow check detects if there is buffer overflow on the web server. If CWAAP detects a URL, cookies, or header are longer than the configured length, it blocks the request because it can cause a buffer overflow
Advanced security checks
The advanced security checks examine web form data to prevent attackers from compromising your system by modifying the web forms on your websites or sending unexpected types and quantities of data to your website.
The advanced security checks are as follows:
-
Cookie consistency. The Cookie Consistency check examines cookies returned by users, to verify that they match the cookies that your website set for that user. If you modify a cookie, the cookie is ripped from the request before it is forwarded to the web server. You can also configure the Cookie Consistency check to transform all of the server cookies that it processes, by encrypting the cookies, proxying the cookies, or adding flags to the cookies. The check applies to requests and responses.
- Field consistency. The Form Field Consistency check examines the web forms returned by users of your website, and verifies that web forms were not modified inappropriately by the client. This check applies only to HTML requests that contain the web form, with or without data. It does not apply to XML requests.
- Field format. The Field Formats check verifies the data that users send to your websites in web forms. It examines both the length and type of data to ensure that it is appropriate for the form field. If the Web App Firewall detects inappropriate web form data in a user request, it blocks the request.
- Content type. Web servers add a Content-Type header with a
MIME/type
definition for each content type. Web servers serve many different types of content. For example, standard HTML of typetext/html
MIME
. JPG images are assigned content types. A normal web server can serve different types of content, all defined in the Content Type header by typeMIME/type
. - HTTP RFC profile. NetScaler Web App Firewall inspects the incoming traffic for HTTP RFC compliance and drops any request that has RFC violations by default. However, there are certain scenarios, where the appliance might have to bypass or block a non-RFC compliance request. In such cases, you can configure the appliance to bypass or block such requests at global or profile level.
- Deny URL. The Deny URL check examines and blocks connections to URLs that hackers commonly access. This check contains a list of URLs that are common targets of hackers or malicious code and that rarely if ever appear in legitimate requests. You can also add URLs or URL patterns to the list. The Deny URL check prevents attacks against various security weaknesses known to exist in the web server software or on many websites.
- POST body limit. Limits the request payload (in bytes) inspected by Web Application Firewall.
XML security checks
The XML Protection checks examine requests for XML-based attacks of all types.
The XML security checks are as follows:
-
XML SQL Injection. The XML SQL injection check examines the user requests for possible XML SQL Injection attacks. If it finds injected SQL in XML payloads, it blocks the requests.
-
XML cross-site scripting. The XML Cross-Site Scripting check examines the user requests for possible cross-site scripting attacks in the XML payload. If it finds a possible cross-site scripting attack, it blocks the request.
-
XML format. The XML Format check examines the XML format of incoming requests and blocks those requests that are not well formed or that do not meet the criteria in the XML specification for properly formed XML documents.
-
XML SOAP fault. The XML SOAP fault check examines responses from your protected web services and filters out XML SOAP faults. The detection prevents leaking sensitive information to attackers.
-
Web service interoperability. The Web Services Interoperability (WS-I) check examines both requests and responses for WS-I standard, and blocks those requests and responses that are not in compliance with WS-I. The purpose of the WS-I check is to block requests that might not interact with other XML appropriately. An attacker can use inconsistencies in the interoperability to attack your XML application.
To disable WAF policies
- From the Edit Account page, select Disabled to clear your WAF.
- Turning the Proxy setting OFF will also disable WAF, but we do not recommend this method.
- Click the Save button.
- You will no longer be able to access the Web Application Firewall section of your account when attempting to access it.
To disable a single WAF policy
- Edit the WAF Policy.
- Click disable in the Proxy Policies section.
To re-enable WAF
- From the Edit Account page, select either Basic or Advanced Application Security from the drop-down menu.
- The WAF Signatures displays the default value of 3.
- Click Save.
- Navigate to the Configuration option on the left-hand navigation panel, select Security, and then Web Application Firewall.
- Click pencil icon to edit the WAF policy.
- Click enable (“lock” icon).
- All of your previously saved configurations will be applied.
- Click Save Changes.
Learning and relaxation
Given the sheer volume of traffic CWAAP examines, it is critical for our customers to understand the traffic patterns and types that they are experiencing. Enabling certain counter measures or features can actually be detrimental to a customer by creating false positives, which might require manual research and review. By enabling the CWAAP Learning feature, a complete traffic pattern can be analyzed, which then makes creating a Relaxation Rule that would prevent specific traffic patterns from being blocked painless and manageable.
Once the Learning behavior is actively monitoring traffic for the specified Protection Type, a comprehensive list of rules with its count appears. Once you have reviewed the list, if there are any entries that must not be blocked, or are not malicious, you can add them to the Relaxation section to prevent them from being blocked in the future.