Routing

Hi all,

Based on this url https://kb.juniper.net/InfoCenter/index?page=content&id=KB20853&actp=METADATA   supposedly it should resolve the issue if i'm using junos version updated. But why during pentest testing, my other department still see this issue on MX480 that user junos ver 17.x?

Appreciate if someone can explain.

As the KB states, it's just the order of ciphers which has been changed... if you connect with a client which only suggest a cbc cipher it will still be selected.

You can alter the allowed ssh ciphers by define a smaller subset under 'system services ssh' as seen below. There you can just limit to CTR ciphers.

user@device# set system services ssh ciphers ?
Possible completions:
  3des-cbc             Triple DES in CBC mode
  [                    Open a set of values
  aes128-cbc           128-bit AES with Cipher Block Chaining
  aes128-ctr           128-bit AES with Counter Mode
  aes128-gcm@openssh.com  128-bit AES with Galois/Counter Mode
  aes192-cbc           192-bit AES with Cipher Block Chaining
  aes192-ctr           192-bit AES with Counter Mode
  aes256-cbc           256-bit AES with Cipher Block Chaining
  aes256-ctr           256-bit AES with Counter Mode
  aes256-gcm@openssh.com  256-bit AES with Galois/Counter Mode
  arcfour              128-bit RC4 with Cipher Block Chaining
  arcfour128           128-bit RC4 with Cipher Block Chaining
  arcfour256           256-bit RC4 with Cipher Block Chaining
  blowfish-cbc         128-bit Blowfish with Cipher Block Chaining
  cast128-cbc          128-bit CAST with Cipher Block Chaining
  chacha20-poly1305@openssh.com  ChaCha20 stream cipher and Poly1305 MAC

Hi,

So it means need to custom the ssh serices config right? When i read that KB i though this it will solve if using the latest junos version.

Please correct me if i wrong.

The KB describes that the order of suggested ciphers has been changed.

ssh (and ssl/tls for that matter) negotiates the ciphers used by a prioritized list provided by both client and server. The first match they will use.

In this case the KB describes that CBC based ciphers has been put lower in the list so CTR will be preferred - but if the client only suggests CBC ciphers, you can force the Junos device to use CBC. This is basically what your pentesters are doing, trying to actively downgrade the security.

It's the same with https:// websites where you can have all your new TLS 1.2, 1.3 etc... but if you forget to disable eg. SSLv3, the client can force-downgrade the connection to SSLv3 if they want to.

The right solution is to decide which ciphers to allow, test that all your clients supports this scheme and then deploy on all devices in your network.

I hope that clarifies.