How to deal with a printer DoSing my WiFi? [Solved]


#1

Hi,

I am using an TP-Link Archer C7 v2 running OpenWrt 18.06.1 r7258-5eb055306f.
I have set up a wireless network on the 802.11bgn (2.4GHz) radio with WPA2 PSK encryption and a MAC address whitelist. This setup has worked well for a few months without any issues.

Two weeks ago I started having occasional problems with connecting my devices to my WiFi network. After looking around I found that there is a Canon printer somewhere running what essentially is a DoS against my WiFi. It is continuously (24/7) sending multiple authentication requests per second to my WiFi. Of course none of them is allowed since the device is not whitelisted, but it results in my WiFi becoming unusable after a few days of the attack. Now I need to restart my router every few days just to keep the WiFi operational. My system log looks essentially like this:

Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:20 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate
Thu Jan 31 07:34:21 2019 daemon.notice hostapd: Station (MAC_ADDR) not allowed to authenticate

I assume this is a printer because looking up the MAC address online pointed to Canon being the manufacturer.

I tried reducing the radio power to the minimum usable within my apartment, but that did not stop the attacks, so the printer must be close (probably still around 50 potential apartments).
I tried turning the WiFi off for a few hours, but the attack resumes immediately after I bring it back online.
I tried setting up an open WiFi with a different router to lure the printer into that network, but it did not work either.
I tried changing the SSID of my network but the attack resumes almost instantly on the new name.
I cannot hide my SSID because then some of my own devices will not be able to connect to the network.

How can I deal with that?
Has anyone encountered something like this before?

Thanks


Hidden SSID in combination with mac filter
Global Printer on a network of multiple VLANS
[SOLVED] Guest Wifi has no internet access
#2

#3

Thanks for the link!
That discussion does not help me solve my problem though. I am not worried about the security of my WiFi (I have a strong random password and the MAC filter and I do not expect a targeted professional attack on me) nor about the logs being useless and spammed with the message.

My main concern is the fact that since this started I need to restart my router every few days otherwise my WiFi becomes unusable. The router is not running out of memory (at least the Web UI says there's plenty free) but after a few days of these constant connection attempts WiFi stops allowing my own whitelisted devices into the network until I reboot it.


#4

Either wait OpenWrt 18.06.2 release, or use snapshot.


#5

I may be misunderstanding, but what I got from that thread is that 18.06.2 will fix the log spamming issue. How does that help with my WiFi not accepting my own whitelisted devices? Did I miss something?


#6

It is a side effect of your whitelist, no one is trying to spam/DoS you.

you could probably try and whitelist it even and see what happens.


#7

Or remove the MAC filter completely. It is useless anyway. You have strong encryption as you say, so whoever has the key will be able to connect. If some malicious player has acquired your key, the MAC filter won't stop him from gaining access.


#8

I added the printer MAC address to my whitelist, but to be on the safe side I also added firewall rules to drop all packets coming from that MAC address. I'll post an update in a few days if the problem with connecting my own devices goes away.

I would prefer to keep the whitelist if possible. It won't stop someone who knows what they are doing from getting in - but it does stop malicious lightbulbs, printers, DVRs and other bot network-controlled devices that do not have easily accessible packet sniffing capabilities. Every little bit helps. :slight_smile:

Thanks for your help!


#9

What stops them is the strong random password. It's like you have a strong deadbolt on your door and also a little piece of tape people have to peel off before they can insert a key... The tape doesn't actually do anything.


#10

If no packet sniffer (which is Layer 3 anyways), it stops them from what exactly?

In theory, it's probably easier to DDoS your router; because a malicious actor can cause your MAC checker to over-utilize the system's resources...especially if your fear is:

  • untrusted IoT devices,
  • not under your control
  • within range of your router
  • without the password
  • (and assume they can attack the AP)

So, it depends on what you truly believe you're securing yourself from.

:wink:


#11

I am obviously not an expert, but I feel that metaphor is stretching it a bit. I wouldn't call a MAC address whitelist something anyone can "peel off". I'd compare it rather to a cheap fingerprint scanner. Sure, you can cheat it by using a bit of tape with a copied fingerprint, but you need to get a copy of a valid fingerprint first. Requires you to know what you're doing and a bit more work.

I would assume it should stop them from brute forcing the password and DoSing the router through constant authentication load.
Using my immediate example of the printer in question - it spammed 5-10 logs per second, 24/7. That gives 13-26 million authentication attempts per month. And the printer is a pretty persistent attacker, rarely moves away or is turned off. Even with a strong random password this feels like a lot of attempts and I would rather prevent it from having those attempts at all, since I am too lazy to regularly change the password.
I would also assume that there is a big benefit of dropping known-bad traffic as soon as possible, which would be the MAC address whitelist. It should be cheaper to drop it there than to let it constantly try to authenticate. Why would it be more expensive to check if a MAC address is on a 4-element list than to authenticate it?


#12

You mean that thing that every time a packet is transmitted is out in the clear? So kinda more like a key-pad with the password written on a sticky note pasted above?

Or just install some android google play store app that's actually a trojan horse and automates attempts to crack. MAC whitelists literally offer zero security.


#13

If its being that much of a nuisanace, make a guest wifi access point (honeypot) and then log/tcpdump everything it does until it gets in.

Once youve identified the model/device, name and shame canon on social media .


#14

Is that something automated botnets / trojans are known to be doing? Actually sniffing MAC addresses from surrounding networks? I'm not talking about a person targeting my network specifically.

I tried that, didn't work. The printer did not actually connect to an open WiFi. It is possible that it probed it as well, but that was just a cheapest router I could get, so it didn't show any details about that. But no IP address was obtained.


#15

It might feel like it, but if you have an 8 character random password that's say 2^56 options to try (assuming 7 bits usable character). In a month it can try about 2^24 leaving it with about 4 billion months to try everything.


#16

I'd be shocked if they weren't but I don't actually have a reference.

Also I'd be shocked if anyone bothered to try brute forcing random keys (because they know it's never going to work), much much much much more likely they're trying some table of 1 million or so common passwords, that sort of thing has literally zero chance of getting into your 8 character random password.

This however is a good point. Even better would probably be to have a rate-limit so that any MAC trying to authenticate more than say 2 times a second for 10 seconds gets dropped. Does anyone know if there is a rate-limit option in hostapd?

The whitelist might actually be better than the rate-limit as the rate-limit requires keeping track of all the MACs you've seen, so if an attacker can try multiple MACs it could fill up memory or whatever.

Since you've whitelisted the attacker device have you had problems? Perhaps even though it logically seems better to have a whitelist in terms of reducing load, the whitelist code is buggy or inefficient (not designed to prevent DoS), or the logging itself is buggy, and so you should disable it to get more stability.


#17

I have not had any problems yet, but it is too early to say for sure, since it usually takes a few days for the problems to show up. The average load reported has gone down though, from ~1.5 to ~1.0, so having the bad device whitelisted does reduce the load on the router, which is counter intuitive. It might be that all the logging caused a lot of unnecessary work. I will update this thread when I know if the problems persist.


#18

That's exactly right. The logging itself is probably nowhere near as efficient as checking a WPA password. Does it in fact even try passwords? I'm not sure how you'd figure that out. There might be some logging you could enable briefly specifically for that purpose.


#19

Have you upgraded to 18.06.2 to see if the excessive logging issue has been fixed.


#20

No, I have not upgraded yet. I am currently testing if whitelisting the bad device removes the problem with my own devices not being able to connect. If it doesn't help, I will upgrade in a few days.