Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : 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. Lab topology 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 ---- ----------- -------- ----- 1 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 ---- ----------- -------- ----- 1 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 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 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 1 FastEthernet0/10 00:23:7D:00:D0:A8 10.0.0.20 infinite static 1 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. 4 comments

Les mots clés de la revue de presse pour cet article : source
Les videos sur SecuObs pour les mots clés : source
Les mots clés pour les articles publiés sur SecuObs : source
Les éléments de la revue Twitter pour les mots clés : source





Les derniers articles du site "PacketLife.net Blog" :

- Don't be Discouraged by Plagiarists
- Can You Keep a Secret Part 2
- Can You Keep a Secret
- Stretch's Hierarchy of Network Needs
- Thoughts on Two Years of Working from Home
- Writing a Custom IPAM Application
- What the CCIE does not Prove
- Traceroute and Not-so-Equal ECMP
- Networking FAQ 4 Fundamentals
- Networking FAQ 3 Names and Addresses

---

S'abonner au fil RSS global de la revue de presse

---