You can deploy Application Security Manager (ASM) 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
provides information about each HTTP request and database query to the database security
product's logging and reporting system. This allows the database security system to correlate the
web transaction with the database query to make a security assessment of the transaction.
Before you can integrate ASM with a database security product, the database security server
itself must have been configured, and be accessible from ASM. 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 the 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 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 with an
external database security server using login pages.
When using login pages for the application, you define the URLs, parameters, and validation
criteria required for users to log in to the application. User and session information is
included in the system logs so you can track a particular session or user. The system can log
activity, or block a user or session if either generates too many violations.
Task Summary
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.
-
On the Main tab, click .
The Active Policies screen opens.
-
Click the Create button.
The Deployment wizard opens to the Select Local Traffic Deployment
Scenario screen.
-
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.
-
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.
-
For Deployment Scenario, select Create a
policy automatically and click
Next.
The Configure Security Policy Properties screen opens.
-
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.
-
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.
-
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.
-
Click Next.
The Configure Attack Signatures screen opens.
-
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.
-
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.
-
Click Next.
The Configure Automatic Policy Building screen opens.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Click Next.
The Security Policy Configuration Summary opens where you can review the
settings to be sure they are correct.
-
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 login pages
In your security policy, you can create a login page to specify a login URL that
presents a site that users must pass through to gain access to the web application. The
login URL commonly leads to the login page of the web application.
-
On the Main tab, click .
The Login Pages List screen opens.
-
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.
-
Click Create.
The New Login Page screen opens.
-
For the Login URL setting, specify a URL that users must pass through to get to the application.
-
From the list, select the type of URL: Explicit or Wildcard.
-
Select either HTTP or HTTPS based on the type of traffic the web application accepts.
-
Type an explicit URL or wildcard expression in the field.
When you click in the field, the system lists URLs that it has seen, and you
can select a URL from the list. Or, you can type explicit URLs in the format
/login, and wildcard URLs without the slash, such as
*.php.
-
From the Authentication Type list, select the method the web server
uses to authenticate the login URL's credentials with a web user.
| Option |
Description |
| None |
The web server does not authenticate users trying to access the web application through the login URL. This is the default setting. |
| HTML Form |
The web application uses a form to collect and authenticate user credentials. If using
this option, you also need to type the user name and password parameters written in the code
of the HTML form. |
| HTTP Basic Authentication |
The user name and password are transmitted in Base64 and stored on the server in plain
text. |
| HTTP Digest Authentication |
The web server performs the authentication; user names and passwords are not
transmitted over the network, nor are they stored in plain text. |
| NTLM |
Microsoft LAN Manager authentication (also called Integrated Windows Authentication)
does not transmit credentials in plain text, but requires a continuous TCP connection
between the server and client. |
-
In the Access Validation area, define at least one validation criteria for the login
page response.
If you define more than one validation criteria, the response must meet all the
criteria before the system allows the user to access the application login URL.
Note: The system checks the access validation criteria on the response of the
login URL only if the response has one of the following content-types: text/html,
text/xml, application/sgml, application/xml, application/html, application/xhtml,
application/x-asp, and application/x-aspx.
-
Click Create to add the login page to the security policy.
The new login page is added to the login pages list.
-
Add as many login pages as needed for your web application.
-
In the editing context area, click Apply Policy to put the changes
into effect.
The security policy now has one or more login pages associated with it.
You can now configure how the login pages are enforced, including the
authentication URLs, logout URLs, and whether or not the login pages have time
limits.
Enforcing login pages
Login enforcement settings prevent forceful browsing attacks where attackers gain access to restricted parts of the web application by supplying a URL directly. You can use login enforcement to force users to pass through one URL (known as the login URL) before being allowed to display a different URL (known as the target URL) where they can access restricted pages and resources. Login enforcement settings specify how the security policy enforces login pages including the expiration time, authenticated URLs, and logout URLs. You can also use authenticated URLs to enforce idle time-outs on applications that are missing this functionality.
-
On the Main tab, click .
The Login Enforcement screen opens.
-
If you want the login URL to be valid for a limited
time, set Expiration Time to Enabled, and type a value, in
seconds.
-
For the Authenticated URLs setting, specify the target URLs that
users can access only by way of the login URL:
-
In the Authenticated URLs field, type the target URL name in the
format /private.php (wildcards are allowed).
-
Click Add to add the URL to the list of authenticated URLs.
-
Repeat to add as many authenticated URLs as needed.
-
Optionally, use the Logout URLs setting to specify the URLs used
to log out of the web application:
-
In the Logout URLs field, type the URL in the format
/logout.html (explicit URLs only).
-
Click Add.
-
Repeat to add as many logout URLs as needed.
-
Click Save to save your settings.
-
To put the security policy changes into effect immediately, click Apply
Policy.
If you specify authenticated URLs and a user tries to bypass them, the system issues
the Login URL bypassed violation. If a user session is idle and exceeds
the expiration time, the system now issues the Login URL expired
violation, and the user can no longer reach the authenticated URLs. For both login
violations, if the enforcement mode is blocking, the system now sends the Login Page
Response to the client (see ).
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.
-
On the Main tab, click . The Database Security screen opens.
-
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).
-
For Server Port Number, type the port number of the
database server.
The default value is 16016, the port used by IBM
InfoSphere
Guardium.
-
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.
-
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 in a security policy
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 create login pages in Application
Security Manager (ASM).
You enable database security integration in a security policy so that Application
Security Manager (ASM) forwards request information to a
third-party database server.
-
On the Main tab, click . The Database Security screen opens.
-
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.
-
Select the Database Security Integration check box.
-
For User Source, select Use Login
Pages to have the system use an ASM login page to determine the
user source.
If there is no login page configured in the security policy, click the login
pages link to open a popup screen where you can add one.
-
Click Save.
The system saves the configuration settings.
The Application Security Manager connects to the database security server and can
forward request data about traffic to it.
