• Skip to main content
  • Skip to footer

Andrew Roderos

Networking and Security

  • Blog
  • Resources
    • Book List
    • Freebies
  • About
  • Contact

Defending against SSH brute force attacks

01/11/2021 by Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

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.

View this post on Instagram

A post shared by Andrew Roderos (@andrewroderos)

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.

Related: Attacking Cisco IOS device

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

Attacking Cisco IOS device
Securing Cisco IOS passwords
Attacking HSRP

BUY ME COFFEE ☕

Did you find this content useful? If so, show your appreciation by buying me a coffee!



  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Security Tagged With: Cisco, Cybersecurity, Information Security, InfoSec, IOS, Network Security

About Andrew Roderos

I am a network security engineer with a passion for networking and security. Follow me on Twitter, LinkedIn, and Instagram.

Footer

WANT TO REACH ME?

Let’s talk!

CONTACT ME

Copyright © 2019–2023 · Andrew Roderos · All Rights Reserved · Privacy Policy · Terms of Use