Essential Configuration Tasks
Overview of the essential configuration tasks
This chapter is your guide to the essential configuration tasks you must complete to initially create and refine a security policy for an Application Security Class on the Application Security Module. Implementing a security policy for a web application has two phases that correspond to the policy modes: transparent and blocking. In phase one, the security policy operates in transparent mode to learn about the web application components and the traffic that the web application processes. In phase two, the security policy operates in blocking mode to actively prevent illegal access to the web application.
The phase one configuration tasks are:
- Define an Application Security Class.
When you define a class, the system automatically creates a default web application and a default security policy in the Application Security Module.
- Define a local traffic virtual server that uses the Application Security Class as a resource.
The virtual server on the Local Traffic Manager load balances the pools that host the web application you are securing. The Application Security Class is the bridge that links the security policy to the web application traffic through the virtual server. You configure the virtual server and one or more pools, and then associate a pool in the virtual server with the Application Security Class.
- Evaluate the required security level for the web application.
The type of security policy you configure depends on the required security level for the web application. Before you start configuring the security policy, you must assess the level of security that is appropriate for the web application, based on business requirements and available resources.
- Configure and test the default security policy using the Learning process.
With the security policy in transparent mode, you can direct real traffic through the web application. The Learning process evaluates the incoming requests for the web application, and if a request contains an object that does not match the security policy, the Learning process records the policy violation. You can then examine the violation to determine whether it should be part of the security policy.
The phase two configuration tasks are:
- Activate the security policy in blocking mode to start protecting the web application.
Once you are confident that the Learning process is reporting only policy violations which are indeed found in illegal requests, you can transition the security policy from transparent mode to blocking mode. In blocking mode, the Policy Enforcer blocks requests that do not comply with the security policy, and forwards requests that do comply to the pool you specified in the Application Security Class.
- Periodically review the security policy settings.
To ensure that the security policy is providing adequate application security, review the forensics, monitoring, and statistics information on a regular basis.
This chapter describes, in detail, the tasks that you perform to configure a standard security policy for a web application hosted on a local traffic virtual server.
The tasks described in this chapter begin after you have installed the BIG-IP system, activated the license, and configured the appropriate network settings. If you have not yet completed these activities, refer to the Installation, Licensing, and Upgrades for BIG-IP Systems guide, and the BIG-IP Network and System Management Guide for additional information. Both of these guides are available at http://tech.f5.com.
Defining an Application Security Class
When configuring a security policy to protect a web application that is running on a local traffic virtual server, the first task is to configure an Application Security Class. An Application Security Class is the logical bridge, or link, between the Application Security Module and the Local Traffic Manager. You use the Application Security Class to specify which incoming HTTP traffic should be diverted through the Application Security Module before being load balanced by the Local Traffic Manager. You create the Application Security Class on the Local Traffic Manager. When you configure an Application Security Class, the system automatically creates a default security policy and a default web application on the Application Security Module.
To create an Application Security Class
- On the Main tab in the navigation pane, expand Application Security, and then click Classes.
The HTTP Class Profiles list screen opens.
- Click the Create button.
The New HTTP Class Profile screen opens.
- Type a name for the class, and configure the remaining settings as needed for this Application Security Class.
For additional information on the options on this screen, click the Help tab.
- Click Finished.
The system adds the class, the default security policy, and the default web application to the configuration, and displays the HTTP Class Profiles list screen.
In the Configuration utility, the Application Security Class and the HTTP Class Profile are different labels for the same object. The difference between the two objects is that, for the Application Security Class, the Application Security setting is enabled by default. If you disable the Application Security setting on an Application Security Class, you effectively turn off application security for the associated web application.
Defining a local traffic virtual server and pool
The next configuration step is to define a virtual server and pool on the Local Traffic Manager. The virtual server processes the incoming traffic, and routes the traffic according to the settings that you configure, which includes associating the Application Security Class with the virtual server. The pool hosts the actual web application content that you want to protect with the security policy.
The following procedure outlines only the basic virtual server and pool configuration. For detailed information on virtual servers, pools, and the other local traffic components, refer to the Configuration Guide for Local Traffic Management, which is available on the Technical Support web site, http://tech.f5.com.
To configure a virtual server and pool
- On the Main tab of the navigation pane, expand Local Traffic, and then click Virtual Servers.
The Virtual Servers list screen opens.
- Click the Create button.
The New Virtual Server screen opens.
- In the Name box, type a name for the virtual server.
- In the Destination option, select Host, and type an IP address.
- In the Service Port box, type 80. Alternately, you can select HTTP from the list.
- In the Configuration section, from the HTTP Profile list, select http.
- In the Resources section, from the Available list in the HTTP Class Profiles option, select the Application Security Class that you created, and click the Move button (<<) to add the class to the Enabled list.
- Click the Add (+) button next to the Default Pool list.
The New Pool screen opens.
- In the Name box, type a name for the pool.
- In the Health Monitors section, select http in the Available list, and click the Move button (<<) to add the monitor to the Active list
- In the Resources section, in the New Members option, add the settings for the server that hosts the web application. For additional information on the settings, click the Help tab in the navigation pane.
- Click Finished.
The screen refreshes, and takes you back to the New Virtual Server screen, where you see the new pool in the Default Pool list.
- Click Finished again.
The system updates the configuration, and the Virtual Server list screen opens, where you can see your newly created virtual server.
For virtual servers that load balance resources for a web application which is protected by the Application Security Module, you must configure an HTTP profile in addition to the Application Security Class. Refer to steps 6 and 7 in the previous procedure.
Associating a pool with the Application Security Class
Now that you have a local traffic virtual server and pool configured, you associate the pool with the Application Security Class. The local traffic pool contains the server resources which are the destination for requests for the web application. When the system receives a request that matches the criteria in the class, the system forwards the request to the Application Security Module. If the request complies with the security policy for web application, the Application Security Module then forwards the request to the pool that you have associated with the Application Security Class.
To associate a pool with an Application Security Class
- On the Main tab of the navigation pane, expand Application Security, and then click Classes.
The HTTP Class Profiles list screen opens.
- In the Name column, click the name of the class that you created earlier.
The Properties screen opens.
- In the Configuration section, from the Pool list, select the name of the pool that you just created.
- Click Update.
The system saves the changes that you made.
Determining the required security level for the web application
Before you start configuring the security policy itself, you need to determine the security level that you want the security policy to enforce. This decision is based on several factors: the complexity of the web application, how often you update the web application, the requirements for protecting the web application, and the resources available to maintain the security policy. All of these factors affect not only how long it takes to get the system configured initially, but also the amount of time it takes to maintain the system over time.
Understanding the security levels
By default, the Application Security Module provides two security levels for security policies: standard and high security. In addition to the default security levels, you can customize either security level to meet the security requirements for your web application.
- Standard security
The standard security level protects the general objects that make up the web application, based on the negative security criteria that is built into the system. You can configure the standard security policy to protect the application against attacks in the following areas:
- SQL injection
- Cross-site scripting
- Cookie poisoning
- Buffer overflow
- Parameter tampering (lengths and meta-characters)
- Forceful browsing (file type enforcement)
- Stealth commanding
- Back-door and debug options
- Third party mis-configuration
The standard security level requires minimal setup and maintenance time.
- High security (APC)
The high security (APC) security level provides a much more in-depth and granular level of security for the web application. When you have fully configured an APC security policy, and put it into blocking mode, it applies only positive security logic. (See Understanding positive security logic , for details.) The APC security level can protect individual parameters within the application, their associated objects, and also any flows to or from the object. The APC security level requires a longer setup time, as the security policy configuration is more closely tied to specific, individual objects and parameters in the application.
You must evaluate the security needs of the web application versus the resources available to set up and maintain the security policy, before you configure the actual security policy. The more evolved the security policy is, the higher the maintenance cost.
The security policy maintenance is tied to the frequency at which you update the web application, as well as the complexity of the application. We recommend that you configure a standard security policy first, to protect the web application against the most common known threats, and to familiarize yourself with the functionality of the Application Security Module.
Understanding positive security logic
The Application Security Module operates on the principle of positive security logic. Positive security logic means that, when the security policy is in blocking mode, the security policy permits only known, legitimate traffic through to the web application. Compare this to negative security logic, which means that the web application is subjected to all traffic, except that which is known to be a threat because it matches the built-in negative logic criteria. By using positive security logic, rather than negative security logic, the Application Security Module protects the web application against both known and unknown threats (also known as zero-day threats).
The biggest advantage of deploying web application security based on positive security logic is that it blocks all access to the web application except for legitimate, known traffic. The biggest risk of deploying web application security based on positive security logic is that the security policy may block traffic that should be recognized as legitimate. This is known as a false positive alarm. When the system blocks a request that is actually legitimate, in other words, generates a false positive, you must adjust the security policy settings accordingly, so that the policy does not block that type of request. This is an heuristic process, and may take several days or weeks.
The goal of testing and fine-tuning the security policy with safe traffic is to eliminate the false positives. Once you have accomplished this goal, you can deploy the security policy in blocking mode, and be confident that the right clients are able to access the web application, and the web application is safe from the myriad known and unknown threats.
Configuring and testing the security policy
Once you have configured the Application Security Class and the local traffic virtual server, and determined which security level to apply to the security policy, you can start the process of updating and testing the security policy for the web application.
This section describes how to configure a standard security policy. You can always use a standard security policy as the baseline for a high-security policy.
Recall that when you created the Application Security Class, the system automatically created a default security policy and a default web application. The default security policy serves as a template, and now you need to update the security policy so that it protects the web application, based on the characteristics of the traffic through the web application.
Testing the security policy with safe traffic
The best way to update and test the security policy is to direct HTTP traffic from known users at the web application, while the web application and the Application Security Module are running in a test environment. Safe traffic is traffic generated by a controlled group of users, those who are known to not be potential attackers. For example, the employees of your company would be a good source of safe traffic. During the time that the Application Security Module is processing the safe traffic, the security policy is learning the true nature of legitimate requests. We recommend that you run safe traffic through the Application Security Module for as long as it takes to eliminate the false positive alarms.
By exposing the web application to safe traffic, from known clients, while the security policy is in transparent mode, you can update and refine the security policy to improve its effectiveness before you put the security policy into blocking mode. The security policy is in transparent mode when it is detecting security policy violations, and reporting them on the Learning traffic screens, but not blocking the traffic that contains the violations. By running safe traffic through the security policy while the policy is in transparent mode, you can verify that:
- The Application Security Module is not posting false positive alarms.
- The Application Security Module is warning you when it detects a real attack against the web application.
Before we explain how to test and refine the security policy, it is important that you understand why one goes through this exercise.
Overview of the Learning process
The process of collecting the information you need from the safe traffic, so that you can refine the security policy and eliminate the false positives, is known as the Learning process. The Learning process gathers data about the traffic as the users traverse the web application. You can use this data to refine the security policy. You can use the Learning process throughout the life of the web application, to ensure that the security policy is current and effective.
Because each web application and security policy is unique, the Learning process is difficult to generalize. To fully understand all of the options available for the Learning process, refer to Chapter 4, Refining the Security Policy with Learning Tools .
Special considerations for APC security policies
If your web application requires a security policy at the high security (APC) level, then there are additional tools and configuration options to help you set up the security policy. These additional tools complement the Learning process when you are building a high-security policy.
- The Crawler tool
You can use the Crawler tool to scan the application and list all of the parameters, such as user names, passwords, or account number fields. For information on the Crawler tool, refer to Chapter 5, Working with the Crawler Tool .
- The Policy Browser
You can use the Policy Browser to overcome browsing issues that the Crawler tool encounters when scanning the web application. For more information on the Policy Browser, refer to Using the Policy Browser to collect web application data.
Transitioning the security policy into blocking mode
When all of the alerts generated in the Learning screens represent invalid requests, for example, requests for non-existent information, or automated scripting attacks, you are ready to put the security policy into blocking mode. The absence of false positives in the Learning screens means that the security policy contains all the necessary objects and flows, and that all of the parameters are set to values that are characteristic of non-harmful, real-life traffic. You can also use the data on the Events screen, in the Statistics section of the Configuration utility, to help you decide whether the security policy is ready to be put into blocking mode.
Security policies can be as restrictive as you need, based on the potential threats and network traffic that the web application processes. For additional details and information about working with security policies, refer to Chapter 3, Working With the Security Policy .
Activating blocking mode on the security policy
You can activate blocking mode in stages, using the Blocking Policy screen. Fore example, you can activate blocking for only Illegal Object Types, so that the Application Security Module blocks any request that refers to a file of a type which is not included in the security policy. When you activate blocking in stages, you can continue to refine the security policy. Once you have activated blocking for all of the relevant policy violations, you can consider that any alarms that the Learning tool reports are for potentially harmful traffic.
To activate blocking mode for a security policy
- On the Main tab of the navigation pane, expand Application Security, and then click Web Applications.
The Web Applications list screen opens.
- Click the name of the security policy for the web application.
The Policy Properties screen opens.
- In the Security Level setting, click the Edit button.
The Blocking Policy screen opens.
- Clear the Disable Blocking check box.
- In the remaining sections of the screen, clear or check the Block and Alarm check boxes as needed.
- Click Save.
The system updates the policy with any changes you made.
The Security Reports screen, in Statistics, is a very good resource when you are deciding whether a security policy is ready to put into blocking mode. This screen displays how many instances of a violation have occurred.
Setting the active policy for the web application
Now that you have transitioned the policy from transparent mode to blocking mode, you need to set the security policy to active for the web application. You do this on the web application properties screen, which is shown in Figure 2.1 . In this example screen, in the Policies List, the first security policy is the active policy, which is indicated by the Active icon () next to the name. The second security policy has been changed (modified) in some way, which is indicated by the Modified icon () next to the name.
Figure 2.1 The Properties screen for a web application
To set the active policy for a web application
- On the Main tab in the navigation pane, expand Application Security, and then click Web Applications.
The Web Applications list screen opens.
- Click the web application name.
The web application properties screen opens.
- In the New Active Policy section, select the default policy that you have been configuring, and then click the Set Active Policy button.
A confirmation popup screen opens, to confirm that you want the selected policy to be the active policy.
- Click OK.
The screen refreshes, and in the Policies List, you see the Active Policy icon next to the selected security policy.
The Application Security Module requires you to confirm the active policy every time you change a property of a security policy. When a security policy has been changed in any way, you see the Modified icon next to the policy name, in the Policies List.
Maintaining and monitoring the security policy
The Application Security Module provides many reporting and monitoring tools, so that you can view and analyze the violations that the system detects in the traffic through the web application. By actively using the monitoring tools, you can be assured that your web applications are fully protected.
To view the monitoring tools
- On the Main tab of the navigation pane, expand Application Security, and then click Statistics.
The Events Monitoring screen opens.
- On the menu bar, select the statistics type that you want to view.
- On each screen, you can use the Filter option to customize and refine the reports.
For additional information and details about the monitoring tools, refer to Chapter 6, Working with the Statistics and Monitoring Tools .