Ask the Expert: Wireless LAN Security

[ciscomoderator]

With Jeal Jimenez

Welcome to the Cisco Support Community Ask the Expert conversation.  This  is an opportunity to learn and ask questions about about how to implement, configure, and troubleshoot WLAN security with expert Jeal Jimenez. 

Our expert will also discuss how WLAN security works and the different security methods that are available and implemented on enterprise WLANs to validate clients and protect their traffic along with the network. 

Jeal Jimenez is a customer support engineer for the Cisco High-Touch Technical Support department specializing in wireless LAN technology. Prior to joining the HTTS department, he worked as a customer support engineer focused on wireless LAN in the Technical Assistance Center before he was promoted to an escalation leader and trainer, working also as a Cisco lab admin during these years. Jeal's technical expertise in the area of wireless LAN technologies spans more than seven years, and he also contributed to Cisco documentation and to the CCIE Wireless written exam. He holds a bachelor's degree in systems engineering from Universidad Latina in Heredia, Costa Rica. Jeal also holds the certifications CCNA, CWNA, CWSP, CCNP, and CCIE wireless (# 31554).

Remember to use the rating system to let Jeal know if you've received an adequate response. 

Because of the volume expected during this event, Jeal might not be able to answer every question. Remember that you can continue the conversation in the Wireless - Mobility community, subcommunity, Security and Network Management, shortly after the event. This event lasts through October 18, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.

[swapneswar panda]

Hi jeal,

I am now in my preparation for CCIE security LAB v4. While going through the details i came through about Wireless seurity parts. So would you mind to please suggest some tips to corelate this for my preparation ?

Thanks

swap

[Jeal Jimenez]

Hello Swap,

I am not completely aware of the Wireless security topics covered by the Security CCIE, but checking the Lab blueprints and software/hardware list, I will say that you should know how to deploy secure authentications on a WLAN using a CUWN (Wireless LAN Controller and Lightweight APs), with an ACS or ISE as the Authentication Servers; this means:

- Learn about how to configure on the WLC some WLAN/SSIDs for 802.1X/EAP authentication methods with WPA or WPA2 (for key management, using TKIP or AES-CCMP for encryption), defining ACS or ISE as the RADIUS Server.

- Understand the differences between the multiple types of EAP authentication methods that you could deploy for a WLAN (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, and probably EAP-FAST with different inner method types). Some methods authenticate clients with username/password credentials, some with client certificates, some only use server side certificates to tunnel/encrypt the client credentials’ handshake, some could do machine authentication or multifactor authentication, etc. So depending on the requirements, you might need to deploy the appropriate EAP method, which might involve PKI.

- Learn how to configure the settings for those EAP authentication methods (including certificates installation) on the client side (wireless IP Phone or AnyConnect Client or perhaps Windows supplicant) and on the ACS/ISE side. The following is just one possible configuration example for you to start getting some hands-on on this topic:

http://www.cisco.com/en/US/products/ps10315/products_configuration_example09186a0080bd1100.shtml

- You might need to be familiar with most of the BYOD deployments possible on WLANs using the ISE, so you could start with the following guide to understand what I am talking about:

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bba10d.shtml

- I will say that you should be also familiar with Layer-3 Web Authentication for guest users using an ISE, such as in the following examples:

http://www.cisco.com/en/US/products/ps11640/products_configuration_example09186a0080bead09.shtml

http://www.cisco.com/en/US/products/ps11640/products_configuration_example09186a0080c13287.shtml

- In addition, it seems you should be familiar with wireless IPS (remember there are multiple attacks and threats to the network that can only happen over the air or with WLAN equipment, and only be detected/mitigated by wireless IDS/IPS). Therefore, I will recommend you to check the “Cisco Adaptive Wireless Intrusion Prevention System Configuration Guide” to get familiar with this topic:

http://www.cisco.com/en/US/docs/wireless/mse/3350/7.0/wIPS/configuration/guide/msecg_ch1_wIPS.html

- Regarding this topic, a WLC can also be integrated with wired IPS to mitigate some attacks coming from the WLAN that don't really need wIPS, so you might want to check if this wired IPS solution is valid for your exam version:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807360fc.shtml

Hope this can help you with your studies! Wish you the best on your CCIE journey!

- Jeal

[swapneswar panda]

Hi jeal,

Many thanks for these many information. i can say you that definitely i was missing some good stuffs which i was not aware (like wireless IPS). I will go through all you mentioned URLs for docs and definitely will revert with my next concerns .

Thanks

swap

[egordon310]

Hi Jeal,

What recommendations do you have to troubleshoot a WLAN where the authentication is failing?  Thanks for your help on this.

Evan

[Jeal Jimenez]

Hi Evan,

I think the best way to troubleshoot an authentication issue is by first understanding the process of the security method implemented, so let me summarize how 802.1X/EAP works, as this is basically the authentication framework implemented on WLANs:

*** Components ***

- Authentication Server: For WLANs this is a RADIUS Server where the authentication of the wireless clients actually takes place (ACS, ISE, Windows NPS, etc.). Here you define the specific EAP method that you want to allow and its settings (certificates, policies, etc.). Here you also have a local database with the client´s credentials to be checked, or it could be linked to an external database.

- Authenticator: This is the WLC/AP, and the role is basically to act as a "proxy" between the wireless client to be authenticated and the RADIUS Server that performs the authentication. Here you configure the SSID to force dot1X/EAP negotiation with the wireless clients trying to associate to this WLAN (using a specific key management and encryption method, like WPA/TKIP or WPA2/AES), and you define the RADIUS Server that will be used for this authentication.

- Supplicant: The wireless client trying to connect to the secure WLAN. Here you configure the SSID profile that will be used for the association to this WLAN. You define the specific EAP method, and the client security credentials (username/password, certificates, tokens, etc.).

*** Process ***

- The wireless client starts the association to the WLAN using the specific SSID and selecting an AP to connect.

- Once basic wireless association is successful, WLC/AP sends an EAP identity request to the client in order start doing 802.1X/EAP.

- The wireless client should answer back with an EAP identity response.

- This response is sent from the WLC/AP to the RADIUS Server on a RADIUS Access-Request packet.

- RADIUS Server processes the request and it replies back with a RADIUS Access-Challenge to start the EAP negotiation with the client (basically offering the client to start doing the EAP method that was configured for the wireless security policy).

- WLC/AP receives this Challenge, and forwards it to the client as an EAP request.

- Client answers back with an EAP response, which is forwarded by the WLC/AP to the RADIUS Server on another Access-Request. From here, the same exchange will happen multiple times between the server and the client (using the WLC/AP as intermediary) while the EAP method is negotiated and credentials are validated/authenticated. Depending on the EAP method we will see more/less exchanges, but in the end, the server should send to the WLC/AP a RADIUS Access-Accept if it passes or a RADIUS Access-Reject if it fails.

- The WLC/AP will inform the client about this result and deauthenticate it from the WLAN if it failed, or allowing it access to the network so it can start passing data traffic (client asking now for an IP address for example, as layer-2 is fully established now).

*** NOTES ***

- EAP is not a specific authentication method, it is just the name of the base protocol. Based on this, a specific EAP method is configured depending on our needs, requirements, and what the devices support (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, EAP-FAST/MSCHAPv2, EAP-FAST/TLS, EAP-FAST/GTC, etc.).

- This EAP method is only defined on the client (supplicant) and RADIUS Server (Authentication Server). Not on the WLC/AP (Authenticator).

*** Troubleshooting ***

Knowing that, without the need of understanding all the details about the specific EAP method deployed or about WiFi, you can easily Troubleshoot a WLAN authentication issue as follows:

1) First of all, check if the issue is happening to multiple clients/devices. If this is only happening to one, then more likely the issue is with the credentials of that client, or with the supplicant SSID setup on that client for the specific EAP method (or with the device itself, hardware or software).

2) If you confirm this is happening to multiple clients, then select one or two to troubleshoot. Check if the client is trying to connect to the SSID. If it is not even trying, the SSID is more likely not properly configured on the WLC/LAP.

3) Check the WLC/AP client association table so you can see the client status, if it is even trying to connect and what the status is. For example, on a Cisco WLC you will notice that the client is stuck on the authentication process because the client status will be 8021X_REQD.

4) If you noticed that the client is trying but failing or stuck on the authentication phase, then immediately check the failed attempts (failure authentication logs) on the RADIUS Server.

5) The server logs should normally tell you the reason of the authentication failure, but if you don´t see any attempts at all, then there could be an issue between the WLC/AP and the server. If there are failures on the server, the reasons are normally: EAP method not defined or not properly configured on the server or the client, wrong credentials, request is not matching the security policy defined, RADIUS Server has an issue with the external database (if used), RADIUS Server doesn´t know the WLC/AP trying to talk to it (it should be configured as AAA client -NAS- with a valid shared secret), the EAP method defined requires certificates from a CA (at least on the Server) and this is not properly setup... The server logs should normally be clear on the specific reason.

6) If you can´t find any logs at all on the server for attempts from this client and you know the WLC/AP is properly configured to communicate with this specific RADIUS Server, then there could be an issue between the WLC/AP and the server, so you might want to check network connectivity between them (proper routing, no ACLs/firewall blocking RADIUS traffic, no fragmentation issues, etc.). At this point, you could start this network troubleshooting between the Authenticator and the Authentication Server, but you could also start some debugging on the Authenticator, as this will clearly confirm if the problem is on the WLC/AP itself, in the client side, or in the server side, as you should see IF:

- The WLC/AP even started with the EAP identity request or not.

- If the client is responding or not.

- If the WLC/AP is sending the request to the proper server or not.

- If the server is responding (and how) or not.

- If this response is forwarded to the client and if the client is responding, and then forwarded back to the server... Until the point you notice a failure due to a lack of response from the client, from the server, or because the WLC/AP is not forwarding what it should where it should. You could even check if the failure is happening during the key management negotiation (which normally happens due to software issues if the client actually supports the one configured on the WLC/AP).

Debug Notes:

- On a Cisco WLC, you could use the following debugs:

debug client

debug aaa all enable

- On Autonomous IOS APs, you could use the following debugs:

debug radius authentication

debug dot11 aaa authenticator process

debug dot11 aaa authenticator state-machine

7) After this, you will definitely focus your troubleshooting on the WLC/AP, the client side, or the server side, checking deeper connectivity between them (packet captures if needed), the settings of the specific EAP method defined on the client and the server, or looking for software issues due to bad behaviors on any of the three components.

Apologies if this is too long, but I hope it is clear enough to deal with these type of issues.

Regards,

Jeal

[tonyp8581]

Hi Jeal,

Your explanation on authentication process is greatly appreciated.  Very well done.

Thanks !!

[Jeal Jimenez]

Hi Tony,

I am glad to know it was helpful!

If further questions arise about that (the process or troubleshooting), please feel free to ask.

PS: If you want to get more details about the authentication process, checking wireless packet captures and WLC debugs, including details about the processes when roaming or when Fast-Secure roaming with any of the supported methods, I will recommend checking the document I posted recently about "802.11 WLAN Roaming and Fast-Secure Roaming on CUWN" (let me know if there are also questions about this):

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080c1a517.shtml

Regards,

Jeal

[ajc]

Hi Jeal,

I was wondering if the Web Auth Redirect URL configured in the WLC can point to an ISE Administration Node (PAN) instead of a Policy Service Node (PSN).

thanks

Abraham

[Jeal Jimenez]

Hi Abraham,

That is not possible, as the Policy Service Node (PSN) is the only node type (ISE Persona) that communicates with the Network Access Device (the AAA Client, in your case the WLC, using RADIUS protocol) to provide the network access, posture, guest access, client provisioning, and profiling services... Basically, this is the ISE Node/Persona that actually evaluates the policies for the requests coming and makes all decisions based on that.

The ISE Administration Node on the other hand, is the ISE persona that allows you to perform all administrative operations on the ISE itself, handling all ISE system-related configurations regarding the functionality of the services it provides. So this is basically the Node for the Administration of the ISE, not to validate the policies configured on the ISE (as this is handled by the PSN as mentioned above).

Regards,

Jeal

[ajc]

Hi Jeal,

Just to clarify my question and based on your answer, the ISE Admin Node would not have the Web Portal feature activated (see picture below) therefore the following steps for Web Auth can not be completed using this Node as Web Auth Redirect URL Server configured in the WLC because it wont work as external web server and could not send the request back to the action_url including credentials, right?. (please assume Web Auth in the picture below instead of MAB).

thanks

How to Make an External (Local) Web Authentication Work with an External Page

As already briefly explained, the utilization of an external WebAuth server is just an external repository for the login page. The user credentials are still authenticated by the WLC. The external web server only allows you to use a special or different login page. Here are the steps performed for an external WebAuth:

1. The client (end user) opens a web browser and enters a URL.

   
   

2. If the client is not authenticated and external web authentication is used, the WLC redirects the user to the external web server URL. In other words, the WLC sends an HTTP redirect to the client with the website's spoofed IP address and points to the external server IP address. The external web authentication login URL is appended with parameters such as the AP_Mac_Address, the client_url (www.website.com), and the action_URL that the customer needs to contact the switch web server.

   
   

3. The external web server URL sends the user to a login page. Then the user can use a pre-authentication access control list (ACL) in order to access the server. The ACL is only needed for the Wireless LAN Controller 2000 series.

   
   

4. The login page takes the user credentials input and sends the request back to the action_URL, such as http://1.1.1.1/login.html, of the WLC web server. This is provided as an input parameter to the customer redirect URL, where 1.1.1.1 is the virtual interface address on the switch.

   
   

5. The WLC web server submits the username and password for authentication.

   
   

6. The WLC initiates the RADIUS server request or uses the local database on the WLC, and then authenticates the user.

   
   

7. If authentication is successful, the WLC web server either forwards the user to the configured redirect URL or to the URL the client entered.

   
   

8. If authentication fails, then the WLC web server redirects the user back to the customer login URL.

   
   

[Jeal Jimenez]

Hello Abraham,

Exactly, you're right! The Web portal is actually the PSN, not the Administration Node.

Regards,

Jeal

[Andrew Vlasek]

Jeal,

This may be a broad question but in general what type of securtiy measures and monitoring would you consider best practice? I have 5508 controllers and I did not pay for the enhanced WIPS capabilities but I am utilizing the built in WIPs functionality of the controllers and I am inundated with security alerts such as "broadcast probe flood" or "deauth flood" as examples. When I read the forums every security alerts leads down the path of contacting TAC and TAC indicating this is probably a false positive. I have my wireless networks firewalled. I have setup industry best practive encryption and authentication, so my question is does the WIPS provide much value? Does Cisco monitor and taking action or investigate these type of alerts internally? I posed this question to other Cisco contacts and I haven't been able to get much information.

Thanks,

Andrew

[Jeal Jimenez]

Hi Andrew,

Let’s talk a bit about wireless threats/attacks and wireless IDS/IPS, and if this doesn’t address your concerns, please let me know so we can expand the discussion…

- There are multiple threats/attacks that can happen over the air and your wired IDS/IPS/firewall can’t really do anything about them; not even firewall rules on the wireless devices. For example, a wireless device can attack your WLAN by sending deauthentication frames to all or some of the wireless clients ("deauth flood”) connecting to a specific AP, so this attack will easily keep disconnecting the clients (basically causing a DoS attack because your wireless clients will continue dropping the WLAN). How does the attacker do this? Wireless clients should accept/follow any “instruction” from the AP they are connected to, so if the AP asks them to disconnect the WLAN/SSID using a deauthentication frame, they should follow this request and disconnect. So the attacker’s trick is to impersonate the AP by sending all these deauthentication frames on behalf of the AP, which is easily done by finding the AP’s MAC address with some wireless packet captures. An attack like “broadcast probe flood” can be a device/attacker sending multiple probes to an AP, forcing it to send probe responses to those multiple requests (as the 802.11 standard defines that the APs should answer back with a probe response when a client is looking for an AP. There are actually multiple attacks that can be done based on the way WiFi works to establish initial associations, where AP should answer back to clients trying to connect/authenticate), consuming not only AP resources but also channel/RF resources (leading to another possible DoS attack).

- So basically, these attacks are happening only over the air without ever touching the wired infrastructure; these “attack” frames are not traveling through any of the infrastructure devices (not even over the AP, or WLC, or firewall), so they can’t be avoided or blocked. For example, on the "deauth flood” the attacker simply directs the frame from its machine to the wireless clients by sending a deauthentication frame over the air on the specific channel used by the impersonated AP. For such an attack, we could say that there is nothing that can be done from the infrastructure perspective, as we can’t stop a device that is not even connected to the WLAN to continue sending deauthentication packets over the air to the clients. However, there is a feature called Client MFP (Management Frame Protection) that could avoid this attack (by having the clients ignoring these frames that can’t be avoided) as the deauthentication frames from the “official” AP are secured and you don’t need a wIPS to implement this, but the limitation is that you need some specific requirements to enable this on a WLAN/SSID (specific security, and wireless clients Must support this as well). The following document explains this feature:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008080dc8c.shtml

- Some other attacks where the attackers “flood” the AP/WLC with multiple authentication attempts (perhaps doing dictionary attacks to some credentials trying to connect to a secure network, or simply trying to cause a DoS attack to the WLAN) can also be mitigated with just the WLC (without the Adaptive wIPS) by enabling the client exclusion feature, where these devices will be excluded from trying to connect to the WLAN (WLC/AP will simply not respond to these excluded devices) after failing the authentication a certain amount of times. This applies to excessive 802.11 authentication and association failures, 802.1X authentication failures, Web-Authentication failures, or even IP theft or IP reuse.

So what do you get with the Adaptive Wireless IPS solution if your WLCs are already detecting attacks by just having the managed APs monitoring the air to find attacks with behaviors matching the signatures already implemented on the internal WLC IDS/IPS?

- First of all, there are a few signature updates that can only be deployed with the Adaptive wIPS, so some attacks might not be recognized by the WLC’s signatures.

- The Adaptive wIPS involves the Cisco MSE with the WCS/NCS/PI, where you might be able to track the attackers’ estimated locations using the maps configured here and Cisco’s location/wIPS technologies.

- In addition, you might be able to better monitor the attacks (with alarms and even email notifications).

- You could even avoid duplicate attack notifications by multiple WLCs, as they will be all working with the MSE to recognize that the attack reported by one WLC is the same that another reported. Now, even if you don’t have Adaptive wIPS and MSE, all your WLCs managing APs that can hear APs from other WLCs, should be configured within the same mobility/RF group and with the same wIPS policies; otherwise, your own WLCs might be reporting false alarms based on what is happening on your other APs/WLCs.

- The following "Cisco Adaptive wIPS Deployment Guide 7.4" should give you more details:

http://www.cisco.com/en/US/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_guide.html

Conclusions

- As you could imagine, some wireless attacks can’t be avoided at all. Going back to the "deauth flood” example, you can’t stop an attacker to continue sending frames over the air affecting clients that can’t do MFP, as you can’t control the AIR (such as you will control your Internet link traffic with a Firewall for example).

- Adaptive wIPS can’t stop such attacks either, however, you might be able to find the attackers location so you can go and find him/her to take appropriate actions against the actual person (yes, not a networking/technology response, but a task for a human :-)).

- On very crowded environments and with multiple types of wireless clients, some attacks could be actually a false alarm due to multiple clients just trying to connect to a WLAN that they can’t join due to security, or even just because there are wireless clients with software/drivers issues (for example, sending probes like crazy, and not really actively trying an attack). Remember the attacks are “recognized” based on signatures, so the behaviors here might be reaching the signatures frequency within the specific intervals, triggering the alarms.

- There are also possibilities that your WLAN could be attacked by a neighbor’s infrastructure WLAN. For example, our WLCs support a feature called AP Containment, where we will “attack” a malicious Rogue AP (for example, an unofficial AP connected by someone to one of your switchports). The way this works is that the WLC’s LAPs around this Rogue AP will start sending deauthentication frames to the clients trying to connect to this Rogue AP (basically doing the attack explained above), so we can avoid having clients connecting to this malicious Rogue and avoid them access to your network. The problem is that a WLAN administrator might be mistakenly attacking another company’s APs thinking that they are malicious Rogue APs, so you might want to check that this is not the case on your network (here, wIPS can’t do anything for you either; you will need to go and talk to the WLAN admin of your neighbors… Another task for a human).

- In the end, how can you confirm that there are actually some of these attacks happening on your RF environment? Some wireless packet captures will definitely tell the truth (taken around the AP reporting them and sniffing the channel reported), showing all those possible attack frames and behaviors.

Hope this can help!

Jeal

[Andrew Vlasek]

   That does help to some degree because it backs up my assumptions that most of the security alerts are if anything  DDOS attacks or mi-interpreted trafic, but do you have any feedback on the fact that a lot of the events tend to be false positives? I get events that turn out to be my own clients and they are not doing any sort of attack indicated in the security alert email I get. If you search the forums in most cases people report TAC told them its a false positive and to tune the signature which in some cases is not very configurable.

   Also I do already have an MSE and I get email alerts from prime infrastructure 1.3 and I have context licenses to track location I just don't get  the additional signatures that comes with the Adaptive WIPS licenses but either option (basica or adaptive) are their really any non RF DDOS type attacks? Without having the dictionary of signatures in front of me I don't remember them all, but are there any signatures I should be more concerned with? And regardless of adaptive WIPS or basic WIPS does either really help security other than from DDOS perspective? I see DDOS almost essentially like  a performance concern or reliability concern where if I see an issue my troubleshooting would start with looking at the affected AP looking for continuous transmitters and then security events.  I am less concerned with DDOS. I am more concerned some device getting unauthorized access.

I am being asked by my team can we shut off these annoying security alerts and I am finding it harder and harder to find a good reason not to at least from an email perspective. If I am having a performance issues then I would then look for continuous transmitters or DDOS attacks. I tried turning on MFP initially and had issues with that to where it didn't look like a road I wanted to go down ensuring client compatibility.

I am also already using the exclusion feature to block clients after multiple failed attempts. I am planning on integrating out wired infrastructure into prime 2.0 so that I can ensure that no authorized AP are broadcasting on our network. Am I missing anything do you have any other suggestions for security? On thing we currently don't have is wired IPS on the wireless infrastructure, but we do only allow corporate boxes with anti-virus on corporate wireless.

Thanks,

Andrew