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 ?
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
email@example.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
firstname.lastname@example.org 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
email@example.com ChaCha20 stream cipher and Poly1305 MAC
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.