I think your lack of knowledge in regards to the OSI Model https://en.wikipedia.org/wiki/OSI_model and how to use it to understand your issues and mitigate the problems they present is the first thing you need to address, until you do, even following steps here may not produce the results you are expecting and could even make things worse as you don't understand what going on.yes i kinda understand now and yes its wifi-based .
there are a lot of routers that you can't connect to when your MAC is changed it will always say that the wifi password is wrong even if its right.
can we use that feature in Nano station ?
it will be like the best thing to stop spoofing
MAC addresses are not encrypted on wifi. You can confirm this yourself with a tool like Kismet, eg:what you can do is prevent wifi scanners from showing your clients,s mac addresses by changing the network prefix lenghth from 24 to 32
wifi scanners scans for the ip range therefore if you prevent it from showing ip addresses mac addresses wont be listed tooMAC addresses are not encrypted on wifi. You can confirm this yourself with a tool like Kismet, eg:what you can do is prevent wifi scanners from showing your clients,s mac addresses by changing the network prefix lenghth from 24 to 32
https://lh6.googleusercontent.com/VjbpX ... m3dBEvwZ60
Check earlier in the thread where layer2 isolation on the wireless access is talked about, along with VLANs and port isolation on switches. There is also enabling WPA2 encryption on wireless assuming that you are in a situation that you can get away with that.ok why dont you provide us with a better solutions then?
I think you are confused. I linked to a screenshot of a wifi scanner by the name of "kismet", a tool I have used myself [you can also verify this easily enough, because it - amongst other, similar tools, no doubt - is free to download and use]. That screenshot shows the MAC addresses of devices connected to an encrypted wireless network.wifi scanners scans for the ip range therefore if you prevent it from showing ip addresses mac addresses wont be listed too
Scroll up.ok why dont you provide us with a better solutions then?
...which is an improvement on "other people" just taking your login without you knowing about it!Off course someone can give login information to other people.
This will not stop MAC spoofing. This is a method to enforce the use of DHCP on the LAN, and disabling default forward blocks the clients from direct east-west communication at layer 2, but doesn't do anything to prevent MAC spoofing.Why you don't think to use dhcp-server with adding arp for static leases without arp requests from clients? If its wi-fi, disable default forwarding.
You're right. What would you do?This will not stop MAC spoofing. This is a method to enforce the use of DHCP on the LAN, and disabling default forward blocks the clients from direct east-west communication at layer 2, but doesn't do anything to prevent MAC spoofing.Why you don't think to use dhcp-server with adding arp for static leases without arp requests from clients? If its wi-fi, disable default forwarding.
How about segment the network in few small int different interfaces and filter hosts in terminating points by src-mac?scroll up..... and see that I would go with WPA2-Enterprise
i.e. AAA-backed per-user authentication
That STILL doesn't stop the endpoint's ability to spoof MAC addresses but at least you can disable the account of anyone caught doing it and that device won't be able to join the network.
At the end of the day, there's nothing you can do to prevent a device from spoofing its MAC. If it chooses to lie, then it's going to tell lies. The only thing you can do is limit the ability to attach to your network.
Okay - so I'll take my laptop there, unplug the expected device, note its MAC address (which I can ultimately learn by plugging my laptop directly into the "mac-verified" device's ethernet card and using wireshark to sniff the packets it sends, noting the SRC MAC) and then set my laptop to spoof that MAC and plug into the network in the same spot.How about segment the network in few small int different interfaces and filter hosts in terminating points by src-mac?
How you sniff the traffic of other devices if they are in another broadcast domain? Your network ends on terminating interface.Okay - so I'll take my laptop there, unplug the expected device, note its MAC address (which I can ultimately learn by plugging my laptop directly into the "mac-verified" device's ethernet card and using wireshark to sniff the packets it sends, noting the SRC MAC) and then set my laptop to spoof that MAC and plug into the network in the same spot.How about segment the network in few small int different interfaces and filter hosts in terminating points by src-mac?
What then?
I go to the other device physically - pull its cable out and sniff it from a direct connection to the device. Then I connect into its port and go online with that MAC from its port.How you sniff the traffic of other devices if they are in another broadcast domain? Your network ends on terminating interface.
The point is isolate the clients from each other any way. Segmentation in subnets is solution.I go to the other device physically - pull its cable out and sniff it from a direct connection to the device. Then I connect into its port and go online with that MAC from its port.How you sniff the traffic of other devices if they are in another broadcast domain? Your network ends on terminating interface.
The point is that even east/west isolation doesn't stop the ability to spoof MAC addresses, if that's your goal.
MAC-based security is broken, which was the original point of this thread.
I'm not saying client isolation is bad. I'm just saying that doesn't help in the OP's problem.The point is isolate the clients from each other any way. Segmentation in subnets is solution.