APM Cookbook Series: You Down with OTP? (pt1)
All corny early 90's hip hop jokes aside, if you're not down with OTP or One-Time Password by now, then this is definitely the place to be. By the time you finish this two part series you will understand and be able to deploy a complex OTP policy complete with error handling. We will start with the basics in part one and then drive it home in part two. Like many, my first experience with OTP and APM on the BIG-IP was guided by fellow F5'er, Per Boe's excellent write up from a post that none other than the illustrious, Jason Rahm shared with us way back in early 2011. As with all things tech, 3 years later things have changed quite a bit and although fundamentally OTP has not changed that much, our implementation has been streamlined. For instance, the once necessary iRule has been integrated and we can do some really cool new things with embedded dropdown options on the logon page. Cody's great Cookbook article here demonstrates the very popular dropdown use-case for domain selection. In part one we will review all of the necessary objects and configuration of those objects. Then we will start with a functional OTP Access Policy that leverages the objects we created to get familiar with the basic concepts. This will be very similar to the write up from 2011 but with an open-source SMS Gateway that anyone can use free of cost. Finally, we will wrap things up in part two with a deeper dive into OTP as a technology and create a more complex OTP policy. This policy will include a logon page dropdown (new in 11.5.x) that can dynamically select the use of SMTP and SMS delivery mechanisms, with full error handling, based on available AD attributes or logon page selection. By the end of these articles you will be more than down with OTP, I promise!! In fact you should be floored with all of the possibilities that VPE can provide by implementing policy branches to customize the UX....which is what it's all about right?? Well maybe...after SUX - the (Secure User Experience) of course :) BTW: This lab demonstration was a blast to build out and if you are anything like me, then the first time you hear that SMS alert come in on your phone, you will definitely smile. Try it out, have fun and post feedback! Prerequisites: You will need the following before proceeding with Part 1: A client to test from (Windows, MAC or Linux with any browser) Active Directory with the following attributes available and set with values; (mobile, mail) A BIG-IP with APM provisioned. (v11.x) - recommended 11.5.x. Your BIG-IP must be able to get to the Internet. A device capable of receiving SMS Part 1: Creating the Virtuals We will begin by configuring the Virtual Servers that will host the APM Access Policy. All you technically need is a standard virtual server listening on port 443 with an http and client side ssl profile applied. Given you are working in the Common partition, create your virtuals with the following commands. tmsh create ltm virtual /Common/ {destination /Common/:443 ip-protocol tcp mask 255.255.255.255 profiles add { /Common/clientssl {context clientside} /Common/http { } /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } Optional: Create a port 80 redirect so you don't have to remember to type "https" tmsh create ltm virtual /Common/ { destination /Common/:80 ip-protocol tcp mask 255.255.255.255 profiles add { /Common/http { } /Common/tcp { } } rules { /Common/_sys_https_redirect }} Verifying Resources AD - Do not move on until you can authenticate with an account (preferably a service account but any will do for this lab as long as it can authenticate and read). Instructions for validating authentication can be found below in Figure 1. Configure your Active Directory Object under: Access Policy >> AAA Servers Figure 1. Configuring AAA AD Servers To verify the above configuration before moving forward you can use the "adtest" command. *The special characters in the password are escaped with "\". adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u serviceacct -w p\@\$\$w0rd1 [root@bigip1:Active:Standalone] config # adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u user1 -w p\@\$\$w0rd1 Test done: total tests: 1, success=1, failure=0 Tip: use the debug option if you have failures. -d 1 adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u serviceacct -w p\@\$\$w0rd1 -d 1 Once authentication is verified we can create our OTP HTTP Form, also found under Access Policy >> AAA Servers Figure 2. Configuring AAA HTTP Form A quick word on textbelt, a free open source SMS gateway and brain child of Ian Webster, a Software Engineer at Google. We all owe him a debt of gratitude and possibly a donation for maintaining a free, awesome and downright user friendly SMS service. There are a few limitations that you can get familiar with here: http://textbelt.com but in general this sublime open source SMS service can't be beat for ease of use and lab testing. Thanks Ian! Take a close look at the Form Method, Form Action, Hidden Form Parameters/Values and Successful Logon Detection Match Type and Value fields in Figure 2. Most of the parameters/values were dictated by the textbelt API and are included on the textbelt homepage but the Hidden Form Parameters/Values field has some unique customizations so that APM can insert custom variables per the session. Breakdown Let's break down the variables in the string for the Hidden Form Parameters/Values field: Values will be learned during certain stages of policy execution. For example, when the AD Query action takes place the "mobile" attribute will be learned and stored in memory as a session variable. When the OTP Generate action takes place then the value will be determined for that session variable. number=%{session.ad.last.attr.mobile}&message=OTP %{session.otp.assigned.val} Expires after use or in %{session.otp.assigned.ttl} seconds. The variable "{session.ad.last.attr.mobile}" will pull the value from the Active Directory Attribute for "mobile". The variable "{session.otp.assigned.val}" will pull the value from a secure memory space and insert it into the message body. The variable "{session.otp.assigned.ttl}" will display the timeout value in seconds for the OTP as configured in your policy. Ultimately the message will look like this when it is sent to the SMS Gateway: number=555123456&message=OTP 786341 Expires after use or in 300 seconds If you have problems, Ian also listed some troubleshooting commands that you can utilize. Make sure to check those out, assign all fields per the image above and move on once you have the syntax correct which should be fine as long as you followed the steps above. That's it for the pre-requisites. Now time for the fun part...tying it all together in VPE with an Access Policy. Access Policy Configuration Head on over to Access Policy>>Access Profiles>>Access Profiles List and click the "+". Create an APM/LTM type profile and take all of the defaults. Choose your language and hit "Finished". Now edit your policy. You should be here: Figure 3. Creating the Access Policy Add a logon page and take the defaults. Add an AD Auth object and set your AD Server. Figure 4. Adding AD Auth Add a message box or MB, off of the successful branch and keep the successful ending at deny. APM Pro Tip: This MB will serve as your successful ending alert and prevent you from having to manually clear sessions constantly during the policy testing phase. Figure 5. Adding a Message Box (MB) Your policy should now look like this: Figure 6. Visual Policy Now apply your new Access Policy to the Port 443 Virtual Server and test. If all goes well you should see this positive affirmation after successful authentication: Figure 7. Message Box - Positive Affirmation Adding the OTP Macro Figure 8. Adding the OTP Macro Add an Ad Query object, name it appropriately and choose your AD server. Set the Required Attributes to "mobile" and "mail". (We will only use mobile in Part 1 of this series) Figure 9. Adding AD Query & Required Attribs Edit the Branch Rules and delete the default expression "Primary User Group 100". Figure 10. Editing AD Query Branch Rules Add an OTP Generate object and take the defaults. Your policy should now look like this: Figure 11. Verify the Visual Policy - OTP Macro After the OTP Generate object add a variable assign object: Custom Variable: session.user.otp.pwd = session.user.otp.pwd Custom Expression: expr {[mcget {session.user.otp.pw}]} Figure 12. Variable Assign - Secure OTP (Select Secure from the list to define the session variable as secure. A secure session variable is variable that is encrypted in the session database. The secure session variable value is not displayed in the session report, or logged by the logging agent.) Next we are going to call on that HTTP AAA Form that we created earlier. Add an HTTP Auth Agent: Figure 13. Adding HTTP Auth Agent Add another logon page so the client has a place to enter their OTP password: Figure 14. Adding the OTP Logon Page Add an OTP Verify Object. Your policy should look like this: Figure 15. Verify Visual Policy - OTP Macro Edit your terminals to indicate success or failure: Figure 16. Editing Terminals You may need to add a new one. Make sure that the default stays on top: Figure 17. Adding New Terminals Now add the Macro to your main policy between the AD Auth and the MB: Figure 18. Adding the Macrocall Here is the final policy. We will keep the allowed ending set to "deny" for now until we are ready to go prime time with the site. Figure 19. Verify Visual Policy - Complete As long as you have your mobile number set under the AD Attribute and given your BIG-IP has outbound connectivity, then you should now be able to successfully test your new service and receive a SMS that, when received, looks like this: Figure 20. IOS - SMS Message Received If you successfully authenticate you should reach your affirmation again. Figure 21. Congratulations! Not only have you achieved success, you have completed part 1! Great job. Please be sure to check out part 2 where we will dive even deeper into APM and this OTP policy. Here's a sneak peak at the macro: You didn't think I was going to show you the whole thing yet did you?!!? ‘til next time…
Breaking up with your identity: it’s not me, it’s you!
Let me tell you why I’m glad my gran is not on the Internet. When it comes to technology securitymost of myexperienceis with customers: with other peoples systems, not mine. However, today I write about a personal experience that scares me a little. I signed up for a Gmail account back when it was an invitation-only beta service. My first impression of it was nothing short of wow! This exclamation inspired by its simplicity, and the fact that it offered an enormous amount of free space. I recall being impressed by that fact that in a time of rapid innovation the Gmail team weren’t trying to do too much with it. I think it was the first time I was able to describe a web-based service as being humble and don’t think I’ve seen anything like it since, until maybe Medium. Over the years my relationship with Google grew to include Google Docs, Google Sites, Analytics and even ‘Google Apps for Your Domain’. Our relationship blossomed – not quite this far, but we were on a good thing. Being an early adopter often means getting first pick of your account name and avoiding the dreaded nathanpearce1234. One cannot win all the time and I don’t always get my way but occasionally there is room for compromise. For example, when I signed up for Twitter, @NathanPearce was already taken. Consequently, and like many others, I reversed my name and have been happily tweeting from @PearceNathan for a few years now. It did weird me out a little when @NathanPearce followed me earlier this year (are you reading this post, @NathanPearce?). For the sci-fi fans: fortunately, I didn’t implode, burst into flames or leap to a parallel universe at this occurrence. I’ve managed to come to terms with the fact that there are a number of people in the world named Nathan Pearce. Mum, you were wrong! There’s a Nathan Pearce working at Sony Entertainment, another is a web savvy 9 year old, and then we have the most interesting Nathan Pearce of all – the web-challenged, heavy-metal loving, corn farmer. And it’s not just his music and farming preferences I’m familiar with. I also know where he travels, his preferred dating sites (a niche farmer-friendly service) and a number of other interesting factoids. How do I know all this? Because Nathan-corn-metal, as he will be known hereafter, keeps providing my email address to people thinking that it is his own. Before you start speculating as to how this mishap can occur, a lesser-known fact about Gmail is how it handles a period before the @ symbol. With Gmail, the following email addresses are all the same: firstlast@gmail.com first.last@gmail.com f.irstlast@gmail.com And, so on. I’ve heard of some clever people using this to their advantage: providing one format for family, another for shopping on-line, etc., and then using Gmail filters to file (delete) messages as appropriate. So, I can confirm that this isn’t a simple formatting mistake. Nathan-corn-metal believes that my email address are belong to him. This mistake (delusion) might seem trivial to some but has also lead to a few interesting circumstances. Email confirmation Nathan-corn-metal does get on the net from time to time. My first interaction was when he signed up for Decibel Magazine – a heavy metal e-zine. I’ve started to enjoy the monthly issues and have been following the developments of many a ‘Lars’ and the up and coming band, Monster Magnet. I’m still not listening to the genre but I’ve developed an appreciation that was never there before. I do hope he renews again this year, for the third time! What Nathan-corn-metal has not learned to appreciate is that when one sign’s up for a service on-line, there often lacks a process to confirm one’s contact details. The moment he hits Submit, the subscription was handed over to me and, unfortunately, I have no way of letting him know of the error, as email is the only detail of contact provided. Telephone bookings I’ll admit that the Decibel Magazine subscription didn’t actually tip me off as to the problem at hand. It was the creation of an on-line travel account. I assume Nathan-corn-metal’s account was setup over the telephone for the following reason’s: the login id was the email address there was a flight booking already in the account So, how did I know there was a flight booked, you may ask? Was there not a password on the account? Yes, there was a password on the account. However, I didn’t need it as there was a link in the automated email addressed to me that went straight to the booking, providing me with access to everything including account preferences and the booking page. Good Samaritan for the good intention At this point I started thinking about how I would feel if I’d made such a mistake and I decided to try and fix things. Surely, the travel company had a contact phone number. I called the travel agency asking to speak to a representative about an existing booking. To their credit, they were very quick to answer the phone. Unfortunately, every moment after this was truly shocking. I didn’t play any games for, despite his apparent learning difficulties, Nathan-corn-metal, for all I know, could be a decent chap. But my attempt at doing the right thing was met with resistance. Maybe it was a lack of understanding of the urgency of the problem? I didn’t know but I had to attempt a new tactic. Being told over and over again that it wasn’t the travel agencies problem was not good enough. Next, I explained it in terms of liability by advising that I would be altering the flight details and then maybe booking myself a trip to Venice using their customer credentials. Then by explaining that as they were the ones to leak said credentials it should make interesting reading in the news. Suddenly, my suggestion that they lock down the account and contact Nathan-corn-metal by telephone immediately was set in motion. Should this have been so difficult? Lesson learned? When so many on-line services fail to provide sufficient checks to ensure we are who we say we are, it is suddenly very simple for a lot to go wrong. I’m delighted to say that I still communicate with my grandparents via hand-written letter for I don’t believe that the Internet is a safe place for them. While the law might have clear definitions for liability, in reality, what is practiced is far from acceptable. Some organizations are building in security checks but only from the perspective of hacking attempts. What about a simple mistake at the time of account creation as done so by the aforementioned head banging tractor driver? In this example, holding off on the creation of an account until verification via OTP (One Time Password) for example would eliminate many false positive during account creation. Never underestimate the human element!
