TACACS+, AAA, SSH and SNMP

AAA, TACACS+ & SSH

One thing that I overlooked due to configuring the devices was user accounts and AAA (Authentication, Authorization and Accounting). AAA is the process which involves authenticating users who wish to access network resources and devices. Authenticated users are then given privileges of which network resources and devices they are allowed to access, through authorization. Finally, when users access these resources a log must be kept in order to identify unauthorized logins, and recording which device by which user during which time of which day these unauthorized logins occurred. In order to begin configuring AAA, the devices also needed to be secured further than your standard plain-text password across telnet (heavily insecure).

In order to initiate AAA on the devices, the command aaa new-model must be entered in global configuration. Afterwards, the aaa authentication command will have to be configured in order to prepare administrative connection methods to be used, such as SSH or console. However, I have opted for a no authentication method on the console command in case of being locked out. In order to configure this, I have created a method list called console_login with the login method none following. 

I have also configured SSH access to the device, primarily due to the fact that sessions between client and server operate in clear text when sending passwords and other commands across TELNET. SSH provides encryption of data traversing the network, so no more sniffed packets with Wireshark. Furthermore, SSH has two versions, where either is better than TELNET in terms of security, but SSH version two offers better protection through encryption ciphers AES or 3DES to protect from packet sniffing, Message Authentication Code (MAC) algorithms for integrity checking, and supports public key certificates.

To configure SSH version two, a domain-name and public key must be configured first using ip domain-name and crypto key generate. I have opted for a key with a modulus of 1024 for better protection. Once the domain-name and keys have been generated, you can enter ip ssh version 2 into global configuration mode and version two will be used on the device. Following this, transport input ssh is entered under the virtual lines configuration (line vty 0 15). Any TELNET connection is blocked, and SSH is allowed. 

Setting the method lists to allow access across a particular line involved entering the command login authentication followed by the named method list. For console, console_login is used whilst the default method list configured for use with SSH. The default method list checks the TACACS+ server for a valid user account before reverting to using the locally configured accounts. 

#BAS1
!
! creates a new AAA model

aaa new-model
!
! configures a domain name on the device
ip domain-name faculty.school
!
! generates a key with the modulus 1024 for SSH
crypto key generate rsa general-keys label SSH-KEY modulus 1024
!
! creates a local user account
username nathan privilege 15 password 0 lewis
username tavita privilege 15 password 0 stewart
!
! configures the SSH version to use (SSH V1.99)

ip ssh version 2
!
! specifies the allowed methods of logging into the device
aaa authentication login default group tacacs+ local

aaa authentication login console_login none
!
! console port configuration
line console 0
 login authentication console_login
 logging synchronous
! virtual line configuration
line vty 0 15
 transport input ssh

 login authentication default

Instead of locally configured accounts, it is must easier to administrate a network when user accounts are configured on a central server, and each device retrieves their login details from a TACACS+ server. An alternative to TACACS+ is RADIUS, however TACACS+ is a superior protocol due to it's accounting and authentication ability. It also provides encryption of traffic between devices. The disadvantage of TACACS+ is the amount of traffic generated from logins and commands entered, however as this only applies when administrators are configuring devices (at this stage), the performance degradation is minimal to it's benefits. I am using Cisco ACS (Access Control Server) to act as a TACACS+ server, and in order for devices to retrieve login information, a TACACS+ client must be configured. The TACACS+ server IP and a secret shared key must be configured before the client can retrieve user logins. In order to do this you must enter tacacs-server host followed by the server IP as well as tacacs-server key followed by the shared key. Now the device will retrieve user logins from the TACACS+ server. I have opted in to supply a source-interface for my TACACS+ requests, using the command ip tacacs source-interface. I have used Loopback1 as the source interface, as the device is a multi-layer switch and a unique interface and IP address is preferred for troubleshooting purposes.

#BAS1
! specifies the tacacs+ server IP and secret key
tacacs-server host 10.0.2.102
tacacs-server key FACULTY
!
ip tacacs source-interface Loopback1

Configuring the TACACS+ server on Cisco Access Control Server (ACS) to send and receive information relating to TACACS+ will be included in a later post.

Simple Network Management Protocol (SNMP)

SNMP is a protocol which provides the administrator with the ability to monitor information of devices throughout the network. This can include interface information or CPU information, or much more. Using SNMP to monitor these aspects of the network can aid in finding issues that inhibit the networks ability to transfer data efficiently. Configuring SNMP on the devices involves choosing a version (1, 2c or 3) and then deciding which information you would like the device to forward to the SNMP manager.

The following will outline how I've configure SNMP to operate on the devices. For the multilayer switches which are operating in layer 3 as part of the backbone, I have configured Loopback interfaces which share an IP address with the Router-ID used for OSPF (see here).

!local interface for SNMP agent.
interface Loopback1
 description SNMP-AGENT
 ip address 1.1.1.1 255.255.255.255

The access-list entry used below provides a method of limiting which IP access can access the SNMP agent for information. In this example, the IP address of my Raspberry Pi which I have configured to act as an SNMP manager is permitted and logged.

access-list 5 permit 10.0.2.34 log

Next is the creation of a user to interact with SNMP on the device. I have opted to use SNMP version 3.

snmp-server user snmpmanager snmp-managers v3 auth md5 management priv des management access 5

And a group has been configured to use privileges such as read-only access.

snmp-server group snmp-managers v3 auth read readonly access 5

Specifying a local interface helps with a direction of where the information comes from. As opposed to letting the device choose where to send the information from, I have opted to send it from Loopback1. If there is a connection issue between devices, making sure the manager can ping Loopback1 on the agent will rule out connectivity issues.

snmp-server trap-source Loopback1

To finalize the configuration that I used, the host which will be the SNMP manager must be specified on the device. The IP address of the Raspberry Pi is entered along with informs and the specified version. With version 3, the auth sub-command becomes available which can be followed by the user in which to authenticate transmissions between the manager and the agent.

snmp-server host 10.0.2.34 informs version 3 auth snmpmanager

snmp-server host 10.0.2.34 version 3 auth snmpmanager

What is missing from this post is the trap information. I have not yet chosen any information to trap, but SNMP is configured so any trap information required by the network management policy can be added and monitored.