You can secure HTTP traffic by using a default configuration or by customizing the configuration. You can adjust the following security checks in an HTTP security profile:
You can also specify how you want the system to respond when it encounters a violation. If the system detects a violation and you enabled the Block flag, instead of forwarding the request, the system can either send a blocking response page or redirect the client to a different location.
The easiest method for adding HTTP protocol security to your HTTP virtual server is to use the system default profile. You do this by configuring a virtual server with the HTTP profile http, and then associating the default HTTP protocol security profile http_security with the virtual server.
This implementation describes how to set up the BIG-IP® system to perform security checks on your HTTP virtual server traffic customized to the needs of your environment. Custom configuration of HTTP security and traffic management requires creating an HTTP security profile, and fine tuning this profile so it protects HTTP traffic the way you want. Once you have all HTTP settings specified, you create a virtual server, attach the custom HTTP security profile, and add a default pool to handle the HTTP traffic.
The HTTP security profile consists of many different security checks for the various components of HTTP traffic. This implementation shows you how to fine-tune your HTTP security profile as required by your environment. The custom checks are described under the assumption that you have already created a custom HTTP security profile but have no other prerequisite or special order. You need configure only the custom checks that you are interested in.
You can achieve a greater level of security when you configure the system to perform the following checks:
When the BIG-IP® system receives an HTTP request from a client, the first validation check that the system performs is to ensure that it is RFC protocol compliant. If the request passes the compliance checks, the system applies the security profile to the request. So that your system fully validates RFC compliance, keep the following HTTP Protocol Checks enabled (they are enabled by default):
Advanced Firewall Manager can examine HTTP requests for methods of application attack that are designed to avoid detection. When found, these coding methods, called evasion techniques, trigger the Evasion technique detected violation. By creating HTTP security profiles, you can detect evasion techniques, such as:
By default, the system logs requests that contain evasion techniques. You can also block requests that include evasion techniques.
|Alarm||The system logs any requests that trigger the violation. This is the default setting.|
|Block||The system blocks any requests that trigger the violation.|
|Alarm and Block||The system both logs and blocks any requests that trigger the violation.|
By creating HTTP security profiles, you can perform several types of checks on HTTP requests to ensure that the requests are well-formed and protocol-compliant.
|Alarm||The system logs any responses that trigger the Mandatory HTTP header is missing violation. This is the default setting.|
|Block||The system blocks any requests that trigger the Mandatory HTTP header is missing violation.|
|Alarm and Block||The system both logs and blocks any requests that trigger the Mandatory HTTP header is missing violation.|
You can configure the BIG-IP® system to log detailed information about protocol security events and store those logs locally.
You now have an implementation in which the BIG-IP® system logs specific Protocol Security events locally.
You can configure the BIG-IP® system to log information about Protocol Security events and send the log messages to remote high-speed log servers.
This illustration shows the association of the configuration objects for remote high-speed logging.
Association of remote high-speed logging configuration objects
When configuring remote high-speed logging of Protocol Security events, it is helpful to understand the objects you need to create and why, as described here:
|Pool of remote log servers||Create a pool of remote log servers to which the BIG-IP system can send log messages.||Creating a pool of remote logging servers.|
|Destination (unformatted)||Create a log destination of Remote High-Speed Log type that specifies a pool of remote log servers.||Creating a remote high-speed log destination.|
|Destination (formatted)||If your remote log servers are the ArcSight, Splunk, IPFIX, or Remote Syslog type, create an additional log destination to format the logs in the required format and forward the logs to a remote high-speed log destination.||Creating a formatted remote high-speed log destination.|
|Publisher||Create a log publisher to send logs to a set of specified log destinations.||Creating a publisher.|
|DNS Logging profile||Create a custom DNS Logging profile to define the data you want the BIG-IP system to include in the DNS logs and associate a log publisher with the profile.||Creating a custom Protocol Security logging profile.|
|Protected object (virtual server)||Associate a custom DNS profile with a protected object to define how the BIG-IP system logs the DNS traffic that the protected object processes.||Configuring a protected object for Protocol Security event logging.|
Create a log destination of the Remote High-Speed Log type to specify that log messages are sent to a pool of remote log servers.
Create a formatted logging destination to specify that log messages are sent to a pool of remote log servers, such as Remote Syslog, Splunk, or IPFIX servers.
|None||Specifies the default format type in which the BIG-IP system logs messages to a remote Syslog server, for example: "management_ip_address","bigip_hostname","context_type","context_name","src_ip","dest_ip","src_port","dest_port","vlan","protocol","route_domain","acl_rule_name","action","drop_reason|
|Field-List||Allows you to:
|User-Defined||Allows you to: