Advice needed about Wifi Security

I'm not going to take the time to read every post, so some of this has probably already been covered.

The 'Bad guys' that know what they are doing are probably not going to 'bruit force' a wifi account, and what I mean by bruit force is password guessing. Unless they know the user uses weak passwords they won't waste time. Wifi's weakness is in the key and hash exchange during authentication. If the 'bad guy' can force a re-authentication of clients and steal the hash, then they will begin using rainbow tables to match 2 hashes. << Much faster than password guessing.

CCMP-AES Encryption < No publicly known weakness. Recommended.
WPA2 < There are weaknesses here and are commonly attacked. Recommended over WPA or earlier.
PSK < recommended password length is equal to or greater than 20. Recommended against APT's!
MAC Filtering < Recommended. Always take a layered approach to security. Though this hurdle can be passed, it does add difficulty. Recommended

About password length.. People have rainbow tables Terabytes in size of pre-compted password hashes of all possible combinations but limited length. Though shorter passwords are probably going to be safe, it isn't likely going to stop a APT. As state sponsored hacking continues to grow, many of these APT techniques are filtered down over time. I recommend staying ahead of the curve and just making it 20 characters or more. Make your password an "out of the blue" phrase you can remember, and then sprinkle in a Upper Case or special Character.

I'd still consider all 802.11 wireless as insecure. That doesn't mean not to ignore security, on the contrary, do all that you reasonably improve it by good choices and practices. It not only means that you may have someone on your wireless network that is "unexpected" and potentially hostile, but also that you should not trust 802.11 encryption for anything of value.

While CCMP / AES "forced" encryption is the recommended choice for most security-aware home use, it might be better to state

(Strike-out mine)

There are plenty of vulnerabilities and weaknesses that have been known for years or decades. Some have been patched, some not. Of some patched, who knows on a specific device, client or AP.

That way we aren't potentially suggesting to someone that wireless is "secure" , or even as secure as PCI-compliance requires, or TLS with forward-secrecy

I've been trying to disable hostapd log, but I can't find the way to do it.
I tried: https://stackoverflow.com/questions/32205140/hostapd-debug-level-configuration but it doesn't matter what I change, the result it's always the same.

Please, could somebody teach me how to do it?

Thanks,

I've got similar issue but it seems that this is because of my WiFi configuration. My both 802.11 AC and N wifi networks have a similar name, and MAC address filter is enabled for both networks, so AC clients can connect only to the AC wifi network and the same for the N clients. Though strangely I have had this configuration for years but never seen these messages before. I can see my clients trying to connect to the opposite network and also I can see a lot of unknown MAC addresses trying to connect to my networks.

Because of hostapd update.

Hi. Sorry for bringing up old topic, but did anyone found a solution to over-spaming log problem? I get these annoying messages even at log level 2. Log looks ugly and big. I'd like to never receive only those particular daemon.notice hostapd: Station xx:xx:xx:xx:xx:xx not allowed to authenticate messages.

Do you have MAC blacklisting turned on?

Yes I have.

option macfilter 'allow'
list maclist 'xxxxx'

Under each wi-fi device, add option log_level '3'

I still get these messages even at option log_level '4'. What I did was a small patch to hostapd in src/ap/ieee802_11.c and then the messages are gone, but of course this is not the best way to solve it as I need to create patches each time there is update to hostapd application.
If it works in your case with option log_level '3' then please let me know version of hostapd you are using.

There's double logging of the decline to respond to MAC addresses from what I found, one at a low level, another at a higher level. Raising the logging-level threshold through UCI, if it worked, would also remove other "important" messages. I haven't been successful in using UCI to raise the threshold.

https://bugs.openwrt.org/index.php?do=details&task_id=1468

I put a quick dirty patch up there that another user confirmed resolved the issue for them (after changing a derp of mine).

That patch isn't "real" in that it would cause loss of functionality for others that may need that logging and should have a run-time switch to enable or disable.

Since this patch keeps circulating around here... did anyone submit it upstream yet?

For general: In situation where it seems that there are some people with knowledge attacking the network and in general to have higher security, its highly recommended to use 802.11w. Then people cant just block you out of your network sending deauthentication packets and so on.

@jeff
This is the issue I also have with log_level. It looks like other log levels than 2 are accepted, but it does not seem that wpa_printf function with MSG_DEBUG (from file src/ap/ieee802_11.c) is outputing anything to syslog during run with log_level '1'. I have patched ieee802_11.c, so that connection refused error is printed only at MSG_DEBUG level, but in that case I do not receive any messages in syslog regardless of log_level setting.

OpenWRT patches the source so that the debug-level calls are optimized out by the compiler to significantly reduce the size of the binary. There is a CONFIG parameter that allows setting the cutoff level. It was not an obvious name, and the hostap applications define their own "unique" logging levels that are not the same as syslog.

Ah, there it is

-CONFIG_WPA_MSG_MIN_PRIORITY=3
+CONFIG_WPA_MSG_MIN_PRIORITY=2

Thanks @jeff. I didn't know that option. So I have changed this option to CONFIG_WPA_MSG_MIN_PRIORITY=1 so that I can output messages in MSG_DEBUG. Recompiled LEDE and tested. I still have problems. I can now control log level from UCI, but for some reason only debug messages sent by function hostapd_logger appears in syslog. If message is send by wpa_printf function, then it appears only if it was sent with MSG_INFO parameter. If I change it to MSG_DEBUG, then message is not appearing in syslog, even though that hostapd is started with -s flag (output messages to syslog instead of stdout). So I do not really understand why behavior is like this. Continue testing, but any idea is welcome :slight_smile:

I poked at the "default" logger for a while with similar puzzlement. For that and other unrelated reasons, I moved to syslog-ng and logrotate. Here's a snippet from my syslog-ng config, if you decide to go that way.

destination messages {
	file("/var/log/messages" template("$FULLDATE $HOST $PRIORITY $PROGRAM: $MSG\n"));
};

destination wireless {
	file("/var/log/wireless" template("$FULLDATE $HOST $PRIORITY $PROGRAM: $MSG\n"));
};

filter f_wireless { program("hostapd") or program("wpa_supplicant"); };
filter f_messages { level(warning..emerg) or not filter(f_wireless); };

log {
	source(src);
	source(net);
        source(kernel);
	filter(f_messages);
	destination(messages);
};

log {
	source(src);
	source(net);
        source(kernel);
	filter(f_wireless);
	destination(wireless);
};

I'm using ulogd and logrotate. Not sure if I can configure it as you have done with syslog-ng. Will spend some time tomorrow again trying to figure out with this wpa_printf.

1 Like

If it helps at all, when I dug into it, I found in src/utils/wpa_debug.c

static int syslog_priority(int level)
{
        switch (level) {
        case MSG_MSGDUMP:
        case MSG_DEBUG:
                return LOG_DEBUG;
        case MSG_INFO:
                return LOG_NOTICE;
        case MSG_WARNING:
                return LOG_WARNING;
        case MSG_ERROR:
                return LOG_ERR;
        }
        return LOG_INFO;
}
1 Like

Yes, I was it in https://bugs.openwrt.org/index.php?do=details&task_id=1468, but it does not give any extra details. While reading forums, I found this one - Patched package hostapd doesn't log as expected where you have also replied. To me it makes sense that wpa_printf with too low log level gets removed during compilation as suggested by @hnyman. I think stock logger works ok, as it still prints debug messages sent by hostapd_logger function, but it just do not print debug messages sent by wpa_printf. I'll check later today regarding compilation of hostapd and will get back. Worst case I think wpa_printf can be replaced with hostapd_logger where it is needed.