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.