F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Integrating ASM and APM with Database Security Products
Manual Chapter : Integrating ASM and APM with Database Security Products

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Overview: Integrating ASM and APM with database security products

You can deploy Application Security Manager (ASM) and Access Policy Manager(APM) with database security products, such as IBM InfoSphere Guardium to increase security visibility, receive alerts about suspicious activity, and prevent attacks. When integrated with database security, ASM can provide information about each HTTP request and database query. This allows the database security system to correlate the web transaction with the database query to make a security assessment of the transaction. ASM also provides application level details to improve the database security system's logging and reporting.

For you to integrate ASM with a database security product, the database security server itself must have been configured and accessible on the network. On the BIG-IP system, you specify the host name or IP address of the database security server. Then, you enable database security integration for one or more security policies that are set up to protect web application resources.

When using database security, Application Security Manager monitors web application traffic and sends information about the users, the requests, and reporting events to the database security server. The following figure shows an example of how ASM can integrate with the IBM InfoSphere Guardium Database Activity Monitoring Appliance.

Integrating ASM and APM with external database security example Integrating ASM and APM with external database security example

The security policy can get user names from requests using login pages configured from within ASM, or the policy can retrieve the user names from Access Policy Manager(APM). This implementation describes how to integrate ASM and APM with an external database security server. APM handles user authentication in this case and provides the information that is sent to the database security server.

Prerequisites for integrating ASM and APM with database security

In order to integrate a database security server from within Application Security Manager (ASM) so that the security policy retrieves the user names from Access Policy Manager (APM), you need to perform basic these system configuration tasks according to the needs of your networking configuration:

  • Run the setup utility and create a management IP address.
  • License and provision ASM, APM, and Local Traffic Manager (LTM).
  • Configure a DNS address (System > Configuration > Device > DNS).
  • Configure an NTP server (System > Configuration > Device > NTP).
  • Restart ASM (at the command line, type tmsh restart /sys service asm).

Task Summary

Creating a VLAN

VLANs represent a collection of hosts that can share network resources, regardless of their physical location on the network. You create a VLAN to associate physical interfaces with that VLAN.
  1. On the Main tab, click Network > VLANs. The VLAN List screen opens.
  2. Click Create. The New VLAN screen opens.
  3. In the Name field, type a unique name for the VLAN.
  4. For the Interfaces setting, click an interface number from the Available list, and use the Move button to add the selected interface to the Untagged list. Repeat this step as necessary.
  5. Click Finished. The screen refreshes, and displays the new VLAN from the list.

Creating a self IP address for a VLAN

Ensure that you have at least one VLAN configured before you create a self IP address.
Self IP addresses enable the BIG-IP system, and other devices on the network, to route application traffic through the associated VLAN.
  1. On the Main tab, click Network > Self IPs. The Self IPs screen opens.
  2. Click Create. The New Self IP screen opens.
  3. In the Name field, type a unique name for the self IP.
  4. In the IP Address field, type an IPv4 or IPv6 address. This IP address should represent the address space of the VLAN that you specify with the VLAN/Tunnel setting.
  5. In the Netmask field, type the network mask for the specified IP address.
  6. From the VLAN/Tunnel list, select the VLAN to associate with this self IP address.
    • On the internal network, select the VLAN that is associated with an internal interface or trunk.
    • On the external network, select the VLAN that is associated with an external interface or trunk.
  7. Use the default values for all remaining settings.
  8. Click Finished. The screen refreshes, and displays the new self IP address.
The BIG-IP system can now send and receive TCP/IP traffic through the specified VLAN.

Creating a local traffic pool for application security

You can use a local traffic pool with Application Security Manager system to forward traffic to the appropriate resources.
Note: You can optionally create a pool as part of creating a security policy using the Deployment wizard.
  1. On the Main tab, click Local Traffic > Pools. The Pool List screen opens.
  2. Click Create. The New Pool screen opens.
  3. In the Name field, type a unique name for the pool.
  4. In the Resources area, for the New Members setting, add to the pool the application servers that host the web application:
    1. Type an IP address in the Address field.
    2. In the Service Port field, type a port number (for example, type 80 for the HTTP service), or select a service name from the list.
    3. Click Add.
  5. Click Finished.
The BIG-IP system configuration now includes a local traffic pool containing the resources that you want to protect using Application Security Manager.

Creating a virtual server to manage HTTPS traffic

You can create a virtual server to manage HTTPS traffic.
  1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
  2. Click the Create button. The New Virtual Server screen opens.
  3. In the Name field, type a unique name for the virtual server.
  4. For the Destination setting, in the Address field, type the IP address you want to use for the virtual server. The IP address you type must be available and not in the loopback network.
  5. For the Destination setting, select Host and in the Address field, type the IP address for the virtual server.
  6. In the Service Port field, type 443 or select HTTPS from the list.
  7. From the Configuration list, select Advanced.
  8. From the HTTP Profile list, select http.
  9. From the HTTP Compression Profile list, select one of the following profiles:
    • httpcompression
    • wan-optimized-compression
    • A customized profile
  10. Optional: From the Web Acceleration Profile list, select one of the following profiles:
    • optimized-acceleration
    • optimized-caching
    • webacceleration
    • A customized profile
  11. From the Web Acceleration Profile list, select one of the following profiles with an enabled application:
    • optimized-acceleration
    • optimized-caching
    • webacceleration
    • A customized profile
  12. For the SSL Profile (Client) setting, from the Available list, select clientssl, and using the Move button, move the name to the Selected list.
  13. Optional: From the SSL Profile (Server) list, select serverssl.
    Note: This setting ensures that there is an SSL connection between the HTTP virtual server and the external HTTPS server.
  14. From the Source Address Translation list, select Auto Map.
  15. From the Default Pool list, select the pool that is configured for application security.
  16. Click Finished.
The HTTPS virtual server appears in the Virtual Server List screen.

Creating a security policy automatically

Before you can create a security policy, you must perform the minimal system configuration tasks including defining a VLAN, a self IP address, and other tasks required according to the needs of your networking environment.
Application Security Manager can automatically create a security policy that is tailored to secure your web application.
  1. On the Main tab, click Security > Application Security > Security Policies. The Active Policies screen opens.
  2. Click the Create button. The Deployment wizard opens to the Select Local Traffic Deployment Scenario screen.
  3. For the Local Traffic Deployment Scenario setting, specify a virtual server to use for the security policy.
    • To secure an existing virtual server that has no security policy associated with it, select Existing Virtual Server and click Next.
    • To create a new virtual server and pool with basic configuration settings, select New Virtual Server and click Next.
    • To create an active but unused security policy, select Do not associate with Virtual Server and click Next. No traffic will go through this security policy until you associate it with a virtual server. The Policy Builder cannot begin automatically creating a policy until traffic is going to ASM through the virtual server.
    The virtual server represents the web application you want to protect. The Configure Local Traffic Settings screen opens.
  4. Configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, name, IP address and port, pool IP address, and port.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy.
    • If you selected Do not associate with Virtual Server, you will have to manually associate the security policy with a virtual server at a later time. On the policy properties screen, you need to specify a name for the security policy.
    The name of the new or existing virtual server becomes the name of the security policy. The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a policy automatically and click Next. The Configure Security Policy Properties screen opens.
  6. From the Application Language list, select the language encoding of the application, or select Auto detect and let the system detect the language.
    Important: You cannot change this setting after you have created the security policy.
  7. If the application is not case-sensitive, clear the Security Policy is case sensitive check box. Otherwise, leave it selected.
    Important: You cannot change this setting after you have created the security policy.
  8. If you do not want the security policy to distinguish between HTTP and HTTPS URLs, clear the Differentiate between HTTP and HTTPS URLs check box. Otherwise, leave it selected.
  9. Click Next. The Configure Attack Signatures screen opens.
  10. To configure attack signatures, move the systems used by your web application from the Available Systems list into the Assigned Systems list. The system adds the attack signatures needed to protect the selected systems.
  11. For the Signature Staging setting, verify that the default option Enabled is selected.
    Note: Because the Real Traffic Policy Builder begins building the security policy in Blocking mode, you can keep signature staging enabled to make sure that false positives do not occur.
    New and updated attack signatures remain in staging for 7 days, and are not enforced (according to the learn, alarm, and block flags) during that time.
  12. Click Next. The Configure Automatic Policy Building screen opens.
  13. For Policy Type, select an option to determine the security features to include in the policy.
    Option Description
    Fundamental Creates a security policy enforcing HTTP protocol compliance, evasion techniques, explicit file types (including length checks), explicit parameters in selective mode at the global level, attack signatures, the violation Request Length Exceeds Defined Buffer Size, host names, header lengths, cookie lengths, the violation Failed to Convert Character, and learn explicit redirection domains.
    Enhanced Creates a security policy with all the elements of the Fundamental policy type; also checks for explicit URLs in selective mode plus meta characters, Explicit parameter length checks in selective mode at the global level, methods, explicit cookies, and content profiles.
    Comprehensive Creates a security policy with all the elements of the Enhanced policy type; also checks for explicit URLs and meta characters, explicit parameters and lengths at the URL level, parameter meta characters, and dynamic parameters.
    A bulleted list on the screen describes which security features are included in each type.
  14. For Rules, move the slider to set the Policy Builder learning speed.
    Option Description
    Fast Use if your application supports a small number of requests from a small number of sessions; for example, useful for web sites with less traffic. However, choosing this option may present a greater chance of adding false entities to the security policy.
    Medium Use if your application supports a medium number of requests, or if you are not sure about the amount of traffic on the application web site. This is the default setting.
    Slow Use if your application supports a large number of requests from many sessions; for example, useful for web sites with lots of traffic. This option creates the most accurate security policy, but takes Policy Builder longer to collect the statistics.
    Based on the option you select, the system sets greater or lesser values for the number of different user sessions, different IP addresses, and length of time before it adds to the security policy and enforces the elements.
  15. For Trusted IP Addresses, select which IP addresses to consider safe:
    Option Description
    All Specifies that the policy trusts all IP addresses. For example, if the traffic is in a corporate lab or preproduction environment where all of the traffic is trusted, the policy is created faster when you select this option.
    Address List Specifies networks to consider safe. Fill in the IP Address and Netmask fields, then click Add. This option is typically used in a production environment where traffic could come from untrusted sources. The IP Address can be either an IPv4 or an IPv6 address.
    If you leave the trusted IP address list empty, the system treats all traffic as untrusted. In general, it takes more untrusted traffic, from different IP addresses, over a longer period of time to build a security policy.
  16. If you want the security policy to automatically detect JSON and XML protocols, select the JSON/XML payload detection check box. If requests contain legitimate XML or JSON data, the Policy Builder creates content profiles in the security policy according to the data it detects.
  17. If you want to display a response page when an AJAX request does not adhere to the security policy, select the AJAX blocking response behavior check box.
  18. Click Next. The Security Policy Configuration Summary opens where you can review the settings to be sure they are correct.
  19. Click Finish to create the security policy. The Automatic Policy Building Status screen opens where you can view the current state of the security policy.
ASM creates the virtual server with an HTTP profile, and on the Security tab, Application Security Policy is enabled and associated with the security policy you created. A local traffic policy is also created and by default sends all traffic for the virtual server to ASM. The Policy Builder automatically begins examining the traffic to the web application and building the security policy (unless you did not associate a virtual server). The system sets the enforcement mode of the security policy to Blocking, but it does not block requests until the Policy Builder processes sufficient traffic, adds elements to the security policy, and enforces the elements.
Tip: This is a good point at which to test that you can access the application being protected by the security policy and check that traffic is being processed by the BIG-IP system.

Creating an access profile

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. Click Create. The New Profile screen opens.
  3. In the Name field, type a name for the access profile.
  4. From the Profile Type list, select one:
    • APM-LTM - Select for a web access management configuration.
    • SSO - Select only when you do not need to configure an access policy.
    • SWG - Explicit - Select to configure access using Secure Web Gateway explicit forward proxy.
    • SWG - Transparent - Select to configure access using Secure Web Gateway transparent forward proxy.
    • SSL-VPN - Select for other types of access, such as network access, portal access, application access. (Most access policy items are available for this type.)
    • ALL - Select for any type of access.
    Additional settings display.
  5. To configure timeout and session settings, select the Custom check box.
  6. In the Inactivity Timeout field, type the number of seconds that should pass before the access policy times out. Type 0 to set no timeout. If there is no activity (defined by the Session Update Threshold and Session Update Window settings in the Network Access configuration) between the client and server within the specified threshold time, the system closes the current session.
  7. In the Access Policy Timeout field, type the number of seconds that should pass before the access profile times out because of inactivity. Type 0 to set no timeout.
  8. In the Maximum Session Timeout field, type the maximum number of seconds the session can exist. Type 0 to set no timeout.
  9. In the Max Concurrent Users field, type the maximum number of users that can use this access profile at the same time. Type 0 to set no maximum.
  10. In the Max Sessions Per User field, type the maximum number of concurrent sessions that one user can start. Type 0 to set no maximum.
  11. In the Max In Progress Sessions Per Client IP field, type the maximum number of concurrent sessions that one client IP address can support. Type 0 to set no maximum.
  12. Select the Restrict to Single Client IP check box to restrict the current session to a single IP address. This setting associates the session ID with the IP address. Upon a request to the session, if the IP address has changed the request is redirected to a logout page, the session ID is deleted, and a log entry is written to indicate that a session hijacking attempt was detected. If such a redirect is not possible, the request is denied and the same events occur.
  13. To configure logout URIs, in the Configurations area, type each logout URI in the URI field, and then click Add.
  14. In the Logout URI Timeout field, type the delay in seconds before logout occurs for the customized logout URIs defined in the Logout URI Include list.
  15. To configure SSO:
    • For users to log in to multiple domains using one SSO configuration, skip the settings in the SSO Across Authentication Domains (Single Domain mode) area. You can configure SSO for multiple domains only after you finish the initial access profile configuration.
    • For users to log in to a single domain using an SSO configuration, configure settings in the SSO Across Authentication Domains (Single Domain mode) area, or you can configure SSO settings after you finish the initial access profile configuration.
  16. In the Domain Cookie field, specify a domain cookie, if the application access control connection uses a cookie.
  17. In the Cookie Options setting, specify whether to use a secure cookie.
    • If the policy requires a secure cookie, select the Secure check box to add the secure keyword to the session cookie.
    • If you are configuring an LTM access scenario that uses an HTTPS virtual server to authenticate the user and then sends the user to an existing HTTP virtual server to use applications, clear this check box.
  18. If the access policy requires a persistent cookie, in the Cookie Options setting, select the Persistent check box. This sets cookies if the session does not have a webtop. When the session is first established, session cookies are not marked as persistent; but when the first response is sent to the client after the access policy completes successfully, the cookies are marked persistent. Persistent cookies are updated for the expiration timeout every 60 seconds. The timeout is equal to session inactivity timeout. If the session inactivity timeout is overwritten in the access policy, the overwritten value will be used to set the persistent cookie expiration.
  19. From the SSO Configurations list, select an SSO configuration.
  20. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  21. Click Finished.
The access profile appears in the Access Profiles List.
To add an SSO configuration for multiple domains, click SSO / Auth Domains on the menu bar. To provide functionality with an access profile, you must configure the access policy. The default access policy for a profile denies all traffic and contains no actions. Click Edit in the Access Policy column to edit the access policy.

Configuring an access policy

You configure an access policy to provide authentication, endpoint checks, and resources for an access profile. This procedure configures a simple access policy that adds a logon page, gets user credentials, submits them to an authentication type of your choice, then allows authenticated users, and denies others.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. Click the name of the access profile you want to edit.
  3. On the menu bar, click Access Policy.
  4. For the Visual Policy Editor setting, click the Edit access policy for Profile policy_name link. The visual policy editor opens the access policy in a separate window or tab.
  5. Click the (+) icon anywhere in the access policy to add a new action item. A popup screen opens, listing predefined actions on tabs such as General Purpose, Authentication, and so on.
  6. On the Logon tab, select Logon Page and click the Add Item button. The Logon Page Agent properties screen opens.
  7. Click Save. The Access Policy screen reopens.
  8. On the rule branch, click the plus sign (+) between Logon Page and Deny.
  9. Set up the appropriate authentication and client-side checks required for application access at your company, and click Add Item.
  10. Change the Successful rule branch from Deny to Allow and click the Save button.
  11. If needed, configure further actions on the successful and fallback rule branches of this access policy item, and save the changes.
  12. At the top of the screen, click the Apply Access Policy link to apply and activate your changes to this access policy.
  13. Click the Close button to close the visual policy editor.

Adding the access profile to the virtual server

Before you can perform this task, you need to create an access profile using Access Policy Manager.

You associate the access profile with the virtual server created for the web application that Application Security Manager is protecting.

You associate the access profile with the virtual server so that Access Policy Managercan apply the profile to incoming traffic.

  1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
  2. Click the name of the virtual server that manages the network resources for the web application you are securing.
  3. In the Access Policy area, from the Access Profile list, select the access profile.
  4. Click Update.
Your access policy is now associated with the virtual server.

Configuring a database security server

To integrate Application Security Manager (ASM) with a third-party database security product, you need to configure the database security server on ASM. You can configure one database security server per system.
  1. On the Main tab, click Security > Options > Application Security > Integrated Services > Database Security. The Database Security screen opens.
  2. Specify the database security server by typing either its Server Host Name or its Server IP Address. Only one of the two fields is required.
    Note: If using SSL to establish a secured session between the BIG-IP system and the database security server, type the IP address of a virtual server configured for the secure connection. The virtual server uses any open IP address for the destination, the IBM Guardium port (16016, by default) for the service port, serverssl or a customized profile for the SSL Profile (Server) setting, and specifies a default pool (containing one member, the database security server, using its IP address and service port, typically, 16016).
  3. For Server Port Number, type the port number of the database server. The default value is 16016, the port used by IBM InfoSphere Guardium.
  4. If you want the system to wait for an ACK response from the database security server before sending the request to the application server, from the Request Hold Timeout list, select Enabled and type the number of milliseconds to wait for the response. The default value is 5 milliseconds. When this setting is enabled, the system forwards the request to the application server as soon as the database security server sends an ACK, or when the timeout has passed. If you leave this setting disabled, the system forwards the request to the application server immediately.
  5. Click Save. The system saves the configuration settings.
The Application Security Manager is now configured to connect to the database security server.
For ASM to forward request data to the database security server, you next need to enable database security integration in one or more security policies.

Enabling database security integration with ASM and APM

Before you can enable database security integration, you need to have created a security policy to protect your web application. For the policy to retrieve the user names of those making requests, you need to have set up Access Policy Manager(APM) on the BIG-IP system.
You enable database security integration in a security policy so that Application Security Manager (ASM) forwards request information to a third-party database server.
  1. On the Main tab, click Security > Application Security > Integrated Services > Database Security. The Database Security screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. Select the Database Security Integration check box.
  4. For User Source, select Use APM Usernames and Session ID. The system uses Access Policy Manager (APM) user names and session ID to determine the user source. You can choose this option only if you have APM licensed and provisioned.
  5. Click Save. The system saves the configuration settings.
The Application Security Manager connects to the database security server and can forward request data to it.

Implementation result

You have set up a BIG-IP system to use Application Security Manager (ASM) to secure application traffic, and Access Policy Manager (APM) to check user credentials.

Client traffic is routed to the virtual server for the web application. At first, traffic is handled by the APM module. APM verifies user credentials and allows those with valid credentials to use web application. APM also sends user names and session IDs of valid users to ASM. After that, ASM checks for security violations and forwards traffic that meets the security policy requirements to the backend server.

The database security server includes the application and user information provided by ASM and APM, so it can be viewed in logs and reports on that system. The database security server can perform a more in depth security assessment of the web request.

If you want to review reports and event logs that associate the user name with the session information on the BIG-IP system, you can set up session tracking (by enabling session awareness). When session awareness is enabled, you can see the user names on the Event Logs: Application: Requests screen in the General Details section of specific requests. IN addition, the Reporting: Application: Charts screen displays the users who sent the illegal requests.

Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information