Ubuntu 24.04のunattended-upgradesは標準で有効？

自動セキュリティ更新を設定する価値

パッチが適用されていないサーバーは、インターネット上で最も狙われやすい対象です。小規模サーバーの侵害の多くは巧妙なものではありません。所有者が更新しなかった古いパッケージに、既知のバグが残っていることが原因です。Ubuntu には、その差を自動的に埋めるツールがあります。unattended-upgradesは、ログインしなくても、スケジュールに従ってセキュリティ更新を自動的にインストールします。VPS で実施できる最も低コストなセキュリティ対策の 1 つであり、Ubuntu では数分で設定できます。

このツールは、意図的に保守的な動作をします。デフォルトでは、すべてのパッケージを更新せず、セキュリティ更新だけを適用します。セキュリティパッチはリスクが低く、確認なしで適用する価値があります。一方、機能更新では、利用中の動作が変わる可能性があります。ほとんどのサーバーでは、このデフォルト設定が適切です。このガイドでも設定を維持しつつ、変更する価値がある項目だけを説明します。

手順 1: インストールして有効化する

Ubuntu 24.04 では、パッケージがすでに存在することが多いものの、常に有効とは限りません。インストールして有効化します。

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

dpkg-reconfigureのプロンプトでは、安定版の更新を自動的にダウンロードしてインストールするかどうかを、yes または no で確認します。yes と答えてください。これにより、毎日のジョブを有効にするファイルが作成されます。

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

1 行目は毎日パッケージ一覧を更新します。2 行目は毎日 unattended upgrade を実行します。両方を 1 に設定すると、systemd timer により、マシンは毎日セキュリティ更新を確認して適用します。以後の操作は必要ありません。

手順 2: 自動的に適用する更新を決める

ポリシーは /etc/apt/apt.conf.d/50unattended-upgrades にあります。ファイルを開き、上部付近にある Allowed-Origins ブロックを確認します。

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

重要なのは -security の行で、デフォルトで有効になっています。これが保守的なポリシーです。セキュリティ更新は自動的に適用し、通常の機能更新は、必要なタイミングで手動適用します。"${distro_id}:${distro_codename}-updates" の origin 行を追加すると、すべての更新を自動適用できます。ただし、重要なサービスをホストするサーバーでは、セキュリティパッチだけを自動適用するほうが安全です。明確な理由がない限り、出荷時の設定のままにしてください。

手順 3: 再起動を処理する

カーネルやコアライブラリなど、一部の更新は再起動後に初めて完全に反映されます。unattended-upgrades は、明示的に設定しない限りサーバーを再起動しません。そのため、パッチが適用されたカーネルが、再起動するまで使われない状態になることがあります。再起動の扱いを決め、50unattended-upgrades に明示的に設定してください。

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

この設定では、更新に再起動が必要な場合に限り、午前 4 時にサーバーを再起動します。フェイルオーバー先のクラスタがない単一の VPS では、カーネル修正を最新に保つために、早朝の短時間の再起動を許容するのが通常は適切です。予期しない再起動が許されないサービスを実行している場合は、再起動を無効のままにし、/var/run/reboot-required を確認したうえで自分で再起動する習慣を付けてください。

手順 4: 動作を確認する

ジョブが実行されるか、1 日待って確認する必要はありません。何も変更せずに、適用される内容だけを表示する dry run を実行します。

sudo unattended-upgrade --dry-run --debug

出力には、対象として検討されたパッケージと、その取得元の origin が表示されます。これにより、ポリシーが実際に機能していることを確認できます。実際のジョブが少なくとも 1 回実行された後は、記録を次の場所で確認できます。

cat /var/log/unattended-upgrades/unattended-upgrades.log

このログで、サーバーが実際に自動でパッチを適用しているかを確認できます。スケジュールに従ってセキュリティパッケージがインストールされていれば、ジョブは正常に動作しています。

この設定の位置付け

自動更新は、サーバーを堅牢化するための 1 つの層であり、対策のすべてではありません。既知のバグが残り続けることは防げますが、誰がログインできるか、何が外部に公開されているかは制御しません。鍵認証だけを許可する SSH の堅牢化 と組み合わせて、入口への総当たり攻撃を防いでください。default-deny の UFW ファイアウォール と組み合わせて、選択した通信だけを到達可能にしてください。さらに、権限を持たないサービスユーザー を使用して、侵害されたアプリケーションからサーバー全体を操作されないようにします。ホストするアプリケーション自体にも、これらとは別に秘密情報があります。このサーバーで self-hosted のパスワード vault を実行する場合は、Vaultwarden の堅牢化 により、apt のパッチ適用だけでは保護できない管理者トークンとバックアップファイルも対策できます。パッチ適用は把握している脆弱性を塞ぎます。その他の層は、把握していない脆弱性による被害を抑えます。

FAQ

unattended-upgrades はすべての更新を適用しますか、それともセキュリティ更新だけですか？

デフォルトでは、セキュリティ更新だけを適用します。/etc/apt/apt.conf.d/50unattended-upgrades 内の Allowed-Origins ブロックにより、-security の origin が有効になり、通常の機能更新は手動適用の対象として残ります。これは意図した動作です。セキュリティパッチはリスクが低く、自動適用する価値があります。一方、機能更新では動作が変わる可能性があるため、ほとんどのサーバーでは保守的なデフォルト設定を維持すべきです。

自動更新によってサーバーは再起動されますか？

設定した場合に限り、再起動されます。設定ファイルで Unattended-Upgrade::Automatic-Reboot "true" と Automatic-Reboot-Time を設定すると、更新に再起動が必要な場合、指定した時刻にサーバーが再起動します。たとえば、カーネルパッチの適用後などです。無効のままにすると、パッチが適用されたカーネルは自分で再起動するまで使用されません。再起動が保留されているかどうかは /var/run/reboot-required で確認できます。

自動更新が実際に実行されているかどうかを確認するにはどうすればよいですか？

sudo unattended-upgrade --dry-run --debug を実行すると、何も変更せずに、現時点で適用される内容を確認できます。過去の実行記録は /var/log/unattended-upgrades/unattended-upgrades.log で確認できます。自動インストールの記録はすべて /var/log/apt/history.log にも保存されます。ログに、毎日のスケジュールに従ってセキュリティパッケージがインストールされた記録があれば、timer は動作しています。dry run の結果が No packages found that can be upgraded unattended になる場合は、すべて最新であるか、許可した origin の範囲が狭く、セキュリティリポジトリと一致していない可能性があります。

unattended-upgrades だけでサーバーの安全を維持できますか？

いいえ。ただし、必要な対策の 1 つです。既知の脆弱性にパッチが適用されないまま残ることを防ぎ、最も一般的な侵害を阻止します。しかし、アクセス制御や公開範囲は制御しません。SSH の堅牢化、default-deny のファイアウォール、最小権限のサービスユーザーを組み合わせることで、侵入されにくいサーバーにできます。