I set up an open wifi hotspot for a community organization not too long ago and today I noticed the dhcp pool was depleted. I looked through the leases and almost all of them were assigned to devices with mac addresses starting with 00:16:A4 and hostnames starting with UA105.

A mac address lookup points to ezurio ltd which was aquired by Laird http://www.lairdtech.com/NewsItem.aspx?id=1012

It almost seems like a bot with the sole intention of depleting the ip pool. There can't be the sheer amount of separate devices that are showing up in the ip pool. It's like the device is changing it's mac and it's hostname and then reconnecting.

Hopefully someone can shed some light on the matter. I attached a pic

This is an old joke....

Assuming you don't want to secure the connection you could change the expiration time to 6 Hours and increase the pool size by a factor of 10. By the looks of it that would solve your issue.




Just a thought...
I wonder how it would handle you switching to a 10.0.0.0/8 and then putting in 8 /16 pools to hand out...... One spilling into the other... I wonder how long it would take to fill it.

Ok I must have not gotten the joke. What is actually happening here? All I can find google wise is possibly a netgear router gone to hell?


Any thoughts?

I don't get the joke?

DHCP Exhaustion Attack is a pretty old type of DoS.
As with all kinds of DoS some people do that just for fun (which I assume is meant by "joke" here).

we have this happening on two of our segments. Same UA names coming in through dhcp with 00:16:a4 MACS. Its hard for me to swallow that we have malicious people hitting me on this. Im sure its an easy DoS attack but a bad router / firmware is where my logic keeps coming back to.

What is the suggested mitigation step with this problem regardless of cause?

There is not much you can do in a hotspot scenario (with known users you can always lock down on MACs)

* Increase DHCP pool -> Attack will take longer and fill up more memory
* Decrease lease time (In a public hotspot I'd say you can go as low as 1h)
* "DHCP Greylisting": Use the authoritative after delay setting to slow down the attack
* For wired networks use MAC limiting
* In this case use bridge filter to block the vendor OUI

It's DHCdrop or similar attack. We use DLink port_security for max mac-address learning from port.

I found this post after I noticed Ezurio ltd mac addresses filling up our probe logs too. It sent about 500 different MACs over a few hours.

I'm not sure if it's a (weak) deliberate attack, or a vendor being too cute with MAC tracking obfuscation.

This thread is one of the only meaingful hits that comes in google when searching for the "00:16:a4" mac address prefix.
So I registered just to post another data point.

I recently turned on guest access ala openwireless.org and started seeing these same accesses. In fact, they are the only "guest" users I've had in less than a week of providing open wifi. Geographically, I am in the chattanooga area. I'm in a low-density part of the suburbs but I do have line-of-sight to an industrial area (I am on top of a hill) and am directly off a small arterial road.

My guess is that these are coming from sort of mobile/automative source. But that's just a gut feeling.
If I get more of them, I might run a packet sniffer to see who, if anyone, they are communicating with.
If I do that, I'll come back and make another post with the results.

Question for you, is this site anywhere close to a railway line?

Well, they kept on coming so I turned on a packet sniffer and saw one connect to:

https://65.169.144.36/

The DNS wouldn't do reverse resolution on that IP address for me.
But the SSL certificate on that server identifies it as Qualcomm Omnitracs for mcp200-ssl.omnitracs.com.
Connecting to it gets me to a Cisco VPN login page.

Google says Omnitracs is a fleet management company that qualcomm spun off. So it looks like my guess was right - these are on vehicles, probably delivery trucks.

To answer chmcwill's question: I am about a mile from the nearest railway but I do have line-of-sight to it.

I saw the same flood of 00:16:a4:..... MAC addressed clients when I removed the "click through" splash page from an RV resort's WiFi for some testing. Its near a freeway so I would say from the other responses in this thread that the clients are from semi-trucks with an Omnitracs systems that are set to connect with any available open WiFi. There is also a train track a bit further away but by the random timing of the entries it looks like freeway traffic to me.

One nice thing about the Meraki setup here is that the open SSID is using DHCP leases placing them on a 10.0.0.0/8 network isolated from the local LAN so the local DHCP pool does not become depleted. The 10.0.0.0/8 IP address is Meraki generated.

I ran into this problem a few years ago. Back then I added a bridge filter rule with a MAC address mask to prevent my DHCP pool from filling up. Today I saw my bridge filter rule and forgot my reason behind it. A quick Google search brought me to this thread and I remembered. I figured I'd share my filter rule for others who are looking for a solution on Mikrotik hardware. Note: I chose to block all traffic from these devices because I couldn't find a legitimate case where this OUI would be assigned to consumer hardware.