Removing ghost hardware using Devcon on Windows 7 x64

This is my first blog post in a while, but I *had* to write something, when I finally managed to solve an issue I’ve been having.

I use a tool called BGInfo, which provides basic information on a computer as part of the wallpaper. Such as below:

bginfo

Recently I’d installed a NIC into the machine, only to find it was the wrong one. I removed the NIC, yet the history of the network card remained.

This was annoying, because I was getting statistics on something that wasn’t there.

To solve my problem, I had to use a tool called Devcon to remove hardware that no longer exits.

Initially, I downloaded Devcon from http://support.microsoft.com/kb/311272/

With instructions from https://social.technet.microsoft.com/Forums/windowsserver/en-US/da6f6847-5e1a-4b73-9f33-98e8cbddf451/ghosthidden-network-interfaces

I was able to identify the device I wanted to remove.

After running the command:

c:\devcon\i386>devcon -r  remove “@PCI\VEN_10EC&DEV_8139&SUBSYS_813910EC&REV_10\4&B244743&0&08F0″
PCI\VEN_10EC&DEV_8139&SUBSYS_813910EC&REV_10\4&B244743&0&08F0: Remove failed
No devices were removed.

Turns out, the reason I can’t remove is due to Devcon from that download not being from Windows 7, or for x64 bit OS.

I’m running Windows 7 x64, and the only way to get this file, is to download the WDK which is 600MB. This is ridiculous, since Devcon is only 100kb.

So, after some googling, I came across the x64 version here:

https://mattwv.wordpress.com/2014/08/19/devcon-exe-disable-failed-on-windows-7-x64/

This links to: https://www.dropbox.com/s/rre9l69jjy4vdyr/devcon.zip

So thanks to that guy, I was able to:

c:\devcon\x64>devcon -r  remove “@PCI\VEN_10EC&DEV_8139&SUBSYS_813910EC&REV_10\4&B244743&0&08F0″
PCI\VEN_10EC&DEV_8139&SUBSYS_813910EC&REV_10\4&B244743&0&08F0: Removed
1 device(s) removed.’

 

Woo!

How to configure 802.1X with AAA – Cisco Switch config

Below is a quick guide on 802.1x port-based authentication using a radius server for authentication.

 

- Firstly enable AAA

 

ALS1(config)#aaa new-model

 

- Configure the location of the Radius-server

 

ALS1(config)#radius-server host 172.16.1.1 key abc123

 

- Then configure what exactly needs authentication, along with how to authenticate it. In this case dot1x, using radius as the authentication method.

 

ALS1(config)#aaa authentication dot1x default group radius

- To globally enable dot1x (note this just “enables” the feature as such)

 

ALS1(config)#dot1x system-auth-control

 

- Following that, is configuring the access port, or group of access ports to use 802.1x to authenticate users against radius. Note, IOS may not show dot1x sub-commands if you haven’t configured the port as an access port.

 

ALS1(config-if)#int fa0/6

ALS1(config-if)#switchport mode access

ALS1(config-if)#dot1x port-control ?

auto PortState will be set to AUTO

force-authorized PortState set to Authorized

force-unauthorized PortState will be set to UnAuthorized

 

ALS1(config-if)#dot1x port-control auto

 

Auto

– Enables 802.1x port-based Authentication

 

Force-authorized

– Disables 802.1x on the port, and the port will auto transition to the authorized state.

 

Force-Unauthorized

– Causes the port to remain in the unauthorised state, effectively making the port useless.

 

Implementing Cisco Switched Networks Chapter 7 Review

This is my review and notes of Chapter 7 of “Implementing Cisco Switched Networks Foundation Learning Guide”.

Implementing-Cisco-IP-Switched-Networks-SWITCH-Foundation-Learning-Guide-Froom-CCIE-No-EB9781587141645

Chapter 7: Preparing the Campus Infrastructure for Advanced Services

WAFFLE WAFFLE WAFFLE. This chapter felt like “oh man, we totally need another chapter!”. When this book was first written, a lot of the content of this chapter was probably in the CCNP Switch exam. It covers topics that I’ve understood are now hardly touched on at all, if at it. Not to say it doesn’t still have some important topics in it. I read this chapter mainly to make sure I’ve covered every possible thing, but a lot of it I didn’t make notes on.

This chapter really went on and on about things that are common sense, especially things you should take into consideration when deploying voice, or video.

It did have some good content, but man it felt like there was a lot of extra stuff that just doesn’t matter for the exam.

What’s probably going to be in the exam:
– Just know the very simple things like important commands such as AutoQoS
– Very basic understanding of QoS, e.g. what DSCP and CoS is
– Very basic understanding of PIM-SM, PIM-DM
– Very basic understanding of IGMP, and IGMP Snooping

What the chapter also covers:
– Preparing your network for Wireless, Voice, and Video
– There was A LOT on each of these

Initially chapter is basically a spiel on why converged networks with video, voice, along with decent wifi connectivity are good.

Then goes into an introduction to WiFi, and its’ application in the Campus Network. I don’t have too many notes on this, mainly because I believe the exam doesn’t heavily focus on wireless and voice any more, as these have become more separate certification tracks of their own.

One point to make about wireless is the two deployment methods:

– Standalone WLAN Solution (also referred to as autonomous)
– Controller-based WLAN Solution

Traffic handling in a Controller-Based Solution
– Data and control messages are encapsulated between the access point and the WLC using the Control and Provisioning of Wireless Access Pooints (CAPWAP) or the LIghtweight Access Point Protocol (LWAPP). Both methods are standards based, but only LWAPP was adopted by Cisco.
– Control packets are enapsulated within the LWAPP or CAPWAP and encrypted.
– ^Same with Data traffic. The traffic is then switched at the WLC.

WLC is typically deployed at the distribution layer.

Hybrid Remote Edge Access Points (HREAP)
– Useful for providing HA of controller-based wireless solutions in remote offices.
– The purpose of these access points is to still offer wireless client connectivity when their connection to the controller (WLC) is lost.

Planning for the Campus Network to Support Voice

Again a lot on planning, and a lot on general considerations when implementing Voice.

– Voice uses UDP
– Voice is very much time sensitive traffic and a lot of thought needs to go into it when implementing.

Planning for the Campus Network to Support Video

Again talks about how it’s time sensitive, but in this case also very bandwidth hungry. This section was still several pages long, but I didn’t really feel like I read anything worth writing down. It was all pretty general, but obvious things to consider.

From these topics we come to something we really need to understand, and that is QoS.

Understanding QoS

Quality of Service refers to the prioritisation of different types of traffic. An example of its’ use is time critical traffic such as Voice packets not being swamped and lost due to lower priority traffic such as P2P consuming all the links bandwidth.

QoS allows you to have:
– Control over resources – Classifying high priority and low priority traffic
– More efficient use of network resources – By using network analysers, you can see a view of the traffic flows within your network and dedicate a higher priority to network resources that require it.
– Tailored services – In an ISP setting, better QoS can be sold at a price to customers who need it.
– Coexistence of mission-critical applications – Correct QoS configuration can ensure mission-critical apps are given exactly what they need.

Network Stability Issues
– Delay (latency)
– Delay variation (Jitter)
– Packet loss

QoS Service Models

– Best-effort service
Basically no QoS is applied, and the switch simply does FIFO (First In, First Out), so packets are simply transmitted out as they arrive in a queue

– Integrated Services (IntServ)
AKA hard QoS.
Implies that traffic flows are reserved explicitly by all intermediate systems and resources

-Differentiated Services (DiffServ)
AKA soft QoS.
Class-based, which some classes of traffic receive preferential handling over other traffic classes
DiffServ categorizes traffic, and then sorts it into queues of various efficiencies.

AutoQoS
Very handy Cisco feature that automates a lot of the QoS configuration

– Basically it does all the QoS config work for you, and therefore requires less of an understanding of QoS config, and enables more less experienced staff to deploy it.

AutoQoS covers:
– Application classification
– Policy generation
– Configuration
– Monitoring and reporting
– Consistency

Traffic Classification and Marking

– Layer 2 = CoS (Class of Service)

At Layer 2, 3 bits are available in 802.1Q frames for classification for up to eight distinct levels of service: 0 through to 7.

– Layer 3 = DSCP (Differentiated Services Code Point)

At Layer 3, QoS uses the six most significant ToS bits in the IP header for a DSCP field definition.
– Allows up to 64 distinct values (levls of service): 0 through to 63.
– Last 2 bits represent the Early Congestion Notification (ECN) bits.

Classification
– Distinguishes a frame or packet with a specific priority or predetermined criteria.
– For Cisco Catalyst switches, classification determines the internal DSCP value on frames. This is for internal QoS packet handling, including policing and scheduling as frames traverse the switch.

When planning QoS in the Campus Network, always apply QoS classification as close to the edge as possible, preferably in the access layer.

Trust Boundaries and Configurations

Covers how a frame is handled as it arrives in on the switch.

E.g. Switch receives a packet with a DSCP value of 46, the switch accepts the ingress QoS value, and internally also uses the same value.

Cisco switches support accepting DSCP, IP Precedence, or CoS values on ingress frames.

The following is the default mappings, for how each L2 and L3 classification is mapped between L2 and L3 respectively:

CoS

0

1

2

3

4

5

6

7

DSCP

0

8

16

24

32

40

48

56

 

IP Precedence

0

1

2

3

4

5

6

7

DSCP

0

8

16

24

32

40

48

56

Marking
Refers to changing the DSCP, CoS, or IP Precedence bits on ingress frames.
– Configurable on a per-interface basis via a policy-map.

Traffic Shaping and Policing

Shaping refers to metering traffic and buffering or delaying excessive traffic so that the traffic rate stays within a desired limit rate. Shaping therefore is not very good for delay-sensitive traffic flows such as voice, video, or storage, but is useful for typical, bursty TCP flows.

Policing differs in that it takes a specific action for out-of-profile traffic exceeding a specified limit.
Policing does not delay or buffer traffic.
Actions for exceeding traffic by default is block, but other options are available such as permissible, trusting, and marking.

Congestion Management

Covers several queuing mechanisms:
– FIFO queuing → switch places all egress frames into the same queue, regardless of classification. Packets are sent out in the same order that they are received.
– Weighted round robin (WRR) queueing → Popular and simple method of differentiating service among traffic classes. With WRR, the switch uses a configured weight value for each egress queue. This weight value determines the proportion of bandwidth of each queue.
– Priority queuing → Switch will process any traffic in the highest of queues before lower queues. Since this method can result in queue starvation in the nonpriority queues, the remaining queues are subject to the WRR queueing to avoid this issue.
– Custom queuing → Strictly for WAN.

Congestion Avoidance

Monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottleneck points.

Then goes into some methods of collision avoidance such as Tail Drop, and Weighted Random Early Detection.

Introduction to IP Multicast in the Campus Network

Initially goes over some basic stuff about multicast, including application and different with unicast and broadcast.

Covers the different types of Multicast addresses:
– Reserved link local addresses – 224.0.0.0 – 224.0.0.255
– Globally scoped addresses – 224.0.1.0 – 238.255.255.255
– Source-specific multicast addresses 232.0.0.0 to 232.255.255.255 – PIM-SSM reserved
– GLOP addresses 233.0.0.0 to 233.255.255.255
– Limited-scope addresses 239.0.0.0 to 239.255.255.255

Multicast MAC Address Structure

Multicast IP addresses get mapped to L2 MAC addresses. Due to how the structuring of this works, each Multicast MAC address maps to 32 potential IP addresses. In other words, each multicast MAC address represents a possible 32 distinct IP multicast addresses.

Reverse Path Forwarding
Is a mechanism that performs an incoming interface check to determine whether to forward or drop an incoming multicast frame.

When a multicast router receives a multicast packet, it determines which direction is the upstream direction (toward the source) and which one is the downstream direction (toward the receiver). A router forwards multicast packets only if the packet is received on the correct upstream interface determined by the RPF process.

Multicast Forwarding Tree
– Source Trees
– Shared Trees

Comparison:
– Both source trees and shared trees avoid multicast traffic loops. Routing devices replicate the multicast packets only where the tree tranches.

Source Trees
– Maintains path information for each multicast source

Shared Trees
– Have the advantage of requiring the minimum amount of state information in each router.
– This lowers the overall memory requirements and complexity for a network that allows only shared trees.
– The disadvantage of shared trees is that, under certain circumstances, the paths between the source and receivers might not be the optimal path, which can introduce additional latency in packet delivery.
Shared trees might overuse some links and leave others unused. In comparison, source trees usually distribute traffic across a set of links.

IP Multicast Protocols

Similar to IP unicast, where it can its’ own routing, management, and L2 protocols.

This section covers:
– PIM (Protocol Independent Multicast) – L3
– IGMP (Internet Group Management Protocol) – L2

PIM
– A multicast routing protocol.
– Uses the current unicast routing protocol to forward IP multicast traffic to other PIM neighbors.

Has several different versions:
– PIM Dense Mode
– PIM Sparse Mode
– PIM Sparse-Dense Mode
– PIM bidirectional

Sparse-dense mode is most common in large enterprise networks.

PIM Dense Mode
– Relies on periodic flooding of the network with multicast traffic to set up and maintain the distribution tree.
– Generally considered obsolete and no longer deployed in campus networks.
– PIM-DM floods the multimedia packet to all routers in the network and then prunes routers that do not service members of that particular multicast group.

PIM Sparse Mode
– Based on the assumption that the multicast group members are sparsely distributed throughout the network and that bandwidth is limited.
– Important to note that PIM-SM does not imply that the group has few members, just that they are widely dispersed.

-PIM-SM differs from dense mode, in that it begins with an empty distribution tree and adds branches only as the result of explicit requests to join the distribution.

Rendezvous Point
– Instead of flooding the network to determine the status of multicast members, PIM-SM defines an RP. When a sender wants to send data, it first does so to the RP. When a receiver wants to receive data, it registers with the RP.
– When the data stream begins to flow from sender to RP to receiver, the routers in the path automatically optimise the path to remove unnecessary hops.

Automating Distribution of RP
Done via:
– Auto-RP
-Bootstrap Router (BSR)
– Anycast-RP

Configuring Internet Group Management Protocol (IGMP)
– Hosts use IGMP to dynamically register themselves in a multicast group on a particular LAN.
– Hosts identify group membership by sending IGMP messages to their local designated multicast router.

IGMP Snooping
Basically it’s a Layer 2 feature that makes sure only ports that have requested a multicast group receive them, and once that port has finished, or no longer sends keepalives, the port is pruned from the group.

In more detail, IGMP snooping requires the LAN switch to examine, or “snoop,” the IGMP join and leave messages sent between hosts and the first-hop designated multicast router.

Preparing the Campus Infrastructure to Support Wireless

Only interesting thing I read is that the only real configuration you need to do on Cisco switches, is configure the access point port as a trunk.

Preparing the Campus Infrastructure to Support Voice

Voice VLANs
Cisco switches offer a unique feature called Voice VLANs, alternatively named auxiliary VLAN. The voice VLAN feature enables you to overlay a voice topology on to a data network seamlessly. Voice VLANs provide for logical networks, even though the data and voice infrastructure are physically the same.

-If an end-user workstation is attached to the Cisco IP Phone that connects to a Cisco switch with a Voice VLAN configuration, traffic rom the user workstation is switched through the phone on the native VLAN, by default.
– The native VLAN is not tagged and is the actual switch port VLAN config. The Cisco IP Phone sends traffic with an 802.1q tag if a Voice VLAN is configured for a VLAN besides the native VLAN.

Basic IP Phone config:
S1(config)#mls qos
S1(config)#int fa0/0
S1(config-if)#switchport mode dynamic desirable
S1(config-if)#switchport voice vlan 700
S1(config-if)#mls qos trust cos
S1(config-if)#power inline auto
S1(config-if)#spanning-tree portfast

Phones download config files from TFP. Use option 150 on DHCP Server to specify TFTP Server location.

Implementing Cisco Switched Networks Chapter 6 Review

This is my review and notes of Chapter 6 of “Implementing Cisco Switched Networks Foundation Learning Guide”.

Implementing-Cisco-IP-Switched-Networks-SWITCH-Foundation-Learning-Guide-Froom-CCIE-No-EB9781587141645

Chapter 6: Securing the Campus Infrastructure

Wasn’t too much of a fan of this chapter. It could just be because I’m pretty over reading this book. I feel like this chapter was generally alright, and I would recommend it if you’re looking into security for your campus network, but I still felt like at points it waffled on, and particularly had content which I highly doubt will be in the exam. Specifically some features that are only available on certain Cisco high end platforms.

What’s probably going to be in the exam:
– Switch Security Fundamentals
– Different types of L2 attacks and mitigation
– Port Security
– Brief understanding of different attack types (Mac spoofing, VLAN hopping, ARP Spoofing, DHCP attacks)
– VACLs
– IP Source Guard
– Dynamic ARP Inspection
– DHCP Snooping
– Understanding/recommendations on services to lock down on Cisco devices e.g. CDP, HTTP
– AAA ← I haven’t done very good notes on this, but I think it’s probably going to be pretty important for the exam.
– 802.1X
– SPAN/RSPAN

What the chapter also covers:
– SPAN to monitor CPU
– ERSPAN
– L2 Tracelog
– IOS Embedded Event Manager
– Network Analysis Module

Security at each layer

CORE—————-Server Farm
|
|
Distribution
|
|
Access

Server Farm
Use host and network based IPS, private VLANs, ACLs and secure passwords

Core
– Do not implement any packet manipulation here.

Distribution
– Use access lists to provide security.

Access
– Use switch port security to control access to the network.

Layer 2 Attack Methods

– MAC layer attacks
– VLAN attacks
– Spoofing attacks
– Attacks on switch devices

Attack methods and steps to Mitigate

Mac address flooding
Switch mac address table gets filled up causing the switch to then behave like a hub and flood traffic out all ports.

Enable port security methods

VLAN hopping
By altering the VLAN ID on packets encapsulated for trunking, an attacking device can send or receive packets on various VLANs, bypassing L3 security mechanisms.

Remove dynamic trunk negotiations on ports

Attacks between devices on a common VLAN
Different customers on same subnet in service provider network.

Implement Private VLANs.

DHCP starvation and DHCP spoofing
Attacker uses all available DHCP addresses or establishes itself as a DHCP server in man-in-the-middle attack.

Use DHCP snooping

STP compromises
Spoofs root bridge. If successful, attacker can see a variety of frames.

Proactively configure the Root Bridge and backup. Enable Root Guard.

MAC spoofing
Attacker spoofs valid host’s MAC addrss.

Use DHCP Snooping and Port Security.

ARP Spoofing
Attacker crafts ARP Replies intended for valid hosts.

Use Dynamic ARP Inspection, DHCP snooping, and port security.

CDP Manipulation
CDP info is sent in clear text and unauthenticated allowing it to be captured.

Disable CDP.

SSH and Telnet attacks
Telnet is in clear text.

Use SSH version 2, and only use Telnet with ACLs setup for specific hosts.

Port Security

S1(config-if)#switchport port-security ← Enables port security
S1(config-if)#switchport port-security maximum ← Specify max allowed MAC addresses
S1(config-if)#switchport port-security mac-address xxx ← Manually specify MAC
S1(config-if)#switchport port-security violation {shutdown | restrict | protect }

Shutdown – IF any frames are seen from a non-allowed address, the interface is errdisabled, a log entry is made, an SNMP trap is sent , and manual intervention or errdisable recovery must be used to make the interface useable. Shutdown mode is the default for violation.

Restrict – Frames from non-allowed address are dropped. A log message is created, and SNMP trap sent

Protect – Frames from the nonallowed address are dropped, but there is no log violation created.

Verify: S1(config-if)#show port-security [interface] [address]

Port Security with Mac Address Sticky

Port security can mitigate spoofing attacks by limiting access through each switch port to a single MAC address. This prevents intruders from using multiple MAC addresses over a short time period but does not limit port access to a specific MAC address.

Port security has a sticky MAC address feature that can limit switch port access to a single, specific MAC address without the network administrator having to gather the MAC address of every legitimate device and manually associate it with a particular switch port.

To Enable:
S1(config-if)#switchport port-security
S1(config-if)#switch port-security mac-address sticky

Verify with show run int x

Blocking Unicast Flooding on Desired Ports
This feature basically stops flooding of unicast frames when the switch doesn’t know where the destination MAC address is.

This is useful when other switch ports have been configured with a static mac address or mac address sticky, and is likely to be the only host on that port.

This stops devices on those ports receiving abiet not much, but unnecessary traffic caused by above.

To Configure: int fa0/1, switchport block {unicast | multicast}

Understanding and Protecting Against VLAN Attacks

VLAN Hopping
Basically an attack method where a device is able to send/receive/capture packets in a VLAN that it should not be able to access. This attack is accomplished by tagging traffic with a specific VLAN ID, or by negotiating a trunk with a switch that has DTP enabled. This is done by switch spoofing or double tagging.

So as above, if a switch has port settings on default (aka DTP enabled) they could connect an unauthorised Cisco switch and negotiate a trunk, therefore having access to all VLANs, or a pc with an app that generates DTP packets.

Another method is double tagging. This is where the attacker sends in frames that have two 802.1Q tags configured. For this attack to work, the attacker needs the recipient to be connected via another switch. It also requires both switches to be connected in the same VLAN as the attacking switch port or native VLAN of the trunk between the switch and the attacked VLAN. I think what that means is if the attacker is in VLAN10 on switch A, switch B also needs to have a host in VLAN 10.

Possibly see Wikipedia for more: http://en.wikipedia.org/wiki/VLAN_hopping#Double_tagging

Mitigation
– Configure all unused ports as access ports
– Place unused ports in shutdown state and put them in a VLAN specifically for unused ports.

When configuring Trunk links:
– Configure the native VLAN to be different from any data VLANs
– Trunking set to On, or Nonegotiate
– Trunks configured to only carry specific VLANs

VLAN Access Control Lists

Cisco Multi-Layer Switches support 3 types of ACLs:
- Router Access Control List (RACL) – Supported in the TCAM Hardware. RACLs can be applied to any routed interface, e.g. SVIs, or L3 Router interfaces.
- Port Access Control List (PACL) – Filters at the port level. Can be applied on L2 switchport, trunk port, or EtherChannel. Act at the L2 port level but can filter based on L3/L4 info.
- VLAN Access Control List (VACL) – Aka VLAN access-maps, apply to all traffic in a VLAN. VACLs support filtering based on Ethertype, and MAC Addresses. VACLs are order-sensitive, similar to route-maps. VACLs can control traffic flowing within the VLAN or control switched traffic, whereas RACLs control only routed traffic.

Configuring VACLs
Apply to all traffic on the VLAN. You can configure VACLs for IP and MAC-layer traffic.
– VACLs follow Route-map conventions, in which map sequences are checked in order.
– There are a few actions such as Permit, Redirect, Deny, VACL Capture, and VACL redirect, which are only available on the Catalyst 6500.

S1(config)#access-list 100 permit ip 10.1.1.1 0.0.0.255 any ← Identifying L3 list
S1(config)#mac access-list extended BACKUP_SERVER ← Identifying L2 list
S1(config-ext-mac)#permit any host 0000.1111.2222
S1(config)#vlan access-map ABC 10 ← Definding the VACL
S1(config-map)#match ip address 100 ← Matching previous L3 ACL
S1(config-map)#action drop ← Action
S1(config-map)#vlan access-map ABC 20
S1(config-map)#match mac address BACKUP_SERVER ← Matching previous L2 ACL
S1(config-map)#action drop
S1(config-map)#vlan access-map ABC 30
S1(config-map)#action forward
S1(config-map)#vlan filter ABC vlan-list 10,20

Spoofing Attacks
- Port security prevents MAC flooding attacks
– DHCP snooping prevents client attacks on the DHCP server and switch.
– Dynamic ARP inspection adds security to ARP using DHCP snooping table to minimise the impact of ARP poisoning and spoofing the attacks.
– IP Source Guard prevents IP spoofing addresses using DHCP the snooping table.

DHCP Spoofing Attack
Basically the attacker has a rogue DHCP server attached to the same segment which replies to DHCP requests before the valid DHCP server does. The attacker DHCP server gives the victim the attackers DNS and Default Gateway settings effectively making the attacker a man-in-the-middle.

Another method of attack is sending thousands of DHCP requests, potentially then exhausting the available addresses in the DHCP address pool.

DHCP Snooping
DHCP Snooping is a feature that determines which switch ports are “trusted” and allowed to response to DHCP requests.
– Per-port security mechanism used to differentiate an untrusted switch port connected to an end user from a trusted switch port connected to a DHCP server or another switch.
– Can be enabled on a per-VLAN basis.
– Trusted ports can either have a DHCP server on it, or be an uplink port towards another DHCP server.
– If an attacker connects a rogue DHCP server on an untrusted port, in which it attempts to reply to a DHCP request, the port is shutdown.

To configure:
S1(config)#ip dhcp snooping
S1(config)#ip dhcp snooping information option ← Enables DHCP option 82. Optional. Switch info such as port ID of the DHCP request.
S1(config-if)#ip dhcp snooping trust ← Enable on the DHCP server port or uplink port.
S1(config-if)#ip dhcp snooping limit rate rate ← Used to stop the DHCP server from being overwhelmed in the case of an attack to use up the DHCP pool.
S1(config)#ip dhcp snooping vlan number X ← Enable on a specific interface.
Verify: show ip dhcp snooping

ARP Spoofing Attack
In normal network operation, if a device doesn’t know the MAC address location of a host, it broadcasts an ARP request, asking for the MAC address of where the device is in the network.

ARP Spoofing is an attack where the attacker device sends out a gratuitous ARP (Unsolicited message/frame) with its’ own MAC address telling other hosts that it is the location for IP address X. Other hosts then install in their ARP caches that device X is at the MAC address of the attacker.

To prevent this, use Dynamic ARP inspection

Dynamic ARP inspection prevents man-in-the-middle attacks by not relaying invalid or gratuitous ARP replies out to other ports in the same VLAN.

– D ARP inspection intercepts all ARP requests and all replies on untrusted ports.
– Each intercepted packet is verified for valid IP-to-MAC bindings that are gathered via DHCP snooping.
– Denied ARP packets are either dropped or logged by the switch for auditing, so ARP poisoning attacks are stopped.
– Incoming ARP packets on trusted ports are not inspected.
– D ARP inspection can also rate-limit ARP requests from client ports to minimize port scanning mechanisms.

So to use DAI, you need to have DHCP snooping on. This is because it uses DHCP snooping to validate the DHCP/MAC address bindings.

In the case of static address configurations, DAI can also validate ARP packets against user-configured ARP ACLs.

Configuration
S1(config)#ip arp inspection vlan X
S1(config)#int x/x
S1(config-if)# ip arp inspection trust ← with arp inspection, you only need to do config on the trusted ports, such as trunk links. All other ports are automatically considered untrusted.
S1(config)#ip arp inspection validate [src-mac|dst-mac|ip] ← Configures DAI to drop ARP packets when the IP addresses are invalid, or when the MAC addresses in the body of the ARP packets do not match the addresses specified in the Ethernet header.

Verify:
show ip arp inspection interfaces
show ip arp inspection vlan x
show ip dhcp snooping binding

Default action if the switch now receives a bogus ARP request is to simply drop the request. The switch can also be configured to err-disable or shut down the port and generate a syslog message.

IP Spoofing and IP Source Guard
IP spoofing is where an attacker is impersonating a legitimate host on the network.
– IP Source Guard prevents a malicious host from attacking the network by hijacking its neighbor’s IP address.
– Provides per-port IP traffic filtering of the assigned source IP addresses at wire speed.
– Dynamically maintains per-port VLAN ACLs based on IP-to-MAC-to-switch port bindings.
– IP Source Guard is typing deployed for untrusted switch ports in the access layer.

IP source Guard works closely with DHCP Snooping. This feature can be enabled on a DHCP snooping untrusted L2 port to prevent IP address spoofing.

When a client receives a valid IP address from the DHCP server, or when a static IP source binding is configured by the user, a per-port and VLAN Access Control List (PVACL) is installed on the port.

Methods of IP Source Guard filtering:
– Source IP address filter
– Source IP and MAC address filter

Configuration
S1(config)#ip dhcp snooping ← enables globally
S1(config)#ip dhcp snooping vlan X
S1(config-if)#ip verify source vlan dhcp-snooping ← Enables IP Source Guard filtering
OR S1(config)#ip verify source vlan dhcp-snooping port-security ← Above with MAC filtering.
S1(config)#ip source binding x.x.x.x ip vlan X interface fax/x ← Static binding on port.

Verify using ‘show ip source binding’

IP Source Guard can only be configured on L2 interfaces.

Securing Network Switches

This section covers protocols such as CDP, SSH, Telnet, VTY ACLs, HTTP Secure Server, AAA, and 802.1x.

Network Discovery Protocols
Covers CDP (Cisco Proprietary) and LLDP (IEEE equivalent).

CDP (Cisco Discovery Protocol)
– Enabled by default.
– ‘no cdp run’ – disables CDP globally
– ‘no cdp enable’ – disables on an interface
– ‘show cdp neighbor [detail]’ – Displays a summary of which devices are seen on which ports.

LLDP (Link Local Discovery Protocol)
– Disabled by default
– ‘lldp run’ enables globally
– ‘lldp enable’ enables on specific interface.
– ‘show lldp neighbor [detail]’ – Similar to CDP.

CDP is a powerful tool in the hands of an attacker, as it gives them a reconnaissance view of the network. Some programs such as CiscoWorks require the use of CDP (or at least are heavily limited without it), so rather than disable it globally, selectively disable it on all ports except trunk ports and management ports.

Telnet
– Convenient, but don’t use it. All data is in plain text. Use SSH instead.
– If Telnet must be used, configure VTY line ACLs to only allow connections from management IPs.

SSH
– Everything is encrypted.

Config:
S1(config)#username matt password cisco
S1(config)#ip domain-name abc.com
S1(config)#crypto key generate rsa
S1(config)#ip ssh version 2
S1(config)#line vty 0 15
S1(config-line)#login local
S1(config-line)#transport input ssh

VTY ACLs
S1(config)#access-list 100 permit ip 10.1.1.1 0.0.0.255 any
S1(config)#line vty 0 15
S1(config)#access-call 100 in

HTTP Secure Server
– Use HTTPS instead of unprotected HTTP by using the command ‘ip http secure-server’. Make sure to disable the unsecure by issuing ‘no ip http server’
– To use HTTPs, you need to have a certificate on the switch. This is done through ‘crypto key generate rsa’ (you need a domain name configured to do this though).
– Configure an ACL so only the management IPs can access the switch web server. Apply it using ‘http access-class XX’
– Configure users, if the switch needs configuration done via the web server. Apply it using ‘http authentication local’.

Authentication Authorisation Accounting (AAA)
See wiki for description of each: http://en.wikipedia.org/wiki/AAA_protocol

AAA is actually quite important. Although my notes here are small, it’s something that will probably be in the exam and something you should make sure you understand, and can configure.

Configuration
Varies depending on what exactly you’re trying to achieve.

Authentication example using Tacacs+:
S1(config)#aaa new-model ← Globally enables AAA
S1(config)#aaa authentication login TEST tacacs+
S1(config)#tacacs-server host 192.168.1.1
S1(config)#line vty 0 4
S1(config)#login authentication TEST

Authorisation example using Tacacs+:
S1(config)#aaa new-model
s1(config)#aaa authorization commands 0 default if-authenticated group tacas+
S1(config)#line vty 0 4
S1(config-line)#authorization commands 0 default.

Accounting example using Tacacs+:
S1(config)#aaa new-model
S1(config)#aaa accounting exec default start-stop group tacacs+
S1(config)#line vty 0 4
S1(config-line)#accounting exec default

Security Using IEEE 802.1X Port-Based Authentication
Basically when a device is attached to the network, a user needs to log in via their user credentials which are stored in an Authentication Server database typically done by RADIUS.

Until the workstation is authenticated, 8021X access control enable only Extensible Authentication Protocol over LAN (EAPOL) traffic on the port.

Configuration
dot1x port-control {auto | force-authorized | force-unauthorized}
force-authorized
– Disables 802.1x port-based authentication and causes the oprt to transition to the authorized state without any authentication exchange required.
– Default Setting

force-unauthorized
– Causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate.
– Use this on ports where you don’t want any users to be able to connect from. I can’t see why you wouldn’t just shutdown the port instead…

auto
– Enables 802.1x port-based authentication.
– Port initializes in the unauthorised state, enabling only EAPOL packets
– The authentication process begins when either the link is brought up (authenticator initiation), or a client sends an EAPOL-start frame and the switch receives it (supplicant initiation).
– After this, the switch requests info identifying the client and this information is relayed between the switch and the authentication server.
– Clients are uniquely identified by their MAC address. This means that only an 802.1x capable host is connected to each access port.

When a client logs out, it sends an EAPOL-logout message, causing the switch port to transition to the unauthorised state.

Configuration

S1(config)#aaa new-model ← Enable AAA
S1(config)#radius-server host 10.1.1.1 auth-port 1821 key abc123
S1(config)#aaa authentication dot1x {default} group method1… ← Create an 802.1x port-based authentication method list
S1(config)#dot1x system-auth-control ← Enable 802.1x port authentication globally. Remember the global default for 802.1x is “force-authorized” which effectively allows anyone access on the ports.
S1(config)#int fa0/1
S1(config-if)#dot1x port-control auto ← Enabling authentication method on the interface

Switch Security Considerations
This section basically covers the thoughts and questions that should be asked when an organization is thinking about what it should cover in terms of security in their network.

One major point to consider is the a balance of reasonable network security against administrative overhead that is required for management of the network.

Cisco recommended minimum security configuration:
– Configure strong system passwords.
– Restrict management access using ACLs.
– Secure physical access to the console.
– Secure access to vty lines.
– Configure system warning banners.
– Disable unneeded or unused services.
– Trim and minimize the use of CDP/LLDP.
– Disable the inegreated HTTP daemon (where appropriate.)
– Configure basic system logging (syslog).
– Secure SNMP.
– Limit trunking connections and propagated VLANs.
– Secure STP.

Troubleshooting Performance and Connectivity

Techniques to Enhance Performance
I wasn’t going to include this, but I thought it was 3 good points for consideration within a production network:

– User performance
Based off the response time it takes for a user when using daily tools such as server databases. This variable gives the user their own perception of the reliability and performance of the network.

– Capacity Planning
This covers the idea of determining future network resource requirements to prevent a performance or availability impact on business-critical applications.

– Proactive fault management
– Responding to faults as they occur, and implementing solutions to prevent further faults in that area. This also comes under PPDIOO.

The next few pages of the book basically go into an analysis look of what things you should consider when looking at network performance, and trying to cover all necessary bases for a continual stable network.

Monitoring Performance with SPAN and VSPAN
Switched Port Analyzer is an important tool aiding in performance and troubleshooting in a network.

It’s basically mirrors all traffic in a VLAN or port[s] to a specific port. That port then usually has some form of network analyser (e.g. wireshark) connected to it.

Local SPAN is where the analyzer port and ports to be mirrored are all within the same switch.

VSPAN refers to mirroring of a VLAN to a single port.

SPAN supports capture of traffic in ingress, egress or both at the same time.

Configuration
S1(config)#monitor session 1 source interface fa0/1
S1(config)#monitor session 1 destination interface fa0/2
S1(config)#end
S1#show monitor session 1

Using SPAN to Monitor the CPU Interface of Switches
From what I understood, I believe this may only be on switches such as the Catalyst 4500 series.

It is helpful though as it gives you a view of what traffic is being processed by the SuperVisor CPU Engine.

cat4506(config)#monitor session 1 source cpu <>
cat4506(config)#monitor session 1 destination interface fa0/1
cat4506(config)#show monitor session 1

RSPAN (Remote Switched Port Analyser)
Similar to SPAN, but supports source ports, source VLANs, and destination ports on different switches, which provide remote monitoring of multiple switches across across a switched network.

– Each RSPAN session carries the SPAN traffic over a user-specified RSPAN VLAN. This VLAN is dedicated for that RSPAN session in all participating switches.

RSPAN consists of an RSPAN source session, an RSPAN VLAN, and an RSPAN destination session.

– It is advisable to configure separate RSPAN source sessions and destination sessions on different network devices.
– To configure an RSPAN source session on one network device, associate a set of source ports and VLANs with an RSPAN VLAN.
– To configure an RSPAN destination session on another device, associate the destination port with the RSPAN VLAN.

RSPAN Guidelines
– Configure the RSPAN VLANs in all source, intermediate, and destination network devices. If enabled, VTP can propagate configurations of VLANS numbered 1 through 1024 as RSPAN VLANs.
– Switches don’t impose a limit on the number of RSPAN VLANs allowed.
– Configure any VLAN as an RSPAN VLAN as long as all participating network devices support configuration of RSPAN VLANs, and use the same RSPAN VLAN for each RSPAN session.

Configuration

-Create the RSPAN transport VLAN:
S1(config)#vlan 901
S1(config)#remote span
S1(config)#end

– Configure the ports you want to mirror on the remote switch:
S1(config)#no monitor session 1
S1(config)#monitor session 1 source interface gigabitethernet0/1 tx
S1(config)#monitor session 1 source interface gigabitethernet0/2 rx
S1(config)#monitor session 1 source interface port-channel 2
S1(config)#monitor session 1 destination remote vlan 901
S1(config)#end

– Configure the destination Switch
S2(config)# monitor session 1 source remote vlan 901
S2(config)# monitor session 1 destination interface gigabitethernet0/1
S2(config)# end

Verify:
Show monitor

Monitoring performance with ERSPAN
Enhanced Remote SPAN.

Features:
– support for source ports, source VLANs, and destination ports on different switches, even across L3 links.
– Carries SPAN traffic over a GRE tunnel.
– Currently only supported on Catalyst 6500 switches.

Config not listed as I doubt this will be in the exam.

Monitoring Performance using VACLs with the Capture Option
– Currently only supported on Catalyst 6500 series.

Basically it’s using a VACL on a SPAN port to filter at Layers 2,3, or 4 to only match traffic the administrator is interested in.

Troubleshooting Using L2 Traceroute
Behaves similarly to traceroute for L3, in which you specify the source and dest MAC addresses, and it will tell you the path the device takes to reach the Dest.
– Requires all switches along the way support L2 tracelog.
– Requires CDP to be on with neighboring switches.

To execute:
S1# traceroute mac 0000.0000.0002 0000.0000.1234

Last things the chapter talks about is Cisco Embedded Event Manager, and Catalyst 6500 Network Analysis Module. Both of which I doubt will be in the Switch exam.