VPSを借りたら最初にやるセキュリティ設定10項目【契約直後のハードニング】

セキュリティ中級2026年6月26日

本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。

TL;DR

VPSは契約してグローバルIPが割り当たった瞬間から、世界中の自動化された総当たり攻撃にさらされます。初期パスワードのままrootでSSHを開けていると、数時間で侵入され、踏み台（他サイトへの攻撃やマイニングの中継）に使われます。

やることはシンプルです。①OS更新 → ②rootログイン無効化と一般ユーザー作成 → ③SSH鍵認証への切り替え → ④ファイアウォール（ufw）→ ⑤fail2ban の5つを最初の30分で済ませれば、攻撃面の大半は塞げます。残りの自動更新・不要サービス停止・ログ監視・バックアップは運用に乗せていく項目です。本記事はUbuntu/Debian系を前提に、各項目のコマンドまで示します。

本記事は自分が契約・管理するVPSのハードニングを対象にした技術解説です。他人のサーバーへの設定変更や侵入テストは不正アクセス禁止法に触れます。SSHポート変更などはサーバーへのログイン手段を失うリスクがあるため、必ず別セッションを開いたまま作業してください。VPSサービスの比較は法人向けVPSレンタルサーバー比較を参照してください。

なぜ「契約直後」が重要なのか

VPSに割り当てられるのはパブリックなIPv4アドレスです。インターネット上のスキャナは、このアドレス空間を常時総当たりでスキャンしており、22番ポート（SSH）が開いていれば即座にログイン試行が始まります。root ユーザーは全環境に存在することが分かっているため、攻撃者はユーザー名を推測する必要すらありません。あとはパスワードを辞書攻撃で当てるだけです。

つまり、初期設定の「rootユーザー＋パスワード認証＋22番ポート」という組み合わせは、攻撃者にとって最も狙いやすい構成です。ここを崩すのが初期ハードニングの本質になります。

設定チェックリスト（優先度つき）

#	項目	優先度	効果
1	OSパッケージの更新	必須	既知の脆弱性を塞ぐ
2	rootログイン無効化＋一般ユーザー＋sudo	必須	root直接侵入を防ぐ
3	SSH鍵認証・パスワード認証無効化	必須	辞書攻撃を無力化
4	SSHポート変更	任意	ログのノイズ削減（本質的防御ではない）
5	ファイアウォール（ufw）	必須	不要ポートを閉じる
6	fail2ban	推奨	試行回数の多いIPを自動遮断
7	自動セキュリティ更新	推奨	更新漏れを防ぐ
8	不要サービスの停止	推奨	攻撃面を減らす
9	ログ監視	推奨	異常の早期検知
10	バックアップ	必須	侵害・障害からの復旧

以下、上から順に進めます。1〜3の順序は守ってください。先にrootを無効化してから鍵を入れ忘れると、ログインできなくなります。

① OSパッケージの更新

契約直後のイメージは、配布された時点からの差分で脆弱性が溜まっていることがあります。まず全パッケージを最新化します。

sudo apt update
sudo apt upgrade -y

カーネルやライブラリの更新後は再起動が必要なことがあります。/var/run/reboot-required が存在すれば再起動してください。

[ -f /var/run/reboot-required ] && sudo reboot

② rootログイン無効化＋一般ユーザー作成＋sudo

rootで直接作業を続けるのは危険です。日常作業用の一般ユーザーを作り、必要なときだけ sudo で昇格する構成にします。

一般ユーザーを作成し、sudo権限を付与します（Ubuntu/Debianでは sudo グループ）。

adduser deploy
usermod -aG sudo deploy

この時点ではまだrootのSSHを無効化しません。次の③で新ユーザーの鍵ログインが成功することを確認してから無効化します。順序を逆にすると締め出されます。

③ SSH鍵認証への切り替えとパスワード認証の無効化

パスワード認証は、どれだけ強固でも総当たりの対象になります。公開鍵認証に切り替えれば、辞書攻撃は事実上無力化できます。

手元（ローカルPC）で鍵ペアを作成

まだ鍵がなければ作成します。Ed25519が推奨です。

ssh-keygen -t ed25519 -C "deploy@myvps"

公開鍵をサーバーに送る

ssh-copy-id が使えれば一発です。

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<サーバーIP>

手動で配置する場合は、サーバー側で以下のように権限を整えます。

mkdir -p ~/.ssh && chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

sshd設定でパスワード認証とrootログインを無効化

別のターミナルで deploy ユーザーの鍵ログインが成功することを確認してから、以下を編集します。

sudo nano /etc/ssh/sshd_config

該当行を次のように設定します。

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

設定を反映します。

sudo systemctl restart ssh

現在のSSHセッションは保持したまま、新しいターミナルでログインできることを必ず確認してください。失敗してもセッションを残しておけば設定を戻せます。

④ SSHポート変更の是非

22番から別ポートへ変えると、自動スキャンのログは確かに減ります。ただしこれは「防御」ではなく「ノイズ削減」です。ポートスキャンで開放ポートはすぐ見つかるため、鍵認証（③）ほどの効果はありません。鍵認証が済んでいれば、ポート変更は任意です。

変更する場合は sshd_config で指定します。

Port 2222

ポートを変えたら、ファイアウォール（⑤）でそのポートを開けるのを忘れないでください。先に閉じると締め出されます。

sudo systemctl restart ssh

⑤ ファイアウォール（ufw）

不要なポートを閉じ、必要なものだけ開けます。Ubuntu/Debianでは ufw が手軽です。

sudo apt install ufw -y

デフォルトで受信を拒否、送信を許可します。

sudo ufw default deny incoming
sudo ufw default allow outgoing

SSHポートを許可してから有効化します（順序を間違えると締め出されます）。22番のままなら次の通りです。

sudo ufw allow 22/tcp

ポートを変えた場合（例: 2222）はそのポートを開けます。

sudo ufw allow 2222/tcp

Webサーバーを動かすなら80/443も開けます。

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

最後に有効化し、状態を確認します。

sudo ufw enable
sudo ufw status verbose

⑥ fail2ban

ufwでポートを絞っても、開けたSSHポートには試行が来ます。fail2banはログを監視し、短時間に失敗を繰り返すIPを自動で一時遮断します。

sudo apt install fail2ban -y

設定は jail.local に書きます（jail.conf を直接編集しない）。

sudo nano /etc/fail2ban/jail.local

最小構成の例です。

[sshd]
enabled = true
maxretry = 5
bantime = 1h
findtime = 10m

ポートを変えた場合は port を明示します（例: port = 2222）。サービスを起動し、状態を確認します。

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

⑦ 自動セキュリティ更新

手動更新は忘れます。セキュリティ更新だけ自動適用する仕組みを入れます。

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

対象や挙動は /etc/apt/apt.conf.d/50unattended-upgrades で確認・調整できます。再起動を伴う更新の扱いには注意してください（自動再起動を有効にする場合は稼働中サービスへの影響を考慮します）。

⑧ 不要サービスの停止

待ち受けしているサービスが多いほど攻撃面が広がります。何がポートを開いているかを確認します。

sudo ss -tulpn

不要なサービス（使っていないメールサーバーやDBの外部公開など）は停止・無効化します。

sudo systemctl disable --now <サービス名>

DBなど内部だけで使うものは、停止せずに待ち受けをlocalhostに限定するか、ufwで外部からのアクセスを遮断する方が安全です。

⑨ ログ監視

侵害は早く気づくほど被害が小さくなります。まずは認証ログを定期的に確認する習慣を持ちます。

sudo journalctl -u ssh --since "1 hour ago"

fail2banの遮断状況も合わせて確認します。

sudo fail2ban-client status sshd

本格的な監視が必要なら、ログ集約や外形監視のツール導入を検討しますが、最初は「認証失敗が急増していないか」を見るだけでも十分役立ちます。

⑩ バックアップ

どれだけ守っても侵害や障害はゼロにできません。復旧できる状態を用意しておくのが最後の砦です。

VPSサービスのスナップショット/イメージ保存機能を使う（最も手軽）
重要データ（設定・DB・コンテンツ）は別の場所にも退避する
「取れている」だけでなく復元できることを一度試す

DBがあれば定期ダンプを別ストレージへ送る運用にします（例）。

mysqldump -u root -p <DB名> > /backup/db_$(date +%F).sql

スナップショット任せにせず、最低限のデータは多重化しておきます。

まとめ

#	項目	最初の30分	運用に乗せる
1	OS更新	○	（自動化は⑦）
2	rootログイン無効化＋一般ユーザー	○
3	SSH鍵認証・パスワード無効	○
4	SSHポート変更	任意
5	ufw	○
6	fail2ban	○	○
7	自動セキュリティ更新		○
8	不要サービス停止		○
9	ログ監視		○
10	バックアップ		○

最優先は ②rootログイン無効化 → ③鍵認証 → ⑤ufw です。この3つで、契約直後のVPSが最も狙われる「root＋パスワード」の経路を塞げます。fail2banと自動更新を足せば、放置されがちな個人VPSとしては十分なラインに乗ります。作業中はログインセッションを常に1本残し、締め出しに備えてください。

各サービス公式

実際にハードニングを試すVPSとしては、料金と国内サポートのバランスから次の2つが定番です。どちらもUbuntu/Debianのテンプレートが選べ、スナップショット（⑩）にも対応しています。

ConoHa VPS: 時間課金とテンプレート（アプリケーションイメージ）が豊富。短期検証から本番まで使いやすい構成です。
Xserver VPS: 高クロックなCPUとシンプルな料金体系。国内データセンターで安定して使えます。

ConoHa VPS Xserver VPS

価格・プランの詳細な比較は法人向けVPSレンタルサーバー比較にまとめています。

セキュリティサーバーのファイアウォール設計 — ufw/iptablesとクラウドの使い分けセキュリティSSH鍵管理の崩壊パターンと修復手順：散乱した鍵を棚卸しして統制するセキュリティ自宅NASや社内サーバーに外から安全につなぐ方法【Tailscale / WireGuard】

記事一覧に戻る