Bulldogs,
I've included a bonus section on AAA in this book - please read that along
Passwords
Port Security
Dot1x Port-Based Authentication
SPAN Basics
Local SPAN
Remote SPAN
SPAN Limitations
VLAN Access Control Lists
Private VLANs
DHCP Snooping
Dynamic ARP Inspection
IP Source Guard
MAC Address Flooding
Dealing With Your Clients In The Real World
with this section. Thanks! -- Chris B.
When we think of network security, we tend to focus on protecting our network from attacks originating outside the network.
That's half the battle - but it's important to remember that many successful network attacks are launched from the inside, and from some seemingly innocent sources, such as...
DHCP ARP
Rogue switches (Switches acting as part of our network, but under the administrative control of a potential network attacker)
CDP Telnet
Unauthorized MAC addresses Hosts on the same VLAN (!)
So while it's wise to protect our network from the outside, we better take some measures to protect us from.. the enemy within.
(Cue dramatic music.)
Seriously, we've got some important work to do here - so let's get to it.
The first methods of security I'm going to talk about in this chapter aren't fancy, they aren't exciting, and they don't cost an arm and a leg. But the basic security features are the ones to start with, and I use a four-step approach to basic network security:
1. Physical security - lock those servers, routers, and switches up!
This is the most basic form of network security, and it's also the most ignored.
2. Passwords - set 'em, change 'em on occasion. If you're relatively new to a particular job site, be ready for a fight on this point from other admins.
3. Different privilege levels - not every user needs the same level of access to potentially destructive commands, because not every user can handle the responsibility.
4. Grant remote access only to those who absolutely, positively need it -- and when users do connect remotely, make that communication as secure as possible.
Physical security is just that. Get the routers and switches locked up!
Steps two and three go hand in hand, and much of what follows may be familiar to you. Don't skip this part, though, because we're going to tie in privilege levels when it comes to telnet access.
You know how to configure the basic passwords on a switch:
SW2(config)#enable password ccna SW2(config)#enable secret ccnp
SW2(config)#line con 0 SW2(config-line)#login
% Login disabled on line 0, until 'password' is set SW2(config-line)#password ccie the enable secret. The command service password-encryption will encrypt the remaining passwords.
The login message shown when the login command is used in the above example simply means that a password needs to be set to enable this feature. As long as you enter both the login and password commands, it does not matter in what order you enter them.
Cisco switches have more VTY lines than routers. Routers allow up to five simultaneous Telnet sessions, and obviously switches allow more!
The default behavior is the same, however. Any user who telnets in to the switch will be placed into user exec mode, and will then be prompted for the proper enable mode password.
If neither the enable secret nor the enable password has been set, the user will not be able to enter enable mode.
To place users coming into the switch via telnet straight into enable mode, use the command privilege level 15 under the VTY lines.
SW2(config-line)#privilege level 15
Note below how the configuration appears on the switch when it comes to the VTY lines. If you want a command to be applied to all 16 lines, you
The possible issue here is that any user who telnets in will be placed into enable mode.
It's easy to configure, but maybe we don't want to give that high level of access so easily.
Consider a situation where a tech support person has to telnet into a router. Maybe they know what they're doing, and with all due respect, maybe they don't. Do you want this person making changes to the router without you knowing about it? It may be better to assign privilege level 15 to yourself while assigning the default value of 0 to others.
I also don't like having one password for all telnet users. I prefer a scheme where each individual user has their own password.
Creating a local database of users and privilege levels allows us to do this, and it's a simple procedure. As a matter of fact, you already did this at least once during your CCNA studies. All you have to do is create a username / password database the same way you create one for PPP authentication.
SW2(config)#username CBRYANT privilege 15 password CCIE SW2(config)#username WMCDANIEL password CCNP
SW2(config)#username BMULLIGAN password CCNA
SW2(config)#line vty 0 15 SW2(config-line)#login local
The username / password command allows the assignment of privilege levels. If none is specified, level 0 is the default. With the above configuration, the first user would be placed into privileged exec mode when connecting via telnet, while the other two users would be required to enter the enable password before they could enter that mode.
The login local command is required to have the switch look to a local database for authentication information. If a user doesn't know their username/password combination, they can't telnet into this switch.
Port Security
Here's another basic security feature that's regularly overlooked, but is very powerful. Port security uses a host's MAC address as a password...
... and if the port receiving this frame is running port security and expects frames with that particular MAC address only, frames from this host would be accepted.
However, if a device with a different MAC address sends frames to the switch on that port, the port will take action - by default, it will shut down and go into error-disabled state. By default, that state requires manual intervention on the part of the network admin to reopen the port.
The switchport port-security command enables this feature, and then we have quite a few options to consider.
SW2(config)#int fast 0/5
SW2(config-if)#switchport port-security
Command rejected: Fa0/5 is not an access port.
SW2(config-if)#switchport mode access SW2(config-if)#switchport access vlan 10
Before we can consider the options, we have to make the port in question
a non-trunking port. Port security can't be configured on a port that even has a possibility of becoming a trunk port. Configuring a port as an access port is the equivalent of turning trunking to "off".
Now, let's get back to those options!
SW2(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address
maximum Max secure addresses violation Security violation mode <cr>
The first option to consider is the maximum value. This is the maximum number of secure MAC addresses allowed on the port. This number can vary - I've seen Cisco switches that would allow up to 1024, but this 2950 will only allow 132. These addresses can be configured statically with the mac-address option, they can be learned dynamically, or you can allow a port to do both. (More on that in just a moment.) with a non-secure MAC address arrive on the port.
The default port security mode is shutdown, and it's just what it sounds like - the port is placed into error-disabled state and manual intervention is needed to reopen the port. An SNMP trap message is also generated.
(You can also use the errdisable recovery command to specify how long the port should remain in that state before the switch itself resets the port.)
SW2(config-if)#switchport port-security violation ? protect Security violation protect mode
restrict Security violation restrict mode shutdown Security violation shutdown mode
Protect mode simply drops the offending frames. Restrict mode is our middle ground - this mode drops the offending frames and will generate both an SNMP trap notification and syslog message regarding the violation, but the port does not go into err-disabled state.
Before we continue, a note of caution - throughout this course, you'll see ports shut down for one reason or another, particularly in the Advanced STP section. Note that not all of these features force the port into err-disabled mode. Be sure you're very familiar with the different states these ports are put into. (I'll have a chart at the end of that section listing each port state.)
Let's take a look at the console messages you'll see when running port security in its default mode, shutdown. I configured a port on this switch with port security, one secure MAC address, and made sure it didn't match the host that would be sending frames on that port. Sure enough, within seconds all of this happened:
SW1(config-if)#
05:06:04: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/7, puttingFa0/7 in err-disable state
05:06:04: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 000f.f773.ed20 on port FastEthernet0/7.
05:06:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/7, changed state to down
05:06:06: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state to down
show interface verifies that this interface is in error-disabled state.
SW1#show int fast 0/7
FastEthernet0/7 is down, line protocol is down (err-disabled)
That port must now manually be reopened - of course, after resolving the security issue that brought it down in the first place!
There is a little "gotcha" with port security that you need to be aware of.
You can specify the number of secure MAC addresses, and you can specify secure MAC addresses as well. What if you allow for more secure MAC address than you actually configure manually, as shown below?
SW1(config-if)#switchport port-security connected to that port right now, port security would allow it. Be careful!
In that configuration, these three addresses would be considered secure:
aa-aa-aa-aa-aa-aa cc-cc-cc-cc-cc-cc
The next dynamically learned MAC address
There is no penalty for hitting the limit of secure addresses - it just means the switch can't learn any more secure addresses.
To verify your port security configuration, run show port-security interface.
SW1#show port-security interface fast 0/2
Last Source Address:Vlan : 0000.0000.0000:0 Security Violation Count : 0
The violation mode here is the default, shutdown. In this scenario, the port will be shut down if the number of secure MAC addresses is reached and a host whose MAC address is not among those secure addresses connects to this port.
Note that "aging time" is set to zero - that actually means that secure MAC addresses on this port will never age out, not that they have zero minutes before aging out. You can change this value with the switchport port-security aging command. This particular switch accepts the value set in minutes; many older models want this entered in seconds. Always use IOS Help to double-check a command's metric!
SW1(config-if)#switchport port-security aging time ?
<1-1440> Aging time in minutes. Enter a value between 1 and 1440
The aging type value determines whether a secure MAC address will absolutely expire after a certain amount of time, or whether aging should be based on inactivity ... as IOS Help shows us!
SW1(config-if)#switchport port-security aging type ? absolute Absolute aging (default)
inactivity Aging based on inactivity time period
Port security is a great feature, but you can't run it on all ports. There are a few port types that you can't configure with port security:
trunk ports
ports placed in an Etherchannel
destination SPAN port
802.1x ports
Why Make Addresses "Sticky"?
We know a MAC address can be dynamically learned by the switch as secure, and we may want that address marked as secure in the running configuration. To do so, enable sticky learning with this command:
switchport port-security mac-address sticky
Why use sticky addresses? Along with MAC address flooding, network intruders can use a spoofed MAC address to gain access to the network.
By configuring sticky learning, the dynamically learned secure MAC addresses are written to the running configuration, which in turn helps to prevent unauthorized network access via MAC spoofing.
Note: To save these dynamically learned static addresses to the startup configuration, you'll need to copy the run config over the startup config before reloading the switch.
Dot1x Port-Based Authentication
Port security is good, but we can take it a step further with dot1x port-based authentication. The name refers to IEEE 802.1x, the standard upon which this feature is based. Unusually enough, the Cisco authentication server must be RADIUS - you can't use TACACS or TACACS+.
One major difference between dot1x port-based authentication and port security is that both the host and switch port must be configured for 802.1x EAPOL (Extensible Authentication Protocol over LANs). That's a major departure from many of the switch features we've studied to date, since most other switch features don't require anything of the host. Usually the PC isn't aware of what the switch is doing, and doesn't need to know. Not this time!
Keeping those rules in mind, a typical dot1x deployment involves:
A dot1x-enabled PC, the supplicant
A dot1x-enabled switch, the authenticator
A RADIUS server, the authentication server (You cannot use a TACACS+ server for this purpose.)
But it's not quite as simple as that. (You were waiting for that, right?)
The PC has a single physical port connected to the switch, but that physical port is logically divided into two ports by dot1x - the controlled and uncontrolled ports.
Unlike the subinterfaces you've studied and created to date, you and I as the network admins do not have to configure the controlled and uncontrolled ports. Dot1x will take care of that - of course, as long as we remember to configure the supplicant for dot1x to begin with!
The controlled port cannot transmit data until authentication actually takes place. The uncontrolled port can transmit without authentication, but only the following protocols can be transmitted:
Extensible Authentication Protocol over LANs (EAPOL) Spanning Tree Protocol (STP)
Cisco Discovery Protocol (CDP)
By default, once the user authenticates, all traffic can be received and transmitted through this port.
To configure dot1x, AAA must first be enabled. As with previous configurations, a method list must be created. And again, as with previous configurations, you should use line as the last choice, just in case something happens regarding your login with the other methods.
SW2(config)#aaa new-model
SW2(config)#aaa authentication dot1x ? WORD Named authentication list.
default The default authentication list.
SW2(config)#aaa authentication dot1x default ?
enable Use enable password for authentication.
group Use Server-group
line Use line password for authentication.
local Use local username authentication.
local-case Use case-sensitive local username authentication.
none NO authentication.
To enable dot1x on the switch:
SW2(config)#dot1x ?
system-auth-control Enable or Disable SysAuthControl
Dot1x must be configured globally, but every switch port that's going to run dot1x authentication must be configured as well.
SW2(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
Force-authorized, the default, does just what it sounds like - it forces the port to authorize any host attempting to use the port, but authentication is not required. Basically, there is no authentication on this port type.
A port in force-unauthorized state literally has the port unable to authorize any client - even clients who could otherwise successfully authenticate!
The auto setting enables dot1x on the port, which will begin the process as unauthorized. Only the necessary EAPOL frames will be sent and received while the port's unauthorized. Once the authentication is complete, normal transmission and receiving can begin. Not surprisingly, this is the most common setting.
SPAN Operation And Configuration
We've secured the ports, but there will also come a time when we want to connect a network analyzer to a switch port. A common situation is illustrated below, where we want to analyze traffic sourced from the three PCs. To properly analyze the traffic, the network analyzer needs a copy of every frame the hosts are sending - but how are we going to get it
there?
SPAN allows the switch to mirror the traffic from the source port(s) to the destination port to which the network analyzer is attached. (In some Cisco documentation, the destination port is referred to as the monitor port.)
SPAN works very well, and the basic operation is simple. Studying SPAN for exams and network usage can seem complicated at first, though, because there are several different versions of SPAN.
The versions are much the same, though; the real difference comes in when you define the source ports. It's the location of the source ports that determines the SPAN version that needs to run on the switch.
In the above example, we're running Local SPAN, since the destination and source ports are all on the same switch. If the source was a VLAN rather than a collection of physical ports, VLAN-based SPAN (VSPAN) would be in effect.
The command monitor session starts a SPAN session, along with allowing the configuration of the source and destination. The sessions are totally separate operations, but the number of simultaneous sessions you can run differs from one switch platform to another. Cat 3550s and
2950s support only two, but more powerful switches can run as many as 64 sessions at once.
SW2(config)#monitor session ? <1-2> SPAN session number
SW2(config)#monitor session 1 ?
destination SPAN destination interface or VLAN source SPAN source interface, VLAN
SW2(config)#monitor session 1 source ? interface SPAN source interface remote SPAN source Remote
SW2(config)#monitor session 1 source interface ? FastEthernet FastEthernet IEEE 802.3
Port-channel Ethernet Channel of interfaces
SW2(config)#monitor session 1 source interface fast 0/1 - 5 , Specify another range of interfaces
- Specify a range of interfaces
both Monitor received and transmitted traffic rx Monitor received traffic only
tx Monitor transmitted traffic only <cr>
Here, ports fast 0/1 - 0/5 have been configured as the source. By default, traffic being received and transmitted will be mirrored, but this can be changed to received traffic only and transmitted traffic only as shown above.
Using the same session number, the traffic will be mirrored to the
destination port 0/10. Verify the SPAN configuration with show monitor.
SW2(config)#monitor session 1 destination interface fast 0/10
SW2#show monitor traffic to be monitored is on one switch, but the only vacant port available is on another switch?
Remote SPAN (RSPAN) is the solution. Both switches will need to be configured for RSPAN, since the switch connected to the PCs will need to send mirrored frames across the trunk. A separate VLAN will be created that will carry only the mirrored frames.
RSPAN configuration is simple, but there are some factors you need to consider when configuring RSPAN:
RSPAN configuration is simple, but there are some factors you need to consider when configuring RSPAN: