CyberPatriot Field Guide
Master Checklists

cisco Cisco Networking Master Checklist

Router/switch IOS hardening for the Packet Tracer module — lines, ACLs, VLANs, STP, routing, and a full worked example.

0 / 0 checked

A single, comprehensive reference for the CyberPatriot Cisco Networking / Packet Tracer module. Combines command references, an in-depth hardening checklist, and competition-oriented "extra points" guidance with exact IOS syntax. Organized for fast scanning during a live round — use the headers to jump directly to what you need.

How to use this doc: Skim the Overview once before the round starts. During the round, use Ctrl+F / header navigation to jump to the section matching the current question or task. Every section ends with a Things to try / extra points block containing ready-to-type command blocks.

On the "CIS Benchmark alignment" notes: Many "Things to try" bullets throughout this doc are explicitly tied back to the CIS Cisco IOS/IOS-XE Benchmark, which organizes device hardening into three families — Management Plane (how admins access/authenticate to the device: passwords, AAA, banners, SSH/line access), Control Plane (the protocols the device uses to run itself: routing, logging, NTP, unnecessary global services), and Data Plane (how the device forwards/filters actual traffic: ACLs, anti-spoofing, interface hardening). Where a tip maps to a Level 1 CIS control, it's baseline guidance appropriate for almost any device. Where a tip is flagged Level 2, it's more advanced/environment-specific — worth attempting if time allows, but lower priority than Level 1 basics. This doc refers to CIS controls by category name, not specific numbered control IDs, since exact numbering varies across CIS Benchmark versions/IOS releases. Because this category runs mostly in Packet Tracer rather than against a live scored real IOS/IOS-XE device, some CIS controls (especially deeper Control/Data Plane items like CoPP or uRPF) may not be fully supported or checkable in the simulator — these are flagged individually where relevant.

CHECKPOINT — Save Your Packet Tracer File BEFORE You Change Anything#

Packet Tracer has no VM-style hypervisor snapshot, but the equivalent habit is just as important: File → Save As a new incrementing filename (e.g., Round1_start.pkt → Round1_v1.pkt → Round1_v2.pkt) before you begin configuring, and again after each major milestone (passwords done, SSH done, VLANs done, ACLs done). If a bad command breaks connectivity or locks you out of a device, you can close without saving and reopen your last good .pkt version instead of rebuilding from scratch. On the devices themselves, run copy running-config startup-config frequently (not just at the end) — an accidental reload, a Packet Tracer crash, or a time-limit cutoff will wipe any unsaved running-config changes.

Table of Contents#

  1. Overview: CyberPatriot Cisco/Packet Tracer Module
  2. Router/Switch Access Modes & Navigation
  3. CLI Shortcuts & Line Editing
  4. Securing Console / VTY / AUX Lines
  5. Enable Secret vs. Enable Password
  6. Password Encryption & Policy
  7. Banner Messages
  8. SSH Configuration
  9. AAA & Local User Authentication
  10. Disabling Unused/Insecure Services
  11. Interface Basics & Unused Port Shutdown
  12. Port Security on Switches
  13. VLANs and VLAN Security
  14. Spanning Tree Protocol (STP) Hardening
  15. DHCP Snooping, Dynamic ARP Inspection & IPv6 RA Guard
  16. Access Control Lists (ACLs)
  17. Routing Basics & Routing Protocol Hardening
  18. DHCP Server Configuration
  19. NAT / PAT Configuration
  20. NTP, Logging & Syslog
  21. CDP and LLDP
  22. Saving, Backing Up & Restoring Configurations
  23. Verification: show Commands Reference
  24. Debugging & Clear Commands
  25. Password Recovery Process
  26. Packet Tracer Non-CLI / GUI Device Audits
  27. Packet Tracer Gotchas vs. Real Cisco IOS
  28. Full Worked Example: Router/Switch Hardening From Scratch
  29. Appendix A: OSI Model Cheat Sheet
  30. Appendix B: Subnetting / CIDR Quick Reference
  31. Appendix C: Common Ports Cheat Sheet
  32. Common Mistakes to Verify Before Submitting (Self-Audit Pass)
  33. Final Submission Checklist

1. Overview: CyberPatriot Cisco/Packet Tracer Module#

Tip: Read the ENTIRE question packet once before touching the topology. Some questions reference later devices or give away hints for earlier ones (e.g., an IP scheme needed for an ACL).

Things to try / extra points#

  • Before changing anything, run show running-config on every device and save/screenshot it — some rounds want you to identify existing misconfigurations, not just harden blindly.
  • Keep a scratch pad of the IP addressing scheme, VLAN IDs, and device names as you discover them; ACL and DHCP questions almost always depend on this info being correct.
  • If time is short, prioritize by point-density heuristics: password/auth hardening and banners are fast wins; ACLs and VLAN trunking take longer to get exactly right — budget time accordingly.

2. Router/Switch Access Modes & Navigation#

Cisco IOS uses a hierarchy of modes, each with its own prompt and available command set.

Mode Prompt Example How to Enter Purpose
User EXEC Router> Default on login Very limited — basic show/ping only
Privileged EXEC Router# enable from user EXEC Full show/debug/copy access
Global Configuration Router(config)# configure terminal from privileged EXEC Device-wide settings (hostname, banners, global services)
Interface Configuration Router(config-if)# interface <type> <number> from global config Per-interface settings (IP address, shutdown, switchport)
Line Configuration Router(config-line)# line console 0 / line vty 0 15 / line aux 0 Console/VTY/AUX password & access settings
Router (routing protocol) Config Router(config-router)# router ospf 1 / router rip from global config Routing protocol parameters
VLAN Config Router(config-vlan)# vlan <id> from global config VLAN naming
cisco-ios
Router> enable
Router# configure terminal
Router(config)# interface gigabitEthernet0/0
Router(config-if)# exit
Router(config)# line console 0
Router(config-line)# exit
Router(config)# router ospf 1
Router(config-router)# exit
Router(config)# exit
Router#
Expected result:
  • The prompt changes at each step to match the mode you entered — Router> to Router# after enable, to Router(config)# after configure terminal, to Router(config-if)# after interface, back to Router(config)# after exit from interface mode, to Router(config-line)# after line console 0, to Router(config-router)# after router ospf 1, and finally back to Router# after the last exit.
  • No output is printed for these navigation commands beyond the prompt itself changing.
If it fails:
  • If the prompt doesn't change as expected, you likely typed a command that wasn't recognized in that mode (e.g., interface typed from user EXEC instead of global config) — IOS reprints the same prompt with % Invalid input detected at '^' marker rather than moving you to a new mode.
  • Always read the current prompt before typing the next command; if you're several levels deep and lost, type end (or Ctrl-Z) to jump straight back to privileged EXEC and start over.

Navigation commands:

shell
enable / en          -> privileged EXEC
disable               -> back to user EXEC
configure terminal / conf t   -> global config
exit                  -> go up (out) one level
end  (or Ctrl-Z)      -> jump directly back to privileged EXEC from anywhere
interface <type>/<number>  (int) -> interface config mode
interface range <type>/<first> - <last>  -> configure multiple interfaces at once
interface vlan <vlan-id>   -> SVI (VLAN interface) config
line console 0        -> console line config
line vty 0 15         -> VTY (remote/telnet/ssh) line config
Expected result:These are reference command syntax, not a block to paste verbatim — each entered individually produces the corresponding mode change (e.g., typing enable at Router> moves you to Router#).
If it fails:If a shortened form like conf t returns % Ambiguous command: instead of entering config mode, another command starting with the same letters exists on that IOS image — type more of the word out (config t or configure terminal in full) to disambiguate.

Note the prompt always tells you exactly what mode you're in — > = user exec, # = privileged exec, (config)# = global config, (config-if)# = interface config, (config-line)# = line config. If you're not sure where you are, look at the prompt before typing anything.

Things to try / extra points#

  • Use interface range to save time when applying the same config to many ports at once:

    cisco-ios
    Switch(config)# interface range fastEthernet0/1 - 9
Switch(config-if-range)# switchport mode access
    What "interface range" saves you
    Without this, applying the same 5 lines of config to 9 different ports means typing `interface fastEthernet0/1`, the 5 lines, `exit`, `interface fastEthernet0/2`, the same 5 lines again... 9 times. `interface range` selects multiple ports at once (the prompt changes to config-if-range# to remind you) so every command you type after it applies to all selected ports simultaneously.
    Expected result:Prompt changes to Switch(config-if-range)# (note -range in the prompt, confirming multiple interfaces are selected), and switchport mode access applies to all 9 ports at once with no per-port output.
    If it fails:
    • % Invalid input detected on the interface range line usually means a typo in the interface name/range syntax — the space-dash-space around the range (0/1 - 9) matters on many IOS versions; also confirm the port numbers actually exist on that device (show ip interface brief lists valid interface names).
    • Verify the change landed on every port with show running-config interface range fastEthernet0/1 - 9.

  • Use end (or Ctrl-Z) instead of repeated exit to jump straight back to privileged EXEC when you're done configuring.

  • Use ? liberally — at any mode, typing ? lists valid next commands. Typing part of a command followed by ? (e.g., sh?) lists completions. This works even under exam time pressure and avoids syntax-error guessing.

  • Use Tab to auto-complete a partially typed command (e.g., conf<Tab> t<Tab> → configure terminal).

3. CLI Shortcuts & Line Editing#

Keys Action
Tab Completes an abbreviated command/parameter
Backspace Deletes character left of cursor
Ctrl-D Deletes character at the cursor
Ctrl-K Erases from cursor to end of line
Esc, D Erases from cursor to end of current word
Ctrl-U / Ctrl-X Erases from cursor back to start of line
Ctrl-W Erases word to the left of cursor
Ctrl-A Moves cursor to beginning of line
Ctrl-B / Left Arrow Cursor one character left
Esc, B Cursor one word left
Esc, F Cursor one word right
Ctrl-F / Right Arrow Cursor one character right
Ctrl-E Cursor to end of line
Ctrl-P / Up Arrow Recall previous command(s)
Down Arrow Recall more recent commands
Ctrl-R / Ctrl-I / Ctrl-L Redisplay current line (useful after a console message interrupts your typing)
Enter at --More-- Show next line
Space at --More-- Show next screen
Any other key at --More-- End pagination, return to prompt
Ctrl-C Abort current command / return to privileged EXEC
Ctrl-Z Return to privileged EXEC from any config mode
Ctrl-Shift-6 Abort an in-progress ping/traceroute

Things to try / extra points#

  • Use terminal length 0 (or terminal length <n>) if show running-config output is being cut off by --More-- and you want the full output at once.
  • If you fat-finger a no command and lock yourself out of a line, Ctrl-C or Ctrl-Shift-6 can save you from a hung session before you need a full device reload.

4. Securing Console / VTY / AUX Lines#

Every line that can be used to access the device (console, VTY = remote Telnet/SSH, AUX) must be password protected and, ideally, use login local against the local user database plus SSH-only transport for VTY.

Checkpoint before touching VTY lines: If you are connected to the device over Telnet/SSH (VTY) rather than the physical console, a mistake here (wrong login local with no valid username, transport input none, a bad access-class) can instantly lock out your own remote session. Save the .pkt file first, and if possible test line changes from the console line rather than the same VTY session you're editing.

cisco-ios
R1(config)# line console 0
R1(config-line)# password ConsoleP@ss1
R1(config-line)# login
R1(config-line)# exec-timeout 5 0
R1(config-line)# logging synchronous
R1(config-line)# exit

R1(config)# line vty 0 4
R1(config-line)# password VtyP@ss1
R1(config-line)# login
R1(config-line)# exec-timeout 5 0
R1(config-line)# exit
Expected result:
  • No output between commands other than the prompt shifting to R1(config-line)# after line console 0 / line vty 0 4, and back to R1(config)# after exit.
  • Verify with show running-config | section line con and line vty — each block should show password, login, and exec-timeout 5 0.
If it fails:
  • If login alone (no login local) is set but no password line exists under that line, anyone connecting gets % Login disabled on line ..., until 'password' is set with the "line password" command — always set the password before login, in that order.
  • If you get locked out of a VTY session while editing it live, don't panic — finish the command sequence in the same session (IOS won't drop your active connection just from re-typing login/password), then verify from a fresh connection attempt.

Common gotcha: Many teams only secure line vty 0 4 and forget that some devices have up to 16 VTY lines (0 15). An unsecured line vty 5 15 is an open backdoor even if 0 4 is locked down. Always check/secure the FULL VTY range.

cisco-ios
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 5 0
R1(config-line)# logging synchronous
R1(config-line)# exit
Expected result:
  • Prompt shows R1(config-line)# while configuring, back to R1(config)# after exit.
  • Confirm with show running-config | section line vty — it should show the full 0 15 range with login local, transport input ssh, and exec-timeout 5 0.
If it fails:
  • % Invalid input detected on login local almost always means no local user exists yet (username ... secret ...) — IOS will still accept the command, but you'll be locked out on the next connection attempt with % No password set or an immediate connection refusal; create the user first (see Section 9).
  • If transport input ssh errors, SSH may not be fully configured yet (RSA keys not generated) — configure SSH first per Section 8, then apply transport input ssh last so you don't lock out Telnet before SSH is ready.

AUX port (physical backdoor via serial/modem) — disable it if not in use:

cisco-ios
R1(config)# line aux 0
R1(config-line)# no exec
R1(config-line)# transport input none
R1(config-line)# exec-timeout 0 1
R1(config-line)# exit
Expected result:
  • Prompt moves through R1(config-line)# and back to R1(config)#; no console output confirms it since these are all no/config-setting commands.
  • Confirm with show running-config | section line aux — should show no exec, transport input none, and exec-timeout 0 1 (which effectively disables idle sessions almost immediately).
If it fails:
  • If you're physically/virtually connected via the AUX line itself when you run no exec, you'll be disconnected immediately — don't run this from an active AUX session.
  • In Packet Tracer, AUX is rarely used for actual connectivity, so this is usually safe to apply blind; on a real device, confirm nothing depends on AUX (e.g., a modem-based OOB management path) before disabling it.

Things to try / extra points#

  • Verify how many VTY lines actually exist with show run | section line vty or line vty ? — don't assume it's always 0 4; Packet Tracer routers/switches often default to 0 15.

  • Set exec-timeout on every line (console, vty, aux) — an easy, fast, commonly-overlooked hardening item.

  • Add brute-force login protection globally:

    cisco-ios
    R1(config)# login block-for 120 attempts 3 within 60
    Reading this command's syntax
    Read it as: IF 3 failed login attempts happen WITHIN 60 seconds, THEN block ALL logins FOR 120 seconds. It's brute-force protection — the numbers are (block-duration) (attempt-count) (time-window), in that specific order, which is easy to mix up when typing it from memory.
    Expected result:
    • No output on success; the prompt returns to R1(config)#.
    • Verify it's active with show login — it should report the block-for state ("Router NOT enabled to watch for login Attacks" before any failures, switching to "enabled" once attempts are being tracked).
    If it fails:
    • % Invalid input detected typically means the numbers are out of accepted range or in the wrong order — the syntax is strictly login block-for <seconds> attempts <tries> within <seconds>.
    • This command also silently does nothing useful unless at least one login/login local line exists to actually trigger failed attempts against.

    This blocks all logins for 120 seconds if 3 failed attempts occur within 60 seconds. Pair it with:

    cisco-ios
    R1(config)# login delay 2
R1(config)# security authentication failure rate 3 log
    Expected result:
    • No output; both commands return to R1(config)# prompt.
    • login delay 2 forces a 2-second wait between login attempts; the failure-rate command starts logging a syslog message once failed attempts exceed the given rate.
    If it fails:% Invalid input detected on security authentication failure rate usually means this specific command isn't supported on the Packet Tracer IOS image for that device model — it's a less commonly emulated command; if it's rejected, login block-for alone still provides the core brute-force protection, so don't spend excess time chasing an unsupported command.

  • Disable the AUX line entirely on devices where it isn't part of the intended topology — it's a commonly forgotten backdoor.

  • Always finish with show running-config | section line to confirm every line block shows login/login local, a password or local-auth, and (for vty) transport input ssh.

  • CIS Benchmark alignment: Securing console, VTY, and AUX lines with login/login local, exec-timeout, and login block-for maps directly to the CIS Cisco IOS/IOS-XE Benchmark's Management Plane "Access Rules" category — this is core, universally-applicable Level 1 guidance, not an edge case.

  • Additional CIS Level 1 Management Plane items worth adding if not already present: an explicit VTY transport policy (transport input ssh — never leave it at the default, which can implicitly allow all protocols), and confirming exec-timeout is non-zero on every line type (console, vty, aux) rather than just the ones a question happens to mention.

  • CIS also calls out restricting VTY access with an inbound ACL (access-class ... in) as part of Management Plane access control — see Section 16 for the worked example.

5. Enable Secret vs. Enable Password#

cisco-ios
R1(config)# enable secret Str0ngP@ss!
R1(config)# no enable password
Expected result:
  • No output; prompt stays at R1(config)#.
  • Verify with show running-config | include enable — should show a line like enable secret 5 $1$... (a hashed string, never the plaintext) and no enable password line at all.
If it fails:
  • If no enable password returns an error or seems to do nothing, it likely means no enable password was configured in the first place (nothing to remove) — this is fine, just confirm via show running-config.
  • If enable secret doesn't take effect (you can still get into privileged EXEC with the old password), double-check you're not still on an old already-authenticated session — log out and reconnect to force re-authentication with the new secret.

Things to try / extra points#

  • Grep the running config for enable password — if present alongside enable secret, remove it with no enable password even though enable secret "wins," because auditors/scoring may flag its mere presence.
  • Use a strong secret: mixed case, digits, symbols, 10+ characters (see Password Encryption & Policy for security passwords min-length).
  • On newer IOS, enable algorithm-type scrypt secret <pw> (or sha256) is available for stronger hashing than default MD5 — verify support with ? before relying on it, since Packet Tracer's IOS emulation may not support every hash algorithm.
  • CIS Benchmark alignment: "Use enable secret, never enable password" is a direct match for the CIS Cisco IOS/IOS-XE Benchmark's Management Plane "Password Rules" category (Level 1) — CIS treats any reversibly-encrypted or plaintext privileged-mode password as a finding regardless of whether a stronger secret is also present.

6. Password Encryption & Policy#

cisco-ios
R1(config)# service password-encryption
R1(config)# security passwords min-length 10
Expected result:
  • No output; prompt stays at R1(config)#.
  • Immediately re-run show running-config — every previously plaintext password <text> line should now read password 7 <obfuscated-hex-string>.
If it fails:
  • % Invalid input detected on security passwords min-length on some older Packet Tracer IOS images means that command isn't supported by that specific device's IOS feature set — it's a less commonly emulated command; don't spend excess time on it if rejected, service password-encryption alone still covers the main finding.
  • This does not upgrade any password to a real hash — a type 7 password is still trivially reversible with widely available tools, so don't treat it as a substitute for using secret/username ... secret wherever that option exists.

Things to try / extra points#

  • Run service password-encryption immediately after setting any passwords — it applies retroactively to already-configured plaintext passwords too, encrypting everything currently in the config.
  • Set security passwords min-length 10 (or per scenario instructions) early, before creating usernames, so later account creation is enforced.
  • Confirm with show running-config that no line shows a password in cleartext (look for password 7 ... = encrypted vs. password 0 ... or bare password <text> = plaintext).
  • autosecure (a.k.a. auto secure) is a one-shot wizard baseline-hardening command on real IOS that walks through many of these steps automatically — worth trying in Packet Tracer, but confirm output matches your intended config since Packet Tracer's feature support is inconsistent (see Section 27).
  • CIS Benchmark alignment: service password-encryption and security passwords min-length are both direct CIS Management Plane "Password Rules" (Level 1) items — this section is essentially a CIS baseline pass.
  • Additional CIS Level 1 password-hygiene item not shown above: confirm no leftover default or vendor-supplied credentials exist anywhere in the config (username cisco password cisco, etc. — see Section 9), since CIS explicitly flags default/known credentials as a critical finding independent of encryption settings.

7. Banner Messages#

A legal warning banner is a fast, easy, frequently-required item — set one on every device.

cisco-ios
R1(config)# banner motd #AUTHORIZED ACCESS ONLY. ALL ACTIVITY IS MONITORED AND LOGGED. UNAUTHORIZED ACCESS IS PROHIBITED AND WILL BE PROSECUTED.#
Expected result:
  • No output at config time; prompt returns to R1(config)#.
  • The banner text then displays automatically to anyone connecting via console/Telnet/SSH, before any login prompt.
If it fails:
  • If the banner appears truncated or IOS shows % Invalid input detected mid-message, the delimiter character (# here) appeared somewhere inside your message text, closing the banner early — pick a delimiter character guaranteed not to appear in the wording (e.g., $ or %) and retype the full command.
  • Verify the final result with show running-config | section banner, not just by eyeballing what you typed.
cisco-ios
R1(config)# banner login #Access restricted to authorized personnel only.#
R1(config)# banner exec #Welcome, authorized user. Remember to log off when finished.#
Expected result:
  • No output at config time.
  • On next connection, banner login displays right before the username/password prompt, and banner exec displays only after a successful login, right before the EXEC prompt appears.
If it fails:
  • Same delimiter-collision risk as banner motd — if the message contains the delimiter character, the banner cuts off early or IOS throws a syntax error.
  • Also note: despite the sample text here saying "Welcome," that's flagged as a graders' anti-pattern in the tip above — swap in neutral/legal wording before submitting, this sample is illustrative only.

Tip: Never use a welcoming banner (e.g., "Welcome to Router1!") — this is a classic CyberPatriot/real-world finding. Banners should be neutral/legal-warning wording, never friendly, since a welcoming banner can be construed as an invitation for unauthorized users.

Things to try / extra points#

  • Set a banner on every device in the topology, not just the one mentioned in a question — banners are a near-guaranteed, low-effort item.
  • Double check the delimiter character doesn't appear inside your message text, or the banner will truncate early/error out.
  • Verify with show running-config | section banner.
  • CIS Benchmark alignment: legal warning banners are a CIS Management Plane "Banner Rules" (Level 1) item. CIS specifically expects banner motd at minimum, and treats a missing, blank, or "welcoming" banner as a finding — this matches the neutral/legal-warning guidance above exactly.

8. SSH Configuration#

SSH requires: a hostname (not the default), a domain name, an RSA key pair, SSH version 2, local user authentication, and VTY lines restricted to SSH-only transport.

cisco-ios
R1(config)# hostname R1
R1(config)# ip domain-name cyberpatriot.local
R1(config)# username admin privilege 15 secret Str0ngP@ss!
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 3
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 5 0
R1(config-line)# exit
What this command is actually doing
This generates the public/private key pair the router will use to encrypt SSH sessions — without it, SSH can't work at all (there's nothing to encrypt with). "modulus 2048" sets the key size in bits — bigger is more secure but takes longer to generate; 2048 is the modern standard. This step needs a hostname and domain name already set, because the key's internal name is built from hostname.domain-name.
Expected result:
  • crypto key generate rsa modulus 2048 prints key-generation progress (The name for the keys will be: R1.cyberpatriot.local, followed by % Generating 2048 bit RSA keys, keys will be non-exportable...[OK]) after a brief pause.
  • Everything else returns silently to the next prompt.
  • Confirm SSH is live with show ip ssh — SSH Enabled - version 2.0 should appear.
If it fails:
  • % Please define a domain-name first or % Please configure a hostname other than Router means hostname and ip domain-name weren't set before crypto key generate rsa — set both first, then generate keys.
  • If show ip ssh shows version 1.99 or SSH disabled after key generation, run ip ssh version 2 explicitly (key generation alone doesn't force v2).
  • If VTY still accepts Telnet after this block, double check transport input ssh actually applied — show running-config | section line vty should show it, not the default transport input all/telnet.

Notes:

cisco-ios
R1(config)# crypto key zeroize rsa
R1(config)# crypto key generate rsa modulus 2048
What this command is actually doing
This generates the public/private key pair the router will use to encrypt SSH sessions — without it, SSH can't work at all (there's nothing to encrypt with). "modulus 2048" sets the key size in bits — bigger is more secure but takes longer to generate; 2048 is the modern standard. This step needs a hostname and domain name already set, because the key's internal name is built from hostname.domain-name.
Expected result:
  • crypto key zeroize rsa prints a confirmation prompt (% All RSA keys will be removed...
  • Continue? [yes/no]: — answer yes), then the regenerate command re-prompts through the normal key-generation output.
If it fails:If regenerating with a different modulus size silently keeps the old key size, the zeroize step didn't actually complete — confirm with show crypto key mypubkey rsa that no key exists before regenerating, and answer the yes/no confirmation explicitly rather than assuming Enter defaults to yes.

Things to try / extra points#

  • Full sequence, in order (order matters — domain name and hostname MUST be set first):
    cisco-ios
    R1(config)# hostname R1
R1(config)# ip domain-name cyberpatriot.local
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# username admin privilege 15 secret Str0ngP@ss!
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exit
    What this command is actually doing
    This generates the public/private key pair the router will use to encrypt SSH sessions — without it, SSH can't work at all (there's nothing to encrypt with). "modulus 2048" sets the key size in bits — bigger is more secure but takes longer to generate; 2048 is the modern standard. This step needs a hostname and domain name already set, because the key's internal name is built from hostname.domain-name.
  • Verify SSH is actually active and version 2: show ip ssh and show ssh (the latter shows active sessions).
  • If crypto key generate rsa prompts "How many bits in the modulus," and you're not asked interactively, use the modulus keyword inline to avoid the prompt: crypto key generate rsa modulus 2048.
  • Telnet is plaintext — sends credentials in the clear. If a question asks "how would you securely access this device remotely," the answer is SSH, not Telnet, and this is worth stating explicitly on written-answer questions.
  • In Packet Tracer specifically, RSA key generation can sometimes take a noticeable pause or silently fail on very old device IOS images — if ip ssh version 2 reports no SSH support after key generation, double-check the device's IOS image/model supports crypto features (older router models in Packet Tracer's device library may not).
  • CIS Benchmark alignment: forcing SSHv2-only remote access (ip ssh version 2 + transport input ssh), setting ip ssh time-out and ip ssh authentication-retries, and using a real user database rather than a shared line password are all direct CIS Management Plane "Access Rules" (Level 1) items.
  • A couple of additional CIS Level 1 SSH-hardening items to be aware of, flagged as possibly not checkable/supported in Packet Tracer: minimum Diffie-Hellman key exchange group size (ip ssh dh min size 2048 on real IOS) and limiting concurrent unauthenticated SSH connection attempts (ip ssh maxstartups) — verify with ? on the actual device before assuming these commands exist in your Packet Tracer IOS image.

9. AAA & Local User Authentication#

cisco-ios
R1(config)# username admin privilege 15 secret AdminUserPass123!
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
Expected result:
  • No output; prompt stays at R1(config)# throughout.
  • Verify with show running-config | include username|aaa — should show the hashed username admin privilege 15 secret 5 $1$... line plus both aaa lines.
If it fails:
  • The moment aaa new-model is entered, it can change how the current session itself is authenticated — if you're on a VTY/SSH session and no valid local user + login local (or the aaa authentication login default local line) is fully in place yet, you risk being locked out immediately on your next connection attempt.
  • Always enter username ... secret ... BEFORE aaa new-model, and test login from a fresh session (or keep your current session open) rather than disconnecting immediately after.
  • If locked out anyway, Packet Tracer requires closing without saving and reopening the last saved .pkt, or a real-device password-recovery process (Section 25).

Things to try / extra points#

  • Remove/rename any obviously weak or default usernames you find already configured (e.g., username cisco password cisco, username admin password admin) — these are classic planted vulnerabilities.
    cisco-ios
    R1(config)# no username cisco
    Expected result: No output; the account is removed immediately. Confirm with show running-config | include username — the removed name should no longer appear. If it fails: % Can't remove last enabled user (wording varies) if this is the only local user and login local is active on a line you need — create a replacement admin user first, verify you can log in with it, then remove the weak/default one, rather than deleting your only working credential.
  • Always use secret (hashed), never password (weakly encrypted/plaintext), when creating usernames: username admin secret ... not username admin password ....
  • Set an explicit privilege level appropriate to the account's role — privilege 15 for full admin, privilege 1 (default) for a restricted view-only account if the scenario calls for tiered access.
  • If aaa new-model is enabled, double-check you still have a way in (e.g., a valid local user + login local on console) before saving/reloading — misconfigured AAA can lock you out of the device, which in Packet Tracer typically requires a reload/password-recovery process to fix.
  • CIS Benchmark alignment: local user creation with secret-hashed passwords and aaa authentication login default local map to the CIS Management Plane "AAA Rules" category (Level 1).
  • Additional CIS Level 1 AAA item worth adding if time allows: aaa authentication enable default (requires a valid username/password to reach privileged EXEC via AAA, not just the shared enable secret). CIS also recommends aaa accounting exec / aaa accounting commands to log administrative actions — flag this as likely limited or unsupported in Packet Tracer (no real external TACACS+/RADIUS accounting server, and local accounting logging is minimal), so treat it as a "know the concept for written questions" item more than a guaranteed hands-on task.

10. Disabling Unused/Insecure Services#

These services either leak information, are outdated/insecure, or simply aren't needed and increase attack surface.

cisco-ios
R1(config)# no ip http server
R1(config)# no ip http secure-server
R1(config)# no ip source-route
R1(config)# no ip bootp server
R1(config)# no service config
R1(config)# no service finger
R1(config)# no service tcp-small-servers
R1(config)# no service udp-small-servers
R1(config)# no ip domain-lookup
Expected result:
  • No output; each no command is silent on success.
  • Verify the full sweep with show running-config | include http|finger|bootp|source-route|small-servers|domain-lookup — none of the disabled services/features should appear as enabled.
If it fails:
  • % Invalid input detected on any individual line usually means that command doesn't exist on this specific device's IOS image/model in Packet Tracer (older router models emulate a smaller command set) — skip that one line and continue with the rest; don't let one unsupported command stop the whole sweep.
  • None of these commands require anything to be configured first, so order doesn't matter and they're safe to run in any sequence.
Command Why disable it
no ip http server Disables the unencrypted web-based management GUI
no ip http secure-server Disables the HTTPS web GUI too, unless it's specifically required by the scenario
no ip source-route Prevents source-routed packets from overriding normal routing (spoofing/attack vector)
no ip bootp server Disables the legacy BOOTP service, rarely needed today
no service config Prevents the router from trying to auto-load its config from a network server at boot (avoids config tampering via rogue TFTP)
no service finger Disables the Finger service, which leaks logged-in user info
no service tcp-small-servers / no service udp-small-servers Disables legacy diagnostic services (echo, chargen, discard, daytime) that serve no modern purpose and can be abused for DoS/amplification
no ip domain-lookup Stops the device from trying to DNS-resolve mistyped commands (which otherwise causes an annoying hang) — a quality-of-life + minor hardening item
no cdp run See Section 21
no ip proxy-arp Per-interface; prevents the router answering ARP requests on behalf of other hosts (info leak/MITM vector) — see Section 11

Note: On many modern IOS versions, tcp-small-servers/udp-small-servers and finger are already off by default — running the no form is harmless (idempotent) and worth doing anyway in case the scenario's image has them explicitly turned on as a planted vulnerability.

Things to try / extra points#

  • Run all of the disable commands above as a standard sweep on every router/switch, even if not explicitly asked — this is a common "unnecessary services" checklist item across CyberPatriot categories, not just Cisco.
  • After disabling, verify with show running-config | include http|finger|bootp|source-route|small-servers (or just eyeball the full show running-config).
  • If a scenario says the device SHOULD be managed via a web GUI, don't blindly disable ip http secure-server — read the question carefully; the "harden everything" instinct can break a required legitimate service. Prefer ip http secure-server (HTTPS) over ip http server (HTTP) if a GUI truly is required.
  • CIS Benchmark alignment: this entire section is essentially a direct implementation of the CIS Control Plane "Global Service Rules" category (Level 1) — disabling ip http server, ip bootp server, service finger, service tcp-small-servers/udp-small-servers, ip source-route, and CDP are all standard CIS baseline items.
  • One CIS Level 1 global-service item not shown above and worth adding: no service pad (disables the legacy X.25 PAD service, an old and rarely-needed protocol that adds attack surface for no modern benefit). Try it, but flag it as possibly unsupported/no-op in Packet Tracer's IOS image — if the command isn't recognized, note that and move on rather than losing time on it.

11. Interface Basics & Unused Port Shutdown#

cisco-ios
R1(config)# interface gigabitEthernet0/0
R1(config-if)# description LINK_TO_ISP
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no ip redirects
R1(config-if)# no ip unreachables
R1(config-if)# no ip proxy-arp
R1(config-if)# no shutdown
R1(config-if)# exit
Expected result:
  • After no shutdown, the console typically prints an unsolicited line-protocol message like %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up (may take a few seconds in Packet Tracer).
  • Confirm with show ip interface brief — status should read up/up.
If it fails:
  • If status stays administratively down after no shutdown, re-check you actually ran it inside the correct interface context (R1(config-if)#, not R1(config)#) — a shutdown/no shutdown typed at the wrong prompt level silently does nothing or errors.
  • If status shows down/down (not administratively down), that's a Layer 1 issue — check the cable/link is actually connected in the Packet Tracer topology, not a config problem.

Shutting down unused interfaces (physical ports with no cable / no intended device) prevents rogue devices from simply plugging in and getting network access:

cisco-ios
Switch(config)# interface range fastEthernet0/10 - 24, gigabitEthernet0/2
Switch(config-if-range)# shutdown
Switch(config-if-range)# description UNUSED_DISABLED
Switch(config-if-range)# exit
Expected result:No console output for shutdown on unused ports (no link to report a state change on); show ip interface brief afterward should show administratively down for the whole range.
If it fails:% Incomplete command or a range error on interface range if the comma-separated mixed range syntax (fastEthernet0/10 - 24, gigabitEthernet0/2) isn't typed exactly right on this IOS image — some older Packet Tracer devices don't support comma-separated multi-range syntax; if it fails, configure each range separately (interface range fastEthernet0/10 - 24 then a separate interface gigabitEthernet0/2 block) instead.

Things to try / extra points#

  • Cross-reference the physical topology diagram (or show ip interface brief "status/protocol" columns) to identify every port with no connected device, and shut every single one down — this is one of the highest-value, fastest checklist items in the whole module.

    cisco-ios
    Switch# show ip interface brief
    Expected result:A table of every interface with IP address, OK?, Method, Status, and Protocol columns.
    If it fails:No error mode; a very long list on a chassis switch may scroll past --More-- — use terminal length 0 first if you need the full output at once (see Section 3).

    Look for interfaces with unassigned and check the topology for a missing cable — those need shutdown.

  • Also move unused switchports into an unused/"parking lot" VLAN (e.g., VLAN 999) in addition to shutting them down — defense in depth, in case someone later runs no shutdown without noticing the VLAN assignment:

    cisco-ios
    Switch(config-if-range)# switchport access vlan 999
    Expected result:
    • No output; silent on success.
    • show vlan brief afterward should list VLAN 999 with these ports assigned (auto-creates VLAN 999 if it doesn't already exist, on most IOS versions).
    If it fails:
    • % Access VLAN does not exist.
    • Creating vlan ... is informational, not an error — it confirms the VLAN was auto-created.
    • If the VLAN doesn't take effect, some IOS versions require vlan 999 / name PARKING_LOT to be explicitly created in global config first before assigning ports to it — create it explicitly if the auto-create message doesn't appear.

  • Re-enable (no shutdown) any interface that legitimately needs to be up but was found administratively shut down as a planted "denial of service" vulnerability — always check both directions (things that should be off, and things that should be on but were sabotaged).

  • Apply no ip redirects, no ip unreachables, and no ip proxy-arp on every routed (Layer 3) interface, especially any interface facing an untrusted segment.

  • CIS Benchmark alignment: no ip redirects, no ip unreachables, and no ip proxy-arp on routed interfaces are direct CIS Data Plane interface-hardening items (part of the border/interface-level anti-spoofing and information-leakage controls), Level 1.

  • A CIS Level 1 Data Plane item not shown above worth adding on every routed interface: no ip directed-broadcast (prevents the interface from forwarding broadcast traffic destined for its own subnet onto the local segment — historically abused for "Smurf"-style amplification floods). On modern IOS this is off by default, but set it explicitly since a scenario may have re-enabled it as a planted issue.

12. Port Security on Switches#

Port security limits which/how many MAC addresses may use an access port, mitigating MAC flooding and rogue device connections.

cisco-ios
Switch(config)# interface range fastEthernet0/1 - 9
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport port-security
Switch(config-if-range)# switchport port-security maximum 1
Switch(config-if-range)# switchport port-security mac-address sticky
Switch(config-if-range)# switchport port-security violation shutdown
Switch(config-if-range)# exit
What "sticky" does
Instead of you having to manually type in the exact MAC address every legitimate device on a port should have, "sticky" tells the switch to learn the first MAC address(es) it actually sees on that port and automatically write them into the running config as if you'd typed them yourself. It's the low-effort way to lock a port to "whatever's already plugged in" without hunting down every MAC address by hand.
Expected result:No output for any of these commands; verify with show port-security interface fastEthernet0/1 — should show Port Security: Enabled, Maximum MAC Addresses: 1, Violation Mode: Shutdown.
If it fails:
  • % Command rejected: FastEthernet0/1 is a dynamic port. (or similar) if switchport mode access wasn't set first, or if the port is currently a trunk — port security requires a static access port; run switchport mode access before the port-security lines, not after.
  • If a currently-connected PC gets disconnected/port goes err-disabled immediately after applying this, the port already had more than 1 MAC in use (e.g., a hub/switch daisy-chained behind it) — raise maximum accordingly or investigate what's actually plugged in.
Mode Behavior on violation
protect Drops offending traffic silently, port stays up, no log/counter increment
restrict Drops offending traffic, increments violation counter, and can log/SNMP-trap
shutdown (default) Puts the port into err-disabled state — port goes completely down until manually recovered (or auto-recovery is configured)
cisco-ios
Switch(config-if-range)# switchport port-security violation protect
Switch(config-if-range)# switchport port-security violation restrict
Switch(config-if-range)# switchport port-security violation shutdown
Expected result:
  • No output; only the last mode set actually takes effect (these three lines are shown together for reference, not meant to be run as a sequence — pick one).
  • Confirm the active mode with show port-security interface <id>.
If it fails:
  • No error mode for any of these three individually.
  • If you're testing violations for a forensics/demo question, remember shutdown mode requires manual (or auto) recovery afterward per the note below — don't use shutdown mode if you're actively testing violation behavior and want the port to keep passing traffic for the next test.

Things to try / extra points#

  • Apply port security to every access port with an end-user device connected — not just a single interface the question mentions.

  • maximum 1 is the common default for a single-PC access port; use a higher number (e.g., 2) only if an IP phone + PC daisy-chain (voice VLAN) is in the topology.

  • sticky MACs are usually the fastest and most "automatic" approach in Packet Tracer — after applying, verify learned addresses got written into the running config:

    cisco-ios
    Switch# show port-security address
Switch# show running-config interface fastEthernet0/1
    Expected result:show port-security address lists each learned MAC with its VLAN and interface; the running-config should now show a switchport port-security mac-address sticky <MAC> line that wasn't there before (auto-inserted once a device sends traffic on that port).
    If it fails:No sticky MAC appears yet if no device has actually sent traffic on that port since sticky was enabled — it learns on next observed frame, not retroactively; generate traffic (e.g., ping from the connected PC) and re-check.

  • If a port goes err-disabled (from a shutdown violation) during testing, recover it manually with:

    cisco-ios
    Switch(config-if)# shutdown
Switch(config-if)# no shutdown
    Expected result:Interface bounces down then up; show interfaces fastEthernet0/1 status (or show port-security interface) should show the port back in a normal connected/secure-up state instead of err-disabled.
    If it fails:If the port immediately re-enters err-disabled right after recovery, the offending extra device/MAC is still physically connected and still violating the limit — the manual bounce doesn't fix the underlying cause, only clears the disabled state momentarily.

    or configure automatic recovery so you don't have to babysit it:

    cisco-ios
    Switch(config)# errdisable recovery cause psecure-violation
Switch(config)# errdisable recovery cause bpduguard
Switch(config)# errdisable recovery interval 30
    Expected result:No output; verify with show errdisable recovery — both causes should show Enabled with a 30-second interval.
    If it fails:
    • % Invalid input detected on bpduguard if BPDU Guard hasn't been configured anywhere yet (Section 14) — that's fine, the recovery cause can still be pre-enabled even before the feature that triggers it exists.
    • Auto-recovery means a repeatedly-violating port will just keep cycling down/up every 30 seconds — if you see a port flapping, that indicates an ongoing violation still needs real investigation, not just auto-recovery.

  • Verify overall port security status quickly: show port-security (summary of all ports) and show port-security interface <id> (detail for one port).

  • CIS Benchmark note: the core CIS Cisco IOS/IOS-XE Benchmark is primarily written around router-level Management/Control/Data Plane controls; switch-specific Layer 2 features like port security aren't part of its main control set. That doesn't make port security less important — it's standard switch-hardening best practice and a near-certain CyberPatriot checklist item — it's just sourced from general L2 security guidance rather than the CIS device benchmark specifically.

13. VLANs and VLAN Security#

Checkpoint before reconfiguring trunks/VLANs: Changing switchport mode trunk, native VLAN, or allowed-VLAN lists on a live uplink can instantly cut inter-switch or inter-VLAN connectivity for the whole topology, not just one port. Save the .pkt file before this section, make one change at a time, and re-verify with show vlan brief / show interfaces trunk before moving to the next port.

Creating and assigning VLANs#

cisco-ios
Switch(config)# vlan 10
Switch(config-vlan)# name SALES
Switch(config-vlan)# exit

Switch(config)# interface fastEthernet0/5
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# exit
Expected result:No output; verify with show vlan brief — VLAN 10 should appear named SALES with fastEthernet0/5 listed under its interfaces.
If it fails:
  • % Invalid input detected on switchport access vlan 10 if the VLAN wasn't created first (some IOS versions auto-create it with a warning instead, others reject it outright) — always create the VLAN with vlan 10 / name ... before assigning ports to it.
  • If the port doesn't show up under VLAN 10 in show vlan brief, confirm switchport mode access was set — a port left in default dynamic mode may not take the static VLAN assignment as expected.

Trunk configuration#

cisco-ios
Switch(config)# interface gigabitEthernet0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk allowed vlan 10,20,30
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# switchport nonegotiate
Switch(config-if)# exit
Expected result:No output; verify with show interfaces trunk — the interface should show Encapsulation: 802.1q, the correct allowed-VLAN list, and native VLAN 999 (not the default 1).
If it fails:
  • % Command rejected on switchport trunk encapsulation dot1q on switches that only support 802.1Q (many modern Packet Tracer switches have no ISL option and don't need/accept this line at all) — if rejected, just skip it and proceed to switchport mode trunk.
  • Native VLAN mismatch between the two ends of a trunk is a silent, hard-to-diagnose failure — IOS won't error, but traffic on the native VLAN can leak between switches or trigger a %CDP-4-NATIVE_VLAN_MISMATCH warning; always set the same native VLAN number on both ends and verify with show interfaces trunk on both switches.

Inter-VLAN routing (SVI or router-on-a-stick)#

shell
! Multilayer switch SVI approach:
Switch(config)# interface vlan 10
Switch(config-if)# ip address 192.168.10.1 255.255.255.0
Switch(config-if)# no shutdown
Switch(config-if)# exit

! Router-on-a-stick subinterface approach:
Router(config)# interface gigabitEthernet0/0.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.1 255.255.255.0
Router(config-subif)# exit
Expected result:No output for either approach; confirm with show ip interface brief — the SVI (Vlan10) or subinterface (GigabitEthernet0/0.10) should show up/up and the assigned IP.
If it fails:
  • SVI approach: the SVI stays down if VLAN 10 doesn't exist yet on that switch, or if no physical port is actually assigned to and up in VLAN 10 anywhere on the switch — an SVI needs at least one active port in that VLAN to come up.
  • Router-on-a-stick: % Invalid input detected on encapsulation dot1q 10 if the subinterface number (.10) doesn't match the VLAN ID argument — by convention they should match for clarity but IOS doesn't strictly require it; if inter-VLAN traffic still doesn't pass, verify the switch-side trunk actually has VLAN 10 in its allowed list (switchport trunk allowed vlan).

VLAN Security — Preventing VLAN Hopping#

VLAN hopping attacks exploit default trunk negotiation (DTP) or a default/matching native VLAN to let an attacker jump between VLANs they shouldn't have access to. Mitigate with:

  1. Change the native VLAN away from the default VLAN 1 on every trunk, and make sure both ends of a trunk agree on it:
    cisco-ios
    Switch(config)# vlan 999
Switch(config-vlan)# name UNUSED_NATIVE_VLAN
Switch(config-vlan)# exit
Switch(config)# interface gigabitEthernet0/1
Switch(config-if)# switchport trunk native vlan 999
    Expected result: No output; show interfaces trunk shows native VLAN 999 for that trunk. If it fails: No error mode beyond the mismatch risk noted above — the real failure mode here is forgetting to change it identically on the switch at the OTHER end of the trunk, which won't error but creates a native VLAN mismatch.
  2. Disable DTP (Dynamic Trunking Protocol) so ports can't be auto-negotiated into trunk mode by a connected attacker device:
    cisco-ios
    Switch(config)# interface range fastEthernet0/1 - 9
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport nonegotiate
    What "interface range" saves you
    Without this, applying the same 5 lines of config to 9 different ports means typing `interface fastEthernet0/1`, the 5 lines, `exit`, `interface fastEthernet0/2`, the same 5 lines again... 9 times. `interface range` selects multiple ports at once (the prompt changes to config-if-range# to remind you) so every command you type after it applies to all selected ports simultaneously.
    Expected result: No output; show interfaces fastEthernet0/1 switchport should show Negotiation of Trunking: Off. If it fails: switchport nonegotiate is only meaningful when the port mode is explicitly access or trunk (not dynamic auto/dynamic desirable) — if it seems to have no effect, confirm switchport mode access (or trunk) actually applied first; nonegotiate on a still-dynamic port doesn't fully stop DTP. switchport nonegotiate should also be applied on legitimate trunk ports (in addition to switchport mode trunk) to fully stop DTP frames from being sent/processed.
  3. Never use VLAN 1 for user traffic or management — leave it unused/unassigned where possible; move management traffic to a dedicated management VLAN.
  4. Explicitly prune trunk-allowed VLANs (switchport trunk allowed vlan <list>) instead of allowing all VLANs across every trunk by default.

Things to try / extra points#

  • Full native-VLAN-hardening worked example:

    cisco-ios
    Switch(config)# vlan 999
Switch(config-vlan)# name UNUSED_NATIVE_VLAN
Switch(config-vlan)# exit
Switch(config)# interface gigabitEthernet0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# switchport trunk allowed vlan 10,20,30
Switch(config-if)# switchport nonegotiate
    Expected result:No output across the block; show interfaces trunk should reflect all four changes together (trunk mode, native VLAN 999, allowed list 10/20/30, negotiation off).
    If it fails:Order matters here — switchport mode trunk should come before switchport trunk allowed vlan/native vlan on some IOS versions, or those sub-commands can be silently ignored/reset; if the final show interfaces trunk doesn't reflect a setting you typed, re-apply it after confirming trunk mode is already active.

  • Set every access port explicitly to switchport mode access (don't leave ports in the default "dynamic auto/desirable" negotiation mode) — this alone blocks a huge class of VLAN-hopping and rogue-trunk attacks.

  • Verify with:

    cisco-ios
    Switch# show vlan brief
Switch# show interfaces trunk
Switch# show interfaces fastEthernet0/1 switchport
    Expected result:Three separate views of VLAN state — show vlan brief for VLAN-to-port mapping, show interfaces trunk for trunk-specific detail (only shows ports actually in trunk mode — empty output here means no trunks are currently configured, which is a valid result on an access-only switch), show interfaces ... switchport for per-port mode/VLAN/negotiation detail.
    If it fails:No error mode; if show interfaces trunk returns nothing at all, that's often not a failure — it just means no interface on that switch is currently trunking, which may be entirely correct depending on the topology.

    Confirm: access ports show Administrative Mode: static access; trunk ports show the correct native VLAN and allowed VLAN list; DTP negotiation shows off/Not-Negotiate.

  • Double check VLAN naming matches what the scenario/topology diagram calls for — a wrong VLAN name (even with correct ID/ports) is sometimes explicitly checked.

  • If a management VLAN is specified, make sure the switch's management SVI (interface vlan <mgmt-id>) — not VLAN 1 — carries the switch's own IP address for remote administration.

  • CIS Benchmark note: native VLAN change, DTP disabling, and VLAN pruning are standard Layer 2 security best practices bundled with most Cisco switch hardening guides, but — like port security — they sit outside the core router-oriented CIS Cisco IOS/IOS-XE Benchmark control set. Treat them as "always do this" competition hygiene rather than something you need a specific CIS citation to justify.

14. Spanning Tree Protocol (STP) Hardening#

STP prevents Layer-2 loops, but its defaults are also an attack surface (rogue switches claiming to be root, forged BPDUs).

cisco-ios
Switch(config)# interface range fastEthernet0/1 - 9
Switch(config-if-range)# spanning-tree portfast
Switch(config-if-range)# spanning-tree bpduguard enable
Switch(config-if-range)# exit

Switch(config)# spanning-tree portfast default
Switch(config)# spanning-tree portfast bpduguard default
What "interface range" saves you
Without this, applying the same 5 lines of config to 9 different ports means typing `interface fastEthernet0/1`, the 5 lines, `exit`, `interface fastEthernet0/2`, the same 5 lines again... 9 times. `interface range` selects multiple ports at once (the prompt changes to config-if-range# to remind you) so every command you type after it applies to all selected ports simultaneously.
Expected result:
  • spanning-tree portfast on an interface prints a one-time warning (%Warning: portfast should only be enabled on ports connected to a single host...) — this is informational, not an error, confirming the command took effect.
  • Verify with show spanning-tree interface fastEthernet0/1 detail — should show Port is in the portfast mode.
If it fails:If a PortFast+BPDU-Guard port immediately goes err-disabled right after applying this, that port is actually connected to another switch (receiving real BPDUs), not an end host — double check the topology before applying, or move that port's config out of the range if it's a genuine inter-switch link.

Things to try / extra points#

  • Apply spanning-tree portfast + spanning-tree bpduguard enable on every genuine access port (end-host ports only) — never on inter-switch trunk/uplink ports.
  • Set the global defaults (spanning-tree portfast default and spanning-tree portfast bpduguard default) so you don't have to remember it per-interface — but be aware this only auto-applies PortFast to ports explicitly in access mode, not trunks.
  • Add storm control on access ports to blunt broadcast/multicast flooding DoS attempts:
    cisco-ios
    Switch(config-if-range)# storm-control broadcast level 10.00
Switch(config-if-range)# storm-control multicast level 10.00
    Expected result: No output; verify with show storm-control broadcast / show storm-control multicast — should list the configured 10.00% threshold per interface. If it fails: % Invalid input detected if this device/IOS image doesn't support storm-control (common on some older Packet Tracer switch models) — not every simulated switch model implements it; skip and note if unsupported rather than spending time troubleshooting a genuinely unsupported command. A threshold set too low can start dropping legitimate bursty traffic (e.g., a chatty broadcast-heavy application) — 10% is a reasonable moderate default, not a hard requirement.
  • Pair bpduguard/psecure-violation err-disable events with auto-recovery (shown in Section 12) so a triggered defense doesn't leave a legitimate port down for the rest of the round.
  • Verify: show spanning-tree summary, show spanning-tree interface <id> detail, show interfaces status err-disabled.
  • CIS Benchmark note: STP hardening (PortFast, BPDU Guard, root guard, storm control) is, like VLAN/port security, a Layer 2 switch best-practice item rather than part of the core CIS Cisco IOS device benchmark's Management/Control/Data Plane control set — still worth doing, just sourced from general switch-hardening guidance.

15. DHCP Snooping, Dynamic ARP Inspection & IPv6 RA Guard#

These Layer-2 features stop rogue DHCP servers and ARP/IPv6-RA spoofing (MITM) attacks — valuable if the scenario topology includes untrusted-looking access ports or a suspicious rogue-server device.

CIS Benchmark note: These are advanced Layer 2 mitigations, not part of the core router-focused CIS Cisco IOS/IOS-XE Benchmark. They're worth trying if the topology has the relevant switches and time allows, but lower priority than the Management Plane basics (Sections 4-9) and the Data Plane ACL/anti-spoofing items (Section 16) below, which map more directly to CIS Level 1 guidance and are more likely to be explicitly asked about.

DHCP Snooping#

cisco-ios
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 1,10,20
Switch(config)# no ip dhcp snooping information option
Switch(config)# interface gigabitEthernet0/1
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# exit
Expected result:No output; verify with show ip dhcp snooping — DHCP snooping is enabled, the listed VLANs, and gigabitEthernet0/1 shown as trusted while all other ports default to untrusted.
If it fails:
  • The single most common mistake: forgetting to mark the uplink/legitimate-server port as trusted — every DHCP client on an untrusted VLAN will then fail to get an address at all, since even the real server's replies get dropped.
  • If clients suddenly can't obtain DHCP leases right after enabling snooping, that's the first thing to check.
  • % Invalid input detected on no ip dhcp snooping information option means this device doesn't insert Option 82 by default anyway — safe to skip if rejected.
  • Only the uplink/trunk port connected to the legitimate DHCP server should be marked trusted; every other (access) port defaults to untrusted and will drop DHCP server-originated messages (OFFER/ACK) — killing rogue DHCP servers plugged into user ports.

Dynamic ARP Inspection (DAI)#

cisco-ios
Switch(config)# ip arp inspection vlan 1,10,20
Switch(config)# interface gigabitEthernet0/1
Switch(config-if)# ip arp inspection trust
Switch(config-if)# exit
Expected result:No output; verify with show ip arp inspection — Source Mac Validation/Destination Mac Validation status and per-VLAN enable state, plus the trusted interface list.
If it fails:If legitimate hosts suddenly lose connectivity (ARP resolution failing) right after enabling DAI, the DHCP snooping binding table (Section 15's DHCP Snooping block) probably isn't populated yet for those hosts — DAI validates ARP against that table, so a host that got its IP before snooping was enabled has no binding entry and gets its ARP traffic dropped; have it renew its DHCP lease (or reboot the PC in Packet Tracer) to get a fresh, tracked binding.
  • DAI relies on the DHCP snooping binding table to validate ARP replies — configure DHCP snooping first (or alongside) for DAI to be effective.

IPv6 RA Guard#

cisco-ios
Router(config)# ipv6 unicast-routing
Switch(config)# interface range fastEthernet0/1 - 24
Switch(config-if-range)# ipv6 nd raguard attach-policy
Expected result:No output; RA Guard silently drops rogue Router Advertisements arriving on the configured (non-uplink) ports.
If it fails:% Invalid input detected is common — RA Guard requires a relatively recent IOS/switch feature set and is frequently not supported in Packet Tracer's simulated switch models at all; if rejected, note it as unsupported in this environment rather than spending time on it — this feature is explicitly lower-priority per the section note above.

Things to try / extra points#

  • Only trust the port(s) that face the legitimate DHCP server / router uplink — trusting the wrong port defeats the whole feature.
  • Verify snooping table and status:
    cisco-ios
    Switch# show ip dhcp snooping
Switch# show ip dhcp snooping binding
Switch# show ip arp inspection
    Expected result: Status/config summary, the actual learned IP-to-MAC-to-port bindings (empty until clients have actually leased addresses since snooping was enabled), and ARP inspection status per VLAN/interface. If it fails: An empty binding table isn't necessarily broken — it only populates as devices lease new/renewed DHCP addresses after snooping was turned on; force a client to release/renew (ipconfig /release then /renew on a Packet Tracer PC, or just reboot it) if you need to see it populate for a demo/verification.
  • If the scenario's topology has an obvious "rogue server" end-device plugged into an access port, DHCP snooping + DAI is exactly the mitigation to reach for.
  • These are more advanced/less commonly graded than password/VLAN/ACL basics — apply them after the higher-value items above if time is limited.

16. Access Control Lists (ACLs)#

ACLs filter traffic by matching rules processed top-down, with an implicit deny all at the end of every ACL (even if you never type it).

Critical reminder: Every ACL — standard or extended, numbered or named — ends with an invisible deny any (or deny ip any any). If you don't include at least one permit, the ACL blocks everything. Always double-check the last visible line isn't your last intended rule if you actually wanted a broader permit.

Standard ACLs (filter by source IP only — numbers 1–99, 1300–1999)#

cisco-ios
R1(config)# access-list 10 permit 192.168.1.0 0.0.0.255
R1(config)# access-list 10 deny any log
Wildcard mask, explained
This is the part that trips almost everyone up: a wildcard mask is the INVERSE of a subnet mask. Subnet mask 255.255.255.0 (a normal /24) becomes wildcard 0.0.0.255. The rule of thumb: 0 in a wildcard octet means "this part of the address must match exactly," 255 means "this part can be anything." So 192.168.1.0 0.0.0.255 means "the first three octets (192.168.1) must match exactly, the last octet can be anything" — i.e., any host in the 192.168.1.0/24 network.
Expected result:
  • No output for either line; the ACL exists in memory but does nothing until applied to an interface or line (see below).
  • Confirm with show access-lists 10.
If it fails:
  • % Invalid input detected if the wildcard mask is malformed (must be exactly 4 octets, e.g. 0.0.0.255, not a subnet mask like 255.255.255.0 — mixing these two up is the single most common ACL mistake).
  • No traffic-blocking effect is expected yet at this point — that's normal, not a failure, since the ACL isn't applied anywhere yet.
  • Wildcard mask is the inverse of a subnet mask: 0.0.0.255 matches any host in 192.168.1.0/24 (subnet mask 255.255.255.0 → wildcard 0.0.0.255).
  • host <ip> is shorthand for a wildcard of 0.0.0.0 (match exactly one address): access-list 10 permit host 192.168.1.50.
  • any is shorthand for 0.0.0.0 255.255.255.255 (match everything).

Extended ACLs (filter by source AND destination IP, protocol, and port — numbers 100–199, 2000–2699)#

cisco-ios
R1(config)# access-list 110 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80
R1(config)# access-list 110 permit tcp any host 192.168.2.10 eq 443
R1(config)# access-list 110 deny ip any any log
Expected result:No output for any line; verify with show access-lists 110 — order of the lines as typed matters and is preserved (top-down evaluation).
If it fails:
  • % Invalid input detected if the source/destination wildcard pair is out of order — extended ACL syntax is always <protocol> <source> <source-wildcard> <destination> <destination-wildcard> [operator port]; a swapped source/destination pair is a common transcription error.
  • eq 80/eq 443 must come after the destination address, not the source — placing it in the wrong position causes it to silently apply to the wrong field (or errors out) rather than matching the intended port.

Named ACLs (easier to read/edit, supports sequence-number-based editing)#

cisco-ios
R1(config)# ip access-list standard BLOCK_GUEST
R1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
R1(config-std-nacl)# deny any
R1(config-std-nacl)# exit

R1(config)# ip access-list extended WEB_ONLY
R1(config-ext-nacl)# permit tcp any any eq 443
R1(config-ext-nacl)# deny ip any any
R1(config-ext-nacl)# exit
Expected result:
  • Prompt changes to R1(config-std-nacl)#/R1(config-ext-nacl)# while building the ACL; no other output.
  • show access-lists BLOCK_GUEST (or WEB_ONLY) shows the named ACL with auto-assigned sequence numbers (10, 20, 30...).
If it fails:
  • % Invalid input detected if you type access-list (numbered syntax) instead of ip access-list standard/extended <name> (named syntax) while already inside this mode — the two syntaxes aren't interchangeable mid-command.
  • A named ACL with the same name as an existing numbered one, or vice versa, causes a naming conflict error — pick names that don't collide with any numbered ACLs already in the config.

Applying an ACL to an interface#

Checkpoint before applying an ACL: Remember the implicit deny all at the end — applying an incomplete or backwards ACL to an interface (especially the one facing your own management traffic) can instantly cut off your own access to the device, not just the "bad" traffic you intended to block. Save the .pkt file first, apply the ACL, then immediately verify with show ip interface <id> and a real ping/SSH test before moving on.

cisco-ios
R1(config)# interface gigabitEthernet0/0
R1(config-if)# ip access-group 110 in
R1(config-if)# exit
Expected result:No output; confirm with show ip interface gigabitEthernet0/0 — should show Outgoing access list is not set / Inbound access list is 110 (or your ACL's name).
If it fails:
  • % Access-list ... does not exist if the ACL number/name was mistyped or the ACL was never actually created — create the ACL first (see above), then apply it; IOS lets you reference a nonexistent numbered ACL in ip access-group without erroring in some versions, silently doing nothing, so always verify with show ip interface rather than trusting the apply command's silence.
  • If you immediately lose your own SSH/Telnet session after this, that's the implicit-deny-all trap from the checkpoint note above — reconnect via console (if available) and fix the ACL to explicitly permit your management traffic.
  • in = filters traffic entering the router on that interface; out = filters traffic leaving.
  • Only one ACL per protocol, per direction, per interface — you can't apply two inbound IPv4 ACLs to the same interface simultaneously.

Placement rule of thumb#

Standard ACLs (source-only matching) should be placed as close to the destination as possible — because they can't distinguish destination, placing them too early can accidentally block traffic meant for other destinations. Extended ACLs (source + destination + port matching) should be placed as close to the source as possible — since they're specific enough to safely filter right at the entry point, saving bandwidth by dropping unwanted traffic before it traverses the network.

Restricting VTY access with a standard ACL#

cisco-ios
R1(config)# access-list 10 permit 192.168.1.0 0.0.0.255
R1(config)# access-list 10 deny any log
R1(config)# line vty 0 15
R1(config-line)# access-class 10 in
R1(config-line)# exit
Wildcard mask, explained
This is the part that trips almost everyone up: a wildcard mask is the INVERSE of a subnet mask. Subnet mask 255.255.255.0 (a normal /24) becomes wildcard 0.0.0.255. The rule of thumb: 0 in a wildcard octet means "this part of the address must match exactly," 255 means "this part can be anything." So 192.168.1.0 0.0.0.255 means "the first three octets (192.168.1) must match exactly, the last octet can be anything" — i.e., any host in the 192.168.1.0/24 network.
Expected result:No output; confirm with show running-config | section line vty — should show access-class 10 in under the VTY block.
If it fails:
  • This is the single easiest way to lock yourself out of remote management — if you're managing the device over Telnet/SSH from an address NOT in the permitted range, applying this immediately drops your own session on the next connection attempt (existing sessions may stay up until you disconnect).
  • Always double-check your own management workstation's subnet is included in the permit line before applying, and test from a fresh connection rather than assuming your current session proves it works.

Editing/removing ACL entries#

cisco-ios
R1# show access-lists 110
R1(config)# ip access-list extended WEB_ONLY
R1(config-ext-nacl)# no 20
R1(config-ext-nacl)# 20 permit tcp any any eq 8443
How ACL sequence-number editing works
Every line in a named/numbered ACL secretly has a sequence number (10, 20, 30...) even if you never typed one — `show access-lists` reveals them. `no 20` deletes just that one line by its number, without touching any other line or having to retype the whole ACL. Typing a number followed by a new rule (`20 permit ...`) inserts a new line at exactly that position — handy for fixing one mistake in a 10-line ACL without rebuilding it from scratch.
Expected result:show access-lists 110 lists each entry with its sequence number (10 permit tcp ..., 20 permit tcp ..., etc.); no 20 silently removes just that line, and typing 20 permit ... reinserts a new rule at that same sequence position.
If it fails:
  • % Invalid input detected on no 20 if that sequence number doesn't exist (numbers can have gaps, e.g. 10/20/30, or may not start at 10 if entries were edited before) — always run show access-lists first to get the real current sequence numbers rather than assuming round increments of 10.
  • Editing a numbered (not named) ACL this way requires entering ip access-list extended <number> mode, not plain access-list <number> ... global config, or sequence-number editing isn't available.
  • Named/numbered ACLs edited via ip access-list ... mode support sequence numbers — use show access-lists to see them, then no <seq#> to delete just that line without retyping the whole ACL.

Things to try / extra points#

  • Always add an explicit final deny ... log line even though it's implicit — the log keyword gives you visibility (via show logging) into what's being blocked, which is useful for verifying the ACL actually works as intended.

  • After writing any ACL, immediately test intended traffic (e.g., ping from an allowed and a denied source in the topology) rather than assuming syntax alone is correct.

  • Common exam trap: an ACL is written correctly but never applied to an interface (or applied to the wrong interface/direction) — always confirm with show ip interface <id> (look for "Outgoing/Incoming access list") in addition to show access-lists.

  • Remember wildcard mask math: to match a /26 subnet (255.255.255.192), the wildcard is 0.0.0.63; for a single host, wildcard is 0.0.0.0 or just use the host keyword.

  • If asked to block a specific protocol/service (e.g., "block Telnet to the router from outside"), use an extended ACL with eq 23 and apply it inbound on the appropriate interface, or use access-class on the VTY lines for a simpler equivalent when the goal is just "restrict management access."

  • Verify overall ACL behavior: show access-lists, show ip interface <id> (to confirm application + direction), and show running-config | section access-list.

  • CIS Benchmark alignment: filtering traffic with ACLs at the network edge is the central idea behind the CIS Data Plane "Border Router Filtering" / anti-spoofing guidance (Level 1) — the implicit-deny reminder and inbound/outbound placement rule above are exactly the mechanics CIS assumes you understand.

  • CIS Level 1 anti-spoofing ACL practice worth adding on any interface facing an untrusted/outside network: explicitly deny inbound traffic sourced from private (RFC 1918) address ranges, loopback (127.0.0.0/8), and the device's own address block if that traffic shouldn't legitimately originate from "outside" — this catches spoofed source addresses trying to impersonate internal hosts.

    cisco-ios
    R1(config)# ip access-list extended ANTI_SPOOF_IN
R1(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any
R1(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any
R1(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any
R1(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any
R1(config-ext-nacl)# permit ip any any
    Expected result:No output while building the ACL; verify with show access-lists ANTI_SPOOF_IN that the deny lines precede the permit (order matters — top-down evaluation).
    If it fails:
    • No error mode for correctly-formed lines.
    • If legitimate internal traffic starts getting blocked after applying this on the WRONG interface (e.g., an internal-facing one instead of the true external/untrusted-facing one), that's a placement mistake, not a syntax one — this ACL should only ever go on the interface facing outside your own network, never on an internal link where 10.x/172.16.x/192.168.x traffic is expected and legitimate.

    Adapt the "permit" line to your actual intended traffic — don't just leave a blanket permit ip any any in a real ACL; it's shown here only to illustrate the anti-spoofing deny pattern.

  • A more advanced CIS Data Plane technique, flag as possibly unsupported in Packet Tracer and generally Level 2/advanced: Unicast Reverse Path Forwarding (ip verify unicast source reachable-via rx), which automatically drops packets whose source address doesn't have a matching route back out the interface they arrived on — a dynamic alternative/complement to manually-written anti-spoofing ACLs.

17. Routing Basics & Routing Protocol Hardening#

Static routing#

cisco-ios
R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.2
R1(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.1
Expected result:No output; verify with show ip route — the routes appear with an S (static) or S* (candidate default route) prefix.
If it fails:The route silently doesn't appear in show ip route if the next-hop IP (10.0.0.2/10.0.0.1) isn't reachable via a directly connected/up interface — IOS accepts the command syntax either way, but an unreachable next hop means the route stays inactive; confirm the next-hop address is actually on a connected subnet with show ip interface brief first.

IPv6 static routing#

cisco-ios
R1(config)# ipv6 route ::/0 2001:db8::1
R1(config)# ipv6 route 2001:db8:2::/64 2001:db8::2
Expected result:No output; verify with show ipv6 route.
If it fails:% IPv6 routing not enabled if ipv6 unicast-routing hasn't been set globally yet (needed before IPv6 routes/routing protocols work at all) — run R1(config)# ipv6 unicast-routing first, then retry.

OSPF#

cisco-ios
R1(config)# router ospf 1
R1(config-router)# network 192.168.1.0 0.0.0.255 area 0
R1(config-router)# default-information originate
R1(config-router)# passive-interface default
R1(config-router)# no passive-interface gigabitEthernet0/0
R1(config-router)# exit
Expected result:
  • No output; after a few seconds, unsolicited %OSPF-5-ADJCHG: Process 1, Nbr <ip> ...
  • Loading -> Full messages appear on the console once OSPF forms an adjacency with a neighbor.
  • Confirm with show ip ospf neighbor.
If it fails:
  • No neighbor ever forms (show ip ospf neighbor stays empty) — most common causes: the network statement's wildcard mask/area doesn't actually cover the interface's IP, mismatched area numbers between neighbors, or MTU/hello-timer mismatches.
  • Also double-check passive-interface default didn't accidentally leave the interface facing your actual OSPF neighbor passive — the no passive-interface line must name every interface that legitimately needs to exchange OSPF hellos, not just the one in this example.

OSPF MD5 authentication (protects routing updates from spoofed neighbors)#

cisco-ios
R1(config)# interface gigabitEthernet0/0
R1(config-if)# ip ospf message-digest-key 1 md5 OspfSecretKey123
R1(config-if)# ip ospf authentication message-digest
R1(config-if)# exit
R1(config)# router ospf 1
R1(config-router)# area 0 authentication message-digest
R1(config-router)# exit
What OSPF MD5 authentication protects against
By default, any device that speaks OSPF on a shared network segment can inject fake routing updates — including a rogue router an attacker plugs in. MD5 authentication makes routers require a shared secret (the key set here) before trusting each other's routing updates, similar to a password between routers. Both sides of a link must have the exact same key number and key string, or they'll refuse to become neighbors at all.
Expected result:
  • No output; existing adjacencies briefly drop and reform once authentication is enabled on both this router and its neighbor.
  • show ip ospf interface gigabitEthernet0/0 should show Message digest authentication enabled.
If it fails:
  • The neighbor router must have the identical key number and MD5 key string configured, or the adjacency drops entirely (%OSPF-5-ADJCHG: ...
  • Full -> Down) — this is the single most common OSPF-auth mistake: enabling auth on one side only, or typo'ing the key string differently on each router.
  • Apply the matching config to both ends within the same maintenance window/checkpoint save so you're not left with a broken adjacency mid-round.

RIP#

cisco-ios
R1(config)# router rip
R1(config-router)# version 2
R1(config-router)# network 192.168.1.0
R1(config-router)# no auto-summary
R1(config-router)# passive-interface default
R1(config-router)# no passive-interface gigabitEthernet0/0
R1(config-router)# exit
Expected result:No output; verify with show ip protocols — should show Routing Protocol is "rip", sending/receiving version 2, and the configured networks.
If it fails:network 192.168.1.0 must be the classful network address (no mask/wildcard argument in RIP, unlike OSPF) — if the interface's actual subnet doesn't match a classful boundary, RIP may not advertise it correctly; no auto-summary is what allows RIPv2 to carry subnet-specific routes instead of collapsing to classful boundaries, so leaving it out is a common cause of routes not appearing as expected on a subnetted topology.

Things to try / extra points#

  • passive-interface default + selectively re-enabling only the interfaces that need to actively exchange routing updates is one of the highest-value routing hardening moves — it stops routing advertisements from leaking out onto end-user access switchports, where they serve no purpose and can leak network topology or accept spoofed updates.
  • Enable OSPF MD5 authentication whenever a routing protocol is present in the scenario and neighbor authentication is asked for or implied — unauthenticated OSPF/EIGRP/RIP updates can be spoofed by a rogue router on the segment.
  • Use no router rip / remove an OSPF process entirely (no router ospf 1) if the topology doesn't actually need dynamic routing and a static route would suffice — fewer running services/protocols is generally safer, though only do this if it doesn't break required connectivity.
  • Verify: show ip route, show ip protocols, show ip ospf neighbor, show ip ospf interface.
  • CIS Benchmark alignment: passive-interface default and routing-protocol neighbor authentication (OSPF MD5, or equivalent for EIGRP/RIP/BGP) are CIS Control Plane guidance and are generally rated Level 2 rather than Level 1 — appropriate, since they only apply when a routing protocol is actually configured, and CyberPatriot Cisco scenarios don't always include one.
  • Worth trying if the topology has routing configured and time allows: Control Plane Policing (CoPP) — rate-limits/filters traffic destined to the router's own control plane (e.g., excessive SSH connection attempts, routing protocol floods) using a class-map/policy-map/service-policy applied to the control-plane interface. This is a Level 2, more advanced Control Plane item; flag it as likely unsupported or only partially supported in Packet Tracer's IOS emulation — verify with ? under control-plane config mode before investing significant time in it.

18. DHCP Server Configuration#

cisco-ios
R1(config)# service dhcp
R1(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.10
R1(config)# ip dhcp pool LAN_POOL
R1(dhcp-config)# network 192.168.1.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.1.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# domain-name cyberpatriot.local
R1(dhcp-config)# exit
Expected result:
  • No output; prompt shifts to R1(dhcp-config)# while inside the pool.
  • Confirm with show ip dhcp pool LAN_POOL and, once a client requests an address, show ip dhcp binding.
If it fails:
  • A client gets no address at all (ipconfig shows 169.254.x.x / APIPA in Packet Tracer) — check service dhcp is present (it's on by default on most IOS versions but can be disabled), and confirm the client's connected interface is actually up and in the same subnet/VLAN as the pool's network statement.
  • If a client gets an address that conflicts with the router's own IP (192.168.1.1), the ip dhcp excluded-address range didn't cover it — always run excluded-address BEFORE creating the pool, or exclusions configured after clients have already leased conflicting addresses won't retroactively fix existing leases.

Things to try / extra points#

  • Double check exclusions cover every statically-addressed device on the subnet (gateway, servers, printers, switch SVI), not just the router itself — a common planted bug is a missing/incomplete exclusion range causing an address conflict.
  • Verify default-router and dns-server values exactly match the topology's actual gateway/DNS IPs — a single wrong octet is a common, easy-to-miss deduction on both router-based DHCP pools and Packet Tracer Server DHCP service configuration (see Section 26).
  • Confirm the pool's network statement subnet mask matches the actual subnet in use (e.g., a /26 network needs 255.255.255.192, not a default /24).
  • Verify: show ip dhcp binding, show ip dhcp pool (or show ip dhcp server statistics), show ip dhcp conflict.

19. NAT / PAT Configuration#

Static NAT#

cisco-ios
R1(config)# ip nat inside source static 192.168.1.10 203.0.113.10
R1(config)# interface gigabitEthernet0/0
R1(config-if)# ip nat inside
R1(config-if)# exit
R1(config)# interface gigabitEthernet0/1
R1(config-if)# ip nat outside
R1(config-if)# exit
Expected result:No output; confirm with show ip nat translations — a permanent static entry for 192.168.1.10 <-> 203.0.113.10 should appear immediately (static entries don't need traffic to show up, unlike dynamic ones).
If it fails:Translation never happens (nothing in show ip nat translations even after generating traffic, or connectivity from outside to the inside host fails) — the near-universal cause is one interface missing its ip nat inside/ip nat outside designation; NAT is a no-op without both being set on the correct interfaces (see the common-mistake tip below).

Dynamic NAT#

cisco-ios
R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255
R1(config)# ip nat pool PUBLIC_POOL 203.0.113.10 203.0.113.20 netmask 255.255.255.0
R1(config)# ip nat inside source list 1 pool PUBLIC_POOL
Expected result:No output; translations only appear in show ip nat translations once matching traffic actually flows (unlike static NAT, dynamic entries are created on demand, not immediately).
If it fails:
  • %NAT-3-ADDRFLTR or translations failing once the pool's address range is exhausted (more inside hosts sending traffic than pool addresses available) — either enlarge the pool range or switch to PAT/overload, which doesn't have this 1-to-1 address limitation.
  • Don't forget ip nat inside/ip nat outside still need to be applied on interfaces exactly as in the static example — this block alone doesn't include them.

PAT (overload) — most common in small topologies#

cisco-ios
R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255
R1(config)# ip nat inside source list 1 interface gigabitEthernet0/1 overload
R1(config)# interface gigabitEthernet0/0
R1(config-if)# ip nat inside
R1(config-if)# exit
R1(config)# interface gigabitEthernet0/1
R1(config-if)# ip nat outside
R1(config-if)# exit
What "overload" means here
Regular NAT is one-to-one: one internal address maps to one external address. "overload" is what turns this into PAT (Port Address Translation) — the technique your home router actually uses — where MANY internal devices share ONE external IP address at the same time, kept separate from each other by using a different port number for each connection. Without "overload," you'd need one public IP per internal device, which usually isn't available.
Expected result:No output; once an inside host sends traffic outward, show ip nat translations shows multiple inside hosts sharing the single outside interface IP, differentiated by port number (the "overload" behavior — this is standard home-router-style PAT).
If it fails:
  • No translations appear if gigabitEthernet0/1 (the interface named after overload) doesn't itself have a valid IP address — PAT overload borrows that interface's own address as the shared public IP, so it must be configured and up first.
  • If it still fails, re-check both ip nat inside/outside designations exactly as with static/dynamic NAT above — that's the most common root cause across all three NAT flavors.

Things to try / extra points#

  • The single most common NAT mistake: forgetting to mark both ip nat inside on the internal-facing interface AND ip nat outside on the external-facing interface — NAT silently does nothing without both.
  • Verify active translations and hit counts: show ip nat translations (add verbose for detail) and show ip nat statistics.
  • Clear stale translations for a clean test: clear ip nat translation *.
  • NAT/PAT is less commonly the security focus of this module vs. connectivity — treat it as a "make the topology work as designed" task rather than a hardening task, unless a question specifically frames it as a security control (e.g., hiding internal addressing).

20. NTP, Logging & Syslog#

cisco-ios
R1(config)# ntp server 192.168.1.254
R1(config)# clock timezone EST -5
R1(config)# service timestamps log datetime msec
R1(config)# service sequence-numbers
R1(config)# logging host 192.168.1.100
R1(config)# logging trap warnings
R1(config)# logging buffered 16384
R1(config)# logging console
Expected result:No output for any line; NTP sync isn't instant — show ntp status may show Clock is unsynchronized for the first minute or so before settling to synchronized.
If it fails:
  • If show ntp status never reaches synchronized, the NTP server IP may be unreachable (ping 192.168.1.254 from the router to confirm) or the target device in the topology isn't actually configured as an NTP server (ntp master on that device) — Packet Tracer's NTP emulation is also known to be slower/flakier than real IOS, so give it a couple of minutes before concluding it's broken.
  • logging console can flood the terminal with messages during heavy troubleshooting — if console output becomes unreadable mid-session, no logging console temporarily (logs are still captured elsewhere via logging buffered/logging host).

Things to try / extra points#

  • Configure ntp server pointing at whatever authoritative time source the topology provides (often another router or a dedicated NTP server device) — verify sync status with:
    cisco-ios
    R1# show ntp status
R1# show ntp associations
    Expected result: show ntp status reports Clock is synchronized, stratum <n> once sync completes; show ntp associations lists the configured server with a * (or sys.peer) marker next to the currently-selected reference. If it fails: See troubleshooting note above — give it time before assuming failure, and confirm the NTP source device/IP is actually reachable and correctly configured as a time source.
  • Configure centralized logging to a syslog server if one exists in the topology (logging host <ip>) — losing local-only logs on a device reload is a common oversight.
  • Set logging trap warnings or a level appropriate to the scenario — too verbose floods the log server, too restrictive misses security-relevant events.
  • Verify with show logging (shows current buffer + config summary) after configuring.
  • CIS Benchmark alignment: centralized syslog (logging host), timestamped logs (service timestamps log datetime), and synchronized time (ntp server) map to the CIS Control Plane "Logging Rules" and "NTP Rules" categories (Level 1) — logging without accurate timestamps is treated by CIS as only marginally useful for incident response, which is why both go together.
  • Additional CIS Level 1 logging nuance: restrict logging console to a specific severity (e.g., logging console critical) rather than leaving it at its default/unbounded verbosity — an unrestricted console logging level can flood and effectively lock up a busy console session during high log volume, which is itself treated as a minor availability risk by CIS.
  • NTP authentication (ntp authenticate, ntp authentication-key <n> md5 <key>, ntp trusted-key <n>) is a CIS NTP-hardening item that prevents a rogue device from feeding the router falsified time — flag as Level 2/advanced and worth trying only if the topology's NTP server device supports authentication and time allows, since plain ntp server <ip> is usually sufficient for competition purposes.

21. CDP and LLDP#

CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol) both broadcast detailed device information (hostname, IOS version, IP address, model, connected port) to directly connected neighbors — useful for troubleshooting, but a significant information-leakage risk on any port facing an untrusted network or end users.

cisco-ios
R1(config)# no cdp run
R1(config)# no lldp run
Expected result:No output; show cdp neighbors / show lldp neighbors afterward should return % CDP is not enabled / an equivalent LLDP-disabled message instead of a neighbor table.
If it fails:% Invalid input detected on no lldp run on older IOS images that don't support LLDP at all (LLDP is a newer, less universally emulated protocol in Packet Tracer than CDP) — if rejected, note it as unsupported on that device and move on; CDP disabling alone still covers the more commonly-tested case.

Per-interface (if CDP/LLDP is still needed elsewhere in the topology, e.g., between trusted switches, but must be disabled on untrusted/user-facing ports):

cisco-ios
R1(config)# interface fastEthernet0/1
R1(config-if)# no cdp enable
R1(config-if)# no lldp transmit
R1(config-if)# no lldp receive
R1(config-if)# exit
Expected result:No output; that specific interface drops out of neighboring devices' CDP/LLDP neighbor tables (verify from the neighboring device, not just this one, since CDP/LLDP is inherently about what OTHER devices see).
If it fails:No error mode for correctly-typed commands; if the neighbor still appears in a peer's show cdp neighbors after this, confirm you disabled it on the correct interface — CDP/LLDP is per-interface, and disabling it on the wrong port (e.g., the trunk instead of the access port) leaves the actual leaky port untouched.

Things to try / extra points#

  • Default posture: disable CDP globally (no cdp run) unless the scenario explicitly requires it for a specific reason (e.g., a question asks you to identify a neighbor using show cdp neighbors first — do that before disabling it!).
  • If CDP is needed only between trusted infrastructure devices (e.g., switch-to-switch uplinks) but the topology has user-facing access ports, disable it selectively per-interface (no cdp enable) on the access ports instead of killing it globally.
  • Verify: show cdp neighbors, show cdp neighbors detail, show cdp interface, show lldp neighbors, show lldp neighbors detail.
  • Remember: if a question asks you to identify or document a neighboring device, do that reconnaissance step first with show cdp neighbors detail — then disable CDP afterward as a hardening step, not before.
  • CIS Benchmark alignment: no cdp run (and disabling LLDP where unneeded) is a standard CIS Control Plane "Global Service Rules" item (Level 1), grouped with the other unnecessary-service disables in Section 10 — CDP/LLDP information leakage is treated the same way as the other legacy/leaky services there.

22. Saving, Backing Up & Restoring Configurations#

cisco-ios
R1# copy running-config startup-config
R1# wr mem
Expected result:Destination filename [startup-config]? — press Enter to accept the default, then Building configuration... followed by [OK].
If it fails:
  • No real failure mode on a functioning device beyond running out of NVRAM space (extremely rare in Packet Tracer).
  • If you're prompted for a filename and just hit Enter without reading it, double-check you didn't accidentally type over the default — a mistyped destination filename saves to the wrong place and your real startup-config stays unsaved/stale.

Both commands accomplish the same thing — wr mem is the classic shorthand for copy running-config startup-config. Always save after every meaningful change block, not just once at the very end.

Backup/restore via TFTP:

cisco-ios
R1# copy running-config tftp
R1# copy startup-config tftp
R1# copy tftp running-config
R1# copy tftp startup-config
Expected result:IOS prompts for the TFTP server's IP address and a destination/source filename, then shows a string of ! characters as the transfer progresses, ending in [OK - <bytes> bytes].
If it fails:
  • The transfer hangs or times out (%Error opening tftp://...) if the TFTP server device/IP in the topology isn't actually reachable or isn't running a TFTP server service — ping the TFTP server IP from the router first to confirm basic connectivity before troubleshooting the copy command itself.
  • copy tftp running-config merges into the existing running config rather than replacing it — if you actually want a clean replacement, copy to startup-config instead and reload.

Backup/restore via USB flash:

cisco-ios
R1# show file systems
R1# copy running-config usbflash0:/
R1# dir usbflash0:/
R1# copy usbflash0:/backup-config running-config
Expected result:show file systems lists all available filesystems including usbflash0: if a USB device is attached in the topology; copy/dir behave like the TFTP equivalents.
If it fails:usbflash0: doesn't appear in show file systems at all if no USB storage device is attached to that router in the Packet Tracer topology, or the specific router model doesn't have a USB port emulated — not every Packet Tracer router model supports this; check the device's physical/module view before assuming the command itself is broken.

Discard unsaved changes / revert to last saved config:

cisco-ios
R1# reload

(reload discards the running config and reboots into the saved startup-config — make sure you actually want to lose unsaved changes before doing this.)

Expected result:
  • System configuration has been modified.
  • Save? [yes/no]: if there are unsaved changes — answering no discards them and proceeds to reboot; yes saves first (equivalent to copy run start then reload).
  • Reboot takes anywhere from several seconds to a couple minutes in Packet Tracer.
If it fails:If you meant to keep your changes and accidentally answered no at the save prompt, there's no undo once the reload proceeds — always read that prompt carefully rather than reflexively hitting Enter/typing an answer.

Erase startup config (factory-reset style):

cisco-ios
R1# erase startup-config
R1# reload
Expected result:
  • erase startup-config prompts Erasing the nvram filesystem will remove all configuration files! Continue? [confirm] — pressing Enter confirms; then [OK].
  • The subsequent reload boots the device with no configuration at all (default hostname, no passwords, everything reset).
If it fails:
  • No error mode beyond the confirmation prompt itself.
  • This is a genuinely destructive, hard-to-reverse action within a round — only run this if you specifically intend to factory-reset the device (e.g., a scenario explicitly asks for it, or you're deliberately starting a device over); it destroys all the hardening work described in every other section of this document on that device, requiring you to redo it all from scratch.

Things to try / extra points#

  • Save constantly. copy run start after finishing each major section (passwords, then SSH, then VLANs, then ACLs, etc.) rather than only once at the very end — if Packet Tracer crashes or the round has a time limit that cuts you off mid-task, unsaved work in the running config may not count.
  • Be aware some CyberPatriot Cisco scoring/checking may inspect either the running config or the startup config depending on how the exercise is set up — when in doubt, save every time, since a saved config satisfies both.
  • Before doing anything destructive (reload, erase startup-config), pause and confirm you don't have unsaved good work — these commands are unforgiving.
  • If instructed to back up a "known good" config before making risky changes, copy running-config tftp (or to USB) gives you a rollback point.

23. Verification: show Commands Reference#

Use these liberally after every major change — verifying is just as important as configuring correctly.

Note on this section: This is a pure command-lookup reference, not new configuration — each show command was already given its own Expected result/If it fails pairing inline at the point it was first introduced earlier in this document (Sections 2-22). As a general rule across all of them: no output / an empty table is often a valid "nothing configured yet" result, not an error; % Invalid input detected or % Ambiguous command means either a typo or that the specific command isn't supported on this device's IOS image (common in Packet Tracer's more limited router/switch models) — try ? at each keyword boundary to confirm the exact supported syntax on that device before assuming something is broken.

Configuration#

shell
show running-config              (show run)
show running-config | section <keyword>
show running-config interface <id>
show startup-config

General / system#

shell
show clock
show clock detail
show version
show boot
show mac address-table
show flash
show history
show protocols
show arp

IP / routing#

shell
show ip interface brief          (show ip int brief)
show ip interface
show ip route
show ip route static
show ip protocols
show ip arp
show ipv6 interface brief
show ipv6 route

Interfaces / switching#

shell
show interfaces
show interface <id>
show interfaces <id> switchport
show interfaces <id> trunk
show interfaces status

VLANs#

shell
show vlan brief
show vlan
show vlan summary
show vlan name <name>

Port security#

shell
show port-security
show port-security interface <id>
show port-security address

Access lists#

shell
show access-lists
show access-lists <name-or-number>
show ip interface <id>              (check for applied ACL + direction)

SSH#

shell
show ip ssh
show ssh

DHCP#

shell
show ip dhcp binding
show ip dhcp server statistics
show ip dhcp conflict
show ip dhcp pool

CDP / LLDP#

shell
show cdp neighbors
show cdp neighbors detail
show cdp interface
show lldp neighbors
show lldp neighbors detail

NTP / Logging#

shell
show ntp status
show ntp associations
show logging

NAT#

shell
show ip nat translations
show ip nat statistics

Things to try / extra points#

  • Make show running-config (or targeted | section filters) your default "did that actually work?" check after every single command block — typos in IOS commands frequently fail silently or apply to the wrong scope.
  • show ip interface brief is the fastest single command to sanity-check the whole device's interface/IP state (up/down, IP assigned or not) — run it early and often.
  • Use the pipe filter (| include, | exclude, | begin, | section) to avoid scrolling through a huge show running-config when hunting for one setting, e.g.:
    cisco-ios
    R1# show running-config | section line vty
R1# show running-config | include banner

24. Debugging & Clear Commands#

shell
debug ?                       (list available debug options)
debug ip packet <acl-number>
debug ip dhcp server events
debug ipv6 dhcp detail
debug ip nat
debug ip nat detailed
no debug <feature>            (turn off one specific debug)
undebug all                   (turn off all debugging at once)
Expected result:Live, continuously-scrolling console output as matching events occur (e.g., debug ip nat prints a line for every translated packet) — this keeps printing until you turn it off, unlike a show command's one-time snapshot.
If it fails:
  • The single most common debug mistake: forgetting to turn it off (undebug all) before moving on — a forgotten debug session left running can flood the console with output for the rest of the round, burying legitimate messages and making the terminal unusable.
  • If the console becomes unresponsive/spammed, undebug all (or u all shorthand) immediately silences it.
  • In Packet Tracer specifically, heavy debug output on a slower host machine can also visibly slow down the simulation — turn debugging off as soon as you've confirmed what you needed to see.
shell
clear ip nat statistics
clear ip nat translation *
clear access-list counters
Expected result:No output; counters/tables reset to zero/empty immediately, useful for getting a clean baseline before re-testing.
If it fails:No error mode; clearing NAT translations mid-session will briefly interrupt any in-progress NAT'd connections (they re-establish on next packet) — expected side effect, not a bug, if you clear translations while actively testing connectivity through the device.

Tip: debug commands generate live, real-time output and can be resource-intensive — use narrowly (specific feature, not debug all) and turn off (undebug all) when done. In a graded competition environment this is rarely the point of a task but can help you verify traffic is actually being filtered/NATed as intended during your own testing.

25. Password Recovery Process#

If a device becomes completely locked out (e.g., a bad AAA config or forgotten enable secret during your own testing):

  1. Physically power-cycle the device and send a break sequence during the boot process to enter ROMMON mode.
  2. Change the configuration register to 0x2142 — this tells the device to ignore/skip loading the startup-config on the next boot.
    cisco-ios
    rommon 1 > confreg 0x2142
rommon 2 > reset
    What the config register actually controls
    The configuration register is a tiny 16-bit setting stored in the router's hardware that controls boot behavior — think of it like a BIOS setting. The default, 0x2102, means "boot normally and load the saved config." 0x2142 means "boot but skip loading the saved config," which is exactly what you want during password recovery — it lets you in without needing the password, because the config with that password never loads. You must always set it back to 0x2102 afterward or the router will keep ignoring its saved config on every future boot.
    Expected result: reset reboots the device; it comes back up skipping the startup-config load, dropping you into initial setup dialog or a blank Router> prompt with no passwords set. If it fails: If the device still loads the old config (and you're still locked out), the break sequence may not have actually been received in time, or the wrong config-register value was set — confirm you're genuinely in rommon > mode (not still at a regular IOS prompt) before typing confreg; the ROMMON prompt looks visually distinct from the normal Router>/Router# prompts.
  3. Device boots with a blank running-config (but startup-config is still intact in NVRAM). Copy it in manually:
    cisco-ios
    Router> enable
Router# copy startup-config running-config
    Expected result: The old startup-config loads into the running-config, restoring the device's original hostname/interfaces/VLANs/etc. — but crucially, the running-config now has passwords intact, and since you booted skipping config load, you have unauthenticated enable access to change them. If it fails: If enable itself still prompts for a password after the reset, the config register change didn't actually take (still loading startup-config normally) — go back to ROMMON and re-verify confreg 0x2142 was actually applied (show version at the end of boot reports the current register value in its last lines).
  4. Make your password changes, then set the config register back to the default 0x2102 so the device boots normally (loading startup-config) going forward:
    cisco-ios
    Router(config)# config-register 0x2102
    Expected result: No output; the new register value takes effect on the next reload, not immediately (this is why you still need to save and reload as a separate final step). If it fails: No error mode for this command itself; the real risk is forgetting this step entirely (see the tip below) — if you've already reloaded and the device boots ignoring its config again, go back through ROMMON once more and set 0x2102 before reloading again.
  5. Save and reload:
    cisco-ios
    Router# copy running-config startup-config
Router# reload
    Expected result: Standard save confirmation ([OK]) followed by a normal reboot; the device comes back up loading its config as usual, with your new passwords active. If it fails: If the device comes back up unconfigured again after this final reload, step 4 (config-register 0x2102) was likely skipped or didn't take — verify the register value with show version (last few lines report Configuration register is 0x...) before reloading, not after.

Things to try / extra points#

  • Don't forget step 4 — leaving the config register at 0x2142 means the device will ignore its saved config on every future boot, which will look like a bizarre unrelated failure if missed.
  • Password recovery in Packet Tracer specifically may require unplugging/replugging the console cable while holding a "Mode"/reset button on the simulated device chassis rather than a literal keyboard break sequence — behavior can differ slightly by device model in the Packet Tracer library, so check the specific device's documentation/behavior if the standard break sequence doesn't seem to trigger ROMMON.

26. Packet Tracer Non-CLI / GUI Device Audits#

Not everything in this module is CLI-based — end devices and "Server" objects are configured through Packet Tracer's GUI tabs. These are easy to forget since they don't show up in show running-config.

Server object → Services tab#

  • FTP: Remove default/weak accounts (e.g., cisco/cisco, admin/admin); create dedicated accounts with least-privilege read/write permissions.
  • AAA (RADIUS/TACACS+): If active, audit the user database table and delete unauthorized or default testing credentials.
  • DHCP: Verify the Default Gateway and DNS Server fields inside the pool are the correct IPs for the topology — a single wrong octet here is a classic, easy-to-miss deduction. Confirm the Start IP Address range doesn't overlap any statically-assigned device.
  • DNS: Verify A-records correctly map hostnames to the intended IPs; delete any unauthorized/rogue entries.

End devices (PCs/Laptops) → Desktop tab → IP Configuration#

  • Confirm whether each device is supposed to be Static or DHCP per the scenario instructions, and correct it if wrong.
  • Verify the subnet mask length matches the actual subnet design (e.g., a /26 device incorrectly configured with a default /24 255.255.255.0 mask is a common planted error).

Wireless Router / Home Router GUI (e.g., Linksys-style device)#

  • Administration → Management: Change the router's admin password away from the default (admin). Disable remote management, or restrict it to HTTPS only.
  • Wireless → Wireless Security: Change security mode from Disabled/WEP to WPA2 Personal (or WPA2/WPA3 if offered); set encryption to AES; assign a strong pre-shared key.
  • Wireless → Basic Wireless Settings: Change the default SSID (e.g., away from Default/Linksys); disable SSID broadcast only if the scenario specifically instructs it (hiding SSID is weak security theater but sometimes explicitly requested).

Things to try / extra points#

  • Treat every Server and end device icon in the topology as a checklist item just like a router/switch — it's easy to tunnel-vision on CLI devices and skip these GUI-based ones entirely.
  • Scoring engines/graders frequently penalize a single incorrect octet in GUI fields (DHCP gateway/DNS, static IP configs) — triple check every IP field you can see against the intended addressing scheme, not just the CLI-configured ones.
  • Default credentials (cisco/cisco, admin/admin, blank passwords) on any GUI-configurable service are a near-guaranteed planted vulnerability — actively hunt for them on every Server/GUI device.

27. Packet Tracer Gotchas vs. Real Cisco IOS#

Packet Tracer emulates a subset of real Cisco IOS behavior — don't assume every real-world command or edge case behaves identically.

Things to try / extra points#

  • If any command from this checklist is rejected with % Invalid input or % Incomplete command and you're confident the syntax is correct for real IOS, try: (1) checking the device model/IOS feature set, (2) using ? to see what IS supported on that device, (3) looking for an alternate/older syntax form.
  • Always verify a "successful" security command actually took effect via the relevant show command — Packet Tracer occasionally accepts a command without fully implementing its real-world effect.
  • When time allows, test end-to-end behavior (e.g., actually try to ping/telnet/ssh from a denied source) rather than trusting that correct-looking config syntax guarantees correct behavior in the simulator.

28. Full Worked Example: Router/Switch Hardening From Scratch#

A complete, ordered example touching most of the high-value items above — a good "starting template" to adapt per device. Broken into numbered steps with a one-line purpose for each chunk, rather than one giant terminal dump, so you can follow it (or jump to just the step you need) under time pressure.

Note on this section: Every command block below is a replay of commands already given detailed Expected result/If it fails annotations at their original point of introduction (Sections 4-16) — follow the linked section for that step if something doesn't behave as expected here. As a general rule for working through this template top-to-bottom: run show running-config (or show run | section <keyword>) after each numbered step before moving to the next, rather than typing all steps blind and debugging at the end — an error in an early step (e.g., a typo in Step 1's hostname) can cause a later step (Step 4's crypto key generate rsa) to fail in a way that's confusing if you don't know which step actually broke.

Router hardening, step by step#

Step 1 — Get into config mode and set identity.

cisco-ios
Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# ip domain-name cyberpatriot.local
R1(config)# no ip domain-lookup

Sets the device's name and domain (required before SSH key generation later) and stops the CLI from hanging on mistyped commands.

Step 2 — Lock down privileged EXEC and passwords.

cisco-ios
R1(config)# enable secret Str0ngP@ss!
R1(config)# no enable password
R1(config)# service password-encryption
R1(config)# security passwords min-length 10

Requires a hashed password to reach privileged EXEC, removes any legacy plaintext enable password, and encrypts/enforces length on passwords stored in the config.

Step 3 — Set the legal warning banner.

cisco-ios
R1(config)# banner motd #AUTHORIZED ACCESS ONLY. ALL ACTIVITY IS MONITORED AND LOGGED.#

Displays a neutral legal notice to anyone connecting, before login.

Step 4 — Create a local admin account and set up SSH.

cisco-ios
R1(config)# username admin privilege 15 secret Str0ngP@ss!
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 3
R1(config)# login block-for 120 attempts 3 within 60
What this command is actually doing
This generates the public/private key pair the router will use to encrypt SSH sessions — without it, SSH can't work at all (there's nothing to encrypt with). "modulus 2048" sets the key size in bits — bigger is more secure but takes longer to generate; 2048 is the modern standard. This step needs a hostname and domain name already set, because the key's internal name is built from hostname.domain-name.

Creates the account SSH logins will use, generates the RSA keypair SSH needs (hostname/domain from Step 1 must already be set), forces SSHv2, and adds brute-force lockout protection.

Step 5 — Secure console, VTY, and AUX lines.

cisco-ios
R1(config)# line console 0
R1(config-line)# password ConsoleP@ss
R1(config-line)# login local
R1(config-line)# exec-timeout 5 0
R1(config-line)# logging synchronous
R1(config-line)# exit
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 5 0
R1(config-line)# logging synchronous
R1(config-line)# exit
R1(config)# line aux 0
R1(config-line)# no exec
R1(config-line)# transport input none
R1(config-line)# exit

Requires local-database login on console and the full VTY range (0-15, not just 0-4), restricts VTY to SSH-only, sets idle timeouts, and disables the AUX port entirely.

Step 6 — Disable unnecessary global services.

cisco-ios
R1(config)# no ip http server
R1(config)# no ip http secure-server
R1(config)# no ip source-route
R1(config)# no ip bootp server
R1(config)# no service config
R1(config)# no service finger
R1(config)# no service tcp-small-servers
R1(config)# no service udp-small-servers
R1(config)# no cdp run

Standard "reduce attack surface" sweep — see Section 10 for what each line does.

Step 7 — Harden the routed interface(s).

cisco-ios
R1(config)# interface gigabitEthernet0/0
R1(config-if)# description LINK_TO_LAN
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no ip redirects
R1(config-if)# no ip unreachables
R1(config-if)# no ip proxy-arp
R1(config-if)# no shutdown
R1(config-if)# exit

Sets the interface's IP/mask (double-check these against the topology!) and disables ICMP redirects/unreachables/proxy-ARP that can leak information. Repeat this step for every routed interface on the device.

Step 8 — Save.

cisco-ios
R1# copy running-config startup-config

Do this now, not just at the very end — see the checkpoints in Section 2 and throughout this doc.

Switch hardening, step by step#

Step 1 — Identity, passwords, and banner.

cisco-ios
Switch> enable
Switch# configure terminal
Switch(config)# hostname SW1
SW1(config)# enable secret Str0ngP@ss!
SW1(config)# service password-encryption
SW1(config)# banner motd #AUTHORIZED ACCESS ONLY. ALL ACTIVITY IS MONITORED AND LOGGED.#

Same baseline identity/password/banner hardening as the router.

Step 2 — Disable unnecessary services and create the admin account.

cisco-ios
SW1(config)# no ip http server
SW1(config)# no cdp run
SW1(config)# username admin privilege 15 secret Str0ngP@ss!

Step 3 — Secure lines and set up SSH.

cisco-ios
SW1(config)# line console 0
SW1(config-line)# login local
SW1(config-line)# exec-timeout 5 0
SW1(config-line)# exit
SW1(config)# line vty 0 15
SW1(config-line)# login local
SW1(config-line)# transport input ssh
SW1(config-line)# exec-timeout 5 0
SW1(config-line)# exit
SW1(config)# ip domain-name cyberpatriot.local
SW1(config)# crypto key generate rsa modulus 2048
SW1(config)# ip ssh version 2
What this command is actually doing
This generates the public/private key pair the router will use to encrypt SSH sessions — without it, SSH can't work at all (there's nothing to encrypt with). "modulus 2048" sets the key size in bits — bigger is more secure but takes longer to generate; 2048 is the modern standard. This step needs a hostname and domain name already set, because the key's internal name is built from hostname.domain-name.

Step 4 — Create the VLANs you'll need (including the unused-native parking VLAN).

cisco-ios
SW1(config)# vlan 10
SW1(config-vlan)# name SALES
SW1(config-vlan)# exit
SW1(config)# vlan 999
SW1(config-vlan)# name UNUSED_NATIVE_VLAN
SW1(config-vlan)# exit

Step 5 — Configure access ports: VLAN assignment + port security + PortFast/BPDU Guard.

cisco-ios
SW1(config)# interface range fastEthernet0/1 - 9
SW1(config-if-range)# switchport mode access
SW1(config-if-range)# switchport access vlan 10
SW1(config-if-range)# switchport port-security
SW1(config-if-range)# switchport port-security maximum 1
SW1(config-if-range)# switchport port-security mac-address sticky
SW1(config-if-range)# switchport port-security violation shutdown
SW1(config-if-range)# switchport nonegotiate
SW1(config-if-range)# spanning-tree portfast
SW1(config-if-range)# spanning-tree bpduguard enable
SW1(config-if-range)# exit
What "sticky" does
Instead of you having to manually type in the exact MAC address every legitimate device on a port should have, "sticky" tells the switch to learn the first MAC address(es) it actually sees on that port and automatically write them into the running config as if you'd typed them yourself. It's the low-effort way to lock a port to "whatever's already plugged in" without hunting down every MAC address by hand.

Every real end-host port gets: locked to access mode, correct VLAN, port security (1 sticky MAC, shut down on violation), DTP disabled, and PortFast + BPDU Guard.

Step 6 — Configure the trunk port.

cisco-ios
SW1(config)# interface gigabitEthernet0/1
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 999
SW1(config-if)# switchport trunk allowed vlan 10,20,30
SW1(config-if)# switchport nonegotiate
SW1(config-if)# exit

Native VLAN moved off VLAN 1 to the unused parking VLAN, allowed-VLAN list explicitly pruned, DTP disabled.

Step 7 — Shut down every unused port and park it in the unused VLAN.

cisco-ios
SW1(config)# interface range fastEthernet0/10 - 24
SW1(config-if-range)# switchport mode access
SW1(config-if-range)# switchport access vlan 999
SW1(config-if-range)# shutdown
SW1(config-if-range)# description UNUSED_DISABLED
SW1(config-if-range)# exit

Step 8 — Configure errdisable auto-recovery so a triggered defense doesn't leave a legitimate port down.

cisco-ios
SW1(config)# errdisable recovery cause psecure-violation
SW1(config)# errdisable recovery cause bpduguard
SW1(config)# errdisable recovery interval 30

Step 9 — Save.

cisco-ios
SW1# copy running-config startup-config

Things to try / extra points#

  • Use this as a template pass, then go back through with the topology/questions in hand and adjust IPs, VLAN IDs, and any scenario-specific requirements — don't apply it verbatim if it conflicts with something the question explicitly asks for differently.
  • After running the full template on a device, do one final show running-config read-through top to bottom looking for anything left in a bad state (leftover enable password, an interface still shutdown that should be up, etc.), and run the Section 32 self-audit checklist against it.
  • Repeat copy running-config startup-config at the very end of your entire session on every device — the most common way to lose credit is forgetting to save on one of several devices in a multi-device topology.
  • Common step-order mistake: running Step 4 (SSH key generation) before Step 1 (hostname/domain-name) on the router. If you see % Please define a domain-name first (or a similarly-worded error), it means you skipped or mistyped Step 1 — go back, confirm hostname and ip domain-name are both set with show running-config | include hostname|domain-name, then retry crypto key generate rsa.
  • After Step 5/Step 3 (VTY lines), immediately test a real SSH login (from another device in the topology, or Packet Tracer's simulated terminal) rather than trusting the config alone — this catches a login local typo or a missing username before you've moved on to ten more commands.
  • If switchport port-security violation shutdown in Step 5 causes a port to go err-disabled during your own testing (e.g., you plugged a test cable into the wrong port), that's expected — recover with shutdown then no shutdown on that interface, or rely on the auto-recovery configured in Step 8.
  • Verify the whole device against the Section 23 show commands reference once all steps are done — don't just trust that no error messages appeared.

29. Appendix A: OSI Model Cheat Sheet#

Layer # Name Function Example Protocols/Devices
7 Application Provides network services directly to end-user applications HTTP, HTTPS, FTP, DNS, SMTP, Telnet, SSH
6 Presentation Data translation/formatting, encryption, compression SSL/TLS, JPEG, ASCII/EBCDIC
5 Session Establishes, manages, and terminates sessions between hosts NetBIOS, RPC, PPTP
4 Transport End-to-end connections, segmentation, reliability, flow control TCP, UDP
3 Network Logical addressing and routing between networks IP, ICMP, OSPF, routers
2 Data Link Physical addressing (MAC), framing, error detection on a single link Ethernet, switches, ARP, VLANs
1 Physical Raw bit transmission over physical media Cables, hubs, NICs, radio signals

Mnemonic (top to bottom, 7→1): All People Seem To Need Data Processing. Mnemonic (bottom to top, 1→7): Please Do Not Throw Sausage Pizza Away.

Device-to-layer mapping (common question type):

Things to try / extra points#

  • Expect a written question phrased like "at which layer does a switch operate?" or "what layer handles logical/IP addressing?" — memorize the table above cold; these are fast, free points.
  • Be ready to distinguish hub vs. switch vs. router conceptually (broadcast domain vs. collision domain, addressing type used, layer of operation) — a very common multiple-choice pattern.

30. Appendix B: Subnetting / CIDR Quick Reference#

Default classful masks#

Class Default Mask First Octet Range
A 255.0.0.0 (/8) 1–126
B 255.255.0.0 (/16) 128–191
C 255.255.255.0 (/24) 192–223
  • 127.x.x.x — reserved for loopback, not a usable class A network.
  • Private ranges (RFC 1918):
    • Class A private: 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
    • Class B private: 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
    • Class C private: 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)

CIDR / subnet mask / host count reference#

CIDR Subnet Mask Usable Hosts (mask − 2)
/8 255.0.0.0 16,777,214
/16 255.255.0.0 65,534
/17 255.255.128.0 32,766
/18 255.255.192.0 16,382
/19 255.255.224.0 8,190
/20 255.255.240.0 4,094
/21 255.255.248.0 2,046
/22 255.255.252.0 1,022
/23 255.255.254.0 510
/24 255.255.255.0 254
/25 255.255.255.128 126
/26 255.255.255.192 62
/27 255.255.255.224 30
/28 255.255.255.240 14
/29 255.255.255.248 6
/30 255.255.255.252 2 (point-to-point link)

Quick subnetting method ("magic number")#

  1. Identify the interesting octet — the one where the mask isn't 0 or 255.
  2. The block size ("magic number") = 256 − <mask value in that octet>.
    • Example: /26 → mask octet = 192 → block size = 256 − 192 = 64.
  3. Subnets increment by the block size in that octet: 0, 64, 128, 192 for a /26.
  4. Usable host range in each subnet = network address + 1, through broadcast address − 1.
    • Example: for the 192.168.1.64/26 subnet → network .64, broadcast .127, usable hosts .65–.126.

Things to try / extra points#

  • Practice going both directions fast: "given this IP + CIDR, what's the network/broadcast/usable range?" and "given this many required hosts, what's the smallest CIDR that fits?" — both are common written-question formats.
  • Remember usable hosts = 2^(host bits) − 2 (subtract network address and broadcast address) — except for /31 (point-to-point, no broadcast, both addresses usable under RFC 3021) and /32 (single host, no subnetting).
  • Double-check any ACL wildcard mask question by first converting the subnet mask to CIDR, then inverting: wildcard = 255.255.255.255 − subnet mask.

31. Appendix C: Common Ports Cheat Sheet#

Port Protocol Service
20/21 TCP FTP (data / control)
22 TCP SSH
23 TCP Telnet
25 TCP SMTP
53 TCP/UDP DNS
67/68 UDP DHCP (server/client)
69 UDP TFTP
80 TCP HTTP
110 TCP POP3
123 UDP NTP
143 TCP IMAP
161/162 UDP SNMP (agent/trap)
443 TCP HTTPS
445 TCP SMB
514 UDP Syslog
3389 TCP RDP

Things to try / extra points#

  • Memorize at minimum: 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 53 (DNS), 67/68 (DHCP) — these show up constantly in both ACL configuration tasks and written questions.
  • When writing an extended ACL to "block insecure remote management," the answer is almost always deny/permit around ports 22 vs. 23 (SSH good, Telnet bad) or 80 vs. 443 (HTTP bad, HTTPS good).

32. Common Mistakes to Verify Before Submitting (Self-Audit Pass)#

Unlike some CyberPatriot categories, the Cisco/Packet Tracer module is less about hunting planted vulnerabilities and more about correct configuration without breaking your own connectivity. Recurring troubleshooting research (competitor postmortems, Packet Tracer instructor guides, and networking-course lab retrospectives) keeps surfacing the same small set of self-inflicted mistake categories, year after year. This section is a self-audit checklist — run it against every device before you consider that device "done," not a vulnerability hunt. Check the boring, foundational stuff first: a wrong subnet mask can produce symptoms that look exactly like a much scarier problem, and chasing the scary-looking problem first wastes round time.

Why this matters: In Packet Tracer, a single wrong digit in an IP address or a port that's shutdown when it shouldn't be can make an entire segment look "broken" in a way that's easy to misdiagnose as a routing or ACL problem. Competitors consistently report losing 10-20 minutes chasing an "ACL is blocking something" theory when the actual cause was a typo'd subnet mask or a forgotten no shutdown. Run this checklist first, in this order, before assuming anything more complex is wrong.

Layer 3 basics (check these FIRST)#

These are described as "simple but foundational" — they're also the fastest to check and rule out.

  • IP address correctness: Does every interface actually have the IP address the topology/question specifies? A single wrong octet is enough to break connectivity while looking, at a glance, like a working config.
  • Subnet mask correctness: Is the mask the right length for the intended subnet (e.g., /26 vs. the default /24)? A too-short or too-long mask can make hosts that should be able to reach each other appear to be on different networks (or vice versa) — this is one of the single most common self-inflicted "connectivity broke and I don't know why" causes.
  • Default gateway: Does every end device (and every DHCP pool's default-router field) point at the correct router interface IP? A wrong gateway means a host can talk to others on its own subnet but nothing beyond it — a very specific, diagnosable symptom worth recognizing.
  • Static routes: Is every ip route statement pointing at the correct next-hop or exit interface, with the correct destination network and mask? A backwards or mistyped static route silently breaks reachability to just that one destination while everything else keeps working, which can be confusing to isolate.

Verify with:

cisco-ios
R1# show ip interface brief
R1# show running-config interface <id>
R1# show ip route
R1# ping <destination>
R1# traceroute <destination>
Expected result:
  • A clean ping shows !!!!! (5 successes); traceroute lists each hop with round-trip times ending at the destination.
  • A route matching the destination should appear in show ip route — if it doesn't, nothing else in the chain will work.
If it fails:
  • ..... (all dots, no !) from ping means no reply at all — check show ip route first for a missing/wrong route before suspecting anything else.
  • A mix like .!.!. (partial success) usually points at a duplicate IP conflict or an intermittent Layer 1/2 issue, not a routing problem.
  • traceroute stopping at a specific hop (rather than reaching the destination) tells you exactly which device in the path is the problem — that's more diagnostic than ping alone, use it when ping simply fails with no further clue.

show ip interface brief gives you a fast top-to-bottom scan of every interface's IP and up/down state. show ip route confirms the route table actually has the path you expect — if a route is missing or wrong, nothing downstream will make sense until it's fixed. Always ping and traceroute from both directions (A to B and B to A) — asymmetric routing/firewalling issues only show up one way.

Layer 2 basics (the sneaky ones)#

These produce misleading symptoms — the physical link looks fine (link light up, show ip interface brief shows "up/up"), but hosts still can't communicate. That mismatch between "looks fine" and "doesn't work" is exactly what wastes time if you don't check it early.

  • VLAN misassignment: Is the access port actually assigned to the VLAN the host is supposed to be on (switchport access vlan <id>)? A port sitting in the wrong VLAN will show as fully "up" while the device on it simply can't reach anything on its intended subnet.
  • Trunk mode / encapsulation mismatches: Do both ends of a trunk agree on trunk mode, encapsulation (dot1q), native VLAN, and allowed-VLAN list? A one-sided trunk (one end set to trunk, the other left on dynamic auto/access) or a native VLAN mismatch can partially or fully break inter-switch traffic while the physical link still shows connected.
  • Unintended shutdown state (or the reverse): Is a port that's supposed to be active sitting administratively down because it was shut down as part of your "shut down all unused ports" sweep — but it turned out to have a real device on it? Conversely, did you forget to shutdown a port that really is unused? Both directions matter; re-check your work here specifically, since bulk interface range commands make it easy to catch one extra port or miss one.

Verify with:

cisco-ios
Switch# show ip interface brief
Switch# show interfaces <id> switchport
Switch# show interfaces <id> trunk
Switch# show vlan brief
Switch# show interfaces status
Expected result:show interfaces <id> switchport should show matching Administrative Mode and Operational Mode (e.g., both static access), the correct Access Mode VLAN, and (for trunks) the correct native VLAN with Negotiation of Trunking: Off.
If it fails:
  • Administrative and Operational mode disagreeing (e.g., admin says access but operational shows trunk, or vice versa) is the classic DTP-negotiation symptom — one end auto-negotiated into a mode you didn't intend; fix by explicitly setting switchport mode on both ends rather than leaving either on a dynamic default.
  • If a port shows up in show vlan brief under a VLAN you didn't expect, that's usually a leftover from a previous config or a typo'd VLAN ID in the switchport access vlan command — re-run it with the correct ID.

show interfaces <id> switchport is the single best command for catching VLAN/trunk misconfiguration — it shows administrative mode, operational mode, access VLAN, and native VLAN all in one place, so a mismatch is immediately visible. show vlan brief cross-checks which ports the switch thinks belong to which VLAN — compare it against the topology diagram, not just against what you remember typing.

Time-saving tip: If a host "can't reach anything," check Layer 2 (VLAN assignment, port shutdown state, trunk config) before you start second-guessing your ACLs or routing — a surprising number of "broken ACL" theories turn out to be a port sitting in the wrong VLAN or administratively shut down.

Service-level basics#

  • DHCP scope typos: Is the default-router and dns-server in every DHCP pool the exact correct IP (not just "close")? (Cross-check against Section 18 and Section 26 if you configured DHCP earlier — it's easy to set this correctly once and then change a gateway IP elsewhere later without circling back to update the pool.)
  • DNS resolution failures: If the scenario relies on name resolution (a server's DNS records, a PC's configured DNS server), does ping <hostname> actually resolve and succeed from an end device, not just ping <ip>?
  • An ACL blocking traffic you didn't mean to block: After applying any ACL, did you actually test the traffic you intended to allow, not just confirm the traffic you intended to block is blocked? It's very easy to write a rule that's technically correct but too narrow (e.g., forgetting a second subnet, or a wrong wildcard mask) and silently break legitimate traffic via the implicit deny.

Verify with:

cisco-ios
R1# show ip dhcp binding
R1# show ip dhcp conflict
PC> ipconfig /all
PC> ping <hostname>
PC> ping <default-gateway>
R1# show access-lists
R1# show ip interface <id>
Expected result:show ip dhcp binding lists active leases with client MAC/IP/lease-expiration; ping <hostname> resolves to an IP before showing the usual !!!!!/..... reply pattern; show access-lists shows per-line match counters incrementing (visible proof traffic is actually hitting each rule, not just that the syntax is valid).
If it fails:
  • ping <hostname> failing while ping <ip> (the same host, by address) succeeds isolates the problem to DNS specifically, not general connectivity — check the DNS server's IP configured on the client and whether that DNS service/record actually exists.
  • If show access-lists shows zero match counters on a permit line you expected to be hit, that's a strong sign the ACL was applied to the wrong interface/direction (see Section 16) — the traffic simply never reaches this ACL at all.

Test connectivity after applying an ACL, not just immediately after writing it — writing correct-looking ACL syntax and applying it to the wrong interface/direction is a distinct failure mode from writing the ACL logic wrong in the first place, and only an actual ping/traceroute test catches both.

Things to try / extra points#

  • Run this entire section as a standalone pass on every device, right after you finish configuring it and again right before final submission — problems introduced later (e.g., re-typing a gateway IP while working on DHCP) can silently break something you already verified earlier.
  • Keep this self-audit separate in your head from security hardening — a device can be perfectly "hardened" (great passwords, SSH working, ACLs applied) and still fail the round because a subnet mask is wrong. Both matter, but they're different failure modes and need different checks.
  • If something that used to work suddenly doesn't after a later change, suspect the most recent thing you touched first — re-read your last few commands in show running-config before assuming an unrelated new bug appeared.
  • Consider literally checking off this section's four verification command blocks on every router and every switch as a fixed end-of-device routine, the same way you'd always run copy running-config startup-config — treat it as equally non-optional.

33. Final Submission Checklist#

Final checkpoint: Before you consider yourself done, do a File → Save As on the Packet Tracer file one last time under a clearly-labeled "final" filename, and run copy running-config startup-config on every single device in the topology. A great config sitting only in a device's running-config (or only in an un-saved .pkt) can be lost to a reload, crash, or time cutoff and score as if it were never done.

A last-pass sweep across every device before time runs out: