Securing Discovery on Edge Ports
Harden Cisco IOS edge interfaces by disabling CDP/LLDP toward untrusted endpoints while keeping discovery active on trusted infrastructure links. Routers share a management LAN with a server and form a direct router-to-router adjacency for CDP/LLDP. The learner enables discovery globally, selectively suppresses it on the client-facing edge, and verifies the outcome with show commands.
CDP Neighbor Discovery and Edge Suppression
Enable Cisco Discovery Protocol (CDP) on R1 to map directly-connected Cisco neighbors while suppressing CDP advertisements on the untrusted management-edge interface. Routers are directly cabled for true CDP adjacency and also share a common management LAN via SW1 alongside an Alpine MGMT host.
LLDP for Multi-Vendor Discovery
Enable the open-standard LLDP on adjacent Cisco IOS routers over direct point-to-point links while also attaching the devices to a shared management LAN. Learners configure deterministic LLDP behavior (global enable plus per-interface transmit/receive) and verify neighbor discovery without adding any routing protocols or static routes.
Centralized Syslog with Timestamps
Configure a Cisco IOS router (R1) to forward its logs to a central syslog server with accurate date/time and millisecond timestamps. Validate the remote host and trap level in show logging. This is Lab 4 of 10 in the Network Discovery & Monitoring series.
Syslog Severity & Buffered Logging
Tune which syslog messages go where on Cisco IOS using severity levels: keep detailed logs locally in a 16 KB buffer, reduce console noise to warnings, and send notifications to a central server. Single management LAN, no routing. Grading focuses on three R1 commands steering severity: logging buffered 16384 debugging, logging console warnings, and logging trap notifications.
Discovery & Monitoring Troubleshooting Capstone
Troubleshoot a pre-broken monitoring deployment on a single shared management LAN. R1 is already configured for discovery and monitoring, but the NMS receives no syslog or SNMP traps from R1. Diagnose with show commands and correct the two seeded faults: wrong syslog target and missing SNMP trap generation. Deterministic, no-routing, single-subnet design for CML Free (5 nodes).
DNS Name Resolution on IOS
Enable and verify DNS-based name resolution on Cisco IOS. R1 will use a central DNS resolver on the management LAN and also maintain a static host mapping for R2, demonstrating resolution order and operational differences between local host tables and DNS queries.
SNMPv3 AuthPriv Monitoring
Harden the monitoring plane by replacing cleartext SNMPv2c with authenticated and encrypted SNMPv3 (authPriv) on R1. You will create a v3 group that requires privacy and a user with SHA authentication and AES-128 encryption, then verify the configuration. The flat management LAN avoids routing complexity so you can focus on the security mechanics of SNMPv3.
SNMPv2c Read-Only Monitoring
Configure Cisco IOS SNMPv2c read-only access on R1 so an NMS on a trusted management LAN can poll device status. You will add a read-only community string and device identity (location/contact), validate from IOS show commands, and confirm basic reachability from the MGMT host. No routing protocols or static routes are used; all devices share a single management subnet bridged by an L2 switch.
SNMP Trap Notifications to the NMS
Configure a Cisco IOS router (R1) to proactively send SNMPv2c trap notifications to a centralized NMS host. Learners practice the difference between polling and traps, add the trap destination and enable device-initiated notifications, and verify deterministically with show commands. Flat L2-only management LAN; no routing, no VLAN/STP complexity.
SSH Hardening to Version 2
Harden the management-plane SSH service on a single Cisco IOS router so only SSHv2 is permitted and session limits are tightened. The baseline lab already has working SSH. You will enforce SSH version 2, set a 60-second authentication timeout, and limit authentication retries to 2. You will also regenerate a 2048-bit RSA key (an exec-only step) and validate with show commands.
Blocking Brute-Force Logins and Adding a Banner on R1
Harden the management plane of a single IOS router by throttling brute-force login attempts and presenting a legal-warning banner. You will enable SSH-based management, configure login block-for and delay to resist password-guessing, and verify behavior from an ADMIN Linux workstation.
Enable Secret and Password Encryption on R1
Harden privileged access on a single IOS router by configuring a hashed enable secret, creating a local admin user with privilege 15 and a secret, and enabling service password-encryption. Verify that privileged access requires the secret and that the running-config contains no cleartext passwords.
AAA Authentication with a Local User Database
Harden R1’s management plane by moving SSH login authentication and exec authorization under the IOS AAA framework using the local user database. You will start from a secure SSH-only baseline that still uses login local, enable aaa new-model, define default AAA methods that point at local, and bind VTY lines to AAA. Success is proven by authenticating from the ADMIN host over SSH and landing at the user’s privilege level.
CCNA: Console and VTY Line Hardening
Harden the console and VTY lines on a single Cisco IOS router so idle sessions close automatically and every access path requires authentication. You will configure login local on both console and VTY, set 5-minute exec timeouts, enable logging synchronous on the console, and restrict VTY to SSH. Verification uses show outputs; grading evaluates the deterministic running-config.
SSH-Only Management: Disabling Telnet on R1
Harden a Cisco IOS router so remote management is allowed only via SSH. You will remove Telnet from the VTY lines, keep local authentication, and add an idle-session timeout. Verify success from a Linux ADMIN host by confirming SSH works and Telnet is refused.
CCNA: SSH Access Fundamentals on R1
Bring up secure remote management (SSH) on a single Cisco IOS router using a dedicated management LAN. You will configure the deterministic set of running-config lines that enable SSH with a local admin account, restrict VTY to SSH, and verify from a Linux workstation. RSA key generation is performed as an exec step and is not graded; the grading focuses on the presence of the configuration lines that make SSH functional and secure.