11-12-2010 09:39 PM - edited 03-06-2019 02:02 PM
DHCP relay agent can build IP-to-MAC entry into DHCP snooping database. This database is used for DAI and IP source guard.
when attacker spoofs an IP address, the DHCP snooping database detects bycomparing with the valid IP-to-MAC entry.
Can MAC address also be spoofed? I know that router and switch allow user to configure MAC address.
thx,
Jingyi
Solved! Go to Solution.
11-13-2010 11:22 AM
Hello Jingyi,
If attacker spoofs host A’s IP address and MAC address, and sends out the malicious packet from the same port, how do DAI and IPSG detect that?
Well, from what you have written you should be able to easily guess that yourself. You have very correctly noted that the IPSG knows the MAC and IP address of the client connected to a port. That means that the client connected to that particular port must use only his own IP address as the source IP address in the packets it sends, and they must be encapsulated in Ethernet frames that are sources from his own MAC address.
Thus, the incoming datagram must have the correct source MAC/source IP combination. As soon as this combination does not correspond to the binding in the DHCP Snooping database, the frame is dropped. As simple as that.
Best regards,
Peter
11-13-2010 12:42 AM
Hi Jingyi,
Yes, of course, the MAC address can be spoofed as well. All modern operating systems allow you to change the MAC address of your network card. They do not do it by rewriting the EEPROM on your network card that stores the original MAC address. Rather, tell the driver of your card to temporarily reprogram its controller to use a different MAC address as its own.
The Dynamic ARP Inspection by its very nature prevents against MAC spoofing. For IP Source Guard, you can activate an enhanced checking that verifies not only the IP address but also the MAC address of the connected station against the DHCP Snooping database using the command
ip verify source port-security
For this to work, the port security must also be activated on the switchport using the switchport port-security command - obviously, some of the code is shared.
Best regards,
Peter
11-13-2010 07:09 AM
Also would like to add around IPSG with IP/MAC filter on, as suggested by Peter, you would have to Enable DHCP option 82, on DHCP snooping, relay and server side.
"If you enable IP source guard with source IP and MAC address filtering, DHCP snooping and port security must be enabled on the interface. You must also enter the ip dhcp snooping information option global configuration command and ensure that the DHCP server supports option 82. When IP source guard is enabled with MAC address filtering, the DHCP host MAC address is not learned until the host is granted a lease. When forwarding packets from the server to the host, DHCP snooping uses option-82 data to identify the host port"
So, do take this into consideration, as some External DHCP servers might not support option 82.
Regards,
Deepak
11-13-2010 10:57 AM
Deepak,
Thank you very much for your addition - that information is very important! As far as I know, inserting the Option-82 is activated by default on Catalyst switches when running DHCP Snooping - am I correct in this assumption?
Best regards,
Peter
11-13-2010 11:54 PM
Hi Peter,
Yes, option 82 is by default enabled with DHCP snooping.
But, some DHCP servers (if not Cisco IOS), might not support option 82. So, we need to ensure this before we consider enabling IPSG with MAC filtering on.
Also, I have seen several issues, where in option 82 is kept disabled, and relay agent may drop those requests. Lately with enhacements done with Cisco IOS, relay agent check all DHCP options and does not allow a packet to be forwarded with blank fields.
As a workaround for option 82, you may enable "ip dhcp relay information trust-all", to allow packets without option 82 field populated to be forwarded.
HTH.
Regards,
Deepak
11-14-2010 12:05 AM
Hello Deepak,
Thank you very much for your answer.
One note:
As a workaround for option 82, you may enable "ip dhcp relay information trust-all", to allow packets without option 82 field populated to be forwarded.
Actually, the command ip dhcp relay information trust-all or its interface-level counterpart ip dhcp relay information trusted solves a different issue: dropping a DHCP packet that contains the Option-82 present but the GIADDR (i.e. the DHCP Relay IP Address) field is set to 0.0.0.0. As the Option-82 is the DHCP Relay Information Option, it is expected that a DHCP Relay inserts this option into a DHCP message, along with populating the GIADDR field with its own IP address. A DHCP packet containing the Option-82 but having the GIADDR field blank can be, quite correctly, considered a suspicious packet, and IOS DHCP servers (I'm not sure about DHCP Relay service) drop such packets until they are configured with one of the commands above.
Catalyst switches running DHCP Snooping insert the Option-82 into DHCP packets sent towards the DHCP server but they do not populate the GIADDR field (quite logically - a DHCP Snooping agent is not a DHCP Relay agent), and thus such packets may not pass validity checks at the DHCP server and may be dropped, and that is the issue you were probably talking about.
Best regards,
Peter
11-13-2010 09:13 AM
Hi Peter,
Thank you for answering my question.
DHCP snooping database records the port to client, client MAC, assigned IP, and client vlan.
If attacker spoofs host A’s IP address and MAC address, and sends out the malicious packet from the same port, how do DAI and IPSG detect that?
Thx,
jingyi
11-13-2010 11:22 AM
Hello Jingyi,
If attacker spoofs host A’s IP address and MAC address, and sends out the malicious packet from the same port, how do DAI and IPSG detect that?
Well, from what you have written you should be able to easily guess that yourself. You have very correctly noted that the IPSG knows the MAC and IP address of the client connected to a port. That means that the client connected to that particular port must use only his own IP address as the source IP address in the packets it sends, and they must be encapsulated in Ethernet frames that are sources from his own MAC address.
Thus, the incoming datagram must have the correct source MAC/source IP combination. As soon as this combination does not correspond to the binding in the DHCP Snooping database, the frame is dropped. As simple as that.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide