EC2上のSecure SSH: 本当の脅威は何か？

By 清水 孝郎 - JUNE 14, 2022
Topics: 脅威リサーチ

SHARE:

本文の内容は、2022年6月14日にMiguel Hernándezが投稿したブログ(https://sysdig.com/blog/aws-secure-ssh-ec2-threats/)を元に日本語に翻訳・再構成した内容となっております。

コンプライアンス監査のたびにSSHを保護するよう求められ、SSHが保護されていなければ、スキャナーがクラウドアカウントの設定やCSPMをチェックするたびに警告を受けることになります。例えば、EC2でSSHを保護しない場合、「セキュリティ・グループの1つがSSHポート（22）を世界に開放している」という重大なアラートが表示されるのは確実です。

このようなことが起きると、「自分は窮地に立たされたのか？」と思うかもしれません。

Secure SSH threats
インターネット上の情報やマーケティング資料では、このトピックについて頻繁に警告しているので、あなたに落ち度があるわけではありません。しかし、本当にそんなに悪いことなのでしょうか？

今回は、この設定ミスをしたときに受けやすい本当の脅威を正直に説明します。

EC2上のSSHとは？

SSH（Secure Shell Protocol）は、サーバー/マシンをリモートで管理するための標準的なプロトコルであり、telnetに代わる安全な代替手段です。SSHでアクセスできるようになると、マシン全体をコントロールできるようになるため、攻撃者の主な侵入口となっています。したがって、SSHログインを保護し、監査することが重要です。

AWSの場合、EC2インスタンスではSSHがデフォルトで有効になっています。マシンをスピンアップするとすぐに、SSHアクセスはRSAキーペアを介して設定されます。そして、その鍵にアクセスできれば、SSHクライアントで接続するのはむしろ簡単な事です。しかし、このアクセスのしやすさは、攻撃者にとっても都合が良いものでもあります。AWSは、ベストプラクティスに従ってEC2上のSSHを保護する方法を説明しています。要約すると

  • SSHポートを外部に公開しない。
  • ルートユーザーがSSH端末を使うことを許可しない。
  • すべてのユーザーにSSHキーペアを使ったログインを強制し、パスワード認証を無効にする。

信頼できないソースからSSH接続を開くと、どのような問題があるのでしょうか？

これは、この記事で探る主な答えです。いくつかの例に飛び込んでみましょう。


CISベンチマーク – 0.0.0.0/0

セキュリティやコンプライアンスを重視する熟練したクラウドエンジニアであれば、有名なCISベンチマークやセキュリティのベストプラクティスをすでにご存知かもしれません。それ以外の方のために、この規格がクラウドプロバイダー上のSSHのセキュリティをどのようにカバーしているかを紹介します。

コンプライアンスを満たすためには、これらのコントロールに合格する必要があるため、あなたのチームはおそらく、設定ミスをチェックするためのツールを活用していると思われます。クラウド・セキュリティ・ポスチャー（CSPM）の監視や、さらなる問題のトラブルシューティングに役立つオープンソースのツールは数多くあり、Prowlerは最も有名なものの1つです。

コントロールを深掘りすると、AWS CIS Benchmarkのポート開放時にアラートを出すものがあります：

  • 4.1 0.0.0.0/0からポート22への侵入を許可するセキュリティグループがないことを確認する（AWS）

CISでは、”SSHなどのリモートコンソールサービスへの自由な接続を取り除くことで、サーバーのリスクへの露出を減らすことができる “とその影響を説明しています。

これはAWSに限ったことではありません。他の2つのパブリッククラウドプロバイダーであるGCPとAzureも同じコントロールを持っています。

  • 3.6 インターネットからのSSHアクセスが制限されていることを確認する(GCP)
  • 6.2 SSHアクセスがインターネットから制限されていることを確認する(Azure)

これは、あなたが見るトリガーされたアラームのほとんどの主な理由です。

したがって、このコントロールの目的は明確であり、サーバーがリスクにさらされるのを減らすことです。しかし、これらのアラームの1つがトリガーされた場合、ポートが露出した瞬間にハッキングされるのでしょうか？実際のリスクを見てみましょう。

SSHを公開することの現実

CSPMやEC2マシンの構成によっては、攻撃者がリソースを多かれ少なかれ制御する可能性があります。そして、最終的な結果は、設定ミスの組み合わせに依存します。

SSHポートにアクセス可能な3つのシナリオを説明していきましょう：

シナリオ攻撃テクニックインフラストラクチャーが侵害される時間
公開+認証なしFreeミリ秒
公開＋認証ブルートフォース数分
公開＋キーペア認証収集またはスクラッピング鍵ペアを保存する際の管理次第で、鍵ペアの収集や廃棄が可能


AWSは全マシンにインストールされているSSHデーモンを最新に保っているので、既知の脆弱性を悪用することはできません。

認証情報なしでSSHアクセス

ここでは2つのことが起こった可能性があります。セットアップした人が世界が燃え上がるのを見たいのか、ハニーポットなのか。マシンを無防備にしておく理由はこれくらいしかないでしょう。これは最悪のシナリオで、ボットやスパイダーが数時間であなたのEC2にアクセスできることはほぼ確実です。

ユーザー/パスワード認証でSSHを開く

このシナリオは前のものよりも一般的ですが、EC2の場合、手動で設定する必要があります。ユーザーとしては、どこからでもSSHでアクセスできるようにするために、この方法でマシンを構成しようという気になるかもしれません。そして、安全だと錯覚して認証情報を作成することになるでしょう。ここで問題です。この特定のシナリオでは、ユーザー名とパスワードのような単純な認証情報の背後にある世界に対してSSHが開かれており、セキュリティは完全にあなたのパスワードの堅牢性に依存しています。

この公開と不十分な認証の組み合わせにより、攻撃者はさまざまなツールを使ってブルートフォース攻撃を行うことができるようになります。ここでは、いくつかのオープンソースツールを使って、3つの例を説明します。

最も有名なポートスキャンツールの1つであるNmapは、スクリプトを使用してブルートフォース攻撃を実行する機能を備えています。この例では、ブルートフォース攻撃をスクリプトで実行することができます。

nmap -p 22 --script ssh-brute --script-args userdb=users.lst,passdb=pass.lst --script-args ssh-brute.timeout=4s <target>

Metasploitはペンテストフレームワークであり、いくつかのモジュールを備えています。そのうちの一つがブルートフォースアタック用で、パラメータを設定することでサーバを攻略することができます。

msf > use auxiliary/scanner/ssh/ssh_login
msf auxiliary(ssh_login) > set RHOSTS <target>
msf auxiliary(ssh_login) > set USERPASS_FILE /usr/share/metasploit-framework/data/wordlists/root_userpass.txt
msf auxiliary(ssh_login) > set PASSWORD /usr/share/metasploit-framework/data/wordlists/rockyou.txt
run

Hydraは、リサーチャーやセキュリティコンサルタントに、リモートからシステムに不正アクセスすることがいかに簡単であるかを示すことができるツールです。

hydra -L /usr/share/wordlists.rockyou.txt -P /usr/share/wordlists/rockyou.txt <target-IP> -t 4 ssh

この種の攻撃は、SSHポートが公開されるとすぐに開始されます。Smart Honeypotのレポートによると、最初のSSHブルートフォース攻撃は12時間以内に発生するそうです。したがって、SSHアクセスにこのタイプの認証を使用する場合は、fail2banのようなブルートフォース攻撃の一部を防ぐツールを使用する必要があります。

SSHオープンとキーペア認証

これはデフォルトの設定です。このシナリオでは、秘密鍵はAWSに保存されず、作成時にのみ取得することができます。脅威としては、誤ってキーペアを漏らしてしまったり、インサイダーによって漏らしてしまったりすることが考えられます。これは起こりうることですが、SSHアクセスに限ったことではありません。

キーペアの作成は、AMIがLinuxやAmazonをベースにしている場合、Linuxシステムの場合と同様で、公開鍵は  ~/.ssh/authorized_keys フォルダーに格納され、それで終わりです。

本題はキーペアをどう管理するかです。GitHubを使って保存している場合は、DumpsterDiverやgit-secretsなどのツールを使うと、ファイルやリポジトリをスクラップして証明書を探すのに便利です。

暗号化に関するもの

鍵ペアの生成は、RSAやEd25519の規格に基づいています。同じインスタンスにアクセスする2つの異なるキーペアが生成される確率はごくわずかです。そのため、ブルートフォースアタックは現実的な攻撃ではありません。

最後の言葉

攻撃対象領域を減らすことは、セキュリティのベストプラクティスの一つですが、SSHを公開した場合の本当の脅威についてもう少し説明したいと思います。あなたは即座にハッキングされるわけではありませんが、それは攻撃者がリモートアクセスを得るために必要な1つのステップです。

この設定ミスと別の設定ミスを組み合わせると、深刻な問題が発生します。しかし、不必要なセキュリティ事故を避けるために、SSHを安全にし、どこからでも接続できるようにSSHを公開しないことをお勧めします。

さらに詳しく知りたい方は、Sysdigを使用して、脅威や脆弱性を検出し、設定と権限のリスクを制御し、コンプライアンス要件を満たすことによって、EC2を保護する方法をご覧ください。

Secure EC2