How to prevent log-in (username & password) attacks on an SRX, especially attacks such as Brute Force attacks, which involve systematically checking all possible keys until the correct key is found for accessing the device.

Malicious users sometimes try to log into a secure device by guessing an authorized user's account password. The goal is to protect a device from malicious users by locking out a user account after a number of failed authentication attempts.

Junos provides multiple options for blocking Telnet and SSH Brute Force log-in attacks on SRX devices.

Creating a Log-In Attempt Limit

To help prevent Brute Force attacks, set an attempt limit for users to make a mistake in entering their username or password. If the user exceeds the log-in limit, the system will either lock him out or prevent any future log-in attempts for a set amount of time.

Set the following options according to your requirements and commit the changes:

backoff-threshold: Sets the threshold for the number of failed log-in attempts on the device before the user experiences a delay when attempting to re-enter a password. When a user incorrectly logs into the device and hits the threshold of failed log-in attempts, the user experiences a delay (set in the backoff-factor statement) before he can attempt to log into the device again. The valid range for this option is 1 to 3 attempts.

backoff-factor: Sets the length of the delay, in seconds, after each failed log-in attempt. When a user incorrectly logs into the device, the user must wait the configured amount of time before he can attempt to log into the device again. The length of the delay increases by the backoff-factor value for each subsequent log-in attempted after the value specified in the backoff-threshold statement is reached. The valid range for this option is 5 to 10 seconds.

tries-before-disconnect: Sets the maximum number of times the user is allowed to enter a password in an attempt to log into the device through SSH or Telnet. When the user reaches the maximum number of failed log-in attempts, he is locked out of the device. The user must wait the configured amount of minutes in the lockout-period statement before he can attempt to log back into the device. The tries-before-disconnect statement must be set when the lockout-period statement is set; otherwise, the lockout-period statement is meaningless. The valid value for this option is 1 to 10 attempts.

lockout-period: Sets the amount of time, in minutes, that the user must wait before he can attempt to log into the device after being locked out due to the number of failed log-in attempts specified in the tries-before-disconnect statement. The lockout-period must be greater than zero. The valid range for this option range is 1 to 43,200 minutes.

CLI Quick Configuration

To quickly configure this section of the example:

1. copy the following commands:
   
   set system login retry-options tries-before-disconnect 5
set system login retry-options backoff-threshold 3
set system login retry-options backoff-factor 10
set system login retry-options lockout-period 4
2. Paste them into a text file, remove any line breaks, change any details necessary to match your network configuration,
3. Then copy and paste the commands into the CLI at the [edit] hierarchy level.

Verifying Log-In Attempt Settings

The system login configuration example below is used to show how to verify log-in attempt settings.
 

1. Log into the device with the wrong credentials (username: space, plus incorrect password).

The system responds as follows:

• Attempt 1: Failed. System immediately prompts for a second attempt.
• Attempt 2: Failed. System immediately prompts for a third attempt.
• Attempt 3: Failed. System introduces a delay of 10 seconds before prompting for a fourth attempt.
• Attempt 4: Failed. System introduces a delay of 20 seconds before prompting for a fifth attempt.
• Attempt 5: Failed. Access to the device is locked out for 4 minutes.

2. Log into the device as root or any other user and run the show system login lockout command.

user1@host1> show system login lockout 
User      Lockout start               Lockout end
space  2014-03-25 10:28:42 UTC   2014-03-25 10:32:42 UTC

The system is locked out from 10:28:42 to 10:32:42, exactly four minutes.

Notes

• This solution can be used to block Brute Force attacks on SRX management IPs.
• This solution cannot block Brute Force attacks on "through" sessions on an SRX device (that is, this solution is valid for traffic coming to the device, but not for traffic passing through the device).

04/20/2026 - Updated Category

• Example: Configuring System Retry Options
• Configuring Password Retry Limits for Telnet and SSH Access