In the CCNA Security curriculum we can learn about AAA or Authentication, Authorization and Accounting. You can become more familiar with this concept by reading this article. In this article, I’ll show some Linux services which can help us maintain security through access control, mainly by using RADIUS and TACACS servers, but with other little tools also.

We’ll be working in GNS3 again, using the following topology:

Note: the Windows 7 client is attached to a switchport on R1 (I used the NM-16ESW module), so we have to configure the VLAN1 interface to establish IP connection between the router and the PC.

The most basic access control means that we’re using passwords to restrict access to console, enable mode, Telnet, SSH and so on. Most of the time we use unencrypted passwords during the configuration, but it’s not the most secure method. If we want, we can enter pre-encrypted passwords, but how do we generate them? The solution is the OpenSSL software library which is available on many platforms. Based on the article mentioned above, we can use the following command to generate passwords:

openssl passwd -salt `openssl rand -base64 3` -1 Cisco123

To explain:

  • We want to generate a password.
  • We must use a so-called salt, a random value which protects against dictionary and other attacks.
  • We use another embedded command which generates a 3 byte salt then converts it to 4 printable characters by Base64 encoding.
  • We use the -1 switch in order to use the MD5 based password algorithm.
  • And finally we add the unencrypted password of ‘Cisco123’.

Now we can enter the following command into the Cisco device:

enable secret 5 $1$eErS$VQ9Rk09VNVZuTnXysfNov/

Note that the ‘5’ parameter means that an already encrypted value follows. Try this by quitting enable mode and entering again.

Access control can be used for devices and users also. Mostly, when we plug our devices into the switch, the port comes up and we can start to work. If port-security is applied, only the PCs with authorized MAC addresses can connect – this is an important step towards security. However, MAC addresses can be spoofed, so we should find an even better solution.

Here is where 802.1x comes into play. This is a protocol designed for wired networks, but we can find it slightly modified in wireless networks also. The basic idea is that there are 3 entities in the communication: the device that wants to connect (the supplicant), the device that provides connection, typically a switch or Access Point (the authenticator) and the authentication server, which controls the access to the authenticator device.

The details of the protocol can be found in Wikipedia and other sites as well; I will only focus on its usage.

In our scenario, we’ll use the Windows 7 PC as the supplicant, the Cisco router (we use it as a switch now) as the authenticator and the Linux machine as the authentication server. This device has to run a special service called RADIUS (Remote Access Dial-in User Service), which controls the access to the switch based on user credentials. To use it, we need to install the package called freeradius (and optionally freeradius-utils). Our objective is to make the user provide a username and password to get the PC connected to the switch.

First, let’s configure the Linux side. Locate the /etc/freeradius directory which contains the configuration files. We need to modify clients.conf first. Insert the following at the end:

Here, the client is the Cisco router (not the Windows PC!), and we need a shared password between the Cisco and the Linux side. We defined the NAS-type also (NAS stands for Network Access Server), the other name of the authenticator. Save it and open the users file, and insert the following line at the end:

swadmin    Cleartext-Password := "Cisco123"

This is the client data that we will have to configure on the PC. Restart the RADIUS service with the service freeradius restart command. To check quickly if the server is listening and doing its job, use the radtest utility:

The first few parameters are self explanatory. The ’10’ is a port number, which can be anything, and ‘testing123’ is the shared secret used in the communication with the local host (this is a preconfigured value). The last line shows that this request is successful, so the username/password data seems correct.

On the Cisco device we need to enter the following commands:

The first line enables the AAA, the next two lines define the location of the RADIUS server and the shared secret, and the final global command enables 802.1x on the device. In interface configuration mode, we set the port to access mode and tell it to start in unauthorized mode, then turn into authorized mode after successful authentication. In unauthorized mode, the switch won’t forward any user traffic.

Finally go to the Windows machine and first check if the Wired AutoConfig service is running. You can do this quickly by launching services.msc in the CLI. Then, select the network adapter which connects to the switchport and configure it according to the knowledge-base document below. It’s important that you don’t use digital certificates, don’t use Windows logon names automatically and specify the correct User authentication data. Finally, try to connect to the switch. It should succeed, but this time it is an authenticated connection.

On Cisco devices we can control the user access through several methods, such as privilege levels and CLI views, but the most effective way is through the TACACS service. The Terminal Access Controller Access-Control System is somewhat similar to RADIUS; a comparison can be found among the useful links at the end of this article.

With TACACS, we can set it so that we can control what commands each user who has access to the device can and cannot use (this is what authorization means). Of course, we need to authenticate them first, and accounting can be done also. TACACS doesn’t have an extensive feature set in this area as RADIUS has though.

Cisco created Secure Access Control Server (ACS) as the authentication server software. ACS runs under Windows and is robust software, but there is also a TACACS server for Linux, and we’ll use that in our lab.

The scenario: assume the company’s network has more than one system administrator. One of them is the senior administrator who has complete control over each device. Others have fewer privileges, and only make certain configurations or perform tasks on the devices just to disencumber the senior administrator. We need to define exactly what commands they can issue on the devices.

The system will work in the following way: users authenticate first, and then every time they issue a command, the device consults the TACACS server if this command is allowed or not.

Configure the Linux side first. The server can be installed by issuing the apt-get install tacacs+ command. The configuration file is /etc/tacacs+/tac_plus.conf. We can find some examples in this file, but almost all are completely commented out. The configuration can be quite complex; if interested, issue the man tac_plus.conf command and read the whole manual.

We’ll start with a very simple configuration: we’ll define our senior administrator who has complete control over the devices, and define one junior administrator, who has a very limited command set, mostly just some show commands. Note that this is far less than in normal user mode or privilege level 1.

First thing we need to modify is the line with the keyword “key”: comment this out and we can easily debug the communication between the router and the TACACS server. Later, when everything seems correct, we can use this key to secure that communication. We just need to add the following to the router’s configuration then: tacacs-server key testing123.

Now write the following lines at the end of the tac_plus.conf file:

The first user section defines the senior admin. The easiest way to allow him all the commands is the default service = permit statement. The following line is for authentication: in this first example we’ll use the cleartext password method, but Linux has numerous other methods (we’ll see a more secure method soon).

The configuration for the junior administrator begins with denying every command, but later we define the exceptions: he can use the show version, show ip and show interfaces commands. The last two commands have other parameters and keywords which are also allowed, but none of the other show commands. Save this file then restart the TACACS server with the service tacacs_plus restart command.

Now go to the Cisco router and configure it. First define an enable secret (when the TACACS server cannot be reached, the users can authenticate themselves with this), then set the server’s location:

The AAA configuration follows. First enable the new method, then configure the authentication and authorization part (accounting is not so important for us now):

The authentication line means that the login process is authenticated by the TACACS service first, and if it’s unsuccessful, then the enable password can be used.

The authorization is a must on the console also. Moreover, when a user starts an exec session, the TACACS server must be consulted. The if-authenticated keyword gives a fallback method if the TACACS server is down; without this, the user cannot issue any command in that case. The last two lines control the commands that can be issued in user mode (privilege level 1) and enable mode (privilege level 15). Without these two lines, users can issue any command on that privilege level, so the restrictions cannot be achieved.

Now the testing: log out from enable and user mode, then log in to user mode again. The router should prompt you for a username and password. Use senior first and test if everything works as usual. Now log out again, but this time log back in as a junior user and try the following:

As can be seen, all commands are forbidden except the one that starts with show ip. Experiment with the other allowed commands also: they should work.

Note: In GNS3, the devices have a basic configuration (with the help of the baseconfig.txt) and the following is in console and VTY configuration: privilege level 15. What it means is that if a user reaches the console or can connect through VTY lines, they immediately get full admin privileges – in other words, they don’t need to know the enable password. This can be seen in the picture above: the user is in enable mode as evident with the “#” symbol, but the restrictions also apply in this mode.

So far so good, but let’s go further. For example, what should we do if we want to allow a user only a special command but not its other variations? For example: we want to allow the junior user to issue the show ip interface brief command, but not the show ip interface f0/0. The solution is quite simple: modify the appropriate permit ip statement in tac_plus.conf file to the following:

permit "ip interface brief"

This way, only this form of the command is accepted. (Don’t forget to reload the TACACS service before testing, of course.)

When we have more users who need access to our devices, it’s inconvenient to define them one by one. In this case, we can use user groups instead. Let’s suppose that we have three junior administrators: Jim, Jack and Joe, who will now be members of the juniors group. Modify the tac_plus.conf file to the following:

The modified configuration is rather self explanatory. The junior users have different passwords, but they all have the same privileges. We can still give more privileges to some of them by using the cmd configuration keyword (in this case the user configuration overwrites the group configuration).

One last trick: a cleartext password is not good practice in configuration files. The tacacs+ package contains a program called tac_pwd, which generates a DES encrypted password from a cleartext one. Let’s use it:

Now modify the configuration in the tac_plus.conf file:

Now Jim has an encrypted password, and additionally can use all permutations of the show ip command.

RADIUS and TACACS allow a lot of possibilities. Consult the manuals and tutorials available on the Internet for more. Happy experimenting!

Useful links:

Using OpenSSL to generate MD5 passwords:
http://www.netomata.com/wiki/cisco_tips#md5_hashes

802.1x protocol and configuration:
http://en.wikipedia.org/wiki/IEEE_802.1X
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2950/software/release/12-1_19_ea1/configuration/guide/2950scg/Sw8021x.html
https://kb.meraki.com/knowledge_base/configuring-8021x-wired-authentication-on-a-windows-7-client

Comparison of RADIUS and TACACS:
http://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html

TACACS+ user guide:
http://www.stben.net/tacacs/users_guide.html