Would it be possible to package software capable of detecting access points that aren't on a known list? Ideally it should find all access points that are nearby and then log an event based on matches. It could go off of MAC address and SSID.
There are some commercial platforms that already do this. For instance, Aruba has
As far as community projects goes I was able to find a few.
These all seem to be done in python. Ideally, it should be a C program that listens for broadcasts from access points. If the broadcast doesn't match a known list then there should be an event logged. I think performance will be critical as most access points don't have a lot of hardware.
Normal wifi antenna receives on a single channel, you need channel-hopping or full-band receiver to catch broadcasts from other networks. Aruba actually does requests from operating access points and draws a map, by magnitude more complex than simple script detecting other AP-s. Gets even more complex with randomizing MAC addresses.
i Don't need crazy complex. I just need a program that can find SSIDs and MACs that match a rule set while excluding stuff that doesn't. That is all it has to do.
I was hoping for a standard way to do this. I don't want to try to code up custom solutions as that creates headaches down the road.
There is no ready-made WIDS in OpenWRT packages.
It is possible to background-scan for own SSID, in simplest way send a list (and own "official" BSSID) to a syslog server where overly heavy application detects anomalies. Further down the road - check what usteer does, if you manage something similar count me in as your customer
Thanks for this. That snappy project looks a lot newer than anything I found on my own.
Just adding to the literature and existing stuff I found. Haven't tried any of them as they look abandoned. Haven't found anything myself that is a set and forget solution that will "just work" with openwrt.
Quick note at how I'm thinking of approaching this:
Horst can end up pretty buggy but that was my goto, with monitor mode on the AP's in addition to the AP interfaces on the different radios. i.e. Using horst client and then scraping the output.
My plan was to use AP's with 2 radios + USB port for a third radio, or find a no compromise tri radio device and not have WIDS/rogue ap detection on 2ghz. Or just double or triple up the AP's and live with the extra power consumption and extra cabling. Doing this properly does a lot of CPU though on my older AP's.
I haven't yet had a look at using the built in scan functionality of different wireless chipsets? i.e. whether that will be an adequate detection solution without having to do monitor mode and active scans / another radio.
I've found parsing syslog with openobserve to be the lowest resource way I could create visualisations with. Haven't done alerting yet as it requires you to do everything over HTTP.
Mm. I now have a correctly configured usteer setup. It's something i'd like to get working eventually but that involves more than just scraping output for unknown bssid / ssid from monitors mode AP's and scans.
I don't have the scanning part done. First I was doing automation with tmux screen captures, but then I got the raw output from horst working. I haven't done integration into my log server for alerting yet.
Yeah usteer configured correctly should get you the neighbour reports from clients of the current AP's? I don't think it will report other AP's in the user interface? I'd have to look into it further.
I think usteer is not ideal as it doesn't have a way to easily do cross AP communications. If anything it might make more sense to use DAWN although I personally have concerns with both.
Ideally this should be done in hostapd, Usteer and DAWN already talk to hostapd so it should be a matter of just making a program to query hostapd for all known APs and then checking a list to see if there are any unknown. It might be necessary to modify hostapd to have native detection abilities. When a majority of clients detect a unknown AP it could trigger hostapd to do some sort of scan. If it detects the device it could then report it somehow. Obviously this would be disabled by default.
For the scanning portion it should be possible to do it passively. hostapd could just listen for incoming frames that are from the AP in question. Also for proper rouge AP detection you would need to check to see if the AP is connected to the same network as current APs. It would also be beneficial to be able to flag other attacks such as deauthentication attacks.
Yeah reason i guess usteer was mentioned as a reference is it gives hearing maps and multiple nodes.
One can add a monitor interface to an interface that has an AP. I haven't tested with all hardware though. I've had issues with horst with mt7615e on the upper 5ghz bands with an AP also active. It'll require further investigation.
Usteer does say whether the device is connected to one of your AP's.
Regarding passive scanning:
What I was talking about was using the built in radio scanning functionality. i.e. instead of looking for a clear channel, can automate it to look for rogue AP's without having to do monitor mode / multi radio stuff.
But obivously iw isn't a stable interface per their documentation so would need further investigation. i.e. something similar to iw dev <device> scan dump and regularly triggering scans etc.
I need to have a look at whether these sorts of scans can be done with minimal impact and what the differences between different radios are.
TBH i think monitor mode listening on all the channels and/or scanning on existing AP's is sufficient for my purposes.
The hearing maps being used to report a rogue ap would be a nice to have. and good on the edge of your network where a client is connected to your network, but there could be a rogue ap far away.
I wonder if you could do more than just detect it? Think about it, you could detect interference from a person across the hall or street and then automatically jump frequencies. You could even have automatic AP setup where each AP chooses a frequency not in use.
One of my interests is federated and or decentralized systems. It would be cool to build a system where OpenWRT devices could effectively self assemble to build a network that provides the best possible service. You could just create a image with the image builder and then flash a bunch of devices. On power up they could automatically detect what frequencies are in use and pick one that is not occupied.
"The scope creep is real" . I want to be careful of the good idea fairy.
Yeah it's "just" some glue logic and we should be right =P
I'd love something like that too. I'm okay with ACS at the moment and just sticking to smaller channel widths.
I'd start with checking whether the local radio measurements make one want to switch channel locally. Similarly can look at usteer and check the neighbouring AP's.
Yeah plenty of possibilities but I think that the place for an RRM system is in a different feature request =P
IMO one would want to have your AP's in a GIS to find the edge of the network etc.
I think there's limited requirement as it's only the edges of the network where it should be an issue for most people running campus level wifi. Rogue AP detection is enough to go and tell someone to turn their rogue AP power down / off to play nice.
I think OpenWRT in a bigger deployment is fairly exciting. Sure it is great for a small home but I think there is some serious benefit to building something that is mostly hardware independent. Think about it, vendors like to EOL stuff so that they can push the latest and greatest but using a system based around OpenWRT means that they have a lot less control over you. In the case of a small business or resource limited organization OpenWRT is nice as it can run on literal junk. I've heard of small business owners building a network out of hardware they got for very cheap used due to a tight budget.
Also I think having the ability to detect interference on a consumer level is useful to. If would be nice to be able to see that your neighbor recently created upgraded Wifi and put it on the same channel as yours. I think OpenWRT could really use some sort of bigger management solution that could speed up deployment and facilitate monitoring. (Thus the RRM) Right now there is Ansible and OpenWISP but both of those require a central controller. (OpenWISP is pretty decent for management)
I've only done SMB with openwrt. i.e. operating on the 5-50 AP level. I'm in the used AP and PoE switch camp for building a network for cheap yes. PoE AP's for sub $10 per unit yes please =P
Openwisp leaves a lot to be desired in the single building front but does give a nice UI. IMO it's more for WISP applications than campus applications. But it'll eventually get there. IMO it's also way too heavy needing 1-2GB of ram, but that's me coming from an embedded systems background.
It got me most of the way there really quickly. But in terms of ease of implementing my own features I'm more inclined to automate with ansible.
I'm inclined for HA yes. But distributed and mesh can be challenging from an implementation perspective. I don't like heaps of broadcast traffic on my network. Central controller doesn't matter if it's push/pull only and the AP's can operate independently if the central controller goes down.
I think what most users are inclined for is easy installation and set and forget. Not whether centralised controller is good/bad.
We already have this with the automatic channel selection.
Have a look at iw dev <phy> survey dump and what your AP is doing when you have 'auto' channel selection with a 'channels' list?
My initial thoughts on if you want this functionality: Channel survey data, coupled with AP scan data and usteer local neigbour output should get you most of the way there if you can somehow start at the edge of your network and work your way in. Similarly if you had monitor mode on channels so you dwell for more than ~115ms which is what it looks like i'm getting on my example AP you could get a better measurement. Some AP's do have a separate radio measurement radio. Haven't seen anything in openwrt yet though. But main thing is SNR / power measurements I guess.
In a nice graph form of channel active time etc:
Graph of example survey output.
Example survey output
Survey data from phy0
frequency: 5180 MHz
channel active time: 115 ms
channel busy time: 1 ms
channel receive time: 1 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5200 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5220 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5240 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5260 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5280 MHz [in use]
channel active time: 745832444 ms
channel busy time: 6224610 ms
channel receive time: 572896 ms
channel BSS receive time: 546861 ms
channel transmit time: 5541988 ms
Survey data from phy0
frequency: 5300 MHz
channel active time: 113 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5320 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5500 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5520 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5540 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5560 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5580 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5660 MHz
channel active time: 117 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5680 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5700 MHz
channel active time: 118 ms
channel busy time: 2 ms
channel receive time: 2 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5720 MHz
channel active time: 118 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5745 MHz
channel active time: 113 ms
channel busy time: 1 ms
channel receive time: 1 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5765 MHz
channel active time: 124 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5785 MHz
channel active time: 114 ms
channel busy time: 19 ms
channel receive time: 18 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5805 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5825 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5845 MHz
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0
frequency: 5865 MHz
channel active time: 154 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2412 MHz
noise: -91 dBm
channel active time: 113 ms
channel busy time: 16 ms
channel receive time: 18 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2417 MHz
noise: -91 dBm
channel active time: 114 ms
channel busy time: 0 ms
channel receive time: 0 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2422 MHz
noise: -91 dBm
channel active time: 114 ms
channel busy time: 10 ms
channel receive time: 17 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2427 MHz
noise: -90 dBm
channel active time: 115 ms
channel busy time: 10 ms
channel receive time: 12 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2432 MHz [in use]
noise: -90 dBm
channel active time: 428261139 ms
channel busy time: 16802568 ms
channel receive time: 22531650 ms
channel BSS receive time: 29059 ms
channel transmit time: 1549844 ms
Survey data from phy0-ap0
frequency: 2437 MHz
noise: -92 dBm
channel active time: 115 ms
channel busy time: 8 ms
channel receive time: 14 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2442 MHz
noise: -77 dBm
channel active time: 115 ms
channel busy time: 1 ms
channel receive time: 7 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2447 MHz
noise: -91 dBm
channel active time: 115 ms
channel busy time: 0 ms
channel receive time: 2 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2452 MHz
noise: -91 dBm
channel active time: 114 ms
channel busy time: 34 ms
channel receive time: 34 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2457 MHz
noise: -92 dBm
channel active time: 114 ms
channel busy time: 2 ms
channel receive time: 7 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2462 MHz
noise: -91 dBm
channel active time: 115 ms
channel busy time: 1 ms
channel receive time: 11 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2467 MHz
noise: -92 dBm
channel active time: 114 ms
channel busy time: 3 ms
channel receive time: 1 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Survey data from phy0-ap0
frequency: 2472 MHz
noise: -92 dBm
channel active time: 184 ms
channel busy time: 13 ms
channel receive time: 14 ms
channel BSS receive time: 0 ms
channel transmit time: 0 ms
Looks like usteer has a "node up script" so i'm going to investigate that further. Plus looks like with hostapd_cli one can also set up channel switch announcements. But yeah probably going to have to make a new post if you want to continue the RRM feature discussion.
That is true, but mesh11sd has built in autonomous channel tracking, enabling an entire mesh backhaul channel to be changed.
There is a different approach. There is currently a proprietary package that works with the openNDS and mesh11sd packages to whitelist access points.
Only users on a whitelisted access point will be granted Internet access by openNDS.
This proprietary package is currently being "open sourced" and in early beta stage with a target release date on OpenWrt sometime in the first half of 2025.
Like I said, this is an entirely different approach, but does have a significant use case overlap.
