Recently, I am considering purchasing a portable OpenWRT router to better protect the traffic of all my devices while traveling. However, I have some privacy concerns:
I am worried that when connecting to different hotel networks, the unique MAC address of my router obtained by the ISP could lead to my identity being uniquely identified and tracked. Currently, iOS has the feature to randomize MAC addresses for different networks and rotate them after a period of time. I would like to know if the OpenWRT router has the capability to “randomize” and “rotate” the MAC address that the ISP obtains.
Additionally, I have seen claims that routers broadcast their MAC addresses, which may pose some privacy issues. Could anyone explain how this works? Can the aforementioned “rotating MAC addresses” and “randomly generating MAC addresses for each network” help avoid this issue?
TLDR; If and only if you keep the router online and are physically moving around with the router at the same time, then maybe the MAC randomization may benefit you. Otherwise, I’d argue it has negligible benefits if you turn the router online at a fixed location and turn it off when physically moving the router. Even then, I don’t believe this would easily tie to your identity at all without quite intensive forensics.
———
Are you saying that randomizing the router’s MAC address enhances the privacy of the devices inside the local network? If so, there’s a serious misunderstanding of the purpose of MAC addresses and the threat model that MAC randomization operates under.
First of all, MAC addresses are valid only within a local network. When I connect to openwrt.orgon my computer, the (highly simplified) packet flow goes like this:
My computer creates an IP packet. Its source address is my computer’s IP address. Its destination address is openwrt.org’s IP address.
My computer wraps the packet into an Ethernet frame. Its source address is the computer’s MAC address. Its destination address is my router’s LAN MAC address.
My computer sends this frame which gets picked up by my router’s LAN port.
My router strips the Ethernet frame and inspects the IP packet header. It determines it should be forwarded to the ISP’s router which is reachable via my router’s WAN port.
My router wraps the packet into a newEthernet frame. Its source address is my router’s WAN MAC address. Its destination address is the ISP router’s MAC address.
Repeat steps 3 through 5 for each router hop until the packet gets to the final router connected to the LAN containing openwrt.org’s servers.
That final router wraps the IP packet into the final Ethernet frame. Its source address is the final router’s MAC address. Its destination address is the openwrt.orgserver’s MAC address.
Notice that the MAC addresses of the Ethernet frames change at each hop. The ISP router never sees the MAC addresses of the internal devices. And neither does the openwrt.org servers, or the servers of any other website. (Well, except for LuCI running on the OpenWrt router, of course.)
Second of all, MAC randomization came about because of smartphones constantly transmitting probes in order to find WiFi networks to connect to. A bunch of WiFi APs collectively can use this to track the physical movement of smartphone owners. This scenario doesn’t apply to your router, because it’s almost always in a fixed location. MAC randomization is mainly useful for WiFi devices that are highly mobile or portable like phones and laptops.
But let’s say for the sake of argument that router MAC randomization on reboot is somehow useful. OpenWrt users have uptimes measured in weeks to months, rebooting their device only to install updates or to test snapshots. So are you expecting users to constantly reboot their routers every 24 hours or so, disrupting all current connections?
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.
