lab 5: cisco device access control - napier40001507/csn11111/lab5.pdf · 2013-10-13 · network...

Network Security Access Control – Rich Macfarlane 1

Lab 5: Cisco Device Access Control Rich Macfarlane 2013

1.1 Details

Aim: The aim of this lab is to introduce network access control concepts, and investigate

Authentication, Authorisation and Accounting on network devices. The ability to read and

understand network logs, error and audit traces, is an important skill, and is introduced

using Cisco network devices.

1.2 Activities

1.2.1 Setup GNS Topology

Run the GNS network simulator (as administrator).

Add a router, and a host machine, as described in previous labs. Configure the interfaces, and

test connectivity. Once the GNS3 topology shown below is created, configure the router (the

configuration in Appendix A can be pasted into the router console as a shortcut).

Starting Topology

Run the task manager (and keep it running), and check CPU usage. Recalculate the idlepc

value for the router type, until the CPU usage decreases.

Create a new project for the lab with File>New Project, as shown below. Save the router

configuration, and check the configuration file has been saved, as detailed in previous labs.


1.2.2 Authentication using Basic Passwords

Basic Passwords Stored on Router

Configure the router to use the same passwords for authentication as in the previous lab.

Set the Privileged Command Mode password to cisco

Set the Console access password to conpass

Configure the virtual interfaces access for telnet, with the password telnetpass

Test the console access control by exiting the router console, and logging back in with the new

password. Test the telnet access using putty.

AAA Services

Start the AAA services on the network device:

R1# config t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# aaa new-model

Configure the login authentication to use the enable password:

R1(config)# aaa authentication login default enable

Test the console access control by exiting the router console, and logging back in. (Try the

console and enable passwords) Test the telnet access from the PC connected to R1.

Questions

Q: Which password gave local access to the console?

Q: Which password gave remote access via telnet?

Access to the network device has been secured using the enable, console, and virtual interface

(vty lines) passwords, and now these have been replaced using the AAA services running on

the router.

These simple passwords, which would be used by all administrators, do not scale well for

multiple administrators, over many devices and host systems.

Questions

Q: What difference would, having a username and password for each administrator make?


1.2.3 Authentication using Local Device User Accounts

Defining Users and passwords adds some accountability to the access control, and can

be used to implement authentication of each user, and authorisation – control over

what each user can do on a device or host system.

Define User Accounts

Add users to the user account db using the username command:

R1# config t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# username rich secret richpass

R1(config)# username bob secret bobpass

R1(config)# username pete secret petepass

View the routers running configuration.

Questions

Q: Are the user accounts in the configuration? In not seek assistance, as you may lock yourself out of

the router if accounts are not created.

Q: What type of encryption is being used to protect the passwords?

Create Console Authentication using Local User Accounts

Create an authentication list for Console access to the router. This has no fallback, so if there

are no user accounts set up, the router may not be accessible.

R1(config)# aaa authentication login CONSOLE-LINE local

R1(config)# line con 0

R1(config-line)# login authentication CONSOLE-LINE

Test the console access control by exiting the router console, and logging back in.

Questions

Q: What is different about the login process?

Q: Can we get access with the original console password, or the enable password?

Create Telnet Authentication using Local User Accounts

Create an authentication list for Telnet access to the router called TELNET-LINES.


Test the telnet access control from the PC connected to R1.

Questions

Q: Can you get access to the router using a local user account?

Continue to Save R1 running configurations to the routers NVRAM, and then save the GNS3

project. Check the configurations have been saved to the host machine.

1.2.4 Monitor Authentication using Debug Trace

On Cisco networking devices, we can use Cisco debug trace to look at the indicators for

successful and unsuccessful authentication attempts. Close all Telnet sessions, except for the

console session.

Check System Clock and Timestamps

It is important in debugging to ensure the proper time is set to reference messages, especially

if logging multiple devices to a central logging system

Check the system clock and debug time stamps are set up. Use the following to check the

clock on the device:

R1# show clock

If the time is wrong, set the correct time using something similar to:

R1# clock set 11:15:00 31 September 2010

Check the debug timestamps are set using:

R1# show run | include timestamp

service timestamps debug datetime msec

service timestamps log datetime msec

If not, set the timestamps: R1# service timestamps debug datetime msec

Test Authentication and Debug

Use the following to activate the authentication debug trace:

R1# debug aaa authentication


Use putty to Telnet to the R1 router. Login with a valid user and password from the local user

accounts db. Note the authentication debug trace appearing in the console window. It should

look like the following.

R1#

*Sep 30 17:19:29.703: AAA/BIND(00000012): Bind i/f

*Sep 30 17:19:29.711: AAA/AUTHEN/LOGIN (00000012): Pick method list 'TELNET-LINES'

Now from the Telnet window, enter the Privileged Exec command mode. You should get a

debug trace like the following. Note the highlighted line: username is Rich, virtual interface is

tty2, the Telnet client network address is 192.168.2.2, service being requested is Enable. Note

also the 2nd last line in the trace, where the outcome of the enable login is decided: Status is

PASS.

R1#

*Sep 30 17:20:53.367: AAA: parse name=tty2 idb type=-1 tty=-1

*Sep 30 17:20:53.371: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2

channel=0

*Sep 30 17:20:53.375: AAA/MEMORY: create_user (0x67C3705C) user='rich' ruser='NULL'

ds0=0 port='tty2' rem_addr='192.168.2.2' authen_type=ASCII service=ENABLE priv=15

initial_task_id='0', vrf= (id=0)

*Sep 30 17:20:53.379: AAA/AUTHEN/START (486274685): port='tty2' list='' action=LOGIN

service=ENABLE

*Sep 30 17:20:53.379: AAA/AUTHEN/START (486274685): non-console enable - default to

enable password

*Sep 30 17:20:53.383: AAA/AUTHEN/START (486274685): Method=ENABLE

*Sep 30 17:20:53.383: AAA/AUTHEN(486274685): Status=GETPASS

*Sep 30 17:20:59.759: AAA/AUTHEN/CONT (486274685): continue_login (user='(undef)')


*Sep 30 17:20:59.767: AAA/AUTHEN/CONT (486274685): Method=ENABLE

*Sep 30 17:20:59.843: AAA/AUTHEN(486274685): Status=PASS

*Sep 30 17:20:59.847: AAA/MEMORY: free_user (0x67C3705C) user='NULL' ruser='NULL'

port='tty2' rem_addr='192.168.2.2' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)

Now log out of the Telnet session, and then start a new one. Login with a valid username, but

use an invalid enable password.

Questions

Q: From the trace, what syntax shows the login to Privileged Exec mode was unsuccessful?

Now log out of both the telnet and the console sessions. Log back into the local console with a

valid user. Go to Privileged Exec command mode using the enable password.


Questions

Q: From the trace, what are values for the username, the interface, the network address, and the

service being requested?

The trace should be similar to the following:

User Access Verification

Username: rich

*Sep 30 18:31:03.523: AAA/BIND(00000017): Bind i/f

*Sep 30 18:31:03.535: AAA/AUTHEN/LOGIN (00000017): Pick method list 'CONSOLE-IN'

Password:

R1>enable

Password:

*Sep 30 18:31:17.651: AAA: parse name=tty0 idb type=-1 tty=-1

*Sep 30 18:31:17.655: AAA: name=tty0 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=0

channel=0

*Sep 30 18:31:17.659: AAA/MEMORY: create_user (0x678C658C) user='rich' ruser='NULL'

ds0=0 port='tty0' rem_addr='async' authen_type=ASCII service=ENABLE priv=15

initial_task_id='0', vrf= (id=0)

*Sep 30 18:31:17.663: AAA/AUTHEN/START (260053936): port='tty0' list='' action=LOGIN

service=ENABLE

*Sep 30 18:31:17.663: AAA/AUTHEN/START (260053936): console enable - default to enable

password (if any)

*Sep 30 18:31:17.667: AAA/AUTHEN/START (260053936): Method=ENABLE


R1#

*Sep 30 18:31:19.523: AAA/AUTHEN/CONT (260053936): continue_login (user='(undef)')


*Sep 30 18:31:19.531: AAA/AUTHEN/CONT (260053936): Method=ENABLE

*Sep 30 18:31:19.583: AAA/AUTHEN(260053936): Status=PASS

*Sep 30 18:31:19.583: AAA/MEMORY: free_user (0x678C658C) user='NULL' ruser='NULL'

port='tty0' rem_addr='async' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)

R1#

To stop the Authentication debug trace:

R1(config)# no debug aaa authentication


1.2.5 Centralised Authentication Server

The local authentication database, on the device is an improvement on the single password per

service model, but it doesn’t scale well. If an organisation has more than a couple of devices, each

device db would have to be managed separately. A large organisation with hundreds of devices and

many administrators, an ISP with thousands of users in each db need a better solution.

Centralising the authentication (and authorisation and accounting) information on one or more

authentication servers is a commonly used model. Several protocols to communicate the

Authentication information can be used, such as Radius and TACACS+.

1.2.6 Install the Radius Authentication Server on Host System

There are a number of free RADIUS servers available, such as WinRadius, a freeware standards-based RADIUS server that runs on most Windows OS’s, or Cisco Secure ACS which runs Radius or TACACS+ protocols for authenticaiton.

Using WinRadius, the free version of the software will only support five usernames. If

WinRadius is not installed on your machine, download from:

WinRadius Radius Server can be downloaded from:

http://download.cnet.com/WinRadius/3000-2085_4-10131429.html

The downloaded zip file should be unpacked into a folder such as the Desktop, and the

WinRadius.exe can simply be run – it does not need to be installed.

1.2.7 Create new Radius Server Topology

Save a copy of the current router configuration to a separate text file.

Create a new project with a router and a host machine which will run the authentication

server, or delete the router and add and configure a new router.

Once the topology shown below is created, the configuration in Apendix A can be used as a

shortcut, or manually configure the router.

Test connectivity from the host PC, as shown below

http://download.cnet.com/WinRadius/3000-2085_4-10131429.html


1.2.8 Configure the Radius Authentication Server

On the host machine, run the WinRadius.exe application, with Administrator permissions, at it

needs to create an authentication database. Rich click the WinRadius.exe and select Run as

Administrator.

When the application is started for the first time, the following messages are displayed

Please go to “Settings/Database and create the ODBC for your RADIUS

database.

Launch ODBC failed.

Select Settings>Database from the main menu and the following screen is displayed. Click the Configure ODBC automatically button and then click OK, as shown below. You should see a message that the ODBC was created successfully. Exit WinRadius and restart the application.


When it is run again, it should now look like the following.

Create User Accounts on the Radius Server

The free version of WinRadius can support only five usernames. The usernames are lost if you

exit the application and restart it. Any usernames created in previous sessions must be

recreated. Note that the first message in the previous screen shows that zero users were

loaded.

Select Operation>Add User, and enter the user RichRadius and the password richradiuspass,

or something similar, as shown below.

You should see a log of the user having been added to the authentication database. Clear the

log, with Log>Clear menu option. (The system can be tested locally, using the TestRadius.exe

application)

Use the netstat –a –p UDP -n command to check if the Radius authentication and

accounting servers are running, as shown below.


Configure the R1 Router for Radius Server Authentication

Start the AAA services on the router, if they are not running:

R1(config)# aaa new-model

Configure the login authentication to first use RADIUS for the authentication service, and then none. If no RADIUS server can be found and authentication cannot be performed, the router globally allows access without authentication. This is a open safe setup, in case the router starts up without connectivity to an active RADIUS server.

R1(config)# aaa authentication login default group radius none

You could alternatively configure local authentication as the backup authentication method

instead.

Specifiy a Radius Server, specifying its IP Address, and a secret key so the communications can

be cryptographically authenticated. Use something like the following:

R1(config)# radius-server host 192.168.2.2 key WinRadius

1.2.9 Test the Centralised Authentication for Console Login

Test connectivity to the server and vice versa, using ping.

Exit the console on the R1 Router, and try to log back in with the user richradius and the

richradiuspass password.

Questions

Q: Did you get access to the Router?

Q: Was there any delay?

Try the user RichRadius and the richradiuspass password.

Questions


Q: Were any messages displayed on the RADIUS server log for either login?

Q: Why was a nonexistent user able to login, and why are there no log msgs on the Radius server?


The router is not communicating with the RADIUS server software! When the RADIUS server is unavailable, messages similar to the following are typically displayed after attempted logins.

*Dec 26 16:46:54.039: %RADIUS-4-RADIUS_DEAD: RADIUS server

192.168.1.3:1645,1646 is not responding.

*Dec 26 15:46:54.039: %RADIUS-4-RADIUS_ALIVE: RADIUS server

192.168.1.3:1645,1646 is being marked alive.

Check the default Cisco IOS RADIUS UDP port numbers used on R1 with the radius-server host command and the Cisco IOS Help function.

R1(config)# radius-server host 192.168.2.2 ?

acct-port UDP port for RADIUS accounting server (default is 1646)

alias 1-8 aliases for this server (max. 8)

auth-port UDP port for RADIUS authentication server (default is

1645)

Questions

Q: What are the default ports used by the device?

From the WinRadius main menu select Settings > System.

Questions

Q: What are the default ports used by the Radius server?

Change the router to use the same ports as the Radius server. Remove the Radius server with:

R1(config)# no radius-server host 192.168.2.2 auth-port 1645

acct-port 1646

Add a new radius server, using the correct ports:


R1(config)# radius-server host 192.168.2.2 auth-port 1812 acct-

port 1813 key WinRadius

Exit the console on R1, and try to log back in with the user richradius and the richradiuspass

password.

Questions



Try the user RichRadius and the richradiuspass password.

Questions



Q: Explain the difference?

Check the log on the Radius Authentication server, it should look something like the below.

Test the console access control by exiting the router console, and logging back in. (Try the

console and enable passwords) Test the telnet access from the PC connected to R1.

Questions

Q: Which password gave local access to the console?

Q: Which password gave remote access via telnet?


1.2.10 Analyse the Radius Protocols Traffic with Wireshark

The link below can help with the analysis of the Radius protocol network traffic:

The Wireshark wiki has details of the Radius protocol:

http://wiki.wireshark.org/Radius

Run Wireshark on the Radius Server machine, and sniff the traffic, while using Radius to login to the router using the console.

Exit the console on R1, and try to log back in with the user richradius and the richradiuspass

password.

Stop the Wireshark capture, use the display filters from the foot of the wiki page to filter the Radius traffic. You should see traffic similar to the following:

Questions

Q: Which transport layer protocol does the Radius protocol use?

Q: Look into the packets, and list the ports being used by the Radius Server, and the Radius Client on

the Router?

Client Port: Server Port:

Q: Which type of Radius packet is returned from the Radius Server?

To see the reassembled contents of the packets in the conversation, right click on a packet and select Follow Stream.

Questions

Q: Can the username be seen?

Q: Is any part of the Radius traffic encrypted?


The UDP reassembled packets should look similar to the following:

Start another Wireshark capture, and try logging the user RichRadius and the richradiuspass

password. Stop the Wireshark capture, and filter out the Radius traffic.

Questions

Q: Which type of Radius packet is returned from the Radius Server?

Q: Why?


1.2.11 Centralised Authentication for Telnet

We can add a Virtual Machine to the topology, and telnet into the router to test remote

access authentication.

If you do not have access to a VM, the host machine can be used from both client and server.

(skip to the configure telnet section).

Adding a Virtual Machine to the GNS3 Topology

Start a virtual machine in VMWare Workstation, such as the Windows XP image.

Add the VM to VMNet2, the 192.168.10.x network, as specified in the below document. An IP

Addess of 192.168.10.5, and a default gateway should be set to 192.168.10.4, as shown in the

figure above.

The Adding VMs to GNS3 guide is available in the following document:

www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf

The VM firewall may have to be turned off/configured to fully test connectivity.

Attach the VM to the R1 router using a Manual Link, a shown above.

Set up the routers fa0/0 interface to IP Address 192.168.10.4 (as the VMWare VMNet2 virtual

hub will be 192.168.10.1 so don’t use that), and test connectivity from the router as shown

below.


Configure Telnet Administrative Access

On the Router, create a unique authentication method list for Telnet access to the router. This does not have the fallback of no authentication, so if there is no access to the RADIUS server, Telnet access is disabled. Name the authentication method list TELNET-LINES.

R1(config)# aaa authentication login TELNET-LINES group radius

Apply the list to the vty lines on the router using the login authentication command.

R1(config)# line vty 0 4

R1(config-line)# login authentication TELNET_LINES

From the VM host, Telnet to R1, and log in with the username richradius and the password of richradiuspass.

Questions


Telnet from the host system to R1, and log in with the username RichRadius and the password of richradiuspass.

Questions


Questions

Q: Why would an organization want to use a centralized authentication server rather than

configuring users and passwords on each individual router?


1.3 Appendix A – Starting router configuration

version 12.4



no service password-encryption

!

hostname R1

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

ip source-route

ip cef

!

no ipv6 cef

!

multilink bundle-name authenticated

!

!

!

archive

log config

hidekeys

!

!

interface FastEthernet0/1

description TO THE 192.168.2.0/24 HOST NETWORK

ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

router rip

network 0.0.0.0

no auto-summary

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

control-plane

!

mgcp fax t38 ecm

mgcp behavior g729-variants static-pt

!

!

gatekeeper

shutdown

!

!

line con 0

stopbits 1


line aux 0

stopbits 1

line vty 0 4

login

!

1.4 Appendix B – Local Authentication Router Configuration

version 12.4



service password-encryption

!

hostname R1

!

boot-start-marker

boot-end-marker

!


enable secret 5 $1$Er41$tNsvIlqRbUHJ24IjjUU5p0

!

aaa new-model

!

!

aaa authentication login default enable

aaa authentication login CONSOLE-IN local

aaa authentication login TELNET-LINES local

!

!

aaa session-id common

ip source-route

ip cef

!

!

ip domain name secure.com

no ipv6 cef

!


!

!

username rich secret 5 $1$StVp$fW2maySQZW.e3iLA074/X/

username bob secret 5 $1$hmoj$SZasrrIHgFovWyTg7hAnp.

username pete secret 5 $1$FDcY$GTxnnWBpGJutI/NXgGKTQ0

!

archive

log config

hidekeys

!

!


ip ssh time-out 10

!

!



ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

router rip

network 0.0.0.0

no auto-summary

!


no ip http server


!

!

control-plane

!

mgcp fax t38 ecm


!

gatekeeper

shutdown

!

!

line con 0

password 7 0822434019181604

login authentication CONSOLE-IN

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login authentication TELNET-LINES

transport input telnet

!

End

1.5 Appendix C – Central Radius Authentication Server router topology and configuration

version 12.4



no service password-encryption

!

hostname R1

!

boot-start-marker

boot-end-marker


!


!

aaa new-model

!

!

aaa authentication login default group radius none

aaa authentication login TELNET-LINES group radius

!

!

aaa session-id common

ip source-route

ip cef

!

no ipv6 cef

!


!

!

!

archive

log config

hidekeys

!

!



ip address 192.168.10.4 255.255.255.0

duplex auto

speed auto

!


description TO THE 192.168.2.0/24 ADMIN NETWORK

ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

router rip

network 0.0.0.0

no auto-summary

!


no ip http server


!

radius-server host 192.168.2.2 auth-port 1812 acct-port 1813 key WinRadius

!

control-plane

!

mgcp fax t38 ecm


!

gatekeeper

shutdown

!

!

line con 0

stopbits 1

line aux 0

stopbits 1

line vty 0 4

login authentication TELNET-LINES

!

end

lab 5: cisco device access control - napier40001507/csn11111/lab5.pdf · 2013-10-13 · network...

Documents