DAI (Dynamic ARP Inspection)


(Rene Molenaar) #1

This topic is to discuss the following lesson:


(Alberto s) #2

Hi rene, I don´t have a DHCP server. My users have Ip address static. Do I need configure ip arp inspection filter?


(Rene Molenaar) #3

Hi Alberto,

 

If you feel ARP poisoning is a risk on your network then you could implement it. However if you use static addresses then it’s probably not worth the effort.

DAI is very useful when you use DHCP as it relies on the DHCP snooping database. When you use DHCP then DAI will work for all address leases and we use the static entries only for some static devices like routers or servers.

If you have to implement this for all your users then it might be quite some work…

Rene


(Sachy) #4

Hi Rene,

Cisco Packet tracer switches do not have the ip dhcp snooping function. Does this mean I have to do it via GNS3 ?

Cheers

Neil


(Mohammad Hasanuz Zaman) #5

Hello Rene,

ARP poisoning attack can mitigate DAI and DAI works on DHCP snooping Database. So If there is no DHCP server, how can we mitigate ARP Poisoning attack?? Its like that if we want to mitigate ARP poisoning then must have to enable DHCP environment or any other way to mitigate ARP POISONING.

BR//
ZAMAN


(Andrew P) #6

Sachy,
I haven’t had much luck with GNS3 on this switching topic–certainly not on the native GNS3 (because there are no real switches). It might be possible via the GNS3 IOU, but I haven’t tried it. Here’s more info on that:

http://srijit.com/how-to-configure-iou-in-gns3-for-real-cisco-switching-labs/

If you can’t get that to work, I believe VIRL supports this feature (which isn’t free). Your other options would be to use a Rack Rental (like with INE.com) or borrow some actual switches if you can.


(Rene Molenaar) #7

Hi Zaman,

There is one other method if you don’t have a DHCP server. You can create static ARP bindings in the ARP snooping database.

Rene


(Stefanio L) #8

Hi, Rene.

If ARP inspection intercepts the ARP packets against the DHCP-snooping table, why does PC’s can send ping to the DHCP_Rogue router when I set up a switch port as trust for ARP inspection and untrust for DHCP-snooping (default)?

By logic the ARP inspection can function independently from DHCP-snooping, because my understanding was that the switch would use DHCP-snooping table for drops ARP on interfaces configured as Untrust in DHCP-snooping.

I was a little confused by that lesson, could you clarify that question?

It follows a basic topology that I used as lab.


(Brian C) #9

So I am on the final run getting ready for my CCNP Switch some areas I am weaker in was DHCP Snooping and DAI.

I created the following lab in CISCO VIRL Lab:

**EDITED:**
I had three pages of information (lol) but decided to edit it out AS I was able to figure out everything by going back over your lesson and watching the video.

Writing on the forums really helps me to get things straight in my brain and also not feel alone when studying and stuck on something.

Thanks for the great lessons!


(Rene Molenaar) #10

Good to hear you were able to figure it out :smile: Good luck with the exam!


(Brian C) #11

Thanks Rene your awesome for teaching this stuff!

I created a post I figured out the answer but don’t know for sure the reason the answer is the way it is.

I probably could have picked a better place to post it. if you get chance take a peak hopefully Andrew or one of the guys will get a prompt by email of my reply but not sure how the forums works for sure.

https://forum.networklessons.com/t/hi-from-united-states-tulsa-oklahoma/718/29


(Helen N) #12

Hi,
DAI works if I have a Windows DHCP Server?


(Lazaros Agapides) #13

Hello Helen

DAI does work with a Windows DHCP server. In fact, it will function with any DHCP server, since the configuration of the server is independant of that of DHCP snooping and DAI. In the following diagram that is found within the lesson:


you can replace the DHCP router with a Windows server providing DHCP services. The DAI functionality is configured and operates within SW1.

SW1 will maintain a DHCP snooping database based on the requests/responses to the DHCP server that are occuring on the trusted ports. This DHCP server can by any device offering DHCP.

I hope this has been helpful!

Laz


(florian k) #14

Hi guys,

one question regarding those two features:

•dst-mac: checks the destination MAC address in the Ethernet header against the target MAC address in the ARP packet. This check is performed for ARP replies. ARP replies with different MAC addresses will be dropped.
•src-mac: checks the source MAC address in the Ethernet header against the sender’s MAC address in the ARP packet. This check is performed for both ARP requests and replies. ARP packets with different MAC addresses will be dropped.

I saw in your previous post “ARP poisoning” the two Wireshark files which show ARP replies when you supply the host and the router with the MAC address of the attacker. In both files one can see that the SRC and Sender MAC addresses or the DEST and Target MAC addresses respectively DO match and thus the above mentioned features would not detect such an attack, right? In which scenario would those two features actually help then?

Thanks!

Flo


(Lazaros Agapides) #15

Hello Florian

ARP inspection by default inspects and compares the IP to MAC associations in ARP packets received on untrusted ports with the DHCP snooping database which has the valid and trusted associations. Even without the dst-mac and src-mac configuration options, an ARP posining attack as decribed in the “ARP Poisoning” lesson would be detected, since the MAC to IP mapping provided by the attacker don’t match the DHCP snooping database.

The dst-mac and src-mac options are additional inspection options that examine the source or destination MAC address found in the HEADER of the ARP packet with the MAC address contained in the PAYLOAD of the ARP packet. This additional level of testing will protect against attackers that want to direct traffic to a third party device on the network.

I hope this has been helpful!

Laz


(florian k) #16

Hi Laz,

thanks for your reply!
I understand the src-mac option as with this you could, as you mentioned, forward the traffic to another source and thus this shall be avoided. But for the dest-mac option i cant think of a scenario. Do you have any idea? Because if the dest-mac in the ethernet header and in the payload differ the destination host would not accept the packet anyway!? Or is this option just to keep your network clean and that such packets are dropped as closest to the src as possible?

Thanks
Flo


(Lazaros Agapides) #17

Hello Florian

Remember that these two options are applied to ARP responses.
This means that the destination MAC address, that is the MAC address that the ARP reply is ACTUALLY being sent to is compared to the target MAC address in the ARP body which is the MAC address of the REAL ORIGINATOR of the ARP request. If these two are different, this means the ARP reply has been tampered with. This would be the case if an attacker took advantage of an ARP request that was made and replied to a different host to poison the ARP table of that host. This would be useful to an attacker on a network where Gratuitous ARP is not allowed.

I hope this has been helpful!

Laz


(florian k) #18

Hi Laz,

thanks for your reply. Could you explain this a bit further to me. I dont get it what the benefit could be if the Dest_MAC in the Ethernet header would be different to the Target_MAC in the ARP body!? As if this would be the case, the frame would be switched to the host with the respective MAC from the Ethernet header but then the host would check the MAC in the ARP body and realize its not his and drop the frame, no?
Also, how is it possible to deny Gratuitous ARP´s, as i thought those are a vital part of every interface for example!?

Thanks for your help!
Flo


(Lazaros Agapides) #19

Hello florian

My apologies for not responding sooner!

Keep in mind that the Sender hardware address and the target hardware addresses found within the ARP packet are not the source and destination MAC addresses found in the Ethernet header. Now you are correct when you say that:

DAI will cause such frames to drop so that they don’t actually reach the host. These are illegitimate packets and most likely come from a malicious source, so they should not be sent to the host. The host will not have to waste time and resources processing them.

As for this question, my apologies. I had the no ip gratuitous-arp command in mind but this just disables the sending of gratuitous ARP packets by the device itself and not the blocking of such packets from hosts.

I hope this has been helpful!

Laz


(Waleed K) #20

“DAI checks the DHCP snooping database for all packets that arrive on untrusted interfaces, when it doesn’t find a match…the ARP packet is dropped.”

According to my understanding of the topic; If you configured the rogue dhcp_router interface as arp trusted interface, DAI will not check this as it only checks arp packets on untrusted interfaces.