LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Cisco DAi. Misunderstand (https://www.linuxquestions.org/questions/linux-security-4/cisco-dai-misunderstand-4175473385/)

LeHibou2 08-14-2013 01:04 PM

Cisco DAi. Misunderstand
 
Hello,

First a reference link :
http://labs.ine.com/workbook/view/se...nspection-Mjcx

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.

Please, tell me where I am wrong !

Many thanks,

LeHibou2

Noway2 08-14-2013 01:25 PM

From the link:
Quote:

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.

LeHibou2 08-14-2013 01:30 PM

Hi Noway2,

Yes but what can prevent the attacker to grab the ip and the mac from the victim and being seen as him ?

I cannot afford to understand the involved mechanism..

Another link:
http://technet.microsoft.com/en-us/l.../cc961394.aspx

if you have the exact same credentials, how could the switch know anything ? the ip-to-mac is the same !

Noway2 08-14-2013 01:45 PM

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.

LeHibou2 08-14-2013 02:05 PM

Exactly,

it is definitely not a narrow suject.

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...

Well, My thoughts..

Noway2 08-14-2013 02:51 PM

Quote:

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.

LeHibou2 08-15-2013 12:46 AM

You are right.

But look at the context :

Server-side : a bunker with cisco DAi and all the best security measures if any.
Client-side : a smartphone from a hotspot.

The hacker just has to listen the connection of his victim (client) study his device (few seconds) and then.. spoof him right.

The server won't notice. The client too because you spoofed entirely his identity.

How could the server know ? As I think : it can't.

I am wrong, am not I ?

Noway2 08-15-2013 02:37 PM

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.

LeHibou2 08-15-2013 02:46 PM

Many thanks Noway2,

You cleared it all :)

I can drop the pressure !

See you and thanks again,

LeHibou2


All times are GMT -5. The time now is 04:24 PM.