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

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 14.1.3, 14.1.2, 14.1.0
Manual Chapter

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

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
    Options
    Application Security
    Advanced Configuration
    Violations List
    .
    The Violations List screen opens.
  2. Click 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
    Traffic Learning
    .
    The Traffic Learning screen opens and lists learning suggestions many of which are related to violations that the system found against the security policy.
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
    ,
    Critical
    Error
    ,
    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.

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 violation on the Learning and 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.
The violation rating is included with information on screens in Application Security Manager™, such as:
  • 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

You can investigate potential attacks by reviewing violation ratings of illegal requests. Requests with a high violation rating are more likely to be attacks that you may want to investigate.
  1. On the Main tab, click
    Security
    Event Logs
    Application
    Requests
    .
    The Requests screen opens, where, by default, you view an event log displaying illegal requests for all security policies.
  2. From the Requests List filter, adjust the
    Violation Rating
     slider to 4-5, and click
    Apply Filter
    .
    The Requests List displays illegal requests with a violation rating of 4 or 5.
  3. In the Requests List, click a request to view information about the request and any violations associated with it.
    The screen refreshes, showing the Request Details area, where you see any violations associated with the request and other details, such as the security policy it relates to, the support ID, the violation rating, and potential attacks that it could cause.
  4. Use the Violation area elements to view details about a violation associated with an illegal request:
    • To view details about this specific violation such as the file type, the expected and actual length of the query, or similar relevant information, click the violation name.
    • To display a general description of that type of violation, click the info icon to the left of the violation name.
By reviewing the high-rated illegal requests, you can determine whether your application is being attacked and get an idea of where the attacks are coming from and what the attackers are doing. As a result, you may decide to modify the security policy or take other steps that do not involve Application Security Manager such as modifying firewall settings or changing the application.

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

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 Learning and 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 Learning and Blocking Settings screen.
  10. Click
    Create
    .
The custom violation is added to the list of user-defined violations. 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
    Policy Building
    Learning and Blocking Settings
    .
    The Learning and Blocking Settings screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown 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 allow 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 on violations 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 when the system detects the violation.

Sample iRules for user-defined violations

You can write iRules® to activate user-defined violations that you created and enabled in a security policy.
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  

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

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.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information