Securing Our Switches: Banners and Best Client Practices


For legal reasons, use a login banner to tell any potential hacker that you shouldn’t be doing this!

banner motd – Message Of The Day (MOTD) is the most commonly used banner 
banner login
banner exec – will appear after someone successfully authenticates

HTTP Security

ip http server
ip http authentication local
ip http secure-server

Generating 1024 bit RSA keys!

Real World Security Plans, Concerns and Conversations

Define realistic expectations with your client! Security doesn’t protect FOREVER. Document an agreement and timeframe.

Even with Auto Secure/One Step Lockdown, Cisco doesn’t guarantee security, but they have done everything they can.

Don’t Just Jump In


  1. Test your solution in a lab
  2. Run an audit/create a network diagram
  3. Take an incremental approach
  4. Have an emergency rollback plan
  • Create a definitive security policy. Put in writing what will and wont be allowed. What actions will be performed when undesirable behaviour takes place?
  • Create an incident response plan. Have a plan in place to handle it and ensure updates as time goes by.

Securing Our Switches: MAC Address Flooding,VLAN Hopping,CDP,Telnet and SSH.

MAC Address Flooding Attacks

A MAC Address Flooding attack is an attempt by a network intruder to overwhelm the switch memory reserved for maintenance of the MAC address table. The intruder generates a large number of frames with different source MAC addresses – all of them invalid. As the switch’s MAC address table capabilities are exhausted, valid entries cannot be made – and this results in those valid frames being broadcast instead of unicast.

This has three side effects, all unpleasant:

  • As mentioned, the MAC address table fills to capacity, preventing legitimate entries from being made.
  • The large number of unnecessary broadcasts quickly consumes bandwidth as well as overall switch resources
  • The intruder can easily intercept packets with a packet sniffer, since the unnecessarily broadcasted packets will be sent out every port on the switch – including the port the intruder is using.

You can combat MAC Address Flooding with two of the features we addresses earlier in this section – port-based authentication and port security.

VLAN Hopping

Double Tagging – Takes advantage of the Native VLAN, a rogue host will transmit a frame with 2 VLAN IDs, the Native VLAN and a genuine VLAN. A trunk on the switch will remove the native VLAN tag, but transmit the frame across the trunk with the genuine VLAN tag intact and then forwarding to hosts in the genuine VLAN, this rogue host has then used the Native VLAN to hop across to the genuine VLAN

Switch Hopping – A rogue host connected to a port in Auto trunking mode, can pretend it is a switch and send DTP frames of it’s own, leading to a trunk being formed to the rogue host.

CDP and Potential Security Issues

Best practice is to disable CDP to all ports that don’t need it! Only links to other Cisco devices. (IP Phones are a interesting case).

CDP is sent in plain text and contains information about your network.

LLDP – Link Layer Discovery Protocol – Other vendors equivalent to CDP.


telnet = plain text and ssh = encrypted password and data

ssh requires a little more from the hardware

ssh can use the local database or aaa

telnet can use the line vty credentials or aaa

Specify your transport input method as ssh, telnet or all!

ssh config

  • Specify domain name
  • crypto ken generate rsa BITS (512)
  • ip ssh time-out ?
  • ip ssh authentication-retries ?

Setup an ACL and protect your VTY ports with it.

Securing Our Switches: Intro to Private VLANs

two kinds of private VLANs, primary and secondary

two kinds of secondary VLANs, community and isolated

PVLAN Hierarchy

  • promiscuous private Primary VLAN (Parent)
  • community private Secondary VLAN (Child)
  • isolated private Secondary VLAN (Child)

Example: (From Chris Bryants SWITCH study guide)


Securing Our Switches: More DHCP Snooping, ARP Inspection and IP Source Guard

DHCP Snooping allows the switch to serve as a firewall between hosts and untrusted DHCP servers. DHCP Snooping classifies interfaces on the switch into one of two categories – trusted and untrusted.

DHCP messages received on trusted interfaces will be allowed to pass through the switch. Not only will DHCP messages received on untrusted interfaces be dropped by the switch, the interface itself will be placed into err-disabled state.

By default, the switch considers all ports untrusted – which means we better remember to configure the switch to trust some ports when we enable DHCP Snooping

Assuming we have a trusted DHCP server off port 0/10, we would then trust that port with the following command:

SW1(config-if)#ip dhcp snooping trust

From your previous studies, you’re familiar with the DHCP Relay Agent Information option. Usually referred to as Option 82 (we still don’t know what happened to the first 81 options), this option can be disabled or enabled with the following command:

SW1(config)#ip dhcp snooping information option

DHCP Snooping is verified with the show ip dhcp snooping command.

Note the “rate limit” for the untrusted port is set to “unlimited”. That rate limit refers to the number of DHCP packets the interface can accept in one second (packets per second).

Dynamic ARP Inspection

Just as we must protect against rogue DHCP servers, we have to be wary of rogue ARP users as well.

From your CCNA studies, you know all about Address Resolution Protocol and how it operates. A rogue device can overhear part of the ARP process in action and make itself look like a legitimate part of the network. This happens through ARP Cache Poisoning. (This is also known as ARP Spoofing – be aware of both names for your exam.)

Enabling Dynamic ARP Inspection (DAI) prevents this behavior by building a database of trusted MAC-IP address mappings. This database is the same database that is built by the DHCP Snooping process, and static ARP configurations can be used by DAI as well.

DAI uses the concept of trusted and untrusted ports, just as DHCP Snooping does. However, untrusted ports in DAI do not automatically drop ARP Requests and Replies.

Once the IP-MAC address database is built, every single ARP Request and ARP Reply received on an untrusted interface is examined. If the ARP message has an approved MAC-IP address mapping, the message is forwarded appropriately; if not, the ARP message is dropped.

If the interface has been configured as trusted, DAI allows the ARP message to pass through without checking the database of trusted mappings. DAI is performed as ARP messages are received, not transmitted.

SW1(config)#ip arp inspection ?
filter Specify ARP acl to be applied
log-buffer Log Buffer Configuration
validate Validate addresses
vlan Enable/Disable ARP Inspection on vlans

 show ip arp inspection

Cisco’s recommended trusted/untrusted port configuration is to have all ports connected to hosts run as untrusted and all ports connected to switches as trusted.

IP Source Guard

We can use IP Source Guard to prevent a host on the network from using another host’s IP address. IP Source Guard works in tandem with DHCP Snooping, and uses the DHCP Snooping database to carry out this operation.

The switch will then dynamically create an VLAN ACL (VACL) that will only allow traffic with the corresponding source IP address to be processed by the switch. This IP address-to-port mapping process is called binding.

To enable IP Source Guard, use the ip verify source vlan command on the appropriate interfaces once DHCP snooping has been enabled with ip dhcp snooping.

Securing Our Switches: The Many Details Of SPAN, VACL + Intro To DHCP Snooping

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.

SPAN works fine if the source and destination ports are on the same switch, but realistically, that’s not always going to happen. What if the 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:

  • If there were intermediate switches between the two shown in the above example, they would all need to be RSPAN-capable.
  • VTP treats the RSPAN VLAN like any other VLAN. It will be propagated throughout the VTP domain if configured on a VTP server. Otherwise, it’s got to be manually configured on every switch along the intermediate path. VTP Pruning will also prune the RSPAN VLAN under the same circumstances that it would prune a “normal” VLAN.
  • MAC address learning is disabled for the RSPAN VLAN.
  • The source and destination must be defined on both the switch with the source port and the switch connected to the network analyzer, but the commands are not the same on each.

After all that, the configuration is simple! Create the VLAN first, and identify it as the RSPAN VLAN with the remote-span command.

SW2(config)#vlan 30


SW2 is the source switch, and the traffic from ports 0/1 – 0/5 will be monitored and frames mirrored to SW1 via RSPAN VLAN 30.

SW2(config)#monitor session 1 source interface fast 0/1 – 5

SW2(config)#monitor session 1 destination remote ?

vlan Remote SPAN destination RSPAN VLAN

SW2(config)#monitor session 1 destination remote vlan 30 % Incomplete command.

SW2(config)#monitor session 1 destination remote vlan 30 ? reflector-port Remote SPAN reflector port

As you see, naming the RSPAN VLAN here doesn’t finish the job. We now have to define the reflector port, the port that will be copying the SPAN traffic onto the VLAN.

SW2(config)#monitor session 1 desti remote vlan 30 reflector-port fast 0/12

SW1 will receive the mirrored traffic and will send it to a network analyzer on port 0/10.

SW1(config)#monitor session 1 source remote vlan 30

SW1(config)#monitor session 1 destination interface fast 0/10

Source port notes:

  • A source port can be monitored in multiple, simultaneous SPAN sessions.
  • A source port can be part of an Etherchannel.
  • A source port cannot be configured as a destination port.
  • A source port can be any port type – Ethernet, FastEthernet, etc.

Destination port notes:

  • A destination port can be any port type.
  • A destination port can participate in only one SPAN session.
  • A destination port cannot be a source port.
  • A destination port cannot be part of an Etherchannel.
  • A destination port doesn’t participate in STP, CDP, VTP, PaGP, LACP, or DTP.


Even though a VACL will do the actual filtering, an ACL has to be written as well. The ACL will be used to as the match criterion within the VACL.

For example, let’s say we have the subnet /24’s addresses configured on hosts in VLAN 100. The hosts – 3 are not to be allowed to communicate with any other hosts on the VLAN, including each other. An ACL will be written to identify these hosts.

SW2(config)#ip access-list extended NO_123_CONTACT

SW2(config-ext-nacl)#permit ip

Notice that even though the three source addresses named in the ACL are the ones that will not be allowed to communicate with other hosts in the VLAN, the ACL statement is permit, not deny. The deny part is coming!

Now the VLAN access-map will be written, with any traffic matching the ACL to be dropped and all other traffic to be forwarded.

Note that the second access-map clause has no match clause, meaning that any traffic that isn’t affect by clause 10 will be forwarded. That is the VACL equivalent of ending an ACL with “permit any”. If you configure a VACL without a final “action forward” clause as shown below, all traffic that does not match a specific clause in the VACL will be dropped.

SW2(config)# vlan access-map NO_123 10

SW2(config-access-map)# match ip address NO_123_CONTACT

SW2(config-access-map)# action drop

SW2(config-access-map)# vlan access-map NO_123 20

SW2(config-access-map)# action forward

Finally, we’ve got to apply the VACL. We’re not applying it to a specific interface – instead, apply the VACL in global configuration mode. The VLAN to be filtered is specified at the end of the command with the vlanlist option.

SW2(config)# vlan filter NO_123 vlan-list 100

A routing ACL can be applied to a SVI to filter inbound and/or outbound traffic just as you would apply one to a physical interface, but VACLs are not applied in that way – they’re applied in global configuration mode.

On L3 switches, you may run into a situation where there’s a VACL configured, and a “normal” ACL affecting incoming traffic is applied to a routed port that belongs to that same VLAN. In this case, packets entering that VLAN will be matched against the VACL first; if the traffic is allowed to proceed, it will then be matched against the inbound ACL on that port.

DHCP Snooping

DHCP messages received on untrusted interfaces be dropped by the switch, the interface itself will be placed into err-disabled state.

Securing Our Switches: Port Security Labs, Intro to Dot1x Authentication and SPAN

There is no penalty for hitting the limit of secure addresses – it just means the switch can’t learn any more secure addresses.

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

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.

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!

  • 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.)

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.

  •  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.


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.

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.




Securing Our Switches: Security Fundamentals, Databases and Port Security

Different privilege levels – not every user needs the same level of access to potentially destructive commands, because not every user can handle the responsibility.

Cisco switches have more VTY lines than routers. Routers allow up to five simultaneous Telnet sessions, and obviously switches allow more!

The username / password command allows the assignment of privilege levels. If none is specified, level 0 is the default.

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.

Port security can’t be configured on a port that even has a possibility of becoming a trunk 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.

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.