Hernándezが投稿したブログ(https://sysdig.com/blog/aws-secure-ssh-ec2-threats/)を元に日本語に翻訳・再構成した内容となっております。コンプライアンス監査のたびにSSHを保護するよう求められ、SSHが保護されていなければ、スキャナーがクラウドアカウントの設定やCSPMをチェックするたびに警告を受けることになります。EC2でSSHを保護しない場合、「セキュリティ・グループの1つがSSHポート(22)を世界に開放している」という重大なアラートが表示されるのは確実です。このようなことが起きると、「自分は窮地に立たされたのか?」と思うかもしれません。インターネット上の情報やマーケティング資料では、このトピックについて頻繁に警告しているので、あなたに落ち度があるわけではありません。本当にそんなに悪いことなのでしょうか?今回は、この設定ミスをしたときに受けやすい本当の脅威を正直に説明します。Protocol)は、サーバー/マシンをリモートで管理するための標準的なプロトコルであり、telnetに代わる安全な代替手段です。SSHでアクセスできるようになると、マシン全体をコントロールできるようになるため、攻撃者の主な侵入口となっています。したがって、SSHログインを保護し、監査することが重要です。AWSの場合、EC2インスタンスではSSHがデフォルトで有効になっています。マシンをスピンアップするとすぐに、SSHアクセスはRSAキーペアを介して設定されます。その鍵にアクセスできれば、SSHクライアントで接続するのはむしろ簡単な事です。このアクセスのしやすさは、攻撃者にとっても都合が良いものでもあります。AWSは、ベストプラクティスに従ってEC2上のSSHを保護する方法を説明しています。要約するとSSHポートを外部に公開しない。ルートユーザーがSSH端末を使うことを許可しない。すべてのユーザーにSSHキーペアを使ったログインを強制し、パスワード認証を無効にする。信頼できないソースからSSH接続を開くと、どのような問題があるのでしょうか?これは、この記事で探る主な答えです。いくつかの例に飛び込んでみましょう。0.0.0.0/0セキュリティやコンプライアンスを重視する熟練したクラウドエンジニアであれば、有名なCISベンチマークやセキュリティのベストプラクティスをすでにご存知かもしれません。それ以外の方のために、この規格がクラウドプロバイダー上のSSHのセキュリティをどのようにカバーしているかを紹介します。コンプライアンスを満たすためには、これらのコントロールに合格する必要があるため、あなたのチームはおそらく、設定ミスをチェックするためのツールを活用していると思われます。クラウド・セキュリティ・ポスチャー(CSPM)の監視や、さらなる問題のトラブルシューティングに役立つオープンソースのツールは数多くあり、Prowlerは最も有名なものの1つです。“とその影響を説明しています。これはAWSに限ったことではありません。他の2つのパブリッククラウドプロバイダーであるGCPとAzureも同じコントロールを持っています。SSHアクセスがインターネットから制限されていることを確認する(Azure)これは、あなたが見るトリガーされたアラームのほとんどの主な理由です。したがって、このコントロールの目的は明確であり、サーバーがリスクにさらされるのを減らすことです。これらのアラームの1つがトリガーされた場合、ポートが露出した瞬間にハッキングされるのでしょうか?実際のリスクを見てみましょう。SSHを公開することの現実CSPMやEC2マシンの構成によっては、攻撃者がリソースを多かれ少なかれ制御する可能性があります。最終的な結果は、設定ミスの組み合わせに依存します。鍵ペアを保存する際の管理次第で、鍵ペアの収集や廃棄が可能AWSは全マシンにインストールされているSSHデーモンを最新に保っているので、既知の脆弱性を悪用することはできません。認証情報なしでSSHアクセスここでは2つのことが起こった可能性があります。セットアップした人が世界が燃え上がるのを見たいのか、ハニーポットなのか。マシンを無防備にしておく理由はこれくらいしかないでしょう。これは最悪のシナリオで、ボットやスパイダーが数時間であなたのEC2にアクセスできることはほぼ確実です。ユーザー/パスワード認証でSSHを開くこのシナリオは前のものよりも一般的ですが、EC2の場合、手動で設定する必要があります。ユーザーとしては、どこからでもSSHでアクセスできるようにするために、この方法でマシンを構成しようという気になるかもしれません。安全だと錯覚して認証情報を作成することになるでしょう。この特定のシナリオでは、ユーザー名とパスワードのような単純な認証情報の背後にある世界に対してSSHが開かれており、セキュリティは完全にあなたのパスワードの堅牢性に依存しています。この公開と不十分な認証の組み合わせにより、攻撃者はさまざまなツールを使ってブルートフォース攻撃を行うことができるようになります。ここでは、いくつかのオープンソースツールを使って、3つの例を説明します。有名なポートスキャンツールの1つであるNmapは、スクリプトを使用してブルートフォース攻撃を実行する機能を備えています。この例では、ブルートフォース攻撃をスクリプトで実行することができます。<target>Metasploitはペンテストフレームワークであり、いくつかのモジュールを備えています。そのうちの一つがブルートフォースアタック用で、パラメータを設定することでサーバを攻略することができます。/usr/share/metasploit-framework/data/wordlists/rockyou.txtrunHydraは、リサーチャーやセキュリティコンサルタントに、リモートからシステムに不正アクセスすることがいかに簡単であるかを示すことができるツールです。sshこの種の攻撃は、SSHポートが公開されるとすぐに開始されます。Honeypotのレポートによると、最初のSSHブルートフォース攻撃は12時間以内に発生するそうです。したがって、SSHアクセスにこのタイプの認証を使用する場合は、fail2banのようなブルートフォース攻撃の一部を防ぐツールを使用する必要があります。SSHオープンとキーペア認証これはデフォルトの設定です。このシナリオでは、秘密鍵はAWSに保存されず、作成時にのみ取得することができます。脅威としては、誤ってキーペアを漏らしてしまったり、インサイダーによって漏らしてしまったりすることが考えられます。これは起こりうることですが、SSHアクセスに限ったことではありません。フォルダーに格納され、それで終わりです。本題はキーペアをどう管理するかです。GitHubを使って保存している場合は、DumpsterDiverやgit-secretsなどのツールを使うと、ファイルやリポジトリをスクラップして証明書を探すのに便利です。暗号化に関するもの鍵ペアの生成は、RSAやEd25519の規格に基づいています。同じインスタンスにアクセスする2つの異なるキーペアが生成される確率はごくわずかです。そのため、ブルートフォースアタックは現実的な攻撃ではありません。攻撃対象領域を減らすことは、セキュリティのベストプラクティスの一つですが、SSHを公開した場合の本当の脅威についてもう少し説明したいと思います。あなたは即座にハッキングされるわけではありませんが、それは攻撃者がリモートアクセスを得るために必要な1つのステップです。この設定ミスと別の設定ミスを組み合わせると、深刻な問題が発生します。不必要なセキュリティ事故を避けるために、SSHを安全にし、どこからでも接続できるようにSSHを公開しないことをお勧めします。詳しく知りたい方は、Sysdigを使用して、脅威や脆弱性を検出し、設定と権限のリスクを制御し、コンプライアンス要件を満たすことによって、EC2を保護する方法をご覧ください。PolicySubprocessorsトラストセンタ。