「サーバーに変な自動起動サービスやcronジョブが仕込まれていないか不安だけど、何をどう見ればいいか分からない」という相談をよく受けます。2026年8月9日から15日の週だけで未処理分を含む1,086件のLinuxカーネルCVEがまとめて公開され、JPCERT/CCも2026年5月15日にLinuxカーネルのローカル権限昇格の脆弱性（「Copy Fail」「Dirty Frag」）へ注意喚起を出すなど、攻撃者が何らかの方法で足がかりを得たあと、再起動後も居座るために自動起動サービスやcronジョブを仕込むケースは珍しくありません。この記事ではsystemctl list-unit-files --state=enabledとls /etc/cron.*を使い、Ubuntu/Debian環境で身に覚えのない自動起動サービス・cronジョブを自分の手で洗い出す方法を、正常/異常の具体的な見分け方まで含めて解説します。

systemctl list-unit-files --state=enabledで「今何が自動起動するか」を洗い出す

Linuxではsystemdが起動時に有効化されたサービスを順に立ち上げます。まずは「そもそも何が自動起動するように設定されているか」を一覧化するところから始めます。

コマンドの実行方法（sudoは不要）

以下をそのままコピーして実行してください。root権限は不要で、一般ユーザーのまま実行できます（設定を変更するわけではなく、閲覧するだけのコマンドのため）。

systemctl list-unit-files --state=enabled

これは「起動時に自動で有効化されるように設定されているユニット（サービス・タイマーなど）」だけを絞り込んで表示するコマンドです。

出力例と正常構成の見分け方（Ubuntu 26.04 LTS / Debian 13.6の場合）

Ubuntu 26.04 LTS「Resolute Raccoon」やDebian 13「Trixie」（最新ポイントリリースは2026年7月11日のDebian 13.6）のサーバー用途の標準構成では、おおむね次のようなサービスが並びます。

UNIT FILE                             STATE   VENDOR PRESET
apparmor.service                      enabled enabled
cron.service                          enabled enabled
fail2ban.service                      enabled enabled
networkd-dispatcher.service           enabled enabled
rsyslog.service                       enabled enabled
ssh.service                           enabled enabled
systemd-timesyncd.service             enabled enabled
ufw.service                           enabled enabled
unattended-upgrades.service           enabled enabled

9 unit files listed.

この中に、次のような特徴を持つ行が混ざっていたら要注意です。

  • OSの標準機能やインストールした覚えのあるアプリケーションのどれにも当てはまらない名前（例：kworkerd.serviceやsystemd-helperd.serviceのように、本物のカーネルスレッドやsystemd本体の名前に似せた紛らわしい名前）
  • ファイル名がランダムな英数字だけの並び
  • 心当たりのないアプリ名だが、インストールした記憶がない

ここで重要なのは「見慣れない＝即異常」ではないという点です。ミドルウェアや監視エージェントを入れると増えるのは正常なので、次の手順で「自分が入れたものかどうか」を裏付けます。

「見慣れないサービス名」を裏付ける3つのコマンド

目的

コマンド

見るポイント

実体のファイルパスと実行内容を見る

systemctl cat サービス名

ExecStart=に指定されているパスが/tmpや/dev/shm、ホームディレクトリ配下など、通常アプリが置かれない場所を指していないか

apt管理下のファイルか確認する

dpkg -S /etc/systemd/system/サービス名

「パッケージが見つかりません」と返ってきたら、apt経由でインストールされたものではない（=手動で置かれた）可能性が高い

いつ有効化されたか確認する

ls -la --time-style=full-iso /etc/systemd/system/*.service

自分が作業した記憶のない日時に更新されたファイルがないか

なお、Ubuntu 26.04 LTSではsystemdにおけるSystem Vスクリプト（/etc/init.d/形式の旧式スクリプト）の互換サポートが削除されています。古いサーバーから引き継いだ独自スクリプトがあると、systemctlの一覧に出てこないまま動き続けている場合があるので、legacyな自動起動を使っている心当たりがあればls /etc/init.d/も合わせて確認してください。サービス点検の全体像はsystemd-analyze security点検2026年8月版でも扱っているので、不要なサービス自体を止めたい場合はそちらも参考にしてください。

ls /etc/cron.*と各ユーザーのcrontabで仕込まれたジョブを確認する

systemdのタイマーだけでなく、昔ながらのcronも自動起動の定番の仕込み先です。Ubuntu/Debianではcron関連の設定が複数の場所に分かれているため、1箇所だけ見て終わりにしないことが大切です。

/etc/crontab・cron.d・cron.daily/weekly/monthlyの中身を見る

cat /etc/crontab
ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly /etc/cron.monthly

catは設定ファイルの中身を、ls -laはディレクトリ内のファイル一覧と最終更新日時を見るコマンドです。いずれも一般ユーザーで実行できます（root所有のファイルでも大半は読み取り権限があります）。正常な/etc/crontabはおおむね次のような、コメント行と空行だけのシンプルな内容です。

# /etc/crontab: system-wide crontab
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.daily
25 6    * * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.hourly

一方、次のような行が/etc/cron.d/配下のファイルなどに追加されていたら、内容を精査してください。

  • curlやwgetで外部URLから何かを取得し、そのままシェルに渡している行（例：取得したスクリプトをパイプで直接実行する形）
  • base64などでエンコードされた読めない文字列を含む行
  • 1分おき・5分おきなど、通常の運用では不自然なほど短い間隔で実行される行
  • ファイルの更新日時が、自分が作業した�covery記憶のない日時になっている行

怪しい行を見つけても、その場で内容を実行して確認するのは避けてください。catで中身を読むだけにとどめ、次の章の手順で対処します。

ユーザーごとのcrontab（sudo crontab -l -u ユーザー名）も忘れずに

ここまでの/etc/crontabや/etc/cron.d/はシステム全体の設定ですが、ユーザーごとに個別のcrontabも存在します。Ubuntu/Debianでは/var/spool/cron/crontabs/に保存されており、中身を直接見るには権限が必要です。

sudo ls /var/spool/cron/crontabs/
sudo crontab -l -u ユーザー名

いずれもsudoが必要です（他人のcrontabを読む操作なのでroot権限が要求されます）。設定を変更する操作ではないので、実行しても環境に影響はありません。ここに、普段使っていないユーザーや、削除したはずの退職者・旧担当者のアカウントの下にジョブが登録されていないかも確認してください。

なお本記事の手順はUbuntu/Debian系（Ubuntu 26.04 LTS「Resolute Raccoon」／Debian 13「Trixie」13.6）を基準にしています。CentOS・Rocky Linux・AlmaLinuxなどRHEL系ではuser crontabの格納パスが異なり（/var/spool/cron/直下）、SSHのサービス名もsshd.serviceになるなど呼び方が違う場合があるので、他ディストリで同じコマンドを打つ際は名称の違いに注意してください（ちなみにUbuntu 26.04 LTSではSSHのサービス名がssh.serviceで統一され、Fail2Banの設定もこれを明示的に対象にするよう変更されています）。

見つけた不審なサービス・cronジョブへの対処と元に戻す方法

ここまでの点検で「これは覚えがない」というサービスやcronジョブが見つかった場合の進め方です。焦って削除するのではなく、記録を残しながら段階的に対処します。

  1. まず記録する：削除・無効化する前に、該当のファイル内容やサービス名をメモまたはコピーして保存しておく（あとで調査や相談をする際の手がかりになります）
  2. 無効化する（systemdサービスの場合）：sudo systemctl disable --now サービス名。disableだけだと次回起動時から自動起動しなくなるだけで、今動いているプロセスは止まらないため、--nowを付けて即時停止も行います
  3. 元に戻せます：無効化しても設定ファイル自体は残るので、誤検知だった場合はsudo systemctl enable --now サービス名で元の状態に戻せます
  4. cronジョブは削除ではなく隔離する：sudo mv /etc/cron.d/怪しいファイル名 ~/quarantine_$(date +%Y%m%d)/のように、いったん別ディレクトリへ移動するだけにとどめる（即座に消してしまうと、後から「何が仕込まれていたか」を確認できなくなります）

ここで見つかったものが、単に自分や過去の担当者が入れた監視ツール・バックアップスクリプトだったというオチも多くあります。判断に迷う場合は無理に一人で結論を出さず、記録した内容を持って詳しい人に相談してください。逆に、外部との不審な通信を伴うなど「乗っ取られている可能性がある」と判断した場合は、自動起動の削除だけで済ませず、パスワード変更・SSH鍵の見直し・システム全体の再インストールまで視野に入れた対応が必要です。合わせて、CUPSやAvahiのように使っていなければ止めてよいサービスの整理はCUPS・Avahi点検2026年8月版｜不要サービスの止め方にまとめているので、自動起動の棚卸しのついでに見直しておくと点検の抜け漏れが減ります。

点検を1回で終わらせず、定期的な習慣にする

今回のsystemctl list-unit-files --state=enabledとls /etc/cron.*による点検は、月1回など決まったタイミングで繰り返すことに意味があります。特に、Debian 11「Bullseye」の無償セキュリティアップデートは2026年8月31日で終了するため、古いOSを使い続けているサーバーでは既知の脆弱性を突かれるリスクが上がり、その後に自動起動の仕込みが行われる可能性も上がります。該当するサーバーがあれば、点検と並行してDebian 13へのアップグレード時期も検討してください。

  • 点検はroot権限不要で始められる（systemctl list-unit-files・ls・catはいずれも一般ユーザーで実行可能）
  • 設定変更を伴う操作（無効化・停止）は必ずsudoが必要で、かつenableで元に戻せる
  • 「見慣れない」だけで判断せず、systemctl catやdpkg -Sで裏付けを取ってから対処する

まとめ

systemctl list-unit-files --state=enabledで自動起動サービスの一覧を、ls /etc/cron.*とcrontab -l -uでcronジョブを洗い出せば、Ubuntu/Debianサーバーの「気づかないうちに何かが仕込まれていないか」は初心者でも自分の手で確認できます。ポイントは、閲覧系のコマンドはsudo不要で気軽に試せること、見慣れない項目はsystemctl catやdpkg -Sで裏付けてから判断すること、そして無効化・隔離は元に戻せる形で行うことです。月1回の習慣にして、Debian 11のサポート終了(2026年8月31日)のような節目のタイミングも点検のきっかけにしてください。