Configuring iRules for Custom Traffic Management on F5 (Session Headers)

F5 iRules provides a toolset within the F5 BIG-IP platform, specifically with the Local Traffic Manager (LTM), for dynamic control and manipulation of network traffic. iRules utilize a scripting language based on TCL (Tool Command Language), which allows administrators to direct, inspect, and modify the traffic passing through the network in real time. The capability to implement custom logic and manage traffic based on specific network and application conditions makes iRules an essential component for customized traffic management solutions.

Here’s a basic rundown of what iRules can do with this scripting capability:

Inspect traffic: iRules can examine the data passing through the network, such as URLs, headers, and payloads, to make decisions based on what the data contains.

Direct traffic: Based on the inspection, iRules can route traffic to different servers or destinations. This is useful for load balancing, ensuring that no single server gets overwhelmed.

Manipulate traffic: iRules can modify the data in transit, such as changing headers, rewriting URLs, or even blocking certain requests entirely.

This capability makes iRules an essential tool for customizing how traffic is handled on a network, ensuring that specific business rules or security protocols are adhered to.

Key Definitions for Session Management 

• Safe Session: Sessions identified as secure and free from any threats.
• At-Risk Session: Sessions that are potentially compromised or exhibiting unusual behavior.
• Header Payload: The data within HTTP request or response headers is crucial for maintaining the integrity of transmitted information.

iRules Configuration Steps

Appdome’s iRules for F5 are designed to enhance security and manage sessions more effectively. Below is an explanation of what each provided iRule does.

1. Navigate to Local Traffic -> iRules -> iRule List
2. Select Create by clicking on the + sign button.
3. Give the iRule a name, such as my_irule. The full pathname of the iRule cannot exceed 255 characters or contain spaces.
4. Paste the provided iRules

Nonce Validation: Checks if the nonce has already been used to prevent replay attacks.

 # Validate that the nonce has not been reused.
    if { [table lookup -notouch $NONCE] != "" } {
        if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
            log local0. "INFO NONCE used - rejecting [IP::client_addr]"
        }
        # Check passthrough mode before rejecting
        if { $passthrough_mode == 1 || $disable_nonce_validation == 1 } {
            if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
                log local0. "INFO Passthrough mode enabled, bypassing NONCE reuse check."
            }
            pool /Common/Pool-AppDome
            return
        }
        HTTP::respond 409 content "NONCE used"
        return
    }

Timestamp Validation: Ensures that the request is not replayed outside a valid time window.

 # Get the current time and calculate the time difference.
    set now [clock seconds]
    set heartbeat_validity {{HEARTBEAT_VALIDITY}}
    set time_elapsed [expr { $now - $TIMESTAMP }]

    # Validate timestamp: if expired, log and handle according to passthrough mode.
    if { $time_elapsed > $heartbeat_validity } {
        if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
            log local0. "INFO Heartbeat expired"
        }
        # Check passthrough mode before rejecting
        if { $passthrough_mode == 1 || $disable_timestamp_validation == 1} {
            if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
                log local0. "INFO Passthrough mode enabled, bypassing heartbeat expiration check."
            }
            pool /Common/Pool-AppDome
            return
        }
        HTTP::respond 408 content "Heartbeat expired"
        return
    }

Missing values

# Check if any required values are missing.
    if { $TIMESTAMP == "" || $NONCE == "" || $SIGNEDMESSAGE == "" } {
        if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
            log local0. "INFO Missing values!"
        }
        # Check passthrough mode before rejecting
        if { $passthrough_mode == 1 } {
            if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
                log local0. "INFO Passthrough mode enabled, bypassing missing values check."
            }
            pool /Common/Pool-AppDome
            return
        }
        HTTP::respond 412 content "Missing values"
        return
    }

Add an iRule to your virtual server

1. Go to Local Traffic > Virtual Servers.
2. Select the virtual server you to which you want to apply the iRule.
3. Select Resources tab.
4. Select Manage
5. Select the iRule you just created from Available list and move it to the Enabled list.
6. Select Finished.

Related Articles:

• MobileBOT™ Defense
• Using F5 WAF with Appdome MobileBOT™ Defense
• How to Use Session Headers in Mobile Bot Defense

How Do I Learn More?

If you have any questions, please send them our way at support.appdome.com or via the chat window on the Appdome platform.

Thank you!

Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app defense easy. We hope we’re living up to the mission with your project. If you don’t already have an account, you can sign up for free.