Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I cannot understand how a hacker could not get the mac associated to an ip of a victim computer.
Did I understand ? i don't think so but here lays what I understood:
- An attacker breaks the victim computer/network. So is he able to get the victims ip and mac.
- The same attacker send an arp on the server which has, fortunately, a poor switch that dumbly accepts all the arp and sends them back to who desires.
How can the DAI technology know that this hacker is the wrong people. It is said to save the ip and the mac address. Spoof the two and then what ?
The attacker becomes legitimate.
I may have forgotten a point. It is not possible that it behaves like that.
When the switch receives an ARP packet on untrusted port, it compares the IP-to-MAC address binding with entries from DHCP Snooping database or ARP access-lists. If there is no match, the ARP packet is dropped. Note that implementing DAI may break some services, such as Proxy ARP. To resolve these issues, ARP inspection allows you to configure some ports as trusted, as all ARP messages from trusted ports bypass the ARP inspection engine. Most of the times, access switch uplinks towards the network distribution or core are configured as trusted.
If I am reading this correctly, it uses a whitelist table to decide if the device is to be trusted. It also looks like it works with DHCP to monitor the mac:ip bindings, It also makes some assumptions such as assuming that switch ports going towards the network are trusted, but these may be configured.
Lets take an example. Your an intruder. You don't know what MAC addresses are associated with the access point. You, as the intruder, send an ARP request (broadcast) on a port that has been designated as untrusted. Unless you have already spoofed to a MAC known to the device, the packet gets dropped. The conventional approach with ARP is to simply hand out an IP address to the request, this is not the case with DAI. The request must either come from a trusted port or from a previously known MAC address on an untrusted port (in which case it is inspected). Unless you know a valid MAC before hand you won't be able to get connected to then query the table to determine an associated MAC. It becomes a chicken-egg (which came first) problem.
Keep in mind that this discussion is also talking about ports, which says to me that it applies to wired networks where the MAC may be sniffed by observing traffic.
But if an attacker want the datas, it is not a wireshark or ettercap that will stop him... on the client side. Since the server side is not interesting at the beginning because we want to gather the credentials.
If true, DAI is just a way to delay the attack not to stop it...
But if an attacker want the datas, it is not a wireshark or ettercap that will stop him...
No, but think about what your saying for a second. An intruder has physical access to your network and a machine capable of running Wireshark on the machine. This is (hopefully) not going to be the man on the street. Whoever would have this capability will undoubtedly be a 'trusted' individual to some degree within the organization. They also have access to the network and can simply pick an unused IP address and probably take a few guesses as gateway... Between words, obtaining a MAC address would be the least of your concerns in this situation.
From what I've read of this and based upon that understanding, yes, I think you're correct that someone sniffing on the wifi traffic could obtain the MAC address. Encryption wouldn't help because the MAC is outside of the encryption. So, someone at the local coffee shop or wherever, now has a MAC address associated with a network. What good does it really do? He still won't be able to sniff the network, he won't be able to connect to it via wireless unless it is insecure (in which case why bother with spoofing a MAC), he won't be able to VPN into it, he won't be able to SSH into it, etc. Also, remember that MAC addresses do not pass through route boundaries, so at most the hacker would have a MAC address of a device and it looks to me like it would be all but useless unless he is able to gain physical access or be in the range of a target wifi and even then there should be much better security in place.
In essence, I don't see the point to this much effort to try to thwart MAC spoofing. To put it simply, MAC addresses were not meant to be a security mechanism; they were meant to be a visible token that was used to get traffic to its destination amongst other nodes and attempting to make it into a security function is nearly pointless. The same sort of logic applies to NAT, it was not meant to be a security / obfuscation mechanism and wasn't designed with this intent in mind.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.