F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Working with Violations
Manual Chapter : Working with Violations

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 >>

About violations

Application Security Manager includes built-in violations. 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. When a violation occurs, the system can learn, alarm, or block a request (blocking is only available when the enforcement mode is set to blocking).

Violation names displayed in the Violation List are the names used as reference in the iRule ASM::custom_violation command and the ASM::violation name command. The violation name is also used in API, iControl, and TMAPI code.

You can also create user-defined violations if you need them on your system.

Types of violations

This table describes the types of violations that can occur. On the Security > Options > Application Security > Advanced Configuration > Violations List, 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.

Viewing descriptions of violations

You can view detailed descriptions of each violation to learn what causes that type of violation, and the type of security risks it could be related to.
  1. On the Main tab, click Security > Application Security > Blocking > . The Blocking Settings screen opens.
  2. Click the info icon preceding the violation you are interested in learning about. A popup screen shows the violation description, risks, and examples, if available.
  3. To view violations that have occurred for the current edited security policy, on the Main tab, click Security > Application Security > Policy Building > Manual Traffic Learning. The Manual Traffic Learning screen opens and lists any violations that the system found against the security policy. For most violations you can click the violation link to view learning suggestions which you can accept in the security policy, and additional information about the violations.
You can view descriptions for all the violations that can occur and see how the blocking settings are configured for the security policy currently being edited.

Changing severity levels of violations

You can change the severity levels of security policy violations for all application security events that occur system-wide. If violations occur, the system displays the events and severity level on the Security Alerts screen and logs the message in the Syslog. This is an optional task that you need to do only if you want to change the default severity levels of violations.
  1. On the Main tab, click Security > Options > Application Security > Advanced Configuration > Violations List.
  2. Review the list of built-in violations and severities.
  3. To change the severity of a violation, click the violation name. The Built-In Violation Details popup screen opens where you can view information about the violation and the current severity level.
  4. From the Severity list, select the severity level you want to use for the violation. The available severities are: Emergency, Alert, CriticalError, Warning, Notice, and Informational.
  5. Click Update.
The new severity level is shown in the violations list. If the changed violation occurs, the system uses the new severity level. Changes made to the event severity levels for security policy violations apply globally to all security policies on the Application Security Manager.

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 iRulesto 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

You can create up to 28 user-defined violations for situations not covered by the built-in violations. User-defined violations are helpful for mitigating zero-day attacks, and to protect your web application against specific vulnerabilities not yet protected by Application Security Manager (ASM). You can write iRules to detect new attack conditions and issue the violation.
  1. On the Main tab, click Security > Options > Application Security > Advanced Configuration > Violations List.
  2. Click User-Defined Violations.
  3. Click Create. The Create New User-Defined Violation popup screen opens.
  4. In the Violation Name field, type a name for the violation using alphanumeric characters and underscores only. The recommended format is an uppercase alphanumeric string starting with VIOLATION, having words separated by underscores; for example, VIOLATION_SLOW_POST. The name is used as reference in the ASM::custom_violation and ASM::violation name iRule commands, and in APIs, iControl, and TMAPI.
  5. In the Violation Title field, type descriptive text for the violation. It is typically similar to the name but in a more friendly format. This text appears wherever the violation is referred to, including configuration of blocking settings, the proxy log, and reports.
  6. From the Type list, select the category of the violation, or leave it set to Unspecified.
  7. From the Severity list, select the severity level of the violation. The available severities are: Informational, Notice, Warning, Error, Critical, Alert, and Emergency.
  8. From the Attack Type list, select one of the existing attack types. If none of the specific attack types is appropriate, select Other Application Attacks or Other Application Activity. The attack type is shown when you click the Info icon next to the violation name on the Blocking Settings screen.
  9. In the Description field, type a description of the violation. The description is shown when you click the Info icon next to the violation name on the Blocking Settings screen.
  10. Click Create.
The custom violation is added to the list of user-defined violations. It is also listed under other violations on the Blocking Settings screen for each security policy on the system. You can edit all attributes of a user-defined violation except the name.
You should now set up the blocking settings (Alarm and Block only) for the user-defined violation enabling the violation for specific security policies. You also need to write iRules that issue the custom violations based on the conditions available using the ASM::raise violation_name [violation_details] command. ASM blocks requests according to the violation’s blocking settings and operation mode, and logs details in the Requests log. For detailed information on iRules, see the F5 Networks DevCentral web site, http://devcentral.f5.com.

Enabling user-defined violations

Application security iRule events must be activated in the security policy to enable user-defined violations.
You enable user-defined violations by configuring the Alarm and Block flags, or blocking actions, for user-defined violations. The blocking actions (along with the enforcement mode) determine how the system processes requests that trigger the violation.
  1. On the Main tab, click Security > Application Security > Blocking. The Settings 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. Adjust the Enforcement Mode setting if needed.
    • To block traffic that causes violations, select Blocking.
    • To not block traffic even if it causes violations (allowing you to make sure that legitimate traffic would not be blocked), select Transparent.
    You can only configure the Block flag if the enforcement mode is set to Blocking.
  4. For each user-defined violation (listed in Other Violations), set the Alarm and Block settings.
    Option Description
    Alarm If selected, the system records requests that trigger the violation in the Charts screen, the system log (/var/log/asm), and possibly in local or remote logs (depending on the settings of the logging profile).
    Block If selected (and the enforcement mode is set to Blocking), the system blocks requests that trigger the violation.
  5. Click Save to save your settings.
  6. To put the security policy changes into effect immediately, click Apply Policy.
Once you have an iRule that determines when to issue the user-defined violation (and the enforcement mode is set to blocking), the specified alarm or block action occurs.

Sample iRules for user-defined violations

You can write iRules to activate user-defined violations that you created and enabled in a security policy.
Note: The examples in this topic may not work depending on your configuration. Some examples include multiple ways of setting them up, or may require additional code. For more information about iRules, refer to devcentral.f5.com.

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 #Using new event 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 ASM::raise violation4 {{violation.name violation4} {violation.type test1} {violation.type test2}} #log the new 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];" #using new command lappend, create violation details and raise #another user-defined violation set x {} lappend $x {key1 value1} lappend $x {key1 value2} ASM::raise violation5 $x } #using old event when ASM_REQUEST_VIOLATION { # log the support ID for the enforced request log local0. "SupportID: [ASM::support_id];" #log request status log local0. "Request Status: [ASM::status];" #log the severity of the request log local0. "Severity: [ASM::severity];" #log Client IP log local0. "ClientIP: [ASM::client_ip];" #log the number of different violations detected in the request log local0. "Number of Violations: [ASM::violation count]" #log iControl violation names log local0. "Violation 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 ASM::raise violation4 {{violation.name violation4} {violation.type test1} {violation.type test2}} #log the new number and names of 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];" #using the new command lappend, create violation details #and raise another user-defined violation set x {} lappend $x {key1 value1} lappend $x {key1 value2} ASM::raise violation5 $x }

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 customized 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======" }

Deleting user-defined violations

You can delete user-defined violations if you no longer need them.
  1. On the Main tab, click Security > Options > Application Security > Advanced Configuration > Violations List.
  2. Click User-Defined Violations.
  3. Select the user-defined violation that you want to delete.
  4. Click Delete. The deleted violation is moved to the list of Historical Violations.
The deleted user-defined violation and details about it remain on the system in the Historical Violations list. From there, you can restore previously removed user-defined violations if you need to.

Exporting and importing user-defined violations

You can export user-defined violations to back them up, or for importing onto another Application Security Manager system.
  1. On the Main tab, click Security > Options > Application Security > Advanced Configuration > Violations List.
  2. Click User-Defined Violations.
  3. Select the user-defined violations to export.
  4. Click Export. The violations are saved in an XML file with the name, date, and time stamp: user_defined_violations_yyyy-mm-dd_hh-mm.xml.
  5. To import the user-defined violations onto another system, navigate to the User-Defined Violations List on the other system, click Import, and specify the exported file.
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