Applies To:
Show Versions
BIG-IP ASM
- 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Working with Violations
About violations
Application Security Manager™ can detect violations that occur in requests. Violations occur when some aspect of a request or response does not comply with the security policy. You can configure the blocking settings for any violation in a security policy to determine how the system will treat requests with violations. When a violation occurs in a request, the system can learn, alarm, or block the request (blocking is only available when the enforcement mode is set to blocking).
In the Violations List you can view a list of all of the violations that are supplied on the system, along with the violation type and severity. The severity level is adjustable, as needed.
You can also create user-defined or custom violations with unique specifications that you want the system to detect.
Viewing descriptions of violations
Changing severity levels of violations
Types of violations
This table describes the types of violations that can occur. On the , you can get details about the violations (and change the severity) by clicking the violation. You also can view descriptions of each violation by clicking the information icon to the left of each violation in the Violations List on the Application Security Blocking Settings screen.
| Violation Type | Description |
|---|---|
| RFC violations | Occur when the format of an HTTP request violates the HTTP RFCs. RFC documents are general specifications that summarize Internet and networking standards. RFCs, as they are commonly known, are published by the International Engineering Task Force (IETF). For more information on RFCs, see http://www.ietf.org/rfc. |
| Access violations | Occur when an HTTP request tries to gain access to an area of a web application, and the system detects a reference to one or more entities that are not allowed (or are specifically disallowed) in the security policy. |
| Length violations | Occur when an HTTP request contains an entity that exceeds the length setting that is defined in the security policy. |
| Input violations | Occur when an HTTP request includes a parameter or header that contains data or information that does not match, or comply with, the security policy. Input violations most often occur when the security policy contains defined user-input parameters. |
| Cookie violations | Occur when the cookie values in the HTTP request do not comply with the security policy. Cookie violations may indicate malicious attempts to hijack private information. |
| Negative security violations | Occur when an incoming request contains a string pattern that matches an attack signature in one of the security policy’s attack signature sets, or when a response contains exposed user data, for example, a credit card number. |
| Other violations | Refers to user-defined violations. If your system includes user-defined violations, they occur when instructed by the iRules® that were developed to activate them. |
About violation rating
You or the security manager can examine requests that cause violations to determine whether the requests are real attacks or false positives. To simplify the task of identifying false positives, each transaction with one or more violations has a violation rating associated with it. The violation rating ranks the transaction from 1 to 5, where 5 indicates the highest probability of a real attack with high severity. This table explains how to interpret the violation ratings.
| Rating | Description |
|---|---|
| 5 | Request is most likely a threat so consider clearing any learning suggestions associated with it. |
| 4 | Request looks like a threat but requires examination before clearing the suggestion. |
| 3 | Request needs further examination. |
| 2 | Request looks like a false positive but requires examination. |
| 1 | Request is most likely a false positive. If it is, then consider accepting learning suggestions to add this to the security policy. |
- Requests lists
- Manual learning suggestions
- Application Security reports and charts
The system assigns the violation rating by assessing the combination of violations occurring in a transaction. The violation rating is assigned to the transaction as a whole rather than the individual violations in the request. This is because real attacks often include multiple violations within one transaction. The violation rating takes into consideration the impact of the violations on the business.
Requests with high violation ratings are likely to be real attacks, and you can review them to analyze threats to your web applications. You can filter the requests in the Requests list to focus on the high-rated illegal requests with ratings of 4 or 5.
You can review requests with low violation ratings and if they are false positives you can accept the request to adopt the learning suggestions for the security policy.
Investigating potential attacks
Overview: Creating user-defined violations
You can create user-defined violations so that Application Security Manager™ (ASM) can detect new threats or protect against application-specific vulnerabilities. After creating the violation, you can then configure the system to alert or block requests that cause it. You need to write iRules®to detect the customized attack conditions and issue the violation. In the security policy properties, you then need to activate iRule events.
The iRules are written using application security events and commands. For detailed information on iRules, see the F5 Networks DevCentral web site, http://devcentral.f5.com.
Creating user-defined violations
Enabling user-defined violations
Sample iRules for user-defined violations
The following application security iRule issues a user-defined violation called VIOLATION_NOT_BROWSER if the request was not sent using Internet Explorer, Mozilla Firefox, Safari, Chrome, or Opera.
when ASM_REQUEST_DONE {
if { {not [HTTP::header "User Agent"]match_regexp "(IE|Mozilla|Safari|Chrome|Opera)" } and {[llength [IP::reputation [ASM::client_ip]]] > 0} }
{ ASM::raise VIOLATION_NOT_BROWSER
}
}
The following application security iRule issues a user-defined violation when there are too many ASM™ violations.
when ASM_REQUEST_DONE {
if {[ASM::violation count] > 3 and [ASM::severity] eq "Error"} {
ASM::raise VIOLATION_TOO_MANY_VIOLATIONS
}
}
This iRule uses an ASM event to log in /var/log/ltm all available information about the request that was enforced by ASM.
when ASM_REQUEST_DONE {
#Get and log info as it was done before v11.5.
log local0. "==============Previous style: Start==========="
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0.
"==============Previous style: Done==========="
#Using the new command (V11.5 or later) log all available information about
#the enforced request.
log local0.
"==============New style Start==========="
#display ASM policy which enforced request
log local0. "ASM Policy: [ASM::policy];"
#log some part of request using iRule commands Method, URI,
log local0. "Request string: [HTTP::method] [HTTP::uri];"
#log payload from request using ASM::payload command and HTTP::payload or
#log Query string.
log local0. "Payload ASM payload [ASM::payload];"
log local0. "Payload HTTP payload [HTTP::payload];"
log local0. "Query String [HTTP::query];"
# log information about request processed by ASM policy
#support ID
log local0. "SupportID: [ASM::support_id];"
#request status for current moment
log local0. "Request Status: [ASM::status];"
#Severity of attack detected in request
log local0. "Severity: [ASM::severity];"
#client IP
log local0. "ClientIP: [ASM::client_ip];"
# number of violations ASM detected in the request
log local0. "Number Violations: [ASM::violation count]"
# log all ASM violation iControl names detected in the request
log local0. "Violations Names: [ASM::violation names];"
# log all Attack types detected in request
log local0. "Attack Types: [ASM::violation attack_types];"
# log all violation details detected in the request.
set details [ASM::violation details]
if { [llength $details]>0 } {
set i 0
foreach pair $details {
if { [lindex $pair 0] contains "viol_name"} {
#Log violation Name
log local0. "Violation Number: $i; $pair"
incr i
} else {
#log other details for violation
set key [lindex $pair 0]
set value [lindex $pair 1]
log local0. "----------$pair----------"
if {$key contains "parameter_data.name" || $key contains
"parameter_data.value"} {
#decode parameter name from base64.
if {[catch {b64decode $value} decoded_value] == 0}{
log local0. "$key ---- $decoded_value"
} else {
log local0. "$key ---- $value"
}
} else {
#log other details
log local0. "$key ---- $value"
}
}
}
}
#Log all violation details as one string. Could be cut.
log local0. "Violation details: [ASM::violation details];"
log local0. "==============New style Done==========="
}
When raising user-defined violations within an ASM iRule, you can specify additional violation details to include in the log as shown in the following example. You need to create the violations in ASM.
#Raise with lappend
when ASM_REQUEST_DONE {
# log support id for enforced request
log local0. "SupportID: [ASM::support_id];"
#log request status
log local0. "Request Status: [ASM::status];"
#log severity of request
log local0. "Severity: [ASM::severity];"
#log Client IP
log local0. "ClientIP: [ASM::client_ip];"
#log number of different violations detected in request
log local0. "Number Violations: [ASM::violation count]"
#log iControl violation names
log local0. "Violations Names: [ASM::violation names];"
# Raise 3 user-defined violations without any details
ASM::raise violation1
ASM::raise violation2
ASM::raise violation3
# Raise a user-defined violation with custom details
set x []
set y1 []
set y2 []
lappend y1 "key1" "value_field1"
lappend y2 "key2" "value_field2"
lappend x $y1
lappend x $y2
log local0. "Raise Violation4 [ASM::raise violation4 $x]"
#Log the number and names of detected violations.
#ASM logs detected and raised violations.
#Log the number of different violations detected in the request
log local0. "Number of Violations: [ASM::violation count]"
#log iControl violation names
log local0. "Violations Names: [ASM::violation names];"
The following iRule shows how to use request blocking with a blocking response page.
#RequestBlockingWithBRP
#Use new ASM iRule commands in old ASM iRule event.
when ASM_REQUEST_BLOCKING {
log local0. "==============OLD style start==========="
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0. "==============OLD style Done==========="
log local0. "==============New style Start==========="
log local0. "SupportID: [ASM::support_id];"
log local0. "Request Status: [ASM::status];"
log local0. "Severity: [ASM::severity];"
log local0. "ClientIP: [ASM::client_ip];"
log local0. "Number Violations: [ASM::violation count]"
log local0. "Violations Names: [ASM::violation names];"
log local0. "Attack Types: [ASM::violation attack_types];"
log local0. "Violation details: [ASM::violation details];"
#check if illegal parameter violation was detected
#then change Blocking response page.
if {([ASM::violation names] contains "VIOLATION_PARAM")} {
log local0. "VIOLATION_PARAM detected, let's customize reject page"
HTTP::header remove Content-Length
HTTP::header insert header_1 value_1
set response "<html><head></body><html>"
ASM::payload replace 0 [ASM::payload length] ""
ASM::payload replace 0 0 $response
}
}
The following example iRule shows how to use all ASM iRule events and commands.
#alliRulesforUDV
#Example with all ASM iRule events and commands
when HTTP_REQUEST {
# get LTM policy matched rule and chosen ASM security policy
set policy [POLICY::names matched]
log local0. "Matched policy [POLICY::names matched]"
log local0. "Matched rule in policy [POLICY::rules matched]"
log local0. "ASM policy [ASM::policy] enforcing"
}
#New ASM iRule event introduced in 11.5
when ASM_REQUEST_DONE {
log local0. "=========Old iRule Data======"
log local0. "Compatibility Mode is triggered"
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0. "=========Old iRule Data Done======"
log local0. "=========New iRule Data======"
log local0. "SupportID: [ASM::support_id];"
log local0. "Request Status: [ASM::status];"
log local0. "Severity: [ASM::severity];"
log local0. "ClientIP: [ASM::client_ip];"
log local0. "Number Violations: [ASM::violation count]"
log local0. "Violations Names: [ASM::violation names];"
log local0. "Attack Types: [ASM::violation attack_types];"
log local0. "Violation details: [ASM::violation details];"
log local0. "=========New iRule Data Done======"
}
# Old ASM iRule events which were before 11.5.0
when ASM_REQUEST_VIOLATION {
log local0. "=========Old iRule Data======"
log local0. "Compatibility Mode is triggered"
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0. "=========Old iRule Data Done======"
log local0. "=========New iRule Data======"
log local0. "SupportID: [ASM::support_id];"
log local0. "Request Status: [ASM::status];"
log local0. "Severity: [ASM::severity];"
log local0. "ClientIP: [ASM::client_ip];"
log local0. "Number Violations: [ASM::violation count]"
log local0. "Violations Names: [ASM::violation names];"
log local0. "Attack Types: [ASM::violation attack_types];"
log local0. "Violation details: [ASM::violation details];"
log local0. "=========New iRule Data Done======"
}
when ASM_RESPONSE_VIOLATION {
log local0. "=========Old iRule Data======"
log local0. "Compatibility Mode is triggered"
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0. "=========Old iRule Data Done======"
log local0. "=========New iRule Data======"
log local0. "SupportID: [ASM::support_id];"
log local0. "Request Status: [ASM::status];"
log local0. "Severity: [ASM::severity];"
log local0. "ClientIP: [ASM::client_ip];"
log local0. "Number Violations: [ASM::violation count]"
log local0. "Violations Names: [ASM::violation names];"
log local0. "Attack Types: [ASM::violation attack_types];"
log local0. "Violation details: [ASM::violation details];"
log local0. "=========New iRule Data Done======"
}
when ASM_REQUEST_BLOCKING {
log local0. "=========Old iRule Data======"
log local0. "Compatibility Mode is triggered"
set x [ASM::violation_data]
for {set i 0} {$i<7} {incr i} {
log local0. [lindex $x $i]
}
log local0. "=========Old iRule Data Done======"
log local0. "=========New iRule Data======"
log local0. "SupportID: [ASM::support_id];"
log local0. "Request Status: [ASM::status];"
log local0. "Severity: [ASM::severity];"
log local0. "ClientIP: [ASM::client_ip];"
log local0. "Number Violations: [ASM::violation count]"
log local0. "Violations Names: [ASM::violation names];"
log local0. "Attack Types: [ASM::violation attack_types];"
log local0. "Violation details: [ASM::violation details];"
log local0. "=========New iRule Data Done======"
}
