Exploring EAP

As discussed in an earlier blog WPA2 Enterprise allows a network to authenticate each user with unique credentials, rather than a blanket passphrase. This is done through an EAP exchange over the 802.1X framework. We’ve touched on this briefly in a post about RBAC, but I wanted to take some time to review two of the different flavors of EAP so you can make an informed decision about which one is best for your organization.

There are two predominant versions of EAP being installed today – PEAP and EAP-TLS.

Protected Extensible Authentication Protocol (PEAP)

PEAP technically has multiple versions, but they all use the same basic “protected” transfer structure. The issue with legacy EAP was that the supplicant’s credentials were transmitted in cleartext… which is less than secure, because it opened up the potential for someone to intercept a username. PEAP corrects this by using two EAP exchanges – outer authentication and inner authentication. The outer authentication is a “dummy” EAP exchange (often using a ridiculous username) that sends information in cleartext to construct a temporary TLS tunnel. Once that encryption cover is in place, the inner authentication takes place securely inside the tunnel, out of sight of roaming sniffers. Can you see why it’s called “Protected”?

The most common version of PEAP is EAP-PEAPv0 (EAP-MSCHAPv2). The protocol used for the inner authentication is EAP-MSCHAPv2, which utilizes a user name and password as the credential. When using PEAP you will need to provide a server side certificate and set up a repository of usernames and passwords for individual client authentications. When your users connect to the network they will validate the server via the installed certificate and (if the trust is there) provide their unique credentials.

This option is popular because PEAP is widely supported by client devices and it allows you to easily utilize an existing database, like Active Directory. Your end users are already used to logging in to the domain using their AD credentials, so asking them to use those same credentials to log on to the network isn’t a stretch.

Extensible Authentication Protocol Transport Layer Security (EAP-TLS)

EAP-TLS is one of the most secure authentication methods available today. Rather than using the standard username / password combination for authentication, EAP-TLS requires both a server side and client side certificate. This means that you can avoid some of the risks inherent to passwords, like a user entering their credentials to connect to the network with an unapproved device or sharing their credentials with another employee. In order to connect to a network secured with EAP-TLS the client must have been provisioned a unique certificate by the network’s public key infrastructure (PKI).

The advantage of this level of security is also its inherent disadvantage. It can be a chore to implement a PKI if you don’t already have one in place. Provisioning this certificate based trust relationship to the client can be a straightforward process with Active Directory’s Group Policy when using Windows hosts, but it can introduce complications with some brands of smart devices unless you have a provisioning mechanism in place… manually installing certificates onto smartphones can be above the skill level of some users and it will bog down your IT department significantly.

Finally, if you do choose to go with EAP-TLS as your EAP structure, be sure to put some heavy security around the server that is housing your PKI.

I don’t mean to scare you away from EAP-TLS, as it is the definitive secure authentication solution. You should just be aware that this security comes at an administrative cost. If you want to go with EAP-TLS I would recommend looking into onboarding software to help provision certificates to your endpoints, like Aruba’s ClearPass or Cisco ISE.

EAP Options to Avoid:

There are many many many other EAP flavors available, too many to effectively cover in a single blog post. PEAP and EAP-TLS are the ones that I see the most often in the enterprise, with the occasional EAP-TTLS popping up here and there. However, there are some legacy EAP options with noticeable security flaws that are worth covering here, less to help plan the future and more to help you avoid these legacy options!

EAP-MD5 – This was one of the first EAP options available. It has severak major weaknesses – first, it does not use tunneled authentication, meaning that the username is transmitted in cleartext. Second, it uses MD5 encryption, which is not a very strong encryption suite. Third, it does not validate the server, opening you up to MiTM attacks.

EAP-LEAP – The username is transmitted in cleartext, which opens you up to social engineering attacks. There are better options out there.

Thoughts on the CWSP…

So, today I passed the Certified Wireless Security Professional (CWSP) exam. For those of you not familiar with the CWNP program, it’s an intensive vendor-neutral certification path that delves deeply into 802.11 tech… VERY deeply. It’s been very beneficial for my career, and it’s one of the few educational courses that I truly enjoy. Anyone interested in learning more about how wireless ticks should take a look at the CWNA at least.

The CWNP program begins with the CWNA as the foundational wireless cert, then it branches into three separate specializations – Security, Analysis, and Design. Once all four exams are completed and a lengthy application submitted (essay questions and all), you can become a candidate for the Certified Wireless Network Expert designation. It’s pretty elite, with only ~150 or so CWNE’s in the USA. I’m gunning to complete the CWNE application by the end of 2017.

For the CWSP course, I used the following resources:

  • CWSP Official Study Guide PW0-204
  • CWSP Official Study Guide CWSP-205
  • Extensive use of the Sybex online companion included with the CWSP-205 book
  • Sample tests available directly from CWNP

I did NOT use the Certitrek guide published in 2015. There may have been some things I missed from that book, but I was very impressed with the most recent version and feel that it covered sufficient enough territory.

The CWSP course covers wireless encryption methods, EAP, fast roaming mechanisms, the different handshakes and key hierarchy, RADIUS, LDAP, MDM, and much more. The book was great. And HARD. Lots of detail to sink your teeth into. I had some issues with incorrect questions on the Sybex portal, so just remember that you can’t 100% trust what their exams tell you when you do your review.


To those of you looking to take the exam, keep hammering through the practice exams from the CWSP-205 book. Once you can pass them reliably, I think you’ll be ready for the real thing.

What’s next for me? I had planned on taking the Wireshark course next to get more familiar with packet analysis, but my work is requesting that I chew through the VCP-NV next, so packet analysis will have to wait a month or two.

On to VCP-NV, WCNA, CWAP, then CWDP!

Merry Christmas to all.

Understanding Wireless Encryption

Wireless is great because it gives you mobility – you can get your work done just about anywhere these days (which is both a good and a bad thing)! But there is an inherent drawback to mobility as wireless traffic is unbounded. It flows in all directions and eavesdropping on private conversations is both easy and undetectable. If you don’t have encryption on your wireless network in place and you have expectations of privacy, well… that’s about the equivalent of shouting intimately personal details in a crowded restaurant and getting upset when people hear you and take notes.

There are many different ways to encrypt your wireless network, but some methods are better than others, and of course they are all obfuscated by IT’s love of acronyms. In this blogpost, I’ll try to outline all the common wireless security options and help you select an encryption method that will secure your network without adding an undue amount of complication.

Wired Equivalent Privacy (WEP):

WEP was the first wireless encryption method, defined in the original IEEE 802.11 standard in 1997. This encryption standard requires the use of matching transmission keys on both the client and the access point. It’s important to note that the standard WEP implementation does not create dynamic encryption keys for each security association, and that WEP can easily be cracked. WEP has two primary weaknesses – a portion of the seeding material used for encryption is sent in cleartext and can be intercepted, and WEP packets can be tampered with due to the weak data integrity check implemented.

To be blunt, don’t use WEP if you can help it. Beyond the obvious security issues, networks that use WEP can’t transmit above 54Mbps – so not only are your communications insecure, they’ll be slow too! If you are forced to use WEP because you have legacy clients require it, you should add additional security through MAC filtering, SSID cloaking, and heavily restricted internal network access.

Wi-Fi Protected Access (WPA):

After WEP was found to have significant security flaws, there was a scramble to shore up the security gap. TKIP encryption was introduced as a result and it was rolled up into the WPA security standard. TKIP addresses many of the issues that WEP had – dynamic encryption keys are generated and significant changes were made to reduce the possibility of tampering. HOWEVER, WPA still uses the weaker ARC4 algorithm that WEP implemented.

As a result, WPA does offer increased security over WEP, but it is still not considered a robust security option. And much like WEP, WPA networks are stuck at 802.11g data rates.

Wi-Fi Protected Access 2 (WPA2) Personal:

WPA2 was introduced in the 802.11i security amendment in 2004. WPA2 uses Counter Mode with Cipher-Block Chaining Message Authentication Code Protocol (CCMP) as the security protocol, and it provides encryption that is considerably stronger than WEP or WPA. We highly recommend that enterprises use either WPA2 Personal or WPA2 Enterprise security for wireless networks.

WPA2 Personal uses a shared passphrase that can range from 8 to 63 characters as the authentication method. If a user knows the passphrase, they will be able to join the WPA2 Personal network. This passphrase is then seeded with the SSID and hashed into a full 256-bit encryption key that serves as a master key for encryption.

WPA2 Personal is very easy to implement and it is widely supported. WPA2 Enterprise (which will be discussed next) offers a stronger level of security than WPA2 Personal… but WPA2 Enterprise requires additional infrastructure and configuration to work effectively, so WPA2 Personal is still commonly used by smaller businesses. Because WPA2 Personal uses a common seeding element (the passphrase) for the dynamic encryption sessions from AP to AP, it is susceptible to a dictionary attack and conversations can be decrypted if the passphrase is compromised and a client’s four-way handshake captured with a packet sniffer.

To shore up defenses against a dictionary attack, it’s important to choose a strong passphrase. The longer and more varied the passphrase chosen, the greater the inherent entropy, and the more difficult it is to crack through brute force. When using WPA2 Personal, be sure to set passphrases of at least 20 characters with upper case, lower case, numbers and symbols included. Try to avoid using common phrases or sequences and refresh these passphrases regularly. Most important of all, educate your users about the danger of social engineering attacks.

Wi-Fi Protected Access 2 (WPA2) Enterprise:

WPA2 Enterprise uses the same strong level of encryption that WPA2 Personal uses, but it does not use a passphrase for authentication. Rather, WPA2 Enterprise utilizes an EAP exchange via the 802.1X framework. There are many flavors of EAP available (and this is something that I’ll get into in a future blogpost) and all kinds of fun things you can do with RADIUS, but the key takeaway is this… on a WPA2 Enterprise network, each client connecting will have their own unique credential. This can take many forms – it can be a token, a username / password combination, or even a client certificate.

Because each authentication uses unique seeding material, the encryption used in WPA2 Enterprise is much more resilient against attacks than WPA2 Personal. WPA2 Enterprise does require some extra legwork to get up and going, but it is the best security method currently available and we highly recommend it for any large corporation.

Other Methods – SSID Cloaking, MAC filters, and VPNs.

There are other less “official” methods of securing your WLAN as well – I’ll review them briefly here.

SSID cloaking is the act of “hiding” the name of your network from users. Essentially, the SSID name is stripped out of the beacon and probe response frames. This can stop regular users from trying to connect, but this is not a strong security method… because the beacon frames are still broadcasting merrily along (just with null information in the SSID field), and anyone with a protocol analyzer will be able to find the name of the network by eavesdropping on someone else’s conversations, as the SSID is transmitted in cleartext. This adds another layer of security, but it is a very thin layer and it can cause erratic client behavior in rare situations.

MAC Filtering is the act of restricting clients by their MAC address. This can help shore up security on a network where the clients don’t support newer security measures – for example, you can have a network dedicated for warehouse scanners that uses WEP security combined with MAC Filtering. While this is an annoying roadblock for malicious hackers, this still isn’t a strong security mechanism. L2 information is sent out in cleartext on a wireless network and someone with a little know-how can spoof a MAC address that is on the whitelist. You should add this to your bag of tricks if you have to use WEP.

VPNs offer another layer of encryption to network traffic. When the weaknesses of WEP were first discovered, VPNs were commonly used as a stopgap to provide data encryption over a wireless network. Today VPNs are primarily used to protect wireless traffic that flows across an unencrypted guest network. If the wireless network doesn’t require a passphrase or credentials, your traffic is flowing in cleartext by default and it can be easily intercepted and rebuilt by a malicious eavesdropper. It’s a good corporate policy to require remote workers to use a VPN whenever they are connected to an open network, like at a coffee shop or in a hotel.


Role Based Access Control

You’re only as strong as your weakest link.

This old adage is especially true when it comes to network security. You can purchase the most expensive, ridiculously feature-rich firewall on the market, install it at the WAN edge, and think that you are safe. But without internal network controls in place as well, you run the risk of someone on the inside stumbling into a restricted resource, and that has the same end result as some foreign agent breaching your perimeter … Someone got somewhere that they really shouldn’t have been allowed, and now data has been compromised.

With the advent of BYOD and the growing appeal of wireless connectivity, the clear definition of permitted devices and internal network boundaries are becoming fuzzy. Studies from IDG, Gartner, and Forrester tell us that 85% of organizations currently allow employees to bring their own devices to work and that over 70% of mobile professionals will conduct their work on their own smart devices by 2018. I’m personally already one of these statistics – I’m writing this at home using Office 365 on a personal computer and checking my email on my personal iPhone. Static port – based security and locked corporate endpoints are no longer valid ways to protect your company… and while wireless encryption standards have come a long way, you still need a good way to control and restrict internal network access.

There are several commonly used methods to lock down your network, but several of these options leave something to be desired. I personally can’t recommend the use of pre-shared keys in an enterprise environment. Several hops ago in my employment journey, I worked at a place where, technically, employees were not allowed on the wireless network – it was intended for guests only. However, as I set up my cubicle on my first day, I found a piece of paper on the bookstand with the guest wireless pass phrase printed on it. It was common knowledge! I mean, it made sense – most people were issued laptops, and meetings were hosted all over the building. If you wanted to pull anything up in those meetings, you needed connectivity. So people used the wireless network against the IT department’s wishes… and because they used a pre-shared key, it would be very painful for the IT staff to change the key and then have to reset every repeat visitor’s network settings. And all it would take would be one “leak” of the new password and they’d be right back where they started. Of course, most employees didn’t have malicious intent, but what if a competitor got their hands on that pre-shared key?

At the risk of going too far into bits and bytes, using a pre-shared key also weakens the encryption used to secure your employee’s wireless communications. A PSK provides seeding material for the master session key that is used to generate unique client keys, so even while the individual keys are generated dynamically there is common thread tying them together. Someone with sophisticated tools and knowledge of the PSK could potentially crack another client’s communication and start eavesdropping undetected.

Another less than ideal method to control network access is via SSID segmentation. This involves setting up multiple SSID’s and assigning a VLAN to each network. One SSID can be assigned for employees, one for guests, one for contractors… and so on, and so on. The VLANs combined with their respective ACLs ensure that everyone has the appropriate permissions. While this gives you some level of control over network traffic, there are some downsides. Significant overhead is required with each SSID in play, as each SSID has to transmit beacon information at a slow data rate to ensure that clients can discover and connect to the wireless network. Once you start reaching more than five SSID’s in a standard enterprise wireless deployment, that beacon overhead can really start to cut into available airtime for actual client traffic. Not to mention the you’re going to be continuously asked by frustrated employees which SSID they should be using!

Enter Role Based Access Control (or RBAC, to satisfy our need for entirely too many acronyms in IT). Role Based Access Control is the principle of assigning privileges based on a role inherent to the user and machine requesting authentication – NOT based on what port they are plugged into or what SSID they are using. Using RBAC, a company director could access financial data regardless of what part of the building they are in – and a guest connecting to that same network would be shepherded straight to the internet, do not pass go, do not access any RFC 1918 space, definitely don’t collect $200. Conversely, thanks to device fingerprinting, that same director could be allowed access to an internal server when using their corporate provided laptop, but be denied access if they request access from a personal (and potentially unsecure) device.

So how do you get started? First, you will need an 802.1X/EAP framework.  There are three primary components in the 802.1X framework – supplicants, authenticators, and authentication servers. Laptops, desktops, iPhones, Androids – any device connecting to your network – is considered a supplicant. When they first connect to an 802.1x network, they are only given extremely limited L2 access … and by that, I mean that literally all they can do is submit their credentials for inspection. They can’t even get a DHCP address! The supplicants send their credentials up to the authenticator, which is commonly a switch, autonomous AP, or WLAN controller. The authenticator can be compared to a bouncer at a club. They don’t make the guest list, but they sure can enforce it! The authenticator relays the supplicant’s credentials to the authentication server in a secure RADIUS session. Depending on whether or not the authentication server approves the credentials, the server returns an ACCESS-REJECT or ACCESS-ACCEPT message back to the authenticator. If the supplicant is accepted the encryption keys are generated and the supplicant granted access.

Conveniently, most authentication servers are able to use LDAP to query an existing Active Directory database. This can greatly simplify the installation, because each employee should already be aware of their AD credentials.

Now, here’s where it can get fun. Multiple Vendor Specific Attributes (VSAs) can be included alongside the RADIUS ACCESS-ACCEPT message, determining network permissions for each supplicant! Using these attributes, the authenticator can take actions like enforcing bandwidth limitations, implementing user specific ACLs, making dynamic VLAN assignments, and more. In the case of the Aruba ecosystem, each supplicant can have its own full set of application-aware traffic shaping policies assigned and enforced.

So, ignoring all the acronyms and “techspeak,” what can this mean for your business? Let’s briefly walk through accessing a network using RBAC on a single SSID. When Bob the intern connects, he has to type in his unique username and password – in this case, he is using his AD credentials. These credentials will be referenced against the specified database, approved, and the controller will give Bob network permissions that are appropriate for an intern. He may be able to use work approved applications, but he will be prevented from accessing specific servers and his streaming bandwidth will be throttled. Regardless of where Bob moves on the network – wired or wireless – these policies will follow him. But when Nancy the CEO connects to this same network, the system recognizes that she is the CEO and as such… she can go where she please! She is given unrestricted and prioritized access. Beyond the submission of user name and password, this all happens transparently to the user… and thanks to interim accounting via RADIUS, you can keep a full log of the transactions and connection states!

To summarize, a well-integrated RBAC system is much more streamlined and secure than static pre-shared keys or port based access control lists. Sure, there can be more work and planning involved during the initial setup, but it’s pretty cool stuff once it’s up and running.

Pitch for NGFW

Cyber-crime is big business – the average cost of a breach is between $3.8 and $4M in 2016 –  and as the stakes rise, digital threats are adapting and evolving to find new ways into your datacenter. Legacy network security systems that only filter by port information at the network perimeter can no longer provide adequate protection.

Attack methods are changing on several fronts:

  • Evasive applications that hop between ports are becoming common, so if your firewall screens traffic by port number alone you are open to a lot of risk.
  • Traffic is often encrypted, making it difficult to tell if traffic is benign or malicious.
  • SaaS applications are on the rise, increasing 46% from 2012 to 2015, and they are often used without sanction by the IT department.
  • Your users are targeted through phishing schemes and seemingly innocuous emails are constantly sent that hide malicious content.

Once someone has breached your perimeter, they can install malware and move through your virtualized environment to find sensitive data. If your firewall is only located between the web and your internal network as a routing point, it will not be able to detect this threat rummaging through your data center – you may not even realize that you have unwelcome guests!

Thankfully, firewall technology has made advances to keep up with these threats and Edge Solutions has partnered with several next generation firewall providers to help keep you safe.

So what is a next generation firewall (NGFW)? An NGFW is able to inspect traffic beyond IP address and port number – it can scan all the way up to application level data! This means that if you have a malicious application attempting to hide itself as web traffic, you will be able to identify the application signature and stop it before it can break into your network.

Using this higher level of visibility and intelligence, an NGFW can implement additional services. Streams can be analyzed for viruses and attack patterns. DNS filters can be put in place to ensure that users don’t wander into unsafe territory and to keep data from being extricated to remote sites. Certificates can be installed to provide decryption services and lower the amount of “unknown” traffic. In some cases, vendors can even provide a cloud-based sandbox environment to test any unknown files for threats, providing zero-day threat resilience.

This technology can be deployed across your network – at the perimeter, the branch office, mobile endpoints, the data center, and even within your virtualized environment to provide microsegmentation – and it is often managed easily through a single software application.

If you’re interested in learning more about moving to a true next generation firewall or if you’d like a complementary personalized threat assessment of your network traffic, please contact us today!