新規VPSのセキュリティ設定 堅牢化チェックリスト

新しく構築したVPSは、オンラインになった瞬間から数分以内に自動化された攻撃にさらされます。このチェックリストでは、サーバーを自分のものとして守り抜くための、最初の1時間で行うべき強化手順を順を追って解説します。

新しいサーバーはすべて、同じ弱点を抱えた状態で稼働を始めます。デフォルトのrootログイン、パスワードのみのSSH、全開放のファイアウォール、そして自動パッチ適用の欠如です。ボットはIPv4アドレス空間全体を絶えずスキャンしているため、「自分のIPはまだ誰にも知られていない」という考えは決して成り立ちません。

このガイドは、そのままコピーして使える順序立てられたハードニング(セキュリティ強化)チェックリストです。新規のDebianまたはUbuntuサーバー上で上から順に作業を進めることで、見せかけのセキュリティ対策が気にするような穴ではなく、攻撃者が実際に悪用する侵入口を塞ぐことができます。

サーバーに触れる前に

初回ログインの前にあらかじめ2つの判断をしておくだけで、後々何時間もの手間を省けます。SSHキーを準備し、root以外のユーザー名を決めておきましょう。

1. 1

   最新のSSHキーを生成する

   自分のマシン上で ssh-keygen -t ed25519 -C "you@device" を実行してください。Ed25519キーは短く高速で、従来のデフォルトであるRSA-2048よりも強力です。

2. 2

   秘密鍵はサーバーに置かない

   秘密鍵は自分のノートPCから外に出してはいけません。サーバーにコピーするのは常に.pubファイルだけです。このルールを破ると、自分自身をロックアウトしてサーバーの再構築に追い込まれることになります。

3. 3

   プロビジョニング時の認証情報を控えておく

   ほとんどのプロバイダーは、一時的なrootパスワードをメールで送るか、構築時にあなたのキーを注入します。キーが注入済みの場合は、ユーザー作成の手順にそのまま進んで構いません。

ステップ1 — すべてにパッチを当て、そのまま維持する

パッチの当たっていないカーネルやOpenSSLは、どんなファイアウォールルールをもってしても防げない唯一の欠陥です。他の設定を行う前に、まずアップデートを済ませてください。

• Debian/Ubuntu: apt update && apt full-upgrade -y を実行し、カーネルが更新された場合は再起動してください。
• セキュリティパッチが自動的に適用されるよう、unattended-upgradesを有効にしてください: apt install unattended-upgrades && dpkg-reconfigure unattended-upgrades。
• 再起動は自分でコントロールできるスケジュールで行いましょう。カーネルの適用を中途半端な状態のまま放置せず、Unattended-Upgrade::Automatic-Rebootを利用の少ない時間帯に設定してください。

ステップ2 — 実名ユーザーを作成し、rootの使用をやめる

rootとしてログインするということは、たった1つのセッションが乗っ取られただけでマシン全体が支配され、しかも監査の痕跡が残らないということです。代わりに、名前付きのsudoアカウントを自分用に用意しましょう。

1. 1

   ユーザーを追加する

   adduser deploy を実行した後、usermod -aG sudo deploy を実行します(RHEL系システムではwheelグループを使用してください)。

2. 2

   そのユーザー用にキーをインストールする

   自分のノートPCから: ssh-copy-id deploy@your-server-ip を実行します。これにより、公開鍵が正しい権限のまま ~/.ssh/authorized_keys に書き込まれます。

3. 3

   扉を閉める前にテストする

   別のターミナルを開き、ssh deploy@server でログインできること、そして sudo -v が実行できることを確認してください。新しいセッションが正常に機能することを確認するまでは、rootログインやパスワード認証を無効化してはいけません。

ステップ3 — SSHハードニング、最も重要な部分

SSHはあらゆるVPSの正面玄関であり、自動化されたログイン試行の大部分が集中する場所でもあります。/etc/ssh/sshd_config(または /etc/ssh/sshd_config.d/ 内のドロップインファイル)を編集し、以下の項目を設定してください。

sshd -t で構文を検証してから systemctl restart ssh を実行してください。sshd -t がエラーを報告した場合は、再起動前に修正してください。そうしないとデーモンが停止してしまう可能性があります。

SSHのポートを22番から変更するのは任意であり、ログのノイズを減らす効果しかありません。これはセキュリティではなく、単なる目くらまし(security through obscurity)です。PasswordAuthenticationをオフにしてしまえば、ポートスキャンを行うボットには推測すべきものが何もなくなるため、ポート番号をいじるよりもキー認証に力を注ぐべきです。

ステップ4 — デフォルト拒否のファイアウォールを有効にする

SSHデーモンを強化しても、マシン上では他のすべてのリスニングサービスと共存していることに変わりはありません。ファイアウォールは「自分で開けない限り閉じている」状態をデフォルトにしてくれます。

1. 1

   基本方針を設定する

   ufwを使う場合: ufw default deny incoming と ufw default allow outgoing を実行します。

2. 2

   提供するものだけを許可する

   ufw allow OpenSSH を実行し、このサーバーが実際にWebトラフィックをホストする場合のみ ufw allow 80,443/tcp も追加します。

3. 3

   有効化して確認する

   ufw enable を実行した後、ufw status verbose で確認します。ここに記載のないものは、すべてインターネットから到達不可能になっています。

ステップ5 — Fail2banでブルートフォース攻撃を減速させる

パスワード認証を無効化していても、ボットはノックを続け、ログを肥大化させます。Fail2banは、繰り返し攻撃を仕掛けてくる相手をファイアウォールレベルでBAN(遮断)します。

• apt install fail2ban — 同梱されているsshd用のjailは、そのまま使い始められます。
• jail.conf を jail.local にコピーし、bantime を長め(例: 1h)に、maxretry を少なめ(例: 3)に、好みに応じて調整してください。
• fail2ban-client status sshd を実行して、BANされたIPの件数を確認し、正常に動作していることをチェックしてください。

ステップ6 — 攻撃対象領域を縮小する

最も安全なサービスとは、そもそも稼働していないサービスです。何がリッスンしているかを監査し、不要なものは削ぎ落としましょう。

ステップ7 — ログを取り、監視し、自分のベースラインを把握する

ハードニングは一度きりのイベントではありません。何かが変化したときに、それに気づける状態を作る必要があります。

• journalctl -u ssh や lastb を使って認証アクティビティを確認し、ログイン失敗の記録を確認しましょう。
• 特権操作の改ざん検知可能な記録を残すために、auditdの導入も検討してください。
• /etc と自分のデータをサーバー外にバックアップしておきましょう。侵害されたサーバーを、事後的に信用するのではなく、クリーンな状態から再構築できるようにするためです。

ホスト自体が重要になる領域

ソフトウェアのハードニングはOSを保護しますが、その下に何があるか——ネットワークフィルタリング、決済の痕跡、そしてサーバーが身元と紐付けられるかどうか——を決めるのはプロバイダー側です。ChainVPSでは、すべてのプランにDDoSフィルタリングと帯域無制限が標準装備されており、Monero(モネロ)を含む21種類の暗号資産によるプリペイド残高からの支払いが可能で、KYC(本人確認)は一切不要です。サーバーを自分の身元に結び付けたくないという脅威モデルをお持ちなら、私たちのオフショアVPSプランはまさにそのために設計されています。

ロケーションもまた、ハードニングの一部です。私たちの15リージョンのうち6つは、プライバシー重視の法域(NL、CH、RO、IS、MD、LU)にあります。強化されたOSと、オフショアの専用サーバーを組み合わせることで、ソフトウェア面と法的な面の両方を隙のない状態に保てます。

1時間チェックリスト、要約版

• システム全体のアップデート完了+自動セキュリティパッチの有効化
• 名前付きsudoユーザーの作成、キーのインストール、ログインのテスト完了
• rootのSSHログインとパスワード認証を両方とも無効化
• sshd -t でSSH設定を検証し、再読み込み完了
• デフォルト拒否のファイアウォールが稼働中、必要なポートのみ開放
• Fail2banがsshd用jailで稼働中
• 開いているポートを監査し、不要なサービスを削除済み
• サーバー外バックアップとログレビュー体制の整備完了