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
SSL VPN username case matters?
Just wondering if anyone has had this issue also. I have Big-IP 4000 (11.4.1 Build 637.0 Hotfix HF3) We have some users who cannot authenticate over the VPN, as they receive a username or password is incorrect mesage when they try. Session logs show Invalid user credentials. In troubleshooting with F5 and Microsoft, I happen to stumble on the fact that the accounts in question were older accounts (migrated from NT4, 2000 domain) and had capital letters in the name. We were looking at SID history. Example user John Smith had logon of JSmith. So I renamed the account and removed a letter from the users name, and made it all lowercase. So I changed it to jsmit, and change the password, I was able to then get the user authenticated. We then just renamed the account back to jsmith (all lowercase) and no issues since. Luckily we didn't have hundreds of users like this. we had several dozen, and when we rolled out the edge client, we were able to rectify any issues quickly.
