DHCP Option 82


#1

Ok, I am exploring DHCP Option 82 as an additional security measure on our network.

We have strictly static assigned IP addresses in sonar. No automatic assignment at all.

Mikrotik is setup as static-only DHCP with sonar doing the usual, writing each customers address manually.

The idea we’re looking at is to authorize requests based on which CPE they’re linking through (sort of verifying client location as well as their device MAC). So in the case of someone at a different location spoofing the MAC of a legit customer, it would deny the request as the two variables (CPE and CLIENT MAC) don’t match.

Does this type of setup still work with the batcher and the subsequent DHCP Option 82?


#2

I’m not sure I follow exactly - the intent of option 82 is so that you authorize the user based on the MAC of the radio, or ISP controlled router, etc, so it doesn’t matter what MAC they are using behind it. The client would never be able to spoof a MAC in any useful way, because you’d exclusively look at the MAC of the ISP controlled CPE.


#3

Yes, and this works fine when you have a 1:1 cpe to client, but we have several sites that are not that way.

Sometimes one radio will feed 3-4 suites or units. So the thought is to retain the normal assignment based on the client MAC, but further legitimize on where the request is coming from by matching a remote ID as well.

This way if someone attempts to spoof a MAC to connect to the network at a different location, it’ll fail as the remote ID doesn’t match.

I effectively want to limit a certain mac to only appear through a certain port.


#4

I’m not sure of a good way to do that - I think it’d have to be some kind of custom solution.


#5

Yeah, it looks like Mikrotik doesn’t have an easy way to do this either and it’s been a popular request for more than a year. Cisco and Juniper both have DHCP Option 82 features that allow for this kind of behavior down to the individual switch port MACs (circuit ID’s). Adds a bit of network hardening by locking in a specific path of a requesting MAC and when it doesn’t match, it doesn’t respond.

We’re not having any issues that this would directly address at the moment, I’m just exploring ways of further hardening our bridged networks from known common attack methods.

It would be nice, and maybe fairly simple, to have sonar do what I’m trying to do, leveraging your batcher tool. i.e. If a DHCP request is sent to sonar and the account is statically assigned, match the client mac to the assignment, the agent remote id to the inventory item and then write the lease to the Mikrotik. If either data point fails to match then drop the request.

Elaborating on an idea in the future: I could then hypothetically tie our network controller to a sonar API/webhook to monitor for failed DHCP matches (wrong paths), identify the offending source port on our network via the agent MAC value, then have our controller turn off/block that specific switch port of all traffic and notify the admin team of the occurrence.

This would effectively shutdown a snooper/hacker automatically network wide without much effort and give us visibility into the exact location of malicious behavior to go look into.


#6

The batcher works by receiving leases that have already been assigned in MikroTik and then adding them to Sonar as soft assignments, so I’m not sure technically how it’d work to do what you’re trying to do with the batcher. I think you’d need some other intermediate step to validate the two separate pieces. Typically, you wouldn’t add customer equipment as inventory to Sonar, so I’m not sure where that particular MAC check would come from. Maybe it’d work better as a RADIUS attribute.