新しいVPSの最初の10分でやる初期設定

新しい VPS の最初の 10 分で、サーバーの安全性が決まります

新しく作成した VPS は安全ではありません。パブリック IP が割り当てられた瞬間から、スキャナーはログインを試みます。初期イメージは、攻撃者にとって大きな攻撃対象になります。root で接続できることが多く、パスワード認証が許可されていることも多いうえ、ファイアウォールがなく、定期的なパッチ適用も設定されていません。幸い、これらをすべて閉じるのに必要なのは、約 10 分と数個のコマンドだけです。これは、何かを配置する前に、新しいサーバーごとに実行する手順です。

手順は順番どおりに進めてください。各手順は前の手順を前提としています。各手順には専用のガイドがあり、進行に合わせてリンクしています。このページは、それらをまとめた最短ルートです。

1 分目: すべてを更新する

プロバイダーから提供された認証情報で root としてログインし、他の作業を始める前にシステムを完全に最新の状態にします。

apt update && apt upgrade -y

パッチが適用されていないサーバーは、最も攻撃を受けやすい対象です。そのため、最初にこの作業を行います。完了したら、自動セキュリティ更新を設定します。手動で更新を覚えておかなくても、最新のパッチが適用された状態を維持できます。

2 分目: sudo を使用する一般ユーザーを作成する

root のまま作業を続けないでください。自分用のユーザーを作成し、sudo 権限を付与します。

adduser matt
usermod -aG sudo matt

以降はこのユーザーでログインし、管理作業には sudo を使用します。常に root で実行すると、すべてのミスや侵害が無制限の権限で発生します。これは、権限のないユーザーで実行することで防ぐ対象です。

Minute 4: SSH 鍵を設定する

パスワードは推測されますが、鍵は推測されません。手元の laptop にまだ鍵がない場合は、作成します。

ssh-keygen -t ed25519

次に、公開鍵を server にコピーします。

ssh-copy-id matt@YOUR_SERVER

新しい user では、ssh-copy-id を有効にしておく必要があります。すでに無効になっている場合は、root の ~/.ssh/authorized_keys を /home/matt/.ssh/authorized_keys（matt が所有）にコピーするか、公開鍵をそのファイルに手動で貼り付けます。

この手順の背景にある、デバイスごとに 1 つの鍵を用意する考え方、鍵によるログインを妨げる権限、紛失した鍵の無効化については、SSH 鍵管理の基本で説明しています。

ログアウトし、鍵を使って matt として再度ログインします。次の手順に進む前に、ログインできることを確認してください。鍵でログインできる状態を確認する前に SSH を制限すると、自分自身を締め出すことになります。そのログインで Permission denied (publickey) が返る場合は、パスワードに戻らず、今の時点で対処してください。このメッセージだけでは 5 つの異なる障害のいずれかしか分からず、ssh -v の出力によって実際にどの障害が発生しているかを特定できます。

Minute 6: root ログインとパスワードを無効にする

鍵が機能することを確認できたら、スキャナーが狙う 2 つの入口を閉じます。パッケージのアップグレードで上書きされないように、drop-in ファイルを使用します。ファイル名は 00- にします。これは 50-cloud-init.conf より前にソートされます。Ubuntu の cloud image には PasswordAuthentication yes が含まれているためです。sshd は最初に読み込んだ値を保持するため、後にソートされるファイルを使うと、その設定は通知なく無効になります。

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

次に SSH を再読み込みします。

sudo systemctl restart ssh

続いて、sshd が実際に使用する設定を確認します。これにより、優先されない drop-in に惑わされずに済みます。

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

パスワード認証を無効にし、root ログインを禁止すれば、サーバーに常時送られるブルートフォース攻撃のネットワークトラフィックは成功しません。オプションのポート変更を含む詳しい手順は、VPS の SSH 強化 にあります。

Minute 8: ファイアウォールを有効にする

受信接続はすべてデフォルトで拒否し、必要なものだけを許可します。有効にする前に SSH を許可してください。そうしないと、自分の接続を切断することになります。

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

実際に稼働させるサービスには allow ルールを追加します。Web サイトであれば、80/tcp と 443/tcp などが該当します。この後に新しい SSH セッションで接続できなくなった場合は、何か操作する前にエラーを確認してください。拒否なら sshd が応答したことを示し、タイムアウトなら通常はファイアウォールがパケットを破棄したことを示します。IPv4 と IPv6 の両方が対象になっていることも確認してください。IPv4 だけをフィルタリングするファイアウォールでは、IPv6 側が無防備なままになります。詳しい手順は VPS でのファイアウォール入門 を参照してください。これらの ufw コマンドは Ubuntu または Debian を前提としています。Rocky または AlmaLinux ではデフォルトで拒否する方針は同じですが、使用するツールは firewalld です。そのため、firewalld 版のこの手順を実行してください。

10 分: Fail2ban でスキャナーを遅らせる

最後に Fail2ban を追加し、ポートへ繰り返しアクセスするアドレスを排除します。

sudo apt install -y fail2ban

Ubuntu 24.04 では、標準インストールで初回起動時から SSH が保護されます。すでに鍵認証を必須にしている場合、これは主な防御策ではなく、ログのノイズを減らして再犯者をブロックする補助策です。

チェックリスト

これが運用手順です。以下のジェネレーターを使って各項目を確認し、サーバーと一緒に保管できる、環境に合わせたチェックリストを作成してください。各手順には正確なコマンドが含まれます。

新しいサーバーごとに一度実行すれば、全体が習慣として身につきます。今の 10 分が、サーバーを侵害された後に待ち受ける非常に長い午後を回避します。

基本的な対策を整えたら、Ubuntu の自動セキュリティ更新により、再度ログインしなくてもサーバーを最新の状態に保てます。その上に追加する各サービスにも個別の確認が必要で、弱点の所在は変わります。セルフホストのパスワード保管庫では、サーバーが平文を保持しないため、Vaultwarden の実際のリスクは管理者トークンとバックアップファイルです。

FAQ

新しい VPS で最初に何をすべきですか？

apt update && apt upgrade -y でシステムを更新し、sudo を使える一般ユーザーを作成して、root での作業をやめます。次に、SSH キーを設定し、root ログインとパスワード認証を無効にして、デフォルト拒否のファイアウォールを有効にし、Fail2ban をインストールします。この順序で実施すれば、サーバーから締め出されることなく各手順を安全に進められます。

SSH のセキュリティ強化で、締め出されないようにするにはどうすればよいですか？

パスワード認証または root ログインを無効にする前に、SSH キーログインを設定してテストします。いったんログアウトし、キーで再ログインして動作を確認してから、PasswordAuthentication と PermitRootLogin だけを無効にします。ファイアウォールを有効にするときは、ufw enable を実行する前に port 22 を許可します。締め出された場合でも、プロバイダーの Web コンソールを使えば SSH なしで再びログインできます。

小規模なサーバーでも、これらすべてが本当に必要ですか？

はい。スキャナーはサーバーの規模を考慮しないためです。すべての公開 IP に対して同じ方法で攻撃を試みます。この手順全体は約 10 分で完了し、root ログイン、パスワード推測、意図せず公開したサービス、未修正の既知のバグといった、攻撃されやすい経路を取り除けます。

最も重要な手順は何ですか？

root ログインを無効にした、キーのみの SSH 認証です。新しい VPS に対する攻撃の多くは、root を対象にした自動的なパスワード推測です。この2つを無効にすると、この種類の攻撃は成立しなくなります。ファイアウォールと Fail2ban により、公開範囲を制限し、残る攻撃の進行も遅らせられます。

サーバーが実際に適切に保護されていることを確認するにはどうすればよいですか？

信頼する前に、次の3点を手作業で確認します。sudo ss -tlnp を実行し、公開アドレスで待ち受けているのが、公開する予定だった port だけであることを確認します。忘れていた 0.0.0.0 または [::] サービスがないことも確認します。sudo ufw status verbose を実行し、受信のデフォルトポリシーが deny であり、通常のルールと (v6) ルールの両方が存在することを確認します。さらに、最初の SSH セッションを閉じる前に、必ず2つ目の SSH セッションを開いてください。SSH 設定の誤りによってサーバーから締め出されるのを防げます。3つすべてが正しければ、基本的な対策は完了しています。