Ubuntu 24.04 LTSのPCで「何が勝手に起動しているのか分からない」まま使っていませんか。systemd-analyze security と systemctl list-unit-files --state=enabled の2つを使えば、自動起動サービスの棚卸しはコマンドだけで完結します。この記事では、UNSAFE判定の読み方、止めてよいサービスの見分け方、止めたあとに元へ戻す手順まで、初心者が自分の環境で手を動かせる粒度で解説します。

まず前提：systemdの「ユニット」と「enabled」が何を指すのか

Ubuntu 24.04 LTSやDebian 13（trixie、2025年8月9日リリース、最新は2026年7月11日の13.6）では、バックグラウンドで動く常駐プログラムをsystemdという仕組みが管理しています。ここで出てくる用語を先に短く言い換えておきます。

  • ユニット（unit）：systemdが管理する対象の設定ファイル1個。サービスなら xxx.service という名前です。
  • enabled：起動時に自動で立ち上がる設定になっている状態。「自動起動オン」と読み替えてください。
  • active（running）：いま実際に動いている状態。enabledとactiveは別物で、「自動起動オンだが今は止まっている」も「自動起動オフだが今は動いている」もあり得ます。
  • サンドボックス：サービスができることをOS側で先に制限しておく仕組み。ファイルを読める範囲、使えるシステム機能などを狭めます。

今回の点検は、この「自動起動オンの一覧」を出し、それぞれがどれだけ無防備に動いているかをスコアで見ていく作業です。この記事のコマンドの大半は読み取りのみで、システムを変更しません。変更を伴うコマンドには、その都度「変更あり」と明記します。

この記事で使うコマンドの権限と副作用の一覧

コマンド

sudo

副作用

元に戻せるか

systemctl list-unit-files --state=enabled

不要

なし（読み取りのみ）

―

systemd-analyze security

不要

なし（読み取りのみ）

―

systemctl status / cat

不要

なし（読み取りのみ）

―

ss -tulpn

推奨（プロセス名表示に必要）

なし（読み取りのみ）

―

systemctl stop

必要

今すぐ停止（再起動で復活）

start で戻る

systemctl disable --now

必要

自動起動オフ＋即停止

enable --now で戻る

systemctl mask

必要

起動を完全に封じる（依存関係経由も不可）

unmask で戻る

drop-inでの設定強化

必要

ユニット設定を上書き

ファイル削除＋daemon-reloadで戻る

手順1：systemctl list-unit-files --state=enabled で自動起動オンの一覧を出す

最初に、起動時に自動で立ち上がる設定になっているユニットだけを抜き出します。これが棚卸しの母集団です。

systemctl list-unit-files --type=service --state=enabled --no-pager

何を見ているか：/lib/systemd/system や /etc/systemd/system にあるサービス定義ファイルのうち、自動起動オンのものだけです。sudoは不要、読み取りのみです。

出力例（Ubuntu 24.04 LTSのデスクトップ環境、抜粋）：

UNIT FILE                          STATE   PRESET
apport.service                     enabled enabled
avahi-daemon.service               enabled enabled
bluetooth.service                  enabled enabled
cups.service                       enabled enabled
cups-browsed.service               enabled enabled
ModemManager.service               enabled enabled
NetworkManager.service             enabled enabled
ssh.service                        enabled enabled
systemd-timesyncd.service          enabled enabled
unattended-upgrades.service        enabled enabled

10 unit files listed.

どこを見て「不要」を判断するか

ここで見るべきは3列目まで全部ではなく、1列目のサービス名と、そのサービスが自分の使い方に必要かどうかだけです。判断の軸は次の3つに絞ると迷いません。

  1. そのハードウェアを持っているか：ModemManager.service はモバイル回線用モデムの管理です。ノートPCでWi-Fiと有線しか使わないなら出番はありません。bluetooth.service もBluetooth機器を使わないなら不要です。
  2. その機能を実際に使っているか：cups.service（印刷）と cups-browsed.service（ネットワーク上のプリンタ自動検出）、avahi-daemon.service（同じLAN内の機器を自動発見する仕組み）は、印刷もファイル共有もしないサーバーでは丸ごと不要です。この3つは外部と通信する常駐サービスなので、優先的に見直す価値があります。詳しい止め方はCUPS・Avahi点検2026年8月版｜不要サービスの止め方で個別に扱っています。
  3. 外から接続を受けているか：ssh.service のように待ち受けポートを開くものは、必要でも設定の点検が要ります（手順4で扱います）。

逆に、名前に見覚えがなくても消してはいけないものがあります。systemd- で始まるユニット、NetworkManager.service、dbus.service、unattended-upgrades.service（セキュリティ更新の自動適用）などはOSの土台です。特に unattended-upgrades.service は「常駐が増えるから止める」と考えがちですが、これを止めると脆弱性修正が届かなくなります。止めるべきサービスの筆頭ではなく、有効であることを確認すべきサービスです。

いま実際に動いているものだけを見る

enabledの一覧には「設定はオンだが今は動いていない」ものが混ざります。実際に動いている常駐だけを見るなら次を使います。

systemctl list-units --type=service --state=running --no-pager

出力例：

UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
cups.service             loaded active running CUPS Scheduler
NetworkManager.service   loaded active running Network Manager
ssh.service              loaded active running OpenBSD Secure Shell server
...

判断ポイント：LOADが loaded、ACTIVEが active、SUBが running なら正常稼働です。ここに failed が出ているものがあれば、それは設定ミスか異常終了なので、次のコマンドで原因を確認します。

systemctl --failed --no-pager
journalctl -u 対象のサービス名 -n 50 --no-pager

正常なら 0 loaded units listed. と出ます。何か並んだ場合は、そのサービス名で journalctl の直近50行を読み、Failed to start の前後にある理由（設定ファイルの行番号やポート競合など）を見ます。sudoは不要ですが、自分以外のサービスのログを見るには sudo が必要な場合があります。

手順2：systemd-analyze security でUNSAFE判定を洗い出す

ここからが本題です。systemd-analyze security は、各サービスがどれだけサンドボックス設定を効かせているかを採点し、0.0〜10.0のexposure（露出度）スコアで返します。数字が大きいほど「守りが薄い＝乗っ取られたときに好き放題される余地が大きい」という意味です。

systemd-analyze security --no-pager

何を見ているか：実際の脆弱性ではなく、ユニット設定に書かれた制限（権限の削減、ファイルシステムの読み取り専用化、システムコール制限など）の有無です。sudoは不要、読み取りのみで、設定を一切変更しません。

出力例（Ubuntu 24.04 LTS、抜粋）：

UNIT                        EXPOSURE PREDICATE HAPPY
avahi-daemon.service             9.5 UNSAFE    😨
cups.service                     9.6 UNSAFE    😨
ssh.service                      9.6 UNSAFE    😨
ModemManager.service             8.2 EXPOSED   🙁
NetworkManager.service           7.8 EXPOSED   🙁
polkit.service                   6.1 MEDIUM    😐
systemd-timesyncd.service        2.1 OK        🙂
systemd-resolved.service         2.2 OK        🙂
systemd-logind.service           2.8 OK        🙂

スコアの読み方と、勘違いしやすい点

EXPOSURE

判定

意味

0.0〜1.9

OK

サンドボックスがよく効いている

2.0〜4.9

MEDIUM

ある程度制限されている

5.0〜7.9

EXPOSED

制限が薄い

8.0〜9.9

UNSAFE

ほぼ無制限にrootで動ける

10.0

UNSAFE

制限なし

ここで最も大事な注意点です。UNSAFEは「そのサービスが危険」でも「侵入されている」でもありません。「設定上、守りの網が張られていない」という意味です。ssh.service が9.6でUNSAFEなのはUbuntuの標準状態であり、SSHの性質上（任意ユーザーでログインセッションを起こすため）強い制限をかけられないからです。UNSAFEを見て慌ててSSHを止めると、リモートサーバーなら自分が締め出されます。

そこで、優先順位は次の順で考えます。

  1. UNSAFE かつ 自分に不要 → 止める候補（最優先。手順3）
  2. UNSAFE かつ 必要 かつ 外部から接続を受ける → 設定を点検して守る（手順4）
  3. UNSAFE かつ 必要 かつ 外部に開いていない → 急いで触らなくてよい
  4. OK / MEDIUM → 基本そのまま

1つのサービスを深掘りする

気になったサービスは、名前を付けて実行すると項目ごとの内訳が出ます。

systemd-analyze security cups.service --no-pager

出力例（抜粋）：

NAME                DESCRIPTION                             EXPOSURE
PrivateNetwork=     Service has access to the host's network     0.5
User=/DynamicUser=  Service runs as root user                    0.4
CapabilityBoundingSet=~CAP_SYS_ADMIN  Service has admin privileges  0.3
ProtectHome=        Service has full access to home directories  0.2
PrivateDevices=     Service potentially has access to hardware devices 0.2
...
→ Overall exposure level for cups.service: 9.6 UNSAFE 😨

判断ポイント：DESCRIPTIONが「Service runs as root user」「full access to home directories」「access to the host's network」となっている行が、そのサービスに与えられている力です。印刷サービスがホームディレクトリへフルアクセスできる必要が本当にあるか、という具体的な問いに落とし込めます。

他ディストリでの違い

  • Debian 13（trixie）：コマンドも出力形式も同じです。ただしデスクトップ環境を入れない構成だと cups や avahi-daemon がそもそも入っていないことが多く、enabledの一覧は短くなります。
  • RHEL 9.8 / 10.2（ともに2026年5月19日リリース、カーネルは順に5.14.0-687.5.1.el9_8、6.12.0-211.7.1.el10_2）：systemdなので同じコマンドが使えますが、パッケージ名が異なり（例：SSHは sshd.service、Ubuntu/Debianは ssh.service）、ファイアウォールは ufw ではなく firewalld（最新安定版は2.5.1、2026年8月7日リリース）が標準です。またSELinuxが有効なため、exposureスコアが高くてもSELinuxポリシー側で追加の制限がかかっている点は割り引いて読む必要があります。Linux Kernel 7.2（2026年8月16日リリース）ではそのSELinuxポリシー検証が全面的に見直されました。
  • systemdを使わない環境（一部の軽量ディストリ）：この記事の手順は使えません。

手順3：ss -tulpn で外に開いているポートと突き合わせ、止める判断をする

UNSAFEなサービスのうち実際に外部から接続を受けているものは、優先度が跳ね上がります。それを確認するのが ss です（netstat の後継で、Ubuntu 24.04・Debian 13ともに標準で入っています）。

sudo ss -tulpn

何を見ているか：いま接続待ち受け状態にあるTCP/UDPポートと、それを開いているプロセス名です。オプションはt=TCP、u=UDP、l=待ち受け中のみ、p=プロセス名、n=名前解決せず数字表示。読み取りのみで変更はしませんが、プロセス名を表示するにはsudoが必要です。

出力例：

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
udp   UNCONN 0      0      0.0.0.0:5353        0.0.0.0:*     users:(("avahi-daemon",pid=812,fd=12))
udp   UNCONN 0      0      127.0.0.54:53       0.0.0.0:*     users:(("systemd-resolve",pid=740,fd=18))
tcp   LISTEN 0      4096   127.0.0.1:631       0.0.0.0:*     users:(("cupsd",pid=1033,fd=7))
tcp   LISTEN 0      128    0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=955,fd=3))

どこを見て正常／異常を判断するか

見るべきは Local Address:Port の左側（IPアドレス部分）です。ここが判断の分かれ目になります。

  • 127.0.0.1 または ::1：自分のPCの中からしか接続できません。外部に露出していないので、優先度は低くなります。上の例の 127.0.0.1:631（CUPSの管理画面）はこれに該当します。
  • 0.0.0.0 または * や ::：すべてのネットワークから接続を受け付けます。上の例の 0.0.0.0:22（SSH）と 0.0.0.0:5353（Avahi）がこれです。ここに並ぶものが、外から触れる面そのものです。
  • Processの列に心当たりのない名前がある：まずそれがパッケージ由来か確認します。

心当たりのないプロセスが出た場合の次の一手はこれです（すべて読み取りのみ）。

sudo ls -l /proc/该当PID/exe
dpkg -S /usr/sbin/該当の実行ファイル名
systemctl status 該当のサービス名 --no-pager

dpkg -S が cups: /usr/sbin/cupsd のようにパッケージ名を返せば、正規にインストールされたものです。no path found matching pattern と返る場合は、パッケージ管理外のバイナリなので、自分で入れた覚えがあるかを確認します。覚えがなければ、ログイン履歴の点検に進むのが筋です（last/lastbログイン監査2026年8月版｜侵入痕跡の見方）。

実際に止める：stop → disable → mask の3段階

止めると決めたら、いきなり削除せず、戻せる順に段階を踏みます。ここからは設定変更を伴います。

段階

コマンド

効果

戻し方

1. 一時停止

sudo systemctl stop cups.service

今だけ止める。再起動で復活

sudo systemctl start cups.service

2. 自動起動オフ

sudo systemctl disable --now cups.service

停止＋次回起動でも立ち上がらない

sudo systemctl enable --now cups.service

3. 封鎖

sudo systemctl mask cups.service

他サービスからの依存起動も含め完全に封じる

sudo systemctl unmask cups.service

推奨はまず1で数日〜1週間ふつうに使ってみて、困らなければ2に進むやり方です。印刷やスキャナ、AirPrint、ネットワーク上のNAS自動検出など、止めて初めて気づく用途があるためです。cups.service を止める場合は cups.socket と cups.path も一緒に止めないと、印刷要求が来た瞬間に再起動される点に注意してください。

sudo systemctl disable --now cups.service cups.socket cups.path

3のmaskは効き目が強く、依存している他のサービスが起動できなくなる副作用があります。使うのは「disableしたのに何かに引きずられて起動してしまう」と確認できたときだけで十分です。

止めたあとは、同じコマンドで結果を確かめます。

systemctl is-enabled cups.service
systemctl is-active cups.service
sudo ss -tulpn | grep 631

期待する出力は disabled、inactive、そして grep は何も表示されない（ポートが閉じた）状態です。maskした場合は is-enabled が masked と返ります。

手順4：止められないUNSAFEを守る（SSHとファイアウォール）

SSHのように必要だがUNSAFEなサービスは、止めるのではなく設定で締めます。ここは設定変更を伴うので、リモートサーバーの場合は必ず別のSSHセッションを開いたまま作業してください。締め出されたときの逃げ道になります。

まず現状のSSH設定を読む（変更なし）

sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|port|pubkeyauthentication|maxauthtries)"

何を見ているか：設定ファイルの記述ではなく、sshdが実際に採用している最終的な設定値です。/etc/ssh/sshd_config.d/ 配下の追加ファイルまで合成した結果が出るので、「設定したのに効かない」の取り違えを防げます。読み取りのみです。

出力例と、望ましい値：

port 22
permitrootlogin prohibit-password
passwordauthentication yes
pubkeyauthentication yes
maxauthtries 6

項目

望ましい値

この例の判定

permitrootlogin

no（rootで直接ログインさせない）

要改善

passwordauthentication

no（鍵認証のみにする）

要改善

pubkeyauthentication

yes

OK

maxauthtries

4程度

許容

passwordauthentication が yes だと、パスワードの総当たり攻撃の的になります。2026年時点では公開鍵認証が事実上の標準で、鍵の種類はEd25519が推奨です。RSA 4096ビットより計算量が少なく、ノートPCやモバイル環境での接続の待ち時間が短くて済みます。

変更する場合は、元ファイルを直接編集せず、上書き用のファイルを1枚足すのが安全です。戻すときはそのファイルを消すだけで済みます。

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 4
EOF
sudo sshd -t && sudo systemctl reload ssh

重要なのは sshd -t です。これは設定ファイルの文法チェックで、問題なければ何も出力しません。エラーが出た場合は行番号が表示されるので、reloadせずに sudo rm /etc/ssh/sshd_config.d/99-hardening.conf で元に戻せます。鍵認証の設定を済ませる前にPasswordAuthentication noを入れると、自分がログインできなくなります。必ず、別端末から鍵でログインできることを確認してから適用してください。

OpenSSHのバージョンを確認する

ssh -V
apt list --installed 2>/dev/null | grep openssh-server

2026年8月時点の上流最新はOpenSSH 10.5/10.5p1（2026年8月11日リリース）です。ただしUbuntu/Debianはバージョン番号を上げずに修正だけを取り込む（バックポート）方式なので、ssh -V の数字が古く見えても、apt list --installed のパッケージ版数（末尾に ubuntu0.x などが付く）が最新なら修正は入っています。数字だけ見て「古い＝危険」と判断しないことが判断のコツです。

なお、OpenSSH 10.3p1（2026年4月2日リリース）では、ProxyJump オプションでユーザー名・ホスト名が検証されずに渡されるシェル・インジェクションの脆弱性と、sshdで「principals」セクションが空のSSH証明書がワイルドカード扱いされ、意図せず広範なアクセスを許しうる挙動が修正されました。後者はSSH証明書を使っている環境だけの話ですが、見落としやすい設定不備です。OpenSSHチームはAIモデルによる脆弱性報告の増加を受け、修正を早く届けるためリリース頻度を増やす方針を示しています。更新を止めないことが、この領域では最も費用対効果が高い対策です。 ファイアウォールの状態を確認する sudo ufw status verbose Ubuntuでは ufw が標準です。読み取りのみです。出力例： Status: inactive Status: inactive なら、ファイアウォールは何もしていません。有効な場合はこう出ます。 Status: active Default: deny (incoming), allow (outgoing), disabled (routed) To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere 判断ポイントはDefault行の deny (incoming)と、To列に並んでいるポートが手順3の ss の結果と一致しているかです。使っていないポートが許可されていたら削除対象になります。有効化する場合は、SSHの許可を先に入れてからにしてください。順番を間違えるとリモート接続が切れます。 sudo ufw allow 22/tcp sudo ufw enable 戻すには sudo ufw disable です。RHEL系では firewalld（2.5.1）を使い、sudo firewall-cmd --list-all で同等の確認ができます。なおfirewalldのtimed rulesは接続数の全体制限はできても、IPアドレスごとの拒否は扱えません。不正なログイン試行をIP単位で弾きたい場合は fail2ban（Debian testingでは1.1.0-11が2026年8月2日にmigrated、上流は1.1.1.beta0が2026年5月6日リリース）との併用が必要です。 手順5：見つかった問題への対処と、点検の定期化 症状別・次にやること 見つかった状態次の一手緊急度 不要なUNSAFEサービスがenabledstop で数日様子見 → disable --now中 0.0.0.0 で待ち受け中の身に覚えのないポートdpkg -S でパッケージ由来か確認 → 不明ならログイン履歴を点検高 passwordauthentication yes鍵認証（Ed25519）を設定 → drop-inで no に高 ufw status が inactiveSSH許可を入れてから ufw enable中 systemctl --failed に何か出るjournalctl -u で直近ログを確認中 unattended-upgrades が無効sudo systemctl enable --now unattended-upgrades高 OSのサポート期限は「設定より先に効く」点検項目 どれだけサービスを絞っても、セキュリティ修正が届かないOSではすべてが無意味になります。まず自分のOSの期限を確認してください。 lsb_release -a cat /etc/os-release 2026年8月時点の期限は次のとおりです。 Debian 11（Bullseye）：2026年8月31日にLTSサポート完全終了。使っている場合は最優先でDebian 12（bookworm、2028年6月まで）以降への移行を。 Debian 12：2028年6月まで（最新は12.14、2026年5月16日リリース） Debian 13（trixie）：LTS含め2030年まで（最新は13.6、2026年7月11日リリース） Ubuntu 24.04 LTS：標準サポート2029年4月まで Ubuntu 26.04 LTS（Resolute Raccoon、2026年4月23日リリース）：2031年4月まで、Ubuntu Pro利用で最大10年 Ubuntu 24.04 LTSから26.04 LTSへの移行を考えている場合、2026年8月27日リリース予定の26.04.1（最初のポイントリリース）を待つのが実務的な定石です。リリース直後の細かい不具合が落ち着き、旧バージョンからの正式なアップグレード経路が開く目安になります。26.04ではcgroup v1の完全廃止（Dockerやコンテナ利用環境ではアップグレード自体がブロックされる可能性あり）、initramfs生成が initramfs-tools から Dracut へ、NTPが systemd-timesyncd から Chrony へ、/tmp がディスクから tmpfs（メモリ上）へ、Pythonが3.12から3.13へ、といった変更があります。この記事の点検を26.04で行うと、enabledの一覧から systemd-timesyncd.service が消えて chrony.service が現れます——これは異常ではなく仕様変更です。Pythonスクリプトを常駐させている場合は3.13での互換性確認も必要になります。 Secure Boot証明書の期限切れという別種のリスク 2026年時点で押さえておきたい注意喚起として、多くのPCに標準搭載されている2013年発行のUEFI Secure Boot CA（証明書認証局）が失効した件があります。Debianプロジェクトは、今後の shim-signed のアップデートによってSecure Bootが有効なシステムが起動できなくなる可能性があるとして、PCメーカー（OEM）から提供されるCA・KEK・DBXの更新を適用するよう強く推奨しています。自分の環境がSecure Boot有効かは次で確認できます（読み取りのみ）。 mokutil --sb-state SecureBoot enabled と出た場合は、メーカーのサポートページでUEFI／BIOSファームウェア更新が出ていないかを確認しておくと安心です。SecureBoot disabled やコマンドが見つからない環境では、この問題の影響を受けません。 点検を1本のコマンドにまとめる 毎回打ち直すのは続かないので、読み取りのみの確認をまとめておくと定期点検が楽になります。以下はすべて読み取りのみ、システムを変更しません。 { echo "=== 自動起動オンのサービス ===" systemctl list-unit-files --type=service --state=enabled --no-pager echo "=== UNSAFE判定 ===" systemd-analyze security --no-pager | grep -E "UNSAFE|EXPOSED" echo "=== 待ち受けポート ===" ss -tulpn echo "=== 失敗ユニット ===" systemctl --failed --no-pager } | sudo tee ~/audit-$(date +%Y%m%d).txt 出力をファイルに残しておくと、次回との差分が最大の武器になります。前回なかったサービスがenabledに増えていたり、待ち受けポートが新しく開いていたりすれば、それが最初に見るべき箇所です。差分はこう取ります。 diff ~/audit-20260820.txt ~/audit-20260920.txt 月1回、あるいはOSのアップグレード直後とソフトを新しく入れた直後に走らせるだけで十分です。毎日やる必要はありません。手間と効果が釣り合う頻度を選ぶほうが、結果的に長続きします。 まとめ：UNSAFEの数を減らすのではなく、不要な常駐を減らす systemctl list-unit-files --state=enabled で自動起動オンの一覧を出し、systemd-analyze security でexposureスコアを見て、ss -tulpn で外に開いているポートと突き合わせる——この3本で、自動起動サービスの棚卸しはひととおり完結します。判断の軸は「UNSAFEかどうか」ではなく「自分が使っていない、かつ外に開いている」の一点です。ssh.service が9.6でUNSAFEでも、それはUbuntu 24.04 LTSの標準状態であって異常ではありません。止めるときは stop で数日試してから disable --now、戻すのは enable --now。SSH設定は元ファイルを触らず /etc/ssh/sshd_config.d/ にファイルを1枚足す形にすれば、削除するだけで元通りです。そして設定作業より優先度が高いのは、Debian 11が2026年8月31日にサポート終了する点や、Ubuntu 26.04.1が2026年8月27日に出る点といったOSの期限と、unattended-upgrades を有効に保つことです。修正が届く状態を保つことが、いちばん手間の少ない防御になります。