Practice Lab · 08 · Cisco / Networking
ACL & Port Security Review
Review ACL order and placement, VTY management restrictions, SSH versus Telnet exposure, port-security state, secure MAC learning, and err-disabled evidence.
The challenge is precision. A careless ACL or management change can block legitimate traffic just as easily as it can improve security.
Lab Snapshot
Mission briefing
Restrict management and endpoint access without breaking approved connectivity
This fictional Cisco network supports a school computer lab and must preserve required connectivity for approved users.
VLAN 10 is STAFF, VLAN 20 is STUDENTS, and VLAN 99 is MANAGEMENT.
Only approved management hosts should be able to reach device management services.
SSH is the preferred remote-management method; insecure legacy management should not remain enabled unless the mission explicitly requires it.
Access ports should prevent unauthorized endpoint changes without blocking approved devices.
ACLs must be reviewed in order because an early permit or deny can change the effect of every later line.
Do not erase ACLs, disable uplinks, or remove port-security settings until you understand the current behavior.
Preserve ACL, interface, port-security, management, logging, and reachability evidence before remediation.
Policy rule
Read ACLs from top to bottom and access controls in context
Network policy is evaluated in order and in a specific location. Before editing, know what traffic reaches the rule, which direction it travels, and what earlier entries already match it.
ACL review
Understand order, placement, direction, and counters
List configured ACLs
Identify standard and extended ACLs, sequence numbers, counters, and whether rules are actually receiving matches.
show access-lists
show ip access-lists
Find where ACLs are applied
Determine the interface, direction, and Layer 3 context where each ACL is enforced.
show running-config | include access-group
show running-config interface gi0/0
show running-config interface gi0/0.10
show running-config interface gi0/0.20
show running-config interface gi0/0.99
Review management-plane access
Check whether VTY access is restricted to the approved management network.
show running-config | section line vty
show running-config | include access-class
Check ACL hit counters
Use counters as evidence that traffic is or is not matching a specific rule, while remembering that counters alone do not prove the rule is correct.
show ip access-lists
Port security
Protect access ports without blocking approved endpoints
Port-security summary
See which interfaces have port security enabled and review violation information.
show port-security
Inspect one access port
Review maximum MAC addresses, learned secure addresses, violation mode, and access-VLAN configuration.
show port-security interface fa0/4
show interfaces fa0/4 switchport
show running-config interface fa0/4
Inspect another access port
Compare a second endpoint-facing interface and determine whether its policy matches the scenario.
show port-security interface fa0/16
show interfaces fa0/16 switchport
show running-config interface fa0/16
Check err-disabled interfaces
Identify ports disabled by violations or protection mechanisms before blindly re-enabling them.
show interfaces status err-disabled
show errdisable recovery
Management plane
Limit administrative access to the right network and protocol
VTY configuration
Review transport protocols, login method, and any access-class applied to remote management.
show running-config | section line vty
SSH state
Confirm SSH is available and inspect active sessions when supported.
show ip ssh
show ssh
Local user configuration
Review configured local administrative identities without exposing secrets.
show running-config | include username
Management interface and route
Confirm the management VLAN interface is reachable from the intended administrative network.
show ip interface brief
show ip route
Logs and timing
Correlate policy changes with actual device events
Device logs
Review recent interface, authentication, ACL, and port-security messages.
show logging
Port-security events
Look for evidence of security violations or interfaces moving into err-disabled state.
show logging | include SECURITY|PORT_SECURITY|ERR
Clock state
Confirm timestamps are meaningful enough to correlate with other evidence.
show clock
show running-config | include ntp
Interface changes
Use link-state messages to understand whether connectivity changes line up with a suspected configuration event.
show logging | include LINEPROTO|LINK
Fictional evidence set
Decide which policy problems are actually supported
ACL 120 is applied inbound on the STUDENTS routed interface. The first line permits ip any any, followed by several more specific deny entries.
Investigation prompt
How does rule order affect whether those later deny statements can ever match?
The permit ip any any line has a large match count. The later deny lines remain at zero matches.
Investigation prompt
How do the counters support your interpretation of the ACL order?
The VTY configuration allows both telnet and ssh, and no access-class limits which source networks may connect.
Investigation prompt
Which parts conflict with the mission's management requirements?
A STAFF host can reach the device management address, while a MANAGEMENT host can also reach it.
Investigation prompt
Which source should be allowed, and what control should enforce that decision?
Fa0/4 has port security enabled with maximum 1, sticky learning, and violation mode shutdown.
Investigation prompt
Does this look inherently wrong, or must you compare it with the approved endpoint model first?
Fa0/16 is err-disabled after a port-security violation. The learned secure MAC differs from the currently connected approved STUDENT-PC.
Investigation prompt
What should you verify before clearing the violation or changing the secure MAC?
A port-security log message occurred shortly before Fa0/16 became err-disabled.
Investigation prompt
How does this help confirm why the interface went down?
SSH is enabled and functioning. No evidence shows that Telnet is required.
Investigation prompt
What narrow change would better match the mission without redesigning the management configuration?
ACL reasoning
Ask six questions before editing policy
Direction
Is the ACL applied inbound or outbound relative to the interface?
Placement
Is the ACL attached to the interface or VTY context that actually handles the traffic?
Order
Can an earlier rule match the traffic before a later rule is evaluated?
Specificity
Does the rule describe the intended source, destination, protocol, and port?
Implicit deny
What traffic will be blocked if it does not match an explicit permit?
Verification
Did counters and reachability change the way you expected after remediation?
Preserve first
Save enough evidence to explain the policy before changing it
Record show access-lists and show ip access-lists before editing ACLs.
Record where each ACL is applied and in which direction.
Record ACL sequence numbers and hit counters.
Record VTY transport and access-class configuration.
Record port-security state, secure MAC addresses, maximums, and violation mode.
Record err-disabled state and relevant log messages.
Record which endpoint MAC address is physically connected to the affected access port.
Re-run the same reachability test immediately after each narrow configuration change.
Authorized remediation examples
Make narrow policy changes and test immediately
These examples are for the fictional authorized topology. Use only the change supported by your evidence.
Remove an overly broad first ACL line
Use sequence-based editing only when the evidence confirms the broad permit is shadowing intended policy.
configure terminal
ip access-list extended 120
no 10
end
Restrict VTY transport to SSH
Use when SSH is working and the mission does not require Telnet.
configure terminal
line vty 0 4
transport input ssh
end
Apply a management access class
Use only after confirming MGMT-VTY permits the approved management network and does not lock out authorized administration.
configure terminal
line vty 0 4
access-class MGMT-VTY in
end
Recover a verified approved access port
Use only after resolving the cause of the port-security violation and confirming the connected endpoint is approved.
configure terminal
interface fa0/16
shutdown
no shutdown
end
Verification
Prove policy works without locking out approved users
ACL behavior
Rule order, placement, and counters now reflect the intended traffic policy.
show ip access-lists
show running-config | include access-group
Management plane
SSH remains available and only the intended source network is permitted for remote management.
show running-config | section line vty
show ip ssh
Port security
The approved endpoint port is operational and port security still enforces the intended device limit.
show port-security
show port-security interface fa0/16
show interfaces status err-disabled
Logging
No new port-security or management errors appear after remediation.
show logging
Reachability
Approved management access succeeds while unauthorized source networks are blocked as intended.
ping <management-address>
ssh -l <admin-user> <management-address>
Reflection
Debrief the access-control decisions
Why can a single permit ip any any line make later ACL deny rules ineffective?
Why are ACL hit counters useful but not sufficient by themselves?
What is the difference between an interface access-group and a VTY access-class?
Why is allowing Telnet unnecessary when SSH is already working and the mission does not require Telnet?
Why should a port-security violation be investigated before simply clearing the err-disabled state?
What is the purpose of sticky MAC learning on an access port?
Why should a management ACL be tested carefully before it is applied to VTY lines?
Which finding in this lab had the greatest risk of locking out legitimate administrators if remediated carelessly?
Completion checklist
Finish only when access matches the mission
I reviewed ACL order, direction, placement, and hit counters.
I identified whether any broad rule shadowed more specific rules.
I reviewed VTY transport and management source restrictions.
I confirmed SSH was available before removing insecure legacy transport.
I reviewed port-security state and secure MAC learning.
I checked err-disabled interfaces and correlated them with logs.
I preserved the affected endpoint MAC information before changing port security.
I made only narrow, mission-supported changes.
I verified approved management access still worked.
I confirmed access-port protection remained enabled after remediation.