Login Security — Brute-Force Protection

A Cisco router exposed to management access — even only via SSH on a restricted subnet — remains vulnerable to brute-force attacks: automated tools that try thousands of username and password combinations until one succeeds. Without countermeasures, IOS accepts every login attempt immediately — a script can try hundreds of passwords per minute with no slowdown, no lockout, and no alert.

Cisco IOS provides a layered set of brute-force defences built directly into the operating system — no external server or licence required. Login block-for triggers a temporary lockout after a defined number of failures. Login delay artificially slows each attempt. Quiet-mode ACL ensures legitimate administrators can bypass the lockout from trusted IPs. Login failure logging records every failed attempt in syslog for security monitoring. Together these four controls make brute-force attacks impractical regardless of password complexity.

This configuration works alongside — not instead of — strong authentication. Complete SSH Configuration and AAA with TACACS+ or AAA with RADIUS first. For source-IP restrictions that prevent attackers from reaching the login prompt at all, see Standard ACL Configuration and Console & VTY Line Configuration. For reviewing login failure log entries after they are generated, see show logging.

1. Login Security — Core Concepts

The Brute-Force Attack Problem

Without protection, a Cisco router's login behaviour allows unlimited retries at wire speed. The four IOS login security commands directly address each step of the attack cycle:

✗ Without Protection Attacker → try "password1" → FAIL immediate retry, no delay Attacker → try "password2" → FAIL immediate retry, no delay Attacker → try "password3" → FAIL immediate retry, no delay Unlimited attempts at wire speed — no lockout, no alert ~600+ attempts/min · 1,000 passwords in ~1.5 min ✓ With All Four Controls Attacker → try "password1" → FAIL [2 sec delay: login delay 2] Attacker → try "password2" → FAIL [2 sec delay] 5 failures within 30 seconds → QUIET MODE triggered immediately All new logins BLOCKED for 120 sec Syslog: %SEC_LOGIN-1-QUIET_MODE_ON Admin 192.168.10.5 still permitted via ADMIN-BYPASS ~30 attempts/min · lockout after 5 failures login block-for 120 attempts 5 within 30 login delay 2 login quiet-mode access-class ADMIN-BYPASS login on-failure log NetsTuts

The Four Login Security Commands

Command What It Does Protects Against
login block-for After X failures within Y seconds, blocks all new logins for Z seconds (quiet mode) Automated credential stuffing and brute-force bursts
login delay Forces a mandatory pause (seconds) between each login attempt Slows password-guessing tools — caps attempt rate to a practical maximum
login quiet-mode access-class Names an ACL whose permitted IPs bypass quiet-mode lockout — admin whitelist Prevents legitimate admins from being locked out by attacker-triggered quiet mode
login on-failure log Generates a syslog message for every failed login attempt with source IP and timestamp Provides visibility — failed attempts recorded and can trigger SIEM alerts

Normal Mode vs Quiet Mode

State Trigger Login Behaviour Quiet-Mode ACL Applies?
Normal mode Default — no threshold exceeded Login attempts accepted with the configured delay between each N/A — all sources may attempt login (subject to VTY ACL)
Quiet mode Failure threshold exceeded: X failures within Y seconds ALL new login connections blocked — TCP refused before the username prompt appears ✓ Yes — IPs permitted by quiet-mode ACL still reach the login prompt
Quiet mode blocks ALL sources — including legitimate admins. If an attacker triggers quiet mode and no quiet-mode ACL is configured, every administrator is locked out for the block-for period. Always configure login quiet-mode access-class before enabling login block-for. The quiet-mode ACL is the most operationally critical part of this configuration.

Relationship to VTY ACL

Control Filters By Blocks At
VTY ACL (access-class) — see Console & VTY Line Configuration Source IP address — only whitelisted IPs can attempt login TCP connection level — unauthorised IPs cannot even connect
Login security (login block-for) Failure count and rate — too many failures from any permitted source Login prompt level — connections accepted but credentials rejected with delay/lockout

2. Lab Topology & Scenario

NetsTuts_R1 is the management target. SSH access is restricted to the management subnet (192.168.10.0/24). Brute-force protection is enforced with login block-for. The admin workstation (192.168.10.5) is whitelisted in the quiet-mode bypass ACL:

Lab Topology — NetsTuts_R1 Brute-Force Protection Admin PC 192.168.10.5 ← in ADMIN-BYPASS ACL Attacker 192.168.10.99 ← blocked during quiet mode 192.168.10.0/24 — Management Subnet Gi0/1 (INSIDE) 192.168.10.1 NetsTuts_R1 login block-for 120 attempts 5 within 30 login delay 2 login quiet-mode access-class ADMIN-BYPASS login on-failure log Gi0/0 (WAN) 203.0.113.2 block-for: 120 s · attempts: 5 · within: 30 s · delay: 2 s · bypass ACL: ADMIN-BYPASS (192.168.10.5) NetsTuts
Parameter Value Meaning
block-for 120 seconds Quiet mode duration — all non-whitelisted logins blocked for 2 minutes
attempts 5 Number of failures that triggers quiet mode
within 30 seconds Observation window — 5 failures must occur within this window to trigger
login delay 2 seconds Mandatory pause after each attempt — even successful ones
quiet-mode ACL ADMIN-BYPASS Permits 192.168.10.5 to bypass quiet mode lockout

3. Step 1 — Create the Quiet-Mode Bypass ACL First

The quiet-mode ACL must be created before login block-for is enabled. If quiet mode triggers before the ACL exists, all sources including the admin are locked out until the timer expires. For a full guide to named standard ACLs, see Named ACLs and Standard ACL Configuration: 

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! -- Quiet-mode bypass: permit admin workstation only
NetsTuts_R1(config)#ip access-list standard ADMIN-BYPASS
NetsTuts_R1(config-std-nacl)#remark Admin workstation bypasses login quiet mode
NetsTuts_R1(config-std-nacl)#10 permit host 192.168.10.5
NetsTuts_R1(config-std-nacl)#20 deny any
NetsTuts_R1(config-std-nacl)#exit
The ADMIN-BYPASS ACL is a standard ACL filtering by source IP only. IPs permitted by this ACL can reach the login prompt even during quiet mode. For a team of admins, use a subnet entry with a wildcard mask: permit 192.168.10.0 0.0.0.15 to cover a /28 block.

4. Step 2 — Configure login block-for

! -- Syntax: login block-for [seconds] attempts [count] within [seconds]
! -- Block for 120 sec if 5 failures occur within 30 seconds
NetsTuts_R1(config)#login block-for 120 attempts 5 within 30

login block-for Parameter Breakdown

Parameter Lab Value Meaning
block-for [n] 120 Quiet mode duration in seconds — all non-whitelisted login connections refused for this long
attempts [n] 5 Failure threshold — this many failures within the window triggers quiet mode
within [n] 30 Observation window in seconds — the failure counter resets if this time passes without reaching the threshold
Threshold tuning guidance. The attempts value should exceed any realistic human mistype rate — 3 to 5 is standard. The within window should be short enough to catch automation (which attempts many passwords per second) without punishing a user who paused between retries. The block-for duration should be long enough to frustrate automation (60–300 seconds) without permanently locking out a forgetful engineer.

5. Step 3 — Configure login delay

! -- Force 2-second pause between all login attempts
NetsTuts_R1(config)#login delay 2
The delay applies to all VTY and console line logins globally. There is no per-source exception — even the admin experiences the 2-second pause after each attempt.

Effect of login delay on Attack Rate

Login Delay Max Attempts / Min Time to Try 1,000 Passwords Practical Effect
No delay (default) ~600+ ~1.5 minutes Brute force feasible with fast connection
login delay 1 ~60 ~16 minutes Slows tools but still practical
login delay 2 ~30 ~33 minutes Combined with block-for, impractical
login delay 5 ~12 ~83 minutes Very slow — may frustrate automation and admin testing equally

6. Step 4 — Apply the Quiet-Mode ACL

! -- Bind quiet-mode bypass ACL to the login engine
NetsTuts_R1(config)#login quiet-mode access-class ADMIN-BYPASS
When quiet mode activates, IOS checks every new incoming connection against ADMIN-BYPASS. Source IP 192.168.10.5 matches the permit entry — the login prompt is presented normally. Any other source hits the deny and is refused during quiet mode. This is different from access-class under line vty which is covered in Console & VTY Line Configuration.

7. Step 5 — Enable Login Failure and Success Logging

! -- Log every failed login attempt
NetsTuts_R1(config)#login on-failure log

! -- Optionally log every N failures to reduce volume during attack
NetsTuts_R1(config)#login on-failure log every 3

! -- Log every successful login
NetsTuts_R1(config)#login on-success log

! -- Accurate timestamps require NTP sync
NetsTuts_R1(config)#service timestamps log datetime msec show-timezone

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
login on-failure log without every logs every single failed attempt — which can flood the log buffer during active attacks. The every 3 modifier logs every 3rd failure, reducing noise while maintaining visibility. login on-success log audits successful logins — useful for detecting after-hours access or unexpected source IPs. Both require NTP synchronisation for accurate timestamps. To forward logs to a central server, see Syslog Server Configuration.

Login Logging Options

Command What Is Logged Log Volume Recommended Use
login on-failure log Every failed attempt — source IP, username, timestamp, VTY line High during attack Use with every [n] on busy devices
login on-failure log every 3 Every 3rd failed attempt Moderate ✓ Recommended for production
login on-success log Every successful login — source IP, username, timestamp Low ✓ Always enable — tracks who logged in and from where

8. Step 6 — Complete VTY Security Integration

! -- VTY ACL: only management subnet can attempt login
NetsTuts_R1(config)#ip access-list standard MGMT-VTY
NetsTuts_R1(config-std-nacl)#remark Only management VLAN reaches VTY
NetsTuts_R1(config-std-nacl)#10 permit 192.168.10.0 0.0.0.255
NetsTuts_R1(config-std-nacl)#exit

! -- VTY line settings
NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#access-class MGMT-VTY in
NetsTuts_R1(config-line)#exec-timeout 5 0
NetsTuts_R1(config-line)#transport input ssh
NetsTuts_R1(config-line)#exit

! -- Console timeout
NetsTuts_R1(config)#line console 0
NetsTuts_R1(config-line)#exec-timeout 10 0
NetsTuts_R1(config-line)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]

Complete Login Security Stack — All Layers

Layer Control Command What It Stops
1 — Network VTY source ACL access-class MGMT-VTY in Attacker IPs outside management subnet cannot connect
2 — Rate limiting Login delay login delay 2 Throttles attempt rate to ~30/min max from permitted sources
3 — Lockout Login block-for login block-for 120 attempts 5 within 30 2-minute full block after 5 failures in 30 seconds
4 — Admin bypass Quiet-mode ACL login quiet-mode access-class ADMIN-BYPASS Admin remains accessible even during attacker-triggered lockout
5 — Visibility Failure logging login on-failure log Every failure recorded for monitoring and incident response
6 — Session Idle timeout exec-timeout 5 0 Abandoned authenticated sessions auto-disconnect after 5 minutes

9. Verification

show login — Normal Mode

NetsTuts_R1#show login
     A login delay of 2 seconds is applied.
     Quiet-Mode access list ADMIN-BYPASS is applied.

     Router enabled to watch for login Attacks.
     If more than 5 login failures occur in 30 seconds or less,
     logins will be disabled for 120 seconds.

     Router presently in Normal-Mode.
     Current Watch Window
       Time remaining: 18 seconds.
       Login failures for current window: 0.
     Total login failures: 0.
Key fields: "login delay of 2 seconds is applied" confirms the delay. "Quiet-Mode access list ADMIN-BYPASS is applied" confirms the bypass ACL is linked. "Router presently in Normal-Mode" confirms quiet mode is not currently active. "Login failures for current window: 0" shows the rolling 30-second observation window counter.

show login — During Quiet Mode

NetsTuts_R1#show login
     A login delay of 2 seconds is applied.
     Quiet-Mode access list ADMIN-BYPASS is applied.

  !! Router presently in Quiet-Mode !!
     Will remain in Quiet-Mode for 97 seconds.
     Denying logins from all sources.
     Logins from ADMIN-BYPASS list are still permitted.

     Total login failures: 7.
"Router presently in Quiet-Mode" confirms the lockout is active. "Will remain in Quiet-Mode for 97 seconds" shows the countdown timer. "Logins from ADMIN-BYPASS list are still permitted" confirms the admin bypass is functioning.

show login failures — Per-Source Attack Detail

NetsTuts_R1#show login failures
Information about login failures is stored in System.

Total failed logins: 7
Threshold reached 1 time.

Failed login attempts from following IPs:
IP: 192.168.10.99   Total Failures: 7   Consecutive Failures: 7
  Failures in last 30 secs: 5   Latest time: 09:15:42 AST Mar 5 2026
show login failures provides per-source-IP breakdown — the most valuable post-incident command. "Threshold reached 1 time" — quiet mode has been triggered once total. IP 192.168.10.99 with 7 consecutive failures is the attacking source. "Failures in last 30 secs: 5" shows the 5 failures in the window that triggered quiet mode.

Syslog Output — login on-failure log Messages

NetsTuts_R1#show logging
...
Mar  5 09:15:38.214 AST: %SEC_LOGIN-4-LOGIN_FAILED: Login failed
  [user: attacker] [Source: 192.168.10.99] [localport: 22]
  [Reason: Login Authentication Failed] at 09:15:38 AST Mar 5 2026

Mar  5 09:15:42.871 AST: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft
  for watching failures is 5 secs, [user: password3]
  [Source: 192.168.10.99] [localport: 22].
  Watchfor failure exceeded. Router going to QUIET-MODE for 120 secs.

Mar  5 09:15:45.123 AST: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success
  [user: admin] [Source: 192.168.10.5] [localport: 22]
  at 09:15:45 AST Mar 5 2026
Three syslog message types: SEC_LOGIN-4-LOGIN_FAILED (severity 4 — Warning) records individual failed attempts with the username tried and source IP. SEC_LOGIN-1-QUIET_MODE_ON (severity 1 — Alert) fires the moment quiet mode activates — the highest priority login security event, should trigger immediate SIEM alerts. SEC_LOGIN-5-LOGIN_SUCCESS (severity 5 — Notice) records the admin's successful login from 192.168.10.5 during quiet mode — possible because of the ADMIN-BYPASS ACL. See Syslog for an explanation of severity levels and Syslog Server Configuration for forwarding these events to a central log server.

Verification Command Summary

Command What It Shows Primary Use
show login Current mode (Normal/Quiet), timer, failure count in window, all configured parameters Primary status check — always run after configuration to confirm all four controls are active
show login failures Per-source-IP failure table — total, consecutive, window count, last timestamp Post-incident analysis — identify attacking IP and attack timeline
show logging SEC_LOGIN syslog messages — FAILED, QUIET_MODE_ON, SUCCESS events with timestamps Real-time monitoring — confirm failures are logged and QUIET_MODE_ON alerts are generated
show running-config | include login All login security commands — block-for, delay, quiet-mode ACL, logging Config audit — verify all four controls are present and correctly configured
clear login failures Resets failure counters and clears the failure table — does not end active quiet mode Reset counters before testing or after clearing a false positive
show ip access-lists ADMIN-BYPASS Bypass ACL entries and match counters Verify bypass ACL permits correct admin IPs and is being evaluated

10. Troubleshooting Login Security Issues

Problem Symptom Cause Fix
Admin locked out during quiet mode SSH refused from admin PC during active quiet mode Quiet-mode ACL not configured, has wrong IP, or not bound with login quiet-mode access-class Use console (unaffected by quiet mode). Check show login — confirm ADMIN-BYPASS is applied. Verify ACL has correct admin IP: show ip access-lists ADMIN-BYPASS. Reconfigure: login quiet-mode access-class ADMIN-BYPASS. See Console & VTY Line Configuration.
Quiet mode not triggering Many failed logins but show login stays Normal-Mode login block-for not configured, or failures are spread beyond the observation window and the counter resets between attempts Verify: show running-config | include login block-for. Check timestamps in show login failures — are they within the within window? If failures are spaced by login delay beyond the window, reduce the within value.
Login failures not in syslog Attacks occurring but no SEC_LOGIN messages in show logging login on-failure log not configured, logging disabled, or log buffer overwritten Verify: show running-config | include login on-failure. Enable: login on-failure log. Check: show logging — confirm buffer is enabled. For forwarding to a syslog server, verify logging [server-IP] is configured. See Syslog Server Configuration.
Legitimate admin triggers quiet mode Admin accidentally triggers lockout during password testing Admin PC not in quiet-mode ACL, or testing from a different workstation Access via console. Add additional workstation to ADMIN-BYPASS: ip access-list standard ADMIN-BYPASS then permit host [new-IP]. Widen to a subnet if needed using a wildcard mask: permit 192.168.10.0 0.0.0.15.
Monitoring tools triggering quiet mode Network monitoring SSH health checks triggering quiet mode repeatedly Monitoring tool credentials are wrong or SSH keys mismatched — each poll generates a failed login Add monitoring tool IP to ADMIN-BYPASS (prevents it locking out others). Fix monitoring credentials. Consider switching to SNMPv3 — SNMP is not subject to login security controls. See SNMP Overview.
Quiet mode appears stuck Quiet mode timer in show login does not count down to zero Ongoing attack attempts during quiet mode may reset the timer on some IOS versions Wait for all attack connections to stop. Clear counters: clear login failures. In some IOS versions, quiet mode ends only when the block-for timer expires with no new triggering events.

Key Points & Exam Tips

  • login block-for [sec] attempts [n] within [sec] is the core command — it triggers quiet mode when n failures occur within the observation window, blocking all new non-whitelisted logins for the specified duration.
  • login delay [sec] forces a mandatory pause after every login attempt (successful or failed) — throttles automated tools regardless of connection speed. Applies globally to all lines, including VTY and console.
  • The quiet-mode bypass ACL must be created and linked before enabling login block-for. Without it, an attacker-triggered quiet mode locks out all admins and the only recovery path is the physical console. See Standard ACLs and Named ACLs.
  • Quiet mode does not affect the console line — console is a physical, non-network connection and cannot be blocked by quiet mode. The console is always the emergency recovery path. See Console & VTY Line Configuration for console security.
  • login on-failure log generates %SEC_LOGIN-4-LOGIN_FAILED messages. login on-success log generates %SEC_LOGIN-5-LOGIN_SUCCESS. The %SEC_LOGIN-1-QUIET_MODE_ON message (severity 1 — Alert) fires when quiet mode triggers — should cause immediate SIEM alerts. See Syslog for severity levels.
  • Quiet mode is a global lockout — it does not track which source triggered it. During quiet mode, ALL sources not in the bypass ACL are blocked — even sources that have made no prior failed attempts.
  • show login is the primary verification command — shows current mode, countdown timer, failure count in the observation window, and all configured parameters. Always verify with this command after configuration.
  • show login failures provides per-source-IP attribution — the most useful post-incident command showing which IP triggered quiet mode, how many attempts it made, and the timestamp of the last attempt.
  • Login security and VTY ACLs are complementary layers — the VTY ACL restricts access to known-good source IPs; login security protects against failures from within those permitted sources. See Console & VTY Line Configuration.
  • On the CCNA exam: know the full login block-for syntax (three parameters: block duration, attempt count, observation window), the purpose of the quiet-mode ACL, what happens without it, and how to interpret show login output in both normal and quiet mode.
  • For the complete device hardening picture, combine these controls with strong passwords and MOTD banners, SSH (never Telnet), and centralised authentication via AAA.
Next Steps: Login brute-force protection is now active. For reviewing SEC_LOGIN syslog entries and QUIET_MODE_ON alerts, see show logging and Syslog Server Configuration. For the SSH configuration these controls are protecting, revisit SSH Configuration. For centralised AAA adding a further authentication layer, see AAA with TACACS+ and Login Authentication Methods. For the VTY line configuration that works alongside these controls, see Console & VTY Line Configuration.

TEST WHAT YOU LEARNED

A router has login block-for 90 attempts 4 within 20. An attacker sends 4 failed logins in 15 seconds. What happens next?

Correct answer is D. The within [n] parameter defines the maximum observation window — quiet mode triggers as soon as the failure count is reached, regardless of how quickly the failures accumulated. 4 failures in 15 seconds still exceeds the threshold of 4 failures within 20 seconds. Quiet mode activates immediately on the 4th failure and lasts for the full block-for duration of 90 seconds. The lockout is global, not per-source — ALL new non-whitelisted connections are refused, not just the attacking IP. This is why the quiet-mode bypass ACL is critical.

Why must the quiet-mode bypass ACL be created and bound before enabling login block-for?

Correct answer is B. This is an operational safety concern, not a technical IOS restriction. IOS accepts login quiet-mode access-class at any time — but if quiet mode is triggered before the bypass ACL is linked, every VTY connection attempt is refused. The administrator cannot SSH in to add the bypass ACL because SSH connections are blocked by quiet mode. The console remains accessible, but in remote or datacentre environments, physical console access may not be immediately available. The correct deployment sequence: (1) create bypass ACL, (2) bind with login quiet-mode access-class, (3) enable login block-for. See Console & VTY Line Configuration.

Attacker at 192.168.10.99 triggers quiet mode. ADMIN-BYPASS permits only 192.168.10.5. A second host at 192.168.10.77 that has never failed a login now tries SSH. What happens?

Correct answer is A. Quiet mode is a global lockout — it does not track which source triggered it and does not restrict the lockout to that source. During quiet mode, ALL connection attempts from sources not permitted by the quiet-mode ACL are refused. 192.168.10.77 has made zero prior failed attempts, but that is irrelevant — quiet mode does not distinguish attackers from innocent bystanders. The only bypass is the quiet-mode ACL. Since 192.168.10.77 is not in ADMIN-BYPASS, its connection is refused. This global behaviour is intentional — quiet mode must comprehensively block connections to be effective against distributed attacks using multiple source IPs.

Does login delay 3 apply to successful logins? Does the quiet-mode bypass ACL exempt whitelisted IPs from the delay?

Correct answer is C. login delay is a global, unconditional control. It applies to every login attempt on every line (VTY and console), regardless of success or failure, and regardless of whether the router is in normal or quiet mode. Even the admin workstation (whitelisted in ADMIN-BYPASS) experiences the configured delay. The quiet-mode bypass ACL serves one purpose only: allowing the TCP connection to reach the login prompt during quiet mode. It does not grant any exemption from the delay. In practice, a 2-3 second delay on a successful login is imperceptible to a human engineer but catastrophic for automated tools relying on rapid submission of thousands of attempts.

show login shows quiet mode active with 73 seconds remaining. The admin at 192.168.10.5 (in ADMIN-BYPASS) needs to log in immediately. What should they do?

Correct answer is D. The quiet-mode bypass is not a future permission that activates after the timer — it is active right now. When the router receives a new connection from 192.168.10.5 during quiet mode, IOS checks ADMIN-BYPASS before applying the quiet-mode block. Since 192.168.10.5 matches the permit entry, the connection proceeds to the login prompt normally. The 2-second delay (from login delay 2) still applies after each attempt, but there is no TCP connection refusal. This is exactly why the bypass ACL is mandatory — administrators responsible for resolving a security incident must never be locked out by the very mechanism protecting the device.

What does %SEC_LOGIN-1-QUIET_MODE_ON indicate and why is its severity significant for security operations?

Correct answer is A. Syslog severities run 0 (Emergency) through 7 (Debug). Severity 1 (Alert) means "immediate action needed." The %SEC_LOGIN-1-QUIET_MODE_ON message is generated at the exact moment quiet mode activates — it is a real-time alert that an active brute-force attack succeeded in meeting the failure threshold. The message contains the attacking source IP, the username last attempted, and the exact timestamp. Lower-severity %SEC_LOGIN-4-LOGIN_FAILED messages (severity 4 — Warning) are informational. The severity 1 quiet-mode event demands investigation and should trigger page/ticket/email alerts in any properly configured monitoring platform. See show logging to view these messages.

After configuring brute-force protection, a monitoring system's SSH health checks keep triggering quiet mode every few minutes. What is happening and how is it fixed?

Correct answer is C. This is a common operational scenario. Monitoring platforms poll device availability every 30-60 seconds via SSH — if credentials are misconfigured, each poll is a failed authentication. With a tight block-for threshold (e.g., 3 failures in 15 seconds), a monitoring tool polling every 10 seconds with wrong credentials hits the trigger in 30 seconds and locks out everyone. The immediate fix is to add the monitoring tool's IP to ADMIN-BYPASS — this prevents the tool's failures from triggering quiet mode that locks out human admins. The correct long-term fix is repairing the monitoring credentials. The ideal architecture switch is SNMPv3 for monitoring — SNMP queries are not login events and are entirely unaffected by login security controls. See SNMP Overview.

What does show login failures show that show login does not, and when is each most useful?

Correct answer is B. show login is the operational health command — it shows whether the system is in normal or quiet mode, how much time remains in quiet mode, how many failures have occurred in the current observation window, and confirms all configured parameters are active. Use it routinely to verify configuration and check current state. show login failures is the forensic command — it maintains a per-source-IP table of every host that has generated failures, with granular counts and the timestamp of the most recent attempt. After quiet mode has been triggered, this command immediately identifies which IP was attacking and how aggressive the attack was. Together with show logging (which shows the usernames attempted), these two commands provide comprehensive post-incident data without requiring any external logging infrastructure.

Does quiet mode triggered by login block-for affect the console line? Why or why not?

Correct answer is D. The login block-for mechanism operates at the network connection level — it blocks TCP connections to VTY lines (SSH and Telnet). The console port is a direct serial or USB connection to the device's hardware — it is not a network connection and cannot be blocked by any software mechanism designed to protect network access. During quiet mode, the console is completely unaffected: the login prompt appears, authentication proceeds normally (typically local), and the engineer can log in. This is the designed behaviour and is why: (1) console access is the emergency recovery path when VTY is blocked, and (2) console authentication should always use local-only methods, never TACACS+/RADIUS, ensuring physical access never depends on a network service. See Console & VTY Line Configuration.

What is the complete minimum configuration for brute-force protection that blocks after 5 failures in 30 seconds, enforces 2-second delay, keeps admin at 192.168.10.5 unblocked, and logs all failures?

Correct answer is C. Option A is missing the quiet-mode ACL entirely — admin will be locked out during quiet mode. Option B references ADMIN-BYPASS in login quiet-mode access-class but the ACL itself is never defined — IOS accepts the command but the ACL does not exist, so no bypass is actually configured. Option D uses access-class ADMIN-BYPASS in which is a VTY line command (applied under line vty 0 4 — see Console & VTY Line Configuration) that filters which IPs can connect to VTY — a completely different mechanism from the quiet-mode bypass. Option C is the only complete answer: (1) defines ADMIN-BYPASS with the admin IP, (2) configures all four controls, (3) links the ACL correctly with login quiet-mode access-class. The ACL definition must precede the reference for the bypass to function.

Related Topics & Step-by-Step Tutorials

Related concepts and next steps:

Back to Home