Cisco 200-301: Network Security and Access Control — Study Guide
Part of the Cisco CCNA 200-301 — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.
Overview
Network security and access control ensure that only authorized entities use network resources in intended ways, while protecting data and services from compromise or disruption. Effective designs align technical controls with the core principles of confidentiality, integrity, availability, and least privilege. Controls must span the management plane (how devices are administered), the control plane (how devices form adjacencies and exchange routing), and the data plane (how user traffic is forwarded), with layered defenses at Layer 2, Layer 3, and above. This section distills practical mechanisms—AAA, ACLs, Layer 2 protections, VPNs, firewalls/IPS, hardening, and operational monitoring—along with design reasoning, common failure modes, and concise configuration examples.
Security Principles and Access Control Foundations
- Confidentiality: Prevent unauthorized disclosure. Enforced with encryption in transit (SSH, IPsec), encryption at rest, and scoped access policies.
- Integrity: Prevent unauthorized alteration. Achieved using cryptographic checks (HMACs, digital signatures), configuration controls, and immutability of audit records.
- Availability: Keep services reachable despite faults or attacks. Realized with redundancy, rate-limiting, policing, and resilient architectures that maintain continuous connectivity during failures.
- Least privilege: Grant the minimum rights necessary, scoped to role, device, protocol, time, and location. Implement using role-based access control (RBAC), segmentation, and per-command authorization.
Design reasoning:
- Drive access policies from business roles. RBAC on infrastructure (e.g., network-operator vs. network-admin) reduces blast radius of credential misuse and operational error.
- Separate duties (e.g., security operations vs. network operations). Enforce via distinct AAA groups and command authorization.
- Prefer deny-by-default postures. Explicitly permit intended flows and management sources, with logging on exceptions.
Common pitfalls:
- Excessive privileges for convenience (e.g., blanket privilege 15). This invites lateral movement and irreversible errors.
- Flat networks lacking segmentation. Broadcast domains and undifferentiated policy boundaries amplify attacks (e.g., ARP spoofing).
- Overly strict controls without telemetry. Lack of counters/logging hampers troubleshooting and can extend outages.
AAA and Secure Device Management
AAA overview:
- Authentication verifies identity. Authorization determines what an identity can do. Accounting records what was done and when.
- Local authentication: Device stores users and passwords. Useful for break-glass; does not scale or centralize policy.
- TACACS+: TCP/49, encrypts the entire payload, supports granular per-command authorization; favored for device administration.
- RADIUS: UDP/1812 (authn/author), UDP/1813 (acct), encrypts only the password field; integrates well with 802.1X and network access, less granular authorization for CLI.
Typical AAA configuration with TACACS+ and local fallback: aaa new-model tacacs server TAC1 address ipv4 10.20.20.10 key $uperSecretKey aaa group server tacacs+ TAC-GRP server name TAC1 aaa authentication login default group TAC-GRP local aaa authorization exec default group TAC-GRP local if-authenticated aaa accounting exec default start-stop group TAC-GRP username breakglass privilege 15 secret StrongLocal!Pass
Role-based access:
- Map TACACS+/RADIUS attributes to device privilege levels or command sets. Use per-command authorization to restrict risky actions (e.g., reload, write, policy-map edits).
- Validate RBAC with test accounts; ensure break-glass local account is documented, secured, and monitored.
Secure management plane:
Prefer SSHv2 for CLI. Disable Telnet and unused servers. ip domain-name corp.local crypto key generate rsa modulus 2048 ip ssh version 2 line vty 0 4 transport input ssh login authentication default access-class MGMT_VTY in ip access-list standard MGMT_VTY permit 10.10.10.0 0.0.0.255
Restrict management to out-of-band or dedicated management VLANs/VRFs. Apply ACLs on the SVI or physical management interface to allow only authorized sources.
Control-plane policing (CoPP) to protect routing, management, and control protocols from floods: class-map match-any CONTROL-PLANE-MGMT match protocol ssh match protocol snmp match protocol ntp policy-map COPP-POLICY class CONTROL-PLANE-MGMT police 32000 conform-action transmit exceed-action drop class class-default police 64000 conform-action transmit exceed-action drop control-plane service-policy input COPP-POLICY Reasoning and cautions: Police, don’t blanket-drop class-default; misclassification can break routing adjacencies or BFD and cause outages. Start with generous rates, observe counters, then tighten.
Password hardening and device integrity:
- Use enable secret (hashed) instead of enable password.
- Enforce minimum length and throttle login attacks: security passwords min-length 12 login block-for 60 attempts 5 within 60
- Prefer local user secrets (PBKDF2/scrypt on supported platforms). Understand that service password-encryption only obfuscates legacy type-7 passwords.
- Secure boot and configuration: secure boot-image secure boot-config
- Protect and version configurations; consider periodic archive to local storage and a secure remote repository. Use SCP or SFTP for file transfers; avoid plaintext TFTP for sensitive files.
Traffic Filtering with IPv4/IPv6 ACLs
IPv4 ACL basics:
- Standard ACLs (1–99, 1300–1999) match only source IPv4 address. Extended ACLs (100–199, 2000–2699) match on source/destination, protocol, and L4 ports.
- Wildcard masks: 0 bit must match; 1 bit is “don’t care.” Compute as inverse of subnet mask (e.g., /24 => 0.0.0.255). Shortcuts: host 192.0.2.5 equals 192.0.2.5 0.0.0.0; any equals 0.0.0.0 255.255.255.255.
- Direction: inbound is processed before routing on ingress; outbound is processed after routing on egress. Packets are checked top-down until the first match; an implicit deny any ends the ACL.
- Placement guidelines: place extended ACLs close to the source to drop unwanted traffic early; place standard ACLs close to the destination to avoid overblocking. Modern platforms use TCAM; still prefer precision near the source.
Examples: ip access-list standard ALLOW-MGMT permit 10.10.10.0 0.0.0.255 deny any log interface Vlan100 ip access-group ALLOW-MGMT in
ip access-list extended APP-POLICY remark Allow HTTPS from users to web farm permit tcp 10.20.0.0 0.0.255.255 172.16.50.0 0.0.0.255 eq 443 remark Deny all else with logging deny ip any any log interface GigabitEthernet0/1 ip access-group APP-POLICY in
Useful refinements: use remark for documentation; use established for rudimentary return-path allowance on TCP (limited security value); enable logging on denies sparingly to avoid CPU spikes.
IPv6 ACL principles:
- Similar logic, but IPv6 ACLs are named only and applied with ipv6 traffic-filter. Default deny is also implicit.
- Always account for essential ICMPv6 types (neighbor solicitation/advertisement, router solicitation/advertisement, PMTU). Overly strict ACLs that drop ICMPv6 break ND and cause black holes. ipv6 access-list V6-EDGE-IN remark Permit ND and control ICMPv6 permit icmp any any nd-na permit icmp any any nd-ns permit icmp any any router-solicitation permit icmp any any router-advertisement remark Permit HTTPS to data center permit tcp 2001:db8:10::/64 2001:db8:50::/64 eq 443 deny ipv6 any any log interface GigabitEthernet0/2 ipv6 traffic-filter V6-EDGE-IN in
Verification and operations:
- show access-lists APP-POLICY and show ipv6 access-lists V6-EDGE-IN to view hit counters and sequence numbers.
- show ip interface or show ipv6 interface to confirm attachment and direction.
- Test narrowly before broad deployment; a misplaced deny ip any any can cause widespread outages.
Common failure modes:
- Wildcard miscalculations that unintentionally match too broadly.
- Applying ACLs in the wrong direction or on the wrong interface/SVI.
- Omitting critical ICMPv6 allowances, leading to neighbor discovery failures.
Layer 2 Protections, VPNs, and Perimeter Defenses
Layer 2 threat controls:
DHCP snooping: Builds a binding table of IP–MAC–VLAN–port for DHCP-learned addresses; drops rogue server replies on untrusted ports; rate-limits offers/requests. ip dhcp snooping ip dhcp snooping vlan 10 interface Gi1/0/24 ip dhcp snooping trust interface Gi1/0/1 ip dhcp snooping limit rate 20 Failure modes: Forgetting to trust uplinks to real DHCP relays/servers breaks address assignment; not saving the binding table across reboots can impact DAI/IPSG until leases renew.
Dynamic ARP Inspection (DAI): Validates ARP packets against the DHCP snooping binding (or static bindings). Drops spoofed ARP. ip arp inspection vlan 10 interface Gi1/0/1 ip arp inspection limit rate 30 Caveat: Statically addressed hosts require static bindings; otherwise, legitimate ARP may be dropped.
IP Source Guard (IPSG): Uses bindings to permit only valid source IP (and optionally MAC) per port. interface Gi1/0/1 ip verify source ! Optionally tie to port-security MAC checks: ! ip verify source port-security
Static binding example for a fixed-IP device: ip source binding 0011.2233.4455 vlan 10 10.10.10.50 interface Gi1/0/5
VPN fundamentals and IPsec concepts:
- Site-to-site VPNs typically use IPsec in tunnel mode to encrypt and authenticate private subnets across untrusted networks. Core elements: IKE Phase 1 (e.g., IKEv2) to establish an ISAKMP SA; Phase 2 to build IPsec SAs with transforms (e.g., AES-GCM for combined mode or AES-CBC with HMAC-SHA2); PFS to ensure forward secrecy; lifetimes to refresh keys; NAT-T over UDP/4500 if NAT is present.
- Remote-access VPNs can be SSL/TLS-based (client or clientless) or IPsec-based. Split tunneling reduces bandwidth on the headend and improves user experience but increases exposure; full tunneling centralizes security controls at the cost of bandwidth and latency.
- Validate path MTU and enable PMTU discovery; encrypted overhead reduces effective MTU and can fragment without proper configuration.
Firewalls and intrusion prevention:
- Firewalls enforce allow/deny with stateful inspection and application awareness (NGFW). On routers, zone-based firewalling provides stateful policy between zones; ACLs alone are stateless.
- IPS analyzes traffic for signatures, anomalies, or behaviors; inline IPS can block, while passive IDS alerts only. Tuning is essential to reduce false positives.
- Design for symmetric flows across stateful devices; asymmetric routing breaks state tables. Position sensors where they see the right traffic (e.g., between untrusted and trusted zones).
Security Operations: Monitoring, Logging, and Incident Triage
Audit logging and time:
- Synchronize clocks for forensic accuracy: ntp server 10.20.20.20 service timestamps log datetime msec localtime show-timezone
- Enable local and remote logging with appropriate severity: logging buffered 16384 informational logging host 10.30.30.5 logging trap informational
- Increase visibility of authentication events and command usage with AAA accounting: aaa accounting commands 15 default start-stop group TAC-GRP
- Use ACL logging on denies judiciously; high-volume logs can spike CPU. Consider sampling with NetFlow/IPFIX for traffic baselining.
Incident triage workflow:
- Detect and scope: Use syslog, SNMP traps, and flow data to identify anomalous sources, ports, and volumes. Correlate counters in ACLs, CoPP, and interfaces.
- Contain: Temporarily apply targeted ACL denies, shut compromised switchports, or quarantine VLANs. For DDoS on the control plane, adjust CoPP policing and consider upstream rate-limits or blackholing.
- Eradicate and recover: Remove malicious artifacts, rotate credentials (including keys and shared secrets), re-enable services incrementally while monitoring.
- Post-incident: Preserve logs/config snapshots, conduct root-cause analysis, and codify preventive controls (e.g., expand Layer 2 protections, refine RBAC).
Common operational gaps:
- Missing NTP leads to unusable timelines.
- Logging everything everywhere creates noise; tune severity and filters by device role.
- No tested break-glass process prolongs outages when AAA servers are unreachable.
Practical Problem Scenario
Orion Retail Group must secure device administration, segment user-to-app traffic for IPv4/IPv6, stop rogue DHCP/ARP activity at stores, enable secure remote access for staff, and improve incident response visibility—without disrupting operations.
- Implement centralized AAA with TACACS+ and local fallback
- Configuration: Stand up TACACS+ servers; define aaa new-model with group TAC-GRP, authentication/authorization/accounting; create a local privilege-15 breakglass user.
- Rationale: Centralized identities and per-command authorization enforce least privilege, provide audit trails of administrative actions, and allow rapid credential revocation. Local fallback preserves access during AAA outages.
- Migrate management access to SSH and restrict by source
- Configuration: Generate RSA keys, enforce ip ssh version 2, disable Telnet, set line vty to transport input ssh with login authentication default; apply access-class MGMT_VTY in to allow only the NOC jump hosts.
- Rationale: Encrypting management traffic prevents credential interception; management ACLs reduce attack surface to a small, known set of sources.
- Protect the control plane with conservative CoPP
- Configuration: Create class-map for SSH, SNMP, NTP; apply policy-map COPP-POLICY that polices known management/control traffic and rate-limits class-default; attach to control-plane input.
- Rationale: Rate-limiting control-plane traffic sustains availability during floods without blocking essential protocols. Starting with relaxed rates avoids accidental self-denial.
- Enforce Layer 2 integrity at stores
- Configuration: Enable DHCP snooping on access VLANs, trust only uplinks to the WAN/relay; apply request/offer rate-limits. Enable DAI on the same VLANs; add static bindings for fixed-IP devices. Enable IP Source Guard on access ports.
- Rationale: These features block rogue DHCP servers, ARP spoofing, and IP impersonation at the first hop, preventing lateral movement and man-in-the-middle attacks.
- Segment applications with precise ACLs (IPv4 and IPv6)
- Configuration: Deploy extended IPv4 ACLs on access-facing interfaces to permit only required protocols (e.g., HTTPS to app servers) and deny/log all else. Deploy IPv6 ACLs with explicit ICMPv6 allowances for ND/RA/RS and app-specific permits; apply with ipv6 traffic-filter.
- Rationale: Source-near, protocol-specific filters minimize unwanted traffic and reduce bandwidth waste; preserving ICMPv6 ensures neighbor discovery and PMTU work reliably.
- Enable secure remote access and site-to-site encryption
- Configuration: Build IPsec site-to-site tunnels in tunnel mode between stores and data centers using IKEv2, AES-GCM, PFS, and lifetimes aligning with operational windows. Provide SSL/TLS-based remote-access VPN for staff with split tunneling to reduce headend load, coupled with endpoint posture checks.
- Rationale: Encrypting untrusted paths protects confidentiality/integrity; split tunneling balances security with performance when paired with endpoint controls.
- Deploy firewall and IPS at the perimeter and DC aggregation
- Configuration: Implement stateful firewall policy between untrusted, user, and server zones; position IPS inline on critical paths with tuned signatures for retail applications. Ensure path symmetry or enable state sharing.
- Rationale: Firewalls enforce high-level zone policy; IPS detects/block exploits preying on app and protocol weaknesses. Correct placement and tuning prevent false positives and asymmetric-state issues.
- Strengthen hardening, logging, and response
- Configuration: Set enable secret, enforce minimum password length and login throttling; enable secure boot-image/config. Configure NTP, buffered and remote syslog at informational severity, and AAA command accounting. Add deny log statements sparingly on key ACLs. Test the break-glass procedure.
- Rationale: Strong credentials and device integrity reduce compromise risk; synchronized, durable logs and accounting accelerate triage. Practiced recovery procedures minimize downtime during incidents.
By executing these steps in order—from identity and management plane, to Layer 2 hardening, to segmentation and encrypted transport, and finally to perimeter inspection and operational visibility—Orion achieves layered, least-privilege security with measurable controls and minimal disruption.
← Wireless LAN Design and Operations · All domains · WAN →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →