Advice needed about Wifi Security

alphalt · May 24, 2018, 9:07pm

Ok, I dug a bit deeper and I think I found the answer I was looking for.
As stated before, there are two interfaces that outputs messages to syslog (the are actually more, but I'm concerned about those two). One is via wpa_printf and the other is via hostapd_logger.
wpa_printf is not really checking log_level setting in UCI wireless setting. In fact, in current version I have (2018-04-09), wpa_printf minimum level is hard coded into the software to MSG_INFO. So, it does not even check CONFIG_MSG_MIN_PRIORITY. I'm not sure if it was intension, or if it is a bug, but I have changed it with the following path:

--- a/src/utils/wpa_debug.c
+++ b/src/utils/wpa_debug.c
@@ -29,7 +29,7 @@ static FILE *wpa_debug_tracing_file = NU
 #endif /* CONFIG_DEBUG_LINUX_TRACING */
 
 
-int wpa_debug_level = MSG_INFO;
+int wpa_debug_level = CONFIG_MSG_MIN_PRIORITY;
 int wpa_debug_show_keys = 0;
 int wpa_debug_timestamp = 0;

In that case wpa_printf will at least take value from CONFIG_MSG_MIN_PRIORITY and will print messages accordingly. I have set it to '1' and got A LOT OF messages, so maybe lower number makes more sense (depends on each and everyone's needs).
Another logging interface hostapd_logger is actually logging hostap based messages and it reads config from UCI wireless, eventually from /var/run/hostapd-phy0.conf. Current log_level value for current hostap is stored in hapd->conf->logger_syslog_level. So, I have patched src/ap/ieee802_11.c file for my own needs only, so that I will get all these connection not allowed messages only if log_level setting in wireless UCI is less than 2. Message will be sent as MSG_INFO, because we get already a lot of information on this error in case CONFIG_MSG_MIN_PRIORITY <= 2. This way I can control only those particular messages with UCI wireless setting. If someone is interested, patch is below (!is_probe part was taken from patch suggested in bugreport in link in post above):

--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -1606,9 +1606,15 @@ ieee802_11_allowed_address(struct hostap
 				      is_probe_req);
 
 	if (res == HOSTAPD_ACL_REJECT) {
-		wpa_printf(MSG_INFO,
+		if (!is_probe_req) {
+		    wpa_printf(MSG_INFO,
 			   "Station " MACSTR " not allowed to authenticate",
 			   MAC2STR(addr));
+		} else if (hapd->conf->logger_syslog_level < MSG_DEBUG) {
+			wpa_printf(MSG_INFO,
+			       "Station " MACSTR " not allowed to authenticate",
+				MAC2STR(addr));
+		}
 		return HOSTAPD_ACL_REJECT;
 	}

m0urs · October 10, 2018, 8:37pm

Any chance that this will be solved in 18.06.1? I just upgraded from 17.04 and now I have the same issue. I have MAC filtering enabled and I would like to leave it enabled. However the log is now quite useless as I see several log entries per second with "daemon.notice hostapd: Station xx:xx:xx:xx:xx:x not allowed to authenticate". This was not the case in 17.04 so I consider it a bug ... Thanks a lot!

Klingon · October 11, 2018, 7:14am

I running 17.01.6, to avoid hostapd messages. In 18.06.1 I didn't find a way to solve it.
In my opinion, the hostapd behaviour in 18.06.1 is not correct (about log messages and filtering enabled).

m0urs · October 11, 2018, 7:46am

Yes, I agree. The behaviour is not correct in my opinion. At least it cannot be that you can no longer use the log as you only see such messages. I disabled MAC address filtering at the moment. But I want to enable that again. And yse, I know it is not such a big security advantage, but I still want to enable it The question is: What can I do that this will be re-examined and maybe fixed?

Klingon · October 11, 2018, 9:27am

You can open a case as bug, and one day will be examined. But, honestly I don't know how to do it.

JW0914 · October 11, 2018, 10:57am

This was answered a long time ago in this thread... please take the time to do a word search for log

m0urs · October 11, 2018, 11:34am

I saw several threads, however I seem to have missed the one where a solution for this issue has been provided? I saw changes in the code done by someone (however that never got implemented in the official code). I also saw the suggestion going to rsyslog, however is this really a solution? These spamming "not allowed to authenticate" messages for MAC addresses which do not really trying to connect to my network (!) were not present in the 17.04 version. Although I saw real "not allowed to authenticate" message if e.g. I tried to connect a new device. So everything was fine in 17.04 and started to go worse in the later releases.

So if you know the solution for that, could you please give me a hint where to look for? Thanks a lot!

m0urs · October 11, 2018, 11:35am

Just forgot: I played with the different logging levels but that did not solve it for me. Or I did it wrong? What I want to achieve is the same behaviour as before, so that these "spamming" messages disappear while I still can see real message if someone is trying to connect to my network with the correct passsword but is not allowed because of the MAC filter.

JW0914 · October 11, 2018, 11:55am

Please see this post by @jeff on April 3

A word search for "log" would have shown this [#20]...

m0urs · October 11, 2018, 12:24pm

I saw that post already yesterday and I added " option log_level '3' " to both of my wifi-device configs. That did not change anything (even with log level 4!). But jeff also states below of his post that he does NOT have MAC filtering enabled. So if I disable MAC filtering then I also do not see any of these messages (which seems to be obvious ;-)) Later you answered that MAC filtering provides negligible security. Maybe, but I still want to enable it

With MAC filtering enabled I still see these messages in the log.

Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:05 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:10 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:16 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:17 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:23 2018 daemon.notice hostapd: Station ec:1f:72:11:1a:a2 not allowed to authenticate
Thu Oct 11 14:03:52 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:52 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:54 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate
Thu Oct 11 14:03:54 2018 daemon.notice hostapd: Station 34:d2:70:d1:a1:06 not allowed to authenticate

I cannot relate any of these MAC addresses to any of my devices. All my devices are correctly connected and have other MAC addresses. I did not see that until yesterday morning (where I upgraded from 17.01 to 18.06). I do not see this as an attack on my network but I also have no explanation where these message are coming from. As I said, with 17.01 I only saw these kind of messages if a new device really wanted to connect to my network but was not allowed to (I regularly saw these messages if I forgot to enable a new device before...)

In the threads the opinion is that these messages are "normal" as every device nearby m ynetwork e.g. from my neighbour might be causing such messages. In that case I am asking me why I did not see such spammy messages before? My neighbourhood has not quite changed between before an after the upgrade?

jow · October 11, 2018, 12:34pm

The reason is a faulty commit in upstream hostapd which changed the logging of this message in a way that ignores the verbosity settings in the hostapd config, or rather uses an inappropriate log level (LOG_INFO) instead of a lower priority one which would be normally filtered away.

Someone has to report it upstream to the hostapd developers so that it gets fixed there.

m0urs · October 11, 2018, 12:36pm

Ah, now we are coming closer "Someone has to report it upstream": However, I am not sure what exactly is meant by that. Anything I can/must do?

JW0914 · October 11, 2018, 12:55pm

Did you restart services / reboot router after making the change?

m0urs · October 11, 2018, 12:56pm

I restarted wifi via the web console for "4". And rebooted for "3".

JW0914 · October 11, 2018, 1:00pm

The only "fix" would then be to disable MAC filtering. MAC filtering offers minimal security, as anyone can garnish wireless MAC addresses being utilized with the proper software. Rather than providing a lengthy explanation, to understand how/why, it would probably be more beneficial to google it.

m0urs · October 11, 2018, 1:03pm

I know that ... I still want to have it As "jow" commented above it seems to be a bug with the logging of these messages (which was not there in earlier releases). So for me the correct "fix" would be to fix the hostapd logging behaviour. Unfortunately I have no understood what exactly "jow" wanted to tell me with "Someone has to report it upstream to the hostapd developers". Can I do that and how should I do that in that case? Or does anyone else need to do that? In this case who and how can I tell him?

JW0914 · October 11, 2018, 1:08pm

In other words, someone has to file a bug report with the devs of hostapd directly

m0urs · October 11, 2018, 2:11pm

If I understand it correctly, then this has already be done some months ago:

https://bugs.openwrt.org/index.php?do=details&task_id=1468&string=hostapd&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

At least it looks like our problem ...

m0urs · October 11, 2018, 2:24pm

I just sent a mail to one of the developers of "hostapd" and asked him to have a look ...

dlakelan · October 11, 2018, 3:08pm

Seriously though, if this is an important enough issue for you, and you want to get control of your logs quickly, installing and configuring a better logging daemon and setting up filters would be not that hard.

Debian uses rsyslog so that's the one I'm more familiar with. https://www.rsyslog.com/

the line

:msg, regex, "Station .* not allowed to authenticate" ~

should cause rsyslog to throw those messages away