How Operators can make Hotspots and Public Wi-Fi Safer

There are numerous articles, papers, and books that decry the lack of security at public hotspots and other networks that are open / quasi-open to the public, such as the Wi-Fi in hotels.   There have been several incidents in the past where some celebrity gets hacked and has their photos and emails downloaded by nefarious parties.

Unwaveringly, however, the "solution" seemingly endorsed by the Wi-Fi industry is always to not trust the hotspot and put the burden on the user:

-        Disable automatic login

-        Turn off file sharing

-        Forget the network

-        Use encrypted applications (e.g. https, SSL)

-        Maintain up-to-date firewalls, anti-virus, and malware software, along with OS security patches

-        Use a corporate or personal virtual private network (VPN)

See a popular infographic circulating around the Twittersphere.

While all of these things are certainly good advice and "best practice", the message of the industry is that the burden of data security is pushed onto the user.   This is flawed for several reasons.   Most IT professionals have difficulty keeping their own OS patch, firewall, anti-virus, and malware deployments up-to-date without expensive programs or services to do it for them automatically.  To expect non-tech savvy users to both do this and keep on top of this is simply unrealistic.   Secondly, while there are lots of software packages available on PCs and laptops for firewalls, anti-virus, anti-malware, and VPN client software,  the selection is quite limited or even non-existent for the smartphones and tablets, which are primarily the devices used on hotspot and public Wi-Fi networks.  Most importantly, however, this implicitly absolves the hotspot / public Wi-Fi operator of any responsibility or ownership of security issues.

While users do need to have some level of personal responsibility and practice common sense, anyone who has ever done any serious work in IT security will tell you that data security is about “defense-in-depth” and must be considered at every level of the network architecture.  Security is something that has to be considered and configured for every device in your network, at every layer of the OSI stack.  This is a belt & suspenders approach, to ensure that a vulnerability to an attack at one layer can get stopped at the next. 

Accordingly, there are simple measures that can be taken in the configuration of a hotspot / public Wi-Fi network by the operator that serve to heighten security and make users safer.  In essence, there is an intrinsic requirement on any hotspot or public Wi-Fi network that clients should be isolated from one another.  If they cannot see each other, they cannot hack each other!  This requirement is always there, but it isn't always acknowledged or realized.  Client devices on a public Wi-Fi network simply do not need to intercommunicate with each other.   So why let them?   

Courtesy: http://i0.wp.com/education.healthcaresource.com/wp-content/uploads/2013/11/iStock_000006853763XSmall.jpg?zoom=1.5&w=325

(Yes, there may be things like publicly accessible printers / TVs, but that can be easily handled as an exception with proper network design and configuration.)

The biggest objections to implementing security, of course, is that it is a PITA for both users and operators and costs too much in equipment and labor.  This is really just an excuse, as Wi-Fi and wired network equipment has been around for many years that have security capabilities built in, if you know how to use it.  Furthermore, such equipment doesn't need to be high end – virtually any enterprise-grade router, switch, and access point has everything you need to build a secure public Wi-Fi network. 

Guideline #1: Use enterprise-grade networking equipment.  Consumer routers and APs are designed for consumer environments, not hotspots and public Wi-Fi networks.  Stop using consumer gear in these environments!  There are plenty of low cost enterprise-grade access points on the market, such as the EnGenius EAP and ECB series of APs.  These models cost nearly the same as their consumer counterparts, and include all of the necessary features built in to operate simple and safer public Wi-Fi networks. For more elaborate networks consisting of several APs, a low cost enterprise-grade managed solution, such as the EnGenius Neutron series, is appropriate because of the additional monitoring and management tools.

Guideline #2:  Don't mix and match APs from different vendors.  While different models of an AP may be needed to accommodate different environments (e.g. indoor vs. outdoor), avoid mixing APs from different vendors.  This is primarily not a functionality restriction, but a pragmatic one.  Aside from the name / location of the AP, its IP address, and its static channel settings, all of the APs should generally be configured exactly the same way.  Mixing and matching APs from different vendors precludes the ability to match configurations.  Two APs from two different vendors set up seemingly in the exact same way will perform differently.

Guideline #3:  Change the default passwords and SNMP communities.  This one should be obvious, but I keep seeing it time and time again.  Many devices will allow for the creation of read-only accounts, so that device settings can be viewed but not altered.  This is generally a good idea if multiple people "need" access to the equipment.  As for SNMP, it can be a very powerful management tool, but can also be easily abused by hackers.  If you are using SNMP, change the default community strings.  If you aren't using SNMP, turn it off!

Once the proper enterprise equipment has been selected, how should it be configured?  Remember that the goal is to keep clients isolated from each other.  This needs to happen at every level of the network.

Guideline #4:  Enable client isolation on your public SSID.  This is usually a check box labeled either "client isolation" or "station isolation" that, when enabled, prevents clients on the same AP from intercommunicating.  Some APs also have a "L2 isolation" feature which prevents clients on different APs (but the same SSID) from intercommunicating.  If your AP has that feature, use it.  If not, don't worry, because this level of protection can also be implemented on a managed switch.

Guideline #5:  Use VLANs.   If you have multiple types of users in parallel (e.g. guests, staff, security, IoT appliances, etc.), this is a necessity.  However, even in a hotspot environment with only one type of user access, it's still a great idea.  Why?  VLAN implementations generally require the use of a management VLAN for network equipment, which puts your network equipment on a separate virtual network from your users.  But you get this benefit even when you aren't using a management VLAN per se, as the network equipment stays on untagged VLAN 1 while the users are all placed on another VLAN.  Result?  Wi-Fi users cannot see or access the network equipment.

So far, the discussion has centered on the APs, but switches and routers are also a critical part of this equation.

Guideline #6:  Use managed (or at least smart) switches.  First and foremost, the switch has an IP address, meaning that the switch can be monitored remotely and accessed to run diagnostics when (note I don't say "if") needed.  Smart and managed switches also support VLANs, so will be necessary for any network deployment implementing them.  Some switches also come with port isolation features, which prevent communication between client ports (e.g. access points) and only allow clients to communicate with backhaul ports.  I personally like using managed switches, as most smart switches don't support implementing access control list (ACL) rules.   ACL rules are an extremely powerful feature to make each port on the switch act like a firewall, capable of allowing or denying traffic on each port based on characteristics like its source or destination IP address / subnet.  Why is this useful?  It can be configured to prevent devices on the same subnet from talking to each other (with exceptions for your router and DHCP server).   I'll be posting a separate blog in the near future with a detailed example of how to configure ACL rules for various scenarios.   As with APs, SNMP communities should be changed or SNMP disabled if you're not going to use it.

Guideline #7:  Use an enterprise router / firewall.  Again, this doesn't need to be a multi-thousand dollar appliance, but don't use a consumer NAT router or the garbage typically provided by the Internet service provider.  There are several devices starting under $200 which are appropriate, with cost generally correlated with capacity.  At a minimum, your enterprise router  needs to support VLANs, DHCP, and DNS resolution.  Typically, you will also want to include Unified Threat Management (UTM), and you may or may not also want application filtering (to prevent torrents) and/or content filtering (to prevent users in a public place from surfing inappropriate sites).  Implementing bandwidth restrictions by client device is also an option on some routers, to ensure that no single user can consume all of the bandwidth you are providing. 

Guideline #8:  Use captive portals.  I know a lot of Wi-Fi engineers who hate captive portals, but they are an absolute necessity in providing public and semi-public access.  Captive portals let you identify what devices are on your network and how much bandwidth they are consuming.  This is not only required by law to be CALEA compliant, but it is just a good idea for (quasi-)public networks to have some knowledge over who is connecting to your network and how much bandwidth they are consuming.  Additionally, captive portals always require acceptance of the “terms of service”, an annoying amount of legalese that nobody ever reads, but this serves to protect the operator in the event someone connects on your network and tries to hack someone else on the Internet.   Captive portals can also be a useful marketing tool: the splash page is great real estate, and many appliances enable login with social media credentials, giving the operator a list of validated contacts for future e-marketing campaigns. 

Some may have observed that I have not said anything about using WPA2 encryption.   As the 802.11 standards are currently defined, the use of an encrypted Wi-Fi signal is useless in a public Wi-Fi environment.   By definition, all clients are BYOD, so the use of WPA2-Enterprise (i.e 802.1x with a RADIUS server) is simply impractical.  Furthermore, using WPA2-Personal (i.e. a pre-shared key / passphrase) just becomes an overhead nightmare for the operator, as it needs to be posted publicly and/or people keep asking for the passphrase.  While in WPA2, an AP does establish a unique set of encryption keys with each client, there are packet sniffing tools readily available that can decrypt data packets when provided with the WPA2 passphrase.   Amazingly, there are so many “public” hot spots in restaurants, doctor’s offices, and the like where WPA2-Personal is used, but this only serves to make the users that can get online “feel” safer without actually doing anything to address security – data cannot be guaranteed to stay encrypted, and a well-advertised WPA2 passphrase won’t prevent man-in-the-middle attacks.  More importantly, encrypting the wireless traffic between the client and the AP is pointless if client isolation is not enabled – two clients with encrypted connections can still see each other on the “wired” portion of the network, which is not encrypted at the MAC layer.    Hence, users should still be operating encrypted applications utilizing https and SSL, which do the encryption of the data all the way up to the application layer.

The security of public Wi-fi networks requires a defense-in-depth strategy.  There are relatively simple configurations and choices that operators of hotspots and other public Wi-Fi networks can do to make their networks intrinsically safer for their users.   In combination with user common-sense, public Wi-Fi networks need not be unsafe environments for people to access the Internet.