Thursday, February 23, 2012
IP Source Guard
So, after saying I would post about IP source guard in my DHCP Snooping Post I neglected to post much of anything for six months BUT I'm back to fulfill my promise.
IP source guard is basically a dynamic per port access list that will be applied to make sure the device is using the IP address (and mac address if configured) that the computer received during it's DHCP handshake.
As mentioned in the previous article, DHCP snooping is going to keep track of what IP address the device gets from the server. Then IP source guard ensures that address, stored in the dhcp snooping database, is the only IP allowed to communicate out the port, thereby defeating IP spoofing and some man in the middle attacks.
Picture a malicious user who connects to the network, and receives an IP address. They then listen to broadcast traffic and ARPs and determine another user's IP/Mac address. The malicious user could then either send out packets with the neighboring device's IP and pretend to be them, possibly bypassing ACLs that grant the attackee extra access. Attack two could be that the malicious user simply responds to request's by using the gateway's IP address and appears to be legitimate traffic.
Both of these could be mitigated by IP source guard, as the malicious user, sending any packets out with an IP (or mac) not included in the dhcp snooping database will be dropped.
NOTE* If you configure source guard on a port that doesn't have an entree either learned dynamically by dhcp snooping or manually entered in the ip source binding table, all packets will be dropped
Source guard is not allowed on routed interfaces or etherchannels
Configuration:
Step one -
A. ensure dhcp snooping is enabled on the vlan you intend to use IP source guard on (or you have manually entered all IP/Mac bindings in the ip source binding table)
B. If you enable IP source guard on a trunk interface (multiple vlans) then all vlans are filtered, ensure dhcp snooping is enabled for ALL vlans on the trunk.
Step two -
Determine if some or all of your addresses need to be manually entered:
ip source binding mac-address vlan vlan-id ip-address inteface interface-id
Step three -
Determine if you just want to use source guard based on IP addresses, or both IP and Mac addresses. If you want to check Mac addresses as well, ensure your DHCP server supports option 82.
interface interface-id
For just checking IP addresses:
ip verify source
For both IP and Mac addresses:
ip verify source port-security
Step Four -
Verify Config
show ip verify source [interface interface-id]
Verify Bindings
show ip source binding
Step Five -
Save if everything looks good
wri mem
(or if you are studying for an exam)
copy running-config startup-config
Thursday, February 16, 2012
Curious what the Openflow stuff is you are hearing all over? Check Out Ivan Pepelnjak's links to recorded versions of OPENFLOW AND SOFTWARE DEFINED NETWORKING 101 type introduction session on the technology causing all the buzz.
Interesting stuff, even if I am very very weary of taking the "brains" out of my switches and placing it in a controller or software situation, if it works well it could very well change the hole concept of networking as we know it.
OSPF Feasible Successors
OSPFv2 Loop-Free Alternate Fast Reroute - Once OSPF has calculated SPF and installed routes in the routing table, it calculates a successor route to destinations, much as EIGRP does. Greatly reduce your down time during re-convergence.
You can find it in the Cisco 15.1 release notes.
Cisco - Yep
Juniper - Yep
HP - As usual, they probably will get around to it in a couple years...
You can find it in the Cisco 15.1 release notes.
Cisco - Yep
Juniper - Yep
HP - As usual, they probably will get around to it in a couple years...
Monday, August 29, 2011
DHCP-Snooping and Dynamic Arp Inspection
Q. What is DHCP Snooping?
A.
1. Switch will watch all dhcp requests and build a table of ip-mac bindings for each port.
2. Switch will drop all dhcp RESPONSES from untrusted ports. (eg. If an end user places a dhcp server on their PC or device and connects to your switch, they won't be able to hand out addresses)
Q. What ports should I make trusted or untrusted?
A. Any ports you expect a dhcp response to come from. This includes the port your DHCP server resides on, as well as switch uplink ports. Make everything else untrusted.
Q. What is option 82?
A. Option 82 adds switch and port information to the DHCP request, so that the dhcp server can log information about the exact location of the client. Useful for tracking down malicious end users.
Q. I am on a procurve and there is something about authorized servers.
A. Put in the IP address of any DHCP servers you have in your network as authorized.
Q. So what about the arp inspection stuff?
A.
Malicious use 1. Think of a malicious user who responds to an arp request for the default gateway's IP address with their own mac. Now all the traffic goes to the malicious user rather than the router. (man in the middle attack)
Malicious use 2. A malicious or malfunctioning computer can send out thousands of arp responses filling up arp tables
Malicious use 3. A malicious or malfunctioning computer can send out arp responses (or gratuitous arp) to false mac addresses breaking network communication.
Arp inspection uses the DHCP snooping binding table to ensure that any arp response from an end user is only for the IP and Mac address they have been properly given by the DHCP server.
Q. This sounds like great security enhancements, are there any "Gotcha's I should know about?"
A. Two of them I can think of.
#1 Say you love this idea and go turn on dhcp-snooping and ip arp inspection today. A computer arp's for the DG or another device but their IP is not in the table yet, they still have a day left on their DHCP lease before they need to renew it. Their arp is dropped and they can't talk to that device. Fix#1, enable DHCP-snooping AT LEAST a full DHCP lease time prior to enabling arp inspection.
#2 Similar to number one. So say you have dhcp-snooping going, and you enable arp inspection, and everything is working fantastic. Now your maintenance window comes along and you need to upgrade your ios and reboot the switch. Now you rebooted and the DHCP-binding table cleared and you are stuck with problem #1 again, until the DHCP leases are renewed clients can't ARP. Fix#2 There is a way to save the database to flash before you reload, or even better, store a copy of the DHCP-snooping table off the switch, on a tftp server.
Q. Configurations?
Cisco:
(config)# ip dhcp snooping
(config)# ip dhcp snooping vlan 20,25-28
(config)# ip dhcp snooping verify mac-address
(config)# interface GigabitEthernet 2/2
(config-if)# ip dhcp snooping trust (for DHCP server connected interfaces and switch uplinks *do all of them since spanning tree could re-converge and send requests up alternate paths!*)
(config)# ip dhcp snooping limit rate 10
(config)# ip dhcp snooping database tftp://10.1.1.1/file
(config)# show running-config dhcp
(config)# ip arp inspection vlan 20,25-28
Procurve:
dhcp-snooping
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping vlan 5 10 20 99
interface a4
dhcp-snooping trust
dhcp-snooping database file tftp:///
show dhcp-snooping
show dhcp-snooping stats
show dhcp-snooping binding
arp-protect vlan 5 10 20 99
**dhcp-snooping on many(most?) procurve switches breaks PXE booting/imaging, and as far as I can tell has only been fixed on a few switch models, if you use PXE booting, test this feature before rolling it out to a production environment**
I will look at IP source-guard soon as it also uses the dhcp-snooping database
Thoughts? Suggestions? Accusations? Comments on my mental health?
A.
1. Switch will watch all dhcp requests and build a table of ip-mac bindings for each port.
2. Switch will drop all dhcp RESPONSES from untrusted ports. (eg. If an end user places a dhcp server on their PC or device and connects to your switch, they won't be able to hand out addresses)
Q. What ports should I make trusted or untrusted?
A. Any ports you expect a dhcp response to come from. This includes the port your DHCP server resides on, as well as switch uplink ports. Make everything else untrusted.
Q. What is option 82?
A. Option 82 adds switch and port information to the DHCP request, so that the dhcp server can log information about the exact location of the client. Useful for tracking down malicious end users.
Q. I am on a procurve and there is something about authorized servers.
A. Put in the IP address of any DHCP servers you have in your network as authorized.
Q. So what about the arp inspection stuff?
A.
Malicious use 1. Think of a malicious user who responds to an arp request for the default gateway's IP address with their own mac. Now all the traffic goes to the malicious user rather than the router. (man in the middle attack)
Malicious use 2. A malicious or malfunctioning computer can send out thousands of arp responses filling up arp tables
Malicious use 3. A malicious or malfunctioning computer can send out arp responses (or gratuitous arp) to false mac addresses breaking network communication.
Arp inspection uses the DHCP snooping binding table to ensure that any arp response from an end user is only for the IP and Mac address they have been properly given by the DHCP server.
Q. This sounds like great security enhancements, are there any "Gotcha's I should know about?"
A. Two of them I can think of.
#1 Say you love this idea and go turn on dhcp-snooping and ip arp inspection today. A computer arp's for the DG or another device but their IP is not in the table yet, they still have a day left on their DHCP lease before they need to renew it. Their arp is dropped and they can't talk to that device. Fix#1, enable DHCP-snooping AT LEAST a full DHCP lease time prior to enabling arp inspection.
#2 Similar to number one. So say you have dhcp-snooping going, and you enable arp inspection, and everything is working fantastic. Now your maintenance window comes along and you need to upgrade your ios and reboot the switch. Now you rebooted and the DHCP-binding table cleared and you are stuck with problem #1 again, until the DHCP leases are renewed clients can't ARP. Fix#2 There is a way to save the database to flash before you reload, or even better, store a copy of the DHCP-snooping table off the switch, on a tftp server.
Q. Configurations?
Cisco:
(config)# ip dhcp snooping
(config)# ip dhcp snooping vlan 20,25-28
(config)# ip dhcp snooping verify mac-address
(config)# interface GigabitEthernet 2/2
(config-if)# ip dhcp snooping trust (for DHCP server connected interfaces and switch uplinks *do all of them since spanning tree could re-converge and send requests up alternate paths!*)
(config)# ip dhcp snooping limit rate 10
(config)# ip dhcp snooping database tftp://10.1.1.1/file
(config)# show running-config dhcp
(config)# ip arp inspection vlan 20,25-28
Procurve:
dhcp-snooping
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping authorized-server #.#.#.#
dhcp-snooping vlan 5 10 20 99
interface a4
dhcp-snooping trust
dhcp-snooping database file tftp://
show dhcp-snooping
show dhcp-snooping stats
show dhcp-snooping binding
arp-protect vlan 5 10 20 99
**dhcp-snooping on many(most?) procurve switches breaks PXE booting/imaging, and as far as I can tell has only been fixed on a few switch models, if you use PXE booting, test this feature before rolling it out to a production environment**
I will look at IP source-guard soon as it also uses the dhcp-snooping database
Thoughts? Suggestions? Accusations? Comments on my mental health?
Tuesday, August 2, 2011
Cisco Live Sessions
Cisco allowed virtual sessions free this year, and they are recorded so I am finally getting around to watching a few. I strongly recommend browsing the selection.
Some highlights from the QoS Design clinic I'm watching now.
Uncompressed HD video - 1.5 Gbps
compressed to - 3-5 Mbps (300:1)
Which is why a single packet dropped in 10,000 is visible to watchers.
This makes it 100 times more sensitive than voice and requires sub-millisecond jitter.
Suggests not just marking packets but also policing.
Eg. No voice endpoint will ever send more than 128kps of data, so if traffic is coming in a trusted voice port and getting tagged with your Voice QoS designation, either drop or re-classify it when it exceeds the 128kps threshold.
-Priority Queue should be less than 33% of link but best effort guaranteed 25%
Some highlights from the QoS Design clinic I'm watching now.
Uncompressed HD video - 1.5 Gbps
compressed to - 3-5 Mbps (300:1)
Which is why a single packet dropped in 10,000 is visible to watchers.
This makes it 100 times more sensitive than voice and requires sub-millisecond jitter.
Suggests not just marking packets but also policing.
Eg. No voice endpoint will ever send more than 128kps of data, so if traffic is coming in a trusted voice port and getting tagged with your Voice QoS designation, either drop or re-classify it when it exceeds the 128kps threshold.
-Priority Queue should be less than 33% of link but best effort guaranteed 25%
Subscribe to:
Posts (Atom)
