The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
IP source guard without DHCP
By stretch | Monday, May 25, 2009 at 2:21 p.m. UTC
Discussion of IOS' IP source guard feature typically accompanies the configuration of DHCP snooping. This is to be expected, as IP source guard relies on a switch's knowledge of DHCP-assigned host addresses in order to validate and restrict spoofed source addresses. However, IP source guard can be implemented independent of DHCP, a useful ability on networks or subnets using only static addressing.
When DHCP snooping is enabled, a switch maintains a database of the DHCP addresses assigned to the hosts connected to each access port. IP source guard references this database when a packet is received on any of these interfaces and compares the source address to the assigned address listed in the database. If the source address differs from the "allowed" address, the packet is assumed to spoofed and is discarded.
Assuming DHCP isn't available or in use on a subnet, static IP bindings can be manually configured per access port to achieve the same effect. The following topology illustrates the lab on which this is being demonstrated.
The first step is to enable IP source guard on every access interface:
Switch(config)# interface f0/10 Switch(config-if)# ip verify source Switch(config-if)# interface f0/20 Switch(config-if)# ip verify source
(Note that for the purposes of the lab, IP source guard has only been enabled on the two relevant access ports. In a real-world deployment, IP source guard should be enabled consistently across all access ports.)
The next step isn't immediately obvious, and in fact a bit counter-intuitive: enabling DHCP snooping. Despite our reliance solely on static bindings in this lab, the DHCP snooping feature must be turned on to enable the inspection of incoming packets. DHCP snooping must be enabled globally, and again for each VLAN on which IP source guard will be run.
Switch(config)# ip dhcp snooping Switch(config)# ip dhcp snooping vlan 10
Next we'll define the static IP source address bindings, under global configuration. Note that this also requires the source MAC address, which can be obtained from the switch's CAM table if not already known.
Switch# show mac address-table int f0/10
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 001d.60b3.0add DYNAMIC Fa0/10
Total Mac Addresses for this criterion: 1
Switch# show mac address-table int f0/20
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 0023.7d00.d0a8 DYNAMIC Fa0/20
Total Mac Addresses for this criterion: 1
Switch# conf t
Switch(config)# ip source binding 001d.60b3.0add vlan 10 10.0.0.10 interface f0/10
Switch(config)# ip source binding 0023.7d00.d0a8 vlan 10 10.0.0.20 interface f0/20
We can verify our new entries with show ip source binding:
Switch# show ip source binding MacAddress IpAddress Lease(sec) Type VLAN Interface ------------------ ------------ ---------- ---------- ---- ----------------- 00:1D:60:B3:0A:DD 10.0.0.10 infinite static 10 FastEthernet0/10 00:23:7D:00:D0:A8 10.0.0.20 infinite static 10 FastEthernet0/20 Total number of bindings: 2
The above output displays the bindings active in the database. However, to inspect the actual operation of IP source guard, the command show ip verify source is used:
Switch(config)# do sh ip verify source Interface Filter-type Filter-mode IP-address Mac-address Vlan --------- ----------- ----------- --------------- -------------- ---- Fa0/10 ip active 10.0.0.10 10 Fa0/20 ip active 10.0.0.20 10
If Filter-mode above lists inactive-no-snooping-vlan for any entry, DHCP snooping has not been enabled for that VLAN (which I totally already knew and wasn't at all a mistake I made in developing this lab).
On host B, we can verify that a legitimate ping (sourced from 10.0.0.20) to host A succeeds:
Host_B$ ping 10.0.0.10 PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data. 64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.465 ms 64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.297 ms 64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.385 ms
To verify that IP source guard is blocking spoofed traffic, we'll need to craft a custom packet. Scapy is a great tool for this:
Host_B# scapy Welcome to Scapy (2.0.0.11 beta) >>> sendp(Ether()/IP(src='1.2.3.4', dst='10.0.0.10')/ICMP(), iface='eth0') . Sent 1 packets.
The above command in the scapy interpreter sends an ICMP echo request to 10.0.0.10 sourced from 1.2.3.4. Although we're obviously unable to test for a response to this ping (even if it got through, the reply would be to 1.2.3.4 instead of Host B), running a protocol analyzer on host A verifies that the spoofed packet is never forwarded by the switch.
Posted in Security
Comments
May 25, 2009 at 2:32 p.m. UTC
Can you explain when this would actually be useful?
IP Source Guard is typically used to prevent users from setting a static IP address on their machine. This scenario doesn't seem to gain anything more than port security (which is a lot less complex), since you need the MAC address for this method anyway.
May 25, 2009 at 2:51 p.m. UTC
@IPv6Freely: In my opinion, the biggest advantage is mitigation of DDoS attacks, in which packets are typically sent from random source addresses to deter administrative filtering by the victim. Of course it's expected that an enterprise will only allow valid-sourced traffic out at the edge, but that does nothing to prevent internal attacks. IP source guard also prevents a malicious host from simply masquerading as another, such as a DNS server.
Also note that port security doesn't grant the ability to filter by source IP, only by source MAC, so (in the absence of DHCP) static bindings are required anyway. In man-in-the-middle attacks the source MAC is likely to be the "valid" MAC of the attacker anyway.
May 25, 2009 at 3:06 p.m. UTC
To me it seems that source guard is a mitigation of man-in-the-middle more than DOS attack. An attacker could try to become .10 or .20, but the binding along with the enabling of DHCP snooping prevents this from occuring.
May 25, 2009 at 3:49 p.m. UTC
I suppose. I just can't see ever using this in production. Maybe someone has a use for it, though....
May 26, 2009 at 1:28 a.m. UTC
Switch(config)# ip source binding 001d.60b3.0add vlan 1 10.0.0.10 interface f0/10
Switch(config)# ip source binding 0023.7d00.d0a8 vlan 1 10.0.0.20 interface f0/20
vlan 10 ,right ???
May 26, 2009 at 1:35 a.m. UTC
@maskmit: Whoops, yes, VLAN 10. Early on in the lab I had started with VLAN 1 but felt it prudent to assign a non-default VLAN for a slightly enhanced "real-world" feel. Thanks for pointing out the error, I've corrected the article.
May 26, 2009 at 1:38 p.m. UTC
Cool,
Do you know the latest status of IP source guard and DHCP snooping for IPv6? Any news from Cisco on that?
May 27, 2009 at 1:35 a.m. UTC
We were looking at implementing DHCP Snooping but some of the other guys on the team were concerned about the size of the binding table and what kind of performance (if any) depredation there was. Anyone have any experience / comments?
May 28, 2009 at 6:38 a.m. UTC
@KingFnerb: We rolled out DHCP Snooping, IPSG, and DAI last year on our LAN last year after we were hit with a virus that was trying to pull off a MITM by spoofing our default gateway. The size of the binding table was never really an issue. The number of entries should be roughly equivalent to your port density. One thing to keep in mind though, when applying IPSG while in "interface range" mode for all 48 ports in a 48 port switch, you'll likely see a huge processor usage spike for about 20-30 seconds and may lose connection and have to telnet/SSH back in.
May 30, 2009 at 11:13 p.m. UTC
A couple of months ago I was called in to assist a client who had been hit with a virus that spoofed their default gateway. They have a flat network with over 400 nodes. This is another IOS feature I can reference to help justify the purchase of some quality switches. Thanks for another great post Jeremy.
June 23, 2009 at 7:35 p.m. UTC
it's very good, i understand now how source guard fonctione!!!!!
thank
October 1, 2009 at 2:05 a.m. UTC
I think this would be of benefit to me, as a way to keep loose cannons from disrupting my network.
Where I work, we have a Manufacturing Engineering Group (MEG) which is entirely separate from the IT group. The MEG has hundreds of PLCs and sensors, each of which has an IP address.
My predecessors didn't have a clue as to how to manage a network, and they hated doing documentation, so they let the MEG put all the PLCs and sensors on the same VLANS as the PCs, printers, etc., and allowed the MEG to statically assign any IP addresses they felt like, from whatever addresses seemed to be free. This system is so entrenched, and the MEG carries so much weight with management, that I can't get them to stop doing it, even though it produces a ridiculous number of duplicate IP address problems.*
Every once in a while, somebody from MEG will assign a PLC/sensor the same IP address as one of the router interfaces, and cause a network disruption.
It seems like IP Source Guard Without DHCP can prevent that from happening. I just have to manually add the router IP and MAC to the binding table.
Do I have that wrong? Is there an easier way to do it?
(* There's lots more insanity of that nature, which prevents me from doing all the things you're probably thinking I should do to fix this. It's a problem of corporate politics, more than anything else.)
March 13, 2010 at 7:35 p.m. UTC
Good ...but must need more clearification about difference between Source Guard and DHCP Snoofing
March 15, 2010 at 4:29 p.m. UTC
How does this work with several trunked switches? Say that the dhcp server runs on the 'core' switch and there are multiple switches trunked from the core where all the client pc's attach. Does dhcp snooping need to be enabled on all switches and what about the trunk ports?
October 28, 2010 at 8:29 a.m. UTC
I'm have another question. If not all computers take IP address from DHCP. Could IPSG with DHCP-snooping work in network where part of computers take IP address from DHCP, part have IP-address staticaly ?
Unfortunately cannot check it.
July 6, 2011 at 5:42 p.m. UTC
useful article.
Thanks
November 7, 2014 at 10:37 p.m. UTC
Hey Jeremy, i want to secure the default gateway mac-address, because i already have an spoofed gw, can i do it using these techniques?
December 10, 2015 at 2:47 a.m. UTC
Thank you, Jeremy. The fact that we must enable DHCP snooping for static binding to work is indeed counter-intuitive. I haven't figured it out until visiting your blog.
Thanks again, Hoang Tran
December 10, 2015 at 2:53 a.m. UTC
Also I found out that we can enter a random MAC address in the "ip source binding" command if we just only want the switch to inspect source IP address.
Regards, Hoang Tran