Thursday, April 14, 2011

CCNP - SWITCH - I passed!

I passed the CCNP SWITCH exam on Monday morning at the second attempt :o)

With much relief I'm now having a couple of weeks off the study to catch up on jobs about the house before I crack on with TSHOOT and get my CCNP in bag.

So far as the exam was concerned I felt that it was challenging but not impossible. I believe people regard this as the hardest of the 3 exams and on measure I would say that it has been the toughest Cisco exam I've sat so far.

Without breaking the NDA, I'd say the exam tests a lot of the detail in a narrow spectrum of topics. The same areas kept cropping up in the multiple choice, multiple answer questions and also the labs/simlet questions.

For any one attending a Cisco Networking Academy, you can ignore multicast completely. If you've got the Cisco Press books you'll see that in the Foundation Learning Guide, multicast is present (chpt 7 I think) BUT in David Hucaby's Official Certification Guide it is not. I think Hucaby's book is more recent so this explains the difference. Also check the exam topics on the Cisco Learning Network and you'll note that multicast is not listed in the tested subjects either.

Other than that little bit of advice I'd recommend you watch your time very carefully. I got to question 49 of 50 and was presented with a lab! I was lucky to have sufficient time remaining and was able to calmly complete it working on the gamble that I wouldn't get a 5th lab ( yes I did get 4 labs) at question 50. I might have felt differently had I only had a few minutes remaining for the last 2 questions. So be warned.

Onwards and upwards.

Thursday, April 7, 2011

CCNP - ROUTE - Practical Application of Route-Maps

Bit of an odd one to chuck in here as I'm still to sit my CCNP SWITCH however I thought I'd log an interesting situation I've encountered at work and how the use of a simple route-map can benefit your network.

Imagine you are migrating from one ISP provider to another. The current provider not only offers your web filtering but also your DNS, web mail, and other hosted services so you can't simply cut them off. You need to be able to split out the Web filtering to your new provider whilst maintaining access to the old ISP for the hosted services.

As part of this move you are migrating the internet access of 300 sites. Each site is getting a new firewall as well and the move to the new ISP is taking place as each site gets it's new hardware.

Due to this hardware change you will end up with some sites on the old hardware pointing to the old ISP and some sites on new hardware pointing to the new ISP.

My question is this, with the minimum of in put by your self how do you run both ISP's at the same time and have the new sites point to the new ISP for the web filtering whilst maintaining access to the old ISP for everything else?

Here is the solution, on the router that provides the connection to both the Old ISP and the New ISP:

1) ip route 0.0.0.0 0.0.0.0 10.10.10.254
!
!
!
2) access-list 111 deny ip any 10.10.10.0 0.0.0.255
3) access-list 111 permit ip 192.168.10.0 0.0.0.255 any
!
4) route-map new-isp permit 10
5) match ip address 111
6) set ip next-hop 172.16.1.1
!
!
7) interface GigabitEthernet0/0
    description ***Inbound Interface towards the ISP's***
    ip policy route-map new-isp

Breaking it down line by line the config is as follows:
1) This is the default route to the old ISP. This required for all sites that have not migrated, also your hosted services are located in this direction. DNS, web mail, Anti-virus are located on servers on the 10.10.10.0/24 subnet.
2) Extended ACL denies packets from any Host going to the old ISP for hosted services, this stops that packet being processed by the route map and therefore prevents the next hop from being changed. The denied packet will be processed as usual by the routing engine and as such you maintain access to your hosted services.
3) This permits the packet from this subnet, to any destination, to be processed by the Route-map. As each site is kitted out with it's new hardware you add the site's IP range ( a /24) to this ACL. This in turn is permitted to be processed by your route-map and the next hope for web filtering is changed.

Remember that if your newly migrated site still needs access to DNS, web mail etc, this will be caught in the first line, the DENY any statement and will not proceed to the route-map for processing.

4) This is the entry for your route-map
5) The match statement catches permitted IP's in ACL 111
6) Any matched IP's in ACL 111 are then directed to the new ISP at 172.16.1.1, the New ISP will provide your web filtering only.
7) Apply your route-map to the inbound interface that receives the traffic from all the sites that are being migrated. The route-map is porcessed at this point and the next-hop defined.

So what happens next?
Each time you want to cut over a new site you simply add a permit statement to ACL111.
Straight away the route-map will pick it up and web traffic will be diverted from the old ISP to the New ISP.

Ultimately you will end up with up to 300 sites listed in ACL111. Once all sites have been migrated you can change your default route, remove the route-map and run access to the internet as normal.

Wednesday, April 6, 2011

CCNP - SWITCH - Switch Security Features - IP Source Guard

IP Source is used to prevent IP Spoofing where an attacker impersonates another host by using it's IP address.

IPSG provide per-port filtering of the assigned source IP, it dynamically maintains per port VLAN ACL's based on the IP-to-MAC bindings set out in the DHCP Snooping database.

IPSG is applied on Untrusted ports and can filter a Source IP or a combination of Source IP and MAC address.

When a violation occurs the packet can be dropped and/or an alert be issued.

Apply IPSG to Access Layer interfaces

Configure IP Source Guard
First enable DHCP Snooping:
  SW1(config)#ip dhcp snooping

Next, apply DHCP Snooping against a specific vlan (or vlans):
  SW1(config)#ip dhcp snooping vlan [id]

Enable IPSG on a specific interface:
  SW1(config-if)#ip verify source vlan [id] dhcp snooping*
    - use this command to verify only source IP addresses

  SW1(config-if)#ip verify source vlan [id] dhcp snooping port-security
   - use this command to verify against source IP and MAC address

Optionally, you can also rate limit and interface
  SW1(config-if)#switchport port-security limit rate [invalid-src-MAC] [rate]

You can also statically bind an IP address to a port:
  SW1(config-if)#ip source binding [ip] vlan [id] interface [id]

Verify IP Source Guard
Use the following commands to verify your configuration:
  SW1#show  ip source binding
   - Displays MAC-to-IP binding, type of binding, vlan membership, interface the binding applies to.

 SW1#sh ip verify source
   - Displays your interface, filter type and mode, IP addr, MAC addr, and VLAN

CCNP - SWITCH - Switch Security Features - Dynamic ARP Inspection

DAI is used to prevent invalid or gratuitous ARP requests in the same VLAN.

When ARP is used correctly, a host sends a broadcast to locate the MAC of a destination host. The Destinations host replies with it's MAC and the originator caches that MAC address and applies it to the Dest field in it's packets.

ARP spoofing is where an attacker appears as the Destination host by supplying it's MAC address against the legitimate host's IP address. The Originating host caches the attacker's MAC and directs packets to the rogue Destination instead of the legitimate Destination.

Operation
DAI intercepts packets on Untrusted ports, packets are then validated for IP-to-MAC bindings that have been gathered from DHCP Snooping.

Denied packets are dropped and/or logged. Incoming ARP requests from Trusted ports are not inspected. Like DHCP you can also rate limit the ARP requests per second. Rate limiting can help prevent port scanning.

Configure DAI
In general configure all Access ports as Untrusted. Configure all switch trunks as Trusted so that no further inspection of packets is required as the request travels through the Access-Distribution- Core of your infrastructure.

Enable DAI on a per VLAN basis:
  SW1(config)#ip arp inspection vlan [id]

Define your trusted ports:
  SW1(config-if)#ip arp inspection trust

NOTE - default configuration for ports is Untrusted.

Verify DAI
Use the following commands to verify your config:
  SW1#show ip arp inspection interfaces
   - Displays interfaces, trust level, any rate limiting, and any bursts noted.

  SW1#show ip arp inspection vlan 10
   - Displays DAI state for the vlan (Enable/Disabled)

  SW1#show ip dhcp snooping bindings
  - Displays MAC-to-IP bindings.

CCNP - SWITCH - Switch Security Features - DHCP Snooping

The following tools can be used to mitigate against Denial of Service attacks and Spoofing attacks.

DHCP Snooping
Feature found on Catalyst switches, DHCP snooping prevents attacks against DHCP servers by monitoring which ports are allowed to pass DHCP packets.

A typical attack can be where an attacker configures a rogue DHCP server and connects it to a port on your switch. When a client sends a DHCP Request out the rogue DHCP server attempts to respond quicker than legitimate DHCP servers. The rogue DHCP server offers the client IP settings (including default gateway and DNS servers) and can then direct the client to use an Attacker's client as it's own DFG. As a result the attacker can now see all of the client's traffic.

Another type of attack can be a denial of service where the attacker floods the legitimate DHCP with 1000's of DHCP Requests it over runs the server and the server is prevented from responding to legitimate DHCP requests.

How DHCP Snooping works is that once set the switch has Trusted and Untrusted ports for DHCP traffic. A trust port is for ports connected to DHCP servers or links that allow access to DHCP servers. The Trusted port is allowed to pass all DHCP Packet types (DHCP Discover, Offer, Unicast Request, Unicast ACK).

An Untrusted port is a port that shouldn't have a DHCP server on and so only be allowed to make a request to a DHCP Server.

Once configured if a rogue device connected to a DHCP Snooping Untrusted port tries to respond to a legitimate request the switch shuts down the port.

Configure DHCP Snooping
DHCP Snooping is enabled globally:
  SW1(config)#ip dhcp snooping

By default all interfaces are untrusted and you define your trusted ports:
  SW1(config-if)#ip dhcp snooping trust

Optionally, on Untrusted ports you can limit the number of DHCP packets allowed per second:
  SW1(config-if)#ip dhcp snooping limit rate [rate]
     - this command can prevent DHCP Starvation attacks where are available leases are used up.

Finally, you can configure DHCP Snooping on specific VLANs:
  SW1(config)#ip dhcp snooping vlan number [id]

Verifiy DHCP Snooping
Use the command:
  SW1#show ip dhcp snooping
    - displays state of dhcp snooping, configured VLANs, configured interfaces, any rate limiting in effect.