Skip Headers
Oracle® Database Firewall Administration Guide
Release 5.0

Part Number E18695-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Using Oracle Database Firewall with BIG-IP ASM

This appendix contains:

About the Integration of Oracle Database Firewall with BIG-IP ASM

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

Description of Figure 11-1 follows
Description of "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.

Key Benefits of Integrating Oracle Database Firewall with BIG-IP ASM

The key benefits of the integration are as follows:

How the Integration Works

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 format

Deploying the Oracle Database Firewall-BIG-IP ASM Integration

This section contains the following topics:

About the Deployment

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.

System Requirements

The integration requires:

  • 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/

Configuring Oracle Database Firewall

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:

  1. Log in to the Administration Console for the Management Server.

    See "Logging in to the Administration Console" for more information.

  2. Ensure that an enforcement point has been defined for the protected database.

  3. Click the Monitoring tab.

    The enforcement points are listed, as shown next.

    Description of f5_002.gif follows
    Description of the illustration f5_002.gif

  4. Click Advanced for the enforcement point that will monitor the protected database.

  5. 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.

Configuring BIG-IP ASM

This section describes how to create the logging profile and write policy settings.

Logging Profile

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.

Policy Settings

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

Developing a BIG-IP ASM iRule

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"
       }
}
}

Required Syslog Message Format

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
    

Configuring syslog-ng.conf

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.

Presentation of Data in Oracle Database Firewall

This section contains the following topics:

Administration Console Dashboard

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".

Viewing the Traffic Log Generated by BIG-IP ASM

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:

  1. Log in to the Administration Console for the Management Server.

    See "Logging in to the Administration Console" for more information.

  2. Click the Reporting tab.

  3. Select Search Log from the Traffic Log menu. The page shown next is displayed.

    Description of f5_008.gif follows
    Description of the illustration f5_008.gif

  4. 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.

  5. When the Searches page indicates that the search is complete, click the report title.

    The Search Results page displays the statements found.

Understanding the Attributes

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.

Web Application Firewall (WAF) Reports

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.