Posts Tagged ‘Air Marshal’

Air Marshal, Reimagined

Out With the Old

Early in 2012, a startup company beginning to make waves in the networking industry introduced a new feature for their line of access points. This startup was called Meraki, and the feature launched was Air Marshal. At the time, the functionality satisfied the security requirements of a typical wireless network: automatic containment of rogue APs seen on the LAN, keyword containment of SSIDs, scheduled Air Marshal scanning, and the ability to configure additional APs as Air Marshal sensors for round-the-clock protection.

With the introduction of the MR34 in 2013, Cisco Meraki introduced the dedicated scanning radio and this took the Wi-Fi industry by storm! No longer would admins have to choose between performance or security. With the dedicated scanning radio, the MR was now capable of servicing clients while simultaneously listening to the entire RF spectrum, protecting clients from malicious rogue APs.

The constant surveillance of wireless networks continues to be important, but recent trends in cybersecurity and the growth of Internet of Things (IoT) requires added flexibility when it comes to securing wireless networks.

The Blacklist

No, James Spader won’t be lending his hand to protect your wireless network. But, much like his character on the popular TV show, Air Marshal will work to eliminate (or contain) all SSIDs found on “the list.” TV shows aside, Air Marshal traditionally made it simple to automate containment of rogue SSIDs that are seen on the LAN, or contain SSIDs that matched a keyword.

However, some environments may have a network comprised of multiple vendors, or may be a part of a collaboration workspace where numerous companies may feature their own WLANs, connecting to the same wired network infrastructure. In this instance, automatic containment of rogues seen on LAN won’t work, as the non-Meraki APs would cease to function for their clients.

But administrators no longer have to forfeit their security capabilities. With Air Marshal’s new SSID Blacklist table, rogue SSIDs won’t be automatically contained, but security rules can be configured to match on a variety of conditions allowing for an accessible network to be locked down with finely tuned security controls.

Security rules may match on four different conditions: exact matches, MAC address matches, keyword matches, and wildcard matches. The rules defined in the SSID blacklist table will match against SSIDs that are seen on LAN, as well as Other SSIDs that are “heard” by the Meraki APs but are not found on the LAN. Any matches will result in the MRs within the vicinity of the rogue or other SSID to actively contain the SSID, rendering the offending SSID useless for clients who wish to connect. Exact matches will match on the SSID seen (whether the SSID is seen on the LAN or not), while keyword rules will ignore surrounding characters and match on just the keyword specified. BSSIDs (MAC addresses used to identify a Wi-Fi network) can be matched against if specific radios (2.4 GHz or 5 GHz, for example) that are broadcasting need to be contained.

The wildcard match provides the greatest amount of flexibility. Wildcards can be used to substitute a string of characters with a single *, or a single character with a single ?. For example, an SSID Blacklist wildcard rule may match the following text: ‘*12345’. If the MR detects an SSID broadcasting ‘Guest-12345’, then that SSID will be contained. If the rule is configured to match on ‘Guest-12?45’ and the MR detects an SSID broadcasting ‘Guest-12345’ or ‘Guest-12Z45’, then that SSID will also be contained.

Merely containing the SSID isn’t enough, though. Administrators often want to be cognizant of the rogue SSIDs that are being detected and secured by their MR access points. As such, if the administrator has configured email alerts or syslog in their Meraki Dashboard, they’ll stay apprised of their security rules in action.

Good News, You’re on the (White)List

Seemingly every other day, a new company is featured in the media as being the latest victim of a cybersecurity attack. Wireless networks are often considered the edge of the network infrastructure, the first line of defense in many cases. As a result, many administrators and security teams alike want to automatically contain rogue SSIDs seen on the LAN. While this grants the highest level of security enforcement, interoperability issues may arise when factoring in how often wireless display adapters and IoT devices connect to the network.

In the modern enterprise, HDMI cables are being replaced with Wi-Fi Direct adapters to make screen sharing and video streaming simple and intuitive. In the majority of instances, these Wi-Fi Direct devices (an adapter and client device, such as a PC, printer or remote) will often communicate on their own, freshly created wireless network. Sounds easy enough… except for one slight issue. This isn’t an SSID that’s broadcast by your MR access points, and in no time at all, deauthentication frames are being sent over the air in an effort to protect your devices from the suspected intruder. While the security team is rejoicing, the network administrator is still working to find a way to whitelist these devices so that security can be maintained with just enough flexibility for day-to-day employee operations. Enter the SSID Whitelist table:

The newly familiar faces are all here when it comes to the way that SSIDs can be matched to whitelist from containment. Exact matches, keyword, MAC, and wildcard can all be used. However, unlike the SSID Blacklist table, the whitelist table will not send email alerts or syslog messages when SSIDs are matched.

Alert, but Don’t Touch

There may be instances where administrators wish to be alerted when certain SSIDs are “seen” on the LAN or “heard” in the air, without taking any specific blacklist or whitelist actions. Using the same match conditions available for the SSID Blacklist and SSID Whitelist tables, alerting security rules may also be configured. These alerts will be sent via email and syslog alerts, if configured.

In With the New

Security has been at the forefront of Meraki since the introduction of Air Marshal in 2012. With the latest enhancements made to Air Marshal, new security rules can be configured to match on a variety of conditions, enabling administrators to implement granular security policies that are flexible for the modern workplace. These new Air Marshal features encompass the rapid innovation made possible by the Meraki dashboard. The new Air Marshal enhancements are available free of charge for existing MR customers as part of a seamless Dashboard update. For the SSID whitelist and SSID alerting functionality, the MR network must be set to MR25.9 firmware or higher. Visit our documentation for more information on configuring Air Marshal.

Floods and Broadcasts

Introduction

This is the fourth in a series of blog posts that focus on wireless security and technology at Cisco Meraki.

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: