SSHポート54日間公開実験：誰がアクセスしてきた？

SSHポート54日間公開実験：誰がアクセスしてきた？

2026年4月26日、テックコミュニティで大きな注目を集めている実験報告がある。開発者のArman B.氏が自身のブログで公開した「I Left Port 22 Open on the Internet for 54 Days. Here’s Who Showed Up」という記事だ。 SSH（Secure Shell）の標準ポートである22番ポートを、インターネットに晒したまま54日間放置した結果、膨大な数のアクセスと攻撃試みが記録された。この実験は、クラウド環境やリモートサーバー管理において無視できないセキュリティの現実を鮮明に突きつけている。

実験の背景：なぜSSHポートを晒すのか？

SSHは、リモートサーバーへの安全な接続を提供するプロトコルとして広く使われている。しかし、その普及度が高いために、自動化された攻撃の主要なターゲットともなっている。多くの開発者やシステム管理者は、SSHポートを閉じるか、鍵認証に限定するなどの対策を講じているが、実際のインターネット空間でどれほどの脅威が飛び交っているのかを体感的に知ることは難しい。

Arman氏の実験は、この疑問に実証的に答えることを目的とした。自身のクラウドサーバー（おそらくVPSやクラウドインスタンス）でSSHポート22をパブリックネットワークに開き、54日間にわたりアクセスログを詳細に記録した。この期間中、サーバーはインターネット上に完全に晒された状態だった。

実験結果：自動化攻撃の洪水

記録されたデータは衝撃的だった。54日間で、延べ数万件の接続試みが確認された。そのほとんどは、自動化されたスキャナやボットによるものだ。具体的には以下のようなパターンが顕著だった。

1. ブルートフォース攻撃の猛威：最も多かったのは、IDとパスワードの組み合わせを総当りで試すブルートフォース攻撃だ。ログには、admin、root、testといった一般的なユーザー名で、辞書ベースのパスワードリストを使用した試みが延々と記録された。攻撃元は分散されており、世界中のIPアドレスから短時間に大量のリクエストが殺到した。この手法は、設定が甘いSSHサーバーを自動的に見つけて乗っ取る「ゼロデイ」型のbotnetの構築に利用される可能性がある。

2. 脆弱性を突く攻撃：SSHソフトウェア自体の脆弱性を悪用する試みも見られた。特定のバージョンに影響する既知の脆弱性を狙ったスキャンが確認され、攻撃者はより高度な技術で侵入を図っていた。

3. 不審な接続要求：正規のユーザーによる接続は皆無だったにもかかわらず、接続要求自体は途切れなかった。中には、SSHのバージョン情報を収集しようとするプローブや、接続後のシェルコマンドを実行しようとする試みも含まれていた。

Arman氏は、これらの攻撃を「インターネットの暗黒面を映す鏡」と表現している。実験期間中、サーバーは堅牢な設定（鍵認証のみ有効化、ファイアウォールで不正IPをブロックなど）で保護されていたため、実際に乗っ取られることはなかったが、ログから受ける精神的圧力は計り知れないという。

背景にある脅威の実態

この実験結果は、単なる個人の体験談にとどまらない。インターネット全体のセキュリティ環境を示す重要なデータポイントだ。

• 自動化攻撃の industrialization：攻撃のほとんどは手動ではなく、自動化されたツールによって行われている。これは、攻撃コストの低下とスケーラビリティの向上を意味する。攻撃者は、クラウド上の脆弱なサーバーを無差別にスキャンし、botnetに組み込むことで、DDoS攻撃や暗号通貨マイニングに悪用する。

• 「暗黙の同意」の危険性：多くの開発者は、クラウドプロバイダーのデフォルト設定でSSHポートが開いていることに気づかず、あるいは「攻撃に遭うのは他人事」と考えがちだ。しかし、Arman氏の実験は、実際には常時監視されていること、そして誰もがターゲットになり得ることを示している。

• 法的・倫理的考慮：実験自体は自身のサーバーで行われたが、インターネットに晒す行為は、意図せず他者への攻撃の踏み台になるリスクも孕んでいる。この点は、セキュリティ研究における倫理的ガイドラインの重要性を再考させる。

セキュリティへの影響と教訓

この実験から得られる教訓は明確だ。首先に、SSHアクセスのセキュリティ強化は不可欠である。具体的な対策として以下の点が挙げられる：

• 鍵認証の必須化：パスワード認証を無効化し、公開鍵暗号方式のみを許可する。これだけでブルートフォース攻撃をほぼ防げる。
• ファイアウォールとセキュリティグループの活用：SSHポートへのアクセスを信頼できるIPアドレスに限定する。クラウド環境では、セキュリティグループで受信トラフィックを厳密に制御すべきだ。
• Fail2banのようなツールの導入：不正な接続試みを自動検出し、一定期間ブロックする仕組みを導入する。
• SSHポートの変更：デフォルトの22番ポートを非標準のポートに変更する。これだけで、スクリプトキディによる自動スキャンを大幅に減らせる。
• 定期的な監査とログ分析：アクセスログを常時監視し、異常なパターンを早期に検知する。

今後の展望：セキュリティの「新しい常識」

Arman氏の実験は、クラウドネイティブ時代におけるセキュリティの基本を再確認させる。ゼロトラストアーキテクチャや、AIを活用した異常検知システムの普及が進む中で、こうした基礎的な対策がなおざりにされるリスクがある。

今後、SSHプロトコル自体の進化も期待される。例えば、より強固な認証メカニズムの組み込みや、自動脅威対応機能の標準化などが検討されている。しかし、技術の進化に頼るだけでなく、開発者や管理者のセキュリティ意識の向上が何より重要だ。

この実験は、インターネットがいかに攻撃にさらされた環境であるかを、具体的な数字で示した貴重なケーススタディと言える。すべてのテックプロフェッショナルは、自身のインフラが「次のターゲット」になり得ることを常に念頭に置くべきだ。

FAQ

Q: SSHポートを公開したままにしておくと、具体的にどのようなリスクがありますか？ A: 主なリスクは、自動化されたブルートフォース攻撃による乗っ取りです。攻撃者は辞書を使ったパスワード総当たりで侵入を試み、成功するとサーバーを乗っ取られ、悪意のあるソフトウェアの拠点や暗号通貨マイニングに利用される可能性があります。また、既知の脆弱性を突かれるリスクもあり、機密データの漏洩やシステム破壊につながります。

Q: SSHのセキュリティを強化するための最も効果的な方法は何ですか？ A: 最も効果的なのは、パスワード認証を無効化して鍵認証のみにすることです。さらに、ファイアウォールでSSHポートへのアクセスを信頼できるIPアドレスに限定し、Fail2banのようなツールで不正接続を自動ブロックすることを推奨します。SSHポートをデフォルトの22から変更することも、自動スキャン対策として有効です。

Q: この実験結果は、クラウド環境でも同様に当てはまりますか？ A: はい、クラウド環境でも同様です。むしろ、クラウドサーバーはインターネットに直接晒されるため、攻撃の対象になりやすいです。クラウドプロバイダーのセキュリティグループを適切に設定し、受信トラフィックを厳密に制御することが必須です。プロバイダーのデフォルト設定に頼らず、自らの責任でセキュリティを構築する意識が重要です。