Cisco CCNA 200-301 – Cisco Device Security Part 4

7. SSH Secure Shell Lab Demo

In this lecture you’ll see how to configure SSH with lab demo. The topology is very simple. I’ve got my router R One with IP address ten dot one and I’m going to be accessing it from my PC one at ten or ten. So let’s go on R one first. And if I do a show IP interface brief here, you can see that the IP address is already configured on there. If I do a show run, you see that I have not configured my telnet or SSH access at the line level yet. So I’ll do that now. So I’ll go to Global configuration and we’ll use a username this time rather than line level security. So I’ll say username, I’ll have username Flackbox with a secret of Flackbox one and then I’ll configure telnet access first. So I’ll go line VTY zero to 15 and I’ll say login local on there to use the local usernames.

Now if I go on to my PC, if I telnet to 1001, I can put in my username of flatbox and my password of flatbox one and I’ll try to do it without putting a typo in while I’m talking. There you go. And you can see that I can log in as Flackbox if I exit back out to the command line on my workstation again. If I try to SSHL to specify the username which is flatbox and attend O one, this is going to fail. I can see that the connection is closed because I’ve enabled telnet access underwriter, but I haven’t enabled SSH access yet. So let’s do that now. So I’ll go back onto R One.

The first thing that I need to do is specify a domain name because that’s going to be used in the certificate. So I say IP domain name and I’ll use flatbox. com for the example. Then I need to generate the certificate. So I say crypto key generate and it’s using RSA. The router will ask me what do I want the key length to be? It defaults to 512. Don’t accept that. The minimum you can use for SSH is seven six eight. So I will use seven six eight here and that is now SSH enabled. If I do a do show run again, you can see that I haven’t added anything else to my virtual terminal lines. These control both telnet and SSH access and the default is that they allow both. So right now both Telnet and SSH should work. So if I go back to the PC again and I try to SSH again now it does prompt me for the password, it doesn’t prompt me for the username because that was included in the SSH command and I can enter my password in there. And now I’m getting into the router with SSH.

If I exit out of here and I try telnet again, you see that telnet access is still enabled as well. So right now I can get in with either telnet or with SSH. I don’t want that. I want to disable the telnet access because it’s an insecure protocol. The traffic all goes in plain text. So to do that I will go back onto router R one again and I’ll go to my virtual terminal lines configuration again and I’ll say transport input. I’ll do a question mark here and you can see I can do all which enables both SSH and telnet. That’s the default. None will do neither. Or I can enable just SSH or just telnet. So I’ll say transport input SSH and that is going to allow only SSH access.

Another thing I should do that is best practice is a global config, say Ipssh version two to only accept the latest version. It’s a bit more secure doing this as well. Okay, so that is SSH configured. Now if I go back to my PC and I try to tell net, you see that telnet is going to fail now because I’ve disabled telnet on the router. But if I try to SSH, SSH is working and that still gets me into the router. Okay, so that’s how you configure SSH and disable telnet. That’s what’s typically going to be done in the real world. Okay? Another thing about real world configuration is that you’re not going to be using local usernames like you saw there. We’re actually going to use an external server to make this more scalable. We’ll cover that in the next one extra.

8. AAA Authentication, Authorization and Accounting

In this lecture you’ll learn about AAA authentication, authorization and accounting. So earlier in this section you saw how to configure local security and configuring line level security or local usernames on each individual router switch has a serious scalability limitation, that is that if a password has to be added, changed or removed, it needs to be done on all devices. And this is whether you’re using line level or usernames for the security. So if a new administrator joins a company and let’s say you’ve got 100 routers and switches, you’re going to have to add that username on all of the different routers and switches. If an administrator leaves, you’re going to need to remove the username on all of the different switches.

And if you’re using a line level password instead, again, if an administrator leaves, then you’re going to need to change that password on all of the different devices. It would be a security issue to have the same password on there when an administrator knows it and they’ve left the company. So, rather than having to configure all of our different devices with our security details, what is a better idea is to use an external AAA server instead and then that allows us to centralize the security. So all of the security configuration, all the usernames and passwords, and the authorization details are configured on the AAA server and all of your routers and switches point at that server. So whenever anybody wants to log in to a router or switch, it checks with the AAA server if they are authenticated and authorized or not. And typically real world, we’re not going to just have one a server, we’re going to put in at least two for redundancy in case one of them goes down. SOA. Stands for Authentication, Authorization and Accounting. Authentication verifies that somebody is really who they say they are, that’s most commonly achieved with a username and password.

The person has to be the actual person to know the password. So that’s how we verify it is them. Authorization specifies what a particular user is allowed to do, such as whether they are allowed to run a particular command or not. And accounting keeps tracks of the actions that a user has carried out. So we can use this as an audit trail to check what commands an administrator entered. And this is not just for pointing the finger at somebody if something goes wrong. If something was working before and now it stopped working, then probably it’s because a command was entered and having an audit trail lets you quickly find out what happened just before it stopped working. So it’s useful for troubleshooting. Authorization and Accounting are optional when you’re using AAA. Authentication is mandatory if Authorization and or Accounting are used.

So Authorization is saying what somebody is allowed to do or not. Well, you want to make sure it really is them before you authorize them to do anything. The same with accounting. If you’re keeping track of what somebody’s doing, you want to make sure it really is them before you actually keep track of that. The protocols that are used for AAA are Radius and or Tacax Plus. Both of them are open standards, although vendors may add their own propriety extensions. I’ll talk a bit more about that in a minute. And many vendors AAA servers support both protocols will support both Radius and Tacax Plus as well. Radius is commonly used for end user level services such as VPN access. If you’ve got users out on the road and they’re going to VPN in to get access to the corporate network, then Radius would be a better match for that. Tacax plus is commonly used for administrator access on Cisco devices because it’s got more granular authorization capabilities.

It’s better for controlling what commands a particular administrator is or is not allowed to run. Cisco, as well as many of our vendors have got a AAA server. Cisco’s AAA server is the Ice, the identity services engine. They also used to have the ACS, which is the access control server, and it was available for years and years, but it’s gone end of sale now. So the current AAA server from Cisco is the Ice. Okay, let’s have a look at how AAA works. So here we’ve got an administrator on the left, and she’s going to log in to the router in the middle. And we’ve also got a AAA server as well. And all of the traffic is going to be going over IP. So the administrator connects to the Cisco router to manage it using either telnet or SSH, preferably SSH because it’s encrypted the router within that telnet or SSH session will challenge the user, ask the user to enter a username and password.

Still within that telenet or SSH session, the administrator enters the username and password. Now, if we were using local authentication, the router would have that username configured on the router itself. But when we use AAA, the username and password is stored externally on our AAA server. So the router passes the credentials, the usernames and password over to the AAA server, and that’s in either a Radius or attack Apps Plus session. The AAA server will look to see if the username and password are valid, and it will reply back to the router to see whether the user is authenticated or not.

Optionally, it can also give the router authorization information as well. So based on the username and password, what commands that user is allowed to run on the router, then the administrator is going to be able to work within their telnet or SSH session. Okay, so that was just having the user and the router directly authenticated with AAA server. But in real world networks, most user databases or the most common user database is Active Directory from Microsoft. Almost for sure. The company you’re working for, they’re using Active Directory. So you come in in the morning and you log in with your Windows username and password. Now, it is possible, if we go back to that previous example, that yes, you could use Active Directory and your AAA server separately. So when you come in in the morning, you log into Windows and you’re using your Active Directory username and password. And then when you go to log into the router to do your Cisco administration, you use a different username and password that is on the AAA server.

But the problem is that users, if they have to remember lots of different usernames and passwords, what they do is they write it on a Post it Note and we stick it on their monitor, and then there’s not much point in having usernames and passwords. So it’s better if you can have just one username and password per user. That way it’s easier for them to remember it. It’s always going to be in sync. Another thing you’ll sometimes see is if you do have different databases, users try to have the same username and password on all of them, but they have to change their password once in a while and it’s going to get out of sync. So it’s not really possible to manage that. It’s best if you’ve just got one database, one username, one password per user. So for that, what you’ll often see again in real world deployments is an Active Directory integration.

Now, it is possible that the router can send the username and password directly to the Active Directory domain controller because the active directory of the domain controller, it supports radius as well. But the problem with this is that Active Directory is a Microsoft product, so it doesn’t support the level of granularity, the control of authorization that a Cisco A server does. A Cisco server that ice, it can control the individual Cisco commands that a user is allowed to run on a router or switch. But Active Directory, it’s from Microsoft, it’s not aware of Cisco level commands. So this comes down to the vendor proprietary extensions. A Cisco A server is great for controlling Cisco routers and switches, but we don’t want to have a separate user database on the Cisco A server and an Active Directory. So what we’ll do is we’ll integrate the AAA server with Active Directory.

That way we get the best of both worlds. We get the really granular control of our authorization from a Cisco A server, and it still allows us to use that one username and password in Active Directory. So how it’s going to work if we’ve got an Active Directory integration? The administrator goes to log into the router using Telnet or SSH. The router will send a challenge back to the user inside Telnet or SSH, asking them for the username and password. The administrator enters the username and password that gets sent to the router or the switch. The router is integrated with the Cisco A server, which will be the ice, and that’s using Radius or Takax.

So it sends the username and password to the Triple A server. When the router sends the username and password to the Triple A server and Radius or Tacax, it’s encrypted. So if anybody’s sniffing the traffic over the wire, they can’t see that username and password. The Triple A server does not have the local user database now it’s on the Active Directory domain controller. So the AAA server sends the username and password to the Active Directory domain controller that will normally be using LDAP, which is lightweight directory access protocol as the protocol. The domain controller will then tell the Triple A server whether that is a valid username and password, and it can also give group information back to the AAA server as well.

So what this allows you to do is maybe you’ve got a group in Active Directory called Cisco Administrators and they get full control on the routers. They can run all commands. Maybe you’ve got another group in Active Directory called Cisco Help Desk, and they can do read only type commands, but they can’t change any of the configuration. So the AAA server can pull that information from Active Directory. Then on your AAA server you can configure what particular groups in Active Directory are allowed to do on your routers and switches what commands were allowed to run.

The Triple A server will then send that information back in the Radius or Tacax session to the router, saying whether that was a valid username or password or not, and also optional authorization information which will be based on the ad group. Like I just explained, the router will then complete the telnet RSS session with the user and they’ll be able to run the commands that they are authorized to run. Okay, so that is the theory of AAA. In the next lecture, I’ll show you how to configure.

• Category: Uncategorized