Cincinnerdi Tech Stuff

A mind-numbing read if ever there was one

Archive for the ‘CCNP’ Category

Port-Security: Devil in the “sticky” details?

with one comment

Cisco’s port-security feature in its switches can restrict a switchport to a single, learned MAC address, potentially preventing such security issues as:

  • A user bringing in their own router, switch or hub to create a rogue network.
  • A user unplugging their corporate PC and plugging in an unauthorized laptop.
  • Unauthorized use of a virtual machine (VM) on a PC which creates a new MAC address

It’s easy to see that the VM – Parallels in this case – uses a separate MAC address for its separate IP in the following screen shot:

We can mitigate problems from normal, non-hacker users; presumably hackers could spoof a laptops MAC address. Shoot, I can even plug in my old Linksys NAT router, have it “clone” my PC’s mac address and it will be able to circumnavigate all of the above listed exploits. But, it does afford some level of protection, so off we go…

Last time the Sticky wasn’t working quite right (thanks to errors in Cisco book!):

“During this practice setup, I found that the 3550 switch DID restrict use of multiple MACs it didn’t learn a “Sticky MAC” address and permitted me to swap out one PC for another. Though I followed Cisco’s instructions (ISBN-10: 1-58720-171-2) where it indicates that Sticky Learning is the default. However, later research on the Cisco web site indicates it’s not (see Note 1 below). I’ll try the switchport
port-security mac-address sticky command next time.”

So this time I used the right IOS, so we get to see some security in action.

Note: The running-config is actually changed to add new “sticky” lines with the actual mac addresses added “…sticky  ####.####.####” 

Also, I’ll note here, I attempted to proceed with DAI (Dynamic ARP Inspection) but the switch’s CLI simply returned an error that the ip arp… command is invalid. Also, the use of ip source binding was also unavailable. Hmmm. Our switches are running IOS Release 12.1Cisco’s web site shows this command supported on a 3550 using Cisco IOS Release 12.2(35) SE (See web page). Administration so far refuses to upgrade the IOS release (sigh!)

Now on to the blow-by-blow account of Port-security: Read the rest of this entry »

Written by scottledyard

2007, April 14th at 9:53 pm

Posted in CCNP, Cisco, Cisco Switches

Pretty severe penalty for excessive DHCP-ing

with one comment

Cisco allows you to monitor any switchport to limit the rate of DHCP client activity. Presumably, someone flooding a network with spurious DISCOVER packets could give a DHCP server headaches.

I figured extra packets would just be dropped, but was in for somewhat of a shock when the port was placed into a permanent ERR-DISABLE status. That means a SysAdmin would need to reset the port manually, unless other provisions were made.

So what’s reasonable number of packets per minute? Maybe 3? I set it to 2 to see what the result. Pretty drastic!

The IOS: Read the rest of this entry »

Written by scottledyard

2007, April 11th at 9:28 am

Firing up a Fresh 3550 Switch using Auto-configuration

leave a comment »

ciscologo.gif

Don’t look here if you’re hoping to actually see a “how-to.” Here’s a link to Cisco page on Switch Auto-Configuration. (I haven’t gone through it, but from what I read I wouldn’t assume it’s going to be easy. Looks like it’s easy on the switch; but you have to configure a ton of stuff!)

So the point of this posting is just to show what displays on your console if you reload or start the switch after erasing the startup-config and a DHCP server happens to be attached. What’s not apparent from the listing is that there will be endless console messages showing attempts to reach a config server.

— System Configuration Dialog — Read the rest of this entry »

Written by scottledyard

2007, April 7th at 10:27 am

Mitigating IP DHCP Snooping

leave a comment »

OVERVIEW – Where Cisco’s DHCP Snooping is used to prevent a rogue DCHP server from offering up bad IPs or worse a bad gateway

Lab 03312007

My daughter’s school gives every student two different ID numbers to use. It’s so confusing for her as to which one to use when. In the same manner, allowing a second DHCP on a subnet segment is apt to confuse many host PCs and the users too. Any home router or a Windows Shared Internet or a distro of Linux can easily be setup as a DHCP server, plugged into your network and begin the confusion.

Worse, if a malicious hacker wants to intercept all packets on a network, browse them and send them on their way, setting up a rogue DHCP server, which can define the gateway IP as itself, is one way to do it (i.e., a man in the middle attack.)

Fortunately, Cisco switches allow you to mitigate either the accidental or intentional danger by defining one or more ports on a switch that can be trusted to dole out IP using DHCP. All ports in a VLAN are initially flagged as untrusted for any DHCP offers, then you may indicate which are to be trusted. We will use the global config command ip dhcp snooping to turn it on. Then we’ll use interface commands to set it up for various ports.

I learned a bit more about the somewhat mysterious background workings of DHCP. And frankly, some mysteries continue. Watching WireSharksniff packets provides a clearer idea as to what’s going on. When a client attempts to renew an IP lease (at half way thru its duration) I believe it uses a direct unicast with the original server. If never answered, it will resort to a discover broadcast, trying to locate any DHCP server to offer it an IP. What seems strange though is after a host interface is forced to close down (in Linux with an ifdown command) then brought back with an ifup, the host seems to request the same IP address it had before even if it’s requesting the IP from a different DHCP server. What’s more, if there should be two DHCP servers present (an abnormal and incorrect setup) the host seems to accept (i.e., request) the IP from the original server. This would seem to indicate the need for a hacker to disable the original DHCP server or intercept any of its offers.

Now I overcame this by temporarily disconnecting the Good DHCP server and resetting the host NIC (using ifdown + ifup). The host PC then became responsive to the Rogue server. Note in the Wireshark sniff display below that both 1.1.1.7 (Rogue) and 1.1.1.11 (Good) DHCP servers offered IPs, but in the window below showing the details of the REQUEST packet that it’s accepting the Rogue offer.

Wireshark DHCP

Eric Capal says it’s because the first one doesn’t have to do an ARP request since the original server is still in the host’s ARP cache.

SETUP – Where two DHCP servers are established and the fun begins

  • Setup PC 11 (HD # 07) as DHCP server to dispense IPs 1.1.1.13-250/24
  • Setup PC07 (HD # 01) as DHCP server (rogue) to dispense IPs 1.1.1.201-210/24
  • (Oops, forgot to activate the server in Windows!)
  • Activated MST instead of PVST (see previous post) in an effort to lower the BPDUs. That didn’t work as there’s only 1 VLAN in use.
  • I messed around with Wireshark trying to get some capture filters to work. Need some training here. Want only source (not transmitted or destination) on one PCs MAC.
  • Put both DHCP servers on one net and did some ifdown/ifup commands. Seems a host will go back to its original DHCP server and use it to get its IP. Then if that one is unavailable, it goes to the other and then becomes “loyal” to that one. Capal says that’s because the first one doesn’t have to do an ARP request since that’s still in its ARP cache.
  • I was surprised to see that PC10 was leasing the 1.1.1.252 address after it was not suppose to be able to access DHCP advertisements from the rogue DHCP server. In fact it was NOT in contact with that server, it was merely re-obtaining the 252 IP from the “good” DHCP server. It was its previous IP and it was a valid IP in the “good” server’s scope of IPs. Apparently it requested the “good” server to lease that same IP even though it was originally dealt from the rogue server.

Now for the Show Run and Show IP DHCP Snooping commands: Read the rest of this entry »

Written by scottledyard

2007, March 31st at 8:44 pm

Add VTP and a 1760 router

leave a comment »

Net layout 032407

Maintaining a VLAN database is much easier using VTP, but requires some care about adding a new switch, else it might wipe out your carefully configured VLANS.

I presumed the best way was to setup ONE switch, zap the other switches revision numbers to zero, and then hook them up. But I could have hooked them all up first and then configured. Switches after THAT would have needed to have their revision # set back.

I planned to incorporate the router right into the load balanced, fault tolerant MST (Multiple Spanning Tree) switch network, but ran into a glitch when it came to the router switch ports. The switch banks added into a 1760 router are NOT full function switches, lacking any but VTP transparent mode and NO facility for any STP other than standard. Odd since the IEEE has deprecated STP in lieu of Rapid STP.

I was able to configure the router switch port, a vlan (10) to serve as an IP addressable gateway, a finally ping out to another network (4.4.4.0/24). No small feat since this required the config of the PIX 501 firewall appliances with a static route back to my net. I did get into the config of the PIX enough to see that OSPF routing protocol could be configured to make this simpler and more flexible.

Questions I still have:

An IP is listed for “who” updates VTP on the switch (see note marked ** below). Since the switches update themselves (presumably with layer 2 multicasts) I’m not sure why a layer 3 IP would be important.

VTP Setup.

Let’s take a look at the initial state of VPT on the 3550 switch that I chose to be the “leader” Read the rest of this entry »

Written by scottledyard

2007, March 25th at 10:00 am

Posted in CCNP, Cisco, Cisco Switches, MST, RSTP, STP

Cisco switches: Classic STP -> RSTP -> MST

leave a comment »


To better use switch connections that are otherwise blocked by STP, I setup 5 switches (2 distribution and 2+1 access) to support 7 VLANs with redundant links for fault tolerance.
Traditional CSTP provided for convergence after a link failed, in 52 seconds. RSTP amazingly reduced that to sub-second convergence. MST maintained that, but the lab will continue next time to carry the 7 VLANs over two different virutual switch topologies. (I did NOT use VTP with this work.) Read the rest of this entry »

Written by scottledyard

2007, March 18th at 1:37 pm

Cisco EtherChannel and dual links

leave a comment »


Last week I explored STP with a trio of switches connected in a ring. Ditto yesterday, but I added double cables between 4 ports of two of the switches and enabled a EtherChannel link. As with most labs, the core part was easy and I chewed through a lot of time trying to ping simply because I hadn’t issued a no shutdown on VLAN1!

Found a good recap of what I did with EtherChannel at this web site. He needs to point out that the cost goes from 12 up to 19 when he disconnects a line.
And at this site are some neat ideas for additional switching labs. PLUS a way to zap any vlans but VLAN1:

conf t
delete flash:vlan.dat

Anyway, here’s some documentation of what went on. Read the rest of this entry »

Written by scottledyard

2007, March 11th at 2:48 pm

%d bloggers like this: