Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Tuesday, March 6, 2012

No Port for You! Using Cisco Port Security

Most Cisco switches support a feature known as Port Security.  Port security gives the network engineer the ability to have more granular control as to what device(s) can be plugged into a switch port.  There are a couple of usual use cases for Port Security.

Uses for Port Security

The first use case is to block unauthorized hubs, switches or access points from being used on the network.  In this scenario, Port Security is configured to allow a set number of MAC addresses to come from a certain port.  In most cases it would be set to two, one for the PC and one for the IP phone.  Any MAC addresses past the first two seen would either be denied access to the network or cause the port to be err-disabled (more on the violation modes later).  The allowed MAC addresses can either be statically assigned, dynamically learned, or dynamically learned and made permanent.

The other use case is to ensure that a secure piece of equipment like a credit card reader or biomedical device is the only device able to use the port.  In this case, the port is usually setup for a static MAC address.  Any other hosts are subject to the configured violation mode setup on the port.  If needed, more than one MAC address can be statically assigned to a single port.

Configuring Port Security


Now let's take a look at how Port Security is configured on a switch port.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address 0000.aaaa.bbbb
SWITCH(config-if)#switchport port-security violation restrict
The first command after entering interface configuration turns Port Security on for the port.  Next, the MAC address to be allowed is configured.  Finally the last line sets the violation mode to protect.  There are three modes: protect, restrict and shutdown.
  • Protect - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC addresses and note the violation in the logs.  The port also stops learning MAC addresses even if the violation is only for a VLAN.  As such Cisco does not recommend this mode.
  • Restrict - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC address, note the violation in the logs, and send an SNMP trap. This is the recommended mode from Cisco versus Protect.
  • Shutdown - When a violation of the Port Security rules is detected, the port is put into err-disabled state until either the engineer clears the port or the timer expires if errdiable recovery is configured.
Sticky MAC Addresses

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address sticky
SWITCH(config-if)#switchport port-security violation restrict
This example is very similar to the first, but you will notice that instead of a MAC address, the keyword sticky is substituted. This configures the port such that the first MAC address it learns will become the secure MAC address for the port until changed by the network engineer.  All other MAC addresses learned will be considered in violation.  There is an implied default configuration of "switchport port-security maximum 1" in this configuration that limits the port to one mac address learned.  If you wanted to let the port have more than one sticky MAC address, enter the command "switchport port-security maximum <number>".

Aging MAC Addresses

Another twist on dynamically learned MAC addresses is to use aging to limit the number of devices on a port, but not necessarily restrict devices based on the MAC address.  In this configuration the port is set to limit the number of MAC addresses allowed, but as MAC addresses are no longer seen for a set type they are aged out allowing new MAC addresses to be added to the port without a violation.  The aging can either be absolute or based on inactivity.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 480 type absolute
SWITCH(config-if)#switchport port-security violation restrict
In the above example, the port is set to age out a MAC address after 480 minutes go by regardless of activity.

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 10 type inactivity
SWITCH(config-if)#switchport port-security violation restrict
This example shows the configuration to have the MAC address aged out 10 minutes after the last activity.

Wrap Up


While Port Security is a very powerful tool, I have not seen it as widely deployed as one would think.  I think part of that is lack of awareness and the other part is fear of taking down a production port automatically.  With the right planning and knowledge, both can be overcome. I really suggest people consider adding Port Security to their port activation templates.  Even if it is just to stop unauthorized hubs, switches and access points, there is definite benefit.

Thursday, October 27, 2011

Network Egress Filtering

Today I volunteered to give a quick presentation on the importance of egress filtering to a wonderful group of education IT folks. Below is the slide deck that I used for the presentation for anyone that might find it interesting.


Thursday, March 31, 2011

Using Cisco Wireless Lan Controllers for a Wired Guest Network

Most people are familiar with using Cisco's mobility anchors to provide a wireless guest network.  The usual topology is that you have a controller with CAPWAP access points connected to it and then a foreign "anchor" controller that is located in the DMZ.  Between the two controllers traffic is tunneled to logically separate the traffic from the rest of the regular network. In this way guest traffic can be effectively managed while keeping internal resources secure.

The same separation can be achieved for a wired guest LAN by using the same WLC architecture.  Setting it up requires the following:

  • The WLC inside the network must have it's interface setup as a dot1q trunk to handle multiple VLANs
  • UDP Port 16666 or IP Protocol 97 must be able to pass through the firewall between the inside WLC and the anchor WLC.
  • A dedicated L2 VLAN for the guest wired network
  • Mobility Groups are already configured on the WLCs.
  • DHCP configured on the Anchor Controller
Configure the Ports

First go to the switch connected to the local WLC and do the following assuming that the WLC is connected to Gi1/0/1 and the new guest wired vlan is 601


switch#configure t
switch(config)#interface Gi1/0/1
switch(config-if)# switchport trunk allowed vlan add 601
Next go to the switch connected to the access port(s) that you want on the guest wireless and do the following:

switch#configure t
switch(config)#interface range gi2/0/1 - 5
switch(config-if-range)# switchport access vlan 601
 Configure the Local WLC


Login to the local WLC web GUI and go to Controller and then Interfaces and click New.  This will bring you to the following screen where you give the Interface a name and tell it what VLAN it should be on.  


Once the information is entered, click apply.  This will bring you to another settings page for the new interface.  In this screen you need to click the box marked Guest LAN and then click Apply.


Now go to WLAN and then click Go next to where it says Create New.  This will bring you to the following screen where you will choose type Guest LAN and give the profile a name.


Clicking Apply will bring you to the WLANs Edit screen for the new profile.  Here there are a few choices to be made about security.  The default is that users will need to login using web authentication if they want onto this guest network.  This requires that you have either setup local usernames and passwords, perhaps through the lobby ambassador setup, or have guest accounts through AAA.  For this example I will use the Web Passthrough option with makes the user accept an acceptable use policy before gaining access.  On the general tab I clicked enable and chose the guest-wired-lan interface that we created earlier as the Ingress Interface.


Next I clicked on the Security Tab and Layer 3 Tab to change the Layer 3 Security to Web Passthrough.  Note that you also have the ability to require web passthrough users to give you their e-mail address, but it doesn't validate it is a real address.


Once you click Apply you will be back to the WLANs list page.  On the right side of the page there is a blue box with a white down arrow next to the WLAN profile we created.  Hover over it and choose Mobility Anchors.  Once you're in that page you will choose the IP of the foreign anchor controller from the drop down and then click Mobility Anchor Create.


This completes the configuration of the local WLC.


Configure the Anchor Controller


Login to the anchor controller and click on WLANs and then Create a new WLAN profile just like the one on the Local Controller above except that the ingress interface is None and don't click enabled.  Once you click apply, go to the mobility anchors for the new profile and make sure the Switch IP Address is set to (local) and click mobility anchor create.  Once you have done this, you can go back to the profile screen and check enabled.  


Wrap Up


This article is a rather whirlwind how to of setting up a guest wired network using the Cisco Wireless LAN Controllers.  There are many intricacies not discussed here, but there are plenty of good documents on Cisco's website about how to configure the WLCs.  I do have a question for anyone from Cisco or a wireless guru.  If you have multiple WLCs on the local LAN, can you have the same wired guest vlan piped to all of them or do you have to have a different vlan for each controller?  If you can have the same vlan, how does the traffic know which controller to associate with?







Thursday, March 17, 2011

PKI Uncovered Book Review

I have recently had the chance to read the new Cisco Press book PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks  by Andrew Karamanian, Srinivas Tenneti, and Francois Dessart.  I will admit that Public Key Infrastructure (PKI) has been something of a double sided sword for me for some time.  I know that PKI is important for securing network resources, but I have also had the belief that certificate based security was a royal pain to implement.


This book took me through the basics of PKI in a manner that made a lot of concepts seem less complicated than I had made them out to be.  The step by step explanations of setting up PKI in a Cisco IOS world were well designed and presented.  Later on in the book the authors proceeded into more complex real world examples of VPNs and 802.1x scenarios based on the building blocks from the beginning of the book.  I am definitely going to keep this book on my quick reference shelf as I move forward with 802.1x and WPA2-Enterprise in my network.