Multiple Tenant, Same Switch – Private VLANs
A private VLAN allows conservation of IP and VLANs via L2 separation within a VLAN. It allows web hosts and ISPs to segregate or group devices whilst conserving IP addressing. PVLANs restrict communication between ports and allow communication with promiscuous port. Think VLAN inside a VLAN!
Primary PVLAN
- Primary PVLAN can be composed of many secondary PVLANs. The secondary PVLANs belong to the same subnet as the Primary PVLAN. The primary VLAN has the task of also carrying data from the promiscuous port to the isolated, community, and other promiscuous ports in the same primary PVLAN.
Secondary PVLAN
- A child PVLAN to the primary PVLAN, a secondary PVLAN is mapped to a single primary PLVAN. Secondary PVLAN are what hosts attach to.
Types of Secondary PVLANs
- Community PVLANS
- Ports can communicate with other community members and the promiscuous port of the primary PVLAN
- Isolated Private VLAN
- Ports can only communicate with the promiscuous ports only.
NOTE: Promiscuous ports only service and work with one primary PVLAN. A promiscuous port can service one isolated PVLAN or many community PVLANs
PVLAN Port types
- Isolated
- Isolated ports are completely separated at L2 from any other ports except those listed as promiscuous. These ports block all traffic to other isolated ports. Traffic is forward to promiscuous ports only
- Servers, Hosts (Think web-hosting!)
- Promiscuous
- These ports communicated with all ports within a PVLAN including community and isolated ports. Promiscuous ports are apart of one primary PVLAN and each promiscuous port can map themselves to multiple secondary PVLANS.
- Routers, Shared Servers, SVIs, Routed Switch ports
- Community
- These ports communicate amongst themselves and their promiscuous ports. L2 communities are isolated from other communities and isolated ports within their PVLAN.
- Servers, Server Farms
Configuration of Private VLANs
The objective of this exercise is meet the requirements of a webhosting company. They have employed you to configure the following PVLAN setup for their tenants.
VLANs in your VLANs so you can isolate while you isolate
First of all we define the PVLAN Type. This allows us to assign which VLAN will be a primary, community or isolated PVLAN
vlan 50private-vlan primaryvlan 51private-vlan communityvlan 52private-vlan isolatedvlan 50private-vlan association 51,52
int gi0/10switchport mode private-vlan hostswitchport private-vlan host-association 50 51int gi0/11switchport mode private-vlan hostswitchport private-vlan host-association 50 51int gi0/12switchport mode private-vlan hostswitchport private-vlan host-association 50 52int gi0/13switchport mode private-vlan hostswitchport private-vlan host-association 50 52int gi0/15switchport mode private-vlan promiscuousswitchport private-vlan mapping 50 add 51,52
show vlan private-vlan typeVlan Type---- -----------------50 primary51 community52 isolatedshow vlan private-vlanPrimary Secondary Type Ports------- --------- ----------------- ------------------------------------------50 51 community Gi0/10, Gi0/11, Gi0/1550 52 isolated Gi0/12, Gi0/13, Gi0/15
Easy enough. I was always daunted by this topic but now after labbing it I have found it to be quite nice and easy. Also remember that this is a 3560 series and higher technology. Sorry 3550!
Challenge Lab – SWITCH
Fellow packet herders. I have set myself a challenge lab encompassing some stuff I have learned. I feel it's time to challenge myself in the public arena and post the results. I am aiming to find some time this week to hit this out. I am looking to be a little busy with wedding preparations but I do have some down time nights that I am going to attempt to lab this out.
SW-A and SW-B are Cisco 3560-x and SW-C and SW-D are 2960S. All four are 48 ports. Just adjust the requirements of interface ranges to match your hardware.
SWITCH CHALLENGE LAB
Switch Placement
- Switch A and B are distribution
- Switch C and D are access
- Any two ethernet devices will act as hosts to test security
Initial Connectivity
- All links to be cabled as per the diagram
- Configure Gi0/7-8 and Gi0/11-12 on each switch using a IEEE trunking standard.
- Gi0/9-10 on all switches should use ISL. DTP frames must not be sent.
- These same links need to provide more bandwidth. Bundle these using a proprietary method
- Distribution switches must handle negotiation of these interfaces.
- Enforce bundle protocol
VLAN & VTP
- Create a Vlan Trunking Protocol domain called Cisco-Inferno
- Set the mode to server for SW-A. Set all others as clients
- Create a VTP password and ensure version 2 is used.
- Create the Following VLANS
- Vlan 10 Servers 10.0.10.0/24
- Vlan 20 Storage 10.0.20.0/24
- Vlan 30 LWAPP 10.0.30.0/24
- Vlan 40 Desktop 10.0.40.0/24
- Vlan 50 Wireless 10.0.50.0/24
- Vlan 100 Management 10.0.100.0/24
- Assign names to the VLANS
- Assign IP address to each device from the Management VLAN.
Spanning-Tree and L2 Redundancy
- Enable 802.1w mode of Spanning-Tree
- Set Vlan 10,20,100 on SW-A to be Root Bridge and make them Secondary on SW-B
- Set Vlan 30,40,50 on SW-B to be Root Bridge and make them Secondary on SW-A
Layer 3
- Create SVI's for VLANs 10,20,30,40,50 using the IP address of 10.0.x.2 (x= VLAN number) on SW-A
- Create SVI's for VLANs 10,20,30,40,50 using the IP address of 10.0.x.3 (x= VLAN number) on SW-B
- Convert the bundle between SW-A and SW-B (Gi0/11-12) to a L3 link. Use the address range of 10.0.5.0/30
Switch Security
Now that base connectivity has been established in out network it is time to implement some security and keep those pesky people out.
- Ports Gi0/24-40 should reside in VLAN 40. Ports Gi0/40-44 should be in VLAN 50. Apply this to SW-C/SW-D
- Enable across all access ports in VLAN 40 on SW-C/SW-D the ability to err disable if a BPDU is detected
- On SW-D enable port fast unconditionally across VLAN 40 and 50 ports
- On SW-C enable port fast in such a way it will loose its port fast status if a BPDU is received on VLAN 40 and 50 ports
- A lobby PC will be connected to Gi0/1 an Gi0/3. Enable the ability to learn the MAC Address dynamically and err disable the port if a different device is detected.
- Gi0/16-20 on SW-C/SW-D require up to 5 different devices to be learned before violating.
- Gi0/30 on SW-C needs a static assignment of the MAC 0000.000a.baba
- Gi0/30 on SW-D needs a static assignment of the MAC 0000.000b.cafe
- Block access from VLAN 40 and 50 into VLAN 100
High Availability
This network requires a strong level of uptime and the time has come to implement some HA technologies.
- You are to use a proprietary standby protocol
- SW-A and SW-B will be supporting each other in a HA setup. Virtual IP addresses are to be 10.0.x.1/24 of each VLAN.
- Group Numbers should represent VLAN numbers
- Follow good design principals when implementing HA - Think how L2 STP is placed.
- If SW-A is active, SW-B should be standby. Visa Versa.
- Ensure that if a switch goes down and comes back up that it regains it's active status.
Clarity : BPDU Guard vs BPDU Filter
In a stunning moment of clarity I figured out the two. It did take far longer that what was required but I feel now I can tick these two technologies off as being understood why you would use them and when you would use them.
Bridge Protocol Data Unit's known also as BPDU's play a fundamental part in a spanning-tree topology. No matter your flavour you will have BPDU's.
BPDU - A quick breakdown
BPDU's are sent out by a switch to exchange information about bridge ID's and cost's of the root path. A switch will use it's MAC address and sent it to the STP multicast address of 01:80:c2:00:00:00. There are Configuration BPDU's, Topology Change Notification BPDU's and Topology Change Notification Acknowledgement BPDU's. Exchanged at a frequency of every 2 seconds by default, BPDU's allow switches to keep a track of network changes and when to block or forward ports to ensure a loop free topology.
BPDU Guard
BPDU Guard is designed to protect your switching network. Remember that a Port-fast port is designed to be connected to a device where BPDU's aren't expected. This could be a end user device, server or access-point. When an unexpected BPDU is detected (an end-user wants to plug in a switch in his cubicle) the port will shutdown and enter a err-disable state.
When enabled globally this is a fantastic solution to protecting port-fast ports on access switches where you don't expect a switch to be plugged in. BPDU guard when enabled on a per port interface, is conditional. It requires the port to be portfast enabled. If you require BPDU guard to be enabled unconditionally then you must do that on the port itself.
Global
SW1(config)# spanning-tree portfast bpduguard default
Interface
SW1(config)# int gi0/10 SW1(config-if)# spanning-tree bpduguard enable
BPDU Filter
Initially I was stumped as to why you would use this. Why on earth would you want to stop BPDU's from being sent or received on a port. I immediate though it was ludicrous. It wasn't until I had a discussion with the man of infinite wisdom @networkjanitor (Kurt Bales) did I understand it's use. The point of demarcation is a fantastic place to use BPDU filter. When an ISP hands off a tail in the DC from their switch infrastructure, neither party want's anything to do with the others STP topology. This one of the uses of this feature. Probably the best one I have found.
First of all, BPDU filter disables spanning-tree on a port period. It does this by restricting sending and receiving BPDU's. Simple enough. When enabled on a global level, BPDU filter will apply to all portfast ports. When a port links up it will transmit some BPDU's out before the port starts to filter BPDUs.
Remember that if a BPDU is received on a portfast interface, the interface will lose portfast status and because BPDU filtering relies on this it will become disabled.
Global
SW1(config)# spanning-tree portfast default SW1(config)# spanning-tree portfast bpdufilter default
Interface
SW1(config)# int gi0/24 SW1(config-if)# spanning-tree bpdufilter enable
Anthony's Wrap
I've used BPDU guard a whole lot. After learning at college you could bring down an entire block of lab's with a switch configured a certain way, I made sure that no network under my jurisdiction would suffer the same fate. Couple BPDU guard with err-disable recovery and you have protection. BPDU filter could also be placed on access layer ports too. Another way to negate pesky attacks from inquisitive minds.
RPR RPR+ – brain download for SWITCH
Router Processor Redundancy (RPR)
Redundant Supervisor Engines – Handy having two brains!
When implemented back in the day in IOS 12.1(13)F it was a great technology. Over time NSR and SSO have addressed the shortcomings with better failover times. RPR on the 6500 series is around 2-4 minutes and on the 4500 series less than 60 seconds. RPR+ only available on the 6500 series comes in at around 30-60 seconds. In this day and age that is a noticeable downtime and isn’t transparent to the end user.
Supervisor engine that forwards all the L2/L3 traffic is the active supervisor engine. The other supervisor engine waits in standby. Both supervisor engines talk to each other.
| Trigger | Event |
| Routing/Switching processor crash | Switching modules power cycled |
| Manual | Subsystems on standby are activated |
| Removal | ACLs reprogrammed into Supervisor engine. |
RPR+
Improved switch over times and Reduced to around 30-60 seconds with no reloading of modules required.
Easy configuration makes RPR (when it was used) too good to not configure!
sw(config)# redundancy sw(config-red)# mode rpr-plus
Simple as that.
Verify with the following
sw# show redundancy states
Syslog – Brain download for SWITCH
Syslog is IOS' way of telling you something is happening/wrong/breaking/living/winning. It is rather informative and extremely helpful. Best part is you can send it all to a remote server and have it grace the walls of your office/NOC/nerve center!
Below is the format for syslog messages that are generated.
%FACILITY-SUBFACILITY-SERVERITY-MNEMONIC:message
%sys-5-config_1: configured from console by 10.1.1.1 vty0
It is smart to set the system time with NTP so all devices are in sync. This will allow you the ability to accurately determine when the log was generated. Below is the config for sending syslog messages to a server. My server is sitting on the IP address of 10.1.1.20 and I want to trap error syslogs (level 3) and higher.
sw(config)# logging 10.1.1.20 sw(config)# logging trap 3
Logging buffered sends it to the local buffer on the device. Although handy for lab action it is limited to physical memory. Handy for a lab if you are consoling around and want to see what is happening whilst configuring other devices.
Syslog levels for reference.
- 0 Emergency
- 1 Alert
- 2 Critical
- 3 Error
- 4 Warning
- 5 Notice
- 6 Informative
- 7 Debugging
SNMP – Brain download for SWITCH
Using UDP this protocol offers a host of options. It allows the monitoring and changing of devices remotely through monitoring or change applications. Polling of interfaces can be performed to perform bandwidth graphs or uptime charts. The frequency of SNMP polls/walks determines bandwidth usage on the network.
The SNMP agent is on the managed device. It collects and stores management information responds to requests and can also generate traps. The agent stores information in the MIB. MIBs permissions are controlled with the community R or RW strings.
Giving thought to the configuration is important. The information that can be collected and the tasks that SNMP can perform are something you want to lock down and secure. My thought process would be as follows
- Access lists – Confines the information to a vlan or to an IP range.
- Community Strings – define community names and permissions
- Traps – define traps and severity levels
- Version 3 – Authentication and Encryption - YAY!
Sw(config)# access-list 192 permit ip 172.16.42.0 0.0.0.255 any Sw(config)# access-list 193 permit ip 172.16.43.0 0.0.0.255 any Sw(config)# snmp-server community cisco-disco RO 192 Sw(config)# snmp-server community cisco-inferno RW 193
CDP, Vote 1 for use in your network!
Cisco Discovery Protocol. Many of us out here have a love/hate relationship with it. I for one and I fear I could be in the minority that like it. Security, Overhead, and Multi-vendor Environments are generally the biggest downsides to CDP. I can agree with the third point but I can defend the first and second.
Allow me to paint a picture which inspired these words. A standard afternoon in Melbourne, Australia. Four seasons in one day styled weather; Sunny and twenty-six degrees one minute and sub-ten degrees and raining the next. The office room was full of discussions regarding best practice and security discussions. Mainly observing how these creatures were interacting for control of the meeting, I chimed in with a statement when LAN security came up. "You will be enabling CDP across your switches?" The comment was chuckled at in unison with some raised eyebrows. "Of course not" was the reply. With the following points I defended my argument with and in my belief the reasons I like this protocol.
Per-Interface/Chassis enablement
By default, most people leave CDP running. CDP contains juicy information regarding hostname, management IP, local and remote interfaces, IOS version, platform and VTP domain. Rather informative for a 'ne'er-do-wells' attempting to get in.
Well it is possible to control this information. There are two ways to do this.
switch(config)# no cdp run
This global command disables the CDP protocol being generated by the switch. Unless the device has all interfaces facing the internet there is no real need to disable across the entire platform. You can disable CDP being sent from the switch on a per interface level.
switch(config)# int gi0/10 switch(config-if)# no cdp enable
This is where my argument for CDP begins. This deployment was an enterprise refresh and included many points of entry. Being in higher education I have found kids like to practice what is preached in class. With that I proposed the first of a few suggestions. By disabling CDP packets from these interfaces the attached devices cannot sniff/read these packets.
Disabled on
- WAN Interfaces
- Desktop Access Ports
- Internet facing interfaces
- Interconnects
- Lightweight AP's
- IP Phones
- WLC
Overhead
By restricting the interfaces and where CDP is sent from, you in turn reduce the overhead on you links. With 1 gig standard these days and 10, 40, and 100 gig Ethernet floating around, if bandwidth is a concern then I think you have important issues to address.
CDP – Handy Dandy!
Here again with more security considerations in your Switched environment. I have started to deep dive into certain technologies with reasons behind why I use them the way I do. CDP will be the first one of these. You may find this blog elsewhere.
CDP
This handy feature consists of a plethora of information about a device and it's connected neighbors. Hello-based and using an ethernet multicast address of 01-00-0C-CC-CC-CC, this protocol includes information such as hostname, management IP, local and remote interfaces, IOS version, platform, and VTP domain.
The information contained here within is cached until refreshed or flushed. CDP can reveal a lot of information regarding devices. IOS version is in my opinion the biggest as an attacker could exploit known vulnerabilities in the code. Though another post I have written defends this point. It states that if an attacker is using the CDP information to attack your network you have a serious problem in other security layers.
The message interval between CDP messages is 60 seconds and the hold time before flushing is 180 seconds. By default it is enabled upon all ports. Dangerous!
The following commands demonstrate the ability to disable CDP on a global level and on a per interface level. I recommend disabling them on all interfaces except trunks, APs, VOIP phones, and WLCs.
2960(config)# no cdp run 2960(config-if)# no cdp enable
Below are the following show options for CDP. Handy as all get out! One is a basic output the other is more details. Have a look at the difference.
2960#show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater Device ID Local Intrfce Holdtme Capability Platform Port ID lab-7206 Eth 0 157 R 7206VXR Fas 0/0/0 lab-as5300-1 Eth 0 163 R AS5300 Fas 03640#show cdp neighbors detail ------------------------- Device ID: 3640 Entry address(es): IP address: 10.2.2.3 Platform: Cisco 3640, Capabilities: Router Switch IGMP Interface: FastEthernet1/0, Port ID (outgoing port): FastEthernet0/0 Holdtime : 125 sec Version : Cisco IOS Software, 3600 Software (C3640-JK9S-M), Version 12.4(16), RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Wed 20-Jun-07 11:43 by prod_rel_team advertisement version: 2 VTP Management Domain: pandom.ciscoinferno.net Duplex: full
As you can see there is a massive amount of information regarding the IOS, Switch platform, and network topology. Use wisely!
They’re climbing in your switchports…..
Lock the doors...... and hope theydon't have blasters!
The infamous Star Wars quote. Generally at a campus edge we lock the doors. Firewalls, IDS, IPS and astro droids. The problem is often we forget about the network behind that. In this day and age an attacker could be anywhere. Cubicle D row 4, an integrator, the air con man or the CTO sent in on a mission. Alright, the last two were two far but hey I enjoy elaborating!
The importance of layer 2 security should be respected and as well regarded as layer 3. A combination of monitoring as well as considering the technologies in this post, you will be on your way to securing your network. Well, you will be better than a network with none! Included are some tasty treats you can go and bake an implementation plan with.
Port Security
CAM Flooding/MAC spoofing is one sure fire way to ruin one's day. CAM flooding essentially is the ability fill the CAM with bogus mac addresses. When legitimate requests come to the full CAM table the switch essentially turns into a hub mode. We know how hubs work right? Flooding. Lot's of flooding. It's a nice way to sniff the traffic as every request to that MAC address is flooded out all ports. Delicious sniffer waiting on Mike from accounting's desktop and precious data seized.
The way to stop against this style of attack is implementing port security. I find this feature fantastic for devices that SHOULD be staying put. Servers, IP Cameras, WAPs. If desktops are deployed then lock them down too. How do you do this? Is it work it? In my opinion....
YES!
Port security gives the ability to dynamically or statically learn the MAC address of expected devices on the switch port. When a device transmits frames with a MAC address that is not expected the port can shut, shut and report or err-disable and report.
Under the interface let's configure a statically assigned
3550(config-if)# switchport port-security 3550(config-if)# switchport port-security mac-address 0000.0000.0000.000a 3550(config-if)# switchport port-security violation shutdown
Firstly we enable port-security then define the mac-address we expect and last but not least the expected action that is taken when an unexpected frame is generated from the port. By default the maximum value is 1 MAC address. You can change this with
3550(config-if)# switchport port-security maximum 5
This set's the expected amount of different MAC addresses to 5. Easy. Next hot feature to use in conjunction with port security would have to be the aging feature. By default learned mac addresses are not aged out. You can set a time for them to do so and the switch flushes them from the interface.
3550(config-if)# switchport port-security aging 10 --or--3550(config-if)# switchport port-security aging static
MAC addressed learned dynamically are cleared in 10 minutes with the first command. The second command ages statically configured secure addresses. It is worth knowing the three modes in which the port-state can enter when a maximum mac-address is reached.
- Protect: Frames are dropped from non-allowed addresses. No log.
- Restrict: Again frames are dropped this time a log message is created and SNMP trap sent
- Shutdown: Interface is errdisabled, log entry made and SNMP trap sent when a non-allowed frame is received.
3550(config-if)# switchport port-security mac-address sticky
Instead of typing the previous commands to specify the mac-address the switch will learn and keep the mac-address of the first frame it captures. Any new frame received on that port will violate it based on the terms listed above.
Blocking Uni/Multicast floods
It is possible to avoid broadcasts on ports that do not need to receive them. When a switch floods a packet with an unknown destination mac address to all ports in the same VLAN. No need to flood to ports that have a set mac address. Use the commands below
3550(config-if)# interface gi0/4 3550(config-if)# switchport block unicast 3550(config-if)# switchport block multicast
Vlan hopping
A network attack that allows access to a vlan that an end device should not be in. By tagging invasive traffic with a specific VID or manipulating the creation of a dynamic trunk can cause a switch to become compromised. The initial exploit of DTP is done when an attacker sends a malicious DTP frame. Essentially forms a trunk between the device and the port allowed access to all Vlan's. Once the attacker has access to all the Vlan's they may intercept data or further launch an attack.
Vlan hopping with Double Tagging
Sounds cool because it is. In a shortened sense there is two VID's per frame. This secondary VID is classed as an "inner header". Once the original VID is stripped from the "Outer Header" there is still a VID on the frame. This fake frame tricks a switch into thinking the traffic was assigned to that vlan.
Mitigation
- Disable trunk negotiation on unused ports as access.
- Place unused ports into shutdown state.
- Purposefully configure non 'auto-magical' features.
- Explicitly define trunks (no-negotiate or on), native vlan.
- Don't let your end user's reign havoc across your desktop fleet.
But wait, there's more. More types of ACL's. Just when you thought it wasn't enough. Holy Joseph and the magic sheep. I like VLAN ACLs. In education it allows quite defined boundaries for Faculties/Students/Staff. Considering at some sites VLAN's are room based or lab based it can be quite handy.
On a multi-layer switch there are three types of access lists
- RACL - Router ACL's work on the TCAM hardware. Applied to the Routed interface (SVI)
- PACL - Port ACL filters traffic at the port level. Can be applied to L2 switch port, trunk or port channel. Although L2 they can filter L3 and L4 info.
- VACL - Vlan access maps. Apply to all traffic in a vlan. Can control traffic in a vlan or switched traffic. RACL's can only do routed traffic.
- Order-Independant merge - Turned from order-dependent to order-independent masks and patterns. ACE entry is large. Processor and memory intensive!
- Order Dependent is newer - New and far more efficient. Maintains order.
3750(switch)# ip dhcp snooping 3750(switch)# ip dhcp snooping information option
Enable snooping as a global command. The information option requests switchport origin. <-- Handy
3750(switch-if)# ip dhcp snooping trust
Under the interface we enable trust. This port connects to our DHCP server. By default all ports are not trusted.
3750(switch-if)# ip dhcp snooping limit rate 5
On an un-trusted port we limit the rate of DHCP requests to 5 per second. This is a way to combat DHCP starvation attempts. Finally we confirm the following settings with
3750# show ip dhcp snooping
Very handy way to prevent DHCP Starvation or man-in-the-middle attacks.
ARP Spoofing attacks
ARP. One of the first networking fundamentals I learnt when I was a little tacker. Address resolution protocol! Think of it as mapping an IP address to a MAC address. Simple as that. That is where it is dangerous. We trust that ARP is right. Well of course it is? Right?
It is possible to spoof an ARP reply from a legitimate device with a gratuitous ARP. This allows a device to appear/masquerade as something else. An attacker will bind his MAC to a legitimate devices IP and then can intercept traffic. I have briefly brushed over the explanation and there is plenty of detail in how to launch an attack with gratuitous ARP.
ARP has no authentication. Ettercap, dsniff, ARPspoof poison ARP tables. When I was young I did some great party tricks at high school and caused the then admin's some headache. Now that the shoes on the other foot I am implementing safeguards to stop "inquisitive" kids like me.
By ensuring valid ARP requests and responses Dynamic ARP inspection will do the following
- Forward ARP packets on trusted interfaces - no checking.
- Intercepts ARP packets on untrusted interfaces
- Verify untrusted intercepted packets have a valid IP-to-MAC binding before forwarding.
- Drop and log ARP packets with invalid IP-to-MAC bindings.
2960-01(config)# ip arp inspection vlan 100 2960-01(config)# int gi1/0/1 2960-01(config-if)# desc Fiberuplink to 3560-01 2960-01(config-if)# ip arp inspection trust
First of we enable inspection across vlan 100. We assign to our uplink port the trusted status. By default all ports are marked as untrusted.
2960-01(config)# ip arp inspection validate [src-mac [dst-mac] [ip]
This command enables DAI to drop ARP packets when IP's are invalid or when the MAC address in the body of ARP packets do not match the Ethernet header.
IP Spoofing and IP Source Guard
IP source guard protects innocent people from being spoofed by a malicious attacker. Dynamically assigns a per port VACL based on IP-to-MAC-to-switch port binding. Bindings can be populated through DHCP snooping or through a static binding. Deployed on untrusted switchports in the access layer.
There are two levels of L2 security filtering
- Source IP filter : Only traffic with a source IP that matches the binding entry is allowed.
- Source IP and MAC : IP traffic filtered based on source IP and additionally the MAC address.
3750(switch-if)# ip verify source vlan dhcp-snooping or 3750(switch-if)# ip verifiy source vlan dhcp-snooping port-security
These commands are configured on ports with dhcp snooping set. First enables without MAC filtering. Second enables with MAC filtering.
Ant's views
Wow. That was alot. Some things I have worked with for a while and some was new to me. I feel these easy steps will help mitigate common attacks. Go out there and re-do your access layer templates. You might be surprised the number of people out there doing things. Education/University level campuses yielded a few tasty treats. Next blog we will discuss things pertaining to "switch hardening".
DHCP – Switches CAN do it better than servers!
Dynamic Host Configuration Protocol
For most environments we configure DHCP as a role on our servers. Windows 2008 R2 DHCP role, *nix service with sudo apt-get install dhcp or something like that. Well your switches can do it too and if bandwidth and broadcasts are a concern look no further. Your vlan can issue DHCP addresses and cut the need for DHCP broadcasts to flood the network across multiple layers to reach a server.
Wow. Exciting. What do I need to know about DHCP?
Well, DHCP is a fundamental network protocol that assigns IP addresses to devices en masse. Sure static is cool. It's also seriously uncool with 20,000 devices and the like. How about statically configuring 200 new 1262 WAP's and inputing an IP to match a mac-address into a WLC. No thanks. Set a scope, define it's options and voila. Happy end-users.
The DHCP process is rather simple but knowing what happens at each stage is important. Here we go into another blog!
DHCP Process
Client sends out a DHCPDISCOVER broadcast. DHCP server returns with a DHCPOFFER unicast which contains parameters such as IP, MAC Address and a lease. Client returns an request for this offer in the form of a DHCPREQUEST broadcast. The DHCP sever will then issue a DHCPACK unicast to confirm.
A client can broadcast to many DHCP servers and many DHCP servers will reply but the first server generally distributes the lease.
Configurations and scope options
A Layer 3 switch can only issue addresses to vlans in which it has an IP in the subnet.
3750(config)# ip dhcp excluded-address 10.129.32.1 10.129.32.10 3750(config)# ip dhcp pool IP_CAMERAS 3750(config-dhcp)# network 10.129.32.0 255.255.254.0 3750(config-dhcp)# default-router 10.129.32.1 3750(config-dhcp)# option 150 10.129.32.2 3750(config-dhcp)# lease 0 8 0 3750(config-dhcp)# ! 0 days 8 hours 0 minutes 3750(config)# interface vlan 32 3750(config-if)# ip address 10.129.32.1 255.255.255.0
Here the above configuration sets up a DHCP scope for the IP Camera vlan. Once we assign a port and plug the cameras in, IOS will assign them an IP address with the parameters configured above.
I want to use a Windows DHCP server in a different Vlan!
My setup is mixed. I have IOS DHCP assigned for my IP cameras. Yet for my desktop/laptop fleet and the Cisco IP handsets I want to use Windows 2008 R2 server with the DHCP role.
What issue would arise using a DHCP server in a different vlan?
If you answered, DHCP requests are broadcast and vlan's are broadcast domains so the switch will not forward my requests on and I will be assigned an APIPA address, then you are correct! We overcome this by a simple feature on the SVI interface. This command forwards the DHCP udp packets as well as TFTP, DNS, NTP, NetBIOS, name server and BOOTP packets. Handy!
Simple commands
3750(config)# interface vlan 40 3750(config)# ip address 10.129.40.1 255.255.255.0 3750(config-if)# ip helper-address 10.100.42.3
Nice and easy. I have forgotten myself some times. PXE boot or WDS - fails to hit the load PE and I know the first thing after a network re-jig or new VLAN is to check ip helper-address.
Some deliciously informative commands to check on leases are
3750# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.129.40.0/24 0063.6973.636f.2d64. Oct 29 2011 04:36 AM Automatic
656d.6574.6572.2d47.
4c4f.4241.4c
Nice and easy today. Simple and effective. I believe the IOS built in DHCP server can be handy if well versed for a few reason. They are as follows and are based on my experiences
- Mass DHCP requests can avoid traversing access layer to distribution and maybe core to reach DHCP server. 8am clock on time, hundreds and or thousands of machines starting and and flooding away.
- Server infrastructure may be located else where or you may have a lack there of
- Can issue pools on a per switch basis. Useful if R&D are segregated or have an island network.
Who is this guy?
About Me- Network Engineer, blogger and CCIE wannabe. I am a guest blogger on PacketPushers, my own content here at blog.ciscoinferno.net and on Twitter @pandom_
Twitterfeed
Error: Twitter did not respond. Please wait a few minutes and refresh this page.