The BIG-IP Application Security Manager Part 9: Username and Session Awareness Tracking
This is the penultimate article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first eight articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Let's say you are building an awesome web application. You want to have as many visitors as possible, but you want to keep your application safe from malicious activity. The BIG-IP ASM can help secure your application by blocking harmful behavior before it ever gets to your app, but it can also help you track down and block the bad guys if they are able to somehow find a way in. This article will focus on the different ways you can track users by session or by username. Using these tracking capabilities, you can find a bad guy, and then you can track the activity or block it altogether. Session Tracking A session begins when a user accesses the web application and it ends when a user exits the application (or when the user exceeds an established timeout length). When a user accesses a web application, the ASM generates a session ID number for that specific session. You can track a specific session by enabling "Session Awareness" on the ASM. Navigate to Security >> Application Security >> Sessions and Logins >> Session Tracking and you will see the screen shown below. Simply check the "Enabled" box for Session Awareness (and Save and Apply Policy) and the ASM will give you the option to take certain actions on any specific session you choose. So, if you are looking through your ASM event logs and notice that a particular user is doing some bad things, you can start logging all activity for that user session or you can block the session completely. I used my trusty Hack-it-yourself auction site to do some testing with this feature. I enabled Session Awareness and then accessed the auction site. Then, I reviewed the ASM event logs (Security >> Event Logs >> Application >> Requests) to see the details of the activity for my user session. Notice in the screenshot below that the Request Details show the Session ID as well as a link to Session Tracking Details (it also gives you a link to the APM session details...pretty cool). When you click on the Session Tracking Details link, you are given the option to Log All Requests, Delay Blocking, and/or Block All. I selected Log All Requests and Block All, and then I tried to log back into the auction site. Guess what? Totally got blocked...and it all got logged in the ASM event logs. So, using this blocking feature, I can easily stop a user from accessing the web application simply by blocking the user session. Now, here's a little more of my story...I accessed the auction site from my Firefox browser and, like I said before, I got blocked. I switched over to Internet Explorer and accessed the site without any problem. Makes sense, though, because I started a totally new session with the other browser. I just wanted to make sure you kept that in mind as you determine the best way to track and stop the bad guys who access your application. Username Tracking Let's talk about your awesome web app for a second. When you created said web app, you no doubt built a login page and established URLs and parameters so that users could authenticate and gain access. By adding these URLs and parameters into your security policy, the ASM can track users by username via the login URL you establish. In order to configure the appropriate login and access parameters, navigate to Security >> Application Security >> Sessions and Logins >> Login Pages List and create a new Login Pages List. In the Login URL, select either Explicit or Wildcard then select either HTTP or HTTPS based on the type of traffic the application accepts, then type in the path of the login page. Next, you can select the Authentication Type (I chose HTML Form based on the structure of the Hack-it-yourself auction site). Next, type in the parameter names for the application's Username and Password parameters (these are case sensitive). When the ASM detects these parameters used together, it knows that a login attempt is taking place. Finally, you need to configure Access Validation criteria that must be satisfied in order for the ASM to allow the user to access the authenticated URL. It's important to note that at least one of these criteria must be selected. If multiple criteria are selected, they must all be satisfied in order for the ASM to allow access to the authenticated URL. The screenshot below shows the settings for my Hack-it-yourself auction site: After the Login Page Properties are set, you can go back to the Session Tracking settings and add the Login Page to the Application Username settings (see the screenshot below). This tells the ASM to start tracking the username from the login URL you listed. The Test I accessed the auction site and logged in with my username (jwagnon) and password. See the screenshot below. Based on all the ASM settings I configured earlier, the ASM should have recognized this login and it should give me the option of tracking this specific user. Sure enough, the ASM Event Logs show the login action (notice the log entry for the Requested URL of /login.php in the screenshot below). I clicked on this specific log entry, and the request details show that the username "jwagnon" logged in to the site. Much like the session tracking options, the ASM gives the option to Log All Requests, Delay Blocking, and/or Block All activity from this specific user. I chose to Log All Requests and Block All activity from this username. Then, I attempted to log back into the auction site using the "jwagnon" username and password, and the ASM blocked the request. Remember how I switched from Firefox to Internet Explorer on the session awareness tracking and I was able to access the site because of the new session I started? Well, I tried that same thing with the username tracking but the ASM blocked it. That's because I used the same username to access the application from both browsers. I also wanted to show the actual HTTP request from this login action. I clicked on the HTTP Request tab for the /login.php event. The screenshot below shows that the request includes the parameters "username" and "password". These are the values for the username and password parameters that were identified in the Login Page Properties that we saw earlier (this is why the values for the parameters are case sensitive). The ASM recognized these two parameter values in the HTTP Request for the /login.php URL, so it gave the option for tracking the username. Session Tracking Status The last thing I'll mention about all this tracking goodness is that the ASM gives you the option of viewing all the session and/or username tracking details from one screen. Navigate to Security >> Reporting >> Applications >> Session Tracking Status to see all the details regarding the sessions and/or usernames you have taken action on. Notice in the screenshot below that the details for Block All and Log All Requests for both session and username are listed (it even shows the value of the session and username). You can click on the hyperlink "View Requests" on the right side of the page and the ASM will display all the requests that satisfy that specific criteria. Pretty cool and handy stuff! Well, I hope this article has helped in your understanding of yet another fantastic capability of the BIG-IP ASM. Here's to tracking down the bad guys and shutting down their nefarious behavior! Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
F5 loadbalancer and session timeout in ASP application
Hello, I have a problem with F5 loadbalancer and session timeout in ASP application. We have F5 in out company for few days Since then, there is a problem with session timeout. ASP app has 30min timeout set but keeps logging of already after few minutes. This phenomenon didn't occur with Windows loadbalancer.
controlling APM access policy from iRule
im trying to influence the access policy to use a different path through the VPE based on a variable set in an irule with ACCESS::session data set. the VPE has an element with some branch rules and expressions like expr { [mcget {session.tst.choice}] == 1}. it seems you can only successfully use this by setting the variable with ACCESS::session data set during the handling of HTTP_REQUEST on /my.policy (this was enabled with ACCESS::restrict_irule_events disable in CLIENT_ACCEPTED). is that correct or am i missing something?
table command causing abort of rule event HTTP_REQUEST
Hello everyone, This is my first dig into iRules, and I'm hitting an issue with the table command that is aborting my rule. I'm essentially trying to rate limit requests per URI per ASPNET Session ID. I've been working with the iRule for a couple days, so I know it's not at its best and has excessive logging (for the purposes of figuring this out). I'm testing with a backend server that doesn't use ASP, so I'm setting it statically in the iRule as a failsafe for now. I'm building that up now for testing.. but hit some snags. The main issue is the table command aborting the rule execution. I was originally putting many of the table lookups directly into the if statements, but I was able to resolve an abort earlier in the rule by setting to a variable first. Here are the logs: [admin@LTM1:ModuleNotLicensed:Active:Standalone] ~ tail /var/log/ltm Jun 6 11:07:23 LTM1 info tmm1[8579]: 01220009:6: Pending rule event HTTP_REQUEST aborted for 192.168.21.102:58079->10.202.20.170:80 (listener: /Common/Drupal_HTTP) Jun 6 11:07:23 LTM1 info tmm[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: HTTP_REQUEST Matched Jun 6 11:07:23 LTM1 info tmm[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: No session cookie found. Quitting.. Jun 6 11:07:23 LTM1 info tmm[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: Got URI, /drupal/themes/garland/images/bg-content-right.png, making key: session1_/drupal/themes/garland/images/bg-content-right.png Jun 6 11:07:23 LTM1 info tmm[8579]: 01220009:6: Pending rule event HTTP_REQUEST aborted for 192.168.21.102:58080->10.202.20.170:80 (listener: /Common/Drupal_HTTP) Jun 6 11:07:23 LTM1 info tmm1[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: HTTP_REQUEST Matched Jun 6 11:07:23 LTM1 info tmm1[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: No session cookie found. Quitting.. Jun 6 11:07:23 LTM1 info tmm1[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: Got URI, /drupal/themes/garland/images/bg-content-right.png, making key: session1_/drupal/themes/garland/images/bg-content-right.png Jun 6 11:07:23 LTM1 info tmm1[8579]: Rule /Common/JSESSIONRateLimit : iRule_Rate-Limiter: Matched second else.. not following conditionals. Jun 6 11:07:23 LTM1 info tmm1[8579]: 01220009:6: Pending rule event HTTP_REQUEST aborted for 192.168.21.102:58081->10.202.20.170:80 (listener: /Common/Drupal_HTTP) ` Here is the rule: `when HTTP_REQUEST { log local0. "iRule_Rate-Limiter: HTTP_REQUEST Matched" set maxReqs 5 set cooldownTimer 30 set sampleTimer 30 set timeout 30 if { [HTTP::cookie exists "ASP.NET_SessionId"] } { set aspid [HTTP::cookie ASP.NET_SessionId] log local0. "iRule_Rate-Limiter: SESSION Cookie present: $aspid" } else { log local0. "iRule_Rate-Limiter: No session cookie found. Quitting.." pool Drupal_Pool event HTTP_REQUEST disable set aspid "session1" } set reqURI [string tolower [HTTP::uri]] set key "$aspid" append key "_$reqURI" log local0. "iRule_Rate-Limiter: Got URI, $reqURI, making key: $key" set onCooldown [table lookup -subtable "Cooldowns" $key] if { $onCooldown != "" } { log local0. "iRule_Rate-Limiter: Key: $key is already on cooldown, sending HTTP:429 status code." HTTP::respond 429 } else { log local0. "iRule_Rate-Limiter: Matched second else.. not following conditionals." set currCount [table add $key 1] if { $currCount == "" } { table set $key 1 $timeout $sampleTimer log local0. "iRule_Rate-Limiter: First attempt for $key, adding to table for tracking." } else { if { ($currCount <= $maxReqs) } { table incr $key 1 incr currCount log local0. "iRule_Rate-Limiter: $key not on timeout, but not first request. Incrementing count to $currCount in session table." } else { HTTP::respond 429 table set -subtable "Cooldowns" $key "yes" $timeout $cooldownTimer log local0. "iRule_Rate-Limiter: $key triggered cooldown with $currCount attempts. Adding to cooldown table." } } } } Note that the rule is aborting at this line of code (line 31): set currCount [table add $key 1] Any help here is greatly appreciated, as I can't find anything outlining why this occurs. It's a small rule, and a simple lookup so I don't see why it would cause the rule to suspend indefinitely. Thanks! Ryan
CMP v10.0 compatible counters using the session table
Problem this snippet solves: This simple iRule shows how you can create a CMP-compatible counter. The first portion of the iRule demonstrates creating and incrementing a global counter which is accessible across all virtual servers and all TCP connections. The second portion of the iRule shows a method for creating a VIP-specific global counter. There is no enforcement of access to the VIP-specific global counter but it should prevent accidental trampling of session table entry names. For details on CMP compatibility you can check these resources: https://devcentral.f5.com/wiki/iRules.CMPCompatibility.ashx https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7751.html Code : when CLIENT_ACCEPTED { set log_prefix "[virtual name] [IP::client_addr]:[TCP::client_port]" } when HTTP_REQUEST { ####################################################################### # # Global (accessible across all VIPs) counter variable example # using the session table # # Look up the counter value. Will return a null string if it doesn't exist set value [session lookup uie "my_counter"] log local0. "$log_prefix: Global lookup value: $value" # Check if the value is null if {$value eq ""}{ # Add a new session table entry with a value of 0 session add uie "my_counter" 0 } else { # Increment the current value by 1 session add uie "my_counter" [expr {$value + 1}] } # Log the updated value log local0. "$log_prefix: Global lookup value: [session lookup uie "my_counter"]" ####################################################################### # # Local (accessible to only this VIP) counter variable example # using the session table # # Save the virtual server name to use as a session table entry prefix # This keeps the variables specific to the virtual server. set vip [virtual name] # Look up the counter value. Will return a null string if it doesn't exist set value [session lookup uie "${vip}_my_counter"] log local0. "$log_prefix: Per-vip lookup value: $value" # Check if the value is null if {$value eq ""}{ # Add a new session table entry with a value of 0 session add uie "${vip}_my_counter" 0 } else { # Increment the current value by 1 session add uie "${vip}_my_counter" [expr {$value + 1}] } # Log the updated value log local0. "$log_prefix: Per-vip lookup value: [session lookup uie "${vip}_my_counter"]" } Tested this on version: 10.0APM already active session error when changing landing URI
for a customer we setup APM with several landing URI to take different routes through the access policy. but of course the users sometimes make the mistake to enter https://apm.domain.com instead of using the correct landing URI, https://apm.domain.com/uri1. they can't correct this within the same session because then they get the "Access policy evaluation is already in progress for your current session." error screen. only workaround is closing the browser, which is annoying. i tried to solve this on that error screen, but that doesn't appear possible (in 11.2.1 and 11.4.0). so i created this iRule to solve it, perhaps it comes in handy for others. this iRule works in 11.4: when HTTP_REQUEST { set sid [ACCESS::session sid] switch -glob [HTTP::uri] { "/uri1*" - "/uri2*" { if {$sid != ""} { log local0. "request for /uri* and active session, remove session and redirect" ACCESS::session remove HTTP::redirect [HTTP::uri] TCP::close } } default { log local0. "default" do nothing } } } this iRule works in 11.2.1, i needed to add the after 5000 and HTTP::collect as APM doesnt quickly enough kill the session: when HTTP_REQUEST { set sid [ACCESS::session sid] switch -glob [HTTP::uri] { "/uri1*" - "/uri2*" { if {$sid != ""} { log local0. "request for /uri* and active session, remove session and redirect" ACCESS::session remove HTTP::collect after 5000 { HTTP::redirect [HTTP::uri] TCP::close } } } default { log local0. "default" do nothing } } }
