The SPR project started out as a series of bash scripts and configuration files. Adding new devices was a little bit error prone, as everything was done on the command line. Each device would require a new, strong password, and each device needed to be added to a zone's configuration. Next, hostapd had to be restarted to get WPA3 password reloading to work. It was hard to debug and not apparent if things failed.
What would make SPR super useful, though, would be if it was easy to use. And a user interface can do that for us.
So this week, Supernetworks pushed out a frontend for testing.
This Release Delivers Basic UI Features
Three functions are now available:
- Add a new wireless device to the network
- List devices
- Set device access zones
While these are simple things, and seemingly easy, SPR's services work together to build a network that is virtually unlike all other wifi setups available today. As a result, the base station service, the DHCP server, and the API need to work together to leverage their features so that users have a super smooth experience.
See a Demo
How Devices are Connected to SPR
- Each wireless device is on an isolated network, keyed in by their MAC address and passphrase
- MAC/ARP spoofing is blocked by hardened firewall rules to completely stop ethernet/IP-based evasion for lateral movement
- Zones specify the level of each individual device's access
- Custom zones can create groups of devices that can intercommunicate without having full LAN access
- Built in ad blocking with CoreDNS
Some of the challenges were
- Laying down a solid foundation between the API and frontend to make adding new features great
- Supporting a smooth WPA3 experience, which uses a ZKP for authentication
- Making it fast and easy to add a device without having to also know or enter its MAC address ahead of time
The built in zones are
- DNS for outbound DNS queries
- WAN for outbound internet access
- LAN for general access to all local devices
When a user types in a new name, such as "Cameras", NFTables verdict maps gets created by the API. All of the members of the maps can send and receive IP traffic to one another, but do not get general access to the LAN. In the future, custom firewall rules will be added to further specify how the groups interact.
What's Next for the UI
For the road map, I'm thinking about security features such as intrusion detection or automated security scanning and fingerprinting, network debugging and bandwidth monitoring, per-device ad blocking, and home automation.