5.1 Configure and verify device access control

Device access control is about protecting the management plane. If an attacker can log in to a switch or router, the rest of the network security story gets much weaker. ENCOR expects you to know the practical pieces: local users, console and VTY lines, SSH, AAA, and verification.

The core idea

A network device should answer three questions before giving someone a shell:

1. Who are you? Authentication.
2. What are you allowed to do? Authorization.
3. What did you do? Accounting.

Local authentication is useful for labs, break-glass access, and fallback. Centralized AAA is what you normally want in production because users, policies, and logs belong in one place.

Admin PC
SSH / VTY
access-class · authenticate · authorize

Basic secure management baseline

This is a clean starting point for IOS XE-style devices. Passwords and addresses are examples only.

hostname SW1
ip domain-name ccnpstudy.local
crypto key generate rsa modulus 2048
ip ssh version 2

username netadmin privilege 15 algorithm-type scrypt secret <unique-local-secret>

enable algorithm-type scrypt secret <unique-enable-secret>

ip access-list standard MGMT-SOURCES
 remark Management subnet only
 permit 10.10.10.0 0.0.0.255
 deny any log

line console 0
 login local
 exec-timeout 5 0
 logging synchronous

line vty 0 4
 transport input ssh
 login local
 access-class MGMT-SOURCES in
 exec-timeout 10 0
 logging synchronous

What this does:

• Creates a local admin user.
• Forces SSH instead of Telnet.
• Restricts VTY access to the management subnet.
• Applies idle timeouts.
• Uses local authentication on console and VTY.

Verification

show ip ssh
show running-config | section line vty
show running-config | include username|enable secret
show access-lists MGMT-SOURCES
show users

Expected signs:

• SSH version 2 is enabled.
• VTY lines accept SSH only.
• login local appears under the line.
• ACL counters increment when a permitted or denied source attempts access.

What “good” looks like in production

A better production design adds centralized AAA and keeps local users only as fallback:

aaa new-model

tacacs server ISE-TACACS-1
 address ipv4 10.10.20.10
 key 0 SharedSecretHere

aaa group server tacacs+ TACACS-SERVERS
 server name ISE-TACACS-1
 ip tacacs source-interface Loopback0

aaa authentication login default group TACACS-SERVERS local
aaa authorization exec default group TACACS-SERVERS local if-authenticated
aaa accounting exec default start-stop group TACACS-SERVERS

The key exam point is order. The device tries the centralized group first and falls back to local if the server is unavailable. That does not mean a user rejected by the AAA server should automatically get local access. In real networks, fallback is for outage handling, not policy bypass.

The source interface is not decoration. If the AAA server, firewall, or ISE policy expects requests from the loopback address, sourcing TACACS+/RADIUS from the wrong interface can look like an authentication problem while actually being a reachability or policy-source problem.

Lab

Goal: Secure SSH access with local login, then add AAA fallback.

Topology:

Admin PC
SW1
R1 · 10.10.10.2

Tasks:

1. Configure SW1 with a hostname, domain name, RSA key, and SSH version 2.
2. Create a local privilege 15 user.
3. Permit SSH only from 10.10.10.0/24 using a standard ACL on the VTY lines.
4. Set console and VTY idle timeouts.
5. Verify SSH succeeds from 10.10.10.50.
6. Try SSH from a non-management source and confirm it is denied.
7. Add AAA with a TACACS+ or RADIUS server if available. Keep local fallback.

Success checks:

show ip ssh
show users
show access-lists MGMT-SOURCES
show aaa servers

Quick check

• Which line command makes the router use local usernames? login local.
• Which command disables Telnet on VTY lines? transport input ssh.
• Which ACL type is normally used to restrict VTY source addresses? Standard ACL.
• Why keep a local user when using AAA? Emergency fallback when the AAA service is unavailable.