If you are not using OpenWRT, it’s time to start now, because all instructions below will be given for OpenWRT.
P.S: Don’t follow instructions blindly, check if your router supports such operations.
Technical part
Create the Script
#!/bin/sh /etc/rc.common
START=17
prefix='28:6A:BA' #prefix used for the mac address, randomizing this part gave strange errors (sometimes)
iface=0 #interface number according to: uci show wireless
renew=39600 #timeout to renew the mac address in seconds
pidfile="/var/run/macChanger.pid"
start() {
if [ -f "${pidfile}" ]; then
pid=`cat "${pidfile}"`
if [ ! -z `top -bn1 | awk '{if ($1 == "'"${pid}"'") print $1}'` ]; then
logger -t "mac changer" -s -p daemon.error "already running!"
return 1
fi
fi
logger -t "mac changer" -s -p daemon.info "started"
while [ true ]; do
mac="${prefix}"`hexdump -n3 -v -e '/1 ":%02X"' /dev/urandom`
network=`uci get wireless.@wifi-iface[${iface}].network`
if [ $? -ne 0 ]; then
logger -t "mac changer" -s -p daemon.error "iface ${iface} not found, exiting"
exit 1
fi
uci set wireless.@wifi-iface[${iface}].macaddr="${mac}"
uci commit wireless
logger -t "mac changer" -p daemon.info "new mac: ${mac} set for: ${network}"
[ "$action" != "boot" ] && /sbin/wifi restart 2> /dev/null || action=''
sleep "${renew}"
done&
echo $! > "${pidfile}"
}
stop() {
if [ -f "${pidfile}" ]; then
pid=`cat "${pidfile}"`
rm "${pidfile}"
if [ ! -z `top -bn1 | awk '{if ($1 == "'"${pid}"'") print $1}'` ]; then
kill ${pid} $(top -bn1 | awk '{if ($2 == "'$pid'") print $1}')
logger -t "mac changer" -s -p daemon.info "stopped"
return 0
fi
fi
logger -t "mac changer" -s -p daemon.error "not running!"
return 1
}
This script is designed to run at startup (as indicated by START=17), generate a new MAC address with a fixed prefix, and apply it to the wireless interface specified by iface=0. The renew variable determines how often the MAC address is renewed. Adjust the prefix and iface variables as needed for your setup.
Alternative script by ChatGPT (untested!):
#!/bin/sh
# Generate a random MAC address
MAC=$(printf '02:%02x:%02x:%02x:%02x:%02x\n' $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random))
# Apply the new MAC address to the WAN interface (replace 'wan' with your interface name if different)
uci set network.wan.macaddr=$MAC
uci commit network
/etc/init.d/network restart
Save the Script: Save the script to /etc/init.d/macChanger. This location is standard for init scripts in OpenWRT (macChanger you can replace name if you want)
Make the Script Executable
Run chmod +x /etc/init.d/macChanger to make the script executable.
Enable the Script
Enable the script to run at startup by executing /etc/init.d/macChanger enable.
These databases are not particularly new. Adding _nomap to the WiFi SSID will opt out of the Microsoft/Google one. Also setting your SSID to hidden will help.
Probably a good idea to do that as well otherwise a random one will be mapped at your house anyway.
Also this may cause unexpected issues according to a forum post on OpenWRT along with this disclaimer:
what use is it to successfully fool google/ apple/ microsoft about your AP, if the neighbours’ APs 6m left and right are loud and strong in their database.
Here is new scripts that probably should help you:
Mimic script:
#!/bin/sh
# Define MAC address prefix
PREFIX="00:1C:B3"
# Generate a random MAC address with the Apple prefix
NEW_MAC=$(printf "%s:%02X:%02X:%02X" $PREFIX $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random) $(od -An -N2 -i /dev/random))
# Apply the new MAC address to the router's interface (replace wlan0 with your interface name)
ifconfig wlan0 down
ifconfig wlan0 hw ether $NEW_MAC
ifconfig wlan0 up
Prefixes (as example):
Apple: The prefix for Apple devices is 00:1B:63.
ASUS: ASUS devices use the prefix 00:11:22.
Change MAC when no devices are connected (UNTESTED!)
#!/bin/sh
# Function to generate a random MAC address
generate_random_mac() {
local OUI="00:11:22" # Replace with your router's OUI
local RANDOM_MAC=$(printf '%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))
echo "$OUI:$RANDOM_MAC"
}
# Check if all devices are disconnected
if [ $(iw dev wlan0 station dump | grep -c Station) -eq 0 ]; then
# Generate a new MAC address
NEW_MAC=$(generate_random_mac)
# Apply the new MAC address to the wireless interface
ip link set dev wlan0 down
ip link set dev wlan0 address $NEW_MAC
ip link set dev wlan0 up
fi
Change MAC by time:
#!/bin/sh
# Function to generate a random MAC address
generate_random_mac() {
local OUI="00:11:22" # Replace with your router's OUI
local RANDOM_MAC=$(printf '%02x:%02x:%02x' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)))
echo "$OUI:$RANDOM_MAC"
}
# Apply the new MAC address to the wireless interface
NEW_MAC=$(generate_random_mac)
ip link set dev wlan0 down
ip link set dev wlan0 address $NEW_MAC
ip link set dev wlan0 up
Replace wlan0 with the name of your wireless interface if it’s different. Also, replace 00:11:22 with the first three octets of your router’s original MAC address to maintain the same OUI.
To schedule this script to run for example at 12:00 and 0:00, you can add the following lines to your crontab:
On some devices you can select a specific BSSID your device is permitted to connect to. Is there a security benefit to this that would be negated if the MAC was randomized and you are unable to leverage this feature?
I think we are misunderstanding eachother. My question was whether there are security benefits to ones ability to restrict connection to a specific BSSID that would outweigh the privacy benefits of randomizing the MAC address on some interval of time.
Maybe it would be more constructive if you outline the scenario in which you are imagining using your BSSID strategy to improve security?
It could be that I’m misunderstanding the utility or the use-case for this strategy, but it seems that it would have limited value in the context of your home router, unless (1) you have reason to believe you are being (or might be) actively targeted by a motivated adversary in close proximity to your router, or (2) you live in a crowded environment (like a big apartment building) and are worried about either an opportunistic threat. If I understand the feature correctly, I’d think the primary utility of locking to a specific BSSID would be using that feature for public wifi and other contexts where its more likely someone would be attempting to impersonate/spoof an SSID.
Am I thinking about this correctly, or have I misunderstood the technique you are referring to?
I wasn’t positing any specifics, but asked if there were any implications under the assumption the client feature of isolating BSSID existed for a reason. I agree those threats/use-cases are rather obscure, and couldn’t think of others. Hence the question.
I wouldn’t use ifconfig in any of those scripts that’s from the old net-tools package. ip link set dev is the correct way to do this on a modern linux system.
It looks as if this feature has been implemented upstream and is exposed in luci. There is some discussion about it including the code that your ChatGPT answer spilled out.
I would go with a design that uses the uci comamand to do this though and not modify the interfaces directly with ip link or ifconfig, as that is bound to cause issues. It certainly should come with warnings as this is not possible with all drivers.
If it were added it could be added as a section under the openwrt card. Would highly suggest checking it actually works though first.I have a few openwrt capable WiFi Devices I can test this on TDW8970 and some original UniFi APs.
Should also mention doing that will cause your devices to look for that network in the area.
I think all three are worth suggesting. I would not use strong words like “must” as I think it’s overly alarming for something which isn’t particularly serious.
bssid randomization
hidden ssid (but disable wifi when not in area)
nomap
The reason being is that
BSSID randomization isn’t always possible (depends on driver and if the device even supports it or openwrt).
Hidden ssid has downsides such as if you have a lot of people in your household then they might forget to disable wifi on their devices when not in the area. Those devices will scan for the BSSID when not in area
Some drivers cannot connect to hidden networks, I have one such Lenovo laptop which has that problem. It is quite common for IoT related devices to not work with hidden networks, and be confused by randomized BSSIDs. Ie if the BSSID changes from the first time you connect to the device it may refuse to connect in later attempts.
I believe that if the BSSID changes, most devices will not reconnect to the Wi-Fi network automatically.
If this were to happen, it could pose a security issue. For instance, a malicious actor could create a hotspot with the same SSID as a network to which you have already connected, and your phone would automatically connect to it.
Which is why I am having second thoughts about this even being mentioned.
It’s going to break a lot of really shouldn’t be done. If you hide the network, you will still be able to detect it with promiscuous scanning tools anyway.
_nomap is the least dangerous, way to prevent white hat WiFi netowrk mapping. If someone really wants to find your WiFi network there is nothing you can do.
If I remember correctly NetworkManager puts the BSSID in the WiFi configuration on linux automatically.
