| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
A web application firewall (WAF) is a filter or server plugin that applies a set of rules, called rule sets, to an HTTP request. Web application firewalls are useful for establishing an increased security layer in order to identify and prevent attacks. It acts as a firewall for applications hosted within the origin server. In addition, it enables administrators to inspect any part of an HTTP request, such as headers and body, and configure conditions to accept or reject the HTTP request based on the condition.
Several free and commercial versions of web application firewall modules are available for use. The web application firewall module for Oracle Traffic Director supports ModSecurity 2.6, which is an intrusion detection and prevention engine for web applications. The ModSecurity rule sets can be customized to shield applications from common attacks such as cross-site scripting (XSS) and SQL injection. Based on various criterion, such as HTTP headers, environment variables and CGI variables, ModSecurity filters and rejects incoming requests. For more information about ModSecurity, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Introduction.
Among the many providers who have published different versions of the rule sets for ModSecurity, Oracle Traffic Director has been tested with the Open Web Application Security Project (OWASP), which is an open-source application security project, and is one of the most commonly used rule set providers. For more information, see https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project.
This section contains the following topics:
With Oracle Traffic Director, web application firewalls can be enabled (or disabled) for each virtual server in your configuration. This in turn applies a set of rules, and acts as a firewall for the web applications deployed on the origin servers. For more information about origin servers and virtual servers, see Chapter 7, "Managing Origin Servers" and Chapter 8, "Managing Virtual Servers" respectively.
Oracle Traffic Director supports rule sets at both virtual server level and configuration level. Note that rules defined at the virtual server level will override rules defined at the configuration level. When deployed, these rules and the configuration changes are pushed to the instances, reconfiguring the instances. For more information about the web application firewall works, see Appendix B, "Web Application Firewall Examples and Use Cases."
To configure web application firewalls, you can either download an open source web application firewall rule sets or create your own rule sets. For example, download the ModSecurity Core Rule Set (CRS) from the OWASP repository, and unzip the rule sets to any folder. Oracle Traffic Director supports rules in the following directories:
base_rules
optional_rules
slr_rules
Note:
Web application firewall supports the ModSecurity 2.6 directives that are used by the configurations within the base_rules, optional_rules and slr_rules directories of OWASP ModSecurity Core Rule Set. However, it does not support Apache core config directives such as <IfDefine...> and <Location...>, and the ones supported by other Apache modules such as RequestHeader, Header and so on.
After unzipping the above directories, the files in these directories can be edited and uploaded to the administration server. These rule set files are then pushed to the Oracle Traffic Director instances when deployed. For more information, see Section 11.7.2.1, "Enabling and Installing Web Application Firewall Rule Sets."
Note:
Though the server can be configured to pick up the rule set files from a directory outside the config directory, rule file management will not be supported. When Oracle Traffic Director is configured for high availability, it is recommended that the web application firewall rule sets are placed within the config directory.
Using unsupported directives, variables, operators, actions, phases, functions and storages can cause server startup errors. For example, installing the rule set file modsecurity_crs_42_tight_security.conf without removing the unsupported action ver can cause Oracle Traffic Director to display the following error message when you start the server:
[ERROR:16] [OTD-20016] Syntax error on line 20 of /scratch/rgoutham/instance1/net-config1/config/ruleset/config1/modsecurity_crs_42_tight_security.conf: [ERROR:16] [OTD-20016] Error parsing actions: Unknown action: ver [ERROR:32] [OTD-20008] Failed to parse VS webapp-firewall-ruleset (ruleset/config1/*.conf) [ERROR:32] [OTD-10422] Failed to set configuration [ERROR:32] server initialization failed
To avoid getting this error, modify the rule set file, and remove or comment out unsupported directives, variables, operators, actions, phases, functions and storages, and then start the server.
You can enable and install web application firewall rule sets by using either the administration console or the CLI.
Note:
When you enable and install a web application firewall rule set, you are, in effect, modifying a configuration. So for the new rule set to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Section 4.3, "Deploying a Configuration."
The CLI examples in this section are shown in shell mode (tadm>). For information about invoking the CLI shell, see Section 2.3.1, "Accessing the Command-Line Interface."
Enabling and Installing Web Application Firewall Rule Sets Using the Administration Console
To configure web application firewall for a virtual server by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to configure web application firewall.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure web application firewall, and select Web Application Firewall.
The Web Application Firewall page is displayed.
On the Web Application Firewall page, click Enabled to enable web application firewall for a particular virtual server.
Click Install Rule Set Files.
In the Install Rule Set Files dialog box, either browse to the folder where you unzipped the rule set files and select the rule set file or enter the full path to the location of the rule set file. To install multiple rule set files, install them one at a time.
After you install one or more rule set files, the following text is added to the Rule Set Pattern field:
ruleset/<virtual-server-id>/*.conf
Note:
When you install rule set files at the configuration level, the rule set pattern appears as follows:
ruleset/*.conf
If required, you can add custom rule set patterns. However, rule sets outside the ruleset/<virtual-server-id> directory (if at the virtual server level) or the ruleset directory (if at the configuration level) cannot be viewed or deleted using the Oracle Traffic Director administration console or CLI. These rule sets will need to be managed manually.
Click Install Rule Set.
A message, confirming that the rule set files were installed, is displayed in the Console Messages pane.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes as described in Section 4.3, "Deploying a Configuration."
Enabling Web Application Firewall Using the CLI
To enable web application firewall using the CLI, run the enable-webapp-firewall command.
For example, the following command enables web application firewall for the virtual server vs1 in the configuration soa.
tadm> enable-webapp-firewall --config=soa --vs=vs1 OTD-70201 Command 'enable-webapp-firewall' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about enable-webapp-firewall, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
Installing Web Application Firewall Rule Sets Using the CLI
To install web application firewall rule sets using the CLI, run the install-webapp-firewall-ruleset command.
For example, the following command installs the web application firewall rule set modsecurity_crs_20_protocol_violations.conf for the virtual server vs1 in the configuration soa.
tadm> install-webapp-firewall-ruleset --config=soa --vs=vs1 /home/rulesets/modsecurity_crs_20_protocol_violations.conf OTD-70201 Command 'install-webapp-firewall-ruleset' ran successfully.
To install web application firewall rule sets at the configuration level, run the above command without the --vs option. For example, the following command installs the web application firewall rule set modsecurity_crs_50_outbound.conf for the configuration soa.
tadm> install-webapp-firewall-ruleset --config=soa /home/rulesets/modsecurity_crs_50_outbound.conf OTD-70201 Command 'install-webapp-firewall-ruleset' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about install-webapp-firewall-ruleset, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
Note:
You can use the set-config-prop and set-virtual-server-prop commands to set the value of webapp-firewall-ruleset property at the configuration level and virtual server level respectively. For more information, see the Oracle Traffic Director Command-Line Reference.
You can view the list of rule set files by using either the administration console or the CLI.
Note:
The CLI examples in this section are shown in shell mode (tadm>). For information about invoking the CLI shell, see Section 2.3.1, "Accessing the Command-Line Interface."
Viewing the List of Rule Set Files Using the Administration Console
To view the list of rule set files by using the administration console, do the following:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to view rule set files.
On the Web Application Firewall page, the Rule Set Files table lists the installed rule set files. To view the contents of these files either click and select individual rule files, or click the Name check box to select all the rules files.
Click View.
The contents of each rule file is displayed in the Rule set file contents window.
Viewing the List of Rule Set Files Using the CLI
While it is not possible to view the contents of individual rule set files using CLI, you can view the list of installed rule set files. To view the list of rule set files, run the list-webapp-firewall-rulesets command.
For example, the following command lists the installed web application firewall rule set files for the virtual server vs1 in the configuration soa:
tadm> list-webapp-firewall-rulesets --config=soa --vs=vs1 --verbose ruleset-file-name -------------------- modsecurity_crs_45_trojans.conf modsecurity_crs_42_tight_security.conf modsecurity_crs_46_slr_et_sqli_attacks.conf
To view the list of web application firewall rule sets that are installed at the configuration level, run the above command without the --vs option. For example, the following command lists the web application firewall rule sets that are installed at the configuration level for the configuration soa.
tadm> list-webapp-firewall-rulesets --config=soa --verbose ruleset-file-name -------------------- modsecurity_crs_40_generic_attacks.conf modsecurity_crs_47_common_exceptions.conf
You can view the properties of a web application firewall by running the get-webapp-firewall-prop command.
For more information about the list-webapp-firewall-rulesets and get-webapp-firewall-prop commands, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
You can remove rule set files by using either the administration console or the CLI.
Note:
The CLI examples in this section are shown in shell mode (tadm>). For information about invoking the CLI shell, see Section 2.3.1, "Accessing the Command-Line Interface."
Removing Rule Set Files Using the Administration Console
To remove rule set files for a particular virtual server:
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to delete rule set files.
On the Web Application Firewall page, either click and select individual rule files or click the Name check box to select all the rule files.
Click the Delete button. At the confirmation prompt, click OK.
A message is displayed in the Console Message pane confirming that the rule set files were deleted.
In addition, the Deployment Pending message is displayed at the top of the main pane. You can either deploy the updated configuration immediately by clicking Deploy Changes, or you can do so later after making further changes, as described in Section 4.3, "Deploying a Configuration."
Removing Rule Set Files Using the CLI
To remove rule set files for a particular virtual server, run the delete-webapp-firewall-ruleset command, as shown in the following example:
tadm> delete-webapp-firewall-ruleset --config=soa --vs=vs1 modsecurity_crs_20_protocol_violations.conf OTD-70201 Command 'delete-webapp-firewall-ruleset' ran successfully.
For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about delete-webapp-firewall-ruleset, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
Note:
The disable-webapp-firewall command can be used to disable a web application firewall. For more information, see the Oracle Traffic Director Command-Line Reference.
Oracle Traffic Director supports various ModSecurity 2.6 directives, variables, operators, actions, functions, persistent Storages and phases.
Supported Web Application Firewall Directives
Oracle Traffic Director supports the following ModSecurity 2.6 directives. For more information and to see the full list of ModSecurity directives, including unsupported directives, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directives.
SecAction SecArgumentSeparator SecAuditEngine SecAuditLog SecAuditLog2 SecAuditLogDirMode SecAuditLogFileMode SecAuditLogParts SecAuditLogRelevantStatus SecAuditLogStorageDir SecAuditLogType SecComponentSignature SecContentInjection SecCookieFormat SecDataDir (see note below) SecDebugLog SecDefaultAction SecDebugLogLevel SecGeoLookupDb SecInterceptOnError SecMarker SecPcreMatchLimit (see note below) SecPcreMatchLimitRecursion (see note below) SecRequestBodyAccess SecRequestBodyInMemoryLimit (see note below) SecRequestBodyNoFilesLimit (see note below) SecRequestBodyLimitAction SecResponseBodyAccess SecResponseBodyLimit SecResponseBodyLimitAction (see note below) SecResponseBodyMimeType SecResponseBodyMimeTypesClear SecRule SecRuleEngine (see note below) SecRuleRemoveById SecRuleRemoveByMsg SecRuleRemoveByTag SecRuleUpdateActionById SecRuleUpdateTargetById SecTmpDir SecUnicodeMapFile (see note below) SecUnicodeCodePage (see note below) SecUploadDir SecUploadFileLimit SecUploadFileMode SecUploadKeepFiles SecWebAppId (see note below) SecCollectionTimeout
Note:
SecWebAppId can be specified within virtual server specific web application firewall configuration file to associate the application namespace to a particular virtual server.
The directive SecRequestBodyLimitAction enables you to set action against requests that hit SecRequestBodyNoFilesLimit. However, the directive SecRequestBodyLimit is not supported by Oracle Traffic Director and hence, you cannot set action against this directive.
Oracle Traffic Director does not support the directive SecRequestBodyLimit, which is used for configuring the maximum request body size that ModSecurity accepts for buffering. In place of this directive, the following options can be used:
Option 1: Use the directives, SecRequestBodyNoFilesLimit and SecRequestBodyLimitAction. Example:
SecRequestBodyNoFilesLimit 100 SecRequestBodyLimitAction Reject
Option 2: For Reject behavior, Oracle Traffic Director can be configured to check a request's Content-Length header in obj.conf. In addition, max-unchunk-size value can be set in server.xml.
Similarly, for ProcessPartial behavior, body-buffer-size element in server.xml can be set to the desired limit. In this case, only the first part of the body that fits the limit is processed and the rest is passed through.
If the directive SecRuleEngine is specified within the configuration file(s) specified by the webapp-firewall-ruleset element, then it will be ignored. However, this condition is not applicable if SecRuleEngine is set to DetectionOnly mode.
The directive SecRequestBodyInMemoryLimit is ignored if the header Content-Type is set to x-www-form-urlencoded.
The directives SecDataDir, SecPcreMatchLimit, SecPcreMatchLimitRecursion, SecUnicodeCodePage, and SecUnicodeMapFile can only be used at configuration level. The scope of these directives is considered to be Main. All the other directives can be used at both virtual server level and configuration level. The scope of these directives is considered to be Any. If a directive with Main scope is specified within the virtual server level configuration file, then an error will be logged and the server will fail to start.
Supported Web Application Firewall Variables
Oracle Traffic Director supports the following ModSecurity 2.6 variables. For more information and to see the full list of ModSecurity variables, including the unsupported variables, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Variables.
ARGS ARGS_COMBINED_SIZE ARGS_GET ARGS_GET_NAMES ARGS_NAMES ARGS_POST ARGS_POST_NAMES AUTH_TYPE DURATION ENV FILES FILES_COMBINED_SIZE FILES_NAMES FILES_SIZES GEO HIGHEST_SEVERITY MATCHED_VAR MATCHED_VARS MATCHED_VAR_NAME MATCHED_VARS_NAMES MODSEC_BUILD MULTIPART_BOUNDARY_QUOTED MULTIPART_BOUNDARY_WHITESPACE MULTIPART_DATA_AFTER MULTIPART_DATA_BEFORE MULTIPART_FILE_LIMIT_EXCEEDED MULTIPART_HEADER_FOLDING MULTIPART_INVALID_QUOTING MULTIPART_INVALID_HEADER_FOLDING MULTIPART_LF_LINE MULTIPART_MISSING_SEMICOLON MULTIPART_CRLF_LF_LINES MULTIPART_STRICT_ERROR MULTIPART_UNMATCHED_BOUNDARY PERF_COMBINED PERF_GC PERF_LOGGING PERF_PHASE1 PERF_PHASE2 PERF_PHASE3 PERF_PHASE4 PERF_PHASE5 PERF_SREAD PERF_SWRITE QUERY_STRING REMOTE_ADDR REMOTE_PORT REMOTE_USER REQBODY_ERROR REQBODY_ERROR_MSG REQBODY_PROCESSOR REQBODY_PROCESSOR_ERROR REQUEST_BASENAME REQUEST_BODY (see note below) REQUEST_BODY_LENGTH REQUEST_COOKIES REQUEST_COOKIES_NAMES REQUEST_FILENAME REQUEST_HEADERS (see note below) REQUEST_HEADERS_NAMES REQUEST_LINE REQUEST_METHOD REQUEST_PROTOCOL REQUEST_URI REQUEST_URI_RAW RESPONSE_BODY RESPONSE_CONTENT_LENGTH RESPONSE_CONTENT_TYPE RESPONSE_HEADERS RESPONSE_HEADERS_NAMES RESPONSE_PROTOCOL RESPONSE_STATUS RULE SERVER_ADDR SERVER_NAME SERVER_PORT SESSIONID TIME TIME_DAY TIME_EPOCH TIME_HOUR TIME_MIN TIME_MON TIME_SEC TIME_WDAY TIME_YEAR TX UNIQUE_ID URL_ENCODED_ERROR USERID WEBAPPID WEBSERVER_ERROR_LOG (see note below) XML
Note:
The REQUEST_BODY variable, which holds raw request body, will contain the body content that is available after it passes through other filters.
In open source ModSecurity, apache error log for each request/response can be collected and stored in the WEBSERVER_ERROR_LOG variable, and printed in the auditlog action. However, Oracle Traffic Director does not support this feature.
As request headers with the same name are concatenated into a single one, the header count is always 1. Hence, &REQUEST_HEADERS:<any header name> will always return 1 in spite of how many same request headers were sent.
Supported Web Application Firewall Operators
Oracle Traffic Director supports the following ModSecurity 2.6 operators. For more information and to see the full list of ModSecurity operators, including unsupported operators https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Operators.
beginsWith contains containsWord endsWith eq ge geoLookup gt inspectFile ipMatch le lt pm pmf pmFromFile rbl (see note below) rx streq strmatch validateByteRange validateDTD validateSchema validateUrlEncoding validateUtf8Encoding verifyCC verifyCPF verifySSN within
Note:
ModSecurity 2.6 does not support the directive SecHttpBlKey. Hence use of Project Honey Pot (dnsbl.httpbl.cong) as RBL, which requires SecHttpBlKey, is not supported.
Supported Web Application Firewall Actions
Oracle Traffic Director supports the following ModSecurity 2.6 actions. For more information and to see the full list of ModSecurity actions, including the unsupported actions, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Actions.
allow append auditlog (see note below) block capture chain ctl deny (see note below) deprecatevar drop (see note below) exec expirevar id initcol log logdata msg multiMatch noauditlog nolog pass pause phase prepend redirect rev sanitiseArg sanitiseMatched sanitiseMatchedBytes sanitiseRequestHeader sanitiseResponseHeader severity setuid setsid setenv setvar skip skipAfter status t tag xmlns
Note:
In open source ModSecurity, apache error log for each request/response can be collected and stored in the WEBSERVER_ERROR_LOG variable, and printed in the auditlog action. However, Oracle Traffic Director does not support this feature.
Actions that change HTTP response status, such as deny, will not successfully change the response status when it is invoked in phase 4. In such a scenario, the following error message is logged in the server log:
" ModSecurity: Access denied with code 403 (phase 4)."
When drop action is invoked in phase 4, Oracle Traffic Director will send out HTTP headers to the client and then drop the connection.
When deny action is invoked in phase 4, Oracle Traffic Director strips the response body, instead of sending 403 response status. This might cause the following warning to appear in the server log:
Response content length mismatch (0 bytes with a content length of <original content length>)
Supported Web Application Firewall Transformation Functions
Oracle Traffic Director supports the following ModSecurity 2.6 transformation functions. For more information and to see the full list of ModSecurity transformation functions, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Transformation_functions.
base64Decode sqlHexDecode base64DecodeExt base64Encode cmdLine compressWhitespace cssDecode escapeSeqDecode hexDecode hexEncode htmlEntityDecode jsDecode length lowercase md5 none normalisePath normalisePathWin parityEven7bit parityOdd7bit parityZero7bit removeNulls removeWhitespace replaceComments removeCommentsChar removeComments replaceNulls urlDecode urlDecodeUni urlEncode sha1 trimLeft trimRight trim
Supported Web Application Firewall Persistent Storages
Oracle Traffic Director supports the following ModSecurity 2.6 persistent storages. For more information and to see the full list of ModSecurity persistent storages, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Persistant_Storage.
GLOBAL IP RESOURCE SESSION USER
Supported Web Application Firewall Phases
Oracle Traffic Director supports the following ModSecurity 2.6 phases. For more information and to see the full list of ModSecurity phases, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phases.
Phase:1 - Request headers stage Phase:2 - Request body stage Phase:3 - Response headers stage Phase:4 - Response body stage Phase:5 - Logging
Note:
Actions that change HTTP response status, such as deny, will not successfully change the response status when it is invoked in phase 4.
When drop action is invoked in phase 4, Oracle Traffic Director will send out HTTP headers to the client and then drop the connection.
When deny action is invoked in phase 4, Oracle Traffic Director strips the response body, instead of sending 403 response status. This might cause the following warning to appear in the server log:
Response content length mismatch (0 bytes with a content length of <original content length>)
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
