zNetLaB › Guided labs › Security
Standard ACL and VTY hardening with SSH
Security Intermediate 4 devices 4 checked tasks 100 points Plan lab
Keep the guest LAN away from the server LAN with a standard ACL placed close to the destination, then lock the router’s VTY lines to SSH only, from the admin LAN only, with a local user. You build it in a browser, type real commands at each device, and every task below is
checked against the running configuration — so you find out it is wrong before anybody else does.
Open this lab in the simulator
The simulator runs in your browser with nothing to install. This lab is part of the full simulator: open it free for 7 days with a new account, then with a plan. It needs an account, which keeps your progress.
The scenario
Keep the guest LAN away from the server LAN with a standard ACL placed close to the destination, then lock the router’s VTY lines to SSH only, from the admin LAN only, with a local user.
Your role: a security engineer. Level: Intermediate Done when: all 4 goals show as passed (100 points).
Network status
Devices: 1 router, 2 PCs, 1 server, cabled as drawn. No Layer 1 or Layer 2 faults: every link is connected and up. R1-Edge starts with addresses (G0/0/0 10.1.0.1/24, G0/0/1 10.2.0.1/24, G0/0/2 10.3.0.1/24). Admin-PC is a host with 10.1.0.10/24, gateway 10.1.0.1. Guest-PC is a host with 10.2.0.10/24, gateway 10.2.0.1. Server is a host with 10.3.0.10/24, gateway 10.3.0.1. Known problems
None: nothing is misconfigured. The network is simply not finished: what the goals list is what you have to build or secure. Goals
The guest LAN can no longer reach the server (25 pts) The admin LAN still can (20 pts) The VTY lines accept SSH only, with a key generated (30 pts) And only from the admin LAN (access-class 10) (25 pts) The activity, in order
The guest LAN can no longer reach the server Why: Blocking traffic is half of security. You prove a block by showing the same ping that worked before now fails. Verify with: ping 10.3.0.10 The admin LAN still can Why: A ping needs a route in BOTH directions. This is the end-to-end proof that everything before it worked. Verify with: ping 10.3.0.10 The VTY lines accept SSH only, with a key generated Why: Each goal is a state the lab can check on the running device. Verify with: show running-config And only from the admin LAN (access-class 10) Why: The login prompt is the most attacked door on the device; an ACL narrows who may even knock. Verify with: show running-config | section line vty Tips
Work in the order given: later goals depend on the earlier ones. After every change, run the verify command before moving on; do not guess. Stuck? Read the verify output first. It names the interface, neighbour or route that is wrong. Why this matters
Keep the guest LAN away from the server LAN with a standard ACL placed close to the destination, then lock the router’s VTY lines to SSH only, from the admin LAN only, with a local user.
What you will be able to do
The guest LAN can no longer reach the server
The admin LAN still can
The VTY lines accept SSH only, with a key generated
And only from the admin LAN (access-class 10)
The network
ISR 4331, PC, Server — 4 devices in all, already cabled.
Gi0/0/0 10.1.0.1/24 Fa0 Gi0/0/1 10.2.0.1/24 Fa0 Gi0/0/2 10.3.0.1/24 Fa0 R1-Edge Admin-PC 10.1.0.10/24 · gw 10.1.0.1 Guest-PC 10.2.0.10/24 · gw 10.2.0.1 Server 10.3.0.10/24 · gw 10.3.0.1 Drawn from this lab: devices, cables, ports and the addresses already set. Device Model Address already set
R1-Edge ISR 4331 configure it Admin-PC PC 10.1.0.10 / 255.255.255.0 gw 10.1.0.1 Guest-PC PC 10.2.0.10 / 255.255.255.0 gw 10.2.0.1 Server Server 10.3.0.10 / 255.255.255.0 gw 10.3.0.1
Cabling
R1-Edge Gi0/0/0 ↔ Admin-PC Fa0 R1-Edge Gi0/0/1 ↔ Guest-PC Fa0 R1-Edge Gi0/0/2 ↔ Server Fa0
What is configured at the start
These are already configured when the lab opens — including, where this is a troubleshooting lab, the fault itself:
R1-Edge interface g0/0/0
ip address 10.1.0.1 255.255.255.0
no shutdown
exit
interface g0/0/1
ip address 10.2.0.1 255.255.255.0
no shutdown
exit
interface g0/0/2
ip address 10.3.0.1 255.255.255.0
no shutdown
exit Tasks, and how each one is checked
Every task is decided by reading the live network — a neighbour in FULL, a ping that succeeds, a line in the running configuration — not by looking for a keyword you typed. The same command shows you what the lab sees.
# Task Pts How to verify it yourself
1 The guest LAN can no longer reach the server 25 On Guest-PC: ping 10.3.0.10 must fail — the policy blocks it. 2 The admin LAN still can 20 On Admin-PC: ping 10.3.0.10 must succeed. 3 The VTY lines accept SSH only, with a key generated 30 Checked automatically against the device’s live state (sshOnly). 4 And only from the admin LAN (access-class 10) 25 Checked automatically against the device’s live state (vtyAcl).
Stuck? Ask the coach
Tell the coach what you see or what you tried. It gives you a hint, not the answer, the way a senior engineer would. Included with a free trial or any plan.
Ask the coach
Reference solution
Try it yourself first — the lab checks your work either way. This is one configuration that makes every task pass, device by device:
R1-Edge access-list 20 deny 10.2.0.0 0.0.0.255
access-list 20 permit any
interface g0/0/2
ip access-group 20 out
exit
access-list 10 permit 10.1.0.0 0.0.0.255
ip domain-name lab.local
username admin secret Adm1nPass
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
login local
transport input ssh
access-class 10 in
exit Where this is examined
This lab practises these topics in the zNetLaB certification courses:
Related labs
Where to start
The lessons all guided labs plans
CCNA®, CCNP® and Cisco® are trademarks of Cisco Systems, Inc. zNetLaB is not affiliated with or endorsed by Cisco.