Xanadu からの SSH での 3DES の廃止変更点 Xanadu 以降、MID サーバーからの 3DES (Triple Data Encryption Standard) 暗号のサポートは無効になります。この決定は、業界のベストプラクティスとセキュリティ標準に沿ったものであり、Now Platform のセキュリティを維持するための ServiceNow の継続的な取り組みの一環です。 この変更は、顧客環境における MID サーバーと Linux ターゲットマシン間の SSH 通信に影響します。この変更は、KMF、Password2、または agent_keystore.jks で設定されたキーには適用されません。 この変更が必要な理由は何ですか? セキュリティ:3DES は、Sweet32 攻撃 (CVE-2016-2183) などの脆弱性により、廃止されました。その結果、安全とは見なされなくなりました。 NIST コンプライアンス:3DES は、暗号化アルゴリズムに関する現在の NIST (米国国立標準技術研究所) ガイドラインを満たしていません。 MID サーバーの SSH での 3DES には、パスフレーズで保護された秘密キーの復号化と SSH セッションの暗号化/復号化の 2 つの使用法があります。 3DES パスフレーズ 保護された秘密鍵 Xanadu に変更はありませんが、Yokohama では 3DES パスフレーズで保護された秘密キーを削除する予定です。 既存のキーが 3DES 暗号アルゴリズムである場合は、AES-128-CBC パスフレーズで保護された秘密キーを再生成することをお勧めします。 a.どのキーが影響を受けますか? discovery_credentialsテーブルで構成された SSH 秘密鍵のみが影響を受けます。 b.秘密鍵が 3DES パスフレーズで保護されているかどうかは、どうすればわかりますか? 3DES は 2010 年にリリースされた OpenSSH 5.4 バージョンから非推奨になったため、discovery_credentialsテーブルで設定されたキーは、3DES でパスフレーズ保護されています。 確認するには、秘密鍵が 3DES パスフレーズで保護されているかどうかを確認するよう Linux 管理者に依頼してください。 そして、秘密鍵 PEM ファイルにキーワード "DES-EDE3-CBC" が存在するかどうかを確認します。存在する場合は、3DES パスフレーズで保護されています。 c.キーが 3DES パスフレーズで保護されている場合、次に何をしますか? Linux アドミンチームと協力して、新しい AES-128-CBC パスフレーズで保護されたキーを生成してください。インスタンスでこのキーを構成し、最初に準本番インスタンスで新しい認証情報をテストします。そして、Linuxサーバーを正常に検出するために使用できるかどうかを確認します。新しいキーを正常に構成した後、古い認証情報を無効/削除してください。 構成の詳細については、「 https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/product/credentials/reference/r_SSHCredentialsForm.html」を参照してください。 d. AESパスフレーズで保護された秘密鍵を生成する方法は? デフォルトでは、OpenSSH 5.4以降のssh-keygenユーティリティは、AES-128-CBCでパスフレーズで保護された秘密鍵を生成します。 つまり、ほとんどのお客様は既に AES パスフレーズで保護された秘密鍵を使用している可能性があり、影響を受けません。 詳細については、Linux アドミンチームにお問い合わせください。 SSH セッション中の 3DES 暗号化 Xanadu の SSH クライアント (MID サーバー) のデフォルトの暗号アルゴリズム提案リストから 3DES が削除されました。 暗号化に使用される暗号アルゴリズムは、SSH サーバーと SSH クライアント間のアルゴリズムネゴシエーション中に確定します。 MID サーバーは SSH クライアントとして機能し、ネゴシエーション中、3DES はデフォルトのアルゴリズム提案リストには含まれません。 注: 3DES のみを使用するように SSH サーバーを設定した場合、Xanadu 以降、SSH ユーザー認証は失敗します。 a.この変更は他のSSHアルゴリズムに影響しますか? この変更は暗号アルゴリズムにのみ影響します。鍵交換アルゴリズム、ホスト鍵アルゴリズム、MAC アルゴリズムに変更はありません。 b.SSHサーバが3DESのみを使用するように設定されているかどうかは、どうすればわかりますか? Linux アドミンチームにコマンド「sudo sshd -T |grep -i ciphers」というエラーメッセージが表示されます (MID サーバー上ではありません)。 コマンド出力が「ciphers 3des-cbc」のようであれば、サーバーが3desのみを使用するように設定されていることを意味します。 c.SSHサーバがSSHセッションの暗号化に3DESのみを使用するように設定されている場合、どのようなエラーが発生しますか? エラーメッセージは、MID サーバーのログまたはインスタンスに次のように記録されます。 SNCSSH Error :Cannot connect, status is SSH_CONNECTION_FAILURE. Could not agree on client-to-server symmetric cipher algorithm Client:[aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc, aes192-cbc, aes256-cbc, none] Server: [3des-cbc]Maverick Error :Failed to establish SSH connection to 10.xx.xx.xx. Failed to establish SSH connection to 10.xx.xx.xx. Failed to negotiate algorithmsd. 3DES の廃止による失敗をどのように修正しますか? インフラストラクチャがより強力な暗号をサポートしているかどうかを確認します。その場合は、構成をそれらの暗号に更新することを検討してください。 サポートされている暗号アルゴリズムについては、 MID サーバー SSH 暗号化アルゴリズムのドキュメント を参照してください。 e.3DES の廃止によって影響を受ける顧客はたくさんいますか? OpenSSH サーバーは、2016 年にリリースされた バージョン7.4 で 3DES 暗号化を廃止しました。そのため、お客様が古いSSHサーバーを使用しており、明示的に3DESのみを使用するように設定している可能性は低いです。