Advice needed about Wifi Security

Hi,

Today, checking my AP Log files (running OpenWrt), I noticed someone is trying to connect to my Wifi by brute force. Something (a PC I think), changes the MAC address every 3/4 minutes and tries to connect again and again.

Log File:

Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:19 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:20 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:20 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:23 2018 daemon.notice hostapd: Station da:a1:19:b1:ed:34 not allowed to authenticate
Tue Apr  3 15:52:23 2018 daemon.notice hostapd: Station da:a1:19:b1:ed:34 not allowed to authenticate
Tue Apr  3 15:52:23 2018 daemon.notice hostapd: Station da:a1:19:b1:ed:34 not allowed to authenticate
Tue Apr  3 15:52:23 2018 daemon.notice hostapd: Station da:a1:19:b1:ed:34 not allowed to authenticate
Tue Apr  3 15:52:24 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:24 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:30 2018 daemon.notice hostapd: Station b4:9d:0b:86:b9:83 not allowed to authenticate
Tue Apr  3 15:52:31 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:31 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:32 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:34 2018 daemon.notice hostapd: Station f0:ee:10:dc:db:26 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:36 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:37 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:37 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:37 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:37 2018 daemon.notice hostapd: Station 1c:b7:2c:5a:c3:05 not allowed to authenticate
Tue Apr  3 15:52:39 2018 daemon.notice hostapd: Station 00:26:ab:d0:44:27 not allowed to authenticate
Tue Apr  3 15:52:39 2018 daemon.notice hostapd: Station 00:26:ab:d0:44:27 not allowed to authenticate
Tue Apr  3 15:52:39 2018 daemon.notice hostapd: Station 00:26:ab:d0:44:27 not allowed to authenticate
Tue Apr  3 15:52:44 2018 daemon.notice hostapd: Station da:a1:19:51:48:92 not allowed to authenticate
Tue Apr  3 15:52:44 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate
Tue Apr  3 15:52:52 2018 daemon.notice hostapd: Station 2c:0e:3d:e0:1e:4e not allowed to authenticate
Tue Apr  3 15:52:52 2018 daemon.notice hostapd: Station 2c:0e:3d:e0:1e:4e not allowed to authenticate
Tue Apr  3 15:52:56 2018 daemon.notice hostapd: Station 00:a0:96:86:33:e7 not allowed to authenticate

My Wifi is MAC address protected (only allowed to connect some listed MACs) + WPA2 PSK Encryption.
Can I do something else to get a better security againts these attacks?

Thanks for any idea/advice about!!!

As background, I consider any wireless client as potentially hostile and, for a home user, choosing a strong password and limiting the permitted MAC addresses is probably the best you can reasonably do to prevent unauthorized connections. One could configure 802.11X authentication, but that is beyond what most would consider "reasonable" configuration and should be done on a host other than the OpenWRT router.

Next, I don't think it's an "attack", per se. Let's look at "who" is trying to connect. The first three pairs of digits in the MAC are a vendor code. Sometimes this can provide insight, though if it returns "Foxconn" or another component or board manufacturer, it may not be terribly helpful. https://www.wireshark.org/tools/oui-lookup.html is one place you can look them up. I'm guessing you live in a city, yes?

00:26:AB SeikoEps	Seiko Epson Corporation
00:A0:96 MitsumiE	Mitsumi Electric Co.,Ltd.
1C:B7:2C AsustekC	ASUSTek COMPUTER INC.
2C:0E:3D SamsungE	SAMSUNG ELECTRO-MECHANICS(THAILAND)
B4:9D:0B Bq
DA:A1:19 Google	    Google, Inc.
F0:EE:10 SamsungE	Samsung Electronics Co.,Ltd

Yep. probably a printer or two and a couple of phones.

The only challenge to this is that the entries clog the logs. If you're up for some configuration and have enough space either on your overlay, or are willing to build a custom ROM, you can install syslog-ng and logrotate to filter the "noise" from your logs into a different file, so that you can see if there is something "important" that is happening.

1 Like

While MAC Allow will provide obfuscation from most neighbors, the security it provides is negligible since any radio's local [MAC] address can be easily seen with the proper equipment while the radio is transmitting. That being said, there's no reason to not utilize MAC Allow.

Provided you're using a complex WiFi password, WPA2-PSK, and Force CCMP (AES) only, your WiFi is secure from any brute force attack.

3 Likes

If this is a recent master image containing commit eba3b028, it seems to have introduced a level of verbosity that I have not been able to quiesce.

Hi @jeff,

Many thanks for your answer. But a I really thing is a computer attack, I have many other MACs like 0a:0b:af:51:db:97 which is an unknown provider. Something is generating MACs randomly to attack my AP.

And yes!!! I live in a city!!! :frowning_face::frowning_face::frowning_face:

As stated above, provided you have the aforementioned configuration, there's no reason to be concerned.

  • You can configure iptables rules in /etc/firewall.user to auto block non-permitted MACs that attempt to connect, however this is ultimately pointless since MACs can be changed in a few seconds and will only serve to consume CPU resources.

If you haven't already, the link I provided regarding a complex password is worth the read, as more often than not, many utilize insecure passwords.

Unless you're willing to move, I think what you're seeing is just people nearby, walking by, driving by, what have you. Part of the 802.11 protocols includes potential clients sending out broadcast probes to find out what stations are out there. When an AP receives one, it returns an "I'm here" message. This is normal and an important part of the protocol, not one to be completely shut off.

Looking at the hostap code, the message comes from ieee802_11_allowed_address() in ./src/ap/ieee802_11.c which is called by handle_probe_req() in ./src/ap/beacon.c so it appears that what you're seeing is the AP "being quiet" when it gets a probe request from a disallowed MAC address.

1 Like

Today I have updated to the latest OpenWrt snapshot version.

Maybe that's the point, now is showing an info that wasn't shown before updating!!!! and nobody is attacking me? Do you think it could be?

Yes, I think it is just a regression that is spamming the log; i.e. it has always been there, just not logged. I looked at it briefly when the change was pushed, I think the /tmp/sun/hostapd-phy0.conf(whatever) may be incorrect(changed).

That's a patch added a few days before:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=eba3b028e46dbfe54f1208e9edf47bb0c6f73ac8

Right, what I linked above.

1 Like

Can be considered as a bug? Or just is showing more info (not a bug).

imo, an issue that needs to be addressed; assuming it truly cannot to turned down by log level settings.

Thanks @anomeome @jeff @JW0914 for your help!!!!

        if (res == HOSTAPD_ACL_REJECT) {
                wpa_printf(MSG_INFO,
                           "Station " MACSTR " not allowed to authenticate",
                           MAC2STR(addr));
                return HOSTAPD_ACL_REJECT;
        }

Can certainly be handled by syslog-ng or another logging system that can filter messages. A priority of "info" is the next one higher than "debug", so seems appropriate to me.

Edit: It may be possible to change the default logger to only show "notice" and higher, but I haven't found coherent documentation on how to do so. That assumes that there is nothing at "info" level of interest from other loggers.

Right, but it no longer seems to honour settings in /etc/config/wireless, at least not as it once did. And this:

hostapd-phy0.conf:logger_syslog=127

is not in agreement with the wiki, I have not gone back to check when it changed though.

I just did a quick check here, with a recent master build. With https://openwrt.org/docs/guide-user/network/wifi/basic as guidance, I added option log_level '3' to the wifi-device stanza. I'm not seeing "info" messages anymore (though I'm in a pretty quiet environment). I see the UCI config reflected in

/var/run/hostapd-phy1.conf:

logger_syslog=127
logger_syslog_level=3
logger_stdout=127
logger_stdout_level=3

Do you have a:

    option macfilter 'allow'
    list maclist 'xx:xx:xx:xx:xx:xx'

in stanza as well. I think this may be the trigger, but not sure. I have the log_level setting, always have actually.

Yes, I'm using it.

@anomeome No, I don't have MAC filtering turned on.