Ubuntuサーバーセキュリティチェックリスト100項目【本番前必読】

この記事のポイント

本番VPSに公開する前に確認したい100項目を、実際に Ubuntu 24.04 で動かして確認した一次データとともに解説します
SSH は ed25519 鍵認証＋パスワード認証の無効化が最低ライン。標準同梱の OpenSSH は 9.6p1（Ubuntu-3ubuntu13.16）で実確認しました
インストール直後の sshd は PasswordAuthentication yes・X11Forwarding yes のまま。sshd -T の実効値で確認済みです
Ubuntu 24.04 の fail2ban 1.0.2 は同梱設定で ban 方式が nftables に切り替わり、sshd jail がデフォルト有効になっていました
/etc/login.defs の PASS_MAX_DAYS は 99999（実質無期限）。本番では 90 日への変更を推奨します

注意

本記事のコマンドと実出力は、Docker公式イメージ ubuntu:24.04（Ubuntu 24.04.4 LTS）で 2026年6月14日に検証したものです。Ubuntu 22.04 やその他のバージョンでは、パッケージのバージョンやデフォルト挙動が異なります（差分は後半で実測比較します）。

「VPSを借りたけど、セキュリティ設定って何をどこまでやればいいの？」という疑問は、Linux 入門者がほぼ必ず通る道です。この記事では、本番公開前に確認したい100項目を、実際に Ubuntu 24.04 を動かして取得した一次データとともにまとめました。

ただ項目を並べるだけでなく、「なぜ必要か」「コマンドを打つと実際に何が表示されるか」を具体的に示します。Ubuntu公式ドキュメントも、セキュリティは単一の防御に頼らず層で守る（layered approach）べきだと述べています。下のスクリーンショットは、その公式ガイダンスの冒頭です。

Ubuntu Server公式ドキュメント「Introduction to security」（実撮影）

目次
初期設定・アップデート
SSH 設定
ファイアウォール UFW 設定
ブルートフォース対策 fail2ban
自動アップデート設定
ユーザー管理・権限
AppArmor・ファイル権限
ログ管理・監査
定期監視・点検
ネットワーク・サービス管理
Ubuntu 22.04 と 24.04 の違い
まとめ

初期設定・アップデート（10項目）
SSH 設定（15項目）
ファイアウォール UFW（10項目）
ブルートフォース対策 fail2ban（10項目）
自動アップデート設定（5項目）
ユーザー管理・権限（10項目）
AppArmor・ファイル権限（10項目）
ログ管理・監査（10項目）
定期監視・点検（10項目）
ネットワーク・サービス管理（10項目）

初期設定・アップデート

VPS を借りて最初にやるべきことから始めます。ここをサボると、後のセキュリティ設定がすべて台無しになります。

まず、このチェックリストで使うセキュリティ関連パッケージの実バージョンを確認しておきましょう。apt-cache policy で候補バージョンを実取得した結果が次の表です。

注目は fail2ban です。Ubuntu 22.04 の 0.11.2 系から 1.0.2-3ubuntu0.1 へ世代交代しており、後述のとおりデフォルトの ban 方式まで変わっています。

①システムを最新の状態に更新する

ubuntu@your-vps: ~

$ sudo apt update && sudo apt upgrade -y
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Reading package lists… Done
Building dependency tree… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

✅ apt update && apt upgrade -y を実行し、最新の状態にした
✅ apt dist-upgrade -y でカーネルを含めて更新した
✅ カーネル更新後は reboot で再起動し、uname -r で適用を確認した

②不要なパッケージを削除する

ubuntu@your-vps: ~

$ sudo apt autoremove -y && sudo apt autoclean
Reading package lists… Done
Building dependency tree… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

✅ apt autoremove で不要な依存パッケージを削除した
✅ インストール済みサービスを確認し、不要なものを apt remove した
✅ ss -tlnp でリスニングポートを確認し、不要なポートを把握した

③ホスト名とタイムゾーンを設定する

ubuntu@your-vps: ~

$ sudo hostnamectl set-hostname myserver
$ hostnamectl status
Static hostname: myserver
Operating System: Ubuntu 24.04.4 LTS
$ sudo timedatectl set-timezone Asia/Tokyo

✅ hostnamectl set-hostname でホスト名を設定した
✅ /etc/hosts に 127.0.1.1 myserver を追加した
✅ timedatectl set-timezone Asia/Tokyo でタイムゾーンを設定した
✅ cat /etc/os-release で Ubuntu 24.04.4 LTS を使っていることを確認した

SSH 設定

SSH はサーバーへの玄関口です。ここが弱いと他のすべてが無意味になるので、SSH 設定は最優先で行うべき箇所です。

まず、Ubuntu 24.04 にインストールした直後の sshd が実際にどんな設定で動くのかを sshd -T（実効設定のダンプ）で確認しました。本番前に直すべき項目を色分けしたのが次の図です。

とくに PasswordAuthentication yes と X11Forwarding yes が、何もしなくても有効になっている点に注意してください。X11Forwarding yes は Ubuntu の openssh-server パッケージが /etc/ssh/sshd_config に明示設定しているもので、公式 man ページにもその旨が書かれています。

Ubuntu manpages の sshd_config(5)。X11Forwarding yes がパッケージ既定であることを明記（実撮影）

①SSH鍵認証を設定する（最重要）

OpenSSH 9.6p1 では ed25519 鍵を推奨します。実際にコンテナ内で鍵を生成すると、ed25519 の公開鍵はわずか97バイト、RSA 4096bit は741バイトでした。短くて強い ed25519 が第一選択です。

あなたのPC（接続元）: ~

$ ssh-keygen -t ed25519 -C “you@example.com”
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): ← パスフレーズを設定する
Your identification has been saved in /home/user/.ssh/id_ed25519
The key fingerprint is:
SHA256:QgghidFBtA8QTm90W8UcKXl+Za5eyS1yD9c+jaP0eVA you@example.com
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@YOUR_SERVER_IP
Number of key(s) added: 1

✅ ローカルで ssh-keygen -t ed25519 で鍵ペアを生成した
✅ パスフレーズを設定した（空のパスフレーズは NG）
✅ ssh-copy-id で公開鍵をサーバーに転送した
✅ ~/.ssh/authorized_keys のパーミッションが 600 になっている
✅ パスワード認証を無効化する前に、鍵認証でログインできることを確認した

②sshd_config を強化する

ubuntu@your-vps: ~

$ sudo nano /etc/ssh/sshd_config.d/99-hardening.conf
# 以下を記述する（sshd_config.d 配下が読み込まれる）
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers ubuntu
$ sudo sshd -t && sudo systemctl reload ssh
# エラーなし = 設定ファイルは正常

注意

実測した sshd -T の初期値は passwordauthentication yes / permitrootlogin without-password / maxauthtries 6 / clientaliveinterval 0 でした。PasswordAuthentication no に変える前に、必ず別ターミナルで鍵ログインを確認してください。間違えると締め出されます。sshd -t で文法チェックをしてから systemctl reload するのが安全です。

✅ PermitRootLogin no に設定した（初期値 without-password から変更）
✅ PasswordAuthentication no に設定した（初期値 yes から変更）
✅ X11Forwarding no に設定した（初期値 yes から変更）
✅ MaxAuthTries 3 に設定した（初期値 6 から変更）
✅ ClientAliveInterval 300 でアイドルタイムアウトを設定した（初期値 0）
✅ AllowUsers ubuntu で SSH 許可ユーザーを限定した
✅ Port をデフォルト以外に変更した（任意）
✅ sshd -t で設定ファイルのシンタックスを確認した
✅ systemctl reload ssh で設定を反映した
✅ 変更後も鍵認証でログインできることを再確認した

③SSH 接続元 IP を制限する（UFW で）

ubuntu@your-vps: ~

$ sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
Rule added
$ sudo ufw deny 22
Rule added

✅ 自分の固定 IP からのみ SSH 接続を許可した
✅ その他 IP からのポート 22 へのアクセスを拒否した
✅ IP が変わる環境では fail2ban で代替保護している

ファイアウォール UFW 設定

UFW（Uncomplicated Firewall）は Ubuntu 標準のファイアウォール管理ツールです。実際に ubuntu:24.04 で確認したところ、バージョンは 0.36.2 で、/etc/default/ufw の入力ポリシーはすでに DEFAULT_INPUT_POLICY="DROP"（全ブロック）に設定されていました。

ubuntu@your-vps: ~

$ sudo apt install -y ufw
Setting up ufw (0.36.2-6) …
$ sudo ufw default deny incoming
Default incoming policy changed to ‘deny’
$ sudo ufw default allow outgoing
Default outgoing policy changed to ‘allow’
$ sudo ufw allow ssh
Rule added
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed (y|n)? y
Firewall is active and enabled on system startup

ここが落とし穴です。/etc/default/ufw がインストール直後から DROP でも、UFW 自体を ufw enable するまでは何も遮断しません。必ず enable まで実行してください。

✅ ufw default deny incoming を設定した
✅ ufw default allow outgoing を設定した
✅ ufw allow ssh（または ufw allow 22/tcp）を実行した
✅ ufw enable でファイアウォールを有効化した
✅ ufw status verbose で設定を確認した
✅ Web サーバーを使う場合のみ ufw allow 80/tcp / 443/tcp を追加した
✅ 不要なポートが開いていないことを確認した
✅ ufw logging on でログを有効化した
✅ VPS のパネル側ファイアウォールも確認した（二重防御）
✅ /etc/default/ufw の IPV6=yes を確認した（実測でも yes）

ブルートフォース対策 fail2ban

インターネットに公開したサーバーには、数分以内に SSH 総当たり攻撃が来ます。正直、想像以上に早いです。fail2ban は指定回数以上ログインに失敗した IP を自動でブロックします。

Ubuntu 24.04 の fail2ban 1.0.2 には重要な変更があります。実際に設定ファイルを直接読み出したところ、デフォルト設定が2層構造になっていました。

上流の /etc/fail2ban/jail.conf は banaction = iptables-multiport ですが、Ubuntu が同梱する /etc/fail2ban/jail.d/defaults-debian.conf がそれを banaction = nftables / backend = systemd に上書きし、さらに [sshd] jail を enabled = true にしています。つまりインストールした瞬間から nftables ベースで SSH を守り始めます。

ubuntu@your-vps: ~

$ sudo apt install -y fail2ban
Setting up fail2ban (1.0.2-3ubuntu0.1) …
$ cat /etc/fail2ban/jail.d/defaults-debian.conf
[DEFAULT]
banaction = nftables
backend = systemd
[sshd]
enabled = true
$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter |- Currently failed: 0 `- Total failed: 0
`- Actions `- Total banned: 0

✅ fail2ban をインストールした（実測バージョン 1.0.2-3ubuntu0.1）
✅ systemctl enable fail2ban で自動起動を有効化した
✅ fail2ban-client status で sshd jail が動作していることを確認した
✅ /etc/fail2ban/jail.local を作成し、設定をカスタマイズした
✅ bantime を 1h 以上（デフォルト 10m より長く）に設定した
✅ maxretry = 3 に減らした（デフォルト 5 より厳しく）
✅ ignoreip に自分の IP を追加した（誤 ban 防止）
✅ ban 方式が nftables であることを把握した（22.04 の iptables 前提手順を混在させない）
✅ fail2ban-client set sshd unbanip <IP> の使い方を把握した（緊急時用）
✅ /var/log/fail2ban.log を毎週確認する仕組みを作った

jail.local の推奨設定（実測デフォルトからの変更点）

bantime = 1h（実測デフォルト 10m から延長）
findtime = 10m（実測デフォルトと同じ。この時間内に maxretry 回失敗でブロック）
maxretry = 3（実測デフォルト 5 より厳しく）
ignoreip = 127.0.0.1 ::1 YOUR_HOME_IP（自分の IP は除外）

自動アップデート設定

unattended-upgrades を使うと、セキュリティアップデートを自動で適用できます。Ubuntu 24.04 では apt-cache policy の候補が 2.9.1+nmu4ubuntu1 で、インストール後は 20auto-upgrades が生成されます。

ubuntu@your-vps: ~

$ sudo apt install -y unattended-upgrades
Setting up unattended-upgrades (2.9.1+nmu4ubuntu1) …
$ cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists “1”;
APT::Periodic::Unattended-Upgrade “1”;

✅ unattended-upgrades をインストールした
✅ /etc/apt/apt.conf.d/20auto-upgrades で自動更新が有効になっている
✅ 50unattended-upgrades でセキュリティアップデートのみ自動適用している
✅ Unattended-Upgrade::Mail でメール通知を設定した（任意）
✅ 月に一度は apt list --upgradable で手動確認する習慣をつけた

ユーザー管理・権限

「root でログインしっぱなし」は論外ですが、デフォルトの /etc/login.defs を実測すると、パスワード有効期限が 99999 日（約273年＝実質無期限）に設定されていることが分かります。UID 0（管理者権限）のユーザーは root だけで、SUID 付き実行ファイルはクリーン環境で8個でした。

ubuntu@your-vps: ~

$ grep -E ‘(PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|UMASK)’ /etc/login.defs
PASS_MAX_DAYS 99999 ← 要変更: 90 程度に
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
UMASK 022
$ awk -F: ‘$3 == 0 {print $1}’ /etc/passwd
root
# root だけなら OK（他が表示されたら要調査）

✅ root 直接ログインを使わず、一般ユーザー＋sudo を使っている
✅ adduser username で一般ユーザーを作成し、usermod -aG sudo username で sudo 権限を付与した
✅ awk -F: '$3 == 0 {print $1}' /etc/passwd で UID 0 が root のみであることを確認した
✅ /etc/login.defs の PASS_MAX_DAYS を 90 に変更した（実測 99999 から）
✅ 使用していないシステムアカウントの shell を /usr/sbin/nologin に変更した
✅ chage -l username でパスワード有効期限を確認した
✅ sudo visudo で sudoers ファイルを安全に編集した
✅ 不要なユーザーを userdel -r username で削除した
✅ last でログイン履歴を確認した
✅ who で現在のログインユーザーを確認した

AppArmor・ファイル権限

AppArmor はプログラムがアクセスできるリソースを制限する仕組みで、Ubuntu 24.04 に標準同梱されています（apt-cache policy の候補は 4.0.1really4.0.1-0ubuntu0.24.04.7）。

ubuntu@your-vps: ~

$ sudo aa-status
apparmor module is loaded.
profiles are loaded.
$ find /usr/bin /usr/sbin /bin -perm -4000 -type f 2>/dev/null
/usr/bin/chfn /usr/bin/chsh /usr/bin/gpasswd
/usr/bin/mount /usr/bin/newgrp /usr/bin/passwd
/usr/bin/su /usr/bin/umount
# クリーン環境では SUID は8個（実測）

✅ aa-status（または apparmor_status）で AppArmor が動作していることを確認した
✅ systemctl enable apparmor で自動起動を有効化した
✅ find / -perm -4000 -type f 2>/dev/null で SUID ファイルを確認した（実測8個が基準）
✅ find / -perm -2000 -type f 2>/dev/null で SGID ファイルを確認した
✅ /etc/passwd と /etc/shadow のパーミッションを確認した
✅ /etc/shadow が 640 または 000 であることを確認した
✅ Web 公開ディレクトリに不要な書き込み権限がないことを確認した
✅ umask が 022 または 027 になっている（実測デフォルト 022）
✅ /tmp に noexec を設定した（/etc/fstab 編集・任意）
✅ 重要ファイルに chattr +i で変更不可属性を設定した（任意）

ログ管理・監査

問題が起きたときに「何が起きたか」を追えるのがログです。ログがなければ原因調査もインシデント対応もできません。

ubuntu@your-vps: ~

$ sudo apt install -y auditd
Setting up auditd (1:3.1.2-2.1build1.1) …
$ sudo systemctl enable –now auditd
$ sudo journalctl -u ssh –since “24 hours ago” | tail -5
… sshd[1234]: Accepted publickey for ubuntu …

✅ auditd（実測 1:3.1.2-2.1build1.1）をインストールして自動起動を有効化した
✅ journalctl -u ssh で SSH ログを定期確認している
✅ /var/log/auth.log でログイン試行を確認した
✅ ログの保存期間を確認・設定した（/etc/logrotate.d/）
✅ systemctl status rsyslog で rsyslog が動作していることを確認した
✅ sudo 使用が /var/log/auth.log で確認できる
✅ ログを外部ストレージにバックアップしている（任意）
✅ last で直近のログインを確認した
✅ lastb でログイン失敗の記録を確認した
✅ 異常なログインを検知したらメール通知が来る仕組みを作った

定期監視・点検

セキュリティ設定は一度やれば終わりではなく、継続的な監視が必要です。

ubuntu@your-vps: ~

$ sudo apt install -y rkhunter
Setting up rkhunter (1.4.6-12) …
$ sudo rkhunter –update && sudo rkhunter –check
File properties checks… Passed
Rootkit checks… Passed

✅ rkhunter（実測 1.4.6-12）をインストールして定期スキャンを設定した
✅ apt list --upgradable で月に一度アップデートを確認している
✅ ss -tlnp で開放ポートを定期確認している
✅ ps aux で不審なプロセスがないか確認している
✅ crontab -l と ls /etc/cron* で cron ジョブを確認した
✅ fail2ban-client status sshd で ban 状況を定期確認している
✅ df -h でディスク使用量の異常な増加を監視している
✅ top / htop で不審な高負荷プロセスを把握している
✅ find /tmp /var/tmp -mtime -1 -type f 2>/dev/null で直近24時間の新規ファイルを確認した
✅ 月に一度、本チェックリストを再実行している

ネットワーク・サービス管理

サービスを絞り込んで攻撃面を最小化することが重要です。

ubuntu@your-vps: ~

$ sudo ss -tlnp
State Local Address:Port Process
LISTEN 0.0.0.0:22 users:((“sshd”,pid=123,fd=3))
# SSH 以外のポートが開いていないことを確認
$ systemctl list-units –type=service –state=running
fail2ban.service loaded active running Fail2Ban Service
ssh.service loaded active running OpenBSD Secure Shell server

✅ ss -tlnp で不要なポートが開いていないことを確認した
✅ 不要なサービスを systemctl disable --now <service> で無効化した
✅ systemctl list-units --state=failed で失敗サービスがないか確認した
✅ DNS 設定（systemd-resolved / /etc/resolv.conf）が正常であることを確認した
✅ ss -antp でネットワーク接続状況を確認した
✅ 外部向け通信に HTTPS を使用し、平文 HTTP は避けている
✅ 必要に応じて VPN（WireGuard など）を設定した
✅ Nginx/Apache を使う場合はバージョン表示（Server トークン）を無効化した
✅ timedatectl status で NTP 時刻同期が正常であることを確認した
✅ ufw status numbered でルールを番号付きで確認した

Ubuntu 22.04 と 24.04 の違い

「22.04 の記事を見ながら 24.04 を設定したら噛み合わない」という事故は地味に多いです。同じ確認スクリプトを両バージョンのコンテナで実行し、セキュリティ既定値の差を実測しました。

最大の違いは fail2ban です。22.04 は同梱の defaults-debian.conf に banaction 指定が無く iptables を使いますが、24.04 では nftables に切り替わります。一方、X11Forwarding yes と PASS_MAX_DAYS 99999 はどちらのバージョンも手動で直す必要があり、バージョンを上げただけでは安全になりません。