Tried verbose logging and no sign of any rekeying every 10 minutes if the parameter is not set in /etc/config/wireless or via luci... there is a greyed out value of 600 in luci, and no parameter in /etc/config/wifi after changing via luci, and no rekeying events appear in the log.
If you set the value in luci (i.e. actually set it to 600 or whatever) do get the rekey messages in the log
however what you do get at default is one set of rekeying messages once a day when the group master key is rekeyed at its hostapd default value. another parameter of hostapd that is not accessible via luci
also hostapd should default to doing a rekey whenever a station leaves, it seems also to not be doing that.
this is a stock openwrt 22.02 image.
the normal default values for hostapd for gtk rekey seem to not being used if they are not specified explicitly in /etc/config/wireless
you have to specify them in /etc/config/wireless
and there is actually an undocumented parameter for strict rekeying already available. (having scanned /lib/netifd/hostapd.sh and tested my theory that it was already optionally there)
option wpa_strict_rekey '1'
and hey presto - it works!
now rekeys whenever some punk does a deauth!
sorted! (though I am rather disapointed to discover it was not already working... "open" wrt eh! back to the philosophical meanderings of whether to treat an idiot as as bad as a saboteur....)
By the way, that comment not aimed at you! I expected it to be working as default should too!, could be a change that crept in from upstream hostapd... ???
A great paper I read ages ago by Dennis Ritchie... "Reflections on trusting trust!"
I guess if I really wanted to prove it i could log with kismet, but I reckon I already have proved it... (given the outside chance that the default is not logged, if so then basically they should just actually log it at the verbose level which it is not)
"assume nothing" seems certainly the post-torvalds-conversion-to-pc state of affairs. If "assume-nothing" was ever a false state in the first place.
indeed, perhaps... "assume the worst" seems the correct posture post the covid scamdemic eh!
maybe it is a good method to always specify all parameters having scanned a hostapd file with good comments in, but thing is, istm, stuff changes that even negates a well commented config file... and they do not post an up to date commented config file...
like the whole ffmpeg and avconv split eh! like no avconv examples... yet reams of still valid today ffmpeg examples eh! cryptic without examples.
I'd say I had a couple of military grade vulnerabilities... streaming audio over http, and... at least another one.... that without rekeying were extra vulnerable...
drifting off topic but... that nadal complaining of chest pains after lambasting jokovic for not taking the vaccine is.... well, whatever you make of it i guess eh!
I'm wondering, if, at some point in time, some years ago, 600 seconds was considered a reasonable rekeying time, what, now, is considered reasonable? given gpu power and prices coming back down into pleb. like me territory? and stuff like kali linux and wifi pineapple etc. and all the refinements to foreknowledge...
I'm thinking 300?
I guess what I would like building in to openwrt is an auto attack detect and deploy bunker busters... except... what if they live in the flat above LOL?
Yes, part of the problem is not having a definition of what good settings should be. (until I found a well documented hostapd.conf)
Thanks for the link.
This is the hostapd.conf file I was reading.
The dhcp stuff is broadcast stuff and I was noticing deauths and then double dhcp in the logs on several nodes. (I have 10+ wifi nodes so its also quite a busy wifi internal network)
I can say from after a couple of days since doing the strict-rekey and the periodic rekey that I am no longer getting massive amounts of deauths (I do think I am in certainly a likely wardriving spot, next to a main road, a very busy wifi area, and I suspect someone quite possibly has kali linux or similar installed in an in-range place.)
My theory about the rekeying is that if it does not change for 24 hours until the gmk rekeys (the state it was in) then there may be some replay attacks opened up. If the attacker knows there is some particular data in a packet (i.e. they are in audio range, which includes parabolic mic type things) and the gtk is near-constant then there is only one key to defeat in decrypting the packet.
with the gtk changing that is made more difficult for an attacker, and an auto gtk-rekey after a deauth should add an extra complication to them.
I did also set wifi isolation on as I figured better to reduce another weakness which is one node on the wifi that was contacted by other wifi nodes, so I put that function on the wired lan, which is isolated from the wifi and needs a firewall rule.
I think it is possibly a weakness that the config files are not fully documented and "set in stone", as what it does is add a layer of uncertainty in each layer upline, uci, then luci as to what a function in either of them actually sets in the config files.
How no gtk rekeying crept in seems to me perhaps some assumption problem, like perhaps assuming hostapd assumes a default. ? Or assuming a hack attack will be the exception rather than the rule?.
they would still need a pairwise to have received it (i.e. they were authorized devices on the BSSID); but I understand your point - and you'd have a bigger issue that simply changing your pairwise PSK would fix
the sending client is no longer associated and the AP shouldn't accept it (if there's sanity checking at this point)
only the AP transmits to all clients on behalf of the received broadcast message from the sending client, so [if there's some sanity checking] the group key would not work unless they also spoofed your BSSID to replay (that might cause you other observable issues)
I don't know...I'm really shocked, actually, I'm glad I set a value...
But...I don't see a log entries...I assume that's because I need x >= 1 machines on the AP for 24+ hours?