Who goes there? Securing wireless access

Learn how to create secure WiFi access, including secure wireless access point configuration, information on WiFi captive portals, the pros and cons of a preshared key, as well as EAP and PEAP authentication. Join Lisa Phifer of Core Competence Inc. in this third part of the Wireless Lunchtime Learning Security School.


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.   

Who goes there Securing wireless access

Carolyn Gibney: Hello, and welcome to today's SearchSecurity.com
Wireless Lunchtime Learning video presentation, 'Who Goes There?
Securing Wireless Access,' with special guest speaker, Lisa Phifer.
My name is Carolyn Gibney, and I will be your host.

The goal of SearchSecurity.com's Wireless Lunchtime Learning
Security School is to equip you with strategies and tactics for
defending your organization's wireless LAN, in a format that fits
your busy schedule. Today's presentation focuses on securing
wireless access, covering techniques like MAC address filtering,
ACLs, pre-shared keys, and more. Plus, general best practices
for remote access configuration. Our expert speaker, Lisa Phifer,
has been involved in the design, implementation, and evaluation
of data communications, internet working, security, and network
management products for over 25 years. Lisa owns Core
Competence, Inc., a consulting firm specializing in network
security and management technology. She teaches about wireless
LANs, mobile security and virtual private networking at many industry
conferences and online webinars. Thank you for joining us today, Lisa.

Lisa Phifer: I am looking forward to our webcast.

Carolyn Gibney: Great. As a reminder, you can see all the tips
and videos in our Wireless Lunchtime Learning Security School
at any time by navigating to SearchSecurity.com/WirelessLunchtimeLearning.
We are ready for your presentation, Lisa. Take it away.

Lisa Phifer: Thank you, Carolyn. Let us start by eliminating a few
measures that cannot be used through lively control wireless access.
First, some people think that hiding the name of your wireless LAN
and service set identifier can actually stop outsiders from using your
network; this is false. Even if you do not send your SSID in beacon
frames, it appears in probe requests, responses, and many other
frames. It is impossible to hide your SSID from attackers, so never
think of that value as a password. Sending beacons without SSIDs
in them just slows up the association process for everyone. Another
common myth is that you can stop eavesdropping by reducing
transmit power. While it does make sense to avoid unnecessary
signal leakage, it is really difficult to provide adequate coverage
without sending some signal where you really did not want to, and
this is particularly true for voice, which requires consistently strong
gap-free coverage. Worse, 802.11n, actually changes the game by
exploiting multipath. That is where signals bounce around barriers
like walls. 11n access points often reach twice as far as their legacy
counterparts, but only in certain directions, and even then, under
certain conditions. Obviously, you cannot count on a dynamic footprint
to control access. Finally, I often recommend directional antennas to
improve wireless LAN performance. It does make good sense to focus
most of your access points output towards legitimate users. With 802.11n,
a new technique called beam forming, can be used to accomplish a logically
similar goal. Again, these measures should not be relied upon to prevent
outsider access. Attackers use more sensitive receivers and stronger
antennas, and we need real access controls to keep them at bay.

What can we use to control and authenticate access? First, most
access points work Mac access control lists that permit or denies
associations based on the data link address assigned to each Wi-Fi
device. It is easy to filter LAN traffic by Mac address because these
values are carried in the header of every 802.11 frame. Unfortunately,
that also makes it very easy for intruders to obtain the Mac address of
any legitimate device. Most access points let you configure Mac ACLs
to accept association requests only from trusted devices and/or reject
association requests from banned devices. Some Wi-Fi client programs
also support Mac ACLs. This is really intended to help biased devices
towards a particular access point when multiple access points with the
same SSID are nearby. On this slide, we illustrate the Intel PROSet client,
which not only tells you the Mac address of the access point to which you
have actually connected, but it actually lets you configure a mandatory
access point Mac address for each SSID.

Why would you or would you not use Mac ACLs? Unfortunately, Mac
addresses are trivial to sniff. Anyone can change a Wi-Fi client's
factory-assigned Mac address to an observed, legitimate address
to bypass a Mac ACL. Furthermore, maintaining long Mac lists and
configuring them into multiple access points would be very time
consuming and also error prone. Despite that, some networks still
use Mac ACLs, why? These access control lists can stop accidental
associations from Wi-Fi clients to neighboring access points, and they
can also be used to discourage visitors from using your network.
Furthermore, every Wi-Fi device has a Mac address, including
embedded clients in point of sale terminals, printers and smartphones.
When you are faced with a device that really supports no other
authentication method, then you can still filter on its Mac address.

Ultimately, I do not recommend using MAC Access Pro lists for access
control. In a small home or office LAN, a short Mac access control list
can actually be used to reduce mistakes without creating a big
management headache. Mac access control lists should never be
used alone without effective access control somewhere upstream.
For example, if you accept voice over IP handset associations based
on Mac address, you should combine that with VLANs and firewalls
that permit only SIP and RTP traffic to your PBX. Once that traffic
reaches your PBX, you probably want to rely upon some more reliable
application layer identifiers to make a decision about permitting or
denying actual voice service use.

Let us take a look at the second method: captive portals. Captive
portals are a far more common method of controlling access to
wired and now wireless hospitality networks. A captive portal
operates with a firewall with a dynamic rule set. All stations are
allowed to connect to the network, but until they authenticate,
they can only send a few limited packets, maybe some DHCP
and DNS. Any outbound web request is automatically captured
and redirected to a captive portal web server. At the web server,
the user is typically challenged to authenticate, this can be as
simple as accepting a terms of service for a hotspot or as
complicated as entering a credit card number to pay for hotspot
access. This challenge response authentication is typically
encrypted using SSL to prevent other users from sniffing logins
and credit card numbers. Once a wireless user has satisfied this
challenge, the SSL session ends and the station is no longer held
captive. The portal's redirect rule is lifted so the authenticated user
can now send and receive any kind of traffic. Captive portal access
is typically granted for a finite period of time, after which that redirect
rule is restored and the user must re-authenticate to continue using
the network.

Captive portals are widely used by public internet networks like the
ones that you find in hotels and conference centers, cafes, and other
broadband and wireless hotspots because they impose minimal
requirements. So long as the customer's device has a web browser,
no installation or configuration is required. When pre-connect
processing is required, for example, to run an Mac security
scan, a web browser is usually able to do something like download
an ActiveX, Java, or temporary executable that can then dissolve
when the session is over. Captive portals are not well suited for
environments where there is no end user and no browser to interact
with the portal. Business travelers that use VPNs or fixed mobile
convergence can get stuck behind captive portals unless the hotspot
actually accommodates them. For example, by providing a non-interactive
login alternative, or by letting VPN protocols bypass the captive portal.
Portals can also be vulnerable to some spoofing attacks, such as when
one user borrows the address of another user who previously paid for
service. You probably would not make employees jump through these
kinds of hoops when connecting to your office network, but many
business travelers go this routine at public hotspots every day. Captive
portals are also used in guest and education networks where
administrators really cannot realistically control the Wi-Fi devices that
are used, but they may still require some access control in auditing.

Let us take a look at a third alternative. Mac access control lists and
captive portals are used in venues where WPA or WPA2 are either
absent or impractical; however, most businesses networks should
really use 802.11 standard access control and authentication
methods. The simpler of these, WPA or WPA2 Personal, provides
a group-level authentication. Here, the access point in every station
must be configured with a pre-shared key generated from a secret
pass phrase up to 63 characters long. When PSKs are used, the
station and access point associate using an 802.11 open system
mode. After the association is established, the access point and
station then complete a four-way key handshake designed to prove
that they both know that same secret. Thereafter, fresh session keys
are delivered during handshake and they are used to encrypt all the
data that is sent over the air, using either TKIP or AES-CCMP.

Today thousands of devices support WPA2 Personal, including
notebooks, USB adapters, PDAs, phones, printers, cameras,
media servers, and many, many more devices. It goes, like
the Windows XP client that is shown on this slide, this is sometimes
referred to as WPA2-PSK, instead of WPA2-Personal; they are really
the same thing. Configuring WPA2-Personal is extremely simple; you
just type in the same passphrase on your station and your access
point. On devices that do not have a keyboard, like a Wi-Fi camera,
you will need Wi-Fi Protected Setup to figure a random PSK. To use
Wi-Fi Protected Setup, you just push a button or you enter a PIN, then
your access point executes a secure setup dialog with your Wi-Fi
client device. The IEEE defined pre-shared keys for use in small networks,
where simplicity was essential and everyone trusted everyone else.
Passphrases are easy to distribute and they are easy to enter when
only a handful of people need them. However, if a worker gives your
passphrase to a guest, that guest now has the same level of access
as your employees do. If a laptop with a previously entered passphrase
is stolen, you will have to update the passphrase used by everyone.

Finally, it is essential to avoid passphrases that are too short and
too easy to guess. At minimum, you want to use a random pass
phrase of at least 20 characters, better yet, use Wi-Fi Protected
Setups to generate a long, random pass phrase for you. Why?
The hacker community has been honing PSK crackers for several
years now. Early tools just tried dictionary words, one-by-one, until
they got lucky; that took a while. Today's tools search enormous
rainbow tables; they are composed of pre-computed handshake
messages that were generated using common SSIDs and pass
phrases. With this method, short simple PSKs can be cracked in a
matter of hours or even minutes. Nonetheless, a long, random,
pre-shared key is a reasonable answer for home network, I also
recommend PSKs for small consumer devices that do not support
802.1X, and also for FnB networks that, for whatever reason, are not
ready to take the 802.1X plunge. However, there are some entry-level
802.1X options that small businesses should consider. If this fits your
bill, take a look at our companion tip for more detail.

Last, but not least, most businesses, especially mid to large enterprises,
have the wherewithal to authenticate Wi-Fi users with 802.1X port access
control. 802.1X works like an on/off switch when stations try to access any
kind of LAN. In an Ethernet LAN, a station may be physically plugged
into a switch, but it cannot send data until it passes 802.1X. In a Wi-Fi
LAN, stations can associate the access point, but they cannot send
data until they pass 802.1X. With 802.1X, the switch or the access point
does not decide whether to permit access, that job falls to an upstream
authentication server, typically a RADIUS server. When a wireless station
associates, the access point forwards the access request to the RADIUS
server. That server authenticates the user and decides whether to grant
access based on some kind of extensible authentication protocol. With
most of those EAP protocols, the user gets a chance to authenticate the
server by checking its digital certificate. When and if both sides are happy,
the access point and station complete a key handshake to derive fresh
encryption keys that are then used by either TKIP or AES to protect
data for the life of the session. Only after reaching that point can
approved stations actually send data through the access point into
an upstream network. Up until we reach that point, all of their data
traffic is actually blocked.

Any wireless LAN that runs WPA or WPA2 can use 802.1X if two
dependencies are met. First, a RADIUS server has to be configured
with its own digital certificate and authorized user account. Second,
each Wi-Fi device must be configured to use 802.1X and possess
valid user credentials. Those credentials could be passwords, tokens,
or certificates, that all depends on your extensible authentication
protocol type. On this slide, we show one example of configuring a
Windows XP client to use 802.1X with protected EAP passwords.
This diagram actually shows what happens under the covers when
you configure a Wi-Fi device to use 802.1X. First, the station connects
to the access point. At this time, any messages the station might
send other than 802.1X EAP messages are simply discarded by the
access point. Next, the access point prompts the station for a user
identity and it relays the station's response to a RADIUS server. On
a large wireless LAN, all access points typically forward access
requests to the same RADIUS server. What happens next will work
the same way no matter which access point the user connects to.
Third, the RADIUS server initiates an open-ended challenge response
dialogue with the station. What actually happens in this step depends
on your extensible authentication protocol type. The server may prove
its own identity and it may challenge the station for a digital certificate,
password, or token. Once the server is satisfied, it returns an access
accept or reject message to the access point. If the user has been
denied access, he can always try again, but if the user has been
approved, the access point and station will complete that final key
handshake used to derive session keys, it is only at that point that
the access point actually unblocks the station. Although there is no
physical port connecting the Wi-Fi device to the access point, you
can think this like unblocking that Ethernet switch port, so that data
can pass into the local area network. Complexity aside, the
biggest difference between pre-shared keys and 802.1X is the
ability to centralize these authorization decisions and make
them on an individual user basis. With 802.1X users can be
authenticated with personal credentials, so that we know
exactly who is using the LAN. RADIUS protocols used by
802.1X also support accounting, so we can use RADIUS
to track usage for auditor billing purposes. In addition,
recalled or pre-shared keys and Mac ACLs may actually
provide a kind of binary authentication, either you are on
or you are off the network.

802.1X authorization can be much more granular. The
RADIUS server can return session parameters based
on your user or group identity, for example, controlling
which SSIDs an individual can use, or signing a virtual
LAN tag to a particular user's traffic. 802.1X also makes
it possible to grant different users different access rights.
Engineers can be permitted to use one part of the network
or warehouse staff can permitted to use a different set of
resources. Clean compliant devices can be given regular
access, while un-patched or infected devices could be
shunted on to a quarantined network. 802.1X establishes
a framework for carving up our wireless network permissions
just about any way we like, all under the control of the
RADIUS server.

I mentioned earlier that user credentials depend on the type
of extensible authentication protocol carried by 802.1X. You
can think of 802.1X as a postal worker that delivers your
mail, think of the extensible authentication protocol, EAP,
as the letters that he or she carries. Just as letters can
communicate many different kinds of messages, EAP
can accomplish many different kinds of authentication.
To date, there are 51 EAP types that have been defined,
but there are just five EAP types that are tested as part of
WPA2 and WPA2 Enterprise certification. The first, EAP-TLS
uses transport layer security to provide mutual authentication
between the station and the server, based on digital certificates,
that means both the Wi-Fi client and the server have to have
a certificate. EAP-TTLS or Tunneled TLS, and Protected EAP,
PEAP, they both authenticate the server via certificate, but
then they create a secure tunnel through which to authenticate
the station by any method. TTLS and PEAP version 0 use
passwords for that Wi-Fi client authentication, while PEAP
version 1 uses tokens.  Finally, there's EAP-SIM, it uses an
entirely different kind of credential, the subscriber identity
module, or SIM card, found in GSM mobile phones to the
Wi-Fi client side authentication.

Even with just five EAP candidates, you still need to choose
one type to authenticate any given user on a particular session.
This is a pretty complex topic and to help you choose, we have
written a companion tip that explores EAP types in much greater
depth, describing benefits, limitations and target environments for
each. Some of the factors that might influence your decision are
listed here. For example, do you want your stations to verify they
have reached the right server? Do you already have user
credentials, like Token Card, that you want to use for wireless
authentication? Is it important to prevent eavesdroppers from
seeing user account names? Do the credentials that you want to
use actually require some kind of cryptographic protection? Is the
EAP type available for every client device and operating system
used on your wireless network? Should the EAP type extend beyond
Wi-Fi, fitting into some kind of broader authentication of framework,
for example, like the ones used for fixed mobile convergence. In
the end, you may choose to support more than one EAP type,
although you will pay a higher price, in terms of overhead. Your
decision may also be influenced by interoperability constraint,
for example, a proprietary EAP type may not be supported by
every access point and client in your network.

Deploying 802.1X and EAP can be daunting, but really, there
are many excellent reasons for going to all that trouble.
Compared to the other three methods that we discussed in this
webcast, 802.1X establishes a strong foundation for individual
authentication and authorization. EAP is complex, in part,
because it allows so much flexibility. 802.1X is a natural fit for
most network access control architectures, including Cisco
NAC, Microsoft NAP, and TNC, letting you go beyond
authentication to include endpoint security state in your
access decision.

You can choose EAP types that avoid common authentication
vulnerabilities, like social engineering, but, it is important to
be aware of weaknesses associated with particular EAP
methods, for example, password-based EAPs, generally they
can be vulnerable to identity exposure. You should also
consider the cost of user credential distribution and maintenance,
for example, EAP-TLS is very secure but it requires a client
certificate on every Wi-Fi device.  Finally, think about what it will
take to configure and run every device in your network with 802.1X,
for example, EAP-TLS is broadly supported. That is great news, but
it can be too resource intensive for small mobile devices. Compare
that to PEAP version 1, which requires third party software installation.
Businesses can benefit from granular authentication and control; they
should use 802.1X to authenticate Wi-Fi devices over which they have
IP control. Another case where 802.1X tends to be used is by carriers
that operate commercial hotspots to facilitate dual mode, phone-roaming,
between wireless LANs and wireless wide area networks.

In this webcast we explored four common methods for controlling
wireless network access, authenticating wireless devices and users,
and determining which of those devices can actually reach different
destinations inside your network. Small networks might choose one
method; larger networks frequently end up using several methods to
meet the needs of different communities. Just one common scenario
here, suppose you are building a corporate wireless LAN that will be
required to support guest internet access, employee notebooks and
Wi-Fi phones. The easiest method to control guest access is captive
portals, but, of course, you want to make sure that captive portal
leads directly to the internet and nowhere else. The only method
supported by your Wi-Fi phone may be pre-shared keys, and
might even just be Mac ACLs. If you use either of those methods,
you will want to filter and segregate that voice traffic to reduce risk
exposure to the rest of your network. For employee notebooks and
maybe some other devices, like smartphones or printers, you may
require 802.1X clearance to reach the heart of your corporate
network with individual authentication.

Let your security policy and business needs, not available technology,
drive your access control and authentication design. Certain devices
and operating systems may limit what is possible, but do not choose
802.1X just because you can, choose it because it is what you need.
Use something else when 802.1X just doesn't fit.

We have tried to give you a feel for readily available alternatives.
While Mac access control lists are pretty intuitive, the other three
methods we talked about are a bit more complex and they do
require careful evaluation and configuration. To assist you in that
endeavor, we did put together several follow-on tips, in particular,
if you are a company with limited IT staff or infrastructure, I highly
recommend that you read the tip on controlling wireless LAN
access on a tight budget. Everyone, even home users, should
really read our tip on defeating evil twin attacks. This is important
because evil twins do their dirty work by actually avoiding some
of the authentication techniques we talked about in today's webcast,
and it is important to understand their potential impact on you. We
will also be talking about other methods for tracking evil twins and
other wireless LAN attacks on our next webcast on wireless
intrusion prevention. Thanks for listening.

Carolyn Gibney: Great presentation, Lisa, thank you. This brings
us to the end of today's video presentation. Once again, we
would like to thank Lisa Pfeiffer, of Core Competence, for joining
us. For more information on secure wireless access, read Lisa's
exclusive companion tips, that she mentioned on 'Controlling
Wireless LAN Access on a Tight Budget,' 'Choosing the Right
Flavor of 802.1X,'  'Combining 802.1X and VLANS for Wireless
LAN Authorization,' and 'Defeating Evil Twin Attacks.' All of these
tips and other great learning materials are available for you in our
Wireless Lunchtime Learning Security School at anytime by
navigating to SearchSecurity.com/WirelessLunchtimeLearning.
A final thanks to all our listeners for joining us today. I am
Carolyn Gibney. Have a great day.


View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.