SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

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

新しいVPSは公開直後から攻撃対象です。約10分で一般ユーザーを作成し、SSH鍵を設定、rootログインを無効化してファイアウォールを有効にする手順を紹介します。

新しい 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 の出力によって実際にどの障害が発生しているかを特定できます。

6 分目: root ログインとパスワード認証を無効にする

鍵が機能することを確認できたら、スキャナーが利用する 2 つの侵入口を閉じます。パッケージのアップグレードで上書きされないように、drop-in ファイルを使用します。ファイル名は 00- にします。これにより、そのディレクトリ内の他のすべてのファイルより先にソートされます。Ubuntu の cloud image には 60-cloudimg-settings.conf と PasswordAuthentication no が含まれています。ただし、プロバイダーが cloud-init で ssh_pwauth を設定すると、cloud-init は 50-cloud-init.conf を書き込みます。このファイルは意図的に image のファイルより先にソートされ、パスワード認証を再び有効にすることがあります。sshd は最初に読み取った値を使用するため、後にソートされるファイルの設定は何も警告されずに無効になります。

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

続いて SSH を reload します。

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 が保護されます。すでに鍵認証を必須にしている場合、これは主な防御策ではなく、ログのノイズを減らして再犯者をブロックする補助策です。

チェックリスト

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

ToolBuild your VPS hardening checklist

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

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

FAQ

新規VPSで最初に行うべきことは何ですか?

apt update && apt upgrade -y でシステムを更新し、sudo 権限を持つ一般ユーザーを作成して、root での作業を停止します。その後、SSH キーを設定し、root ログインとパスワード認証を無効化し、デフォルト拒否のファイアウォールを有効にして、Fail2ban をインストールします。この順序で行うことで、締め出されるリスクを避けつつ各ステップを安全に完了できます。

SSHの強化中に締め出されないようにするにはどうすればよいですか?

パスワードや root ログインを無効にする前に、SSH キーによるログインを設定してテストします。いったんログアウトし、キーで再ログインして動作を確認してから、PasswordAuthentication と PermitRootLogin を無効にします。ファイアウォールを有効にする際は、ufw enable を実行する前に 22 番ポートを許可してください。万が一締め出された場合は、プロバイダーの Web コンソールから SSH なしでアクセスできます。

小規模なサーバーでもこれらすべてが必要ですか?

はい、スキャナーはサーバーの規模を考慮しないためです。すべての公開 IP に対して同様に攻撃を試みます。この一連の手順は 10 分程度で完了し、root ログインの禁止、パスワード推測の防止、意図しないサービスの公開停止、既知の脆弱性の自動パッチ適用といった基本的な対策を網羅できます。

最も重要なステップは何ですか?

root ログインを無効にした上での、SSH キーのみによる認証です。新規 VPS への攻撃の多くは root を標的とした自動化されたパスワード推測であり、これら 2 つを無効にすることで、その攻撃手法を完全に排除できます。さらにファイアウォールと Fail2ban を導入することで、公開範囲を制限し、残存する攻撃の速度を低下させます。

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

信頼する前に、手作業で 3 つの点を確認します。sudo ss -tlnp を実行し、意図したポートのみがパブリックアドレスで待ち受けていること、忘れていた 0.0.0.0 や [::] サービスが動作していないことを確認します。sudo ufw status verbose を実行し、デフォルトの受信ポリシーが deny であること、およびプレーンなルールと (v6) ルールの両方が存在することを確認します。また、最初の SSH セッションを閉じる前に必ず 2 つ目のセッションを開いておき、SSH 設定のミスでサーバーから締め出されないようにします。これら 3 つが正しければ、基本的な対策は完了しています。