【ITニュース解説】Someone Is Trying to SSH Into Your Server. What Should You Actually Do?

あなたがサーバーを立ち上げたばかりの時、SSHへの不正なログイン試行が大量にログに記録されるのを見て驚くかもしれない。これは、インターネット上に常に存在する自動化されたスキャナーによるものであり、あなたのサーバーが特別に狙われているわけではない。世界中のすべての公開IPv4アドレスは、オンラインになってから数分以内にスキャンされるのが一般的であり、これはインターネットの「背景ノイズ」と認識すべきだ。しかし、このノイズを無視してデフォルト設定や弱いパスワードのままでいると、数時間以内に自動スクリプトによってサーバーが侵入され、仮想通貨マイナーの設置やDDoS攻撃用のボットネットに組み込まれるなどの被害に遭う可能性があるため、適切な対策が必須となる。

不正な接続試行があった際、システムエンジニアを目指す初心者がまず行うべきことは、実際に侵入されたかどうかを確認する「トリアージ」である。これは、パニックに陥る前に冷静に状況を把握するために非常に重要となる。DebianやUbuntuシステムではsudo grep "Accepted " /var/log/auth.log、systemdを使用するシステムではsudo journalctl -u sshd -g "Accepted "といったコマンドを使って、正常に認証されたログを探す。このログには、どのユーザーが、どの認証方法で、どのIPアドレスから接続したかが記録されている。もし、身に覚えのないユーザー名やIPアドレスからの認証成功ログが見つかった場合、それは明白な侵入である。その際には、即座にサーバーのネットワーク接続を切断し、フォレンジック分析のためにディスクスナップショットを取得し、データをバックアップした上で、OSをゼロから再構築することが唯一の安全な選択肢となる。攻撃者は一度侵入すると、カーネルルートキットやバックドアなど、システム内に巧妙な仕掛けを残すため、単にファイルを削除するだけでは安全な状態に戻せないことを理解しておく必要がある。

次に、よくある誤解とその本質的な対策について解説する。SSHのデフォルトポートである22番を、例えば2222番など別のポートに変更するというアドバイスは、インターネット上の自動スキャナーからの大量の不正アクセス試行を減らす効果はある。これによりログファイルの肥大化やサーバーリソースの無駄遣いを抑制できる。しかし、これは「セキュリティ・バイ・オブスキュリティ」と呼ばれるもので、本質的なセキュリティ対策とは言えない。Nmapのようなツールを使えば、すべてのポートをスキャンしてSSHサービスが稼働しているカスタムポートを簡単に見つけ出すことが可能だからである。そのため、ポート変更はノイズ削減には有効だが、セキュリティ強化には不十分であることを認識しておくべきだ。

本質的なセキュリティ強化策として最も重要なのは、SSHデーモン（sshd）の設定を適切に行うことである。/etc/ssh/sshd_config、または推奨されるドロップインディレクトリ/etc/ssh/sshd_config.d/99-hardening.confに以下の三つの設定を適用することを強く推奨する。一つ目は、PermitRootLogin noを設定し、rootユーザーでの直接ログインを禁止すること。多くの攻撃スクリプトはrootユーザーを標的とするため、これを無効化することで攻撃の難易度を大幅に上げられる。二つ目は、PasswordAuthentication noとKbdInteractiveAuthentication noを設定し、パスワード認証を完全に無効にすること。これにより、パスワードの推測やブルートフォース攻撃が一切通用しなくなる。三つ目は、PubkeyAuthentication yesを設定し、公開鍵認証のみを許可すること。これにより、認証の強度が飛躍的に向上する。また、MaxAuthTries 3を設定することで、認証試行回数を制限し、一度の接続内で多数のキーやパスワードを試すことを防ぐ。これらの設定変更を行う際には、まずsudo sshd -tで設定ファイルの構文をテストし、現在のターミナルセッションを開いたまま、別のターミナルから新しい設定でSSH接続を試す「ゴールデンルール」を必ず守る必要がある。これは、誤った設定で自分自身がサーバーから締め出される事態を防ぐためである。

パスワード認証を無効にした場合、SSH鍵の強度が非常に重要になる。現在でも多くのシステムエンジニアが古い2048ビットのRSA鍵を使用していることがあるが、これは処理が遅く、セキュリティも不十分な場合がある。推奨されるのはEd25519という楕円曲線暗号方式の鍵である。Ed25519鍵は3072ビットのRSA鍵と同等のセキュリティ強度を持ちながら、より高速で効率的である。鍵生成時には、ssh-keygen -t ed25519 -a 100 -C "コメント"のように-a 100フラグでKDF（鍵導出関数）のラウンド数を増やし、オフラインでのブルートフォース攻撃を困難にすることが推奨される。そして何よりも重要なのが、プライベートキーに強力なパスフレーズを設定することである。パスフレーズがない鍵は、平文のパスワードと同様に危険であり、もしプライベートキーが盗まれた場合、パスフレーズがなければ容易に悪用されてしまう。ssh-agentを使用すれば、セッション中に一度だけパスフレーズを入力するだけで済むため、利便性を損なわずにセキュリティを確保できる。さらに、サーバー側の~/.ssh/authorized_keysファイル内でfrom="IPアドレス/CIDR"のようなオプションを追加することで、特定のIPアドレスからのみ鍵認証を許可するといった細かなアクセス制限も可能になる。

さらに動的な防御策として、サーバーへの不正なアクセス試行を自動的に検知し、対応するツールがある。Fail2banは、ログファイルを監視し、一定時間内に複数回の認証失敗を検出したIPアドレスを一時的にファイアウォールでブロックするPythonデーモンである。例えば、SSHの失敗ログを監視し、10分以内に3回認証失敗したIPアドレスを24時間ブロックするといった設定が可能だ。ただし、Fail2banはあくまでリアクティブであり、攻撃者が何回か試行に失敗するまでアクションを起こさないという限界がある。より進んだ対策として、CrowdSecがある。これはFail2banの現代版とも言えるツールで、世界中のCrowdSecインスタンスと脅威情報を共有することで、未知の攻撃元IPアドレスであっても、他のサーバーで悪意ある活動が報告されていれば、自サーバーへの最初のパケットでブロックできるプロアクティブな防御を可能にする。また、UFW（Uncomplicated Firewall）のようなLinuxカーネルの機能を用いたレートリミットも有効である。sudo ufw limit sshというコマンドを実行するだけで、30秒以内に6回以上の接続試行があったIPアドレスからの通信を自動的にブロックするルールを設定できる。これはログを解析するのではなく、カーネルレベルで接続状態を追跡するため、非常に効率的である。

究極的なセキュリティ対策は、SSHポート22をインターネットから完全に隠蔽することである。もしSSHアクセスが必要なのが特定の管理者のみであれば、ポート22を不特定多数に公開しておく必要はない。クラウドプロバイダ（AWS、Google Cloudなど）のセキュリティグループやクラウドファイアウォールを利用し、特定のオフィスIPアドレスや自宅の固定IPアドレスからのみポート22へのアクセスを許可する設定が最も効果的である。これにより、不正な接続試行がサーバーに到達する前にクラウドインフラのレイヤーでブロックされるため、サーバーリソースの消費も抑えられる。さらに柔軟な方法として、TailscaleやWireGuardのようなオーバーレイネットワーク（VPN）を導入することも有効だ。サーバーと管理用ラップトップの両方にVPNクライアントをインストールし、SSHデーモンをそのVPNが提供するプライベートIPアドレスにのみバインドさせる。これにより、サーバーのパブリックIPアドレス上のポート22は完全に閉鎖された状態となり、VPNを通じてのみSSH接続が可能となるため、外部からのスキャンや攻撃から完全に隔離される。

より高度なセキュリティ要件が求められる本番環境では、FIDO2ハードウェアキーやSSH証明書の導入も検討すべきである。FIDO2ハードウェアキーは、SSHキーを物理デバイスに紐付けることで、キーファイルが盗まれた場合でも物理的な操作がなければ認証できないようにする。SSH証明書は、多数のサーバーとユーザーを管理する際に非常に有効で、内部の認証局（CA）がユーザーの公開鍵に有効期限付きの証明書を発行することで、ユーザーの離職時などに個々のサーバーから鍵を削除する手間を省き、一元的にアクセス管理を行えるようになる。

万が一、不正侵入が成功してしまった場合の対応策も重要である。まず、サーバーのネットワーク接続を直ちに隔離し、それ以上被害が拡大しないようにする。この際、再起動は避け、メモリ上の情報や一時ファイルなど、フォレンジック分析に必要な証拠が失われないようにする。次に、実行中のプロセスやネットワーク接続、最近変更されたファイルなどの証拠を収集する。攻撃者が残した永続化メカニズムも確認する。しかし、最終的にはシステムをゼロから再構築することが唯一の安全な選択肢である。攻撃者はシステムのバイナリを改ざんするなどして、管理者が見ても異常を検知できないように細工する可能性があるため、決して手動でのクリーンアップを試みるべきではない。アプリケーションデータをバックアップした後、ディスクをワイプし、クリーンなOSを再デプロイし、サーバーに保存されていたすべての秘密情報（APIキーやデータベース認証情報など）を必ず変更する必要がある。

まとめとして、Linuxサーバーを運用する上でのSSHセキュリティに関する実践的な指針をいくつか挙げる。公共インターネットにポート22を公開しないこと、もし公開する場合は特定のIPアドレスのみに制限すること。sshd_configでパスワード認証を無効にし、rootログインを禁止すること。Ed25519タイプの強力なSSH鍵をパスフレーズ付きで使用すること。ログ監査では、失敗した接続試行の数に惑わされず、「Accepted」ログに不正なエントリーがないかを重点的に確認すること。Fail2banやCrowdSecを導入して不正な接続試行によるリソース消費を減らすこと。そして、SSHデーモンの設定を変更する際は、必ず構文テストと別ターミナルからの接続テストを行うこと。インターネット上でのSSHへの不正な接続試行は避けられないノイズだが、適切な設定と対策を施すことで、そのノイズがあなたのサーバーに侵入するのを確実に防ぐことができる。重要なのは、不正なパケットがポート22に到達しても、認証する術がなく、どこにも進めない状態を作り出すことである。