enforce Static Lease.
Even when using Static Lease clients can use any IP they want.
https://www.makeuseof.com/what-is-mac-binding-how-does-it-work/
You appear to be a person of few words…
I guess you mean "thread" instead of "threat"...
Whoever wrote that article does not know what they are talking about... period. Assigning a static IP address on the DHCP server, does not prevent any device from using any IP address; there is not even the need to spoof the MAC address. You do not even need a DHCP server or a router to have a functioning network.
This could only work on wireless networks, where you can block/allow access by MAC address; but you cannot prevent MAC spoofing. If you need real network security, use IEEE 802.1X.
That is why a feature to limit a IP to a MAC
This could only work on wireless networks, where you can block/allow access by MAC address;
Why?
but you cannot prevent MAC spoofing. If you need real network security,
It is still something
Is it like Captive Portal ?
Other OS have IP MAC binding
Also See
You can have static ARP entries with Linux too using ip neighbor
.
And no. 802.1x is not used for/to be a captive portal...
I assumed (probably my mistake) that @RSHARM wants to prevent unauthorized devices from connecting to any other device in the network. If they only want to block traffic from rogue devices to the router, then your idea would be a good solution.
I agree with @eduperez - the author of that thread merely describes how to:
- configure the DHCP server to only offer known MACs a leases with a pre-set IP
- configure the DHCP server not to issue other leases
This will not prevent:
- A client setting any IP within the CIDR range locally; nor
- Prevent clients form "using any IP they want"
Another option is this Firewall example preventing Internet usage:
config rule
option target 'DROP'
option src 'lan'
option dest '*'
option family 'ipv4'
option name 'test_block_not_MAC'
list proto 'all'
list src_ip '!192.168.1.xxx'
list src_mac 'xx:xx:xx:xx:xx:xx'
DHCP doesn't enforce IP. I asking any way to bind IP-MAC.
You linked to an article that states that DHCP does enforce IP to MAC binding; we responded that the article is bogus, and both @_bernd and @lleachii suggested methods to filter rogue traffic that reaches the router. If you want to control all the traffic in your network, you need IEEE 802.1X.
ip neighbor
!
ip neighbor add ${IP} lladdr ${MAC} dev ${DEV} nud permanent
BUT, this will not prevent any sniffing on the link, and it does not prevent the usage of any mac address, it will simply "bind" an IP addr to an MAC addr. (And this introduces a rotten can of worms. Trust me/us.)
If you want / If you think you will need other forms of "protection": Go ahead, buy Cisco gear and drink the ASA Cool Aid.
If you want to secure your network, read up on 802.1x how it can help you to secure your local network.
802.1x is more or less the standard to secure a network against unknown/untrusted user and devices.
In Europe, almost every University uses 802.1x on Eduroam for authentication and accounting. (One user account from your home university and you get network access on all the other universities.) And most of bigger enterprises (I have seen) uses it, too, on their office networks...
If you can not trust who connects to your network, then use 802.1x and dynamic VLANs (private tunnel group id), and everyone else will get put either in a "wan only"/guest network, or will get no access to any resource on the network at all.
Edit: PS: And, like @lleachii suggests, allow only traffic from known mac addresses, but still, this would not solve every issue... If you want to ensure who is allowed to connect: Use 802.1x.
In theory, you could create an ipset in firewall4 with src_ip and src_mac, and load a list of allowed IPv4 and MAC combinations. Then make a custom rule to drop IPv4 traffic that isn’t in the set.
I’m not sure this would really work (only on my first cup of coffee this morning), but it’s an idea to be considered and maybe proven wrong.
And introduces new ones, like manually maintaining the list of all MAC addresses, some of which change at arbitrary intervals due to MAC randomization (I have a couple of Android devices that do this when they feel the urge; iOS also does this).
Yes that's the default. But this can be set on a per ssid basis. On trusted networks I have chosen to use the actual hardware address...
Sounds good to me, that’s how we do it.
Most of the code is setting up the mac:ip pairs and putting them into ipsets. We allow anything that wasn’t explicitly listed in the pairs through but you could invert that rule or just add a drop/reject.
I’m not big on nftables syntax but the same thing must be achievable.
It's pretty straight forward ... nft allows you to put two or more selectors together to perform very fast lookups in sets, e.g.
add set inet banIP test { type ether_addr . ipv4_addr; flags interval; auto-merge; }
add rule inet banIP lan-forward ether saddr . ip saddr @test counter reject