9 Configuring Integration with BIG-IP ASM

Topics

About the Integration of Oracle AVDF with BIG-IP ASM

This chapter discusses integration of Audit Vault and Database Firewall (Oracle AVDF), 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 9-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 AVDF and BIG-IP ASM Integration".

Figure 9-1 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit

Description of Figure 9-1 follows
Description of ''Figure 9-1 Oracle AVDF with F5 BIG-IP ASM Data Flow Unit''

The 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 the 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 to the Database Firewall additional information about the SQL statements sent to the database, including the Web user name and IP address of the Web user who originated them. This information is not usually available from the SQL statements generated by the Web application server.

The information obtained from BIG-IP ASM, and from the Database Firewall system itself, is logged by the 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.

Summary of Key Benefits

The key benefits of this integration are:

  • Improves security through a partnership of the two systems.

  • Allows Oracle AVDF to provide detailed information about the origin and context of the SQL statements from the Web application layer.

  • Enables Oracle AVDF 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.

How the Integration Works

The integration works by using a syslog messaging system to deliver alerts from BIG-IP ASM. Standard BIG-IP ASM syslog messages enabled through the ASM logging profile provide details of each alert, such as the secured target client's IP address and other attributes of the session.

A BIG-IP ASM iRule™ is set up, which generates a syslog message during a user login to provide the Web username. Oracle AVDF provides a sample iRule, which must 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 Oracle AVDF. Oracle AVDF 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 the cookie's name starts with "TS"). The cookie and the name of the user is sent to Oracle AVDF by a syslog message generated by the iRule on the ASM. 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 AVDF 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 Web users.

Oracle AVDF can automatically relay all syslog messages received from BIG-IP ASM to an external syslog server, up to a maximum size of 2KB each. If required, syslog messages generated by Oracle AVDF itself can be routed to the same destination. Oracle AVDF does not alter the BIG-IP ASM syslog traffic in any way.

Oracle AVDF 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.

Deploying the Oracle AVDF and BIG-IP ASM Integration

Topics

About the Deployment

Deploying BIG-IP ASM with Oracle AVDF requires the configuration of a few straightforward settings in both systems, and the customization of an iRule so that it matches the Web application's configuration.

System Requirements

The integration requires:

  • Oracle AVDF

  • F5 BIG-IP ASM versions 9.4.5, 10, or 11. Other F5 products, such as FirePass®, BIG-IP LTM™, BIG-IP GTM™, WebAccelerator™ or WANJet® are not currently supported.

Visit the F5 Web site for the latest information on BIG-IP ASM: http://www.f5.com/

Configuring Oracle AVDF to Work with F5

You can configure Oracle AVDF to operate with F5 BIG-IP ASM only after you have configured the enforcement point for the secured target.

To configure Oracle AVDF to operate with F5 BIG-IP ASM for a secured target:

  1. Ensure that an enforcement point has been defined for this secured target.

    See "Configuring Enforcement Points".

  2. Log in to the Audit Vault Server console as an administrator.

  3. Click the Secured Targets tab, and then from the Monitoring menu, click Enforcement Points.

  4. Click the name of the enforcement point that monitors this secured target.

  5. Click Advanced.

  6. Complete the options:

    • System Address: This read-only information shows the IP address of the Database Firewall associated with this enforcement point. BIG-IP ASM must send syslog messages to this address and port.

    • WAF Addresses: Delete the word DISABLED, and enter the IP address of each BIG-IP ASM system that generates syslog messages to send to the Database Firewall. Separate each IP address with a space character.

    • Disable WAF Alert Forwarding: Select this check box to stop the Database Firewall from forwarding syslog messages. The current status of alert forwarding is displayed below this option.

    • Destination Host and Dest 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 Database Firewall. The 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 Database Firewall itself.

    • Enhance reports with WAF logging data: Select this check box to enable the Database Firewall to record BIG-IP ASM attributes obtained from the syslog messages, such as the IP address and name of the Web application user. If this box is not checked, the Database Firewall will not attempt to match F5 and Database Firewall SQL messages.

    • Cookie Prefixes: F5 adds cookies, with a standard prefix, to the pages it serves up. If necessary change the prefix of these cookies in this field. The Database Firewall searches for cookies with this prefix.

    • 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 Oracle AVDF. Use Server IP and Server Port, for example 5514, to specify the IP address of the Database Firewall (this is the same IP address used to connect to the firewall's Administration console). 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 for F5 v9, or request_status for F5 v10 and v11

  • response_code

  • method

  • protocol

  • uri

  • query_string

  • ip for F5 v9, or ip_client for F5 v10 and v11

  • web_application_name (http_class_name for F5 v11.2)

  • 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 AVDF 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 Database Firewall, which logs the username against SQL statements generated by the Web application server.

The sample iRule provided with Oracle AVDF 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 secured target IP address of the Web client.

  • [ClientPort] is the secured target 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 AVDF does not use this information, other than to report the authentication method used.

    For example:

    Rule capture_login_rule HTTP_REQUEST_DATA:
DBFIREWALL:CLIENT=192.0.2.1:443,ASPSESSIONIDSASSBSCD=1234,TS10da7b=23545,
  USERNAME=FredBloggs,AUTHMETHOD=webforms

Configuring syslog-ng.conf

To enable the iRule syslog messages to be transmitted to Oracle AVDF, it is necessary to log in to the BIG-IP hardware platform and execute the BIG-IP ASM commands listed below for the version you are using. Doing so modifies /etc/syslog-ng /syslog-ng.conf (do not modify the file directly, because changes will not persist after you restart the system).

For BIG-IP ASM Version 11

To configure syslog-ng.conf:

  1. Run this command:

    modify sys syslog remote-servers add {dbfw_server_name {host dbfw_IP_address remote-port dbfw_port}}

    Where dbfw_server_name is the name of your Database Firewall server, and dbfw_IP_address and dbfw_port are the IP address and port number of the Database Firewall. For example:

    modify sys syslog remote-servers add { d_dbfw {host 192.0.2.181 remote-port 5514}}

  2. Save the system configuration:

    save sys config

For All Other Supported BIG-IP ASM Versions

To configure syslog-ng.conf, run this command:

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 Database Firewall (the value entered for System Address in Step 6).

For example (the IP address and port will be different for each enforcement point):

bigpipe syslog include "destination d_dbfw { tcp(\"192.0.2.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.

Viewing F5 Data in Oracle AVDF Reports

You can generate several reports from the Audit Vault Server console. These reports are listed in the Database Firewall F5 Reports table in the Oracle Audit Vault and Database Firewall Auditor's Guide.