Wireless networks underpin most of our day-to-day activities, all while sharing the same relatively small frequency spectrum. As such, the protocols that dictate how these networks work are exceptionally polite by design, and for good reason. This is because wireless networks, like humans, are half-duplex, meaning only one station or person can talk at anyone time.
However, this politeness can also be used against such networks by potential “bad actors.” This post will detail how Cisco Meraki access points help our users’ networks from being excessively impacted by such malicious (intentional or otherwise) devices.
How can broadcasting be bad?
You may be asking “why would a network broadcast be a bad thing? On my wired network, protocols use broadcasts all the time,” and you would be correct that broadcasts are seldom a problem on the wired side of network (but not always). However, as we have previously discussed, wireless is a shared access medium, so if someone was continually talking (packet flood discussed below), we would have to wait for them to stop. More importantly, when an access point transmits to a client on a wireless network, it has to transmit at a speed that the client can understand. For a broadcast frame, this speed is actually the slowest supported data rate of the BSSID and is often a basic data rate.
This means that when transmitting broadcast (and management) traffic, the access point can only talk as fast as the slowest data rate at which the BSSID will accept a client association. If the default settings for minimum bit rate have not been changed, then an access point will send the broadcast frames out at up to 150 times slower than it could do (though this isn’t something Meraki recommends).
This can render the 802.11 network unusable, as the access points are always busy transmitting or waiting for the malicious broadcast traffic (if another AP or client is broadcasting). This behavior is often weaponized by bad actors into a DoS attack against wireless networks.
Meraki APs help minimize excessive broadcast traffic from entering the wireless medium from the wired network by enabling Proxy ARP. This means that an access point currently serving a wireless client responds to an ARP request from the wired portion of a network on behalf of the wireless client, which would have otherwise been sent as a broadcast.
Additionally, Air Marshal can alert Meraki network administrators to malicious broadcast traffic that has been seen by the access points in their network, as shown below:
Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.
What is a packet flood?
In a similar manner to misusing broadcast traffic, a client or AP could send out large amounts of 802.11 management (beacon, association, and authentication) frames, knowing that an access point is bound by protocol to process and, where appropriate, respond to them. This is akin to an inquisitive toddler peppering their parent with questions, without waiting for a response, over and over again.
As any teacher or parent will know, working in this kind of environment requires either the patience of a saint or the unconditional love of a parent. Alas, for 802.11 networks, access points, whilst being very polite, lack both of these things! As such, when a client behaves in this manner, it is detrimental to the performance of the overall wireless network in much the same way as excessive broadcast traffic.
As with malicious broadcast traffic, Air Marshal will alert the administrator that the access points within their network are seeing this potentially nasty behavior and display the frame type, as shown below:
Then, the administrator can investigate the local environment to ascertain and mitigate the source of the malicious broadcasts.
Other things to consider…
Finally, one other type of network-level transmission that can cause issues in 802.11 networks is multicast traffic. Unlike wired networks, wireless networks typically send multicast traffic flows over the wireless medium as broadcast traffic. In order to alleviate this potential issue, Meraki access points enable IGMP by default. This has the effect of converting the multicast stream into (potentially multiple) unicast transmissions that are likely to be transmitted at much higher speeds.
This is essential in classroom environments, where students could be watching a multicast HD video stream as illustrated above.
Conclusion
Similar to the “evil twin” attack discussed in the previous blog post, there is nothing that can be done to mitigate these risks while still complying with the 802.11 network standard. However, the power of the Meraki dashboard and access points provide instant visibility into threats in an organization.
References
For more information on Air Marshal and spoofs please see the following additional references:
TEDGlobal 2010, themed “And Now the Good News”, wrapped up with some good news for Meraki and TEDGlobal attendees using the conference WiFi. As part of the British Telecom Sponsorship team, fellow Meraki engineer Robert Shanks and I were on site to deploy and support the wireless network for this 4-day conference. To make a long story short, the wireless network performed flawlessly, with just over a 1,000 people connecting throughout the conference and transferring over 250 gigabytes of data.
The conference venue, located in Oxford, UK, had its fiber backhaul brought in by BT. The backhaul was then distributed to wireless users in the two main venues of the conference, the Oxford Playhouse and the gala rooms of the Randolph Hotel, through fifteen MR14 dual-radio access points.
We leaned heavily on the Cloud Controller to quickly deploy the network with a small team. Rogue AP detection and automatic channel spreading maintained performance while TEDsters blogged, tweeted, browsed and streamed all at once. While we trusted the Cloud Controller’s real-time alerts to let us know about unexpected changes (there weren’t any), we also kept tabs on the network’s summary report, giving us a good understanding of the overall usage and performance of the network.
Along with performance and usage information, the summary reports confirmed that the device-of-choice for TEDsters was the iPad, with well over 100 using the network. In fact, hand-held devices accounted for over 50% of clients connecting to the network.
We had a great time at TED, and were happy to see the Meraki network being used so heavily. Thanks to the team at British Telecom for including us!
One of the most challenging aspects of managing large distributed networks is troubleshooting issues when the client is across town (or maybe even across the country!). Having on-site IT personnel 24/7 at even small satellite branch offices can require a very large IT staff and is too expensive for most organizations. Meraki networks offer a variety of “remote hands” troubleshooting tools, helping network admins diagnose and resolve many wireless connectivity issues without dispatching IT staff to the site. The ability to run diagnostic checks such as pinging an access point, running a throughput test from Dashboard, or reviewing detailed event logs have been integral to Meraki’s value for distributed networks and organizations with small IT staffs and large footprints.
We are now announcing a set of Live Client Tools that expose even more up-to-the-second information about who is on a wireless network, and further help troubleshoot connectivity issues. Administrators who log into their Enterprise network in Dashboard will notice several new and improved areas. On the Monitor > Overview page, there is now a new addition under the network name showing the number of clients that are associated at that moment:
If you click on the “More” link, you will see an expanded list with more information, including which SSIDs and channels the clients are using. This data is automatically refreshed as long as the “More” link is expanded.
Even cooler, Enterprise customers can change the access points map to show where clients are associated: click the “Options” menu on the map and select “Current clients.”
But the really interesting stuff is on the Access Point and Client detail pages. The Access Point detail page used to look like this:
Now, all of the live tools have been consolidated into a new, cleaner layout. Both Pro and Enterprise networks will benefit from the new layout. Enterprise networks now have two additional features in this area: Current Clients and Ping Client MAC. Clicking on the play icon next to Current Clients will pop up a list of all clients associated to that AP at that instant, including useful information about each client such as MAC, SSID, channel, signal strength, and how long they have been associated. Click on the name of a client to go to its client details page. You’ll even see clients that have associated, but not authenticated (they’re listed in grey). If you click the Ping link next to the client, you can actually ping that client in real time using ARP, as well as get additional information, such as RSSI changes over time and 802.1X identity (if appropriate).
The other new addition, Ping Client MAC, allows you to enter a MAC address and try to ping it. This can be very useful if you are trying to determine if a particular device is on your network at that moment.
There is also a new Live Tools section on the client detail page. From this page you can also ping that individual client, but there are a few additional new tools:
The Locate Client tool allows you to find out whether that client is associated on your network at that moment, and if so, where they’re associated and for how long:
Finally, the Packet Counter tool shows a real-time count of received and sent packets to that client. You can actually see the packet counters roll as you ping the client!
We think these new tools further improve Meraki’s uniquely clear approach to distributed, multi-site network management, a normally challenging task. Network administrators can more quickly resolve their wireless users’ connectivity issues and access accurate real-time data about the exact state of their network.
WPA-Enterprise encryption with 802.1X authentication is the method of choice for providing secure access in an Enterprise WLAN environment. Unfortunately it’s also notoriously tricky to configure, with a range of possible configuration issues involving the three key players in the system (client devices, access points, and the RADIUS authentication server itself).
We’re pleased to announce a handy diagnostic tool in our Enterprise Cloud Controller which helps identify many problems with a custom 802.1X setup.
After configuring your RADIUS server for 802.1X, you now have the option of testing your setup directly from Meraki Dashboard:
Enter the username and password for a test user and click the Test button. The system initiates a test from each of your Access Points to your RADIUS server using 802.1X authentication with PEAP and MS-CHAPv2. Each AP in the network is individually tested; this enables us to detect network issues or RADIUS server configuration problems that might affect only a few of your APs.
If all goes well, you’ll see results like this:
(In the example above one AP is shown as “unreachable”, meaning that it was powered off and was therefore not tested. This is common for example if your network has one or two spare APs which are not normally kept powered on.)
If there are test failures, however, you’ll see results like these:
In this example there was a timeout while attempting to reach the server from one out of five APs tested. This error often results from forgetting to add an AP’s IP address to the whitelist on your RADIUS server, and it’s usually a very difficult error to discover and debug.
We think this is a useful tool that makes it super easy to troubleshoot the security of your WLAN. In addition, this tool provides peace of mind that each AP can authenticate users correctly. Automated testing is especially valuable in large, 100+ AP environments, where testing each AP manually could literally take days.
We look forward to hearing your feedback about it!
Enter the username and password for a test user and click the Test button. The system initiates a test from each of your Access Points to your RADIUS server using 802.1X authentication with PEAP and MS-CHAPv2. Each AP in the network is individually tested; this enables us to detect network issues or RADIUS server configuration problems that might affect only a few of your APs.
