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 → try "password2" → fail → ...
             [immediate retry, no delay, no lockout, no alert]
             Unlimited attempts at wire speed

  With all four controls:
  Attacker → try "password1" → fail → [2 sec delay: login delay 2]
           → try "password2" → fail → [2 sec delay]
           → try "password3" → fail (3rd in window)
           ↓ 5 failures in 30 seconds → QUIET MODE triggered
  [ALL new login connections BLOCKED for 120 seconds]
  [Syslog: %SEC_LOGIN-1-QUIET_MODE_ON]
  [Admin 192.168.10.5 still permitted via ADMIN-BYPASS ACL]

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:

      [Admin PC: 192.168.10.5]         [Attacker: 192.168.10.99]
            |                                    |
            ‘————————————————‘———————————’
                             |
                      192.168.10.0/24
                             |
                       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

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

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

A. Nothing — the attack must continue for the full 20 seconds before the threshold counts B. Quiet mode triggers for 20 seconds — the within value doubles as the block duration C. Only the attacking IP (source) is blocked for 90 seconds — other sources can still attempt login D. Quiet mode triggers immediately on the 4th failure — the threshold is a count, not a time fill. 4 failures within the 20-second window is met at 15 seconds. All non-whitelisted login connections are blocked for 90 seconds regardless of source

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.

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

A. IOS returns a syntax error if login quiet-mode access-class is entered after login block-for B. If quiet mode triggers before the bypass ACL is configured, all VTY access is blocked — including the administrator trying to add the ACL. The only remaining path is the physical console. Creating the ACL first guarantees the admin bypass exists before any lockout can occur C. IOS requires the ACL to be compiled before block-for can reference it — a parser sequencing requirement D. The order is irrelevant — both commands can be entered in any sequence with identical results

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.

3. 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?

A. The connection from 192.168.10.77 is refused — quiet mode is a global lockout. It does not track which source triggered it. ALL sources not in the quiet-mode bypass ACL are refused during quiet mode, regardless of their prior failure history B. 192.168.10.77 is permitted — quiet mode only blocks the specific IP that triggered it C. 192.168.10.77 gets 2 attempts before being individually blocked D. 192.168.10.77 is permitted because it has no prior failed attempts on record

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.

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

A. The delay only applies to failed attempts — successful logins proceed without any delay B. The delay applies only during quiet mode — normal mode connections proceed immediately C. The delay applies to ALL login attempts — successful and failed — at all times. The quiet-mode bypass ACL only controls whether the TCP connection is allowed through during quiet mode — it does not exempt whitelisted IPs from the login delay. Even the admin at 192.168.10.5 experiences the 3-second pause after each attempt D. The delay only applies to VTY lines — console logins are exempt regardless of setting

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.

5. `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?

A. They cannot — quiet mode blocks all sources until the timer expires, including ADMIN-BYPASS entries B. They must wait 73 seconds then connect immediately before another attack triggers quiet mode again C. They must use the console — SSH is completely disabled during quiet mode D. The admin at 192.168.10.5 can SSH right now — the quiet-mode bypass ACL permits this IP to reach the login prompt during active quiet mode. The 2-second login delay still applies, but the TCP connection is not refused. This is the entire purpose of the bypass ACL

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.

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

A. It indicates quiet mode just activated — the configured failure threshold was met, confirming an active brute-force attack. Severity 1 (Alert) is the second-highest syslog priority, demanding immediate attention. Any SIEM should trigger an immediate alert on this message. It includes the attacking source IP, username attempted, and timestamp — providing instant attack attribution B. It indicates quiet mode is configured but not yet triggered — severity 1 is Cisco's default for all login security events C. It confirms the quiet-mode ACL loaded successfully — severity 1 means the ACL is syntactically valid D. It confirms login delay is active — generated each time a delay is applied to a login attempt

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.

7. 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?

A. The monitoring system's SSH key expired — renew the key on the router B. Increase the block-for duration — 300 seconds gives the monitoring system more time between polls C. The monitoring tool has wrong credentials or a key mismatch — each poll generates a failed authentication. Rapid polling at short intervals accumulates failures that exceed the threshold. Fix: add the monitoring system's IP to ADMIN-BYPASS (prevents it locking out others) AND correct the monitoring credentials. Long-term: switch monitoring to SNMPv3 which is unaffected by login security D. Set login delay 0 — the delay causes the monitoring tool to time out and retry, creating the extra failures

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.

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

A. show login failures displays the quiet-mode ACL contents — show login only names the ACL B. show login failures provides per-source-IP forensic detail — each attacking IP, total failures, consecutive failures, failures in the last window, and the timestamp of the last attempt. show login shows aggregate status and mode. Use show login for real-time health checks; use show login failures after an incident to identify the attacking IP and attack timeline C. show login failures shows usernames attempted — show login only shows counts D. show login failures shows the block-for configuration — show login only shows current mode

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.

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

A. Yes — quiet mode blocks all access including the physical console B. Yes — but only if no quiet-mode ACL is configured; with ADMIN-BYPASS the console is exempt C. No — but only because the console uses a different authentication method that bypasses quiet mode checking D. No — quiet mode blocks new incoming network connections (VTY/SSH/Telnet). The console is a direct physical serial or USB connection, not a network connection. It cannot be blocked by a mechanism that operates at the network layer. Console login always works regardless of quiet mode state — this is the emergency recovery path when VTY is fully blocked. See Console & VTY Line Configuration.

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.

10. 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?

login block-for 60 attempts 5 within 30
login delay 2
login on-failure log

(Missing quiet-mode ACL — admin will be locked out) B.

login block-for 60 attempts 5 within 30
login delay 2
login quiet-mode access-class ADMIN-BYPASS
login on-failure log

(References ADMIN-BYPASS but never defines the ACL) C.

ip access-list standard ADMIN-BYPASS
 permit host 192.168.10.5
!
login block-for 60 attempts 5 within 30
login delay 2
login quiet-mode access-class ADMIN-BYPASS
login on-failure log

login block-for 60 attempts 5 within 30
login delay 2
access-class ADMIN-BYPASS in
login on-failure log

(Uses VTY line command instead of quiet-mode binding)

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.

Back to Home