13 posts tagged with "SPR"

Intro​

In the blog post we'll describe how to build and run SPR on a Mini-PC. And we'll use a WiFi 6 capable radio inside.

First, get a Mini PC ready​

1. Identify a good mini PC to use. Wilson suggested a look at QOTOM's i3 broadwell routers.

The g330 is not bad. It's a fanless build with a TDP of 15W. One mini pci-e slot is dedicated to mSATA, and the other can be used to fit a wifi radio. It also has additional SATA available for one more storage drive.

WARNING: On this device, the mini-pcie slot has a tall post for half-sized cards that needs to be removed to fit thicker full sized WiFi cards.

2. Get a good WiFi radio.

We'll run with an 802.11ax card that works with Linux in AP mode (at least 802.11ac is recommended).

Mediatek is the disruptor in this space and supports AP mode on Linux. [NOTE: Many other cards will NOT work with ax in AP mode on Linux with open source drivers] . If you have recommendations please do not hesitate to reach out on the matrix chat. For the G330 Qotom, 2 antennas wires are provided to outside the case, so the 2x2 configuration is best.

The MT7915 can be purchased from AsiaRF.

Setup​

Download and install Ubuntu Server. Since the WiFi 6 driver is a work in progress, we grabbed a daily release of Jammy Jellyfish 22.04 from the Ubuntu Live page to get the latest fixes. Copy the installer to installation media (a flash drive) then plug it in and go.

Then follow the SPR Setup Guide.

Our config/base/config.sh:

#!/bin/sh                                                                                                              
SSID_NAME=6lab                                                                                                         
SSID_INTERFACE=wlan1                                                                                                   

#PPPIF=eth0                                                                                                            
#WANIF=ppp0
#PPP_VLANID=201
#PPP_PROVIDER=provider-config
WANIF=enp1s0
RUN_WAN_DHCP=true
RUN_WAN_DHCP_IPV=4
# Uncomment the next line if a second ethernet port goes to wired LAN
#LANIF=eth1
VLANIF=wlan1
VLANSIF=$VLANIF.

LANIP=192.168.3.1
DNSIP=$LANIP
TINYNETSTART=192.168.3.4
TINYNETSTOP=192.168.3.255
TINYNETMASK=255.255.255.252
TINYSLASHMASK=30
DOCKERNET=172.17.0.0/16
DOCKERIF=docker0

WIREGUARD_PORT=51280
#WIREGUARD_NETWORK=192.168.3.1/24

Configure hostapd for 802.11AX​

On the SPR device, modify configs/wifi/hostapd.conf and add:

ieee80211ax=1
he_su_beamformer=1
he_su_beamformee=1
he_mu_beamformer=1
he_oper_chwidth=1 # 80mhz channel
he_oper_centr_freq_seg0_idx=42

Restart wifid

docker compose restart wifid

Connect a wifi 6 client and verify HE codings are available

# iw dev wlan1.4096 station dump -v  | grep bitrate
        tx bitrate:     1200.9 MBit/s 80MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0
        rx bitrate:     720.6 MBit/s 80MHz HE-MCS 7 HE-NSS 2 HE-GI 0 HE-DCM 0

Some Notes on the MT7915​

The MT7915 is a Dual Mode driver. This means that it supports both 2Ghz and 5Ghz frequencies simultaneously. For our install the 2ghz interface is on wlan0 and 5Ghz on wlan1. This is really wonderful, since one card can serve older IOT devices that only run on 2Ghz as well as more modern devices at high speeds.

The linux kernel driver is not yet as stable as it could be, so beware that it may not yet be production ready -- several assertions and crashes were noticed. The mainline kernel does not yet support radar scanning, however the code is available in the openwrt development branch.

User Friendliness​

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 Zones​

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.

Hello, SPR​

I'm happy to start releasing the Secure Programmable Router project to the world. I've been running my home WiFi with it for the past few months and I'm beyond excited to give back to the open source community. I started working on this project because I think that Linux provides a tremendous amount of agility and power for secure home networking but I felt like there was no router project out there that pulled it all together.

The SPR project is about several things​

• A highly secure foundation to operate a home network where using the internet is safe and it's easy to see and control what IoT devices are up to when they are plugged in.

• Making home privacy easy instead of begrudgingly sharing telemetry with big data companies.

• Open source and empowering developers by lowering the barrier to entry for coding with home networking.

• About reducing the barrier for entry.

• Enabling scripting and rapid prototyping.

• Adapting modern networking paradigms and tools that can meets today's needs.

How SPR Came To Be​

During the past year, I took a serious look at opnsense and OpenWRT, and ordered over a dozen different wifi routers to set up my home network. I sat down and built and deployed my own OpenWRT images and to set up secure wifi networks to connect with a more serious firewall. What I found was that the setups I had managed to achieve were not only frustrating to manage, but when I went to test their security, I found time and time again that vendor wifi routers were insecure due to fundamental limitations with the network designs. On top of that, they were riddled with software security holes. Unfortunately, running the open source builds of OpenWRT often had degraded performance versus the proprietary vendor patches or required breaking secure boot.

I felt frustrated because I felt like I had lost control over my own home network. I had only a basic idea of what I was running and what my devices were doing, let alone the routers themselves. Between smart bulbs and vacuum cleaners and home security cameras and speakers, TVs, gaming consoles, laptops, desktops, streaming devices, more routers, and work equipment, there was a lot of stuff that was online.

I've been working in computer security for over 15 years and I often get asked for how to set up a home network.

The best advice I could give people for their home wifi was to keep their mission critical systems on a dedicated wifi router, and plug that one into the main wifi router with all the other "stuffs" that ultimately connects to the internet. This is awkward and requires switching networks or IGMP proxying to do discovery or zeroconf. This doesn't scale well across a multi-office home with repeaters and backhaul. It also doesn't scale well in an apartment where there's competition for radio bandwidth with neighbors for essentially one of only three coveted 80mhz channels on 5ghz.

The next best advice was to split out the "whatever" non-critical devices to the guest network, and the mission critical stuff on the main network. Hardening the guest network with isolation breaks discovery and streaming as well. In practice I found that most of the routers I looked at did not have good guest isolation anyway when enabled, something I will blog about later. No exploits are required, because more or less an attacker can just ask a router to send packets for them to work around hostapd's AP Isolation feature, and most of the routers will happily do what they do best, route the packets.

At the end of the day though, it's fundamentally a flawed idea to have a shared passphrase across many devices because that passphrase effectively lets devices spoof each other or attempt to intercept traffic, making it tough to truly firewall devices.

So then I started looking into enterprise wifi authentication: 802.1x (EAP-PEAP, EAP-TLS, EAP-PWD). EAP-TLS really is the only secure way to do things since EAP-PEAP suffers from fundamental man in the middle issues that were never fixed. Or EAP-PWD (which is almost wpa3) would be great, if it was supported by more devices and drivers, and well with EAP-TLS, certificate management is pain.

I really wished that one could just use a unique passphrase per device. Well, it turns out that yes, that works, and hostapd supports it out of the box. With some logic and usability and correctness fixes to hostapd, and it was easy to seamlessly add new devices and their passphrases on the fly.

Okay that was great. Next, I created strong device isolation with per-device subnets that could be configured to communicate with other subnets using forwarding rules. The resulting network was a bit too different than the spirit of the networking scripts in OpenWRT, and the patching became unreasonable to expect for upstream to accept, so I started from fresh ground.

SPR is implemented for rapid iteration. Services are containerized so that developers can swap out core services or roll up new ones in a testable, reproducible manner. An API drives configuration to allow for customization. SPR Runs off of Ubuntu, with Docker containers, and manages the network with NFTables. It uses hostapd for the base station software, CoreDHCP for DHCP, CoreDNS for DNS, and supports Wireguard.

SPR simply enables users to do better than today's status quo. It lets users run a hardened, secure network without restrictive drawbacks. It lets users connect their consumer electronics to the internet with the peace of mind that doing so does not weaken their home network security.

What's Next​

Today SPR runs as a proof of concept on a Raspberry Pi. With a USB dongle it's well able to handle over a dozen wifi stations and serve data from the internet with rates up to 500mbps. Work is underway to expand to new systems.

I'm currently wrapping up a Web UI to make SPR user friendly. In the near future I'll be posting a road map for what's planned.

Want to learn more and discuss? Join the Discord Chat