Sunday, 28 April 2013

Meraki Multi-factor Authentication

 In a recent post, I was voicing my concerns around the existing default security method employed by cloud-wireless solutions to 'protect' administrative access to their service. In summary, I proposed that some type of multi-factor authentication should be the default method of access for administrators (both customer and vendor) of cloud wireless services. The current default of a "username and password" is too weak when considering the damage that can be inflicted on an organization by unauthorized access to any cloud-managed network.

I heard from one of the guys at Meraki, letting me know that they already have multi-factor authentication. 

I already knew that they have an SMS OTP method, but I didn't really think that it was a particularly good solution. For instance, what about if you're out of cell-phone range or suffer one of those annoying delays in receipt of an SMS message? However, after taking another look, they also now show support for authentication amongst the authentication options, using the Google Authenticator app. Here is a screen-shot from the dashboard: 

This sounded very promising, so I thought I do a little more digging around the capabilities of their two factor authentication, particularly the Google Authenticator option.

Google Authenticator - Trust Google...Really?

My first thought when I saw the Google Authenticator app mentioned was: "How many organizations are going to trust or rely on Google to perform their authentications, or are going to want to sign up for a Google account just to authenticate against their cloud service?" It turns out it's not like that at all - you don't need to trust Google or involve them at all in the authentication process. 

The Google Authenticator app is an implementation of the time-based One Time Password Algorithm specified in the IETF standard  RFC 6238. Yes, that's right, an open, standards-based OTP process! That also means that you don't really need to use Google's OTP app at all - other apps which implement the same RFC should also work just as well (so you don't need to rely on the Google app). As far as I can tell, there is no communication or involvement with the Google network at all - the app is standalone (unless you were using it to log in to a Google service)

The algorithm relies on the "prover" (i.e. the app/soft token) and the "verifier" (i.e. authentication server) being able to accurately derive the current (correct) Unix time. During the registration process of the app/soft token and authentication server, the two entities are synced so that at any point in the future, they will be both be able to derive the same time-based OTP. One time passwords are generated every 30 seconds and are 6 digits long.

As long as the prover and verifier use the same RFC OTP standard, it doesn't matter who is providing the services. This fact is being taken advantage of by a growing number of organizations, including: Amazon Web Services, Google Mail, Dropbox, Lastpass and Microsoft (to name a few). They all use two factor authentication using the RFC 6238 standard. Users of multiple services are therefore able to use the same app (e.g. Google Authenticator) for authentication - they can have multiple accounts authenticated by the same instance of the authenticator app (even though they are all authentication systems run by different organizations) 

Jumping on this standardized OTP bandwagon looks like a very smart move by Meraki. Their customers can download an authenticator app (which is free in the case of Google Authenticator)  to their smartphone (Android or IOS) and use it to generate one time passwords that they can use to access their Meraki dashboard. Why invent a new OTP system when their is already a widely accepted, standardized method in place?

Setting Up The Meraki Dashboard for Two Factor Authentication

My next step was to have a go at setting up two factor authentication myself, to see just what is involved. Unless the process is relatively easy to execute, it may end up being more trouble than it's worth to configure.

As I'd already read about the requirement for Google Authenticator, I went along to the Google Play store and downloaded the app to my Android smartphone.

Next, I logged in to my Meraki dashboard and tried to set up two factor authentication for my organization. It initially refused, as I had to enable the two factor authentication for my own account first (which makes sense as I am the admin for the organisation). I went in to my profile and enabled two factor authentication. I was presented with the following screen:

As I already had the Google Authenticator app installed on my (Android) phone, I simply used the app to capture the second QR code shown on the screen-shot above (which has been replaced by a fake one in addition to being blurred out).

Once the QR code had been scanned, the Google Authenticator app showed me a 6 digit code which I typed in to the verification code field on the screen-shot shown above. It was accepted first time and that was it! Here is the Google Authenticator screen-shot taken from my (Android) phone:

The only drawback to using a two-factor system like this is the inconvenience if you are unfortunate enough to lose your token generator (i.e. your phone with Google Authenticator on). You obviously cannot generate your one time passwords to login! So, I checked out the Apple App Store and downloaded the same app for my iPad (well, it's an iPhone app, but worked fine on the iPad). So, if I should lose my phone, I can use my iPad to generate my OTP as an alternative. 

I registered it using the same QR scanning technique via the Meraki dashboard and had my iPad registered in just a few moments. Here is a screen-dump of the iPhone app:

It's actually pretty cool to have both of the devices next to each other and see them generating the same OTP every 30 seconds. As they are time sync'ed and have been registered with the same authenticator source, they will always generate the same OTP.

Next time I logged in to my Meraki dashboard, I used my regular username and password, but in addition, I was prompted to enter the 6 digit OTP shown on my phone app:

I entered the code and was allowed access to my regular dashboard. The two factor authentication worked perfectly.

Just to prove the whole standards-based theory, I also installed another (non-Google) OTP app called "HDE OTP" (which is again free) on my iPad. Once I had done the whole QR code sync process again with that app, I could also use it to log in to the Meraki dashboard!


Meraki look they have done a really nice job of implementing two factor authentication for administrative access to their cloud management service. By using a standardized approach, they provide a very flexible, but secure approach.

My only preference to improve this would be for their dashboard to use two factor authentication as the default authentication method. Perhaps after an initial 5 logins using just a username/password login, users could be nagged by the interface to set up an OTP access method. If they definitely do not wish to use it, perhaps they could explicitly opt-out of the OTP approach by setting a check-box to disable OTP and have to check an acceptance check-box to state that they understand the significant security risks of not doing so.

All in all though, I have to say: "Nice job!".


Wednesday, 24 April 2013

How Do I "Get Into" WiFi?

I've been thinking about writing this article for a while and today I came across some articles and Tweets which finally spurred me in to action (see references at the end of this article). In this article I discuss the CWNP program, with particular emphasis on the CWTS certification, for those wishing to learn about WiFi networking.

I meet a lot of people in my line of work (IT professionals in the main) who would like to improve their knowledge of WiFi networking, or would perhaps even like to shift their area of expertise to become focused in this area. However, the question often arises: "how do I get into WiFi networking". 

If you're an IT professional who already has one or two areas of expertise (maybe you're already a security, routing or perhaps voice specialist?) perhaps you would like to understand WiFi networking, as it will doubtless touch your core area of focus during your day-to-day networking life. Or, perhaps you'd just like to be able to understand that consultant who turns up on site and starts speaking at you with a constant stream of WiFi jargon. Whichever is it, you probably recognise that in addition to maintaining your core skills, you need to acquire a basic grasp of the fundamentals of other technology areas. Knowing where to start can sometimes be a little over-whelming.

Similarly if you are an IT professional who recognises the current explosion in the mobility space, you might feel it's time for a change and time to get "a piece of the action" by switching your core skills to become a WiFi specialist.

Whatever your starting point, it's often difficult to know where to start and, more importantly, where to invest your precious time and money to gain the maximum "bang for your buck" (excuse the quotes, I'm British and not used to these American, but universally accepted, colloquialisms).  

Unless you have a generous employer who is going to invest time and money in sending you on a number of  WiFi training courses, then you are going to have to look at strategies for expanding your knowledge yourself. This generally means self-study.

You might consider looking at one of the popular vendor-sponsored certification programs. For example, Cisco provide the CCNA wireless certification which you can self-study for using their study guide. However, vendor programs, such as CCNA, tend to focus a lot on product-related information and perhaps skimp a little on the technical depth that you might hope for (note: you also need to have passed the basic CCNA R&S exam as a pre-requisite to the CCNA Wireless exam) . In my opinion, the key to mastering a technology area is to have a solid foundation rooted in a good understanding of the general theory and principles of the whole subject-area - the vendor-specific stuff can follow on later once you understand how the technology should work.

My own personal preference for self-study and a professional WiFi certification path is the vendor-neutral CWNP program. It has a range of study guides and certification exams ranging from entry level (CWTS) right up to industry guru status (CWNE). The quality of their material and the standard of the exams is exemplary. Even if you aren't going to take the exams, the wealth of WiFi knowledge in their study guides is staggering and a valuable resource to have on your bookshelf.

I personally started my own certification journey in WiFi with the CWNA (Certified Wireless Network Administrator) exam a few years ago, which is the second level of certification (one level above their entry level exam). However, the CWNA is a very challenging exam - it's definitely not for WiFi beginners (in my opinion). But, CWNP also provide an entry level exam for those who are at the beginning of their WiFi journey : CWTS (Certified Wireless Technology Specialist). Although this is an entry level exam, don't be fooled, it still covers a lot of ground and provides a wealth of information to provide a solid understanding of WiFi basics.

I hadn't looked at the CWTS in any detail myself until fairly recently - I guess I'd rather unfairly dismissed it in my mind as a bit of a low-level qualification. But I recently got involved with helping some colleagues start their certification journey and had a proper look at what the CWTS has to offer - I was very impressed!

I got hold of a copy of the CWTS guide from Amazon on my Kindle. It weighs in at a thumping 541 pages! A lightweight entry level qualification!!?? - I don't think so. In summary, the study guide follows the objectives of the CWTS exam and give you a comprehensive, detailed introduction in to the world of WiFi. Here are the chapter titles to give you a flavour of what you will find in the study guide:

  • Ch1 - Introduction to Computer Networking
  • Ch2 - Introduction to Wireless Local Area Networking
  • Ch3 - Wireless LAN Infrastructure Devices
  • Ch4 - Wireless LAN Client Devices
  • Ch5 - Physical Layer Access Methods
  • Ch6 - Radio Frequency Fundamentals
  • Ch7 - Wireless LAN Antennas and Accessories
  • Ch8 - Wireless LAN Terminology & Technology
  • Ch9 - Wireless LAN Security Basics
  • Ch10 - Wireless Lan Site Survey
  • Ch11 - Performing an RF Wireless LAN Site Survey
  • Ch12 - Troubleshooting and Maintaining IEEE 802.11 Wireless Local Area Networks
In additional, you also get to to download an accompanying CD which has plenty of practice questions for you to hone your skills for the exam (if you should choose to do it).

In summary, my recommendation for getting your feet wet in WiFi is to do yourself a massive favour and get hold of the CWTS study guide. It will provide you a thorough (vendor-neutral) grounding in  WiFi networking and will provide you with the first step on an industry recognised (and well-respected) certification program. I personally think that the study guide is very well written and perfectly suited for the IT professional, or perhaps student, who already has some networking skills that they wish to expand.

Don't forget that it isn't all just about reading though. You can also have have some fun with WiFi yourself for very little outlay. Although Enterprise-grade WiFi gear can be a little expensive, you can perhaps play with your own home WiFi router, maybe re-flash an old Linksys home router or even pick up a bargain on eBay - there's no substitute for getting your hands on some gear whilst you study.

There are also some great free software packages you can get hold of to help you with your studies. You might like to take a look at:
I hope this gives you a few ideas to get you started on your journey in expanding your knowledge in WiFi networking. Good luck! Let me know how you get on :)


Monday, 22 April 2013

Cloud Based Wireless Services - Some Thoughts About Security...

In this article, I present some of my thoughts around security of cloud-managed wireless solutions (which I am a massive fan of!). Hopefully the views here will be construed as constructive ideas that may prompt vendors to perhaps look more closely at their current implementations to perhaps feed in to product improvements.

I've been taking a close look at a some cloud-managed wireless solutions recently and they appear to be a very exciting area, providing a very compelling proposition for many organisations.

Remote access to manage your network from anywhere that you have an Internet connection is an incredibly powerful (and empowering) feature. As a consultant working for a vendor-neutral re-seller  the possibilities around remote support and managed services for my customers provide a whole new avenue of exciting opportunities.

However, after the initial buzz and excitement of playing with these solutions, I started to think long and hard about their security. Many of the concerns I hear expressed with any cloud service are around security (for fairly obvious reasons). Once you hand over responsibility to a 3rd party for a service that forms a critical part of your business function, the whole issue of who you really trust with your business assets rears its head.

For wireless cloud solutions the chief areas of concern (for me), with regards to their security are:
  1. Traffic between the on-premise components of your wireless network and the cloud - How secure is this traffic as it flows between on-premise components and cloud servers? This can apply to:

    • Management traffic
    • Control traffic (if the solution requires it)
    • User traffic (if the solution requires it)
  2. Cloud component security - How well secured are these elements?:

    • Physical access
    • Site/Server resilience
    • Network security (SSL Certs, OS patching, firewalls etc.)

  3. Reporting and statistical data access - Although no user traffic generally flows through the cloud, who has access to the (potentially commercially sensitive) reporting and statistical data that the system creates? 
  4. End-user administrative access control - What access controls are in place for those who have administrative access to the management of the solution (both customer and vendor)?
(Note: I'm not including the obvious and ever-present security of wireless end-user traffic here - that issue is not unique to cloud-based offerings and is readily solved existing WiFi (802.11) authentication and encryption methods)

I think/hope that most vendors have the first three points in this list pretty well covered off - trusting that all of these items are taken care of is fundamental in the selection process of a cloud-based service. The general assumptions are that:
  • Traffic to/from the cloud to the on-site kit will be encrypted using some type of robust encryption technique
  • Vendors have robust security infrastructure and processes in place (e.g. daily pen-testing, firewalls etc.) around their cloud infrastructure
  • Access to customer generated statistical data is protected by vendor mechanisms and processes
To be honest, there is little that can be done to verify these areas for the average end-user. I'm sure that many end-users will rely on the fact that a cloud provider is probably only going to get one of theses areas wrong once before a major part of their business is seriously or perhaps fatally damaged.

(Note: these are my own personal assumptions - if you are a military or government-related organization, I accept that you may not be quite so trusting when it comes to cloud based services.)

So, assuming that the cloud provider has (securely) taken care of the elements over which they exercise total control, that leaves us with the fourth item from our list above: end-user and vendor administrative control of the cloud-based wireless service. 

Once the end-user (customer) has purchased their equipment and the accompanying subscription licenses, they are going to want to access their new cloud-based wireless network and excitedly show their colleagues this cool, new platform. To access their cloud service they'll fire up their browser and type in the user name and password that they have been provided by their cloud vendor. If they are a particularly diligent employee, they'll hopefully also change their login password to make sure they are observing good security practice and not using the default password that has been issued to them. Once their credentials are entered, they will then have access to manage all of the devices for their organization that are part of the cloud-based service. 

(I've only spoken about wireless devices so far, but it's worth noting that many wireless vendors are now moving in to edge switches and security appliances too, providing even more penetration in to an organization's infrastructure.)

But, just taking a step back, let's have a think about what's going on here. An organisation is allowing an individual access and control of their network infrastructure from anywhere in the world, based on a simple username/password combination.  OK, the credentials will be sent over SSL encrypted connections and the user will hopefully use a nice long complicated password, but there is still no way of proving that this individual, who has unfettered access to key business systems, is who they say they are....

Consider the following:
  • Laptops and mobile devices (perhaps containing password information) get stolen and lost
  • People, who should know better, write account details on post-it notes
  • Employees short-cut security by sharing credentials
  • People often use the same username/password credentials across a number of online sites and systems, some of which may become compromised
  • Social engineering attacks may be mounted against an organization. 
There are, unfortunately, many methods by which simple username/password credentials may fall in to the wrong hands.

In my opinion, a simple username/password combination is simply not enough when allowing ubiquitous access to network systems via a cloud service. Administrative access must be protected by some technique that also confirms that the user is who they purport to be.  This technique may include a user certificate or perhaps a two-factor authentication method, but this should method should be the default security access policy for a cloud service. 

Unfortunately, many users tend to use the default settings of many systems, either believing them to be sufficient from a security point of view, or through simple laziness. Unless a robust default is provided as a default, many will not take advantage of more secure options, even if they are provided.

Although a two factor authentication mechanism may seem a little onerous (if considering the logistical complexity of traditional fob-based hardware tokens), the wide-spread use of mobile devices by many employees would seem to naturally lend itself to some type of app-based authentication system to facilitate this fairly readily without too much additional investment by vendors.

There will doubtless still be end-users still refuse to buy-in to this level of secured access to administer their network, therefore an option to fall-back to the standard username/password combination must still be provided. But, this should only be allowed after being explicitly requested by an end-user organization and should perhaps accompanied by strong warnings around liability in the event of unauthorised network access.

If a customer should choose to disable the default two-factor authentication (or similar user-identity verification system), then comprehensive policy enforcement for end-user administrative access must still be provided. This should provide extensive features for maximum user security enforcement, including:
  • Password length & complexity policies (e.g. minimum numbers & types of character)
  • Password re-use polices (e.g. not allow previously used passwords of their variants)
  • Period password changes policies (e.g. enforce password change every month)
  • Source geographic regions and/or IP addresses ranges exclusion or inclusion (e.g. do not allow access from unexpected countries)
  • Configurable Session timeouts (e.g. force login every 30 minutes in case terminal left unattended)
  • Account lock-out to prevent brute force attacks (e.g. lock an account and generate an event after 5 failed login attempts)
Having looked at some existing cloud-based offerings, they comply with the points outlined above to varying degrees. But, given the seriousness of impact in a breach in this area, I think it is an area that all wireless cloud vendors need to take a very careful look at. None currently (to my knowledge) provide a default authentication system for administrative users that can identify a user beyond their basic username and password. I do not believe this is good enough. The strongest possible authentication should be the default, with any other methods being actively discouraged and requiring a customer to acknowlede that they understand the impact of reduced security for access to their service.

Attacks on online services will generally start on the weakest link in a system. From what I have seen so far, the weakest link in wireless cloud services is the authentication of administrative users to those services. I think that any vendors that do not impose stringent security mechanisms in this area are taking a significant risk and urgently need to address this. 

End-users often do not employ the most secure practices - in the case of cloud based services, vendors need to protect end-users from themselves and to safeguard their own reputation. Also, for those resellers and partners who wish to provide services around these offerings, they need to have the confidence that they have robust security in-place to protect their own interests too.

Monday, 15 April 2013

Aerohive AP DHCP Option 226 in Cisco IOS

Just a quick note to myself (as well as sharing for anyone interested)...

Aerohive APs can be told where to find Hive Manager using DHCP option 225 (for the HM name) or option 226 (for the HM IP address). - (see here for a much better explanation)

I tried to set up the DHCP option 226 for an Aerohive AP today to tell it where to find Hive Manager in my lab. The DHCP server I am using is a Cisco IOS switch. I couldn't get the AP to accept the option for some reason.

After lots of playing about, I finally figured out what my issue was: I was using the 'ascii' keyword for the option type, when it should have been the 'ip' type (...yes, it's always obvious in retrospect).

Here is the correct configuration for a DHCP scope in case you find yourself in the same position:

! *** only assign addresses above .150 ***
ip dhcp excluded-address
ip dhcp excluded-address
ip dhcp pool AP-VLAN
   option 226 ip