BSI recommended SSH hardening

[G_W_Albrecht]

The German BSI (Federal Office for Information Security) is a main source for IT security recommendations in Europe. Based on its Technical Guideline TR-02102-4_ Cryptographic Mechanisms: Recommendations and Key Lengths – Use of S..., i have tried to harden SSH on my R81.20 Gateway using the suggested cryptographic protocols that should be safe until 2029+. This has resulted in the following configuration:

GW8120> show ssh server cipher enabled
--------------------------------
enabled cipher:
--------------------------------
aes128-gcm@openssh.com
aes256-gcm@openssh.com
--------------------------------
GW8120> show ssh server kex enabled
--------------------------------
enabled kex:
--------------------------------
diffie-hellman-group16-sha512
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
--------------------------------
GW8120> show ssh server mac enabled
--------------------------------
enabled mac:
--------------------------------
hmac-sha2-256
hmac-sha2-256-etm@openssh.com
hmac-sha2-512
hmac-sha2-512-etm@openssh.com
-------------------------------- 

 I would like to receive comments, additions and critical statements concerning SSH cryptographic protocols in CP products!

Additional note: Suggested secure ciphers also include aes128-ctr, aes192-ctr and aes256-ctr, but the recommendation is AEAD_AES_128_GCM and AEAD_AES_256_GCM.

[PhoneBoy]

R81.20 has a newer version of OpenSSH that supports more recent ciphers than earlier releases.
And has commands built into clish to manage them 🙂

[G_W_Albrecht]

That is true - i am writing about R81.20 and using these CLISH commands as seen above.

[Blason_R]

Hmm - Thanks for the information but I being a linux geek always prefer to modify sshd.conf or in checkpoint case may be edit sshd templates file?

[the_rock]

From my R81.20 jumbo 14 lab:

quantum-firewall> show ssh server cipher enabled
--------------------------------
enabled cipher:
--------------------------------
aes128-ctr
aes128-gcm@openssh.com
aes192-ctr
aes256-ctr
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
--------------------------------
quantum-firewall> show ssh server mac enabled
--------------------------------
enabled mac:
--------------------------------
hmac-sha1
hmac-sha1-etm@openssh.com
hmac-sha2-256
hmac-sha2-256-etm@openssh.com
hmac-sha2-512
hmac-sha2-512-etm@openssh.com
umac-64-etm@openssh.com
umac-64@openssh.com
umac-128-etm@openssh.com
umac-128@openssh.com
--------------------------------
quantum-firewall>

[G_W_Albrecht]

See the linked doc for recommended macs. But why do you post your settings instead of comments or additions as requested?

[G_W_Albrecht]

Yes, see sk106031: How to change SSH encryption protocols and Message Authentication Code settings! For small changes the clish commands do come handy...

[the_rock]

Good to know 🙂

[Ilovecheckpoint]

Hello, I have just noticed CVE-2023-48795 of 2023 which advises to disable cipher chacha20-poly1305.

I was expecting on latest hotfixes, this cipher would have been disabled by default. Today, on 2026, on reccomanded hotfix Take 120, this cipher is still enabled, so I will disable on all gateways. To me it is an unexpected behavior. Why ?

[PhoneBoy]

It appears the default for this setting changed in R82 and above.
However, that only applies for fresh installs as upgrades (JHF or version) do not change existing settings.
A fresh install of R81.20 (and presumably earlier releases) appears to have chacha20-poly1305 enabled by default. 

[Bob_Zimmerman]

That CVE is technically an issue, but all an attacker could do with it is disable keystroke timing obfuscation or cause the session to break.

The keystroke timing obfuscation feature was added in OpenSSH 9.5, and the most recent version Check Point ships is 8.7p1 in R82.10. The feature isn't in any version they ship, so that aspect of the CVE is not relevant.

The attack requires that the attacker be able to discard packets between the client and server. An attacker who can do that can obviously break the connection without attacking the cryptography: just discard the SYNs!

This CVE is a total nonissue for Check Point systems. You should have ChaCha20-Poly1305 enabled. It's both stronger and faster than AES128-GCM.