This is the second in a series of discussions regarding the CCNA Security (IINS) exam. I expect this discussion to be quite a bit different since we are now talking about configuration as opposed to threats, vulnerabilities, policies. There are a lot of directions that each person can go to give examples of configuration options. This topic is "Secure Cisco Routers".

I figured that I will kick off a discussion on how privilege levels work in IOS...

There are 16 privilege levels, 0 to 15. Level 0 is reserved for user-level access privileges and level 15 is reserved for privileged mode commands. Levels 2-14 allow you to tailor access to meet the needs of your particular organization. This will allow you to allow a certain group of users the ability to configure particular interfaces, while preventing them from making other configuration changes. Privilege levels are "cascading." Therefore, if a user has level 10 access, the user has access to the commands authorized in levels 1-9 as well.

Type 5 passwords refer to the MD5 hashing algorithm defined in RFC 1321. It was designed by Ron Rivest in 1991 and is used in many applications including Cisco type 5 Authentication. This is used for encrypting the enable secret password. It is moderately difficult to reverse engineer this type of encryption.

Type 7 passwords refer to Cisco's proprietary algorithm in encrypting passwords. This is best used to prevent shoulder surfers from recording privilege level access to network resources (ports, http(s) services). It can easily be broken quickly using online resources.

In a configuration file, the command service password-encryption will encrypt all passwords with the exception of the more secure type 5 enable secret variety. This prevents passwords from showing up in plain text in configuration files. Best practice says that backup configuration files should be kept in secure areas because of how easy and vulnerable the type 7 password is.

Privilege levels are definitely an interesting concept. I think the concept of moving commands between is a bit confusing. I was glad that the article you referenced showed how to use "enable x" where "x" is a privilege level. This is handy for messing with privilege levels without getting into the second "A" (Authorization) of the AAA model.

Privilege levels are definitely an interesting concept. I think the concept of moving commands between is a bit confusing. I was glad that the article you referenced showed how to use "enable x" where "x" is a privilege level. This is handy for messing with privilege levels without getting into the second "A" (Authorization) of the AAA model.

I think the discussion of privilage levels is a proper segway to custom views. There are several commands used in configuring custom views. Are there any secrets in memorizing them? How useful are they in today's network deployments? Are they common place or "featurific" which often do not get put into play in production environments?

Regarding the Video, I absolutely agree. It would be nice to have something like that, but I certainly don't expect it. Stuff like that is time consuming if you don't create them regularly. This is an open forum and no one should feel obligated to do anything that they don't have the time and resources for. Keith has been doing some excellent work with video and I am way envious of his skills. I was just throwing that out there as a challenge if someone wanted to take the time, or already had one readily available

Regarding the password encryption methods, that is a great explanation. I have a piece of trivia that I'll add--

If you encrypt your passwords with "service password-encryption" and subsequently remove it, what happens? It would be easy to assume that the type 7 passwords would be decrypted and stored in plain text. However, that is not the case. The passwords are still stored as type 7 and displayed as type 7. Doing a "show running-config" or "show startup-config" will display the type 7 format. If you manually add them back into the configuration (overwriting the type 7 ones), they will then be in clear text. The IOS understands these passwords to be type 7 because of the '7' indicator with them while stored in flash and in execution ram. Therefore the type 7 passwords can continue to work even though the router may no longer be doing "password-encryption".

Another interesting side effect of type 7 versus type 5 is that type 7 is reversible. There is truly a mathematical process that can reverse it back into a clear text password. This sounds pretty bad, and it is certainly something to be aware of. However, consider using a non reversible (type 5) password with a challenge algorithm like CHAP. Both endpoints must know the passwords, or have equivalent hashes. With type 5 this is not the case and thus CHAP cannot work with type 5 passwords. However, the IOS can understand the origination of a type 7 password and thus it can work with CHAP. Probably not an IINS concept, but another piece of trivia.

I think technologies such as parser-view and lawful intercept do provide a lot of granularity in access. The organizations I support don't allow access to their network devices from their help desk, so I don't personally see this implemented. I do have an opinion that a lot of places that need something like this already have TACACS+ in place. In those cases, very fine granularity can be found using command authorization in TACACS+. I'm sure there are some organizations that use parser-view extensively. I too am curious to others opinions on how extensively these are used, especially in the service provider space. I found a nice presentation at the url below:

I don't work for a service provider, but I can tell you that setting up various views on every single device you have can get ugly, especially if you have a large amount of devices. I work in a 500+ node network. That includes routers, switches, bridges, APs, controllers and management software. I would much rather use TACACS+ and set up Authorization permissions on one AAA server than various views on every node.

Now, I do have some contacts at the ISP that provides Internet access to my organization and their take is the same. I can see views comming in handy in a small environment, but not an enterprise! A question I would pose is how big does the environment need to get before one would consider dumping views and going to AAA?

I'm not sure the organization would need to get very large at all. The network guy in a small organization probably is struggling with the network, Microsoft/Mac OS, et al., as an additional duty, and his/her day job would take most of his time. The network guy working in a larger organization probably is going to be fully employed maintaining the network; I don't see that person having a lot of time for individual views. I think views are a hold over from the bad old days of early UNIX.