This appendix contains:
About the Integration of Oracle Database Firewall with BIG-IP ASM
Key Benefits of Integrating Oracle Database Firewall with BIG-IP ASM
Deploying the Oracle Database Firewall-BIG-IP ASM Integration
This chapter discusses integration of Oracle Database Firewall, BIG-IP Application Security Manager (ASM), Web clients, and the Web application server, how the integration works, and its key benefits.
BIG-IP Application Security Manager (ASM), from f5 Networks, Inc., is an advanced Web Application Firewall (WAF) that provides comprehensive edge-of-network protection against a wide range of Web-based attacks.
BIG-IP ASM is deployed between the Web clients and the Web application server, see Figure 11-1. It analyzes each HTTP and HTTPS request, and blocks potential attacks before they reach the Web application server. BIG-IP ASM can be installed on a wide range of BIG-IP platforms, see "Deploying the Oracle Database Firewall-BIG-IP ASM Integration".
The integration of Oracle Database Firewall with BIG-IP ASM works well with an ArcSight SIEM integration. See Chapter 12, "Using Oracle Database Firewall with ArcSight SIEM," for more information.
Figure 11-1 Oracle Database Firewall with F5 BIG-IP ASM Data Flow Unit
Oracle Database Firewall is deployed between the Web application server and database. It provides protection against attacks originating from inside or outside the network and works by analyzing the intent of the SQL statements sent to the database. It is not dependent on recognizing the syntax of known security threats, and can therefore block previously unseen attacks, including those targeted against an organization.
A deployment that includes both BIG-IP ASM and Oracle Database Firewall provides all the security benefits of both products and enables the two systems to work in partnership to reach unparalleled levels of data security.
A key benefit of the integration is that it allows BIG-IP ASM to pass Oracle Database Firewall additional information about the SQL statements sent to the database, including the actual name and IP address of the Web user who originated them. This information is not directly available from the SQL statements generated by the Web application server.
The information obtained from BIG-IP ASM, and from the Oracle Database Firewall system itself, is logged by Oracle Database Firewall as attributes of the appropriate statements. Once the data has been logged, it can be retrieved in views of the traffic logs to give complete visibility into the source and nature of any attacks.
The key benefits of the integration are as follows:
Improves security through a partnership of the two systems.
Allows Oracle Database Firewall to provide detailed information about the origin and context of the SQL statements from the Web application layer.
Enables Oracle Database Firewall to act as a log store for data generated by BIG-IP ASM.
Provides "layered" security at the edge of the network, and close to the database.
The integration works by using a syslog messaging system to deliver alerts from the Web application firewall. Standard BIG-IP ASM syslog messages enabled through the ASM logging profile provide details of each alert, such as the user's source IP address and other attributes of the session.
In addition, an optional BIG-IP ASM iRule™ can be set up, which generates a syslog message during a user login to provide the Web username. Oracle Database Firewall provides a sample iRule, which can be customized to match the specific login procedures of the Web application. See "Developing a BIG-IP ASM iRule".
During the deployment procedure, BIG-IP ASM is set up to route all its syslog messages to an Oracle Database Firewall. The Oracle Database Firewall attempts to match each relevant BIG-IP ASM syslog message with the appropriate SQL statements generated by the Web application server. If a match is found, it extracts the information contained in the BIG-IP ASM syslog message, and stores that information as attributes of the logged SQL statements. If a match is not found, a separate record is added to the traffic log, containing the attributes from the syslog message.
The software uses cookies to match SQL statements with Web users. When the user logs in, BIG-IP ASM assigns a unique cookie to that user (normally a "TS" cookie). The cookie and the name of the user is sent to the Oracle Database Firewall by a syslog message generated by the Oracle Database Firewall iRule. If the user's actions cause an alert or other event, BIG-IP ASM generates an additional syslog message containing the same identifying cookie, which enables the software to match the syslog message with the specific user. Since the Oracle Database Firewall system is also able to match syslog messages with SQL statements, this enables individual SQL statements relating to potential threats to be attributed to specific users.
The Oracle Database Firewall can automatically relay all syslog messages received from BIG-IP ASM to an external syslog server, up to a maximum size of 2kB. If required, syslog messages generated by the Oracle Database Firewall itself can be routed to the same destination. The Oracle Database Firewall does not alter the BIG-IP ASM syslog traffic in any way.
The Oracle Database Firewall monitors the status of the connection to BIG-IP ASM, and generates syslog messages every two minutes if the connection is not present or has been lost.
See Also:
Appendix C, "Syslog Message Format," for more information about the syslog formatThis section contains the following topics:
Deploying BIG-IP ASM with Oracle Database Firewall requires the configuration of a few straightforward settings in both systems, and the optional customization of an iRule to provide the Web application user's name.Deploying BIG-IP ASM with Oracle Database Firewall requires the configuration of a few straightforward settings in both systems, and the optional customization of an iRule to provide the Web application user's name.
Oracle Database Firewall
F5 BIG-IP ASM version 9.4.5 and version 10. Other F5 products, such as FirePass®, BIG-IP LTM™, BIG-IP GTM™, WebAccelerator™ or WANJet® are not currently supported.
At the time of publishing this guide, BIG-IP ASM is supported on BIG-IP 3600, 4100, 6900, 8400, and 8800 hardware platforms. If necessary, visit the f5 Web site for the latest information. The URL is:
http://www.f5.com/
Configuration of Oracle Database Firewall to operate with F5 BIG-IP ASM can be carried out only after the enforcement point(s) have been set up for the protected database.
To configure Oracle Database Firewall to operate with F5 BIG-IP ASM:
Log in to the Administration Console for the Management Server.
See "Logging in to the Administration Console" for more information.
Ensure that an enforcement point has been defined for the protected database.
Click the Monitoring tab.
The enforcement points are listed, as shown next.
Click Advanced for the enforcement point that will monitor the protected database.
Complete the options:
System Address: This read-only information shows the IP address of the Oracle Database Firewall, as set up in the System Settings page. BIG-IP ASM must send syslog messages to this address and port.
WAF Addresses: Enter the IP address of each BIG-IP ASM system that generates syslog messages to send to the Oracle Database Firewall. Separate each IP address with a space character.
Destination Host and TCP Port: Specify the IP address and port number of the syslog server that is to receive the BIG-IP ASM syslog messages forwarded by the Oracle Database Firewall. The Oracle Database Firewall relays these messages unmodified.
The IP address does not need to be the same as the syslog destination used for syslog messages generated by the Oracle Database Firewall itself.
Disable WAF Alert Forwarding: Select this check box to stop the Oracle Database Firewall from forwarding syslog messages. The current status of alert forwarding is displayed below this option.
Enhance reports with WAF logging data: Select this check box to enable the Oracle Database Firewall traffic log to record BIG-IP ASM attributes obtained from the syslog messages, such as the IP address and name of the Web application user.
Session Idle Timeout: The user's cookie is stored only for the length of time specified in this field. This enables the same cookie to be used by different users, providing the time period specified here has elapsed.
Exclude Addresses: You can specify a list of IP addresses of Web application servers or other SQL-generating sources to ignore for reporting purposes. For example, you may want to add the IP address of an internal Web application server.
This section describes how to create the logging profile and write policy settings.
Configure the Web application's logging profile to send BIG-IP ASM syslog messages to the Oracle Database Firewall. Use Server IP and Server Port to specify the IP address of the Oracle Database Firewall (this is the same IP address used to connect to the Administration Console), and a port number of 5514. Select TCP for the Protocol.
The Selected Items box must include the following attributes:
violations
unit_hostname
management_ip_address
policy_name
policy_apply_date
x_forwarded_for_header_value
support_id
request_blocked
response_code
method
protocol
uri
query_string
ip
web_application_name
request
Note:
The attributes must appear in the Selected Items box in the order shown here.In the policy settings, enable the required events to send through the syslog (refer to the ASM help if you are not sure how to do this).
Oracle Database Firewall recognizes the following events:
Evasion technique detected
Request length exceeds defined buffer size
Illegal dynamic parameter value
Illegal meta character in header
Illegal meta character in parameter value
Illegal parameter data type
Illegal parameter numeric value
Illegal parameter value length
Illegal query string or POST data
Illegal static parameter value
Parameter value does not comply with regular expression
Attack signature detected
Illegal HTTP status in response
Optionally, an iRule can be used to monitor the login page and generate a syslog message each time a user logs into the Web application. The syslog message contains the username of the Web application user, and the cookies associated with that user. The message is routed to the Oracle Database Firewall, which logs the username against SQL statements generated by the Web application server.
The sample iRule provided by Oracle Database Firewall contains the required format of the syslog message, but must be customized to handle the specific login requirements of your Web application.
# F5 BIG-IP example iRule # Description: Capture username and cookies from user login to web application # # Global variable definitions and other initialisation logic goes here when RULE_INIT { ### Customise this to suit your application # The page that user logins from set ::login_page "/login.asp" # The name of the field holding the user name set ::login_parameter_name "Uname" # The method of authentiaction which will be sent to Oracle Database Firewall set ::auth_method "webforms" # HTTP protocol methods that is used by the login form set ::login_method "POST" ### Don't change these # Limit the length of the HTTP request for safety set ::max_header_content_length 5242880 # Log iRule trace messages to /var/log/ltm? 1=yes, 0=no # Must be set to 0 for production systems set ::payload_debug 0 } # HTTP request received, check if it's a login request and start assembling the # data when HTTP_REQUEST { # Log the debug message if trace is enabled if {$::payload_debug}{log local3. "[IP::client_addr]:[TCP::client_port]: New HTTP [HTTP::method] request to [HTTP::host][HTTP::uri]"} # Reset cookies to empty, later used as an indicator of the fact that # login HTTP request has been received set cookie_all "" # If the request is to the login page populate cookie_all variable with # all the cookies received if {[HTTP::path] starts_with $::login_page and [HTTP::method] eq $::login_method} { set cookie_name [HTTP::cookie names] for {set c 0}{$c < [HTTP::cookie count]}{incr c}{ set cookie_string [split [lindex $cookie_name $c] " "] set cookie_list $cookie_string=[HTTP::cookie [lindex $cookie_string 0]] append cookie_all "," $cookie_list } # Log the debug message if trace is enabled if {$::payload_debug}{log local3. "[IP::client_addr]:[TCP::client_port]: Matched path and method check"} # Validate the Content-Length value and set the content_length variable if {[HTTP::header value Content-Length] > $::max_header_content_length } {set content_length $::max_header_content_length } else { set content_length [HTTP::header value Content-Length] } # Get the payload data if {$content_length > 0}{ HTTP::collect $content_length # Log the debug message if trace is enabled if {$::payload_debug}{log local3. "[IP::client_addr]:[TCP::client_port]: Collecting $content_length bytes"} } } } # Got the data, parse them and generate the syslog message when HTTP_REQUEST_DATA { # If cookies are present this is a login request, get the user name if {$cookie_all != "" } { # Log the debug message if trace is enabled if {$::payload_debug}{log local3. "[IP::client_addr]: [TCP::client_port]: Collected request data: [HTTP::payload]"} # Reset the error flag to 0 set uname_logged 0 # Find the $::login_parameter_name among the parameters in the request and extrat its value set param_value_pairs [split [HTTP::payload] "&"] for {set i 0} {$i < [llength $param_value_pairs]} {incr i} { set params [split [lindex $param_value_pairs $i] "="] if { [lindex $params 0] equals $::login_parameter_name } { # User name was found, generate the syslog message # which includes IP, port, all the cookies, user name and # the auth_method string set username [lindex $params 1] log local3. "DBFIREWALL:CLIENT=[IP::client_ addr]:[TCP::client_port]$cookie_all, USERNAME=$username,AUTHMETHOD=$::auth_method" # Set the flag so not to trigger the error reporting log message below set uname_logged 1 break } } # If user name has not been found in parameters log an error if {$uname_logged == 0 } { log local0. "ERROR: iRule failed to extract user name from page $login_page with parameter $login_parameter_name" } } }
The required format of the syslog message to be generated by the custom iRule is as follows:
Rule [iRuleName] HTTP_REQUEST_DATA: DBFIREWALL:CLIENT=[ClientIPAddress]:[ClientPort],[Cookies], USERNAME=[Name],AUTHMETHOD=[AuthMethod]
In this specification:
[iRuleName
] is the name of the iRule
.
[ClientIPAddress
] is the source IP address of the Web client.
[ClientPort
] is the source port number of the Web client.
[Cookies
] is a list of cookies available from the BIG-IP ASM HTTP object.
[Name
] is the user name.
[AuthMethod
] is the method of authentication used between the F5 Web server and its Web clients, as set up in BIG-IP ASM. Oracle Database Firewall does not use this information, other than to report the authentication method used.
For example:
Rule capture_login_rule HTTP_REQUEST_DATA:
DBFIREWALL:CLIENT=10.190.0.1:443,ASPSESSIONIDSASSBSCD=1234,TS10da7b=23545,
USERNAME=FredBloggs,AUTHMETHOD=webforms
To enable the iRule syslog messages to be transmitted to the Oracle Database Firewall, it is necessary to log in to the BIG-IP hardware platform and execute the following BIG-IP ASM command, which modifies /etc/syslog-ng /syslog-ng.conf
(do not modify the file directly, because changes will not persist after you restart the system):bigpipe syslog include
"destination d_dbfw { tcp(\"dbfw_ip_address\" port(dbfw_port));};log { source(local); filter(f_local3); destination(d_dbfw);};"
Where dbfw_ip_address
and dbfw_port
are the IP address and port number of the Oracle Database Firewall. For example:
bigpipe syslog include
'"destination d_dbfw { tcp(\"192.168.0.181\" port(5514));};log { source(local); filter(f_local3); destination(d_dbfw);};"'
The two instances of the syslog destination name (d_dbfw
) need to be changed only in the unlikely event that the destination name is already in use. The port number is normally 5514.
This section contains the following topics:
The Dashboard page of the Oracle Database Firewall Administration Console provides an overview of the top-ten threats by Web user, statistics about any blocked statements, and the current status of the link to BIG-IP ASM. You may want to display this information to obtain an overview of the threats and to confirm that the system is operational.
To display the information, log in to the Oracle Database Firewall Administration Console, and display the Dashboard page.
Two areas are provided on the Dashboard page for WAF information:
WAF Status: This provides the current status of the link to BIG-IP ASM (on the top line), and the following statistics:
Policy Confirmed: The number of BIG-IP ASM syslog messages over the last hour that have been matched with SQL statements and generated an Oracle Database Firewall "block" or "warn".
Policy Conflict: The number of BIG-IP ASM syslog messages over the last hour that have been matched with SQL statements, but did not generate an Oracle Database Firewall "block" or "warn".
Matched: The number of BIG-IP ASM syslog messages that have been successfully matched with SQL statements over the last hour.
Unmatched: The number of BIG-IP ASM syslog messages that have not been successfully matched with SQL statements over the last hour.
Events in Last Hour: The total number of syslog messages from BIG-IP ASM over the last hour.
Top Ten Threats by Web User: This lists the most significant threats over the indicated period of time. The threats are listed by Web username. Each row is for a separate user.
Clicking a user lists all attacks made by the user.
Note:
The WAF sections appear on the Dashboard when the WAF settings have been configured, as described on "Web Application Firewall (WAF) Reports".You can display the data collected from BIG-IP ASM by viewing the traffic log in the Oracle Database Firewall Administration Console. The traffic log stores:
Each SQL statement that has been logged by the Oracle Database Firewall, and the attributes associated with each statement. The attributes include the data from the Oracle Database Firewall system (such as the threat severity and action level), and if available, data obtained from any BIG-IP ASM syslog messages that have been matched with the SQL statement.
Each violation reported by a BIG-IP ASM syslog message that has not been matched with an SQL statement.
To display the traffic log:
Log in to the Administration Console for the Management Server.
See "Logging in to the Administration Console" for more information.
Click the Reporting tab.
Select Search Log from the Traffic Log menu. The page shown next is displayed.
Enter a title, and specify the search conditions to use to obtain the required records from the traffic log. Click Search.
See Oracle Database Firewall Security Management Guide for more information about accessing the Search Traffic Log page.
When the Searches page indicates that the search is complete, click the report title.
The Search Results page displays the statements found.
The attributes shown with the Oracle Database Firewall logo are obtained from the Oracle Database Firewall system. Those with an f5 logo are obtained or derived from BIG-IP ASM. See Appendix D, "Traffic Log Attributes" for details of the attributes.
You can generate several reports from the Oracle Database Firewall Administration Console, including the following:
F5 Alerts Blocked by F5: All alerts blocked by BIG-IP ASM.
F5 Confirmed Alert: Alerts detected by BIG-IP ASM that generate a "block" or "warn" in Oracle Database Firewall.
F5 Incident Report: List of all incidents by time.
F5 Incident Summary by User: List of incidents grouped by user.
F5 Incident Summary by Cluster: List of incidents grouped by cluster of SQL statements.
F5 No WAF Match: Alerts detected by BIG-IP ASM that Oracle Database Firewall has not matched with SQL statements.
F5 Policy Conflict: Alerts detected by BIG-IP ASM that do not cause a "block" or "warn" in Oracle Database Firewall.
F5 Policy Conflict by User: Policy Conflict report grouped by user.