Network devices are susceptible to unauthorized login attempts by attackers seeking access. Cisco’s IOS offers a solution by introducing ACLs, which can block an attacker from even receiving a prompt to enter a password. This is achieved when an external user attempts to connect through Telnet or SSH. In these instances, IOS represents this connection using a vty line.
ACLs can be applied to these vty lines, thus controlling which addresses are allowed to initiate a Telnet or SSH session with the router or switch. If an address is filtered out by the ACL, the user won’t encounter a login prompt.
For instance, if all devices used by the network engineering team are on the subnet 10.1.1.0/24. The security policy dictates that only these team members should have the rights to Telnet or SSH into any Cisco routers on the network. To implement this, the configuration exemple below can be applied to each router to restrict access to those not within the specified subnet.
Here’s an example of how to control vty access using the access class command:
The access-class command is an essential tool in Cisco IOS for managing access to routers, particularly in controlling Telnet and SSH connections. It operates by referencing the logic in access-list 3. The term “in” specifically pertains to inbound Telnet and SSH connections to the router, meaning it regulates access for users trying to Telnet into the router.
As set up, ACL 3 scrutinizes the source IP address of packets involved in incoming Telnet connections.
IOS also enables the use of ACLs for filtering outbound Telnet and SSH connections. For example, consider a scenario where a user, having already established a connection to the CLI via Telnet or SSH and currently in user or enable mode, attempts to use the telnet or ssh commands for connecting from the local device to another device. In such cases, an outbound vty filter comes into play. This filter applies ACL logic to the user’s actions, specifically when they try to initiate outbound connections.
To set up an outbound VTY ACL, the command access class acl out is used in VTY configuration mode. Once this is configured, the router begins to filter attempts by current vty users to establish new connections to other devices using telnet and ssh commands.
Between the two options of safeguarding either inbound or outbound connections, protecting inbound connections is generally more critical and common. However, it’s worth noting that outbound VTY ACLs exhibit a unique characteristic in their use of ACLs. When the out keyword is enabled, the standard IP ACL mentioned in the access-class command focuses on the destination IP address, not the source. In other words, it regulates the connections based on the target device of the telnet or ssh command, rather than the originating device.
How To Encrypt Older IOS Passwords with Service Password-encryption.
Its been noted that older versions of Cisco’s IOS present a security vulnerability due to the use of clear-text passwords within the configuration files. These passwords can be exposed in various ways, such as when configuration files are printed, stored as backup copies on servers, or displayed on a network engineer’s screen.
To mitigate this risk, Cisco introduced the service password-encryption command for global configuration. This command provides a basic level of encryption for passwords that are typically stored in clear text. The encryption applies specifically to the passwords associated with several commands in the IOS system. These commands, which originally stored passwords in clear text but are now subject to encryption through this feature, include:
password password (console or vty mode)
username name password password (global)
enable password password (global
It’s important to note, however, that the encryption provided by the service password-encryption command is not highly secure. It uses a reversible algorithm, meaning that the encrypted passwords can be relatively easily decrypted with the right tools. Therefore, while it offers a layer of security against casual observation, it shouldn’t be relied upon as the sole means of protecting sensitive password information.
For more robust security, it’s recommended to use stronger, more modern encryption methods and to manage access to configuration files and backups securely.
The process of encrypting clear text passwords in Cisco IOS using the service password-encryption command can be demonstrated through a practical example below.
Initially, the configuration is displayed in its unencrypted state, showing the clear text console password. This is achieved using the command show running-config | section line con 0. This specific command filters the output of the running configuration to only show the section related to the console (console line 0).
After enabling the password encryption feature with the service password-encryption command, the same show running-config | section line con 0 command is executed again. This time, the output will display the previously clear text password in an encrypted format. The contrast between the two outputs – before and after encryption – highlights the effect of the service password-encryption command in securing console line passwords.
Example: Encryption and the service password
When you examine the output of the show running-config command before and after applying the service password-encryption command in Cisco IOS, two key changes become evident. First, the encryption process scrambled the original clear-text password. Second, IOS introduces a method to show that a password in the configuration is encrypted, as opposed to being in clear text.
IOS achieves this by adding an encryption type indicator to the password command. In the case of passwords encrypted with the service password-encryption command, this indicator is the number “7“. This notation signifies that the password is encrypted using the method associated with service password-encryption. In contrast, clear-text passwords are considered type 0 by IOS. Depending on the specific command, this type indicator might or might not be explicitly listed.
It’s important to note that while the service password-encryption global command encrypts passwords, the reverse command, no service password-encryption, does not revert the passwords back to their clear-text form immediately. Instead, as shown in the example below, the encrypted passwords remain in their encrypted state even after the encryption service is disabled. They only return to clear text when a password is modified or changed.
This behavior underlines the fact that service password-encryption is more about preventing casual viewing of passwords rather than providing a robust encryption method.
The service password-encryption command in Cisco IOS, unfortunately does not offer robust protection. The encryption it uses is relatively weak and can be easily decrypted with tools available on the Internet. For instance, an encrypted password from an example configuration, when inputted into one of these decryption tools, could reveal the original password, such as “cisco.” Therefore, while this encryption may deter casual prying, it is not effective against attackers with more advanced knowledge and tools.
How To Encode the Enable Passwords with Hashes.
In the early versions of IOS, Cisco used the enable password password global command for setting the password required to enter enable mode. Originally, this command stored the password in clear text, and while the service password-encryption command provided some level of encryption, it was not very secure.
To address this, Cisco introduced the enable secret password global command as a more secure alternative. Although both commands are still present in IOS, the enable secret command is recommended due to its enhanced security.
How Enable Password and Enable Secret Works.
In practical terms, it is advisable to use the enable secret password global command and avoid the enable password password command. Even though Cisco has not removed the enable password command from IOS, the enable secret command is more secure and has been the preferred choice for close to 2 decades now.
When both commands are configured on a device, the password set by the enable secret password command takes precedence. If only one of these commands is configured, that command’s password is used. If neither command is configured, console users automatically enter enable mode without a password prompt, while Telnet and SSH users are denied access without the option to enter an enable password.
How To Enhance The Enable Secret with a Hash.
The enable secret command enhances security by never storing the actual clear-text password in the configuration. Instead, IOS uses a hash function, typically MD5, to store a hashed value of the password. This hash function is a complex mathematical formula that makes it computationally challenging to derive the original clear-text password from the hashed value.
This method ensures that even if someone accesses the configuration, they cannot easily determine the actual password, as they only see the hashed value. The main ideas are illustrated in the example below, demonstrating the effectiveness of hashing in securing the enable secret password.
If the original plain-text password can’t be regenerated, how does a switch or router verify the password entered by a user? The key lies in a unique characteristic of security hashes like MD5; each plain-text input consistently produces a distinct output from the mathematical formula.
For example, using the enable secret orbitcom command generates an MD5 hash. If a user enters “orbitcom” when attempting to access enable mode, IOS computes the MD5 hash of “orbitcom” and compares it to the stored MD5 hash from the enable secret command. If they match, IOS grants the user access to enable mode. Conversely, any other input results in a different MD5 hash, leading IOS to deny access.
This method allows IOS to validate user-entered passwords through the following steps:
Hash Generation: IOS calculates the MD5 hash of the password specified in the enable secret command and stores this hash in the configuration.
User Input Hashing: When a user attempts to access enable mode and enters a password, IOS hashes this input using the same MD5 algorithm.
Comparison: IOS compares the hash of the user-entered password with the stored hash. If they match, it confirms that the user has entered the correct password.
This system enables switches and routers to verify passwords without storing them in plain text. This approach’s effectiveness can be observed in the configuration of a switch.
The example below illustrates the creation of an enable secret command, including some related aspects.
In this example, the show running-configuration command reveals the stored (hashed) value. It also shows that IOS alters the enable secret orbitcom command to indicate encryption type 5, signifying that the password listed is an MD5 hash of the original plain-text password. The long, complex string seen in the output is this hash, effectively obscuring the actual password.
The conclusion of the example highlights a notable aspect concerning the removal of the enable secret password; once in enable mode, it’s possible to delete the enable secret password simply by using the no enable secret command, and this can be done without needing to input the original password value.
Additionally, the existing password can be replaced by executing the enable secret command again with a new password. However, it’s crucial to note that you cannot view or retrieve the original plain-text password.
This feature underscores the security measures inherent in the Cisco IOS system. The ability to delete or overwrite the enable secret password without the need to know the current password enhances administrative flexibility. At the same time, the inability to view the original plain-text password ensures that even with privileged access, the actual password remains secure and undisclosed, maintaining the integrity of the password system.
