DAI (Dynamic ARP Inspection)

(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!

1 Like
(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:
image
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

1 Like
(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.

(Lazaros Agapides) #21

Hello Waleed

Both your statement and the quoted statement are correct. DAI does indeed check the DCHP snooping database for all packets that arrive on untrusted interfaces. If the info in the ARP packet is not in the database, the ARP packet is dropped.

It is also true that if you connect a rogue dhcp router on a trusted interface, no check will be made against the DHCP snooping database.

Trusted, no check, untrusted check, and if the check does not pass, drop.

I hope this has been helpful!

Laz

1 Like
(Oren E) #22

Dear Rene’
I need your help please : Following the packet tracer of DAI in this further link : https://networklessons.com/switching/dai-dynamic-arp-inspection , there is an important line : SW1(config)#ip arp inspection vlan 123
however it is not working at all : I use a 7.2 version of packet tracer (the latest) , but the CLI show en error below the word arp.
I wonder why. Please try to figure this out
Thanks
Oren

(Lazaros Agapides) #23

Hello Oren

Cisco Packet Tracer is what is known as a simulator. This means that it is configured to respond to commands in a similar manner to how a real Cisco IOS device would. Someone has programmed it to “act” like the IOS of a real device. Because of this, not all possible configuration options are available on packet tracer. There are many things that don’t work on it, and ARP inspection is one of them.

I went into my packet tracer and typed the command ip ? to see what available options exist. Here is what I get:

Switch(config)#ip ?
  access-list       Named access-list
  cef               Cisco Express Forwarding
  default-gateway   Specify default gateway (if not routing IP)
  default-network   Flags networks as candidates for default routes
  dhcp              Configure DHCP server and relay parameters
  domain            IP DNS Resolver
  domain-lookup     Enable IP Domain Name System hostname translation
  domain-name       Define the default domain name
  flow-export       Specify host/port to send flow statistics
  forward-protocol  Controls forwarding of physical and directed IP broadcasts
  ftp               FTP configuration commands
  host              Add an entry to the ip hostname table
  inspect           Context-based Access Control Engine
  ips               Intrusion Prevention System
  local             Specify local options
  name-server       Specify address of name server to use
  nat               NAT configuration commands
  route             Establish static routes
  routing           Enable IP routing
  ssh               Configure ssh options
  tcp               Global TCP parameters
Switch(config)#ip 

Notice that the “arp” keyword is not available. This is why the error is indicated under the word arp.

In order to test this, you will require the use of an emulator such as GNS3 and not a simulator like Packet Tracer. The emulator will allow you to run a REAL Cisco IOS file on your computer, providing you with all of the available commands of that IOS.

I hope this has been helpful!

Laz

(Oren E) #24

Dear Laz
I’d tried to use GNS3 but it is a very heavy software, which needs a virtual machine - which is heavy too. After installing both, the photos of all devices need a licence. The main problem is that a switch can’t open a CLI without a virtual machine.
I’d spent more than wo days in order to figure all of this out , and I conclude that the effort is not worthy at all.
Sorry - but I won’t spend time and effort for something that is not working well.
Oren

(Lazaros Agapides) #25

Hello Oren

It is true that GNS3 does have some hefty requirements, but even so, it can be useful even on systems with fewer resources. The following has an excellent “getting started” documentation for GNS3 that may be of help.

Other than GNS3, the only other way to get labs done is using VIRL or using real equipment.

I hope this has been helpful!

Laz