web-dev-qa-db-ja.com

SSHで利用可能な暗号/ MAC / Kexの安全な構成

以前に投稿された質問に続いて Taxonomy of Ciphers/MACs/Kex available in SSH? に続き、次の設計目標を達成するために助けが必要です。

  • 96ビットHMACアルゴリズムを無効にします。
  • MD5ベースのHMACアルゴリズムを無効にします。
  • CBCモード暗号を無効にし、CTRモード暗号を使用します。

このため、サポートされている暗号のデフォルトのリストは次のとおりです。

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour

私はそれをこれに変更することを考えていました:

Ciphers aes256-ctr,aes192-ctr,aes128-ctr,[email protected],[email protected],arcfour256

次に、HMACの場合、次をサポートします。

[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-sha1-96,hmac-md5-96

そして、私はそれをこれに変更することを考えていました:

[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected],hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-ripemd160

これは、一般的なSSH構成に対する既知の弱点と攻撃を軽減しながら、セキュリティの面で最もメリットがありますか?この質問は、SSHコードの0日またはその他の関連する欠陥に関するものではなく、特に、暗号、KexAlgorithms、およびMACの可能な限り最良の配置および構成に関するものであることに注意してください。順序が間違っている場合は、それらを整理するためのより良い方法を提案してください。これはsshd_configファイル用でもあり、クライアント接続用ではありません。

27
John

SSHのセキュリティを本当に心配している人は、おそらくこのページを読みたいと思うでしょう。

https://stribika.github.io/2015/01/04/secure-secure-Shell.html

OpenSSHがサポートするすべてのキー交換、サーバー認証、暗号、MACを通過し、本当に安全とは見なされないものはすべて破棄し、排除するすべての正当な正当化を行います。このセットアップで、あなたは堅実です!

TL; DR?最高のセキュリティの勝者は次のとおりです。

鍵交換:curve25519-sha256
(フォールバック:diffie-hellman-group-exchange-sha256

サーバー認証:Ed25519 with SHA512
(フォールバック:RSA with SHA1 4096 Bits

暗号:chacha20-poly1305
(フォールバック:aes256-ctr

MAC:hmac-sha2-512-etm
(フォールバック:hmac-sha2-512

フォールバックは、ほとんどのSSHサーバーで見られるものであり、それほど安全ではありませんが、今日の標準では十分に安全です。

私の側からの1つのコメント:データのコピー(scpまたはrsync)またはポート転送X11またはVNCにもSSHを使用する場合、パフォーマンスとレイテンシは関係ありません。その場合、aes128-ctrは(今日の時点で安全であることがわかっている暗号のうち)最高のパフォーマンスを提供し、[email protected]の使用を検討することができます。MD5も壊れているため、HMAC-MD5はありません今日までのところ、MD5はSHA-1をはるかに上回り、SHA-2をはるかに上回っています。アルゴリズムの速度については、次のページを参照してください。

https://www.cryptopp.com/benchmarks.html

私見それは許容できるトレードオフです:より多くの速度のためにいくつかのセキュリティをトレードします。

chacha20-poly1305はどうですか?今のところ、chacha20-poly1305のベンチマークはありません。また、安全であることが証明されているとは言えません。これはRC4(別名arcfour)の代替となるはずなので、ソフトウェアのaes128-ctrよりもさらに高速ですが、最新のIntel CPUはハードウェアでAES128を計算できるため、SSH実装がそれを使用する場合、期待できます。 AES128は非常に高速です。それでもChaChaの方が速いかもしれませんが、少し心配なのはまだ証明されていないセキュリティです。攻撃の試行回数が少なすぎ、2008年以来存在していますが、NSAがRC4 SSL/TLS接続をリアルタイムで切断できることが判明したとき、つい最近ChaChaが人気を博しました。ChaChaはそれを修正してTLSのRC4を置き換えますが、それはそのセキュリティの証拠にはなりません。

鍵交換やサーバー認証について心配する必要はありません。その速度は、最初の接続時と、鍵を更新する必要がある場合にのみ機能します(いつ発生するかは、選択した暗号と転送するデータの量によって異なります...すべての暗号データ制限があり、それに達すると、新しいキーは既存のキーにとどまると暗号化が弱まるので交換されますが、更新はそれほど頻繁には行われないため、これら2つについては常に最高のセキュリティと速度を完全に無視します。

また、MD5またはSHA-1には、切り捨てられたハッシュ(-96)を使用しないでください。パケットごとに数バイトを節約する以外に、実際のメリットはありません(MD5の場合は4、SHA-1の場合は8)。ハッシュは計算/検証に同じくらい時間がかかり(速度の利点はありません)、切り捨てはセキュリティを弱めるだけです(セキュリティの利点はありません)。 SHA-2の方がはるかに大きいため(パケットあたり32、48、64バイト)、送信パケットの最大サイズを考慮するとこのような大きなハッシュは意味をなさないため、切り捨てはSHA-2に見返りをもたらしますが、これらの切り捨てはオプションではありません。

9
Mecki

Cbc暗号を削除するには、次のように/ etc/ssh/sshd_configの「Ciphers」行を追加または変更します。Ciphers aes128-ctr、aes192-ctr、aes256-ctr、arcfour256、arcfour128、arcfour

HMAC MD5を削除するには、次のように/ etc/ssh/sshd_configのMAC行を追加または変更します。MACs hmac-sha1、hmac-ripemd160

SSHDを再起動して変更を適用します。service sshd restart

2