We are back from Las Vegas and had a great time at BSides as well as at DEF CON. Teams on site ran the latest nzyme alpha release to monitor the local WiFi environment. Things worked even better than expected and we took a ton of experience and new ideas home.
Don’t forget to subscribe to stay in the loop! (Mastodon, LinkedIn, RSS)
Let’s take a look at what’s new!
Running nzyme in Las Vegas
I was on-site to assist the NOC teams at BSides Las Vegas as well as DEF CON with their nzyme WiFi monitoring deployments. The things that I hoped to take home were:
- Stress testing the latest version of nzyme in probably one of the most hostile and complex WiFi environments on this planet.
- Experience how others use the system
- Learn where people get stuck and what doesn’t make sense yet
Stress Testing
The taps were deployed on Raspberry Pi 3’s and 4’s, with two WiFi adapters each, covering the 2.4 and 5 GHz bands entirely.
The average memory consumption of the nzyme-tap process was less than 100MB at all times and total CPU utilization
remained under 4%, even on the older Rasperry Pi 3’s. This was even beyond my highest expectations and shows that
using Rust, with a focus on performance on the taps, seems to turn out well. No tap crashed, except once, when tap #3
had its power cable unplugged by a vendor at their booth. Overall, future deployments should make use of Power over
Ethernet (PoE) where possible.
A review of the nzyme-tap logs revealed that there were no significant parsing errors.
Detection
The current WiFi detection capabilities of nzyme v2.0.0-alpha.1 at or below what previous version were able to do.
Nonetheless, the hostile environment at the conference locations provided a great opportunity to test the existing
detection logic.
Detection/Alerts UX
The detection and alert handling user experience proved to be an issue. The configuration was confusing for new users, and several browser tabs had to be opened to copy data around. Large networks with many BSSIDs/access points require a lot of network monitoring configuration. Future releases will feature an import functionality, but other UX issues remain.
The feedback made it into several GitHub issues that will be addressed over the coming alpha releases. Thanks everyone!
Detection Performance
In short: Network monitoring performance was absolutely terrible in environments that large. One bottleneck, that was fixed on-site, was inefficient SQL queries that were caused by large BSSID tables. However, the approach of searching recent data for network configuration deviations will not scale enough to reach acceptable response times in many professional environments.
This is why, while still in Vegas, work on a real-time detection engine started. Instead of retroactively searching over existing data, nzyme is now comparing tap reports when they arrive at the nodes. Early testing of this new approach showed very promising initial results.
Goal achieved.
Update on the upcoming alpha.2 release
You can expect the next pre-release, alpha.2, in the coming days. Most of it’s functionality was already tested
in Las Vegas.
The big changes and new features since alpha.1 will be:
- WiFi Network Monitoring re-implemented
- Entirely configured through web interface
- Bandit detection re-implemented
- Automatically detects several attack platforms, including WiFi Marauder, WiFi Pineapple, Evil AP and Pwnagotchi
- Alerting and alert actions re-implemented
- Tons of smaller bug fixes
After this release, the focus will shift to WiFi triangulation/location and remaining WiFi detections for
v2.0.0-final. Following that, work on the Ethernet features will begin.
