Cisco Security Part II - Security at the port level

2. Security at the port level

A switch is used to interconnect different devices: desktops, laptops, servers, printers, other switches and so forth. By granting access to a network, an administrator increases the likelihood of a security breach as well as the vulnerability landscape. Here are three actions that can be performed:

• Connection a non-approved device. Particularly nowadays with BYOD being teh buzzword, the proliferation of personal devices that can be connected to the network has exploded.
• Abuse of the port, for example by creating a trunk that allows a device to have access to networks not supposed to be accessed directly.
• Injection of control frames into the network, for example modification of the spanning-tree topology.

Of course, there are many, many more possible attacks. However, the purpose of this document is not to enumerate everything known to mankind, as by the time this document hits the web, there will already be things to be added.

2.1 Trunk/access

When interconnecting two switches, the need to transmit frames that belong to different virtual LAN (VLAN) may arise. In order to do so, network device vendors came up with different solutions, such as ISL from Cisco. Later, the protocol to transmit multiple VLAN over a single physical connection was standardized by the IEEE as 802.1Q.

Trunking is also used in IP Telephony: the usual setup is to have the PC piggy-back on the phone, which acts as a small switch. The “normal” data traffic is sent and received as-is and the voice traffic is encapsulated within 802.1Q. This gives the ability to separate both traffics and to use additional fields in the 802.1Q header to prioritize the voice traffic over other forms of traffic.

However, if not restricted, this ability can also be a recipe for disaster. For example, if all the ports carry all the VLANs or have the ability to create a trunk, an attacker could leverage that to gain access to other networks by sending tagged frames back to the switch.

In Cisco terminology, a trunk is called a “trunk” port (obvious, isn’t it?) and a non-trunk port is called an “access” port. An access port won’t send any 802.1Q encapsulated frame to the connected device. In the receive direction, the frame will be dropped.

In order to configure a port as an access or a trunk, the command "switchport" needs to be used within the interface:

interface GigabitEthernet 0/10
 switchport mode access
This will instruct the switch to treat the port Gi0/10 as an access port.

Once a port's mode has been set, further configuration is possible. For instance, if the port is an access port, the VLAN on which that port resides can be set with:

switchport access vlan 20

Likewise, a trunk port with native VLAN (defined later) 10 and with tagged VLAN 20 and 30 is configured with:

interface GigabitEthernet0/11
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,20,30
The native VLAN on a trunk is the VLAN in which all the untagged frames received will be placed, and that will be sent untagged. Numerous documents refer to the danger of native VLAN in regard to VLAN hopping or the abuse of Q-in-Q. A good practice is to make sure the native VLAN of all your inter-switch trunks are not assigned to any user VLAN.

2.2 Negotiation of a trunk (DTP)

Cisco switches allow a trunk to be dynamically formed. This means that if you don't force the mode, the connected device can announce itself as a switch and negotiate a trunk. The protocol responsible for this is Dynamic Trunking Protocol or DTP.

With the mode forced to access, the negotiation is automatically stopped. If set to a trunk and if the negotiation is left on, the switch will use DTP to inform its peer it can form a trunk.

To disable the trunk negotiation, the command is

switchport nonegotiate

2.3 Spanning-tree

Spanning Tree is the protocol responsible for negotiating a loop-free topology, even if the physical infrastructure has loops, for example for redundancy. It works by electing a root switch, which will then send specific frames called BPDU (Bridge Protocol Data Unit) that all switches in the topology have to forward following certain rules.

Based on the BPDU and the port it was received, each switch designs a port leading to the root, possibly through other switches, a set of ports that can be used for other connected switches to reach the root, and a set of blocked ports. These are ports the switch could use to reach the root, but with a higher cost.

These BPDUs have multiple roles: they can announce a better path to the root, they are used to hold the root election and they can influence the whole topology.

From what precedes, an attacker can abuse this protocol to either perform a DoS against the network, or forward all the traffic to a specific machine.

When designing a network, it is important to minimize the role of spanning-tree by using other techniques, such as bonding multiple interfaces into a single logical interface called a port-channel or an etherchannel.

When a port comes up, the default behavior is to wait for a certain amount of time, that depends on the version of spanning-tree used, to determine what the status of the port should be (root, designated, blocked). Cisco invented a mechanism to permit the port to start forwarding before that time, called "portfast".

With that came the risk of creating short network loops,until the port got the first BPDU and adopt the relevant state.

2.3.1 bpduguard

Cisco developed a security feature to force a port to go immediately down if a BPDU is received. The BPDU will be dropped as well.

If a port is connected to a phone or a computer, there is no valid reason why a BPDU should be received. On the other hand, if a BPDU is received from a port connected to a user device, this could indicate:

• an attempt to inject BPDUs into the network, regardless of the reason;
• an temporary loop in the network due to incorrect network settings on a computer or a connectivity issue;
• a replay of a previous network capture;
• and possibly other reasons.

In such an event, a reasonable thing to do is to drop the port to the down state, to prevent further incidents. This is configured on a device interface with:

interface GigabitEthernet 0/12
 spanning-tree bpduguard enable
Upon reception of a BPDU on the port, the state will be err-disable. To correct this,the port needs to be reset (shutdown/no shutdown) or the error recovery mechanism needs to be activated. This latter is not recommended as it will put the port back in service, possibly allowing the activity to resume.

It is also worth to notice that the default for this command has changed between IOS and NX-OS: a show configuration all will display these values.

2.3.2 bpdufilter

In situations where bpduguard is not welcome, for instance on uplinks to a provider, another mechanism exists: bpdufilter. Instead of shutting the port down, bpdufilter drops all bpdus, incoming and outgoing. This has the side effect of splitting the spanning-tree domain in two.

In my past, I had to help an ISP configure it: his switch connected to his clients' frequently had issues. It was found that on some occasions, the spanning-tree root role changed from his internal network to a client's.

However, it needs to be understood that, as spanning-tree is no longer working, topology loops in this situation have to be manually addresed, for instance in the form of a manual activation, or by using techniques that negate the need for spanning-tree, such as etherchannel, or unique VLANs with a L3 redundancy solution.

The configuration looks like bpduguard's:

interface GigabithEthernet0/12
 spanning-tree bpdufilter enable

2.3.3 portfast / port type edge

The spanning-tree protocol mandates that a port goes through various states before being able to forward traffic. During these state, no traffic is received or emitted besides BPDUs.

A way to speed that process is to declare the port as "portfast" or "type edge". It means that spanning-tree will take a shortcut in the states and be able to forward quickly after being turned on.

However, this has to be gauged: on the one hand, this means that a user device will have access to the network sooner, but on the other hand, it permits the creation of temporary loops - until the next BPDU is seen, the link will be up. As soon as a BPDU arrives on the port, the normal spanning-tree decision concerning the port role (root, designated etc) is taken and one end of the loop will be blocked.

An attacker could leverage this fact to create temporary, short lived loops to disrupt the switch operations. If successful, this can create either a switch or topology wide outage.

Other ways of dealing with the timers are possible: one could use rapid spanning-tree and shorten the timers from 2 seconds to 1 for the <Hello> BPDU - as more BPDUs are sent, the expected life of a loop is cut down, limiting the risk or the possibility of perpetrating such an attack. This, however, has to be evaluated as a shorter timer may also increase the risk of instabilities on the network: a transient frame drop on a link can result in flapping between that link and a backup link, possibly amplifying the problem.

2.4 Mac address learning on a port

The role of a switch is to build a table of what mac address resides on what port, and forward frames accordingly. This allows for point-to-point communications between two devices within the same VLAN, without impacting the other connected devices. A way of describing this is to state that the collision domain is limited to the port and the device connected to it.

As the switch has to consult that table binding a MAC to a port for every frame, the memory dedicated is called CAM (Content Addressable Memory), a special type of memory which is in limited quantity in any device.

An attack of the "old days" was to generate many frames with random source MAC address. This caused the switch to learn these in its CAM, filling it to the point that no new entry could be created. Any new MAC would not be learned, and the forwarding process would be for the switch to broadcast a frame to these legit but unknown addresses to all port, transforming the switch into a hub and allowing an attacker to sniff the corresponding traffic.

2.4.1 Number of permitted mac addresses

The first line of defense offered by a switch is to limit the number of MAC addresses permitted on a given port - past the number, the switch will either drop the frame or even shut the port down. MAC address counting works with the VLAN ID included in the learning: the same address seen on the same port but on two different VLANs count as two entries, one per VLAN. This is important to understand when using devices such as IP phones that may start in a VLAN and jump to a different VLAN afterwards.

The question now is: what about forgetting the known addresses? Should the switch keep them forever? Or forward these entries after a certain time?

2.4.2 Sticky Learning

In a static world, a machine is always connected to the same port, and thus the MAC address will always be seen on the same port. In that case, a sticky learning is possible, meaning that the switch will permanently - even across reboots - remember the association.

A nice - or annoying, it depends what your goals are - feature of this memorization is that if a MAC address known on a given port is seen somewhere else as source, the frame will be dropped and a security violation logged.

2.4.3 Aging considerations

However, the world is not static: laptops move from offices to meeting rooms, workstations are installed and reused and so forth. So the concept of sticky learning doesn't work well, or one needs an army of network administrator to prune the entries as machines are being moved.

Another possibility is to enforce a certain time after which the entry will be forgotten. This time is either an idle time (no frame exchanged for a certain period) or absolute (the address is removed even if traffic is seen, leading to a renewal of the learning if need be). 

2.4.4 Actions for violations

As said, the action can be the simple drop of the frame, the drop of the frame plus logging or even to shut the port completely down.

Deciding which one is a matter of policies and will of surfacing the issues - if the only thing happening is the frame being dropped, the event may go unnoticed until a user complains he has a problem. On the other hand, if the port is shut down, a visible trace exists of the event, that can be investigated and acted upon.

2.4.5 Putting it together 

Now, time to show some configurations.

2.4.5.1 Basic port security, 3 MAC addresses, no sticky learning, drop-and-log upon violation, portfast and bpduguard, mac address forgotten after 5 minutes. 

This configuration is almost a "this is your average mileage": it will work okay in many situations.

interface gigabitEthernet 0/12
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security aging time 5
 spanning-tree portfast
 spanning-tree bpduguard enable
 [rest of the configuration]
2.4.5.2 Sticky learning, 2 MAC addresses, drop-and-log upon violation, portfast and bpduguard.

This could be used for a server. The first two mac addresses seen on the port are learnt.

interface gigabitEthernet 0/12
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 [rest of the configuration]

2.5 Recommended configurations

2.5.1 Workstation

We consider this machine to be installed at a desk and will never be moved, no phone

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.2 Laptop/meeting room

That machine may be moved between ports.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security aging time 5
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.3 Phone with computer attached

The phone starts in a VLAN and moves to the new one (voice), workstation attached

Note: the phone negotiates its voice vlan using either CDP or LLDP, but this will not be discussed in this document.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport voice vlan YY
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable

 switchport nonegotiate

2.5.4 Server / router

This considers that there is not virtual or cluster IP.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security

 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.5 Network provider / external party

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 spanning-tree portfast
 spanning-tree bpdufilter enable
 switchport nonegotiate

Cisco Switch Security - Section 1 - Management Interface

1. Management port and Interface

The management interface permits an administrator to configure the switch, check different operational parameters and alter the way frames are treated or forwarded.

There are multiple types of management interfaces:

• Direct or local interactive session, for example through a serial console
• Remote or network interactive session, for example through a SSH connection
• Management protocol, for example SNMP

1.1 Authentication

This is the act by which someone connecting will assume a specific identity, using a personal piece of information. This can be a password, a token code or one time password, a fingerprint etc. The important part is that that piece of information is sufficient to ascertain the requested identity, i.e. that no one else could have provided it.

In order to establish traceability and accounting, it is important that each administrator be given his/her own username and password.

1.1.1 Local and enable authentication

I won't talk about the old "line" passwords.

Cisco allows one to create a database of usernames using the command username. Its syntax is

username user secret password 

Where user is the given username, priv the privilege level (0 to 15, more on this below) and password the clear text password. By using the keyword secret, the password will be stored as a salted MD5 hash, which is stronger than the default password 7 based on a Vigenere Cipher.

Cisco users know the famous enable command: it grants level 15 access to the system if no other level is provided. When user tries to increase his/her privilege level, a special password is requested, that needs to be set with

enable secret password

Again, the secret keyword forces the storage to be salted and hashed using MD5.

1.1.2 Centralized authentication

Opposed to the local authentication, on which all the accounts need to exist on all the devices, there is a central authentication: the accounts exist in one location and a device has to check the credentials against that repository. In turn, the repository may send back additional information along the ACCEPT or REJECT response, such as the privilege level or a list of permitted commands.

I have seen two major centralized authentication deployed with Cisco devices: radius and tacacs. While other methods, such as LDAP or KERBEROS, are possible, I haven't seen them widely used.

1.1.2.1 Remote Authentication Dial-In User Service (Radius)

For a description of radius, look here. By no standard is RADIUS a recent protocol. It was originally developed in 1991 to allow the central authentication of dial-in users. Over the years, its use cases have grown to include not only dial-in, but also console authentication, OS login authentication and so forth.

On Cisco devices, two types of radius server exist: private (limited to a group) or global (accessible to all groups). The difference is that if a radius server is used by more than a single group, a global definition will force all the parameters (ports, key, timeouts) to be the same. A private server exists only within the scope of a group, and has its own parameters: if the same server is defined in another group, different parameters can be specified.

The authentication process with Cisco is as follow:

• A server exists within a group (there is also a default global group called radius)
• A group is used in an authentication method
• An authentication method is used to perform the authentication process attached to a management interface

Configuration steps:

Activate the aaa code

aaa new-model 

Define a group and its private servers:

aaa group server radius my-group-name 

server server1 key key1

server server2 key key2

Define an authentication method using the group and local if none of the servers is reachable:

aaa authentication login my-auth-name group my-group-name local

Bind the authentication to the remote management interface

line vty 0 15 

login authentication my-auth-name

It is important to understand the notion of "backup authentication". In the aaa authentication statement, I specified local after the group name. This means that the local authentication database will be used only and only if the servers in the group fail to reply. If a server replies with a rejection, the authentication process stops there and returns an authentication failure, and denies the login.

The backup authentication allows an administrator to gain access to the device even if the radius servers are down or unreachable. However, this opens the potential for misuse. Let's assume Alice is a disgruntled employees and is about to be fired. Her account was just disabled in radius. Decided to leave in a blaze of glory, she runs a DoS against the radius servers and use the local credentials to access the switch...

1.1.2.2 Terminal Access Controller Access-Control System (TACACS)

For more information on tacacs/tacacs+, read the wikipedia page.

Tacacs/Tacacs+ has some advantages over radius: encryption of the whole communication instead of just the password field, authorization of individual commands. However, if radius is an open protocol, Tacacs is proprietary.
The authentication process is the same as for radius.

Configuration steps:

Activate the aaa code

aaa new-model

Define the server group

aaa group server tacacs+ my-group-nameserver server1server server2

Define an authentication method using the group and local if none of the server is reachable:

aaa authentication login my-auth-name group my-group-name local 

1.1.3 Putting the authentication together

aaa new-modelusername myuser secret MySecretPassword 

aaa group server radius my-group   

server 1.1.1.1 key ThisIsMyRadiusKey

aaa authentication  login my-auth-login group my-group local

line vty 0 15 

login authentication my-group

1.2 Authorization

After a user has proven who he/she is to the system, he has to get his/her authorization to perform tasks. For instance, is the user allowed to "show" certain parameters? The configuration? Is he/she allowed to alter the system configuration? 

The authorization process for Cisco devices has two different options.

• Privilege level based: the user will be assigned to a privilege level, which has a number of commands allowed. All users at the same privilege level have the right to execute the same commands.
• Command based: when a user enters a command, the device will check with the authorization server whether this is permitted. If the answer is "yes", the command is allowed, otherwise the command fails. 

The latter depends on the authorization server and will not be described in this text. 

1.2.1 Local database

To authorize a user against the local database, two components are needed: a user entry defining the privilege level, and the aaa statement to instruct the device to enforce the privilege level. I will describe the process of defining what command is available to a privilege level later.  Of course, this presumes the user has been authenticated prior to be authorized!

To assign a privilege level to a user, the command is username.

username user privilege priv 

To instruct the device to apply the privilege level.

aaa authorization exec <my list> local

To apply the authorization to the user sessions.

line vty 0 15authorization exec <my list>

1.2.2 Radius authorization

Radius authorization works in almost the same way: the Radius server returns an A/V pair the device interprets as the privilege level. 

Configuring the A/V pair depends on your Radius server. The information that needs to be returned is

shell:priv-lvl=<priv level>

In order to configure the radius authorization, either a group of radius servers or all the radius servers can be selected through the definition of a list-name.

aaa authorization exec <my list> group <my radius group>

- OR -

aaa authorization exec <my list> group radius

As for the authentication, a second method can be added as a failover if the first method fails. 

1.2.3 Tacacs+

This is the same as for the radius authorization: an A/V pair is defined on the server and returned. Instead of creating a group of radius servers, one would create a group of tacacs+ servers.

1.2.4 Allowing commands based on the privilege level

Now that each user is assigned a privilege level, we can restrict the commands used. 

An important point to remember: a privilege level allows access to all the commands listed for that privilege, but also for all the commands allowed for the privileges below! For instance, if "ping" is allowed at privilege level 3,  all users at level 3 and up can use it. 

Privilege levels start at 0, which allows only 5 commands (disable,enable,help,exit,logout), and up to 15, which is the equivalent of "root" in the Unix world, and accessible through the enable command without parameter.

Of course, all the privilege levels don't have to be used. But the planning needs to be adequate, otherwise you may have to shift levels and change a fair amount of configuration.

 As a privilege level inherits all the commands from below, the command definition can have "holes", and for instance, you may configure privilege levels 1, 7, 9, and13. Levels 2 thru 6 will have the same commands as level 1, 8 as level 7, 10 thru 12 as level 9 and 14 as level 13. This allows for future definitions if needed.

In IOS, commands come in two flavors: exec and configuration. The exec mode is basically the shell in which you type all non configuration commands, including reloading the device, pinging other devices, saving the configuration and displaying information. The configuration mode, as its name indicates, is to alter the configuration of the device. 

Example: to allow privilege level 7 to save the configuration and to configure SNMP parameters

privilege exec level 7 write memory 

privilege exec level 7 configure 

privilege exec level 7 configure terminal 

privilege configure level 7 snmp-server

1.3 Accounting

Accounting allows one to review "what" was done by "whom". This is often overlooked but is an extremely important feature to have, both from a compliance perspective and from the company's ability to quickly find the origin of an issue. 

There are two options for command accounting: logging and aaa accounting. The logging part will be addressed in a later chapter.  

The aaa accounting is only possible with radius and tacacs+. No local aaa accounting is possible. To activate aaa accounting, as for authentication and authorization, a group must exist. A quick note: there is no named-list available for system accounting, all the accounting needs to be done as default.

aaa accounting exec default start-stop group <my group> 

aaa accounting command <my level> default start-stop group <my group>

The first command logs all accesses to the exec shell, recording the time started and stopped. The second logs all commands executed at level <my level>.

1.4 Consoles

A Cisco device has multiple types of console: local serial and remote (network) consoles. A console is a way to interact with the management plane of the device, i.e. to execute commands to get some information about the device's status or to modify its configuration.

1.4.1 Serial consoles

These are physical console ports on the device. Usually, they are RJ45 (ethernet-like) ports, but nowadays, they also come as USB miniports. In order to connect to it, one needs to have a physical access to the equipment. 

As physical ports, they don't support any fancy features such as encryption or access-list, but they provide access to the rommon during the boot sequence. 

There could be one or two console ports, denoted "con" and "aux". The latter can be configured as a console port to connect a modem and gain a remote access should the device lose access to the network. 

1.4.2 Network consoles

These are virtual consoles - denoted by vty - that emulates a serial port over a network connection. They are accessible from anywhere as long as a TCP connection is possible to the device. 

1.4.2.1 Specifying the protocol

Network consoles support different protocols: telnet, rlogin, ssh. These define what service will be bound to the vty. For instance

line vty 0 4 

transport input telnet 

line vty 5 15 

transport input ssh 

defines that telnet sessions will be allocated a vty from 0 to 4 and the ssh ones will get a number between 5 and 15.

Administering a network device is a sensitive task: whoever gets access to yours can deeply affect your operations by creating issues, monitoring traffic or redirecting packets. As such, it is important that all remote management connections are encrypted.  

SSH was designed as a VPN technology. The best known feature is the replacement for telnet. As telnet sends the password plaintext, it is susceptible to being intercepted by an attacker. All modern devices support configuring SSH for remote administration, and Cisco is no exception.

ip ssh version 2

This will force SSH version 2 to be used. Version 1 is afflicted by a series of issues that can be used to compromise a device.

ip domain-name <your domain-name>

Next, we have to define the domain-name for the system. This is not extremely important to have something resolvable or meaningful.

crypto key generate rsa

Next we generate the encryption keys using the default settings. There are options to specify whether the keys are exportable, the modulus size (or key length) and so forth.

line vty 0 15

transport input ssh

Last but not least, we apply this to all vtys. Starting now, the device is only accessible through ssh. A word of caution: SSH requires some authentication, it is important to have that configured and working prior to enabling SSH.

1.4.2.2 Limiting the sources

Now that we can authenticate, authorize and trace, and that all the sessions are encrypted, let's look further: how can we restrict the access to the management console to certain sources.

An important point in any secure design is "segregation": segregation of networks and machines based on roles - network operators or engineers, system administrators, non technical personnel and so forth. The requirements for each are different, and it makes sense to have them in different subnets. 

Using an access-list, it is possible to restrict the access to any Cisco device to a group of subnets. The following example uses a standard access-list and supposes that:

• The local subnet for the network operators is 192.168.21.0/24
• The remote access subnet for the network operators is 192.168.255.240/29

  The commands are

access-list 10 permit 192.168.21.0 0.0.0.255
access-list 10 permit 192.168.255.240 0.0.0.7

line vty 0 15

access-class 10 in

1.5 More control over the login process

There are now a few things left we can do. 

1.5.1 Limiting the number of failed attempts in SSH

First, we will put some obstacles in an attacker's path. Let's assume the attacker wants to brute force some credentials and has access to a machine with access to the device. A common attack is to create a session and start trying combinations of username/password.

An important step is to make sure this takes as long as possible by severing the connection after a few failed attempts. That way, the attacker will spend a fair amount of time re-establishing the session to the device, which will give some more time for the security team to notice the events and react.

ip ssh authentication-retries 2

This gives two attempts, if the first one fails, the second must succeed or the session will be interrupted. 

1.5.2 In case of (repeated) failures ...

Also, we may want to enforce a delay in the login process if too many authentication failures are encountered in a brief period of time. Cisco offers a mechanism for this in the login enhancements.

login block-for 30 attempts 5 within 60

The previous command instructs the router to suspend the login process for 30 seconds if 5 failed attempts are detected within 60 seconds or less. This is a powerful way of delaying an attack, but at the same time, it offers a side-effect of enabling an attacker to DoS a network device and prevent legitimate access.

In order to mitigate that, an access-list can be applied to provide a list of IPs that have access, even during the quiet-period (the period during which the login process is suspended).

access-list 11 permit host 192.168.21.10
login quiet-mode access-class 11

Again, this has another side effect: if the compromised machine is 192.168.21.10, there will be no enforcement of the quiet-mode for the attacker. The emphasis is on making sure the host(s) allowed are perfectly secure. 

The team may want to log failed attempts, but maybe not EVERY failed attempt. For instance, we may not need to know whenever a colleague (or self) fat fingers his/her password.

login on-failure log every 3

This logs the failure only after 3 unsuccessful attempts. 

1.5.3 But if successful ...

We may want, however, to keep track of all successful logins. Even though we have the accounting in place, we may want to have a specific message for each successful created session. 

login on-success log

That last command will generate a log entry for each successful login to the device. 

1.5.4 More delays during login!

Yes, there is a way to add some delay between the login attempts. Again, using the login enhancements, a delay between two login attempts can be enforced.

login delay 3

After this, there will be three seconds between two login attempts. With all the previous configuration in place, an attacker would spend around 72 seconds - not including the session re-establishment - for every 5 attempts. This will considerably slow down his effort and give that time to be detected.

Cisco Switch Security (Introduction)

Networks are the core of all modern computer and information processing infrastructure. Regardless of the level of abstraction used - SaaS, PaaS, IaaS, cloud computing and so forth - networks and network devices still sit in the path of all data transfers.

Securing a network device means that steps will be taken to harden its configuration, ascertain no knowledge can be gained by interrogating the device, that only the authorized personnel will have access to its management interfaces and that it will contribute to the overall security scheme of the organization in a "security in depth" framework.

The result of a compromised network device can be extreme: not only the attacker has the ability to disrupt a corporation's communications, but also to modify the traffic path, sniff the transfers or even alter the data in transit. Scary? Yes and it is only a summary.

Several resources exist that describe how to secure network devices. One of them is the Security Configuration Guides as part of the NSA's Information Assurance program. Some of the steps in these articles are from that guide.

Over the next few weeks, different aspects of switch security will be examined:

• Section 1 treats of the management console and interface
• Section 2 addresses the security at the port level 
• Section 3 examines security at the VLAN level
• Section 4 deals with two additional layer 2 protocols
• Section 5 treats of logging and logs
• Section 6 deals with miscellaneous items