SRX ssh brute-force countermeasures

It’s always a good idea to secure and also harden your SRX in case it is reachable via the Internet.
Today I labbed a bit to see if this Filter actually works.

 

For this Lab we setup the “system login retry-options”:

Now to the Options we have:

tries-before-disconnect: Sets the maximum number of times the user is allowed to enter a password to attempt to log in to the device through SSH or Telnet. When the user reaches the maximum number of failed login attempts, the user is locked out of the device.

backoff-threshold: Sets the threshold for the number of failed login attempts on the device before the user experiences a delay when attempting to reenter a password.

backoff-factor: Sets the length of delay in seconds after each failed login attempt. When a user incorrectly logs in to the device, the user must wait the configured amount of time before attempting to log in to the device again.

lockout period: Sets the amount of time in minutes before the user can attempt to log in to the device after being locked out due to the number of failed login attempts specified in the tries-before-disconnect statement.
You can read the full explanations here:
https://www.juniper.net/documentation/en_US/junos/topics/example/system-retry-options-configuring.html

 

 

After that (to see it more easy), we create a syslog-file for just the ssh failed attempts:

What this does is basically telling your SRX to log all failed ssh-attempts to a file called ssh-logs.

This way, your SRX is ready to take on almost every script-kiddie brute-force attack and logs every failed attempt.

Be sure to check the file from time to time – and remember: change your passwords from time to time and use at least 64 letters and numbers, hash-signs, virgin-blood and so on –> you get the idea right? 😉

 

Leave a Comment

Captcha * Time limit is exhausted. Please reload CAPTCHA.