Mojo's wireless access points can ID and mitigate threats, trigger alerts
Network managers don’t need a primer on the threats that could befall their networks, from man-in-the-middle threats from rogue APs to the global ransomware epidemic. It’s a bad situation that shows no signs of improving any time soon. It’s not surprising, then, that Wireless Intrusion Prevention Systems are becoming increasingly popular.
WIPS are based on the very sound idea that if you truly want to keep intruders off your network, you’ll need intelligence both in the Wi-Fi access point and in the cloud. That’s one reason why vendors such as Aruba, Cisco, and Extreme (Air Defense) offer solutions that combine analysis of network data with a back-end thinking engine.
Another WIPS vendor is Mojo Networks (formerly known as Airtight) which recently released a cloud-based Wireless Intrusion Prevention System as a Service called Cognitive WiFi. That is the subject of this review.
(We also requested review units from Aruba, Cisco, and Extreme, but Mojo is the only vendor that came through.)
Mojo’s WIPS architecture combines APs that can also be wireless routers (with optional DHCP) connected to a cloud-based engine that is used to both activate the APs and manage them — so you can configure them, monitor traffic, choose authentication methods, perform forensics, and so on.
Mojo offers all the basics you’d expect from a WIPS. Admins can manage multiple sites at once and receive alerts when certain conditions are met. They can collect data about authorized visitors and guests (including data that could potentially be used for marketing purposes). The same APs can host multiple SSIDs with different levels of authorization. Most importantly, Mojo’s APs can identify potential hazards and mitigate them automatically or bring them to the administrator’s attention.
Once they’re configured, the APs can be disconnected from Mojo’s cloud console and continue to do their jobs, but until they reconnect to the mothership you won’t get the full benefit of the back-end data analysis.
Mojo Networks’ Cognitive WiFi satisfied us as being multi-site ready, understanding attacks, and having very good sensing skills—all manageable from a single, if clunky UI/UX.
What is WIPS?
As the name implies, WIPS use policy and network controls to prevent bad guys from gaining access to network resources. When they detect something that looks like rogue hardware, they send an alert to an admin who can determine whether it’s actually a threat and if so, isolate it before it causes too much damage.
That means WIPS need to fit into a wide range of environments and, ideally, require a minimum of site-specific configuration detail. Some WIPS have used a local appliance (or access to a network operating center) to monitor traffic and/or serve as a router/firewall/switch. But when you’re faced with monitoring multiple sites, this can become tedious, expensive and time consuming. Performing threat analysis and AP provisioning in the cloud simplifies and automates this process.
One reason WIPS-managed networks are increasingly popular is they can leverage your existing infrastructure – you don’t have to move to the latest access point technology or wait for your systems partners to upgrade their security and authentication systems. As an unaligned organization, Mojo connects to WIPS infrastructure from Cisco and Aruba/HPE (though we didn’t test this). Thus WIPS is less about brand names and more about secured pathways.
While it’s vital to detect and mitigate rogue attacks quickly, forensic analysis, regulatory compliance and other needs can be equally important. Mojo’s cloud console lets you do all of this more or less on a single screen, although not always as elegantly as we’d have liked.
WIPS Architecture under Mojo
MojoNetworks’ WIPS WiFi coverage is composed of AP connectivity managed by a cloud-based dashboard organized into two categories: Services (configuration, forensics, WIPS configuration, administration) and Apps (Learn/gateway screens, application analysis, optional software and more).
Tom Henderson/IDG We deployed six APs, all adjacent to a college campus and a shopping center office building, in a downtown location. Each location we tested had APs deployed according to the usual “rules” for deploying IEEE 802.11ac access points. Above the site are two transmitters, a 250w FM radio station, and its 900Mhz transmitter link. To say the area was radiologically active is an understatement.
Each Mojo-provided AP contains three radios: Two radios service the 2.4 and 5Ghz WiFi bands, while the third radio watches the environment for traffic and abnormalities. The third radio is a key element in watching the radiological scenery, and therefore in intrusion prevention capability, given the wide number of stressful circumstances that the other two radios can find themselves under. One of Mojo’s staff called it their “third eye,” and it’s an uncommon but not entirely unique feature.
Our test APs connected to a network segment with fiber-based Internet access and optionally to VLANs with traffic paths to local desired hosts/locations. From there, the PoE-powered Mojo APs initially boot a software firmware load from Mojo’s site, with policies and network and authentication information designated by the site administrator. Each AP can support multiple SSIDs each with their own WLAN configuration and policies. Depending on authentication method, each can support differing methods pinned to each SSID, including a customizable walled garden. While each AP can be completely tailored, generic templated configurations will suit most organizations; we found the templates easily modified and pretty thorough.
The APs pass traffic to internal and Internet choices as administrative policies describe. The policies are constructed to mate handily with SSIDs, and we could choose between open Internet access, through walled garden access (via social media authentication or a splash page), or by comparatively stringent methods. Mojo also supports third-party SAML 2.0-based authentication, though we didn’t test that.
The service worked across IEEE 802.11a,b,g,n+/- and ac WiFi services as expected. Mojo’s APs seem to be able to detect APs and clients/WiFi devices down to -96db, corroborated by a Netscout analyzer whose threshold of sensitivity as a test tool is only slightly better.
The Dashboard Console
You configure APs using Mojo’s cloud portal, aka the Dashboard. If an AP can reach Mojo’s cloud resources, it will pull the location’s or specific AP’s configuration and restart using those settings. It’s like a netboot/PxEboot for the endpoint AP, and this is how you’d initially provision them. This worked fine, but pushing down new configurations took longer than we expected – one of our only beefs.
The Dashboard’s sub-windows are administratively definable, and the monitoring components of the dashboard are divided into four tabs: Network, Access Points, Clients and WIPS. We suggest using a high-res monitor in high resolution to get the most of the information on a screen; it doesn’t work well with laptop geometries unless you have binoculars. Multi-monitor setups for broader installations will be a must.
Tom Henderson/IDG The business end of the Dashboard is the Wireless Services Manager. It’s the largest work area of administrative control in the Dashboard and where we spent most of our time.
From the monitoring section of the Dashboard, we could monitorManaged Devices (Managed Access Points), WiFi (APs, Radios, Clients and WLANs), Security (APs, Clients and Networks), Applications (Protocols, named applications like Facebook, Amazon, XMPP (Messaging), FTP, etc.).
We checked the Managed Devices, and the WiFI and WLAN configuration (more on that later). Then we looked at the Security Tab, which has interesting data, including a long list of what’s in the vicinity, radiologically speaking – classified by Authorized, Misconfigured, Rogue, External, and Found but Uncategorized.
We deployed six total APs in our test environment, which in turn found dozens of area APs in the adjacent college building, nearby office buildings, residences, shopping centers, even people walking down the street with phones or devices on free-association mode. Amusingly but not surprisingly, a number of insecure WiFi printers were also found on adjacent/nearby networks. On a typical day, more than 80 APs were located in the vicinity of the test site, numerous unsecure devices, up to several hundred clients, as well as people walking and driving by with devices that constantly hunt for APs to join by default.
The Security tab reveals the goods: known APs, rogue clients and APs, all in a green/red UI, with blue noting external but detected devices, and light green denoting guests. White reveals uncategorized devices, neither fish nor fowl – detected but awaiting categorization until the layout of the network has been described by an administrator.
Tom Henderson/IDG You can map APs to a base drawing, which indicates where physical devices like clients are located within the geometry of the drawing. That means you can track a smartphone user in near-realtime as they walk through the radiological boundaries of the AP-covered areas, as well as locate a rogue device or the source of an attack.
Security relies upon identifying, normalizing and successfully authenticating network devices. You can choose from several authentication themes, including the never-recommended completely open AP, as well as WPA/WPA2, along with 802.1x authentication. (The latter requires a Radius server in the circuit; there is a plug-in, but it uses a pre-shared key and therefore might not be useful, according to Radius experts.) You can also use Google authentication, where a Google authentication proxy circuit is tenable in conjunction with the walled garden software offered by the APs. The walled garden gateway is highly customizable, although the garden HTML splash screen editor frustrated us.
WPA2 can use the IEEE 802.1a and 802.1q IKE protocols, whose authentication is also external to the Mojo Network components. Using IKE is non-trivial for some organizations and so WPA2 PreSharedKey/PSK is most commonly used. As mentioned, we did not test third-party security providers with MojoNetwork’s APs.
Events
The bad guys wind up listed in the Events tab. Should a rogue AP appear – and anyone with a smartphone can make a rogue AP accidentally by attempting to share their Internet connection – that device remains permanently on the possible rogue AP list.
False positives such as these make it trickier to perform intrusion prevention and forensic analysis by dirtying the lists unnecessarily. You have to individually acknowledge each event – there can be hundreds of them – and add a note to each. We found this tedious in the extreme. This strictness will appeal, however, to diligent organizations. Great for documentation, bureaucracy for others. You use the same log to record system and performance-related events.
Authentication and rogue classification is important, because Mojo’s infrastructure attempts to detect other APs on the backbone or enterprise network. If it can do that, it considers them non-hostile. But if the logic can’t detect an AP (often by Mac address, but we suspect there are more methods), then the potentially rogue AP is considered to be hostile, and man-in-the-middle attacks or other attacks could be taking place.
We tested rogue APs both through emulation as well as actual rogue APs, then connected a rogue to the network to see if Mojo’s cloud logic could identify it as a rogue. It took less than a minute, but we would have preferred it happen instantly.
External APs can optionally be auto-classified as rogue, but are automatically qualified. Rogue APs and clients trigger alarms, sometimes noisily (lots of log entries), and Mojo supports syslog pipes to an organization’s syslog analyzer(s) for regulatory/compliance purposes. The physical location of the rogue or potential rogue can then be vectored on the location map. It could be as innocent as someone trying to configure their device or they could be looking to snarf user credentials or cause re-association blockages, a kind of Denial of Service/DoS attack. There are many variants of DoS attacks disambiguated in the Forensics section of the Mojo Dashboard. The noise is therefore necessary.
Monitoring and Forensics
Monitored APs render interesting information, including an event log, but also a very difficult-to-read rendering (dark red text on a black background) of congestion information encountered by clients of the specific AP. Also included are traffic profiles, including top application for the AP. Amusingly, Spotify topped the list of several APs in our live test environment.
Tom Henderson/IDG The information regarding the radios in the APs renders a configuration listing of how the radios are related to WiFi channels, but also about their worst-case client sensitivity (how radiologically close, similar to “bars”) measured as RSSI (in dbm). This indicates the weakest signal the AP radio had with a client.
As we used three SSIDs and six APs, we could track traffic per SSID and the type of authentication used. We also got saw how the clients spread over the SSID/WLAN AP radios. We caught an Amazon video lover this way. It was 9 p.m., and he or she was the sole person in the building.
The Apps Visibility we found to be very interesting, as each app (ex: Facebook, SSL/HTTP page, iCloud, etc.) is given a Threat Index, which admins can redefine. Facebook, it turns out, is by default rated a very high threat. We could drill down and ask how many clients (and their Mac addresses) accessed Facebook, how much data they consumed, how Facebook data compared to all data transfers for a specific client and how often Facebook was accessed for that client over time. So you’ll know if Eddie uses Facebook on breaks or Eddie uses Facebook from the time he arrives until he leaves, as well as if he watches plentiful videos over Facebook.
The Forensic portion of the dashboard deals with the discovery of bad guys. Tracked in near realtime are AP Related Threats (rogue, banned, honeypot, DoSed, and/or misconfigured APs), and Client Related Threats (unauthorized, banned, mis-association, discovered ad hoc networks and/or bridging/ICS clients – those backdooring the network). These are stated by time and are graphed by devices or instances.
You can drill down into each item on the list (ex: Unauthorized Client) into the instances found. The event is reported explicitly. An example might be:
|
Procedurally, Ethernet frames and 802.11 control information are monitored, but not packet payloads. In turn, the .pcap files generated can be read by WireShark (and other .pcap analyzers) for troubleshooting, crack attempt analysis, and trouble-ticket generation by a third party app if desired.
Reports
The MojoNetwork reports are strong. They’re divided into Assessment, Compliance, Incident, Device Inventory, and Performance.
Our test bed was insufficient to report much of Device Inventory and Performance. The Assessment reports include Airspace Risk, and Wireless Vulnerability tests, which can be generated on scheduled, then emailed, as can other reports.
Compliance reports include DoD Directive 8100.2 Compliance, GLBA Wireless Compliance, HIPAA Wireless Compliance, MITS, and PCI DSS 3.1 Wireless Compliance and Internal Audit Reports, and SOX Compliance Reports.
You can modify each report as to salient fields (headers, footers, fields), then have them generated and/or archived on a scheduled frequency. We felt that these make up for the time we had to spend acknowledging alerts by attaching tiny notes to each one.
Criticisms
The UX of the Mojo Dashboard needs a little work. There is much information that’s inter-related, but it’s a hierarchical system, and so up and down the menus we went, drilling down, until we clicked back and back and back, perhaps needlessly if salient processes were properly interconnected.
Because of the breadth of administratively changeable items, we worry that the simple username/password of the Mojo Networks cloud account becomes very susceptible to a major hacking episode. A clear path needs to be open to Mojo Networks to ensure administrative success, and we noted that there is insufficient multi-homing.
We’d like to see more difficult auth to get to the MojoNetworks cloud account. Without a clear path to Mojo’s site, no contact is made. An initial DNS lookup from the APs at installation time might be helpful to more easily effect initial connection.
Another downside: Some pushed AP configuration changes could take twenty minutes from click to availability, causing us to drum our fingers excessively. Most changes seemed to require an AP restart, done automatically. The only signal that the changes took effect was an indication that a changed service became available after a small AP time-out. Change them all at once, and the WiFI site can go down for up to 20 minutes. Granted, that’s not something anyone is likely to do.
Summary
Mojo’s Cognitive Cloud WiFi presents a cloud-based WIPS system that worked well in testing. Its UX/UI is only a little weird due to hierarchical menu madness, and an enormous amount of customization and authentication is possible. It seems to be heterogeneous with other systems infrastructure, but played well in our highly noisy test environment. It was quickly responsive, except where AP reboots or AP configuration pushes were made.
We felt the online docs could use a bit of work, but there is an online Mojo Networks training system and it makes up for the lack of a ready, context-sensitive help system. And their tech support was uniformly helpful and responsive to the requests we made (though they were aware we were reviewing their product – your mileage may vary).
How We Tested
We tested MojoNetworks APs and cloud systems in a 1920s concrete building that used to be a firehouse. It has six areas of unblocked coverage, and contained six APs cabled to it via Ethernet and powered with PowerOverEthernet/PoE. In turn, the APs were connected via an HP 8-port L2/L3 switch, then to a GBE backbone connected via fiber to the Internet (provided by Smithville Internet). More than 80 other APs were sensed in the neighborhood, along with hundreds of clients. The building is underneath an FM commercial band transmitter and a 900mhz transmitter link, and has four 150mhz transmitters within line of sight. Noise shelf in the WiFi ranges was -99dbm at 2.4ghz, and -113dbm at 5.2ghz – in other words, very noisy.
We used seven rogue access point clients to emulate rogue, disassociation and DoS attacks. These included several Linksys and Netgear switches re-flashed in common WiFi configurations, but also with DD-WRT software to permit us to use two advanced attacks. We also converted two Linux notebook (Lenovo Yoga and x120e) to act as WEP and WPA attackers. We checked connectivity with Lenovo, Samsung and Apple laptops running updated Windows 10, LinuxMint 18 and MacOS 12.12, respectively.
We used five smartphones (Apple iPhone 5c and 6, Samsung S3, Asus ZenPhone and a Motorola/Lenovo) to test rogue-client status and also attempted MiTM and disassociation attacks with the Samsung S3 and Motorola phones, as well as ad hoc network credential theft tests, also using the notebooks.




