APM 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 } } }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
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
Why you still need layer 7 persistence
Tony Bourke of the Load Balancing Digest points out that mega proxies are largely dead. Very true. He then wonders whether layer 7 persistence is really all that important today, as it was largely implemented to solve the problems associated with mega-proxies - that is, large numbers of users coming from the same IP address. Layer 7 persistence is still applicable to situations where you may have multiple users coming from a single IP address (such as a small client base coming from a handful of offices, with each office using on public IP address), but I wonder what doing Layer 4 persistence would do to a major site these days. I’m thinking, not much. I'm going to say that layer 4 persistence would likely break a major site today. Layer 7 persistence is even more relevant today than it has been in the past for one very good reason: session coherence. Session coherence may not have the performance and availability ramifications of the mega-proxy problem, but it is essential to ensure that applications in a load-balanced environment work correctly. Where's F5? VMWorld Sept 15-18 in Las Vegas Storage Decisions Sept 23-24 in New York Networld IT Roadmap Sept 23 in Dallas Oracle Open World Sept 21-25 in San Francisco Storage Networking World Oct 13-16 in Dallas Storage Expo 2008 UK Oct 15-16 in London Storage Networking World Oct 27-29 in Frankfurt SESSION COHERENCE Layer 7 persistence is still heavily used in applications that are session sensitive. The most common example is shopping carts stored in the application server session, but it also increasingly important to Web 2.0 and interactive applications where state is important. Sessions are used to store that state and therefore Layer 7 persistence becomes important to maintaining that state in a load-balanced environment. It's common to see layer 7 persistence driven by JSESSIONID or PHPSESSIONID header variables today. It's a question we see in the forums here on DevCentral quite often. Many applications are rolled out, and then inserted into a load balanced environment, and subsequently break because sessions aren't shared across web application servers and the client isn't always routed to the same server or they come back "later" (after the connections have timed out) and expect the application to continue where they left it. If they aren't load balanced back to the same server, the session data isn't accessible and the application breaks. Application server sessions generally persist for hours as opposed to the minutes or seconds allowed for a TCP connection. Layer 4 (TCP) persistence can't adequately address this problem. Source port and IP address aren't always enough to ensure routing to the correct server because it doesn't persist once the connection is closed, and multiple requests coming from the same browser use multiple connections now, each with a different source port. That means two requests on the same page may not be load balanced to the same server, even though they both may require access to the application session data. These sites and applications are used for hours, often with long periods of time between requests, which means connections have often long timed out. Could layer 4 persistence work? Probably, but only if the time-out on these connections were set unreasonably high, which would consume a lot more resources on the load balancer and reduce its capacity significantly. And let's not forget SaaS (Software as a Service) sites like salesforce.com, where rather than mega-proxy issues cropping up we'd have lots-of-little-proxy issues cropping up as businesses still (thanks to IPv4 and the need to monitor Internet use) employ forward proxies. And SSL, too, is highly dependent upon header data to ensure persistence today. I agree with Tony's assessment that the mega proxy problem is largely a non-issue today, but session coherence is taking its place a one of the best reasons to implement layer 7 persistence over layer 4 persistence.F5 APM Limit max user per session
Currently, F5 running on APM with SSL VPN function. How is it possible if I want to set the max session per user to "1". The Access Profile setting allow me only ... for example scenario of F5 USER A login to PC1 - > Passed USER A login to PC2 - > Passed and terminate the session on PC1 But it's not my desire, I want the scenario like USER A login to PC1 - > Passed USER A login to PC2 - > Cannot Login Are there any solution that can config it, or I have to use iRules to detect it. Thanks
User ID based pool selection
hi there! I am trying to write one iRule to select the pool based on user ID. For example, when the user tries to login, grab the ID of test1@example.com and send to pool1 and for other user ID test2@example.com send to pool2. Essentially, after successfully logged in have tried to save the user ID in the table. However, the issue is when test1 logs in, test2 cannot login. Not sure what I am doing wrong. Is there any limitation on table? I assumed it should be session based when used from different browsers. Any help on this will be highly appreciated. F5 version: 12.1 Cheers. Best regards Hyder
