Login Block and Rate Limiting

Lab Objectives

• Configure local user authentication and secure VTY access on R1 (use SSH and local login).
• Implement brute-force protection with login block-for, and slow down attempts with login delay and quiet-mode.
• Verify the configuration and understand how these mechanisms interact to harden device access.

Note: Use the BASE LAB TOPOLOGY below for all tasks. All interface IPs and names in the commands and explanations use the exact addresses shown.

                    [Internet]
                   203.0.113.1
                        |
                   R1 (Gateway)
                  Gi0/0: 10.10.10.1
                  Gi0/1: 10.10.20.1
                  Gi0/2: 10.10.30.1
                  /     |     \
               R2      R3      R4
   Gi0/0: 10.10.10.2   |   Gi0/0: 10.10.30.2
   Gi0/1: 10.10.40.1   |
              /  \      |
           S1    S2    S3
          /  \    |   /  \
        PC1  PC2 PC3 PC4  PC5

IP references you will use:

• R1 Gi0/0 — 10.10.10.1 (towards R2)
• VLANs on switches: VLAN10 192.168.1.0/24, VLAN20 192.168.2.0/24, VLAN30 192.168.3.0/24
• Public/Internet simulated as 203.0.113.0/24

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Configure SSH and local user for VTY access

Create a local administrative user named admin with secret password Lab@123. Configure the vty lines to accept only SSH, require local authentication, and set a reasonable exec-timeout.

Parameters (do not show commands here): Username = admin, secret = Lab@123, VTY: transport input = ssh, login = local, exec-timeout = 10 minutes (10 0).

Task 2: Configure login block-for

Enable global brute-force protection so the device will block further login attempts for 120 seconds if there are 3 failed login attempts within 60 seconds.

Parameters: block duration = 120 seconds, attempts = 3, within = 60 seconds.

Task 3: Configure login delay and quiet-mode

On the VTY lines set a login delay of 3 seconds (adds delay between successive login attempts) and enable quiet-mode globally to reduce information given to unauthenticated hosts.

Parameters: login delay = 3 seconds on line vty 0 4; enable login quiet-mode globally.

Think About It: Why is it useful to combine a temporary block (login block-for) with a per-attempt delay (login delay) and quiet-mode? Consider attacker behavior, impact on legitimate admins, and defense-in-depth.

---

Lab Solution

Task 1 Solution: Configure SSH and local user for VTY access

What we are doing: We create a local admin account and force SSH + local authentication on the VTY lines. SSH provides encrypted management; local authentication ensures the device checks the local username database. exec-timeout reduces risk from unattended sessions.

R1(config)# username admin privilege 15 secret Lab@123
R1(config)# ip domain-name lab.nhprep.com
R1(config)# crypto key generate rsa modulus 2048
% Generating 2048 bit RSA keys, keys will be non-exportable...
R1(config)# line vty 0 4
R1(config-line)# transport input ssh
R1(config-line)# login local
R1(config-line)# exec-timeout 10 0
R1(config-line)# exit

What just happened:

• username admin privilege 15 secret Lab@123 — creates a local administrative user named admin with secret password Lab@123. This is used by login local.
• ip domain-name lab.nhprep.com — needed before generating RSA keys (SSH requires a domain name for key generation).
• crypto key generate rsa modulus 2048 — generates RSA key pair for SSH; 2048-bit is a modern recommended modulus.
• line vty 0 4 — enters configuration for virtual terminal lines (remote management).
• transport input ssh — disables Telnet; accepts only SSH connections.
• login local — uses local username database for login authentication.
• exec-timeout 10 0 — automatically logs out idle sessions after 10 minutes (10 minutes 0 seconds).

Verify:

R1# show running-config | section username
username admin privilege 15 secret 5 $1$AbCd$...   ! (secret will appear encrypted)
R1# show running-config | include ip domain-name
ip domain-name lab.nhprep.com
R1# show running-config | section line vty
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0

Expected sample outputs above show the username, domain, and vty settings.

---

Task 2 Solution: Configure login block-for

What we are doing: We configure a global defense that, when a remote source causes 3 failed login attempts within 60 seconds, the device blocks the source for 120 seconds. This mitigates automated brute-force attempts by making them inefficient.

R1(config)# login block-for 120 attempts 3 within 60

What just happened:

• login block-for 120 attempts 3 within 60 — globally instructs IOS to block further login attempts from an offending source for 120 seconds if there are 3 failed login attempts observed within any 60-second window. Blocking slows or halts automated brute-force tools which rely on rapid repeated attempts.

Verify:

R1# show running-config | include login block-for
login block-for 120 attempts 3 within 60
R1# show login
Login status:
  login block-for 120 attempts 3 within 60
  (Other statistics follow depending on device and IOS version)

Expected output shows the configured block rule. During an actual attack, show login will report blocked sources and counters.

Tip: If you are unexpectedly locked out after triggering the block, wait the configured block duration (120 seconds) or access the device from a different IP that isn’t blocked.

---

Task 3 Solution: Configure login delay and quiet-mode

What we are doing: We add a per-login delay on vty lines and enable quiet-mode globally to reduce feedback to unauthenticated clients. The delay increases the time between attempts, making brute-force slower even if the attacker rotates IPs. Quiet-mode avoids giving detailed failure messages that attackers can use.

R1(config)# login quiet-mode
R1(config)# line vty 0 4
R1(config-line)# login delay 3
R1(config-line)# exit

What just happened:

• login quiet-mode — enables reduced feedback behavior for login attempts. In practice, quiet-mode suppresses some login messages and can limit the information that unauthenticated hosts receive (reducing reconnaissance value).
• line vty 0 4 / login delay 3 — sets a 3-second delay applied to each login attempt on VTY lines. This means after a failed attempt the line will pause before presenting the prompt again, slowing attackers.

Verify:

R1# show running-config | include login quiet-mode
login quiet-mode
R1# show running-config | section line vty
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0
 login delay 3

The output shows quiet-mode in the global config and login delay 3 under the vty lines.

Real-world context: In production, combining these controls — quiet-mode to hide information, login delay to slow attempts, and login block-for to temporarily block repeat offenders — provides layered protection without immediately denying legitimate administrators who might mistype passwords occasionally.

---

Troubleshooting Scenario

Scenario: VTY access locked after testing

Symptom: After purposefully generating failed logins to test protections, you cannot log in remotely via SSH to R1. Ping and network reachability are fine.

Your task: Find and fix the issue.

Hint: Check for a global block configuration that might be active and consider whether your test host IP has been blocked.

Solution:

1. Verify the block rule and current status:

R1# show login

2. If you confirm the block rule is causing the lockout and you are managing the device from the blocked IP, either wait 120 seconds for the block to expire or remove the rule temporarily from the running configuration:

R1(config)# no login block-for 120 attempts 3 within 60

3. Alternatively, connect via the console or from an IP not blocked, then adjust thresholds (for example: reduce block duration or increase allowed attempts) or add an admin maintenance source that won't be blocked.

Explanation: The no login block-for ... command removes the global block configuration. In production, rather than removing protections, adjust thresholds conservatively or add management-access controls (such as an access-list allowing the known admin IPs) to avoid accidental lockouts.

---

Verification Checklist

• Local admin user admin exists and is configured with secret Lab@123.
• VTY lines accept only SSH and use login local.
• login block-for 120 attempts 3 within 60 is present in global config.
• login delay 3 is set on line vty 0 4.
• login quiet-mode is enabled.

Common Mistakes

Symptom	Cause	Fix
Cannot SSH to device after testing	You triggered the login block and your IP is currently blocked	Wait block duration (120s) or remove rule with no login block-for ... from console or another IP
Still able to telnet into device	transport input telnet still allowed on vty	Change to transport input ssh under line vty 0 4
Users experiencing excessive login delay	login delay set too high on VTY lines	Lower the value (e.g., login delay 1) or remove (no login delay)
Too many legitimate admin lockouts	Thresholds too strict (low attempts or long block time)	Adjust attempts and block-for values upward to balance security and availability

Challenge Task

Allow only the Management subnet (192.168.3.0/24) to reach the router's VTY lines while keeping the brute-force protections in place. Use an access-list and line vty access-class to enforce this. Do not copy commands — design and apply them yourself, test from a host in 192.168.3.0/24, and verify remote access and that hosts outside the management subnet are denied the login prompt.

Important: Be careful—if you apply an access-class incorrectly, you may block yourself. Always ensure console access or an alternate management path is available before applying restrictive access controls.