I was a victim of SSH brute force attacks, which I covered here. As a result, I discovered a great solution without using SSH keys. As another layer of security, I added two-factor authentication to my server. A few years ago, I wondered if there was a solution in Cisco IOS. I discovered a security feature called login enhancements or login block. Let’s look at how it can help defend from SSH brute force attacks by enabling this feature.
What is login block?
It is a Cisco IOS feature that allows users to configure the device to block login attempts automatically. It does this by monitoring login attempts and activates when a possible denial of service attack (DoS) is detected.
This feature has two options: login block and login delay. By enabling this feature, you can slow down brute force attacks and protect from DoS attacks.
Preparation
This article assumes that your device has the configuration for successful SSH connections. If not, make sure to configure it first if you want to follow along.
Before we configure the login enhancement, let’s enable the feature that generates syslogs on failure and successful logins. To enable the logging feature, issue the commands as shown below.
R1(config)#login on-failure log R1(config)#login on-success log
Launching SSH dictionary attack
I used Hydra in Kali Linux to launch the attack, as can be seen below. In the interest of time, the selected password is in the upper section of the RockYou wordlist.
andrew@kali:~$ hydra -l bob -P /usr/share/wordlists/rockyou.txt ssh://192.168.8.236 -t 64 Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway). Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2021-01-08 14:19:33 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [DATA] max 64 tasks per 1 server, overall 64 tasks, 14344399 login tries (l:1/p:14344399), ~224132 tries per task [DATA] attacking ssh://192.168.8.236:22/ [22][ssh] host: 192.168.8.236 login: bob password: internet 1 of 1 target successfully completed, 1 valid password found [WARNING] Writing restore file because 61 final worker threads did not complete until end. [ERROR] 61 targets did not resolve or could not be connected [ERROR] 0 target did not complete Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2021-01-08 14:19:48
If we check back on our Cisco device and check the log, we can see the failed authentication attempts.
R1# *Jan 8 22:25:12.295: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] at 22:25:12 UTC Fri Jan 8 2021 *Jan 8 22:25:12.302: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] at 22:25:12 UTC Fri Jan 8 2021 *Jan 8 22:25:12.441: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] at 22:25:12 UTC Fri Jan 8 2021 <-- Output omitted for brevity --> *Jan 8 22:25:17.000: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: bob] [Source: 192.168.8.240] [localport: 22] at 22:25:17 UTC Fri Jan 8 2021
While the attack is happening, I attempted to log into the router but was unsuccessful. Since Hydra used up all the virtual teletype (VTY) lines during the attack, the router refused my connection.
MacBook-Pro:~ Andrew$ ssh user1@192.168.8.236 ssh: connect to host 192.168.8.236 port 22: Connection refused
Configuration
Now, we’re ready to configure the login block feature on our Cisco IOS device. Issue the command to enable the feature, as shown below.
R1(config)#login block-for 180 attempts 10 within 10
The command above configures the device to block any further login attempts for 180 seconds, where 10 or more failed login attempts occur within 10 seconds.
Unfortunately, I don’t have the best numbers for you. You will have to figure out the best number for your environment.
Testing
Let’s test what happens when we exceed the threshold by launching another dictionary attack. Use the same command earlier, as can be seen above.
Eventually, Cisco IOS recognizes the attack and enters the quiet mode period.
R1# <-- Omitted output for brevity --> *Jan 9 01:55:13.418: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] at 01:55:13 UTC Sat Jan 9 2021 *Jan 9 01:55:13.419: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 1 secs, [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 01:55:13 UTC Sat Jan 9 2021 *Jan 9 01:55:13.499: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 0 secs, [user: bob] [Source: 192.168.8.240] [localport: 22] [Reason: Login Authentication Failed] [ACL: sl_def_acl] at 01:55:13 UTC Sat Jan 9 2021 *Jan 9 01:55:17.529: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 192.168.8.240(57780) -> 0.0.0.0(22), 1 packet *Jan 9 01:56:24.099: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 192.168.8.205(64248) -> 0.0.0.0(22), 1 packet <-- Omitted output for brevity --> *Jan 9 01:56:02.235: %SEC-6-IPACCESSLOGRL: access-list logging rate-limited or missed 1711 packets
During the quiet period, the IOS device will block all login attempts. As can be seen below, the router rejected my attempt to connect via SSH.
MacBook-Pro:~ Andrew$ ssh user1@192.168.8.236 ssh: connect to host 192.168.8.236 port 22: Connection refused
If we analyze the IOS log, the router blocked my SSH connection.
*Jan 9 01:56:24.099: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 192.168.8.205(64248) -> 0.0.0.0(22), 1 packet
How does the IOS device even do this? As it enters the quiet mode, it also creates and applies an extended ACL called sl_def_acl to the VTY lines.
R1#sh ip access-list
Extended IP access list sl_def_acl
10 deny tcp any any eq telnet log
20 deny tcp any any eq www log
30 deny tcp any any eq 22 log (204 matches)
40 permit ip any any log
R1#sh run | sec line vty
line vty 0 4
access-class sl_def_acl in
<-- Output omitted for brevity -->
line vty 5 59
access-class sl_def_acl in
<-- Output omitted for brevity -->
Note
Cisco IOS hides this ACL in the running configuration.
With our current configuration, the only way we can log into the device is via the console. Unfortunately, logging in via console is not always possible in the production environment. That said, this configuration will cause DoS to authorized users. There must be another way.
Enter quiet mode ACL
While quiet mode access-class is optional, it is a recommended configuration when enabling the login block feature. Essentially, you create an allowed list that can connect to the IOS device when it enters quiet mode.
The first step is to create an ACL. It can be standard or extended ACL. For this purpose, I opted for standard ACL.
R1(config)#access-list 2 permit 192.168.8.53
The second and final step is to associate the ACL with the login block feature.
R1(config)#login quiet-mode access-class 2
At this point, we’re ready to test it out. Let’s launch another dictionary attack by using the same command, as can be seen above.
When the IOS device enters the quiet mode, nobody can initiate a connection except for the host defined in access-list 2.
MacBook-Pro:~ Andrew$ ssh user1@192.168.8.236 ssh: connect to host 192.168.8.236 port 22: Connection refused andrew@ubuntu:~$ ssh user1@192.168.8.236 Password: R1>exit Connection to 192.168.8.236 closed. *Jan 9 03:52:08.781: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: user1] [Source: 192.168.8.53] [localport: 22] at 03:52:08 UTC Mon Jan 9 2021 R1#sh run | sec line vty line vty 0 4 access-class 2 in <-- Output omitted for brevity -->
Additional information
If you have an existing management ACL associated with the VTY lines, IOS will replace it as it enters the quiet mode. When the timer expires, it will automatically revert the changes.
Hosts that are part of the quiet mode ACL can still trigger the login block feature. However, since they are on the allowed list, then they are still allowed to connect. With this in mind, you may want a different set of IPs or networks in the quiet mode ACL compared to your standard list.
Final Thoughts
Configuring the login block feature may or may not be necessary, depending on one’s environment. You have to evaluate the existing security controls in place and work with your security team to satisfy their requirements or adhere to the security policies.
At a minimum, you would want to create and apply an ACL to the VTY line(s). It limits the number of connections to the device from trusted IPs or networks. However, in this day and age where Zero Trust gets thrown into the conversation, then you’d want even more security controls.
A possible solution is adding two-factor authentication (2FA) to your AAA server or enabling SSH public key. I’ve written articles about adding 2FA to tac_plus and FreeRADIUS server, so check them out if you’re interested.
A lot of security professionals believe in a defense in depth strategy. With that in mind, you may want to think about other security controls that you can implement without hindering usability.
You might like to read
BUY ME COFFEE ☕
